draft-ietf-tsvwg-rsvp-pcn-11.txt   rfc7417.txt 
Internet Engineering Task Force Georgios Karagiannis
Internet-Draft Huawei Technologies
Intended status: Experimental Anurag Bhargava
Expires: April 6, 2015 Cisco Systems, Inc.
October 6, 2014
Generic Aggregation of Resource ReSerVation Protocol (RSVP) Internet Engineering Task Force (IETF) G. Karagiannis
for IPv4 And IPv6 Reservations over PCN domains Request for Comments: 7417 Huawei Technologies
draft-ietf-tsvwg-rsvp-pcn-11 Category: Experimental A. Bhargava
ISSN: 2070-1721 Cisco Systems, Inc.
December 2014
Abstract Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations
over Pre-Congestion Notification (PCN) Domains
This document specifies extensions to Generic Aggregated RSVP Abstract
RFC 4860 for support of the PCN Controlled Load (CL) and Single
Marking (SM) edge behaviors over a Diffserv cloud using Pre-
Congestion Notification.
Status of this Memo This document specifies extensions to Generic Aggregate RSVP (RFC
4860) for support of the Pre-Congestion Notification (PCN) Controlled
Load (CL) and Single Marking (SM) edge behaviors over a Diffserv
cloud using PCN.
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for examination, experimental implementation, and
working documents as Internet-Drafts. The list of current Internet- evaluation.
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on April 6, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7417.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
described in the Simplified BSD License. described in the Simplified BSD License.
Requirements Language Table of Contents
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1. Introduction ....................................................4
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1.1. Objective ..................................................4
document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Overview and Motivation ....................................5
1.3. Requirements Language and Terminology ......................8
1.4. Organization of This Document .............................12
2. Overview of RSVP Extensions and Operations .....................12
2.1. Overview of RSVP Aggregation Procedures in PCN-Domains ....12
2.2. PCN-Marking, Encoding, and Transport of
Pre-congestion Information ................................14
2.3. Traffic Classification within the Aggregation Region ......14
2.4. Deaggregator (PCN-Egress-Node) Determination ..............15
2.5. Mapping E2E Reservations onto Aggregate Reservations ......15
2.6. Size of Aggregate Reservations ............................16
2.7. E2E Path ADSPEC Update ....................................16
2.8. Intra-domain Routes .......................................16
2.9. Inter-domain Routes .......................................16
2.10. Reservations for Multicast Sessions ......................16
2.11. Multi-level Aggregation ..................................16
2.12. Reliability Issues .......................................17
3. Elements of Procedures .........................................17
3.1. Receipt of E2E Path Message by PCN-Ingress-Node
(Aggregating Router) ......................................17
3.2. Handling of E2E Path Message by Interior Routers ..........17
3.3. Receipt of E2E Path Message by PCN-Egress-Node
(Deaggregating Router) ....................................18
3.4. Initiation of New Aggregate Path Message by
PCN-Ingress-Node (Aggregating Router) .....................18
3.5. Handling of Aggregate Path Message by Interior Routers ....18
3.6. Handling of Aggregate Path Message by
Deaggregating Router ......................................18
3.7. Handling of E2E Resv Message by Deaggregating Router ......19
3.8. Handling of E2E Resv Message by Interior Routers ..........19
3.9. Initiation of New Aggregate Resv Message by
Deaggregating Router ......................................20
3.10. Handling of Aggregate Resv Message by Interior Routers ...20
3.11. Handling of E2E Resv Message by Aggregating Router .......21
3.12. Handling of Aggregate Resv Message by
Aggregating Router .......................................21
3.13. Removal of E2E Reservation ...............................21
3.14. Removal of Aggregate Reservation .........................22
3.15. Handling of Data on Reserved E2E Flow by
Aggregating Router .......................................22
3.16. Procedures for Multicast Sessions ........................22
3.17. Misconfiguration of PCN-Node .............................22
3.18. PCN-Based Flow Termination ...............................22
4. Protocol Elements ..............................................23
4.1. PCN Objects ...............................................24
5. Security Considerations ........................................28
6. IANA Considerations ............................................29
7. References .....................................................29
7.1. Normative References ......................................29
7.2. Informative References ....................................30
Appendix A. Example Signaling Flow ................................33
Acknowledgments ...................................................35
Authors' Addresses ................................................36
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Overview and Motivation . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Organization of This Document . . . . . . . . . . . . . . . . 11
2. Overview of RSVP extensions and Operations . . . . . . . . . . . 11
2.1. Overview of RSVP Aggregation Procedures in PCN domains . . . . . 11
2.2. PCN Marking and encoding and transport of pre-congestion
Information . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Traffic Classification Within The Aggregation Region . . . . . . 13
2.4. Deaggregator (PCN-egress-node) Determination . . . . . . . . . . 13
2.5. Mapping E2E Reservations Onto Aggregate Reservations . . . . . . 13
2.6 Size of Aggregate Reservations . . . . . . . . . . . . . . . . . 14
2.7. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . . . 14
2.8. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . . .14
2.9. Inter-domain Routes . . . . . . . . . . . . . . . . . . . . . . 15
2.10. Reservations for Multicast Sessions . . . . . . . . . . . . . . 15
2.11. Multi-level Aggregation . . . . . . . . . . . . . . . . . . . . 15
2.12. Reliability Issues . . . . . . . . . . . . . . . . . . . . . . 15
3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Receipt of E2E Path Message by PCN-ingress-node
(aggregating router) . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Handling Of E2E Path Message by Interior Routers . . . . . . . 16
3.3. Receipt of E2E Path Message by PCN-egress-node
(deaggregating router) . . . . . . . . . . . . . . . . . . . . . 16
3.4. Initiation of new Aggregate Path Message By PCN-ingress-node
(Aggregating Router) . . . . . . . . . . . . . . . . . . . . . 16
3.5. Handling Of new Aggregate Path Message by Interior Routers . . 16
3.6 Handling Of Aggregate Path Message by Deaggregating Router . . 16
3.7. Handling of E2E Resv Message by Deaggregating Router . . . . . 17
3.8. Handling Of E2E Resv Message by Interior Routers . . . . . . . 17
3.9. Initiation of New Aggregate Resv Message By Deaggregating Router 17
3.10. Handling of Aggregate Resv Message by Interior Routers . . . 18
3.11. Handling of E2E Resv Message by Aggregating Router . . . . . . 18
3.12. Handling of Aggregated Resv Message by Aggregating Router . . 18
3.13. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 19
3.14. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 19
3.15. Handling of Data On Reserved E2E Flow by Aggregating Router . 19
3.16. Procedures for Multicast Sessions . . . . . . . . . . . . . . 19
3.17. Misconfiguration of PCN node . . . . . . . . . . . . . . . . 19
3.18. PCN based Flow Termination . . . . . . . . . . . . . . . . . 19
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Normative References . . . . . . . . . . . . . . . . . . . . . . 24
9. Informative References . . . . . . . . . . . . . . . . . . . . . 25
10. Appendix A: Example Signaling Flow . . . . . . . . . . . . . . . 26
11. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 29
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
of the existing flows. To support these two features, the overall of the existing flows. To support these two features, the overall
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
packets are appropriately marked when certain configured rates are PCN-packets are appropriately marked when certain configured rates
exceeded. These configured rates are below the rate of the link, are 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
another 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 PCN-domain to carry reports from a
domain to carry reports from a PCN-ingress-node to a PCN Decision PCN-ingress-node to a PCN Decision Point, considering that the PCN
point, considering that the PCN Decision Point and PCN-egress-node Decision Point and PCN-egress-node are collocated.
are collocated.
If the PCN Decision Point is not collocated with the PCN-egress-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 scope for this document. Moreover, as mentioned above, this
architecture conforms with PBAC (Policy-Based Admission Control), architecture conforms with Policy-Based Admission Control (PBAC),
when the Decision Point is located in a another node then the PCN- where the Decision Point is located in a node other than the
ingress-node [RFC2753]. PCN-ingress-node [RFC2753].
Several signaling protocols can be used to carry information between Several signaling protocols can be used to carry information between
PCN-boundary-nodes (PCN-ingress-node and PCN-egress-node). However, PCN-boundary-nodes (PCN-ingress-node and PCN-egress-node). However,
since (1) both PCN-egress-node and PCN-ingress-nodes are located on since (1) both the PCN-egress-node and PCN-ingress-node are located
the data path and (2) the admission control procedure needs to be on the data path and (2) the admission control procedure needs to be
done at PCN-egress-node, a signaling protocol that follows the same done at the PCN-egress-node, a signaling protocol that follows the
path as the data path, like RSVP (Resource Reservation Protocol), is same path as the data path, like RSVP, is more suited for this
more suited for this purpose. In particular, this document specifies purpose. In particular, this document specifies extensions to
extensions to Generic Aggregated RSVP [RFC4860] for support of the Generic Aggregate RSVP [RFC4860] for support of the PCN Controlled
PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over Load (CL) and Single Marking (SM) edge behaviors over a Diffserv
a Diffserv cloud using Pre-Congestion Notification. cloud using Pre-Congestion Notification.
This draft is intended to be published as Experimental in order to: This document is published as an Experimental document in order to:
o) validate industry interest by allowing implementation and o validate industry interest by allowing implementation and
deployment deployment
o) gather operational experience, in particular around dynamic o gather operational experience, particularly related to dynamic
interactions of RSVP signaling and PCN notification and interactions of RSVP signaling and PCN, and corresponding levels
corresponding levels of performance. of performance
Support for the techniques specified in this document involves RSVP Support for the techniques specified in this document involves RSVP
functionality in boundary nodes of a PCN domain whose interior nodes functionality in boundary nodes of a PCN-domain whose interior nodes
forward RSVP traffic without performing RSVP functionality. forward RSVP traffic without performing RSVP functionality.
1.2 Overview and Motivation 1.2. Overview and Motivation
Two main Quality of Service (QoS) architectures have been specified Two main QoS architectures have been specified by the IETF: the
by the IETF. These are the Integrated Services (Intserv) [RFC1633] Integrated Services (Intserv) [RFC1633] architecture and the
architecture and the Differentiated Services (DiffServ) architecture 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 QoS to
Service (QoS) to applications over heterogeneous networks. One of the applications over heterogeneous networks. One of the QoS signaling
QoS signaling protocols used by the Intserv architecture is the protocols used by the Intserv architecture is RSVP [RFC2205], which
Resource reServation Protocol (RSVP) [RFC2205], which can be used by can be used by applications to request per-flow resources from the
applications to request per-flow resources from the network. These network. These RSVP requests can be admitted or rejected by the
RSVP requests can be admitted or rejected by the network. network. Applications can express their quantifiable resource
Applications can express their quantifiable resource requirements requirements using Intserv parameters as defined in [RFC2211] and
using Intserv parameters as defined in [RFC2211] and [RFC2212]. The [RFC2212]. The Controlled Load (CL) service [RFC2211] is a form of
Controlled Load (CL) service [RFC2211] is a quality of service (QoS) QoS that closely approximates the QoS that the same flow would
closely approximating the QoS that the same flow would receive from a receive from a lightly loaded network element. The CL service is
lightly loaded network element. The CL service is useful for useful for inelastic flows such as those used for real-time media.
inelastic flows such as those used for real-time media.
The DiffServ architecture can support the differentiated treatment of The Diffserv architecture can support the differentiated treatment of
packets in very large scale environments. While Intserv and RSVP packets in very large-scale environments. While Intserv and RSVP
classify packets per-flow, Diffserv networks classify packets into classify packets per flow, Diffserv networks classify packets into
one of a small number of aggregated flows or "classes", based on the one of a small number of aggregated flows or "classes", based on the
Diffserv codepoint (DSCP) in the packet IP header. At each Diffserv Diffserv Codepoint (DSCP) in the packet IP header. At each Diffserv
router, packets are subjected to a "per-hop behavior" (PHB), which is router, packets are subjected to a "Per Hop Behavior" (PHB), which is
invoked by the DSCP. The primary benefit of Diffserv is its invoked by the DSCP. The primary benefit of Diffserv is its
scalability, since the need for per-flow state and per-flow scalability, since the need for per-flow state and per-flow
processing, is eliminated. processing is eliminated.
However, DiffServ does not include any mechanism for communication However, Diffserv does not include any mechanism for communication
between applications and the network. Several solutions have been between applications and the network. Several solutions have been
specified to solve this issue. One of these solutions is Intserv over specified to solve this issue. One of these solutions is Intserv
Diffserv [RFC2998] including resource-based admission control (RBAC), over Diffserv [RFC2998], including Resource-Based Admission Control
PBAC, assistance in traffic identification/classification, and (RBAC), PBAC, assistance in traffic identification/classification,
traffic conditioning. Intserv over Diffserv can operate over a and traffic conditioning. Intserv over Diffserv can operate over a
statically provisioned or a RSVP aware Diffserv region. When it is statically provisioned or an RSVP-aware Diffserv region. When it is
RSVP aware, several mechanisms may be used to support dynamic RSVP aware, several mechanisms may be used to support dynamic
provisioning and topology-aware admission control, including provisioning and topology-aware admission control, including
aggregate RSVP reservations, per-flow RSVP, or a bandwidth broker. aggregate RSVP reservations, per-flow RSVP, or a bandwidth broker.
[RFC3175] specifies aggregation of Resource ReSerVation Protocol [RFC3175] specifies aggregation of RSVP end-to-end reservations over
(RSVP) end-to-end reservations over aggregate RSVP reservations. In aggregate RSVP reservations. In [RFC3175], the RSVP generic
[RFC3175] the RSVP generic aggregated reservation is characterized by aggregate reservation is characterized by an RSVP SESSION object
a RSVP SESSION object using the 3-tuple <source IP address, using the 3-tuple <source IP address, destination IP address,
destination IP address, Diffserv Code Point>. Diffserv Codepoint>.
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 [RFC4923] and
[RFC4860]. For example, multiple generic aggregate reservations [RFC4860]. For example, multiple generic aggregate reservations can
can be applied in the situation that multiple E2E reservations using be applied in situations where multiple end-to-end (E2E) reservations
different preemption priorities need to be aggregated through a PCN- using different preemption priorities need to be aggregated through a
domain using the same PHB. By using multiple aggregate reservations PCN-domain using the same PHB. Using multiple aggregate reservations
for the same PHB, it allows enforcement of the different preemption for the same PHB allows
priorities within the aggregation region. This allows more efficient
management of the Diffserv resources, and in periods of resource o enforcement of the different preemption priorities within the
shortage, this allows sustainment of a larger number of E2E aggregation region
reservations with higher preemption priorities. In particular,
[SIG-NESTED] discusses in detail how end-to-end RSVP reservations can o more efficient management of Diffserv resources
be established in a nested VPN environment through RSVP aggregation.
o sustainment of a larger number of E2E reservations with higher
preemption priorities during periods of resource shortage
In particular, [RFC4923] discusses in detail how end-to-end RSVP
reservations can be established in a nested VPN environment through
RSVP aggregation.
[RFC4860] provides generic aggregate reservations by extending [RFC4860] provides generic aggregate reservations by extending
[RFC3175] to support multiple aggregate reservations for the same [RFC3175] to support multiple aggregate reservations for the same
source IP address, destination IP address, and PHB (or set of PHBs). source IP address, destination IP address, and PHB (or set of PHBs).
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 an Extended Virtual Destination Port in
in the RSVP SESSION object. In addition to this, the RSVP SESSION 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 Codepoint (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 (1) requests from
a PCN-egress-node to a PCN-ingress-node and (2) reports from a a PCN-egress-node to a PCN-ingress-node and (2) reports from a
PCN-ingress-node to a PCN-egress-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,
that the signaling protocol functionality supported by the PCN- the signaling protocol functionality supported by the PCN-ingress-
ingress-nodes and PCN-egress-nodes needs to maintain logical nodes and PCN-egress-nodes needs to maintain logical aggregate
aggregate constructs (i.e. ingress-egress-aggregate state) and be constructs (i.e., ingress-egress-aggregate state) and be able to map
able to map E2E reservations to these aggregate constructs. Moreover, E2E reservations to these aggregate constructs. Moreover, no actual
no actual reservation state is needed to be maintained inside the PCN reservation state is needed to be maintained inside the PCN-domain,
domain, i.e., the PCN-interior-nodes are not maintaining any i.e., the PCN-interior-nodes are not maintaining any reservation
reservation state. 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 aggregation procedures of RFC 4860 to fit the PCN
requirements with as little change as possible over the RFC 4860 requirements with as little change as possible over the
functionality functionality provided in RFC 4860.
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 the aggregate RSVP signaling procedures to carry PCN
information between the PCN-boundary-nodes (PCN-ingress-node and information between the PCN-boundary-nodes (PCN-ingress-node and
PCN-egress-node). PCN-egress-node).
Approach (2): Approach (2):
o) adapting the RFC 4860 aggregation procedures to fit the PCN o adapting the aggregation procedures of RFC 4860 to fit the PCN
requirements with more significant changes over RFC4860 (i.e. requirements with significant changes over RFC 4860 (i.e., the
the aspect of the procedures that have to do with maintaining aspect of the procedures that have to do with maintaining
aggregate states and to do with mapping the E2E reservations to aggregate states and mapping the E2E reservations to aggregate
aggregate constructs are kept, but the procedures that have to constructs are kept, but the procedures that are specific to
do with the aggregate RSVP signaling and aggregate reservation 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 piggybacking 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 operations of
operations have been thoroughly studied and implemented, it can be RFC 4860 have been thoroughly studied and implemented, it can be
considered that the RFC 4860 solution can better deal with the more considered that the solution from RFC 4860 can better deal with the
challenging situations (rerouting in the PCN domain, failure of an more challenging situations (rerouting in the PCN-domain, failure of
PCN-ingress-node, failure of an PCN-egress-node, rerouting towards a a PCN-ingress-node, failure of a 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
PCN information between the PCN-boundary-nodes (PCN-ingress-node and information between the PCN-boundary-nodes (PCN-ingress-node and
PCN-egress-node). PCN-egress-node).
In particular, this document specifies extensions to Generic As noted earlier, this document specifies extensions to Generic
Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) Aggregate 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 Aggregate RSVP
[RFC4860] for support of PCN edge behaviors as specified in [RFC4860] for support of PCN edge behaviors as specified in [RFC6661]
[RFC6661] and [RFC6662]. Moreover, this document specifies how RSVP and [RFC6662]. Moreover, this document specifies how RSVP
aggregation can be used to setup and maintain: (1) Ingress Egress aggregation can be used to set up and maintain (1) Ingress-Egress-
Aggregate (IEA) states at Ingress and Egress nodes and (2) generic Aggregate (IEA) states at Ingress and Egress nodes and (2) generic
aggregation of RSVP end-to-end RSVP reservations over PCN (Congestion aggregation of end-to-end RSVP reservations over PCN (Congestion and
and Pre-Congestion Notification) domains. Pre-Congestion Notification) domains.
To comply with this specification, PCN-nodes MUST be able to To comply with this specification, PCN-nodes MUST be able to support
support the functionality specified in [RFC5670], [RFC5559], the functionality specified in [RFC5670], [RFC5559], [RFC6660],
[RFC6660], [RFC6661], [RFC6662]. Furthermore, the PCN-boundary-nodes [RFC6661], and [RFC6662]. Furthermore, the PCN-boundary-nodes MUST
MUST support the RSVP generic aggregated reservation procedures support the RSVP generic aggregate reservation procedures specified
specified in [RFC4860] which are augmented with procedures specified in [RFC4860], which are augmented with procedures specified in this
in this document. document.
1.3. Terminology 1.3. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document uses terms defined in [RFC4860], [RFC3175], [RFC5559], This document uses terms defined in [RFC4860], [RFC3175], [RFC5559],
[RFC5670], [RFC6661], [RFC6662]. [RFC5670], [RFC6661], and [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
router at the ingress edge of the aggregation region The process in (or associated with) the router at the ingress edge
(with respect to the end-to-end RSVP reservation) of the aggregation region (with respect to the end-to-end RSVP
and behaving in accordance with [RFC4860]. In this reservation) and behaving in accordance with [RFC4860]. In this
document, it is also the PCN-ingress-node. It is document, it is also the PCN-ingress-node. It is important to
important to notice that in the context of this notice that in the context of this document the Aggregator must be
document the Aggregator must be able to determine able to determine the Deaggregator using the procedures specified
the Deaggregator using the procedures specified in in Section 4 of [RFC4860] and Section 1.4.2 of [RFC3175].
Section 4 of [RFC4860] and in Section 1.4.2 of
[RFC3175].
Congestion level estimate (CLE): Congestion Level Estimate (CLE)
The ratio of PCN-marked to total PCN-traffic The ratio of PCN-marked to total PCN-traffic (measured in octets)
(measured in octets) received for a given ingress- received for a given ingress-egress-aggregate during a given
egress-aggregate during a given measurement period. measurement period. The CLE is used to derive the PCN-admission-
The CLE is used to derive the PCN-admission-state state and is also used by the report suppression procedure if
and is also used by the report suppression procedure report suppression is activated.
if report suppression is activated.
Deaggregator This is the process in (or associated with) the Deaggregator
router at the egress edge of the aggregation region The process in (or associated with) the router at the egress edge
(with respect to the end-to-end RSVP reservation) of the aggregation region (with respect to the end-to-end RSVP
and behaving in accordance with [RFC4860]. In this reservation) and behaving in accordance with [RFC4860]. In this
document, it is also the PCN-egress-node and document, it is also the PCN-egress-node and Decision Point.
Decision Point.
E2E end to end E2E
End to end
E2E Reservation This is an RSVP reservation such that: E2E Microflow
A microflow where its associated packets are being forwarded on an
E2E path.
(i) corresponding RSVP Path messages are initiated E2E Reservation
upstream of the Aggregator and terminated An RSVP reservation such that:
downstream of the Deaggregator, and
(ii) corresponding RSVP Resv messages are initiated (1) corresponding RSVP Path messages are initiated upstream of the
downstream of the Deaggregator and terminated Aggregator and terminated downstream of the Deaggregator, and
upstream of the Aggregator, and
(iii) this RSVP reservation is aggregated over an (2) corresponding RSVP Resv messages are initiated downstream of
Ingress Egress Aggregate (IEA) between the the Deaggregator and terminated upstream of the Aggregator,
Aggregator and Deaggregator. and
An E2E RSVP reservation may be a per-flow
reservation, which in this document is only
maintained at the PCN-ingress-node and PCN-egress-
node. Alternatively, the E2E reservation may itself
be an aggregate reservation of various types (e.g.,
Aggregate IP reservation, Aggregate IPsec
reservation, see [RFC4860]). As per regular RSVP
operations, E2E RSVP reservations are
unidirectional.
E2E microflow a microflow where its associated packets are being (3) this RSVP reservation is aggregated over an Ingress-Egress-
forwarded on an E2E path. Aggregate (IEA) between the Aggregator and Deaggregator.
Extended vDstPort (Extended Virtual Destination Port) An E2E RSVP reservation may be a per-flow reservation, which in
this document is only maintained at the PCN-ingress-node and
PCN-egress-node. Alternatively, the E2E reservation may itself be
an aggregate reservation of various types (e.g., Aggregate IP
reservation, Aggregate IPsec reservation [RFC4860]). As per
regular RSVP operations, E2E RSVP reservations are unidirectional.
An identifier used in the SESSION that remains ETM-Rate
constant over the life of the generic aggregate The rate of excess-traffic-marked (ETM) PCN-traffic received at a
reservation. The length of this identifier is 32- PCN-egress-node for a given ingress-egress-aggregate in octets
bits when IPv4 addresses are used and 128 bits when per second.
IPv6 addresses are used.
A sender(or Aggregator) that wishes to narrow the
scope of a SESSION to the sender-receiver pair (or
Aggregator-Deaggregator pair) should place its IPv4
or IPv6 address here as a network unique
identifier. A sender (or Aggregator) that wishes to
use a common session with other senders (or
Aggregators) in order to use a shared reservation
across senders (or Aggregators) must set this field
to all zeros. In this document, the Extended
vDstPort should contain the IPv4 or IPv6 address of
the Aggregator.
ETM-rate Extended vDstPort (Extended Virtual Destination Port)
The rate of excess-traffic-marked PCN-traffic An identifier used in the SESSION that remains constant over the
received at a PCN-egress-node for a given ingress- life of the generic aggregate reservation. The length of this
egress-aggregate in octets per second. identifier is 32 bits when IPv4 addresses are used and 128 bits
when IPv6 addresses are used.
Ingress-egress-aggregate (IEA): A sender (or Aggregator) that wishes to narrow the scope of a
The collection of PCN-packets from all PCN-flows SESSION to the sender-receiver pair (or Aggregator-Deaggregator
that travel in one direction between a specific pair pair) should place its IPv4 or IPv6 address here as a network
of PCN-boundary-nodes. In this document one RSVP unique identifier. A sender (or Aggregator) that wishes to use a
generic aggregated reservation is mapped to only common session with other senders (or Aggregators) in order to use
one ingress-egress-aggregate, while one a shared reservation across senders (or Aggregators) must set this
ingress-egress-aggregate is mapped to either field to all zeros. In this document, the Extended vDstPort
one or to more than one RSVP generic aggregated should contain the IPv4 or IPv6 address of the Aggregator.
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 Ingress-Egress-Aggregate (IEA)
(from [RFC2474]) flow of packets which is identified by source The collection of PCN-packets from all PCN-flows that travel in
address, destination address, protocol id, and one direction between a specific pair of PCN-boundary-nodes. In
source port, destination port (where applicable). this document, one RSVP generic aggregate reservation is mapped to
only one ingress-egress-aggregate, while one ingress-egress-
aggregate is mapped to one or more RSVP generic aggregate
reservations. PCN-flows and their PCN-traffic that are mapped
into a specific RSVP generic aggregate reservation can also be
easily mapped into their corresponding ingress-egress-aggregate.
PCN-domain: a PCN-capable domain; a contiguous set of Microflow (from [RFC2474])
PCN-enabled nodes that perform Diffserv scheduling A single instance of an application-to-application flow of
[RFC2474]; the complete set of PCN-nodes that in packets, which is identified by <source address, destination
principle can, through PCN-marking packets, address, protocol id> and (where applicable) <source port,
influence decisions about flow admission and destination port>.
termination within the domain; includes the PCN-
egress-nodes, which measure these PCN-marks, and the
PCN-ingress-nodes.
PCN-boundary-node: a PCN-node that connects one PCN-domain to a node PCN-Admission-State
either in another PCN-domain or in a non-PCN-domain. 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-interior-node: a node in a PCN-domain that is not a PCN- PCN-Boundary-Node
boundary-node. A PCN-node that connects one PCN-domain to a node in either
another PCN-domain or a non-PCN-domain.
PCN-node: a PCN-boundary-node or a PCN-interior-node. PCN-Domain
A PCN-capable domain; a contiguous set of PCN-enabled nodes that
perform Diffserv scheduling [RFC2474]; the complete set of
PCN-nodes that in principle can, through PCN-marking packets,
influence decisions about flow admission and termination within
the domain; includes the PCN-egress-nodes, which measure these
PCN-marks, and the PCN-ingress-nodes.
PCN-egress-node: a PCN-boundary-node in its role in handling PCN-Egress-Node
traffic as it leaves a PCN-domain. In this A PCN-boundary-node in its role in handling traffic as it leaves a
document the PCN-egress-node operates also as a PCN-domain. In this document, the PCN-egress-node also operates
Decision Point and Deaggregator. as a Decision Point and Deaggregator.
PCN-ingress-node: a PCN-boundary-node in its role in handling PCN-Flow
traffic as it enters a PCN-domain. In this The unit of PCN-traffic that the PCN-boundary-node admits (or
document the PCN-ingress-node operates also as a terminates); the unit could be a single E2E microflow (as defined
Aggregator. in [RFC2474]) or some identifiable collection of microflows.
PCN-traffic, PCN-Ingress-Node
PCN-packets, A PCN-boundary-node in its role in handling traffic as it enters a
PCN-BA: a PCN-domain carries traffic of different Diffserv PCN-domain. In this document, the PCN-ingress-node also operates
behavior aggregates (BAs) [RFC2474]. The PCN-BA as an Aggregator.
uses the PCN mechanisms to carry PCN-traffic, and
the corresponding packets are PCN-packets.
The same network will carry traffic of other
Diffserv BAs. The PCN-BA is
distinguished by a combination of the Diffserv
codepoint (DSCP) and ECN fields.
PCN-flow: the unit of PCN-traffic that the PCN-boundary-node PCN-Interior-Node
admits (or terminates); the unit could be a single A node in a PCN-domain that is not a PCN-boundary-node.
E2E microflow (as defined in [RFC2474]) or some
identifiable collection of microflows.
PCN-admission-state: PCN-Node
The state ("admit" or "block") derived by the A PCN-boundary-node or a PCN-interior-node.
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 PCN-Sent-Rate
The rate of PCN-traffic received at a PCN-ingress- The rate of PCN-traffic received at a PCN-ingress-node and
node and destined for a given ingress-egress- destined for a given ingress-egress-aggregate in octets per
aggregate in octets per second. second.
PCN-Traffic, PCN-Packets, PCN-BA
A PCN-domain carries traffic of different Diffserv Behavior
Aggregates (BAs) [RFC2474]. The PCN-BA uses the PCN mechanisms to
carry PCN-traffic, and the corresponding packets are PCN-packets.
The same network will carry traffic of other Diffserv BAs. The
PCN-BA is distinguished by a combination of the Diffserv Codepoint
(DSCP) and Explicit Congestion Notification (ECN) fields.
PHB-ID (Per Hop Behavior Identification Code) PHB-ID (Per Hop Behavior Identification Code)
A 16-bit field containing the Per Hop Behavior A 16-bit field containing the Per Hop Behavior Identification Code
Identification Code of the PHB, or of the set of of the PHB, or of the set of PHBs, from which Diffserv resources
PHBs, from which Diffserv resources are to be reserved. This field must be encoded as specified in
are to be reserved. This field must be encoded as Section 2 of [RFC3140].
specified in Section 2 of [RFC3140].
RSVP generic aggregated reservation: an RSVP reservation that is RSVP Generic Aggregate Reservation
identified by using the RSVP SESSION object An RSVP reservation that is identified by using the RSVP SESSION
for generic RSVP aggregated reservation. This RSVP object for generic RSVP aggregate reservation. This RSVP SESSION
SESSION object is based on the RSVP SESSION object object is based on the RSVP SESSION object specified in [RFC4860],
specified in [RFC4860] augmented with the following 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
set to the IPv4 or IPv6 destination addresses, IPv4 or IPv6 destination addresses, respectively, of the
respectively, of the Deaggregator (PCN-egress- Deaggregator (PCN-egress-node).
node)
o) PHB-ID (Per Hop Behavior Identification Code) o The PHB-ID 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 The Extended vDstPort should be set to the IPv4 or IPv6
IPv6 destination addresses, of the Aggregator destination addresses, of the Aggregator (PCN-ingress-node).
(PCN-ingress-node)
VDstPort (Virtual Destination Port) VDstPort (Virtual Destination Port)
A 16-bit identifier used in the SESSION that remains constant over
the life of the generic aggregate reservation.
A 16-bit identifier used in the SESSION that 1.4. Organization of This Document
remains constant over the life of the generic
aggregate reservation.
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
RSVP extensions and operations. The elements of the used procedures of RSVP extensions and operations. The elements of the procedures
are specified in Section 3. Section 4 describes the protocol that are used in this document are specified in Section 3. Section 4
elements. The security considerations are given in section 5 and the describes the protocol elements. The security considerations are
IANA considerations are provided in Section 6. given in Section 5, and the 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 aggregate reservations [RFC4860], which depend on ingress-
ingress-egress-aggregates. In particular, one RSVP generic aggregated egress-aggregates. In particular, one RSVP generic aggregate
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 one or more RSVP
one, or more than one, RSVP generic aggregated reservations. generic aggregate reservations. In addition, to comply with this
In addition, to comply with this specification, the PCN-boundary specification, the PCN-boundary-nodes need to distinguish and process
nodes need to distinguish and process (1) RSVP SESSIONS for generic (1) RSVP SESSIONS for generic aggregate sessions and their messages
aggregated sessions and their messages according to [RFC4860], (2) according to [RFC4860] and (2) E2E RSVP SESSIONS and messages
E2E RSVP sessions and messages according to [RFC2205]. according to [RFC2205].
This document locates all RSVP processing for a PCN domain at PCN- This document locates all RSVP processing for a PCN-domain at
Boundary nodes. PCN-interior-nodes do not perform any RSVP PCN-boundary-nodes. PCN-interior-nodes do not perform any RSVP
functionality or maintain RSVP-related state information. Rather, functionality or maintain RSVP-related state information. Rather,
PCN-interior nodes forward all RSVP messages (for both generic PCN-interior-nodes forward all RSVP messages (for both generic
aggregated reservations[RFC4860] and end to end reservations aggregate reservations [RFC4860] and E2E reservations [RFC2205]) as
[RFC2205]) as if they were ordinary network traffic. if they were ordinary network traffic.
Moreover, each Aggregator and Deaggregator (i.e., PCN-boundary-nodes) Moreover, each Aggregator and Deaggregator (i.e., PCN-boundary-nodes)
need to support policies to initiate and maintain for each pair of needs to support policies to initiate and maintain, for each pair of
PCN-boundary-nodes of the same PCN-domain one ingress-egress- PCN-boundary-nodes of the same PCN-domain, one ingress-egress-
aggregate. 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
H--------/ |-----| |------| \-------->H H--------/ |-----| |------| \-------->H
| | | |
\ / \ /
-------------------------- --------------------------
H = Host requesting end-to-end RSVP reservations H = Host requesting end-to-end RSVP reservations
R = RSVP router R = RSVP router
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
over Generic Aggregate RSVP Reservations RSVP Reservations in PCN-Domains, Based on [RFC4860]
in PCN domains, based on [RFC4860]
Both the Aggregator and Deaggregator can maintain one or Both the Aggregator and Deaggregator can maintain one or more RSVP
more RSVP generic aggregated Reservations, but the Deaggregator is generic aggregate reservations, but the Deaggregator is the entity
the entity that initiates these RSVP generic aggregated reservations. that initiates these RSVP generic aggregate reservations. Note that
Note that one RSVP generic aggregated reservation matches to only one RSVP generic aggregate reservation matches to only one ingress-
one ingress-egress-aggregate, while one ingress-egress-aggregate egress-aggregate, while one ingress-egress-aggregate matches to one
matches to either one or to more than one RSVP generic aggregated or more RSVP generic aggregate reservations. This can be
reservations. This can be accomplished by using for the different accomplished by using for the different RSVP generic aggregate
RSVP generic aggregated reservations the same combinations of reservations the same combinations of ingress and egress identifiers,
ingress and egress identifiers, but with a different PHB-ID value but with a different PHB-ID value (see [RFC4860]). The procedures
(see [RFC4860]). The procedures for aggregation of E2E reservations for aggregation of E2E reservations over generic aggregate RSVP
over generic aggregate RSVP reservations are the same as the reservations are the same as the procedures specified in Section 4 of
procedures specified in Section 4 of [RFC4860], augmented with the [RFC4860], augmented with the ones specified in Section 2.5.
ones specified in Section 2.5.
One significant difference between this document and [RFC4860] is the One significant difference between this document and [RFC4860] is the
fact that in this document the admission control of E2E RSVP fact that in this document the admission control of E2E RSVP
reservations over the PCN core is performed according to the PCN reservations over the PCN-core is performed according to the PCN
procedures, while in [RFC4860] this is achieved via first admitting procedures, while in [RFC4860] this is achieved via first admitting
aggregate RSVP reservations over the aggregation region and then aggregate RSVP reservations over the aggregation region and then
admitting the E2E reservations over the aggregate RSVP reservations. admitting the E2E reservations over the aggregate RSVP reservations.
Therefore, in this document, the RSVP generic aggregate RSVP Therefore, in this document, the RSVP generic aggregate RSVP
reservations are not subject to admission control in the PCN-core, reservations are not subject to admission control in the PCN-core,
and the E2E RSVP reservations are not subject to admission control and the E2E RSVP reservations are not subject to admission control
over the aggregate reservations. In turn, this means that several over the aggregate reservations. In turn, this means that several
procedures of [RFC4860] are significantly simplified in this procedures described in [RFC4860] are significantly simplified in
document: this document:
o) unlike [RFC4860], the generic aggregate RSVP reservations need
not be admitted in the PCN core.
o) unlike [RFC4860], the RSVP aggregated traffic does not need to
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 o Unlike [RFC4860], the generic aggregate RSVP reservations need not
information be admitted in the PCN-core.
The method of PCN marking within the PCN domain is specified in o Unlike [RFC4860], the RSVP aggregated traffic does not need to be
[RFC5670]. In addition, the method of encoding and transport of pre- tunneled between Aggregator and Deaggregator; see Section 2.3.
congestion information is specified in [RFC6660]. The PHB-ID (Per Hop
Behavior Identification Code) used SHOULD be set equal
to PCN-compatible Diffserv codepoint(s).
2.3. Traffic Classification Within The Aggregation Region o Unlike [RFC4860], the Deaggregator need not perform admission
control of E2E reservations over the aggregate RSVP reservations.
The PCN-ingress marks a PCN-BA using PCN-marking (i.e., combination o Unlike [RFC4860], there is no need for dynamic adjustment of the
of the DSCP and ECN fields), which interior nodes use to RSVP generic aggregate reservation size; see Section 2.6.
classify PCN-traffic. 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
Deaggregator) by using the RSVP SESSION object for RSVP generic
aggregated reservations, see Section 2.1 of [RFC4860]. Note that the
DSCP value included in the SESSION object, SHOULD be set equal
to a PCN-compatible Diffserv codepoint. Since no admission control
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 Determination 2.2. PCN-Marking, Encoding, and Transport of Pre-congestion Information
The present document assumes the same dynamic Deaggregator The method of PCN-marking within the PCN-domain is specified in
determination method as used in [RFC4860]. [RFC5670]. In addition, the method of encoding and transport of
pre-congestion information is specified in [RFC6660]. The PHB-ID
(Per Hop Behavior Identification Code) used SHOULD be set equal to
PCN-compatible Diffserv Codepoint(s).
2.5. Mapping E2E Reservations Onto Aggregate Reservations 2.3. Traffic Classification within the Aggregation Region
To comply with this specification for the mapping of E2E reservations The PCN-ingress marks a PCN-BA using PCN-marking (i.e., a combination
onto aggregate reservations, the same methods MUST be used as the of the DSCP and ECN fields), which interior nodes use to classify
ones described in Section 4 of [RFC4860], augmented by the following PCN-traffic. The PCN-traffic (e.g., E2E microflows) belonging to an
rules: RSVP generic aggregate reservation can be classified only at the
PCN-boundary-nodes (i.e., Aggregator and Deaggregator) by using the
RSVP SESSION object for RSVP generic aggregate reservations; see
Section 2.1 of [RFC4860]. Note that the DSCP value included in the
SESSION object SHOULD be set equal to a PCN-compatible Diffserv
Codepoint. Since no admission control procedures over the RSVP
generic aggregate reservations in the PCN-core are required, unlike
[RFC4860], the RSVP aggregated traffic need not be tunneled between
Aggregator and Deaggregator. In this document, one RSVP generic
aggregate reservation is mapped to only one ingress-egress-aggregate,
while one ingress-egress-aggregate is mapped to one or more RSVP
generic aggregate reservations. PCN-flows and their PCN-traffic that
are mapped into a specific RSVP generic aggregate reservation can
also easily be classified into their corresponding ingress-egress-
aggregate. The method of traffic conditioning of PCN-traffic and
non-PCN-traffic, as well as the method of PHB configuration, are
described in [RFC6661] and [RFC6662].
o) An Aggregator (also PCN-ingress-node in this document) or 2.4. Deaggregator (PCN-Egress-Node) Determination
Deaggregator (also PCN-egress-node and Decision Point in this
document) MUST use one or more policies to determine whether a This document assumes the same dynamic Deaggregator determination
RSVP generic aggregated reservation can be mapped into an ingress- method as that used in [RFC4860].
Egress-aggregate. This can be accomplished by using for the
different RSVP generic aggregated reservations the same 2.5. Mapping E2E Reservations onto Aggregate Reservations
To comply with this specification, for the mapping of E2E
reservations onto aggregate reservations, the same methods MUST be
used as the ones described in Section 4 of [RFC4860], augmented by
the following rules:
o An Aggregator (PCN-ingress-node) or Deaggregator (PCN-egress-node
and Decision Point) MUST use one or more policies to determine
whether an RSVP generic aggregate reservation can be mapped into
an ingress-egress-aggregate. This can be accomplished by using
for the different RSVP generic aggregate reservations the same
combinations of ingress and egress identifiers, but with a combinations of ingress and egress identifiers, but with a
different PHB-ID value (see [RFC4860]) corresponding to the PCN different PHB-ID value (see [RFC4860]) corresponding to the PCN
specifications. In particular, the RSVP SESSION object specified specifications -- in particular, the RSVP SESSION object specified
in [RFC4860] augmented with the following information: in [RFC4860], augmented with the following information:
o) the IPv4 DestAddress, IPv6 DestAddress MUST be set to the o The IPv4 DestAddress, IPv6 DestAddress MUST be set to the IPv4
IPv4 or IPv6 destination addresses, respectively, of the 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 aggregate 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 The 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 o The Extended vDstPort SHOULD be set to the IPv4 or IPv6
destination addresses, of the Aggregator (PCN-ingress-node), destination addresses of the Aggregator (PCN-ingress-node); see
see [RFC4860]. [RFC4860].
2.6. Size of Aggregate Reservations 2.6. Size of Aggregate Reservations
Since:(i) no admission control of E2 reservations over the RSVP Since (1) no admission control of E2E reservations over the RSVP
aggregated reservations is required, and (ii) no admission control of aggregate reservations is required and (2) no admission control of
the RSVP aggregated reservation over the PCN core is required, the RSVP aggregate reservation over the PCN-core is required, the
the size of the generic aggregate reservation is irrelevant and can size of the generic aggregate reservation is irrelevant and can be
be set to any arbitrary value by the Deaggreagtor. The Deaggregator set to any arbitrary value by the Deaggregator. The Deaggregator
SHOULD set the value of a generic aggregate reservation to a null SHOULD set the value of a generic aggregate reservation to a null
bandwidth. We also observe that there is no need for dynamic bandwidth. We also observe that there is no need for dynamic
adjustment of the RSVP aggregated reservation size. adjustment of the RSVP aggregate reservation size.
2.7. E2E Path ADSPEC update 2.7. E2E Path ADSPEC Update
To comply with this specification, for the update of the E2E Path To comply with this specification, for the update of the E2E Path
ADSPEC, the same methods can be used as the ones described in ADSPEC, the same methods can be used as the 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 maintain neither E2E RSVP nor RSVP generic
generic aggregation states and reservations. Therefore, intra-domain aggregation states and reservations. Therefore, intra-domain route
route changes will not affect intra-domain reservations since such 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-
interior-nodes are not able to distinguish neither RSVP generic nodes can distinguish neither RSVP generic aggregate sessions and
aggregated sessions and their associated messages [RFC4860], nor E2E their associated messages [RFC4860] nor E2E RSVP SESSIONS and their
RSVP sessions and their associated messages [RFC2205]. 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.
for solving inter-domain routes changes associated with the operation However, for solving inter-domain route changes associated with the
of the RSVP messages, the same methods SHOULD be used as the ones operation of the RSVP messages, the same methods SHOULD be used as
described in [RFC4860] and in Section 1.4.7 of the ones described in [RFC4860] and in Section 1.4.7 of [RFC3175].
[RFC3175].
2.10. Reservations for Multicast Sessions 2.10. Reservations for Multicast Sessions
PCN does not consider reservations for multicast sessions. PCN does not consider reservations for multicast sessions.
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 do not support 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, for solving possible reliability To comply with this specification, for solving possible reliability
issues, the same methods MUST used as the ones described in Section 4 issues, the same methods MUST be used as the ones described in
of [RFC4860]. Section 4 of [RFC4860].
3. Elements of Procedure 3. Elements of Procedures
This section describes the procedures used to implement the This section describes the procedures used to implement the aggregate
aggregated RSVP procedure over PCN. It is considered that the RSVP procedure over PCN. It is considered that the procedures for
procedures for aggregation of E2E reservations over generic aggregate aggregation of E2E reservations over generic aggregate RSVP
RSVP reservations are same as the procedures specified in Section reservations are the same as the procedures specified in Section 4 of
4 of [RFC4860] except where a departure from these procedures is [RFC4860], except where a departure from these procedures is
explicitly described in the present section. Please refer to explicitly described in this section. Please refer to Appendix B of
[RFC4860] for all the below error [RFC2205] and Section 3 of [RFC4860] for the processing rules and
cases: error handling for the error cases listed below:
o) Incomplete message
o) Unexpected objects
3.1. Receipt of E2E Path Message by Aggregating router o Message formatting errors, e.g., incomplete message
o Unknown 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 When the E2E Path message arrives at the exterior interface of the
Aggregator, (also PCN-ingress-node in this document), then standard Aggregator (PCN-ingress-node), then standard RSVP generic aggregation
RSVP generic aggregation [RFC4860] procedures are used. [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
The PCN-interior-nodes receive the E2E Path message on an interior 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
It is considered that, by configuration, the PCN-interior-nodes considered that, by configuration, the PCN-interior-nodes ignore the
ignore the E2E RSVP signaling messages [RFC2205]. Therefore, the E2E E2E RSVP signaling messages [RFC2205]. Therefore, the E2E Path
Path messages are simply forwarded as normal IP datagrams. messages are simply forwarded as normal IP datagrams.
3.3. Receipt of E2E Path Message by Deaggregating router 3.3. Receipt of E2E Path Message by PCN-Egress-Node
(Deaggregating Router)
When receiving the E2E Path message the Deaggregator (also PCN- When receiving the E2E Path message, the Deaggregator (PCN-egress-
egress-node and Decision Point in this document) performs the node and Decision Point) performs the regular procedures of
regular [RFC4860] procedures, augmented with the following rules: [RFC4860], augmented with the following rules:
o) The Deaggregator MUST NOT perform the RSVP-TTL vs IP TTL- o The Deaggregator MUST NOT perform the RSVP-TTL vs. IP TTL-check
check and MUST NOT update the ADspec Break bit. This is because (TTL = Time To Live) and MUST NOT update the ADSPEC Break bit.
the whole PCN-domain is effectively handled by E2E RSVP as a This is because the whole PCN-domain is effectively handled by E2E
virtual link on which integrated service is indeed supported RSVP as a virtual link on which integrated service is indeed
(and admission control performed) so that the Break bit MUST supported (and admission control performed) so that the Break bit
NOT be set, see also [draft-lefaucheur-rsvp-ecn-01]. MUST NOT be set; see also [RSVP-PCN-CL].
The Deaggregator forwards the E2E Path message towards the The Deaggregator forwards the E2E Path message towards the receiver.
receiver.
3.4. Initiation of new Aggregate Path Message by Aggregating Router 3.4. Initiation of New Aggregate Path Message by PCN-Ingress-Node
(Aggregating Router)
To comply with this specification, for the initiation of the new RSVP To comply with this specification, for the initiation of the new RSVP
generic aggregated Path message by the Aggregator (also PCN-ingress- generic aggregate Path message by the Aggregator (PCN-ingress-node),
node in this document), the same methods MUST be used as the ones the same methods MUST be used as the ones described in [RFC4860].
described in [RFC4860].
3.5. Handling Of 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 Aggregated Path message on an The PCN-interior-nodes receive the Aggregate Path message on an
interior interface and forward it on another interior interface. interior interface and forward it on another interior interface. It
It is considered that, by configuration, the PCN-interior-nodes is considered that, by configuration, the PCN-interior-nodes ignore
ignore the Aggregated Path signaling messages. Therefore, the the Aggregate Path signaling messages. Therefore, the Aggregate Path
Aggregated Path messages are simply forwarded as normal IP datagrams. messages are simply forwarded as normal IP datagrams.
3.6. Handling Of Aggregate Path Message By Deaggregating Router 3.6. Handling of Aggregate Path Message by Deaggregating Router
When receiving the Aggregated Path message, the Deaggregator (also When receiving the Aggregate Path message, the Deaggregator
PCN-egress-node and Decision Point in this document) performs the (PCN-egress-node and Decision Point) performs the regular procedures
regular [RFC4860] procedures, augmented with the following rules: of [RFC4860], augmented with the following rules:
o) When the received Aggregated Path message by the Deaggregator o When the received Aggregate Path message by the Deaggregator
contains the RSVP-AGGREGATE-IPv4-PCN-response or contains the RSVP-AGGREGATE-IPv4-PCN-response or RSVP-AGGREGATE-
RSVP-AGGREGATE-IPv6-PCN-response PCN objects, which carry the IPv6-PCN-response PCN objects, which carry the PCN-sent-rate, then
PCN-sent-rate, then the procedures specified in Section 3.18 of the procedures specified in Section 3.18 of this document MUST be
this document MUST be followed. followed.
3.7. Handling of E2E Resv Message by Deaggregating Router 3.7. Handling of E2E Resv Message by Deaggregating Router
When the E2E Resv message arrives at the exterior interface of the When the E2E Resv message arrives at the exterior interface of the
Deaggregator, (also PCN-egress-node and Decision Point in this Deaggregator (PCN-egress-node and Decision Point), then standard RSVP
document) then standard RSVP aggregation [RFC4860] procedures are aggregation procedures of [RFC4860] are used, augmented with the
used, augmented with the following rules: following rules:
o) The E2E RSVP session associated with an E2E Resv o The E2E RSVP SESSION associated with an E2E Resv message that
message that arrives at the external interface of the Deaggregator arrives at the external interface of the Deaggregator is
is mapped/matched with an RSVP generic aggregate and with a PCN mapped/matched with an RSVP generic aggregate and with a PCN
ingress-egress-aggregate. ingress-egress-aggregate.
o) Depending on the type of the PCN edge behavior supported by the o Depending on the type of the PCN edge behavior supported by the
Deaggregator, the PCN admission control procedures specified in Deaggregator, the PCN admission control procedures specified in
Section 3.3.1 of [RFC6661] or [RFC6662] MUST be followed. Since no Section 3.3.1 of [RFC6661] or [RFC6662] MUST be followed. Since
admission control procedures over the RSVP aggregated reservations no admission control procedures over the RSVP aggregate
in the PCN-core are required, unlike [RFC4860], the Deaggregator reservations in the PCN-core are required, unlike [RFC4860], the
does not perform any admission control of the E2E Reservation over Deaggregator does not perform any admission control of the E2E
the mapped generic aggregate RSVP reservation. If the PCN based reservation over the mapped generic aggregate RSVP reservation.
admission control procedure is successful then the Deaggregator If the PCN-based admission control procedure is successful, then
MUST allow the new flow to be admitted onto the associated RSVP the Deaggregator MUST allow the new flow to be admitted onto the
generic aggregation reservation and onto the PCN ingress-egress- associated RSVP generic aggregation reservation and onto the PCN
aggregate, see [RFC6661] and [RFC6662]. If the PCN based admission ingress-egress-aggregate; see [RFC6661] and [RFC6662]. If the
control procedure is not successful, then the E2E Resv MUST NOT be PCN-based admission control procedure is not successful, then the
admitted onto the associated RSVP generic aggregate reservation and E2E Resv MUST NOT be admitted onto the associated RSVP generic
onto the PCN ingress-egress-aggregation. The E2E Resv message is aggregate reservation and onto the PCN ingress-egress-aggregation.
further processed according to [RFC4860]. The E2E Resv message is further processed according to [RFC4860].
The way of how the PCN-admission-state is maintained is specified in How the PCN-admission-state is maintained is specified in [RFC6661]
[RFC6661] and [RFC6662]. and [RFC6662].
3.8. Handling Of E2E Resv Message By Interior Routers 3.8. Handling of E2E Resv Message by Interior Routers
The E2E Resv messages traversing the PCN core are IP addressed to the The E2E Resv messages traversing the PCN-core are IP addressed to the
Aggregating router and are not marked with Router Alert, therefore Aggregating router and are not marked with Router Alert; therefore,
the E2E Resv messages are simply forwarded as normal IP datagrams. the E2E Resv messages are simply forwarded as normal IP datagrams.
3.9. Initiation of New Aggregate Resv Message By Deaggregating Router 3.9. Initiation of New Aggregate Resv Message by Deaggregating Router
To comply with this specification, for the initiation of the new RSVP To comply with this specification, for the initiation of the new RSVP
generic aggregated Resv message by the Deaggregator (also PCN-egress- generic aggregate Resv message by the Deaggregator (PCN-egress-node
node and Decision Point in this document), the same methods MUST be and Decision Point), the same methods MUST be used as the ones
used as the ones described in described in Section 4 of [RFC4860], augmented with the following
Section 4 of [RFC4860] augmented with the following rules: rules:
o) The size of the generic aggregate reservation is irrelevant, see o The size of the generic aggregate reservation is irrelevant (see
Section 2.6, and can be set to any arbitrary value by the PCN- Section 2.6) and can be set to any arbitrary value by the
egress node. The Deaggregator SHOULD set the value of a RSVP PCN-egress-node. The Deaggregator SHOULD set the value of an RSVP
generic aggregate reservation to a null bandwidth. We also generic aggregate reservation to a null bandwidth. We also
observe that there is no need for dynamic adjustment of the RSVP observe that there is no need for dynamic adjustment of the RSVP
generic aggregated reservation size. generic aggregate reservation size.
o) When [RFC6661] is used and the ETM-rate measured by the o When [RFC6661] is used and the ETM-rate measured by the
Deaggregator contains a non-zero value for some Deaggregator contains a non-zero value for some ingress-egress-
ingress-egress-aggregate, see [RFC6661] and [RFC6662], the aggregate (see [RFC6661] and [RFC6662]), the Deaggregator MUST
Deagregator MUST request the PCN-ingress-node to provide an request the PCN-ingress-node to provide an estimate of the rate
estimate of the rate (PCN-sent-rate) at which the Aggregator (PCN-sent-rate) at which the Aggregator (PCN-ingress-node) is
(also PCN-ingress-node in this document) is receiving PCN-traffic receiving PCN-traffic that is destined for the given ingress-
that is destined for the given ingress-egress-aggregate. egress-aggregate.
o) When [RFC6662] is used and the PCN-admission-state computed by the o When [RFC6662] is used and the PCN-admission-state computed by the
Deaggregator, on the basis of the CLE is "block" for the given Deaggregator on the basis of the CLE is "block" for the given
ingress-egress-aggregate, the Deaggregator MUST request the PCN- ingress-egress-aggregate, the Deaggregator MUST request the
ingress-node to provide an estimate of the rate (PCN-sent-rate) at PCN-ingress-node to provide an estimate of the rate
which the Aggregator is receiving PCN-traffic that is (PCN-sent-rate) at which the Aggregator is receiving PCN-traffic
destined for the given ingress-egress-aggregate. that is destined for the given ingress-egress-aggregate.
o) In the above two cases and when the PCN-sent-rate needs to be o In the above two cases and when the PCN-sent-rate needs to be
requested from the Aggregator, the Deaggregator MUST generate requested from the Aggregator, the Deaggregator MUST generate and
and send an (refresh) Aggregated Resv message to the Aggregator send to the Aggregator a (refresh) Aggregate Resv message that
that MUST carry one of the following PCN objects, see Section 4.1, MUST carry one of the following PCN objects (see Section 4.1),
depending on whether IPv4 or IPv6 is supported: depending on whether IPv4 or IPv6 is supported:
o) RSVP-AGGREGATE-IPv4-PCN-request
o) RSVP-AGGREGATE-IPv6-PCN-request. o RSVP-AGGREGATE-IPv4-PCN-request
o RSVP-AGGREGATE-IPv6-PCN-request
3.10. Handling of Aggregate Resv Message by Interior Routers 3.10. Handling of Aggregate Resv Message by Interior Routers
The Aggregated Resv messages traversing the PCN core are IP addressed The Aggregate Resv messages traversing the PCN-core are IP addressed
to the Aggregating router and are not marked with Router Alert, to the Aggregating router and are not marked with Router Alert;
therefore the Aggregated Resv messages are simply forwarded as normal therefore, the Aggregate Resv messages are simply forwarded as normal
IP datagrams. IP datagrams.
3.11. Handling of E2E Resv Message by Aggregating Router 3.11. Handling of E2E Resv Message by Aggregating Router
When the E2E Resv message arrives at the interior interface of the When the E2E Resv message arrives at the interior interface of the
Aggregator (also PCN-ingress-node in this document), then standard Aggregator (PCN-ingress-node), then standard RSVP aggregation
RSVP aggregation [RFC4860] procedures are used. procedures of [RFC4860] are used.
3.12. Handling of Aggregated Resv Message by Aggregating Router 3.12. Handling of Aggregate Resv Message by Aggregating Router
When the Aggregated Resv message arrives at the interior interface of When the Aggregate Resv message arrives at the interior interface of
the Aggregator, (also PCN-ingress-node in this document), the Aggregator (PCN-ingress-node), then standard RSVP aggregation
then standard RSVP aggregation [RFC4860] procedures are used, procedures of [RFC4860] are used, augmented with the following rules:
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 o The Aggregator SHOULD use the information carried by the PCN
particular, when the Aggregator receives an Aggregated Resv objects (see Section 4) and follow the steps specified in
message which carries one of the following PCN objects: Section 3.4 of [RFC6661] and [RFC6662]. If the "R" flag carried
RSVP-AGGREGATE-IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN- by the RSVP-AGGREGATE-IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN-
request, with the flag "R" set to ON, see Section 4.1, the request PCN objects is set to ON (see Section 4.1), then the
Aggregator initiates an Aggregated Path message, and includes the Aggregator follows the steps described in Section 3.4 of [RFC6661]
calculated PCN-sent-rate into the RSVP-AGGREGATE-IPv4-PCN-response and [RFC6662] on calculating the PCN-sent-rate. In particular,
or RSVP-AGGREGATE-IPv6-PCN-response PCN objects, see Section 4.1, the Aggregator MUST provide the estimated current rate of
which that MUST be carried by the Aggregated Path message. This PCN-traffic received at that node and destined for a given
Aggregated Path message is sent towards the Deaggregator (also ingress-egress-aggregate in octets per second (the PCN-sent-rate).
PCN-egress-node and Decision Point in this document) that The way this rate estimate is derived is a matter of
requested the calculation of the PCN-sent-rate. implementation; see [RFC6661] or [RFC6662].
o The Aggregator initiates an Aggregate Path message. In
particular, when the Aggregator receives an Aggregate Resv message
that carries one of the following PCN objects -- RSVP-AGGREGATE-
IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN-request -- with the
"R" flag set to ON (see Section 4.1), the Aggregator initiates an
Aggregate Path message and includes the calculated PCN-sent-rate
in the RSVP-AGGREGATE-IPv4-PCN-response or RSVP-AGGREGATE-
IPv6-PCN-response PCN objects (see Section 4.1), which MUST be
carried by the Aggregate Path message. This Aggregate Path
message is sent towards the Deaggregator (PCN-egress-node and
Decision Point) that requested the calculation of the
PCN-sent-rate.
3.13. Removal of E2E Reservation 3.13. Removal of E2E Reservation
To comply with this specification, for the removal of E2E To comply with this specification, for the removal of E2E
reservations, the same methods MUST be used as the ones described in reservations, the same methods MUST be used as the ones described in
Section 4 of [RFC4860] and [RFC4495]. Section 4 of [RFC4860] and Section 5 of [RFC4495].
3.14. Removal of Aggregate Reservation 3.14. Removal of Aggregate Reservation
To comply with this specification, for the removal of RSVP generic To comply with this specification, for the removal of RSVP generic
aggregated reservations, the same methods MUST be used as the ones aggregate reservations, the same methods MUST be used as the ones
described in Section 4 of [RFC4860] and Section 2.10 of [RFC3175]. In described in Section 4 of [RFC4860] and Section 2.10 of [RFC3175].
particular, should an aggregate reservation go away (presumably due In particular, should an aggregate reservation go away (presumably
to a configuration change, route change, or policy event), the E2E due to a configuration change, route change, or policy event), the
reservations it supports are no longer active. E2E reservations it supports are no longer active. They MUST be
They MUST be treated accordingly. treated accordingly.
3.15. Handling of Data On Reserved E2E Flow by Aggregating Router 3.15. Handling of Data on Reserved E2E Flow by Aggregating Router
The handling of data on the reserved E2E flow by Aggregator (also The handling of data on the reserved E2E flow by the Aggregator
PCN-ingress-node in this document) uses the procedures described (PCN-ingress-node) uses the procedures described in [RFC4860],
in [RFC4860] augmented with: augmented with the following:
o) Regarding, PCN marking and traffic classification the procedures
defined in Section 2.2 and 2.3 of this document are used. o Regarding PCN-marking and traffic classification, the procedures
defined in Sections 2.2 and 2.3 of this document are used.
3.16. Procedures for Multicast Sessions 3.16. Procedures for Multicast Sessions
In this document no multicast sessions are considered. No multicast sessions are considered in this document.
3.17. 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.10. the desired behavior is the same as that described in Section 3.10.
3.18 PCN based Flow Termination 3.18. PCN-Based Flow Termination
When the Deaggregator (also PCN-egress-node and Decision Point in When the Deaggregator (PCN-egress-node and Decision Point) needs to
this document) needs to terminate an amount of traffic associated terminate an amount of traffic associated with one ingress-egress-
with one ingress-egress-aggregate (see Section 3.3.2 of [RFC6661] and aggregate (see Section 3.3.2 of [RFC6661] and [RFC6662]), then
[RFC6662]), then several procedures of terminating E2E microflows can several procedures for terminating E2E microflows can be deployed.
be deployed. The default procedure of terminating E2E microflows The default procedure for terminating E2E microflows (i.e.,
(i.e., PCN-flows) is as follows, see i.e., [RFC6661] and [RFC6662]. PCN-flows) is as follows; see, for example, [RFC6661] and [RFC6662].
For the same ingress-egress-aggregate, select a number of E2E For the same ingress-egress-aggregate, select a number of E2E
microflows to be terminated in order to decrease the total incoming microflows to be terminated in order to decrease the total incoming
amount of bandwidth associated with one ingress-egress-aggregate by amount of bandwidth associated with one ingress-egress-aggregate by
the amount of traffic to be terminated, see above. In this situation the amount of traffic to be terminated. In this situation, the same
the same mechanisms for terminating an E2E microflow can be followed mechanisms for terminating an E2E microflow can be followed as the
as specified in [RFC2205]. However, based on a local policy, the mechanisms specified in [RFC2205]. However, based on a local policy,
Deaggregator could use other ways of selecting which microflows the Deaggregator could use other ways of selecting which microflows
should be terminated. For example, for the same ingress-egress- should be terminated. For example, for the same ingress-egress-
aggregate, select a number of E2E microflows to be terminated or to aggregate, select a number of E2E microflows to be terminated or to
reduce their reserved bandwidth in order to decrease the total reduce their reserved bandwidth in order to decrease the total
incoming amount of bandwidth associated with one ingress-egress- incoming amount of bandwidth associated with one ingress-egress-
aggregate by the amount of traffic to be terminated. In this aggregate by the amount of traffic to be terminated. In this
situation the same mechanisms for terminating an E2E microflow or situation, the same mechanisms for terminating an E2E microflow or
reducing bandwidth associated with an E2E microflow can be followed reducing bandwidth associated with an E2E microflow can be followed
as specified in [RFC4495]. as the mechanisms specified in Section 5 of [RFC4495].
4. Protocol Elements 4. Protocol Elements
The protocol elements in this document are using the ones defined in The protocol elements in this document are using the elements defined
Section 4 of [RFC4860] and Section 3 of [RFC3175] augmented with the in Section 4 of [RFC4860] and Section 3 of [RFC3175], augmented with
following rules: the following rules:
o) the DSCP value included in the SESSION object, SHOULD be set equal
to a PCN-compatible Diffserv codepoint.
o) Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination o The DSCP value included in the SESSION object SHOULD be set equal
addresses, of the Aggregator (also PCN-ingress-node in this to a PCN-compatible Diffserv Codepoint.
document), see [RFC4860].
o) When the Deaggregator (also PCN-egress-node and Decision Point o The Extended vDstPort SHOULD be set to the IPv4 or IPv6
in this document) needs to request the PCN-sent-rate from the destination addresses of the Aggregator (PCN-ingress-node); see
PCN-ingress-node, see Section 3.9 of this document, the [RFC4860].
Deaggregator MUST generate and send an (refresh) Aggregate
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.
o) When the Aggregator receives an Aggregate Resv message which o When the Deaggregator (PCN-egress-node and Decision Point) needs
carries one of the following PCN objects: to request the PCN-sent-rate from the PCN-ingress-node (see
RSVP-AGGREGATE-IPv4-PCN-request or Section 3.9 of this document), the Deaggregator MUST generate and
RSVP-AGGREGATE-IPv6-PCN-request, with the flag "R" set to ON, see send a (refresh) Aggregate Resv message to the Aggregator that
Section 4.1, then the Aggregator MUST generate and send to the MUST carry one of the following PCN objects (see Section 4.1),
Deaggregator an Aggregated Path message which carries one of the depending on whether IPv4 or IPv6 is supported:
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 o RSVP-AGGREGATE-IPv4-PCN-request
o RSVP-AGGREGATE-IPv6-PCN-request
o When the Aggregator receives an Aggregate Resv message that
carries one of the following PCN objects -- RSVP-AGGREGATE-
IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN-request, with the "R"
flag set to ON (see Section 4.1) -- then the Aggregator MUST
generate and send to the Deaggregator an Aggregate Path message
that 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
This section describes four types of PCN objects that can be carried This section describes four types of PCN objects that can be carried
by the (refresh) Aggregate Path or the (refresh) Aggregate Resv by the (refresh) Aggregate Path or the (refresh) Aggregate Resv
messages specified in [RFC4860]. messages specified in [RFC4860].
These objects are: These objects are as follows:
o RSVP-AGGREGATE-IPv4-PCN-request,
o RSVP-AGGREGATE-IPv6-PCN-request, o RSVP-AGGREGATE-IPv4-PCN-request
o RSVP-AGGREGATE-IPv4-PCN-response,
o RSVP-AGGREGATE-IPv6-PCN-response. o RSVP-AGGREGATE-IPv6-PCN-request
o RSVP-AGGREGATE-IPv4-PCN-response
o RSVP-AGGREGATE-IPv6-PCN-response
o RSVP-AGGREGATE-IPv4-PCN-request: PCN request object, when IPv4
addresses are used:
o) RSVP-AGGREGATE-IPv4-PCN-request: PCN request object, when
IPv4 addresses are used:
Class = 248 (PCN) Class = 248 (PCN)
C-Type = 1 (RSVP-AGGREGATE-IPv4-PCN-request C-Type = 1 (RSVP-AGGREGATE-IPv4-PCN-request)
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| 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) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Decision Point Address (4 bytes) | | IPv4 Decision Point Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
|R| Reserved | |R| Reserved |
+-------------+-------------+-------------+-------------| +-------------+-------------+-------------+-------------+
o) RSVP-AGGREGATE-IPv6-PCN-request: PCN object, when o RSVP-AGGREGATE-IPv6-PCN-request: PCN object, when IPv6 addresses
IPv6 addresses are used: are used:
Class = 248 (PCN) Class = 248 (PCN)
C-Type = 2 (RSVP-AGGREGATE-IPv6-PCN-request C-Type = 2 (RSVP-AGGREGATE-IPv6-PCN-request)
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ 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) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ Decision Point Address (16 bytes) + + Decision Point Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
|R| Reserved | |R| Reserved |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o RSVP-AGGREGATE-IPv4-PCN-response: PCN object, IPv4 addresses
are used:
o) RSVP-AGGREGATE-IPv4-PCN-response: PCN object, IPv4
addresses are used:
Class = 248 (PCN) Class = 248 (PCN)
C-Type = 3 (RSVP-AGGREGATE-IPv4-PCN-response) C-Type = 3 (RSVP-AGGREGATE-IPv4-PCN-response)
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| 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) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Decision Point Address (4 bytes) | | IPv4 Decision Point Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| PCN-sent-rate | | PCN-sent-rate |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o RSVP-AGGREGATE-IPv6-PCN-response: PCN object, IPv6 addresses
are used:
o) RSVP-AGGREGATE-IPv6-PCN-response: PCN object, IPv6
addresses are used:
Class = 248 (PCN) Class = 248 (PCN)
C-Type = 4 (RSVP-AGGREGATE-IPv6-PCN-response) C-Type = 4 (RSVP-AGGREGATE-IPv6-PCN-response)
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ 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) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ Decision Point Address (16 bytes) + + Decision Point Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| PCN-sent-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],
[RFC6663], [RFC6661] and [RFC6662]: [RFC6661], and [RFC6662]:
o the IPv4 or IPv6 address of the PCN-ingress-node (Aggregator) and o The IPv4 or IPv6 address of the PCN-ingress-node (Aggregator) and
the IPv4 or IPv6 address of the PCN-egress-node (Deaggregator); the IPv4 or IPv6 address of the PCN-egress-node (Deaggregator):
together they specify the ingress-egress-aggregate to which the together, they specify the ingress-egress-aggregate to which the
report refers. According to [RFC6663] the report should carry the report refers. According to [RFC6663], the report should carry
identifier of the PCN-ingress-node (Aggregator) and the the identifier of the PCN-ingress-node (Aggregator) and the
identifier of the PCN-egress-node (Deaggregator) (typically identifier of the PCN-egress-node (Deaggregator) (typically their
their IP addresses); IP addresses).
o Decision Point address specify the IPv4 or IPv6 address of the o Decision Point Address: specifies the IPv4 or IPv6 address of the
Decision Point. In this document this field MUST contain the IP Decision Point. In this document, this field MUST contain the IP
address of the Deaggregator. address of the Deaggregator.
o "R": 1 bit flag that when set to ON, signifies, according to o "R": 1-bit flag that, when set to ON, signifies, according to
[RFC6661] and [RFC6662], that the PCN-ingress-node (Aggregator) [RFC6661] and [RFC6662], that the PCN-ingress-node (Aggregator)
MUST provide an estimate of the rate (PCN-sent-rate) at which the MUST provide an estimate of the rate (PCN-sent-rate) at which the
PCN-ingress-node (Aggregator) is receiving PCN-traffic that is PCN-ingress-node (Aggregator) is receiving PCN-traffic that is
destined for the given ingress-egress-aggregate. destined for the given ingress-egress-aggregate.
O "Reserved": 31 bits that are currently not used by this o "Reserved": 31 bits that are currently not used by this document
document and are reserved. These SHALL be set to 0 and SHALL be and are reserved. These SHALL be set to 0 and SHALL be ignored on
ignored on reception. reception.
o PCN-sent-rate: the PCN-sent-rate for the given o PCN-sent-rate: the estimate of the rate at which the PCN-ingress-
ingress-egress-aggregate. It is expressed in octets/second; its node (Aggregator) is receiving PCN-traffic that is destined for
format is a 32-bit IEEE floating point number; The PCN-sent-rate the given ingress-egress-aggregate. It is expressed in
is specified in [RFC6661] and [RFC6662] and it represents the octets/second; its format is a 32-bit IEEE floating-point number.
estimate of the rate at which the PCN-ingress-node (Aggregator) The PCN-sent-rate is specified in [RFC6661] and [RFC6662].
is receiving PCN-traffic that is destined for the given
ingress-egress-aggregate.
5. Security Considerations 5. Security Considerations
The security considerations specified in [RFC2205], [RFC4860] and The security considerations specified in [RFC2205], [RFC4860], and
[RFC5559] apply to this document. In addition, [RFC4230] and [RFC5559] apply to this document. In addition, [RFC4230] and
[RFC6411] provide useful guidance on RSVP security mechanisms. [RFC6411] provide useful guidance on RSVP security mechanisms.
Security within a PCN domain is fundamentally based on the controlled Security within a PCN-domain is fundamentally based on the controlled
environment trust assumption stated in Section 6.3.1 of [RFC5559], in environment trust assumption stated in Section 6.3.1 of [RFC5559] --
particular that all PCN-nodes are PCN-enabled and are trusted in particular, that all PCN-nodes are PCN-enabled and are trusted to
to perform accurate PCN-metering and PCN-marking. perform accurate PCN-metering and PCN-marking.
In the PCN domain environments addressed by this document, Generic In the PCN-domain environments addressed by this document, Generic
Aggregate Resource ReSerVation Protocol (RSVP) messages specified in Aggregate RSVP messages specified in [RFC4860] are used for support
[RFC4860] are used for support of the PCN Controlled Load (CL) and of the PCN Controlled Load (CL) and Single Marking (SM) edge
Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- behaviors over a Diffserv cloud using Pre-Congestion Notification.
Congestion Notification. Hence the security mechanisms discussed Hence, the security mechanisms discussed in [RFC4860] are applicable.
in [RFC4860] are applicable. Specifically, the INTEGRITY object Specifically, the INTEGRITY object [RFC2747] [RFC3097] can be used to
[RFC2747][RFC3097] can be used to provide hop-by-hop RSVP message provide hop-by-hop RSVP message integrity, node authentication, and
integrity, node authentication and replay protection, thereby replay protection, thereby protecting against corruption and spoofing
protecting against corruption and spoofing of RSVP messages and of RSVP messages and PCN feedback conveyed by RSVP messages.
PCN feedback conveyed by RSVP messages.
For these reasons, this document does not introduce significant For these reasons, this document does not introduce significant
additional security considerations beyond those discussed in additional security considerations beyond those discussed in
[RFC5559] and [RFC4860]. [RFC5559] and [RFC4860].
6. IANA Considerations 6. IANA Considerations
IANA has modified the RSVP parameters registry, 'Class Names, IANA has modified the "Class Names, Class Numbers, and Class Types"
Class Numbers, and Class Types' subregistry, to add a new subregistry of the "Resource Reservation Protocol (RSVP) Parameters"
Class Number and assign 4 new C-Types under this new Class registry, to add a new Class Number and assign four new C-Types under
Number, as described below, see Section 4.1: this new Class Number, as described below; see Section 4.1:
Class Class
Number Class Name Reference Number Class Name Reference
------ ---------------------- --------- ------- ---------------------- -------------
248 PCN this document 248 PCN RFC 7417
Class Types or C-Types:
1 RSVP-AGGREGATE-IPv4-PCN-request this document
2 RSVP-AGGREGATE-IPv6-PCN-request this document
3 RSVP-AGGREGATE-IPv4-PCN-response this document
4 RSVP-AGGREGATE-IPv6-PCN-response this document
When this draft is published as an RFC, IANA should update the
reference for the above 5 items to that published RFC (and the RFC
Editor should remove this sentence).
7. Acknowledgments Class Types or C-Types - 248 PCN
We would like to thank the authors of [draft-lefaucheur-rsvp-ecn- Value Description Reference
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 1 RSVP-AGGREGATE-IPv4-PCN-request RFC 7417
like to thank Bob Briscoe, David Black, Ken Carlberg, Tom Taylor, 2 RSVP-AGGREGATE-IPv6-PCN-request RFC 7417
Philip Eardley, Michael Menth, Toby Moncaster, James Polk, Scott 3 RSVP-AGGREGATE-IPv4-PCN-response RFC 7417
Bradner, Lixia Zhang and Robert Sparks for the provided comments. In 4 RSVP-AGGREGATE-IPv6-PCN-response RFC 7417
particular, we would like to thank Francois Le Faucheur for
contributing in addition to comments also to a significant amount of
text.
8. Normative References 7. References
[RFC6661] T. Taylor, A, Charny, F. Huang, 7.1. Normative References
G. Karagiannis, M. Menth, "PCN Boundary Node Behaviour for the
Controlled Load (CL) Mode of Operation", July
2012.
[RFC6662] A. Charny, J. Zhang, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node Behaviour Requirement Levels", BCP 14, RFC 2119, March 1997,
for the Single Marking (SM) Mode of Operation", <http://www.rfc-editor.org/info/rfc2119>.
July 2012.
[RFC6663] G. Karagiannis, T. Taylor, [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
K. Chan, M. Menth, P. Eardley, " Requirements for Signaling of (Pre-) Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Congestion Information in a DiffServ Domain", Functional Specification", RFC 2205, September 1997,
July 2012. <http://www.rfc-editor.org/info/rfc2205>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
Requirement Levels", BCP 14, RFC 2119, March 1997. "Per Hop Behavior Identification Codes", RFC 3140,
June 2001, <http://www.rfc-editor.org/info/rfc3140>.
[RFC2205] Braden, R., ed., et al., "Resource ReSerVation Protocol [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
(RSVP)- Functional Specification", RFC 2205, September 1997. "Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, September 2001,
<http://www.rfc-editor.org/info/rfc3175>.
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le [RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation Protocol
Faucheur, "Per Hop Behavior Identification Codes", (RSVP) Extension for the Reduction of Bandwidth of a
RFC 3140, June 2001. Reservation Flow", RFC 4495, May 2006,
<http://www.rfc-editor.org/info/rfc4495>.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M.
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, Davenport, "Generic Aggregate Resource ReSerVation
September 2001. Protocol (RSVP) Reservations", RFC 4860, May 2007,
<http://www.rfc-editor.org/info/rfc4860>.
[RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation [RFC5670] Eardley, P., Ed., "Metering and Marking Behaviour of
Protocol (RSVP) Extension for the Reduction of PCN-Nodes", RFC 5670, November 2009,
Bandwidth of a Reservation Flow", RFC 4495, May 2006. <http://www.rfc-editor.org/info/rfc5670>.
[RFC4860] F. Le Faucheur, B. Davie, P. Bose, C. Christou, M. [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Pre-Congestion Notification (PCN) States in the IP Header
Reservations", RFC4860, May 2007. Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
July 2012, <http://www.rfc-editor.org/info/rfc6660>.
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", [RFC6661] Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
RFC 5670, November 2009. Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary-
Node Behavior for the Controlled Load (CL) Mode of
Operation", RFC 6661, July 2012,
<http://www.rfc-editor.org/info/rfc6661>.
[RFC6660] Moncaster, T., Briscoe, B., and M. Menth, "Baseline [RFC6662] Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T.
Encoding and Transport of Pre-Congestion Information", RFC 6660, Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary-
July 2012. Node Behavior for the Single Marking (SM) Mode of
Operation", RFC 6662, July 2012,
<http://www.rfc-editor.org/info/rfc6662>.
9. Informative References [RFC6663] Karagiannis, G., Taylor, T., Chan, K., Menth, M., and P.
Eardley, "Requirements for Signaling of Pre-Congestion
Information in a Diffserv Domain", RFC 6663, July 2012,
<http://www.rfc-editor.org/info/rfc6663>.
[draft-lefaucheur-rsvp-ecn-01.txt] Le Faucheur, F., Charny, A., 7.2. Informative References
Briscoe, B., Eardley, P., Chan, K., and J. Babiarz, "RSVP Extensions
for Admission Control over Diffserv using Pre-congestion
Notification (PCN) (Work in progress)", June 2006.
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", RFC 1633, June Services in the Internet Architecture: an Overview",
1994. RFC 1633, June 1994,
<http://www.rfc-editor.org/info/rfc1633>.
[RFC2211] J. Wroclawski, Specification of the Controlled-Load Network [RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Element Service, September 1997 Network Element Service", RFC 2211, September 1997,
<http://www.rfc-editor.org/info/rfc2211>.
[RFC2212] S. Shenker et al., Specification of Guaranteed Quality of [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
Service, September 1997 of Guaranteed Quality of Service", RFC 2212,
September 1997, <http://www.rfc-editor.org/info/rfc2212>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS Field) in the "Definition of the Differentiated Services Field (DS
IPv4 and IPv6 Headers", RFC 2474, December 1998. Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
W. Weiss, "A framework for Differentiated Services", RFC 2475, and W. Weiss, "An Architecture for Differentiated
December 1998. Services", RFC 2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000,
<http://www.rfc-editor.org/info/rfc2747>.
[RFC2753] Yavatkar, R., D. Pendarakis and R. Guerin, "A Framework for [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
Policy-based Admission Control", January 2000. for Policy-based Admission Control", RFC 2753,
January 2000, <http://www.rfc-editor.org/info/rfc2753>.
[RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Speer, M., Braden, R., Davie, B., Wroclawski, J., and E.
Framework for Integrated Services Operation Over DiffServ Networks", Felstaine, "A Framework for Integrated Services Operation
RFC 2998, November 2000. over Diffserv Networks", RFC 2998, November 2000,
<http://www.rfc-editor.org/info/rfc2998>.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
-- Updated Message Type Value", RFC 3097, April 2001. Authentication -- Updated Message Type Value", RFC 3097,
April 2001, <http://www.rfc-editor.org/info/rfc3097>.
[RFC4230] H. Tschofenig, R. Graveman, "RSVP Security Properties", [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security
RFC 4230, December 2005. Properties", RFC 4230, December 2005,
<http://www.rfc-editor.org/info/rfc4230>.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) [RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling
Architecture", RFC 5559, June 2009. in a Nested Virtual Private Network", RFC 4923,
August 2007, <http://www.rfc-editor.org/info/rfc4923>.
[RFC6411] M. Behringer, F. Le Faucheur, B. Weis, "Applicability of [RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN)
Keying Methods for RSVP Security", RFC 6411, October 2011. Architecture", RFC 5559, June 2009,
<http://www.rfc-editor.org/info/rfc5559>.
[SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested [RFC6411] Behringer, M., Le Faucheur, F., and B. Weis,
Virtual Private Network", Work in Progress, July 2007. "Applicability of Keying Methods for RSVP Security",
RFC 6411, October 2011,
<http://www.rfc-editor.org/info/rfc6411>.
10. Appendix A: Example Signaling Flow [RSVP-PCN-CL]
Le Faucheur, F., Charny, A., Briscoe, B., Eardley, P.,
Babiarz, J., and K. Chan, "RSVP Extensions for Admission
Control over Diffserv using Pre-congestion Notification
(PCN)", Work in Progress, draft-lefaucheur-rsvp-ecn-01,
June 2006.
Appendix A. Example Signaling Flow
This appendix is based on Appendix A of [RFC4860]. In particular, it
provides an example signaling flow of the specifications detailed in
Sections 3 and 4.
This appendix is based on the appendix provided in [RFC4860]. In
particular, it provides an example signaling flow of the
specification detailed in Section 3 and 4.
This signaling flow assumes an environment where E2E reservations are This signaling flow assumes an environment where E2E reservations are
aggregated over generic aggregate RSVP reservations and applied over aggregated over generic aggregate RSVP reservations and applied over
a PCN domain. In particular the Aggregator (PCN-ingress-node) and a PCN-domain. In particular, the Aggregator (PCN-ingress-node) and
Deaggregator (PCN-egress-node) are located at the boundaries of the Deaggregator (PCN-egress-node) are located at the boundaries of the
PCN domain. The PCN-interior-nodes are located within the PCN-domain, PCN-domain. The PCN-interior-nodes are located within the
between the PCN-boundary nodes, but are not shown in this Figure. It PCN-domain, between the PCN-boundary-nodes, but are not shown in the
illustrates a possible RSVP message flow that could take place in the diagram below. It illustrates a possible RSVP message flow that
successful establishment of a unicast E2E reservation that is the could take place in the successful establishment of a unicast E2E
first between a given pair of Aggregator/Deaggregator. reservation that is the first between a given Aggregator-Deaggregator
pair.
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=GApcn) E2E PathErr(NEW-AGGREGATE-NEEDED,SOI=GApcn)
<---------------------------------- <----------------------------------------
(3) (3)
AggPath(Session=GApcn) AggPath(Session=GApcn)
-------------------------------> ------------------------------->
(4) (4)
E2E Path E2E Path
-----------> ----------->
(5) (5)
AggResv (Session=GApcn) (PCN object) AggResv (Session=GApcn) (PCN object)
<------------------------------- <-------------------------------
(6) (6)
AggResvConfirm (Session=GApcn) AggResvConfirm (Session=GApcn)
------------------------------> ------------------------------>
(7) (7)
E2E Resv E2E Resv
<--------- <---------
(8) (8)
E2E Resv (SOI=GApcn) E2E Resv (SOI=GApcn)
<----------------------------- <-----------------------------
(9) (9)
E2E Resv E2E Resv
<----------- <-----------
(1) The Aggregator forwards E2E Path into the aggregation region (1) The Aggregator forwards E2E Path into the aggregation region
after modifying its IP protocol number to RSVP-E2E-IGNORE after modifying its IP protocol number to RSVP-E2E-IGNORE.
(2) Let's assume no Aggregate Path exists. To be able to accurately (2) Let's assume that no Aggregate Path exists. To be able to
update the ADSPEC of the E2E Path, the Deaggregator needs the accurately update the ADSPEC of the E2E Path, the Deaggregator
ADSPEC of Aggregate Path. In this example, the Deaggregator needs the ADSPEC of Aggregate Path. In this example, the
elects to instruct the Aggregator to set up an Aggregate Path Deaggregator elects to instruct the Aggregator to set up an
state for the PCN PHB-ID. To do that, the Deaggregator Aggregate Path state for the PCN PHB-ID. To do that, the
sends an E2E PathErr message with a New-Agg-Needed PathErr Deaggregator sends an E2E PathErr message with a
code. NEW-AGGREGATE-NEEDED PathErr code.
The PathErr message also contains a SESSION-OF-INTEREST The PathErr message also contains a SESSION-OF-INTEREST (SOI)
(SOI) object. The SOI contains a GENERIC-AGGREGATE SESSION object. The SOI contains a GENERIC-AGGREGATE SESSION (GApcn)
(GApcn) whose PHB-ID is set to the PCN PHB-ID. The GENERIC- whose PHB-ID is set to the PCN PHB-ID. The GENERIC-AGGREGATE
AGGREGATE SESSION contains an interface-independent Deaggregator SESSION contains an interface-independent Deaggregator address
address inside the DestAddress and appropriate values inside the inside the DestAddress and appropriate values inside the vDstPort
vDstPort and Extended vDstPort fields. In this document, the and Extended vDstPort fields. In this document, the Extended
Extended vDstPort SHOULD contain the IPv4 or IPv6 address of vDstPort SHOULD contain the IPv4 or IPv6 address of the
the Aggregator. 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 the GENERIC-AGGREGATE Session signals an Aggregate Path for the GENERIC-AGGREGATE SESSION
(GApcn). (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 PCN-egress-node MUST NOT perform the ADSPEC accordingly. The PCN-egress-node MUST NOT perform the
RSVP-TTL vs IP TTL-check and MUST NOT update the ADspec Break RSVP-TTL vs. IP TTL-check and MUST NOT update the ADSPEC Break
bit. This is because the whole PCN-domain is effectively handled bit. This is because the whole PCN-domain is effectively handled
by E2E RSVP as a virtual link on which integrated service is by E2E RSVP as a virtual link on which integrated service is
indeed supported (and admission control performed) so that the indeed supported (and admission control performed) so that the
Break bit MUST NOT be set, see also Break bit MUST NOT be set; see also [RSVP-PCN-CL]. The
[draft-lefaucheur-rsvp-ecn-01]. The Deaggregator also modifies Deaggregator also modifies the E2E Path IP protocol number to
the E2E Path IP protocol number to RSVP before forwarding it. 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 the generic aggregate reservation. In with establishment of the generic aggregate reservation. In
effect, the Deaggregator can be seen as anticipating effect, the Deaggregator can be seen as anticipating the actual
the actual demand of E2E reservations so that the generic demand of E2E reservations so that the generic aggregate
aggregate reservation is in place when the E2E Resv reservation is in place when the E2E Resv request arrives, in
request arrives, in order to speed up establishment of E2E order to speed up establishment of E2E reservations. Here it is
reservations. Here it is also assumed that the Deaggregator also assumed that the Deaggregator includes the optional
includes the optional Resv Confirm Request in the Aggregate ResvConfirm Request in the Aggregate Resv message.
Resv message.
(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.
(7) The Deaggregator has explicit confirmation that the generic (7) The Deaggregator has explicit confirmation that the generic
aggregate reservation is 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 the PCN PHB-ID=x. The generic aggregate reservation with the PCN PHB-ID=x. After the
Deaggregator knows that a generic aggregate reservation (GApcn) previous step (7), the Deaggregator knows that a generic
is in place for the corresponding PHB-ID since (7). At this step aggregate reservation (GApcn) is in place for the corresponding
the Deaggregator maps the generic aggregated reservation onto one PHB-ID. At this step, the Deaggregator maps the generic
ingress-egress-aggregate maintained by the Deaggregator (as a aggregate reservation onto one ingress-egress-aggregate
PCN-egress-node), see Section 3.7. The Deaggregator performs maintained by the Deaggregator (as a PCN-egress-node); see
admission control of the E2E Resv onto the generic Aggregate Section 3.7. The Deaggregator performs admission control of the
reservation for the PCN PHB-ID (GApcn). The Deaggregator takes E2E Resv onto the generic aggregate reservation for the PCN
also into account the PCN admission control procedure as PHB-ID (GApcn). The Deaggregator also takes into account the PCN
as specified in [RFC6661] and [RFC6662], see Section 3.7. admission control procedure as specified in [RFC6661] and
If one or both the admission control procedures (PCN based [RFC6662]; see Section 3.7. If one or both of the admission
admission control procedure and admission control procedure control procedures (the PCN-based admission control procedure
specified in [RFC4860]) are not successful, then the E2E Resv is described in Section 3.3.1 of [RFC6661] or [RFC6662], and the
not admitted onto the associated RSVP generic aggregate admission control procedure specified in [RFC4860]) are not
reservation for the PCN PHB-ID (GApcn). Otherwise, assuming that successful, then the E2E Resv is not admitted onto the associated
the generic aggregate reservation for the PCN (GApcn) had been RSVP generic aggregate reservation for the PCN PHB-ID (GApcn).
established with sufficient bandwidth to support the E2E Resv, Otherwise, assuming that the generic aggregate reservation for
the Deaggregator adjusts its counter, tracking the unused the PCN (GApcn) had been established with sufficient bandwidth to
bandwidth on the generic aggregate reservation. Then it forwards support the E2E Resv, the Deaggregator adjusts its counter,
the E2E Resv to the Aggregator including a SESSION-OF-INTEREST tracking the unused bandwidth on the generic aggregate
object conveying the selected mapping onto GApcn (and hence onto reservation. Then it forwards the E2E Resv to the Aggregator,
the PCN PHB-ID). 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 (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 onto the PCN PHB-ID). The Aggregator removes the SOI object
and forwards the E2E Resv towards the sender. and forwards the E2E Resv towards the sender.
11. Authors' Address Acknowledgments
We would like to thank the authors of [RSVP-PCN-CL], since some ideas
used in this document are based on the work initiated in
[RSVP-PCN-CL]. Moreover, we would like to thank Bob Briscoe, David
Black, Ken Carlberg, Tom Taylor, Philip Eardley, Michael Menth, Toby
Moncaster, James Polk, Scott Bradner, Lixia Zhang, and Robert Sparks
for the provided comments. In particular, we would like to thank
Francois Le Faucheur for contributing a significant amount of text,
in addition to his comments.
Authors' Addresses
Georgios Karagiannis Georgios Karagiannis
Huawei Technologies Huawei Technologies
Hansaallee 205, Hansaallee 205
40549 Dusseldorf, 40549 Dusseldorf
Germany Germany
Email: Georgios.Karagiannis@huawei.com
EMail: Georgios.Karagiannis@huawei.com
Anurag Bhargava Anurag Bhargava
Cisco Systems, Inc. Cisco Systems, Inc.
7100-9 Kit Creek Road 7100-9 Kit Creek Road
PO Box 14987 PO Box 14987
RESEARCH TRIANGLE PARK, NORTH CAROLINA 27709-4987 Research Triangle Park, NC 27709-4987
USA United States
Email: anuragb@cisco.com
EMail: anuragb@cisco.com
 End of changes. 241 change blocks. 
1045 lines changed or deleted 1074 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/