draft-ietf-tsvwg-rsvp-pcn-06.txt   draft-ietf-tsvwg-rsvp-pcn-07.txt 
Internet Engineering Task Force Georgios Karagiannis Internet Engineering Task Force Georgios Karagiannis
Internet-Draft University of Twente Internet-Draft University of Twente
Intended status: Experimental Anurag Bhargava Intended status: Experimental Anurag Bhargava
Expires: January 29, 2014 Cisco Systems, Inc. Expires: April 21, 2014 Cisco Systems, Inc.
July 29, 2013 October 21, 2013
Generic Aggregation of Resource ReSerVation Protocol (RSVP) Generic Aggregation of Resource ReSerVation Protocol (RSVP)
for IPv4 And IPv6 Reservations over PCN domains for IPv4 And IPv6 Reservations over PCN domains
draft-ietf-tsvwg-rsvp-pcn-06 draft-ietf-tsvwg-rsvp-pcn-07
Abstract Abstract
This document specifies extensions to Generic Aggregated RSVP This document specifies extensions to Generic Aggregated RSVP
[RFC4860] for support of the PCN Controlled Load (CL) and Single [RFC4860] for support of the PCN Controlled Load (CL) and Single
Marking (SM) edge behaviors over a Diffserv cloud using Pre- Marking (SM) edge behaviors over a Diffserv cloud using Pre-
Congestion Notification. Congestion Notification.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 29, 2014. This Internet-Draft will expire on April 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 39 skipping to change at page 2, line 39
1.2. Overview and Motivation . . . . . . . . . . . . . . . . . . . 4 1.2. Overview and Motivation . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Organization of This Document . . . . . . . . . . . . . . . . 11 1.4. Organization of This Document . . . . . . . . . . . . . . . . 11
2. Overview of RSVP extensions and Operations . . . . . . . . . . . 11 2. Overview of RSVP extensions and Operations . . . . . . . . . . . 11
2.1. Overview of RSVP Aggregation Procedures in PCN domains . . . . . 11 2.1. Overview of RSVP Aggregation Procedures in PCN domains . . . . . 11
2.2. PCN Marking and encoding and transport of pre-congestion 2.2. PCN Marking and encoding and transport of pre-congestion
Information . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Information . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Traffic Classification Within The Aggregation Region . . . . . . 13 2.3. Traffic Classification Within The Aggregation Region . . . . . . 13
2.4. Deaggregator (PCN-egress-node) Determination . . . . . . . . . . 13 2.4. Deaggregator (PCN-egress-node) Determination . . . . . . . . . . 13
2.5. Mapping E2E Reservations Onto Aggregate Reservations . . . . . . 14 2.5. Mapping E2E Reservations Onto Aggregate Reservations . . . . . . 14
2.6 Size of Aggregate Reservations . . . . . . . . . . . . . . . . . 14 2.6 Size of Aggregate Reservations . . . . . . . . . . . . . . . . . 15
2.7. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . . . 14 2.7. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . . . 15
2.8. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . . .14 2.8. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . . .15
2.9. Inter-domain Routes . . . . . . . . . . . . . . . . . . . . . . 14 2.9. Inter-domain Routes . . . . . . . . . . . . . . . . . . . . . . 15
2.10. Reservations for Multicast Sessions . . . . . . . . . . . . . . 14 2.10. Reservations for Multicast Sessions . . . . . . . . . . . . . . 15
2.11. Multi-level Aggregation . . . . . . . . . . . . . . . . . . . . 15 2.11. Multi-level Aggregation . . . . . . . . . . . . . . . . . . . . 15
2.12. Reliability Issues . . . . . . . . . . . . . . . . . . . . . . 15 2.12. Reliability Issues . . . . . . . . . . . . . . . . . . . . . . 15
2.13. Message Integrity and Node Authentication . . . . . . . . . . 15 2.13. Message Integrity and Node Authentication . . . . . . . . . . 16
3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . . 15 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Receipt of E2E Path Message By PCN-ingress-node 3.1. Receipt of E2E Path Message By PCN-ingress-node
(aggregating router) . . . . . . . . . . . . . . . . . . . . . . 15 (aggregating router) . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Handling Of E2E Path Message By Interior Routers . . . . . . . 16 3.2. Handling Of E2E Path Message By Interior Routers . . . . . . . 17
3.3. Receipt of E2E Path Message By PCN-egress-node 3.3. Receipt of E2E Path Message By PCN-egress-node
(deaggregating router) . . . . . . . . . . . . . . . . . . . . . 16 (deaggregating router) . . . . . . . . . . . . . . . . . . . . . 17
3.4. Initiation of new Aggregate Path Message By PCN-ingress-node 3.4. Initiation of new Aggregate Path Message By PCN-ingress-node
(Aggregating Router) . . . . . . . . . . . . . . . . . . . . . 17 (Aggregating Router) . . . . . . . . . . . . . . . . . . . . . 18
3.5. Handling Of new Aggregate Path Message By Interior Routers . . 17 3.5. Handling Of new Aggregate Path Message By Interior Routers . . 18
3.6. Handling of E2E Resv Message by Deaggregating Router . . . . . 17 3.6. Handling of E2E Resv Message by Deaggregating Router . . . . . 18
3.7. Handling Of E2E Resv Message By Interior Routers . . . . . . . 17 3.7. Handling Of E2E Resv Message By Interior Routers . . . . . . . 18
3.8. Initiation of New Aggregate Resv Message By Deaggregating Router 17 3.8. Initiation of New Aggregate Resv Message By Deaggregating Router 19
3.9. Handling of Aggregate Resv Message by Interior Routers . . . . 18 3.9. Handling of Aggregate Resv Message by Interior Routers . . . . 18
3.10. Handling of E2E Resv Message by Aggregating Router . . . . . . 18 3.10. Handling of E2E Resv Message by Aggregating Router . . . . . . 19
3.11. Handling of Aggregated Resv Message by Aggregating Router . . 18 3.11. Handling of Aggregated Resv Message by Aggregating Router . . 19
3.12. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 19 3.12. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 20
3.13. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 19 3.13. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 20
3.14. Handling of Data On Reserved E2E Flow by Aggregating Router . 19 3.14. Handling of Data On Reserved E2E Flow by Aggregating Router . 20
3.15. Procedures for Multicast Sessions . . . . . . . . . . . . . . 19 3.15. Procedures for Multicast Sessions . . . . . . . . . . . . . . 21
3.16. Misconfiguration of PCN node . . . . . . . . . . . . . . . . 19 3.16. Misconfiguration of PCN node . . . . . . . . . . . . . . . . 21
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 20 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Normative References . . . . . . . . . . . . . . . . . . . . . . 25 8. Normative References . . . . . . . . . . . . . . . . . . . . . . 27
9. Informative References . . . . . . . . . . . . . . . . . . . . . 26 9. Informative References . . . . . . . . . . . . . . . . . . . . . 27
10. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 27 10. Appendix A: Example Signaling Flow . . . . . . . . . . . . . . . 28
11. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
1.1 Objective 1.1 Objective
Pre-Congestion Notification (PCN) can support the quality of service Pre-Congestion Notification (PCN) can support the quality of service
(QoS) of inelastic flows within a Diffserv domain in a simple, (QoS) of inelastic flows within a Diffserv domain in a simple,
scalable, and robust fashion. Two mechanisms are used: admission scalable, and robust fashion. Two mechanisms are used: admission
control and flow termination. Admission control is used to decide control and flow termination. Admission control is used to decide
whether to admit or block a new flow request, while flow termination whether to admit or block a new flow request, while flow termination
is used in abnormal circumstances to decide whether to terminate some is used in abnormal circumstances to decide whether to terminate some
skipping to change at page 4, line 28 skipping to change at page 4, line 28
thus providing notification to boundary nodes about overloads before thus providing notification to boundary nodes about overloads before
any congestion occurs (hence "pre-congestion" notification). The any congestion occurs (hence "pre-congestion" notification). The
PCN-egress-nodes measure the rates of differently marked PCN traffic PCN-egress-nodes measure the rates of differently marked PCN traffic
in periodic intervals and report these rates to the Decision Points in periodic intervals and report these rates to the Decision Points
for admission control and flow termination; the Decision Points use for admission control and flow termination; the Decision Points use
these rates to make decisions. The Decision Points may be collocated these rates to make decisions. The Decision Points may be collocated
with the PCN-ingress-nodes, or their function may be implemented in a with the PCN-ingress-nodes, or their function may be implemented in a
centralized node. For more details see [RFC5559], [RFC6661], and centralized node. For more details see [RFC5559], [RFC6661], and
[RFC6662]. [RFC6662].
The main objective of this document is to specify the signalling The main objective of this document is to specify the signaling
protocol that can be used within a Pre-Congestion Notification (PCN) protocol that can be used within a Pre-Congestion Notification (PCN)
domain to carry reports from a PCN-egress-node to a PCN Decision domain to carry reports from a PCN-egress-node to a PCN Decision
point, considering that the PCN decision Point and PCN-ingress-node point, considering that the PCN decision Point and PCN-ingress-node
are collocated. are collocated.
If the PCN decision point is not collocated with the PCN-ingress-node If the PCN decision point is not collocated with the PCN-ingress-node
then additional signalling procedures are required that are out of then additional signaling procedures are required that are out of
the scope of this document. Moreover, as mentioned above this the scope of this document. Moreover, as mentioned above this
architecture conforms with PBAC when decision point is located in a architecture conforms with PBAC (Policy-Based Admission Control),
centralized node [RFC2753]. when decision point is located in a centralized node [RFC2753].
Several signaling protocols can be used to carry reports from a PCN- Several signaling protocols can be used to carry reports from a PCN-
egress-node to a PCN-ingress-nodes. However, since both PCN-egress- egress-node to a PCN-ingress-nodes. However, since both PCN-egress-
node and PCN-ingress-nodes are located on the data path, a signaling node and PCN-ingress-nodes are located on the data path, a signaling
protocol that follows the same path as the data path, like RSVP protocol that follows the same path as the data path, like RSVP
(Resource Reservation Protocol), is more suited for this purpose. In (Resource Reservation Protocol), is more suited for this purpose. In
particular, this document specifies extensions to Generic particular, this document specifies extensions to Generic
Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL)
and Single Marking (SM) edge behaviors over a Diffserv cloud using and Single Marking (SM) edge behaviors over a Diffserv cloud using
Pre-Congestion Notification. Pre-Congestion Notification.
skipping to change at page 5, line 32 skipping to change at page 5, line 32
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 over
Diffserv [RFC2998] including resource-based admission control (RBAC), Diffserv [RFC2998] including resource-based admission control (RBAC),
policy-based admission control (PBAC), assistance in traffic PBAC, assistance in traffic identification/classification, and
identification/classification, and traffic conditioning. traffic conditioning. Intserv over Diffserv can operate over a
Intserv over Diffserv can operate over a statically provisioned statically provisioned Diffserv region or RSVP aware. When it is RSVP
Diffserv region or RSVP aware. When it is RSVP aware, several aware, several mechanisms may be used to support dynamic provisioning
mechanisms may be used to support dynamic provisioning and topology- and topology-aware admission control, including aggregate RSVP
aware admission control, including aggregate RSVP reservations, per- reservations, per-flow RSVP, or a bandwidth broker. [RFC3175]
flow RSVP, or a bandwidth broker. specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-
[RFC3175] specifies aggregation of Resource ReSerVation end reservations over aggregate RSVP reservations. In [RFC3175] the
Protocol (RSVP) end-to-end reservations over aggregate RSVP RSVP aggregated reservation is characterized by a RSVP SESSION object
reservations. In [RFC3175] the RSVP aggregated reservation is using the 3-tuple <source IP address, destination IP address,
characterized by a RSVP SESSION object using the 3-tuple <source IP Diffserv Code Point>.
address, destination IP address, Diffserv Code Point>.
Several scenarios require the use of multiple generic aggregate Several scenarios require the use of multiple generic aggregate
reservations that are established for a given PHB from a given source reservations that are established for a given PHB from a given source
IP address to a given destination IP address, see [SIG-NESTED], IP address to a given destination IP address, see [SIG-NESTED],
[RFC4860]. For example, multiple generic aggregate reservations [RFC4860]. For example, multiple generic aggregate reservations
can be applied in the situation that multiple e2e reservations using can be applied in the situation that multiple e2e reservations using
different preemption priorities need to be aggregated through a PCN- different preemption priorities need to be aggregated through a PCN-
domain using the same PHB. By using multiple aggregate reservations domain using the same PHB. By using multiple aggregate reservations
for the same PHB allows enforcement of the different preemption for the same PHB allows enforcement of the different preemption
priorities within the aggregation region. This allows more efficient priorities within the aggregation region. This allows more efficient
skipping to change at page 6, line 22 skipping to change at page 6, line 22
in the RSVP SESSION object. In addition to this, the RSVP SESSION in the RSVP SESSION object. In addition to this, the RSVP SESSION
object for generic aggregate reservations uses the PHB Identification object for generic aggregate reservations uses the PHB Identification
Code (PHB-ID) defined in [RFC3140], instead of using the Diffserv Code (PHB-ID) defined in [RFC3140], instead of using the Diffserv
Code Point (DSCP) used in [RFC3175]. The PHB-ID is used to identify Code Point (DSCP) used in [RFC3175]. The PHB-ID is used to identify
the PHB, or set of PHBs, from which the Diffserv resources are to be the PHB, or set of PHBs, from which the Diffserv resources are to be
reserved. reserved.
The RSVP like signaling protocol required to carry reports from a The RSVP like signaling protocol required to carry reports from a
PCN-egress-node to a PCN-ingress-node needs to follow the PCN PCN-egress-node to a PCN-ingress-node needs to follow the PCN
signaling requirements defined in [RFC6663]. In addition to signaling requirements defined in [RFC6663]. In addition to
that the signalling protocol functionality supported by the PCN- that the signaling protocol functionality supported by the PCN-
ingress-nodes and PCN-egress-nodes needs to maintain logical ingress-nodes and PCN-egress-nodes needs to maintain logical
aggregate constructs (i.e. ingress-egress-aggregate state) and be aggregate constructs (i.e. ingress-egress-aggregate state) and be
able to map e2e reservations to these aggregate constructs. Moreover, able to map e2e reservations to these aggregate constructs. Moreover,
no actual reservation state is needed to be maintained inside the PCN no actual reservation state is needed to be maintained inside the PCN
domain, i.e., the PCN-interior-nodes are not maintaining any domain, i.e., the PCN-interior-nodes are not maintaining any
reservation state. reservation state.
This can be accomplished by two possible approaches: This can be accomplished by two possible approaches:
Approach (1): Approach (1):
skipping to change at page 7, line 10 skipping to change at page 7, line 10
o) hence not performing aggregate RSVP signaling o) hence not performing aggregate RSVP signaling
o) piggy-backing of the PCN information inside the e2e RSVP o) piggy-backing of the PCN information inside the e2e RSVP
signaling. signaling.
Both approaches are probably viable, however, since the RFC 4860 Both approaches are probably viable, however, since the RFC 4860
operations have been thoroughly studied and implemented, it can be operations have been thoroughly studied and implemented, it can be
considered that the RFC 4860 solution can better deal with the more considered that the RFC 4860 solution can better deal with the more
challenging situations (rerouting in the PCN domain, failure of an challenging situations (rerouting in the PCN domain, failure of an
PCN-ingress-node, failure of an PCN-egress-node, rerouting towards a PCN-ingress-node, failure of an PCN-egress-node, rerouting towards a
different edge, etc.). This is also the reason of choosing Approach different edge, etc.). This is the reason for choosing Approach (1)
(1) for the specification of the signaling protocol used to carry PCN for the specification of the signaling protocol used to carry
information from the PCN-egress-node to the PCN-ingress-node. PCN information from the PCN-egress-node to the PCN-ingress-node.
In particular, this document specifies extensions to Generic In particular, this document specifies extensions to Generic
Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL)
and Single Marking (SM) edge behaviors over a Diffserv cloud using and Single Marking (SM) edge behaviors over a Diffserv cloud using
Pre-Congestion Notification. Pre-Congestion Notification.
This document follows the PCN signaling requirements defined in This document follows the PCN signaling requirements defined in
[RFC6663] and specifies extensions to Generic Aggregated RSVP [RFC6663] and specifies extensions to Generic Aggregated RSVP
[RFC4860] for support of PCN edge behaviors as specified in [RFC4860] for support of PCN edge behaviors as specified in
[RFC6661] and [RFC6662]. Moreover, this document specifies how RSVP [RFC6661] and [RFC6662]. Moreover, this document specifies how RSVP
skipping to change at page 7, line 49 skipping to change at page 7, line 49
For readability, a number of definitions from [RFC3175] as well as For readability, a number of definitions from [RFC3175] as well as
definitions for terms used in [RFC5559], [RFC6661], and [RFC6662] are definitions for terms used in [RFC5559], [RFC6661], and [RFC6662] are
provided here, where some of them are augmented with new meanings: provided here, where some of them are augmented with new meanings:
Aggregator This is the process in (or associated with) the Aggregator This is the process in (or associated with) the
router at the ingress edge of the aggregation region router at the ingress edge of the aggregation region
(with respect to the end-to-end RSVP reservation) (with respect to the end-to-end RSVP reservation)
and behaving in accordance with [RFC4860]. In this and behaving in accordance with [RFC4860]. In this
document, it is also the PCN-ingress-node and the document, it is also the PCN-ingress-node and the
decision point. decision point. It is important to notice that in
the context of this document the Aggregator MUST be
able to determine the Deaggregator using the
procedures specified in Section 4 of [RFC4860] and
in Section 1.4.2 of [RFC3175].
Deaggregator This is the process in (or associated with) the Deaggregator This is the process in (or associated with) the
router at the egress edge of the aggregation region router at the egress edge of the aggregation region
(with respect to the end-to-end RSVP reservation) (with respect to the end-to-end RSVP reservation)
and behaving in accordance with [RFC4860]. In this and behaving in accordance with [RFC4860]. In this
document, it is also the PCN-egress-node. document, it is also the PCN-egress-node.
E2E (or e2e) end to end E2E (or e2e) end to end
E2E Reservation This is an RSVP reservation such that: E2E Reservation This is an RSVP reservation such that:
skipping to change at page 8, line 26 skipping to change at page 8, line 32
(iii) this RSVP reservation is aggregated over an (iii) this RSVP reservation is aggregated over an
Ingress Egress Aggregate (IEA) between the Ingress Egress Aggregate (IEA) between the
Aggregator and Deaggregator. Aggregator and Deaggregator.
An E2E RSVP reservation may be a per-flow An E2E RSVP reservation may be a per-flow
reservation, which in this document is only reservation, which in this document is only
maintained at the PCN-ingress-node and PCN-egress- maintained at the PCN-ingress-node and PCN-egress-
node. Alternatively, the E2E reservation may itself node. Alternatively, the E2E reservation may itself
be an aggregate reservation of various types (e.g., be an aggregate reservation of various types (e.g.,
Aggregate IP reservation, Aggregate IPsec Aggregate IP reservation, Aggregate IPsec
reservation, see [RFC4860]). As per regular RSVP reservation, see [RFC4860]). As per regular RSVP
operations, E2E RSVP reservations are operations, E2E RSVP reservations are
unidirectional. unidirectional.
PHB-ID (Per Hop Behavior Identification Code) 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 of the PHB, or of the set of Identification Code 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 are to be reserved. This field MUST be encoded as
specified in Section 2 of [RFC3140]. specified in Section 2 of [RFC3140].
skipping to change at page 8, line 49 skipping to change at page 8, line 55
A 16-bit identifier used in the SESSION that A 16-bit identifier used in the SESSION that
remains constant over the life of the generic remains constant over the life of the generic
aggregate reservation. aggregate reservation.
Extended vDstPort (Extended Virtual Destination Port) Extended vDstPort (Extended Virtual Destination Port)
An identifier used in the SESSION that remains An identifier used in the SESSION that remains
constant over the life of the generic aggregate constant over the life of the generic aggregate
reservation. The length of this idenitifier is 32- reservation. The length of this idenitifier is 32-
bits when IPv4 addresses are used and 128 bits when bits when IPv4 addresses are used and 128 bits when
IPv6 addresses are used. A sender(or Aggregator) IPv6 addresses are used.
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 A sender(or Aggregator) that wishes to narrow the
contain the IPv4 or IPv6 address of the Aggregator. 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.
PCN-domain: a PCN-capable domain; a contiguous set of PCN-domain: a PCN-capable domain; a contiguous set of
PCN-enabled nodes that perform Diffserv scheduling PCN-enabled nodes that perform Diffserv scheduling
[RFC2474]; the complete set of PCN-nodes that in [RFC2474]; the complete set of PCN-nodes that in
principle can, through PCN-marking packets, principle can, through PCN-marking packets,
influence decisions about flow admission and influence decisions about flow admission and
termination for the PCN-domain; includes termination for the PCN-domain; includes
the PCN-egress-nodes, which measure these the PCN-egress-nodes, which measure these
PCN-marks, and the PCN-ingress-nodes. PCN-marks, and the PCN-ingress-nodes.
PCN-boundary-node: a PCN-node that connects one PCN-domain to a node PCN-boundary-node: a PCN-node that connects one PCN-domain to a node
either in another PCN-domain or in a non-PCN-domain. either in another PCN-domain or in a non-PCN-domain.
PCN-interior-node: a node in a PCN-domain that is not a PCN- PCN-interior-node: a node in a PCN-domain that is not a PCN-
boundary-node. boundary-node.
PCN-node: a PCN-boundary-node or a PCN-interior-node. PCN-node: a PCN-boundary-node or a PCN-interior-node.
PCN-egress-node: a PCN-boundary-node in its role in handling PCN-egress-node: a PCN-boundary-node in its role in handling
traffic as it leaves a PCN-domain. traffic as it leaves a PCN-domain. In this
document the PCN-ingress-node operates also as a
deaggregator.
PCN-ingress-node: a PCN-boundary-node in its role in handling PCN-ingress-node: a PCN-boundary-node in its role in handling
traffic as it enters a PCN-domain. In this traffic as it enters a PCN-domain. In this
document the PCN-ingress-node operates also as a document the PCN-ingress-node operates also as a
Decision Point and aggregator. Decision Point and aggregator.
PCN-traffic, PCN-traffic,
PCN-packets, PCN-packets,
PCN-BA: a PCN-domain carries traffic of different Diffserv PCN-BA: a PCN-domain carries traffic of different Diffserv
behavior aggregates (BAs) [RFC2474]. The PCN-BA behavior aggregates (BAs) [RFC2474]. The PCN-BA
skipping to change at page 12, line 24 skipping to change at page 12, line 36
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 RSVP Reservations over Generic Aggregate RSVP Reservations
in PCN domains, based on [RFC4860] in PCN domains, based on [RFC4860]
Moreover, each Aggregator and Deaggregator (i.e., PCN-boundary-nodes) Moreover, each Aggregator and Deaggregator (i.e., PCN-boundary-nodes)
MUST support policies to initiate and maintain for each pair of MUST support policies to initiate and maintain for each pair of
PCN-boundary-nodes of the same PCN-domain (1) one ingress-egress- PCN-boundary-nodes of the same PCN-domain one ingress-egress-
aggregate and (2) either one or more RSVP generic aggregated aggregate. Both the Aggregator and Deaggregator can maintain one or
reservations. Note that one RSVP generic aggregated reservation more RSVP generic aggregated Reservations, but the Deaggregator is
matches to only one ingress-egress-aggregate, while one ingress- the entity that initiates these RSVP generic aggregated reservations.
egress-aggregate matches to either one or to more than one RSVP Note that one RSVP generic aggregated reservation matches to only
generic aggregated reservations. This can be accomplished by using one ingress-egress-aggregate, while one ingress-egress-aggregate
for the different RSVP generic aggregated reservations the same matches to either one or to more than one RSVP generic aggregated
combinations of ingress and egress identifiers, but with a different reservations. This can be accomplished by using for the different
PHB-ID value (see [RFC4860]). The procedures for aggregation of E2E RSVP generic aggregated reservations the same combinations of
reservations over generic aggregate RSVP reservations are the same as ingress and egress identifiers, but with a different PHB-ID value
the procedures specified in Section 4 of [RFC4860]. (see [RFC4860]). The procedures for aggregation of E2E reservations
over generic aggregate RSVP reservations are the same as the
Depending on a policy the Aggregator MUST be able to decide whether procedures specified in Section 4 of [RFC4860], augmented with the
an e2e microflow (i.e., PCN-flow) can be mapped into (1) one RSVP following ones, see also Section 2.5:
generic aggregated reservation and (2) one ingress-egress-aggregate
maintained by the Aggregator (i.e., PCN-ingress-node). Note that each
RSVP generic aggregated reservation is identified by using the RSVP
SESSION object [RFC4860]. The RSVP SESSION object for generic
aggregate reservations is based on the RSVP SESSION object specified
in [RFC4860] augmented with the following information:
o) the IPv4 DestAddress, IPv6 DestAddress MUST be set to the IPv4
or IPv6 destination addresses, respectively, of the Deaggregator
(PCN-egress-node), see [RFC4860]. Note that the PCN-domain is
considered as being only one RSVP hop (for Generic aggregated
RSVP or e2e RSVP). This means that the next RSVP hop for the
Aggregator in the downstream direction is the Deaggregator and
the next RSVP hop for the Deaggregator in the upstream direction
is the Aggregator. Furthermore, it is considered that for the
determination of the Deaggregator, the same methods can be used
as the ones described in Section 4 of [RFC4860].
o) PHB-ID (Per Hop Behavior Identification Code) SHOULD be set equal o) Aggregator (PCN-ingress-node) and Deaggregator (PCN-egress-node)
to PCN-compatible Diffserv codepoint(s). MUST be able to determine, for each received e2e Path message, in
which ingress-egress-aggregate it can be mapped to.
o) Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination o) Depending on policies the Aggregator and Deaggregator MUST be able
addresses, of the Aggregator (PCN-ingress-node), see [RFC4860]. to decide whether a RSVP generic aggregate reservations can be
mapped into an ingress-egress-aggregate, see Section 2.5 for more
details.
2.2 PCN Marking and encoding and transport of pre-congestion 2.2 PCN Marking and encoding and transport of pre-congestion
information information
The method of PCN marking within the PCN domain is based on The method of PCN marking within the PCN domain is based on
[RFC5670]. In addition, the method of encoding and transport of pre- [RFC5670]. In addition, the method of encoding and transport of pre-
congestion information is based [RFC6660]. The PHB-ID (Per Hop congestion information is based [RFC6660]. The PHB-ID (Per Hop
Behavior Identification Code) used SHOULD be set equal Behavior Identification Code) used SHOULD be set equal
to PCN-compatible Diffserv codepoint(s). to PCN-compatible Diffserv codepoint(s).
skipping to change at page 13, line 53 skipping to change at page 13, line 45
microflows) belonging to a RSVP generic aggregated reservation can be microflows) belonging to a RSVP generic aggregated reservation can be
classified only at the PCN-boundary-nodes (i.e., Aggregator and classified only at the PCN-boundary-nodes (i.e., Aggregator and
Deaggregator) by using the RSVP SESSION object for RSVP generic Deaggregator) by using the RSVP SESSION object for RSVP generic
aggregated reservations, see Section 2.1 of [RFC4860]. It is aggregated reservations, see Section 2.1 of [RFC4860]. It is
considered that tunnels need to be used between Aggregators and considered that tunnels need to be used between Aggregators and
Deaggregators, using the same procedures as specified in Section 4 of Deaggregators, using the same procedures as specified in Section 4 of
[RFC4860]. [RFC4860].
2.4. Deaggregator (PCN-egress-node) Determination 2.4. Deaggregator (PCN-egress-node) Determination
To comply with this specification it is considered that to determine To comply with this specification it is considered that in order to
the Deaggregator, the same methods can be used as the ones described determine the Deaggregator, the same methods can be used as the ones
in Section 4 of [RFC4860]. described in Section 4 of [RFC4860] and in Section 1.4.2 of
[RFC3175]. In the context of this document this can be determined
very easily, since from the point of RSVP, the next RSVP hop for the
Aggregator in the downstream direction is the Deaggregator and the
next RSVP hop for the Deaggregator in the upstream direction is the
Aggregator.
2.5. Mapping E2E Reservations Onto Aggregate Reservations 2.5. Mapping E2E Reservations Onto Aggregate Reservations
To comply with this specification it is considered that for the To comply with this specification it is considered that for the
mapping of e2e reservations onto aggregate reservations, the same mapping of e2e reservations onto aggregate reservations, the same
methods can be used as the ones described in Section 4 of [RFC4860], methods can be used as the ones described in Section 4 of [RFC4860],
augmented by the following rules: augmented by the following rules:
o) PCN-ingress-node MUST use one or more policies to determine o) An Aggregator (PCN-ingress-node) MUST be able to determine for
whether an e2e RSVP reservation session associated with an e2e each e2e Path message that arrives at its external interface in
Path message that arrives at the external interface of the PCN- which ingress-egress-aggregate it can be mapped to. This is
ingress-node can be mapped onto an existing RSVP generic possible, see also Section 2.4, since from the point of RSVP, the
aggregation reservation state. Deaggregator (PCN-egress-node) is one RSVP hop away from the
Aggregator (PCN-ingress-node). The Aggregator (PCN-ingress-node)
uses PCN related information sent by the Deaggregator to
map RSVP generic aggregated states to ingress-egress-aggregates.
o) A PCN-ingress-node (Aggregator) or PCN-egress-node (Deaggregator)
MUST use one or more policies to determine whether a RSVP generic
aggregated reservation can be mapped into an ingress-egress-
aggregate. Note that one RSVP generic aggregated reservation
matches to only one ingress-egress-aggregate, while one ingress-
egress-aggregate matches to either one or to more than one RSVP
generic aggregated reservations. The Aggregator or the
Deaggregator MUST be able to map RSVP generic aggregated
reservations into ingress-egress-aggregates. This can be
accomplished by using for the different RSVP generic aggregated
reservations the same combinations of ingress and egress
identifiers, but with a different PHB-ID value (see [RFC4860]). In
particular, each RSVP generic aggregated reservation is identified
by using the RSVP SESSION object [RFC4860]. The RSVP SESSION
object for generic aggregate reservations is based on the RSVP
SESSION object specified in [RFC4860] augmented with the following
information:
o) the IPv4 DestAddress, IPv6 DestAddress MUST be set to the IPv4
or IPv6 destination addresses, respectively, of the
Deaggregator (PCN-egress-node), see [RFC4860]. Note that the
PCN-domain is considered as being only one RSVP hop (for
Generic aggregated RSVP or e2e RSVP). This means that the next
RSVP hop for the Aggregator in the downstream direction is the
Deaggregator and the next RSVP hop for the Deaggregator in the
upstream direction is the Aggregator.
o) PHB-ID (Per Hop Behavior Identification Code) SHOULD be set
equal to PCN-compatible Diffserv codepoint(s).
o) Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination
addresses, of the Aggregator (PCN-ingress-node), see [RFC4860].
2.6. Size of Aggregate Reservations 2.6. Size of Aggregate Reservations
To comply with this specification it is considered that for the To comply with this specification it is considered that for the
determination of the size of the RSVP generic aggregate reservations, determination of the size of the RSVP generic aggregate reservations,
the same methods can be used as the ones described in [RFC4860] and the same methods can be used as the ones described in [RFC4860] and
Section 1.4.4. of [RFC3175]. Section 1.4.4. of [RFC3175].
2.7. E2E Path ADSPEC update 2.7. E2E Path ADSPEC update
skipping to change at page 15, line 39 skipping to change at page 16, line 25
procedures for aggregation of e2e reservations over generic aggregate procedures for aggregation of e2e reservations over generic aggregate
RSVP reservations are same as the procedures specified in Section RSVP reservations are same as the procedures specified in Section
4 of [RFC4860]. Please refer to [RFC4860] for all the below error 4 of [RFC4860]. Please refer to [RFC4860] for all the below error
cases: cases:
*) Incomplete message *) Incomplete message
*) Unexpected objects *) Unexpected objects
3.1. Receipt of E2E Path Message By PCN-ingress-node (aggregating 3.1. Receipt of E2E Path Message By PCN-ingress-node (aggregating
router) router)
When the e2e RSVP message arrives at the exterior interface of the When the e2e Path message arrives at the exterior interface of the
Aggregator, i.e., PCN-ingress-node, then standard RSVP generic Aggregator, i.e., PCN-ingress-node, then standard RSVP generic
aggregation [RFC4860] procedures are used, augmented with the aggregation [RFC4860] procedures are used, augmented with the
following rules: following rules:
o) The e2e RSVP reservation session associated with an e2e Path o) The e2e RSVP reservation session associated with an e2e Path
message that arrives at the external interface of the PCN- message that arrives at the external interface of the PCN-
ingress-node is mapped/matched onto an existing RSVP generic ingress-node is mapped/matched onto an PCN ingress-egress-
aggregation reservation state. aggregate.
o) If the timer t-recvFail does NOT expire for a given PCN-egress-
node, then: o) If the timer t-recvFail does NOT expire for a given PCN-egress-
node, then:
o) If (1) the PCN-admission state for the ingress-egress- o) If (1) the PCN-admission state for the ingress-egress-
aggregate associated with the received e2e Path and (2) the aggregate associated with the received e2e Path is "admit",
state for the selected RSVP generic aggregated reservation, the Decision Point (i.e., PCN-ingress-node) SHOULD allow the
see [RFC4860], are "admit", the Decision Point (i.e., PCN- new flow to be admitted to that PCN ingress-egress-
ingress-node) SHOULD allow the new flow to be admitted to aggregate, see [RFC6661] and [RFC6662]. The e2e Path message
that RSVP generic aggregated reservation, see [RFC6661] and is then forwarded towards destination.
[RFC6662]. The e2e Path message is then forwarded towards
destination.
o) If for the same ingress-egress-aggregate and the same RSVP o) If for the same PCN ingress-egress-aggregate
generic aggregated reservation (1) the PCN-admission- the PCN-admission-state is "block", the request SHOULD NOT
state and/or (2) the state for the RSVP generic aggregated be admitted by the PCN-ingress-node (Aggregator) and an e2e
reservation are/is "block", the flow SHOULD NOT be PathErr message SHOULD be generated, using standard e2e RSVP
admitted by the Aggregator and an e2e PathErr message SHOULD procedures [RFC4495]. This e2e PathErr message is sent to
be generated, using standard e2e RSVP procedures the originating sender of the e2e Path message, using
[RFC4495]. This e2e PathErr message is sent to the standard e2e RSVP procedures [RFC2205], [RFC4495]. This e2e
originating sender of the e2e Path message, using standard PathErr message is sent to the originating sender of the e2e
e2e RSVP procedures [RFC2205], [RFC4495]. This e2e PathErr Path message. The e2e RSVP error code "01: Admission Control
message is sent to the originating sender of the e2e Path
message. The e2e RSVP error code "01: Admission Control
failure" and the "Sub-code = 2: Requested bandwidth failure" and the "Sub-code = 2: Requested bandwidth
unavailable " specified in Appendix B of [RFC2205] SHOULD be unavailable " specified in Appendix B of [RFC2205] SHOULD be
used for this purpose. used for this purpose.
o) If the timer t-recvFail expires for a given PCN-egress-node, the When the originating sender receives this e2e PathErr
Decision Point (i.e., PCN-ingress-node) SHOULD NOT message it SHOULD apply a PCN specific policy to generate an
allow the e2e microflow (i.e., PCN-flow) to be admitted to that e2e PathTear message to release all the possible Path states
RSVP generic aggregated reservation (which is matched to one initiated on the e2e RSVP aware nodes on the path towards
ingress-egress-aggregate), see [RFC6661], [RFC6662]. The the PCN-ingress-node (Aggregator).
admission or rejection procedure of a PCN-flow into the PCN-
domain is defined in detail in: [RFC6661] and [RFC6662]. o) If the timer t-recvFail expires for a given PCN-egress-node, the
If the Aggregator is not able to admit the e2e microflow it Decision Point (i.e., PCN-ingress-node) SHOULD NOT
SHOULD then generate an e2e PathErr message using standard e2e allow the e2e microflow (i.e., PCN-flow) to be admitted to that
RSVP procedures [RFC4495]. This e2e PathErr message is sent to PCN ingress-egress-aggregate, see [RFC6661], [RFC6662]. The
the originating sender of the e2e Path message. The e2e RSVP admission or rejection procedure of a PCN-flow into the PCN-
error code "01: Admission Control failure" and the "Sub-code = domain is defined in detail in: [RFC6661] and [RFC6662].
2: Requested bandwidth unavailable " specified in Appendix B of If the Aggregator is not able to admit the e2e microflow it
[RFC2205] SHOULD be used for this purpose. SHOULD then generate an e2e PathErr message using standard e2e
RSVP procedures [RFC4495]. This e2e PathErr message is sent to
the originating sender of the e2e Path message. The e2e RSVP
error code "01: Admission Control failure" and the "Sub-code =
2: Requested bandwidth unavailable " specified in Appendix B of
[RFC2205] SHOULD be used for this purpose. When the originating
sender receives this e2e PathErr message it SHOULD apply a PCN
specific policy to generate an e2e PathTear message to release all
the possible Path states initiated on the e2e RSVP aware nodes on
the path towards the PCN-ingress-node (Aggregator).
The way of how the PCN-admission-state is maintained is specified in The way of how the PCN-admission-state is maintained is specified in
[RFC6661] and [RFC6662]. The way of how the RSVP generic aggregated [RFC6661] and [RFC6662]. The way of how the RSVP generic aggregated
reservation state is maintained is specified in [RFC4860]. reservation state is maintained is specified in [RFC4860].
3.2. Handling Of E2E Path Message By Interior Routers 3.2. Handling Of E2E Path Message By Interior Routers
The e2e Path messages traverse zero or more PCN-interior-nodes. The e2e Path messages traverse zero or more PCN-interior-nodes.
The PCN-interior-nodes receive the e2e Path message on an interior The PCN-interior-nodes receive the e2e Path message on an interior
interface and forward it on another interior interface. It is interface and forward it on another interior interface. It is
considered that by configuration the PCN-interior-nodes are not able considered that by configuration the PCN-interior-nodes are not able
to distinguish neither e2e RSVP sessions and their associated to distinguish neither e2e RSVP sessions and their associated
messages [RFC2205]. Therefore, the e2e Path messages are simply messages [RFC2205]. Therefore, the e2e Path messages are simply
forwarded as normal IP datagrams. forwarded as normal IP datagrams.
3.3. Receipt of E2E Path Message By PCN-egress-node (deaggregating 3.3. Receipt of E2E Path Message By PCN-egress-node (Deaggregating
router) router)
When receiving the e2e Path message the PCN-egress-node When receiving the e2e Path message the PCN-egress-node
(Deaggregator) performs main regular [RFC4860] procedures, augmented (Deaggregator) performs main regular [RFC4860] procedures, augmented
with the following rules, see also [draft-lefaucheur-rsvp-ecn-01]: with the following rules:
o) The PCN-egress-node MUST NOT perform the RSVP-TTL vs IP TTL- o) The PCN-egress-node MUST NOT perform the RSVP-TTL vs IP TTL-
check and MUST NOT update the ADspec Break bit. This is because check and MUST NOT update the ADspec Break bit. This is because
the whole PCN-domain is effectively handled by e2e RSVP as a the whole PCN-domain is effectively handled by e2e RSVP as a
virtual link on which integrated service is indeed supported virtual link on which integrated service is indeed supported
(and admission control performed) so that the Break bit MUST (and admission control performed) so that the Break bit MUST
NOT be set. NOT be set, see also [draft-lefaucheur-rsvp-ecn-01].
o) If the Deaggregator does not maintain any RSVP generic
aggregated reservation states, then one or more of such states
are created during this step. Moreover, also at this step
the Deaggregator maps the new generated RSVP generic
aggregated reservations onto one ingress-egress-aggregate
maintained by the Deaggregator (PCN-egress-node), see Section
2.5.
The PCN-egress-nodes forwards the e2e Path message towards the The PCN-egress-nodes forwards the e2e Path message towards the
receiver. receiver.
3.4. Initiation of new Aggregate Path Message By PCN-ingress-node 3.4. Initiation of new Aggregate Path Message By PCN-ingress-node
(Aggregating Router) (Aggregating Router)
To comply with this specification it is considered that for the To comply with this specification it is considered that for the
initiation of the new RSVP aggregated Path message by the PCN- initiation of the new RSVP aggregated Path message by the PCN-
ingress-node (Aggregator), the same methods can be used as the ones ingress-node (Aggregator), the same methods can be used as the ones
skipping to change at page 17, line 37 skipping to change at page 18, line 38
interface and forward it on another interior interface. interface and forward it on another interior interface.
It is considered that by configuration, the PCN-interior-nodes are It is considered that by configuration, the PCN-interior-nodes are
not able to distinguish neither RSVP generic aggregated sessions and not able to distinguish neither RSVP generic aggregated sessions and
their associated messages [RFC4860]. Therefore, the Aggregated Path their associated messages [RFC4860]. Therefore, the Aggregated Path
messages are simply forwarded as normal IP datagrams. messages are simply forwarded as normal IP datagrams.
3.6. Handling of E2E Resv Message by Deaggregating Router 3.6. Handling of 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, i.e., PCN-egress-node, then standard RSVP Deaggregator, i.e., PCN-egress-node, then standard RSVP
aggregation [RFC4860] procedures are used. aggregation [RFC4860] procedures are used. It is important to be
noticed that according to [RFC4860] the Deaggregator is responsible
of performing admission control of the E2E RESV onto the generic
aggregate reservation.
3.7. Handling Of E2E Resv Message By Interior Routers 3.7. Handling Of E2E Resv Message By Interior Routers
The e2e Resv messages traverse zero or more PCN-interior-nodes. The The e2e Resv messages traverse zero or more PCN-interior-nodes. The
PCN-interior-nodes receive the e2e Resv message on an interior PCN-interior-nodes receive the e2e Resv message on an interior
interface and forward it on another interior interface. It is interface and forward it on another interior interface. It is
considered that by configuration the PCN-interior-nodes are not able considered that by configuration the PCN-interior-nodes are not able
to distinguish neither e2e RSVP sessions and their associated to distinguish neither e2e RSVP sessions and their associated
messages [RFC2205]. Therefore, the e2e Resv messages are simply messages [RFC2205]. Therefore, the e2e Resv messages are simply
forwarded as normal IP datagrams. forwarded as normal IP datagrams.
skipping to change at page 18, line 49 skipping to change at page 20, line 4
aggregation [RFC4860] procedures are used, augmented with the aggregation [RFC4860] procedures are used, augmented with the
following rules: following rules:
o) If the Decision Point is not collocated with the PCN-ingress- o) If the Decision Point is not collocated with the PCN-ingress-
node, then other procedures need to be specified of handling the node, then other procedures need to be specified of handling the
Aggregated Resv Message by the Aggregating router, i.e., PCN- Aggregated Resv Message by the Aggregating router, i.e., PCN-
ingress-node. Even though these procedures are out of the scope ingress-node. Even though these procedures are out of the scope
of this document, the PCN-ingress-node can refer to a central of this document, the PCN-ingress-node can refer to a central
decision point which can respond to the PCN ingress as per decision point which can respond to the PCN ingress as per
[RFC2753] [RFC2753]
o) If the Decision point is collocated with the PCN-ingress-node, o) If the Decision point is collocated with the PCN-ingress-node,
then the PCN-ingress-node (i.e. Aggregator) SHOULD use the then the PCN-ingress-node (i.e. Aggregator) SHOULD use the
information carried by the PCN objects as specified in information carried by the PCN objects, see Section 4, to map
[RFC6661], [RFC6662]. When the Aggregator (i.e., PCN-ingress- the RSVP generic aggregated state onto the maintained ingress-
node) needs to terminate an amount of traffic associated with egress-aggregate state at the Aggregator (PCN-ingress-node).
one ingress-egress-aggregate (see bullet 2 in Section 3.3.2 of Furthermore, the Aggregator follows the steps specified in
[RFC6661] and [RFC6662]), then several procedures of terminating [RFC6661], [RFC6662]. Using the information contained in the PCN
e2e microflows can be deployed. The default procedure of object the Aggregator (i.e., PCN-ingress-node) can decide
terminating e2e microflows (i.e., PCN-flows) is as follows, see whether the PCN-admission state for the ingress-egress-aggregate
e.g., [RFC6661]. is "admit" or "reject". Moreover, when the Aggregator (i.e.,
PCN-ingress-node) needs to terminate an amount of traffic
associated with one ingress-egress-aggregate (see bullet 2 in
Section 3.3.2 of [RFC6661] and [RFC6662]), then several
procedures of terminating e2e microflows can be deployed. The
default procedure of terminating e2e microflows (i.e., PCN-
flows) is as follows, see e.g., [RFC6661].
For the same ingress-egress-aggregate, select a number of e2e For the same ingress-egress-aggregate, select a number of e2e
microflows to be terminated in order to decrease the total microflows to be terminated 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, see above. aggregate by the amount of traffic to be terminated, see above.
In this situation the same mechanisms for terminating an e2e In this situation the same mechanisms for terminating an e2e
microflow can be followed as specified in [RFC2205]. However, microflow can be followed as specified in [RFC2205]. However,
based on a local policy, the Aggregator could use other ways of based on a local policy, the Aggregator could use other ways of
selecting which microflows should be terminated. selecting which microflows should be terminated.
For example, for the same ingress-egress-aggregate, select a For example, for the same ingress-egress-aggregate, select a
number of e2e microflows to be terminated or to reduce their number of e2e microflows to be terminated or to reduce their
skipping to change at page 20, line 20 skipping to change at page 21, line 34
o) A PCN-egress-node (i.e., Deaggregator) SHOULD send periodically o) A PCN-egress-node (i.e., Deaggregator) SHOULD send periodically
and at the end of each t-meas measurement interval, or less and at the end of each t-meas measurement interval, or less
frequently if "optional report suppression" is activated, an frequently if "optional report suppression" is activated, an
(refresh) aggregated RSVP message to the PCN-ingress-node (i.e. (refresh) aggregated RSVP message to the PCN-ingress-node (i.e.
aggregator), see [RFC6661] and [RFC6662]. aggregator), see [RFC6661] and [RFC6662].
o) the DSCP value included in the SESSION object, SHOULD be set equal o) the DSCP value included in the SESSION object, SHOULD be set equal
to a PCN-compatible Diffserv codepoint. to a PCN-compatible Diffserv codepoint.
o) An aggregated Resv message MUST carry one or more C-type PCN o) An aggregated Resv message MUST carry one or more PCN
objects, see Section 4.1, to report the data measured by an objects, see Section 4.1, to report the data measured by an
PCN-egress-node (i.e., Deaggregator). PCN-egress-node (i.e., Deaggregator).
o) As described in [RFC6661], [RFC6663], PCN reports o) As described in [RFC6661], [RFC6663], PCN reports
from the PCN-egress-node (Deaggregator) to the decision point may from the PCN-egress-node (Deaggregator) to the decision point may
contain flow identifiers for individual flows within an contain flow identifiers for individual flows within an
ingress-egress-aggregate that have recently experienced ingress-egress-aggregate that have recently experienced
excess-marking. Hence, the PCN report messages used by the PCN CL excess-marking. Hence, the PCN report messages used by the PCN CL
edge behavior MUST be capable of carrying sequences of octet edge behavior MUST be capable of carrying sequences of octet
strings constituting such identifiers. When the PCN CL edge strings constituting such identifiers. When the PCN CL edge
behavior is used, the individual flow identifiers need to be behavior is used, the individual flow identifiers need to be
included in specific PCN objects, see Section 4.1 included in specific PCN objects, see Section 4.1
(C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs, (RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs,
= RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs) RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs)
4.1 PCN object 4.1 PCN objects
The PCN object reports data measured by a PCN-egress-node and The PCN object reports data measured by a PCN-egress-node and
carried by the generic aggregated RESV messages specified in carried by the generic aggregated RESV messages specified in
[RFC4860]. PCN objects are defined for different PCN edge behavior [RFC4860]. PCN objects are defined for different PCN edge behavior
drafts. This document defines six types of PCN objects: drafts. This document defines six types of PCN objects that belong
into the SESSION Class and need to be carried by
Aggregate RESV messages. These objects are:
o) Single Marking (SM) PCN object, when IPv4 addresses are used: RSVP-AGGREGATE-IPv4-PCN-SM, RSVP-AGGREGATE-IPv6-PCN-SM,
Class = PCN RSVP-AGGREGATE-IPv4-PCN-CL, RSVP-AGGREGATE-IPv6-PCN-CL,
C-Type = RSVP-AGGREGATE-IPv4-PCN-SM RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs, RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs.
o) RSVP-AGGREGATE-IPv4-PCN-SM: Single Marking (SM) PCN object, when
IPv4 addresses are used:
Class = 1 (SESSION)
C-Type = RSVP-AGGREGATE-IPv4-PCN-SM (to be replaced by IANA)
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 PCN-ingress-node Address (4 bytes) | | IPv4 PCN-ingress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 PCN-egress-node Address (4 bytes) | | IPv4 PCN-egress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of not marked PCN-traffic (NM-rate) | | rate of not marked PCN-traffic (NM-rate) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of PCN-marked PCN-traffic (PM-rate) | | rate of PCN-marked PCN-traffic (PM-rate) |
+-------------+-------------+-------------+-------------| +-------------+-------------+-------------+-------------|
o) Single Marking (SM) PCN object, when IPv6 addresses are used: o) RSVP-AGGREGATE-IPv6-PCN-SM: Single Marking (SM) PCN object, when
Class = PCN IPv6 addresses are used:
C-Type = RSVP-AGGREGATE-IPv6-PCN-SM
Class = 1 (SESSION)
C-Type = RSVP-AGGREGATE-IPv6-PCN-SM (to be replaced by IANA)
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IPv6 PCN-ingress-node Address (16 bytes) + + IPv6 PCN-ingress-node Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 21, line 31 skipping to change at page 22, line 52
+ IPv6 PCN-egress-node Address (16 bytes) + + IPv6 PCN-egress-node Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of not marked PCN-traffic (NM-rate) | | rate of not marked PCN-traffic (NM-rate) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of PCN-marked PCN-traffic (PM-rate) | | rate of PCN-marked PCN-traffic (PM-rate) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o) Controlled (CL) PCN object, IPv4 addresses are used: o) RSVP-AGGREGATE-IPv4-PCN-CL: Controlled (CL) PCN object, IPv4
Class = PCN addresses are used:
C-Type = RSVP-AGGREGATE-IPv4-PCN-CL Class = 1 (SESSION)
C-Type = RSVP-AGGREGATE-IPv4-PCN-CL (To be replaced by IANA)
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 PCN-ingress-node Address (4 bytes) | | IPv4 PCN-ingress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 PCN-egress-node Address (4 bytes) | | IPv4 PCN-egress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of not marked PCN-traffic (NM-rate) | | rate of not marked PCN-traffic (NM-rate) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of threshold-marked PCN-traffic (ThM-rate) | | rate of threshold-marked PCN-traffic (ThM-rate) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| rate of excess-traffic-marked PCN-traffic (ETM-rate) | | rate of excess-traffic-marked PCN-traffic (ETM-rate) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o) Controlled (CL) PCN object, IPv6 addresses are used: o) RSVP-AGGREGATE-IPv6-PCN-CL: Controlled (CL) PCN object, IPv6
Class = PCN addresses are used:
C-Type = RSVP-AGGREGATE-IPv6-PCN-CL Class = 1 (SESSION)
C-Type = RSVP-AGGREGATE-IPv6-PCN-CL (to be replaced by IANA)
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IPv6 PCN-ingress-node Address (16 bytes) + + IPv6 PCN-ingress-node Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 23, line 5 skipping to change at page 24, line 14
o rate of PCN-marked traffic (PM-rate) in octets/second; its format o rate of PCN-marked traffic (PM-rate) in octets/second; its format
is a 32-bit IEEE floating point number; is a 32-bit IEEE floating point number;
o rate of threshold-marked PCN traffic (ThM-rate) in o rate of threshold-marked PCN traffic (ThM-rate) in
octets/second; its format is a 32-bit IEEE floating point number; octets/second; its format is a 32-bit IEEE floating point number;
o rate of excess-traffic-marked traffic (ETM-rate) in o rate of excess-traffic-marked traffic (ETM-rate) in
octets/second; its format is a 32-bit IEEE floating point number; octets/second; its format is a 32-bit IEEE floating point number;
o) Controlled (CL) PCN CL Flow IDs object, IPv4 addresses are used: o) RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs: Controlled (CL) PCN CL Flow IDs
Class = PCN object, IPv4 addresses are used:
C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs Class = 1 (SESSION)
C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs (to be replaced by IANA)
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address | | Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address | | Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 47 skipping to change at page 25, line 5
combination of each subsequent 5 tuple: combination of each subsequent 5 tuple:
Source address, Destination address, Source Port, Source address, Destination address, Source Port,
Destination Port and Protocol number. Destination Port and Protocol number.
If Length is 0 then the RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs is If Length is 0 then the RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs is
empty. empty.
o) Source address (4 bytes): The IPv4 source address. o) Source address (4 bytes): The IPv4 source address.
o) Destination address (4 bytes): The IPv4 destination address. o) Destination address (4 bytes): The IPv4 destination address.
o) Protocol (1 byte): The IP protocol number. It refers to the o) Protocol (1 byte): The IP protocol number. It refers to the
true upper layer protocol carried by the packets. true upper layer protocol carried by the packets.
o) Source Port (2 bytes): contains the source port number. o) Source Port (2 bytes): contains the source port number.
o) Destination Port (2 bytes): contains the destination port o) Destination Port (2 bytes): contains the destination port
number. number.
o) Controlled (CL) PCN CL Flow IDs object, IPv6 addresses are used: o) RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs: Controlled (CL) PCN CL Flow IDs
Class = PCN object, IPv6 addresses are used:
C-Type = RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs Class = 1 (SESSION)
C-Type = RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs (To be replaced by IANA)
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Source Address | | Source Address |
| | | |
| | | |
skipping to change at page 25, line 20 skipping to change at page 26, line 29
o) Destination Port (2 bytes): contains the destination port o) Destination Port (2 bytes): contains the destination port
number. number.
5. Security Considerations 5. Security Considerations
The same security considerations specified in [RFC2205], [RFC4230], The same security considerations specified in [RFC2205], [RFC4230],
[RFC4860], [RFC5559] and [RFC6411]. [RFC4860], [RFC5559] and [RFC6411].
6. IANA Considerations 6. IANA Considerations
This document makes the following requests to the IANA: This document makes the following requests to the IANA.
o allocate a new Object Class (PCN Object), see Section 4.1. IANA needs to modify the RSVP parameters registry, 'Class Names,
Class Numbers, and Class Types' subregistry, and assigned 6 new C-
Types under the existing SESSION Class (Class number 1), as described
Below, see Section 4.1:
Class
Number Class Name Reference
------ ----------------------- ---------
1 SESSION [RFC2205]
Class Types or C-Types:
19? RSVP-AGGREGATE-IPv4-PCN-SM this document
20? RSVP-AGGREGATE-IPv6-PCN-SM this document
21? RSVP-AGGREGATE-IPv4-PCN-CL this document
22? RSVP-AGGREGATE-IPv6-PCN-CL this document
23? RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs this document
24? RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs this document
7. Acknowledgments 7. Acknowledgments
We would like to thank the authors of [draft-lefaucheur-rsvp-ecn- We would like to thank the authors of [draft-lefaucheur-rsvp-ecn-
01.txt], since some ideas used in this document are based on the work 01.txt], since some ideas used in this document are based on the work
initiated in [draft-lefaucheur-rsvp-ecn-01.txt]. Moreover, we would initiated in [draft-lefaucheur-rsvp-ecn-01.txt]. Moreover, we would
like to thank Bob Briscoe, David Black, Ken Carlberg, Tom Taylor, like to thank Bob Briscoe, David Black, Ken Carlberg, Tom Taylor,
Philip Eardley, Michael Menth, Toby Moncaster, Francois Le Faucheur, Philip Eardley, Michael Menth, Toby Moncaster, Francois Le Faucheur,
James Polk and Lixia Zhang for the provided comments. James Polk and Lixia Zhang for the provided comments.
skipping to change at page 27, line 20 skipping to change at page 28, line 43
[RFC6411] M. Behringer, F. Le Faucheur, B. Weis, "Applicability of [RFC6411] M. Behringer, F. Le Faucheur, B. Weis, "Applicability of
Keying Methods for RSVP Security", RFC 6411, October 2011. Keying Methods for RSVP Security", RFC 6411, October 2011.
[SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested [SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested
Virtual Private Network", Work in Progress, July 2007. Virtual Private Network", Work in Progress, July 2007.
[RFC2753] Yavatkar, R., D. Pendarakis and R. Guerin, "A Framework for [RFC2753] Yavatkar, R., D. Pendarakis and R. Guerin, "A Framework for
Policy-based Admission Control", January 2000. Policy-based Admission Control", January 2000.
10. Authors' Address 10. Appendix A: Example Signaling Flow
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 aggregated over
generic aggregate RSVP reservations and applied over a PCN domain. In
particular the Aggregator (PCN-ingress-node) and Deaggregator (PCN-
egress-node) are located at the boundaries of the PCN domain. The
PCN-interior-nodes are located within the PCN-domain, between the
PCN-boundary nodes, but are not shown in this Figure. It illustrates
a possible RSVP message flow that could take place in the successful
establishment of a unicast E2E reservation that is the first between
a given pair of Aggregator/Deaggregator.
Aggregator (PCN-ingress-node) Deaggregator (PCN-egress-node)
E2E Path
----------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(New-agg-needed,SOI=GAx)
<----------------------------------
E2E PathErr(New-agg-needed,SOI=GAy)
<----------------------------------
(3)
AggPath(Session=GAx)
------------------------------->
AggPath(Session=GAy)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (Session=GAx) (PCN object)
<-------------------------------
AggResv (Session=GAy) (PCN object)
<-------------------------------
(6)
AggResvConfirm (Session=GAx)
------------------------------>
AggResvConfirm (Session=GAy)
------------------------------>
(7)
E2E Resv
<---------
(8)
E2E Resv (SOI=GAx)
<-----------------------------
(9)
E2E Resv
<-----------
(1) The Aggregator (PCN-ingress-node) maps the e2e RSVP reservation
session associated with the e2e Path message onto an PCN ingress-
egress-aggregate. The Aggregator forwards e2e Path into the
aggregation region after modifying its IP protocol number to
RSVP-E2E-IGNORE. Note that in this case it is considered that the
PCN-admission-state is "admit", see Section 3.1. Otherwise, the
e2e Path will not be forwarded into the aggregation region and
the steps associated with the PCN-admission-state is "block"
situation specified in Section 3.1 will be followed.
(2) Let's assume no Aggregate Path exists. To be able to accurately
update the ADSPEC of the e2e Path, the Deaggregator needs the
ADSPEC of Aggregate Path. In this example, the Deaggregator
elects to instruct the Aggregator to set up Aggregate Path states
for the two supported PHB-IDs. To do that, the Deaggregator
sends two e2e PathErr messages with a New-Agg-Needed PathErr
code. Both PathErr messages also contain a SESSION-OF-INTEREST
(SOI) object. In the first e2e PathErr, the SOI contains a
GENERIC-AGGREGATE SESSION (GAx) whose PHB-ID is set to x. In the
second e2e PathErr, the SOI contains a GENERIC-AGGREGATE SESSION
(GAy) whose PHB-ID is set to y. In both messages the GENERIC-
AGGREGATE SESSION contains an interface-independent Deaggregator
address inside the DestAddress and appropriate values inside the
vDstPort and Extended vDstPort fields.
(3) The Aggregator follows the request from the Deaggregator and
signals an Aggregate Path for both GENERIC-AGGREGATE Sessions
(GAx and GAy).
(4) The Deaggregator takes into account the information contained in
the ADSPEC from both Aggregate Paths and updates the e2e Path
ADSPEC accordingly. The Deaggregator also modifies the e2e Path
IP protocol number to RSVP before forwarding it.
(5) In this example, the Deaggregator elects to immediately proceed
with establishment of generic aggregate reservations for both
PHB-IDs. In effect, the Deaggregator can be seen as anticipating
the actual demand of e2e reservations so that resources are
available on the generic aggregate reservations when the e2e Resv
requests arrive, in order to speed up establishment of e2e
reservations.
At this step the Deaggregator maps the new generated RSVP generic
aggregated reservations onto one ingress-egress-aggregate
maintained by the Deaggregator (PCN-egress-node), see Section
3.3. Moreover, the Deaggregator, depending on the used
PCN edge behaviour and IP version, it includes one of the
following PCN objects specified in Section 4.1:
RSVP-AGGREGATE-IPv4-PCN-SM, RSVP-AGGREGATE-IPv6-PCN-SM,
RSVP-AGGREGATE-IPv4-PCN-CL or RSVP-AGGREGATE-IPv6-PCN-CL.
Here it is also Assumed that the Deaggregator includes the
optional Resv Confirm Request in these Aggregate Resv.
(6) The Aggregator merely complies with the received ResvConfirm
Request and returns the corresponding Aggregate ResvConfirm.
Moreover, the PCN-ingress-node functionality uses the PCN object
to map the RSVP generic aggregated reservation state onto the
maintained PCN ingress-egress-aggregate state. Moreover, the
Aggregator performs the steps specified in Section 3.11.
(7) The Deaggregator has explicit confirmation that both Aggregate
Resvs are established.
(8) On receipt of the e2e Resv, the Deaggregator applies the mapping
policy defined by the network administrator to map the e2e Resv
onto a generic aggregate reservation. Let's assume that this
policy is such that the e2e reservation is to be mapped onto the
generic aggregate reservation with PHB-ID=x. The Deaggregator
knows that a generic aggregate reservation (GAx) is in place for
the corresponding PHB-ID since (7). The Deaggregator performs
admission control of the e2e Resv onto the generic aggregate
reservation for PHB-ID=x (GAx). Assuming that the generic
aggregate reservation for PHB-ID=x (GAx) had been established
with sufficient bandwidth to support the e2e Resv, the
Deaggregator adjusts its counter, tracking the unused bandwidth
on the generic aggregate reservation. Then it forwards the e2e
Resv to the Aggregator including a SESSION-OF-INTEREST object
conveying the selected mapping onto GAx (and hence onto
PHB-ID=x).
(9) The Aggregator records the mapping of the e2e Resv onto GAx (and
onto PHB-ID=x). The Aggregator removes the SOI object and
forwards the e2e Resv towards the sender.
11. Authors' Address
Georgios Karagiannis Georgios Karagiannis
University of Twente University of Twente
P.O. Box 217 P.O. Box 217
7500 AE Enschede, 7500 AE Enschede,
The Netherlands The Netherlands
EMail: g.karagiannis@utwente.nl EMail: g.karagiannis@utwente.nl
Anurag Bhargava Anurag Bhargava
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 51 change blocks. 
197 lines changed or deleted 420 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/