HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:33:10 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 22 Jun 1995 22:00:00 GMT ETag: "30504d-2fbf7-2fe9e7e0" Accept-Ranges: bytes Content-Length: 195575 Connection: close Content-Type: text/plain Internet Draft R. Braden, Ed. Expiration: December 1995 ISI File: draft-ietf-rsvp-spec-06.txt L. Zhang PARC D. Estrin ISI S. Herzog ISI S. Jamin USC Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification June 21, 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: December 1995 [Page 1] Internet Draft RSVP Specification June 1995 What's Changed Since Boston IETF The most important changes in this document from the rsvp-spec-05 draft are: o Added SE (Shared Explicit) style to all parts of the document. o Further clarified reservation options and added table in Figure 3. Defined option vector in STYLE object. o Renamed CREDENTIAL object class to POLICY_DATA object class, and rewrote section 2.5 to more fully express its intended usage. o Clarified the relationship between the wildcard scope reservation option and wildcards in individual FILTER_SPEC objects: wildcard is as wildcard does. o Added SCOPE object definition and define the rules for its use to prevent looping of wildcard-scope messages. o Added TAG object. This is needed to do semantic fragmentation in certain cases; however, the rules for its use are not yet written down. Furthermore, there has been some debate about semantic fragmentation. o Added some mechanisms for handling backwards compatibility for future protocol extensions: (1) High bit of object class number; (2) unmerged FLOWSPEC C-Type; (3) unmerged POLICY_DATA C-Type. o Rewrote Section 4.3 on preventing looping. Included rules for SCOPE object. o Specified rules for local repair upon route change notification (Section 4.4). o Specified for each error type whether or not the state information in the erroneous packet is to be stored and forwarded. o Deleted the discussion of retransmitting a Teardown message Q times; assume Q=1 is sufficient. o Moved Session Groups to Appendix D, "Experimental and Open Issues". Session Groups should be revisited as part of a larger context of cross-session reservations. o Changed common header format, removing Object Count (which was Braden, Zhang, et al. Expiration: December 1995 [Page 2] Internet Draft RSVP Specification June 1995 redundant) and rearranging the remaining fields. Moved the two common header flags into objects: Entry-Police into SESSION object and LUB-used into ERROR_SPEC object. o Revised the rules for state timeout (Section 4.5) and redefined the TIME_VALUES object format. o Changed the error message format: (1) removed required RSVP_HOP object from PERR and RERR messages; (2) removed CREDENTIAL (i.e., POLICY_DATA) object from RERR messages; (3) specified more carefully what may appear in flow descriptor list of RERR messages. o Revised the definitions of error codes and error values, and moved them into a separate Appendix B. o No longer require CREDENTIAL (i.e., POLICY_DATA) match for teardown. o Revised routing of RERR messages to use SCOPE objects to avoid wildcard-induced looping. o Added LIH (logical interface handle) to RSVP_HOP object, for IP multicast tunnels. o Added two new upcall event types in the API: reservation event and policy data event. o Generalized the generic traffic control calls slightly to allow multiple filter specs per flowspec, for SE style. This introduced a new set of handles, called FHandle. Also added a preemption upcall. o Added route change notification to the generic interface to routing. o Updated the message processing rules (Section 5). o Rewrote Appendix C on UDP encapsulation. o Removed specification of FLOWSPEC object format (but int-serv working group has since reneged on promise to specify it). Braden, Zhang, et al. Expiration: December 1995 [Page 3] Internet Draft RSVP Specification June 1995 1. Introduction This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet [RSVP93,ISInt93]. A host uses the RSVP protocol to request a specific quality of service (QoS) from the network, on behalf of an application data stream. RSVP is also used to deliver QoS requests to routers along the path(s) of the data stream and to maintain router and host state to provide the requested service. This will generally (but not necessarily) require reserving resources along the data path. RSVP reserves resources for simplex data streams, i.e., it reserves resources in only one direction on a link, so that a sender is logically distinct from a receiver. However, the same application may act as both sender and receiver. RSVP operates on top of IP, 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. As shown in Figure 1, an implementation of RSVP, like the implementations of routing and management protocols, will typically execute in the background, not in the data forwarding path. RSVP is not itself a routing protocol; the RSVP daemon consults the local routing protocol(s) to obtain routes. Thus, a host sends IGMP messages to join a multicast group, and it sends RSVP messages to reserve resources along the delivery path(s) from that group. RSVP is designed to operate with existing and future unicast and multicast routing protocols. Braden, Zhang, et al. Expiration: December 1995 [Page 4] Internet Draft RSVP Specification June 1995 HOST ROUTER _________________________ RSVP ______________________ | | .---------------. | | _______ ______ | . | ________ . ______ | | | | | | | . || | . | || RSVP | |Applic-| | RSVP <----- ||Routing | -> RSVP <------> | | App <----->daemon| | ||Protocol| |daemon|| | | | | | | || daemon <----> || | |_______| |___.__| | ||_ ._____| |__.___|| |===|===============v=====| |===v=============v====| | data .......... | | . ............ | | | ____v_ ____v____ | | _v__v_ _____v___ | | | |Class-| | || data | |Class-| | || data | |=> ifier|=> Packet =============> ifier|==> Packet |======> | |______| |Scheduler|| | |______| |Scheduler|| | |_________|| | |_________|| |_________________________| |______________________| Figure 1: RSVP in Hosts and Routers Each router that is capable of resource reservation passes incoming data packets to 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. The scheduler allocates resources for transmission on the particular link-layer medium used by each 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. There are many possible ways this might be accomplished, and the details will be medium-dependent. The scheduler itself allocates packet transmission capacity on a QoS- passive medium such as a leased line. 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 and to be consistent with IP multicast, RSVP makes receivers responsible for requesting resource reservations [RSVP93]. A QoS request, typically originating in a receiver host application, will be passed to the local RSVP implementation, shown as a user daemon in Figure 1. The RSVP protocol is then used to pass 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 program applies a local decision procedure, called "admission control", to determine if it can supply the Braden, Zhang, et al. Expiration: December 1995 [Page 5] Internet Draft RSVP Specification June 1995 requested QoS. If admission control succeeds, the RSVP program sets parameters to the packet classifier and scheduler to obtain the desired QoS. If admission control fails at any node, the RSVP program returns an error indication to the application 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 the membership of a large group will be constantly changing, 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, in addition to receiver-initiation. 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). In summary, RSVP has the following attributes: o RSVP supports multicast or unicast data delivery and adapts to changing group membership as well as changing routes. o RSVP is simplex. o RSVP is receiver-oriented, i.e., the receiver of a data flow is responsible for the initiation and maintenance of the resource reservation used for that flow. o RSVP maintains "soft state" in the routers, enabling it to gracefully support dynamic membership changes and automatically adapt to routing changes. o RSVP provides several reservation models or "styles" (defined below) to fit a variety of applications. 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 Braden, Zhang, et al. Expiration: December 1995 [Page 6] Internet Draft RSVP Specification June 1995 services. Section 2 presents an overview of the RSVP protocol mechanisms, while Section 3 gives examples of the services and mechanism. Section 4 contains the functional specification of RSVP. Section 5 presents explicit message processing rules. 1.1 Data Flows The set of data flows with the same unicast or multicast destination constitute a session. RSVP treats each session independently. All data packets in a particular session are directed to the same IP destination address DestAddress, and perhaps to some further demultiplexing point defined in a higher layer (transport or application). We refer to the latter as a "generalized destination port". DestAddress is the group address for multicast delivery, or the unicast address of a single receiver. A generalized destination port 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 uses 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 the multicast routing protocol. 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 correspond to a unique Internet host, or a single host may contain multiple logical senders and/or receivers, distinguished by generalized ports. Senders Receivers _____________________ ( ) ===> R1 S1 ===> ( Multicast ) ( ) ===> R2 ( distribution ) S2 ===> ( ) ( by Internet ) ===> R3 (_____________________) Figure 2: Multicast Distribution Session Braden, Zhang, et al. Expiration: December 1995 [Page 7] Internet Draft RSVP Specification June 1995 Even if the destination address is unicast, there may be multiple receivers, distinguished by the generalized port. There may also be multiple senders for a unicast destination, i.e., RSVP can set up reservations for multipoint-to-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 the DestAddress and the generalized destination port defining the session) defines 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. Note that the action to control the QoS occurs at the place where the data enters the medium, i.e., at the upstream end of the link, although the RSVP reservation request originates from receiver(s) downstream. The flowspec in a reservation request will generally include a service type and two sets of numeric parameters: (1) an "Rspec" (R for `reserve'), which defines the desired per-hop reservation, and (2) a "Tspec" (T for `traffic'), which defines the parameters that may be used to police the data flow, i.e., to ensure it does not exceed its promised traffic level. The form and contents of Tspecs and Rspecs are determined by the integrated service model [ServTempl95a], and are generally opaque to RSVP. RSVP delivers the Tspec and Rspec, together with an indication whether traffic policing is needed to the admission control and packet scheduling components of traffic control. A service that requires traffic policing might for example apply it at the edge of the network and at data merge points; RSVP knows when these occur and must so indicate to the traffic control mechanism. On the other hand, RSVP cannot interpret the service embodied in the flowspec and therefore does not know whether policing will actually be applied in a particular case. In the general RSVP reservation model [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 Braden, Zhang, et al. Expiration: December 1995 [Page 8] Internet Draft RSVP Specification June 1995 the interest of simplicity (and to minimize layer violation), the present RSVP version uses a much more restricted form of filter spec: select only on sender IP address, on UDP/TCP port number, and perhaps on IP protocol id. RSVP can distinguish subflows of a hierarchically-encoded signal if they are assigned distinct multicast destination addresses, or, for a unicast destination, distinct destination ports. Data packets that are addressed to a particular session but do not match any of the filter specs for that session are expected to be sent as best-effort traffic, and under congested conditions, such packets are likely to experience long delays, and they may be dropped. When a receiver does not wish to receive a particular (sub-)flow, it can economize on network resources by explicitly asking the network to drop unneeded the data packets; it does so by leaving the multicast group(s) to which these packets are addressed. Thus, determining where packets get delivered should be a routing function; RSVP is concerned only with the QoS of those packets that are delivered by routing. RSVP reservation request messages originate at receivers and are passed upstream towards the sender(s). (This document defines the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the data flow direction.) When an elementary reservation request is received at a node, the RSVP daemon takes two primary actions: 1. Daemon makes 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. Daemon forwards the reservation 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, for two reasons. First, it is Braden, Zhang, et al. Expiration: December 1995 [Page 9] Internet Draft RSVP Specification June 1995 possible (in theory) for the kernel to modify the flowspec hop- by-hop, although currently no realtime services do this. Second, reservations from different downstream branches of the multicast distribution tree(s) must be "merged" as reservations travel upstream. Merging reservations is a necessary consequence of multicast distribution, which creates a single stream of data packets in a particular router from any Si, regardless of the set of receivers downstream. The reservation for Si on a particular outgoing link L should be the "maximum" of the individual flowspecs from the receivers Rj that are downstream via link L. Merging is discussed further in Section 2.2. The basic RSVP reservation model is "one pass": a receiver sends a reservation request upstream, and each node in the path can only accept or reject the request. This scheme provides no way to make end-to-end service guarantees, since the QoS request must be applied independently at each hop. RSVP also supports an optional reservation model, known as "One Pass With Advertising" (OPWA) [Shenker94]. In OPWA, RSVP control packets sent downstream, following the data paths, are used to gather information on the end-to-end service that would result from a variety of possible reservation requests. The results ("advertisements") are delivered by RSVP to the receiver host, and perhaps to the receiver application. The information may then be used by the receiver to construct an appropriate reservation request. 1.3 Reservation Styles A reservation request includes a set of control options. 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" all senders' packets. A distinct reservation requires that the filter spec match exactly one sender, a wildcard reservation must match at least one. Another option controls the scope of the request: an " explicit" sender specification, or a "wildcard" that implicitly selects all sender hosts upstream of the given node. These control options are collectively called the reservation "style", as shown in Figure 3. Braden, Zhang, et al. Expiration: December 1995 [Page 10] Internet Draft RSVP Specification June 1995 || Reservations: Scope || 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: 1. Wildcard-Filter (WF) Style The WF style implies the options: "shared" reservation and " wildcard" reservation scope. 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 for that link from all receivers, independent of the number of senders using it. A WF-style reservation has wildcard scope, i.e., the reservation is propagated upstream towards all sender hosts. A WF-style reservation automatically extends to new senders as they appear. 2. Fixed-Filter (FF) Style The FF style implies the options: "distinct" reservations and "explicit" reservation scope. 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. It scope is determined by an explicit list of senders. 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 necessarily be merged to share a single reservation in a given node. Braden, Zhang, et al. Expiration: December 1995 [Page 11] Internet Draft RSVP Specification June 1995 3. Shared Explicit (SE) Style The SE style implies the options: "shared" reservation and " explicit" reservation scope. Thus, an SE-style reservation creates a single reservation into which flows from all upstream senders are mixed. However, like a FF reservation the set of senders (and therefore its scope (and therefore the scope) is specified explicitly by the receiver making the reservation. WF and SE are both shared reservations, appropriate for those multicast applications whose application-specific constraints make it unlikely that multiple data sources will transmit simultaneously. One example is audio conferencing, where a limited number of people talk at once; each receiver might issue a WF or SE reservation request for twice one audio channel (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. It is not possible to merge shared reservations with distinct reservations. Therefore, WF and SE styles are incompatible with FF, but are compatible with each other. Merging a WF style reservation with an SE style reservation results in a WF reservation. Other reservation options and styles may be defined in the future (see Appendix D.4, for example). 2. RSVP Protocol Mechanisms 2.1 RSVP Messages There are two fundamental RSVP message types: RESV and PATH . Each receiver host sends RSVP reservation request (RESV) messages towards the senders. These reservation messages must follow in reverse the routes the data packets will use, all the way upstream to the sender hosts included in the scope. RESV messages must be delivered to the sender hosts so that the hosts can set up appropriate traffic control parameters for the first hop. Also note that RSVP sends no positive acknowledgment messages to indicate success (although the delivery of a reservation request to a sender could be used to trigger an acknowledgement at a higher level of protocol.) Braden, Zhang, et al. Expiration: December 1995 [Page 12] Internet Draft RSVP Specification June 1995 Sender Receiver _____________________ Path --> ( ) Si =======> ( Multicast ) Path --> <-- Resv ( ) =========> Rj ( distribution ) <-- Resv (_____________________) Figure 4: RSVP Messages Each sender transmits RSVP PATH messages forward along the uni- /multicast routes provided by the routing protocol(s); see Figure 4. These "Path" messages store path state in each node. Path state is used by RSVP 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). PATH messages may also carry the following information: o Sender Template The Sender Template 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 sender IP address, UDP/TCP sender port, and protocol id. The port number and/or protocol id can be wildcarded. o Tspec PATH message may optionally carry a Tspec that defines an upper bound on the traffic level that the sender will generate. This Tspec can be used by RSVP to prevent over- reservation (and perhaps unnecessary Admission Control failure) on the non-shared links starting at the sender. o Adspec The PATH message may carry a package of OPWA advertising information, known as an "Adspec". An Adspec received in a PATH message is passed to the local traffic control routines, which return an updated Adspec; the updated version is Braden, Zhang, et al. Expiration: December 1995 [Page 13] Internet Draft RSVP Specification June 1995 forwarded downstream. Previous Incoming Outgoing Next Hops Interfaces Interfaces Hops _____ _____________________ _____ | | data --> | | data --> | | | A |-----------| a c |--------------| C | |_____| <-- Resv | | <-- Resv |_____| Path --> | | Path --> _____ _____ | ROUTER | | | | | | | | | |--| D | | B |--| data-->| | data --> | |_____| |_____| |--------| b d |-----------| |<-- Resv| | <-- Resv | _____ _____ | Path-->|_____________________| Path --> | | | | | | |--| D' | | B' |--| | |_____| |_____| | | Figure 5: Router Using RSVP Figure 5 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 but the same session). As illustrated in Figure 5, there may be multiple previous hops and/or next hops through a given physical interface. This may result from the connected network being a shared medium or from the existence of non-RSVP routers in the path to the next RSVP hop (see Section 2.6). An RSVP daemon must preserve the next and previous hop addresses in its reservation and path state, respectively. A RESV message is sent with a unicast destination address, the address of a previous hop. PATH messages, on the other hand, are sent with the session destination address, unicast or multicast. Although multiple next hops may send reservation requests through the same physical interface, the final effect should be to install a reservation on that interface, which is defined by an effective flowspec. This effective flowspec will be the "maximum" of the flowspecs requested by the different next hops. In turn, a RESV Braden, Zhang, et al. Expiration: December 1995 [Page 14] Internet Draft RSVP Specification June 1995 message forwarded to a particular previous hop carries a flowspec that is the "maximum" over the effective reservations on the corresponding outgoing interfaces. Both cases represent merging, which is discussed further below. There are a number of ways for a new or modified reservation request to fail in a given node: 1. The effective flowspec, computed using the new request, may fail admission control. 2. Administrative policy or control may prevent the requested reservation. 3. There may be no matching path state (i.e., the scope may be empty), which would prevent the reservation being propagated upstream. 4. A reservation style that requires a unique sender may have a filter spece that matches more than one sender in the path state, due to the use of wildcards. 5. The requested style may be incompatible with the style(s) of existing reservations for the same session on the same outgoing interface, so an effective flowspec cannot be computed. 6. The requested style may be incompatible with the style(s) of reservations that exist on other outgoing interfaces but will be merged with this reservation to create a refresh message for the previous hop. In any of these cases, an error message is returned to the receiver(s) responsible for the erroneous message, which may or may not be propagated forward along the path. 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 was detected will persist until the receiver(s) responsible cease attempting the reservation. In general, if the error is likely to be repeated at every node further along the path, it is best to drop the errneous message rather than generate a flood of error messages; this is the case for the last four error classes listed above. The first two error classes, admission control and administrative policy, may or may not allow propagation of the message, depending upon the detailed reason and perhaps on local administrative policy and/or the particular service request. More complete rules are given in the Braden, Zhang, et al. Expiration: December 1995 [Page 15] Internet Draft RSVP Specification June 1995 error definitions in Appendix B. An erroneous FILTER_SPEC object in a RESV message will normally be detected at the first RSVP hop from the receiver application, i.e., within the receiver host. However, an admission control failure caused by a FLOWSPEC or a POLICY_DATA object may be detected anywhere along the path(s) to the sender(s). 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). A node may be allowed to preempt an established reservation, in accordance with administrative policy; this will also trigger an error message to all affected receivers. 2.2 Merging and Packing A previous section explained that reservation requests in RESV messages are necessarily merged, to match the multicast distribution tree. As a result, only the essential (i.e., the "largest") reservation requests are forwarded, once per refresh period. A successful reservation request will propagate as far as the closest point(s) along the sink tree to the sender(s) where a reservation level equal or greater than that being requested has been made. At that point, the merging process will drop it in favor of another, equal or larger, reservation request. For protocol efficiency, RSVP also allows multiple sets of path (or reservation) information for the same session to be "packed" into a single PATH (or RESV) message, respectively. (For simplicity, the protocol currently prohibits packing different sessions into the same RSVP message). Unlike merging, packing preserves information. In order to merge reservations, RSVP must be able to merge flowspecs and to merge filterspecs. Merging flowspecs requires calculating the the "largest" of a set of flowspecs, which are otherwise opaque to RSVP. Merging flowspecs is required both to calculate the effective flowspec to install on a given physical interface (see the discussion in connection with Figure 5), and to merge flowspecs when sending a refresh message upstream. Since flowspecs are generally multi-dimensional vectors (they contain both Tspec and Rspec components, each of which may itself be multi-dimensional), they are not strictly ordered. When it cannot take the larger of two flowspecs, RSVP must compute and use a Braden, Zhang, et al. Expiration: December 1995 [Page 16] Internet Draft RSVP Specification June 1995 third flowspec that is at least as large as each, i.e., a "least upper bound" (LUB). It is also possible for two flowspecs to be incomparable, which is treated as an error. The definition and implementation of the rules for comparing flowspecs are outside RSVP proper, but they are defined as part of the service templates [ServTempl95a] 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 5. o 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). o The Tspecs supplied in PATH messages from different previous hops which may send data packets to this reservation (e.g., some or all of A, B, and B' in Figure 5) are summed; call this sum Path_Te. o The maximum Tspec supplied in RESV messages from different next hops (e.g., D and D') is calculated; call this Resv_Te. o 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. Two filter specs can be merged only they are identical or if one contains the other through wild-carding. The result is the more general of the two, i.e., the one with more wildcard fields. 2.3 Soft State To maintain reservation state, RSVP keeps "soft state" in router and host nodes. RSVP soft state is created and periodically refreshed by PATH and RESV messages. The state is deleted if no refreshes arrive before the expiration of a "cleanup timeout" interval; it may also be deleted as the result of an explicit "teardown" message. 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; 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 existence of state at that node. (This document uses the term "refresh message" in this effective sense, to indicate an RSVP Braden, Zhang, et al. Expiration: December 1995 [Page 17] Internet Draft RSVP Specification June 1995 message that does not modify the existing state at the node in question.) In addition to the cleanup timeout, there is a "refresh timeout" period. As messages arrive, the RSVP daemon checks them against the existing state; if it matches, the cleanup timeout timer on the state is reset and the message is dropped. At the expiration of each refresh timeout period, RSVP scans its state to build and forward PATH and RESV messages to succeeding hops. RSVP sends its messages as IP datagrams without reliability enhancement. Periodic transmission of refresh messages by hosts and routers is expected to replace any lost RSVP messages. To tolerate K-1 successive packet losses, the effective cleanup timeout must be at least K times the refresh timeout. In addition, the traffic control mechanism in the network should be statically configured to grant high-reliability service to RSVP messages, to protect RSVP messages from congestion losses. In steady state, refreshing is performed hop-by-hop, which allows merging and packing as described in the previous section. If the received state differs from the stored state, the stored state is updated. Furthermore, if the result will be to modify the refresh messages to be generated, these refresh messages must be generated and forwarded immediately. This will result in state changes propagating 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. The "soft" router state maintained by RSVP is dynamic; to change the set of senders Si or receivers Rj 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 and immediate propagation to all nodes along the path. The RSVP state associated with a session in a particular node is divided into atomic elements that are created, refreshed, and timed out independently. The atomicity is determined by the requirement that any sender or receiver may enter or leave the session at any time, so its state should be created and timed out independently. 2.4 Teardown RSVP teardown messages remove path and reservation state without waiting for the cleanup timeout period, as an optimization to Braden, Zhang, et al. Expiration: December 1995 [Page 18] Internet Draft RSVP Specification June 1995 release resources quickly. It is not necessary (although it may be desirable, since the resources being consumed may be "valuable"), to explicitly tear down an old reservation. 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 should be forwarded hop-by-hop without delay. Teardown messages (like other RSVP messages) are not delivered reliably. However, loss of a teardown message is not considered a problem because the state will time out even if it is not explicitly deleted. If one or more teardown message hops are lost, the router that failed to receive a teardown 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. 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. A 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 message deletes the specified state in the node where it is received. Like any other state change, this will be propagated immediately to the next node, but only if it represents a net change after merging. As a result, an RTEAR message will prune the reservation state back (only) as far as possible. 2.5 Admission 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 will 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 as well as a resource reservation component. As input to the policy-based admission decision, RSVP messages may carry policy data. This data may include credentials identifying Braden, Zhang, et al. Expiration: December 1995 [Page 19] Internet Draft RSVP Specification June 1995 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 neighboring 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 not be possible or desirable to carry all the receivers' policy data upstream to the sender(s). The policy data will have to be administratively merged, near enough to 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. 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. 2.6 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, so service guarantees cannot be made. However, if such a cloud has sufficient excess capacity, it may provide acceptable and useful realtime service. RSVP will automatically tunnel 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, the copies that emerge will carry as a Previous Hop address the IP address of the last RSVP-capable router before entering the cloud. This will effectively construct a tunnel through the cloud for RESV messages, which will be forwarded directly to the next RSVP-capable router on the path(s) back Braden, Zhang, et al. Expiration: December 1995 [Page 20] Internet Draft RSVP Specification June 1995 towards the source. Automatic tunneling is not perfect; in some circumstances it may distribute path information to RSVP-capable routers not included in the data distribution paths, which may create unused reservations at these routers. This is because PATH messages carry the IP source address of the previous hop, not of the original sender, and multicast routing may depend upon the source as well as the destination address. This can be overcome by manual configuration of the neighboring RSVP programs, when necessary. 2.7 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, using RSVP. H3 A receiver application receives a PATH message. H4 A receiver starts sending appropriate RESV messages, specifying the desired flow descriptors, using RSVP. H5 A sender application receives a RESV message. H6 A sender starts sending data packets. There are several synchronization considerations. o Suppose that a new sender starts sending data (H6) but no receivers have joined the group (H1). Then there will be no multicast routes beyond the host (or beyond the first RSVP- capable router) along the path; the data will be dropped at the first hop until receivers(s) do appear (assuming a multicast routing protocol that "prunes off" or otherwise avoids unnecessary paths). o Suppose that a new sender starts sending PATH messages (H2) and immediately starts sending data (H6), and there are receivers but no RESV messages have reached the sender yet Braden, Zhang, et al. Expiration: December 1995 [Page 21] Internet Draft RSVP Specification June 1995 (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 any PATH messages have reached it (H3), RSVP will return error messages to the receiver. The receiver may simply choose to ignore such error messages, or it may avoid them by waiting for PATH messages before sending RESV messages. A specific application program interface (API) for RSVP is not defined in this protocol spec, as it may be host system dependent. However, Section 4.6.1 discusses the general requirements and presents a generic API. 3. Examples We use the following notation for a RESV message: 1. Wildcard-Filter (WF) WF( *{Q}) Here "*{Q}" represents a Flow Descriptor with a "wildcard" scope (choosing all senders) and a flowspec of quantity Q. 2. Fixed-Filter (FF) FF( S1{Q1}, S2{Q2}, ...) A list of (sender, flowspec) pairs, i.e., flow descriptors, packed into a single RESV message. 3. Shared Explicit (SE) SE( (S1,S2,...)Q1, (S3,S4,...)Q2, ...) A list of shared reservations, each specified by a single flowspec and a list of senders. For simplicity we assume here that flowspecs are one-dimensional, defining for example the average throughput, and state them as a multiple of some unspecified base resource quantity B. Figure 6 shows schematically a router with two previous hops labeled Braden, Zhang, et al. Expiration: December 1995 [Page 22] Internet Draft RSVP Specification June 1995 (a) and (b) and two outgoing interfaces 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 and R2 (R3) are routed via outgoing interface (c) ((d) respectively). In addition to the connectivity shown in 6, we must also specify the multicast routing within this node. Assume first that data packets (hence, PATH messages) from each Si shown in Figure 6 is routed to both outgoing interfaces. Under this assumption, Figures 7, 8, and 9 illustrate Wildcard-Filter, Fixed-Filter, and Shared-Explicit reservations, respectively. ________________ (a)| | (c) ( S1 ) ---------->| |----------> ( R1, R2) | Router | (b)| | (d) ( S2,S3 ) ------->| |----------> ( R3 ) |________________| Figure 6: Router Configuration In Figure 7, the "Receive" column shows the RESV messages received over outgoing interfaces (c) and (d) and the "Reserve" column shows the resulting reservation state for each interface. The "Send" column shows the RESV messages forwarded to previous hops (a) and (b). In the "Reserve" column, each box represents one reservation "channel", with the corresponding filter. As a result of merging, only the largest flowspec is forwarded upstream to each previous hop. Braden, Zhang, et al. Expiration: December 1995 [Page 23] Internet Draft RSVP Specification June 1995 | Send | Reserve Receive | | _______ WF( *{3B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} ) | |_______| | -----------------------|---------------------------------------- | _______ WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) | |_______| Figure 7: Wildcard-Filter Reservation Example 1 Figure 8 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 message forwarded to previous hop b. On the other hand, the two different flow descriptors for sender S1 are merged into the single message FF( S1{3B} ), which is sent to previous hop (a). For each outgoing interface, there is a private reservation for each source that has been requested, but this private reservation is shared among the receivers that made the request. Finally, Figure 9 shows a simple example of Shared-Explicit (SE) style reservations. Here each outgoing interface has a single reservation that is shared by a list of senders. Braden, Zhang, et al. Expiration: December 1995 [Page 24] Internet Draft RSVP Specification June 1995 | Send | Reserve Receive | | ________ FF( S1{3B} ) <- (a) | (c) | S1{B} | (c) <- FF( S1{B}, S2{5B} ) | |________| | | S2{5B} | | |________| ---------------------|--------------------------------------------- | ________ <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) FF( S2{5B}, S3{B} ) | |________| | | S3{B} | | |________| Figure 8: Fixed-Filter Reservation Example | Send | Reserve Receive | | ________ SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} ) | | {B} | | |________| ---------------------|--------------------------------------------- | ________ <- (b) | (d) |(S1,S3) | (d) <- SE( (S1,S3){3B} ) SE( (S2,S3){3B} ) | | {3B} | | |________| Figure 9: Shared-Explicit Reservation Example The three examples just shown assume full routing, i.e., data packets from S1, S2, and S3 are routed to both outgoing interfaces. The top part of Figure 10 shows another routing assumption: data packets from S1 are not forwarded to interface (d), because the mesh topology provides a shorter path for S1 -> R3 that does not traverse this node. The bottom of Figure 10 shows WF style reservations under this assumption. Since there is no route from (a) to (d), the reservation forwarded out interface (a) considers only the reservation on interface (c); no merging takes place in this case. Braden, Zhang, et al. Expiration: December 1995 [Page 25] Internet Draft RSVP Specification June 1995 _______________ (a)| | (c) ( S1 ) ---------->| --------->--> |----------> ( R1, R2) | / | | / | (b)| / | (d) ( S2,S3 ) ------->| ->----------> |----------> ( R3 ) |_______________| Router Configuration | Send | Reserve Receive | | _______ WF( *{B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} ) | |_______| | -----------------------|---------------------------------------- | _______ WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) | |_______| Figure 10: Wildcard-Filter Reservation Example -- Partial Routing Finally, we note that state that is received through a particular interface Iout in never forwarded out the same interface. Conversely, state that is forwarded out interface Iout must be computed using only state that arrived on interfaces different from Iout. A trivial example of this rule is illustrated in Figure 11, 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) are 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. These result in independent reservations in the two directions. Braden, Zhang, et al. Expiration: December 1995 [Page 26] Internet Draft RSVP Specification June 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 11: Independent Reservations Braden, Zhang, et al. Expiration: December 1995 [Page 27] Internet Draft RSVP Specification June 1995 4. RSVP Functional Specification 4.1 RSVP Message Formats All RSVP messages consist 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 ordering and choice of object types. These rules are specified using Backus-Naur Form (BNF) augmented with square brackets surrounding optional sub-sequences. 4.1.1 Common Header 0 1 2 3 +-------------+-------------+-------------+-------------+ | Vers | Flags| Type | RSVP Checksum | +-------------+-------------+-------------+-------------+ | Message Length | (Reserved) | +-------------+-------------+-------------+-------------+ The fields in the common header are as follows: Vers Protocol version number. This is version 2. Flags (None defined yet) Type 1 = PATH 2 = RESV 3 = PERR 4 = RERR 5 = PTEAR 6 = RTEAR Braden, Zhang, et al. Expiration: December 1995 [Page 28] Internet Draft RSVP Specification June 1995 RSVP Checksum A standard TCP/UDP checksum over the contents of the RSVP message, with the checksum field replaced by zero. Message Length The total length of this RSVP message in bytes, including this common header and the variable-length objects that follow. 4.1.2 Object Formats An 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 | +-------------+-------------+-------------+-------------+ | | // (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 will always be 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. Braden, Zhang, et al. Expiration: December 1995 [Page 29] Internet Draft RSVP Specification June 1995 SESSION Contains the IP destination address (DestAddress) and possibly 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 If present, contains values for the refresh period R and the state time-to-live T (see section 4.5), to override the default values of R and T. STYLE Defines the reservation style plus style-specific information that is not a FLOWSPEC or FILTER_SPEC object, in a 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. Braden, Zhang, et al. Expiration: December 1995 [Page 30] Internet Draft RSVP Specification June 1995 ADSPEC Carries an Adspec containing 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, of this RSVP message. SCOPE An explicit specification of the scope for forwarding a RESV message. TAG Encloses a list of one or more objects and attaches a logical name or "tag" value to them. The tag value is unique to the next/previous hop and the session (specified by HOP and SESSION objects, respectively). The enclosed object list is the "tagged sublist", and the objects in it said to be "tagged" with the tag value. Objects in a particular tagged sublist must all have the same class-num. Tagged objects with the same tag value are declared to be logically related, i.e., to be members of some larger logical set of objects. Note that the tagged sublist implies no ordering; it defines only a set of objects. The meaning of the logical relationship depends upon the class-num of the tagged objects. C-Type Braden, Zhang, et al. Expiration: December 1995 [Page 31] Internet Draft RSVP Specification June 1995 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 (together with the 'Optional' flag bit) 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. If Class-Num < 128, then the node should ignore the object but forward it (unmerged). If Class-Num >= 128, the message should be rejected and an "Unknown Object Class" error returned. Note that merging cannot be performed on unknown object types; as a result, unmerged objects may be forwarded to the first node that does know how to merge them. The scaling limitations that this imposes must be considered when defining and deploying new object types. 4.1.3 Path Message PATH messages carry information from senders to receivers along the paths used by the data packets. The IP destination address of a PATH message is the DestAddress for the session; the source address is an address of the node that sent the message (preferably the address of the interface through which it was sent). The PHOP (i.e., the RSVP_HOP) object of each PATH message should contain the IP source address. The format of a PATH message is as follows: ::= [ ] [ ] ::= | ::= [ ] [ ] [ ] Each sender descriptor defines a sender, and the sender descriptor list allows multiple sender descriptors to be packed Braden, Zhang, et al. Expiration: December 1995 [Page 32] Internet Draft RSVP Specification June 1995 into a PATH message. For each sender in the list, the SENDER_TEMPLATE object defines the format of data packets; in addition, a SENDER_TSPEC object may specify the traffic flow, a POLICY_DATA object may specify user credential and accounting information, and an ADSPEC object may carry advertising (OPWA) data. Each sender host must periodically send PATH message(s) containing a sender descriptor for each its own data stream(s). Each sender descriptor is forwarded and replicated as necessary to follow the delivery path(s) for a data packet from the same sender, finally reaching the applications on all receivers (except that it is not looped back to a receiver included in the same application process as the sender). It is an error to send ambiguous path state, i.e., two or more Sender Templates that are different but overlap, due to wildcards. For example, if we represent a Sender Template as (IP address, sender port, protocol id and use `*' to represent a wildcard, then each of the following pairs of Sender Templates would be an error: (10.1.2.3, 34567, *) and (10.1.2.3, *, *) (10.1.2.3, 34567, *) and (10.1.2.3, 34567, 17) A PATH message received at a node is processed to create path state for all senders defined by SENDER_TEMPLATE objects in the sender descriptor list. If present, 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 all senders implied by the SENDER_TEMPLATEs. Periodically, the path state is scanned to create new PATH messages which are forwarded upstream. A node must independently compute the route for each sender descriptor being forwarded. These routes, obtained from uni-/multicast routing, generally depend upon the (sender host address, DestAddress) pairs and consist of a list of outgoing interfaces. The descriptors being forwarded through the same outgoing interface may be packed into as few PATH messages as possible. Note that multicast routing of path information is based on the sender address(es) from the sender descriptors, not the IP source address; this is necessary to prevent routing loops; see Section 4.3. Multicast routing may also report the expected incoming Braden, Zhang, et al. Expiration: December 1995 [Page 33] Internet Draft RSVP Specification June 1995 interface (i.e., the shortest path back to the sender). If so, any PATH message that arrives on a different interface should be discarded immediately. It is possible that routing will report no routes for a (sender, DestAddress) pair; path state for this sender should be stored locally but not forwarded. 4.1.4 Resv Messages RESV messages carry reservation requests hop-by-hop from receivers to senders, along the reverse paths of data flow 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 NHOP (i.e., the RSVP_HOP) object must contain the IP address of the (incoming) interface through which the RESV message is sent. The RESV message format is as follows: ::= [ ] [ ] [ ]