Internet Draft R. Braden, Ed. Expiration: May 1996 ISI File: draft-ietf-rsvp-spec-08.txt L. Zhang PARC S. Berson ISI S. Herzog ISI J. Wroclaswki MIT Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification November 22, 1995 Status of Memo This document is an Internet-Draft. 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 obsoleted 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." To learn the current status of any Internet-Draft, please check the linebreak "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. Braden, Zhang, et al. Expiration: May 1996 [Page 1] Internet Draft RSVP Specification November 1995 Table of Contents 1. Introduction ........................................................5 1.1 Data Flows ......................................................8 1.2 Reservation Model ...............................................9 1.3 Reservation Styles ..............................................11 1.4 Examples of Styles ..............................................14 2. RSVP Protocol Mechanisms ............................................18 2.1 RSVP Messages ...................................................18 2.2 Port Usage ......................................................20 2.3 Merging Flowspecs ...............................................21 2.4 Soft State ......................................................22 2.5 Teardown ........................................................24 2.6 Errors and Acknowledgments ......................................25 2.7 Policy and Security .............................................27 2.8 Automatic RSVP Tunneling ........................................28 2.9 Host Model ......................................................28 3. RSVP Functional Specification .......................................30 3.1 RSVP Message Formats ............................................30 3.2 Sending RSVP Messages ...........................................42 3.3 Avoiding RSVP Message Loops .....................................44 3.4 Local Repair ....................................................48 3.5 Time Parameters .................................................48 3.6 Traffic Policing and TTL ........................................50 3.7 Multihomed Hosts ................................................51 3.8 Future Compatibility ............................................52 3.9 RSVP Interfaces .................................................55 4. Message Processing Rules ............................................65 APPENDIX A. Object Definitions .........................................82 APPENDIX B. Error Codes and Values .....................................97 APPENDIX C. UDP Encapsulation ..........................................101 APPENDIX D. Experimental and Open Issues ...............................103 Braden, Zhang, et al. Expiration: May 1996 [Page 2] Internet Draft RSVP Specification November 1995 What's Changed The most important changes in this document from the rsvp-spec-07 draft are: o The role and interpretation of the IP Protocol Id is changed. The Protocol Id is now a required part of the session definition, and filter specs and sender templates now assume the Protocol Id from the session rather than stating it explicitly. o A "soft" reservation confirmation message is added. o The text states explicitly that an erroneous reservation message is not forwarded. A mechanism to allow a receiver more flexible control over forwarding of its messages after an admission control failure has not been designed and is therefore not included in this version of the protocol. o A terminology confusion is eliminated. The term "scope" was used both for a set of senders and for a set of sender hosts. A new term "sender selection" is introduced for the first, leaving "scope" for the second. o The FILTER_SPEC object is dropped from a wildcard sender selection (WF) style reservation, which now selects "all senders" without qualification. o The StyleID byte is dropped from a STYLE object, as redundant. o An SE style flow descriptor is simplified to a single flowspec. o The IP Router Alert option is now required in PATH, PTEAR, and RACK messages. o The TIME_VALUES object is now required in RESV and PATH messages; there is no default. o Policing at branch points is now defined in a new section on policing (3.6). o A 2-second delay is inserted into local repair. o Merging of SE with WF objects is no longer allowed. Braden, Zhang, et al. Expiration: May 1996 [Page 3] Internet Draft RSVP Specification November 1995 o The Rmax end-to-end bound on the refresh rate R is removed, since its utility was unclear. o A rule for randomizing refresh timeouts is included. o The suggestion that TCP could be used for carrying RSVP state through a congested non-RSVP cloud is removed. o SENDER_TSPECS are now required in PATH| messages. o There are new sections on multihomed hosts (3.7) and future compatibility (3.8). The latter section makes clear that a message containing an object with unknown C-Type should be rejected. Any more forgiving treatment seems too complex. o Appendix C on UDP encapsulation is completely changed. o Some text was rearranged in Sections 1 and 2. Braden, Zhang, et al. Expiration: May 1996 [Page 4] Internet Draft RSVP Specification November 1995 1. Introduction This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet [RSVP93,ISInt93]. On behalf of an application data stream, a host uses the RSVP protocol to request a specific quality of service (QoS) from the network. RSVP delivers QoS requests to routers along the path(s) of the data stream and maintains router and host state to provide the requested service. RSVP requests will generally, although not necessarily, result in resources being reserved along the data path. RSVP requests resources for simplex data streams, i.e., it requests resources in only one direction. Therefore, a sender is logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IP (either IPv4 or IP6), occupying the place of a transport protocol in the protocol stack. However, like ICMP, IGMP, and routing protocols, RSVP does not transport application data but is rather an Internet control protocol. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1. RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. The RSVP daemon consults the local routing protocol(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP only concerns with the QoS of those packets that are forwarded by routing. Braden, Zhang, et al. Expiration: May 1996 [Page 5] Internet Draft RSVP Specification November 1995 HOST ROUTER _________________________ RSVP _____________________________ | | .--------------. | | _______ ______ | / | ________ . ______ | | | | | | | / || | . | | | RSVP | |Applic-| | RSVP <----/ ||Routing | -> RSVP <----------> | | App <----->daemon| | ||Protocol| |daemon| | | | | | | | || daemon <----> | | | |_______| |___.__| | ||_ ._____| |__.__.| | | | | | | | | . | |===|===============|=====| |===|=============|====.======| | data .........| | | | ...........| .____ | | | ____V_ ____V____ | | _V__V_ _____V___ | Adm.|| | | |Class-| | || data | |Class-| | ||Cntrl|| | |=> ifier|=> Packet ============> ifier|==> Packet ||_____|| data | |______| |Scheduler|| | |______| |Scheduler|===========> | |_________|| | |_________| | |_________________________| |_____________________________| Figure 1: RSVP in Hosts and Routers Each router that is capable of resource reservation passes incoming data packets through a packet classifier and then queues them as necessary in a packet scheduler. The packet classifier determines the route and the QoS class for each packet. There is a scheduler for each interface, to allocate resources for transmission on the particular link-layer medium used by that interface. If the link- layer medium is QoS-active, i.e., if it has its own QoS management capability, then the packet scheduler is responsible for negotiation with the link layer to obtain the QoS requested by RSVP. This mapping to the link layer QoS may be accomplished in a number of possible ways; the details will be medium-dependent. On a QoS- passive medium such as a leased line, the scheduler itself allocates packet transmission capacity. The scheduler may also allocate other system resources such as CPU time or buffers. In order to efficiently accommodate heterogeneous receivers and dynamic group membership, RSVP makes receivers responsible for requesting resource reservations [RSVP93]. A QoS request, which typically originates from a receiver host application, is passed to the local RSVP implementation, shown as a user daemon in Figure 1. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s). At each node, the RSVP daemon communicates with a local decision Braden, Zhang, et al. Expiration: May 1996 [Page 6] Internet Draft RSVP Specification November 1995 module, called "admission control", to determine if the router can supply the requested QoS. If the admission control check succeeds, the RSVP daemon sets parameters in the packet classifier and scheduler to obtain the desired QoS. If the admission control check fails, the RSVP program immediately returns an error notification to the application process that originated the request. We refer to the packet classifier, packet scheduler, and admission control components as " traffic control". RSVP is designed to scale well for very large multicast groups. Since both the membership of a large group and the topology of large multicast trees are likely to change with time, the RSVP design assumes that router state for traffic control will be built and destroyed incrementally. For this purpose, RSVP uses "soft state" in the routers. That is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s); in absence of refreshes, the state will automatically time out and be deleted. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP transfers reservation parameters as opaque data (except for certain well-defined operations on the data), which it simply passes to traffic control for interpretation. Although the RSVP protocol mechanisms are largely independent of the encoding of these parameters, the encodings must be defined in the reservation model that is presented to an application; see Appendix A for more details. In summary, RSVP has the following attributes: o RSVP makes resource reservations for both unicast and many-to- many multicast applications, adapting dynamically to changing group membership as well as changing routes. o RSVP is simplex, i.e., it reserves for data flow in one direction only. o RSVP is receiver-oriented, i.e., the receiver of a data flow initiates and maintains the resource reservation used for that flow. o RSVP maintains "soft state" in the routers, providing graceful support for dynamic membership changes and automatic adaptation to routing changes. o RSVP provides several reservation models or "styles" (defined below) to fit a variety of applications. Braden, Zhang, et al. Expiration: May 1996 [Page 7] Internet Draft RSVP Specification November 1995 o RSVP provides transparent operation through routers that do not support it. Further discussion on the objectives and general justification for RSVP design are presented in [RSVP93,ISInt93]. The remainder of this section describes the RSVP reservation services. Section 2 presents an overview of the RSVP protocol mechanisms. Section 3 contains the functional specification of RSVP, while Section 4 presents explicit message processing rules. Appendix A defines the variable-length typed data objects used in the RSVP protocol. Appendix B defines error codes and values. Appendix C defines an extension for UDP encapsulation of RSVP messages. Finally, some experimental RSVP features are documented in Appendix D for future reference. 1.1 Data Flows RSVP defines a "session" as a data flow with a particular destination and transport-layer protocol. The destination for a particular session is generally defined by DestAddress, the IP destination address of the data packets, and perhaps by DstPort, a " generalized destination port", i.e., some further demultiplexing point in the transport or application protocol layer. RSVP treats each session independently, and this document often assumes the qualification "for the same session". DestAddress is a group address for multicast delivery or the unicast address of a single receiver. DstPort could be defined by a UDP/TCP destination port field, by an equivalent field in another transport protocol, or by some application-specific information. Although the RSVP protocol is designed to be easily extendible for greater generality, the present version supports only UDP/TCP ports as generalized ports. Figure 2 illustrates the flow of data packets in a single RSVP session assuming multicast data distribution. The arrows indicate data flowing from senders S1 and S2 to receivers R1, R2, and R3, and the cloud represents the distribution mesh created by multicast routing. Multicast distribution forwards a copy of each data packet from a sender Si to every receiver Rj; a unicast distribution session has a single receiver R. Each sender Si and each receiver Rj may be running in a unique Internet host, or a single host may contain multiple senders and/or receivers, distinguished by generalized ports. Braden, Zhang, et al. Expiration: May 1996 [Page 8] Internet Draft RSVP Specification November 1995 Senders Receivers _____________________ ( ) ===> R1 S1 ===> ( Multicast ) ( ) ===> R2 ( distribution ) S2 ===> ( ) ( by Internet ) ===> R3 (_____________________) Figure 2: Multicast Distribution Session For unicast transmission, there will be a single destination host but there may be multiple senders; RSVP can set up reservations for multipoint-to-single-point transmission. 1.2 Reservation Model An elementary RSVP reservation request consists of a "flowspec" together with a "filter spec"; this pair is called a "flow descriptor". The flowspec specifies a desired QoS. The filter spec, together with session definition, specifies the set of data packets -- the "flow" -- to receive the QoS defined by the flowspec. The flowspec is used to set parameters to the node's packet scheduler (assuming that admission control succeeds), while the filter spec is used to set parameters in the packet classifier. Data packets that are addressed to a particular session but do not match any of the filter specs for that session are handled as best-effort traffic. Note that the action to control QoS occurs at the place where the data enters the medium, i.e., at the upstream end of the link, although an RSVP reservation request originates from receiver(s) downstream. In this document, we define the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flows. The flowspec in a reservation request will generally include a service class and two sets of numeric parameters: (1) an "Rspec" (R for `reserve') that defines the desired QoS, and (2) a "Tspec" (T for `traffic') that describes the data flow. The formats and contents of Tspecs and Rspecs are determined by the integrated service model [ServTempl95a], and are generally opaque to RSVP. Braden, Zhang, et al. Expiration: May 1996 [Page 9] Internet Draft RSVP Specification November 1995 In the most general approach [RSVP93], filter specs may select arbitrary subsets of the packets in a given session. Such subsets might be defined in terms of senders (i.e., sender IP address and generalized source port), in terms of a higher-level protocol, or generally in terms of any fields in any protocol headers in the packet. For example, filter specs might be used to select different subflows in a hierarchically-encoded signal by selecting on fields in an application-layer header. However, in the interest of simplicity (and to minimize layer violation), the present RSVP version uses a much more restricted form of filter spec, consisting of sender IP address and optionally the UDP/TCP port number SrcPort. RSVP reservation request messages originate at receivers and are passed upstream towards the sender(s). When a reservation request is received at a node, two general actions are taken. 1. Make a reservation The flowspec and the filter spec are passed to traffic control. Admission control determines the admissibility of the request (if it's new); if this test fails, the reservation is rejected and RSVP returns an error message to the appropriate receiver(s). If admission control succeeds, the node uses the flowspec to set up the packet scheduler for the desired QoS and the filter spec to set the packet classifier to select the appropriate data packets. 2. Forward the request upstream The reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. First, it is possible in theory for the traffic control mechanism to modify the flowspec hop-by-hop, although none of the currently defined services does so. Second, reservations for the same sender, or the same set of senders, from different downstream branches of the multicast tree(s) are "merged" as reservations travel upstream; that is, a node forwards upstream only the reservation request with the "maximum" flowspec. When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. A successful reservation Braden, Zhang, et al. Expiration: May 1996 [Page 10] Internet Draft RSVP Specification November 1995 request propagates as far as the closest point(s) along the sink tree to the sender(s) where there is an existing reservation level equal or greater than that being requested. At that point, the arriving request will be dropped in favor of the equal or larger reservation in place; the node may then send a reservation confirmation message back to the receiver. Note that the receipt of a confirmation is only a high-probability indication, not a guarantee that the requested service is in place all the way to the sender(s), as explained in Section 2.6. The basic RSVP reservation model is "one pass": a receiver sends a reservation request upstream, and each node in the path either accepts or rejects the request. This scheme provides no easy way for a receiver to find out the resulting end-to-end service. Therefore, RSVP supports an enhancement to one-pass service known as "One Pass With Advertising" (OPWA) [Shenker94]. With OPWA, RSVP control packets are sent downstream, following the data paths, to gather information that may be used to predict the end- to-end QoS. The results ("advertisements") are delivered by RSVP to the receiver hosts and perhaps to the receiver applications. The advertisements may then be used by the receiver to construct, or to dynamically adjust, an appropriate reservation request. 1.3 Reservation Styles A reservation request includes a set of control options, which are collectively called the reservation "style". One option concerns the treatment of reservations for different senders within the same session: establish a "distinct" reservation for each upstream sender, or else make a single reservation that is " shared" among all packets of selected senders. Another option controls the selection of senders: an "explicit" list of all selected senders, or a "wildcard" that implicitly selects all the senders to the session. In an explicit-selection reservation, each filter spec must match exactly one sender, while in a wildcard-selection no filter spec is needed. Braden, Zhang, et al. Expiration: May 1996 [Page 11] Internet Draft RSVP Specification November 1995 Sender || Reservations: Selection || Distinct | Shared _________||__________________|____________________ || | | Explicit || Fixed-Filter | Shared-Explicit | || (FF) style | (SE) Style | __________||__________________|____________________| || | | Wildcard || (None defined) | Wildcard-Filter | || | (WF) Style | __________||__________________|____________________| Figure 3: Reservation Attributes and Styles The styles currently defined are as follows (see Figure 3): o Wildcard-Filter (WF) Style The WF style implies the options: "shared" reservation and " wildcard" sender selection. Thus, a WF-style reservation creates a single reservation into which flows from all upstream senders are mixed; this reservation may be thought of as a shared "pipe", whose "size" is the largest of the resource requests from all receivers, independent of the number of senders using it. A WF-style reservation is propagated upstream towards all sender hosts, and automatically extends to new senders as they appear. Symbolically, we can represent a WF-style reservation request by: WF( * {Q}) where the asterisk represents wildcard sender selection and Q represents the flowspec. o Fixed-Filter (FF) Style The FF style implies the options: "distinct" reservations and "explicit" sender selection. Thus, an elementary FF-style reservation request creates a distinct reservation for data packets from a particular sender, not sharing them with other senders' packets for the same session. Braden, Zhang, et al. Expiration: May 1996 [Page 12] Internet Draft RSVP Specification November 1995 The total reservation on a link for a given session is the total of the FF reservations for all requested senders. On the other hand, FF reservations requested by different receivers Rj but selecting the same sender Si must be merged to share a single reservation. Symbolically, we can represent an elementary FF reservation request by: FF( S{Q}) where S is the selected sender and Q is the corresponding flowspec; the pair forms a flow descriptor. RSVP allows multiple elementary FF-style reservations to be requested at the same time, using a list of flow descriptors: FF( S1{Q1}, S2{Q2}, ...) o Shared Explicit (SE) Style The SE style implies the options: "shared" reservation and " explicit" sender selection. Thus, an SE-style reservation creates a single reservation into which flows from all upstream senders are mixed. However, like the FF style, the SE style allows a receiver to explicitly specify the set of senders. Symbolically, we can represent an SE reservation request by: SE( (S1,S2,...){Q} ), i.e., a flow descriptor composed of a flowspec Q and a list of senders S1, S2, etc. Both WF and SE are shared reservations, appropriate for those multicast applications whose application-specific constraints make it unlikely that multiple data sources will transmit simultaneously. Packetized audio is an example of an application suitable for shared reservations; since a limited number of people talk at once, each receiver might issue a WF or SE reservation request for twice the bandwidth required for one sender (to allow some over-speaking). On the other hand, the FF style, which creates independent reservations for the flows from different senders, is appropriate for video signals. Braden, Zhang, et al. Expiration: May 1996 [Page 13] Internet Draft RSVP Specification November 1995 The RSVP rules disallow merging of shared reservations with distinct reservations, since these modes are fundamentally incompatible. They also disallow merging explict sender selection with wildcard sender selection, since this might produce an unexpected service for a receiver that specified explicit selection. As a result of these prohibitions, WF, SE, and FF styles are all mutually incompatible. Other reservation options and styles may be defined in the future (see Appendix D.4, for example). 1.4 Examples of Styles This section presents examples of each of the reservation styles and show the effects of merging. Figure 4 shows schematically a router with two incoming interfaces through which data streams will arrive, labeled (a) and (b), and two outgoing interfaces through which data will be forwarded, labeled (c) and (d). This topology will be assumed in the examples that follow. There are three upstream senders; packets from sender S1 (S2 and S3) arrive through previous hop (a) ((b), respectively). There are also three downstream receivers; packets bound for R1 (R2 and R3) are routed via outgoing interface (c) ((d), respectively). We furthermore assume that R2 and R3 arrive via different next hops, e.g., via the two routers D and D' in Figure 9. This illustrates the effect of a non-RSVP cloud or a broadcast LAN on interface (d). In addition to the connectivity shown in 4, we must also specify the multicast routes within this node. Assume first that data packets from each Si shown in Figure 4 is routed to both outgoing interfaces. Under this assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter, Fixed-Filter, and Shared-Explicit reservations, respectively. ________________ (a)| | (c) ( S1 ) ---------->| |----------> ( R1 ) | Router | (b)| | (d) ( S2,S3 ) ------->| |----------> ( R2, R3 ) |________________| Figure 4: Router Configuration Braden, Zhang, et al. Expiration: May 1996 [Page 14] Internet Draft RSVP Specification November 1995 For simplicity, these examples show flowspecs as one-dimensional multiples of some base resource quantity B. The "Receive" column shows the RSVP reservation requests received over outgoing interfaces (c) and (d), and the "Reserve" column shows the resulting reservation state for each interface. The "Send" column shows the reservation requests that are sent upstream to previous hops (a) and (b). In the "Reserve" column, each box represents one reserved "pipe" on the outgoing link, with the corresponding flow descriptor. Figure 5, showing the WF style, illustrates the two possible merging situations. Each of the two next hops on interface (d) results in a separate RSVP reservation request, as shown. These two requests are merged into the effective flowspec 3B, which is used to make the reservation on interface (d). To forward the reservation requests upstream, the reservations on the interfaces (c) and (d) are merged; as a result, the larger flowspec 4B is forwarded upstream to each previous hop. | Send | Reserve Receive | | _______ WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) | |_______| | -----------------------|---------------------------------------- | _______ WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) | |_______| <- WF( *{2B} ) Figure 5: Wildcard-Filter (WF) Reservation Example Figure 6 shows Fixed-Filter (FF) style reservations. The flow descriptors for senders S2 and S3, received from outgoing interfaces (c) and (d), are packed into the request forwarded to previous hop (b). On the other hand, the three different flow descriptors for sender S1 are merged into the single request FF( S1{4B} ), which is sent to previous hop (a). For each outgoing interface, there is a separate reservation for each source that has been requested, but this reservation is shared among all the receivers that made the request. Braden, Zhang, et al. Expiration: May 1996 [Page 15] Internet Draft RSVP Specification November 1995 | Send | Reserve Receive | | ________ FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} ) | |________| | | S2{5B} | | |________| ---------------------|--------------------------------------------- | ________ <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} ) | | S3{B} | | |________| Figure 6: Fixed-Filter (FF) Reservation Example Figure 7 shows an example of Shared-Explicit (SE) style reservations. When SE-style reservations are merged, the resulting filter spec is the union of the original filter specs. | Send | Reserve Receive | | ________ SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} ) | | {B} | | |________| ---------------------|--------------------------------------------- | __________ <- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} ) SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} ) | |__________| Figure 7: Shared-Explicit (SE) Reservation Example The three examples just shown assume that data packets from S1, S2, and S3 are routed to both outgoing interfaces. The top part of Figure 8 shows another routing assumption: data packets from S2 and S3 are not forwarded to interface (c), e.g., because the network topology provides a shorter path for these senders towards R1, not traversing this node. The bottom part of Figure 8 shows Braden, Zhang, et al. Expiration: May 1996 [Page 16] Internet Draft RSVP Specification November 1995 WF style reservations under this assumption. Since there is no route from (b) to (c), the reservation forwarded out interface (b) considers only the reservation on interface (d). _______________ (a)| | (c) ( S1 ) ---------->| >-----------> |----------> ( R1 ) | - | | - | (b)| - | (d) ( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 ) |_______________| Router Configuration | Send | Reserve Receive | | _______ WF( *{rB} ) <- (a) | (c) | * {B} | (c) <- WF( *{4B} ) | |_______| | -----------------------|---------------------------------------- | _______ WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) | |_______| <- WF( * {2B} Figure 8: WF Reservation Example -- Partial Routing Braden, Zhang, et al. Expiration: May 1996 [Page 17] Internet Draft RSVP Specification November 1995 2. RSVP Protocol Mechanisms 2.1 RSVP Messages Previous Incoming Outgoing Next Hops Interfaces Interfaces Hops _____ _____________________ _____ | | data --> | | data --> | | | A |-----------| a c |--------------| C | |_____| Path --> | | Path --> |_____| <-- Resv | | <-- Resv _____ _____ | ROUTER | | | | | | | | | |--| D | | B |--| data-->| | data --> | |_____| |_____| |--------| b d |-----------| | Path-->| | Path --> | _____ _____ | <--Resv|_____________________| <-- Resv | | | | | | |--| D' | | B' |--| | |_____| |_____| | | Figure 9: Router Using RSVP Figure 9 illustrates RSVP's model of a router node. Each data stream arrives from a "previous hop" through a corresponding "incoming interface" and departs through one or more "outgoing interface(s)". The same physical interface may act in both the incoming and outgoing roles for different data flows in the same session. Multiple previous hops and/or next hops may be reached through a given physical interface, as a result of the connected network being a shared medium, or the existence of non-RSVP routers in the path to the next RSVP hop (see Section 2.8). An RSVP daemon preserves the next and previous hop addresses in its reservation and path state, respectively. There are two fundamental RSVP message types: RESV and PATH. Each receiver host sends RSVP reservation request (RESV) messages upstream towards the senders. These reservation messages must follow exactly the reverse of the routes the data packets will use, upstream to all the sender hosts included in the sender selection. RESV messages must be delivered to the sender hosts themselves so that the hosts can set up appropriate traffic control parameters for the first hop. Braden, Zhang, et al. Expiration: May 1996 [Page 18] Internet Draft RSVP Specification November 1995 Each RSVP sender host transmits RSVP PATH messages downstream along the uni-/multicast routes provided by the routing protocol(s), following the paths of the data. These "Path" messages store " path state" in each node along the way. This path state includes at least the unicast IP address of the previous hop node, which is used to route the RESV messages hop- by-hop in the reverse direction. (In the future, some routing protocols may supply reverse path forwarding information directly, replacing the reverse-routing function of path state). A PATH message may carry the following information in addition to the previous hop address: o Sender Template A PATH message is required to carry a Sender Template, which describes the format of data packets that the sender will originate. This template is in the form of a filter spec that could be used to select this sender's packets from others in the same session on the same link. Like a filter spec, the Sender Template is less than fully general at present, specifying only the sender IP address and optionally the UDP/TCP sender port. It assumes the protocol Id for the session. o Sender Tspec A PATH message is required to carry a Sender Tspec, which defines the traffic characteristics of the data stream that the sender will generate. This Tspec is used by traffic control to prevent over-reservation (and perhaps unnecessary Admission Control failure) on all links on which the named sender is the only source sending to the session. o Adspec A PATH message may optionally carry a package of OPWA advertising information, known as an "Adspec". An Adspec received in a PATH message is passed to the local traffic control, which returns an updated Adspec; the updated version is then forwarded downstream. For protocol efficiency, RSVP also allows multiple sets of reservation information for the same session to be "packed" into a single RESV message. Unlike merging, packing preserves information. For simplicity, however, the protocol currently prohibits packing reservations of different sessions into the same Braden, Zhang, et al. Expiration: May 1996 [Page 19] Internet Draft RSVP Specification November 1995 RSVP message. PATH messages are sent with the same source and destination addresses as the data, so that they will be routed correctly through non-RSVP clouds (see Section 2.8). On the other hand, RESV messages are sent hop-by-hop; each RSVP-speaking node forwards a RESV message to the unicast address of a previous RSVP hop. 2.2 Port Usage At present an RSVP session is defined by the triple: (DestAddress, ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port field (i.e., a 16-bit quantity carried at octet offset +2 in the transport header). DstPort may be omitted (set to zero) if the ProtocolId specifies a protocol that does not have a destination port field in the format used by UDP and TCP. RSVP allows any value for ProtocolId. However, end-system implementations of RSVP may know about certain values for this field, and in particular must know about the values for UDP and TCP (17 and 6, respectively). An end system should give an error to an application that either: o specifies a non-zero DstPort for a protocol that does not have UDP/TCP-like ports, or o specifies a zero DstPort for a protocol that does have UDP/TCP-like ports. Filter specs and sender templates are defined by the pair: (SrcAddress, SrcPort), where SrcPort is a UDP/TCP source port field (i.e., a 16-bit quantity carried at octet offset +0 in the transport header). SrcPort may be omitted (set to zero) in certain cases. The following rules hold for the use of zero DstPort and/or SrcPort fields in RSVP. 1. Destination ports must be consistent. Path state and/or reservation state for the same DestAddress and ProtocolId must have DstPort values that are all zero or all non-zero. Violation of this condition in a node is a "Conflicting Dest Port" error. 2. Destination ports rule. If DstPort in a session definition is zero, all SrcPort fields used for that session must also be zero. The Braden, Zhang, et al. Expiration: May 1996 [Page 20] Internet Draft RSVP Specification November 1995 assumption here is that the protocol does not have TCP/UDP- like ports. Violation of this condition in a node is a "Conflicting Src Port" error. 3. Source Ports must be consistent. A sender host must not send path state both with and without a zero SrcPort. Violation of this condition is an "Ambiguous Path" error. 2.3 Merging Flowspecs As noted earlier, a single physical interface may receive multiple reservation request from different next hops for the same session and with the same filter spec, but RSVP should install only one reservation on that interface. This reservation should an effective flowspec that is the "maximum" of the flowspecs requested by the different next hops. Similarly, a RESV message forwarded to a previous hop should carry a flowspec that is the "maximum" of the flowspecs requested by the different next hops. Both cases represent flowspec merging. Merging flowspecs requires calculating the "largest" of a set of flowspecs, which are otherwise opaque to RSVP. Since flowspecs are multi-dimensional vectors (they contain both Tspec and Rspec components, each of which may itself be multi-dimensional), generally speaking they cannot be strictly ordered. However, in many cases one can easily determine the "larger" of two flowspecs, such as when both request the same bandwidth but one requests a tighter delay, or when one of the two requests both a higher bandwidth and a tighter delay bound. When the "larger" of the two cannot be determined, RSVP must compute and use a third flowspec that is at least as large as each, i.e., a "least upper bound" (LUB). If the two flowspecs are incomparable, their comparison will treated as an error. We can now give the complete rules for calculating the effective flowspec (Te, Re) to be installed on an interface. Here Te is the effective Tspec and Re is the effective Rspec. As an example, consider interface (d) in Figure 9. 1. Re is calculated as the largest (using an LUB if necessary) of the Rspecs in RESV messages from different next hops (e.g., D and D') but the same outgoing interface (d). 2. All Tspecs that were supplied in PATH messages from different previous hops (e.g., some or all of A, B, and B' in Figure 9) are summed; call this sum Path_Te. Braden, Zhang, et al. Expiration: May 1996 [Page 21] Internet Draft RSVP Specification November 1995 3. The maximum Tspec supplied in RESV messages from different next hops (e.g., D and D') is calculated; call this Resv_Te. 4. Te is the GLB (greatest lower bound) of Path_Te and Resv_Te. For Tspecs defined by token bucket parameters, this means to take the smaller of the bucket size and the rate parameters. Flowspecs, Tspecs, and Adspecs are opaque to RSVP. Therefore, the last of these steps is actually performed by traffic control. The definition and implementation of the rules for comparing flowspecs, calculating LUB's, and summing Tspecs are outside the definition of RSVP [ServTempl95a]. Section 3.9.4 shows generic calls that an RSVP daemon could use for these functions. 2.4 Soft State RSVP takes a "soft state" approach to managing the reservation state in routers and hosts. RSVP soft state is created and periodically refreshed by PATH and RESV messages. The state is deleted if no matching refresh messages arrive before the expiration of a "cleanup timeout" interval. It may also be deleted by an explicit "teardown" message, described in the next section. At the expiration of each "refresh timeout" period and after a state change, RSVP scans its state to build and forward PATH and RESV refresh messages to succeeding hops. PATH and RESV messages are idempotent. When a route changes, the next PATH message will initialize the path state on the new route, and future RESV messages will establish reservation state there; the state on the now-unused segment of the route will time out. Thus, whether a message is "new" or a "refresh" is determined separately at each node, depending upon the existing state at that node. RSVP sends its messages as IP datagrams with no reliability enhancement. Periodic transmission of refresh messages by hosts and routers is expected to handle the occasional loss of RSVP messages. If the effective cleanup timeout is set to K times the refresh timeout period, then RSVP can tolerate K-1 successive RSVP packet losses without falsely erasing a reservation. We recommend that the network traffic control mechanism be statically configured to grant some minimal bandwidth for RSVP messages to protect them from congestion losses. The state maintained by RSVP is dynamic; to change the set of senders Si or to change any QoS request, a host simply starts sending revised PATH and/or RESV messages. The result should be an appropriate adjustment in the RSVP state in all nodes along the Braden, Zhang, et al. Expiration: May 1996 [Page 22] Internet Draft RSVP Specification November 1995 path. In steady state, refreshing is performed hop-by-hop to allow merging. If the received state differs from the stored state, the stored state is updated. If this update results in modification of state to be forwarded in refresh messages, these refresh messages must be generated and forwarded immediately, so that state changes can be propagated end-to-end without delay. However, propagation of a change stops when and if it reaches a point where merging causes no resulting state change. This minimizes RSVP control traffic due to changes and is essential for scaling to large multicast groups. State that is received through a particular interface I* should never be forwarded out the same interface. Conversely, state that is forwarded out interface I* must be computed using only state that arrived on interfaces different from I*. A trivial example of this rule is illustrated in Figure 10, which shows a transit router with one sender and one receiver on each interface (and assumes one next/previous hop per interface). Interfaces (a) and (c) serve as both outgoing and incoming interfaces for this session. Both receivers are making wildcard-scope reservations, in which the RESV messages are forwarded to all previous hops for senders in the group, with the exception of the next hop from which they came. The result is independent reservations in the two directions. There is an additional rule governing the forwarding of RESV messages: state from RESV messages received from outgoing interface Io should be forwarded to incoming interface Ii only if PATH messages from Ii are forwarded to Io. Braden, Zhang, et al. Expiration: May 1996 [Page 23] Internet Draft RSVP Specification November 1995 ________________ a | | c ( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) |________________| Send | Receive | WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) | Receive | Send | WF( *{4B}) --> (a) | (c) --> WF( *{4B}) | Reserve on (a) | Reserve on (c) __________ | __________ | * {4B} | | | * {3B} | |__________| | |__________| | Figure 10: Independent Reservations 2.5 Teardown Upon arrival, RSVP "teardown" messages remove path and reservation state immediately. Although it is not necessary to explicitly tear down an old reservation, we recommend that all end hosts send a teardown request as soon as an application finishes. There are two types of RSVP teardown message, PTEAR and RTEAR. A PTEAR message travels towards all receivers downstream from its point of initiation and deletes path state along the way. An RTEAR message deletes reservation state and travels towards all senders upstream from its point of initiation. A PTEAR (RTEAR) message may be conceptualized as a reversed-sense Path message (Resv message, respectively). A teardown request may be initiated either by an application in an end system (sender or receiver), or by a router as the result of state timeout. Once initiated, a teardown request must be forwarded hop-by-hop without delay. A teardown message deletes the specified state in the node where it is received. As always, this state change will be propagated immediately to the next node, but only if there will be a net change after merging. As a result, an RTEAR message will prune the reservation state back (only) as far as possible. Like all other RSVP messages, teardown requests are not delivered Braden, Zhang, et al. Expiration: May 1996 [Page 24] Internet Draft RSVP Specification November 1995 reliably. The loss of a teardown request message will not cause a protocol failure because the unused state will eventually time out even though it is not explicitly deleted. If a teardown message is lost, the router that failed to receive that message will time out its state and initiate a new teardown message beyond the loss point. Assuming that RSVP message loss probability is small, the longest time to delete state will seldom exceed one refresh timeout period. 2.6 Errors and Acknowledgments There are two RSVP error messages, RERR and PERR, and a reservation confirmation message RACK. There are a number of ways for a syntactically valid reservation request to fail at some node along the path, triggering a RERR message: 1. The effective flowspec that is computed using the new request may fail admission control. 2. Administrative policy may prevent the requested reservation. 3. There may be no matching path state, so that the request cannot be forwarded towards the sender(s). 4. A reservation style that requires the explicit selection of a unique sender may have a filter spec that is ambiguous, i.e., that matches more than one sender in the path state, due to the use of wildcard fields in the filter spec. 5. The requested style may be incompatible with the style(s) of existing reservations. The incompatibility may occur among reservations for the same session on the same outgoing interface, or among effective reservations on different outgoing interfaces. In any of these cases, a RERR message is returned to the receiver(s) responsible for the erroneous request. A node may also decide to preempt an established reservation. A preemption will trigger a RERR message to all affected receivers. An error message does not modify state in the nodes through which it passes. Therefore, any reservations established downstream of the node where the failure occurred will persist until the responsible receiver(s) explicitly tear down the state or allow it to time out. In this version of RSVP, detection of an error in a reservation Braden, Zhang, et al. Expiration: May 1996 [Page 25] Internet Draft RSVP Specification November 1995 request not only generates a RERR message, it also prevents the request from being forwarded further. This may not always be the desirable behavior; for example, a receiver may want a reservation request to propagate all the way to the sender despite an admission control failure at a particular link along the path. However, design of the appropriate mechanism has proved difficult, and therefore this version take the simplest approach. When admission control fails for a reservation request, any existing reservation is left in place. This prevents a new, very large, reservation from disrupting the existing QoS by merging with an existing reservation and then failing admission control (this has been called the "killer reservation" problem). To request a confirmation for its reservation request, a receiver Rj includes in the RESV message a confirmation-request object containing its IP address. At each merge point, only the largest flowspec and any accompanying confirmation-request object is forwarded upstream. If the reservation request from Rj is equal to or smaller than the reservation in place on a node, its RESV are not forwarded further, and if the RESV included an confirmation-request object, a RACK message is sent back to Rj. This mechanism has the following consequences: o A new reservation request with a flowspec larger than any in place for a session will normally result in either a RERR or a RACK message back to the receiver from each sender. In this case, the RACK message will be an end-to-end confirmation. o The receipt of a RACK gives no guarantees. Assume the first two reservation requests from receivers R1 and R2 arrive at the node where they are merged. R2, whose reservation was the second to arrive at that node, may receive a RACK from that node while R1's request has not yet propagated all the way to a matching sender and may still fail. In this case, R2 will receive a RACK although there is no end-to-end reservation in place. Furthermore, if the two flowspecs are equal, R2 may receive a RACK followed by a RERR. However, if its flowspec is smaller, R2 will receive only the RACK. o Despite these uncertainties, receipt of a RACK indicates a high probability that the reservation is in place. o Finally, note that RERR and/or RACK messages may be lost. Braden, Zhang, et al. Expiration: May 1996 [Page 26] Internet Draft RSVP Specification November 1995 2.7 Policy and Security RSVP-mediated QoS requests will result in particular user(s) getting preferential access to network resources. To prevent abuse, some form of back pressure on users is likely to be required. This back pressure might take the form of administrative rules, or of some form of real or virtual billing for the "cost" of a reservation. The form and contents of such back pressure is a matter of administrative policy that may be determined independently by each administrative domain in the Internet. Therefore, admission control at each node is likely to contain a policy component in addition to a resource reservation component. As input to the policy-based admission decision, RSVP messages may carry policy data. This data may include credentials identifying users or user classes, account numbers, limits, quotas, etc. To protect the integrity of the policy-based admission control mechanisms, it may be necessary to ensure the integrity of RSVP messages against corruption or spoofing, hop by hop. For this purpose, RSVP messages may carry integrity objects that can be created and verified by neighbor RSVP-capable nodes. These objects are expected to contain an encrypted part and to assume a shared secret between neighbors. User policy data in reservation request messages presents a scaling problem. When a multicast group has a large number of receivers, it will be impossible or undesirable to carry all receivers' policy data upstream to the sender(s). The policy data will have to be administratively merged at places near the receivers, to avoid excessive policy data. Administrative merging implies checking the user credentials and accounting data and then substituting a token indicating the check has succeeded. A chain of trust established using an integrity field will allow upstream nodes to accept these tokens. In summary, different administrative domain in the Internet may have different policies regarding their resource usage and reservation. The role of RSVP is to carry policy data associated with each reservation to the network as needed. Note that the merge points for policy data are likely to be at the boundaries of administrative domains. It may be necessary to carry accumulated and unmerged policy data upstream through multiple nodes before reaching one of these merge points. Braden, Zhang, et al. Expiration: May 1996 [Page 27] Internet Draft RSVP Specification November 1995 2.8 Automatic RSVP Tunneling It is impossible to deploy RSVP (or any new protocol) at the same moment throughout the entire Internet. Furthermore, RSVP may never be deployed everywhere. RSVP must therefore provide correct protocol operation even when two RSVP-capable routers are joined by an arbitrary "cloud" of non-RSVP routers. Of course, an intermediate cloud that does not support RSVP is unable to perform resource reservation. However, if such a cloud has sufficient capacity, it may still provide acceptable realtime service. RSVP automatically tunnels through such a non-RSVP cloud. Both RSVP and non-RSVP routers forward PATH messages towards the destination address using their local uni-/multicast routing table. Therefore, the routing of PATH messages will be unaffected by non-RSVP routers in the path. When a PATH message traverses a non-RSVP cloud, it carries to the next RSVP-capable node the IP address of the last RSVP-capable router before entering the cloud. This effectively constructs a tunnel through the cloud for RESV messages, which can then be forwarded directly to the next RSVP- capable router on the path(s) back towards the source. Some interconnection topologies of RSVP and non-RSVP routers can cause RESV messages to arrive at the wrong RSVP-capable node, or to arrive at the wrong interface at the correct node. An RSVP daemon must be prepared to handle either situation. When a RESV message arrives, its IP destination address should normally be the address of one of the local interfaces. If so, the reservation should be made on the addressed interface, even if it is not the one on which the message arrived. If the destination address does not match any local interface and the message is not a PATH or PTEAR, it should be forwarded without further processing by this node. 2.9 Host Model Before a session can be created, the session identification, comprised of DestAddress and perhaps the generalized destination port, must be assigned and communicated to all the senders and receivers by some out-of-band mechanism. When an RSVP session is being set up, the following events happen at the end systems. H1 A receiver joins the multicast group specified by DestAddress, using IGMP. H2 A potential sender starts sending RSVP PATH messages to the DestAddress. Braden, Zhang, et al. Expiration: May 1996 [Page 28] Internet Draft RSVP Specification November 1995 H3 A receiver application receives a PATH message. H4 A receiver starts sending appropriate RESV messages, specifying the desired flow descriptors. H5 A sender application receives a RESV message. H6 A sender starts sending data packets. There are several synchronization considerations. o H1 and H2 may happen in either order. o Suppose that a new sender starts sending data (H6) but there are no multicast routes because no receivers have joined the group (H1). Then the data will be dropped at some router node (which node depends upon the routing protocol) until receivers(s) appear. o Suppose that a new sender starts sending PATH messages (H2) and data (H6) simultaneously, and there are receivers but no RESV messages have reached the sender yet (e.g., because its PATH messages have not yet propagated to the receiver(s)). Then the initial data may arrive at receivers without the desired QoS. The sender could mitigate this problem by awaiting arrival of the first RESV message (H5); however, receivers that are farther away may not have reservations in place yet. o If a receiver starts sending RESV messages (H4) before receiving any PATH messages (H3), RSVP will return error messages to the receiver. The receiver may simply choose to ignore such error messages, or it may avoid them by waiting for PATH messages before sending RESV messages. [LZ: should recommend that a receiver wait for at least PATH messages to arrive before sending RESV messages.] A specific application program interface (API) for RSVP is not defined in this protocol spec, as it may be host system dependent. However, Section 3.9.1 discusses the general requirements and presen Braden, Zhang, et al. Expiration: May 1996 [Page 29] Internet Draft RSVP Specification November 1995 3. RSVP Functional Specification 3.1 RSVP Message Formats An RSVP message consists of a common header followed by a variable number of variable-length, typed "objects". The subsections that follow define the formats of the common header, the object structures, and each of the RSVP message types. For each RSVP message type, there is a set of rules for the permissible choice and ordering of object types. These rules are specified using Backus-Naur Form (BNF) augmented with square brackets surrounding optional sub-sequences. 3.1.1 Common Header 0 1 2 3 +-------------+-------------+-------------+-------------+ | Vers | Flags| Type | RSVP Checksum | +-------------+-------------+-------------+-------------+ | RSVP Length | (Reserved) | Send_TTL | +-------------+-------------+-------------+-------------+ | Message ID | +----------+--+-------------+-------------+-------------+ |(Reserved)|MF| Fragment offset | +----------+--+-------------+-------------+-------------+ The fields in the common header are as follows: Vers: 4 bits Protocol version number. This is version 1. Flags: 4 bits (None defined yet) Type: 8 bits 1 = PATH 2 = RESV 3 = PERR 4 = RERR Braden, Zhang, et al. Expiration: May 1996 [Page 30] Internet Draft RSVP Specification November 1995 5 = PTEAR 6 = RTEAR 7 = RACK RSVP Checksum: 16 bits A standard TCP/UDP checksum over the contents of the RSVP message, with the checksum field replaced by zero. RSVP Length: 16 bits The total length of this RSVP packet in bytes, including the common header and the variable-length objects that follow. If the MF flag is on or the Fragment Offset field is non-zero, this is the length of the current fragment of a larger message. Send_TTL: 8 bits The IP TTL value with which the message was sent. Message ID: 32 bits A label shared by all fragments of one message from a given next/previous RSVP hop. An RSVP implementation assigns a unique Message ID to each message it sends. MF: More Fragments Flag: 1 bit This flag is the low-order bit of a byte; the seven high- order bits are reserved. It is on for all but the last fragment of a message. Fragment Offset: 24 bits This field gives the byte offset of the fragment in the message. 3.1.2 Object Formats Every object consists of one or more 32-bit words with a one- word header, in the following format: 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | Braden, Zhang, et al. Expiration: May 1996 [Page 31] Internet Draft RSVP Specification November 1995 +-------------+-------------+-------------+-------------+ | | // (Object contents) // | | +-------------+-------------+-------------+-------------+ An object header has the following fields: Length A 16-bit field containing the total object length in bytes. Must always be a multiple of 4, and at least 4. Class-Num Identifies the object class; values of this field are defined in Appendix A. Each object class has a name, which is always capitalized in this document. An RSVP implementation must recognize the following classes: NULL A NULL object has a Class-Num of zero, and its C-Type is ignored. Its length must be at least 4, but can be any multiple of 4. A NULL object may appear anywhere in a sequence of objects, and its contents will be ignored by the receiver. SESSION Contains the IP destination address (DestAddress), the IP protocol id, and a generalized destination port, to define a specific session for the other objects that follow. Required in every RSVP message. RSVP_HOP Carries the IP address of the RSVP-capable node that sent this message. This document refers to a RSVP_HOP object as a PHOP ("previous hop") object for downstream messages or as a NHOP ("next hop") object for upstream messages. TIME_VALUES Contains the value for the refresh period R used by the creator of the message; see 3.5. Required in Braden, Zhang, et al. Expiration: May 1996 [Page 32] Internet Draft RSVP Specification November 1995 every PATH and RESV message. STYLE Defines the reservation style plus style-specific information that is not in FLOWSPEC or FILTER_SPEC objects. Required in every RESV message. FLOWSPEC Defines a desired QoS, in a RESV message. FILTER_SPEC Defines a subset of session data packets that should receive the desired QoS (specified by an FLOWSPEC object), in a RESV message. SENDER_TEMPLATE Contains a sender IP address and perhaps some additional demultiplexing information to identify a sender, in a PATH message. SENDER_TSPEC Defines the traffic characteristics of a sender's data stream, in a PATH message. ADSPEC Carries OPWA data, in a PATH message. ERROR_SPEC Specifies an error, in a PERR or RERR message. POLICY_DATA Carries information that will allow a local policy module to decide whether an associated reservation is administratively permitted. May appear in a PATH or RESV message. INTEGRITY Contains cryptographic data to authenticate the originating node, and perhaps to verify the contents, Braden, Zhang, et al. Expiration: May 1996 [Page 33] Internet Draft RSVP Specification November 1995 of this RSVP message. SCOPE An explicit list of sender hosts towards which to forward a message. May appear in a RESV, RERR, or RTEAR message. RESV_CONFIRM Carries the IP address of a receiver that requested a confirmation. May appear in a RESV or RACK message. C-Type Object type, unique within Class-Num. Values are defined in Appendix A. The maximum object content length is 65528 bytes. The Class- Num and C-Type fields may be used together as a 16-bit number to define a unique type for each object. The high-order bit of the Class-Num is used to determine what action a node should take if it does not recognize the Class- Num of an object; see Section 3.8. 3.1.3 Path Message Each sender host periodically sends a PATH message containing a description of each data stream it originates. The PATH message travels from a sender to receiver(s) along the same path(s) used by the data packets. The IP source address of a PATH message is an address of the sender it describes, while the destination address is the DestAddress for the session. These addresses assure that the message will be correctly routed through a non-RSVP cloud. Each RSVP-capable node along the path(s) captures PATH messages and processes them to build local path state. The node then forwards the PATH messages towards the receiver(s), replicating it as dictated by multicast routing, while preserving the original IP source address. PATH messages eventually reach the applications on all receivers; however, they are not looped back to a receiver running in the same application process as the sender. The format of a PATH message is as follows: Braden, Zhang, et al. Expiration: May 1996 [Page 34] Internet Draft RSVP Specification November 1995 ::= [ ] ::= [ ] [ ] The PHOP (i.e., the RSVP_HOP) object of each PATH message contains the address of the interface through which the PATH message was most recently sent. The SENDER_TEMPLATE object defines the format of data packets from this sender, while the SENDER_TSPEC object specifies the traffic characteristics of the flow. Optionally, there may be a POLICY_DATA object specifying user credential and accounting information and/or an ADSPEC object carrying advertising (OPWA) data. A PATH message received at a node is processed to create path state for the sender defined by the SENDER_TEMPLATE and SESSION objects. Any POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in the path state. If an error is encountered while processing a PATH message, a PERR message is sent to the originating sender of the PATH message. PATH messages must satisfy the rules on SrcPort and DstPort in Section 2.2. Periodically, the RSVP daemon at a node scans the path state to create new PATH messages to forward downstream. Each message contains a sender descriptor defining one sender. The RSVP daemon forwards these messages using routing information it obtains from the appropriate uni-/multicast routing daemon. The route depends upon the session DestAddress, and for some routing protocols also upon the source (sender's IP) address. The routing information generally includes the list of none or more outgoing interfaces to which the PATH message to be forwarded. Because each outgoing interface has a different IP address, the PATH messages sent out different interfaces contain different PHOP addresses. In addition, any ADSPEC or POLICY_DATA objects carried in PATH messages will also generally differ for different outgoing interfaces. Some IP multicast routing protocols (e.g., DVMRP, PIM, and MOSPF) also keep track of the expected incoming interface for each source host to a multicast group. Whenever this information is available, RSVP should check the incoming interface of each PATH message and immediately discard those Braden, Zhang, et al. Expiration: May 1996 [Page 35] Internet Draft RSVP Specification November 1995 messages that have arrived on the wrong interface. 3.1.4 Resv Messages RESV messages carry reservation requests hop-by-hop from receivers to senders, along the reverse paths of data flows for the session. The IP destination address of a RESV message is the unicast address of a previous-hop node, obtained from the path state. The IP source address is an address of the node that sent the message. The RESV message format is as follows: ::= [ ] [ ] [ ] [ ]