RFC 2210
The Use of RSVP with IETF Integrated Services
RFC 2210: The Use of RSVP with IETF Integrated Services 💖
Title block, bestie 🎀
- Network Working Group 🌐
- Author: J. Wroclawski, MIT LCS 🧚
- Category: Standards Track
- Date: September 1997
- Obsoletes / Updates: this title block doesn't list anything it obsoletes or updates 🙈
Status of This Memo 🎀
Okay so this doc is a standards track protocol for the whole Internet community, and it's literally asking for discussion and suggestions for improvements 🫶. For the current standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🦋.
Abstract ✨
This note explains how to use the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services 💅. RSVP defines several data objects that carry resource reservation info, but RSVP itself treats them as opaque, meaning it doesn't read inside them 👀. This note gives the usage and data format for those objects 🌸.
1. Introduction ✨
The integrated services framework lets applications choose between multiple, controlled levels of delivery service for their data packets 🦋. To make that work, two things are needed:
- Individual network elements (subnets and IP routers) along the path that an application's data packets follow must support mechanisms to control the quality of service delivered to those packets 💅.
- There must be a way to communicate the application's requirements to network elements along the path, and to convey QoS management information between network elements and the application 🫶.
In the integrated services framework, the first function is handled by QoS control services such as Controlled-Load [RFC 2211] and Guaranteed [RFC 2212] 💖. The second function can be handled in a number of ways, but it's often done by a resource reservation setup protocol like RSVP [RFC 2205] 🔥.
Because RSVP is built to work with a variety of QoS control services, and those services are built to work with a variety of setup mechanisms, there's a logical separation between the two specs 🧠. The RSVP spec doesn't define the internal format of the RSVP protocol fields, or objects, that are related to invoking QoS control services 🙈. RSVP treats those objects as opaque. They can carry different info to meet different application and QoS control service needs 🌈.
Interfaces to the QoS control services are also defined in a general format, so the services can be used with a variety of setup mechanisms 🍓.
This RFC gives you everything you need to use RSVP and the integrated services QoS control services together 👑. It defines the usage and contents of three RSVP protocol objects: the FLOWSPEC, ADSPEC, and SENDER_TSPEC 💜. This applies in an environment supporting the Controlled-Load and/or Guaranteed QoS control services ⭐. If new services or capabilities get added to the integrated services framework, this note will be revised as required ✨.
2. Use of RSVP 💅
Several types of data must be transported between applications and network elements to correctly invoke QoS control services 🦋.
NOTE: In addition to the data used to directly invoke QoS control services, RSVP carries authentication, accounting, and policy information needed to manage the use of these services. This note is concerned only with the RSVP objects needed to actually invoke QoS control services, and does not discuss accounting or policy objects. 🙈
This data includes:
- Info generated by each receiver describing the QoS control service desired, a description of the traffic flow the resource reservation should apply to (the Receiver TSpec), and whatever parameters are needed to invoke the service (the Receiver RSpec) 💖. This info is carried from the receivers to intermediate network elements and the sender(s) by RSVP FLOWSPEC objects 🧚. The info in a FLOWSPEC object can change at intermediate points in the network because of reservation merging and other factors 🌀.
- Info generated at each sender describing the data traffic that sender produces (the Sender TSpec) 🌸. It's carried from the sender to intermediate network elements and the receiver(s) by RSVP, but intermediate elements never modify it 🔒. This info is carried in RSVP SENDER_TSPEC objects 📦.
- Info generated or modified inside the network and used at the receivers to make reservation decisions 🔍. This could include available services, delay and bandwidth estimates, and operating parameters used by specific QoS control services 📊. This info is collected from network elements and carried toward the receivers in RSVP ADSPEC objects 🦋. Rather than carrying info from each intermediate node separately to the receivers, the info in the ADSPEC is a summary, computed as the ADSPEC passes each hop 🧮. The size of this summary stays (roughly) constant as the ADSPEC flows through the network, which gives it good scaling properties 📈.
From the point of view of RSVP objects, the breakdown looks like this 👀:
- The RSVP SENDER_TSPEC object carries the traffic specification (sender TSpec) generated by each data source within an RSVP session 📦. It's transported unchanged through the network and delivered to both intermediate nodes and receiving applications 🚚.
- The RSVP ADSPEC object carries info generated at either data sources or intermediate network elements 🌱. It flows downstream toward the receivers, and may be used and updated inside the network before it's delivered to receiving applications 🔄. This info includes parameters describing the properties of the data path, including the availability of specific QoS control services, plus parameters that specific QoS control services need in order to operate correctly 🛠️.
- The RSVP FLOWSPEC object carries reservation request info (Receiver_TSpec and RSpec) generated by data receivers 💌. The info in the FLOWSPEC flows upstream toward the data sources 🆙. It may be used or updated at intermediate network elements before it arrives at the sending application 🧚.
NOTE: The existence of both the SENDER_TSPEC and ADSPEC RSVP objects is somewhat historical 📜. Using the message format described in this note, it would be possible to place all of the service control info carried "downstream" by RSVP in the same object 🤷♀️. However, the distinction between data that isn't updated within the network (in the SENDER_TSPEC object) and data that is updated within the network (in the ADSPEC object) may be useful to an implementation in practice, so it's been kept 💜.
2.1 Summary of operation 🦋
Here's how operation goes 🧚:
An application instance taking part in an RSVP session as a data sender registers with RSVP 📝. One piece of info the application instance gives is the Sender TSpec, which describes the traffic the application expects to generate 🌊. That info is used to construct an RSVP SENDER_TSPEC object, which gets included in the RSVP PATH messages generated for the application 📨.
The sending application also constructs an initial RSVP ADSPEC object 🏗️. This ADSPEC carries info about the QoS control capabilities and requirements of the sending application itself, and it's the starting point for accumulating the path properties described below 🌱. The ADSPEC gets added to the RSVP PATH message created at the sender 📬.
NOTE: For the convenience of application programmers, a host RSVP implementation may allow the sending application to not provide an initial adspec, and instead supply its own default 🎁. This is most likely when the application sender doesn't itself take part in the end-to-end QoS control process (by actively scheduling CPU usage and similar means), and doesn't itself care which QoS control service the receivers select 🙃.
Typically, the default ADSPEC supplied by the host RSVP in this case would support all QoS control services known to the host 🖥️. However, the exact behavior of this mechanism is implementation dependent 🤷♀️.
The ADSPEC gets modified by subsequent network elements as the RSVP PATH message moves from the sender to the receiver(s) 🚶♀️. At each network element, the ADSPEC is passed from RSVP to the traffic control module ➡️. The traffic control module updates the ADSPEC, which may contain data for several QoS control services, by identifying the services mentioned in the ADSPEC and calling each of those services to update its portion 🔧. If the traffic control module finds a QoS control service that's mentioned in the ADSPEC but isn't implemented by the network element, a flag is set to report this to the receiver 🚩. The updated ADSPEC is then returned to RSVP for delivery to the next hop along the path ➡️.
When the PATH message arrives at an application receiver, the data in the SENDER_TSPEC and ADSPEC objects is passed across the RSVP API to the application 🎉. The application (perhaps with help from a library of common resource-reservation functions) interprets the arriving data and uses it to guide the selection of resource reservation parameters 🧠. For example, it can use the arriving "PATH_MTU" composed characterization parameter [RFC 2215] to determine the maximum packet size parameter in the reservation request 📏. It can also use the arriving Guaranteed service "C" and "D" parameters [RFC 2212] to calculate a mathematical bound on delivered packet delay when using the Guaranteed service 🧮.
An application receiver that wants to make a resource reservation supplies its local RSVP with the necessary reservation parameters 🙋♀️. Among these are the QoS control service desired (Guaranteed or Controlled-Load), the traffic specifier (TSpec) describing the level of traffic the resources should be reserved for, and, if the selected QoS control service needs it, an RSpec describing the level of service desired 💅. These parameters get composed into an RSVP FLOWSPEC object and sent upstream by RSVP ⬆️.
At each RSVP-aware point in the network, the SENDER_TSPECs arriving in PATH messages and the FLOWSPECs arriving in RESV messages are used to request an appropriate resource reservation from the desired QoS control service 🔁. State merging, message forwarding, and error handling all follow the rules of the RSVP protocol 📜.
Finally, the merged FLOWSPEC object arriving at each of an RSVP session's data senders is delivered to the application 🎀. This lets each sender know the merged reservation request and the properties of the data path 🌈.
2.2. RSVP support for multiple QoS control services ✨
Okay so this part is about receivers picking their QoS control service at runtime 🎀. Like, they get to decide in the moment, which is so cute. But bestie, to make that work, a receiver has to know everything it needs about a service before it chooses one. So the SENDER_TSPEC and ADSPEC objects have to give receivers info for every service that might get picked 💅.
The two QoS control services that are defined right now share the exact same Sender TSpec 🫶. That makes the SENDER_TSPEC object so much simpler, since it only needs to carry one TSpec data structure in this shared format. This common SENDER_TSPEC works with either Guaranteed or Controlled-Load service. Iconic, honestly 🦋.
The ADSPEC is what gives receivers the info they need to pick a service and figure out the reservation parameters 🌈. It includes:
- Whether or not there's a non-RSVP hop somewhere on the path. If there is one, the application's traffic gets reservationless best-effort service at at least one point on that path 😭.
- Whether or not a specific QoS control service is implemented at every hop along the path. For example, a receiver might find out that at least one integrated-services aware hop supports the Controlled-Load service but not the Guaranteed service 👀.
- Default or global values for the general characterization parameters described in [RFC 2215] 🌸. These describe properties of the path itself, no matter which QoS control service gets selected. A value reported in this section of the ADSPEC applies to all services, unless a different, service-specific value is also present in the ADSPEC.
- A service-specific value for one or more general characterization parameters, but only if that value is different from the default 🧚.
- Values of the per-service characterization parameters defined by each supported service 💜.
The ADSPEC data is split up into blocks or fragments, and each one is tied to a specific service 🍓. This is so the adspec can carry info about multiple services, lets new services get deployed later without immediately updating existing code, and lets an application that will never use a particular service skip the ADSPEC data for it. The full structure of the ADSPEC is in Section 3.3, so go check that out 🙈.
A sender can signal that a specific QoS control service should not be used by the receivers in an RSVP session 🚫. To do that, it just leaves out every mention of that service from the ADSPEC, as described in Section 3.3. When a receiver gets the ADSPEC, the complete absence of a fragment for a specific service tells it that the service should not be used 💀.
NOTE: In RSVP Version 1, all receivers within a session are required to choose the same QoS control service. This restriction exists because merging reservations that ask for different QoS control services is really hard, and there's currently no general service replacement mechanism 😩. The restriction may be eliminated in the future ✨.
Given that restriction, it might be useful to coordinate which QoS control service the receivers pick. One way is to have the sender(s) offer only one choice, using the ADSPEC mechanism from above. Then all receivers must select that same service 🫶. Another option is to use a higher-level session announcement and setup mechanism to tell receivers which QoS control service is in use. You could also configure the receivers manually, or have the session receivers run an agreement protocol among themselves 🎀.
Just like with the ADSPEC, the FLOWSPEC and SENDER_TSPEC object formats described in Section 3 can carry TSpecs and RSpecs for more than one QoS control service, each in its own data fragment 🌸. Right now, though, using a FLOWSPEC or SENDER_TSPEC that contains fragments for more than one QoS control service is not supported 🥺. In the future this might power a more flexible service request and replacement scheme, so applications can still get useful end-to-end QoS control when not every intermediate node supports the same set of QoS services ⭐. RSVP-application APIs should be designed to pass SENDER_TSPEC, FLOWSPEC, and ADSPEC objects of variable size, including info about multiple QoS control services, between RSVP and its clients 💖.
2.3. Use of ADSPEC Information 🧁
This section gives some details about setting reservation parameters and using the info carried in the RSVP ADSPEC object 💅.
2.3.1. Determining the availability of a QoS control service 🔍
The RSVP ADSPEC has flag bits that tell application receivers whether a completely reservation-capable path exists between each sender and the receiver 🛤️. These are called "break bits", because they flag breaks in the QoS control along a network path 💔. Break bits live in the header that starts each per-service data fragment of an RSVP ADSPEC.
Service number 1 is used in the ADSPEC for a fragment carrying global parameter values that apply to all services (see [RFC 2215] for more details) 🌍. The break bit in service 1's per-service header tells receiver(s) whether every network element on the path from sender to receiver supports RSVP and integrated services. If a receiver finds this bit set, that means at least one network element on the data path between the ADSPEC's sender and the receiver can't provide QoS control services at all 😬. This bit corresponds to the global NON_IS_HOP characterization parameter defined in [RFC 2215].
NOTE: If this bit is set, the values of all other parameters in the ADSPEC are unreliable. Setting it means at least one node along the sender-receiver path didn't fully process the ADSPEC ⚠️.
Service-specific break bits tell receiver(s) whether every network element on the path from sender to receiver supports a particular QoS control service 🎯. Each service's break bit lives in the ADSPEC's per-service header for that service. If a bit is set at the receiver, at least one network element on the data path supports RSVP but doesn't support the QoS control service that goes with that per-service header 🙅♀️. These bits correspond to the service-specific NON_IS_HOP characterization parameters defined in [RFC 2215].
Section 3 has more info about break bits 📚.
2.3.2. Determining Path MTU 📏
Both the Guaranteed and Controlled-Load QoS control services put an upper bound on packet size 🎀. They also require the application to limit the maximum size of packets that get resource reservations 🚧. For both services, the desired maximum packet size is a parameter of the reservation request. If a reservation request asks for a packet size bigger than the service supports, the service rejects it with an admission control error 🙅♀️.
Since RSVP reservation requests come from receivers, the receivers in an RSVP session need to know the MTU supported by the QoS control services along a data path, not just the senders 🫣. Also, in some unusual cases, the MTU a QoS control service supports can be different from the one that same router supports for best-effort service 🤯.
RSVP uses a scalable form of MTU negotiation to handle these problems ✨. Here's how it works:
- Each sending application that joins an RSVP session fills in the M (maximum packet size) parameter in its generated Sender_TSpec (carried from senders to receivers in a SENDER_TSPEC object) with the largest packet it wants to send that's covered by resource reservation 📦.
- Each RSVP PATH message from a sending application also carries an ADSPEC object with at least one PATH_MTU characterization parameter. When it reaches the receiver, this parameter gives the minimum MTU at any point along the path from sender to receiver 🛣️. Usually only the "global" PATH_MTU parameter (service 1, parameter 9) will be there, and in that case its value is a legal MTU for all reservation requests 🙌. If a service-specific PATH_MTU parameter shows up, its value will be smaller than the global one, and it should be used for reservation requests for that service 🎯.
- Each receiver takes the minimum of all the PATH_MTU values (for the desired QoS control service) that arrive in ADSPEC messages from different senders, and uses that value as the MTU in its reservation requests 🧮. This value fills in the M parameter of the TSpec created at the receiver. For an FF style reservation, a receiver can also choose to use the MTU derived from each sender's ADSPEC in the FLOWSPEC generated for that sender, if it cares about getting the maximum MTU on each data path 💜. To keep up with changes in the data path, the receiver can keep watching the arriving ADSPECs, and change the reservation if a newly arriving ADSPEC shows a smaller MTU than the one currently in use 👀.
- As reservation requests (RESV messages) travel from receivers to senders, reservation parameters get merged at intermediate nodes 🔀. During that merge, the smaller of two M parameters arriving at a merge point is forwarded in the upstream RESV message 🪄.
- As reservation requests arrive at intermediate RSVPs, the minimum of the receivers' requested TSpec and the sum of the sender TSpecs is taken, and a reservation for the resulting TSpec is made 🧠. The reservation uses the smaller of the actual path MTU value computed by the receivers and the largest maximum packet size declared by any of the sender(s). (The TSpec sum() function result's M parameter is the max of the summed TSpec M parameters 🤓.)
- When the completely merged RESV message reaches each sender, the MTU value (M parameter) in the merged FLOWSPEC object will have been set to the smallest acceptable MTU of the data paths from that sender to any session receiver 🏁. The sending application should use this MTU to size its packets 🎀. Any packets bigger than this MTU may get delivered as best-effort rather than being covered by the session's resource reservation 😅.
Note that senders do not adjust the value of their Sender_TSpec's M field to match the actual packet size chosen in this step 🙅♀️. The M value represents the largest packet the sender could send, not the largest packet it's currently sending 💅.
Note that the scheme above lets each sender in a session use the largest MTU that's appropriate for that sender, in cases where different data paths or receivers have different acceptable MTUs 🌈. That's giving flexibility, periodt ✨.
3. RSVP Object Formats 🎀
This section specifies the detailed contents and wire format of the RSVP SENDER_TSPEC, ADSPEC, and FLOWSPEC objects for use with the Guaranteed and Controlled-Load QoS control services 📐. The object formats specified here are based on the general message construction rules given in Appendix 1 🧚.
3.1. RSVP SENDER_TSPEC Object ✨
okay so the RSVP SENDER_TSPEC object is how a data source tells the network what its traffic looks like 🌸 it carries a global Token_Bucket_TSpec parameter (service_number 1, parameter 127, as defined in [RFC 2215]). this one is required, no skipping it 💅 and it's usable by either the Guaranteed or Controlled-Load QoS control services, so it's giving versatile 🦋
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |0| reserved | 6 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (7 words not including header)
(c) - Service header, service number 1 (default/global information)
(d) - Length of service 1 data, 6 words not including header
(e) - Parameter ID, parameter 127 (Token_Bucket_TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including headerso in this TSpec, the [r] and [b] params are set to reflect the sender's view of its own generated traffic 🧚 the peak rate [p] can be set to the sender's peak traffic generation rate (if it's known and controlled), the physical interface line rate (if known), or positive infinity (if no better value is available) ♾️ positive infinity is written as an IEEE single-precision floating-point number with an exponent of all ones (255) and a sign and mantissa of all zeros 🤓 if you want the deets on IEEE floats, check out [RFC 1832] ✨
the minimum policed unit [m] should generally be set equal to the size of the smallest packet the application generates 📦 that size includes the application data and all protocol headers at or above the IP level (IP, TCP, UDP, RTP, etc.) 🎀 it does NOT include link-level headers, because those keep changing as the packet hops across different parts of the internetwork 🌈
the [m] param is used by nodes in the network to figure out the max bandwidth overhead needed to carry a flow's packets over a given link-level technology, based on the ratio of [m] to the link-level header size 🫶 this is how the right amount of bandwidth gets allocated to the flow at each point in the net. quick heads up though: smaller [m] values mean bigger overhead estimates, and so a higher likelihood of the reservation request getting rejected by a node 😭 so in some cases, an app that sends a low percentage of very small packets might choose to set [m] larger than its actual minimum transmitted packet size 🍓 that makes the reservation more likely to succeed, but the trade-off is that packets smaller than [m] get policed as if they were exactly [m] in size 💀
an [m] value of zero is illegal!! 🙅♀️ it would mean no data or IP headers are present, and that would give an infinite amount of link-level overhead. not it.
the maximum packet size param [M] should be set to the size of the largest packet the app might want to generate, as described in Section 2.3.2 👑 by definition, this value has to be equal to or larger than [m] ✨
3.2. RSVP FLOWSPEC Object
the RSVP FLOWSPEC object carries the info needed to make reservation requests from the receiver(s) into the network 💜 it says which QoS control service is being requested, plus the params that service needs 🦋
the QoS control service being requested is indicated by the service_number in the FLOWSPEC's per-service header 🎀
3.2.1 FLOWSPEC object when requesting Controlled-Load service
here's the format of an RSVP FLOWSPEC object coming from a receiver that wants Controlled-Load service 🌸 each of the TSpec fields uses the preferred concrete representation specified in the 'Invocation Information' section of [RFC 2211] 📚 the value 5 in the per-service header (field (c) below) means Controlled-Load service is being requested 💅
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 5 (c) |0| reserved | 6 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (7 words not including header)
(c) - Service header, service number 5 (Controlled-Load)
(d) - Length of controlled-load data, 6 words not including
per-service header
(e) - Parameter ID, parameter 127 (Token Bucket TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including per-service
headerin this object, the TSpec params [r], [b], and [p] reflect the traffic params of the receiver's desired reservation (the Reservation TSpec) 🫧 what these fields mean is covered fully in [RFC 2211] 📖 also, it's unlikely to make sense for [p] to be smaller than [r] 🙃
the maximum packet size param [M] should be set to the value of the smallest path MTU, which the receiver learns from info in arriving RSVP ADSPEC objects 🛣️ alternatively, if the receiving app has built-in knowledge of the max packet size in use within the RSVP session, and that value is smaller than the smallest path MTU, [M] may be set to that value 🌟 but heads up: requesting an [M] larger than the service modules along the data path can support will make the reservation fail 😬 check section 2.3.2 for more on the MTU value 🎀
the [m] value can be chosen a few ways 🧩 remember that when a resource reservation is installed at each intermediate node, the value used for [m] is the smaller of the receiver's request and the values in each sender's SENDER_TSPEC 💖
if the app has a fixed, known minimum packet size, that value should be used for [m] 🥇 this is the most desirable case 😍
for a shared reservation style, the receiver can choose between two options, or pick some point in between them 🤝
- if the receiver picks a large value for [m], the reservation allocates less overhead for link-level headers 📉 but if a new sender with a smaller SENDER_TSPEC [m] joins the session later, an already-installed reservation might fail at that point 😱
- if the receiver picks a value of [m] equal to the smallest value any sender might use, the reservation has to allocate more overhead for link-level headers 📈 but it won't fail later if a new sender with a smaller SENDER_TSPEC [m] joins the session 🛡️
for an FF reservation style, if no app-specific value is known, the receiver should simply use the value of [m] arriving in each sender's SENDER_TSPEC for its reservation request to that sender 🫶
3.2.2. FLOWSPEC Object when Requesting Guaranteed Service ✨
Okay bestie, this is the FLOWSPEC a receiver sends when it wants Guaranteed service 🎀 It carries a TSpec and an RSpec that describe the traffic the receiver wants for the flow 💅
Both the TSpec and RSpec fields use the preferred concrete representation from the Invocation Information section of [RFC 2212] 📝 The service header identifier (field (c) in the picture) is set to 2, which tells everyone Guaranteed service is being requested 🔥
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | Unused | 10 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 2 (c) |0| reserved | 9 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 130 (h) | 0 (i) | 2 (j) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | Rate [R] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | Slack Term [S] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (9 words not including header)
(c) - Service header, service number 2 (Guaranteed)
(d) - Length of per-service data, 9 words not including per-service
header
(e) - Parameter ID, parameter 127 (Token Bucket TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including parameter header
(h) - Parameter ID, parameter 130 (Guaranteed Service RSpec)
(i) - Parameter 130 flags (none set)
(j) - Parameter 130 length, 2 words not including parameter headerIn this object, the TSpec parameters [r], [b], and [p] get set to match the traffic the receiver wants to reserve (the Reservation TSpec) 🌸 What those fields mean is explained fully in [RFC 2212], so go read that if you want the deep dive 🤓 Also, it's unlikely to make sense for the [p] term to be smaller than the [r] term. Like, that would be kind of a weird vibe 💀
The RSpec terms [R] and [S] get picked so you end up with the bandwidth and delay guarantees you want ✨ That selection process is described in [RFC 2212] too 🦋
The [m] and [M] parameters are set the exact same way as in the Controlled-Load service FLOWSPEC from the previous section 🫶
3.3. RSVP ADSPEC Object 🧚
An RSVP ADSPEC object is built from data fragments that each service which might get used by the application contributes 💜 It starts with an overall message header, then a fragment for the default general parameters, and then fragments for every QoS control service that application receivers might select 🌈 How big the ADSPEC ends up depends on how many per-service data fragments there are, how big they are, and whether any non-default general parameters show up (more on those in Section 3.3.5) 🍓
If a service doesn't have a data fragment at all, that means the application sender doesn't know or care about that service 🙈 It's also a hint to intermediate nodes that they shouldn't add or update anything about that service in the ADSPEC, and a hint to application receivers that they shouldn't pick that service when making reservations 🚫
Every fragment that's there gets identified by a per-service data header 🎀 Each header has a field that says which service it is, a break bit, and a length field 🔥
The length field is what lets a network element skip over a service's ADSPEC info if it doesn't recognize or implement that service ✨ When an element skips it, it sets the break bit, which says the service's ADSPEC data wasn't updated on at least one hop 😭 Also, a service's break bit can be set even if the element doesn't support that service at all, so don't read too much into it 💅 Basically, if a network element hits a per-service data header it doesn't understand, it just sets bit 23 to say the service isn't supported, and then skips the rest of that fragment 💀
Data fragments always have to show up in an ADSPEC in service_number order 📋 The default general parameters fragment (service_number 1) always goes first, no exceptions 👑
Inside a data fragment, the service-specific data has to come first, then any non-default general parameters that are present, ordered by parameter_number 🌸 The size and structure of the service-specific data is fixed by the service definition, so you don't have to parse it at runtime, yay 🥳 The rest of the fragment, the non-default general parameters, changes in size and structure depending on which of them are there, so you have to go through the per-parameter headers to parse it 🔍
Since each data fragment can be a different size, you always have to look at the length field to find where the fragment ends. You can't just assume it's a fixed-size structure 🙅♀️
3.3.1. RSVP ADSPEC format 🦋
Here's the basic ADSPEC format 💖 The message header and the default general parameters fragment are always there 🫶 The fragments for Guaranteed or Controlled-Load service can be left out if the RSVP session isn't going to use that service 🌷 And if new services get defined later, more data fragments will get added too 🚀
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (a) | reserved | Msg length - 1 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Default General Parameters fragment (Service 1) (c) |
| (Always Present) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Guaranteed Service Fragment (Service 2) (d) |
| (Present if application might use Guaranteed Service) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Controlled-Load Service Fragment (Service 5) (e) |
| (Present if application might use Controlled-Load Service) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall message length not including header word
(c, d, e) - Data fragments3.3.2. Default General Characterization Parameters ADSPEC data fragment ✨
okay bestie, every RSVP ADSPEC carries the general characterization parameters from [RFC 2215] 🫶 The global or default ones (the values that apply to all the services, or to the path itself) live in the per-service data fragment for service number 1. It's the one in the picture above. This fragment is always there, and it's always first in the message 💅
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 1 (c) |x| reserved | 8 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 4 (e) | (f) | 1 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | IS hop cnt (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | 6 (h) | (i) | 1 (j) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Path b/w estimate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | 8 (k) | (l) | 1 (m) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum path latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | 10 (n) | (o) | 1 (p) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | Composed MTU (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(c) - Per-Service header, service number 1 (Default General
Parameters)
(d) - Global Break bit ([RFC 2215], Parameter 2) (marked x) and
length of General Parameters data block.
(e) - Parameter ID, parameter 4 (Number-of-IS-hops param from
[RFC 2215])
(f) - Parameter 4 flag byte
(g) - Parameter 4 length, 1 word not including header
(h) - Parameter ID, parameter 6 (Path-BW param from [RFC 2215])
(i) - Parameter 6 flag byte
(j) - Parameter 6 length, 1 word not including header
(k) - Parameter ID, parameter 8 (minimum path latency from [RFC
2215])
(l) - Parameter 8 flag byte
(m) - Parameter 8 length, 1 word not including header
(n) - Parameter ID, parameter 10 (composed path MTU from [RFC 2215])
(o) - Parameter 10 flag byte
(p) - Parameter 10 length, 1 word not including headerThe rules for composing general parameters are in [RFC 2215] 📖
Now the global break bit 🔥 It's bit 23 of word 1, the one marked (x) in the picture. It's how we flag that there's a network element somewhere on the data path that doesn't support QoS control services. It gets cleared when the ADSPEC is created, and it gets set to one if a network element that doesn't support RSVP or integrated services shows up. If an ADSPEC reaches a receiver with this bit set, that's a sign that all the other parameters in the ADSPEC may be invalid, because not every network element on the path supports updating the ADSPEC 😭
The general parameters get updated at every network node that supports RSVP:
- When a PATH message ADSPEC hits a network element that implements integrated services, the part of the ADSPEC for service number 1 gets handed to the general parameters module. That module updates the global general parameters 🌸
- When a PATH message ADSPEC hits a network element that does not support RSVP or implement integrated services, the break bit in the general parameters service header must be set. Realistically, another RSVP-capable element usually sets it, once it's been made aware of the gap in integrated services coverage 🙈
- Either way, the ADSPEC gets passed back to RSVP so it can be delivered to the next hop along the path 🦋
3.3.3. Guaranteed Service ADSPEC data fragment 💜
The Guaranteed service uses the RSVP ADSPEC to carry the data needed to compute the C and D terms that get passed from the network up to the application 🧚 The smallest a non-empty guaranteed service data fragment can be is 8 32-bit words. Here's what the Guaranteed fragment looks like:
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 2 (a) |x| reserved | N-1 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 133 (c) | 0 (d) | 1 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | End-to-end composed value for C [Ctot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | 134 (f) | (g) | 1 (h) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | End-to-end composed value for D [Dtot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | 135 (i) | (j) | 1 (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Since-last-reshaping point composed C [Csum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | 136 (l) | (m) | 1 (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | Since-last-reshaping point composed D [Dsum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | Service-specific general parameter headers/values, if present |
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
N | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Per-Service header, service number 2 (Guaranteed)
(b) - Break bit and Length of per-service data in 32-bit
words not including header word.
(c) - Parameter ID, parameter 133 (Composed Ctot)
(d) - Parameter 133 flag byte
(e) - Parameter 133 length, 1 word not including header
(f) - Parameter ID, parameter 134 (Composed Dtot)
(g) - Parameter 134 flag byte
(h) - Parameter 134 length, 1 word not including header
(i) - Parameter ID, parameter 135 (Composed Csum).
(j) - Parameter 135 flag byte
(k) - Parameter 135 length, 1 word not including header
(l) - Parameter ID, parameter 136 (Composed Dsum).
(m) - Parameter 136 flag byte
(n) - Parameter 136 length, 1 word not including headerWhen a node that actually implements guaranteed service builds the guaranteed service ADSPEC fragment, each parameter gets set to that node's local values ✨ When an application or network element that doesn't implement guaranteed service builds one, it should set the value of each parameter to zero, and set the break bit to show the service isn't actually implemented at that node 🫠
An application or host RSVP that's building a guaranteed service ADSPEC fragment, but doesn't implement guaranteed service itself, may create a truncated "empty" guaranteed ADSPEC fragment. It's just the header word:
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 2 (a) |1| (b) | 0 (c) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Per-Service header, service number 2 (Guaranteed)
(b) - Break bit (set, service not implemented)
(c) - Length of per-service data in 32-bit words not
including header word.This might happen if the sending application or host doesn't do resource reservation itself, but still wants the network to handle it 🌈 In that case the break bit will always be set, since the creator of the ADSPEC fragment doesn't implement guaranteed service itself 💀
Now, when a PATH message ADSPEC with a per-service header for Guaranteed service hits a network element that implements Guaranteed service, the guaranteed service data fragment gets updated 🔥
- If the data block in the ADSPEC is empty (header-only), the header-only fragment must first be expanded into the complete data fragment described above, with the initial values of Ctot, Dtot, Csum, and Dsum set to zero. You can spot an empty fragment quickly by checking for a size field of zero. The value of the break bit in the header is preserved when the extra Guaranteed service data is added. The overall message length and the guaranteed service data fragment size (field (b) in the pictures above) both change to reflect the longer message 🎀
- The values of Ctot, Csum, Dtot, and Dsum in the ADSPEC data fragment then get composed with the local values exported by the network element, using the composition functions defined in [RFC 2212] 🧠
- When a PATH message ADSPEC with a Guaranteed service header hits a network element that supports RSVP but does not implement Guaranteed service, that network element sets the break bit in the Guaranteed service header 🙅♀️
- The new values go into the correct fields of the ADSPEC, and the ADSPEC gets passed back to RSVP for delivery to the next hop along the path 💖
When a PATH message ADSPEC with a Guaranteed service data fragment hits a network element that supports RSVP but does not implement Guaranteed service, that network element sets the break bit in the Guaranteed service header 🫶
And last but definitely not least: when a PATH message ADSPEC without a Guaranteed service header hits a network element that implements Guaranteed service, the Guaranteed service module leaves the ADSPEC unchanged 🙈 No Guaranteed service per-service header means the application doesn't care about Guaranteed service at all, so no drama 💅
3.3.4. Controlled-Load Service ADSPEC data fragment ✨
Okay so the Controlled-Load service doesn't need any extra ADSPEC data to work properly, unlike Guaranteed service 🫶. The only ADSPEC data that's specific to Controlled-Load is the Controlled-Load break bit 🦋. That means the usual Controlled-Load data block carries zero extra info 💅. The smallest the controlled-load service data fragment can be is 1 32-bit word 🎀.
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 5 (a) |x| (b) | N-1 (c) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Service-specific general parameter headers/values, if present |
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
N | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Per-Service header, service number 5 (Controlled-Load)
(b) - Break bit
(c) - Length of per-service data in 32 bit words not including
header word.Here's how the Controlled-Load part of the ADSPEC gets handled, bestie 👑:
- When a PATH message ADSPEC with a Controlled-Load service header hits a network element that implements Controlled-Load service, the network element makes no changes to the service header 🌸.
- When a PATH message ADSPEC with a Controlled-Load service header hits a network element that supports RSVP but does not implement Controlled-Load service, the network element sets the break bit in the Controlled-Load service header 🙈.
- In either case, the ADSPEC gets handed back to RSVP so it can go to the next hop along the path 🧚.
3.3.5. Overriding Global ADSPEC Data with Service-Specific Information 🌈
Sometimes the default values for the general parameters just aren't right for a specific service 😭. For example, a Guaranteed service implementation might only accept packets smaller than the link MTU, or a network element might cap the share of outgoing link bandwidth that Controlled-Load gets to less than the full bandwidth, for admin reasons 💀.
When that happens, the receiver gets both the service-specific value and the default value in the ADSPEC 🍓. Service-specific info that overrides the general info is carried by a parameter with the same name as the general parameter, and it sits inside the data fragment of the QoS control service it applies to ✨. These are called override parameters, or service-specific general parameters 💜.
Here's an example of a Controlled-Load ADSPEC fragment overriding the global path bandwidth estimate with a different value 🎀:
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 5 (a) |x| (b) | 2 (c) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 6 (d) | 0 (d) | 1 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Path b/w estimate for C-L service (32b IEEE FP number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Per-Service header, service number 5 (Controlled-Load)
(b) - Break bit
(c) - Length of per-service data, two words not including header
(c) - Parameter ID, parameter 6
(AVAILABLE_PATH_BANDWIDTH general parameter from [RFC 2215])
(d) - Parameter 6 flags (none set)
(e) - Parameter 6 length, one word not including headerYou can spot override parameters pretty easily 🔥. First, check the fragment's length field, because it'll be bigger than the "standard" length for that fragment 👀. Then look at the parameter headers. They use parameter_numbers from the general parameter part of the number space (1-127), but they live in service-specific data blocks (the ones with service_numbers between 2 and 254 in the per_service header field) 🧚♀️.
Including override parameters in a data fragment is optional 🦋. A parameter header/value pair only gets added when an application or QoS control service wants to swap the global value of a general parameter for a service-specific one 🌸.
Just like with IP options, only the use of these override parameters is optional 🙈. All implementations must be prepared to receive and process override parameters 🫶.
The main rule for override parameters is simple: use the override value (local or from the ADSPEC) if one exists, and use the default value otherwise 💅. If a local node exports an override value for a general parameter but the arriving ADSPEC doesn't have one, the local node adds it ✨. Here's the pseudo-code with more detail:
/* Adspec parameter processing rules *
<get arriving ADSPEC from RSVP>
for ( <each service number N with a fragment in the ADSPEC> ) {
if ( <the local node does not support the service> ) {
<set the break bit in the service header>
} else {
for ( <each parameter in the data fragment for service N> ) {
if ( < the local service N supplies a value for the parameter> ) {
<compose the arriving and values and update the adspec>
} else {
/* Must be a general parameter, or service N would have
* supplied a value..
*/
<compose the arriving value with the local default value
and update the adspec>
}
}
for ( <any parameters supplied by the local service N
implementation but not found in the adspec> ) {
/*
* Must be an override value for a general parameter,
* or the adspec would have contained a value..
*/
<compose the local override value with the arriving default
value (from the service 1 data fragment) and add the parameter
to the adspec's service N fragment in parameter_number order>
}
}
}
<pass updated ADSPEC back to RSVP>In practice, the two 'for' loops can be squished together 🎀. Override parameters inside a service's fragment are sent in numerical order, so you can check whether a parameter is there without scanning the whole fragment 🧠. And since the data fragments are ordered by service_number, the default values for general parameters always get read before they're needed to update local override values in the second loop 👑.
3.3.6. Example ✨
Okay so this picture shows the complete adspec for an app that can use either controlled-load or guaranteed service, and it's giving full buffet 🍓 It has data fragments for the general parameters, guaranteed, AND controlled-load services. Every fragment is standard size, and there are zero override parameters, so no drama 💅
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | Unused | 19 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |x| reserved (d)| 8 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 4 (f) | (g) | 1 (h) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | zero extension of .. IS hop cnt (16-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | 6 (i) | (j) | 1 (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Path b/w estimate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | 8 (l) | (m) | 1 (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Minimum path latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 10 (o) | (p) | 1 (q) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | zero extension of .. composed MTU (16-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | 2 (r) |x| reserved (s)| 8 (t) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | 133 (u) | (v) | 1 (w) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
13 | End-to-end composed value for C [Ctot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
14 | 134 (x) | (y) | 1 (z) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
15 | End-to-end composed value for D [Dtot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | 135 (aa | (bb | 1 (cc) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
17 | Since-last-reshaping point composed C [Csum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
18 | 136 (dd) | (ee) | 1 (ff) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
19 | Since-last-reshaping point composed D [Dsum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | 5 (gg |x 0 (hh) | 0 (ii) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Word 1: Message Header:
(a) - Message header and version number
(b) - Message length - 19 words not including header
Words 2-7: Default general characterization parameters
(c) - Per-Service header, service number 1
(Default General Parameters)
(d) - Global Break bit (NON_IS_HOP general parameter 2) (marked x)
(e) - Length of General Parameters data block (8 words)
(f) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS
general parameter)
(g) - Parameter 4 flag byte
(h) - Parameter 4 length, 1 word not including header
(i) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH
general parameter)
(j) - Parameter 6 flag byte
(k) - Parameter 6 length, 1 word not including header
(l) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY
general parameter)
(m) - Parameter 8 flag byte
(n) - Parameter 8 length, 1 word not including header
(o) - Parameter ID, parameter 10 (PATH_MTU general parameter)
(p) - Parameter 10 flag byte
(q) - Parameter 10 length, 1 word not including header
Words 11-19: Guaranteed service parameters
(r) - Per-Service header, service number 2 (Guaranteed)
(s) - Break bit
(t) - Length of per-service data, 8 words not including header
(u) - Parameter ID, parameter 133 (Composed Ctot)
(v) - Composed Ctot flag byte
(w) - Composed Ctot length, 1 word not including header
(x) - Parameter ID, parameter 134 (Composed Dtot)
(y) - Composed Dtot flag byte
(z) - Composed Dtot length, 1 word not including header
(aa)- Parameter ID, parameter 135 (Composed Csum).
(bb)- Composed Csum flag byte
(cc)- Composed Csum length, 1 word not including header
(dd)- Parameter ID, parameter 136 (Composed Dsum).
(ee)- Composed Dsum flag byte
(ff)- Composed Dsum length, 1 word not including header
Word 20: Controlled-Load parameters
(gg - Per-Service header, service number 5 (Controlled-Load)
(hh)- Break bit
(ii)- Length of controlled-load data, 0 words not including header4. Security Considerations 🔐
Good news, bestie: the message formatting and usage rules in this note don't raise any security issues on their own 🫶 BUT using these rules to set up multiple qualities of service with RSVP and integrated services scheduling modules does introduce a new security need: controlling and authenticating who gets access to the enhanced qualities of service 😭 There's more on that in [RFC 2205], [RFC 2212], and [RFC 2211]. And [RFCRSVPMD5] describes the mechanism that protects the integrity of RSVP messages carrying the info in here. This is literally the part where you lock the door 🔒✨
Appendix 1: Message construction rules 🧚
Okay this section explains the rule used to build the object formats from Section 3 💖 It's a general wire format for packing integrated services data objects into setup and management protocol messages. The whole thing has a three-level structure, and it's so clean:
- An overall message header carries a version number and message length. Because the header is in a standard format, the same code library can handle data objects carried by multiple setup protocols. Iconic reuse 👑
- Per-service fragments carry info about one specific QoS control service, like guaranteed [RFC 2212] or controlled load [RFC 2211]. Each per-service fragment carries one or more parameters, and which parameters show up depends on what the protocol in use needs. Examples are in Section 2 🌸
- Parameters are the actual data used to control or monitor a service. A parameter can be a single quantity like an integer, or a composite structure like a TSpec. The parameters specific to a service are defined by that service's specification, while the general parameters (the ones shared by lots of services) are defined by [RFC 2215] 🦋
A1.1. Message Header 💅
The 32-bit message header specifies the message format version number and the total length of the message. The overall message has to be aligned to a 32-bit boundary inside the transport protocol's data packet. The message length is counted in 32-bit words not including the word containing the header. Why? It lowers the chances that one accidentally cleared word causes an infinite loop in the message parser. Smart, right? 🧠
The Message Header is a 32-bit bitfield laid out as shown below, then encoded as an XDR unsigned integer. Encoding it as an XDR unsigned integer is the same as converting the bitfield from the machine's native format to big-endian network byte order.
Message Header
MSB LSB
31 28 27 16 15 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | Unused | OVERALL LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+V- Message format version; currently 0OVERALL LENGTH- Message length in 32-bit words not including header
A1.2. Per-Service Data Header 🌈
The message header is followed by one or more service-specific data blocks, and each one holds the data for one specific QoS control service. Every service-specific block starts with an identifying header. This 32-bit header has the service number, a one-bit flag (the "break bit", since it signals a break in the QoS control path), and a length field. The length field is the number of 32-bit words used to hold data for this service, counted not including the word containing the header.
The break bit, if set, means the service named in the header was unsupported or unrecognized at some point along the message's path through the network. It maps onto the general parameter NON_IS_HOP defined in [RFC 2215]. It starts out cleared when a message is first generated, and it gets set whenever the message passes through an element that doesn't recognize the service_number in the per-service header 🙈
The Per-Service Data Header is a 32-bit bitfield laid out as shown below, then encoded as an XDR unsigned integer.
Per-Service Data Header
MSB LSB
31 24 23 16 15 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SVC_NUMBER |B| Reserved | SVC_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+SVC_NUMBER- Service ID number (defined in service specification).B- Break bit - service unsupported/break in path.SVC_LENGTH- Service-specific data length in 32-bit words, not including header.
A1.3. Parameter Header 🎀
okay so every parameter block gets its own little ID card, called the Parameter Header 🪪. after the per-service header comes one or more of these blocks, and each one is labelled with the parameter identifier (the parameter number), the length of the data holding its value, and a flag field. the data field(s) of the parameter come right after. the parameter number, plus what the data words after the header mean and how they're formatted, come from whichever spec defines that parameter 🧚
the Parameter Header is a 32-bit bitfield laid out like this, and then it gets encoded as an XDR unsigned integer 💅
Parameter Header
MSB LSB
31 24 23 16 15 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PARAM_NUM |I FLAGS | PARAM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here's what each field is giving:
PARAM_NUMis the parameter number, defined in the service specification 🔢FLAGSholds the per-parameter flags 🚩PARAM_LENGTHis the length of the per-parameter data in 32-bit words, and it does not include the header word 📏
the only flag defined in the FLAGS field right now is:
I(bit 23), which is INVALID 💀
this flag says the parameter value wasn't processed correctly at one or more network elements along a data path. it's meant for a possible future service composition scheme, so it's kind of a sneak peek into the future 🔮
every other bit in the FLAGS field of the parameter header is reserved for now, and they should be set to zero 🫶
A1.4. Parameter Data 🌸
after the Parameter Header comes the actual data that represents the parameter value. the parameter values get encoded into one or more 32-bit words using the XDR external data representation described in [RFC 1832], and those words get placed in the message 📦
the document that defines a parameter should give an XDR description of that parameter's data fields. if it doesn't, the description should be provided in this note ✨
References
[RFC 2205] Braden, B., Ed., et. al., "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[RFC 2216] Shenker, S., and J. Wroclawski. "Network Element QoS Control Service Specification Template", RFC 2216, September 1997.
[RFC 2212] Shenker, S., Partridge, C., and R Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC 2211] Wroclawski, J., "Specification of the Controlled Load Quality of Service", RFC 2211, September 1997.
[RFC 2215] Shenker, S., and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[RFCRSVPMD5] Baker, F., "RSVP Cryptographic Authentication", Work in Progress.
[RFC 1832] Srinivansan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
Author's Address 💜
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
Phone: 617-253-7885 Fax: 617-253-2673 (FAX) EMail: jtw@lcs.mit.edu
📦 where this page comes from
- ietf: rfc2210 1997-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms