RFC 4860
Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations
RFC 4860: Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations 🎀
- Network Working Group 🌸
- Authors: F. Le Faucheur (Cisco Systems, Inc.), B. Davie (Cisco Systems, Inc.), P. Bose (Lockheed Martin), C. Christou (Booz Allen Hamilton), M. Davenport (Booz Allen Hamilton) 👑
- Category: Standards Track ✨
- Date: May 2007 📅
- Obsoletes / Updates: none listed in this title block 🦋
Status of This Memo ✨
Okay so this document is an Internet standards track protocol spec 💅 It's meant for the whole Internet community, and the authors are literally asking for discussion and suggestions for improvements 🫶 For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) doc. Distribution of this memo is unlimited 🌈
Copyright Notice
Copyright (C) The IETF Trust (2007). 🔥
Abstract 🧚
Bestie, [RFC 3175] is the one that defines aggregate RSVP reservations 💖 These let resources get reserved in a Diffserv network for a given Per Hop Behavior (PHB), or a given set of PHBs, going from a given source to a given destination. RFC 3175 also explains how end-to-end RSVP reservations can get aggregated onto those aggregate reservations when they travel through a Diffserv cloud 🌸
Here's the problem 😭 There are situations where you need multiple aggregate reservations for the same source IP address, destination IP address, and PHB (or set of PHBs). RFC 3175's aggregate reservations don't support that. So this document defines a more flexible kind of aggregate RSVP reservation, called a generic aggregate reservation ✨ You can now set up multiple generic aggregate reservations for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address 🎀
These generic aggregate reservations can be used to aggregate end-to-end RSVP reservations, and this document also defines the procedures for that aggregation. And they can also be used end-to-end, directly by end-systems attached to a Diffserv network. Main character energy 👑
Table of Contents 🦋
1. Introduction ....................................................3
1.1. Related IETF Documents .....................................6
1.2. Organization of This Document ..............................6
1.3. Requirements Language ......................................7
2. Object Definition ...............................................7
2.1. SESSION Class ..............................................8
2.2. SESSION-OF-INTEREST (SOI) Class ...........................11
3. Processing Rules for Handling Generic Aggregate RSVP
Reservations ...................................................13
3.1. Extensions to Path and Resv Processing ....................13
4. Procedures for Aggregation over Generic Aggregate RSVP
Reservations ...................................................14
5. Example Usage Of Multiple Generic Aggregate Reservations
per PHB from a Given Aggregator to a Given Deaggregator ........19
6. Security Considerations ........................................21
7. IANA Considerations ............................................24
8. Acknowledgments ................................................25
9. Normative References ...........................................26
10. Informative References ........................................26
Appendix A. Example Signaling Flow ................................281. Introduction ✨
Okay so [RSVP-AGG] is the spec that defines RSVP aggregate reservations 🌷 They let resources get reserved in a Diffserv network for a flow identified by its 3-tuple <source IP address, destination IP address, Diffserv Code Point> 💅
[RSVP-AGG] also defines how end-to-end (E2E) RSVP reservations get aggregated onto those aggregate reservations when they transit a Diffserv cloud 🦋 Figure 1 shows what that looks like. This document reuses the terminology from [RSVP-AGG], so you'll see the same words 🫶
--------------------------
/ Aggregation \
|----| | Region | |----|
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
Deag = Deaggregator
I = Interior Router
--> = E2E RSVP reservation
==> = Aggregate RSVP reservation
Figure 1 : Aggregation of E2E Reservations
over Aggregate RSVP ReservationsSo these aggregate reservations use a SESSION type that [RSVP-AGG] specifies 🍓 It holds the receiver (or Deaggregator) IP address and the Diffserv Code Point (DSCP) of the Per Hop Behavior (PHB) that Diffserv resources are to be reserved from. For example, for IPv4, the SESSION object looks like this 🧚
o Class = SESSION,
C-Type = RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Session Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+These aggregate reservations also use the SENDER_TEMPLATE and FILTER_SPEC types from [RSVP-AGG], and those only carry the sender (or Aggregator) IP address 💜 For IPv4, the SENDER_TEMPLATE object looks like this:
o Class = SENDER_TEMPLATE,
C-Type = RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Aggregator Address (4 bytes) |
+-------------+-------------+-------------+-------------+So from a given source IP address to a given destination IP address, you can set up separate aggregate reservations for different PHBs (or different sets of PHBs) 🌈 BUT 😭 from a given source to a given destination, only a single [RSVP-AGG] aggregate reservation can exist for a given PHB (or given set of PHBs). That's the limit we're here to fix 💀
Situations have since come up where you need multiple aggregate reservations for the same source IP address, destination IP address, and PHB (or set of PHBs) 🙈 One example: E2E reservations using different preemption priorities (per [RSVP-PREEMP]) need to be aggregated through a Diffserv cloud using the same PHB. Using multiple aggregate reservations for the same PHB lets you enforce those different preemption priorities inside the aggregation region 🔥 That means Diffserv resources get managed more efficiently, and when resources are scarce, you can keep a bigger number of E2E reservations with higher preemption priorities alive 👑
For example, [SIG-NESTED] goes into detail on how end-to-end RSVP reservations can be set up in a nested VPN environment through RSVP aggregation 🌸 In particular, it describes how multiple parallel generic aggregate reservations (for the same PHB), each with different preemption priorities, can efficiently support the preemption priorities of end-to-end reservations. Iconic 🦋
This document answers that need for multiple aggregate reservations on the same PHB (or same set of PHBs). It does this by defining the more flexible kind of aggregate RSVP reservation, the generic aggregate reservation 💖 The main trick is adding two notions to the RSVP SESSION object: a Virtual Destination Port and an Extended Virtual Destination Port ✨
The notion of Virtual Destination Port was introduced in [RSVP-IPSEC] to solve a similar requirement (in a different context) for identifying and demultiplexing sessions beyond the IP destination address 🎀 This document reuses that notion from [RSVP-IPSEC] to identify and demultiplex generic aggregate sessions beyond the IP destination address and PHB. So multiple generic aggregate reservations can be set up for a given PHB (or set of PHBs), from a given source IP address to a given destination IP address 🫶
Next, [RSVP-TE] introduced the concept of an Extended Tunnel ID (on top of the tunnel egress address and the Tunnel ID) in the SESSION object. That object is used to set up MPLS Traffic Engineering tunnels with RSVP 🧚 The Extended Tunnel ID is a really handy way for the tunnel ingress node to narrow the scope of the session down to the ingress-egress pair. The ingress node can do this by using one of its own IP addresses as a globally unique identifier and putting it into the Extended Tunnel ID, and therefore into the SESSION object 💅 This document reuses the Extended Tunnel ID notion from [RSVP-TE], just renaming it Extended Virtual Destination Port. That gives you a convenient way to narrow the scope of a generic aggregate session down to an Aggregator-Deaggregator pair 🌷
The RSVP SESSION object for generic aggregate reservations uses the PHB Identification Code (PHB-ID) defined in [PHB-ID] to identify the PHB, or set of PHBs, that the Diffserv resources come from 🍓 This replaces using the Diffserv Code Point (DSCP) like [RSVP-AGG] does. Using the PHB-ID instead of the DSCP lets you explicitly indicate whether the Diffserv resources belong to a single PHB or to a set of PHBs 💜 It also helps when a generic aggregate reservation spans two (or more) Diffserv domains that use different DSCP values for the same Diffserv PHB (or set of PHBs). The reason is that the PHB-ID conveys the PHB (or set of PHBs) on its own, no matter which DSCP value(s) are used locally for it 🌈
Generic aggregate reservations can be used to aggregate end-to-end RSVP reservations, and this document defines the procedures for that aggregation too 🔥 Those procedures are based on the ones in [RSVP-AGG], and this document only specifies the differences from them 👑 And again, generic aggregate reservations may also be used end-to-end, directly by end-systems attached to a Diffserv network 🦋 Slay 💅
1.1. Related IETF Documents
Okay so this doc is lowkey built on [RSVP-AGG] 💖 It reuses [RSVP-AGG] wherever that works and only specifies the extra stuff it needs on top of it ✨
The mechanisms in [BW-REDUC] let an existing reservation shrink its allocated bandwidth, so RSVP routers can do that instead of tearing the whole reservation down 🦋 Those mechanisms apply to the generic aggregate reservations defined in this document.
[RSVP-TUNNEL] describes a general approach to running RSVP over different types of tunnels 🌸 One of them, the "type 2 tunnel", is kinda similar to the generic aggregate reservations here. A single aggregate reservation gets made for the tunnel while lots of individual flows ride through it. BUT [RSVP-TUNNEL] doesn't cover using Diffserv-based classification and scheduling in the core of a network (between tunnel endpoints). It just relies on a UDP/IP tunnel header for classification 🙈 That's why [RSVP-AGG] needed extra objects and procedures beyond [RSVP-TUNNEL]. This document is giving the same energy: it also assumes Diffserv-based classification and scheduling in the aggregation region, so it needs extra objects and procedures beyond [RSVP-TUNNEL] too 💅
As explained earlier, this document reuses the Virtual Destination Port idea from [RSVP-IPSEC] and the Extended Tunnel ID idea from [RSVP-TE] 🫶
1.2. Organization Of This Document
Here's the tea on how this doc is laid out 🍓 Section 2 defines the new RSVP objects for generic aggregate reservations and for aggregating E2E reservations onto them. Section 3 covers the processing rules for handling generic aggregate reservations. Section 4 specifies the procedures for aggregating end-to-end RSVP reservations over generic aggregate RSVP reservations. Section 5 gives example usage of how generic aggregate reservations may be used.
The Security Considerations and the IANA Considerations are in Sections 6 and 7, respectively 🔐
Finally, Appendix A walks through an example signaling flow that shows E2E RSVP reservations getting aggregated onto generic aggregate RSVP reservations 🧚
1.3. Requirements Language
Keyword time 🎀 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 RFC 2119 [KEYWORDS].
2. Object Definition ✨
This doc reuses the RSVP-AGGREGATE-IP4 FILTER_SPEC, RSVP-AGGREGATE-IP6 FILTER_SPEC, RSVP-AGGREGATE-IP4 SENDER_TEMPLATE, and RSVP-AGGREGATE-IP6 SENDER_TEMPLATE objects that were defined in [RSVP-AGG] 🌈
This document defines:
- two new objects (GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION) under the existing SESSION Class, and
- two new objects (GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI) under a brand new SESSION-OF-INTEREST Class.
Detailed descriptions of these objects are coming up below in this section 👑
The GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION objects are applicable to all types of RSVP messages 💜
This specification uses the GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI objects in two situations:
- inside an E2E PathErr message that carries an error code of NEW-AGGREGATE-NEEDED, to convey the session of a new generic aggregate reservation that needs to be set up.
- inside an E2E Resv message, to convey the session of the generic aggregate reservation that this E2E reservation needs to be mapped onto.
The procedures for these are in Section 4 🦋
But wait, there's more 😭 It's envisioned that being able to signal, inside RSVP messages, the Session of another reservation (one that has some relationship with the current RSVP reservation) might be useful for other stuff in the future. So those objects were specified in a more generic way under a flexible SESSION-OF-INTEREST class 🧚
All the new objects defined in this document are optional with respect to RSVP, so general RSVP implementations that don't care about generic aggregate reservations don't have to support them 🫶 RSVP routers supporting generic aggregate IPv4 or IPv6 reservations MUST support the GENERIC-AGGREGATE-IP4 SESSION object or the GENERIC-AGGREGATE-IP6 SESSION object, respectively. RSVP routers supporting RSVP aggregation over generic aggregate IPv4 or IPv6 reservations MUST support the GENERIC-AGG-IP4-SOI object or GENERIC-AGG-IP6-SOI object, respectively. 🔥
2.1. SESSION Class
- GENERIC-AGGREGATE-IP4 SESSION object:
Class = 1 (SESSION)
C-Type = 17 0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31IPv4 DestAddress (IPv4 Destination Address)
This is the IPv4 address of the receiver (or Deaggregator) 💖
Reserved
An 8-bit field. All bits MUST be set to 0 on transmit. This field MUST be ignored on receipt. 🙅♀️
Flags
An 8-bit field. Its content and processing are the same as for the Flags field of the IPv4/UDP SESSION object (see [RSVP]) ✨
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, that Diffserv resources are to be reserved from. This field MUST be encoded as specified in Section 2 of [PHB-ID] 🍓
Reserved
A 16-bit field. All bits MUST be set to 0 on transmit. This field MUST be ignored on receipt. 💅
VDstPort (Virtual Destination Port)
A 16-bit identifier used in the SESSION that stays constant over the life of the generic aggregate reservation 🦋
Extended vDstPort (Extended Virtual Destination Port)
A 32-bit identifier used in the SESSION that stays constant over the life of the generic aggregate reservation. A sender (or Aggregator) that wants to narrow the scope of a SESSION to the sender-receiver pair (or Aggregator-Deaggregator pair) SHOULD place its IPv4 address here as a network unique identifier. A sender (or Aggregator) that wants to use a common session with other senders (or Aggregators) so they can share a reservation across senders (or Aggregators) MUST set this field to all zeros. 🌸
- GENERIC-AGGREGATE-IP6 SESSION object:
Class = 1 (SESSION)
C-Type = 18 0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| |
+ +
| Extended vDstPort |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7 8 15 16 25 26 31IPv6 DestAddress (IPv6 Destination Address)
This is the IPv6 address of the receiver (or Deaggregator) 👑
Reserved
An 8-bit field. All bits MUST be set to 0 on transmit. This field MUST be ignored on receipt. 🙅♀️
Flags
An 8-bit field. Its content and processing are the same as for the Flags field of the IPv6/UDP SESSION object (see [RSVP]) 🌈
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, that Diffserv resources are to be reserved from. This field MUST be encoded as specified in Section 2 of [PHB-ID] 🍓
Reserved
A 16-bit field. All bits MUST be set to 0 on transmit. This field MUST be ignored on receipt. 💅
VDstPort (Virtual Destination Port)
A 16-bit identifier used in the SESSION that stays constant over the life of the generic aggregate reservation 🦋
Extended vDstPort (Extended Virtual Destination Port)
A 128-bit identifier used in the SESSION that stays constant over the life of the generic aggregate reservation. A sender (or Aggregator) that wants to narrow the scope of a SESSION to the sender-receiver pair (or Aggregator-Deaggregator pair) SHOULD place its IPv6 address here as a network unique identifier. A sender (or Aggregator) that wants to use a common session with other senders (or Aggregators) so they can share a reservation across senders (or Aggregators) MUST set this field to all zeros. 😭💜
2.2. SESSION-OF-INTEREST (SOI) Class ✨
okay so the SESSION-OF-INTEREST (SOI) object is giving "I'm a copy of someone else's session" 💅 It lives under Class = 132 and comes in two flavours:
- GENERIC-AGG-IP4-SOI object:
Class = 132,C-Type = 1
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| |
// Content of a GENERIC-AGGREGATE-IP4 SESSION Object //
| |
+-------------+-------------+-------------+-------------+Content of a GENERIC-AGGREGATE-IP4 SESSION Object:
This field holds a copy of the SESSION object for the session that the reservation is interested in 🫶 For GENERIC-AGG-IP4-SOI, the session of interest in this field is a GENERIC-AGGREGATE-IP4 SESSION.
- GENERIC-AGG-IP6-SOI object:
Class = 132,C-Type = 2
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP6- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| |
// Content of a GENERIC-AGGREGATE-IP6 SESSION Object //
| |
+-------------+-------------+-------------+-------------+Content of a GENERIC-AGGREGATE-IP6 SESSION Object:
Same energy as the IPv4 one, just for the IPv6 crew 🌈 This field holds a copy of the SESSION object for the session of interest. For GENERIC-AGG-IP6-SOI, that session is a GENERIC-AGGREGATE-IP6 SESSION.
Here's an example that makes it click ✨ Say a SESSION-OF-INTEREST object rides inside an E2E Resv message (following the procedures in Section 4) to say which generic aggregate IPv4 session the E2E reservation should get mapped onto. Then you use the GENERIC-AGG-IP4-SOI object, encoded like this:
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+--+----------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31⚠️ bestie, don't mix these up: a SESSION-OF-INTEREST object is not a SESSION object in itself 🙈 It doesn't replace the SESSION object in RSVP messages, and it doesn't change how the SESSION object is used there either. It just lets you carry another RSVP reservation's Session inside RSVP signalling messages for specific purposes. In this document, it's how an E2E RSVP message for an end-to-end reservation carries the Session of the generic aggregate reservation tied to that E2E reservation. The details of those procedures are in Section 4 💜
3. Processing Rules for Handling Generic Aggregate RSVP Reservations 🎀
okay this section is the rulebook for how nodes handle the new stuff 📜 It extends the RSVP message processing that [RSVP] requires and that [RSVP-PROCESS] lays out. The extensions are needed so you can properly process the GENERIC-AGGREGATE-IP4 or GENERIC-AGGREGATE-IP6 SESSION object and the RSVP-AGGREGATE-IP4 or RSVP-AGGREGATE-IP6 FILTER_SPEC object. Error code values for the referenced errors live in [RSVP] 🧚 Same as the other RSVP docs, the values for internally reported (API) errors aren't defined.
When I say GENERIC-AGGREGATE-IP4 and GENERIC-AGGREGATE-IP6 SESSION objects, I'm dropping the IP version, so they're just GENERIC-AGGREGATE SESSION, unless we actually need to tell IPv4 and IPv6 apart 💅
Same deal for [RSVP-AGG]: RSVP-AGGREGATE-IP4 and RSVP-AGGREGATE-IP6 SESSION, FILTER_SPEC, and SENDER_TEMPLATE objects all get shortened to RSVP-AGGREGATE, unless the IPv4/IPv6 difference matters for the point we're making 🦋
3.1. Extensions to Path and Resv Processing
Let's go through the PATH message processing changes first 🛣️
- When a session is defined using the GENERIC-AGGREGATE SESSION object, only the [RSVP-AGG] RSVP-AGGREGATE SENDER_TEMPLATE may be used. If this condition is violated in a PATH message received by an RSVP end-station, the RSVP end-station SHOULD report a "Conflicting C-Type" API error to the application. If this condition is violated in a PATH message received by an RSVP router, the RSVP router MUST consider this as a message formatting error.
- For PATH messages that contain the GENERIC-AGGREGATE SESSION object, the VDstPort value, the Extended VDstPort value, and the PHB-ID value should be recorded (in addition to the destination/Deaggregator address and source/Aggregator address) ✨ These values form part of the recorded state of the session. The PHB-ID may need to be passed to traffic control 🚦 However, the vDstPort and Extended VDstPort are not passed to traffic control, because they don't show up inside the data packets of the matching reservation.
Next up are the RESV message processing changes 💖
- When a RESV message contains a [RSVP-AGG] RSVP-AGGREGATE FILTER_SPEC, the session MUST be defined using either the RSVP-AGGREGATE SESSION object (as per [RSVP-AGG]) or the GENERIC-AGGREGATE SESSION object (as per this document). If this condition isn't met, an RSVP router or end-station MUST consider that there's a message formatting error 🙅♀️
- When the RSVP-AGGREGATE FILTER_SPEC is used and the SESSION type is GENERIC-AGGREGATE, each node uses data classifiers like this:
- To do Diffserv classification, the node MUST rely on the Diffserv data classifier based only on the DSCP 🎯 The relevant DSCP value(s) are the ones associated with the PHB-ID of the generic aggregate reservation.
- If the node also needs fine-grain classification (say, for fine-grain input policing at a trust boundary) then the node MUST create a data classifier described by the 3-tuple <DestAddress, SrcAddress, DSCP>. The relevant DSCP value(s) are again the ones associated with the PHB-ID of the generic aggregate reservation 🍓
- Heads up, though 👀 if multiple generic aggregate reservations are set up with different Virtual Destination Ports (and/or different Extended Virtual Destination Ports) but the same <DestAddress, SrcAddress, PHB-ID>, the classifier can't tell them apart. So if the router uses the classifier for policing, it will police those together, and it MUST program the policing rate to the sum of the reserved rate across all the matching reservations 💜
4. Procedures for Aggregation over Generic Aggregate RSVP Reservations ✨
okay so the way E2E reservations get aggregated over generic aggregate RSVP reservations is basically the same as in [RSVP-AGG] 💅 the only differences are the changes listed in this section, so lets get into them 🫶
As [RSVP-AGG] says, the Deaggregator is the one in charge of mapping a given E2E reservation onto a given aggregate reservation 👑 when it wants a brand new aggregate reservation, it sends the Aggregator an E2E PathErr message with the error code NEW-AGGREGATE-NEEDED. In [RSVP-AGG], the Deaggregator tells the Aggregator the DSCP for that new aggregate reservation by putting a DCLASS Object in the E2E PathErr and encoding the DSCP inside. This document changes and extends that procedure, so it's giving upgrade 🦋
The Deaggregator MUST include a SESSION-OF-INTEREST object in the E2E PathErr message, and that object has to carry the GENERIC-AGGREGATE SESSION to use for setting up the requested generic aggregate reservation 💖 since that GENERIC-AGGREGATE SESSION already has the PHB-ID in it, the DCLASS object doesn't need to be in the PathErr message at all. Literally one less thing to pack 🎀
Also, the Deaggregator can totally make sure different Aggregators end up using different sessions for their Aggregate Path toward it 🧚 it does this by picking VDstPort and/or Extended VDstPort numbers that are different for each Aggregator (for example, using the Aggregator address as the Extended VDstPort), then telling them those values inside the GENERIC-AGGREGATE SESSION in the SESSION-OF-INTEREST object. That's a super easy way to get separate reservations from every Aggregator to one Deaggregator 🌸 and if the Aggregators actually should share a reservation, the Deaggregator can give all of them the same VDstPort and Extended VDstPort. That means the same GENERIC-AGGREGATE SESSION goes inside the SESSION-OF-INTEREST in each of the E2E PathErr messages, and all the Aggregators can set up an Aggregate Path with that one session 🤝
So yeah, lots of sharing scenarios are easy to support ✨ which Aggregators get shared or separate reservations is decided by Deaggregator policy, and that policy is beyond the scope of this document 🙈
The Deaggregator MAY also put extra RSVP objects in the E2E PathErr message (with the error code NEW-AGGREGATE-NEEDED), and those objects are for setting up the newly needed generic aggregate reservation 💅 for example, the Deaggregator MAY include an RSVP Signaled Preemption Priority Policy Element (as specified in [RSVP-PREEMP]).
The [RSVP-AGG] procedures for how the Aggregator handles an E2E PathErr with the error code NEW-AGGREGATE-NEEDED get extended in a matching way. When the Aggregator gets one of these with a SESSION-OF-INTEREST object, it MUST trigger setup of a generic aggregate reservation 🔥 specifically, it MUST start sending aggregate Path messages using the GENERIC-AGGREGATE SESSION found in that SESSION-OF-INTEREST object. If the received E2E PathErr has an RSVP Signaled Preemption Priority Policy Element, the Aggregator MUST include that object in the Aggregate Path for the matching generic aggregate reservation 😭 if the E2E PathErr has other extra objects that can clearly be read as belonging to the new generic aggregate reservation (and not to the E2E reservation), the Aggregator SHOULD include those in that Aggregate Path too. And for the Source Address (aka the Aggregator Address in the Sender-Template) of the generic aggregate reservation, the Aggregator MUST use the address it uses to identify itself as the PHOP (RSVP previous hop) when it forwards the E2E Path messages that go with that E2E PathErr 🌈
The Deaggregator follows the same [RSVP-AGG] procedures for setting up, keeping alive, and clearing the aggregate Resv state 🦋 the big difference is that a Deaggregator following this spec MUST use generic aggregate reservations, which means using the GENERIC-AGGREGATE SESSION we talked about earlier in this document 💜
This document also changes how E2E Resv messages get swapped between the Deaggregator and the Aggregator 🫶 the Deaggregator MUST include the new SESSION-OF-INTEREST object in the E2E Resv message, so the Aggregator knows which generic aggregate session to map that E2E reservation onto. Again, the GENERIC-AGGREGATE SESSION inside the SESSION-OF-INTEREST already has the PHB-ID, so the DCLASS object doesn't need to be in the E2E Resv message either 🎀 the Aggregator MUST read the SESSION-OF-INTEREST in the E2E Resv as saying which generic aggregate reservation session that E2E reservation gets mapped onto. And the Aggregator MUST not include the SESSION-OF-INTEREST object when it sends an E2E Resv upstream toward the sender 🙅♀️
Heads up: the SESSION-OF-INTEREST object only goes in the E2E Resv heading from the Deaggregator to the Aggregator. It never goes back upstream toward the sender 💀
Depending on relevant policy, the Deaggregator may decide at some point that an aggregate reservation isn't needed anymore and should be torn down 🥀 when that happens, the Deaggregator MUST send an aggregate ResvTear. Once the Aggregator gets that aggregate ResvTear, it SHOULD send an aggregate PathTear, unless its relevant policy says to do something different or to wait a while first (for example, so it can speed up re-establishing that aggregate reservation later) ⭐
[RSVP-AGG] explains how the Aggregator and Deaggregator tell each other who they are 🧚 for example, the Aggregator puts one of its IP addresses in the RSVP HOP object of the E2E Path that goes downstream, and the Deaggregator gets that after it crosses the aggregation region. Same deal the other way: the Deaggregator tells the Aggregator who it is by including one of its IP addresses in a bunch of fields, including the ERROR SPECIFICATION of the E2E PathErr message (the one with the NEW-AGGREGATE-NEEDED error code) and in the RSVP HOP object of the E2E Resv message. The thing is, [RSVP-AGG] doesn't talk about which IP addresses the Aggregator and Deaggregator should pick for these jobs 🙈 since these addresses are supposed to identify the Aggregator and Deaggregator themselves (not some specific interface on those boxes), this document RECOMMENDS that the Aggregator and Deaggregator SHOULD use interface-independent addresses (like a loopback address) whenever they tell each other who they are 💖 that way, identification doesn't get messed up by any interface state change on these devices. And that means more stable operations and way less RSVP signaling inside the aggregation region 🌸 For example, if both sides use interface-independent addresses, an interface failure on one of them might just reroute a given generic aggregate reservation, but the reservation won't have to be torn down and a new one set up. It also won't change how E2E reservations are mapped onto generic aggregate reservations (as long as the Aggregator and Deaggregator still have reachability after the failure, and they're still on the shortest path to the destination) 👑
BUT, when they're identifying themselves to real RSVP neighbors (meaning neighbors that aren't on the other side of the aggregation region), the Aggregator and Deaggregator SHOULD keep using interface-dependent addresses like regular [RSVP] procedures say 🥹 this goes for stuff like the Aggregator identifying itself downstream as a PHOP for the generic aggregate reservation, or identifying itself upstream as a NHOP (RSVP next hop) for an E2E reservation. It also goes for the Deaggregator identifying itself downstream as a PHOP for the E2E reservation, or identifying itself upstream as a NHOP for the generic aggregate reservation. And for processing generic aggregate reservations, interior routers (aka routers inside the aggregation region) SHOULD keep using interface-dependent addresses as regular [RSVP] procedures say 🧚
Overall, inside the aggregation region (between the Aggregator and the Deaggregator), RSVP should be thought of as E2E reservations getting mapped onto aggregate reservations, and those E2E reservations aren't tied to physical interfaces anymore (unlike regular RSVP) 🦋 but generic aggregate reservations (inside the region) and E2E reservations (outside the region) keep the regular RSVP model and stay tied to physical interfaces 💅
As we covered above, generic aggregate reservations can be set up edge-to-edge because E2E reservations from outside the aggregation region are getting aggregated across it 🌈 but generic aggregate reservations can also be used end-to-end by end-systems that are directly attached to a Diffserv domain, like Public Switched Telephone Network (PSTN) gateways 📞 in that case, the end-systems can set up the generic aggregate reservations in response to application-level triggers, like voice call signaling 🎀 Or, generic aggregate reservations can be used edge-to-edge to manage bandwidth in a Diffserv cloud even when RSVP isn't being used end-to-end 🌸 a simple example is statically configuring a generic aggregate reservation for a certain bandwidth for traffic going from an ingress (Aggregator) router to an egress (Deaggregator) router 🍓
In that case, configuration on the Aggregator and on the Deaggregator is what controls setting up the generic aggregate reservations ✨ configuration on the Aggregator triggers creation of the aggregate Path message and gives the Aggregator enough info to work out what goes in the GENERIC-AGGREGATE SESSION object. That typically includes the Deaggregator IP address, the PHB-ID, and maybe the VDstPort. Configuration on the Deaggregator tells it to respond to a received generic aggregate Path message, and gives it enough info to control the reservation 🧚 that can include the bandwidth the Deaggregator should reserve for a given <Deaggregator, PHB-ID, VDstPort> tuple 💜
And last but not least: when there aren't any E2E microflow reservations, the Aggregator can use a bunch of different policies to set the DSCP on packets going into the aggregation region, and to decide how they get mapped onto generic aggregate reservations 👑 that decides whether those packets actually get to use the resources reserved by the aggregate reservation. These policies are local configuration, just like it is for any device at the edge of a Diffserv cloud 🫧
5. Example Usage Of Multiple Generic Aggregate Reservations per PHB from a Given Aggregator to a Given Deaggregator ✨
Okay bestie, let's walk through a full example 🦋 RSVP aggregation is used here to support E2E reservations between Cloud-1, Cloud-2, and Cloud-3. Picture this layout:
I----------I I----------I
I Cloud-1 I I Cloud-2 I
I----------I I----------I
| |
Agg-Deag-1------------ Agg-Deag-2
/ \
/ Aggregation |
| Region |
| |
| ---/
\ /
\Agg-Deag-3---------/
|
I----------I
I Cloud-3 I
I----------IFigure 2 : Example Usage of Generic Aggregate IP Reservations
Okay so, here are the assumptions we're working with 💅
o The E2E reservations from Cloud-1 to Cloud-3 have a preemption of either P1 or P2. 💖
o The E2E reservations from Cloud-2 to Cloud-3 have a preemption of either P1 or P2. 🌸
o The E2E reservations are only for Voice, which needs to be treated in the aggregation region using the EF (Expedited Forwarding) PHB. 🎀
o Traffic from the E2E reservations is encapsulated in aggregate IP reservations from Aggregator to Deaggregator using Generic Routing Encapsulation [GRE] tunneling. 🧚
So, following that, the following generic aggregate RSVP reservations may be established from Agg-Deag-1 to Agg-Deag-3 for aggregating the end-to-end RSVP reservations. It's giving organized 🫶
(1) A first generic aggregate reservation for aggregation of Voice reservations from Cloud-1 to Cloud-3 requiring use of P1:
* GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress = Agg-Deag-3
vDstPort = V1
PHB-ID = EF
Extended VDstPort = Agg-Deag-1
* STYLE = FF or SE
* IPv4/GPI FILTER_SPEC:
IPv4 SrcAddress = Agg-Deag-1
* POLICY_DATA (PREEMPTION_PRI) = P1(2) A second generic aggregate reservation for aggregation of Voice reservations from Cloud-1 to Cloud-3 requiring use of P2:
* GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress = Agg-Deag-3
vDstPort = V2
PHB-ID = EF
Extended VDstPort = Agg-Deag-1
* STYLE = FF or SE
* IPv4/GPI FILTER_SPEC:
IPv4 SrcAddress = Agg-Deag-1
* POLICY_DATA (PREEMPTION_PRI) = P2where V1 and V2 are arbitrary VDstPort values picked by Agg-Deag-3. 🍓
The following generic aggregate RSVP reservations may be established from Agg-Deag-2 to Agg-Deag-3 for aggregating the end-to-end RSVP reservations. Same energy, different Cloud 🌈
(3) A third generic aggregate reservation for aggregation of Voice reservations from Cloud-2 to Cloud-3 requiring use of P1:
* GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress = Agg-Deag-3
vDstPort = V3
PHB-ID = EF
Extended VDstPort = Agg-Deag-2
* STYLE = FF or SE
* IPv4/GPI FILTER_SPEC:
IPv4 SrcAddress = Agg-Deag-2
* POLICY_DATA (PREEMPTION_PRI) = P1(4) A fourth generic aggregate reservation for aggregation of Voice reservations from Cloud-2 to Cloud-3 requiring use of P2:
* GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress = Agg-Deag-3
vDstPort = V4
PHB-ID = EF
Extended VDstPort = Agg-Deag-2
* STYLE = FF or SE
* IPv4/GPI FILTER_SPEC:
IPv4 SrcAddress = Agg-Deag-2
* POLICY_DATA (PREEMPTION_PRI) = P2where V3 and V4 are arbitrary VDstPort values picked by Agg-Deag-3. 🎀
Note that V3 and V4 could be equal to V1 and V2 (respectively), since in this example the Extended VDstPort of the GENERIC-AGGREGATE Session contains the address of the Aggregator. That means it ensures different sessions are used from each Aggregator. This is literally the main character move 👑💅
6. Security Considerations ✨
okay bestie, security is where things get serious 🔒💀. RSVP messages are what control the resource reservations for generic aggregate reservations, and they might also control the E2E reservations that get aggregated over them. To keep the reservation and admission control stuff trustworthy, the RSVP Authentication mechanisms from [RSVP-CRYPTO1] and [RSVP-CRYPTO2] may be used. They protect RSVP messages hop-by-hop, give you node authentication and replay protection, and guard against corrupted or spoofed RSVP messages 🛡️. These hop-by-hop integrity tools work really well for the RSVP messages used for generic aggregate reservations, and for E2E RSVP messages sitting outside the aggregation region. They can also protect E2E RSVP messages when they transit through the aggregation region, because the Aggregator and Deaggregator act like RSVP neighbors from the E2E flows' point of view. That's true even when they aren't actually IP neighbors 🦋.
[RSVP-CRYPTO1] talks about a few ways to do key distribution 🔑. The first is manual distribution of the RSVP Authentication shared keys. This is the base option, and every implementation is mandated to support it. The catch is that it can become a real burden in some environments if the keys change often. The other option is to use a standard key management protocol for secure key distribution. Still, existing key distribution protocols might not fit every environment, since they can be complicated or a lot of operational work 🥱.
Things get trickier where RSVP neighbors can have one or more IP hops between them. With some RSVP messages, like a Path message, an RSVP router doesn't know the RSVP next hop at the time it forwards the message 🤯. Finding the RSVP next hop is literally the job of a Path message, and it re-discovers that next hop whenever it changes, say after a routing change. That means the router might not know which security association to use when forwarding the message. This gets especially spicy when you want RSVP Authentication to protect E2E messages, like E2E Path, while they transit an aggregation region that uses the dynamic Deaggregator determination procedure from [RSVP-AGG]. The Aggregator and Deaggregator act as RSVP neighbors for the E2E reservation even with one or more IP hops in between, and the Aggregator doesn't know ahead of time which router will end up as the Deaggregator 😭.
One way to handle that situation is to share the same RSVP Authentication shared key across all the RSVP routers in a part of the network where RSVP neighbors might have IP hops between them. For example, all the Aggregators or Deaggregators in an aggregation region could share one RSVP Authentication key. Meanwhile, different per-neighbor keys could be used between any RSVP router pair straddling the boundary between two administrative domains that have agreed to use RSVP signaling 🌸.
When one RSVP Authentication shared key has to be shared among multiple RSVP neighbors, manual key distribution may be used. For RSVP multicast flows, it might also become possible in the future to adapt a multicast key management method (e.g. from IETF Multicast Security Working Group) for key distribution in that kind of multicast RSVP usage 👀. For RSVP unicast flows that cross domain boundaries, it isn't currently clear how automated key management could work 🤷♀️.
Specifying an actual automated key management technique is outside the scope of this document 🙅♀️. Operators should think through these key management issues before they deploy this specification 🧐.
The RSVP Authentication mechanisms don't provide confidentiality, so if you need that, IPsec ESP [IPSEC-ESP] may be used 🔐. Just know it adds the burden of key distribution, and it runs into the same key management issue from above when there can be IP hops between RSVP hops. Confidentiality solutions for the case with IP hops between RSVP hops might get developed in the future, maybe by adapting confidentiality solutions from the IETF MSEC Working Group. Those RSVP confidentiality solutions are outside the scope of this document ✨.
RSVP Authentication also doesn't protect against traffic analysis 👁️. Generic aggregate reservations are meant to reserve resources collectively for a whole set of users or hosts. So if someone snoops on the corresponding RSVP messages, they could learn way more traffic analysis info than they could from snooping an E2E reservation 😬. When RSVP neighbors are directly attached, things like bulk link encryption might be used if you need protection against traffic analysis. That approach could be used inside the aggregation region to protect the generic aggregate reservations, and it may also be used outside the aggregation region to protect the E2E reservation. It isn't applicable, though, to protecting E2E reservations while their E2E RSVP messages transit through the aggregation region 🙈.
When generic aggregate reservations are used to aggregate E2E reservations, the security considerations in [RSVP-AGG] apply, and they get revisited here 🔁.
First up, if an aggressor manages to take over an aggregate reservation, the E2E flows end up operating unreserved 📉. Reserving a great excess of bandwidth might also end up causing a denial of service 🚫. Those issues aren't unique to the extensions in this document, since RSVP itself has them. But they can get worse here, because each aggregate reservation usually facilitates communication for many sessions. So compromising one aggregate reservation can do way more damage than compromising a typical E2E reservation 💥. Using the RSVP Authentication mechanisms to guard against these attacks has already been discussed above 🛡️.
There's also an extra security consideration that's specific to RSVP aggregation. It involves modifying the IP protocol number in RSVP Path messages that traverse an aggregation region 🕵️♀️. If someone maliciously changes the IP protocol number in a Path message, every RSVP device after that on the path ignores the message, which stops reservations from being made. It could even be possible to fix the value before it reaches the receiver, which makes the attack really hard to detect 😱. Also, in theory, a node might modify the IP protocol number of non-RSVP messages too, which could mess with the operation of other protocols 🙃. So it is RECOMMENDED that implementations of this specification only support modifying the IP protocol number for RSVP Path, PathTear, and ResvConf messages. In other words, a general facility for modifying the IP protocol number SHOULD NOT be made available 🚫.
Network operators who deploy routers with RSVP aggregation capability should be aware of the risks of inappropriate IP protocol number modification 🧠. They should take appropriate steps, like physical security and password protection, to reduce the risk that an attacker could configure a router to maliciously modify the protocol number 🔐💅.
7. IANA Considerations 🎀
IANA modified the RSVP parameters registry, specifically the 'Class Names, Class Numbers, and Class Types' subregistry, and assigned two new C-Types under the existing SESSION Class (Class number 1). Here's the table 📋:
Class
Number Class Name Reference
------ ----------------------- ---------
1 SESSION [RFC2205]
Class Types or C-Types:
17 GENERIC-AGGREGATE-IP4 [RFC4860]
18 GENERIC-AGGREGATE-IP6 [RFC4860]IANA also modified that same RSVP parameters registry and 'Class Names, Class Numbers, and Class Types' subregistry 🌈. This time they assigned one new Class Number for the SESSION-OF-INTEREST class and two new C-Types for that class. Check out the table below 👇:
Class
Number Class Name Reference
------ ----------------------- ---------
132 SESSION-OF-INTEREST [RFC4860]
Class Types or C-Types:
1 GENERIC-AGG-IP4-SOI [RFC4860]
2 GENERIC-AGG-IP6-SOI [RFC4860]These allocations are in accordance with [RSVP-MOD] 💜.
8. Acknowledgments 🫶
This document borrows heavily from [RSVP-AGG] 📚. It also borrows the concepts of Virtual Destination Port and Extended Virtual Destination Port from [RSVP-IPSEC] and [RSVP-TE], respectively 🧚.
Also, a big thank you to Fred Baker, Roger Levesque, Carol Iturralde, Daniel Voce, Anil Agarwal, Alexander Sayenko, and Anca Zamfir for their input into the content of this document 💖. Thanks to Steve Kent for the insightful comments on using RSVP reservations in IPsec environments 🙌.
Ran Atkinson, Fred Baker, Luc Billot, Pascal Delprat, and Eric Vyncke provided guidance and suggestions for the security considerations section 🥹🔥.
9. Normative References 📖
[IPSEC-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PHB-ID] Black, D., Brim, S., Carpenter, B., and F. Le
Faucheur, "Per Hop Behavior Identification Codes", RFC
3140, June 2001.
[RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S.,
and S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RSVP-AGG] Baker, F., Iturralde, C., Le Faucheur, F., and B.
Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001.
[RSVP-CRYPTO1] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RSVP-CRYPTO2] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC
3097, April 2001.
[RSVP-IPSEC] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", RFC 2207, September 1997.
[RSVP-MOD] Kompella, K. and J. Lang, "Procedures for Modifying
the Resource reSerVation Protocol (RSVP)", BCP 96, RFC
3936, October 2004.10. Informative References ✨
Okay bestie, here are the reference buddies this doc calls on for backup. Every one gets its full details listed so you can go find them 🔍
[BW-REDUC]Polk, J. and S. Dhesikan, "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow", RFC 4495, May 2006. 🦋[GRE]Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 🌸[RSVP-PREEMP]Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001. 👑[RSVP-PROCESS]Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997. 💅[RSVP-TE]Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. 🧚[RSVP-TUNNEL]Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000. 🍓[SIG-NESTED]Baker, F. and P. Bose, "QoS Signaling in a Nested Virtual Private Network", Work in Progress, February 2007. 🫶
Appendix A. Example Signaling Flow 🎀
Okay so this appendix doesn't add any new rules, it's just a walkthrough of the Section 4 stuff using a possible RSVP message flow 🦋 It assumes E2E reservations get aggregated over generic aggregate RSVP reservations, and it shows how the very first unicast E2E reservation between a given Aggregator/Deaggregator pair gets set up successfully. Main character energy, literally 💖
Aggregator Deaggregator
E2E Path
----------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(New-agg-needed,SOI=GAx)
<----------------------------------
E2E PathErr(New-agg-needed,SOI=GAy)
<----------------------------------
(3)
AggPath(Session=GAx)
------------------------------->
AggPath(Session=GAy)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (Session=GAx)
<-------------------------------
AggResv (Session=GAy)
<-------------------------------
(6)
AggResvConfirm (Session=GAx)
------------------------------>
AggResvConfirm (Session=GAy)
------------------------------>
(7)
E2E Resv
<---------
(8)
E2E Resv (SOI=GAx)
<-----------------------------
(9)
E2E Resv
<-----------Let's break it down step by step 🫶
- (1) The Aggregator forwards E2E Path into the aggregation region after modifying its IP protocol number to RSVP-E2E-IGNORE. 💅
- (2) Let's assume no Aggregate Path exists. To accurately update the ADSPEC of the E2E Path, the Deaggregator needs the ADSPEC of the Aggregate Path. So in this example, the Deaggregator decides to tell the Aggregator to set up Aggregate Path states for the two supported PHB-IDs 🔥 To do that, it sends two E2E PathErr messages with a New-Agg-Needed PathErr code. Both PathErr messages also carry a SESSION-OF-INTEREST (SOI) object. In the first E2E PathErr, the SOI contains a GENERIC-AGGREGATE SESSION (GAx) whose PHB-ID is set to x. In the second one, the SOI contains a GENERIC-AGGREGATE SESSION (GAy) whose PHB-ID is set to y. In both messages, the GENERIC-AGGREGATE SESSION holds an interface-independent Deaggregator address inside the DestAddress, plus appropriate values inside the vDstPort and Extended vDstPort fields 🌈
- (3) The Aggregator follows the Deaggregator's request and signals an Aggregate Path for both GENERIC-AGGREGATE Sessions (GAx and GAy) ✨
- (4) The Deaggregator takes the info in the ADSPEC from both Aggregate Paths into account and updates the E2E Path ADSPEC to match. It also changes the E2E Path IP protocol number back to RSVP before forwarding it 🦋
- (5) In this example, the Deaggregator decides to jump right in and set up generic aggregate reservations for both PHB-IDs 💖 Basically it's anticipating the real demand for E2E reservations, so resources are already sitting there on the generic aggregate reservations when the E2E Resv requests show up. That speeds up E2E reservation setup, iconic behavior 👑 Also, assume the Deaggregator includes the optional Resv Confirm Request in these Aggregate Resvs.
- (6) The Aggregator just complies with the ResvConfirm Request it got and sends back the matching Aggregate ResvConfirm 🫶
- (7) Now the Deaggregator has explicit confirmation that both Aggregate Resvs are established 🎀
- (8) When the E2E Resv arrives, the Deaggregator applies the mapping policy the network administrator defined to map that E2E Resv onto a generic aggregate reservation. Let's assume the policy says the E2E reservation goes onto the generic aggregate reservation with PHB-ID=x. The Deaggregator knows a generic aggregate reservation (GAx) has been in place for that PHB-ID since step (7). It performs admission control of the E2E Resv onto the generic aggregate reservation for PHB-ID=x (GAx). Assuming GAx was established with enough bandwidth to support the E2E Resv, the Deaggregator adjusts its counter that tracks the unused bandwidth on GAx. Then it forwards the E2E Resv to the Aggregator, including a SESSION-OF-INTEREST object that conveys the selected mapping onto GAx (and therefore onto PHB-ID=x) 🧚
- (9) The Aggregator records the mapping of the E2E Resv onto GAx (and onto PHB-ID=x). It removes the SOI object and forwards the E2E Resv toward the sender 🌸
Authors' Addresses 💜
Here's where you can find the authors. Slide into their inboxes, they're giving helpful 🫶
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot Sophia-Antipolis
France
EMail: flefauch@cisco.com
Bruce Davie
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
EMail: bds@cisco.com
Pratik Bose
Lockheed Martin
700 North Frederick Ave.
Gaithersburg, MD 20879
USA
EMail: pratik.bose@lmco.com
Chris Christou
Booz Allen Hamilton
13200 Woodland Park Road
Herndon, VA 20171
USA
EMail: christou_chris@bah.com
Michael Davenport
Booz Allen Hamilton
Suite 390
5220 Pacific Concourse Drive
Los Angeles, CA 90045
USA
EMail: davenport_michael@bah.comFull Copyright Statement 🌈
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔥
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Please send that info to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 💜
📦 where this page comes from
- ietf: rfc4860 2007-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms