RFC 3175
Aggregation of RSVP for IPv4 and IPv6 Reservations
Aggregation of RSVP for IPv4 and IPv6 Reservations 🎀
Part 1 of 9 ✨ bestie, this one's the opening chunk, and the title block comes first 💅
Okay so this RFC is from September 2001, and it's a Standards Track doc from the Internet community, written by F. Baker, C. Iturralde, F. Le Faucheur, and B. Davie at Cisco Systems. It's RFC 3175 🦋 It doesn't list anything it obsoletes or updates in its title block.
Status of this Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and it's 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) edition that's current. Distribution of this memo is unlimited 🌈
Copyright Notice ©️
Copyright (C) The Internet Society (2001). All Rights Reserved. 💜
Abstract 🫶
This doc is about using one single RSVP (Resource ReSerVation Protocol) reservation to bundle up a bunch of other RSVP reservations across a transit routing region. It's conceptually similar to Virtual Paths in an ATM (Asynchronous Transfer Mode) network, so if you've seen those, you already get the vibe 🧚
It proposes a way to dynamically create that aggregate reservation, classify the traffic it covers, figure out how much bandwidth is needed to meet the requirement, and recover that bandwidth once the sub-reservations aren't needed anymore 💖 It also has recommendations about algorithms and policies for predictive reservations ✨
1. Introduction ✨
Okay, big picture 🔥 A key problem in RSVP version 1 [RSVP] is, as its applicability statement notes, that it doesn't have facilities for aggregating individual reserved sessions into a common class 😭 Aggregation is recommended in [CSZ], and it's required for scalability. No cap, it's essential 💅
The aggregation problem can be handled in a bunch of different ways 🌸 For example, sometimes it's enough to just mark reserved traffic with a suitable DSCP (like EF), which lets scheduling and classification state get aggregated 🎀 You could also set up one or more aggregate reservations from ingress to egress of an "aggregation region" (defined below), where each aggregate reservation carries similarly marked packets from a huge number of flows 🦋 The payoff is high levels of assurance that the end-to-end requirements of reserved flows get met, while reservation state also gets aggregated. Iconic behavior honestly 👑
Throughout, we'll talk about "Aggregator" and "Deaggregator," which are the routers at the ingress and egress edges of an aggregation region 🧚 How a router figures out whether it should be the aggregator or the deaggregator is described below 👀
We'll call the individual reserved sessions (the ones we're trying to aggregate) "end-to-end" reservations ("E2E" for short), and their Path/Resv messages are E2E Path/Resv messages 💜 The bigger reservation, the one that represents lots of E2E reservations, is an "aggregate" reservation, and its Path/Resv messages are "aggregate Path/Resv messages" 🍓
1.1. Problem Statement: Aggregation Of E2E Reservations 🙈
So the thing is, lots of small reservations have been talked about a ton 💀 The short version: each reservation needs a non-trivial amount of message exchange, computation, and memory resources in each router along the way. It'd be nice to bring that down to something more manageable, especially where the load is heaviest and aggregation is possible 🌈
Aggregation has its own challenges though 😬 It reduces the isolation between individual flows, which means one flow might suffer delay from another flow's bursts. Bursts from different flows may synchronize too. BUT, and this is the iconic part, there's evidence [CSZ] that aggregation has no negative effect on the mean delay of the flows, and it actually reduces delay in the "tail" of the delay distribution (for example, the 99% percentile delay) for the flows 🔥 Those benefits kind of make up for losing strict isolation. Main character energy for aggregation, honestly ✨
1.2. Proposed Solution 🎀
Here's the plan 🦋 We aggregate several E2E reservations that cross an "aggregation region" and share common ingress and egress routers into one larger reservation from ingress to egress. An "aggregation region" is a contiguous set of systems that can do RSVP aggregation (as defined below) along any possible route through that contiguous set 🧚
Communication interfaces fall into two categories relative to an aggregation region: they're either "exterior" to it or "interior" to it 💅 Routers that have at least one interface in the region fall into one of three categories for a given RSVP session. They either aggregate, they deaggregate, or they sit between an aggregator and a deaggregator 🫶
Aggregation depends on hiding E2E RSVP messages from RSVP-capable routers inside the aggregation region 🙈 To do that, the IP Protocol Number in the E2E reservation's Path, PathTear, and ResvConf messages changes from RSVP (46) to RSVP-E2E-IGNORE (134) when it enters the aggregation region, and it gets restored to RSVP at the deaggregator point 💖 While inside the region, these messages are ignored by each router whenever they're forwarded to an interior interface. Ignored here means no state gets stored and the message is forwarded as a normal IP datagram 🌸
Since the deaggregating router sees the previous RSVP hop on such messages as the aggregating router, Resv and other messages don't need this modification. They're unicast from RSVP hop to RSVP hop anyway 🦋
The token buckets (SENDER_TSPECs and FLOWSPECS) of E2E reservations get summed into the matching information elements in aggregate Path and Resv messages 🍓 Aggregate Path messages go from the aggregator to the deaggregator(s) using RSVP's normal IP Protocol Number 🎀 Aggregate Resv messages go back from the deaggregator to the aggregator. That's how an aggregate reservation gets established on behalf of the set of E2E flows that use this aggregator and deaggregator 👑
Setting up fewer aggregate reservations for a bigger number of E2E reservations means there's less state to store and fewer signalling messages exchanged in the aggregation region ✨ Lowkey so efficient 🧚
Here's another layer 💅 Using Differentiated Services mechanisms for classification and scheduling of traffic supported by aggregate reservations (instead of doing per aggregate reservation classification and scheduling) cuts the amount of classification and scheduling state in the aggregation region even further 💜 That state isn't just independent of the number of E2E reservations, it's also independent of the number of aggregate reservations in the region 🌈 One or more Diff-Serv DSCPs identify the traffic covered by aggregate reservations, and one or more Diff-Serv PHBs give that traffic the required forwarding treatment 🔥 You can also have more than one aggregate reservation between the same pair of routers, each one representing a different class of traffic and each using its own DSCP and its own PHB 🙌
1.3. Definitions 📖
An "aggregation region" is a set of RSVP-capable routers where E2E RSVP messages arriving on an exterior interface of one router in the set would traverse one or more interior interfaces (of this router and possibly of other routers in the set) before finally traversing an exterior interface 🦋
Such an E2E RSVP message is said to have crossed the aggregation region 🧚
The "aggregating" router for this E2E flow is the first router that processes the E2E Path message as it enters the aggregation region. That's the one that forwards the message from an exterior interface to an interior interface 💖
The "deaggregating" router for this E2E flow is the last router to process the E2E Path as it leaves the aggregation region. That's the one forwarding the message from an interior interface to an exterior interface 🌸
An "interior" router for this E2E flow is any router in the aggregation region that receives this message on an interior interface and forwards it to another interior interface. Interior routers do neither aggregation nor deaggregation for this flow 🍓
Note that by these definitions, a single router with a mix of interior and exterior interfaces can act as an aggregator on some E2E flows, a deaggregator on other E2E flows, and an interior router on yet other flows 🤯 Router multitasking, iykyk 👑
1.4. Detailed Aspects of Proposed Solution 🎀
A number of issues jump to mind when you think about this model 🧠 We'll get into them next 💅🫶
1.4.1. Traffic Classification Within The Aggregation Region ✨
okay so, the reason RSVP Version 1 didn't have a way to aggregate sessions is that there wasn't a clear way to classify the aggregate 🙈 With Differentiated Services, that's at least partially fixed. Traffic of a particular class can get marked with a given DSCP, and that's how it gets classified. We're going with that model 💅
We're assuming that on each link along the way, there's a queue, WDM color, or something similar set aside for all the aggregated traffic of the same class. We also assume there's enough bandwidth to carry the traffic assigned to it 🫶 That bandwidth can be adjusted based on how much aggregated reservation traffic is assigned to the same class.
There are loads of options for exactly which Diff-serv PHBs you could use for different classes of traffic as it crosses the aggregation region. This is the "service mapping" problem described in [RFC2998], and it applies to situations way broader than the ones in this document 🧚 People make good arguments for using either EF or one or more AF PHBs for aggregated traffic. For example, controlled load requires non-TSpec-conformant (policed) traffic to be forwarded as best effort traffic instead of dropped. So it may make sense to use an AF class for controlled load, using the higher drop preference for non-conformant packets 🌸
In regular (unaggregated) RSVP, a session is identified by a destination address and optionally a protocol port. Since the data in an aggregated reservation is identified by a DSCP, the session gets defined by the destination address and DSCP instead 🦋 When two DSCPs are used (one for conformant packets and one for non-conformant, like we just talked about), the session is identified by the DSCP of the conformant packets. In general, we'll talk about mapping aggregated traffic onto a DSCP, even if a second DSCP might be used for non-conformant traffic.
Whichever PHB or PHBs carry the aggregated reservations, care needs to be taken in an environment where provisioned Diff-Serv and aggregated RSVP are both used in the same network. You have to make sure the total admitted load for a single PHB doesn't go over the link capacity allocated to that PHB 😭 One way to handle this is to reserve one PHB (or more) strictly for the aggregated reservation traffic (for example, the AF1 Class), while using other PHBs for provisioned Diff-Serv (for example, the AF2, AF3 and AF4 Classes) 💜
Inside the aggregation region, some RSVP reservation state is kept per aggregate reservation. Classification and scheduling state (like the DSCPs used for classifying traffic), though, is kept per aggregate reservation class instead of per aggregate reservation 👑 For example, if Guaranteed Service reservations are mapped to the EF DSCP throughout the aggregation region, there may be a reservation for each aggregator/deaggregator pair in each router. But only the EF DSCP needs to be inspected at each interior interface, and only a single queue is used for all EF traffic. Iconic efficiency 🔥
1.4.2. Deaggregator Determination 🎀
The first question is "How do we determine the Aggregator/Deaggregator pair that are responsible for aggregating a particular E2E flow through the aggregation region?"
Figuring out the aggregator is easy, honestly 💖 We know an E2E flow has reached an aggregator when its Path message arrives at a router on an exterior interface and has to be forwarded out an interior interface.
Figuring out the deaggregator is more involved 😭 If an SPF routing protocol, like OSPF or IS-IS, is in use, and if it's been extended to advertise information about Deaggregation roles, it can tell us the set of routers the deaggregator will be picked from. In principle, if the aggregator and deaggregator are in the same area, the deaggregator's identity could be figured out from the link state database. But this approach wouldn't work in multi-area environments or for distance vector protocols.
One method for Deaggregator determination is manual configuration. With this method, the network operator configures the Aggregator and the Deaggregator with the info they need 🍓
Another method lets the Deaggregator be determined automatically, with the Aggregator notified to match. When the E2E RSVP Path message moves from an interior interface to an exterior interface, the deaggregating router has to tell the aggregating router about the correlation between itself and the flow. This is lowkey great because it isn't specific to any routing protocol. It also automatically adjusts to route changes 🌈 For instance, if a topology change puts another Deaggregator on the shortest path, this method will automatically identify the new Deaggregator and switch over to it 🦋
1.4.3. Mapping E2E Reservations Onto Aggregate Reservations 💅
As we talked about above, there may be multiple Aggregate Reservations between the same Aggregator/Deaggregator pair ✨ The rules for mapping E2E reservations onto aggregate reservations are policy decisions. They depend on the network environment and what the network administrator is going for 👑 That kind of policy is outside the scope of this specification, so we just assume the network administrator has defined one. We also assume the policy is somehow accessible to the Aggregators/Deaggregators. But exactly how it gets to them (Local Configuration, COPS, LDAP, etc.) is also outside the scope of this specification 🫶
An example of a very simple policy would be mapping all the E2E reservations onto a single Aggregate Reservation (that is, a single DSCP) between a given pair of Aggregator/Deaggregator 🌸
Another example, which takes into account the Int-Serv service type the receiver asked for (signalled in the E2E Resv), would be mapping Guaranteed Service E2E reservations onto one DSCP in the aggregation region and Controlled Load E2E reservations onto a different DSCP 💜
A third example would be a policy where the mapping of E2E reservations onto Aggregate Reservations takes Policy Objects into account. These could be things like info authenticating the end user, which the sender might include in the E2E Path and/or the receiver might include in the E2E Resv 🔥
No matter what the actual policy is, there are a bunch of options for where the decision to map an E2E reservation onto an aggregate reservation gets made, and how that decision gets communicated between Aggregator and Deaggregator 🧚 Both could be assumed to make the decision independently. But that would either need extra procedures to fix inconsistent mapping decisions (where the Aggregator and Deaggregator pick different Aggregate Reservations for the same E2E reservation), or it would risk possible undetected misbehavior whenever the decisions didn't match 😭
For simplicity and reliability, the responsibility for the mapping decision goes entirely to the Deaggregator. The Deaggregator tells the Aggregator which mapping it selected, and the Aggregator follows that decision 💖 The Deaggregator was picked over the Aggregator because the Deaggregator is the first to have access to all the info needed to make the call. That includes receiving the E2E Resv, which shows the requested Int-Serv service type and carries the info the receiver signalled. This allows faster operations, like setting up or resizing an Aggregate Reservation in a bunch of situations, which means faster E2E reservation establishment ⭐
1.4.4. Size of Aggregate Reservations 🍓
There's a range of options for figuring out the size of the aggregate reservation, and it's a tradeoff between simplicity and scalability 🦋 Simplistically, the size of the aggregate reservation needs to be greater than or equal to the sum of the bandwidth of the E2E reservations it aggregates. Its burst capacity must be greater than or equal to the sum of their burst capacities too. But if you follow that religiously, you'd have to change the bandwidth of the aggregate reservation every time an underlying E2E reservation changes. That loses one of the key benefits of aggregation, which is cutting down the message processing cost in the aggregation region 😭
So we assume there's some policy, not defined in this specification (although sample policies with the necessary characteristics are suggested). This policy keeps the bandwidth required on a given aggregate reservation in check by looking at the sum of the bandwidths of its underlying E2E reservations, while trying hard to change it infrequently 🌈 This may need some level of trend analysis. If there's a significant probability that the current aggregate reservation will be used up in the next interval of time, the router must predict the necessary bandwidth and request it. If the router has a lot of bandwidth reserved but very little probability of using it, the policy may be to predict the amount of bandwidth required and release the excess 💅
This policy is likely to benefit from some hysteresis (that is, making sure the trigger condition for increasing the aggregate reservation size is sufficiently different from the trigger condition for decreasing it). That helps avoid oscillation in stable conditions 🧚
Honestly, defining and running policies like this are as much business issues as technical ones, so they're out of the scope of this document 💀
1.4.5. E2E Path ADSPEC update ✨
okay so, E2E RSVP messages are hidden from the Interior routers inside the aggregation region 🙈 which means the ADSPECs on E2E Path messages don't get updated as they zoom through. so the Deaggregator for a flow has to fix up the ADSPEC in the matching E2E Path itself, to show how the aggregation region changes the QoS you can actually get end-to-end. the Deaggregator should update the E2E Path ADSPEC as accurately as possible 💅
Aggregate Path messages are processed inside the region, so the Interior routers update their ADSPEC to show the impact on QoS within the interior region 🦋. that means the Deaggregator should totally use the info in an Aggregate Path's ADSPEC wherever it's there. it's also allowed to wait until that info arrives before forwarding the E2E Path, so its own update comes out accurate 🫶
to give the Deaggregator the most info possible, whenever the Aggregator signals an Aggregate Path, the Aggregator should include an ADSPEC with fragments for all service types supported in the aggregation region 🎀 even if that Aggregate Path's Aggregate Reservation only supports some of them. giving the Deaggregator info for every service type makes it way easier to update the E2E ADSPEC accurately and on time ✨
depending on the environment and the policy for mapping E2E reservations onto Aggregate Reservations, the Deaggregator may for example:
- update all the E2E Path ADSPEC segments (
Default General Parameters Fragment,Guaranteed Service Fragment,Controlled-Load Service Fragment) based on the ADSPEC of a single Aggregate Path, or - update the E2E Path ADSPEC by taking into account the ADSPEC from multiple Aggregate Path messages (for example, update the
Default General Parameters Fragmentusing the "worst" value for each parameter across all the Aggregate Paths' ADSPECs, and update theGuaranteed Service Fragmentusing theGuaranteed Service Fragmentfrom the ADSPEC of the Aggregate Path for the reservation used for Guaranteed Services) 🌸
by taking the info in the Aggregate Path ADSPEC(s) into account like this, the Deaggregator should be able to update the E2E Path ADSPEC accurately in most situations 💖
however, there are some particular situations where the Deaggregator can't make the E2E Path ADSPEC update entirely accurately 😭 this is most likely when the path across the aggregation region depends on the service requested in the E2E Resv, which hasn't arrived yet. it could happen if, for example:
- the service mapping policy for the aggregation region sends E2E reservations requesting Guaranteed Service to a different PHB than those requesting Controlled Load service.
- Diff-Serv aware routing is used in the aggregation region, so packets with different DSCPs follow different paths (sending them over different MPLS label switched paths, for example).
so the ADSPEC for the aggregate reservation supporting guaranteed service may be different from the ADSPEC for the aggregate reservation supporting controlled load. not it being the same, babe 💀
say the sender sends an E2E Path with an ADSPEC containing segments for both Guaranteed Services and Controlled Load. when it's time to update the E2E ADSPEC, the Deaggregator doesn't know which service type the receiver will actually request 🤷♀️ so it can't know which PHB will carry this E2E flow, and it can't pick the right parameter values to factor into the Default General Parameters Fragment. like we said above, a conservative approach would be to always use the worst value for every parameter. but whether you go conservative or just use one of the two Aggregate Path ADSPECs, the E2E Path ADSPEC will be inaccurate (over-optimistic or over-pessimistic) for at least one service type the destination actually requests 😩
we know a totally accurate E2E Path ADSPEC update isn't possible in every situation, so we recommend taking a conservative approach in these cases (over-pessimistic rather than over-optimistic) and fixing the E2E Path ADSPEC as soon as possible 🍓 in the example above, that means as soon as the Deaggregator gets the E2E Resv from the receiver, it should generate another E2E Path with an accurately updated ADSPEC, based on which Aggregate Reservation will actually carry the E2E flow ✨👑
1.4.6. Intra-domain Routes 🦋
RSVP handles route changes directly, since reservations follow the same routes their data follows 💅 this works because Path messages carry the same IP source and destination addresses as the data flow the reservation is for. but now that we're making aggregate reservations by sending a Path message from an aggregating router to a deaggregating router, the reserved (E2E) data packets no longer carry the same IP addresses as the aggregate Path message. so the issue becomes making sure data packets for reserved flows follow the same path as the Path message that set up Path state for the aggregate reservation. there are several viable approaches 🧚
first, the data can be tunneled from aggregator to deaggregator, using things like IP-in-IP tunnels, GRE tunnels, MPLS label-switched paths, and so on 🌈 each has its own perks, especially MPLS, which allows traffic engineering 🔥 they also each cost some link overhead and configuration complexity 😮💨
if the data isn't tunneled, we're relying on a property of IP best metric routing: if the route from A to Z includes the path from H to L, and the best metric route was chosen all along the way, then the best metric route was chosen from H to L too 🧠 so an aggregate Path message that crosses a given aggregator and deaggregator will necessarily use the best path between them ✨
if that's a single path, the problem is solved 🎀 if it's a multi-path route with equal-cost paths, we have to figure out (maybe by measurement) what proportion of a given E2E reservation's traffic goes along each path, and make sure there's enough bandwidth for current use 😤 a simple, though wasteful, way to do this is to reserve the total capacity of the aggregate route down each path 💀
that's why we think it's advantageous to use one of the tunneling mechanisms above when multiple equal-cost paths may exist 💜
1.4.7. Inter-domain Routes 🌍
inter-domain routes are a little different from the intra-domain case we just covered 🫠 best-path considerations don't apply here, because routing is based on a combination of routing policy and shortest AS path, not simple best metric.
with inter-domain routes, data traffic from different E2E sessions (but the same aggregate session) may not enter an aggregation region through the same aggregator interface, and/or may not leave through the same deaggregator interface 😵💫 it's possible that some central system that sees the reservation information for both of the apparent sessions could spot this. but it's not clear we could work out how much traffic went one way or the other without measuring it.
we just want to note that this problem can happen and needs to be allowed for in the implementation 📝 we recommend that each such E2E reservation be summed into its appropriate aggregate reservation, even though that means over-reservation 🙈💅
1.4.8. Reservations for Multicast Sessions 💜
aggregating reservations for multicast sessions is way more complex than for unicast 😭 the first challenge is building a multicast tree that distributes the aggregate Path messages along the same path the data packets for that aggregate reservation will follow. and that's complicated, because the path a data packet takes can depend on lots of things, like its source address, whether shared trees or source-specific trees are used, and where the rendezvous point for the tree is 🌀
once the aggregate Path messages can be distributed, figuring out the right amount of resources to reserve on each link of the multicast tree is still a big problem 😩 multicast aggregates can be super heterogeneous, so it seems like we'd need to keep info about individual E2E reservations inside the aggregation region to allocate resources correctly. which means we could end up with a complicated set of procedures for forming aggregate reservations that don't actually reduce the stored state much for multicast sessions 💀
as noted above, RSVP state has several aspects, and our approach for unicast aggregates all of them: classification, scheduling, and reservation state 🎀 one possible approach for multicast is to focus only on aggregating classification and scheduling state, which are arguably the most important because of how much they affect the forwarding path ✨ that's the approach described in the current draft 🫶
1.4.9. Multi-level Aggregation ✨
Okay so, ideally an aggregation scheme should be able to handle recursive aggregation 🔁, where the aggregate reservations get aggregated too (bestie, it's giving Russian nesting dolls 🪆). Multi-level aggregation can be done with the procedures described here plus a simple extension to the protocol number swapping process 💅.
We can think of E2E RSVP reservations as being at aggregation level 0 🌱. When we aggregate those, we get reservations at aggregation level 1. In general, level n reservations can be aggregated to form reservations at level n+1 🫶.
When an aggregating router receives an E2E Path, it swaps the protocol number from RSVP to RSVP-E2E-IGNORE 🔄. It should also write the aggregation level (1, in this case) into the 2 byte field that is present (and currently unused) in the router alert option 🎀. In general, a router that aggregates level n reservations to create level n+1 reservations will write the number n+1 in the router alert field.
A router that deaggregates level n+1 reservations will examine all messages with IP Protocol number RSVP-E2E-IGNORE, but it will process the message and swap the protocol number back to RSVP only when the router alert field carries the number n+1 👑. For any other value, the message is forwarded unchanged. Interior routers ignore all messages with IP Protocol number RSVP-E2E-IGNORE 🙈. Also, only a few bits of that 2 byte option field would be needed, given how many levels of aggregation are likely 🍓.
For IPv6, certain values of the router alert "value" field are reserved 🧚. This specification requires IANA to assign a small number of consecutive values for recording the aggregation level 📋.
1.4.10. Reliability Issues ✨
There are a bunch of aggregation issues that would benefit from some kind of explicit acknowledgment mechanism for RSVP messages 🥺. For example, a set of routers could be configured so that an E2E Path with protocol type RSVP-E2E-IGNORE gets effectively "black-holed" 🕳️ if it never reaches a router that's set up properly to act as a deaggregator. It could then travel all the way to its destination, where it would probably be ignored because of its non-standard protocol number 💀. This situation is not easy to detect, bestie.
The aggregator can be sure this problem hasn't happened if an aggregate PathErr message is received from the deaggregator (as described in detail below) ✅. It can also be sure there's no problem if an E2E Resv is received. However, the fact that neither of these events has happened may only mean that no receiver wants to reserve resources for this session, or that an RSVP message loss occurred, or it may mean the Path was black-holed 😭. If a neighbor-to-neighbor acknowledgment mechanism existed, though, the aggregator would expect to receive an acknowledgment of the E2E Path from the deaggregator. It would read the lack of a response as a sign that a configuration problem existed, and it could then refrain from aggregating this particular session 🛑. We note that such a reliability mechanism has been proposed for RSVP in [RFC291], and we propose that it be used here 🫶.
1.4.11. Message Integrity and Node Authentication ✨
[RSVP] defines a hop-by-hop authentication and integrity check 🔐. The present specification allows this check to be used on Aggregate RSVP messages, and it also preserves this check on E2E RSVP messages for E2E RSVP messages 💜.
Outside the Aggregation Region, any E2E RSVP message may contain an INTEGRITY object that uses a keyed cryptographic digest technique. This assumes that RSVP neighbors share a secret 🗝️. Because E2E RSVP messages are not processed by routers in the Aggregation Region, the Aggregator and Deaggregator appear as logical RSVP neighbors of each other 👯. The Deaggregator is the Aggregator's Next Hop for E2E RSVP messages, while the Aggregator is the Deaggregator's Previous Hop. So INTEGRITY objects that may appear in E2E RSVP messages traversing the Aggregation Region are exchanged directly between the Aggregator and Deaggregator, in a way that's totally transparent to the Interior routers 🫥. That means hop-by-hop integrity checking for E2E messages over the Aggregation Region requires that the Aggregator and Deaggregator share a secret. Techniques for establishing that secret are described in [INTEGRITY] 🔑.
Inside the Aggregation Region, any Aggregate RSVP message may contain an INTEGRITY object, which assumes that the corresponding RSVP neighbors inside the Aggregation Region share a secret. Those neighbors are things like Aggregator and Interior Router, two Interior Routers, or Interior Router and Deaggregator 🏠.
1.4.12. Aggregated reservations without E2E reservations ✨
Up to this point, we've assumed that the aggregate reservation is established because of E2E reservations set up from outside the aggregation region 🌍. But it should be clear that other triggers are possible, bestie 🙌. As discussed in [RFC2998], an aggregate RSVP reservation can be used to manage bandwidth in a diff-serv cloud even when RSVP isn't used end-to-end 🦋.
The simplest alternative is the static configuration of an aggregated reservation for a certain amount of traffic from an ingress (aggregator) router to an egress (de-aggregator) router 🧁. This would have to be configured in at least the system that originates the aggregate PATH message (the aggregator). The deaggregator could detect that the PATH message is directed to it, and it could be configured to "turn around" such messages. In other words, it responds with a RESV back to the aggregator 🔁. Or, the configuration of the aggregate reservation could be done at both the aggregator and the deaggregator. As before, an aggregate reservation is associated with a DSCP for the traffic that will use the reserved capacity 🏷️.
When there are no E2E microflow reservations, the aggregator can use a variety of policies to set the DSCP of packets passing into the aggregation region. That decides whether they gain access to the resources reserved by the aggregate reservation 🎟️. These policies are a matter of local configuration, as usual for a device at the edge of a diffserv cloud 🧭.
Note that the "aggregator" could even be a device like a PSTN gateway, which makes an aggregate reservation for the set of calls to another PSTN gateway (the deaggregator) across an intervening diff-serv region 📞. In this case, the reservation may be established in response to call signalling 📲.
From the perspective of RSVP signalling and the handling of data packets in the aggregation region, these cases are equivalent to aggregating E2E RSVP reservations 💅. The only difference is that E2E RSVP signalling doesn't take place, so it can't be used as a trigger. That means some additional knowledge is required when setting up the aggregate reservation 🧠.
2. Elements of Procedure ✨
To implement aggregation, we define a number of elements of procedure 📝.
2.1. Receipt of E2E Path Message By Aggregating Router 🚪
The very first event is the arrival of the E2E Path message at an exterior interface of an aggregator 📬. Standard RSVP procedures [RSVP] are followed for this, including deciding which set of interfaces the message should be forwarded onto 🗺️. These interfaces comprise zero or more exterior interfaces and zero or more interior interfaces. (If the number of interior interfaces is zero, the router isn't acting as an aggregator for this E2E flow 🙅.)
Service on exterior interfaces is handled as defined in [RSVP] 🌐.
Service on interior interfaces is a bit complicated 😵💫. The message needs to be included in some aggregate reservation, but at this point it's not known which one, because the deaggregator isn't known yet. So the E2E Path message is forwarded on the interior interface(s) using the IP Protocol number RSVP-E2E-IGNORE, but in every other respect it's sent exactly the way it would be by an RSVP router that wasn't performing aggregation 🎀.
2.2. Handling Of E2E Path Message By Interior Routers 🧚
At this point, the E2E Path message traverses zero or more interior routers 🛣️. Interior routers receive the E2E Path message on an interior interface and forward it on another interior interface. The Router Alert IP Option alerts interior routers to check internally, but they find that the IP Protocol is RSVP-E2E-IGNORE and the next hop interface is interior 🙈. As such, they simply forward it as a normal IP datagram 💌.
2.3. Receipt of E2E Path Message By Deaggregating Router
okay so the E2E Path message finally shows up at a deaggregating router 🦋 It comes in on an interior interface and gets forwarded out an exterior interface. The Router Alert IP Option is what tells the router to grab it, but this time the IP Protocol is RSVP-E2E-IGNORE and the next hop is an exterior interface 🎀
Before the E2E Path heads off to the receiver, the Deaggregator should update its ADSPEC ✨ This update is about how the aggregation region changes the QoS the flow can actually get end to end 💅 That info can be pulled from the ADSPEC of the Aggregate Path messages going from the Aggregator to the Deaggregator. So to update the ADSPEC properly, a deaggregating router may wait (more on this below) for an aggregate Path to show up before it forwards the E2E Path 🫶
When the E2E Path arrives, the Deaggregator may or may not know yet which DSCP the E2E flow will be mapped onto. That depends on the policy used to map E2E reservations onto Aggregate Reservations, as described above 🧚 If the Deaggregator already knows the mapping at this point, it first checks that there is an Aggregate Path in place for the matching DSCP. If there is, it uses that Aggregate Path's ADSPEC to update the E2E Path's ADSPEC, then forwards the E2E Path toward the receiver 💖 If there isn't, it asks for one by sending an E2E PathErr message with an error code of NEW-AGGREGATE-NEEDED and the desired DSCP encoded in the DCLASS Object 😭 The Deaggregator may also, at the same time, request an aggregate reservation for other DSCPs 🌈 When the Aggregate Path for the desired DSCP arrives, the Deaggregator then uses its ADSPEC to update the ADSPEC of the E2E Path.
If the Deaggregator still can't tell what the mapping is at this point, it uses the information in the ADSPEC of one Aggregate Path, or of multiple Aggregate Paths, to update the E2E Path ADSPEC 🍓 In the same way, if one or more of the Aggregate Paths it needs isn't established yet, it requests establishment of the matching Aggregate Path by sending an E2E PathErr message with an error code of NEW-AGGREGATE-NEEDED and the desired DSCP encoded in the respective DCLASS Object. When the Aggregate Path for the desired DSCP shows up, the Deaggregator uses that Aggregate Path's ADSPEC to update the ADSPEC of the E2E Path 🎀
Generating an E2E PathErr message with an error code of NEW-AGGREGATE-NEEDED should not remove any Path state 🙅♀️ What it should do is get the aggregating router to start the necessary aggregate Path message, which is covered in the next section 💜
Last but not least, the deaggregating router changes the E2E Path message's IP Protocol from RSVP-E2E-IGNORE to RSVP and forwards it toward its intended destination 👑
2.4. Initiation of New Aggregate Path Message By Aggregating Router
the aggregating router is the one in charge of generating a new Aggregate Path for a DSCP 🦋 It does this when it gets an E2E PathErr message with the error code NEW-AGGREGATE-NEEDED from the deaggregator. The DSCP value for the Aggregate Path Session is found in the DCLASS Object of that E2E PathErr message. The identity of the deaggregator itself is in the ERROR SPECIFICATION of the E2E PathErr message 🧚 The destination address of the aggregate Path message is the address of the deaggregating router, and the message goes out with IP protocol number RSVP 💅
Here's the tea ☕ Existing RSVP procedures say the size of a reservation for a flow is set to the minimum of the Path SENDER_TSPEC and the Resv FLOW_SPEC. So an Aggregate Reservation can never be bigger than the SENDER_TSPEC the Aggregator put in the Aggregate Path. To make sure the Deaggregator can size Aggregate Reservations without running into undesired limits, the aggregating router should always try to put a SENDER_TSPEC in the Aggregate Path that's at least as big as what the Deaggregator would actually need 😭 One way to do that is to use a SENDER_TSPEC that's obviously bigger than the highest load of E2E reservations this network might support 🔥 Another way is for the Aggregator to keep track of which flows are mapped onto a DSCP and always add their E2E Path SENDER_TSPEC into the Aggregate Path SENDER_TSPEC (and maybe add some extra bandwidth in anticipation of future E2E reservations) 🌸
The aggregating router finds out about the mapping from an E2E flow to a DSCP in two ways ✨ First, when it gets an E2E PathErr with the error code NEW-AGGREGATE-NEEDED, it learns that the matching E2E flow is (at least temporarily) mapped onto a given DSCP. Second, when it gets an E2E Resv containing a DCLASS Object (more on that below), it learns that the matching E2E flow is mapped onto a given DSCP 🫶
2.5. Handling of E2E Resv Message by Deaggregating Router
Once the deaggregator has sent the E2E Path message on toward the destination, it has to expect an E2E Resv for the session 👀 When that Resv arrives, its job is to make sure there's enough bandwidth reserved inside the aggregation region for the new E2E reservation. If there is, it forwards the E2E Resv to the aggregating router 💖
First, the Deaggregating router makes the final call on which Aggregate Reservation (and therefore which DSCP) this E2E reservation gets mapped onto 🧚 That decision follows the policy the network administrator picked, as described above 🎀
If this final mapping lets the Deaggregator update the E2E Path ADSPEC more accurately than it could when it forwarded the original E2E Path, it should do that and generate a new E2E Path right away 🚀 That way the receiver gets the accurate ADSPEC info as soon as possible 🫶 Otherwise, normal Refresh procedures should be followed for the E2E Path 🔁
If there's no Aggregate Reservation yet from the matching aggregating router with the matching DSCP, the Deaggregating router will set up a new Aggregate Reservation, as described in the next section 🦋
If the matching Aggregate Reservation exists but doesn't have enough bandwidth reserved to fit the new E2E reservation (on top of all the E2E reservations already mapped onto it), it should follow the normal RSVP procedures [RSVP] for a reservation placed with insufficient bandwidth to support it 😬 It can also try first to grow the aggregate reservation supplying the bandwidth, by increasing the size of the FLOW_SPEC it puts in the aggregate Resv that it sends upstream 💅 Like we talked about in the last section, the Aggregating Router should make sure the SENDER_TSPEC it includes in the Aggregate Path is always bigger than the FLOW_SPEC the Deaggregator might ask for in the Aggregate Resv. That way the Deaggregator isn't unnecessarily blocked from increasing the Aggregate Reservation bandwidth as needed 🌈
When there's enough bandwidth on the matching aggregate reservation, the Deaggregating Router can just send the E2E Resv message with IP Protocol RSVP to the aggregating router ✨ This message should include the DCLASS object, so the aggregator knows which DSCP to use for this E2E flow 🍓 The deaggregator also adds the token bucket from the E2E Resv FLOWSPEC object into its internal tally of how much of the Aggregate reservation is in use 🧮
As discussed above, the Deaggregator MAY anticipate the current demand and increase the Aggregate Reservation's size ahead of what E2E reservations actually need 🔮 This helps cut down on the times that there isn't enough bandwidth reserved on the matching Aggregate Reservation when an E2E Resv gets processed, and it avoids the delay that comes with growing that aggregate bandwidth 🦋
2.6. Initiation of New Aggregate Resv Message By Deaggregating Router
When an E2E Resv message shows up on an exterior interface, the Deaggregator works out the right DSCP for the session using the mapping policy 🎀 Then it looks for the matching path state for a session with that DSCP. If aggregate Path state exists but no aggregate Resv state does, the Deaggregator creates a new aggregate Resv 💖
If there's no aggregate Path state for the right DSCP, it could be because the Deaggregator couldn't decide the final mapping for this E2E flow earlier and chose not to set up Aggregate Path state for every DSCP 🧚 In that case, the Deaggregator should ask for the matching Aggregate Path by sending an E2E PathErr with the error code NEW-AGGREGATE-NEEDED and a DCLASS containing the required DSCP 😭 That triggers the Aggregator to set up the matching Aggregate Path. Once the Deaggregator sees that the aggregate Path state is established, it creates a new Aggregate Resv 🌸
The FLOW_SPEC of the new Aggregate Resv is set to a value not smaller than what the E2E reservation it's supporting needs 💪 The Aggregate Resv gets sent toward the aggregator (that is, to the previous hop), using the AGGREGATED-RSVP session and filter specifications defined below 🦋 Since the DSCP is in the SESSION object, no DCLASS object is needed ✨ The message should be reliably delivered using the mechanisms in [RFC2961] or, alternatively, the CONFIRM object may be used, so the deaggregator can be sure the aggregate Resv actually arrives and gets granted 🫶 That's how the deaggregator knows the requested bandwidth is available to hand out to the E2E flows it supports 👑
To cut down on situations where no matching Aggregate Reservation exists when an E2E Resv gets processed (and the delay that comes with creating one), the Deaggregator MAY anticipate the current demand and create the Aggregate Reservation before any E2E Resv messages that need bandwidth on those aggregate reservations show up 🔮
2.7. Handling of Aggregate Resv Message by Interior Routers
The aggregate Resv message gets handled in basically the same way as defined in [RSVP] 🧚 The Session object has the address of the deaggregating router (or the group address for the session, in the case of multicast) and the DSCP chosen for the session 💖 The Filterspec object identifies the aggregating router 🎀 These routers do admission control and resource allocation as usual, then send the aggregate Resv on toward the aggregator 🦋
2.8. Handling of E2E Resv Message by Aggregating Router 💌
okay so when the aggregating router gets an E2E Resv message carrying a DCLASS Object, that's the final confirmation that the E2E reservation has been mapped onto an Aggregate Reservation 🎀 it's the official "yes, we're together" moment 💖 under normal circumstances this is literally the only way the aggregator finds out about that association 🙈 then it should forward the E2E Resv to its previous hop, following the usual RSVP processing rules [RSVP] ✨
2.9. Removal of E2E Reservation 🧹
E2E reservations get removed the normal way: PathTear, ResvTear, timeout, or when some error condition shows up 💀 when that happens, their FLOWSPEC information must also be removed from the allocated portion of the aggregate reservation 🫶 that same bandwidth may be re-used for other traffic in the near future 🌸 and when E2E Path messages are removed, their SENDER_TSPEC information must also be removed from the aggregate Path 🧺
2.10. Removal of Aggregate Reservation 🥀
if an aggregate reservation goes away (presumably due to a configuration change, route change, or policy event), the E2E reservations it supports are no longer active 😭 they must be treated accordingly 💅
2.11. Handling of Data On Reserved E2E Flow by Aggregating Router 📦
before it's established that a given E2E flow is part of a given aggregate, the flow's data should be treated as traffic without a reservation, by whatever policies prevail for that kind of traffic 🙃 generally, that means getting the same forwarding behavior as best effort traffic 🧸 but once it's established that the flow belongs to a given aggregate, the aggregating router is responsible for marking related traffic with the correct DSCP and forwarding it in the way that's appropriate for traffic on that reservation ✨ this may imply forwarding it to a given IP next hop, or piping it down a given link layer circuit, tunnel, or MPLS label switched path 🚇
the aggregator is responsible for doing per-reservation policing on the E2E flows it's aggregating 👮♀️ it meters the traffic belonging to each reservation to check compliance with the token bucket for the matching E2E reservation 🪣 packets that are in compliance get forwarded as mentioned above 💖 packets that are out of compliance must be either dropped, reshaped or marked to a different DSCP 😬 the detailed policing behavior is part of the service mapping described in [RFC2998] 📜
2.12. Procedures for Multicast Sessions 🌈
because of the difficulties of aggregating multicast sessions we talked about above, we focus on aggregating scheduling and classification state in the multicast case 🧠 the main difference between multicast and unicast is that, instead of sending an aggregate Path message to the unicast address of a single deaggregating router, we send the "aggregate" Path message to the same group address as the E2E session 🎯 this makes sure the aggregate Path message follows the same route as the E2E Path 🛤️ that difference is reflected in the Session objects defined below 🧾 the downside is that we still keep reservation state per multicast session inside the aggregation region 🫠
there's also a challenge with multicast sessions that have heterogeneous receivers 👀 picture an interior router that has to forward packets for a multicast session out two interfaces, but has only received a reservation request on one of them 🤔 it gets packets marked with the DSCP chosen for the aggregate reservation 🎀 when it sends them out the interface with no installed reservation, it has these options:
- a) remark those packets to best effort before sending them out the interface;
- b) send the packets out the interface with the DSCP chosen for the aggregate reservation.
option a) is kinda messy 😩 because it needs nMF classification at an interior router, just to recognize which flows' packets need to be demoted 🫣 option b) needs over-reservation of resources on the interface that never got a reservation request 💸 and without that over-reservation, the packets sent with the "wrong" DSCP could degrade the service that packets using that DSCP get legitimately 💔
to make MF classification acceptable in an interior router, it may be possible to treat heterogeneous flows as an exception 🙌 that way, an interior router only needs to be able to recognize those individual microflows that have heterogeneous resource needs on the outbound interfaces of that router 🧚
3. Protocol Elements 🧚
3.1. IP Protocol RSVP-E2E-IGNORE 🦋
this specification requires the assignment of a protocol type called RSVP-E2E-IGNORE, whose number is 134 at this point 🔢 it's only used on E2E messages that need a router alert (Path, PathTear, and ResvConf), and it signifies that the message must be treated one way when it's destined to an interior interface, and another way when it's destined to an exterior interface 🚪 the Aggregator swaps the protocol type from RSVP to RSVP-E2E-IGNORE in E2E Path, PathTear, and ResvConf messages when they enter the Aggregation Region 🔁 and the Deaggregator swaps it back from RSVP-E2E-IGNORE to RSVP in those same E2E messages when they exit the Aggregation Region 👋
3.2. Path Error Code 🚨
a PathErr code NEW-AGGREGATE-NEEDED is required 📣 this one doesn't mean a fatal error has happened 🙅♀️ it means the aggregating router needs to take an action to avoid an error condition in the near future ⏰
3.3. SESSION Object 🎟️
the SESSION object holds two values: the IP Address of the aggregate session destination, and the DSCP that it will use on the E2E data the reservation contains 💌 for unicast sessions, the session destination address is the address of the deaggregating router 📍 for multicast sessions, the session destination is the multicast address of the E2E session (or sessions) being aggregated 🌐 including the DSCP in the session lets multiple sessions toward the same address be told apart by their DSCP and queued separately 🧁 it also gives us a way to aggregate scheduling and classification state 🧠 when a session uses a pair of PHBs (e.g., AF11 and AF12), the DSCP used should represent the numerically smallest PHB (e.g., AF11) 🔎 this follows the same naming convention described in [BRIM] 📖
session types are defined for both IPv4 and IPv6 addresses 🌍
IP4 SESSION object: Class = SESSION, C-Type = RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Session Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+IP6 SESSION object: Class = SESSION, C-Type = RSVP-AGGREGATE-IP6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Session Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+3.4. SENDER_TEMPLATE Object 🪪
the SENDER_TEMPLATE object identifies the aggregating router for the aggregate reservation 🏷️
IP4 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE, C-Type = RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Aggregator Address (4 bytes) |
+-------------+-------------+-------------+-------------+IP6 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE, C-Type = RSVP-AGGREGATE-IP6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Aggregator Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+3.5. FILTER_SPEC Object 🧩
the FILTER_SPEC object identifies the aggregating router for the aggregate reservation 📍 it's syntactically identical to the SENDER_TEMPLATE object 👯♀️
4. Policies and Algorithms For Predictive Management Of Blocks Of Bandwidth 📈
the exact policies used to decide how much bandwidth an aggregate reservation should get at any given time are beyond the scope of this document 🙊 they may even be proprietary to the service provider in question 🔒 still, here we explore some of the issues and suggest approaches 💡
in short, the ideal is that the aggregate reservation always has enough resources to allocate to any E2E reservation that needs its support, and never takes too much 🎯 simple to say, way harder to achieve 😅 the factors that come into play include the times in the diurnal cycle: you might find that lots of people start placing calls at 8:00 AM, even though the hour from 7:00 to 8:00 is dead calm 🌅 they also include recent history: if more people have been placing calls recently than have been finishing them, a prediction of the bandwidth needed a few moments from now may call for more than is currently allocated 📈 and likewise, at the end of a busy period, the trend may call for declining reservation amounts 📉
we recommend a policy along these lines 💅 at any given time, one should expect that the amount of bandwidth required for the aggregate reservation is the larger of the following:
- (a) a requirement known a priori, such as from history of the diurnal cycle at a particular week day and time of day, and
- (b) the trend line over recent history, with 90 or 99% statistical confidence.
we further expect that changes to the aggregate reservation would be made no more often than every few minutes, and ideally on a bigger granularity, like fifteen minute or hourly intervals ⏳ the finer the granularity, the more signaling is required 📡 while the coarser the granularity, the greater the chance for error, and the need to recover from that error 🫠
in general, we expect that the aggregate reservation will never add up to exactly the sum of the reservations it supports 🧮 instead, it'll be an integer multiple of some block reservation size, one that exceeds that value 🧱✨
5. Security Considerations 🔒✨
Okay bestie, there are LOTS of security issues in this doc 😭. For example, if an attacker grabs an aggregate reservation, a bunch of calls end up running unreserved 💀. Reserving a huge pile of extra bandwidth could also lead to a denial of service. But these problems aren't unique to this extension, because RSVP itself has them too 🫶. The authors believe the security mechanisms in RSVP cover these issues as well ✨.
One security issue that's specific to RSVP aggregation is messing with the IP protocol number in RSVP Path messages that travel through an aggregation region 🙈. If someone maliciously changed that field, every device after it would ignore the message, so reservations could never get made 😱. They could even change the value back before it reaches the receiver, which makes the attack really hard to spot 🕵️. In theory, a node could also change the IP protocol number on non-RSVP messages, which would mess with other protocols totally. Yikes 💀.
One way to lower the risk of malicious changes to the IP protocol number is to use an IPSEC authentication header, which makes sure malicious changes to the IP header get detected 🔐. This is a desirable approach, but it comes with some admin burden in the form of key management for authentication 🔑.
It is RECOMMENDED that implementations of this specification only support modification of the IP protocol number for RSVP Path, PathTear, and ResvConf messages. That means a general facility for modifying the IP protocol number SHOULD NOT be made available 🚫. Main character boundaries, honestly 👑.
Network operators who deploy routers with RSVP aggregation capability should be aware of the risks of inappropriate modification of the IP protocol number. They should also take appropriate steps, like physical security and password protection, to reduce the risk that an attacker could configure a router to modify the protocol number maliciously 🛡️.
6. IANA Considerations 📋💖
Section 1.2 proposes a new protocol type, RSVP-E2E-IGNORE 🧚. It identifies a message that routers in the network core will see. Further processing of these messages may or may not be required, depending on the egress interface type, as described in Section 1.2. IANA assigned IP protocol number 134, in accordance with [RFC2780], which meets the Standards Track publication criterion 🎀.
Section 1.4.9 describes how the Router Alert is used in this specification. It's essentially a simple counter of the depth of aggregation nesting 🔢. The IPv4 Router Alert [RFC2113] has the option to ask the router to look at the protocol type of the intercepted datagram and decide what to do with it, and the parameter is extra info for that decision. The IPv6 Router Alert [RFC2711] turns the parameter into an option sub-type. So the IPv6 router alert option may not be used algorithmically for this protocol 🙃. IANA assigned a block of 32 values (3-35, "Aggregated Reservation Nesting Level") that we may map to nesting depths 0..31, hoping 32 levels is enough 🤞.
Section 3.2 discusses a new, required path error code. IANA has assigned RSVP Parameters Error Code 26 to NEW-AGGREGATE-NEEDED 🍓.
Sections 3.3, 3.4, and 3.5 describe extensions to three object classes: Session, Filter Specification, and Sender Template 💜. IANA has assigned two new common C-Types for the aggregator's address. RSVP-AGGREGATE-IP4 is C-Type 9, and RSVP-AGGREGATE-IP6 is C-Type 10 ✨. When these C-Types are added to the IANA RSVP Class Names, Class Numbers and Class Types registry, the same numbering is used in all three Classes, just like IPv4 and IPv6 address tuples in [RSVP] 🌈.
7. Acknowledgments 🫶
The authors acknowledge that published documents and discussions with several people materially contributed to this document 🌸. Those people are notably John Wroclawski, Steve Berson, and Andreas Terzis, and the design is influenced by the RSVP tunnels document [TERZIS] 💅.
APPENDIX 1: Example Signalling Flow For First E2E Flow 🦋
Okay so this Appendix doesn't add any extra specification 🙈. It only illustrates the spec above through one possible flow of RSVP signalling messages. These messages set up a successful unicast E2E reservation, which is the first one between a given pair of Aggregator/Deaggregator 🧚.
Aggregator Deaggregator
E2E Path
---------------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(New-agg-needed, DCLASS=x)
<-------------------------------
E2E PathErr(New-agg-needed, DCLASS=y)
<-------------------------------
(3)
AggPath(DSCP=x)
------------------------------->
AggPath(DSCP=y)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (DSCP=x)
<-------------------------------
AggResv (DSCP=y)
<-------------------------------
(6)
AggResvConfirm (DSCP=x)
------------------------------>
AggResvConfirm (DSCP=y)
------------------------------>
(7)
E2E Resv
<----------
(8)
E2E Resv (DCLASS=x)
<-----------------------------
(9)
E2E Resv
<---------------Here's the step-by-step breakdown 💕:
- (1) 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 Aggregate PATH. In this example, the Deaggregator chooses to tell the Aggregator to set up Aggregate Path states for the two supported DSCPs. It does this by sending a New-Agg-Needed PathErr code for each DSCP 🤓.
- (3) The Aggregator follows the Deaggregator's request and signals an Aggregate Path for both DSCPs ✨.
- (4) The Deaggregator takes the information in the ADSPEC from both Aggregate Paths into account and updates the E2E Path ADSPEC accordingly. The Deaggregator also changes the E2E Path IP Protocol Number back to RSVP before forwarding it 🔁.
- (5) In this example, the Deaggregator decides to go ahead right away with establishing Aggregate Reservations for both DSCPs. Basically, the Deaggregator is anticipating actual demand for E2E reservations. That way, resources are already available on Aggregate Reservations when E2E Resv requests arrive, which speeds up E2E reservation setup 🚀. Let's also assume the Deaggregator includes the optional Resv Confirm Request in these Aggregate Resv messages 💜.
- (6) The Aggregator just complies with the received ResvConfirm Request and returns the matching Aggregate ResvConfirm ✅.
- (7) The Deaggregator now has explicit confirmation that both Aggregate Resv messages are established 🎉.
- (8) When the E2E Resv arrives, the Deaggregator applies the mapping policy that the network administrator defined to map the E2E Resv onto an Aggregate Reservation. Let's assume this policy maps the E2E reservation onto the Aggregate Reservation with DSCP=x. The Deaggregator knows an Aggregate Reservation is in place for that DSCP since step (7). It performs admission control of the E2E Resv onto the Aggregate Resv for DSCP=x. If the Aggregate Resv for DSCP=x was established with enough bandwidth to support the E2E Resv, the Deaggregator adjusts its counter tracking the unused bandwidth on the Aggregate Reservation. Then it forwards the E2E Resv to the Aggregator, including a DCLASS object that conveys the selected mapping onto DSCP=x 🌈.
- (9) The Aggregator records the mapping of the E2E Resv onto DSCP=x. It removes the DCLASS object and forwards the E2E Resv towards the sender 💖.
APPENDIX 2: Example Signalling Flow For Subsequent E2E Flow Without Reservation Resizing 🦋
Okay so this Appendix doesn't add any new spec, bestie 🫶 It just shows the stuff we already covered through a possible flow of RSVP signalling messages. The flow is for a unicast E2E reservation that gets set up successfully after other E2E reservations already exist between the same Aggregator/Deaggregator pair. You can picture it as a sequel to the flow in Appendix 1 ✨
Aggregator Deaggregator
E2E Path
---------------->
(10)
E2E Path
------------------------------->
(11)
E2E Path
----------->
E2E Resv
<-----------
(12)
E2E Resv (DCLASS=x)
<-----------------------------
(13)
E2E Resv
<---------------- (10) The Aggregator sends the E2E Path into the aggregation region, but first it changes the IP Protocol Number to RSVP-E2E-IGNORE 💅
- (11) Since earlier E2E reservations were already set up, we're going to assume an Aggregate Path exists for every supported DSCP 🌈 The Deaggregator checks the ADSPEC from those Aggregate Paths and updates the E2E Path ADSPEC to match. It also changes the E2E Path IP Protocol Number back to RSVP before forwarding it, so it's giving full glow-up energy 💖
- (12) When the E2E Resv shows up, the Deaggregator uses the mapping policy the network administrator set to map it onto an Aggregate Reservation. We'll assume the policy says this E2E reservation goes onto the Aggregate Reservation with DSCP=x. Again, since earlier E2E reservations exist, we'll assume an Aggregate Reservation is already in place for DSCP=x. The Deaggregator runs admission control to fit the E2E Resv onto the Aggregate Resv for DSCP=x. If the Aggregate Resv for DSCP=x has enough unused bandwidth for the new E2E Resv, the Deaggregator updates its counter of unused bandwidth on the Aggregate Reservation and forwards the E2E Resv to the Aggregator. It includes a DCLASS object that shows the mapping onto DSCP=x 🎀
- (13) The Aggregator notes the mapping of the E2E Resv onto DSCP=x. It takes out the DCLASS object and forwards the E2E Resv toward the sender 🧚
APPENDIX 3: Example Signalling Flow For Subsequent E2E Flow With Reservation Resizing ⭐
Same energy as Appendix 2, bestie! This one doesn't add any new spec either. It just shows the spec through a possible flow of RSVP signalling messages for a unicast E2E reservation that gets set up successfully after other E2E reservations between the same Aggregator/Deaggregator pair. Think of it as the sequel to Appendix 2 💜
Aggregator Deaggregator
E2E Path
---------------->
(14)
E2E Path
------------------------------->
(15)
E2E Path
----------->
E2E Resv
<-----------
(16)
AggResv (DSCP=x, increased Bw)
<-------------------------------
(17)
AggResvConfirm (DSCP=x, increased Bw)
------------------------------>
(18)
E2E Resv (DCLASS=x)
<-----------------------------
(19)
E2E Resv
<---------------- (14) The Aggregator sends the E2E Path into the aggregation region, but first it changes the IP Protocol Number to RSVP-E2E-IGNORE 💅
- (15) Since earlier E2E reservations were already set up, we're going to assume an Aggregate Path exists for every supported DSCP 🌈 The Deaggregator checks the ADSPEC from those Aggregate Paths and updates the E2E Path ADSPEC to match. It also changes the E2E Path IP Protocol Number back to RSVP before forwarding it 💖
- (16) When the E2E Resv shows up, the Deaggregator uses the mapping policy the network administrator set to map it onto an Aggregate Reservation. We'll assume the policy says this E2E reservation goes onto the Aggregate Reservation with DSCP=x. Since earlier E2E reservations exist, we'll assume an Aggregate Reservation is already in place for DSCP=x. The Deaggregator runs admission control to fit the E2E Resv onto the Agg Resv for DSCP=x. This time, let's assume the Aggregate Resv for DSCP=x does NOT have enough unused bandwidth for the new E2E Resv 😬 So the Deaggregator tries to bump up the Aggregate Reservation bandwidth for DSCP=x by sending a new Aggregate Resv. The new bandwidth is big enough to cover every E2E reservation already mapped onto that Aggregate reservation, plus the new E2E reservation, plus maybe a bit of spare bandwidth for E2E reservations that might show up later. We'll also assume the Deaggregator includes the optional Resv Confirm Request in these Aggregate Resv messages 🎀
- (17) The Aggregator just does what the ResvConfirm Request asks and sends back the matching Aggregate ResvConfirm ✨
- (18) Now the Deaggregator has explicit confirmation that the Aggregate Resv was increased successfully 🥳 It runs admission control again, this time fitting the E2E Resv onto the increased Aggregate Reservation for DSCP=x. Assuming the increased Aggregate Reservation for DSCP=x now has enough unused bandwidth and resources for the new E2E Resv, the Deaggregator updates its counter of unused bandwidth on the Aggregate Reservation and forwards the E2E Resv to the Aggregator. It includes a DCLASS object that shows the mapping onto DSCP=x 🌸
- (19) The Aggregator notes the mapping of the E2E Resv onto DSCP=x. It takes out the DCLASS object and forwards the E2E Resv toward the sender 🧚
References 📚
[CSZ]Clark, D., S. Shenker, and L. Zhang, "Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanism," in Proc. SIGCOMM'92, September 1992.[IP]Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.[HOSTREQ]Braden, R., "Requirements for Internet hosts - communication layers", STD 3, RFC 1122, October 1989.[DSFIELD]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.[PRINCIPLES]Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.[ASSURED]Heinanen, J, Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.[BROKER]Jacobson, V., Nichols K. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, June 1999.[BRIM]Brim, S., Carpenter, B. and F. LeFaucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000.[RSVP]Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) Version 1 Functional Specification", RFC 2205, September 1997.[TERZIS]Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.[DCLASS]Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.[INTEGRITY]Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.[RFC2998]Bernet Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "Integrated Services Operation Over Diffserv Networks", RFC 2998, November 2000.[RFC2961]Berger, L., Gan, D., Swallow, G., Pan, P. and F. Tommasi, "RSVP Refresh Reduction Extensions", RFC 2961, April 2001.[RFC2780]Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", RFC 2780, March 2000.[RFC2711]Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.[RFC2113]Katz, D. "IP Router Alert Option", RFC 2113, February 1997.
Authors' Addresses 🖋️
Fred Baker, Cisco Systems:
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, CA, 93117 USA
Phone: (408) 526-4257
EMail: fred@cisco.comCarol Iturralde, Cisco Systems:
Carol Iturralde
Cisco Systems
250 Apollo Drive
Chelmsford MA, 01824 USA
Phone: 978-244-8532
EMail: cei@cisco.comFrancois Le Faucheur, Cisco Systems:
Francois Le Faucheur
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06410 Biot - Sophia Antipolis
France
Phone: +33.4.97.23.26.19
EMail: flefauch@cisco.comBruce Davie, Cisco Systems:
Bruce Davie
Cisco Systems
250 Apollo Drive
Chelmsford MA,01824 USA
Phone: 978-244-8921
EMail: bdavie@cisco.comFull Copyright Statement ✨
Copyright (C) The Internet Society (2001). All Rights Reserved. 💖
okay bestie, the Internet Society owns the copyright on this doc 🎀 but you're totally allowed to copy it and pass it around, and to make derivative works that comment on or explain it or help you implement it. You can publish and distribute those too, in whole or in part, with no restrictions of any kind ✨, as long as the copyright notice and this paragraph are on every copy and derivative work. The one thing you can't do is change this document itself in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations 🙈. The exceptions are when you're developing Internet standards (then you follow the copyright procedures in the Internet Standards process) or when you need to translate it into languages other than English 🌍.
The limited permissions above are perpetual, and the Internet Society or its successors or assigns will never revoke them 🦋.
The legal bit, word for word: This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 💀
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society, you're literally keeping the lights on for the RFC Editor 💜
📦 where this page comes from
- ietf: rfc3175 2001-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms