Internet Draft R. Braden, Ed. Expiration: September 1995 ISI File: draft-ietf-rsvp-spec-05.txt L.Zhang PARC D. Estrin ISI S. Herzog ISI S. Jamin USC Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification March 24, 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: September 1995 [Page 1] Internet Draft RSVP Specification March 1995 What's Changed Since Toronto IETF This version of the document incorporates many of the protocol changes agreed to at the December 1994 IETF meeting in San Jose. The most major changes are: o The RSVP packet format has been reorganized to carry most data as typed variable-length objects. o This generality includes provision for 16-byte IP6 addresses. o Filter specs have been simplified. o DF style has been moved to an Appendix, as experimental. o UDP encapsulation has been included. o OPWA has been included. o The Drop flag has been eliminated. o Session groups have been added. o The routing of RERR messages has been changed. 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 Braden, Zhang, et al. Expiration: September 1995 [Page 2] Internet Draft RSVP Specification March 1995 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. 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 a particular outgoing link for packet transmission, and it 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). Braden, Zhang, et al. Expiration: September 1995 [Page 3] Internet Draft RSVP Specification March 1995 At each node, the RSVP program applies a local decision procedure, called "admission control", to determine if it can supply the 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]. Braden, Zhang, et al. Expiration: September 1995 [Page 4] Internet Draft RSVP Specification March 1995 The remainder of this section describes the RSVP reservation 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. Braden, Zhang, et al. Expiration: September 1995 [Page 5] Internet Draft RSVP Specification March 1995 Senders Receivers _____________________ ( ) ===> R1 S1 ===> ( Multicast ) ( ) ===> R2 ( distribution ) S2 ===> ( ) ( by Internet ) ===> R3 (_____________________) Figure 2: Multicast Distribution Session 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 packet scheduler in the node (assuming that admission control succeeds), while the filter spec is used to set parameters in the packet classifier. 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 general RSVP reservation model allows filter specs to 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, considerations of both architectural purity and practical requirements have led to the decision that RSVP should use separate sessions for distinct subflows of hierarchically-encoded signals. For multicast sessions, subflows can be distinguished by multicast destination address; for unicast sessions, they must be Braden, Zhang, et al. Expiration: September 1995 [Page 6] Internet Draft RSVP Specification March 1995 distinguished by destination port. As a result of these considerations, the present RSVP version includes a quite restricted definition of filter specs, selecting only on sender IP address and UDP/TCP port number, and on protocol id. However, the design of the protocol would easily handle a more general definition in future versions. Any packets that are addressed to a particular session but do not match any of the filter specs for that session will be sent as best-effort traffic. Under congested conditions, such packets are likely to experience long delays and may be dropped. A receiver may wish to conserve network resources by explicitly asking the network to drop those data packets for which there is no reservation; however, such dropping should be performed by routing, not by RSVP. 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). (Note that this document always uses 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. 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 it fails this test, the reservation is rejected and RSVP sends back an error message towards the responsible receiver(s). If it passes, the flowspec is used to set up the packet scheduler for the desired QoS and the filter spec is used to set the packet classifier to select the appropriate data packets. 2. Forward reservation upstream. The reservation request is propagated upstream towards the appropriate senders. The set of senders 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 possible (at least in theory) for the kernel to modify the flowspec hop-by-hop (although currently no realtime services do Braden, Zhang, et al. Expiration: September 1995 [Page 7] Internet Draft RSVP Specification March 1995 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.3. For both of these primary actions, there are options controlled by the receiver making the reservation. These options are combined into a control variable called the reservation "style", which is discussed in section 1.3. One option concerns the treatment of reservations for different senders within the same session: establish a "distinct" reservation for each upstream sender, or else "mix" all senders' packets into a single reservation. Another option controls the scope of the request: "unitary" (i.e., a single specified sender), an explicit sender list, or a "wildcard" that implicitly selects all senders upstream of the given node. 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; the QoS request is 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 Each RSVP reservation request specifies a "reservation style". The following reservation styles are defined in this version of the protocol. 1. Wildcard-Filter (WF) Style The WF style specifies the options: "mixing" 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 Braden, Zhang, et al. Expiration: September 1995 [Page 8] Internet Draft RSVP Specification March 1995 of 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 senders. A WF-style reservation automatically extends to new senders to the session as they appear. 2. Fixed-Filter (FF) Style The FF style specifies the options: "distinct" reservation and a "unitary" reservation scope. Thus, an elementary FF- style reservation request creates a distinct reservation for data packets from a particular sender, not mixing them with other senders' packets for the same session. 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. WF reservations are 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 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. The WF and FF styles are incompatible and cannot be combined within a session. Other reservation styles may be defined in the future (see Appendix C). 2. RSVP Protocol Mechanisms 2.1 RSVP Messages There are two fundamental RSVP message types, RESV messages and PATH messages. 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 senders within the scope. RESV messages are delivered to the sender hosts, so that the hosts can set up appropriate traffic Braden, Zhang, et al. Expiration: September 1995 [Page 9] Internet Draft RSVP Specification March 1995 control parameters for the first hop. If a reservation request fails at any node, an RSVP error message is returned to the receiver; however, RSVP sends no positive acknowledgment messages to indicate success. Sender Receiver _____________________ Path --> ( ) Si =======> ( Multicast ) Path --> <-- Resv ( ) =========> Rj ( distribution ) <-- Resv (_____________________) Figure 3: RSVP Messages Each sender transmits RSVP PATH messages forward along the uni- /multicast routes provided by the routing protocol(s); see Figure 3. 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, without 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. o Tspec The PATH message may optionally carry a flowspec containing only a Tspec, defining 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". Braden, Zhang, et al. Expiration: September 1995 [Page 10] Internet Draft RSVP Specification March 1995 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 4: Router Using RSVP Figure 4 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 4, 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 message forwarded to a particular previous hop carries a flowspec that is the "maximum" over the effective reservations on the Braden, Zhang, et al. Expiration: September 1995 [Page 11] Internet Draft RSVP Specification March 1995 corresponding outgoing interfaces. Both cases represent merging, which is discussed further below. There are a number of ways for a new reservation request to fail in a given node. 1. There may be no matching path state (i.e., the scope may empty), which would prevent the reservation being propagated upstream. 2. Its 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. 3. Its style may be incompatible with the style(s) of reservations that exist on other outgoing interfaces but will be merged with this reservation when a refresh message to create a refresh message for the previous hop. 4. The effective flowspec may fail admission control. In any of these cases, an error message is returned to the receiver(s) responsible for the message, but 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. 2.2 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. It is not necessary (although it may be desirable, since the resources being consumed may be "valuable"), to explicitly tear down an old reservation. 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, while 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 message that does not modify the existing state at the node in question.) Braden, Zhang, et al. Expiration: September 1995 [Page 12] Internet Draft RSVP Specification March 1995 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 refresh 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 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 next section. However, 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 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 the appropriate adjustment in the distributed RSVP state, and immediate propagation to the succeeding nodes. 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, and its state should be created and timed out independently. Management of RSVP state is complex because there may not be a one-to-one correspondence between state carried in RSVP control messages and the resulting state in nodes. Due to merging, a single message contain state referring to multiple stored elements. Conversely, due to reservation sharing, a single stored state element may depend upon (typically, the maximum of) state values received in multiple control messages. Braden, Zhang, et al. Expiration: September 1995 [Page 13] Internet Draft RSVP Specification March 1995 2.3 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. Although flowspecs are opaque to RSVP, an RSVP daemon must be able to calculate the "largest" of a set of flowspecs. This is required both to calculate the effective flowspec to install on a given physical interface (see the discussion in connection with Figure 4), 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 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. 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 prohibits packing different sessions into the same RSVP message). 2.4 Teardown RSVP teardown messages remove path and reservation state without waiting for the cleanup timeout period, as an optimization to release resources quickly. Although teardown messages (like other RSVP messages) are not delivered reliably, the state will time out even if it is not explicitly deleted. 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. A router may also initiate a teardown message as the result of router or link failures detected by the routing protocol. Once initiated, a teardown request should be forwarded Braden, Zhang, et al. Expiration: September 1995 [Page 14] Internet Draft RSVP Specification March 1995 hop-by-hop without delay. To increase the reliability of teardown, Q copies of any given teardown message can be sent. Note that a node cannot actually delete the state being torn down until it has sent Q Teardown messages; it must place the state in a "moribund" status meanwhile. The appropriate value of Q is an engineering issue. Q = 1 would be the simplest and may be adequate, since unrefreshed state will time out anyway; teardown is an optimization. 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 tears down path state along the way. A RTEAR message tears down 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 change. As a result, an RTEAR message will prune the reservation state back (only) as far as possible. Note that the RTEAR message will cease to be forwarded at the same node where merging suppresses forwarding of the corresponding RESV messages. The change will be propagated as a new teardown message if the result has been to remove all state for this session at this node. However, the result may simply be to change the propagated information; thus, the receipt of a RTEAR message may result in the immediate forwarding of a modified RESV refresh message. Deletion of path state, whether as the result of a teardown message or because of timeout, may force adjustments in order in related reservation state to maintain consistency in the local node. For example, when a PTEAR deletes the path state for a sender S, the adjustment in reservation depends upon the style: if the style is WF and S is the only sender to the session, delete the reservation; if the style is FF, delete only reservations for sender S. These reservation changes should not trigger an immediate RESV refresh message, since the teardown message will have already made the required changes upstream. However, at the node in which an RTEAR message stops, the change of reservation state may trigger a RESV refresh starting at that node. Braden, Zhang, et al. Expiration: September 1995 [Page 15] Internet Draft RSVP Specification March 1995 2.5 Security There are two distinct types of security concerns in RSVP. 1. Protecting RSVP Message Integrity It may be necessary to ensure the integrity of RSVP messages against corruption or spoofing, hop by hop. RSVP messages have an optional integrity field that can be created and verified by neighboring RSVP nodes. 2. Authenticating Reservation Requests RSVP-mediated resource reservations may reserve network resources, providing special treatment for a particular set of users. Administrative mechanisms will be necessary to control who gets privileged service and to collect billing information. These mechanisms may require secure authentication of senders and/or receivers responsible for the reservation. RSVP messages may contain credential information to verify user identity. The RSVP packet formats provide for both; see Section 4. 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 there is sufficient excess capacity through such a cloud, acceptable and useful realtime service may still be possible. 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 towards the source. Braden, Zhang, et al. Expiration: September 1995 [Page 16] Internet Draft RSVP Specification March 1995 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 Session Groups Section 1.2 explained that a distinct destination address, and therefore a distinct session, will be used for each of the subflows in a hierarchically encoded flow. However, these separate sessions are logically related. For example it may be necessary to pass reservations for all subflows to Admission Control at the same time (since it would be nonsense to admit high frequency components but reject the baseband component of the session data). Such a logical grouping is indicated in RSVP by defining a "session group", an ordered set of sessions. To declare that a set of sessions form a session group, a receiver includes a data structure we call a SESSION_GROUP object in the RESV message for each of the sessions. A SESSION_GROUP object contains four fields: a reference address, a session group ID, a count, and a rank. o The reference address is an agreed-upon choice from among the DestAddress values of the sessions in the group, for example the smallest numerically. o The session group ID is used to distinguish different groups with the same reference address. o The count is the number of members in the group. o The rank, an integer between 1 and count, is different in each session of the session group. The SESSION_GROUP objects for all sessions in the group will contain the same values of the reference address, the session group ID, and the count value. The rank values establishes the desired order among them. If RSVP at a given node receives a RESV message containing a SESSION_GROUP object, it should wait until RESV messages for all `count' sessions have appeared (or until the end of the refresh Braden, Zhang, et al. Expiration: September 1995 [Page 17] Internet Draft RSVP Specification March 1995 cycle) and then pass the RESV requests to Admission Control as a group. It is normally expected that all sessions in the group will be routed through the same nodes. However, if not, only a subset of the session group reservations may appear at a given node; in this case, the RSVP should wait until the end of the refresh cycle and then perform Admission Control on the subset of the session group that it has received. The rank values will identify which are missing. Note that routing different sessions of the session group differently will generally result in delays in establishing or rejecting the desired QoS. A "bundling" facility could be added to multicast routing, to force all sessions in a session group to be routed along the same path. 2.8 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. In order to join an RSVP session, 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 listens for PATH messages. H4 A receiver starts sending appropriate RESV messages, specifying the desired flow descriptors, using RSVP. H5 A sender starts sending data packets. There are several synchronization considerations. o Suppose that a new sender starts sending data (H5) 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 (H5), and there are Braden, Zhang, et al. Expiration: September 1995 [Page 18] Internet Draft RSVP Specification March 1995 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. o If a receiver starts sending RESV messages (H4) before any PATH messages have reached it (H5) (and if path state is being used to route RESV messages), 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( *{Q}) Here "*{Q}" represents a Flow Descriptor with a "wildcard" scope (choosing all senders) and a flowspec of quantity Q. 2. Fixed-Filter FF( S1{Q1}, S2{Q2}, ...) A list of (sender, flowspec) pairs, i.e., flow descriptors, packed into a single RESV message. 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 5 shows schematically a router with two previous hops labeled (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 5, we must also specify the Braden, Zhang, et al. Expiration: September 1995 [Page 19] Internet Draft RSVP Specification March 1995 multicast routing within this node. Assume first that data packets (hence, PATH messages) from each Si shown in Figure 5 is routed to both outgoing interfaces. Under this assumption, Figures 6 and 7 illustrate Wildcard-Filter reservations and Fixed-Filter reservations, respectively. ________________ (a)| | (c) ( S1 ) ---------->| |----------> ( R1, R2) | Router | (b)| | (d) ( S2,S3 ) ------->| |----------> ( R3 ) |________________| Figure 5: Router Configuration In Figure 6, the "Receive" column shows the RESV messages received over outgoing interfaces (c) and () 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. | Send | Reserve Receive | | _______ WF( *{3B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} ) | |_______| | -----------------------|---------------------------------------- | _______ WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) | |_______| Figure 6: Wildcard-Filter Reservation Example 1 Figure 7 shows Fixed-Filter 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 Braden, Zhang, et al. Expiration: September 1995 [Page 20] Internet Draft RSVP Specification March 1995 reservation for each source that has been requested, but this private reservation is shared among the receivers that made the request. | 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 7: Fixed-Filter Reservation Example The two examples just shown assume full routing, i.e., data packets from S1, S2, and S3 are routed to both outgoing interfaces. Assume the routing shown in Figure 8, in which 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). _______________ (a)| | (c) ( S1 ) ---------->| --------->--> |----------> ( R1, R2) | / | | / | (b)| / | (d) ( S2,S3 ) ------->| ->----------> |----------> ( R3 ) |_______________| Figure 8: Router Configuration Under this assumption, Figure 9 shows Wildcard-Filter reservations. Since there is no route from (a) to (d), the reservation forwarded out interface (a) considers only the reservation on interface (c), so no merging takes place in this case. Braden, Zhang, et al. Expiration: September 1995 [Page 21] Internet Draft RSVP Specification March 1995 | Send | Reserve Receive | | _______ WF( *{B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} ) | |_______| | -----------------------|---------------------------------------- | _______ WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) | |_______| Figure 9: Wildcard-Filter Reservation Example -- Partial Routing Braden, Zhang, et al. Expiration: September 1995 [Page 22] Internet Draft RSVP Specification March 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" using a common structure. 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 | Type | Flags | Message Length | +-------------+-------------+-------------+-------------+ | RSVP Checksum | Object Count | +-------------+-------------+-------------+-------------+ The common header fields are as follows: Vers Protocol version number. This is version 2. Type 1 = PATH 2 = RESV 3 = PERR 4 = RERR 5 = PTEAR 6 = RTEAR Flags 0x01 = Entry-Police Braden, Zhang, et al. Expiration: September 1995 [Page 23] Internet Draft RSVP Specification March 1995 This flag should be on in a PATH message sent by an RSVP daemon in a sender host. The first RSVP node that finds the flag on in a PATH message (i.e., the first-[RSVP-]hop router) should institute policing for the flow(s) described in this message. This flag should never be forwarded in PATH refresh messages. 0x02 = LUB-Used This flag is described below in the section on Error Messages. Message Length The total length of this RSVP message, including this common header and the objects included in Object Count. RSVP Checksum A standard TCP/UDP checksum over the contents of the RSVP message, with the checksum field replaced by zero. Object Count Count of 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 | C-Type | +-------------+-------------+-------------+-------------+ | | // (Object contents) // | | +-------------+-------------+-------------+-------------+ An object header has the following fields: Length Total length in bytes. Must always be a multiple of 4, and at least 4. Braden, Zhang, et al. Expiration: September 1995 [Page 24] Internet Draft RSVP Specification March 1995 Class Object class. In this document, the names of object classes are capitalized. 0 = NULL A NULL object has a Class of zero; 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. 1 = SESSION Contains the IP destination address (DestAddress) and possibly a generalized source port, to define a specific session for the other objects that follow. Required in every RSVP message. 2 = SESSION_GROUP When present, defines a session group, a set of related sessions whose reservation requests should be passed collectively to Admission Control. 3 = 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. 4 = STYLE Defines the reservation style plus style-specific information that is not a FLOWSPEC or FILTER_SPEC object, in a RESV message. 5 = FLOWSPEC Defines a desired QoS, in a RESV message. 6 = FILTER_SPEC Defines a subset of session data packets that should receive the desired QoS (specified by an FLOWSPEC Braden, Zhang, et al. Expiration: September 1995 [Page 25] Internet Draft RSVP Specification March 1995 object), in a RESV message. 7 = SENDER_TEMPLATE Contains a sender IP address and perhaps some additional demultiplexing information to identify a sender, in a PATH message. 8 = SENDER_TSPEC Defines the traffic characteristics of a sender's data stream, in a PATH message. 9 = ADVERT Carries an Adspec containing OPWA data, in a PATH message. 10 = 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. 11 = ERROR_SPEC Specifies an error, in a PERR or RERR message. 12 = CREDENTIAL Contains user credential and/or information for policy control and/or accounting. 13 = INTEGRITY Contains a cryptographic data to authenticate the originating node, and perhaps verify the contents, of this RSVP message. C-Type Object type; unique within Class. Values defined in Appendix A. The Class and C-Type fields may be used together as a 16-bit number to define a unique type for each object. The formats of specific object types are defined in Appendix A. Braden, Zhang, et al. Expiration: September 1995 [Page 26] Internet Draft RSVP Specification March 1995 4.1.3 Path Message PATH messages carry information from senders to receivers along the same paths, and using the same uni-/multicast routes, as the data packets. The IP destination address of a PATH message is the DestAddress for the session, and the source address is an address of the node that sent the message (if possible, the address of the particular interface through which it was sent). 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 into a PATH message. For each sender in the list, the SENDER_TEMPLATE object defines the format of data packets, the SENDER_TSPEC object may specify the traffic flow, and the CREDENTIAL object may specify the user credentials. There may also be an ADVERT object carrying advertising (OPWA) data. Each sender host must periodically send a PATH message containing the sender descriptor(s) describing its own data stream(s), for a given session. 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 not a receiver included in the sender process). At each node, a route must be computed independently for each sender descriptors being forwarded. These routes, obtained from the uni/multicast routing table, generally depend upon the (sender host address, DestAddress) pairs, and consist of a list of outgoing interfaces. Then the descriptors being forwarded through the same outgoing interface can be packed into as few Braden, Zhang, et al. Expiration: September 1995 [Page 27] Internet Draft RSVP Specification March 1995 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. PHOP (i.e., the RSVP_HOP object) of each PATH message should contain the IP source address, the interface address through which the message is sent. PATH messages are processed at each node they reach to create path state, which includes SENDER_TEMPLATE object and possibly CREDENTIAL, SENDER_TSPEC, and ADVERT objects. If an error is encountered while processing a PATH message, a PERR message is sent to all senders implied by the SENDER_TEMPLATEs in the sender descriptor list. 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 Next Hop address (in the RSVP_HOP object) should be the IP address of the (incoming) interface through which the RESV message is sent. The IP source address is an address of the node that sent the message (if possible, the address of the particular interface through which it was sent). The permissible sequence of objects in a RESV message depends upon the reservation style specified in the STYLE object. Currently, object types Style-WF and Style-FF of class STYLE are defined (see Appendix A). The RESV message format is as follows: ::= [ ] [ ] [ ] [ ] ::= [ ] | Braden, Zhang, et al. Expiration: September 1995 [Page 28] Internet Draft RSVP Specification March 1995 ::= | The reservation scope, i.e., the set of senders towards which a particular reservation is to be forwarded, is determined by matching FILTER_SPEC objects against the path state created from SENDER_TEMPLATE objects, considering any wildcards that may be present. 4.1.5 Error Messages There are two types of RSVP error messages: o PERR messages result from PATH messages and travel towards senders. PERR messages are routed hop-by-hop like RESV messages; at each hop, the IP destination address is the unicast address of a previous hop. o RERR messages result from RESV messages and travel hop- by-hop towards the appropriate receivers, routed by the reservation state. At each hop, the IP destination address is the unicast address of a next-hop node. Routing is discussed below. RSVP error messages are triggered only by processing of PATH and RESV messages; errors encountered while processing error or teardown messages must not create error messages. ::= [ ] ::= (see earlier definition) ::= [ ] [ ] Braden, Zhang, et al. Expiration: September 1995 [Page 29] Internet Draft RSVP Specification March 1995 ::= (see earlier definition) The ERROR_SPEC specifies the error. It includes the IP address of the node that detected the error, called the Error Node Address. When a PATH or RESV message has been "packed" with multiple sets of elementary parameters, the RSVP implementation should process each set independently and return a separate error message for each that is in error. An error message may be duplicated and forwarded unchanged. In general, error messages should be delivered to the applications on all the session nodes that (may have) contributed to this error. o A PERR message is forwarded to all previous hops for all senders listed in the Sender Descriptor List. o The node that creates a RERR message as the result of processing a RESV message should send the RERR message out the interface through which the RESV arrived. In succeeding hops, the routing of a RERR message depends upon its style and upon routing. In general, a RERR message is sent out some subset of the outgoing interfaces specified for multicast routing, using Error Node Address as the source address and DestAddress as the destination. (This rule is necessary to prevent packet loops; see Section 4.3 below). Within this set of outgoing interfaces, a RERR message is sent only to next hop(s) whose RESV message(s) created the error; this in turn depends upon the merging of flowspecs. Assume that a reservation whose error is being reported was formed by merging two flowspecs Q1 and Q2 from different next hops. - If Q1 = Q2, the error message should be forwarded to both next hops. - If Q1 < Q2, the error message should be forwarded only to the next hop for Q2. - If Q1 and Q2 are incomparable, the error message should be forwarded to both next hops, and the LUB flag should be turned on. Braden, Zhang, et al. Expiration: September 1995 [Page 30] Internet Draft RSVP Specification March 1995 The ERROR_SPEC and the LUB-flag should be delivered to the receiver application. In the case of an Admission Control error, the style-specific tail will contain the FLOWSPEC object that failed. If the LUB-flag is off, this should be the same as a FLOWSPEC in a RESV message sent by this application; otherwise, they may differ. An error in a 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 CREDENTIAL object may be detected anywhere along the path(s) to the sender(s). 4.1.6 Teardown Messages There are two types of RSVP Teardown message, PTEAR and RTEAR. o PTEAR messages delete path state (which in turn may delete reservations state) and travel towards all receivers that are downstream from the point of initiation. PTEAR messages are routed like PATH messages, and their IP destination address is DestAddress for the session. o RTEAR messages delete reservation state and travel towards all matching senders upstream from the point of teardown initiation. RTEAR message are routed like RESV messages, and their IP destination address is the unicast address of a previous hop. ::= [ ] ::= (see earlier definition) ::= [ ] [ ] ::= (see earlier definition) Flowspec objects in the style-specific tail of a RTEAR message Braden, Zhang, et al. Expiration: September 1995 [Page 31] Internet Draft RSVP Specification March 1995 will be ignored and may be omitted. If the state being deleted was created with user credentials from a CREDENTIAL field, then the matching PTEAR or RTEAR message must include matching CREDENTIAL field(s). [There is a problem here: tearing down path state may implicitly delete reservation state. But a PTEAR message does not have credentials for the reservation state, only for the path state. Some argue that a CREDENTIAL may not be needed in teardown messages, on the assumption that false teardown messages can be injected only with the collusion of routers along the data path, and in that case, the colluding router can just as well stop delivering the RESV messages, which will have the same effect.] 4.2 Sending RSVP Messages RSVP messages are sent hop-by-hop between RSVP-capable routers as "raw" IP datagrams, protocol number 46. Raw IP datagrams are similarly intended to be used between an end system and the first/last hop router; however, it is also possible to encapsulate RSVP messages as UDP datagrams for end-system communication, as described in Appendix C. UDP encapsulation will simplify installation of RSVP on current end systems, particularly when firewalls are in use. Under overload conditions, lost RSVP control messages could cause the loss of resource reservations. Routers should be configured to give a preferred class of service to RSVP packets. RSVP should not use significant bandwidth, but the queueing delay for RSVP messages needs to be controlled. An RSVP PATH or RESV message consists of a small root segment followed by a variable-length list of objects, which may overflow the capacity of one datagram. IP fragmentation is inadvisable, since it has bad error characteristics; RSVP-level fragmentation should be used. That is, a message with a long list of descriptors will be divided into segments that will fit into individual datagrams, each carrying the same root fields. Each of these messages will be processed at the receiving node, with a cumulative effect on the local state. No explicit reassembly is needed. Since RSVP messages are normally expected to be generated and sent hop-by-hop, their MTU should be determined by the MTU of each interface. Braden, Zhang, et al. Expiration: September 1995 [Page 32] Internet Draft RSVP Specification March 1995 [There may be rare instances in which this does not work very well, and in which manual configuration would not help. The problem case is an interface connected to a non-RSVP cloud in which some particular link far away has a smaller MTU. This would affect only those sessions that happened to use that link. Proper solution to this case would require MTU discovery separately for each interface and each session, which is a very large amount of machinery and some overhead for a rare (?) case. Best approach seems to be to rely on IP fragmentation and reassembly for this case.] 4.3 Avoiding RSVP Message Loops We must ensure that the rules for forwarding RSVP control messages avoid looping. In steady state, PATH and RESV messages are forwarded on each hop only once per refresh period. This avoids directly looping packets, but there is still the possibility of an " auto-refresh" loop, clocked by the refresh period. The effect of such a loop is to keep state active "forever", even if the end nodes have ceased refreshing it (but the state will be deleted when the receivers leave the multicast group and/or the senders stop sending PATH messages). In addition, error and teardown messages are forwarded immediately and are therefore subject to direct looping. PATH messages are forwarded using routes determined by the appropriate routing protocol. For routing that is source- dependent (e.g., some multicast routing algorithms), the RSVP daemon must route each sender descriptor separately using the source addresses found in the SENDER_TEMPLATE objects. This should ensure that there will be no auto-refresh loops of PATH information, even in a topology with cycles. Since PATH messages don't loop, they create path state defining a loop-free reverse path to each sender. As a result, RESV and RTEAR messages directed to particular senders cannot loop. PERR messages are always directed to particular senders and therefore cannot loop. However, there is a potential auto-refresh problem for RESV, RTEAR, and RERR messages with wildcard scope, as we now discuss. If the topology has no loops, then auto-refresh can be avoided, even for wildcard scope, with the following rule: A reservation request received from next hop N must not be forwarded to N. Braden, Zhang, et al. Expiration: September 1995 [Page 33] Internet Draft RSVP Specification March 1995 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 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 reservation requests in the two directions, without an auto-refresh loop. ________________ a | | c ( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) |________________| Send & Receive on (a) | Send & Receive on (c) | WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) | WF( *{4B}) --> (a) | (c) --> WF( *{4B}) | | Reserve on (a) | Reserve on (c) __________ | __________ | * {4B} | | | * {3B} | |__________| | |__________| | Figure 10: Avoiding Auto-Refresh in Non-Looping Topology However, further effort is needed to prevent auto-refresh loops from wildcard-scope reservations in the presence of cycles in the topology. [TBD!!]. We treat routing of RERR messages as a special case. They are sent with unicast addresses of next hops, but the multicast routing is used to prevent loops. As explained above, RERR messages are forwarded to a subset of the multicast tree to DestAddress, rooted at the node on which the error was discovered. Since multicast routing cannot create loops, this will prevent loops for RERR messages. [Open question about Figure 10: should it be possible to have incompatible reservation styles on the two interfaces? For example, if R1 requests a WF reservation and R2 requests a FF reservation, it is logically possible to make the corresponding reservations on the two different interfaces. The current Braden, Zhang, et al. Expiration: September 1995 [Page 34] Internet Draft RSVP Specification March 1995 implementation does NOT allow this; instead, it prevents mixing of incompatible styles in the same session on a node, even if they are on different interfaces.] 4.4 Local Repair Each RSVP daemon periodically sends refreshes to its next/previous hops. An important optimization would allow the local routing protocol module to notify the RSVP daemon of route changes for particular destinations. The RSVP daemon should use this information to trigger an immediate refresh of state for these destinations, using the new route. This allows fast adaptation to routing changes without the overhead of a short refresh period. 4.5 Time Parameters For each element of state, there are two time parameters: the refresh period R and the time-to-live value T. R specifies the period between sending successive refreshes of this data. T controls how long state will be retained after refreshes stop appearing, and depends upon period between receiving successive refreshes. Specifically, R <= T, and the "cleanout time" is K * T. Here K is a small integer; K-1 successive messages may be lost before state is deleted. Currently K = 3 is suggested. Clearly, a smaller T means increased RSVP overhead. If the router does not implement local repair, a smaller T improves the speed of adapting to routing changes. With local repair, a router can be more relaxed about T, since the periodic refresh becomes only a backstop robustness mechanism. There are three possible ways for a router to determine R and T. o Default values are configured in the router. Current defaults are 30 seconds for T and R. o A router may adjust the value of T dynamically to keep a constant total overhead due to refresh traffic; as more sessions appear, the period would be lengthened. In this case, R = T could be used. o R and T can be specified by the end systems. For this purpose, PATH and RESV messages may contain the optional TIM_VALUES object. When messages are merged and forwarded to the next hop, R should be the minimum R that has been received, and T should be the maximum T that has been received. Thus, the largest T determines how long state is retained, and the smallest R determines the responsiveness of Braden, Zhang, et al. Expiration: September 1995 [Page 35] Internet Draft RSVP Specification March 1995 RSVP to route changes. In the first hop, they are expected to be equal. The RSVP API might allow an application to override the default value for a particular session. Braden, Zhang, et al. Expiration: September 1995 [Page 36] Internet Draft RSVP Specification March 1995 4.6 RSVP Interfaces RSVP on a router has interfaces to routing and to traffic control in the kernel. RSVP on a host has an interface to applications (i.e, an API) and also an interface to traffic control (if it exists on the host). 4.6.1 Application/RSVP Interface This section describes a generic interface between an application and an RSVP control process. The details of a real interface may be operating-system dependent; the following can only suggest the basic functions to be performed. Some of these calls cause information to be returned asynchronously. o Register Call: REGISTER( DestAddress , DestPort [ , SESSION_object ] , SND_flag , RCV_flag [ , Source_Address ] [ , Source_Port ] [ , Sender_Template ] [ , Sender_Tspec ] [ , Data_TTL ] [ , UserCredential ] [ , Upcall_Proc_addr ] ) -> Session-id This call initiates RSVP processing for a session, defined by DestAddress together with the TCP/UDP port number DestPort. If successful, the REGISTER call returns immediately with a local session identifier Session-id, which may be used in subsequent calls. The SESSION_object parameter is included as an escape mechanism to support some more general definition of the session ("generalized destination port"), should that be necessary in the future. Normally SESSION_object will be omitted; if it is supplied, it should be an appropriately-formatted representation of a SESSION object. SND_flag should be set true if the host will send data, and RCV_flag should be set true if the host will receive data. Setting neither true is an error. The optional parameters Source_Address, Source_Port, Sender_Template, Braden, Zhang, et al. Expiration: September 1995 [Page 37] Internet Draft RSVP Specification March 1995 Sender_Tspec, and Data_TTL are all concerned with a data source, and they will be ignored unless SND_flag is true. If SND_FLAG is true, a successful REGISTER call will cause RSVP to begin sending PATH messages for this session using these parameters, which are interpreted as follows: - Source_Address This is the address of the interface from which the data will be sent. If it is omitted, a default interface will be used. - Source_Port This is the UDP/TCP port from which the data will be sent. If it is omitted or zero, the port is "wild" and can match any port in a FILTERSPEC. - Sender_Template This parameter is included as an escape mechanism to support a more general definition of the sender ("generalized source port"). Normally this parameter may be omitted; if it is supplied, it should be an appropriately formatted representation of a SENDER_TEMPLATE object. - Sender_Tspec This parameter is a Tspec describing the traffic flow to be sent. It may be included to prevent over- reservation on the initial hops. - Data_TTL This is the (non-default) IP Time-To-Live parameter that is being supplied on the data packets. It is needed to ensure that Path messages do not have a scope larger than multicast data packets. Finally, Upcall_Proc_addr is the address of an upcall procedure to receive asynchronous error or event notification; see below. o Reserve Call: RESERVE( session-id, style, style-dependent-parms ) Braden, Zhang, et al. Expiration: September 1995 [Page 38] Internet Draft RSVP Specification March 1995 A receiver uses this call to make a resource reservation for the session registered as `session-id'. The style parameter indicates the reservation style. The rest of the parameters depend upon the style, but generally these will include appropriate flowspecs and filter specs. The first RESERVE call will initiate the periodic transmission of RESV messages. A later RESERVE call may be given to modify the parameters of the earlier call (but note that changing the reservations may result in admission control failure, depending upon the style). The RESERVE call returns immediately. Following a RESERVE call, an asynchronous ERROR/EVENT upcall may occur at any time. o Release Call: RELEASE( session-id ) This call will terminate RSVP state for the session specified by session-id. It may send appropriate teardown messages and will cease sending refreshes for this session-id. o Error/Event Upcalls Call: (session-id, Info_type, List_count [ ,Error_code ,Error_value ,LUB-flag ] [ ,Filter_spec_list ] [ ,Flowspec_list ] [ ,Advert_list ] ) Here "Upcall_Proc" represents the upcall procedure whose address was supplied in the REGISTER call. This upcall may occur asynchronously at any time after a REGISTER call and before a RELEASE call, to indicate an error or an event. Currently there are three upcall types, distinguished by the Info_type parameter: 1. Info_type = Path Event A Path Event upcall indicates the receipt of a PATH message, indicating to the application that there is Braden, Zhang, et al. Expiration: September 1995 [Page 39] Internet Draft RSVP Specification March 1995 at least one active sender. This upcall provides synchronizing information to the receiver application, and it may also provide parallel lists of senders (in Filter_spec_list), traffic descriptions (in Flowspec_list), and service advertisements (in Advert_list). 'List_count' is the number in each list; where these objects are missing, corresponding null objects must appear. Error_code and Error_value, and LUB-flag should be ignored in a Path Event upcall. 2. Info_type = Path Error An Path Error event indicates an error in processing a sender descriptor originated by this sender. The Error_code parameter will define the error, and Error_value may supply some additional (perhaps system-specific) data about the error. `List_count' will be 1, and Filter_spec_list and Flowspec_list will contain the Sender_Template and the Sender_Tspec supplied in the REGISTER call; Advert_list will contain one NULL object. 3. Info_type = Resv Error An Resv Error event indicates an error in processing a RESV message to which this application contributed. The Error_code parameter will define the error, and Error_value may supply some additional (perhaps system-specific) data on the error. `List_count' will be 1, and Filter_spec_list and Flowspec_list will contain one FILTER_SPEC and one FLOWSPEC object. These objects are taken from the RESV message that caused the error (unless the LUB- flag is on, in which case FLOWSPEC may differ). Although RSVP messages indicating path events or errors may be received periodically, the API should make the corresponding asynchronous upcall to the application only on the first occurrence, or when the information to be reported changes. 4.6.2 RSVP/Traffic Control Interface In each router and host, enhanced QoS is achieved by a group of inter-related traffic control functions: a packet classifier, Braden, Zhang, et al. Expiration: September 1995 [Page 40] Internet Draft RSVP Specification March 1995 an admission control module, and a packet scheduler. This section describes a generic RSVP interface to traffic control. 1. Make a Reservation Call: Rhandle = TC_AddFlowspec( Flowspec, Police_Flag [ , Sender_Tspec] [ , SD_rank , SD_end_flag ] ) This call passes a Flowspec defining a desired QoS to admission control. It may also pass Sender_Tspec, the maximum traffic characteristics computed over the SENDER_TSPECs of senders that will contribute data packets to this reservation. Police_Flag is a Boolean parameter that indicates whether traffic policing should be applied at this point. The SD_rank and SD_end_flag fields are used for a member of a session group. SD_rank is the rank value from the SESSION_GROUP object. The call is made with each of the sessions in the group, and SD_end_flag is set true for the last one. This call returns an error code if Flowspec is malformed or if the requested resources are unavailable. Otherwise, it establishes a new reservation channel corresponding to Rhandle. It returns the opaque number Rhandle for subsequent references to this reservation. 2. Add Filter Call: TC_AddFilter( Rhandle, Session, Filterspec ) This call is used to define a filter corresponding to the given handle, following a successful TC_AddFlowspec call. 3. Modify or Delete Filter Call: TC_ModFilter( Rhandle, Session, [ new_Filterspec] ) This call can modify an existing filter or replace an Braden, Zhang, et al. Expiration: September 1995 [Page 41] Internet Draft RSVP Specification March 1995 existing filter with no filter (i.e., delete the filter). 4. Modify or Delete Flowspec Call: TC_ModFlowspec( Rhandle [, new_Flowspec [ ,Sender_Tspec]] ) This call can modify an existing reservation or delete the reservation. If new_Flowspec is included, it is passed to Admission Control; if it is rejected, the current flowspec is left in force. If new_Flowspec is omitted, the reservation is deleted and Rhandle is invalidated. 5. OPWA Update Call: TC_Advertise( interface, Adspec [ ,Sender_TSpec ] ) -> New_Adspec This call is used for OPWA to compute the outgoing advertisement New_Adspec for a specified interface. 6. Initialize Traffic Control Call: TC_Initialize(interface ) This call is used when RSVP initializes its state, to clear out all existing classifier and/or packet scheduler state for a specified interface. 4.6.3 RSVP/Routing Interface An RSVP implementation needs the following support from the packet forwarding and routing mechanism of the node. o Promiscuous receive mode for RSVP messages Any datagram received for IP protocol 46 is to be diverted to the RSVP program for processing, without being forwarded. The identity of the interface on which it is received should also be available to the RSVP daemon. o Route discovery Braden, Zhang, et al. Expiration: September 1995 [Page 42] Internet Draft RSVP Specification March 1995 RSVP must be able to discover the route(s) that the routing algorithm would have used for forwarding a specific datagram. GetUcastRoute( DestAddress ) -> OutInterface GetMcastRoute( SrcAddress, DestAddress ) -> OutInterface_list o Route Change Notification Routing may provide an asynchronous notification to RSVP that a specified route has changed. New_Ucast_Route( DestAddress ) -> new_OutInterface New_Mcast_Route( SrcAddress, DestAddress ) -> new_OutInterface_list o Outgoing Link Specification RSVP must be able to force a (multicast) datagram to be sent on a specific outgoing virtual link, bypassing the normal routing mechanism. A virtual link may be a real outgoing link or a multicast tunnel. Outgoing link specification is necessary because RSVP may send different versions of outgoing PATH messages on different interfaces, for the same source and destination addresses, and to avoid loops. o Discover Interface List RSVP must be able to learn what real and virtual interfaces exist. Braden, Zhang, et al. Expiration: September 1995 [Page 43] Internet Draft RSVP Specification March 1995 5. Message Processing Rules This generic description of RSVP operation assumes the following data structures. An actual implementation may use additional or different structures to optimize processing. o PSB -- Path State Block Each PSB holds path state for a particular (session, sender) pair, defined by SESSION and SENDER_TEMPLATE objects, respectively. PSB contents include a PHOP object and possibly SENDER_TSPEC, CREDENTIAL, and/or ADVERT objects from PATH messages. o RSB -- Reservation State Block RSB's are used to hold reservation state. Each RSB holds reservation state for the 4-tuple: (session, next hop, style, filterspec), defined in SESSION, NHOP (i.e., RSVP_HOP), STYLE, and FILTER_SPEC objects, respectively. We assume that RSB contents include the outgoing interface OI that is implied by NHOP. RSB contents also include a FLOWSPEC object and may include a CERTIFICATE object. MESSAGE ARRIVES Verify version number, checksum, and length fields of common header, and discard message if it fails. Further processing depends upon message type. PATH MESSAGE ARRIVES Start with the Refresh_Needed flag off. Each sender descriptor object sequence in the message defines a sender. Process each sender as follows. 1. If there is a CREDENTIAL object, verify it; if it is unacceptable, build and send a PERR message, drop the PATH message, and return. 2. If there is no path state block (PSB) for the (session, sender) pair then: o Create a new PSB. o Set a cleanup timer for the PSB. If this is the first Braden, Zhang, et al. Expiration: September 1995 [Page 44] Internet Draft RSVP Specification March 1995 PSB for the session, set a refresh timer for the session. o Copy PHOP into the PSB. Copy into the PSB any of the following objects that are present in the message: CREDENTIAL, SENDER_TSPEC, and/or ADVERT. Copy the EntryPolice flag from the common header into the PSB. o Call the appropriate route discovery routine, using DestAddress from SESSION and (for multicast routing) SrcAddress from SENDER_TEMPLATE. Store the resulting routing bit mask ROUTE_MASK in the PSB. 3. Otherwise (there is a matching PSB): o If CREDENTIAL differs between message and PSB, verify new CREDENTIAL. If it is acceptable, copy it into PSB. Otherwise, build and send a PERR message for "Bad Credential", drop the PATH message, and return. o Restart cleanup timer. o Update the PSB with values from the message, as follows. Copy the ADVERT object, if any, into the PSB. Copy the EntryPolice flag into the PSB. If the values of PHOP or SEND_TSPEC differ between the message and the PSB, copy the new values into the PSB and turn on the Refresh_Needed flag. If SEND_TSPEC has changed, reservations matching S may also change; this may be deferred until a RESV refresh arrives. o Call the appropriate route discovery routine and compare the route mask with the ROUTE_MASK value already in the PSB; if a new bit (interface) has been added, turn on the Refresh_Needed flag. Store new ROUTE_MASK in the PSB. 4. If the Refresh_Needed flag is now set, execute the PATH REFRESH event sequence (below). PATH TEAR MESSAGE ARRIVES o If there is no path state for this destination, drop the message and return. o Forward a copy of the PTEAR message using the same rules as Braden, Zhang, et al. Expiration: September 1995 [Page 45] Internet Draft RSVP Specification March 1995 for a PATH message (see PATH REFRESH). o Each sender descriptor in the PTEAR message contains a SENDER_TEMPLATE object defines a sender S; process it as follows. 1. Locate the PSB for the pair: (session, S). If none exists, continue with next sender descriptor. 2. Examine the RSB's for this session and delete any reservation state associated with sender S, depending upon the reservation style. For example: Delete a WF reservation for which S is the only sender. Delete an FF reservation for S. 3. Delete the PSB. PATH ERROR MESSAGE ARRIVES o If there are no existing PSB's for SESSION then drop the PERR message and return. o Look up the PSB for (session, sender); sender is defined by SENDER_TEMPLATE. If no PSB is found, drop PERR message and return. o If PHOP in PSB is local API, deliver error to application via an upcall: Call: ( session-id, Path Error, 1, Error_code, Error_value, 0, SENDER_TEMPLATE, NULL, NULL) Note that CREDENTIAL, SENDER_TSPEC, and ADVERT objects in the message is ignored. Otherwise (PHOP is not local API), forward a copy of the PERR message to the PHOP node. RESV MESSAGE ARRIVES Braden, Zhang, et al. Expiration: September 1995 [Page 46] Internet Draft RSVP Specification March 1995 A RESV message arrives through outgoing interface OI. o Check the SESSION object. If there are no existing PSB's for SESSION then build and send a RERR message (as described later) specifying "No Path Information", drop the RESV message, and return. However, do not send the RERR message if the style has wildcard reservation scope and this is not the receiver host itself. o Check the STYLE object. If style in the message conflicts with the style of any reservation for this session in place on any interface, reject the RESV message by building and sending a RERR message specifying "Bad Style", drop the RESV message, and return. o Check the CREDENTIAL object. Verify the CREDENTIAL field (if any) to check permission to create a reservation. [This check may also involve the CREDENTIAL fields from the PSB's in the scope of this reservation; in that case, it would better fit below in processing the individual flow descriptors.] o Check for path state If there are no PSB's matching the scope of this reservation, build and send a RERR message specifying "No Sender Information", drop the RESV message, and return. o Make reservations Process the style-specific tail sequence. For FF style, execute the following steps for each b flow descriptor, i.e., each (FLOWSPEC, FILTERSPEC) pair. For WF style execute the following once, using some internal placeholder "WILD_FILTER" for FILTERSPEC to indicate wildcard scope. 1. Find or create a reservation state block (RSB) for the 4-tuple: (SESSION, NHOP, style, FILTERSPEC). 2. Start or restart the cleanout timer on the RSB. Braden, Zhang, et al. Expiration: September 1995 [Page 47] Internet Draft RSVP Specification March 1995 3. Start a refresh timer for this session if none was started. 4. If the RSB existed and if FLOWSPEC and the SENDER_TSPEC objects are unchanged, drop the RESV message and return. 5. Compute Sender_Tspec as the maximum over the SENDER_TSPEC objects of the PSB's within the scope of the reservation. 6. Set Police_flag on if any PSB's in the scope have the EntryPolice flag on, or if the style is WF and there is more than one PSB in the scope, otherwise off. 7. Computer K_Flowspec, the effective kernel flowspec, as the maximum of the FLOWSPEC values in all RSB's for the same (SESSION, OI, FILTERSPEC) triple. Similarly, the kernel filter spec K_filter is either the FILTER_SPEC object under consideration (unitary scope), or it is WILD_FILTER (wildcard scope). If there was no previous kernel reservation in place for (SESSION, OI, FILTERSPEC), call the kernel interface module: TC_AddFlowspec( Sender_Tspec, K_flowspec, Police_Flag ) If this call fails, build and send a RERR message specifying "Admission control failed", drop the RESV message, and return. Otherwise, record the kernel handle K_handle returned by the call in the RSB(s). Then call: TC_AddFilter( K_handle, K_Filter) to set the filter, drop the RESV message and return. /item However, if there was a previous kernel reservation with handle K_handle, call the kernel interface module: TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec) If this call fails, build and send a RERR message specifying "Admission control failed". In any case, drop the RESV message and return. Braden, Zhang, et al. Expiration: September 1995 [Page 48] Internet Draft RSVP Specification March 1995 If processing a RESV message finds an error, a RERR message is created containing flow descriptor and an ERRORS object. The Error Node field of the ERRORS object (see Appendix A) is set to the IP address of OI, and the message is sent unicast to NHOP. created RESV TEAR MESSAGE ARRIVES A RTEAR message arrives on outgoing interface OI. o If there are no existing PSB's for SESSION then drop the RTEAR message and return. o Process the style-specific tail sequence to tear down reservations. For FF style, execute the following steps for each b flow descriptor, i.e., each (FLOWSPEC, FILTERSPEC) pair. For WF style execute the following once, using some internal placeholder "WILD_FILTER" for FILTERSPEC to indicate wildcard scope. 1. Find matching RSB(s) for the 4-tuple: (SESSION, NHOP, style, FILTERSPEC). If no RSB is found, continue with next flow descriptor, if any. 2. Delete the RSB(s). 3. If there are no more RSBs for the same (SESSION, OI, FILTERSPEC/) triple, call the kernel interface module: TC_ModFlowspec( K_handle ) to delete the reservation. Then build and forward a new RERR message. - WF style: send a copy to each PHOP among all matching senders. - FF style: Send to PHOP of matching PSB. 4. Otherwise (there are other RSB's for the same reservation), recompute K_Flowspec and call the kernel interface module: TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec) Braden, Zhang, et al. Expiration: September 1995 [Page 49] Internet Draft RSVP Specification March 1995 to update the reservation, and then execute the RESV REFRESH sequence (below). If this kernel call fails, return; the prior reservation will remain in place. RESV ERROR MESSAGE ARRIVES o Call the appropriate route discovery routine, using DestAddress from SESSION and (for multicast routing) SrcAddress from the Error Node field in the ERRORS object. Let the resulting routing bit mask be M. o Determine the set of RSBs matching the triple: (SESSION, style, FILTERSPEC). If no RSB is found, drop RERR message and return. Recompute the maximum over the FLOWSPEC objects of this set of RSB's. If the LUB was used in this computation, turn on the LUB-flag in the received RESV message. o Delete from the set of RSVs any whose OI does not appear in the bit mask M and whose NHOP is not the local API. If none remain, drop RERR message and return. For each PSB in the resulting set, do the following step. o If NHOP in PSB is local API, deliver error to application via an upcall: Call: ( session-id, Resv Error, 1, Error_code, Error_value, LUB-flag, FILTER_SPEC, FLOWSPEC, NULL) Here LUB-flag is taken from the received packet, as possibly modified above. Otherwise (NHOP is not local API), forward a copy of the RERR message to the PHOP node. PATH REFRESH This sequence may be entered by either the expiration of the path refresh timer for a particular session, or immediately as the result of processing a PATH message turning on the Refresh_Needed flag. For each virtual outgoing interface ("vif") V, build a PATH message Braden, Zhang, et al. Expiration: September 1995 [Page 50] Internet Draft RSVP Specification March 1995 and send it to V. To build the message, consider each PSB whose ROUTE_MASK includes V, and do the following: o Pass the ADVERT and SENDER_TSPEC objects present in the PSB to the kernel call TC_Advertise, and get back a modified ADVERT object. Pack this modified object into the PATH message being built. o Create a sender descriptor sequence containing the SENDER_TEMPLATE, CREDENTIAL, and SENDER_TSPEC objects, if present in the PSB. Pack the sender descriptor into the PATH message being built. o If the PSB has the EntryPolice flag on and if interface V is not capable of policing, turn the EntryPolice flag on in the PATH message being built. o If the maximum size of the PATH message is reached, send the packet out interface V and start packing a new one. RESV REFRESH This sequence may be entered by either the expiration of the reservation refresh timer for a particular session, or immediately as the result of processing a RESV message. Each PSB for this session is considered in turn, to compute a style- dependent tail sequence. These sequences for a given PHOP are then packed into the same message(s) and sent to that PHOP. The logic is somewhat different depending upon whether the scope of the reservations is wildcard or not (they may not be mixed). For each PSB that does not correspond to the API, do the following. o Compute (FLOWSPEC, FILTER_SPEC) Pair Select each RSB in whose reservation scope the PSB falls, and compute the maximum over the FLOWSPEC objects of this set of RSB's. Also, select an appropriate FILTER_SPEC. The scope depends upon the style and the filter spec of the RSB: 1. WF: Select every RSB whose OI matches a bit in the ROUTE_MASK of the PSB. In this case, FILTER_SPEC is the standard WILD_FILTER. 2. FF: Select every RSB whose FILTER_SPEC matches SENDER_TEMPLATE in the RSB. This matching process should Braden, Zhang, et al. Expiration: September 1995 [Page 51] Internet Draft RSVP Specification March 1995 consider wildcards. In this case, FILTER_SPEC is taken from any of the matching RSB's. [?? Need to either 'merge' filter specs, which probably means to remove gratuitous wildcards??] This computation also yields a style (since style must be consistent across RSB's for given session). [??Again, need merging rules]] o Build RESV packets Append this (FLOWSPEC, FILTER_SPEC pair) to the RESV message being built for destination PHOP (from the PSB). When the packet fills, or upon completion of all PSB's with the same PHOP, set the NHOP address in the message to the interface address and send the packet out that interface to the PHOP address. Braden, Zhang, et al. Expiration: September 1995 [Page 52] Internet Draft RSVP Specification March 1995 appendix 6. Object Type Definitions C-types are defined for the two Internet address families IPv4 and IP6. To accomodate other address families, additional C-types could easily be defined. These definitions are contained as an Appendix to ease updating. 6.1 SESSION Class Currently, SESSION objects contain the pair: (DestAddress, DestPort), where DestAddress is the data destination address and DestPort is the UDP/TCP destination port. Other SESSION C-Types could be defined in the future to support other demultiplexing conventions in the transport-layer or application layer. o IPv4/UDP SESSION object: Class = 1, C-Type = 1 +-------------+-------------+-------------+-------------+ | IPv4 DestAddress (4 bytes) | +-------------+-------------+-------------+-------------+ | //////////// | DestPort | +-------------+-------------+-------------+-------------+ o IP6/UDP SESSION object: Class = 1, C-Type = 129 +-------------+-------------+-------------+-------------+ | | + + | | + IP6 DestAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | //////////// | DestPort | +-------------+-------------+-------------+-------------+ Braden, Zhang, et al. Expiration: September 1995 [Page 53] Internet Draft RSVP Specification March 1995 6.2 SESSION_GROUP Class o IPv4 SESSION_GROUP Object: Class = 2, C-Type = 1: +-------------+-------------+-------------+-------------+ | IPv4 Reference DestAddress | +-------------+-------------+-------------+-------------+ | Session_Group ID | Count | Rank | +-------------+-------------+-------------+-------------+ o IP6 SESSION_GROUP Object: Class = 2, C-Type = 129: +-------------+-------------+-------------+-------------+ | | + + | | + IP6 Reference DestAddress + | | + + | | +-------------+-------------+-------------+-------------+ | Session-Group ID | Count | Rank | +-------------+-------------+-------------+-------------+ Braden, Zhang, et al. Expiration: September 1995 [Page 54] Internet Draft RSVP Specification March 1995 6.3 RSVP_HOP Class o IPv4 RSVP_HOP object: Class = 3, C-Type = 1 +-------------+-------------+-------------+-------------+ | IPv4 Next/Previous Hop Address | +-------------+-------------+-------------+-------------+ Braden, Zhang, et al. Expiration: September 1995 [Page 55] Internet Draft RSVP Specification March 1995 o IP6 RSVP_HOP object: Class = 3, C-Type = 129 +-------------+-------------+-------------+-------------+ | | + + | | + IP6 Next/Previous Hop Address + | | + + | | +-------------+-------------+-------------+-------------+ This object provides the IP address of the interface through which the last RSVP-knowledgeable hop forwarded this message. Braden, Zhang, et al. Expiration: September 1995 [Page 56] Internet Draft RSVP Specification March 1995 6.4 STYLE Class o STYLE-WF object: Class = 4, C-Type = 1 +-------------+-------------+-------------+-------------+ | Style=1 | //////// | //////// | ///////// | +-------------+-------------+-------------+-------------+ o STYLE-FF object: Class = 4, C-Type = 2 +-------------+-------------+-------------+-------------+ | Style=2 | //////// | //////// | FD Count | +-------------+-------------+-------------+-------------+ FD Count The count of elements in the variable-length object list that follows. See the RESV message format definition earlier. Braden, Zhang, et al. Expiration: September 1995 [Page 57] Internet Draft RSVP Specification March 1995 6.5 Flowspec Class o CSZ FLOWSPEC object: Class = 5, C-Type = 1 +-----------+-----------+-----------+-----------+ | QoS Service Code | +-----------+-----------+-----------+-----------+ | b: Token Bucket Depth (bits) | +-----------+-----------+-----------+-----------+ | r: Average data rate (bits/sec) | +-----------+-----------+-----------+-----------+ | d: Max end-to-end delay (ms) | +-----------+-----------+-----------+-----------+ | (For Future Use) | +-----------+-----------+-----------+-----------+ QoS Service Code Integer value defining what service is being requested. The values currently defined for this code are: 1 = Guaranteed Service The Tspec is (b, r), while the Rspec is (r). (d) is ignored. 2 = Bounded-Delay Predictive Service The Tspec is (b, r), while the Rspec is (d). Braden, Zhang, et al. Expiration: September 1995 [Page 58] Internet Draft RSVP Specification March 1995 6.6 FILTER_SPEC Class o IPv4/UDP FILTER_SPEC object: Class = 6, C-Type = 1 +-------------+-------------+-------------+-------------+ | IPv4 SrcAddress (4 bytes) | +-------------+-------------+-------------+-------------+ | Protocol Id | ////// | SrcPort | +-------------+-------------+-------------+-------------+ o IP6/UDP FILTER_SPEC object: Class = 6, C-Type = 129 +-------------+-------------+-------------+-------------+ | | + + | | + IP6 SrcAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | Protocol Id | ////// | SrcPort | +-------------+-------------+-------------+-------------+ SrcAddress is an IP address for a host, and SrcPort is a UDP/TCP source port, defining a sender. Braden, Zhang, et al. Expiration: September 1995 [Page 59] Internet Draft RSVP Specification March 1995 6.7 SENDER_TEMPLATE Class o IPv4/UDP SENDER_TEMPLATE object: Class = 7, C-Type = 1 Definition same as IPv4/UDP FILTER_SPEC object. o IP6/UDP SENDER_TEMPLATE object: Class = 7, C-Type = 129 Definition same as IP6/UDP FILTER_SPEC object. 6.8 SENDER_TSPEC Class The most common form of Tspec is a token bucket. o Token Bucket SENDER_TSPEC object: Class = 8, C-Type = 1 +-----------+-----------+-----------+-----------+ | b: Token Bucket Depth (bits) | +-----------+-----------+-----------+-----------+ | r: Average data rate (bits/sec) | +-----------+-----------+-----------+-----------+ Braden, Zhang, et al. Expiration: September 1995 [Page 60] Internet Draft RSVP Specification March 1995 6.9 ADVERT Class [TBD] 6.10 TIME_VALUES Class o TIME_VALUES Object: Class = 10, C-Type = 1 +-------------+-------------+-------------+-------------+ | Refresh Period | +-------------+-------------+-------------+-------------+ | State TTL Time | +-------------+-------------+-------------+-------------+ Braden, Zhang, et al. Expiration: September 1995 [Page 61] Internet Draft RSVP Specification March 1995 6.11 ERROR_SPEC Class o IPv4 ERROR_SPEC object: Class = 11, C-Type = 1 +-------------+-------------+-------------+-------------+ | IP4 Error Node Address (4 bytes) | +-------------+-------------+-------------+-------------+ | Error Code | ////////// | Error Value | +-------------+-------------+-------------+-------------+ o IP6 ERROR_SPEC object: Class = 11, C-Type = 129 +-------------+-------------+-------------+-------------+ | | + + | | + IP6 Error Node Address (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | Error Code | ////////// | Error Value | +-------------+-------------+-------------+-------------+ Errnor Node The IP address Error Code A one-octet error description. 01 = Insufficient memory 02 = Count Wrong The FD Count field does not match length of message. 03 = No path information for this Resv 04 = No Sender information for this Resv Braden, Zhang, et al. Expiration: September 1995 [Page 62] Internet Draft RSVP Specification March 1995 There is path information, but it does not include the sender specified in any of the Filterspecs listed in the Resv messager. 05 = Incorrect Dynamic Reservation Count Dynamic Reservation Count is zero or less than FD Count. 06 = Filterspec error 07 = Flowspec syntax error 08 = Flowspec value error Internal inconsistency of values. [What should be done with Flowspec Feature Not Supported?] 09 = Resources unavailable [Sub-reasons? Depend upon traffic control and admission control algorithms?] 10 = Illegal style Error Value Specific cause of the error described by the Error Code. Braden, Zhang, et al. Expiration: September 1995 [Page 63] Internet Draft RSVP Specification March 1995 6.12 CREDENTIAL Class [TBD] 6.13 INTEGRITY Class [TBD] Braden, Zhang, et al. Expiration: September 1995 [Page 64] Internet Draft RSVP Specification March 1995 7. UDP Encapsulation As described earlier, RSVP control messages are intended to be carried as "raw packets", directly within IP datagrams. Implementing RSVP in a node will typically require an intercept in the packet forwarding path for protocol 46, which means a kernel change. However, for ease of installing RSVP on host systems in the short term, it may be desirable to avoid host kernel changes by supporting UDP encapsulation of RSVP messages. This encapsulation would be used between hosts and the last- (or first-) hop router(s). This scheme will also support the case of an intermediate RSVP router whose kernel supports multicast but does not have the RSVP intercept, by allowing UDP encapsulation on each interface. The UDP encapsulation approach must support a domain that contains a mix of "UDP-only" hosts, which require UDP encapsulation, and "raw- capable" host, which can use raw RSVP packets. Raw-capable hosts and first-hop router(s) must send each RSVP message twice in the local domain, once as a raw packet and once with UDP encapsulation; these nodes will also receive some local RSVP packets in both formats. We assume that the only negative impact of this duplication will be (negligible) additional packet processing overhead in the raw-capable hosts and first-hop routers. [REST TBD] 8. DF Style (Experimental) In addition to the WF and FF styles defined in this specification, a Dynamic Filter (DF) style has also been proposed. The following describes this style and gives examples of its usage. At this time, DF style is experimental. 8.1 Reservation Styles A Dynamic-Filter (DF) style reservation decouples reservations from filters. Each DF reservation request specifies a number D of distinct reservations to be made using the same specified flowspec, and these reservations have a wildcard reservation scope, so they go everywhere. The number of reservations that are actually made in a particular node is D' = min(D,Ns), where Ns is the total number of senders upstream of the node. Like a FF style request, a DF style request causes distinct reservations for different senders. In addition to D and the flowspec, a DF style reservation may also specify a list of K filterspecs, for some K in the range: 0 <= K Braden, Zhang, et al. Expiration: September 1995 [Page 65] Internet Draft RSVP Specification March 1995 <= D'. These filterspecs define particular senders to use the D' reservations, and this list establishes the scope for the filter specs. Once a DF reservation has been established, the receiver may change the set of filterspecs to specify a different selection of senders, without a new admission control check (assuming D' and the common flowspec remain unchanged). This is known as "channel switching", in analogy with a television set. In order to provide assured channel switching, each node along the path must reserve enough bandwidth for all D' channels, even though some of this bandwidth may be unused at any one time. If D' changes (because the receiver changed D or because the number Ns of upstream sources changed), or if the common flowspec changes, the refresh message is treated as a new reservation that is subject to admission control and may fail. The essential difference between the FF and DF styles is that the DF style allows a receiver to switch channels without danger of an admission denial due to limited resources (unless a topology change reroutes traffic along a lower-capacity path or new senders appear), once the initial reservations have been made. This in turn implies that the DF style creates reservations that may not be in use at any given time. The DF style is compatible with the FF style but not the WF style. 8.2 Examples To give an example of the DF style, we use the following notation: o DF Style DF( n, {r} ; ) or DF( n, {r} ; S1, S2, ...) This message carries the count n of channels to be reserved, each using common flowspec r. It also carries a list, perhaps empty, of filterspecs defining senders. Figure 11 shows an example of Dynamic-Filter reservations. The receivers downstream from interface (d) have requested two reserved channels, but selected only one sender, S1. The node reserves min(2,3) = 2 channels of size B on interface (d), and it then applies any specified filters to these channels. Since only one sender was specified, one channel has no corresponding filter, as shown by `?'. Braden, Zhang, et al. Expiration: September 1995 [Page 66] Internet Draft RSVP Specification March 1995 Similarly, the receivers downstream of interface (c) have requested two channels and selected senders S1 and S2. The two channels might have been one channel each from R1 and R2, or two channels requested by one of them, for example. | Send | Reserve Receive | | ________ DF( 1,{B}; S1) <- (a) | (c) | S1{B} | (c) <- DF( 2,{B}; S1, S2) | |________| | | S2{B} | | |________| | ------------------------|------------------------------------------- | ________ DF( 2,{B}; S2) <- (b) | (d) | S1{B} | (d) <- DF( 2,{B}; S1) | |________| | | ?{B} | | |________| Figure 11: Dynamic-Filter Reservation Example A router should not reserve more Dynamic-Filter channels than the number of upstream sources (three, in the router of Figure 11). Since there is only one source upstream from previous hop (a), the first parameter of the DF message (the count of channels to be reserved) was decreased to 1 in the forwarded reservations. However, this is unnecessary, because the routers upstream will reserve only one channel, regardless. When a DF reservation is received, it is labeled with the IP address of the next hop (RSVP-capable) router, downstream from the current node. Since the outgoing interface may be directly connected to a shared medium network or to a non-RSVP-capable router, there may be more than one next-hop node downstream; if so, each sends independent DF RESV messages for a given session. The number N' of DF channels reserved on an outgoing interface is given by the formula: N' = min( D1+D2+...Dn, Ns), where Di is the D value (channel reservation count) in a RESV from the ith next-hop node. For a DF reservation request with a Dynamic Reservation Count = C, Braden, Zhang, et al. Expiration: September 1995 [Page 67] Internet Draft RSVP Specification March 1995 RSVP should call TC_AddFlowspec C times. 8.3 Resv Messages Add the following sequence: ::= ::= | 8.4 STYLE Class o STYLE-DF object: Class = 4, C-Type = 3 +-------------+-------------+-------------+-------------+ | Style=3 | //////// | Dyn Resv Cnt| FD Count | +-------------+-------------+-------------+-------------+ Style 3 = Dynamic-Filter Dyn Resv Count The number of channels to be reserved for a Dynamic Filter style reservation. This integer value must not less than FD Count. REFERENCES [CSZ92] Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanisms", Proc. SIGCOMM '92, Baltimore, MD, August 1992. [ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and PARC, June 1994. [IServ93] Shenker, S., Clark, D., and L. Zhang, "A Service Model for an Integrated Services Internet", Work in Progress, October 1993. [Partridge92] Partridge, C., "A Proposed Flow Specification", RFC 1363, BBN, September 1992. Braden, Zhang, et al. Expiration: September 1995 [Page 68] Internet Draft RSVP Specification March 1995 [Shenker94] Shenker, S., "Two-Pass or Not Two-Pass", Current Meeting Report, RSVP Working Group, Proceedings of the Thirtieth Internet Engineering Task Force, Toronto, Canada, July 1994. [RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, September 1993. Security Considerations See Section 2.5. Authors' Addresses Lixia Zhang Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 Phone: (415) 812-4415 EMail: Lixia@PARC.XEROX.COM Bob Braden USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: (310) 822-1511 EMail: Braden@ISI.EDU Deborah Estrin Computer Science Department University of Southern California Los Angeles, CA 90089-0871 Phone: (213) 740-4524 EMail: estrin@USC.EDU Braden, Zhang, et al. Expiration: September 1995 [Page 69] Internet Draft RSVP Specification March 1995 Shai Herzog USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Palo Alto, CA 94304 Phone: (310) 822 1511 EMail: Herzog@ISI.EDU Sugih Jamin Computer Science Department University of Southern California Los Angeles, CA 90089-0871 Phone: (213) 740-6578 EMail: jamin@catarina.usc.edu Braden, Zhang, et al. Expiration: September 1995 [Page 70]