RFC 2205
Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification 🎀
Part 1 of 18 ✨
- RFC: 2205 🦋
- Series: Network Working Group
- Authors: R. Braden, Ed. (ISI), L. Zhang (UCLA), S. Berson (ISI), S. Herzog (IBM Research), and S. Jamin (Univ. of Michigan) 🫶
- Category: Standards Track 👑
- Date: September 1997 🌸
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙈
Status of this Memo 📜
Okay so this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions to make it better 💖. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1), since that's the source of truth 💅. Distribution of this memo is unlimited, so share away 🌈.
Abstract 🌸
This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet ✨. RSVP gives you receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. It's giving reliable and built to grow 💜.
Table of Contents 🧚
1. Introduction ................................................... 4
1.1 Data Flows ................................................. 7
1.2 Reservation Model .......................................... 8
1.3 Reservation Styles .........................................11
1.4 Examples of Styles .........................................14
2. RSVP Protocol Mechanisms .......................................19
2.1 RSVP Messages ..............................................19
2.2 Merging Flowspecs ..........................................21
2.3 Soft State .................................................22
2.4 Teardown ...................................................24
2.5 Errors .....................................................25
2.6 Confirmation ...............................................27
2.7 Policy Control .............................................27
2.8 Security ...................................................28
2.9 Non-RSVP Clouds ............................................29
2.10 Host Model ................................................30
3. RSVP Functional Specification ..................................32
3.1 RSVP Message Formats .......................................32
3.2 Port Usage .................................................47
3.3 Sending RSVP Messages ......................................48
3.4 Avoiding RSVP Message Loops ................................50
3.5 Blockade State .............................................54
3.6 Local Repair ...............................................56
3.7 Time Parameters ............................................57
3.8 Traffic Policing and Non-Integrated Service Hops ...........58
3.9 Multihomed Hosts ...........................................59
3.10 Future Compatibility ......................................61
3.11 RSVP Interfaces ...........................................63
4. Acknowledgments ................................................76
APPENDIX A. Object Definitions ....................................77
APPENDIX B. Error Codes and Values ................................92
APPENDIX C. UDP Encapsulation .....................................98
APPENDIX D. Glossary .............................................102
REFERENCES .......................................................111
SECURITY CONSIDERATIONS ..........................................111
AUTHORS' ADDRESSES ...............................................112What's Changed 🦋
This revision has some very minor changes from the ID14 version. Here's the tea ☕:
- For clarity, each message type is now defined separately in Section 3.1. 📝
- We added more precise and complete rules for accepting Path messages for unicast and multicast destinations (Section 3.1.3). 🎯
- We added more precise and complete rules for processing and forwarding PathTear messages (Section 3.1.5). 🚀
- A note was added that a
SCOPEobject will be ignored if it appears in aResvTearmessage (Section 3.1.6). 🙈 - A note was added that a
SENDER_TSPECorADSPECobject will be ignored if it appears in aPathTearmessage (Section 3.1.5). 💀 - The obsolete error code Ambiguous Filter Spec (09) was removed, and a new (and more consistent) name was given to error code 08 (Appendix B). 🧹
- In the generic interface to traffic control, the Adspec was added as a parameter to the
AddFlowandModFlowcalls (3.11.2). This is needed to accommodate a node that updates the slack term (S) of Guaranteed service. 🔧 - An error subtype was added for an Adspec error (Appendix B). ⚠️
- Additional explanation was added for handling a
CONFIRMobject (Section 3.1.4). 🌟 - The rules for forwarding objects with unknown class type were clarified. 🔍
- Additional discussion was added to the Introduction and to Section 3.11.2 about the relationship of RSVP to the link layer. (Section 3.10). 🔗
- Section 2.7 on Policy and Security was split into two sections, and some additional discussion of security was included. 🔐
- There were some minor editorial improvements. 💅
1. Introduction ✨
This doc defines RSVP, a resource reservation setup protocol made for an integrated services Internet [RSVP93, RFC 1633]. A host uses RSVP to request specific qualities of service from the network for particular application data streams or flows 🌸. Routers use it too: they pass QoS requests along to all the nodes on the path(s) of the flows, and they set up and maintain the state needed to provide the requested service 🧚. RSVP requests will generally result in resources being reserved in each node along the data path 💜.
RSVP asks for resources on simplex flows, which means it only cares about one direction 🦋. So RSVP treats a sender as logically distinct from a receiver, even though the same application process can be both a sender and a receiver at the same time 🫶. It runs on top of IPv4 or IPv6 and takes the spot of a transport protocol in the stack. Here's the twist: it doesn't carry application data at all. It's an Internet control protocol, like ICMP, IGMP, or routing protocols 🔥. Like those routing and management protocols, an RSVP implementation will typically run in the background, not in the data forwarding path, as shown in Figure 1 👑.
RSVP is not itself a routing protocol, but it's designed to operate with current and future unicast and multicast routing protocols 🌈. An RSVP process consults the local routing database(s) to get routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group 🎀. Routing protocols decide where packets get forwarded, and RSVP is only concerned with the QoS of those packets that are forwarded according to routing 💅.
To efficiently handle large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [RSVP93] 😭. A QoS request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree 🌟. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers 📈✨.
HOST ROUTER
_____________________________ ____________________________
| _______ | | |
| | | _______ | | _______ |
| |Appli- | | | |RSVP | | | |
| | cation| | RSVP <---------------------------> RSVP <---------->
| | <--> | | | _______ | | |
| | | |process| _____ | ||Routing| |process| _____ |
| |_._____| | -->Polcy|| || <--> -->Polcy||
| | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl||
| |data | | |_____|| ||__.____| | | |_____||
|===|===========|==|==========| |===|==========|==|==========|
| | --------| | _____ | | | --------| | _____ |
| | | | ---->Admis|| | | | | ---->Admis||
| _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl||
| | | | | |_____|| | | | | ||_____||
| |Class-| | Packet | | | |Class-| | Packet | |
| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>
| |______| |________| |data | |______| |________| |data
| | | |
|_____________________________| |____________________________|Figure 1: RSVP in Hosts and Routers 🖼️
Quality of service is implemented for a particular data flow by mechanisms collectively called "traffic control" 🧁. These include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded ⏰. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS 🎯. Traffic control implements QoS service models defined by the Integrated Services Working Group 🌸.
During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control" 🧚. Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control determines whether the user has administrative permission to make the reservation 🔐. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS 🥳. If either check fails, the RSVP program returns an error notification to the application process that originated the request 💀.
RSVP protocol mechanisms give you a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths 🌸. RSVP itself just transfers and manipulates QoS and policy control parameters as opaque data, then passes them to the right traffic control and policy control modules to interpret. The structure and contents of the QoS parameters are documented in specs from the Integrated Services Working Group; see [RFC 2210]. The policy parameters are still under development 🚧.
Since the membership of a large multicast group and the resulting multicast tree topology can change over time, the RSVP design assumes that RSVP state and traffic control state get built and destroyed incrementally in routers and hosts. So RSVP establishes "soft" state 🫧. That means RSVP sends periodic refresh messages to keep the state alive along the reserved path(s). If the refresh messages stop, the state automatically times out and gets deleted, no drama 💀.
In summary, RSVP has these main vibes:
- RSVP makes resource reservations for both unicast and many-to-many multicast applications, adapting dynamically to changing group membership as well as to changing routes. 🌈
- RSVP is simplex, i.e., it makes reservations for unidirectional data flows. ➡️
- RSVP is receiver-oriented, i.e., the receiver of a data flow initiates and maintains the resource reservation used for that flow. 🎧
- RSVP maintains "soft" state in routers and hosts, providing graceful support for dynamic membership changes and automatic adaptation to routing changes. 🦋
- RSVP is not a routing protocol but depends upon present and future routing protocols. 🗺️
- RSVP transports and maintains traffic control and policy control parameters that are opaque to RSVP. 📦
- RSVP provides several reservation models or "styles" (defined below) to fit a variety of applications. 💅
- RSVP provides transparent operation through routers that do not support it. ✨
- RSVP supports both IPv4 and IPv6. 👑
Further discussion on the objectives and general justification for RSVP design is presented in [RSVP93] and [RFC 1633]. Bookmark those if you're a nerd like me 🤓.
The rest of this section describes the RSVP reservation services. Section 2 gives an overview of the RSVP protocol mechanisms. Section 3 has the functional specification of RSVP, while Section 4 covers the explicit message processing rules. Appendix A defines the variable-length typed data objects used in the RSVP protocol. Appendix B defines error codes and values. Appendix C defines a UDP encapsulation of RSVP messages, for hosts whose operating systems don't provide enough raw network I/O support 🧚.
1.1 Data Flows ✨
RSVP defines a "session" as a data flow with a particular destination and transport-layer protocol. RSVP treats each session independently, and this document often leaves out the implied qualification "for the same session" 🎀.
An RSVP session is defined by the triple: (DestAddress, ProtocolId [, DstPort]). Here DestAddress, the IP destination address of the data packets, can be a unicast or multicast address. ProtocolId is the IP protocol ID. The optional DstPort parameter is a "generalized destination port", i.e., some further demultiplexing point in the transport or application protocol layer. DstPort could be defined by a UDP/TCP destination port field, by an equivalent field in another transport protocol, or by some application-specific information 💜.
The RSVP protocol is designed to be easily extensible for greater generality, but the basic protocol documented here only supports UDP/TCP ports as generalized ports. It's not strictly necessary to include DstPort in the session definition when DestAddress is multicast, since different sessions can always have different multicast addresses. However, DstPort is necessary to allow more than one unicast session addressed to the same receiver host 🙈.
Figure 2 shows the flow of data packets in a single RSVP session, assuming multicast data distribution. The arrows show data flowing from senders S1 and S2 to receivers R1, R2, and R3, and the cloud is the distribution mesh created by multicast routing. Multicast distribution forwards a copy of each data packet from a sender Si to every receiver Rj, while a unicast distribution session has a single receiver R. Each sender Si can be running on its own Internet host, or a single host can contain multiple senders told apart by "generalized source ports" 🍓.
Senders Receivers
_____________________
( ) ===> R1
S1 ===> ( Multicast )
( ) ===> R2
( distribution )
S2 ===> ( )
( by Internet ) ===> R3
(_____________________)
Figure 2: Multicast Distribution SessionFor unicast transmission there's a single destination host but there may be multiple senders, and RSVP can set up reservations for multipoint-to-single-point transmission 🫶.
1.2 Reservation Model ✨
An elementary RSVP reservation request consists of a "flowspec" together with a "filter spec", and this pair is called a "flow descriptor" 🔥. The flowspec specifies a desired QoS. The filter spec, together with a session specification, defines the set of data packets (the "flow") that will receive the QoS defined by the flowspec. The flowspec is used to set parameters in the node's packet scheduler or other link layer mechanism, while the filter spec sets parameters in the packet classifier. Data packets that are addressed to a particular session but don't match any of the filter specs for that session are handled as best-effort traffic 🌷.
The flowspec in a reservation request will generally include a service class and two sets of numeric parameters: (1) an "Rspec" (R for 'reserve') that defines the desired QoS, and (2) a "Tspec" (T for 'traffic') that describes the data flow. The formats and contents of Tspecs and Rspecs are determined by the integrated service models [RFC 2210] and are generally opaque to RSVP 🧁.
The exact format of a filter spec depends on whether IPv4 or IPv6 is in use; see Appendix A. In the most general approach [RSVP93], filter specs may select arbitrary subsets of the packets in a given session. Those subsets might be defined in terms of senders (i.e., sender IP address and generalized source port), in terms of a higher-level protocol, or generally in terms of any fields in any protocol headers in the packet. For example, filter specs might be used to select different subflows of a hierarchically-encoded video stream by selecting on fields in an application-layer header 🎬. But in the interest of simplicity (and to minimize layer violation), the basic filter spec format defined in this RSVP specification has a very restricted form: sender IP address and optionally the UDP/TCP port number SrcPort 🧠.
Because the UDP/TCP port numbers are used for packet classification, each router has to be able to examine these fields. This raises three potential problems 😬.
- Avoiding IP fragmentation. It's necessary to avoid IP fragmentation of a data flow for which a resource reservation is desired.
The document [RFC 2210] specifies a procedure for applications using RSVP facilities to compute the minimum MTU over a multicast tree and return the result to the senders 📏.
- IPv6 header stacking. IPv6 inserts a variable number of variable-length Internet-layer headers before the transport header, which makes packet classification for QoS harder and more expensive 🥴.
Efficient classification of IPv6 data packets could be obtained using the Flow Label field of the IPv6 header. The details will be provided in the future 🔮.
- IP Security hiding ports. IP-level Security, under either IPv4 or IPv6, may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers 🔒.
A small extension to RSVP for IP Security under IPv4 and IPv6 is described separately in [RFC 2207] 💡.
RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Heads up: in this document, the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" are defined with respect to the direction of data flow 🧭.
At each intermediate node, a reservation request triggers two general actions:
- Make a reservation on a link. The RSVP process passes the request to admission control and policy control. If either test fails, the reservation is rejected and the RSVP process returns an error message to the appropriate receiver(s). If both succeed, the node sets the packet classifier to select the data packets defined by the filter spec, and it interacts with the appropriate link layer to obtain the desired QoS defined by the flowspec 🛎️.
The detailed rules for satisfying an RSVP QoS request depend on the particular link layer technology in use on each interface. Specifications are under development in the ISSLL Working Group for mapping reservation requests into popular link layer technologies. For a simple leased line, the desired QoS will be obtained from the packet scheduler in the link layer driver, for example. If the link-layer technology implements its own QoS management capability, then RSVP has to negotiate with the link layer to obtain the requested QoS. The action to control QoS happens where the data enters the link-layer medium, i.e., at the upstream end of the logical or physical link, even though an RSVP reservation request originates from receiver(s) downstream 🌊.
- Forward the request upstream. A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request 🚀.
The reservation request that a node forwards upstream may differ from the request it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be "merged" as reservations travel upstream 🌟.
When a receiver starts a reservation request, it can also ask for a confirmation message 💌 to find out whether its request was (probably) installed in the network. ✨ A successful request travels upstream along the multicast tree until it hits a point where an existing reservation is equal or greater than what's being requested. At that point the new request gets merged with the reservation already there and doesn't need to go any further, and the node may then send a confirmation back to the receiver. 🦋 But ngl, getting a confirmation is only a high-probability sign, not a guarantee, that the service is actually set up all the way to the sender(s). More on that in Section 2.6. 💅
The basic RSVP reservation model is "one pass" 🧚: a receiver sends a request upstream, and every node on the path either accepts it or rejects it. The problem is there's no easy way for the receiver to figure out what end-to-end service they actually end up with. 😭 So RSVP supports an upgrade to one-pass called "One Pass With Advertising" (OPWA) [OPWA95]. With OPWA, RSVP control packets get sent downstream, following the data paths, to collect info that can be used to predict the end-to-end QoS. The results ("advertisements") get delivered by RSVP to the receiver hosts and maybe to the receiver applications too. Then the receiver can use those advertisements to build an appropriate reservation request, or adjust one on the fly. It's giving planning ahead 👑
1.3 Reservation Styles 🌸
A reservation request comes with a set of options that are collectively called the reservation "style". 🎀
One option is about how reservations for different senders in the same session get treated: either set up a "distinct" reservation for each upstream sender, or make one single reservation that is "shared" among all packets from selected senders. 💜
Another option controls how senders get selected. It can be an "explicit" list of all the selected senders, or a "wildcard" that implicitly selects all the senders in the session. ✨ In an explicit sender-selection reservation, each filter spec has to match exactly one sender, while in a wildcard sender-selection no filter spec is needed at all.
Sender || Reservations:
Selection || Distinct | Shared
_________||__________________|____________________
|| | |
Explicit || Fixed-Filter | Shared-Explicit |
|| (FF) style | (SE) Style |
__________||__________________|____________________|
|| | |
Wildcard || (None defined) | Wildcard-Filter |
|| | (WF) Style |
__________||__________________|____________________|Figure 3: Reservation Attributes and Styles
Here are the styles that are currently defined (see Figure 3) 📊:
- Wildcard-Filter (WF) Style 🌈
The WF style implies the options: "shared" reservation and "wildcard" sender selection. So a WF-style reservation creates a single reservation shared by flows from all upstream senders. You can think of it as a shared "pipe" whose "size" is the largest of the resource requests from all receivers, no matter how many senders are using it. 🫶 A WF-style reservation gets propagated upstream towards all sender hosts, and it automatically extends to new senders as they show up.
Symbolically, we can represent a WF-style reservation request by:
WF( * {Q})where the asterisk represents wildcard sender selection and Q represents the flowspec.
- Fixed-Filter (FF) Style 💖
The FF style implies the options: "distinct" reservations and "explicit" sender selection. So an elementary FF-style reservation request creates a distinct reservation for data packets from one particular sender, and doesn't share them with other senders' packets for the same session.
Symbolically, we can represent an elementary FF reservation request by:
FF( S{Q})where S is the selected sender and Q is the corresponding flowspec. The pair forms a flow descriptor. RSVP lets you request multiple elementary FF-style reservations at the same time, using a list of flow descriptors:
FF( S1{Q1}, S2{Q2}, ...)The total reservation on a link for a given session is the `sum' of Q1, Q2, ... for all requested senders. 🧮
- Shared Explicit (SE) Style 🦄
The SE style implies the options: "shared" reservation and "explicit" sender selection. So an SE-style reservation creates a single reservation shared by selected upstream senders. Unlike the WF style, the SE style lets a receiver explicitly specify the exact set of senders to include. 🍓
We can represent an SE reservation request containing a flowspec Q and a list of senders S1, S2, ... by:
SE( (S1,S2,...){Q} )Shared reservations, made by WF and SE styles, are a good fit for multicast apps where multiple data sources aren't likely to transmit at the same time. 🎙️ Packetized audio is a great example: since only a limited number of people talk at once, each receiver might issue a WF or SE reservation request for twice the bandwidth needed for one sender (to allow some over-speaking 🙈). The FF style, which creates distinct reservations for flows from different senders, is the move for video signals. 📹
The RSVP rules don't allow merging shared reservations with distinct reservations, because those modes are fundamentally incompatible. 🙅 They also don't allow merging explicit sender selection with wildcard sender selection, since that could produce an unexpected service for a receiver who asked for explicit selection. As a result of all these prohibitions, WF, SE, and FF styles are all mutually incompatible. 💀
It might seem possible to simulate a WF reservation using the SE style. When an application asks for WF, the RSVP process on the receiver host could use local state to create an equivalent SE reservation that explicitly lists all senders. 🤔 But an SE reservation forces the packet classifier in each node to explicitly select each sender in the list, while a WF lets the packet classifier just "wild card" the sender address and port. So when there's a large list of senders, a WF-style reservation can result in way less overhead than an equivalent SE-style reservation. ✨ That's why both SE and WF are included in the protocol. 👑
Other reservation options and styles may be defined in the future. 🔮
1.4 Examples of Styles 🎨
This section walks through an example of each reservation style and shows the effects of merging. 🧁
Figure 4 shows a router with two incoming interfaces, labeled (a) and (b), where flows arrive, and two outgoing interfaces, labeled (c) and (d), where data gets forwarded. This topology gets assumed in the examples that follow. 🗺️ There are three upstream senders: packets from sender S1 (S2 and S3) arrive through previous hop (a) ((b), respectively). There are also three downstream receivers: packets bound for R1 (R2 and R3) are routed via outgoing interface (c) ((d), respectively). We also assume that outgoing interface (d) is connected to a broadcast LAN, meaning replication happens in the network. R2 and R3 are reached via different next hop routers (not shown). 🌐
We also have to specify the multicast routes within the node of Figure 4. First, assume that data packets from each Si shown in Figure 4 get routed to both outgoing interfaces. Under that assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter, Fixed-Filter, and Shared-Explicit reservations, respectively. 🧩
________________
(a)| | (c)
( S1 ) ---------->| |----------> ( R1 )
| Router | |
(b)| | (d) |---> ( R2 )
( S2,S3 ) ------->| |------|
|________________| |---> ( R3 )
|Figure 4: Router Configuration
For simplicity, these examples show flowspecs as one-dimensional multiples of some base resource quantity B. 📏 The "Receives" column shows the RSVP reservation requests received over outgoing interfaces (c) and (d), and the "Reserves" column shows the resulting reservation state for each interface. The "Sends" column shows the reservation requests that get sent upstream to previous hops (a) and (b). In the "Reserves" column, each box represents one reserved "pipe" on the outgoing link, with the corresponding flow descriptor. 🎀
Figure 5, showing the WF style, illustrates two distinct situations where merging is required. 🌟 (1) Each of the two next hops on interface (d) results in a separate RSVP reservation request, as shown. These two requests must be merged into the effective flowspec, 3B, that gets used to make the reservation on interface (d). (2) The reservations on interfaces (c) and (d) must be merged in order to forward the reservation requests upstream. As a result, the larger flowspec 4B gets forwarded upstream to each previous hop. 🫧
|
Sends | Reserves Receives
|
| _______
WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} )
| |_______| <- WF( *{2B} )Figure 5: Wildcard-Filter (WF) Reservation Example
Figure 6 shows Fixed-Filter (FF) style reservations. 🌷 For each outgoing interface, there's a separate reservation for each source that has been requested, but that reservation gets shared among all the receivers that made the request. The flow descriptors for senders S2 and S3, received through outgoing interfaces (c) and (d), get packed (not merged) into the request forwarded to previous hop (b). On the other hand, the three different flow descriptors specifying sender S1 get merged into the single request FF( S1{4B} ) that is sent to previous hop (a). 🥰
|
Sends | Reserves Receives
|
| ________
FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} )
| |________|
| | S2{5B} |
| |________|
---------------------|---------------------------------------------
| ________
<- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} )
FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} )
| | S3{B} |
| |________|
Figure 6: Fixed-Filter (FF) Reservation ExampleFigure 7 is where things get spicy 🌸 It shows Shared-Explicit (SE) style reservations. When SE-style reservations get merged, the resulting filter spec is the union of the original filter specs, and the resulting flowspec is the largest flowspec. ✨
|
Sends | Reserves Receives
|
| ________
SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} )
| | {B} |
| |________|
---------------------|---------------------------------------------
| __________
<- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} )
SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} )
| |__________|
Figure 7: Shared-Explicit (SE) Reservation ExampleOkay so these first three examples all assume that data packets from S1, S2, and S3 get routed out to both outgoing interfaces 🦋 Figure 8 switches up the routing assumption. In the top part, data packets from S2 and S3 are not forwarded to interface (c), e.g., because the network topology gives these senders a shorter path toward R1 that doesn't go through this node. The bottom part of Figure 8 shows WF style reservations under that assumption. Since there is no route from (b) to (c), the reservation forwarded out interface (b) only considers the reservation on interface (d). It's giving quiet confidence 💅
_______________
(a)| | (c)
( S1 ) ---------->| >-----------> |----------> ( R1 )
| > |
| > |
(b)| > | (d)
( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 )
|_______________|
Router Configuration |
Sends | Reserves Receives
|
| _______
WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} )
| |_______| <- WF( * {2B} )
Figure 8: WF Reservation Example -- Partial Routing2. RSVP Protocol Mechanisms 🎀
2.1. RSVP Messages
Previous Incoming Outgoing Next
Hops Interfaces Interfaces Hops
_____ _____________________ _____
| | data --> | | data --> | |
| A |-----------| a c |--------------| C |
|_____| Path --> | | Path --> |_____|
<-- Resv | | <-- Resv _____
_____ | ROUTER | | | |
| | | | | |--| D |
| B |--| data-->| | data --> | |_____|
|_____| |--------| b d |-----------|
| Path-->| | Path --> | _____
_____ | <--Resv|_____________________| <-- Resv | | |
| | | |--| D' |
| B' |--| | |_____|
|_____| | |
Figure 9: Router Using RSVPFigure 9 is RSVP's model of a router node, and honestly it's so clean 😭 Each data flow shows up from a "previous hop" through a corresponding "incoming interface" and leaves through one or more "outgoing interface"(s). The same interface can play both the incoming and outgoing roles for different data flows in the same session. Multiple previous hops and/or next hops can be reached through one physical interface. For example, the figure implies that D and D' are connected to (d) with a broadcast LAN. 🧚
There are two fundamental RSVP message types: Resv and Path. 🍓
Each receiver host sends RSVP reservation request (Resv) messages upstream toward the senders. These messages must follow exactly the reverse of the path(s) the data packets will use, going upstream to all the sender hosts included in the sender selection. They create and maintain "reservation state" in each node along the path(s). Resv messages must finally be delivered to the sender hosts themselves, so the hosts can set up appropriate traffic control parameters for the first hop. We already talked about how Resv messages get processed back in Section 1.2, so go check that if you need a refresher 🙈
Each RSVP sender host sends RSVP "Path" messages downstream along the uni-/multicast routes provided by the routing protocol(s), following the paths of the data. These Path messages store "path state" in each node along the way. That path state includes at least the unicast IP address of the previous hop node, which is used to route the Resv messages hop-by-hop in the reverse direction. (In the future, some routing protocols may supply reverse path forwarding information directly, replacing the reverse-routing function of path state. The future is looking bright 🌈)
A Path message carries the following information in addition to the previous hop address:
- Sender Template: A Path message is required to carry a Sender Template, which describes the format of the data packets the sender will originate. This template is in the form of a filter spec that could be used to select this sender's packets from others in the same session on the same link. Sender Templates have exactly the same expressive power and format as the filter specs that appear in Resv messages. So a Sender Template may specify only the sender IP address and optionally the UDP/TCP sender port, and it assumes the protocol Id specified for the session. 💜
- Sender Tspec: A Path message is required to carry a Sender Tspec, which defines the traffic characteristics of the data flow the sender will generate. This Tspec is used by traffic control to prevent over-reservation, and perhaps unnecessary Admission Control failures. 🫶
- Adspec: A Path message may carry a package of OPWA advertising information, known as an "Adspec". An Adspec received in a Path message is passed to the local traffic control, which returns an updated Adspec. The updated version is then forwarded in Path messages sent downstream. 📣
Path messages are sent with the same source and destination addresses as the data, so they get routed correctly through non-RSVP clouds (see Section 2.9). On the other hand, Resv messages are sent hop-by-hop. Each RSVP-speaking node forwards a Resv message to the unicast address of a previous RSVP hop. Different vibes, same goal 🦋
2.2. Merging Flowspecs
A Resv message forwarded to a previous hop carries a flowspec that is the "largest" of the flowspecs requested by the next hops the data flow will be sent to. (However, see Section 3.5 for a different merging rule used in certain cases.) We say the flowspecs have been "merged". The examples in Section 1.4 showed another case of merging: multiple reservation requests from different next hops for the same session and the same filter spec, where RSVP should install only one reservation on that interface. Here again, the installed reservation should have an effective flowspec that is the "largest" of the flowspecs requested by the different next hops. ✨
Flowspecs are opaque to RSVP, so the actual rules for comparing them have to be defined and implemented outside RSVP proper. The comparison rules are defined in the appropriate integrated service specification document. An RSVP implementation will need to call service-specific routines to perform flowspec merging. 🔥
Here's the tea: flowspecs are generally multi-dimensional vectors. They may contain both Tspec and Rspec components, and each of those may itself be multi-dimensional. So it may not be possible to strictly order two flowspecs. For example, if one request calls for a higher bandwidth and another calls for a tighter delay bound, neither one is "larger" than the other. In a case like that, instead of taking the larger, the service-specific merging routines must be able to return a third flowspec that is at least as large as each. Mathematically, that's the "least upper bound" (LUB). In some cases, a flowspec at least as small is needed. That's the "greatest lower bound" (GLB). 💅
The effective flowspec (Re, Te) to be installed on an interface is calculated using the following steps [RFC 2210]. Here Te is the effective Tspec and Re is the effective Rspec.
- An effective flowspec is determined for the outgoing interface. Depending on the link-layer technology, this may require merging flowspecs from different next hops. That means computing the effective flowspec as the LUB of the flowspecs. Note that what flowspecs to merge is determined by the link layer medium (see Section 3.11.2), while how to merge them is determined by the service model in use [RFC 2210]. The result is a flowspec that is opaque to RSVP but actually consists of the pair (Re, Resv_Te), where Re is the effective Rspec and Resv_Te is the effective Tspec.
- A service-specific calculation of Path_Te is performed. Path_Te is the sum of all the Tspecs that were supplied in Path messages from different previous hops (e.g., some or all of A, B, and B' in Figure 9).
- (Re, Resv_Te) and Path_Te are passed to traffic control. Traffic control will compute the effective flowspec as the "minimum" of Path_Te and Resv_Te, in a service-dependent manner. 🧁
Section 3.11.6 defines a generic set of service-specific calls to compare flowspecs, to compute the LUB and GLB of flowspecs, and to compare and sum Tspecs. We're getting into the good stuff now 👑
2.3. Soft State 🌙
RSVP is giving soft state, bestie 🧚 Reservations get created and then refreshed over and over by Path and Resv messages. If no matching refresh shows up before the cleanup timeout runs out, the state is deleted. An explicit teardown message can also wipe it, which we'll get to in the next section 💅 At every refresh timeout, and after any state change, RSVP scans its state and builds and forwards fresh Path and Resv refresh messages to the next hops.
Path and Resv messages are idempotent, so sending the same one twice is totally fine 🫶 When a route changes, the next Path message sets up path state on the new route, and future Resv messages build the reservation state there. The state on the old, now-unused part of the route just times out. Whether a message counts as "new" or a "refresh" gets figured out separately at each node, depending on whether that node already has state. Main character energy 👑
RSVP sends its messages as plain IP datagrams with no reliability add-ons 🦋 Hosts and routers just keep resending refresh messages so an occasional lost RSVP message gets covered. If the effective cleanup timeout is K times the refresh timeout period, RSVP can survive K-1 losses in a row without wrongly deleting state. The traffic control mechanism should be configured ahead of time to give RSVP messages some minimal bandwidth, so congestion doesn't knock them out 🌸
The state RSVP keeps is super dynamic 💖 If you want to change the set of senders Si or tweak any QoS request, a host just starts sending revised Path and/or Resv messages. Every node along the path adjusts its RSVP state to match, and any unused state times out unless it gets explicitly torn down.
In steady state, refreshes go hop-by-hop so merging can happen 🧚 When the received state is different from what's stored, the stored state gets updated. If that update changes the state that gets forwarded in refresh messages, those refresh messages have to be generated and forwarded right away, so the changes travel end-to-end with zero delay ✨ The propagation stops as soon as it hits a point where merging doesn't change anything. That keeps RSVP control traffic low when things change, and honestly it's essential for scaling to big multicast groups 🔥
State received through a particular interface I* should never go back out that same interface 🙈 And state sent out I* has to be computed only from state that arrived on interfaces other than I*. The simplest example is Figure 10: a transit router with one sender and one receiver on each interface, assuming one next or previous hop per interface. Interfaces (a) and (c) act as both the outgoing and incoming interface for this session. Both receivers make wildcard-style reservations, so their Resv messages go to all previous hops for senders in the group, except the one they came from. The result is independent reservations in each direction 🦋
________________
a | | c
( R1, S1 ) <----->| Router |<-----> ( R2, S2 )
|________________|
Send | Receive
|
WF( *{3B}) <-- (a) | (c) <-- WF( *{3B})
|
Receive | Send
|
WF( *{4B}) --> (a) | (c) --> WF( *{4B})
|
Reserve on (a) | Reserve on (c)
__________ | __________
| * {4B} | | | * {3B} |
|__________| | |__________|
|
Figure 10: Independent ReservationsThere's one more rule for forwarding Resv messages, and it's a big one 👑 State from Resv messages received from outgoing interface Io should only be forwarded to incoming interface Ii if Path messages from Ii are forwarded to Io.
2.4 Teardown
RSVP "teardown" messages wipe path or reservation state immediately ✨ You don't have to explicitly tear down an old reservation, but we recommend that all end hosts send a teardown request as soon as an application finishes 💅
There are two kinds of RSVP teardown message: PathTear and ResvTear 🎀 A PathTear travels toward all receivers downstream from where it started, and it deletes path state along with any reservation state that depends on it. A ResvTear deletes reservation state and travels toward all senders upstream from where it started. You can think of a PathTear (or ResvTear) as a Path (or Resv) message going in reverse 🔄
A teardown request can start from an application on an end system (sender or receiver), or from a router because a state timed out or service got preempted 🫠 Once it starts, it gets forwarded hop-by-hop without delay. A teardown message deletes the specified state at the node that receives it. That change only gets propagated to the next node immediately if there's still a net change after merging. So a ResvTear only prunes reservation state back as far as it possibly can 🌿
Teardown requests aren't delivered reliably either, just like every other RSVP message 🥺 But losing one isn't a disaster, since the unused state will eventually time out even without being explicitly deleted. If a teardown message gets lost, the router that never got it will time out its state and start a new teardown beyond the point of loss. As long as RSVP message loss is pretty rare, the longest time to delete state will seldom go past one refresh timeout period 💖
You can tear down any subset of the established state 🧚 For path state, the granularity is a single sender. For reservation state, it's an individual filter spec. Check out Figure 7: receiver R1 could send a ResvTear for sender S2 only (or for any subset of the filter spec list), and S1 stays right where it is 🦋
A ResvTear message specifies the style and filters, and any flowspec is ignored 🙈 Whatever flowspec is in place gets removed once all of its filter specs are torn down.
2.5 Errors
There are two RSVP error messages: ResvErr and PathErr 😭 PathErr messages are super simple. They just go upstream to the sender that created the error, and they don't change path state in the nodes they pass through. There are only a few possible causes of path errors.
Reservation requests can fail in a bunch of ways, even when they're syntactically valid 💀 A node can also decide to preempt an established reservation. Handling ResvErr messages is kind of complicated (see Section 3.5). Since a failed request might be the result of merging a bunch of requests, a reservation error has to be reported to all of the responsible receivers 🫶 Merging heterogeneous requests also creates a potential problem called the "killer reservation" problem, where one request could deny service to another. And there are actually two killer-reservation problems 🔥
- The first killer reservation problem (KR-I) shows up when there's already a reservation Q0 in place. If another receiver makes a bigger reservation Q1 > Q0, merging Q0 and Q1 might get rejected by admission control at some upstream node. That must not deny service to Q0.
The fix is simple: when admission control fails for a reservation request, any existing reservation stays in place ✨
- The second killer reservation problem (KR-II) is the reverse. The receiver making reservation Q1 is persistent even though Admission Control keeps failing for Q1 at some node. That must not stop a different receiver from establishing a smaller reservation Q0 that would've succeeded if it hadn't been merged with Q1 👑
To fix this, a ResvErr message creates extra state called "blockade state" at each node it passes through. Blockade state changes the merging process so it leaves out the offending flowspec (Q1 in the example). That lets a smaller request get forwarded and established. The Q1 reservation state is said to be "blockaded" 🚫 Detailed rules are in Section 3.5.
A reservation request that fails Admission Control creates blockade state, but it stays in place in the nodes downstream of the failure point 🥹 People sometimes say these downstream reservations are "wasted" and should time out if nobody actively deletes them. But they get left in place, and here's why:
- There are two possible reasons a receiver keeps going with a failed reservation: (1) it's polling for resource availability along the entire path, or (2) it wants the desired QoS along as much of the path as possible. In the second case for sure, and maybe in the first case too, the receiver will want to hold onto the reservations it made downstream from the failure 💅
- If those downstream reservations weren't kept, RSVP would be way less responsive to certain transient failures. Say a route flaps to an alternate route that's congested, so an existing reservation suddenly fails, then quickly recovers to the original route 🌈 The blockade state in each downstream router must not remove the state or prevent its immediate refresh.
- If we didn't refresh the downstream reservations, they might time out and then get restored every Tb seconds (where Tb is the blockade state timeout interval). That kind of on-off behavior could be super distressing for users 😩
2.6 Confirmation
If a receiver Rj wants a confirmation for its reservation request, it puts a confirmation-request object containing Rj's IP address into the Resv message 🎀 At each merge point, only the largest flowspec and any accompanying confirmation-request object gets forwarded upstream. If the reservation request from Rj is equal to or smaller than the reservation already in place on a node, its Resv doesn't get forwarded any further. And if that Resv included a confirmation-request object, a ResvConf message gets sent back to Rj 🫶 If the confirmation request does get forwarded, it goes out immediately, and no more than once for each request ✨
This confirmation mechanism has some big consequences, bestie 👀💅
- A new reservation request with a flowspec larger than any in place for a session will normally result in either a
ResvError aResvConfmessage back to the receiver from each sender. In this case, theResvConfmessage will be an end-to-end confirmation. 🎀 - The receipt of a
ResvConfgives no guarantees 😭 Say the first two reservation requests from receivers R1 and R2 arrive at the node where they get merged. R2, whose reservation was the second to arrive at that node, may get aResvConffrom that node while R1's request hasn't propagated all the way to a matching sender yet and can still fail. So R2 may receive aResvConfeven though there's no end-to-end reservation in place, and R2 may even get aResvConffollowed by aResvErr. Not me being like "wait, what" 💀
2.7 Policy Control 👑
RSVP-mediated QoS requests let particular user(s) get preferential access to network resources. To stop abuse, some form of back pressure will generally be required on users who make reservations. This back pressure might come from administrative access policies, or it might depend on some form of user feedback, like real or virtual billing for the "cost" of a reservation. Either way, reliable user identification and selective admission will generally be needed when a reservation is requested 🫶
The term "policy control" is used for the mechanisms required to support access policies and back pressure for RSVP reservations. When a new reservation is requested, each node has to answer two questions: "Are enough resources available to meet this request?" and "Is this user allowed to make this reservation?" These two decisions are called the "admission control" decision and the "policy control" decision, respectively, and both must be favorable for RSVP to make a reservation. Different administrative domains in the Internet may have different reservation policies, so it's giving multiple rulebooks 📖✨
The input to policy control is called "policy data", which RSVP carries in POLICY_DATA objects. Policy data may include credentials identifying users or user classes, account numbers, limits, quotas, etc. Like flowspecs, policy data is opaque to RSVP, so RSVP just passes it to policy control when required. Merging policy data also has to be done by the policy control mechanism rather than by RSVP itself. Note that the merge points for policy data are likely to be at the boundaries of administrative domains. It may therefore be necessary to carry accumulated and unmerged policy data upstream through multiple nodes before it reaches one of these merge points 🧚
Carrying user-provided policy data in Resv messages presents a potential scaling problem 🙈 When a multicast group has a large number of receivers, it will be impossible or undesirable to carry all receivers' policy data upstream. The policy data will have to be administratively merged at places near the receivers, so it doesn't get excessive. Further discussion of these issues and an example of a policy control scheme will be found in [PolArch96]. Specifications for the format of policy data objects and RSVP processing rules for them are still under development 🚧
2.8 Security 🔐
RSVP raises the following security issues, and honestly they're kind of serious 😤
- Message integrity and node authentication
Corrupted or spoofed reservation requests could lead to theft of service by unauthorized parties, or to denial of service caused by locking up network resources. RSVP protects against such attacks with a hop-by-hop authentication mechanism using an encrypted hash function. The mechanism is supported by INTEGRITY objects that may appear in any RSVP message. These objects use a keyed cryptographic digest technique, which assumes that RSVP neighbors share a secret. Although this mechanism is part of the base RSVP specification, it is described in a companion document [Baker96].
Widespread use of the RSVP integrity mechanism will require the availability of the long-sought key management and distribution infrastructure for routers. Until that infrastructure becomes available, manual key management will be required to secure RSVP message integrity 🔑
- User authentication
Policy control will depend upon positive authentication of the user responsible for each reservation request. Policy data may therefore include cryptographically protected user certificates. Specification of such certificates is a future issue 🌸
Even without globally-verifiable user certificates, it may be possible to provide practical user authentication in many cases by establishing a chain of trust, using the hop-by-hop INTEGRITY mechanism described earlier.
- Secure data streams
The first two security issues concerned RSVP's operation. A third security issue concerns resource reservations for secure data streams. In particular, the use of IPSEC (IP Security) in the data stream poses a problem for RSVP: if the transport and higher level headers are encrypted, RSVP's generalized port numbers cannot be used to define a session or a sender.
To solve this problem, an RSVP extension has been defined in which the security association identifier (IPSEC SPI) plays a role roughly equivalent to the generalized ports [RFC 2207] 🦋
2.9 Non-RSVP Clouds ☁️
It is impossible to deploy RSVP (or any new protocol) at the same moment throughout the entire Internet. Furthermore, RSVP may never be deployed everywhere. So RSVP must therefore provide correct protocol operation even when two RSVP-capable routers are joined by an arbitrary "cloud" of non-RSVP routers. Of course, an intermediate cloud that doesn't support RSVP is unable to perform resource reservation. However, if such a cloud has sufficient capacity, it may still provide useful realtime service ⭐
RSVP is designed to operate correctly through such a non-RSVP cloud. Both RSVP and non-RSVP routers forward Path messages towards the destination address using their local uni-/multicast routing table. Therefore, the routing of Path messages will be unaffected by non-RSVP routers in the path. When a Path message traverses a non-RSVP cloud, it carries to the next RSVP-capable node the IP address of the last RSVP-capable router before entering the cloud. A Resv message is then forwarded directly to the next RSVP-capable router on the path(s) back towards the source 🎀
Even though RSVP operates correctly through a non-RSVP cloud, the non-RSVP-capable nodes will in general perturb the QoS provided to a receiver. So RSVP passes a NonRSVP flag bit to the local traffic control mechanism when there are non-RSVP-capable hops in the path to a given sender. Traffic control combines this flag bit with its own sources of information, and forwards the composed information on integrated service capability along the path to receivers using Adspecs [RFC 2210] 🌈
Some topologies of RSVP routers and non-RSVP routers can cause Resv messages to arrive at the wrong RSVP-capable node, or to arrive at the wrong interface of the correct node. An RSVP process must be prepared to handle either situation. If the destination address doesn't match any local interface and the message is not a Path or PathTear, the message must be forwarded without further processing by this node. To handle the wrong interface case, a "Logical Interface Handle" (LIH) is used. The previous hop information included in a Path message includes not only the IP address of the previous node but also an LIH defining the logical outgoing interface, and both values are stored in the path state. A Resv message arriving at the addressed node carries both the IP address and the LIH of the correct outgoing interface, i.e, the interface that should receive the requested reservation, regardless of which interface it arrives on 🧭
The LIH may also be useful when RSVP reservations are made over a complex link layer, to map between IP layer and link layer flow entities ✨
2.10 Host Model 🖥️
Before a session can be created, the session identification (DestAddress, ProtocolId [, DstPort]) must be assigned and communicated to all the senders and receivers by some out-of-band mechanism. When an RSVP session is being set up, the following events happen at the end systems:
H1 A receiver joins the multicast group specified by
DestAddress, using IGMP.
H2 A potential sender starts sending RSVP Path messages to the
DestAddress.
H3 A receiver application receives a Path message.
H4 A receiver starts sending appropriate Resv messages,
specifying the desired flow descriptors.
H5 A sender application receives a Resv message.
H6 A sender starts sending data packets.There are several synchronization considerations, and they're kinda important 👀
- H1 and H2 may happen in either order.
- Suppose that a new sender starts sending data (H6) but there are no multicast routes because no receivers have joined the group (H1). Then the data will be dropped at some router node (which node depends upon the routing protocol) until receiver(s) appear 🙃
- Suppose that a new sender starts sending Path messages (H2) and data (H6) simultaneously, and there are receivers but no Resv messages have reached the sender yet (e.g., because its Path messages have not yet propagated to the receiver(s)). Then the initial data may arrive at receivers without the desired QoS. The sender could mitigate this problem by awaiting arrival of the first Resv message (H5); however, receivers that are farther away may not have reservations in place yet 🥺
- If a receiver starts sending Resv messages (H4) before receiving any Path messages (H3), RSVP will return error messages to the receiver.
The receiver may simply choose to ignore such error messages, or it may avoid them by waiting for Path messages before sending Resv messages 💜
A specific application program interface (API) for RSVP is not defined in this protocol spec, as it may be host system dependent. However, Section 3.11.1 discusses the general requirements and outlines a generic interface 🧁
3. RSVP Functional Specification 🌟
3.1 RSVP Message Formats 💌
An RSVP message consists of a common header, followed by a body consisting of a variable number of variable-length, typed "objects". The following subsections define the formats of the common header, the standard object header, and each of the RSVP message types 🦋
For each RSVP message type there's a whole rulebook 📜 saying which object types are allowed. It's written in Backus-Naur Form (BNF) with square brackets around the optional sub-sequences 🎀. The BNF kinda implies an order for the objects in a message, but honestly in lots of cases (not all!) object order makes zero logical difference 🙈. An implementation SHOULD create messages with the objects in the order shown here, but accept the objects in any permissible order ✨
3.1.1 Common Header 🎀
0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | Flags| Msg Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+
| Send_TTL | (Reserved) | RSVP Length |
+-------------+-------------+-------------+-------------+Okay, so here are the fields in the common header 💅
Vers: 4 bits- Protocol version number. This is version 1.
Flags: 4 bits0x01-0x08: Reserved- No flag bits are defined yet.
Msg Type: 8 bits- The message types are numbered like this 💜
1 = Path
2 = Resv
3 = PathErr
4 = ResvErr
5 = PathTear
6 = ResvTear
7 = ResvConfRSVP Checksum: 16 bits- The one's complement of the one's complement sum of the message, with the checksum field replaced by zero for the purpose of computing the checksum. An all-zero value means that no checksum was transmitted 🥺
Send_TTL: 8 bits- The IP TTL value with which the message was sent. See Section 3.8.
RSVP Length: 16 bits- The total length of this RSVP message in bytes, including the common header and the variable-length objects that follow 🌸
3.1.2 Object Formats ✨
Every object is made of one or more 32-bit words, and it starts with a one-word header. Here's the vibe:
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+An object header has the following fields:
Length- A 16-bit field containing the total object length in bytes. It MUST always be a multiple of 4, and at least 4 🔥
Class-Num- Identifies the object class. The values of this field are defined in Appendix A. Each object class has a name, which is always capitalized in this document. An RSVP implementation MUST recognize the following classes 👑
NULL: A NULL object has a Class-Num of zero, and its C-Type is ignored. Its length MUST be at least 4, but can be any multiple of 4. A NULL object MAY appear anywhere in a sequence of objects, and its contents will be ignored by the receiver 🙈SESSION: Contains the IP destination address (DestAddress), the IP protocol id, and some form of generalized destination port, to define a specific session for the other objects that follow. REQUIRED in every RSVP message 💖RSVP_HOP: Carries the IP address of the RSVP-capable node that sent this message and a logical outgoing interface handle (LIH; see Section 3.3). This document refers to a RSVP_HOP object as a PHOP ("previous hop") object for downstream messages or as a NHOP (" next hop") object for upstream messages 🦋TIME_VALUES: Contains the value for the refresh period R used by the creator of the message; see Section 3.7. REQUIRED in every Path and Resv message ⏰STYLE: Defines the reservation style plus style-specific information that is not in FLOWSPEC or FILTER_SPEC objects. REQUIRED in every Resv message 🎀FLOWSPEC: Defines a desired QoS, in a Resv message. ✨FILTER_SPEC: Defines a subset of session data packets that SHOULD receive the desired QoS (specified by a FLOWSPEC object), in a Resv message 🌈SENDER_TEMPLATE: Contains a sender IP address and perhaps some additional demultiplexing information to identify a sender. REQUIRED in a Path message 🧚SENDER_TSPEC: Defines the traffic characteristics of a sender's data flow. REQUIRED in a Path message 📈ADSPEC: Carries OPWA data, in a Path message 🌸ERROR_SPEC: Specifies an error in a PathErr, ResvErr, or a confirmation in a ResvConf message 😭POLICY_DATA: Carries information that will allow a local policy module to decide whether an associated reservation is administratively permitted. MAY appear in Path, Resv, PathErr, or ResvErr message. The use of POLICY_DATA objects is not fully specified at this time; a future document will fill this gap 🔮INTEGRITY: Carries cryptographic data to authenticate the originating node and to verify the contents of this RSVP message. The use of the INTEGRITY object is described in [Baker96] 🔐SCOPE: Carries an explicit list of sender hosts towards which the information in the message is to be forwarded. MAY appear in a Resv, ResvErr, or ResvTear message. See Section 3.4 🫶RESV_CONFIRM: Carries the IP address of a receiver that requested a confirmation. MAY appear in a Resv or ResvConf message 💜
C-Type- Object type, unique within Class-Num. Values are defined in Appendix A.
The maximum object content length is 65528 bytes. The Class-Num and C-Type fields may be used together as a 16-bit number to define a unique type for each object 🍓
The high-order two bits of the Class-Num is used to determine what action a node SHOULD take if it does not recognize the Class-Num of an object; see Section 3.10 🌈
3.1.3 Path Messages 🦋
Each sender host periodically sends a Path message for each data flow it originates. It contains a SENDER_TEMPLATE object defining the format of the data packets and a SENDER_TSPEC object specifying the traffic characteristics of the flow. Optionally, it MAY contain MAY be an ADSPEC object carrying advertising (OPWA) data for the flow 💅
A Path message travels from a sender to receiver(s) along the same path(s) used by the data packets. The IP source address of a Path message MUST be an address of the sender it describes, while the destination address MUST be the DestAddress for the session. These addresses assure that the message will be correctly routed through a non-RSVP cloud 🗺️
The format of a Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]If the INTEGRITY object is present, it MUST immediately follow the common header. There are no other requirements on transmission order, although the above order is RECOMMENDED. Any number of POLICY_DATA objects MAY appear 💖
The PHOP (i.e., RSVP_HOP) object of each Path message contains the previous hop address, i.e., the IP address of the interface through which the Path message was most recently sent. It also carries a logical interface handle (LIH) 🌸
Each RSVP-capable node along the path(s) captures a Path message and processes it to create path state for the sender defined by the SENDER_TEMPLATE and SESSION objects. Any POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in the path state. If an error is encountered while processing a Path message, a PathErr message is sent to the originating sender of the Path message. Path messages MUST satisfy the rules on SrcPort and DstPort in Section 3.2 🔥
Periodically, the RSVP process at a node scans the path state to create new Path messages to forward towards the receiver(s). Each message contains a sender descriptor defining one sender, and carries the original sender's IP address as its IP source address. Path messages eventually reach the applications on all receivers; however, they are not looped back to a receiver running in the same application process as the sender 🔁
The RSVP process forwards Path messages and replicates them as required by multicast sessions, using routing information it obtains from the appropriate uni-/multicast routing process. The route depends upon the session DestAddress, and for some routing protocols also upon the source (sender's IP) address. The routing information generally includes the list of zero or more outgoing interfaces to which the Path message is to be forwarded. Because each outgoing interface has a different IP address, the Path messages sent out different interfaces contain different PHOP addresses. In addition, ADSPEC objects carried in Path messages will also generally differ for different outgoing interfaces 🌈
Path state for a given session and sender may not necessarily have a unique PHOP or unique incoming interface. There are two cases, corresponding to multicast and unicast sessions 👀
- Multicast Sessions
Multicast routing allows a stable distribution tree in which Path messages from the same sender arrive from more than one PHOP, and RSVP MUST be prepared to maintain all such path state. The RSVP rules for handling this situation are contained in Section 3.9. RSVP MUST NOT forward (according to the rules of Section 3.9) Path messages that arrive on an incoming interface different from that provided by routing 🫶
- Unicast Sessions
3.1.4 Resv Messages 💌
Resv messages are the reservation requests that hop ✨ back from receivers to senders, zooming along the reverse paths of the session's data flows 🔙. The IP destination address is the unicast address of a previous-hop node, grabbed from the path state 🎯. The IP source address is the address of the node that sent the message.
Here's the Resv message format:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <empty> |
<flow descriptor list> <flow descriptor>Okay so, if there's an INTEGRITY object, it MUST immediately follow the common header 🔐. The STYLE object plus the flow descriptor list MUST sit at the very end of the message, and anything inside the flow descriptor list MUST follow the BNF below 📋. There are no other rules about transmission order, although the order above is RECOMMENDED 💅.
The NHOP (aka the RSVP_HOP) object holds the IP address of the interface the Resv message went out through, plus the LIH for the logical interface where the reservation is needed 🧭.
A RESV_CONFIRM object is basically a big "pls confirm 🥺." It carries the IP address of the receiver that should get the ResvConf. You can have any number of POLICY_DATA objects, and they MAY appear 🎀.
The BNF above just says a flow descriptor list is a list of flow descriptors. The style-dependent rules below get more specific about what a valid list looks like for each reservation style 📝.
- WF style:
<flow descriptor list> ::= <WF flow descriptor>
<WF flow descriptor> ::= <FLOWSPEC>- FF style:
<flow descriptor list> ::=
<FLOWSPEC> <FILTER_SPEC> |
<flow descriptor list> <FF flow descriptor>
<FF flow descriptor> ::=
[ <FLOWSPEC> ] <FILTER_SPEC>Each elementary FF style request is one (FLOWSPEC, FILTER_SPEC) pair, and you can pack several of them into the flow descriptor list of a single Resv message 📦. A FLOWSPEC can be left out if it's identical to the most recent one in the list 🙈. The first FF flow descriptor MUST contain a FLOWSPEC, though 💖.
- SE style:
<flow descriptor list> ::= <SE flow descriptor>
<SE flow descriptor> ::=
<FLOWSPEC> <filter spec list>
<filter spec list> ::= <FILTER_SPEC>
| <filter spec list> <FILTER_SPEC>Now, the reservation scope (the set of senders a reservation gets forwarded toward, after merging) works like this 🔍:
- Explicit sender selection: The reservation goes to every sender whose SENDER_TEMPLATE objects in the path state match a FILTER_SPEC object in the reservation. That match MUST follow the rules in Section 3.2 🎯.
- Wildcard sender selection: A request with wildcard sender selection matches every sender that routes to the given outgoing interface 🌊. Whenever a Resv message with wildcard sender selection gets forwarded to more than one previous hop, a SCOPE object MUST be included in the message (see Section 3.4 below) 🫶. In that case, forwarding is limited to just the sender IP addresses explicitly listed in the SCOPE object.
A Resv message a node forwards is usually the result of merging a bunch of incoming Resv messages that are not blockaded (see Section 3.5) 🧩. If one of those merged messages has a RESV_CONFIRM object AND a FLOWSPEC that's larger than the FLOWSPECs of the other merged requests, then that RESV_CONFIRM object gets forwarded in the outgoing Resv message 👑. A RESV_CONFIRM in one of the other merged requests (whose flowspecs are equal to, smaller than, or incomparable to the merged flowspec, and which isn't blockaded) will trigger a ResvConf message carrying that RESV_CONFIRM 📨. And a RESV_CONFIRM in a blockaded request won't be forwarded or returned at all. It just gets dropped at the current node 🫠.
3.1.5 Path Teardown Messages 🧹
Receiving a PathTear (path teardown) message deletes the matching path state 🗑️. The matching state MUST match the SESSION, SENDER_TEMPLATE, and PHOP objects. On top of that, a PathTear for a multicast session can only match path state for the incoming interface where the PathTear arrived 🚪. If there's no matching path state, the PathTear SHOULD be discarded and not forwarded 🙅♀️.
PathTear messages get started explicitly by senders, or by path state timing out in any node, and they travel downstream toward all receivers ⬇️. A unicast PathTear MUST NOT be forwarded if there's path state for the same (session, sender) pair but with a different PHOP 🚫. Forwarding for multicast PathTear messages follows the rules in Section 3.9.
A PathTear MUST be routed exactly like the Path message it corresponds to 🗺️. So its IP destination address MUST be the session DestAddress, and its IP source address MUST be the sender address from the path state being torn down 💌.
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
[ <sender descriptor> ]
<sender descriptor> ::= (see earlier definition)A PathTear MAY include a SENDER_TSPEC or ADSPEC object in its sender descriptor, but those MUST be ignored 🙃. The order requirements are the same as the ones given earlier for a Path message, but the order above is RECOMMENDED 🎀.
Deleting path state, whether from a PathTear or from a timeout, also has to adjust the related reservation state so the local node stays consistent 🧠. What happens depends on the reservation style. Say a PathTear deletes the path state for sender S. With explicit sender selection (FF or SE), any reservation whose filter spec matches S SHOULD be deleted 🗑️. With wildcard sender selection (WF), the reservation SHOULD be deleted if S is the last sender to the session 🫡. These reservation changes SHOULD NOT trigger an immediate Resv refresh message, since the PathTear already made the needed changes upstream 🙌. They also SHOULD NOT trigger a ResvErr message, because the result could be a whole shower of those messages 🌧️.
3.1.6 Resv Teardown Messages 🫧
Receiving a ResvTear (reservation teardown) message deletes the matching reservation state 💨. The matching reservation state MUST match the SESSION, STYLE, and FILTER_SPEC objects, as well as the LIH in the RSVP_HOP object. If there's no matching reservation state, a ResvTear message SHOULD be discarded 🙅♀️. A ResvTear MAY tear down any subset of the filter specs in FF-style or SE-style reservation state ✂️.
ResvTear messages get started explicitly by receivers, or by any node whose reservation state has timed out, and they travel upstream toward all matching senders ⬆️. A ResvTear MUST be routed like the corresponding Resv message, and its IP destination address will be the unicast address of a previous hop 🎯.
<ResvTear Message> ::= <Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP>
[ <SCOPE> ] <STYLE>
<flow descriptor list>
<flow descriptor list> ::= (see earlier definition)FLOWSPEC objects in a ResvTear's flow descriptor list will be ignored, and they MAY be omitted 🙈. The order requirements for the INTEGRITY object, sender descriptor, STYLE object, and flow descriptor list are the same as the ones given earlier for a Resv message, but the order above is RECOMMENDED 💅. A ResvTear MAY include a SCOPE object, but it MUST be ignored 🫶.
A ResvTear stops being forwarded at the node where merging would have suppressed forwarding of the corresponding Resv message 🛑. Depending on how the state changes in a node, getting a ResvTear might mean a ResvTear gets forwarded, a modified Resv message gets forwarded, or nothing gets forwarded at all 🎢. Here are those three cases, using the FF-style reservations from Figure 6 ✨.
- If receiver R2 sends a ResvTear for its reservation S3{B}, that reservation is removed from interface (d), and a ResvTear for S3{B} gets forwarded out (b) 🦋.
- If receiver R1 sends a ResvTear for its reservation S1{4B}, that reservation is removed from interface (c), and a modified Resv message
FF( S1{3B} )is immediately forwarded out (a) ⚡. - If receiver R3 sends a ResvTear for S1{B}, nothing changes in the effective reservation S1{3B} on (d), and no message gets forwarded 🌸.
3.1.7 Path Error Messages 🚨
PathErr (path error) messages 💌 are the ones that report errors when processing Path messages. They travel upstream toward the senders, routed hop-by-hop using the path state. At each hop, the IP destination address is the unicast address of a previous hop. PathErr messages never modify the state of any node they pass through. They're only reported to the sender application 🫶
<PathErr message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC>
[ <POLICY_DATA> ...]
[ <sender descriptor> ]
<sender descriptor> ::= (see earlier definition)The ERROR_SPEC object is the one that spells out the error and includes the IP address of the node that caught it (Error Node Address) 🔍 One or more POLICY_DATA objects MAY be included message to provide relevant information. The sender descriptor gets copied over from the message in error. The object order requirements are the same as the ones given earlier for a Path message, but the order above is RECOMMENDED ✨
3.1.8 Resv Error Messages
ResvErr (reservation error) messages report errors when processing Resv messages. They can also report the spontaneous disruption of a reservation, like when it gets administratively preempted 🚨
ResvErr messages travel downstream toward the appropriate receivers, routed hop-by-hop using the reservation state. At each hop, the IP destination address is the unicast address of a next-hop node 🦋
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <POLICY_DATA> ...]
<STYLE> [ <error flow descriptor> ]The ERROR_SPEC object specifies the error and includes the IP address of the node that detected it (Error Node Address). One or more POLICY_DATA objects MAY be included in an error message to provide relevant information (e.g., when a policy control error is being reported). The RSVP_HOP object holds the previous hop address, and the STYLE object is copied from the Resv message in error. The SCOPE object in a ResvErr message is defined below in Section 3.4 🎀 The object order requirements are the same as those given for Resv messages, but the order above is RECOMMENDED.
The following style-dependent rules define what a valid error flow descriptor looks like. The object order requirements are the same as those given earlier for flow descriptors 💅
- WF Style:
<error flow descriptor> ::= <WF flow descriptor>- FF style:
<error flow descriptor> ::= <FF flow descriptor>Each flow descriptor in a FF-style Resv message MUST be processed independently, and a separate ResvErr message MUST be generated for each one that is in error. Iconic behavior 👑
- SE style:
<error flow descriptor> ::= <SE flow descriptor>An SE-style ResvErr message MAY list the subset of the filter specs in the corresponding Resv message to which the error applies.
Note that a ResvErr message contains only one flow descriptor. So a Resv message with N > 1 flow descriptors (FF style) MAY create up to N separate ResvErr messages 🌈
Generally speaking, a ResvErr message SHOULD be forwarded toward all receivers that may have caused the error being reported. More specifically:
- The node that detects an error in a reservation request sends a ResvErr message to the next hop node that the erroneous reservation came from.
This ResvErr message MUST contain the information needed to define the error and to route the error message in later hops. So it includes an ERROR_SPEC object, a copy of the STYLE object, and the appropriate error flow descriptor. If the error is an admission control failure while trying to increase an existing reservation, then the existing reservation MUST be left in place and the InPlace flag bit MUST be on in the ERROR_SPEC of the ResvErr message 🧚
- Succeeding nodes forward the ResvErr message to next hops that have local reservation state. For reservations with wildcard scope there's an extra limit on forwarding ResvErr messages, to avoid loops (see Section 3.4). There's also a rule restricting the forwarding of a Resv message after an Admission Control failure (see Section 3.5).
A ResvErr message that is forwarded SHOULD carry the FILTER_SPEC(s) from the corresponding reservation state.
- When a ResvErr message reaches a receiver, the STYLE object, flow descriptor list, and ERROR_SPEC object (including its flags) SHOULD be delivered to the receiver application 🫶
3.1.9 Confirmation Messages
ResvConf messages are sent to (probabilistically) acknowledge reservation requests. A ResvConf message is sent as the result of a RESV_CONFIRM object showing up in a Resv message 💖
A ResvConf message is sent to the unicast address of a receiver host, and that address is obtained from the RESV_CONFIRM object. However, a ResvConf message is forwarded to the receiver hop-by-hop, to accommodate the hop-by-hop integrity check mechanism 🔐
<ResvConf message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC>
<RESV_CONFIRM>
<STYLE> <flow descriptor list>
<flow descriptor list> ::= (see earlier definition)The object order requirements are the same as those given earlier for a Resv message, but the order above is RECOMMENDED.
The RESV_CONFIRM object is a copy of that object from the Resv message that triggered the confirmation. The ERROR_SPEC is only used to carry the IP address of the originating node, in the Error Node Address. The Error Code and Value are zero to indicate a confirmation 🌸 The flow descriptor list specifies the particular reservations being confirmed. It may be a subset of the flow descriptor list of the Resv that requested the confirmation.
3.2 Port Usage
An RSVP session is normally defined by the triple: (DestAddress, ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port field (i.e., a 16-bit quantity carried at octet offset +2 in the transport header). DstPort MAY be omitted (set to zero) if the ProtocolId specifies a protocol that doesn't have a destination port field in the format used by UDP and TCP 🍓
RSVP allows any value for ProtocolId. However, end-system implementations of RSVP may know about certain values for this field, specifically the values for UDP and TCP (17 and 6, respectively). An end system MAY give an error to an application that either:
- specifies a non-zero DstPort for a protocol that does not have UDP/TCP-like ports, or
- specifies a zero DstPort for a protocol that does have UDP/TCP-like ports.
Filter specs and sender templates specify the pair: (SrcAddress, SrcPort), where SrcPort is a UDP/TCP source port field (i.e., a 16-bit quantity carried at octet offset +0 in the transport header). SrcPort MAY be omitted (set to zero) in certain cases.
The following rules hold for the use of zero DstPort and/or SrcPort fields in RSVP.
- Destination ports must be consistent.
Path state and reservation state for the same DestAddress and ProtocolId MUST each have DstPort values that are all zero or all non-zero. Violating this condition in a node is a "Conflicting Dest Ports" error 😭
- Destination ports rule.
If DstPort in a session definition is zero, all SrcPort fields used for that session MUST also be zero. The assumption here is that the protocol doesn't have UDP/TCP-like ports. Violating this condition in a node is a "Bad Src Ports" error 💀
- Source Ports must be consistent.
A sender host MUST NOT send path state both with and without a zero SrcPort. Violating this condition is a "Conflicting Sender Port" error 🙈
Note that RSVP has no "wildcard" ports. In other words, a zero port can't match a non-zero port ✨
3.3 Sending RSVP Messages
RSVP messages are sent hop-by-hop between RSVP-capable routers as "raw" IP datagrams with protocol number 46. Raw IP datagrams are also meant to be used between an end system and the first/last hop router. It's also possible to encapsulate RSVP messages as UDP datagrams for end-system communication, as described in Appendix C. UDP encapsulation is needed for systems that cannot do raw network I/O 🌊
Path, PathTear, and ResvConf messages MUST be sent with the Router Alert IP option [RFC 2113] in their IP headers. This option MAY be used in the fast forwarding path of a high-speed router to detect datagrams that need special processing 🔥
Upon the arrival of an RSVP message M that changes the state, a node MUST forward the state modification immediately. However, this MUST NOT trigger sending a message out the interface through which M arrived (which could happen if the implementation simply triggered an immediate refresh of all state for the session). This rule is necessary to prevent packet storms on broadcast LANs 🌩️
In this version of the spec, each RSVP message MUST occupy exactly one IP datagram. If it exceeds the MTU, that datagram will be fragmented by IP and reassembled at the recipient node. This has several consequences:
- A single RSVP message may not exceed the maximum IP datagram size, approximately 64K bytes.
- A congested non-RSVP cloud could lose individual message fragments, and any lost fragment will lose the entire message.
Future versions of the protocol will provide solutions for these problems if they prove burdensome. The most likely direction is to perform "semantic fragmentation", i.e., break the path or reservation state being transmitted into multiple self-contained messages, each of an acceptable size 🧩
RSVP uses its periodic refresh mechanisms to recover from occasional packet losses. Under network overload, though, substantial losses of RSVP messages could cause a failure of resource reservations 😱 To control the queuing delay and dropping of RSVP packets, routers SHOULD be configured to offer them a preferred class of service. If RSVP packets experience noticeable losses when crossing a congested non-RSVP cloud, a larger value can be used for the timeout factor K (see section 3.7) 💜
Okay so multicast tunnels are lowkey the most iykyk trick ever 🦋 Some multicast routing protocols do IP encapsulation of multicast packets so they can get through routers that don't have multicast capability. The tunnel basically looks like a logical outgoing interface that gets mapped onto some physical interface, and a routing protocol that supports tunnels describes a route using a list of logical interfaces instead of physical ones. RSVP can work across these tunnels too, and here's how 💅
- When a node N forwards a Path message out a logical outgoing interface L, it puts an encoding of L's identity into the message. This is called the "logical interface handle" or LIH 🎀 The LIH value rides along in the
RSVP_HOPobject. - The next hop node N' stores that LIH value in its path state 🧚
- When N' sends a Resv message back to N, it includes the LIH value from its path state, again in the
RSVP_HOPobject. - When the Resv message gets to N, the LIH value gives N everything it needs to attach the reservation to the right logical interface. N is the one that creates and interprets the LIH. To N', it's just an opaque value 🫶
Just so we're clear, this only solves the routing problem that tunnels cause. The tunnel shows up to RSVP as a non-RSVP cloud 🌈 Setting up RSVP reservations inside the tunnel will need extra machinery, which is going to be defined later.
3.4 Avoiding RSVP Message Loops ✨
Forwarding RSVP messages has to avoid looping, no cap 😭 In steady state, Path and Resv messages get forwarded on each hop only once per refresh period. That stops packets from looping, but there's still a chance of an "auto-refresh" loop that's clocked by the refresh period. These auto-refresh loops can keep state alive "forever," even after the end nodes stop refreshing it, until the receivers leave the multicast group and/or the senders stop sending Path messages. Meanwhile, error and teardown messages get forwarded immediately, so they're open to direct looping 💀
Let's go through each message type 👑
Path Messages
Path messages get forwarded in exactly the same way as IP data packets. So there should be no loops of Path messages (except maybe transient routing loops, which we ignore here), even in a topology with cycles. Iconic behaviour 💖
PathTear Messages
PathTear messages use the same routing as Path messages, so they cannot loop 🍓
PathErr Messages
Path messages don't loop, which means they create path state that defines a loop-free reverse path to each sender. PathErr messages are always directed to particular senders, so they cannot loop either 🦋
Resv Messages
Resv messages directed to particular senders (aka explicit sender selection) cannot loop. However, Resv messages with wildcard sender selection (WF style) have the potential for auto-refresh looping 🙈
ResvTear Messages
ResvTear messages are routed the same way as Resv messages, but during the second pass around a loop there won't be any state, so any ResvTear message gets dropped. No looping problem here, periodt 💅
ResvErr Messages
ResvErr messages for WF style reservations can loop for basically the same reasons Resv messages do 😬
ResvConf Messages
ResvConf messages are forwarded toward a fixed unicast receiver address, so they cannot loop 🌸
If the topology has no loops, then looping of Resv and ResvErr messages with wildcard sender selection can be avoided by just enforcing the rule from earlier: state that is received through a particular interface must never be forwarded out that same interface. But when the topology does have cycles, extra effort is needed to stop auto-refresh loops of wildcard Resv messages and fast loops of wildcard ResvErr messages. The solution this protocol spec goes with is for those messages to carry an explicit sender address list in a SCOPE object ⭐
When a WF style Resv message is going to be forwarded to a particular previous hop, a new SCOPE object gets computed from the SCOPE objects that came in on matching Resv messages. If the computed SCOPE object is empty, the message isn't forwarded to that previous hop. Otherwise, the message gets sent with the new SCOPE object. The rules for computing a new SCOPE object for a Resv message are:
- Form the union of the sets of sender IP addresses listed in all SCOPE objects in the reservation state for the given session.
If reservation state from some NHOP doesn't contain a SCOPE object, a substitute sender list must be created and included in the union. For a message that arrived on outgoing interface OI, the substitute list is the set of senders that route to OI.
- Remove any local senders (i.e., any sender applications on this node) from that set.
- If the SCOPE object is going to be sent to PHOP, remove from the set any senders that didn't come from PHOP.
Figure 11 shows an example of wildcard-scoped (WF style) Resv messages 🎀 The address lists inside the SCOPE objects are shown in square brackets. Heads up that there may be additional connections among the nodes, creating looping topology that isn't shown.
________________
a | | c
R4, S4<----->| Router |<-----> R2, S2, S3
| |
a | |
R1, S1<----->| |
|________________|
Send on (a): | Receive on (c):
|
<-- WF( [S4] ) | <-- WF( [S4, S1])
|
Send on (b): |
|
<-- WF( [S1] ) |
|
Receive on (a): | Send on (c):
|
WF( [S1,S2,S3]) --> | WF( [S2, S3]) -->
|
Receive on (b): |
|
WF( [S2,S3,S4]) --> |
|
Figure 11: SCOPE Objects in Wildcard-Scope ReservationsOkay wait, I have to be real about something. Copying that diagram exactly means it keeps the original's labels, so I'm not fixing them. Carrying on 💖
SCOPE objects aren't necessary if multicast routing uses shared trees or if the reservation style has explicit sender selection. Also, attaching a SCOPE object to a reservation should be deferred to a node that has more than one previous hop for the reservation state 🧚
The following rules apply to SCOPE objects in WF style ResvErr messages:
- The node that detected the error starts a ResvErr message containing a copy of the SCOPE object associated with the reservation state or message in error.
- Say a wildcard-style ResvErr message shows up at a node with a SCOPE object containing the sender host address list L. The node forwards the ResvErr message using the rules of Section 3.1.8. However, the ResvErr message forwarded out OI must contain a SCOPE object derived from L by including only those senders that route to OI. If this SCOPE object is empty, the ResvErr message should not be sent out OI 😭
3.5 Blockade State 🚫
The basic rule for creating a Resv refresh message is to merge the flowspecs of the reservation requests in place in the node, by computing their LUB. This rule gets modified by the existence of "blockade state" from ResvErr messages, which solves the KR-II problem (see Section 2.5). Blockade state also plays into how ResvErr messages get routed for Admission Control failure 💅
When a ResvErr message for an Admission Control failure is received, its flowspec Qe is used to create or refresh an element of local blockade state. Each element of blockade state has a blockade flowspec Qb taken from the flowspec of the ResvErr message, plus an associated blockade timer Tb. When a blockade timer expires, the matching blockade state gets deleted.
How granular blockade state is depends on the style of the ResvErr message that created it. For an explicit style, there may be a blockade state element (Qb(S),Tb(S)) for each sender S. For a wildcard style, blockade state is per previous hop P.
An element of blockade state with flowspec Qb is said to "blockade" a reservation with flowspec Qi if Qb is not (strictly) greater than Qi. For example, suppose the LUB of two flowspecs is computed by taking the max of each of their corresponding components. Then Qb blockades Qi if, for some component j, Qb[j] <= Qi[j] 🌈
Now suppose a node receives a ResvErr message from previous hop P (or, if the style is explicit, sender S) as the result of an Admission Control failure upstream. Then:
- An element of blockade state gets created for P (or S) if it didn't already exist.
Qb(P)(orQb(S)) is set equal to the flowspec Qe from the ResvErr message.- A corresponding blockade timer
Tb(P)(orTb(S)) is started or restarted for a timeKb*R. Here Kb is a fixed multiplier and R is the refresh interval for reservation state. Kb should be configurable 🍓 - If there's some local reservation state that isn't blockaded (see below), an immediate reservation refresh for P (or S) gets generated.
- The ResvErr message is forwarded to next hops like this. If the InPlace bit is off, the ResvErr message is forwarded to all next hops that have reservation state. If the InPlace bit is on, the ResvErr message is forwarded only to the next hops whose Qi is blockaded by Qb.
Finally, here's the modified rule for merging flowspecs to create a reservation refresh message 👑
- If there are any local reservation requests Qi that aren't blockaded, they get merged by computing their LUB. The blockaded reservations get ignored. This lets a smaller reservation that hasn't failed, and might still succeed, get forwarded after a larger reservation fails.
- Otherwise (all local requests Qi are blockaded), they get merged by taking the GLB (Greatest Lower Bound) of the Qi's.
(Using some definition of "minimum" improves performance by bracketing the failure level between the largest that succeeds and the smallest that fails. GLB was picked in particular because it's simple to define and implement, and no reason is known for using a different definition of "minimum" here.)
This refresh merging algorithm gets applied separately to each flow (each sender or PHOP) contributing to a shared reservation (WF or SE style) 🌸
Okay bestie, Figure 12 is the perfect example of blockade state for a shared reservation (WF style) 💅 There are two previous hops, (a) and (b), and two next hops, (c) and (d). The bigger reservation 4B showed up first from (c), but it failed upstream via PHOP (a) and not via PHOP (b) 😭 The figure shows the final "steady state" after the smaller reservation 2B arrived from (d). That steady state gets shaken up roughly every Kb*R seconds when the blockade state times out. The next refresh sends 4B to previous hop (a), and presumably that fails, which sends a ResvErr message to rebuild the blockade state and brings us right back to this picture 🔄 At the same time, the ResvErr gets forwarded to next hop (c) and to every downstream receiver responsible for the 4B reservations 🫶
Send Blockade | Reserve Receive
State {Qb}|
| ________
(a) <- WF(*{2B}) {4B} | | * {4B} | WF(*{4B}) <- (c)
| |________|
|
---------------------------|-------------------------------
|
| ________
(b) <- WF(*{4B}) (none)| | * {2B} | WF(*{2B}) <- (d)
| |________|Figure 12: Blockading with Shared Style
3.6 Local Repair ✨
When a route changes, the next Path or Resv refresh message will establish path or reservation state (respectively) along the new route. To adapt fast to routing changes without paying the overhead of short refresh periods, the local routing protocol module can tell the RSVP process about route changes for particular destinations 🦋 The RSVP process should use that info to trigger a quick refresh of state for those destinations, using the new route.
The specific rules are as follows:
- When routing detects a change of the set of outgoing interfaces for destination
G, RSVP should update the path state, wait for a short periodW, and then send Path refreshes for all sessionsG/*(i.e., for any session with destinationG, regardless of destination port).
The short wait before sending Path refreshes gives the routing protocol time to settle, so the value for W should be chosen accordingly. Currently W = 2 sec is suggested, but this value should be configurable per interface.
- When a Path message arrives with a Previous Hop address that differs from the one stored in the path state, RSVP should send immediate Resv refreshes to that PHOP 🌸
3.7 Time Parameters ⏰
Each element of RSVP path or reservation state in a node has two time parameters. The first is the refresh period R between generation of successive refreshes for the state by the neighbor node. The second is the local state's lifetime L. Each RSVP Resv or Path message may carry a TIME_VALUES object that specifies the R value used to generate that (refresh) message, and that R is then used to work out L when the state is received and stored. The values for R and L may vary from hop to hop 💜
Here's the detailed breakdown:
- Floyd and Jacobson [FJ94] have shown that periodic messages generated by independent network nodes can become synchronized. That can disrupt network services, since the periodic messages compete with other network traffic for link and forwarding resources 😬 Because RSVP sends periodic refresh messages, it must avoid message synchronization and make sure any synchronization that does happen is not stable.
For this reason, the refresh timer should be randomly set to a value in the range [0.5R, 1.5R].
- To avoid premature loss of state,
Lmust satisfyL >= (K + 0.5)*1.5*R, whereKis a small integer. Then, in the worst case,K-1successive messages may be lost without the state being deleted. To compute a lifetimeLfor a collection of state with differentRvaluesR0, R1, ..., replaceRbymax(Ri).
Currently K = 3 is suggested as the default. However, a larger K value may be necessary for hops with a high loss rate. K may be set either by manual configuration per interface, or by some adaptive technique that has not yet been specified 🔥
- Each Path or Resv message carries a TIME_VALUES object containing the refresh time
Rused to generate refreshes. The recipient node uses thatRto determine the lifetimeLof the stored state created or refreshed by the message. - The refresh time
Ris chosen locally by each node. If the node does not implement local repair of reservations disrupted by route changes, a smallerRspeeds up adaptation to routing changes, but it also increases the RSVP overhead. With local repair, a router can be more relaxed aboutR, since the periodic refresh becomes only a backstop robustness mechanism. A node may therefore adjust the effectiveRdynamically to control the amount of overhead due to refresh messages 🧚
The current suggested default for R is 30 seconds. However, the default value Rdef should be configurable per interface.
- When
Ris changed dynamically, there is a limit on how fast it may increase. Specifically, the ratio of two successive valuesR2/R1must not exceed1 + Slew.Max.
Currently, Slew.Max is 0.30. With K = 3, one packet may be lost without a state timeout while R is increasing 30 percent per refresh cycle 👑
- To improve robustness, a node may temporarily send refreshes more often than
Rafter a state change (including initial state establishment) 🌈 - The values of
Rdef,K, andSlew.Maxused in an implementation should be easily modifiable per interface, since experience may lead to different values. Dynamically adaptingKand/orSlew.Maxin response to measured loss rates is for future study 🍓
3.8 Traffic Policing and Non-Integrated Service Hops 🚦
Some QoS services may require traffic policing at some or all of (1) the edge of the network, (2) a merging point for data from multiple senders, and/or (3) a branch point where upstream traffic flow may be greater than the downstream reservation being requested. RSVP knows where those points are and must so indicate to the traffic control mechanism. On the other hand, RSVP does not interpret the service embodied in the flowspec, so it does not know whether policing will actually be applied in any particular case 🙈
The RSVP process passes a separate policing flag for each of these three situations to traffic control:
E_Police_Flag-- Entry Policing
This flag is set in the first-hop RSVP node that implements traffic control (and is therefore capable of policing).
For example, sender hosts must implement RSVP, but currently many of them do not implement traffic control. In that case, the E_Police_Flag should be off in the sender host, and it should only be set on when the first node capable of traffic control is reached. This is controlled by the E_Police flag in SESSION objects.
M_Police_Flag-- Merge Policing
This flag should be set on for a reservation using a shared style (WF or SE) when flows from more than one sender are being merged.
B_Police_Flag-- Branch Policing
This flag should be set on when the flowspec being installed is smaller than, or incomparable to, a FLOWSPEC in place on any other interface, for the same FILTER_SPEC and SESSION.
RSVP must also test for the presence of non-RSVP hops in the path and pass that information to traffic control. From this flag bit that the RSVP process supplies, plus its own local knowledge, traffic control can detect a hop in the path that is not capable of QoS control, and it passes this information to the receivers in Adspecs [RFC 2210] ✨
With normal IP forwarding, RSVP can detect a non-RSVP hop by comparing the IP TTL with which a Path message is sent to the TTL with which it is received. For this purpose, the transmission TTL is placed in the common header. However, the TTL is not always a reliable indicator of non-RSVP hops, so other means must sometimes be used. For example, if the routing protocol uses IP encapsulating tunnels, then the routing protocol must inform RSVP when non-RSVP hops are included. If no automatic mechanism will work, manual configuration will be required.
3.9 Multihomed Hosts 🏠
Accommodating multihomed hosts takes some special rules in RSVP. We use the term multihomed host to cover both hosts (end systems) with more than one network interface and routers that support local application programs.
An application running on a multihomed host may explicitly specify which interface any given flow will use for sending and/or receiving data packets, overriding the system-specified default interface. The RSVP process must be aware of the default, and if an application sets a specific interface, it must also pass that information to RSVP 💅
- Sending Data
A sender application uses an API call (SENDER in Section 3.11.1) to declare to RSVP the characteristics of the data flow it will originate. This call may optionally include the local IP address of the sender. If the application sets it, this parameter must be the interface address for sending the data packets; otherwise, the system default interface is implied.
The RSVP process on the host then sends Path messages for this application out the specified interface (only) 🚀
- Making Reservations
A receiver application uses an API call (RESERVE in Section 3.11.1) to request a reservation from RSVP. This call may optionally include the local IP address of the receiver, i.e., the interface address for receiving data packets. For multicast sessions, this is the interface on which the group has been joined. If the parameter is omitted, the system default interface is used 🎀
In general, the RSVP process should send Resv messages for an application out the specified interface, bestie 💅 But when the application is running on a router and the session is multicast, things get a lil more complicated 🙈 Say a receiver application joins the group on an interface Iapp that differs from Isp, the shortest-path interface to the sender. Then there are two possible ways multicast routing can deliver data packets to that application. The RSVP process must figure out which case holds by examining the path state, so it knows which incoming interface to use for sending Resv messages ✨
- The multicast routing protocol may create a separate branch of the multicast distribution 'tree' to deliver to
Iapp. In this case, there will be path state for both interfacesIspandIapp. The path state onIappshould only match a reservation from the local application; it must be marked "Local_only" by the RSVP process. If "Local_only" path state forIappexists, the Resv message should be sent outIapp.
Note that it is possible for the path state blocks for Isp and Iapp to have the same next hop, if there is an intervening non-RSVP cloud 🌸
- The multicast routing protocol may forward data within the router from
IsptoIapp. In this case,Iappwill appear in the list of outgoing interfaces of the path state forIsp, and the Resv message should be sent outIsp🦋 - When Path and PathTear messages are forwarded, path state marked
Local_Onlymust be ignored 🙅♀️
3.10 Future Compatibility ✨
We may expect that in the future, new object C-Types will be defined for existing object classes, and perhaps new object classes will be defined. It will be desirable to use such new objects within the Internet with older implementations that don't recognize them 🧚 Unfortunately, this is only possible to a limited degree with reasonable complexity, sis. The rules are as follows (b represents a bit).
1. Unknown Class 🍓
There are three possible ways an RSVP implementation can treat an object with unknown class. The choice is determined by the two high-order bits of the Class-Num octet, like so:
Class-Num = 0bbbbbbb: The entire message should be rejected and an "Unknown Object Class" error returned.Class-Num = 10bbbbbb: The node should ignore the object, neither forwarding it nor sending an error message.Class-Num = 11bbbbbb: The node should ignore the object but forward it, unexamined and unmodified, in all messages resulting from this message.
The following more detailed rules hold for unknown-class objects with a Class-Num of the form 11bbbbbb:
- Such unknown-class objects received in PathTear, ResvTear, PathErr, or ResvErr messages should be forwarded immediately in the same messages.
- Such unknown-class objects received in Path or Resv messages should be saved with the corresponding state and forwarded in any refresh message resulting from that state.
- When a Resv refresh is generated by merging multiple reservation requests, the refresh message should include the union of unknown-class objects from the component requests. Only one copy of each unique unknown-class object should be included in this union.
- The original order of such unknown-class objects need not be retained; however, the message that is forwarded must obey the general order requirements for its message type.
Although objects with unknown class cannot be merged, these rules will forward such objects until they reach a node that knows how to merge them 🫶 Forwarding objects with unknown class enables incremental deployment of new objects; however, the scaling limitations of doing so must be carefully examined before a new object class is deployed with both high bits on ⚠️
2. Unknown C-Type for Known Class 💜
One might expect the known Class-Num to provide information that could allow intelligent handling of such an object. However, in practice, such class-dependent handling is complex, and in many cases it is not useful 🙄
Generally, the appearance of an object with unknown C-Type should result in rejection of the entire message and generation of an error message (ResvErr or PathErr as appropriate). The error message will include the Class-Num and C-Type that failed (see Appendix B). The end system that originated the failed message may be able to use this information to retry the request using a different C-Type object, repeating this process until it runs out of alternatives or succeeds 🔁
Objects of certain classes (FLOWSPEC, ADSPEC, and POLICY_DATA) are opaque to RSVP, which simply hands them to traffic control or policy modules. Depending upon its internal rules, either of the latter modules may reject a C-Type and inform the RSVP process. RSVP should then reject the message and send an error, as described in the previous paragraph 💀
3.11 RSVP Interfaces 🎀
RSVP on a router has interfaces to routing and to traffic control. RSVP on a host has an interface to applications (i.e, an API) and also an interface to traffic control (if it exists on the host) 🌈
3.11.1 Application/RSVP Interface 👑
This section describes a generic interface between an application and an RSVP control process. The details of a real interface may be operating-system dependent; the following can only suggest the basic functions to be performed. Some of these calls cause information to be returned asynchronously ⭐
Register Session
Call: SESSION( DestAddress , ProtocolId, DstPort
[ , SESSION_object ]
[ , Upcall_Proc_addr ] ) -> Session-idThis call initiates RSVP processing for a session, defined by DestAddress together with ProtocolId and possibly a port number DstPort. If successful, the SESSION call returns immediately with a local session identifier Session-id, which may be used in subsequent calls 🦋
The Upcall_Proc_addr parameter defines the address of an upcall procedure to receive asynchronous error or event notification; see below. The SESSION_object parameter is included as an escape mechanism to support some more general definition of the session ("generalized destination port"), should that be necessary in the future. Normally, SESSION_object will be omitted ✨
Define Sender
Call: SENDER( Session-id
[ , Source_Address ] [ , Source_Port ]
[ , Sender_Template ]
[ , Sender_Tspec ] [ , Adspec ]
[ , Data_TTL ] [ , Policy_data ] )A sender uses this call to define, or to modify the definition of, the attributes of the data flow. The first SENDER call for the session registered as Session-id will cause RSVP to begin sending Path messages for this session; later calls will modify the path information 🌊
The SENDER parameters are interpreted as follows:
Source_Address: This is the address of the interface from which the data will be sent. If it is omitted, a default interface will be used. This parameter is needed only on a multihomed sender host.Source_Port: This is the UDP/TCP port from which the data will be sent.Sender_Template: This parameter is included as an escape mechanism to support a more general definition of the sender ("generalized source port"). Normally this parameter may be omitted.Sender_Tspec: This parameter describes the traffic flow to be sent; see [RFC 2210].Adspec: This parameter may be specified to initialize the computation of QoS properties along the path; see [RFC 2210].Data_TTL: This is the (non-default) IP Time-To-Live parameter that is being supplied on the data packets. It is needed to ensure that Path messages do not have a scope larger than multicast data packets.Policy_data: This optional parameter passes policy data for the sender. This data may be supplied by a system service, with the application treating it as opaque 🔐
Reserve
Call: RESERVE( session-id, [ receiver_address , ]
[ CONF_flag, ] [ Policy_data, ]
style, style-dependent-parms )A receiver uses this call to make or to modify a resource reservation for the session registered as session-id. The first RESERVE call will initiate the periodic transmission of Resv messages. A later RESERVE call may be given to modify the parameters of the earlier call (but note that changing existing reservations may result in admission control failures) 💅
The optional receiver_address parameter may be used by a receiver on a multihomed host (or router); it is the IP address of one of the node's interfaces. The CONF_flag should be set on if a reservation confirmation is desired, off otherwise. The Policy_data parameter specifies policy data for the receiver, while the style parameter indicates the reservation style. The rest of the parameters depend upon the style; generally these will be appropriate flowspecs and filter specs 🎀
The RESERVE call returns immediately. Following a RESERVE call, an asynchronous ERROR/EVENT upcall may occur at any time 🌸
Release
Call: RELEASE( session-id )This call removes RSVP state for the session specified by session-id. The node then sends appropriate teardown messages and ceases sending refreshes for this session-id 🧹
Error/Event Upcalls
The general form of a upcall is as follows:
Upcall: <Upcall_Proc>( ) -> session-id, Info_type,
information_parametersOkay so picture this 🎀 the upcall is basically a callback you hand over in the SESSION call, and "Upcall_Proc" is just the name for it 💅 It can get triggered asynchronously at literally any point after SESSION and before RELEASE, to tell you about an error or an event 🔔
Currently there are five upcall types, and they're sorted by the Info_type parameter. What info you get back depends on which type you're dealing with 🦋
1. Info_type = PATH_EVENT
Bestie, this one is the first Path message for the session showing up 🌊 It basically tells the receiver app "hey, there's at least one active sender," and it also fires if the path state changes ✨
Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=PATH_EVENT,
Sender_Tspec, Sender_Template
[ , Adspec ] [ , Policy_data ]This upcall presents the Sender_Tspec, the Sender_Template, the Adspec, and any policy data from a Path message 🧚
2. Info_type = RESV_EVENT
This one gets triggered by the first RESV message, or by a change to an earlier reservation state, for this session 🔥
Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=RESV_EVENT,
Style, Flowspec, Filter_Spec_list
[ , Policy_data ]Here 'Flowspec' is the effective QoS that got received 👑 Also, an FF-style Resv message can cause multiple RESV_EVENT upcalls, one for each flow descriptor 🌈
3. Info_type = PATH_ERROR
This is the drama one 💀 A Path Error event means something went wrong with the sender info that was given in a SENDER call 😭
Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=PATH_ERROR,
Error_code , Error_value ,
Error_Node , Sender_Template
[ , Policy_data_list ]Error_code tells you what the error is, and Error_value can carry extra (maybe system-specific) details about it 🍓 Error_Node gives the IP address of the node that caught the error, and if it's there, Policy_data_list holds any POLICY_DATA objects from the failed Path message 🫶
4. Info_type = RESV_ERR
A Resv Error event means there was an error in a reservation message that this app had a hand in 🙈
Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=RESV_ERROR,
Error_code , Error_value ,
Error_Node , Error_flags ,
Flowspec, Filter_spec_list
[ , Policy_data_list ]Error_code defines the error and Error_value might supply extra (maybe system-specific) data 🌸 Error_Node is the IP address of the node that detected the event being reported 🦋
There are two Error_flags, and they're both lowkey important 👀
- InPlace
This flag may be on for an Admission Control failure, to indicate that there was, and is, a reservation in place at the failure node. It gets set at the failure point and forwarded in ResvErr messages 💜
- NotGuilty
This flag may be on for an Admission Control failure, to indicate that the flowspec requested by this receiver was strictly less than the flowspec that got the error. It gets set at the receiver API 🙅♀️
Filter_spec_list and Flowspec hold the matching objects from the error flow descriptor (see Section 3.1.8) ✨ List_count tells you how many FILTER_SPECS are in Filter_spec_list 🔢 And Policy_data_list holds any POLICY_DATA objects from the ResvErr message 🎀
5. Info_type = RESV_CONFIRM
A Confirmation event means a ResvConf message got received 🥳
Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=RESV_CONFIRM,
Style, List_count,
Flowspec, Filter_spec_list
[ , Policy_data ]These parameters get interpreted the same way as in the Resv Error upcall 💅
Here's the tea ☕ Path or resv messages can keep showing up periodically, but the API should only make the asynchronous upcall to the app the first time it happens, or when the info being reported changes 🧠 Every error and confirmation event should get reported to the application, no exceptions 🚨
3.11.2 RSVP/Traffic Control Interface
It's honestly hard to make one generic interface for traffic control 😤 Setting up a reservation depends a lot on which link layer technology is being used on an interface 🔌
Merging RSVP reservations is required because of multicast data delivery 🌐 Multicast replicates data packets so they can go to different next-hop nodes, and at each replication point, RSVP has to merge reservation requests from those next hops by computing the "maximum" of their flowspecs ✨ At a given router or host, one or more of these three replication locations might be in use 🧚
- IP layer: IP multicast forwarding does the replication in the IP layer 💖 In this case, RSVP has to merge the reservations that are in place on the matching outgoing interfaces so it can forward a request upstream 🦋
- "The network": Replication might happen downstream from the node, like on a broadcast LAN, in link-layer switches, or in a mesh of non-RSVP-capable routers (see Section 2.8) 🕸️ Here RSVP has to merge reservations from the different next hops to make the reservation on the single outgoing interface, and it also has to merge reservation requests from all outgoing interfaces to forward a request upstream 🫶
- Link-layer driver: For a multi-access technology, replication may happen in the link layer driver or interface card 🪄 For example, this can happen when there's a separate ATM point-to-point VC toward each next hop 💜 RSVP may need to apply traffic control independently to each VC, without merging requests from different next hops 🌸
Generally speaking, these complexities don't really change the protocol processing RSVP needs to do, except for figuring out exactly which reservation requests need merging 🙌 It might be a good idea to organize an RSVP implementation into two parts: a core that does link-layer-independent processing, and a link-layer-dependent adaptation layer 🧩 That said, here we present a generic interface that assumes replication can only happen at the IP layer or in "the network" 🎀
Make a Reservation
Call: TC_AddFlowspec( Interface, TC_Flowspec,
TC_Tspec, TC_Adspec, Police_Flags )
-> RHandle [, Fwd_Flowspec]TC_Flowspec tells admission control the effective QoS you want, and its value is computed as the maximum over the flowspecs of different next hops (see the Compare_Flowspecs call below) 💖 TC_Tspec sets the effective sender Tspec Path_Te (see Section 2.2) ✨ TC_Adspec sets the effective Adspec 🌷 Police_Flags carries the three flags E_Police_Flag, M_Police_Flag, and B_Police_Flag, so check out Section 3.8 for those 👀
If this call works, it sets up a new reservation channel matching RHandle; otherwise, it returns an error code 💅 The caller uses the opaque number RHandle for any later references to this reservation 🔑 If the traffic control service updates the flowspec, the call also returns the updated object as Fwd_Flowspec 🦋
Modify Reservation
Call: TC_ModFlowspec( Interface, RHandle, TC_Flowspec,
TC_Tspec, TC_Adspec, Police_flags )
[ -> Fwd_Flowspec ]This call changes an existing reservation 🛠️ TC_Flowspec goes to Admission Control, and if it gets rejected, the current flowspec stays in force 🙅♀️ The corresponding filter specs, if there are any, aren't affected 🌈 The other parameters work the same as in TC_AddFlowspec, and if the service updates the flowspec, the call returns the updated object as Fwd_Flowspec ✨
Delete Flowspec
Call: TC_DelFlowspec( Interface, RHandle )This call deletes an existing reservation, including the flowspec and all of its associated filter specs 🗑️💀
Add Filter Spec
Call: TC_AddFilter( Interface, RHandle,
Session , FilterSpec ) -> FHandleThis call attaches an extra filter spec to the reservation named by the given RHandle, after a successful TC_AddFlowspec call 🧚 It returns a filter handle FHandle 🎟️
Delete Filter Spec
Call: TC_DelFilter( Interface, FHandle )This call removes one specific filter, the one named by FHandle 🫧
OPWA Update
Call: TC_Advertise( Interface, Adspec,
Non_RSVP_Hop_flag ) -> New_AdspecOPWA uses this call to compute the outgoing advertisement New_Adspec for a given interface 📣 The flag bit Non_RSVP_Hop_flag should be set whenever the RSVP daemon detects that the previous RSVP hop included one or more non-RSVP-capable routers 🔍 TC_Advertise puts this info into New_Adspec to show that a non-integrated-service hop was found; see Section 3.8 🌟
Preemption Upcall
Upcall: TC_Preempt() -> RHandle, Reason_codeSo, the preemption bit. When a new reservation request comes in and admission control or policy control needs room, it can kick out one or more existing reservations to make space. 💅 Each kicked-out reservation triggers a TC_Preempt() upcall to RSVP, and that upcall carries the RHandle of the bumped reservation plus a sub-code explaining why it got the boot. Iconic behaviour, honestly. 😭
3.11.3. RSVP/Policy Control Interface
This interface will be specified in a future document. 🔮 Stay tuned, bestie!
3.11.4. RSVP/Routing Interface
Okay, so RSVP needs some support from the node's routing mechanisms too. 🗺️ Here's what it needs:
- Route Query
To forward Path and PathTear messages, an RSVP process must be able to query the routing process(s) for routes.
Ucast_Route_Query( [ SrcAddress, ] DestAddress,
Notify_flag ) -> OutInterface
Mcast_Route_Query( [ SrcAddress, ] DestAddress,
Notify_flag )
-> [ IncInterface, ] OutInterface_listDepending upon the routing protocol, the query may or may not depend upon SrcAddress, i.e., upon the sender host IP address, which is also the IP source address of the message. 🤔 Here IncInterface is the interface through which the packet is expected to arrive, and some multicast routing protocols may not provide it. If the Notify_flag is True, routing will save state necessary to issue unsolicited route change notification callbacks (see below) whenever the specified route changes. 🔔
A multicast route query may return an empty OutInterface_list if there are no receivers downstream of a particular router. 🫥 A route query may also return a `No such route' error, probably as a result of a transient inconsistency in the routing (since a Path or PathTear message for the requested route did arrive at this node). 😳 In either case, the local state should be updated as requested by the message, which cannot be forwarded further. Updating local state will make path state available immediately for a new local receiver, or it will tear down path state immediately. ✨
- Route Change Notification
If requested by a route query with the Notify_flag True, the routing process may provide an asynchronous callback to the RSVP process that a specified route has changed. 📣
Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
OutInterface
Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
[ IncInterface, ] OutInterface_list- Interface List Discovery
RSVP must be able to learn what real and virtual interfaces are active, with their IP addresses. 🪪
It should be possible to logically disable an interface for RSVP. When an interface is disabled for RSVP, a Path message should never be forwarded out that interface, and if an RSVP message is received on that interface, the message should be silently discarded (perhaps with local logging). 🙈 Quiet ignore mode, the ultimate boundary-setting moment.
3.11.5. RSVP/Packet I/O Interface
RSVP also needs some support from the node's packet I/O and forwarding mechanisms. 📦 Let's go:
- Promiscuous Receive Mode for RSVP Messages
Packets received for IP protocol 46 but not addressed to the node must be diverted to the RSVP program for processing, without being forwarded. 🧲 The RSVP messages to be diverted in this manner will include Path, PathTear, and ResvConf messages. These message types carry the Router Alert IP option, which can be used to pick them out of a high-speed forwarding path. Alternatively, the node can intercept all protocol 46 packets. 🦋
On a router or multi-homed host, the identity of the interface (real or virtual) on which a diverted message is received, as well as the IP source address and IP TTL with which it arrived, must also be available to the RSVP process. 👀
- Outgoing Link Specification
RSVP must be able to force a (multicast) datagram to be sent on a specific outgoing real or virtual link, bypassing the normal routing mechanism. A virtual link might be a multicast tunnel, for example. 🚇 Outgoing link specification is necessary to send different versions of an outgoing Path message on different interfaces, and to avoid routing loops in some cases. 🔁
- Source Address and TTL Specification
RSVP must be able to specify the IP source address and IP TTL to be used when sending Path messages. 🎯
- Router Alert
RSVP must be able to cause Path, PathTear, and ResvConf message to be sent with the Router Alert IP option. 🚨
3.11.6. Service-Dependent Manipulations
Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP, so their contents are defined in service specification documents. 🫣 To manipulate these objects, RSVP process must have available to it the following service-dependent routines. 🛠️
- Compare Flowspecs
Compare_Flowspecs( Flowspec_1, Flowspec_2 ) ->
result_codeThe possible result_codes indicate: flowspecs are equal, Flowspec_1 is greater, Flowspec_2 is greater, flowspecs are incomparable but LUB can be computed, or flowspecs are incompatible. 🎀
Note that comparing two flowspecs implicitly compares the Tspecs that are contained. Although the RSVP process cannot itself parse a flowspec to extract the Tspec, it can use the Compare_Flowspecs call to implicitly calculate Resv_Te (see Section 2.2). 🧮
- Compute LUB of Flowspecs
LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
Flowspec_LUB- Compute GLB of Flowspecs
GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
Flowspec_GLB- Compare Tspecs
Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_codeThe possible result_codes indicate: Tspecs are equal, or Tspecs are unequal. ⚖️
- Sum Tspecs
Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sumThis call is used to compute Path_Te (see Section 2.2). ➕
4. Acknowledgments 🫶
The design of RSVP is based upon research performed in 1992-1993 by a collaboration including Lixia Zhang (UCLA), Deborah Estrin (USC/ISI), Scott Shenker (Xerox PARC), Sugih Jamin (USC/Xerox PARC), and Daniel Zappala (USC). Sugih Jamin developed the first prototype implementation of RSVP and successfully demonstrated it in May 1993. Shai Herzog, and later Steve Berson, continued development of RSVP prototypes. 🌱
Since 1993, many members of the Internet research community have contributed to the design and development of RSVP. These include (in alphabetical order) Steve Berson, Bob Braden, Lee Breslau, Dave Clark, Deborah Estrin, Shai Herzog, Craig Partridge, Scott Shenker, John Wroclawski, Daniel Zappala, and Lixia Zhang. 👑 In addition, a number of host and router vendors have made valuable contributions to the RSVP documents, particularly Fred Baker (Cisco), Mark Baugher (Intel), Lou Berger (Fore Systems), Don Hoffman (Sun), Steve Jakowski (NetManage), John Krawczyk (Bay Networks), and Bill Nowicki (SGI), as well as many others. 💖
APPENDIX A. Object Definitions 🧚
C-Types are defined for the two Internet address families IPv4 and IPv6. To accommodate other address families, additional C-Types could easily be defined. These definitions are contained as an Appendix, to ease updating. 🌈
All unused fields should be sent as zero and ignored on receipt. 🧼
A.1 SESSION Class
SESSION Class = 1. 🎀
- IPv4/UDP SESSION object: Class = 1, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+- IPv6/UDP SESSION object: Class = 1, C-Type = 2
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+DestAddress
The IP unicast or multicast destination address of the session. This field must be non-zero. 📍
Protocol Id
The IP Protocol Identifier for the data flow. This field must be non-zero. 🔢
Flags
0x01 = E_Police flag
The E_Police flag is used in Path messages to determine the effective "edge" of the network, to control traffic policing. If the sender host is not itself capable of traffic policing, it will set this bit on in Path messages it sends. The first node whose RSVP is capable of traffic policing will do so (if appropriate to the service) and turn the flag off. 🚓
DstPort
The UDP/TCP destination port for the session. Zero may be used to indicate `none'. 🫥
Other SESSION C-Types could be defined in the future to support other demultiplexing conventions in the transport-layer or application layer. 🔮
A.2 RSVP_HOP Class
RSVP_HOP class = 3. 🪜
- IPv4 RSVP_HOP object: Class = 3, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+- IPv6 RSVP_HOP object: Class = 3, C-Type = 2
+-------------+-------------+-------------+-------------+
- +
- IPv6 Next/Previous Hop Address +
- +
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
This object carries the IP address of the interface that the last RSVP-knowledgeable hop used to forward this message 🦋 The Logical Interface Handle (LIH) is how we tell apart logical outgoing interfaces, as discussed in Sections 3.3 and 3.9 ✨ A node that gets an LIH in a Path message saves it and sends it back in the HOP objects of later Resv messages going to the node that originated the LIH. The LIH should be identically zero if there's no logical interface handle 🙈
A.3 INTEGRITY Class
INTEGRITY class = 4.
See [Baker96]. 📚
A.4 TIME_VALUES Class
TIME_VALUES class = 5. 🕰️
TIME_VALUES Object: Class = 5, C-Type = 1
+-------------+-------------+-------------+-------------+
| Refresh Period R |
+-------------+-------------+-------------+-------------+Refresh Period
The refresh timeout period R used to generate this message, in milliseconds. ⏱️
A.5 ERROR_SPEC Class
ERROR_SPEC class = 6. 🚨
IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+IPv6 ERROR_SPEC object: Class = 6, C-Type = 2
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Error Node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+Error Node Address
The IP address of the node where the error was detected. 📍
Flags
0x01 = InPlace: This flag is only used for an ERROR_SPEC object in a ResvErr message. If it's on, it means there was, and still is, a reservation in place at the failure point. 🏠0x02 = NotGuilty: This flag is only used for an ERROR_SPEC object in a ResvErr message, and it's only set in the interface to the receiver application. If it's on, it means the FLOWSPEC that failed was strictly greater than the FLOWSPEC this receiver requested. 😤✨
Error Code
A one-octet error description. 🔢
Error Value
A two-octet field with extra info about the error. What's in it depends on the Error Type. 🧩
The values for Error Code and Error Value are defined in Appendix B. 📖
A.6 SCOPE Class
SCOPE class = 7.
This object holds a list of IP addresses, used for routing messages with wildcard scope without loops 🔁 The addresses must be listed in ascending numerical order. 💅
IPv4 SCOPE List object: Class = 7, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| IPv4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+IPv6 SCOPE list object: Class = 7, C-Type = 2
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+A.7 STYLE Class
STYLE class = 8. 🎀
STYLE object: Class = 8, C-Type = 1
+-------------+-------------+-------------+-------------+
| Flags | Option Vector |
+-------------+-------------+-------------+-------------+Flags: 8 bits
(None assigned yet) 🫙
Option Vector: 24 bits
A set of bit fields giving values for the reservation options. If new options are added in the future, their fields in the option vector will be assigned from the least-significant end. If a node doesn't recognize a style ID, it may interpret as much of the option vector as it can, ignoring any new fields that may have been defined. 🧠
The option vector bits are assigned (from the left) like this:
19 bits: Reserved
2 bits: Sharing control
00b: Reserved
01b: Distinct reservations
10b: Shared reservations
11b: Reserved
3 bits: Sender selection control
000b: Reserved
001b: Wildcard
010b: Explicit
011b - 111b: ReservedThe low order bits of the option vector are determined by the style, like so: 👑
WF 10001b
FF 01010b
SE 10010bA.8 FLOWSPEC Class
FLOWSPEC class = 9. 🌊
Reserved (obsolete) flowspec object: Class = 9, C-Type = 1Inv-serv Flowspec object: Class = 9, C-Type = 2
The contents and encoding rules for this object are specified in documents prepared by the int-serv working group [RFC 2210]. 📜
A.9 FILTER_SPEC Class
FILTER_SPEC class = 10. 🔍
IPv4 FILTER_SPEC object: Class = 10, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| ////// | ////// | SrcPort |
+-------------+-------------+-------------+-------------+IPv6 FILTER_SPEC object: Class = 10, C-Type = 2
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| ////// | ////// | SrcPort |
+-------------+-------------+-------------+-------------+IPv6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////// | Flow Label (24 bits) |
+-------------+-------------+-------------+-------------+SrcAddress
The IP source address for a sender host. It must be non-zero. 🚫0️⃣
SrcPort
The UDP/TCP source port for a sender, or zero to indicate none. 🔌
Flow Label
A 24-bit Flow Label, defined in IPv6. This value may be used by the packet classifier to efficiently identify the packets belonging to a particular (sender->destination) data flow. 🏷️✨
A.10 SENDER_TEMPLATE Class
SENDER_TEMPLATE class = 11. 🧚
IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 1: Definition same as IPv4/UDP FILTER_SPEC object. 🪞IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 2: Definition same as IPv6/UDP FILTER_SPEC object. 🪞IPv6 Flow-label SENDER_TEMPLATE object: Class = 11, C-Type = 3
A.11 SENDER_TSPEC Class
SENDER_TSPEC class = 12. 💫
Intserv SENDER_TSPEC object: Class = 12, C-Type = 2
The contents and encoding rules for this object are specified in documents prepared by the int-serv working group. 📚
A.12 ADSPEC Class
ADSPEC class = 13. 🍓
Intserv ADSPEC object: Class = 13, C-Type = 2
The contents and format for this object are specified in documents prepared by the int-serv working group. 📚
A.13 POLICY_DATA Class
POLICY_DATA class = 14. 🔐
Type 1 POLICY_DATA object: Class = 14, C-Type = 1
The contents of this object are for further study. 🔮
A.14 Resv_CONFIRM Class
RESV_CONFIRM class = 15. ✅
IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1
APPENDIX B. Error Codes and Values 🚨✨
okay bestie, this appendix is basically the RSVP "why did my request get rejected" cheat sheet 💅 The following Error Codes may show up in ERROR_SPEC objects and get passed along to end systems. Unless it says otherwise, these Error Codes only show up in ResvErr messages 📬
- Error Code = 00: Confirmation 🎉
this one is reserved for the ERROR_SPEC object of a ResvConf message. the Error Value is zero too, obviously 🫶
- Error Code = 01: Admission Control failure 💸
the reservation request got turned away by Admission Control because there weren't enough resources 😭
for this Error Code, the 16 bits of the Error Value field look like this:
ssur cccc cccc ccccwhere the bits are:
ss = 00: the low order 12 bits hold a globally-defined sub-code (listed below) 🌍
ss = 10: the low order 12 bits hold an organization-specific sub-code. RSVP isn't expected to understand it beyond reading it as a plain number 🏢
ss = 11: the low order 12 bits hold a service-specific sub-code. RSVP isn't expected to understand it beyond a plain number either. and since traffic control might swap in a different service, this encoding can include some representation of the service being used 🔄
u = 0: RSVP rejects the message and doesn't touch local state 🙅♀️
u = 1: RSVP can use the message to update local state and forward it on. basically this means it's just informational ℹ️
r: reserved bit, should be zero 🌸
cccc cccc cccc: a 12 bit code 🔢
these globally-defined sub-codes can show up in the low-order 12 bits when ssur = 0000:
- Sub-code = 1: Delay bound cannot be met ⏰
- Sub-code = 2: Requested bandwidth unavailable 📉
- Sub-code = 3: MTU in flowspec larger than interface MTU 📏
- Error Code = 02: Policy Control failure 🙅♀️
the Reservation or Path message got rejected for administrative reasons. think: required credentials missing, insufficient quota or balance, or administrative preemption 🔐 this one can show up in a PathErr or ResvErr message. the contents of the Error Value field are still TBD for the future 🔮
- Error Code = 03: No path information for this Resv message 🗺️
there's no path state for this session, so the Resv message can't be forwarded. no map, no route 💀
- Error Code = 04: No sender information for this Resv message 👻
there IS path state for this session, but it doesn't include the sender that matches some flow descriptor in the Resv message. the Resv message can't be forwarded, bestie 😭
- Error Code = 05: Conflicting reservation style ⚔️
the reservation style clashes with the style(s) of reservation state that already exists. the Error Value field holds the low-order 16 bits of the Option Vector of the existing style that caused the clash. this Resv message cannot be forwarded 🚫
- Error Code = 06: Unknown reservation style ❓
the reservation style isn't recognized at all. this Resv message cannot be forwarded 🫠
- Error Code = 07: Conflicting dest ports 🔌
sessions for the same destination address and protocol showed up with both zero and non-zero dest port fields. this one can appear in a PathErr or ResvErr message 🥴
- Error Code = 08: Conflicting sender ports 🎭
the sender port is both zero and non-zero in Path messages for the same session. this one can only appear in a PathErr message 🙃
- Error Code = 09, 10, 11: (reserved) 🤐
- Error Code = 12: Service preempted 🛑
the service request defined by the STYLE object and the flow descriptor got administratively preempted. rude 😤
for this Error Code, the 16 bits of the Error Value field look like this:
ssur cccc cccc ccccthe high-order bits ssur work the same as they do under Error Code 01 🔁 the globally-defined sub-codes that can show up in the low-order 12 bits when ssur = 0000 are to be defined in the future 🔮
- Error Code = 13: Unknown object class 🧩
the Error Value holds a 16-bit value made of (Class-Num, C-Type) for the unknown object. this error should only be sent if RSVP is going to reject the message, and that call is made by looking at the high-order bits of the Class-Num 🔍 it can show up in a PathErr or ResvErr message ✨
- Error Code = 14: Unknown object C-Type 🤷♀️
the Error Value holds the 16-bit (Class-Num, C-Type) pair for the object 📦
- Error Code = 15-19: (reserved) 🤐
- Error Code = 20: Reserved for API 🛠️
the Error Value field holds an API error code, for an API error that got detected asynchronously and has to be reported through an upcall 📣
- Error Code = 21: Traffic Control Error 🚦
the Traffic Control call failed because of the format or contents of the request parameters. the Resv or Path message that caused the call can't be forwarded, and retrying the call would be futile 🥲
for this Error Code, the 16 bits of the Error Value field look like this:
ss00 cccc cccc ccccthe high-order bits ss work the same as they do under Error Code 01 💅 these globally-defined sub-codes can show up in the low order 12 bits (cccc cccc cccc) when ss = 00:
- Sub-code = 01: Service conflict ⚔️
trying to merge two incompatible service requests 🙅♀️
- Sub-code = 02: Service unsupported 🚫
traffic control can't provide the requested service, and it doesn't have an acceptable replacement either 😩
- Sub-code = 03: Bad Flowspec value 🧾
the request is malformed or unreasonable 🤨
- Sub-code = 04: Bad Tspec value 🧾
the request is malformed or unreasonable 🤨
- Sub-code = 05: Bad Adspec value 🧾
the request is malformed or unreasonable 🤨
- Error Code = 22: Traffic Control System error 💥
a system error got detected and reported by the traffic control modules. the Error Value will hold a system-specific value with more info about the error. RSVP isn't expected to be able to interpret this value 🤖
- Error Code = 23: RSVP System error 💀
the Error Value field gives implementation-dependent info about the error. RSVP isn't expected to be able to interpret this value either 🫠
okay now the lowkey important part 🫶 in general, every RSVP message gets rebuilt at each hop, and the node that creates an RSVP message is responsible for building it correctly 🏗️ similarly, each node is required to verify that every RSVP message it receives was built correctly ✅ if a programming error ends up letting an RSVP create a malformed message, the error usually isn't reported to end systems in an ERROR_SPEC object 🙈 instead it just gets logged locally, and maybe reported through network management mechanisms 📝
the only message formatting errors that get reported to end systems are the ones that may reflect version mismatches, and that the end system might be able to work around, for example by falling back to a previous CType for an object. see codes 13 and 14 above 🔄🌈
the choice of message formatting errors that an RSVP may detect and log locally is implementation-specific 🛠️ but it will typically include the following:
- Wrong-length message: RSVP Length field does not match message length 📏
- Unknown or unsupported RSVP version 🔢
- Bad RSVP checksum 🧮
- INTEGRITY failure 🔐
- Illegal RSVP message Type 🙅♀️
- Illegal object length: not a multiple of 4, or less than 4 📐
- Next hop/Previous hop address in HOP object is illegal 🧭
- Bad source port: Source port is non-zero in a filter spec or sender template for a session with destination port zero 🔌
- Required object class (specify) missing 🕳️
- Illegal object class (specify) in this message type 🚫
- Violation of required object order 🔀
- Flow descriptor count wrong for style or message type 🔢
- Logical Interface Handle invalid 🪪
- Unknown object Class-Num 🧩
- Destination address of ResvConf message does not match Receiver Address in the RESV_CONFIRM object it contains 📬💔
the appendices are giving full main character energy ✨🌈
APPENDIX C. UDP Encapsulation 🦋✨
Okay so an RSVP implementation usually needs to do "raw" network I/O 💅, which just means sending and receiving IP datagrams using protocol 46. But some important classes of host systems might not support raw network I/O at all 🥺, so those hosts have to wrap their RSVP messages in UDP instead.
The basic UDP encapsulation scheme makes two assumptions:
- All hosts are capable of sending and receiving multicast packets if multicast destinations are to be supported.
- The first/last-hop routers are RSVP-capable.
A method of relaxing the second assumption is given later. 🌸
Let Hu be a "UDP-only" host that needs UDP encapsulation, and Hr a host that can do raw network I/O. The UDP encapsulation scheme has to allow RSVP to interoperate across any mix of Hr hosts, Hu hosts, and routers, no matter how the topology is arranged 🌈.
Resv, ResvErr, ResvTear, and PathErr messages get sent to unicast addresses that the node learned from its path or reservation state. If the node keeps track of which previous hops and which interfaces need UDP encapsulation, these messages can use UDP encapsulation when it's necessary 🧚. Path and PathTear messages are a different story: they go to the destination address for the session, which can be unicast or multicast 👑.
The tables in Figures 13 and 14 lay out the basic rules for UDP encapsulation of Path and PathTear messages, one table for unicast DestAddress and one for multicast DestAddress. The other message types are sent unicast, so they should follow the unicast rules in Figure 13 💖. Under the RSVP Send' columns, the notation is mode(destaddr, destport), and destport is left out for raw packets. The Receive' columns show the group that gets joined and, where it matters, the UDP Listen port 🎀.
Two flavors of UDP encapsulation are useful here: one sent by Hu, and one sent by Hr and R. Splitting them up stops the recipient from processing the same thing twice 🙈. In practice, the two flavors are told apart by their different UDP port numbers, Pu and Pu'.
Here's the symbol cheat sheet for the tables:
- D is the DestAddress for the particular session.
- G* is a well-known group address of the form
224.0.0.14, which means a group that's limited to the local connected network. - Pu and Pu' are two well-known UDP ports for UDP encapsulation of RSVP, with values
1698and1699. - Ra is the IP address of the router interface
a. - Router interface
ais on the local network connected to Hu and Hr.
The following notes apply to these figures:
- [Note 1] Hu sends a unicast Path message either to the destination address D, if D is local, or to the address Ra of the first-hop router. Ra is presumably known to the host.
- [Note 2] Here D is the address of the local interface through which the message arrived.
- [Note 3] This assumes that the application has joined the group D.
Here's Figure 13, the unicast destination rules:
UNICAST DESTINATION D:
RSVP RSVP
Node Send Receive
___ _____________ _______________
Hu UDP(D/Ra,Pu) UDP(D,Pu)
[Note 1] and UDP(D,Pu')
[Note 2]
Hr Raw(D) Raw()
and if (UDP) and UDP(D, Pu)
then UDP(D,Pu') [Note 2]
(Ignore Pu')
R (Interface a):
Raw(D) Raw()
and if (UDP) and UDP(Ra, Pu)
then UDP(D,Pu') (Ignore Pu')
Figure 13: UDP Encapsulation Rules for Unicast Path and Resv MessagesAnd here's Figure 14, the multicast destination rules:
MULTICAST DESTINATION D:
RSVP RSVP
Node Send Receive
___ _____________ _________________
Hu UDP(G*,Pu) UDP(D,Pu')
[Note 3]
and UDP(G*,Pu)
Hr Raw(D,Tr) Raw()
and if (UDP) and UDP(G*,Pu)
then UDP(D,Pu') (Ignore Pu')
R (Interface a):
Raw(D,Tr) Raw()
and if (UDP) and UDP(G*,Pu)
then UDP(D,Pu') (Ignore Pu')
Figure 14: UDP Encapsulation Rules for Multicast Path MessagesA router can figure out whether its interface X needs UDP encapsulation by listening for UDP-encapsulated Path messages. Those messages are sent either to G* (for a multicast D) or to the address of interface X (for a unicast D) 🕵️♀️. There's one failure mode for this scheme 💀: if no host on the connected network acts as an RSVP sender, there won't be any Path messages to trigger UDP encapsulation. In this (unlikely) case, UDP encapsulation has to be configured explicitly on the router's local network interface.
When a UDP-encapsulated packet comes in, the IP TTL usually isn't available to the application on most systems. So the RSVP process that receives a UDP-encapsulated Path or PathTear message should use the Send_TTL field of the RSVP common header as the effective receive TTL. Manual configuration can override this 🙈.
We've been assuming that the first-hop RSVP-capable router R sits on the directly-connected network. If it doesn't, there are a few possible approaches:
- Hu can send both unicast and multicast sessions to
UDP(Ra,Pu)withTTL=Ta.
Here Ta has to be the TTL that reaches R exactly. If Ta is too small, the Path message won't make it to R. If Ta is too large, R and the routers after it may keep forwarding the UDP packet until its hop count runs out. That turns on UDP encapsulation between routers across the Internet, which could cause bogus UDP traffic 😬. The host Hu has to be explicitly configured with Ra and Ta.
- A particular host on the LAN connected to Hu could be set up as an "RSVP relay host" 🧚. A relay host would listen on (G*,Pu) and forward any Path messages directly to R, although it wouldn't be in the data path. The relay host would have to be configured with Ra and Ta.
APPENDIX D. Glossary 📖💕
- Admission control: A traffic control function that decides whether the packet scheduler in the node can supply the requested QoS while continuing to provide the QoS requested by previously-admitted requests. See also "policy control" and "traffic control".
- Adspec: An Adspec is a data element (object) in a Path message that carries a package of OPWA advertising information. See "OPWA".
- Auto-refresh loop: An auto-refresh loop is an error condition that occurs when a topological loop of routers keeps refreshing existing reservation state even though all receivers have stopped requesting these reservations. See section 3.4 for more information. 🔁
- Blockade state: Blockade state helps to solve a "killer reservation" problem. See sections 2.5 and 3.5, and "killer reservation". 🚧
- Branch policing: Traffic policing at a multicast branching point on an outgoing interface that has "less" resources reserved than another outgoing interface for the same flow. See "traffic policing".
- C-Type: The class type of an object; unique within class-name. See "class-name".
- Class-name: The class of an object. See "object".
- DestAddress: The IP destination address; part of session identification. See "session".
- Distinct style: A (reservation) style attribute; separate resources are reserved for each different sender. See also "shared style".
- Downstream: Towards the data receiver(s). ⬇️
- DstPort: The IP (generalized) destination port used as part of a session. See "generalized destination port".
- Entry policing: Traffic policing done at the first RSVP- (and policing-) capable router on a data path. 🚪
- ERROR_SPEC: Object that carries the error report in a PathErr or ResvErr message. 🙅♀️
- Explicit sender selection: A (reservation) style attribute; all reserved senders are to be listed explicitly in the reservation message. See also "wildcard sender selection".
- FF style: Fixed Filter reservation style, which has explicit sender selection and distinct attributes. 💜
- FilterSpec: Together with the session information, defines the set of data packets to receive the QoS specified in a flowspec. The filterspec is used to set parameters in the packet classifier function. A filterspec may be carried in a FILTER_SPEC or SENDER_TEMPLATE object.
- Flow descriptor: The combination of a flowspec and a filterspec. 🌊
- Flowspec: Defines the QoS to be provided for a flow. The flowspec is used to set parameters in the packet scheduling function to provide the requested quality of service. A flowspec is carried in a FLOWSPEC object. The flowspec format is opaque to RSVP and is defined by the Integrated Services Working Group. 🎀
- Generalized destination port: The component of a session definition that provides further transport or application protocol layer demultiplexing beyond DestAddress. See "session".
- Generalized source port: The component of a filter spec that provides further transport or application protocol layer demultiplexing beyond the sender address.
- GLB: Greatest Lower Bound
- Incoming interface: The interface on which data packets are expected to arrive, and on which Resv messages are sent. 📥
- INTEGRITY: Object of an RSVP control message that contains cryptographic data to authenticate the originating node and to verify the contents of an RSVP message. 🔐
- Killer reservation problem: The killer reservation problem describes a case where a receiver attempting and failing to make a large QoS reservation prevents smaller QoS reservations from being established. See Sections 2.5 and 3.5 for more information. 🦈
- LIH: The LIH (Logical Interface Handle) is used to help deal with non-RSVP clouds. See Section 2.9 for more information.
- Local repair: Allows RSVP to rapidly adapt its reservations to changes in routing. See Section 3.6 for more information. 🛠️
- LPM: Local Policy Module. the function that exerts policy control.
- LUB: Least Upper Bound.
- Merge policing: Traffic policing that takes place at data merge point of a shared reservation.
- Merging: The process of taking the maximum (or more generally the least upper bound) of the reservations arriving on outgoing interfaces, and forwarding this maximum on the incoming interface. See Section 2.2 for more information. 🫶
- MTU: Maximum Transmission Unit.
- Next hop: The next router in the direction of traffic flow. ➡️
- NHOP: An object that carries the Next Hop information in RSVP control messages.
- Node: A router or host system. 🖥️
- Non-RSVP clouds: Groups of hosts and routers that do not run RSVP. Dealing with nodes that do not support RSVP is important for backwards compatibility. See section 2.9. ☁️
- Object
An element of an RSVP control message, basically a type, length, value triplet 🎀
- OPWA 🌸: Short for "One Pass With Advertising." It's a reservation setup model where Path messages sent downstream gather info that the receivers can use to predict the end-to-end service. That gathered info is called an advertisement. See also "Adspec."
- Outgoing interface 🦋: The interface that data packets and Path messages get forwarded out of.
- Packet classifier 💅: A traffic control function in the primary data packet forwarding path. It picks a service class for each packet, based on the reservation state RSVP set up. It can be combined with the routing function. See also "traffic control."
- Packet scheduler ⭐: A traffic control function in the primary data packet forwarding path. It delivers QoS for each flow, using one of the service models defined by the Integrated Services Working Group. See also "traffic control."
- Path state 🧚: Info kept in routers and hosts about all RSVP senders.
- PathErr 🙈: The Path Error RSVP control message.
- PathTear 💀: The Path Teardown RSVP control message.
- PHOP 🍓: An object that carries the Previous Hop information in RSVP control messages.
- Police 💜: See traffic policing.
- Policy control 👑: A function that decides whether a new QoS request has administrative permission to make the requested reservation. Policy control may also do accounting (usage feedback) for a reservation.
- Policy data 🌈: Data carried in a Path or Resv message, used as input to policy control to determine authorization and/or usage feedback for the given flow.
- Previous hop 🫶: The previous router in the direction of traffic flow. Resv messages flow towards previous hops.
- ProtocolId ✨: The part of session identification that specifies the IP protocol number used by the data stream.
- QoS 🔥: Quality of Service.
- Reservation state 🎀: Info kept in RSVP-capable nodes about successful RSVP reservation requests.
- Reservation style 🌸: Describes a set of attributes for a reservation, including the sharing attributes and sender selection attributes. See Section 1.3 for details.
- Resv message 💖: The reservation request RSVP control message.
- ResvConf 🦋: The Reservation Confirmation RSVP control message. It confirms a reservation was successfully installed at some upstream node.
- ResvErr 😭: The Reservation Error control message. It says a reservation request has failed or an active reservation has been preempted.
- ResvTear 🧚: The Reservation Teardown RSVP control message, which deletes reservation state.
- Rspec 🍓: The part of a flowspec that defines a desired QoS. The Rspec format is opaque to RSVP and is defined by the Integrated Services Working Group of the IETF.
- RSVP_HOP ⭐: An object of an RSVP control message that carries the PHOP or NHOP address of the source of the message.
- Scope 💅: The set of sender hosts that a given reservation request gets propagated to.
- SE style 👑: Shared Explicit reservation style. It has explicit sender selection and shared attributes.
- Semantic fragmentation 🌈: A way of fragmenting a large RSVP message using info about its structure and contents, so each fragment is a logically complete RSVP message.
- Sender template 💜: A parameter in a Path message that defines a sender, carried in a SENDER_TEMPLATE object. It has the form of a filter spec that can be used to select this sender's packets from other packets in the same session on the same link.
- Sender Tspec 🫶: A parameter in a Path message. It's a Tspec that characterizes the traffic parameters for the data flow from the corresponding sender, carried in a SENDER_TSPEC object.
- Session 🎀: An RSVP session defines one simplex unicast or multicast data flow that needs reservations. A session is identified by the destination address, transport-layer protocol, and an optional (generalized) destination port.
- Shared style 💖: A reservation style attribute where all reserved senders share the same reserved resources. See also "distinct style."
- Soft state 🦋: Control state in hosts and routers that expires if it isn't refreshed within a specified amount of time.
- STYLE 🌸: An object of an RSVP message that specifies the desired reservation style.
- Style ✨: See "reservation style."
- TIME_VALUES ⏰: An object in an RSVP control message that specifies the time period timer used for refreshing the state in this message.
- Traffic control 👑: The whole set of machinery in the node that supplies requested QoS to data streams. Traffic control includes the packet classifier, packet scheduler, and admission control functions.
- Traffic policing 🔥: The function, performed by traffic control, of forcing a given data flow into compliance with the traffic parameters implied by the reservation. It may involve dropping non-compliant packets or sending them with lower priority, for example.
- TSpec 🌈: A traffic parameter set that describes a flow. The format of a Tspec is opaque to RSVP and is defined by the Integrated Service Working Group.
- UDP encapsulation 🧚: A way for hosts that can't use raw sockets to take part in RSVP. They wrap the RSVP protocol (raw) packets in ordinary UDP packets. See Section APPENDIX C for more information.
- Upstream 💜: Towards the traffic source. RSVP Resv messages flow upstream.
- WF style 🍓: Wildcard Filter reservation style. It has wildcard sender selection and shared attributes.
- Wildcard sender selection 🫶: A reservation style attribute where traffic from any sender to a specific session gets the same QoS. See also "explicit sender selection."
References ✨
[Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in Progress.
[RFC 1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and PARC, June 1994.
[FJ94] Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2, April, 1994.
[RFC 2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC 2113] Katz, D., "IP Router Alert Option", RFC 2113, cisco Systems, February 1997.
[RFC 2210] Wroclawski, J., "The Use of RSVP with Integrated Services", RFC 2210, September 1997.
[PolArch96] Herzog, S., "Policy Control for RSVP: Architectural Overview". Work in Progress.
[OPWA95] Shenker, S. and L. Breslau, "Two Issues in Reservation Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995.
[RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, September 1993.
Security Considerations 🔒
See Section 2.8. 💀
Authors' Addresses 💌
Bob Braden 🌸
Bob Braden
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: (310) 822-1511
EMail: Braden@ISI.EDULixia Zhang 🦋
Lixia Zhang
UCLA Computer Science Department
4531G Boelter Hall
Los Angeles, CA 90095-1596 USA
Phone: 310-825-2695
EMail: lixia@cs.ucla.eduSteve Berson 💖
Steve Berson
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: (310) 822-1511
EMail: Berson@ISI.EDUShai Herzog 🧚
Shai Herzog
IBM T. J. Watson Research Center
P.O Box 704
Yorktown Heights, NY 10598
Phone: (914) 784-6059
EMail: Herzog@WATSON.IBM.COMSugih Jamin 🌈
Sugih Jamin
University of Michigan
CSE/EECS
1301 Beal Ave.
Ann Arbor, MI 48109-2122
Phone: (313) 763-1583
EMail: jamin@EECS.UMICH.EDU📦 where this page comes from
- ietf: rfc2205 1997-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms