draft-ietf-tsvwg-rsvp-pcn-07.txt   draft-ietf-tsvwg-rsvp-pcn-08.txt 
Internet Engineering Task Force Georgios Karagiannis Internet Engineering Task Force Georgios Karagiannis
Internet-Draft University of Twente Internet-Draft University of Twente
Intended status: Experimental Anurag Bhargava Intended status: Experimental Anurag Bhargava
Expires: April 21, 2014 Cisco Systems, Inc. Expires: August 14, 2014 Cisco Systems, Inc.
October 21, 2013 February 14, 2014
Generic Aggregation of Resource ReSerVation Protocol (RSVP) Generic Aggregation of Resource ReSerVation Protocol (RSVP)
for IPv4 And IPv6 Reservations over PCN domains for IPv4 And IPv6 Reservations over PCN domains
draft-ietf-tsvwg-rsvp-pcn-07 draft-ietf-tsvwg-rsvp-pcn-08
Abstract Abstract
This document specifies extensions to Generic Aggregated RSVP This document specifies extensions to Generic Aggregated RSVP
[RFC4860] for support of the PCN Controlled Load (CL) and Single RFC 4860 for support of the PCN Controlled Load (CL) and Single
Marking (SM) edge behaviors over a Diffserv cloud using Pre- Marking (SM) edge behaviors over a Diffserv cloud using Pre-
Congestion Notification. Congestion Notification.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2014. This Internet-Draft will expire on August 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 38 skipping to change at page 2, line 38
1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Overview and Motivation . . . . . . . . . . . . . . . . . . . 4 1.2. Overview and Motivation . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Organization of This Document . . . . . . . . . . . . . . . . 11 1.4. Organization of This Document . . . . . . . . . . . . . . . . 11
2. Overview of RSVP extensions and Operations . . . . . . . . . . . 11 2. Overview of RSVP extensions and Operations . . . . . . . . . . . 11
2.1. Overview of RSVP Aggregation Procedures in PCN domains . . . . . 11 2.1. Overview of RSVP Aggregation Procedures in PCN domains . . . . . 11
2.2. PCN Marking and encoding and transport of pre-congestion 2.2. PCN Marking and encoding and transport of pre-congestion
Information . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Information . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Traffic Classification Within The Aggregation Region . . . . . . 13 2.3. Traffic Classification Within The Aggregation Region . . . . . . 13
2.4. Deaggregator (PCN-egress-node) Determination . . . . . . . . . . 13 2.4. Deaggregator (PCN-egress-node) Determination . . . . . . . . . . 13
2.5. Mapping E2E Reservations Onto Aggregate Reservations . . . . . . 14 2.5. Mapping E2E Reservations Onto Aggregate Reservations . . . . . . 13
2.6 Size of Aggregate Reservations . . . . . . . . . . . . . . . . . 15 2.6 Size of Aggregate Reservations . . . . . . . . . . . . . . . . . 14
2.7. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . . . 15 2.7. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . . . 14
2.8. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . . .15 2.8. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . . .14
2.9. Inter-domain Routes . . . . . . . . . . . . . . . . . . . . . . 15 2.9. Inter-domain Routes . . . . . . . . . . . . . . . . . . . . . . 15
2.10. Reservations for Multicast Sessions . . . . . . . . . . . . . . 15 2.10. Reservations for Multicast Sessions . . . . . . . . . . . . . . 15
2.11. Multi-level Aggregation . . . . . . . . . . . . . . . . . . . . 15 2.11. Multi-level Aggregation . . . . . . . . . . . . . . . . . . . . 15
2.12. Reliability Issues . . . . . . . . . . . . . . . . . . . . . . 15 2.12. Reliability Issues . . . . . . . . . . . . . . . . . . . . . . 15
2.13. Message Integrity and Node Authentication . . . . . . . . . . 16 2.13. Message Integrity and Node Authentication . . . . . . . . . . 15
3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . . 16 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Receipt of E2E Path Message By PCN-ingress-node 3.1. Receipt of E2E Path Message by PCN-ingress-node
(aggregating router) . . . . . . . . . . . . . . . . . . . . . . 17 (aggregating router) . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Handling Of E2E Path Message By Interior Routers . . . . . . . 17 3.2. Handling Of E2E Path Message by Interior Routers . . . . . . . 16
3.3. Receipt of E2E Path Message By PCN-egress-node 3.3. Receipt of E2E Path Message by PCN-egress-node
(deaggregating router) . . . . . . . . . . . . . . . . . . . . . 17 (deaggregating router) . . . . . . . . . . . . . . . . . . . . . 16
3.4. Initiation of new Aggregate Path Message By PCN-ingress-node 3.4. Initiation of new Aggregate Path Message By PCN-ingress-node
(Aggregating Router) . . . . . . . . . . . . . . . . . . . . . 18 (Aggregating Router) . . . . . . . . . . . . . . . . . . . . . 16
3.5. Handling Of new Aggregate Path Message By Interior Routers . . 18 3.5. Handling Of new Aggregate Path Message by Interior Routers . . 16
3.6. Handling of E2E Resv Message by Deaggregating Router . . . . . 18 3.6 Handling Of Aggregate Path Message by Deaggregating Router . . 16
3.7. Handling Of E2E Resv Message By Interior Routers . . . . . . . 18 3.7. Handling of E2E Resv Message by Deaggregating Router . . . . . 17
3.8. Initiation of New Aggregate Resv Message By Deaggregating Router 19 3.8. Handling Of E2E Resv Message by Interior Routers . . . . . . . 17
3.9. Handling of Aggregate Resv Message by Interior Routers . . . . 18 3.9. Initiation of New Aggregate Resv Message By Deaggregating Router 17
3.10. Handling of E2E Resv Message by Aggregating Router . . . . . . 19 3.10. Handling of Aggregate Resv Message by Interior Routers . . . 18
3.11. Handling of Aggregated Resv Message by Aggregating Router . . 19 3.11. Handling of E2E Resv Message by Aggregating Router . . . . . . 18
3.12. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 20 3.12. Handling of Aggregated Resv Message by Aggregating Router . . 18
3.13. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 20 3.13. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 19
3.14. Handling of Data On Reserved E2E Flow by Aggregating Router . 20 3.14. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 19
3.15. Procedures for Multicast Sessions . . . . . . . . . . . . . . 21 3.15. Handling of Data On Reserved E2E Flow by Aggregating Router . 19
3.16. Misconfiguration of PCN node . . . . . . . . . . . . . . . . 21 3.16. Procedures for Multicast Sessions . . . . . . . . . . . . . . 19
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 21 3.17. Misconfiguration of PCN node . . . . . . . . . . . . . . . . 19
4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.18. PCN based Flow Termination . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 26 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26 4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Normative References . . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23
9. Informative References . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Appendix A: Example Signaling Flow . . . . . . . . . . . . . . . 28 8. Normative References . . . . . . . . . . . . . . . . . . . . . . 24
11. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Informative References . . . . . . . . . . . . . . . . . . . . . 25
10. Appendix A: Example Signaling Flow . . . . . . . . . . . . . . . 25
11. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
1.1 Objective 1.1 Objective
Pre-Congestion Notification (PCN) can support the quality of service Pre-Congestion Notification (PCN) can support the quality of service
(QoS) of inelastic flows within a Diffserv domain in a simple, (QoS) of inelastic flows within a Diffserv domain in a simple,
scalable, and robust fashion. Two mechanisms are used: admission scalable, and robust fashion. Two mechanisms are used: admission
control and flow termination. Admission control is used to decide control and flow termination. Admission control is used to decide
whether to admit or block a new flow request, while flow termination whether to admit or block a new flow request, while flow termination
is used in abnormal circumstances to decide whether to terminate some is used in abnormal circumstances to decide whether to terminate some
skipping to change at page 4, line 25 skipping to change at page 4, line 25
rate of PCN-traffic is metered on every link in the domain, and PCN- rate of PCN-traffic is metered on every link in the domain, and PCN-
packets are appropriately marked when certain configured rates are packets are appropriately marked when certain configured rates are
exceeded. These configured rates are below the rate of the link, exceeded. These configured rates are below the rate of the link,
thus providing notification to boundary nodes about overloads before thus providing notification to boundary nodes about overloads before
any congestion occurs (hence "pre-congestion" notification). The any congestion occurs (hence "pre-congestion" notification). The
PCN-egress-nodes measure the rates of differently marked PCN traffic PCN-egress-nodes measure the rates of differently marked PCN traffic
in periodic intervals and report these rates to the Decision Points in periodic intervals and report these rates to the Decision Points
for admission control and flow termination; the Decision Points use for admission control and flow termination; the Decision Points use
these rates to make decisions. The Decision Points may be collocated these rates to make decisions. The Decision Points may be collocated
with the PCN-ingress-nodes, or their function may be implemented in a with the PCN-ingress-nodes, or their function may be implemented in a
centralized node. For more details see [RFC5559], [RFC6661], and another node. For more details see [RFC5559], [RFC6661], and
[RFC6662]. [RFC6662].
The main objective of this document is to specify the signaling The main objective of this document is to specify the signaling
protocol that can be used within a Pre-Congestion Notification (PCN) protocol that can be used within a Pre-Congestion Notification (PCN)
domain to carry reports from a PCN-egress-node to a PCN Decision domain to carry reports from a PCN-ingress-node to a PCN Decision
point, considering that the PCN decision Point and PCN-ingress-node point, considering that the PCN Decision Point and PCN-egress-node
are collocated. are collocated.
If the PCN decision point is not collocated with the PCN-ingress-node If the PCN Decision Point is not collocated with the PCN-egress-node
then additional signaling procedures are required that are out of then additional signaling procedures are required that are out of
the scope of this document. Moreover, as mentioned above this the scope of this document. Moreover, as mentioned above this
architecture conforms with PBAC (Policy-Based Admission Control), architecture conforms with PBAC (Policy-Based Admission Control),
when decision point is located in a centralized node [RFC2753]. when the Decision Point is located in a another node then the PCN-
ingress-node [RFC2753].
Several signaling protocols can be used to carry reports from a PCN- Several signaling protocols can be used to carry information between
egress-node to a PCN-ingress-nodes. However, since both PCN-egress- PCN-boundary-nodes (PCN-ingress-node and PCN-egress-node). However,
node and PCN-ingress-nodes are located on the data path, a signaling since (1) both PCN-egress-node and PCN-ingress-nodes are located on
protocol that follows the same path as the data path, like RSVP the data path and (2) the admission control procedure needs to be
(Resource Reservation Protocol), is more suited for this purpose. In done at PCN-egress-node, a signaling protocol that follows the same
particular, this document specifies extensions to Generic path as the data path, like RSVP (Resource Reservation Protocol), is
Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) more suited for this purpose. In particular, this document specifies
and Single Marking (SM) edge behaviors over a Diffserv cloud using extensions to Generic Aggregated RSVP [RFC4860] for support of the
Pre-Congestion Notification. PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over
a Diffserv cloud using Pre-Congestion Notification.
1.2 Overview and Motivation 1.2 Overview and Motivation
Two main Quality of Service (QoS) architectures have been specified Two main Quality of Service (QoS) architectures have been specified
by the IETF. These are the Integrated Services (Intserv) [RFC1633] by the IETF. These are the Integrated Services (Intserv) [RFC1633]
architecture and the Differentiated Services (DiffServ) architecture architecture and the Differentiated Services (DiffServ) architecture
([RFC2475]). ([RFC2475]).
Intserv provides methods for the delivery of end-to-end Quality of Intserv provides methods for the delivery of end-to-end Quality of
Service (QoS) to applications over heterogeneous networks. One of the Service (QoS) to applications over heterogeneous networks. One of the
skipping to change at page 5, line 40 skipping to change at page 5, line 40
specified to solve this issue. One of these solutions is Intserv over specified to solve this issue. One of these solutions is Intserv over
Diffserv [RFC2998] including resource-based admission control (RBAC), Diffserv [RFC2998] including resource-based admission control (RBAC),
PBAC, assistance in traffic identification/classification, and PBAC, assistance in traffic identification/classification, and
traffic conditioning. Intserv over Diffserv can operate over a traffic conditioning. Intserv over Diffserv can operate over a
statically provisioned Diffserv region or RSVP aware. When it is RSVP statically provisioned Diffserv region or RSVP aware. When it is RSVP
aware, several mechanisms may be used to support dynamic provisioning aware, several mechanisms may be used to support dynamic provisioning
and topology-aware admission control, including aggregate RSVP and topology-aware admission control, including aggregate RSVP
reservations, per-flow RSVP, or a bandwidth broker. [RFC3175] reservations, per-flow RSVP, or a bandwidth broker. [RFC3175]
specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to- specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-
end reservations over aggregate RSVP reservations. In [RFC3175] the end reservations over aggregate RSVP reservations. In [RFC3175] the
RSVP aggregated reservation is characterized by a RSVP SESSION object RSVP generic aggregated reservation is characterized by a RSVP
using the 3-tuple <source IP address, destination IP address, SESSION object using the 3-tuple <source IP address, destination IP
Diffserv Code Point>. address, Diffserv Code Point>.
Several scenarios require the use of multiple generic aggregate Several scenarios require the use of multiple generic aggregate
reservations that are established for a given PHB from a given source reservations that are established for a given PHB from a given source
IP address to a given destination IP address, see [SIG-NESTED], IP address to a given destination IP address, see [SIG-NESTED],
[RFC4860]. For example, multiple generic aggregate reservations [RFC4860]. For example, multiple generic aggregate reservations
can be applied in the situation that multiple e2e reservations using can be applied in the situation that multiple E2E reservations using
different preemption priorities need to be aggregated through a PCN- different preemption priorities need to be aggregated through a PCN-
domain using the same PHB. By using multiple aggregate reservations domain using the same PHB. By using multiple aggregate reservations
for the same PHB allows enforcement of the different preemption for the same PHB allows enforcement of the different preemption
priorities within the aggregation region. This allows more efficient priorities within the aggregation region. This allows more efficient
management of the Diffserv resources, and in periods of resource management of the Diffserv resources, and in periods of resource
shortage, this allows sustainment of a larger number of E2E shortage, this allows sustainment of a larger number of E2E
reservations with higher preemption priorities. In particular, reservations with higher preemption priorities. In particular,
[SIG-NESTED] discusses in detail how end-to-end RSVP reservations can [SIG-NESTED] discusses in detail how end-to-end RSVP reservations can
be established in a nested VPN environment through RSVP aggregation. be established in a nested VPN environment through RSVP aggregation.
skipping to change at page 6, line 18 skipping to change at page 6, line 18
In particular, multiple such generic aggregate reservations can be In particular, multiple such generic aggregate reservations can be
established for a given PHB from a given source IP address to a given established for a given PHB from a given source IP address to a given
destination IP address. This is achieved by adding the concept of a destination IP address. This is achieved by adding the concept of a
Virtual Destination Port and of an Extended Virtual Destination Port Virtual Destination Port and of an Extended Virtual Destination Port
in the RSVP SESSION object. In addition to this, the RSVP SESSION in the RSVP SESSION object. In addition to this, the RSVP SESSION
object for generic aggregate reservations uses the PHB Identification object for generic aggregate reservations uses the PHB Identification
Code (PHB-ID) defined in [RFC3140], instead of using the Diffserv Code (PHB-ID) defined in [RFC3140], instead of using the Diffserv
Code Point (DSCP) used in [RFC3175]. The PHB-ID is used to identify Code Point (DSCP) used in [RFC3175]. The PHB-ID is used to identify
the PHB, or set of PHBs, from which the Diffserv resources are to be the PHB, or set of PHBs, from which the Diffserv resources are to be
reserved. reserved.
The RSVP like signaling protocol required to carry (1) requests from
The RSVP like signaling protocol required to carry reports from a a PCN-egress-node to a PCN-ingress-node and (2) reports from a
PCN-egress-node to a PCN-ingress-node needs to follow the PCN PCN-ingress-node to a PCN-egress-node needs to follow the PCN
signaling requirements defined in [RFC6663]. In addition to signaling requirements defined in [RFC6663]. In addition to
that the signaling protocol functionality supported by the PCN- that the signaling protocol functionality supported by the PCN-
ingress-nodes and PCN-egress-nodes needs to maintain logical ingress-nodes and PCN-egress-nodes needs to maintain logical
aggregate constructs (i.e. ingress-egress-aggregate state) and be aggregate constructs (i.e. ingress-egress-aggregate state) and be
able to map e2e reservations to these aggregate constructs. Moreover, able to map E2E reservations to these aggregate constructs. Moreover,
no actual reservation state is needed to be maintained inside the PCN no actual reservation state is needed to be maintained inside the PCN
domain, i.e., the PCN-interior-nodes are not maintaining any domain, i.e., the PCN-interior-nodes are not maintaining any
reservation state. reservation state.
This can be accomplished by two possible approaches: This can be accomplished by two possible approaches:
Approach (1): Approach (1):
o) adapting the RFC 4860 aggregation procedures to fit the PCN o) adapting the RFC 4860 aggregation procedures to fit the PCN
requirements with as little change as possible over the RFC 4860 requirements with as little change as possible over the RFC 4860
functionality functionality
o) hence performing aggregate RSVP signaling (even if it is to be o) hence performing aggregate RSVP signaling (even if it is to be
ignored by PCN interior nodes) ignored by PCN interior nodes)
o) using this aggregate RSVP signaling procedures to carry PCN o) using this aggregate RSVP signaling procedures to carry PCN
information from PCN-egress-node to the PCN-ingress-node. information between the PCN-boundary-nodes (PCN-ingress-node and
PCN-egress-node).
Approach (2): Approach (2):
o) adapting the RFC 4860 aggregation procedures to fit the PCN o) adapting the RFC 4860 aggregation procedures to fit the PCN
requirements with more significant changes over RFC4860 (i.e. requirements with more significant changes over RFC4860 (i.e.
the aspect of the procedures that have to do with maintaining the aspect of the procedures that have to do with maintaining
aggregate states and to do with mapping the e2e reservations to aggregate states and to do with mapping the E2E reservations to
aggregate constructs are kept, but the procedures that have to aggregate constructs are kept, but the procedures that have to
do with the aggregate RSVP signaling and aggregate reservation do with the aggregate RSVP signaling and aggregate reservation
establishment/maintenance are dropped). establishment/maintenance are dropped).
o) hence not performing aggregate RSVP signaling o) hence not performing aggregate RSVP signaling
o) piggy-backing of the PCN information inside the e2e RSVP o) piggy-backing of the PCN information inside the E2E RSVP
signaling. signaling.
Both approaches are probably viable, however, since the RFC 4860 Both approaches are probably viable, however, since the RFC 4860
operations have been thoroughly studied and implemented, it can be operations have been thoroughly studied and implemented, it can be
considered that the RFC 4860 solution can better deal with the more considered that the RFC 4860 solution can better deal with the more
challenging situations (rerouting in the PCN domain, failure of an challenging situations (rerouting in the PCN domain, failure of an
PCN-ingress-node, failure of an PCN-egress-node, rerouting towards a PCN-ingress-node, failure of an PCN-egress-node, rerouting towards a
different edge, etc.). This is the reason for choosing Approach (1) different edge, etc.). This is the reason for choosing Approach (1)
for the specification of the signaling protocol used to carry for the specification of the signaling protocol used to carry
PCN information from the PCN-egress-node to the PCN-ingress-node. PCN information between the PCN-boundary-nodes (PCN-ingress-node and
PCN-egress-node).
In particular, this document specifies extensions to Generic In particular, this document specifies extensions to Generic
Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL)
and Single Marking (SM) edge behaviors over a Diffserv cloud using and Single Marking (SM) edge behaviors over a Diffserv cloud using
Pre-Congestion Notification. Pre-Congestion Notification.
This document follows the PCN signaling requirements defined in This document follows the PCN signaling requirements defined in
[RFC6663] and specifies extensions to Generic Aggregated RSVP [RFC6663] and specifies extensions to Generic Aggregated RSVP
[RFC4860] for support of PCN edge behaviors as specified in [RFC4860] for support of PCN edge behaviors as specified in
[RFC6661] and [RFC6662]. Moreover, this document specifies how RSVP [RFC6661] and [RFC6662]. Moreover, this document specifies how RSVP
skipping to change at page 7, line 48 skipping to change at page 7, line 49
[RFC5670], [RFC6661], [RFC6662]. [RFC5670], [RFC6661], [RFC6662].
For readability, a number of definitions from [RFC3175] as well as For readability, a number of definitions from [RFC3175] as well as
definitions for terms used in [RFC5559], [RFC6661], and [RFC6662] are definitions for terms used in [RFC5559], [RFC6661], and [RFC6662] are
provided here, where some of them are augmented with new meanings: provided here, where some of them are augmented with new meanings:
Aggregator This is the process in (or associated with) the Aggregator This is the process in (or associated with) the
router at the ingress edge of the aggregation region router at the ingress edge of the aggregation region
(with respect to the end-to-end RSVP reservation) (with respect to the end-to-end RSVP reservation)
and behaving in accordance with [RFC4860]. In this and behaving in accordance with [RFC4860]. In this
document, it is also the PCN-ingress-node and the document, it is also the PCN-ingress-node. It is
decision point. It is important to notice that in important to notice that in the context of this
the context of this document the Aggregator MUST be document the Aggregator MUST be able to determine
able to determine the Deaggregator using the the Deaggregator using the procedures specified in
procedures specified in Section 4 of [RFC4860] and Section 4 of [RFC4860] and in Section 1.4.2 of
in Section 1.4.2 of [RFC3175]. [RFC3175].
Congestion level estimate (CLE):
The ratio of PCN-marked to total PCN-traffic
(measured in octets) received for a given ingress-
egress-aggregate during a given measurement period.
The CLE is used to derive the PCN-admission-state
and is also used by the report suppression procedure
if report suppression is activated.
Deaggregator This is the process in (or associated with) the Deaggregator This is the process in (or associated with) the
router at the egress edge of the aggregation region router at the egress edge of the aggregation region
(with respect to the end-to-end RSVP reservation) (with respect to the end-to-end RSVP reservation)
and behaving in accordance with [RFC4860]. In this and behaving in accordance with [RFC4860]. In this
document, it is also the PCN-egress-node. document, it is also the PCN-egress-node and
Decision Point.
E2E (or e2e) end to end E2E end to end
E2E Reservation This is an RSVP reservation such that: E2E Reservation This is an RSVP reservation such that:
(i) corresponding RSVP Path messages are initiated (i) corresponding RSVP Path messages are initiated
upstream of the Aggregator and terminated upstream of the Aggregator and terminated
downstream of the Deaggregator, and downstream of the Deaggregator, and
(ii) corresponding RSVP Resv messages are initiated (ii) corresponding RSVP Resv messages are initiated
downstream of the Deaggregator and terminated downstream of the Deaggregator and terminated
upstream of the Aggregator, and upstream of the Aggregator, and
skipping to change at page 8, line 36 skipping to change at page 8, line 45
An E2E RSVP reservation may be a per-flow An E2E RSVP reservation may be a per-flow
reservation, which in this document is only reservation, which in this document is only
maintained at the PCN-ingress-node and PCN-egress- maintained at the PCN-ingress-node and PCN-egress-
node. Alternatively, the E2E reservation may itself node. Alternatively, the E2E reservation may itself
be an aggregate reservation of various types (e.g., be an aggregate reservation of various types (e.g.,
Aggregate IP reservation, Aggregate IPsec Aggregate IP reservation, Aggregate IPsec
reservation, see [RFC4860]). As per regular RSVP reservation, see [RFC4860]). As per regular RSVP
operations, E2E RSVP reservations are operations, E2E RSVP reservations are
unidirectional. unidirectional.
PHB-ID (Per Hop Behavior Identification Code) E2E microflow a microflow where its associated packets are being
A 16-bit field containing the Per Hop Behavior forwarded on an E2E path.
Identification Code of the PHB, or of the set of
PHBs, from which Diffserv resources
are to be reserved. This field MUST be encoded as
specified in Section 2 of [RFC3140].
VDstPort (Virtual Destination Port)
A 16-bit identifier used in the SESSION that
remains constant over the life of the generic
aggregate reservation.
Extended vDstPort (Extended Virtual Destination Port) Extended vDstPort (Extended Virtual Destination Port)
An identifier used in the SESSION that remains An identifier used in the SESSION that remains
constant over the life of the generic aggregate constant over the life of the generic aggregate
reservation. The length of this idenitifier is 32- reservation. The length of this identifier is 32-
bits when IPv4 addresses are used and 128 bits when bits when IPv4 addresses are used and 128 bits when
IPv6 addresses are used. IPv6 addresses are used.
A sender(or Aggregator) that wishes to narrow the A sender(or Aggregator) that wishes to narrow the
scope of a SESSION to the sender-receiver pair (or scope of a SESSION to the sender-receiver pair (or
Aggregator-Deaggregator pair) SHOULD place its IPv4 Aggregator-Deaggregator pair) SHOULD place its IPv4
or IPv6 address here as a network unique or IPv6 address here as a network unique
identifier. A sender (or Aggregator) that wishes to identifier. A sender (or Aggregator) that wishes to
use a common session with other senders (or use a common session with other senders (or
Aggregators) in order to use a shared reservation Aggregators) in order to use a shared reservation
across senders (or Aggregators) MUST set this field across senders (or Aggregators) MUST set this field
to all zeros. In this document, the Extended to all zeros. In this document, the Extended
vDstPort SHOULD contain the IPv4 or IPv6 address of vDstPort SHOULD contain the IPv4 or IPv6 address of
the Aggregator. the Aggregator.
ETM-rate
The rate of excess-traffic-marked PCN-traffic
received at a PCN-egress-node for a given ingress-
egress-aggregate in octets per second.
Ingress-egress-aggregate (IEA):
The collection of PCN-packets from all PCN-flows
that travel in one direction between a specific pair
of PCN-boundary-nodes. In this document one RSVP
generic aggregated reservation is mapped to only
one ingress-egress-aggregate, while one
ingress-egress-aggregate is mapped to either
one or to more than one RSVP generic aggregated
reservations. PCN-flows and their PCN-traffic that
are mapped into a specific RSVP generic aggregated
reservation can also easily be mapped into their
corresponding ingress-egress-aggregate.
Microflow: a single instance of an application-to-application
(from [RFC2474]) flow of packets which is identified by source
address, destination address, protocol id, and
source port, destination port (where applicable).
PCN-domain: a PCN-capable domain; a contiguous set of PCN-domain: a PCN-capable domain; a contiguous set of
PCN-enabled nodes that perform Diffserv scheduling PCN-enabled nodes that perform Diffserv scheduling
[RFC2474]; the complete set of PCN-nodes that in [RFC2474]; the complete set of PCN-nodes that in
principle can, through PCN-marking packets, principle can, through PCN-marking packets,
influence decisions about flow admission and influence decisions about flow admission and
termination for the PCN-domain; includes termination for the PCN-domain; includes
the PCN-egress-nodes, which measure these the PCN-egress-nodes, which measure these
PCN-marks, and the PCN-ingress-nodes. PCN-marks, and the PCN-ingress-nodes.
PCN-boundary-node: a PCN-node that connects one PCN-domain to a node PCN-boundary-node: a PCN-node that connects one PCN-domain to a node
either in another PCN-domain or in a non-PCN-domain. either in another PCN-domain or in a non-PCN-domain.
PCN-interior-node: a node in a PCN-domain that is not a PCN- PCN-interior-node: a node in a PCN-domain that is not a PCN-
boundary-node. boundary-node.
PCN-node: a PCN-boundary-node or a PCN-interior-node. PCN-node: a PCN-boundary-node or a PCN-interior-node.
PCN-egress-node: a PCN-boundary-node in its role in handling PCN-egress-node: a PCN-boundary-node in its role in handling
traffic as it leaves a PCN-domain. In this traffic as it leaves a PCN-domain. In this
document the PCN-ingress-node operates also as a document the PCN-egress-node operates also as a
deaggregator. Decision Point and Deaggregator.
PCN-ingress-node: a PCN-boundary-node in its role in handling PCN-ingress-node: a PCN-boundary-node in its role in handling
traffic as it enters a PCN-domain. In this traffic as it enters a PCN-domain. In this
document the PCN-ingress-node operates also as a document the PCN-ingress-node operates also as a
Decision Point and aggregator. Aggregator.
PCN-traffic, PCN-traffic,
PCN-packets, PCN-packets,
PCN-BA: a PCN-domain carries traffic of different Diffserv PCN-BA: a PCN-domain carries traffic of different Diffserv
behavior aggregates (BAs) [RFC2474]. The PCN-BA behavior aggregates (BAs) [RFC2474]. The PCN-BA
uses the PCN mechanisms to carry PCN-traffic, and uses the PCN mechanisms to carry PCN-traffic, and
the corresponding packets are PCN-packets. the corresponding packets are PCN-packets.
The same network will carry traffic of other The same network will carry traffic of other
Diffserv BAs. The PCN-BA is Diffserv BAs. The PCN-BA is
distinguished by a combination of the Diffserv distinguished by a combination of the Diffserv
codepoint (DSCP) and ECN fields. codepoint (DSCP) and ECN fields.
Microflow: a single instance of an application-to-application
(from [RFC2474]) flow of packets which is identified by source
address, destination address, protocol id, and
source port, destination port (where applicable).
e2e microflow a microflow where its associated packets are being
forwarded on an E2E path.
PCN-flow: the unit of PCN-traffic that the PCN-boundary-node PCN-flow: the unit of PCN-traffic that the PCN-boundary-node
admits (or terminates); the unit could be a single admits (or terminates); the unit could be a single
e2e microflow (as defined in [RFC2474]) or some E2E microflow (as defined in [RFC2474]) or some
identifiable collection of microflows. identifiable collection of microflows.
RSVP generic aggregated reservation: an RSVP reservation that is PCN-admission-state:
The state ("admit" or "block") derived by the
Decision Point for a given ingress-egress-aggregate
based on statistics about PCN-packet marking. The
Decision Point decides to admit or block new flows
offered to the aggregate based on the current value
of the PCN-admission-state.
PCN-sent-rate
The rate of PCN-traffic received at a PCN-ingress-
node and destined for a given ingress-egress-
aggregate in octets per second.
PHB-ID (Per Hop Behavior Identification Code)
A 16-bit field containing the Per Hop Behavior
Identification Code of the PHB, or of the set of
PHBs, from which Diffserv resources
are to be reserved. This field MUST be encoded as
specified in Section 2 of [RFC3140].
RSVP generic aggregated reservation: an RSVP reservation that is
identified by using the RSVP SESSION object identified by using the RSVP SESSION object
for generic RSVP aggregate reservation. This RSVP for generic RSVP aggregated reservation. This RSVP
SESSION object is based on the RSVP SESSION object SESSION object is based on the RSVP SESSION object
specified in [RFC4860] augmented with the following specified in [RFC4860] augmented with the following
information: information:
o) the IPv4 DestAddress, IPv6 DestAddress SHOULD be o) the IPv4 DestAddress, IPv6 DestAddress SHOULD be
set to the IPv4 or IPv6 destination addresses, set to the IPv4 or IPv6 destination addresses,
respectively, of the Deaggregator (PCN-egress- respectively, of the Deaggregator (PCN-egress-
node) node)
o) PHB-ID (Per Hop Behavior Identification Code) o) PHB-ID (Per Hop Behavior Identification Code)
SHOULD be set equal to PCN-compatible Diffserv SHOULD be set equal to PCN-compatible Diffserv
codepoint(s). codepoint(s).
o) Extended vDstPort SHOULD be set to the IPv4 or o) Extended vDstPort SHOULD be set to the IPv4 or
IPv6 destination addresses, of the Aggregator IPv6 destination addresses, of the Aggregator
(PCN-ingress-node) (PCN-ingress-node)
Ingress-egress-aggregate (IEA): VDstPort (Virtual Destination Port)
The collection of PCN-packets from all PCN-flows
that travel in one direction between a specific pair
of PCN-boundary-nodes. An ingress-egress-aggregate
is identified by the combination of (1) PCN-BA
(i.e., combination of the DSCP and ECN fields),(2)
IP addresses of the specific pair of
PCN-boundary-nodes used by the
ingress-egress-aggregate. In this document one RSVP
generic aggregated reservation is mapped to only
one ingress-egress-aggregate, while one
ingress-egress-aggregate is mapped to either
one or to more than one RSVP generic aggregated
reservations.
PCN-admission-state:
The state ("admit" or "block") derived by the
Decision Point for a given ingress-egress-aggregate
based on statistics about PCN-packet marking. The
Decision Point decides to admit or block new flows
offered to the aggregate based on the current value
of the PCN-admission-state.
Congestion level estimate (CLE):
The ratio of PCN-marked to total PCN-traffic
(measured in octets) received for a given ingress-
egress-aggregate during a given measurement period.
The CLE is used to derive the PCN-admission-state
and is also used by the report suppression procedure
if report suppression is activated.
t-meas:
A configurable time interval that defines the
measurement period over which the PCN-egress-node
collects statistics relating to PCN-traffic marking.
t-fail:
An interval after which the Decision Point (i.e.,
PCN-ingress-node in this document) concludes that
communication from a given PCN-egress-node has failed
if it has received no reports from the
PCN-egress-node during that interval.
t-recvFail: A 16-bit identifier used in the SESSION that
A timer per ingress-egress-aggregate that the remains constant over the life of the generic
Decision point (i.e., PCN-ingress-node) sets every aggregate reservation.
time it receives an RSVP Aggregated RESV message for
that ingress-egress-aggregate. When its value
reaches t-fail it is assumed that the PCN-ingress-
node has lost contact with the PCN-egress-node.
Therefore the PCN-ingress-node blocks admission of
new PCN-flows into that aggregate and raises a
management alarm.
1.4. Organization of This Document 1.4. Organization of This Document
This document is organized as follows. Section 2 gives an overview of This document is organized as follows. Section 2 gives an overview of
RSVP extensions and operations. The elements of the used procedures RSVP extensions and operations. The elements of the used procedures
are specified in Section 3. Section 4 describes the protocol are specified in Section 3. Section 4 describes the protocol
elements. The security considerations are given in section 5 and the elements. The security considerations are given in section 5 and the
IANA considerations are provided in Section 6. IANA considerations are provided in Section 6.
2. Overview of RSVP extensions and Operations 2. Overview of RSVP extensions and Operations
2.1 Overview of RSVP Aggregation Procedures in PCN domains 2.1 Overview of RSVP Aggregation Procedures in PCN domains
The PCN-boundary-nodes, see Figure 1, can support RSVP SESSIONS for The PCN-boundary-nodes, see Figure 1, can support RSVP SESSIONS for
generic aggregated reservations {RFC4860], which are depending on generic aggregated reservations {RFC4860], which are depending on
ingress-egress-aggregates. In particular, one RSVP generic aggregated ingress-egress-aggregates. In particular, one RSVP generic aggregated
reservation matches to only one ingress-egress-aggregate. reservation matches to only one ingress-egress-aggregate.
However, one ingress-egress-aggregate matches to either However, one ingress-egress-aggregate matches to either
one or more than one RSVP generic aggregated reservations. one, or more than one, RSVP generic aggregated reservations.
In addition, to comply with this specification it is considered that In addition, to comply with this specification, the PCN-boundary
the PCN-boundary nodes are able to distinguish by using the addresses nodes need to distinguish and process (1) RSVP SESSIONS for generic
that the RSVP messages are addressed to, and process (1) RSVP aggregated sessions and their messages according to [RFC4860], (2)
SESSIONS for generic aggregated sessions and their messages according E2E RSVP sessions and messages according to [RFC2205]. Furthermore,
to [RFC4860], (2) e2e RSVP sessions and messages according to it is considered that by configuration the PCN-interior-nodes do not
[RFC2205]. Furthermore, it is considered that by configuration the intercept (nor process) RSVP messages associated with generic
PCN-interior-nodes are not able to distinguish neither RSVP generic aggregated reservation [RFC4860], or with end to end RSVP
aggregated sessions and their associated messages [RFC4860], nor e2e reservations [RFC2205]. Moreover, each Aggregator and Deaggregator
RSVP sessions and their associated messages [RFC2205]. (i.e., PCN-boundary-nodes) need to support policies to initiate and
maintain for each pair of PCN-boundary-nodes of the same PCN-domain
one ingress-egress-aggregate.
-------------------------- --------------------------
/ PCN-domain \ / PCN-domain \
|----| | | |----| |----| | | |----|
H--| R |\ |-----| |------| /| R |-->H H--| R |\ |-----| |------| /| R |-->H
H--| |\\| | |---| |---| | |//| |-->H H--| |\\| | |---| |---| | |//| |-->H
|----| \| | | I | | I | | |/ |----| |----| \| | | I | | I | | |/ |----|
| Agg |======================>| Deag | | Agg |======================>| Deag |
/| | | | | | | |\ /| | | | | | | |\
H--------//| | |---| |---| | |\\-------->H H--------//| | |---| |---| | |\\-------->H
skipping to change at page 12, line 43 skipping to change at page 12, line 31
Agg = Aggregator (PCN-ingress-node) Agg = Aggregator (PCN-ingress-node)
Deag = Deaggregator (PCN-egress-node) Deag = Deaggregator (PCN-egress-node)
I = Interior Router (PCN-interior-node) I = Interior Router (PCN-interior-node)
--> = E2E RSVP reservation --> = E2E RSVP reservation
==> = Aggregate RSVP reservation ==> = Aggregate RSVP reservation
Figure 1 : Aggregation of E2E Reservations Figure 1 : Aggregation of E2E Reservations
over Generic Aggregate RSVP Reservations over Generic Aggregate RSVP Reservations
in PCN domains, based on [RFC4860] in PCN domains, based on [RFC4860]
Moreover, each Aggregator and Deaggregator (i.e., PCN-boundary-nodes) Both the Aggregator and Deaggregator can maintain one or
MUST support policies to initiate and maintain for each pair of
PCN-boundary-nodes of the same PCN-domain one ingress-egress-
aggregate. Both the Aggregator and Deaggregator can maintain one or
more RSVP generic aggregated Reservations, but the Deaggregator is more RSVP generic aggregated Reservations, but the Deaggregator is
the entity that initiates these RSVP generic aggregated reservations. the entity that initiates these RSVP generic aggregated reservations.
Note that one RSVP generic aggregated reservation matches to only Note that one RSVP generic aggregated reservation matches to only
one ingress-egress-aggregate, while one ingress-egress-aggregate one ingress-egress-aggregate, while one ingress-egress-aggregate
matches to either one or to more than one RSVP generic aggregated matches to either one or to more than one RSVP generic aggregated
reservations. This can be accomplished by using for the different reservations. This can be accomplished by using for the different
RSVP generic aggregated reservations the same combinations of RSVP generic aggregated reservations the same combinations of
ingress and egress identifiers, but with a different PHB-ID value ingress and egress identifiers, but with a different PHB-ID value
(see [RFC4860]). The procedures for aggregation of E2E reservations (see [RFC4860]). The procedures for aggregation of E2E reservations
over generic aggregate RSVP reservations are the same as the over generic aggregate RSVP reservations are the same as the
procedures specified in Section 4 of [RFC4860], augmented with the procedures specified in Section 4 of [RFC4860], augmented with the
following ones, see also Section 2.5: ones specified in Section 2.5.
o) Aggregator (PCN-ingress-node) and Deaggregator (PCN-egress-node) One significant difference between this document and [RFC4860] is the
MUST be able to determine, for each received e2e Path message, in fact that in this document the admission control of E2E RSVP
which ingress-egress-aggregate it can be mapped to. reservations over the PCN core is performed according to the PCN
procedures, while in [RFC4860] this is achieved via first admitting
aggregate RSVP reservations over the aggregation region and then
admitting the E2E reservations over the aggregate RSVP reservations.
Therefore, in this document, the RSVP generic aggregate RSVP
reservations are not subject to admission control in the PCN-core,
and the E2E RSVP reservations are not subject to admission control
over the aggregate reservations. In turn, this means that several
procedures of [RFC4860] are significantly simplified in this
document:
o) Depending on policies the Aggregator and Deaggregator MUST be able o) unlike [RFC4860], the generic aggregate RSVP reservations need
to decide whether a RSVP generic aggregate reservations can be not be admitted in the PCN core.
mapped into an ingress-egress-aggregate, see Section 2.5 for more o) unlike [RFC4860], the RSVP aggregated traffic does not need to
details. be tunneled between Aggregator and Deaggregator, see Section
2.3.
o) unlike [RFC4860], the Deaggregator need not perform admission
control of E2E reservations over the aggregate RSVP
reservations.
o) unlike [RFC4860], there is no need for dynamic adjustment of
the RSVP generic aggregated reservation size, see Section 2.6.
2.2 PCN Marking and encoding and transport of pre-congestion 2.2 PCN Marking and encoding and transport of pre-congestion
information information
The method of PCN marking within the PCN domain is based on The method of PCN marking within the PCN domain is specified in
[RFC5670]. In addition, the method of encoding and transport of pre- [RFC5670]. In addition, the method of encoding and transport of pre-
congestion information is based [RFC6660]. The PHB-ID (Per Hop congestion information is specified in [RFC6660]. The PHB-ID (Per Hop
Behavior Identification Code) used SHOULD be set equal Behavior Identification Code) used SHOULD be set equal
to PCN-compatible Diffserv codepoint(s). to PCN-compatible Diffserv codepoint(s).
2.3. Traffic Classification Within The Aggregation Region 2.3. Traffic Classification Within The Aggregation Region
The PCN-ingress marks a PCN-BA using PCN-marking (i.e., combination The PCN-ingress marks a PCN-BA using PCN-marking (i.e., combination
of the DSCP and ECN fields), which interior nodes use to of the DSCP and ECN fields), which interior nodes use to
classify PCN-traffic. The PCN-traffic (e.g., e2e microflows) classify PCN-traffic. The PCN-traffic (e.g., E2E microflows)
belonging to an ingress-egress-aggregate can be classified only at belonging to a RSVP generic aggregated reservation can be
the PCN-boundary-nodes using the combination of (1) PCN-BA (i.e.,
combination of the DSCP and ECN fields), (2) IP addresses of the
specific pair of PCN-boundary-nodes used by a ingress-egress-
aggregate. The method of classification and traffic conditioning of
PCN-traffic and non-PCN traffic and PHB configuration is described in
[RFC6661] and [RFC6662]. Moreover, the PCN-traffic (e.g., e2e
microflows) belonging to a RSVP generic aggregated reservation can be
classified only at the PCN-boundary-nodes (i.e., Aggregator and classified only at the PCN-boundary-nodes (i.e., Aggregator and
Deaggregator) by using the RSVP SESSION object for RSVP generic Deaggregator) by using the RSVP SESSION object for RSVP generic
aggregated reservations, see Section 2.1 of [RFC4860]. It is aggregated reservations, see Section 2.1 of [RFC4860]. Note that the
considered that tunnels need to be used between Aggregators and DSCP value included in the SESSION object, SHOULD be set equal
Deaggregators, using the same procedures as specified in Section 4 of to a PCN-compatible Diffserv codepoint. Since no admission control
[RFC4860]. procedures over the RSVP generic aggregated reservations in the PCN-
core are required, unlike [RFC4860], the RSVP aggregated traffic need
not to be tunneled between Aggregator and Deaggregator. In this
document one RSVP generic aggregated reservation is mapped to only
one ingress-egress-aggregate, while one ingress-egress-aggregate is
mapped to either one or to more than one RSVP generic aggregated
reservations. PCN-flows and their PCN-traffic that are mapped into a
specific RSVP generic aggregated reservation can also easily be
classified into their corresponding ingress-egress-aggregate. The
method of traffic conditioning of PCN-traffic and non-PCN traffic and
PHB configuration is described in [RFC6661] and [RFC6662].
2.4. Deaggregator (PCN-egress-node) Determination 2.4. Deaggregator Determination
To comply with this specification it is considered that in order to The present document assumes the same dynamic Deaggregator
determine the Deaggregator, the same methods can be used as the ones determination method as used in [RFC4860].
described in Section 4 of [RFC4860] and in Section 1.4.2 of
[RFC3175]. In the context of this document this can be determined
very easily, since from the point of RSVP, the next RSVP hop for the
Aggregator in the downstream direction is the Deaggregator and the
next RSVP hop for the Deaggregator in the upstream direction is the
Aggregator.
2.5. Mapping E2E Reservations Onto Aggregate Reservations 2.5. Mapping E2E Reservations Onto Aggregate Reservations
To comply with this specification it is considered that for the To comply with this specification for the mapping of E2E reservations
mapping of e2e reservations onto aggregate reservations, the same onto aggregate reservations, the same methods MUST be used as the
methods can be used as the ones described in Section 4 of [RFC4860], ones described in Section 4 of [RFC4860], augmented by the following
augmented by the following rules: rules:
o) An Aggregator (PCN-ingress-node) MUST be able to determine for
each e2e Path message that arrives at its external interface in
which ingress-egress-aggregate it can be mapped to. This is
possible, see also Section 2.4, since from the point of RSVP, the
Deaggregator (PCN-egress-node) is one RSVP hop away from the
Aggregator (PCN-ingress-node). The Aggregator (PCN-ingress-node)
uses PCN related information sent by the Deaggregator to
map RSVP generic aggregated states to ingress-egress-aggregates.
o) A PCN-ingress-node (Aggregator) or PCN-egress-node (Deaggregator) o) An Aggregator (also PCN-ingress-node in this document) or
MUST use one or more policies to determine whether a RSVP generic Deaggregator (also PCN-egress-node and Decision Point in this
aggregated reservation can be mapped into an ingress-egress- document) MUST use one or more policies to determine whether a
aggregate. Note that one RSVP generic aggregated reservation RSVP generic aggregated reservation can be mapped into an ingress-
matches to only one ingress-egress-aggregate, while one ingress- Egress-aggregate. This can be accomplished by using for the
egress-aggregate matches to either one or to more than one RSVP different RSVP generic aggregated reservations the same
generic aggregated reservations. The Aggregator or the combinations of ingress and egress identifiers, but with a
Deaggregator MUST be able to map RSVP generic aggregated different PHB-ID value (see [RFC4860]) corresponding to the PCN
reservations into ingress-egress-aggregates. This can be specifications. In particular, the RSVP SESSION object specified
accomplished by using for the different RSVP generic aggregated in [RFC4860] augmented with the following information:
reservations the same combinations of ingress and egress
identifiers, but with a different PHB-ID value (see [RFC4860]). In
particular, each RSVP generic aggregated reservation is identified
by using the RSVP SESSION object [RFC4860]. The RSVP SESSION
object for generic aggregate reservations is based on the RSVP
SESSION object specified in [RFC4860] augmented with the following
information:
o) the IPv4 DestAddress, IPv6 DestAddress MUST be set to the IPv4 o) the IPv4 DestAddress, IPv6 DestAddress MUST be set to the
or IPv6 destination addresses, respectively, of the IPv4 or IPv6 destination addresses, respectively, of the
Deaggregator (PCN-egress-node), see [RFC4860]. Note that the Deaggregator (PCN-egress-node), see [RFC4860]. Note that the
PCN-domain is considered as being only one RSVP hop (for PCN-domain is considered as being only one RSVP hop (for
Generic aggregated RSVP or e2e RSVP). This means that the next Generic aggregated RSVP or E2E RSVP). This means that the next
RSVP hop for the Aggregator in the downstream direction is the RSVP hop for the Aggregator in the downstream direction is the
Deaggregator and the next RSVP hop for the Deaggregator in the Deaggregator and the next RSVP hop for the Deaggregator in the
upstream direction is the Aggregator. upstream direction is the Aggregator.
o) PHB-ID (Per Hop Behavior Identification Code) SHOULD be set o) PHB-ID (Per Hop Behavior Identification Code) SHOULD be set
equal to PCN-compatible Diffserv codepoint(s). equal to PCN-compatible Diffserv codepoint(s).
o) Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination o) Extended vDstPort SHOULD be set to the IPv4 or IPv6
addresses, of the Aggregator (PCN-ingress-node), see [RFC4860]. destination addresses, of the Aggregator (PCN-ingress-node),
see [RFC4860].
2.6. Size of Aggregate Reservations 2.6. Size of Aggregate Reservations
To comply with this specification it is considered that for the Since:(i) no admission control of E2 reservations over the RSVP
determination of the size of the RSVP generic aggregate reservations, aggregated reservations is required, and (ii) no admission control of
the same methods can be used as the ones described in [RFC4860] and the RSVP aggregated reservation over the PCN core is required,
Section 1.4.4. of [RFC3175]. the size of the generic aggregate reservation is irrelevant and can
be set to any arbitrary value by the Deaggreagtor. The Deaggregator
SHOULD set the value of a generic aggregate reservation to a null
bandwidth. We also observe that there is no need for dynamic
adjustment of the RSVP aggregated reservation size.
2.7. E2E Path ADSPEC update 2.7. E2E Path ADSPEC update
To comply with this specification it is considered that for the To comply with this specification, for the update of the E2E Path
update of the e2e Path ADSPEC, the same methods can be used as the ADSPEC, the same methods can be used as the ones described in
ones described in [RFC4860]. [RFC4860].
2.8. Intra-domain Routes 2.8. Intra-domain Routes
The PCN-interior-nodes are neither maintaining e2e RSVP nor RSVP The PCN-interior-nodes are neither maintaining E2E RSVP nor RSVP
generic aggregation states and reservations. Therefore, intra-domain generic aggregation states and reservations. Therefore, intra-domain
route changes will not affect intra-domain reservations since such route changes will not affect intra-domain reservations since such
reservations are not maintained by the PCN-interior-nodes. reservations are not maintained by the PCN-interior-nodes.
Furthermore, it is considered that by configuration, the PCN- Furthermore, it is considered that by configuration, the PCN-
interior-nodes are not able to distinguish neither RSVP generic interior-nodes are not able to distinguish neither RSVP generic
aggregated sessions and their associated messages [RFC4860], nor e2e aggregated sessions and their associated messages [RFC4860], nor E2E
RSVP sessions and their associated messages [RFC2205]. RSVP sessions and their associated messages [RFC2205].
2.9. Inter-domain Routes 2.9. Inter-domain Routes
The PCN-charter scope precludes inter-domain considerations. However, The PCN-charter scope precludes inter-domain considerations. However,
for solving inter-domain routes changes associated with the operation for solving inter-domain routes changes associated with the operation
of the RSVP messages, the same methods SHOULD be used as the ones of the RSVP messages, the same methods SHOULD be used as the ones
described in [RFC4860] and in Section 1.4.7 of described in [RFC4860] and in Section 1.4.7 of
[RFC3175]. [RFC3175].
skipping to change at page 15, line 51 skipping to change at page 15, line 27
2.11. Multi-level Aggregation 2.11. Multi-level Aggregation
PCN does not consider multi-level aggregations within the PCN domain. PCN does not consider multi-level aggregations within the PCN domain.
Therefore, the PCN-interior-nodes are not supporting multi-level Therefore, the PCN-interior-nodes are not supporting multi-level
aggregation procedures. However, the Aggregator and Deaggregator aggregation procedures. However, the Aggregator and Deaggregator
SHOULD support the multi-level aggregation procedures specified in SHOULD support the multi-level aggregation procedures specified in
[RFC4860] and in Section 1.4.9 of [RFC3175]. [RFC4860] and in Section 1.4.9 of [RFC3175].
2.12. Reliability Issues 2.12. Reliability Issues
To comply with this specification it is considered that for solving To comply with this specification, for solving possible reliability
possible reliability issues, the same methods can be used as the ones issues, the same methods MUST used as the ones described in Section 4
described in Section 4 of [RFC4860]. of [RFC4860].
2.13. Message Integrity and Node Authentication 2.13. Message Integrity and Node Authentication
To comply with this specification it is considered that for message To comply with this specification, for message integrity and node
integrity and node authentication, the same methods can be used as authentication, the same methods MUST be used as the ones described
the ones described in Section 4 of [RFC4860] and [RFC5559]. in Section 4 of [RFC4860] and [RFC5559].
3. Elements of Procedure 3. Elements of Procedure
This section describes the procedures used to implement the This section describes the procedures used to implement the
aggregated RSVP procedure over PCN. It is considered that the aggregated RSVP procedure over PCN. It is considered that the
procedures for aggregation of e2e reservations over generic aggregate procedures for aggregation of E2E reservations over generic aggregate
RSVP reservations are same as the procedures specified in Section RSVP reservations are same as the procedures specified in Section
4 of [RFC4860]. Please refer to [RFC4860] for all the below error 4 of [RFC4860] except where a departure from these procedures is
explicitly described in the present section. Please refer to
[RFC4860] for all the below error
cases: cases:
*) Incomplete message o) Incomplete message
*) Unexpected objects o) Unexpected objects
3.1. Receipt of E2E Path Message By PCN-ingress-node (aggregating
router)
When the e2e Path message arrives at the exterior interface of the
Aggregator, i.e., PCN-ingress-node, then standard RSVP generic
aggregation [RFC4860] procedures are used, augmented with the
following rules:
o) The e2e RSVP reservation session associated with an e2e Path
message that arrives at the external interface of the PCN-
ingress-node is mapped/matched onto an PCN ingress-egress-
aggregate.
o) If the timer t-recvFail does NOT expire for a given PCN-egress-
node, then:
o) If (1) the PCN-admission state for the ingress-egress-
aggregate associated with the received e2e Path is "admit",
the Decision Point (i.e., PCN-ingress-node) SHOULD allow the
new flow to be admitted to that PCN ingress-egress-
aggregate, see [RFC6661] and [RFC6662]. The e2e Path message
is then forwarded towards destination.
o) If for the same PCN ingress-egress-aggregate
the PCN-admission-state is "block", the request SHOULD NOT
be admitted by the PCN-ingress-node (Aggregator) and an e2e
PathErr message SHOULD be generated, using standard e2e RSVP
procedures [RFC4495]. This e2e PathErr message is sent to
the originating sender of the e2e Path message, using
standard e2e RSVP procedures [RFC2205], [RFC4495]. This e2e
PathErr message is sent to the originating sender of the e2e
Path message. The e2e RSVP error code "01: Admission Control
failure" and the "Sub-code = 2: Requested bandwidth
unavailable " specified in Appendix B of [RFC2205] SHOULD be
used for this purpose.
When the originating sender receives this e2e PathErr
message it SHOULD apply a PCN specific policy to generate an
e2e PathTear message to release all the possible Path states
initiated on the e2e RSVP aware nodes on the path towards
the PCN-ingress-node (Aggregator).
o) If the timer t-recvFail expires for a given PCN-egress-node, the 3.1. Receipt of E2E Path Message by Aggregating router
Decision Point (i.e., PCN-ingress-node) SHOULD NOT
allow the e2e microflow (i.e., PCN-flow) to be admitted to that
PCN ingress-egress-aggregate, see [RFC6661], [RFC6662]. The
admission or rejection procedure of a PCN-flow into the PCN-
domain is defined in detail in: [RFC6661] and [RFC6662].
If the Aggregator is not able to admit the e2e microflow it
SHOULD then generate an e2e PathErr message using standard e2e
RSVP procedures [RFC4495]. This e2e PathErr message is sent to
the originating sender of the e2e Path message. The e2e RSVP
error code "01: Admission Control failure" and the "Sub-code =
2: Requested bandwidth unavailable " specified in Appendix B of
[RFC2205] SHOULD be used for this purpose. When the originating
sender receives this e2e PathErr message it SHOULD apply a PCN
specific policy to generate an e2e PathTear message to release all
the possible Path states initiated on the e2e RSVP aware nodes on
the path towards the PCN-ingress-node (Aggregator).
The way of how the PCN-admission-state is maintained is specified in When the E2E Path message arrives at the exterior interface of the
[RFC6661] and [RFC6662]. The way of how the RSVP generic aggregated Aggregator, (also PCN-ingress-node in this document), then standard
reservation state is maintained is specified in [RFC4860]. RSVP generic aggregation [RFC4860] procedures are used.
3.2. Handling Of E2E Path Message By Interior Routers 3.2. Handling Of E2E Path Message by Interior Routers
The e2e Path messages traverse zero or more PCN-interior-nodes. The E2E Path messages traverse zero or more PCN-interior-nodes.
The PCN-interior-nodes receive the e2e Path message on an interior The PCN-interior-nodes receive the E2E Path message on an interior
interface and forward it on another interior interface. It is interface and forward it on another interior interface.
considered that by configuration the PCN-interior-nodes are not able It is considered that, by configuration, the PCN-interior-nodes
to distinguish neither e2e RSVP sessions and their associated ignore the E2E RSVP signaling messages [RFC2205]. Therefore, the E2E
messages [RFC2205]. Therefore, the e2e Path messages are simply Path messages are simply forwarded as normal IP datagrams.
forwarded as normal IP datagrams.
3.3. Receipt of E2E Path Message By PCN-egress-node (Deaggregating 3.3. Receipt of E2E Path Message by Deaggregating router
router)
When receiving the e2e Path message the PCN-egress-node When receiving the E2E Path message the Deaggregator (also PCN-
(Deaggregator) performs main regular [RFC4860] procedures, augmented egress-node and Decision Point in this document) performs the
with the following rules: regular [RFC4860] procedures, augmented with the following rules:
o) The PCN-egress-node MUST NOT perform the RSVP-TTL vs IP TTL- o) The Deaggregator MUST NOT perform the RSVP-TTL vs IP TTL-
check and MUST NOT update the ADspec Break bit. This is because check and MUST NOT update the ADspec Break bit. This is because
the whole PCN-domain is effectively handled by e2e RSVP as a the whole PCN-domain is effectively handled by E2E RSVP as a
virtual link on which integrated service is indeed supported virtual link on which integrated service is indeed supported
(and admission control performed) so that the Break bit MUST (and admission control performed) so that the Break bit MUST
NOT be set, see also [draft-lefaucheur-rsvp-ecn-01]. NOT be set, see also [draft-lefaucheur-rsvp-ecn-01].
o) If the Deaggregator does not maintain any RSVP generic The Deaggregator forwards the E2E Path message towards the
aggregated reservation states, then one or more of such states
are created during this step. Moreover, also at this step
the Deaggregator maps the new generated RSVP generic
aggregated reservations onto one ingress-egress-aggregate
maintained by the Deaggregator (PCN-egress-node), see Section
2.5.
The PCN-egress-nodes forwards the e2e Path message towards the
receiver. receiver.
3.4. Initiation of new Aggregate Path Message By PCN-ingress-node 3.4. Initiation of new Aggregate Path Message by Aggregating Router
(Aggregating Router)
To comply with this specification it is considered that for the To comply with this specification, for the initiation of the new RSVP
initiation of the new RSVP aggregated Path message by the PCN- generic aggregated Path message by the Aggregator (also PCN-ingress-
ingress-node (Aggregator), the same methods can be used as the ones node in this document), the same methods MUST be used as the ones
described in [RFC4860]. described in [RFC4860].
3.5. Handling Of new Aggregate Path Message By Interior Routers 3.5. Handling Of Aggregate Path Message By Interior Routers
The Aggregate Path messages traverse zero or more PCN-interior-nodes. The Aggregate Path messages traverse zero or more PCN-interior-nodes.
The PCN-interior-nodes receive the e2e Path message on an interior The PCN-interior-nodes receive the E2E Path message on an interior
interface and forward it on another interior interface. interface and forward it on another interior interface.
It is considered that by configuration, the PCN-interior-nodes are It is considered that, by configuration, the PCN-interior-nodes
not able to distinguish neither RSVP generic aggregated sessions and ignore the E2E RSVP signaling messages [RFC2205]. Therefore, the
their associated messages [RFC4860]. Therefore, the Aggregated Path Aggregated Path messages are simply forwarded as normal IP datagrams.
messages are simply forwarded as normal IP datagrams.
3.6. Handling of E2E Resv Message by Deaggregating Router 3.6. Handling Of Aggregate Path Message By Deaggregating Router
When the e2e Resv message arrives at the exterior interface of the When receiving the Aggregated Path message, the Deaggregator (also
Deaggregator, i.e., PCN-egress-node, then standard RSVP PCN-egress-node and Decision Point in this document) performs the
aggregation [RFC4860] procedures are used. It is important to be regular [RFC4860] procedures, augmented with the following rules:
noticed that according to [RFC4860] the Deaggregator is responsible
of performing admission control of the E2E RESV onto the generic
aggregate reservation.
3.7. Handling Of E2E Resv Message By Interior Routers o) When the received Aggregated Path message by the Deaggregator
contains the RSVP-AGGREGATE-IPv4-PCN-response or
RSVP-AGGREGATE-IPv6-PCN-response PCN objects, which carry the
PCN-sent-rate, then the procedures specified in Section 3.18 of
this document MUST be followed.
The e2e Resv messages traverse zero or more PCN-interior-nodes. The 3.7. Handling of E2E Resv Message by Deaggregating Router
PCN-interior-nodes receive the e2e Resv message on an interior
interface and forward it on another interior interface. It is
considered that by configuration the PCN-interior-nodes are not able
to distinguish neither e2e RSVP sessions and their associated
messages [RFC2205]. Therefore, the e2e Resv messages are simply
forwarded as normal IP datagrams.
3.8. Initiation of New Aggregate Resv Message By Deaggregating Router When the E2E Resv message arrives at the exterior interface of the
Deaggregator, (also PCN-egress-node and Decision Point in this
document) then standard RSVP aggregation [RFC4860] procedures are
used, augmented with the following rules:
To comply with this specification it is considered that for the o) The E2E RSVP session associated with an E2E Resv
initiation of the new RSVP aggregated Resv message by the PCN- message that arrives at the external interface of the Deaggregator
egress-node (Deaggregator), the same methods can be used as the ones is mapped/matched with an RSVP generic aggregate and with a PCN
described in Section 4 of [RFC4860] augmented with the following ingress-egress-aggregate.
rules:
o) At the end of each t-meas measurement interval, or less o) Depending on the type of the PCN edge behavior supported by the
frequently if "optional report suppression" is activated, see Deaggregator, the PCN admission control procedures specified in
[RFC6661], and [RFC6662], the PCN-egress-node MUST include the Section 3.3.1 of [RFC6661] or [RFC6662] MUST be followed. Since no
new PCN object that will be sent to the associated Decision admission control procedures over the RSVP aggregated reservations
Point (i.e., PCN-ingress-node). The PCN-egress-node reports the in the PCN-core are required, unlike [RFC4860], the Deaggregator
data it measures for a particular ingress-egress-aggregate in a does not perform any admission control of the E2E Reservation over
PCN object, as specified in Section 4 of this document (see the mapped generic aggregate RSVP reservation. If the PCN based
[RFC6661], and [RFC6662]). The address of the PCN-ingress- admission control procedure is successful then the Deaggregator
node, i.e., Aggregator, is the one specified in the same MUST allow the new flow to be admitted onto the associated RSVP
ingress-egress-aggregate. It is considered that the ingress- generic aggregation reservation and onto the PCN ingress-egress-
egress-aggregate state stores both IP addresses of the PCN- aggregate, see [RFC6661] and [RFC6662]. If the PCN based admission
ingress-node, i.e., Aggregator, and of the IP-egress-node, i.e., control procedure is not successful, then the E2E Resv MUST NOT be
Deaggregator. admitted onto the associated RSVP generic aggregate reservation and
onto the PCN ingress-egress-aggregation. The E2E Resv message is
further processed according to [RFC4860].
3.9. Handling of Aggregate Resv Message by Interior Routers The way of how the PCN-admission-state is maintained is specified in
[RFC6661] and [RFC6662].
The Aggregated Resv messages traverse zero or more PCN-interior- 3.8. Handling Of E2E Resv Message By Interior Routers
nodes. The PCN-interior-nodes receive the Aggregated Resv message on
an interior interface and forward it on another interior interface.
It is considered that by configuration, the PCN-interior-nodes are
not able to distinguish neither RSVP generic aggregated sessions and
their associated messages [RFC4860]. Therefore, the Aggregated Resv
messages are simply forwarded as normal IP datagrams.
3.10. Handling of E2E Resv Message by Aggregating Router The E2E Resv messages traversing the PCN core are IP addressed to the
Aggregating router and are not marked with Router Alert, therefore
the E2E Resv messages are simply forwarded as normal IP datagrams.
When the e2e Resv message arrives at the interior interface of the 3.9. Initiation of New Aggregate Resv Message By Deaggregating Router
Aggregating router, i.e., PCN-ingress-node, then standard RSVP
aggregation [RFC4860] procedures are used.
3.11. Handling of Aggregated Resv Message by Aggregating Router To comply with this specification, for the initiation of the new RSVP
generic aggregated Resv message by the Deaggregator (also PCN-egress-
node and Decision Point in this document), the same methods MUST be
used as the ones described in
Section 4 of [RFC4860] augmented with the following rules:
When the Aggregated Resv message arrives at the interior interface of o) The size of the generic aggregate reservation is irrelevant, see
the Aggregating router, i.e., PCN-ingress-node, then standard RSVP Section 2.6, and can be set to any arbitrary value by the PCN-
aggregation [RFC4860] procedures are used, augmented with the egress node. The Deaggregator SHOULD set the value of a RSVP
following rules: generic aggregate reservation to a null bandwidth. We also
observe that there is no need for dynamic adjustment of the RSVP
generic aggregated reservation size.
o) If the Decision Point is not collocated with the PCN-ingress- o) When [RFC6661] is used and the ETM-rate measured by the
node, then other procedures need to be specified of handling the Deaggregator contains a non-zero value for some
Aggregated Resv Message by the Aggregating router, i.e., PCN- ingress-egress-aggregate, see [RFC6661] and [RFC6662], the
ingress-node. Even though these procedures are out of the scope Deagregator MUST request the PCN-ingress-node to provide an
of this document, the PCN-ingress-node can refer to a central estimate of the rate (PCN-sent-rate) at which the Aggregator
decision point which can respond to the PCN ingress as per (also PCN-ingress-node in this document) is receiving PCN-traffic
[RFC2753] that is destined for the given ingress-egress-aggregate.
o) If the Decision point is collocated with the PCN-ingress-node, o) When [RFC6662] is used and the PCN-admission-state computed by the
then the PCN-ingress-node (i.e. Aggregator) SHOULD use the Deaggregator, on the basis of the CLE is "block" for the given
information carried by the PCN objects, see Section 4, to map ingress-egress-aggregate, the Deaggregator MUST request the PCN-
the RSVP generic aggregated state onto the maintained ingress- ingress-node to provide an estimate of the rate (PCN-sent-rate) at
egress-aggregate state at the Aggregator (PCN-ingress-node). which the Aggregator is receiving PCN-traffic that is
Furthermore, the Aggregator follows the steps specified in destined for the given ingress-egress-aggregate.
[RFC6661], [RFC6662]. Using the information contained in the PCN
object the Aggregator (i.e., PCN-ingress-node) can decide
whether the PCN-admission state for the ingress-egress-aggregate
is "admit" or "reject". Moreover, when the Aggregator (i.e.,
PCN-ingress-node) needs to terminate an amount of traffic
associated with one ingress-egress-aggregate (see bullet 2 in
Section 3.3.2 of [RFC6661] and [RFC6662]), then several
procedures of terminating e2e microflows can be deployed. The
default procedure of terminating e2e microflows (i.e., PCN-
flows) is as follows, see e.g., [RFC6661].
For the same ingress-egress-aggregate, select a number of e2e
microflows to be terminated in order to decrease the total
incoming amount of bandwidth associated with one ingress-egress-
aggregate by the amount of traffic to be terminated, see above.
In this situation the same mechanisms for terminating an e2e
microflow can be followed as specified in [RFC2205]. However,
based on a local policy, the Aggregator could use other ways of
selecting which microflows should be terminated.
For example, for the same ingress-egress-aggregate, select a
number of e2e microflows to be terminated or to reduce their
reserved bandwidth in order to decrease the total incoming
amount of bandwidth associated with one ingress-egress-aggregate
by the amount of traffic to be terminated. In this situation the
same mechanisms for terminating an e2e microflow or reducing
bandwidth associated with an e2e microflow can be followed as
specified in [RFC4495].
3.12. Removal of E2E Reservation o) In the above two cases and when the PCN-sent-rate needs to be
requested from the Aggregator, the Deaggregator MUST generate
and send an (refresh) Aggregated Resv message to the Aggregator
that MUST carry one of the following PCN objects, see Section 4.1,
depending on whether IPv4 or IPv6 is supported:
o) RSVP-AGGREGATE-IPv4-PCN-request
o) RSVP-AGGREGATE-IPv6-PCN-request.
To comply with this specification it is considered that for the 3.10. Handling of Aggregate Resv Message by Interior Routers
removal of e2e reservations, the same methods can be used as the ones
described in Section 4 of [RFC4860] and [RFC4495], augmented by the
methods described in Section 3.11.
3.13. Removal of Aggregate Reservation The Aggregated Resv messages traversing the PCN core are IP addressed
to the Aggregating router and are not marked with Router Alert,
therefore the Aggregated Resv messages are simply forwarded as normal
IP datagrams.
To comply with this specification it is considered that for the 3.11. Handling of E2E Resv Message by Aggregating Router
removal of RSVP generic aggregated reservations, the same methods can
be used as the ones described in Section 4 of [RFC4860] and Section
2.10 of [RFC3175]. In particular, should an aggregate reservation go
away (presumably due to a configuration change, route change, or
policy event), the e2e reservations it supports are no longer active.
They must be treated accordingly.
3.14. Handling of Data On Reserved E2E Flow by Aggregating Router When the E2E Resv message arrives at the interior interface of the
Aggregator (also PCN-ingress-node in this document), then standard
RSVP aggregation [RFC4860] procedures are used.
The handling of data on the reserved e2e Flow by Aggregating Router 3.12. Handling of Aggregated Resv Message by Aggregating Router
is using the procedures described in [RFC4860] augmented with:
When the Aggregated Resv message arrives at the interior interface of
the Aggregator, (also PCN-ingress-node in this document),
then standard RSVP aggregation [RFC4860] procedures are used,
augmented with the following rules:
o) the Aggregator SHOULD use the information carried by the PCN
objects, see Section 4, and follow the steps specified in
[RFC6661], [RFC6662]. If the "R" flag carried by the
RSVP-AGGREGATE-IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN-request
PCN objects is set to ON, see Section 4.1, then the Aggregator
follows the steps described in Section 3.4 of [RFC6661] and
[RFC6662] on calculating the PCN-sent-rate. In particular, the
Aggregator MUST provide the estimated current rate of PCN-traffic
received at that node and destined for a given ingress-egress-
aggregate in octets per second (the PCN-sent-rate). The way this
rate estimate is derived is a matter of implementation, see
[RFC6661] or [RFC6662].
o) the Aggregator initiates an Aggregated Path message. In
particular, when the Aggregator receives an Aggregated Resv
message which carries one of the following PCN objects:
RSVP-AGGREGATE-IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN-
request, with the flag "R" set to ON, see Section 4.1, the
Aggregator initiates an Aggregated Path message, and includes the
calculated PCN-sent-rate into the RSVP-AGGREGATE-IPv4-PCN-response
or RSVP-AGGREGATE-IPv6-PCN-response PCN objects, see Section 4.1,
which that MUST be carried by the Aggregated Path message. This
Aggregated Path message is sent towards the Deaggregator (also
PCN-egress-node and Decision Point in this document) that
requested the calculation of the PCN-sent-rate.
3.13. Removal of E2E Reservation
To comply with this specification, for the removal of E2E
reservations, the same methods MUST be used as the ones described in
Section 4 of [RFC4860] and [RFC4495].
3.14. Removal of Aggregate Reservation
To comply with this specification, for the removal of RSVP generic
aggregated reservations, the same methods MUST be used as the ones
described in Section 4 of [RFC4860] and Section 2.10 of [RFC3175]. In
particular, should an aggregate reservation go away (presumably due
to a configuration change, route change, or policy event), the E2E
reservations it supports are no longer active.
They MUST be treated accordingly.
3.15. Handling of Data On Reserved E2E Flow by Aggregating Router
The handling of data on the reserved E2E flow by Aggregator (also
PCN-ingress-node in this document) uses the procedures described
in [RFC4860] augmented with:
o) Regarding, PCN marking and traffic classification the procedures o) Regarding, PCN marking and traffic classification the procedures
defined in Section 2.2 and 2.4 of this document are used. defined in Section 2.2 and 2.3 of this document are used.
3.15. Procedures for Multicast Sessions 3.16. Procedures for Multicast Sessions
In this document no multicast sessions are considered. In this document no multicast sessions are considered.
3.16. Misconfiguration of PCN-node 3.17. Misconfiguration of PCN-node
In an event where a PCN-node is misconfigured within a PCN-domain, In an event where a PCN-node is misconfigured within a PCN-domain,
the desired behavior is same as described in Section 3.9. Therefore, the desired behavior is same as described in Section 3.10.
the Aggregated Resv messages are simply forwarded as normal IP
datagrams.
4. Protocol Elements 3.18 PCN based Flow Termination
The protocol elements in this document are using the protocol When the Deaggregator (also PCN-egress-node and Decision Point in
elements defined in Section 4 [RFC4860] and Section 3 of [RFC3175] this document) needs to terminate an amount of traffic associated
augmented with the following rules: with one ingress-egress-aggregate (see Section 3.3.2 of [RFC6661] and
[RFC6662]), then several procedures of terminating E2E microflows can
be deployed. The default procedure of terminating E2E microflows
(i.e., PCN-flows) is as follows, see i.e., [RFC6661] and [RFC6662].
o) A PCN-egress-node (i.e., Deaggregator) SHOULD send periodically For the same ingress-egress-aggregate, select a number of E2E
and at the end of each t-meas measurement interval, or less microflows to be terminated in order to decrease the total incoming
frequently if "optional report suppression" is activated, an amount of bandwidth associated with one ingress-egress-aggregate by
(refresh) aggregated RSVP message to the PCN-ingress-node (i.e. the amount of traffic to be terminated, see above. In this situation
aggregator), see [RFC6661] and [RFC6662]. the same mechanisms for terminating an E2E microflow can be followed
as specified in [RFC2205]. However, based on a local policy, the
Deaggregator could use other ways of selecting which microflows
should be terminated. For example, for the same ingress-egress-
aggregate, select a number of E2E microflows to be terminated or to
reduce their reserved bandwidth in order to decrease the total
incoming amount of bandwidth associated with one ingress-egress-
aggregate by the amount of traffic to be terminated. In this
situation the same mechanisms for terminating an E2E microflow or
reducing bandwidth associated with an E2E microflow can be followed
as specified in [RFC4495].
o) the DSCP value included in the SESSION object, SHOULD be set equal 4. Protocol Elements
to a PCN-compatible Diffserv codepoint.
o) An aggregated Resv message MUST carry one or more PCN The protocol elements in this document are using the ones defined in
objects, see Section 4.1, to report the data measured by an Section 4 of [RFC4860] and Section 3 of [RFC3175] augmented with the
PCN-egress-node (i.e., Deaggregator). following rules:
o) the DSCP value included in the SESSION object, SHOULD be set equal
to a PCN-compatible Diffserv codepoint.
o) As described in [RFC6661], [RFC6663], PCN reports o) Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination
from the PCN-egress-node (Deaggregator) to the decision point may addresses, of the Aggregator (also PCN-ingress-node in this
contain flow identifiers for individual flows within an document), see [RFC4860].
ingress-egress-aggregate that have recently experienced
excess-marking. Hence, the PCN report messages used by the PCN CL o) When the Deaggregator (also PCN-egress-node and Decision Point
edge behavior MUST be capable of carrying sequences of octet in this document) needs to request the PCN-sent-rate from the
strings constituting such identifiers. When the PCN CL edge PCN-ingress-node, see Section 3.9 of this document, the
behavior is used, the individual flow identifiers need to be Deaggregator MUST generate and send an (refresh) Aggregate
included in specific PCN objects, see Section 4.1 Resv message to the Aggregator that MUST carry one of the
(RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs, following PCN objects, see Section 4.1, depending on whether IPv4
RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs) or IPv6 is supported:
o) RSVP-AGGREGATE-IPv4-PCN-request
o) RSVP-AGGREGATE-IPv6-PCN-request.
o) When the Aggregator receives an Aggregate Resv message which
carries one of the following PCN objects:
RSVP-AGGREGATE-IPv4-PCN-request or
RSVP-AGGREGATE-IPv6-PCN-request, with the flag "R" set to ON, see
Section 4.1, then the Aggregator MUST generate and send to the
Deaggregator an Aggregated Path message which carries one of the
following PCN objects, see Section 4.1, depending on whether IPv4
or IPv6 is supported:
o) RSVP-AGGREGATE-IPv4-PCN-response,
o) RSVP-AGGREGATE-IPv6-PCN-response.
4.1 PCN objects 4.1 PCN objects
The PCN object reports data measured by a PCN-egress-node and This section describes four types of PCN objects that can be carried
carried by the generic aggregated RESV messages specified in by the (refresh) Aggregate Path or the (refresh) Aggregate Resv
[RFC4860]. PCN objects are defined for different PCN edge behavior messages specified in [RFC4860].
drafts. This document defines six types of PCN objects that belong
into the SESSION Class and need to be carried by
Aggregate RESV messages. These objects are:
RSVP-AGGREGATE-IPv4-PCN-SM, RSVP-AGGREGATE-IPv6-PCN-SM, These objects are:
RSVP-AGGREGATE-IPv4-PCN-CL, RSVP-AGGREGATE-IPv6-PCN-CL, o RSVP-AGGREGATE-IPv4-PCN-request,
RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs, RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs. o RSVP-AGGREGATE-IPv6-PCN-request,
o RSVP-AGGREGATE-IPv4-PCN-response,
o RSVP-AGGREGATE-IPv6-PCN-response.
o) RSVP-AGGREGATE-IPv4-PCN-SM: Single Marking (SM) PCN object, when o) RSVP-AGGREGATE-IPv4-PCN-request: PCN request object, when
IPv4 addresses are used: IPv4 addresses are used:
Class = 1 (SESSION) Class = (to be replaced by IANA) (PCN)
C-Type = RSVP-AGGREGATE-IPv4-PCN-SM (to be replaced by IANA) C-Type = RSVP-AGGREGATE-IPv4-PCN-request (to be replaced by IANA)
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 PCN-ingress-node Address (4 bytes) | | IPv4 PCN-ingress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 PCN-egress-node Address (4 bytes) | | IPv4 PCN-egress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of not marked PCN-traffic (NM-rate) | | IPv4 Decision Point Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of PCN-marked PCN-traffic (PM-rate) | |R| Reserved |
+-------------+-------------+-------------+-------------| +-------------+-------------+-------------+-------------|
o) RSVP-AGGREGATE-IPv6-PCN-SM: Single Marking (SM) PCN object, when o) RSVP-AGGREGATE-IPv6-PCN-request: PCN object, when
IPv6 addresses are used: IPv6 addresses are used:
Class = 1 (SESSION) Class = (to be replaced by IANA) (PCN)
C-Type = RSVP-AGGREGATE-IPv6-PCN-SM (to be replaced by IANA) C-Type = RSVP-AGGREGATE-IPv6-PCN-request (to be replaced by IANA)
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IPv6 PCN-ingress-node Address (16 bytes) + + IPv6 PCN-ingress-node Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IPv6 PCN-egress-node Address (16 bytes) + + IPv6 PCN-egress-node Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of not marked PCN-traffic (NM-rate) | | |
+ +
| |
+ Decision Point Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of PCN-marked PCN-traffic (PM-rate) | |R| Reserved |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o) RSVP-AGGREGATE-IPv4-PCN-CL: Controlled (CL) PCN object, IPv4 o) RSVP-AGGREGATE-IPv4-PCN-response: PCN object, IPv4
addresses are used: addresses are used:
Class = 1 (SESSION) Class = (to be replaced by IANA) (PCN)
C-Type = RSVP-AGGREGATE-IPv4-PCN-CL (To be replaced by IANA) C-Type = RSVP-AGGREGATE-IPv4-PCN-response (To be replaced by IANA)
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 PCN-ingress-node Address (4 bytes) | | IPv4 PCN-ingress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 PCN-egress-node Address (4 bytes) | | IPv4 PCN-egress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of not marked PCN-traffic (NM-rate) | | IPv4 Decision Point Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| rate of threshold-marked PCN-traffic (ThM-rate) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of excess-traffic-marked PCN-traffic (ETM-rate) | | PCN-sent-rate |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o) RSVP-AGGREGATE-IPv6-PCN-CL: Controlled (CL) PCN object, IPv6 o) RSVP-AGGREGATE-IPv6-PCN-response: PCN object, IPv6
addresses are used: addresses are used:
Class = 1 (SESSION) Class = (to be replaced by IANA) (PCN)
C-Type = RSVP-AGGREGATE-IPv6-PCN-CL (to be replaced by IANA) C-Type = RSVP-AGGREGATE-IPv6-PCN-response (to be replaced by IANA)
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IPv6 PCN-ingress-node Address (16 bytes) + + IPv6 PCN-ingress-node Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IPv6 PCN-egress-node Address (16 bytes) + + IPv6 PCN-egress-node Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of not marked PCN-traffic (NM-rate) | | |
+-------------+-------------+-------------+-------------+ + +
| rate of threshold-marked PCN-traffic (ThM-rate) | | |
+ Decision Point Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of excess-traffic-marked PCN-traffic (ETM-rate) | | PCN-sent-rate |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The fields carried by the PCN object are specified in The fields carried by the PCN object are specified in
[RFC6663], [RFC6661] and [RFC6662]: [RFC6663], [RFC6661] and [RFC6662]:
o the IPv4 or IPv6 address of the PCN-ingress-node and the IPv4 o the IPv4 or IPv6 address of the PCN-ingress-node (Aggregator) and
or IPv6 address of the PCN-egress-node; together they specify the the IPv4 or IPv6 address of the PCN-egress-node (Deaggregator);
ingress-egress-aggregate to which the report refers. According to together they specify the ingress-egress-aggregate to which the
[RFC6663] the report should carry the identifier of the PCN- report refers. According to [RFC6663] the report should carry the
ingress-node and the identifier of the PCN-egress-node (typically identifier of the PCN-ingress-node (Aggregator) and the
identifier of the PCN-egress-node (Deaggregator) (typically
their IP addresses); their IP addresses);
o rate of not-marked PCN-traffic (NM-rate) in octets/second; its o Decision Point address specify the IPv4 or IPv6 address of the
format is a 32-bit IEEE floating point number; Decision Point. In this document this field MUST contain the IP
address of the Deaggregator.
o rate of PCN-marked traffic (PM-rate) in octets/second; its format
is a 32-bit IEEE floating point number;
o rate of threshold-marked PCN traffic (ThM-rate) in
octets/second; its format is a 32-bit IEEE floating point number;
o rate of excess-traffic-marked traffic (ETM-rate) in
octets/second; its format is a 32-bit IEEE floating point number;
o) RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs: Controlled (CL) PCN CL Flow IDs
object, IPv4 addresses are used:
Class = 1 (SESSION)
C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs (to be replaced by IANA)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+ +
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o) Length (1 byte): the length of the
RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs object in units of 16 bytes.
This field is used to specify the number of IPv4 flow IDs
carried by this object. Each flow ID is represented by the
combination of each subsequent 5 tuple:
Source address, Destination address, Source Port,
Destination Port and Protocol number.
If Length is 0 then the RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs is
empty.
o) Source address (4 bytes): The IPv4 source address.
o) Destination address (4 bytes): The IPv4 destination address.
o) Protocol (1 byte): The IP protocol number. It refers to the
true upper layer protocol carried by the packets.
o) Source Port (2 bytes): contains the source port number.
o) Destination Port (2 bytes): contains the destination port
number.
o) RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs: Controlled (CL) PCN CL Flow IDs
object, IPv6 addresses are used:
Class = 1 (SESSION)
C-Type = RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs (To be replaced by IANA)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+ +
| |
| Source Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o) Length (1 byte): the length of the
RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs object in units of 40 bytes.
This field is used to specify the number of flow IDs carried by
this object. Each flow ID is represented by the combination of
each subsequent 5 tuple fields:
Source address, Destination address, Source Port,
Destination Port and Protocol number.
If Length is 0 then the RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs object
is empty.
o) Source address (16 bytes): The IPv6 source address.
o) Destination address (16 bytes): The IPv6 destination address.
o) Protocol (1 byte): The IP protocol number. It refers to the o "R": 1 bit flag that when set to ON, signifies, according to
true upper layer protocol carried by the packets. [RFC6661] and [RFC6662], that the PCN-ingress-node (Aggregator)
MUST provide an estimate of the rate (PCN-sent-rate) at which the
PCN-ingress-node (Aggregator) is receiving PCN-traffic that is
destined for the given ingress-egress-aggregate.
o) Source Port (2 bytes): contains the source port number. O "Reserved": 31 bits that are currently not used by this
document and are reserved. These SHALL be set to 0 and SHALL be
ignored on reception.
o) Destination Port (2 bytes): contains the destination port o PCN-sent-rate: the PCN-sent-rate for the given
number. ingress-egress-aggregate. It is expressed in octets/second; its
format is a 32-bit IEEE floating point number; The PCN-sent-rate
is specified in [RFC6661] and [RFC6662] and it represents the
estimate of the rate at which the PCN-ingress-node (Aggregator)
is receiving PCN-traffic that is destined for the given
ingress-egress-aggregate.
5. Security Considerations 5. Security Considerations
The same security considerations specified in [RFC2205], [RFC4230], The same security considerations specified in [RFC2205], [RFC4230],
[RFC4860], [RFC5559] and [RFC6411]. [RFC4860], [RFC5559] and [RFC6411].
6. IANA Considerations 6. IANA Considerations
This document makes the following requests to the IANA. This document makes the following requests to the IANA.
IANA needs to modify the RSVP parameters registry, 'Class Names, IANA needs to modify the RSVP parameters registry, 'Class Names,
Class Numbers, and Class Types' subregistry, and assigned 6 new C- Class Numbers, and Class Types' subregistry, and add a new
Types under the existing SESSION Class (Class number 1), as described Class Number as well as assign 4 new C-Types under this new Class
Below, see Section 4.1: Number, as described below, see Section 4.1:
Class Class
Number Class Name Reference Number Class Name Reference
------ ----------------------- --------- ------ ----------------------- ---------
(defined
1 SESSION [RFC2205] by IANA) PCN this document
Class Types or C-Types: Class Types or C-Types:
(defined by IANA) RSVP-AGGREGATE-IPv4-PCN-request this document
19? RSVP-AGGREGATE-IPv4-PCN-SM this document (defined by IANA) RSVP-AGGREGATE-IPv6-PCN-request this document
20? RSVP-AGGREGATE-IPv6-PCN-SM this document (defined by IANA) RSVP-AGGREGATE-IPv4-PCN-response this document
21? RSVP-AGGREGATE-IPv4-PCN-CL this document (defined by IANA) RSVP-AGGREGATE-IPv6-PCN-response this document
22? RSVP-AGGREGATE-IPv6-PCN-CL this document
23? RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs this document
24? RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs this document
7. Acknowledgments 7. Acknowledgments
We would like to thank the authors of [draft-lefaucheur-rsvp-ecn- We would like to thank the authors of [draft-lefaucheur-rsvp-ecn-
01.txt], since some ideas used in this document are based on the work 01.txt], since some ideas used in this document are based on the work
initiated in [draft-lefaucheur-rsvp-ecn-01.txt]. Moreover, we would initiated in [draft-lefaucheur-rsvp-ecn-01.txt]. Moreover, we would
like to thank Bob Briscoe, David Black, Ken Carlberg, Tom Taylor, like to thank Bob Briscoe, David Black, Ken Carlberg, Tom Taylor,
Philip Eardley, Michael Menth, Toby Moncaster, Francois Le Faucheur, Philip Eardley, Michael Menth, Toby Moncaster, James Polk and
James Polk and Lixia Zhang for the provided comments. Lixia Zhang for the provided comments. In particular, we would like
to thank Francois Le Faucheur for contributing in addition to
comments also a significant amount of text.
8. Normative References 8. Normative References
[RFC6661] T. Taylor, A, Charny, F. Huang, [RFC6661] T. Taylor, A, Charny, F. Huang,
G. Karagiannis, M. Menth, "PCN Boundary Node Behaviour for the G. Karagiannis, M. Menth, "PCN Boundary Node Behaviour for the
Controlled Load (CL) Mode of Operation", July Controlled Load (CL) Mode of Operation", July
2012. 2012.
[RFC6662] A. Charny, J. Zhang, [RFC6662] A. Charny, J. Zhang,
G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node Behaviour G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node Behaviour
skipping to change at page 27, line 47 skipping to change at page 25, line 5
Protocol (RSVP) Extension for the Reduction of Protocol (RSVP) Extension for the Reduction of
Bandwidth of a Reservation Flow", RFC 4495, May 2006. Bandwidth of a Reservation Flow", RFC 4495, May 2006.
[RFC4860] F. Le Faucheur, B. Davie, P. Bose, C. Christou, M. [RFC4860] F. Le Faucheur, B. Davie, P. Bose, C. Christou, M.
Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP)
Reservations", RFC4860, May 2007. Reservations", RFC4860, May 2007.
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes",
RFC 5670, November 2009. RFC 5670, November 2009.
[RFC6660] Moncaster, T., Briscoe, B., and M. Menth, "Baseline [RFC6660] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information", RFC 6660, Encoding and Transport of Pre-Congestion Information", RFC 6660,
July 2012. July 2012.
9. Informative References 9. Informative References
[draft-lefaucheur-rsvp-ecn-01.txt] Le Faucheur, F., Charny, A., [draft-lefaucheur-rsvp-ecn-01.txt] Le Faucheur, F., Charny, A.,
Briscoe, B., Eardley, P., Chan, K., and J. Babiarz, "RSVP Extensions Briscoe, B., Eardley, P., Chan, K., and J. Babiarz, "RSVP Extensions
for Admission Control over Diffserv using Pre-congestion for Admission Control over Diffserv using Pre-congestion
Notification (PCN) (Work in progress)", June 2006. Notification (PCN) (Work in progress)", June 2006.
skipping to change at page 28, line 47 skipping to change at page 25, line 58
[SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested [SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested
Virtual Private Network", Work in Progress, July 2007. Virtual Private Network", Work in Progress, July 2007.
[RFC2753] Yavatkar, R., D. Pendarakis and R. Guerin, "A Framework for [RFC2753] Yavatkar, R., D. Pendarakis and R. Guerin, "A Framework for
Policy-based Admission Control", January 2000. Policy-based Admission Control", January 2000.
10. Appendix A: Example Signaling Flow 10. Appendix A: Example Signaling Flow
This appendix is based on the appendix provided in [RFC4860]. In This appendix is based on the appendix provided in [RFC4860]. In
particular, it provides an example signaling flow of the particular, it provides an example signaling flow of the
specification detailed in Section 3 and 4. This signaling flow specification detailed in Section 3 and 4.
assumes an environment where E2E reservations are aggregated over
generic aggregate RSVP reservations and applied over a PCN domain. In This signaling flow assumes an environment where E2E reservations are
particular the Aggregator (PCN-ingress-node) and Deaggregator (PCN- aggregated over generic aggregate RSVP reservations and applied over
egress-node) are located at the boundaries of the PCN domain. The a PCN domain. In particular the Aggregator (PCN-ingress-node) and
PCN-interior-nodes are located within the PCN-domain, between the Deaggregator (PCN-egress-node) are located at the boundaries of the
PCN-boundary nodes, but are not shown in this Figure. It illustrates PCN domain. The PCN-interior-nodes are located within the PCN-domain,
a possible RSVP message flow that could take place in the successful between the PCN-boundary nodes, but are not shown in this Figure. It
establishment of a unicast E2E reservation that is the first between illustrates a possible RSVP message flow that could take place in the
a given pair of Aggregator/Deaggregator. successful establishment of a unicast E2E reservation that is the
first between a given pair of Aggregator/Deaggregator.
Aggregator (PCN-ingress-node) Deaggregator (PCN-egress-node) Aggregator (PCN-ingress-node) Deaggregator (PCN-egress-node)
E2E Path E2E Path
-----------> ----------->
(1) (1)
E2E Path E2E Path
-------------------------------> ------------------------------->
(2) (2)
E2E PathErr(New-agg-needed,SOI=GAx) E2E PathErr(New-agg-needed,SOI=GApcn)
<----------------------------------
E2E PathErr(New-agg-needed,SOI=GAy)
<---------------------------------- <----------------------------------
(3) (3)
AggPath(Session=GAx) AggPath(Session=GApcn)
------------------------------->
AggPath(Session=GAy)
-------------------------------> ------------------------------->
(4) (4)
E2E Path E2E Path
-----------> ----------->
(5) (5)
AggResv (Session=GAx) (PCN object) AggResv (Session=GApcn) (PCN object)
<-------------------------------
AggResv (Session=GAy) (PCN object)
<------------------------------- <-------------------------------
(6) (6)
AggResvConfirm (Session=GAx) AggResvConfirm (Session=GApcn)
------------------------------>
AggResvConfirm (Session=GAy)
------------------------------> ------------------------------>
(7) (7)
E2E Resv E2E Resv
<--------- <---------
(8) (8)
E2E Resv (SOI=GAx) E2E Resv (SOI=GApcn)
<----------------------------- <-----------------------------
(9) (9)
E2E Resv E2E Resv
<----------- <-----------
(1) The Aggregator (PCN-ingress-node) maps the e2e RSVP reservation (1) The Aggregator forwards E2E Path into the aggregation region
session associated with the e2e Path message onto an PCN ingress- after modifying its IP protocol number to RSVP-E2E-IGNORE
egress-aggregate. The Aggregator forwards e2e Path into the
aggregation region after modifying its IP protocol number to
RSVP-E2E-IGNORE. Note that in this case it is considered that the
PCN-admission-state is "admit", see Section 3.1. Otherwise, the
e2e Path will not be forwarded into the aggregation region and
the steps associated with the PCN-admission-state is "block"
situation specified in Section 3.1 will be followed.
(2) Let's assume no Aggregate Path exists. To be able to accurately (2) Let's assume no Aggregate Path exists. To be able to accurately
update the ADSPEC of the e2e Path, the Deaggregator needs the update the ADSPEC of the E2E Path, the Deaggregator needs the
ADSPEC of Aggregate Path. In this example, the Deaggregator ADSPEC of Aggregate Path. In this example, the Deaggregator
elects to instruct the Aggregator to set up Aggregate Path states elects to instruct the Aggregator to set up an Aggregate Path
for the two supported PHB-IDs. To do that, the Deaggregator state for the PCN PHB-ID. To do that, the Deaggregator
sends two e2e PathErr messages with a New-Agg-Needed PathErr sends an E2E PathErr message with a New-Agg-Needed PathErr
code. Both PathErr messages also contain a SESSION-OF-INTEREST code.
(SOI) object. In the first e2e PathErr, the SOI contains a
GENERIC-AGGREGATE SESSION (GAx) whose PHB-ID is set to x. In the The PathErr message also contains a SESSION-OF-INTEREST
second e2e PathErr, the SOI contains a GENERIC-AGGREGATE SESSION (SOI) object. The SOI contains a GENERIC-AGGREGATE SESSION
(GAy) whose PHB-ID is set to y. In both messages the GENERIC- (GApcn) whose PHB-ID is set to the PCN PHB-ID. The GENERIC-
AGGREGATE SESSION contains an interface-independent Deaggregator AGGREGATE SESSION contains an interface-independent Deaggregator
address inside the DestAddress and appropriate values inside the address inside the DestAddress and appropriate values inside the
vDstPort and Extended vDstPort fields. vDstPort and Extended vDstPort fields. In this document, the
Extended vDstPort SHOULD contain the IPv4 or IPv6 address of
the Aggregator.
(3) The Aggregator follows the request from the Deaggregator and (3) The Aggregator follows the request from the Deaggregator and
signals an Aggregate Path for both GENERIC-AGGREGATE Sessions signals an Aggregate Path for the GENERIC-AGGREGATE Session
(GAx and GAy). (GApcn).
(4) The Deaggregator takes into account the information contained in (4) The Deaggregator takes into account the information contained in
the ADSPEC from both Aggregate Paths and updates the e2e Path the ADSPEC from both Aggregate Paths and updates the E2E Path
ADSPEC accordingly. The Deaggregator also modifies the e2e Path ADSPEC accordingly. The PCN-egress-node MUST NOT perform the
IP protocol number to RSVP before forwarding it. RSVP-TTL vs IP TTL-check and MUST NOT update the ADspec Break
bit. This is because the whole PCN-domain is effectively handled
by E2E RSVP as a virtual link on which integrated service is
indeed supported (and admission control performed) so that the
Break bit MUST NOT be set, see also
[draft-lefaucheur-rsvp-ecn-01]. The Deaggregator also modifies
the E2E Path IP protocol number to RSVP before forwarding it.
(5) In this example, the Deaggregator elects to immediately proceed (5) In this example, the Deaggregator elects to immediately proceed
with establishment of generic aggregate reservations for both with establishment of the generic aggregate reservation. In
PHB-IDs. In effect, the Deaggregator can be seen as anticipating effect, the Deaggregator can be seen as anticipating
the actual demand of e2e reservations so that resources are the actual demand of E2E reservations so that the generic
available on the generic aggregate reservations when the e2e Resv aggregate reservation is in place when the E2E Resv
requests arrive, in order to speed up establishment of e2e request arrives, in order to speed up establishment of E2E
reservations. reservations. Here it is also assumed that the Deaggregator
At this step the Deaggregator maps the new generated RSVP generic includes the optional Resv Confirm Request in the Aggregate
aggregated reservations onto one ingress-egress-aggregate Resv message.
maintained by the Deaggregator (PCN-egress-node), see Section
3.3. Moreover, the Deaggregator, depending on the used
PCN edge behaviour and IP version, it includes one of the
following PCN objects specified in Section 4.1:
RSVP-AGGREGATE-IPv4-PCN-SM, RSVP-AGGREGATE-IPv6-PCN-SM,
RSVP-AGGREGATE-IPv4-PCN-CL or RSVP-AGGREGATE-IPv6-PCN-CL.
Here it is also Assumed that the Deaggregator includes the
optional Resv Confirm Request in these Aggregate Resv.
(6) The Aggregator merely complies with the received ResvConfirm (6) The Aggregator merely complies with the received ResvConfirm
Request and returns the corresponding Aggregate ResvConfirm. Request and returns the corresponding Aggregate ResvConfirm.
Moreover, the PCN-ingress-node functionality uses the PCN object
to map the RSVP generic aggregated reservation state onto the
maintained PCN ingress-egress-aggregate state. Moreover, the
Aggregator performs the steps specified in Section 3.11.
(7) The Deaggregator has explicit confirmation that both Aggregate (7) The Deaggregator has explicit confirmation that the generic
Resvs are established. aggregate reservation is established.
(8) On receipt of the e2e Resv, the Deaggregator applies the mapping (8) On receipt of the E2E Resv, the Deaggregator applies the mapping
policy defined by the network administrator to map the e2e Resv policy defined by the network administrator to map the E2E Resv
onto a generic aggregate reservation. Let's assume that this onto a generic aggregate reservation. Let's assume that this
policy is such that the e2e reservation is to be mapped onto the policy is such that the E2E reservation is to be mapped onto the
generic aggregate reservation with PHB-ID=x. The Deaggregator generic aggregate reservation with the PCN PHB-ID=x. The
knows that a generic aggregate reservation (GAx) is in place for Deaggregator knows that a generic aggregate reservation (GApcn)
the corresponding PHB-ID since (7). The Deaggregator performs is in place for the corresponding PHB-ID since (7). At this step
admission control of the e2e Resv onto the generic aggregate the Deaggregator maps the generic aggregated reservation onto one
reservation for PHB-ID=x (GAx). Assuming that the generic ingress-egress-aggregate maintained by the Deaggregator (as a
aggregate reservation for PHB-ID=x (GAx) had been established PCN-egress-node), see Section 3.7. The Deaggregator performs
with sufficient bandwidth to support the e2e Resv, the admission control of the E2E Resv onto the generic Aggregate
Deaggregator adjusts its counter, tracking the unused bandwidth reservation for the PCN PHB-ID (GApcn). The Deaggregator takes
on the generic aggregate reservation. Then it forwards the e2e also into account the PCN admission control procedure as
Resv to the Aggregator including a SESSION-OF-INTEREST object as specified in [RFC6661] and [RFC6662], see Section 3.7.
conveying the selected mapping onto GAx (and hence onto
PHB-ID=x).
(9) The Aggregator records the mapping of the e2e Resv onto GAx (and If one or both the admission control procedures (PCN based
onto PHB-ID=x). The Aggregator removes the SOI object and admission control procedure and admission control procedure
forwards the e2e Resv towards the sender. specified in [RFC4860]) are not successful, then the E2E Resv is
not admitted onto the associated RSVP generic aggregate
reservation for the PCN PHB-ID (GApcn). Otherwise, assuming that
the generic aggregate reservation for the PCN (GApcn) had been
established with sufficient bandwidth to support the E2E Resv,
the Deaggregator adjusts its counter, tracking the unused
bandwidth on the generic aggregate reservation. Then it forwards
the E2E Resv to the Aggregator including a SESSION-OF-INTEREST
object conveying the selected mapping onto GApcn (and hence onto
the PCN PHB-ID).
(9) The Aggregator records the mapping of the E2E Resv onto GApcn
(and onto the PCN PHB-ID). The Aggregator removes the SOI object
and forwards the E2E Resv towards the sender.
11. Authors' Address 11. Authors' Address
Georgios Karagiannis Georgios Karagiannis
University of Twente University of Twente
P.O. Box 217 P.O. Box 217
7500 AE Enschede, 7500 AE Enschede,
The Netherlands The Netherlands
EMail: g.karagiannis@utwente.nl EMail: g.karagiannis@utwente.nl
 End of changes. 159 change blocks. 
761 lines changed or deleted 632 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/