RFC 7417
Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains
RFC 7417: Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains 🎀
okay so this one is from the IETF (the Internet Engineering Task Force, the crew that writes the rules for how the internet talks to itself 🌐). It's an Experimental document, not a Standards Track one, so it's more of a "let's try this out and see" vibe 🧪. It came out in December 2014 under ISSN 2070-1721. The authors are G. Karagiannis from Huawei Technologies and A. Bhargava from Cisco Systems, Inc. 💅 The header doesn't list anything it obsoletes or updates, so no drama there 🙈
Abstract ✨
okay so the abstract is giving very "here's the whole plot" 🦋 It says this document specifies extensions to Generic Aggregate RSVP ([RFC4860]) so it can support the Pre-Congestion Notification (PCN) Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud that's using PCN 🌈
Status of This Memo 📜
bestie, this section is lowkey important. The document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧪 It defines an Experimental Protocol for the Internet community, and it's a product of the IETF. It represents consensus of the IETF community and got public review. The IESG (Internet Engineering Steering Group) approved it for publication 👑 But not everything the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🤓
For info about its current status, errata, and feedback, you can head to http://www.rfc-editor.org/info/rfc7417 🔗
Copyright Notice 💖
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 🫶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info, as in effect on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions 📖 Any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're also provided without warranty, as described in the Simplified BSD License ⚖️
Table of Contents 🗺️
1. Introduction ....................................................4
1.1. Objective ..................................................4
1.2. Overview and Motivation ....................................5
1.3. Requirements Language and Terminology ......................8
1.4. Organization of This Document .............................12
2. Overview of RSVP Extensions and Operations .....................12
2.1. Overview of RSVP Aggregation Procedures in PCN-Domains ....12
2.2. PCN-Marking, Encoding, and Transport of
Pre-congestion Information ................................14
2.3. Traffic Classification within the Aggregation Region ......14
2.4. Deaggregator (PCN-Egress-Node) Determination ..............15
2.5. Mapping E2E Reservations onto Aggregate Reservations ......15
2.6. Size of Aggregate Reservations ............................16
2.7. E2E Path ADSPEC Update ....................................16
2.8. Intra-domain Routes .......................................16
2.9. Inter-domain Routes .......................................16
2.10. Reservations for Multicast Sessions ......................16
2.11. Multi-level Aggregation ..................................16
2.12. Reliability Issues .......................................17
3. Elements of Procedures .........................................17
3.1. Receipt of E2E Path Message by PCN-Ingress-Node
(Aggregating Router) ......................................17
3.2. Handling of E2E Path Message by Interior Routers ..........17
3.3. Receipt of E2E Path Message by PCN-Egress-Node
(Deaggregating Router) ....................................18
3.4. Initiation of New Aggregate Path Message by
PCN-Ingress-Node (Aggregating Router) .....................18
3.5. Handling of Aggregate Path Message by Interior Routers ....18
3.6. Handling of Aggregate Path Message by
Deaggregating Router ......................................18
3.7. Handling of E2E Resv Message by Deaggregating Router ......19
3.8. Handling of E2E Resv Message by Interior Routers ..........19
3.9. Initiation of New Aggregate Resv Message by
Deaggregating Router ......................................20
3.10. Handling of Aggregate Resv Message by Interior Routers ...20
3.11. Handling of E2E Resv Message by Aggregating Router .......21
3.12. Handling of Aggregate Resv Message by
Aggregating Router .......................................21
3.13. Removal of E2E Reservation ...............................21
3.14. Removal of Aggregate Reservation .........................22
3.15. Handling of Data on Reserved E2E Flow by
Aggregating Router .......................................22
3.16. Procedures for Multicast Sessions ........................22
3.17. Misconfiguration of PCN-Node .............................22
3.18. PCN-Based Flow Termination ...............................22
4. Protocol Elements ..............................................23
4.1. PCN Objects ...............................................24
5. Security Considerations ........................................28
6. IANA Considerations ............................................29
7. References .....................................................29
7.1. Normative References ......................................29
7.2. Informative References ....................................30
Appendix A. Example Signaling Flow ................................33
Acknowledgments ...................................................35
Authors' Addresses ................................................361. Introduction 🌸
1.1. Objective 🎯
okay so Pre-Congestion Notification (PCN) can support the Quality of Service (QoS) of inelastic flows inside a Diffserv domain in a way that's simple, scalable, and robust 💅 There are two mechanisms in play: admission control and flow termination 🫧 Admission control decides whether to admit or block a brand-new flow request. Flow termination is for abnormal situations, where it decides whether to kill some of the flows that already exist 😭
To make this work, the overall rate of PCN-traffic gets metered on every link in the domain. PCN-packets get marked when certain configured rates are exceeded 🌈 Those configured rates sit below the link's actual rate, so boundary nodes get warned about overloads before any congestion actually happens. That's why it's called "pre-congestion" notification ✨
The PCN-egress-nodes measure the rates of differently marked PCN-traffic in periodic intervals, then report those rates to the Decision Points. The Decision Points use the rates to make their admission control and flow termination calls 👑 A Decision Point can be collocated with a PCN-ingress-node, or its function can live in some other node. If you want the deeper dive, check out [RFC5559], [RFC6661], and [RFC6662] 🤓
The main goal of this document is to specify the signaling protocol that can be used inside a PCN-domain. That protocol carries reports from a PCN-ingress-node to a PCN Decision Point, and it assumes the PCN Decision Point and PCN-egress-node are collocated 🫶
If the PCN Decision Point is not collocated with the PCN-egress-node, then additional signaling procedures are required. Those are out of scope for this document 🙈 Also, as mentioned above, this architecture conforms with Policy-Based Admission Control (PBAC), where the Decision Point lives in a node other than the PCN-ingress-node [RFC2753] 🧚
Several signaling protocols can carry information between PCN-boundary-nodes (that's the PCN-ingress-node and PCN-egress-node). But here's the tea 🍓 Both the PCN-egress-node and PCN-ingress-node sit on the data path, and the admission control procedure has to happen at the PCN-egress-node. So a signaling protocol that follows the same path as the data path, like RSVP, is the better fit 💖 Specifically, this document extends Generic Aggregate RSVP [RFC4860] so it supports the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre-Congestion Notification ✨
This document is published as an Experimental document so that it can:
- validate industry interest by allowing implementation and deployment
- gather operational experience, particularly related to dynamic interactions of RSVP signaling and PCN, and the corresponding levels of performance 📊
Support for the techniques in this document involves RSVP functionality in the boundary nodes of a PCN-domain. The interior nodes forward RSVP traffic without performing RSVP functionality 🦋
1.2. Overview and Motivation 🎀
okay so bestie, the IETF has specified two main QoS architectures 💅. The first is Integrated Services (Intserv) [RFC1633], and the second is the Differentiated Services (Diffserv) architecture ([RFC2475]). Lowkey iconic duo 👑
Intserv gives you a way to deliver end-to-end QoS to applications across heterogeneous networks ✨. One of the QoS signaling protocols it uses is RSVP [RFC2205], which lets an application ask the network for per-flow resources 🦋. Those RSVP requests can be admitted or rejected by the network, no cap. Applications describe what they need with quantifiable resource requirements using the Intserv parameters from [RFC2211] and [RFC2212]. The Controlled Load (CL) service [RFC2211] is a form of QoS that closely approximates what the same flow would get from a lightly loaded network element 🌸. It's super useful for inelastic flows, like the ones used for real-time media 🎧
Diffserv can handle differentiated treatment of packets in very large-scale environments 🌈. Intserv and RSVP classify packets per flow, but Diffserv sorts packets into one of a small number of aggregated flows, or "classes" 🧚. The sorting is based on the Diffserv Codepoint (DSCP) in the packet IP header. At each Diffserv router, packets get a "Per Hop Behavior" (PHB), and the DSCP is what invokes it 💜. The main perk of Diffserv is scalability, because the need for per-flow state and per-flow processing is gone 😭 iconic.
Here's the tea: Diffserv does not include any mechanism for communication between applications and the network 🙈. A few solutions have been specified to fix that. One is Intserv over Diffserv [RFC2998], which includes Resource-Based Admission Control (RBAC), PBAC, help with traffic identification and classification, and traffic conditioning ✨. Intserv over Diffserv can run over a statically provisioned Diffserv region or an RSVP-aware one. When the region is RSVP aware, a few mechanisms can support dynamic provisioning and topology-aware admission control: aggregate RSVP reservations, per-flow RSVP, or a bandwidth broker 💖.
[RFC3175] specifies aggregating RSVP end-to-end reservations over aggregate RSVP reservations 🍓. In [RFC3175], the RSVP generic aggregate reservation is described by an RSVP SESSION object using the 3-tuple <source IP address, destination IP address, Diffserv Codepoint> 💅.
Several scenarios need multiple generic aggregate reservations set up for a given PHB, going from a given source IP address to a given destination IP address. Check out [RFC4923] and [RFC4860] for those 👀. For example, multiple generic aggregate reservations can be used when several end-to-end (E2E) reservations with different preemption priorities need to be aggregated through a PCN-domain using the same PHB 🫶. Using multiple aggregate reservations for the same PHB lets you:
- enforce the different preemption priorities within the aggregation region 🔥
- manage Diffserv resources more efficiently 💜
- keep a larger number of E2E reservations with higher preemption priorities alive during periods of resource shortage 🛡️
[RFC4923] goes deep on how end-to-end RSVP reservations can be set up in a nested VPN environment through RSVP aggregation 🌸.
[RFC4860] provides generic aggregate reservations by extending [RFC3175] so it supports multiple aggregate reservations for the same source IP address, destination IP address, and PHB (or set of PHBs) ✨. Specifically, multiple generic aggregate reservations can be set up for a given PHB from a given source IP address to a given destination IP address. The trick is adding the concept of a Virtual Destination Port and an Extended Virtual Destination Port in the RSVP SESSION object 🎀. On top of that, the RSVP SESSION object for generic aggregate reservations uses the PHB Identification Code (PHB-ID) defined in [RFC3140] instead of the Diffserv Codepoint (DSCP) used in [RFC3175]. The PHB-ID is what identifies the PHB, or set of PHBs, that the Diffserv resources get reserved from 🦋.
The RSVP-like signaling protocol that carries (1) requests from a PCN-egress-node to a PCN-ingress-node and (2) reports from a PCN-ingress-node to a PCN-egress-node needs to follow the PCN signaling requirements in [RFC6663] 💌. On top of that, the signaling functionality supported by PCN-ingress-nodes and PCN-egress-nodes needs to maintain logical aggregate constructs (aka ingress-egress-aggregate state) and be able to map E2E reservations to those constructs 🧩. Also, no actual reservation state needs to be maintained inside the PCN-domain. The PCN-interior-nodes are not maintaining any reservation state at all, which is giving minimalism 🌿.
There are two possible ways to do this 💅.
Approach (1):
- adapt the aggregation procedures of RFC 4860 to fit the PCN requirements, changing as little as possible from the functionality RFC 4860 already provides 🌷
- so perform aggregate RSVP signaling (even though PCN-interior-nodes will ignore it) 🙃
- use the aggregate RSVP signaling procedures to carry PCN information between the PCN-boundary-nodes (PCN-ingress-node and PCN-egress-node) 🫧
Approach (2):
- adapt the aggregation procedures of RFC 4860 to fit the PCN requirements with significant changes over RFC 4860. The parts about maintaining aggregate states and mapping E2E reservations to aggregate constructs are kept, but the procedures specific to aggregate RSVP signaling and aggregate reservation establishment/maintenance are dropped 🪄
- so do not perform aggregate RSVP signaling 🙅♀️
- piggyback the PCN information inside the E2E RSVP signaling 🎁
Both approaches are probably viable 🤷♀️. But since the operations of RFC 4860 have been thoroughly studied and implemented, it can be considered that the solution from RFC 4860 can better handle the more challenging situations: rerouting in the PCN-domain, failure of a PCN-ingress-node, failure of a PCN-egress-node, rerouting toward a different edge, and so on 😤. That's why Approach (1) was chosen for specifying the signaling protocol that carries PCN information between the PCN-boundary-nodes (PCN-ingress-node and PCN-egress-node) 👑 ate.
As noted earlier, this document specifies extensions to Generic Aggregate RSVP [RFC4860] to support the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre-Congestion Notification 🌈.
This document follows the PCN signaling requirements defined in [RFC6663] and specifies extensions to Generic Aggregate RSVP [RFC4860] to support the PCN edge behaviors specified in [RFC6661] and [RFC6662] 💜. It also specifies how RSVP aggregation can be used to set up and maintain (1) Ingress-Egress-Aggregate (IEA) states at Ingress and Egress nodes, and (2) generic aggregation of end-to-end RSVP reservations over PCN (Congestion and Pre-Congestion Notification) domains ✨.
To comply with this specification, PCN-nodes MUST be able to support the functionality specified in [RFC5670], [RFC5559], [RFC6660], [RFC6661], and [RFC6662] 🫶. Furthermore, the PCN-boundary-nodes MUST support the RSVP generic aggregate reservation procedures specified in [RFC4860], which are augmented with the procedures specified in this document 💖.
1.3. Requirements Language and Terminology ✨
Okay bestie, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those capitalised words are the ones with real rules attached 💅
This document uses terms defined in [RFC4860], [RFC3175], [RFC5559], [RFC5670], [RFC6661], and [RFC6662]. So you'll see those a lot 🧚
For readability, a number of definitions from [RFC3175] as well as definitions for terms used in [RFC5559], [RFC6661], and [RFC6662] are provided here, where some of them are augmented with new meanings. Here's the lineup 🎀
Aggregator The process in (or associated with) the router at the ingress edge of the aggregation region (with respect to the end-to-end RSVP reservation) and behaving in accordance with [RFC4860]. In this document, it is also the PCN-ingress-node. 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 Section 1.4.2 of [RFC3175]. Main character energy 👑
Congestion Level Estimate (CLE) The ratio of PCN-marked to total PCN-traffic (measured in octets) received for a given ingress-egress-aggregate during a given measurement period. The CLE is used to derive the PCN-admission-state and is also used by the report suppression procedure if report suppression is activated. 📊
Deaggregator The process in (or associated with) the router at the egress edge of the aggregation region (with respect to the end-to-end RSVP reservation) and behaving in accordance with [RFC4860]. In this document, it is also the PCN-egress-node and Decision Point. 🦋
E2E End to end. 💖
E2E Microflow A microflow where its associated packets are being forwarded on an E2E path. ✨
E2E Reservation An RSVP reservation such that:
- corresponding RSVP Path messages are initiated upstream of the Aggregator and terminated downstream of the Deaggregator, and
- corresponding RSVP Resv messages are initiated downstream of the Deaggregator and terminated upstream of the Aggregator, and
- this RSVP reservation is aggregated over an Ingress-Egress-Aggregate (IEA) between the Aggregator and Deaggregator.
An E2E RSVP reservation may be a per-flow reservation, which in this document is only maintained at the PCN-ingress-node and PCN-egress-node. Alternatively, the E2E reservation may itself be an aggregate reservation of various types (e.g., Aggregate IP reservation, Aggregate IPsec reservation [RFC4860]). As per regular RSVP operations, E2E RSVP reservations are unidirectional. One direction only, no cap 🫶
ETM-Rate The rate of excess-traffic-marked (ETM) PCN-traffic received at a PCN-egress-node for a given ingress-egress-aggregate in octets per second. 🌸
Extended vDstPort (Extended Virtual Destination Port) An identifier used in the SESSION that remains constant over the life of the generic aggregate reservation. The length of this identifier is 32 bits when IPv4 addresses are used and 128 bits when IPv6 addresses are used.
A sender (or Aggregator) that wishes to narrow the scope of a SESSION to the sender-receiver pair (or Aggregator-Deaggregator pair) should place its IPv4 or IPv6 address here as a network unique identifier. A sender (or Aggregator) that wishes to use a common session with other senders (or Aggregators) in order to use a shared reservation across senders (or Aggregators) must set this field to all zeros. In this document, the Extended vDstPort should contain the IPv4 or IPv6 address of the Aggregator. Lowkey a lot of "should" and "must" energy here, but they're lowercase, so they're just regular words 🙈
Ingress-Egress-Aggregate (IEA) The collection of PCN-packets from all PCN-flows that travel in one direction between a specific pair of PCN-boundary-nodes. In this document, one RSVP generic aggregate reservation is mapped to only one ingress-egress-aggregate, while one ingress-egress-aggregate is mapped to one or more RSVP generic aggregate reservations. PCN-flows and their PCN-traffic that are mapped into a specific RSVP generic aggregate reservation can also be easily mapped into their corresponding ingress-egress-aggregate. 🔥
Microflow (from [RFC2474]) A single instance of an application-to-application flow of packets, which is identified by <source address, destination address, protocol id> and (where applicable) <source port, destination port>. 🍓
PCN-Admission-State The state ("admit" or "block") derived by the Decision Point for a given ingress-egress-aggregate based on statistics about PCN-packet marking. The Decision Point decides to admit or block new flows offered to the aggregate based on the current value of the PCN-admission-state. The vibe check is literally admit or block 🚦
PCN-Boundary-Node A PCN-node that connects one PCN-domain to a node in either another PCN-domain or a non-PCN-domain. 🌈
PCN-Domain A PCN-capable domain; a contiguous set of PCN-enabled nodes that perform Diffserv scheduling [RFC2474]; the complete set of PCN-nodes that in principle can, through PCN-marking packets, influence decisions about flow admission and termination within the domain; includes the PCN-egress-nodes, which measure these PCN-marks, and the PCN-ingress-nodes. The whole neighbourhood 🏡
PCN-Egress-Node A PCN-boundary-node in its role in handling traffic as it leaves a PCN-domain. In this document, the PCN-egress-node also operates as a Decision Point and Deaggregator. 👋
PCN-Flow The unit of PCN-traffic that the PCN-boundary-node admits (or terminates); the unit could be a single E2E microflow (as defined in [RFC2474]) or some identifiable collection of microflows. 🎀
PCN-Ingress-Node A PCN-boundary-node in its role in handling traffic as it enters a PCN-domain. In this document, the PCN-ingress-node also operates as an Aggregator. 🛎️
PCN-Interior-Node A node in a PCN-domain that is not a PCN-boundary-node. The quiet ones in the back 🤫
PCN-Node A PCN-boundary-node or a PCN-interior-node. 💜
PCN-Sent-Rate The rate of PCN-traffic received at a PCN-ingress-node and destined for a given ingress-egress-aggregate in octets per second. 🚀
PCN-Traffic, PCN-Packets, PCN-BA A PCN-domain carries traffic of different Diffserv Behavior Aggregates (BAs) [RFC2474]. The PCN-BA uses the PCN mechanisms to carry PCN-traffic, and the corresponding packets are PCN-packets. The same network will carry traffic of other Diffserv BAs. The PCN-BA is distinguished by a combination of the Diffserv Codepoint (DSCP) and Explicit Congestion Notification (ECN) fields. Same network, different lanes 🛣️
PHB-ID (Per Hop Behavior Identification Code) A 16-bit field containing the Per Hop Behavior Identification Code of the PHB, or of the set of PHBs, from which Diffserv resources are to be reserved. This field must be encoded as specified in Section 2 of [RFC3140]. 🌟
RSVP Generic Aggregate Reservation An RSVP reservation that is identified by using the RSVP SESSION object for generic RSVP aggregate reservation. This RSVP SESSION object is based on the RSVP SESSION object specified in [RFC4860], augmented with the following information:
- The IPv4 DestAddress, IPv6 DestAddress should be set to the IPv4 or IPv6 destination addresses, respectively, of the Deaggregator (PCN-egress-node).
- The PHB-ID should be set equal to PCN-compatible Diffserv Codepoint(s).
- The Extended vDstPort should be set to the IPv4 or IPv6 destination addresses, of the Aggregator (PCN-ingress-node).
Three extra fields, all with their own job 🧩
VDstPort (Virtual Destination Port) A 16-bit identifier used in the SESSION that remains constant over the life of the generic aggregate reservation. 💅
1.4. Organization of This Document
Here's the map of the whole doc 🗺️ This document is organized as follows. Section 2 gives an overview of RSVP extensions and operations. The elements of the procedures that are used in this document are specified in Section 3. Section 4 describes the protocol elements. The security considerations are given in Section 5, and the IANA considerations are provided in Section 6. ✨
2. Overview of RSVP Extensions and Operations 🌸
2.1. Overview of RSVP Aggregation Procedures in PCN-Domains ✨
okay so the PCN-boundary-nodes (see Figure 1) can totally support RSVP SESSIONS for generic aggregate reservations [RFC4860], and those depend on ingress-egress-aggregates. like, one RSVP generic aggregate reservation matches to only one ingress-egress-aggregate 💅
however, one ingress-egress-aggregate can match to one or more RSVP generic aggregate reservations 🎀. and to be compliant with this spec, the PCN-boundary-nodes need to tell apart and process (1) RSVP SESSIONS for generic aggregate sessions and their messages under [RFC4860] and (2) E2E RSVP SESSIONS and messages under [RFC2205] 🌸
this document puts all the RSVP processing for a PCN-domain at the PCN-boundary-nodes 🧚. PCN-interior-nodes don't do any RSVP functionality and don't keep any RSVP-related state info. they just forward all RSVP messages (for both generic aggregate reservations [RFC4860] and E2E reservations [RFC2205]) as if they were ordinary network traffic 🦋
moreover, each Aggregator and Deaggregator (aka the PCN-boundary-nodes) needs to support policies to start and maintain, for each pair of PCN-boundary-nodes of the same PCN-domain, one ingress-egress-aggregate 🫶
--------------------------
/ PCN-domain \
|----| | | |----|
H--| R |\ |-----| |------| /| R |-->H
H--| |\\| | |---| |---| | |//| |-->H
|----| \| | | I | | I | | |/ |----|
| Agg |======================>| Deag |
/| | | | | | | |\
H--------//| | |---| |---| | |\\-------->H
H--------/ |-----| |------| \-------->H
| |
\ /
--------------------------
H = Host requesting end-to-end RSVP reservations
R = RSVP router
Agg = Aggregator (PCN-ingress-node)
Deag = Deaggregator (PCN-egress-node)
I = Interior Router (PCN-interior-node)
--> = E2E RSVP reservation
==> = Aggregate RSVP reservation
Figure 1: Aggregation of E2E Reservations over Generic Aggregate
RSVP Reservations in PCN-Domains, Based on [RFC4860]both the Aggregator and Deaggregator can maintain one or more RSVP generic aggregate reservations, but the Deaggregator is the one that starts these RSVP generic aggregate reservations 👑. quick reminder: one RSVP generic aggregate reservation matches to only one ingress-egress-aggregate, while one ingress-egress-aggregate matches to one or more RSVP generic aggregate reservations 💜. this works by using the same combos of ingress and egress identifiers for the different RSVP generic aggregate reservations, but with a different PHB-ID value (see [RFC4860]). the procedures for aggregating E2E reservations over generic aggregate RSVP reservations are the same as the ones in Section 4 of [RFC4860], plus the ones in Section 2.5 🌈
one big difference between this document and [RFC4860] is that here, admission control of E2E RSVP reservations over the PCN-core is done with the PCN procedures. over in [RFC4860], it's done by first admitting aggregate RSVP reservations over the aggregation region and then admitting the E2E reservations over those aggregate RSVP reservations 🙈. so in this document, the generic aggregate RSVP reservations are not subject to admission control in the PCN-core, and the E2E RSVP reservations are not subject to admission control over the aggregate reservations. this literally simplifies a bunch of [RFC4860] procedures 💅:
- Unlike [RFC4860], the generic aggregate RSVP reservations need not be admitted in the PCN-core.
- Unlike [RFC4860], the RSVP aggregated traffic does not need to be tunneled between Aggregator and Deaggregator; see Section 2.3.
- Unlike [RFC4860], the Deaggregator need not perform admission control of E2E reservations over the aggregate RSVP reservations.
- Unlike [RFC4860], there is no need for dynamic adjustment of the RSVP generic aggregate reservation size; see Section 2.6.
2.2. PCN-Marking, Encoding, and Transport of Pre-congestion Information 🌸
the PCN-marking inside the PCN-domain is specified in [RFC5670]. the encoding and transport of pre-congestion info is specified in [RFC6660] 🧚. the PHB-ID (Per Hop Behavior Identification Code) used SHOULD be set equal to PCN-compatible Diffserv Codepoint(s) ✨
2.3. Traffic Classification within the Aggregation Region 🎀
the PCN-ingress marks a PCN-BA using PCN-marking (a combo of the DSCP and ECN fields), and interior nodes use that to classify PCN-traffic 🦋. PCN-traffic (like E2E microflows) that belongs to an RSVP generic aggregate reservation can only be classified at the PCN-boundary-nodes (aka the Aggregator and Deaggregator), using the RSVP SESSION object for RSVP generic aggregate reservations; see Section 2.1 of [RFC4860]. note that the DSCP value in the SESSION object SHOULD be set equal to a PCN-compatible Diffserv Codepoint 💅
since no admission control procedures over the RSVP generic aggregate reservations in the PCN-core are required, unlike [RFC4860], the RSVP aggregated traffic doesn't need to be tunneled between Aggregator and Deaggregator 🫶. here, one RSVP generic aggregate reservation is mapped to only one ingress-egress-aggregate, while one ingress-egress-aggregate is mapped to one or more RSVP generic aggregate reservations. PCN-flows and their PCN-traffic that get mapped into a specific RSVP generic aggregate reservation can also easily be classified into their matching ingress-egress-aggregate 🌈. the traffic conditioning method for PCN-traffic and non-PCN-traffic, plus the PHB configuration method, are described in [RFC6661] and [RFC6662] 👑
2.4. Deaggregator (PCN-Egress-Node) Determination 💜
this document assumes the same dynamic Deaggregator determination method as the one used in [RFC4860] 🍓
2.5. Mapping E2E Reservations onto Aggregate Reservations ✨
to be compliant with this spec, the same methods MUST be used for mapping E2E reservations onto aggregate reservations as the ones in Section 4 of [RFC4860], plus the following rules 🎀:
- An Aggregator (PCN-ingress-node) or Deaggregator (PCN-egress-node and Decision Point) MUST use one or more policies to determine whether an RSVP generic aggregate reservation can be mapped into an ingress-egress-aggregate. this can be done by using the same combos of ingress and egress identifiers for the different RSVP generic aggregate reservations, but with a different PHB-ID value (see [RFC4860]) that matches the PCN specs. in particular, that's the RSVP SESSION object specified in [RFC4860], augmented with the following info:
- 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 counts as only one RSVP hop (for generic aggregate RSVP or E2E RSVP). this means 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 🦋.
- The PHB-ID (Per Hop Behavior Identification Code) SHOULD be set equal to PCN-compatible Diffserv Codepoint(s) 🌸.
- The 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 🫶
since (1) no admission control of E2E reservations over the RSVP aggregate reservations is required and (2) no admission control of the RSVP aggregate reservation over the PCN-core is required, the size of the generic aggregate reservation is irrelevant. it can be set to any arbitrary value by the Deaggregator 💅. the Deaggregator SHOULD set the value of a generic aggregate reservation to a null bandwidth. we also observe that there is no need for dynamic adjustment of the RSVP aggregate reservation size 🌈
2.7. E2E Path ADSPEC Update 🍓
to be compliant with this spec, for updating the E2E Path ADSPEC, the same methods can be used as the ones described in [RFC4860] ✨
2.8. Intra-domain Routes 👑
the PCN-interior-nodes maintain neither E2E RSVP nor RSVP generic aggregation states and reservations. so intra-domain route changes won't affect intra-domain reservations, since those reservations aren't maintained by the PCN-interior-nodes 🦋
also, it's considered that by configuration, the PCN-interior-nodes can't tell apart RSVP generic aggregate sessions and their associated messages [RFC4860], or E2E RSVP SESSIONS and their associated messages [RFC2205] 🙈
2.9. Inter-domain Routes 🌸
the PCN-charter scope rules out inter-domain considerations 🧚. however, for solving inter-domain route changes tied to the operation of RSVP messages, the same methods SHOULD be used as the ones described in [RFC4860] and in Section 1.4.7 of [RFC3175] ✨
2.10. Reservations for Multicast Sessions 🎀
PCN does not consider reservations for multicast sessions 💜
2.11. Multi-level Aggregation 💅
PCN doesn't consider multi-level aggregations within the PCN-domain. so the PCN-interior-nodes don't support multi-level aggregation procedures. however, the Aggregator and Deaggregator SHOULD support the multi-level aggregation procedures specified in [RFC4860] and in Section 1.4.9 of [RFC3175] 🌈
2.12. Reliability Issues 🫶
to be compliant with this spec, for solving possible reliability issues, the same methods MUST be used as the ones described in Section 4 of [RFC4860] 👑
3. Elements of Procedures ✨
this section describes the procedures used to implement the aggregate RSVP procedure over PCN 🧚. it's considered that the procedures for aggregating E2E reservations over generic aggregate RSVP reservations are the same as the procedures in Section 4 of [RFC4860], except where a departure from those procedures is explicitly described in this section. for the processing rules and error handling of the error cases listed below, please refer to Appendix B of [RFC2205] and Section 3 of [RFC4860] 🦋:
- Message formatting errors, e.g., incomplete message
- Unknown objects
3.1. Receipt of E2E Path Message by PCN-Ingress-Node (Aggregating Router) 🌸
when the E2E Path message arrives at the exterior interface of the Aggregator (PCN-ingress-node), 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's considered that, by configuration, the PCN-interior-nodes ignore the E2E RSVP signaling messages [RFC2205]. so the E2E Path messages are simply forwarded as normal IP datagrams 🌈
3.3. Receipt of E2E Path Message by PCN-Egress-Node (Deaggregating Router) 💖
okay so when the E2E Path message shows up, the Deaggregator (PCN-egress-node and Decision Point) does the regular [RFC4860] stuff 🧚, but with a couple of extra rules on top:
- The Deaggregator MUST NOT perform the RSVP-TTL vs. IP TTL-check (TTL = Time To Live) and MUST NOT update the ADSPEC Break bit. bestie, this is because the whole PCN-domain is basically treated by E2E RSVP as one virtual link where integrated service is actually supported (and admission control is performed). So 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, when the Aggregator (PCN-ingress-node) starts a new RSVP generic aggregate Path message, the same methods MUST be used as the ones described in [RFC4860]. no notes, just follow [RFC4860] 💅
3.5. Handling of Aggregate Path Message by Interior Routers 🫶
Aggregate Path messages can pass through zero or more PCN-interior-nodes. These nodes get the Aggregate Path message on an interior interface and send it out another interior interface. it's considered that, by configuration, the PCN-interior-nodes ignore the Aggregate Path signaling messages 🙈. so the Aggregate Path messages just get forwarded like normal IP datagrams.
3.6. Handling of Aggregate Path Message by Deaggregating Router 🔥
when the Deaggregator (PCN-egress-node and Decision Point) receives the Aggregate Path message, it does the regular [RFC4860] procedures, plus this extra rule:
- when the Aggregate Path message the Deaggregator gets has the RSVP-AGGREGATE-IPv4-PCN-response or RSVP-AGGREGATE-IPv6-PCN-response PCN objects (which carry the PCN-sent-rate), then the procedures in Section 3.18 of this document MUST be followed. main character energy 👑
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), the standard RSVP aggregation procedures of [RFC4860] are used, plus these rules:
- the E2E RSVP SESSION in an E2E Resv message that shows up at the external interface of the Deaggregator gets mapped/matched with an RSVP generic aggregate and with a PCN ingress-egress-aggregate. 🧚
- depending on which type of PCN edge behavior the Deaggregator supports, the PCN admission control procedures in Section 3.3.1 of [RFC6661] or [RFC6662] MUST be followed. ngl this part is kinda the heart of it 💖 there are no admission control procedures over the RSVP aggregate reservations in the PCN-core, unlike [RFC4860], so the Deaggregator doesn't do any admission control of the E2E reservation over the mapped generic aggregate RSVP reservation. if the PCN-based admission control works out, 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 it doesn't work out, then the E2E Resv MUST NOT be admitted onto the associated RSVP generic aggregate reservation and onto the PCN ingress-egress-aggregation 🙅♀️. either way, the E2E Resv message gets processed further 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 going through the PCN-core are IP addressed to the Aggregating router and are NOT marked with Router Alert. so they're just forwarded like normal IP datagrams 💅 (no drama, no extra steps).
3.9. Initiation of New Aggregate Resv Message by Deaggregating Router ✨
to comply with this specification, when the Deaggregator (PCN-egress-node and Decision Point) starts a new RSVP generic aggregate Resv message, the same methods MUST be used as the ones described in Section 4 of [RFC4860], plus these rules:
- 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 🍓. also, we observe that there's no need for dynamic adjustment of the RSVP generic aggregate reservation size.
- when [RFC6661] is used and the ETM-rate measured by the Deaggregator has 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 destined for the given ingress-egress-aggregate. 🔥
- 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 destined for the given ingress-egress-aggregate. 💀
- 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:
RSVP-AGGREGATE-IPv4-PCN-requestRSVP-AGGREGATE-IPv6-PCN-request
3.10. Handling of Aggregate Resv Message by Interior Routers 🧚
the Aggregate Resv messages going through the PCN-core are IP addressed to the Aggregating router and are NOT marked with Router Alert. so they're 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), the standard RSVP aggregation procedures of [RFC4860] are used. easy peasy 🌸
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), the standard RSVP aggregation procedures of [RFC4860] are used, plus these rules:
- the Aggregator SHOULD use the information carried by the PCN objects (see Section 4) and follow the steps 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 in Section 3.4 of [RFC6661] and [RFC6662] for calculating the PCN-sent-rate. in particular, the Aggregator MUST provide the estimated current rate of PCN-traffic it receives at that node and that's destined for a given ingress-egress-aggregate, in octets per second (the PCN-sent-rate). how that rate estimate gets derived is up to implementation; see [RFC6661] or [RFC6662] 🧠
- the Aggregator starts an Aggregate Path message. specifically, when the Aggregator gets an Aggregate Resv message carrying 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 starts an Aggregate Path message and puts the calculated PCN-sent-rate in the RSVP-AGGREGATE-IPv4-PCN-response or RSVP-AGGREGATE-IPv6-PCN-response PCN objects (see Section 4.1). those MUST be carried by the Aggregate Path message 🔥. this Aggregate Path message is sent towards the Deaggregator (PCN-egress-node and Decision Point) that asked for the PCN-sent-rate calculation 🎀
3.13. Removal of E2E Reservation 🦋
to comply with this specification, for removing 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 removing 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]. here's the tea: if an aggregate reservation goes away (probably because of 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 Aggregator (PCN-ingress-node) handles data on the reserved E2E flow using the procedures in [RFC4860], plus this:
- for 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. not today, bestie 🫶
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 the one 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]), there are several ways to terminate E2E microflows that can be used. the default procedure for terminating E2E microflows (i.e., PCN-flows) goes like this; see, for example, [RFC6661] and [RFC6662] 💖
for the same ingress-egress-aggregate, select a number of E2E microflows to be terminated so the total incoming bandwidth associated with that ingress-egress-aggregate drops by the amount of traffic to be terminated. in this situation, the same mechanisms for terminating an E2E microflow can be followed as the ones in [RFC2205]. however, based on local policy, the Deaggregator could pick microflows to terminate in other ways. for example, for the same ingress-egress-aggregate, select a number of E2E microflows to be terminated or to reduce their reserved bandwidth, so the total incoming bandwidth associated with that ingress-egress-aggregate drops 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 ones in Section 5 of [RFC4495]. 🦋👑
4. Protocol Elements ✨
okay bestie, this section is where the protocol elements get their PCN makeover 💅 They're borrowed from Section 4 of [RFC4860] and Section 3 of [RFC3175], and then we add a few extra rules on top 🎀
- The DSCP value in the SESSION object SHOULD be set equal to a PCN-compatible Diffserv Codepoint 🦋
- The Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination addresses of the Aggregator (PCN-ingress-node). See [RFC4860] 🌸
- When the Deaggregator (PCN-egress-node and Decision Point) needs to ask the PCN-ingress-node for the PCN-sent-rate (see Section 3.9 of this document), the Deaggregator MUST generate and send a (refresh) Aggregate Resv message to the Aggregator. That message MUST carry one of the following PCN objects (see Section 4.1), depending on whether IPv4 or IPv6 is supported 😭
- RSVP-AGGREGATE-IPv4-PCN-request
- RSVP-AGGREGATE-IPv6-PCN-request
- When the Aggregator receives an Aggregate Resv message carrying one of these 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 an Aggregate Path message to the Deaggregator. That message MUST carry one of the following PCN objects (see Section 4.1), depending on whether IPv4 or IPv6 is supported 🔥
- RSVP-AGGREGATE-IPv4-PCN-response
- RSVP-AGGREGATE-IPv6-PCN-response
4.1. PCN Objects
this part is the object lineup, and honestly it's giving very organised 🧚 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] 💜
Here are the four objects:
- RSVP-AGGREGATE-IPv4-PCN-request
- RSVP-AGGREGATE-IPv6-PCN-request
- RSVP-AGGREGATE-IPv4-PCN-response
- RSVP-AGGREGATE-IPv6-PCN-response
Now the glow-up. First up is the IPv4 request object, for when IPv4 addresses are in use 🌈
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 |
+-------------+-------------+-------------+-------------+Next is the IPv6 request object, for when IPv6 addresses are used. It's longer because each address is 16 bytes, so it's giving full scroll-length energy ✨
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 |
+-------------+-------------+-------------+-------------+Then the IPv4 response object, for when IPv4 addresses are used. This one carries the PCN-sent-rate 🦋
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 |
+-------------+-------------+-------------+-------------+And the last one is the IPv6 response object, for when 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 in the PCN object are specified in [RFC6663], [RFC6661], and [RFC6662]. Here's the tea ☕
- 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 name the ingress-egress-aggregate that the report is about. 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 🌸
- Decision Point Address: the IPv4 or IPv6 address of the Decision Point. In this document, this field MUST contain the IP address of the Deaggregator 🫶
- "R": a 1-bit flag. When it's set to ON, it signifies, according to [RFC6661] and [RFC6662], that the PCN-ingress-node (Aggregator) MUST provide an estimate of the rate (PCN-sent-rate) at which it is receiving PCN-traffic destined for the given ingress-egress-aggregate 🔥
- "Reserved": 31 bits that this document doesn't use right now, so they're reserved. They SHALL be set to 0 and SHALL be ignored on reception 🙈
- PCN-sent-rate: the estimate of the rate at which the PCN-ingress-node (Aggregator) is receiving PCN-traffic destined for the given ingress-egress-aggregate. It's expressed in octets/second, and its format is a 32-bit IEEE floating-point number. The PCN-sent-rate is specified in [RFC6661] and [RFC6662] 🌈
5. Security Considerations
ok bestie, this is the serious part, so let's get into it 🔒 The security considerations in [RFC2205], [RFC4860], and [RFC5559] apply to this document. On top of that, [RFC4230] and [RFC6411] give useful guidance on RSVP security mechanisms 💜
Security inside a PCN-domain is fundamentally based on the controlled environment trust assumption stated in Section 6.3.1 of [RFC5559]. In particular, all PCN-nodes are PCN-enabled and are trusted to perform accurate PCN-metering and PCN-marking. No cap, that's the whole foundation 😭
In the PCN-domain environments this document covers, Generic Aggregate RSVP messages specified in [RFC4860] are used to support the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre-Congestion Notification. So 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. That protects against corruption and spoofing of RSVP messages and of the PCN feedback carried in them 🛡️✨
For these reasons, this document does not introduce significant additional security considerations beyond those discussed in [RFC5559] and [RFC4860]. Phew, we're safe 💖
6. IANA Considerations
IANA has modified the "Class Names, Class Numbers, and Class Types" subregistry of the "Resource Reservation Protocol (RSVP) Parameters" registry. It added a new Class Number and assigned four new C-Types under that Class Number, as described below. See Section 4.1 🎀
Class
Number Class Name Reference
------- ---------------------- -------------
248 PCN RFC 7417Class 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 📚
Okay bestie, these are the must-reads 💅 Each one is copied exactly below so no detail gets lost 🫶
[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 🧚
These are the bonus reads 🌸 Great background if you want to go deeper, and every entry is kept exactly as written 💜
[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 ✨
okay so this appendix is bestie-level helpful 🫶 it's based on Appendix A of [RFC4860], and it walks through an example signaling flow of the specs from Sections 3 and 4. no cap, it's the cutest little story of how everything actually connects 🎀
the setup is giving: E2E reservations get aggregated over generic aggregate RSVP reservations and then applied over a PCN-domain. the Aggregator (PCN-ingress-node) and Deaggregator (PCN-egress-node) chill at the boundaries of the PCN-domain. the PCN-interior-nodes live inside the domain, between the PCN-boundary-nodes, but they're not shown in the diagram below 🦋 this is the successful setup of a unicast E2E reservation that's the very first one between a given Aggregator-Deaggregator pair. iconic start 👑
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
<-----------step (1), the Aggregator forwards E2E Path into the aggregation region after it changes its IP protocol number to RSVP-E2E-IGNORE. 💅
step (2), let's assume no Aggregate Path exists yet. to update the ADSPEC of the E2E Path accurately, the Deaggregator needs the ADSPEC of the Aggregate Path. so in this example the Deaggregator decides to tell the Aggregator to set up an Aggregate Path state for the PCN PHB-ID 🌸 it does that by sending an E2E PathErr message with a NEW-AGGREGATE-NEEDED PathErr code.
the PathErr message also carries a SESSION-OF-INTEREST (SOI) object. the SOI holds a GENERIC-AGGREGATE SESSION (GApcn) whose PHB-ID is set to the PCN PHB-ID. the GENERIC-AGGREGATE SESSION has an interface-independent Deaggregator address inside the DestAddress, plus 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. (it's a SHOULD, so that's the recommended move, not a must 🙈)
step (3), the Aggregator follows the Deaggregator's request and signals an Aggregate Path for the GENERIC-AGGREGATE SESSION (GApcn) 🧚
step (4), the Deaggregator takes the info from the ADSPEC of both Aggregate Paths into account and updates the E2E Path ADSPEC to match ✨ the PCN-egress-node MUST NOT do the RSVP-TTL vs. IP TTL-check, and it MUST NOT update the ADSPEC Break bit. why? because the whole PCN-domain is basically treated by E2E RSVP as a virtual link where integrated service is supported (and admission control happens), so the Break bit MUST NOT be set. see also [RSVP-PCN-CL] for more tea ☕ the Deaggregator also changes the E2E Path IP protocol number back to RSVP before forwarding it 💜
step (5), here the Deaggregator decides to go ahead and set up the generic aggregate reservation right away. it's basically anticipating the real demand for E2E reservations, so the generic aggregate reservation is already in place when the E2E Resv request shows up, which speeds things up 🚀 it's also assumed that the Deaggregator includes the optional ResvConfirm Request in the Aggregate Resv message.
step (6), the Aggregator just complies with the received ResvConfirm Request and sends back the matching Aggregate ResvConfirm 🫶
step (7), the Deaggregator now has explicit confirmation that the generic aggregate reservation is established 🎉
step (8), when the E2E Resv arrives, the Deaggregator applies the mapping policy set by the network administrator to map the E2E Resv onto a generic aggregate reservation. let's assume the policy says the E2E reservation maps onto the generic aggregate reservation with PCN PHB-ID=x. after step (7), the Deaggregator knows a generic aggregate reservation (GApcn) is in place for that PHB-ID. so now it maps that generic aggregate reservation onto one ingress-egress-aggregate it maintains 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). it also takes the PCN admission control procedure into account, as specified in [RFC6661] and [RFC6662]; see Section 3.7 🦋 if one or both of the admission control procedures fail (the PCN-based one described in Section 3.3.1 of [RFC6661] or [RFC6662], and the one specified in [RFC4860]), then the E2E Resv is not admitted onto the associated RSVP generic aggregate reservation for the PCN PHB-ID (GApcn) 😭 otherwise, assuming the generic aggregate reservation for the PCN (GApcn) was set up with enough bandwidth to support the E2E Resv, the Deaggregator adjusts its counter that tracks the unused bandwidth on the generic aggregate reservation. then it forwards the E2E Resv to the Aggregator, including a SESSION-OF-INTEREST object that conveys the selected mapping onto GApcn (and therefore onto the PCN PHB-ID) 🎀
step (9), the Aggregator records the mapping of the E2E Resv onto GApcn (and onto the PCN PHB-ID). then it removes the SOI object and forwards the E2E Resv towards the sender. main character energy, periodt 👑✨
Acknowledgments 🌈
we'd like to thank the authors of [RSVP-PCN-CL], since some ideas in this document are based on the work they started in [RSVP-PCN-CL]. we also want 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 their comments 💕 extra special shoutout to Francois Le Faucheur, who contributed a significant amount of text on top of 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
📦 where this page comes from
- ietf: rfc7417 2014-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms