RFC 7417
Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains
Pages: 36
Experimental
Experimental
Part 2 of 2 – Pages 17 to 36
3. Elements of Procedures
This section describes the procedures used to implement the aggregate RSVP procedure over PCN. It is considered that the procedures for aggregation of E2E reservations over generic aggregate RSVP reservations are the same as the procedures specified in Section 4 of [RFC4860], except where a departure from these procedures is explicitly described in this section. Please refer to Appendix B of [RFC2205] and Section 3 of [RFC4860] for the processing rules and error handling for the error cases listed below: o Message formatting errors, e.g., incomplete message o Unknown objects3.1. Receipt of E2E Path Message by PCN-Ingress-Node (Aggregating Router)
When the E2E Path message arrives at the exterior interface of the Aggregator (PCN-ingress-node), then standard RSVP generic aggregation [RFC4860] procedures are used.3.2. Handling of E2E Path Message by Interior Routers
The E2E Path messages traverse zero or more PCN-interior-nodes. The PCN-interior-nodes receive the E2E Path message on an interior interface and forward it on another interior interface. It is considered that, by configuration, the PCN-interior-nodes ignore the E2E RSVP signaling messages [RFC2205]. Therefore, the E2E Path messages are simply forwarded as normal IP datagrams.
3.3. Receipt of E2E Path Message by PCN-Egress-Node (Deaggregating Router)
When receiving the E2E Path message, the Deaggregator (PCN-egress- node and Decision Point) performs the regular procedures of [RFC4860], augmented with the following rules: o The Deaggregator MUST NOT perform the RSVP-TTL vs. IP TTL-check (TTL = Time To Live) and MUST NOT update the ADSPEC Break bit. This is because the whole PCN-domain is effectively handled by E2E RSVP as a virtual link on which integrated service is indeed supported (and admission control performed) so that the Break bit MUST NOT be set; see also [RSVP-PCN-CL]. The Deaggregator forwards the E2E Path message towards the receiver.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 generic aggregate Path message by the Aggregator (PCN-ingress-node), the same methods MUST be used as the ones described in [RFC4860].3.5. Handling of Aggregate Path Message by Interior Routers
The Aggregate Path messages traverse zero or more PCN-interior-nodes. The PCN-interior-nodes receive the Aggregate Path message on an interior interface and forward it on another interior interface. It is considered that, by configuration, the PCN-interior-nodes ignore the Aggregate Path signaling messages. Therefore, the Aggregate Path messages are simply forwarded as normal IP datagrams.3.6. Handling of Aggregate Path Message by Deaggregating Router
When receiving the Aggregate Path message, the Deaggregator (PCN-egress-node and Decision Point) performs the regular procedures of [RFC4860], augmented with the following rules: o When the received Aggregate Path message by the Deaggregator contains the RSVP-AGGREGATE-IPv4-PCN-response or RSVP-AGGREGATE- IPv6-PCN-response PCN objects, which carry the PCN-sent-rate, then the procedures specified in Section 3.18 of this document MUST be followed.
3.7. Handling of E2E Resv Message by Deaggregating Router
When the E2E Resv message arrives at the exterior interface of the Deaggregator (PCN-egress-node and Decision Point), then standard RSVP aggregation procedures of [RFC4860] are used, augmented with the following rules: o The E2E RSVP SESSION associated with an E2E Resv message that arrives at the external interface of the Deaggregator is mapped/matched with an RSVP generic aggregate and with a PCN ingress-egress-aggregate. o Depending on the type of the PCN edge behavior supported by the Deaggregator, the PCN admission control procedures specified in Section 3.3.1 of [RFC6661] or [RFC6662] MUST be followed. Since no admission control procedures over the RSVP aggregate reservations in the PCN-core are required, unlike [RFC4860], the Deaggregator does not perform any admission control of the E2E reservation over the mapped generic aggregate RSVP reservation. If the PCN-based admission control procedure is successful, then the Deaggregator MUST allow the new flow to be admitted onto the associated RSVP generic aggregation reservation and onto the PCN ingress-egress-aggregate; see [RFC6661] and [RFC6662]. If the PCN-based admission control procedure is not successful, then the E2E Resv MUST NOT be admitted onto the associated RSVP generic aggregate reservation and onto the PCN ingress-egress-aggregation. The E2E Resv message is further processed according to [RFC4860]. How the PCN-admission-state is maintained is specified in [RFC6661] and [RFC6662].3.8. Handling of E2E Resv Message by Interior Routers
The E2E Resv messages traversing the PCN-core are IP addressed to the Aggregating router and are not marked with Router Alert; therefore, the E2E Resv messages are simply forwarded as normal IP datagrams.
3.9. Initiation of New Aggregate Resv Message by Deaggregating Router
To comply with this specification, for the initiation of the new RSVP generic aggregate Resv message by the Deaggregator (PCN-egress-node and Decision Point), the same methods MUST be used as the ones described in Section 4 of [RFC4860], augmented with the following rules: 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-egress-node. The Deaggregator SHOULD set the value of an RSVP generic aggregate reservation to a null bandwidth. We also observe that there is no need for dynamic adjustment of the RSVP generic aggregate reservation size. o When [RFC6661] is used and the ETM-rate measured by the Deaggregator contains a non-zero value for some ingress-egress- aggregate (see [RFC6661] and [RFC6662]), the Deaggregator MUST request the PCN-ingress-node to provide an estimate of the rate (PCN-sent-rate) at which the Aggregator (PCN-ingress-node) is receiving PCN-traffic that is destined for the given ingress- egress-aggregate. 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 ingress-egress-aggregate, the Deaggregator MUST request the PCN-ingress-node to provide an estimate of the rate (PCN-sent-rate) at which the Aggregator is receiving PCN-traffic that is destined for the given ingress-egress-aggregate. o In the above two cases and when the PCN-sent-rate needs to be requested from the Aggregator, the Deaggregator MUST generate and send to the Aggregator a (refresh) Aggregate Resv message 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-request3.10. Handling of Aggregate Resv Message by Interior Routers
The Aggregate Resv messages traversing the PCN-core are IP addressed to the Aggregating router and are not marked with Router Alert; therefore, the Aggregate Resv messages are simply forwarded as normal IP datagrams.
3.11. Handling of E2E Resv Message by Aggregating Router
When the E2E Resv message arrives at the interior interface of the Aggregator (PCN-ingress-node), then standard RSVP aggregation procedures of [RFC4860] are used.3.12. Handling of Aggregate Resv Message by Aggregating Router
When the Aggregate Resv message arrives at the interior interface of the Aggregator (PCN-ingress-node), then standard RSVP aggregation procedures of [RFC4860] are used, augmented with the following rules: o The Aggregator SHOULD use the information carried by the PCN objects (see Section 4) and follow the steps specified in Section 3.4 of [RFC6661] and [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 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
To comply with this specification, for the removal of E2E reservations, the same methods MUST be used as the ones described in Section 4 of [RFC4860] and Section 5 of [RFC4495].
3.14. Removal of Aggregate Reservation
To comply with this specification, for the removal of RSVP generic aggregate reservations, the same methods MUST be used as the ones described in Section 4 of [RFC4860] and Section 2.10 of [RFC3175]. In particular, should an aggregate reservation go away (presumably due to a configuration change, route change, or policy event), the E2E reservations it supports are no longer active. They MUST be treated accordingly.3.15. Handling of Data on Reserved E2E Flow by Aggregating Router
The handling of data on the reserved E2E flow by the Aggregator (PCN-ingress-node) uses the procedures described in [RFC4860], augmented with the following: 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
No multicast sessions are considered in this document.3.17. Misconfiguration of PCN-Node
In an event where a PCN-node is misconfigured within a PCN-domain, the desired behavior is the same as that described in Section 3.10.3.18. PCN-Based Flow Termination
When the Deaggregator (PCN-egress-node and Decision Point) needs to terminate an amount of traffic associated with one ingress-egress- aggregate (see Section 3.3.2 of [RFC6661] and [RFC6662]), then several procedures for terminating E2E microflows can be deployed. The default procedure for terminating E2E microflows (i.e., PCN-flows) is as follows; see, for example, [RFC6661] and [RFC6662]. For the same ingress-egress-aggregate, select a number of E2E microflows to be terminated in order to decrease the total incoming amount of bandwidth associated with one ingress-egress-aggregate by the amount of traffic to be terminated. In this situation, the same mechanisms for terminating an E2E microflow can be followed as the mechanisms specified in [RFC2205]. However, based on a local policy, the Deaggregator could use other ways of selecting which microflows should be terminated. For example, for the same ingress-egress- aggregate, select a number of E2E microflows to be terminated or to reduce their reserved bandwidth in order to decrease the total
incoming amount of bandwidth associated with one ingress-egress- aggregate by the amount of traffic to be terminated. In this situation, the same mechanisms for terminating an E2E microflow or reducing bandwidth associated with an E2E microflow can be followed as the mechanisms specified in Section 5 of [RFC4495].4. Protocol Elements
The protocol elements in this document are using the elements defined in Section 4 of [RFC4860] and Section 3 of [RFC3175], augmented with the following rules: o The DSCP value included in the SESSION object SHOULD be set equal to a PCN-compatible Diffserv Codepoint. o The Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination addresses of the Aggregator (PCN-ingress-node); see [RFC4860]. o When the Deaggregator (PCN-egress-node and Decision Point) needs to request the PCN-sent-rate from the PCN-ingress-node (see Section 3.9 of this document), the Deaggregator MUST generate and send a (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 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 by the (refresh) Aggregate Path or the (refresh) Aggregate Resv messages specified in [RFC4860]. These objects are as follows: o RSVP-AGGREGATE-IPv4-PCN-request 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: Class = 248 (PCN) C-Type = 1 (RSVP-AGGREGATE-IPv4-PCN-request) +-------------+-------------+-------------+-------------+ | IPv4 PCN-ingress-node Address (4 bytes) | +-------------+-------------+-------------+-------------+ | IPv4 PCN-egress-node Address (4 bytes) | +-------------+-------------+-------------+-------------+ | IPv4 Decision Point Address (4 bytes) | +-------------+-------------+-------------+-------------+ |R| Reserved | +-------------+-------------+-------------+-------------+
o RSVP-AGGREGATE-IPv6-PCN-request: PCN object, when IPv6 addresses
are used:
Class = 248 (PCN)
C-Type = 2 (RSVP-AGGREGATE-IPv6-PCN-request)
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 PCN-ingress-node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 PCN-egress-node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Decision Point Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
|R| Reserved |
+-------------+-------------+-------------+-------------+
o RSVP-AGGREGATE-IPv4-PCN-response: PCN object, IPv4 addresses
are used:
Class = 248 (PCN)
C-Type = 3 (RSVP-AGGREGATE-IPv4-PCN-response)
+-------------+-------------+-------------+-------------+
| IPv4 PCN-ingress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| IPv4 PCN-egress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| IPv4 Decision Point Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| PCN-sent-rate |
+-------------+-------------+-------------+-------------+
o RSVP-AGGREGATE-IPv6-PCN-response: PCN object, IPv6 addresses
are used:
Class = 248 (PCN)
C-Type = 4 (RSVP-AGGREGATE-IPv6-PCN-response)
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 PCN-ingress-node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 PCN-egress-node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Decision Point Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| PCN-sent-rate |
+-------------+-------------+-------------+-------------+
The fields carried by the PCN object are specified in [RFC6663],
[RFC6661], and [RFC6662]:
o The IPv4 or IPv6 address of the PCN-ingress-node (Aggregator) and
the IPv4 or IPv6 address of the PCN-egress-node (Deaggregator):
together, they specify the ingress-egress-aggregate to which the
report refers. According to [RFC6663], the report should carry
the identifier of the PCN-ingress-node (Aggregator) and the
identifier of the PCN-egress-node (Deaggregator) (typically their
IP addresses).
o Decision Point Address: specifies the IPv4 or IPv6 address of the
Decision Point. In this document, this field MUST contain the IP
address of the Deaggregator.
o "R": 1-bit flag that, when set to ON, signifies, according to
[RFC6661] and [RFC6662], that the PCN-ingress-node (Aggregator)
MUST provide an estimate of the rate (PCN-sent-rate) at which the
PCN-ingress-node (Aggregator) is receiving PCN-traffic that is
destined for the given ingress-egress-aggregate.
o "Reserved": 31 bits that are currently not used by this document
and are reserved. These SHALL be set to 0 and SHALL be ignored on
reception.
o PCN-sent-rate: the estimate of the rate at which the PCN-ingress-
node (Aggregator) is receiving PCN-traffic that is destined for
the given ingress-egress-aggregate. It is expressed in
octets/second; its format is a 32-bit IEEE floating-point number.
The PCN-sent-rate is specified in [RFC6661] and [RFC6662].
5. Security Considerations
The security considerations specified in [RFC2205], [RFC4860], and
[RFC5559] apply to this document. In addition, [RFC4230] and
[RFC6411] provide useful guidance on RSVP security mechanisms.
Security within a PCN-domain is fundamentally based on the controlled
environment trust assumption stated in Section 6.3.1 of [RFC5559] --
in particular, that all PCN-nodes are PCN-enabled and are trusted to
perform accurate PCN-metering and PCN-marking.
In the PCN-domain environments addressed by this document, Generic
Aggregate RSVP messages specified in [RFC4860] are used for support
of the PCN Controlled Load (CL) and Single Marking (SM) edge
behaviors over a Diffserv cloud using Pre-Congestion Notification.
Hence, the security mechanisms discussed in [RFC4860] are applicable.
Specifically, the INTEGRITY object [RFC2747] [RFC3097] can be used to
provide hop-by-hop RSVP message integrity, node authentication, and
replay protection, thereby protecting against corruption and spoofing
of RSVP messages and PCN feedback conveyed by RSVP messages.
For these reasons, this document does not introduce significant
additional security considerations beyond those discussed in
[RFC5559] and [RFC4860].
6. IANA Considerations
IANA has modified the "Class Names, Class Numbers, and Class Types" subregistry of the "Resource Reservation Protocol (RSVP) Parameters" registry, to add a new Class Number and assign four new C-Types under this new Class Number, as described below; see Section 4.1: Class Number Class Name Reference ------- ---------------------- ------------- 248 PCN RFC 7417 Class Types or C-Types - 248 PCN Value Description Reference ------ ------------------------------ ------------ 1 RSVP-AGGREGATE-IPv4-PCN-request RFC 7417 2 RSVP-AGGREGATE-IPv6-PCN-request RFC 7417 3 RSVP-AGGREGATE-IPv4-PCN-response RFC 7417 4 RSVP-AGGREGATE-IPv6-PCN-response RFC 74177. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997, <http://www.rfc-editor.org/info/rfc2205>. [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001, <http://www.rfc-editor.org/info/rfc3140>. [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001, <http://www.rfc-editor.org/info/rfc3175>. [RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow", RFC 4495, May 2006, <http://www.rfc-editor.org/info/rfc4495>.
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007, <http://www.rfc-editor.org/info/rfc4860>. [RFC5670] Eardley, P., Ed., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009, <http://www.rfc-editor.org/info/rfc5670>. [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, July 2012, <http://www.rfc-editor.org/info/rfc6660>. [RFC6661] Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. 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>. [RFC6662] Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T. Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary- Node Behavior for the Single Marking (SM) Mode of Operation", RFC 6662, July 2012, <http://www.rfc-editor.org/info/rfc6662>. [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>.7.2. Informative References
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994, <http://www.rfc-editor.org/info/rfc1633>. [RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997, <http://www.rfc-editor.org/info/rfc2211>. [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 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, "Definition of the Differentiated Services Field (DS 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 W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>. [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000, <http://www.rfc-editor.org/info/rfc2747>. [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000, <http://www.rfc-editor.org/info/rfc2753>. [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000, <http://www.rfc-editor.org/info/rfc2998>. [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001, <http://www.rfc-editor.org/info/rfc3097>. [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005, <http://www.rfc-editor.org/info/rfc4230>. [RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling in a Nested Virtual Private Network", RFC 4923, August 2007, <http://www.rfc-editor.org/info/rfc4923>. [RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009, <http://www.rfc-editor.org/info/rfc5559>.
[RFC6411] Behringer, M., Le Faucheur, F., and B. Weis, "Applicability of Keying Methods for RSVP Security", RFC 6411, October 2011, <http://www.rfc-editor.org/info/rfc6411>. [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 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 the diagram below. 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 Aggregator-Deaggregator pair. Aggregator (PCN-ingress-node) Deaggregator (PCN-egress-node) E2E Path -----------> (1) E2E Path -------------------------------> (2) E2E PathErr(NEW-AGGREGATE-NEEDED,SOI=GApcn) <---------------------------------------- (3) AggPath(Session=GApcn) -------------------------------> (4) E2E Path -----------> (5) AggResv (Session=GApcn) (PCN object) <------------------------------- (6) AggResvConfirm (Session=GApcn) ------------------------------> (7) E2E Resv <--------- (8) E2E Resv (SOI=GApcn) <----------------------------- (9) E2E Resv <-----------
(1) The Aggregator forwards E2E Path into the aggregation region
after modifying its IP protocol number to RSVP-E2E-IGNORE.
(2) Let's assume that 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 an
Aggregate Path state for the PCN PHB-ID. To do that, the
Deaggregator sends an E2E PathErr message with a
NEW-AGGREGATE-NEEDED PathErr code.
The PathErr message also contains a SESSION-OF-INTEREST (SOI)
object. The SOI contains a GENERIC-AGGREGATE SESSION (GApcn)
whose PHB-ID is set to the PCN PHB-ID. The GENERIC-AGGREGATE
SESSION contains an interface-independent Deaggregator address
inside the DestAddress and appropriate values inside the vDstPort
and Extended vDstPort fields. In this document, the Extended
vDstPort SHOULD contain the IPv4 or IPv6 address of the
Aggregator.
(3) The Aggregator follows the request from the Deaggregator and
signals an Aggregate Path for the GENERIC-AGGREGATE SESSION
(GApcn).
(4) The Deaggregator takes into account the information contained in
the ADSPEC from both Aggregate Paths and updates the E2E Path
ADSPEC accordingly. 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 the whole PCN-domain is effectively handled
by E2E RSVP as a virtual link on which integrated service is
indeed supported (and admission control performed) so that the
Break bit MUST NOT be set; see also [RSVP-PCN-CL]. 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 the generic aggregate reservation. In
effect, the Deaggregator can be seen as anticipating the actual
demand of E2E reservations so that the generic aggregate
reservation is in place when the E2E Resv request arrives, in
order to speed up establishment of E2E reservations. Here it is
also assumed that the Deaggregator includes the optional
ResvConfirm Request in the Aggregate Resv message.
(6) The Aggregator merely complies with the received ResvConfirm
Request and returns the corresponding Aggregate ResvConfirm.
(7) The Deaggregator has explicit confirmation that the generic
aggregate reservation is 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 the PCN PHB-ID=x. After the
previous step (7), the Deaggregator knows that a generic
aggregate reservation (GApcn) is in place for the corresponding
PHB-ID. At this step, the Deaggregator maps the generic
aggregate reservation onto one ingress-egress-aggregate
maintained by the Deaggregator (as a PCN-egress-node); see
Section 3.7. The Deaggregator performs admission control of the
E2E Resv onto the generic aggregate reservation for the PCN
PHB-ID (GApcn). The Deaggregator also takes into account the PCN
admission control procedure as specified in [RFC6661] and
[RFC6662]; see Section 3.7. If one or both of the admission
control procedures (the PCN-based admission control procedure
described in Section 3.3.1 of [RFC6661] or [RFC6662], and the
admission control procedure specified in [RFC4860]) are not
successful, then the E2E Resv is not admitted onto the associated
RSVP generic aggregate reservation for the PCN PHB-ID (GApcn).
Otherwise, assuming that the generic aggregate reservation for
the PCN (GApcn) had been established with sufficient bandwidth to
support the E2E Resv, the Deaggregator adjusts its counter,
tracking the unused bandwidth on the generic aggregate
reservation. Then it forwards the E2E Resv to the Aggregator,
including a SESSION-OF-INTEREST object conveying the selected
mapping onto GApcn (and hence onto the PCN PHB-ID).
(9) The Aggregator records the mapping of the E2E Resv onto GApcn
(and onto the PCN PHB-ID). The Aggregator removes the SOI object
and forwards the E2E Resv towards the sender.
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 Huawei Technologies Hansaallee 205 40549 Dusseldorf Germany EMail: Georgios.Karagiannis@huawei.com Anurag Bhargava Cisco Systems, Inc. 7100-9 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709-4987 United States EMail: anuragb@cisco.com