diff options
Diffstat (limited to 'doc/rfc/rfc2210.txt')
| -rw-r--r-- | doc/rfc/rfc2210.txt | 1851 |
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc2210.txt b/doc/rfc/rfc2210.txt new file mode 100644 index 0000000..3c3abb6 --- /dev/null +++ b/doc/rfc/rfc2210.txt @@ -0,0 +1,1851 @@ + + + + + + +Network Working Group J. Wroclawski +Request for Comments: 2210 MIT LCS +Category: Standards Track September 1997 + + + + The Use of RSVP with IETF Integrated Services + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This note describes the use of the RSVP resource reservation protocol + with the Controlled-Load and Guaranteed QoS control services. The + RSVP protocol defines several data objects which carry resource + reservation information but are opaque to RSVP itself. The usage and + data format of those objects is given here. + +1. Introduction + + The Internet integrated services framework provides the ability for + applications to choose among multiple, controlled levels of delivery + service for their data packets. To support this capability, two + things are required: + + - Individual network elements (subnets and IP routers) along the + path followed by an application's data packets must support + mechanisms to control the quality of service delivered to those + packets. + + - 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 must be provided. + + In the integrated services framework the first function is provided + by QoS control services such as Controlled-Load [RFC 2211] and + Guaranteed [RFC 2212]. The second function may be provided in a + number of ways, but is frequently implemented by a resource + reservation setup protocol such as RSVP [RFC 2205]. + + + + + +Wroclawski Standards Track [Page 1] + +RFC 2210 RSVP with INTSERV September 1997 + + + Because RSVP is designed to be used with a variety of QoS control + services, and because the QoS control services are designed to be + used with a variety of setup mechanisms, a logical separation exists + between the two specifications. The RSVP specification does not + define the internal format of those RSVP protocol fields, or objects, + which are related to invoking QoS control services. Rather, RSVP + treats these objects as opaque. The objects can carry different + information to meet different application and QoS control service + requirements. + + Similarly, interfaces to the QoS control services are defined in a + general format, so that the services can be used with a variety of + setup mechanisms. + + This RFC provides the information required to use RSVP and the + integrated service framework's QoS control services together. It + defines the usage and contents of three RSVP protocol objects, the + FLOWSPEC, ADSPEC, and SENDER_TSPEC, in an environment supporting the + Controlled-Load and/or Guaranteed QoS control services. If new + services or capabilities are 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: + + - Information generated by each receiver describing the QoS + control service desired, a description of the traffic flow to + which the resource reservation should apply (the Receiver TSpec), + and whatever parameters are required to invoke the service (the + Receiver RSpec). This information is carried from the receivers to + intermediate network elements and the sender(s) by RSVP FLOWSPEC + objects. The information being carried in a FLOWSPEC object may + change at intermediate points in the network due to reservation + merging and other factors. + + + + + + +Wroclawski Standards Track [Page 2] + +RFC 2210 RSVP with INTSERV September 1997 + + + - Information generated at each sender describing the data traffic + generated by that sender (the Sender TSpec). This information is + carried from the sender to intermediate network elements and the + receiver(s) by RSVP, but is never modified by intermediate + elements within the network. This information is carried in RSVP + SENDER_TSPEC objects. + + - Information generated or modified within the network and used at + the receivers to make reservation decisions. This information + might include available services, delay and bandwidth estimates, + and operating parameters used by specific QoS control services. + this information is collected from network elements and carried + towards receivers in RSVP ADSPEC objects. Rather than carrying + information from each intermediate node separately to the + receivers, the information in the ADSPEC represents a summary, + computed as the ADSPEC passes each hop. The size of this summary + remains (roughly) constant as the ADSPEC flows through the + network, giving good scaling properties. + + From the point of view of RSVP objects, the breakdown is as follows: + + - The RSVP SENDER_TSPEC object carries the traffic specification + (sender TSpec) generated by each data source within an RSVP + session. It is transported unchanged through the network, and + delivered to both intermediate nodes and receiving applications. + + - The RSVP ADSPEC object carries information which is generated at + either data sources or intermediate network elements, is flowing + downstream towards receivers, and may be used and updated inside + the network before being delivered to receiving applications. + This information includes both parameters describing the + properties of the data path, including the availability of + specific QoS control services, and parameters required by specific + QoS control services to operate correctly. + + - The RSVP FLOWSPEC object carries reservation request + (Receiver_TSpec and RSpec) information generated by data + receivers. The information in the FLOWSPEC flows upstream towards + data sources. It may be used or updated at intermediate network + elements before arriving at the sending application. + + NOTE: The existence of both 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 information carried "downstream" by RSVP in the same + object. However, the distinction between data which is not + updated within the network (in the SENDER_TSPEC object) and data + which is updated within the network (in the ADSPEC object) may + + + +Wroclawski Standards Track [Page 3] + +RFC 2210 RSVP with INTSERV September 1997 + + + be useful to an implementation in practice, and is therefore + retained. + +2.1 Summary of operation + + Operation proceeds as follows: + + An application instance participating in an RSVP session as a data + sender registers with RSVP. One piece of information provided by the + application instance is the Sender TSpec describing the traffic the + application expects to generate. This information is used to + construct an RSVP SENDER_TSPEC object, which is included in RSVP PATH + messages generated for the application. + + The sending application also constructs an initial RSVP ADSPEC + object. This adspec carries information about the QoS control + capabilities and requirements of the sending application itself, and + forms the starting point for the accumulation of path properties + described below. The ADSPEC is 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 not to provide an + initial adspec, instead supplying its own default. This usage is + most likely when the application sender does not itself + participate in the end-to-end QoS control process (by actively + scheduling CPU usage and similar means) and does not itself care + which QoS control service is selected by the receivers. + + 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 is modified by subsequent network elements as the RSVP + PATH message moves from sender to 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 such service to + update its portion of the ADSPEC. If the traffic control module + discovers a QoS control service mentioned in the ADSPEC but not + 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. + + + + + + +Wroclawski Standards Track [Page 4] + +RFC 2210 RSVP with INTSERV September 1997 + + + Upon arrival of the PATH message 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 the help of a + library of common resource-reservation functions) interprets the + arriving data, and uses it to guide the selection of resource + reservation parameters. Examples of this include use of the arriving + "PATH_MTU" composed characterization parameter [RFC 2215] to + determine the maximum packet size parameter in the reservation + request and use of 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 wishing 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 for which resources should be reserved, and, if needed by + the selected QoS control service, an RSpec describing the level of + service desired. These parameters are composed into an RSVP FLOWSPEC + object and transmitted 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 proceed according to 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 to inform each + sender of the merged reservation request and properties of the data + path. + +2.2. RSVP support for multiple QoS control services + + The design described in this note supports RSVP sessions in which the + receivers choose a QoS control service at runtime. + + To make this possible, a receiver must have all the information + needed to choose a particular service before it makes the choice. + This means that the RSVP SENDER_TSPEC and ADSPEC objects must provide + the receivers with information for all services which might be + chosen. + + The Sender TSpec used by the two currently defined QoS control + services is identical. This simplifies the RSVP SENDER_TSPEC object, + which need carry only a single TSpec data structure in this shared + format. This common SENDER_TSPEC can be used with either Guaranteed + or Controlled-Load service. + + + +Wroclawski Standards Track [Page 5] + +RFC 2210 RSVP with INTSERV September 1997 + + + The RSVP ADSPEC carries information needed by receivers to choose a + service and determine the reservation parameters. This includes: + + - Whether or not there is a non-RSVP hop along the path. If there + is a non-RSVP hop, the application's traffic will receive + reservationless best-effort service at at least one point on the + path. + + - Whether or not a specific QoS control service is implemented at + every hop along the path. For example, a receiver might learn that + at least one integrated-services aware hop along the path supports + the Controlled-Load service but not the Guaranteed service. + + - Default or global values for the general characterization + parameters described in [RFC 2215]. These values describe + properties of the path itself, irrespective of the selected QoS + control service. 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, if the service-specific value differs + from the default value. + + - Values of the per-service characterization parameters defined by + each supported service. + + Data in the ADSPEC is divided into blocks or fragments, each of which + is associated with a specific service. This allows the adspec to + carry information about multiple services, allows new services to be + deployed in the future without immediately updating existing code, + and allows an application which will never use a particular service + to omit the ADSPEC data for that service. The structure of the + ADSPEC is described in detail in Section 3.3. + + A sender may indicate that a specific QoS control service should + *not* be used by the receivers within an RSVP session. This is done + by omitting all mention of that service from the ADSPEC, as described + in Section 3.3. Upon arrival at a receiver, the complete absence of + an ADSPEC fragment for a specific service indicates to receivers 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 + is imposed by the difficulty of merging reservations requesting + different QoS control services, and the current lack of a general + service replacement mechanism. The restriction may be eliminated + in the future. + + + +Wroclawski Standards Track [Page 6] + +RFC 2210 RSVP with INTSERV September 1997 + + + Considering this restriction, it may be useful to coordinate the + receivers' selection of a QoS control service by having the + sender(s) offer only one choice, using the ADSPEC mechanism + mentioned above. All receivers must then select the same service. + Alternatively, the coordination might be accomplished by using a + higher-level session announcement and setup mechanism to inform + the receivers of the QoS control service in use, by manual + configuration of the receivers, or by an agreement protocol + running among the session receivers themselves. + + As with the ADSPEC, the FLOWSPEC and SENDER_TSPEC object formats + described in Section 3 are capable of carrying TSpecs and RSpecs + for more than one QoS control service in separate data fragments. + Currently, use of a FLOWSPEC or SENDER_TSPEC containing fragments + for more than one QoS control service is not supported. In the + future, this capability may be used to implement a more flexible + service request and replacement scheme, allowing applications to + obtain useful end-to-end QoS control when not all intermediate + nodes support the same set of QoS services. RSVP-application APIs + should be designed to support passing SENDER_TSPEC, FLOWSPEC, and + ADSPEC objects of variable size and containing information 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 the use of information conveyed by the RSVP ADSPEC object. + +2.3.1. Determining the availability of a QoS control service + + The RSVP ADSPEC carries flag bits telling the application receivers + whether or not a completely reservation-capable path exists between + each sender and the receiver. These bits are called "break bits", + because they indicate breaks in the QoS control along a network path. + Break bits are carried within the header which begins each per- + service data fragment of an RSVP ADSPEC. + + Service number 1 is used within the ADSPEC to identify a fragment + carrying information about global parameter values that apply to all + services (see [RFC 2215] for more details). The break bit in service + 1's per-service header is used to tell the receiver(s) whether all of + the network elements along the path from sender to receiver support + RSVP and integrated services. If a receiver finds this bit set, at + least one network element along the data transmission path between + the ADSPEC's sender and the receiver can not provide QoS control + services at all. This bit corresponds to the global NON_IS_HOP + characterization parameter defined in [RFC 2215]. + + + + +Wroclawski Standards Track [Page 7] + +RFC 2210 RSVP with INTSERV September 1997 + + + NOTE: If this bit is set, the values of all other parameters in + the ADSPEC are unreliable. The bit being set indicates that at + least one node along the sender-receiver path did not fully + process the ADSPEC. + + Service-specific break bits tell the receiver(s) whether all of the + network elements along the path from sender to receiver support a + particular QoS control service. The break bit for each service is + carried within the ADSPEC's per-service header for that service. If + a bit is set at the receiver, at least one network element along the + data transmission path supports RSVP but does not support the QoS + control service corresponding to the per-service header. These bits + correspond to the service-specific NON_IS_HOP characterization + parameters defined in [RFC 2215]. + + Section 3 gives more information about break bits. + +2.3.2. Determining Path MTU + + Both Guaranteed and Controlled-Load QoS control services place an + upper bound on packet size, and require that the application limit + the maximum size of packets subject to resource reservation. For both + services, the desired maximum packet size is a parameter of the + reservation request, and the service will reject (with an admission + control error) reservation requests specifying a packet size larger + than that supported by the service. + + Since RSVP reservation requests are made by receivers, this implies + that the *receivers* in an RSVP session, as well as the senders, need + to know the MTU supported by the QoS control services along a data + path. Further, in some unusual cases the MTU supported by a QoS + control service may differ from that supported by the same router + when providing best effort service. + + A scalable form of MTU negotiation is used to address these problems. + MTU negotiation in an RSVP system works as follows: + + - Each sending application joining 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 maximum packet size it wishes to send covered by resource + reservation. + + - Each RSVP PATH message from a sending application also carries + an ADSPEC object containing at least one PATH_MTU characterization + parameter. When it arrives at the receiver, this parameter gives + the minimum MTU at any point along the path from sender to + receiver. Generally, only the "global" PATH_MTU parameter + + + +Wroclawski Standards Track [Page 8] + +RFC 2210 RSVP with INTSERV September 1997 + + + (service 1, parameter 9) will be present, in which case its value + is a legal MTU for all reservation requests. If a service specific + PATH_MTU parameter is present, its value will be smaller than that + of the global parameter, and 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) arriving in ADSPEC messages from + different senders and uses that value as the MTU in its + reservation requests. This value is used to fill in the M + parameter of the TSpec created at the receiver. In the case of a + FF style reservation, a receiver may also choose to use the MTU + derived from each sender's ADSPEC in the FLOWSPEC generated for + that sender, if the receiver is concerned about obtaining the + maximum MTU on each data path. To accomodate changes in the data + path, the receiver may continue to watch the arriving ADSPECS, and + modify the reservation if a newly arriving ADSPEC indicates a + smaller MTU than is currently in use. + + - As reservation requests (RESV messages) move from receivers to + senders, reservation parameters are merged at intermediate nodes. + As part of this merging, the smaller of two M parameters arriving + at a merge point will be 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 will use 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 arrives at 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. This MTU should be used + by the sending application to size its packets. Any packets larger + than this MTU may be 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 selected in + this step. The value of M represents the largest packet the sender + could send, not the largest packet the sender is currently + sending. + + + + + + +Wroclawski Standards Track [Page 9] + +RFC 2210 RSVP with INTSERV September 1997 + + + Note that the scheme above will allow each sender in a session to use + the largest MTU appropriate for that sender, in cases where different + data paths or receivers have different acceptable MTU's. + +3. RSVP Object Formats + + This section specifies the detailed contents and wire format of 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 + + The RSVP SENDER_TSPEC object carries information about a data + source's generated traffic. The required RSVP SENDER_TSPEC object + contains a global Token_Bucket_TSpec parameter (service_number 1, + parameter 127, as defined in [RFC 2215]). This TSpec carries traffic + information usable by either the Guaranteed or Controlled-Load QoS + control services. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wroclawski Standards Track [Page 10] + +RFC 2210 RSVP with INTSERV September 1997 + + + 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 header + + + In this TSpec, the parameters [r] and [b] are set to reflect the + sender's view of its generated traffic. The peak rate parameter [p] + may be set to the sender's peak traffic generation rate (if known and + controlled), the physical interface line rate (if known), or positive + infinity (if no better value is available). Positive infinity is + represented as an IEEE single-precision floating-point number with an + exponent of all ones (255) and a sign and mantissa of all zeros. The + format of IEEE floating-point numbers is further summarized in [RFC + 1832]. + + The minimum policed unit parameter [m] should generally be set equal + to the size of the smallest packet generated by the application. This + packet size includes the application data and all protocol headers at + or above the IP level (IP, TCP, UDP, RTP, etc.). The size given does + not include any link-level headers, because these headers will change + as the packet crosses different portions of the internetwork. + + + + + + +Wroclawski Standards Track [Page 11] + +RFC 2210 RSVP with INTSERV September 1997 + + + The [m] parameter is used by nodes within the network to compute the + maximum bandwidth overhead needed to carry a flow's packets over the + particular link-level technology, based on the ratio of [m] to the + link-level header size. This allows the correct amount of bandwidth + to be allocated to the flow at each point in the net. Note that + smaller values of this parameter lead to increased overhead + estimates, and thus increased likelyhood of a reservation request + being rejected by the node. In some cases, an application + transmitting a low percentage of very small packets may therefore + choose to set the value of [m] larger than the actual minimum + transmitted packet size. This will increase the likelyhood of the + reservation succeeding, at the expense of policing packets of size + less than [m] as if they were of size [m]. + + Note that the an [m] value of zero is illegal. A value of zero would + indicate that no data or IP headers are present, and would give an + infinite amount of link-level overhead. + + The maximum packet size parameter [M] should be set to the size of + the largest packet the application might wish to generate, as + described in Section 2.3.2. This value must, by definition, be equal + to or larger than the value of [m]. + +3.2. RSVP FLOWSPEC Object + + The RSVP FLOWSPEC object carries information necessary to make + reservation requests from the receiver(s) into the network. This + includes an indication of which QoS control service is being + requested, and the parameters needed for that service. + + The QoS control service requested is indicated by the service_number + in the FLOWSPEC's per-service header. + +3.2.1 FLOWSPEC object when requesting Controlled-Load service + + The format of an RSVP FLOWSPEC object originating at a receiver + requesting Controlled-Load service is shown below. Each of the TSpec + fields is represented using the preferred concrete representation + specified in the 'Invocation Information' section of [RFC 2211]. The + value of 5 in the per-service header (field (c), below) indicates + that Controlled-Load service is being requested. + + + + + + + + + + +Wroclawski Standards Track [Page 12] + +RFC 2210 RSVP with INTSERV September 1997 + + + 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 + header + + + In this object, the TSpec parameters [r], [b], and [p] are set to + reflect the traffic parameters of the receiver's desired reservation + (the Reservation TSpec). The meaning of these fields is discussed + fully in [RFC 2211]. Note that it is unlikely to make sense for the + [p] term to be smaller than the [r] term. + + The maximum packet size parameter [M] should be set to the value of + the smallest path MTU, which the receiver learns from information in + arriving RSVP ADSPEC objects. Alternatively, if the receiving + application has built-in knowledge of the maximum packet size in use + within the RSVP session, and this value is smaller than the smallest + path MTU, [M] may be set to this value. Note that requesting a value + of [M] larger than the service modules along the data path can + support will cause the reservation to fail. See section 2.3.2 for + further discussion of the MTU value. + + + + + + +Wroclawski Standards Track [Page 13] + +RFC 2210 RSVP with INTSERV September 1997 + + + The value of [m] can be chosen in several ways. Recall 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 application has a fixed, known minimum packet size, than that + value should be used for [m]. This is the most desirable case. + + For a shared reservation style, the receiver may choose between two + options, or pick some intermediate point between them. + + - if the receiver chooses a large value for [m], then the + reservation will allocate less overhead for link-level headers. + However, if a new sender with a smaller SENDER_TSPEC [m] joins the + session later, an already-installed reservation may fail at that + time. + + - if the receiver chooses a value of [m] equal to the smallest + value which might be used by any sender, then the reservation will + be forced to allocate more overhead for link-level headers. + However it will not fail later if a new sender with a smaller + SENDER_TSPEC [m] joins the session. + + For a FF reservation style, if no application-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 + + The format of an RSVP FLOWSPEC object originating at a receiver + requesting Guaranteed service is shown below. The flowspec object + used to request guaranteed service carries a TSpec and RSpec + specifying the traffic parameters of the flow desired by the + receiver. + + Each of the TSpec and RSpec fields is represented using the preferred + concrete representation specified in the 'Invocation Information' + section of [RFC 2212]. The value of 2 for the service header + identifier (field (c) in the picture below) indicates that Guaranteed + service is being requested. + + + + + + + + + + + +Wroclawski Standards Track [Page 14] + +RFC 2210 RSVP with INTSERV September 1997 + + + 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 header + + + In this object, the TSpec parameters [r], [b], and [p] are set to + reflect the traffic parameters of the receiver's desired reservation + (the Reservation TSpec). The meaning of these fields is discussed + fully in [RFC 2212]. Note that it is unlikely to make sense for the + [p] term to be smaller than the [r] term. + + The RSpec terms [R] and [S] are selected to obtain the desired + bandwidth and delay guarantees. This selection is described in [RFC + 2212]. + + + + +Wroclawski Standards Track [Page 15] + +RFC 2210 RSVP with INTSERV September 1997 + + + The [m] and [M] parameters are set identically to those for the + Controlled-Load service FLOWSPEC, described in the previous section. + +3.3. RSVP ADSPEC Object + + An RSVP ADSPEC object is constructed from data fragments contributed + by each service which might be used by the application. The ADSPEC + begins with an overall message header, followed by a fragment for the + default general parameters, followed by fragments for every QoS + control service which may be selected by application receivers. The + size of the ADSPEC varies depending on the number and size of per- + service data fragments present and the presence of non-default + general parameters (described in Section 3.3.5). + + The complete absence of a data fragment for a particular service + means that the application sender does not know or care about that + service, and is a signal to intermediate nodes not to add or update + information about that service to the ADSPEC. It is also a signal to + application receivers that they should not select that service when + making reservations. + + Each fragment present is identified by a per-service data header. + Each header contains a field identifying the service, a break bit, + and a length field. + + The length field allows the ADSPEC information for a service to be + skipped over by a network elements which does not recognize or + implement the service. When an element does this, it sets the break + bit, indicating that the service's ADSPEC data was not updated at at + least one hop. Note that a service's break bit can be set without + otherwise supporting the service in any way. In all cases, a network + element encountering a per-service data header it does not understand + simply sets bit 23 to report that the service is not supported, then + skips over the rest of the fragment. + + Data fragments must always appear in an ADSPEC in service_number + order. In particular, the default general parameters fragment + (service_number 1) always comes first. + + Within a data fragment, the service-specific data must alway come + first, followed by any non-default general parameters which may be + present, ordered by parameter_number. The size and structure of the + service-specific data is fixed by the service definition, and does + not require run-time parsing. The remainder of the fragment, which + carries non-default general parameters, varies in size and structure + depending on which, if any, of these parameters are present. This + part of the fragment must be parsed by examining the per-parameter + headers. + + + +Wroclawski Standards Track [Page 16] + +RFC 2210 RSVP with INTSERV September 1997 + + + Since the overall size of each data fragment is variable, it is + always necessary to examine the length field to find the end of the + fragment, rather than assuming a fixed-size structure. + + 3.3.1. RSVP ADSPEC format + + The basic ADSPEC format is shown below. The message header and the + default general parameters fragment are always present. The fragments + for Guaranteed or Controlled-Load service may be omitted if the + service is not to be used by the RSVP session. Additional data + fragments will be added if new services are defined. + + 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 fragments + +3.3.2. Default General Characterization Parameters ADSPEC data fragment + + All RSVP ADSPECs carry the general characterization parameters + defined in [RFC 2215]. Values for global or default general + parameters (values which apply to the all services or the path + itself) are carried in the per-service data fragment for service + number 1, as shown in the picture above. This fragment is always + present, and always first in the message. + + + + + + + +Wroclawski Standards Track [Page 17] + +RFC 2210 RSVP with INTSERV September 1997 + + + 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 header + + + Rules for composing general parameters appear in [RFC 2215]. + + In the above fragment, the global break bit (bit 23 of word 1, marked + with (x) in the picture) is used to indicate the existence of a + network element not supporting QoS control services somewhere in the + data path. This bit is cleared when the ADSPEC is created, and set + to one if a network element which does not support RSVP or integrated + + + +Wroclawski Standards Track [Page 18] + +RFC 2210 RSVP with INTSERV September 1997 + + + services is encountered. An ADSPEC arriving at a receiver with this + bit set indicates that all other parameters in the ADSPEC may be + invalid, since not all network elements along the path support + updating of the ADSPEC. + + The general parameters are updated at every network node which + supports RSVP: + + - When a PATH message ADSPEC encounters a network element + implementing integrated services, the portion of the ADSPEC + associated with service number 1 is passed to the module + implementing general parameters. This module updates the global + general parameters. + + - When a PATH message ADSPEC encounters a network element that + does *not* support RSVP or implement integrated services, the + break bit in the general parameters service header must be set. In + practice, this bit will usually be set by another network element + which supports RSVP, but has been made aware of the gap in + integrated services coverage. + + - In either case, the ADSPEC is passed back to RSVP for delivery + to the next hop along the path. + +3.3.3. Guaranteed Service ADSPEC data fragment + + The Guaranteed service uses the RSVP ADSPEC to carry data needed to + compute the C and D terms passed from the network to the application. + The minimum size of a non-empty guaranteed service data fragment is 8 + 32-bit words. The ADSPEC fragment for Guaranteed service has the + following format: + + + + + + + + + + + + + + + + + + + + +Wroclawski Standards Track [Page 19] + +RFC 2210 RSVP with INTSERV September 1997 + + + 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 header + + When a node which actually implements guaranteed service creates the + guaranteed service adspec fragment, the parameter values are set to + the local values for each parameter. When an application or network + + + + + + +Wroclawski Standards Track [Page 20] + +RFC 2210 RSVP with INTSERV September 1997 + + + element which does not itself implement guaranteed service creates a + guaranteed service adspec fragment, it should set the values of each + parameter to zero, and set the break bit to indicate that the service + is not actually implemented at the node. + + An application or host RSVP which is creating a guaranteed service + adspec fragment but does not itself implement the guaranteed service + may create a truncated "empty" guaranteed adspec fragment consisting + of only a 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 occur if the sending application or host does not do + resource reservation iself, but still wants the network to do so. + Note that in this case the break bit will always be set, since the + creator of the adspec fragment does not itself implement guaranteed + service. + + When a PATH message ADSPEC containing a per-service header for + Guaranteed service encounters a network element implementing + Guaranteed service, the guaranteed service data fragment is updated: + + - If the data block in the ADSPEC is an empty (header-only) block + the header-only fragment must first be expanded into the complete + data fragment described above, with initial values of Ctot, Dtot, + Csum, and Dsum set to zero. An empty fragment can be recognized + quickly by checking for a size field of zero. The value of the + break bit in the header is preserved when the additional + Guaranteed service data is added. The overall message length and + the guaranteed-service data fragment size (field (b) in the + pictures above) are changed to reflect the increased message + length. + + The values of Ctot, Csum, Dtot, and Dsum in the ADSPEC data + fragment are then composed with the local values exported by the + network element according to the composition functions defined in + [RFC 2212]. + + + + +Wroclawski Standards Track [Page 21] + +RFC 2210 RSVP with INTSERV September 1997 + + + - When a PATH message ADSPEC with a Guaranteed service header + encounters a network element that supports RSVP but does *not* + implement Guaranteed service, the network element sets the break + bit in the Guaranteed service header. + + - The new values are placed in the correct fields of the ADSPEC, + and the ADSPEC is passed back to RSVP for delivery to the next hop + along the path. + + When a PATH message ADSPEC containing a Guaranteed service data + fragment encounters a network element that supports RSVP but does + *not* implement Guaranteed service, the network element sets the + break bit in the Guaranteed service header. + + When a PATH message ADSPEC *without* a Guaranteed service header + encounters a network element implementing Guaranteed service, the + Guaranteed service module of the network element leaves the ADSPEC + unchanged. The absence of a Guaranteed service per-service header in + the ADSPEC indicates that the application does not care about + Guaranteed service. + + +3.3.4. Controlled-Load Service ADSPEC data fragment + + Unlike the Guaranteed service, the Controlled-Load service does not + require extra ADSPEC data to function correctly. The only ADSPEC data + specific to the Controlled-Load service is the Controlled-Load break + bit. Therefore the usual Controlled-Load service data block contains + no extra information. The minimum size of the controlled-load service + data fragment 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. + + + + + +Wroclawski Standards Track [Page 22] + +RFC 2210 RSVP with INTSERV September 1997 + + + The Controlled-Load portion of the ADSPEC is processed according to + the following rules: + + - When a PATH message ADSPEC with a Controlled-Load service header + encounters a network element implementing Controlled-Load service, + the network element makes no changes to the service header. + + - When a PATH message ADSPEC with a Controlled-Load service header + encounters 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 is passed back to RSVP for delivery + to the next hop along the path. + +3.3.5. Overriding Global ADSPEC Data with Service-Specific Information + + In some cases, the default values for the general parameters are not + correct for a particular service. For example, an implementation of + Guaranteed service may accept only packets with a smaller maximum + size than the link MTU, or the percentage of outgoing link bandwidth + made available to the Controlled-Load service at a network element + may be administratively limited to less than the overall bandwidth. + + In these cases, a service-specific value, as well as the default + value, is reported to the receiver receiving the ADSPEC. Service- + specific information which overrides general information is carried + by a parameter with the same name as the general parameter, placed + within the data fragment of the QoS control service to which it + applies. These service-specific values are referred to as override or + service-specific general parameters. + + For example, the following Controlled-Load ADSPEC fragment carries + information overriding the global path bandwidth estimate with a + different value: + + + + + + + + + + + + + + + + +Wroclawski Standards Track [Page 23] + +RFC 2210 RSVP with INTSERV September 1997 + + + 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 header + + + The presence of override parameters in a data fragment can be quickly + detected by examining the fragment's length field, which will be + larger than the "standard" length for the fragment. Specific + override parameters can be easily identified by examining the + parameter headers, because they have parameter_number's from the + general parameter portion of the number space (1-127), but are found + in service-specific data blocks (those with service_numbers between 2 + and 254 in the per_service header field). + + The presence of override parameters in a data fragment is optional. A + parameter header/value pair is added only when a particular + application or QoS control service wishes to override the global + value of a general parameter with a service-specific value. + + As with IP options, it is only the use of these override parameters + that is optional. All implementations must be prepared to receive and + process override parameters. + + The basic principle for handling override parameters is to use the + override value (local or adspec) if it exists, and to use the default + value otherwise. If a local node exports an override value for a + general parameter, but there is no override value in the arriving + adspec, the local node adds it. The following pseudo-code fragment + gives more detail: + + + + + + + + + +Wroclawski Standards Track [Page 24] + +RFC 2210 RSVP with INTSERV September 1997 + + + /* 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 combined. Since override + parameters within a service's fragment are transmitted in numerical + order, it is possible to determine whether a parameter is present + without scanning the entire fragment. Also, because the data + fragments are ordered by service_number, the default values for + general parameters will always be read before they might be needed to + update local override values in the second for loop. + +3.3.6. Example + + The picture below shows the complete adspec for an application which + can use either controlled-load or guaranteed service. In the example, + + + + + +Wroclawski Standards Track [Page 25] + +RFC 2210 RSVP with INTSERV September 1997 + + + data fragments are present for general parameters, guaranteed, and + controlled-load services. All fragments are of standard size, and + there are no override parameters present. + + + 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Wroclawski Standards Track [Page 26] + +RFC 2210 RSVP with INTSERV September 1997 + + + 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 header + + + + + +Wroclawski Standards Track [Page 27] + +RFC 2210 RSVP with INTSERV September 1997 + + +4. Security Considerations + + The message formatting and usage rules described in this note raise + no security issues. The overall use of these rules to implement + multiple qualities of service using RSVP and integrated services + scheduling modules introduces a new security requirement; the need to + control and authenticate access to enhanced qualities of service. + This requirement is discussed further in [RFC 2205], [RFC 2212], and + [RFC 2211]. [RFCRSVPMD5] describes the mechanism used to protect the + integrity of RSVP messages carrying the information described here. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wroclawski Standards Track [Page 28] + +RFC 2210 RSVP with INTSERV September 1997 + + +Appendix 1: Message construction rules + + This section gives the rule used to generate the object formats of + Section 3. It is a general wire format for encoding integrated + services data objects within setup and management protocol messages. + The format has a three-level structure: + + - An overall message header carries a version number and message + length. Providing this header in a standard format allows the + same code library to handle data objects carried by multiple setup + protocols. + + - Per-service fragments carry information about a specific QoS + control service, such as guaranteed [RFC 2212] or controlled load + [RFC 2211]. Each per-service fragment carries one or more + parameters. The set of parameters present in a fragment is + determined by the needs of the protocol in use. Examples are given + in Section 2. + + - Parameters are the actual data used to control or monitor a + service. A parameter may be a single quantity such as an integer, + or a composite data structure such as a TSpec. The parameters + specific to a service are defined by the service specification. + The available general parameters, with definitions shared by many + services, are defined by [RFC 2215]. + + + + + + + + + + + + + + + + + + + + + + + + + + +Wroclawski Standards Track [Page 29] + +RFC 2210 RSVP with INTSERV September 1997 + + +A1.1. Message Header + + The 32-bit message header specifies the message format version number + and total length of the message. The overall message must be aligned + to a 32-bit boundary within the transport protocol's data packet. + The message length is measured in 32-bit words *not including the + word containing the header*. This is to lower the probability of an + accidentally cleared word resulting in an infinite loop in the + message parser. + + The Message Header is represented by a 32-bit bitfield laid out as + shown below and then encoded as an XDR unsigned integer. Encoding as + an XDR unsigned integer is equivalent to 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 0 + OVERALL LENGTH - Message length in 32-bit words not including header + + + + + + + + + + + + + + + + + + + + + + + + + + +Wroclawski Standards Track [Page 30] + +RFC 2210 RSVP with INTSERV September 1997 + + +A1.2. Per-Service Data Header + + The message header is followed by one or more service-specific data + blocks, each containing the data associated with a specific QoS + control service. Each service-specific data block begins with an + identifying header. This 32-bit header contains the service number, a + one-bit flag (the "break bit", because it indicates a break in the + QoS control path) and a length field. The length field specifies the + number of 32-bit words used to hold data specific to this service as + a count of 32-bit words *not including the word containing the + header*. + + The break bit, if set, indicates that the service specified by the + header was unsupported or unrecognized at some point in the message's + path through the network. This bit corresponds to the general + parameter NON_IS_HOP defined in [RFC 2215]. It is cleared when a + message is first generated, and set whenever the message passes + through an element that does not recognize the service_number in the + per-service header. + + The Per-Service Data Header is represented by a 32-bit bitfield laid + out as shown below and 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. + + + + + + + + + + + + + + + +Wroclawski Standards Track [Page 31] + +RFC 2210 RSVP with INTSERV September 1997 + + +A1.3. Parameter Header + + The per-service header is followed by one or more service parameter + blocks, each identified by a Parameter Header. This header contains + the parameter identifier (parameter number), the length of the data + carrying the parameter's value, and a flag field. The data field(s) + of the parameter follow. The parameter number, as well as the + meaning and format of the data words following the header, are given + by the specification which defines the parameter. + + The Parameter Header is represented by a 32-bit bitfield laid out as + shown below and then encoded as an XDR unsigned integer. + + + Parameter Header + + MSB LSB + 31 24 23 16 15 0 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PARAM_NUM |I FLAGS | PARAM_LENGTH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + PARAM_NUM - Parameter number (defined in service specification) + FLAGS - Per-parameter flags + PARAM_LENGTH - Length of per-parameter data in 32-bit words, not + including the header word. + + The following flags are currently defined in the FLAGS field: + + I (bit 23) - INVALID + + This flag indicates that the parameter value was + not correctly processed at one or more network + elements along a data path. It is intended for use + in a possible future service composition scheme. + + Other bits in the FLAGS field of the parameter header are currently + reserved, and should be set to zero. + + + + + + + + + + + + + +Wroclawski Standards Track [Page 32] + +RFC 2210 RSVP with INTSERV September 1997 + + +A1.4. Parameter Data + + Following the Parameter Header is the actual data representing the + parameter value. Parameter values are encoded into one or more 32-bit + words using the XDR external data representation described in [RFC + 1832], and the resulting words are placed in the message. + + The document defining a parameter should provide an XDR description + of the parameter's data fields. If it does not, a 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 + + + + + +Wroclawski Standards Track [Page 33] + |