Internet Draft K. M. Shaheen S. M. Shahrier Document: draft-shaheen-shahrier-nsis-brsvp-00.txt InterDigital Expires: 2002 July 2002 The Use of Bi-Directional RSVP in the Wireless Internet Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Abstract With the current evolution toward wireless data, wireless internet, and wireless multimedia applications such as Voice over IP (VoIP), video conferencing, and Video telephony, similar performance requirements to those of existing circuit switched or voice based wireless systems are essential to the success of this evolution. Among these performance requirements are the call setup time, delay, reliability, and Quality of Service (QoS). To ensure QoS, provide faster call setup time, and reduce the number of RSVP messaging across the network; this note introduces the concept and describes the use of bi-directional RSVP (B- RSVP) resource reservation protocol with both Controlled-Load and Guaranteed QoS control services. While RSVP allows for uni-directional resource reservations only in the "send" direction, B-RSVP protocol generalizes the process by allowing simultaneous bi-directional (send and receive) resource reservations on each hop. B-RSVP also allows for Shaheen Standard Track - Expires June 2002 1 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet a reverse route (receive only) uni-directional resource reservation. B- RSVP is most suitable for applications in which the originator of a service is solely responsible for making the necessary reservations and their cost. This note defines several data objects that carry resource reservation information required for both send and receive traffic. The proposed message formats are extensions to existing RSVP messages and totally backward compatible. The usage and data format of those objects are described herein. 1. Introduction The success of the current evolution toward wireless internet and wireless multimedia applications such as VoIP, video conferencing, and video telephony requires similar if not superior performance to that of existing voice based wireless services. Call Setup time, delay, reliability, and QoS are among the performance criterion that need to be observed. In order to ensure QoS, reduce call setup time for Wireless multimedia calls, simplify the implementation of billing systems, and improve the overall system capacity and performance; an extension to existing RSVP protocol is introduced herein. The bi-directional-RSVP (B-RSVP) is a rather generalized form of the current RSVP protocol [RFC 2205, RFC 2210]. B-RSVP expands on RSVP uni- directional reservation capabilities in the 'send' direction by extending the reservation capabilities to 'receive' direction and to bi- directional reservation (i.e., 'send receive' directions). The main concept of B-RSVP is based existing circuit switching telephony operation. The originator side of a phone call (multi-media session) is responsible of establishing the call, making the necessary reservations, monitoring the status of the call, and the billing for the call. Moreover, the originator will be immediately notified if the resources necessary to carry out the call were not available (busy tone or announcement). This approach will provide more efficient, faster, and more reliable multi-media session establishment procedures [23.207, 23.228, 24.228]. The uni-directional RSVP requires both end points to establish the resources necessary to carry a bi-directional communication services using uni-directional mechanism. This will result in a longer set up time, asynchronous reservation procedures (where resources for one direction may be allocated while resources for the other direction are not), and excessive per call RSVP messaging on the network. This document provides the information required to use the bi- directional RSVP and the integrated service framework's QoS control services together. It expands the usage and contents of three of the existing RSVP protocol objects [RFC 2210], the FLOWSPEC, ADSPEC, and Shaheen Standard Track - Expires June 2002 2 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet 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 Bi-Directional RSVP The underline assumption is that both the originator of a multimedia session negotiates the media information with the terminated side. Both sides have to agree on the means by which the session will be carried, including the type of service (audio, video, or/and text), codec information, bit rate for both directions, port number, ...etc [RFC 2543][23.228, 24.228]. In order to allocate resources for the negotiated session, several types of data must be transported between applications and network elements to correctly invoke QoS control services. The originator of the multimedia session is responsible for invoking these data, which includes: - Information generated at the originator describing the data traffic generated (the Sender TSpec). This information is carried from the originator to intermediate network elements and the terminated end point(s) by B-RSVP, but is never modified by intermediate elements within the network. This information is carried in B-RSVP SENDER_TSPEC objects. - Information generated or modified within the network and used at the terminated end points 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 terminated end points in B-RSVP ADSPEC objects. Rather than carrying information from each intermediate node separately to the terminated end points, 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. - Information generated by each terminated end point 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 terminated end points to intermediate network elements and the originator(s) by B-RSVP FLOWSPEC objects. The information being carried in a Shaheen Standard Track - Expires June 2002 3 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet FLOWSPEC object may change at intermediate points in the network due to reservation merging and other factors. From the point of view of B-RSVP objects, the breakdown is as follows: - The B-RSVP SENDER_TSPEC object carries the traffic specification (sender TSpec) generated by originator end point. It is transported unchanged through the network, and delivered to both intermediate nodes and terminated end points' applications. - The B-RSVP ADSPEC object carries information which is generated at either the originator end points or intermediate network elements, is flowing downstream towards terminated end points, and may be used and updated inside the network before being delivered to applications of the terminated end points. This information includes both parameters describing the properties of the data path (unidirectional or bi- directional), including the availability of specific QoS control services, and parameters required by specific QoS control services to operate correctly. - The B-RSVP FLOWSPEC object carries reservation request (Receiver_TSpec and RSpec) information generated by terminated end points. The information in the FLOWSPEC flows upstream towards the originator end point(s). It may be used or updated at intermediate network elements before arriving at the application of the originating end point(s). 2.1 Summary of operation Operation proceeds as follows: An application instance participating in an B-RSVP session as a data originator registers with B-RSVP. One piece of information provided by the application instance is the Sender TSpec describing the traffic (uni-directional or bi-directional) the application expects to generate. This information is used to construct an B-RSVP SENDER_TSPEC object, which is included in B-RSVP PATH messages generated for the application. The originating application also constructs an initial B-RSVP ADSPEC object. This adspec carries information about the QoS control capabilities and requirements of the originating application itself, and forms the starting point for the accumulation of path properties described below. The ADSPEC is added to the B-RSVP PATH message created at the originator end point. Shaheen Standard Track - Expires June 2002 4 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet Typically the default ADSPEC supplied by the host B-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 B-RSVP PATH message moves from originator to terminated end point(s). At each network element, the ADSPEC is passed from B-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 terminated end point. The updated ADSPEC is then returned to B-RSVP for delivery to the next hop along the path. Upon arrival of the PATH message at an application of terminated end point, the data in the SENDER_TSPEC and ADSPEC objects is passed across the B-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 at the terminated end point wishing to make a resource reservation supplies its local B-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 B-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 existing 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. Shaheen Standard Track - Expires June 2002 5 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet 2.2. B-RSVP support for multiple QoS control services The design described in this note supports B-RSVP sessions in which the receivers choose a QoS control service at runtime. The terminated end point must have all related information, during session establishment phase, needed to choose a particular service before it makes the choice. This means that the B-RSVP SENDER_TSPEC and ADSPEC objects must provide the terminated 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 B-RSVP SENDER_TSPEC object, which need to 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. The B-RSVP ADSPEC carries information needed by terminated end point to choose a service and determine the reservation parameters as listed in [RFC 2210]: - Whether or not there is a non-RSVP/non-B-RSVP hop along the path. If there is a non-RSVP/non-B-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 Shaheen Standard Track - Expires June 2002 6 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet 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. 2.3. Use of ADSPEC Information The same procedures are used to determine the availability of a QoS control service and to determine Path MTU as in [RFC 2210] 3. B_RSVP Object Formats This section specifies the detailed contents and wire format of B-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 [RFC 2210]. 3.1. B-RSVP SENDER_TSPEC Object The B-RSVP SENDER_TSPEC object carries information about a data source's generated traffic. The required B-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. 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | (a) | reserved | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 1 (c) |0| reserved | 6 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 |Token Bucket Rate [rs] (IEEE floating point number) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 |Token Bucket Size [bs] (IEEE floating point number) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [ps] (IEEE floating point number) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [ms] (32-bit integer) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Shaheen Standard Track - Expires June 2002 7 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet 8 | Maximum Packet Size [Ms] (32-bit integer) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Token Bucket Rate [rr] (IEEE floating point number) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Token Bucket Size [br] (IEEE floating point number) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Peak Data Rate [pr] (IEEE floating point number) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Minimum Policed Unit [mr] (32-bit integer) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13 | Maximum Packet Size [Mr] (32-bit integer) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) - Message format version number (0000: Existing RSVP "Send", 0011:B-RSVP "Receive", 1111 B-RSVP "Send Receive") (b) - Overall length (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 [rs], [rr], [rs], and [br] are set to reflect views of the originator's of its generated traffic in both directions (send and receive). The peak rate parameters [ps] and [pr] may be set to the Originator's peak traffic generation rate in the send and receive directions, respectively (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 parameters [ms] and [mr] should generally be set equal to the size of the smallest packet in both directions (send/received 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. The [m] parameter (either [ms] or [mr]) 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 Shaheen Standard Track - Expires June 2002 8 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet 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 likelihood 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 likelihood 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] (either [Ms] or [Mr]) should be set to the size of the largest packet the application might wish to send or receive, as described in Section 2.3.2. This value must, by definition, be equal to or larger than the value of [m]. 3.2. B-RSVP FLOWSPEC Object The B-RSVP FLOWSPEC object carries information necessary to make reservation requests from the terminated end point(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. 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | (a) | reserved | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 5 (c) |0| reserved | 6 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | Shaheen Standard Track - Expires June 2002 9 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 |Token Bucket Rate [rs] (IEEE floating point number) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 |Token Bucket Size [bs] (IEEE floating point number) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [ps] (IEEE floating point number) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [ms] (32-bit integer) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [Ms] (32-bit integer) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Token Bucket Rate [rr] (IEEE floating point number) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Token Bucket Size [br] (IEEE floating point number) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Peak Data Rate [pr] (IEEE floating point number) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Minimum Policed Unit [mr] (32-bit integer) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13 | Maximum Packet Size [Mr] (32-bit integer) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) - Message format version number (0000: Existing RSVP "Send", 0011:B-RSVP "Receive", 1111 B-RSVP "Send Receive") (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 bi-directional (send and receive) traffic parameters of the terminated end point'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] (either Ms or Mr) should be set to the bi-directional values of the smallest path MTU (i.e., MTU send and MTU receive) , which the terminated end point learns from information in arriving B-RSVP ADSPEC objects. Alternatively, if the Shaheen Standard Track - Expires June 2002 10 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet terminated end point application has built-in knowledge of the bi- directional maximum packet size in use within the B-RSVP session, and this bi-directional value is smaller than the smallest path MTU (MTUs and MTUr), [M] (Ms and Mr) 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. The value of [m] (ms and mr) can be chosen in several ways. Recall that when a bi-directional/unidirectional 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 originator's SENDER_TSPEC. If the application has a fixed, known minimum packet sizes for both directions/uni-directional, than that values 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 terminated end point chooses a large value for [m] (ms and/or mr), then the reservation will allocate less overhead for link-level headers. However, if a new originator with a smaller SENDER_TSPEC [m] joins the session later, an already-installed reservation may fail at that time. - if the terminated end point chooses a value of [m] (ms and/or mr) equal to the smallest value which might be used by any originator, then the reservation will be forced to allocate more overhead for link-level headers. However it will not fail later if a new originator with a smaller SENDER_TSPEC [m] joins the session. For a FF reservation style, if no application-specific value is known the terminated end point should simply use the value of [m] arriving in each originator's SENDER_TSPEC for its reservation request to that originator. 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. Shaheen Standard Track - Expires June 2002 11 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet 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. 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | (a) | Unused | 10 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 2 (c) |0| reserved | 9 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 |Token Bucket Rate [rs] (IEEE floating point number) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 |Token Bucket Size [bs] (IEEE floating point number) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [ps] (IEEE floating point number) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [ms] (32-bit integer) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [Ms] (32-bit integer) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Token Bucket Rate [rr] (IEEE floating point number) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Token Bucket Size [br] (IEEE floating point number) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Peak Data Rate [pr] (IEEE floating point number) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Minimum Policed Unit [mr] (32-bit integer) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13 | Maximum Packet Size [Mr] (32-bit integer) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | 130 (h) | 0 (i) | 2 (j) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 15 | Rate [Rs] (32-bit IEEE floating point number) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | Slack Term [Ss] (32-bit integer) "Send" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 17 | Rate [Rr] (32-bit IEEE floating point number) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 18 | Slack Term [Sr] (32-bit integer) "Receive" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Shaheen Standard Track - Expires June 2002 12 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet (a) - Message format version number Message format version number (0000: Existing RSVP "Send", 0011:B-RSVP "Receive", 1111 B-RSVP "Send Receive") (b) - Overall length (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 bi-directional/uni-directional traffic parameters of the terminated end point'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 in both directions (send and receive). This selection is described in [RFC 2212]. The [m] and [M] parameters (n both directions: ms, mr, Ms, and Mr) are set identically to those for the Controlled-Load service FLOWSPEC, described in the previous section. 3.3. B-RSVP ADSPEC Object An B-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 terminated end points. 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 originator 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 Shaheen Standard Track - Expires June 2002 13 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet application at the terminated end points 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 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 always 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. 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. B-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 B-RSVP session. Additional data fragments will be added if new services are defined. 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (a) | reserved | Msg length - 1 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Shaheen Standard Track - Expires June 2002 14 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet | 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 Message format version number (0000: Existing RSVP "Send", 0011:B-RSVP "Receive", 1111 B-RSVP "Send Receive") (b) - Overall message length not including header word (c, d, e) - Data fragments 3.3.2. Default General Characterization Parameters ADSPEC data fragment All B-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. 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 | Send Path b/w estimate (IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Receive Path b/w estimate (IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | 8 (k) | (l) | 1 (m) | Shaheen Standard Track - Expires June 2002 15 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Send Minimum path latency (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Receive Minimum path latency (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | 10 (n) | (o) | 1 (p) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Send Composed MTU (32-bit unsigned integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Receive 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 B-RSVP, RSVP, or integrated services is encountered. An ADSPEC arriving at a terminated end point 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. Shaheen Standard Track - Expires June 2002 16 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet The general parameters are updated at every network node which supports B-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 B-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 B-RSVP, but has been made aware of the gap in integrated services coverage. - In either case, the ADSPEC is passed back to B-RSVP for delivery to the next hop along the path. 3.3.3. Guaranteed Service ADSPEC data fragment The Guaranteed service uses the B-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: 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 Cs [Cs-tot] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | End-to-end composed value for Cr [Cr-tot] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | 134 (f) | (g) | 1 (h) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | End-to-end composed value for Ds [Ds-tot] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | End-to-end composed value for Dr [Dr-tot] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | 135 (i) | (j) | 1 (k) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Since-last-reshaping point composed Cs [Cs-sum] (32-bit integer) | Shaheen Standard Track - Expires June 2002 17 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Since-last-reshaping point composed Cr [Cr-sum] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | 136 (l) | (m) | 1 (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Since-last-reshaping point composed Ds [Ds-sum] (integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13 | Since-last-reshaping point composed Dr [Dr-sum] (integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | 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: Cs-tot send direction, Cr-tot receive direction) (d) - Parameter 133 flag byte (e) - Parameter 133 length, 1 word not including header (f) - Parameter ID, parameter 134 (Composed Dtot: Ds-tot send direction, Dr-tot receive direction)) (g) - Parameter 134 flag byte (h) - Parameter 134 length, 1 word not including header (i) - Parameter ID, parameter 135 (Composed Csum: Cs-sum send direction, Cr-sum receive direction)). (j) - Parameter 135 flag byte (k) - Parameter 135 length, 1 word not including header (l) - Parameter ID, parameter 136 (Composed Dsum: Ds-sum send direction, Dr-sum receive direction)). (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 element which does not itself implement guaranteed service creates a guaranteed service adspec fragment, it should set the values of each parameter to Shaheen Standard Track - Expires June 2002 18 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet zero, and set the break bit to indicate that the service is not actually implemented at the node. An application or host B-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 originating 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 the bi-directional 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 bi-directional 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]. - When a PATH message ADSPEC with a Guaranteed service header encounters a network element that supports B-RSVP but does *not* Shaheen Standard Track - Expires June 2002 19 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet 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 B-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 B-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. The Controlled-Load portion of the ADSPEC is processed according to the following rules: Shaheen Standard Track - Expires June 2002 20 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet - 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 B-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 B-RSVP for delivery to the next hop along the path. 4. References [RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Service" - RFC 2210, September 1997. [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. Shaheen Standard Track - Expires June 2002 21 The Use of Bi-Directional RSVP December 2001 in the Wireless Internet 5. Contact Information Kamel M. Shaheen InterDigital 781 Third Ave. Phone: 1-610-878-5727 King of Prussia, PA. USA Email: kamel.shaheen@interdigital.com Sharif M. Shahrier InterDigital 781 Third Ave. Phone: 1-610-337-4343 King of Prussia, PA. USA Email: sharif.shahrier@interdigital.com Shaheen Standard Track - Expires June 2002 22