idnits 2.17.1 draft-ietf-rsvp-spec-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1663 has weird spacing: '...ng, the detai...' == Line 2277 has weird spacing: '...ed flag param...' == Line 3245 has weird spacing: '... object k ...' == Line 3374 has weird spacing: '... object k ...' == Line 3770 has weird spacing: '...ildcard scope...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 1995) is 10492 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'H5' is mentioned on line 956, but not defined == Missing Reference: 'S4' is mentioned on line 1931, but not defined == Missing Reference: 'S1' is mentioned on line 1927, but not defined == Missing Reference: 'S2' is mentioned on line 1931, but not defined == Missing Reference: 'S3' is mentioned on line 1931, but not defined == Missing Reference: 'TBD' is mentioned on line 3353, but not defined == Unused Reference: 'CSZ92' is defined on line 4018, but no explicit reference was found in the text == Unused Reference: 'IServ93' is defined on line 4026, but no explicit reference was found in the text == Unused Reference: 'Partridge92' is defined on line 4029, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CSZ92' ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. 'ISInt93') -- Possible downref: Non-RFC (?) normative reference: ref. 'IServ93' ** Downref: Normative reference to an Informational RFC: RFC 1363 (ref. 'Partridge92') -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP93' == Outdated reference: A later version (-02) exists of draft-ietf-intserv-svc-template-00 ** Downref: Normative reference to an Informational draft: draft-ietf-intserv-svc-template (ref. 'ServTempl95a') -- Possible downref: Non-RFC (?) normative reference: ref. 'Shenker94' Summary: 12 errors (**), 0 flaws (~~), 17 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Braden, Ed. 3 Expiration: January 1996 ISI 4 File: draft-ietf-rsvp-spec-07.txt L. Zhang 5 PARC 6 D. Estrin 7 ISI 8 S. Herzog 9 ISI 10 S. Jamin 11 USC 13 Resource ReSerVation Protocol (RSVP) -- 15 Version 1 Functional Specification 17 July 7, 1995 19 Status of Memo 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 To learn the current status of any Internet-Draft, please check the 32 linebreak "1id-abstracts.txt" listing contained in the Internet- 33 Drafts Shadow Directories on ds.internic.net (US East Coast), 34 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au 35 (Pacific Rim). 37 Abstract 39 This memo describes version 1 of RSVP, a resource reservation setup 40 protocol designed for an integrated services Internet. RSVP provides 41 receiver-initiated setup of resource reservations for multicast or 42 unicast data flows, with good scaling and robustness properties. 44 What's Changed Since Danvers IETF 46 The most important changes in this document from the rsvp-spec-05 draft 47 are: 49 o Added fields to common header for linear fragmentation, and 50 moved all references to semantic fragmentation to Appendix D. 52 o Added SE (Shared Explicit) style to all parts of the document. 54 o Further clarified reservation options and added table in Figure 55 3. Defined option vector in STYLE object. 57 o Renamed CREDENTIAL object class to POLICY_DATA object class, and 58 rewrote section 2.5 to more fully express its intended usage. 60 o Clarified the relationship between the wildcard scope 61 reservation option and wildcards in individual FILTER_SPEC 62 objects: wildcard is as wildcard does. 64 o Added SCOPE object definition and defined the rules for its use 65 to prevent looping of wildcard-scope messages. 67 o Added some mechanisms for handling backwards compatibility for 68 future protocol extensions: (1) High bit of object class number; 69 (2) unmerged FLOWSPEC C-Type; (3) unmerged POLICY_DATA C-Type. 71 o Rewrote Section 4.3 on preventing looping. Included rules for 72 SCOPE object. 74 o Specified rules for local repair upon route change notification 75 (Section 4.4). 77 o Specified for each error type whether or not the state 78 information in the erroneous packet is to be stored and 79 forwarded. 81 o Deleted the discussion of retransmitting a Teardown message Q 82 times; assume Q=1 is sufficient. 84 o Moved Session Groups to Appendix D, "Experimental and Open 85 Issues". Session Groups should be revisited as part of a larger 86 context of cross-session reservations. 88 o Changed common header format, removing Object Count (which was 89 redundant) and rearranging the remaining fields. Moved the two 90 common header flags into objects: Entry-Police into SESSION 91 object and LUB-used into ERROR_SPEC object. 93 o Revised the rules for state timeout (Section 4.5) and redefined 94 the TIME_VALUES object format. 96 o Changed the error message format: (1) removed required RSVP_HOP 97 object from PERR and RERR messages; (2) specified more carefully 98 what may appear in flow descriptor list of RERR messages. 100 o Revised the definitions of error codes and error values, and 101 moved them into a separate Appendix B. 103 o No longer require CREDENTIAL (i.e., POLICY_DATA) match for 104 teardown. 106 o Revised routing of RERR messages to use SCOPE objects to avoid 107 wildcard-induced looping. 109 o Added LIH (logical interface handle) to RSVP_HOP object, for IP 110 multicast tunnels. 112 o Specified that addresses should be sorted in SCOPE object. 114 o Added two new upcall event types in the API: reservation event 115 and policy data event. 117 o Generalized the generic traffic control calls slightly to allow 118 multiple filter specs per flowspec, for SE style. This 119 introduced a new set of handles, called FHandle. Also added a 120 preemption upcall. 122 o Added route change notification to the generic interface to 123 routing. 125 o Updated the message processing rules (Section 5). 127 o Rewrote Appendix C on UDP encapsulation. 129 o Removed specification of FLOWSPEC object format (but int-serv 130 working group has since reneged on promise to specify it). 132 1. Introduction 134 This document defines RSVP, a resource reservation setup protocol 135 designed for an integrated services Internet [RSVP93,ISInt93]. 137 A host uses the RSVP protocol to request a specific quality of 138 service (QoS) from the network, on behalf of an application data 139 stream. RSVP is also used to deliver QoS requests to routers along 140 the path(s) of the data stream and to maintain router and host state 141 to provide the requested service. This will generally (but not 142 necessarily) require reserving resources along the data path. 144 RSVP reserves resources for simplex data streams, i.e., it reserves 145 resources in only one direction on a link, so that a sender is 146 logically distinct from a receiver. However, the same application 147 may act as both sender and receiver. RSVP operates on top of IP, 148 occupying the place of a transport protocol in the protocol stack. 149 However, like ICMP, IGMP, and routing protocols, RSVP does not 150 transport application data but is rather an Internet control 151 protocol. As shown in Figure 1, an implementation of RSVP, like the 152 implementations of routing and management protocols, will typically 153 execute in the background, not in the data forwarding path. 155 RSVP is not itself a routing protocol; the RSVP daemon consults the 156 local routing protocol(s) to obtain routes. Thus, a host sends IGMP 157 messages to join a multicast group, and it sends RSVP messages to 158 reserve resources along the delivery path(s) from that group. RSVP 159 is designed to operate with existing and future unicast and multicast 160 routing protocols. 162 HOST ROUTER 164 _________________________ RSVP ______________________ 165 | | .---------------. | 166 | _______ ______ | . | ________ . ______ | 167 | | | | | | . || | . | || RSVP 168 | |Applic-| | RSVP <----- ||Routing | -> RSVP <------> 169 | | App <----->daemon| | ||Protocol| |daemon|| 170 | | | | | | || daemon <----> || 171 | |_______| |___.__| | ||_ ._____| |__.___|| 172 |===|===============v=====| |===v=============v====| 173 | data .......... | | . ............ | 174 | | ____v_ ____v____ | | _v__v_ _____v___ | 175 | | |Class-| | || data | |Class-| | || data 176 | |=> ifier|=> Packet =============> ifier|==> Packet |======> 177 | |______| |Scheduler|| | |______| |Scheduler|| 178 | |_________|| | |_________|| 179 |_________________________| |______________________| 181 Figure 1: RSVP in Hosts and Routers 183 Each router that is capable of resource reservation passes incoming 184 data packets to a packet classifier and then queues them as necessary 185 in a packet scheduler. The packet classifier determines the route 186 and the QoS class for each packet. The scheduler allocates resources 187 for transmission on the particular link-layer medium used by each 188 interface. If the link-layer medium is QoS-active, i.e., if it has 189 its own QoS management capability, then the packet scheduler is 190 responsible for negotiation with the link layer to obtain the QoS 191 requested by RSVP. There are many possible ways this might be 192 accomplished, and the details will be medium-dependent. The 193 scheduler itself allocates packet transmission capacity on a QoS- 194 passive medium such as a leased line. The scheduler may also 195 allocate other system resources such as CPU time or buffers. 197 In order to efficiently accommodate heterogeneous receivers and 198 dynamic group membership and to be consistent with IP multicast, RSVP 199 makes receivers responsible for requesting resource reservations 200 [RSVP93]. A QoS request, typically originating in a receiver host 201 application, will be passed to the local RSVP implementation, shown 202 as a user daemon in Figure 1. The RSVP protocol is then used to pass 203 the request to all the nodes (routers and hosts) along the reverse 204 data path(s) to the data source(s). 206 At each node, the RSVP program applies a local decision procedure, 207 called "admission control", to determine if it can supply the 208 requested QoS. If admission control succeeds, the RSVP program sets 209 parameters to the packet classifier and scheduler to obtain the 210 desired QoS. If admission control fails at any node, the RSVP 211 program returns an error indication to the application that 212 originated the request. We refer to the packet classifier, packet 213 scheduler, and admission control components as "traffic control". 215 RSVP is designed to scale well for very large multicast groups. 216 Since the membership of a large group will be constantly changing, 217 the RSVP design assumes that router state for traffic control will be 218 built and destroyed incrementally. For this purpose, RSVP uses "soft 219 state" in the routers, in addition to receiver-initiation. 221 RSVP protocol mechanisms provide a general facility for creating and 222 maintaining distributed reservation state across a mesh of multicast 223 or unicast delivery paths. RSVP transfers reservation parameters as 224 opaque data (except for certain well-defined operations on the data), 225 which it simply passes to traffic control for interpretation. 226 Although the RSVP protocol mechanisms are largely independent of the 227 encoding of these parameters, the encodings must be defined in the 228 reservation model that is presented to an application (see Appendix 229 A). 231 In summary, RSVP has the following attributes: 233 o RSVP supports multicast or unicast data delivery and adapts to 234 changing group membership as well as changing routes. 236 o RSVP is simplex. 238 o RSVP is receiver-oriented, i.e., the receiver of a data flow is 239 responsible for the initiation and maintenance of the resource 240 reservation used for that flow. 242 o RSVP maintains "soft state" in the routers, enabling it to 243 gracefully support dynamic membership changes and automatically 244 adapt to routing changes. 246 o RSVP provides several reservation models or "styles" (defined 247 below) to fit a variety of applications. 249 o RSVP provides transparent operation through routers that do not 250 support it. 252 Further discussion on the objectives and general justification for 253 RSVP design are presented in [RSVP93,ISInt93]. 255 The remainder of this section describes the RSVP reservation 256 services. Section 2 presents an overview of the RSVP protocol 257 mechanisms, while Section 3 gives examples of the services and 258 mechanism. Section 4 contains the functional specification of RSVP. 259 Section 5 presents explicit message processing rules. 261 1.1 Data Flows 263 The set of data flows with the same unicast or multicast 264 destination constitute a session. RSVP treats each session 265 independently. All data packets in a particular session are 266 directed to the same IP destination address DestAddress, and 267 perhaps to some further demultiplexing point defined in a higher 268 layer (transport or application). We refer to the latter as a 269 "generalized destination port". 271 DestAddress is the group address for multicast delivery, or the 272 unicast address of a single receiver. A generalized destination 273 port could be defined by a UDP/TCP destination port field, by an 274 equivalent field in another transport protocol, or by some 275 application-specific information. Although the RSVP protocol is 276 designed to be easily extendible for greater generality, the 277 present version uses only UDP/TCP ports as generalized ports. 279 Figure 2 illustrates the flow of data packets in a single RSVP 280 session, assuming multicast data distribution. The arrows 281 indicate data flowing from senders S1 and S2 to receivers R1, R2, 282 and R3, and the cloud represents the distribution mesh created by 283 the multicast routing protocol. Multicast distribution forwards a 284 copy of each data packet from a sender Si to every receiver Rj; a 285 unicast distribution session has a single receiver R. Each sender 286 Si and each receiver Rj may correspond to a unique Internet host, 287 or a single host may contain multiple logical senders and/or 288 receivers, distinguished by generalized ports. 290 Senders Receivers 291 _____________________ 292 ( ) ===> R1 293 S1 ===> ( Multicast ) 294 ( ) ===> R2 295 ( distribution ) 296 S2 ===> ( ) 297 ( by Internet ) ===> R3 298 (_____________________) 300 Figure 2: Multicast Distribution Session 302 Even if the destination address is unicast, there may be multiple 303 receivers, distinguished by the generalized port. There may also 304 be multiple senders for a unicast destination, i.e., RSVP can set 305 up reservations for multipoint-to-point transmission. 307 1.2 Reservation Model 309 An elementary RSVP reservation request consists of a "flowspec" 310 together with a "filter spec"; this pair is called a "flow 311 descriptor". The flowspec specifies a desired QoS. The filter 312 spec (together with the DestAddress and the generalized 313 destination port defining the session) defines the set of data 314 packets -- the "flow" -- to receive the QoS defined by the 315 flowspec. The flowspec is used to set parameters to the node's 316 packet scheduler (assuming that admission control succeeds), while 317 the filter spec is used to set parameters in the packet 318 classifier. Note that the action to control the QoS occurs at the 319 place where the data enters the medium, i.e., at the upstream end 320 of the link, although the RSVP reservation request originates from 321 receiver(s) downstream. 323 The flowspec in a reservation request will generally include a 324 service type and two sets of numeric parameters: (1) an "Rspec" (R 325 for `reserve'), which defines the desired per-hop reservation, and 326 (2) a "Tspec" (T for `traffic'), which defines the parameters that 327 may be used to police the data flow, i.e., to ensure it does not 328 exceed its promised traffic level. 330 The form and contents of Tspecs and Rspecs are determined by the 331 integrated service model [ServTempl95a], and are generally opaque 332 to RSVP. RSVP delivers the Tspec and Rspec, together with an 333 indication whether traffic policing is needed to the admission 334 control and packet scheduling components of traffic control. A 335 service that requires traffic policing might for example apply it 336 at the edge of the network and at data merge points; RSVP knows 337 when these occur and must so indicate to the traffic control 338 mechanism. On the other hand, RSVP cannot interpret the service 339 embodied in the flowspec and therefore does not know whether 340 policing will actually be applied in a particular case. 342 In the general RSVP reservation model [RSVP93], filter specs may 343 select arbitrary subsets of the packets in a given session. Such 344 subsets might be defined in terms of senders (i.e., sender IP 345 address and generalized source port), in terms of a higher-level 346 protocol, or generally in terms of any fields in any protocol 347 headers in the packet. For example, filter specs might be used to 348 select different subflows in a hierarchically-encoded signal by 349 selecting on fields in an application-layer header. However, in 350 the interest of simplicity (and to minimize layer violation), the 351 present RSVP version uses a much more restricted form of filter 352 spec: select only on sender IP address, on UDP/TCP port number, 353 and perhaps on IP protocol id. 355 RSVP can distinguish subflows of a hierarchically-encoded signal 356 if they are assigned distinct multicast destination addresses, or, 357 for a unicast destination, distinct destination ports. Data 358 packets that are addressed to a particular session but do not 359 match any of the filter specs for that session are expected to be 360 sent as best-effort traffic, and under congested conditions, such 361 packets are likely to experience long delays, and they may be 362 dropped. When a receiver does not wish to receive a particular 363 (sub-)flow, it can economize on network resources by explicitly 364 asking the network to drop unneeded the data packets; it does so 365 by leaving the multicast group(s) to which these packets are 366 addressed. Thus, determining where packets get delivered should 367 be a routing function; RSVP is concerned only with the QoS of 368 those packets that are delivered by routing. 370 RSVP reservation request messages originate at receivers and are 371 passed upstream towards the sender(s). (This document defines the 372 directional terms "upstream" vs. "downstream", "previous hop" vs. 373 "next hop", and "incoming interface" vs "outgoing interface" with 374 respect to the data flow direction.) When an elementary 375 reservation request is received at a node, the RSVP daemon takes 376 two primary actions: 378 1. Daemon makes a reservation 380 The flowspec and the filter spec are passed to traffic 381 control. Admission control determines the admissibility of 382 the request (if it's new); if this test fails, the 383 reservation is rejected and RSVP returns an error message to 384 the appropriate receiver(s). If admission control succeeds, 385 the node uses the flowspec to set up the packet scheduler for 386 the desired QoS and the filter spec to set the packet 387 classifier to select the appropriate data packets. 389 2. Daemon forwards the reservation upstream 391 The reservation request is propagated upstream towards the 392 appropriate senders. The set of sender hosts to which a 393 given reservation request is propagated is called the "scope" 394 of that request. 396 The reservation request that a node forwards upstream may differ 397 from the request that it received, for two reasons. First, it is 398 possible (in theory) for the traffic control mechanism to modify 399 the flowspec hop-by-hop, although currently no realtime services 400 do this. Second, reservations from different downstream branches 401 of the multicast distribution tree(s) must be "merged" as 402 reservations travel upstream. Merging reservations is a necessary 403 consequence of multicast distribution, which creates a single 404 stream of data packets in a particular router from any Si, 405 regardless of the set of receivers downstream. The reservation 406 for Si on a particular outgoing link L should be the "maximum" of 407 the individual flowspecs from the receivers Rj that are downstream 408 via link L. Merging is discussed further in Section 2.2. 410 The basic RSVP reservation model is "one pass": a receiver sends a 411 reservation request upstream, and each node in the path can only 412 accept or reject the request. This scheme provides no way to make 413 end-to-end service guarantees, since the QoS request must be 414 applied independently at each hop. RSVP also supports an optional 415 reservation model, known as "One Pass With Advertising" (OPWA) 416 [Shenker94]. In OPWA, RSVP control packets sent downstream, 417 following the data paths, are used to gather information on the 418 end-to-end service that would result from a variety of possible 419 reservation requests. The results ("advertisements") are 420 delivered by RSVP to the receiver host, and perhaps to the 421 receiver application. The information may then be used by the 422 receiver to construct an appropriate reservation request. 424 1.3 Reservation Styles 426 A reservation request includes a set of control options, which are 427 collectively called the reservation "style". 429 One option concerns the treatment of reservations for different 430 senders within the same session: establish a "distinct" 431 reservation for each upstream sender, or else make a single 432 reservation that is " shared" among all packets of selected 433 senders. Another option controls the scope of the request: an 434 "explicit" sender specification, or a "wildcard" that implicitly 435 selects a group of senders. In an explicit-style reservation, the 436 filter spec must match exactly one sender, while the filter spec 437 in a wildcard reservation must match at least one sender but may 438 match any number. 440 || Reservations: 441 Scope || Distinct | Shared 442 _________||__________________|____________________ 443 || | | 444 Explicit || Fixed-Filter | Shared-Explicit | 445 || (FF) style | (SE) Style | 446 __________||__________________|____________________| 447 || | | 448 Wildcard || (None defined) | Wildcard-Filter | 449 || | (WF) Style | 450 __________||__________________|____________________| 452 Figure 3: Reservation Attributes and Styles 454 The styles currently defined are as follows (see Figure 3): 456 1. Wildcard-Filter (WF) Style 458 The WF style implies the options: "shared" reservation and " 459 wildcard" reservation scope. Thus, a WF-style reservation 460 creates a single reservation into which flows from all 461 upstream senders are mixed; this reservation may be thought 462 of as a shared "pipe", whose "size" is the largest of the 463 resource requests for that link from all receivers, 464 independent of the number of senders using it. A WF-style 465 reservation has wildcard scope, i.e., the reservation is 466 propagated upstream towards all sender hosts. A WF-style 467 reservation automatically extends to new senders as they 468 appear. 470 2. Fixed-Filter (FF) Style 472 The FF style implies the options: "distinct" reservations and 473 "explicit" reservation scope. Thus, an elementary FF-style 474 reservation request creates a distinct reservation for data 475 packets from a particular sender, not sharing them with other 476 senders' packets for the same session. It scope is 477 determined by an explicit list of senders. 479 The total reservation on a link for a given session is the 480 total of the FF reservations for all requested senders. On 481 the other hand, FF reservations requested by different 482 receivers Rj but selecting the same sender Si must 483 necessarily be merged to share a single reservation in a 484 given node. 486 3. Shared Explicit (SE) Style 488 The SE style implies the options: "shared" reservation and " 489 explicit" reservation scope. Thus, an SE-style reservation 490 creates a single reservation into which flows from all 491 upstream senders are mixed. However, like a FF reservation 492 the set of senders (and therefore its scope (and therefore 493 the scope) is specified explicitly by the receiver making the 494 reservation. 496 WF and SE are both shared reservations, appropriate for those 497 multicast applications whose application-specific constraints make 498 it unlikely that multiple data sources will transmit 499 simultaneously. One example is audio conferencing, where a limited 500 number of people talk at once; each receiver might issue a WF or 501 SE reservation request for twice one audio channel (to allow some 502 over-speaking). On the other hand, the FF style, which creates 503 independent reservations for the flows from different senders, is 504 appropriate for video signals. 506 It is not possible to merge shared reservations with distinct 507 reservations. Therefore, WF and SE styles are incompatible with 508 FF, but are compatible with each other. Merging a WF style 509 reservation with an SE style reservation results in a WF 510 reservation. 512 Other reservation options and styles may be defined in the future 513 (see Appendix D.4, for example). 515 2. RSVP Protocol Mechanisms 517 2.1 RSVP Messages 519 There are two fundamental RSVP message types: RESV and PATH . 521 Each receiver host sends RSVP reservation request (RESV) messages 522 towards the senders. These reservation messages must follow in 523 reverse the routes the data packets will use, all the way upstream 524 to the sender hosts included in the scope. RESV messages must be 525 delivered to the sender hosts so that the hosts can set up 526 appropriate traffic control parameters for the first hop. 528 Also note that RSVP sends no positive acknowledgment messages to 529 indicate success (although the delivery of a reservation request 530 to a sender could be used to trigger an acknowledgement at a 531 higher level of protocol.) 532 Sender Receiver 533 _____________________ 534 Path --> ( ) 535 Si =======> ( Multicast ) Path --> 536 <-- Resv ( ) =========> Rj 537 ( distribution ) <-- Resv 538 (_____________________) 540 Figure 4: RSVP Messages 542 Each sender transmits RSVP PATH messages forward along the uni- 543 /multicast routes provided by the routing protocol(s); see Figure 544 4. These "Path" messages store path state in each node. Path 545 state is used by RSVP to route the RESV messages hop-by-hop in the 546 reverse direction. (In the future, some routing protocols may 547 supply reverse path forwarding information directly, replacing the 548 reverse-routing function of path state). 550 PATH messages may also carry the following information: 552 o Sender Template 554 The Sender Template describes the format of data packets that 555 the sender will originate. This template is in the form of a 556 filter spec that could be used to select this sender's 557 packets from others in the same session on the same link. 559 Like a filter spec, the Sender Template is less than fully 560 general at present, specifying only sender IP address, 561 UDP/TCP sender port, and protocol id. The port number 562 and/or protocol id can be wildcarded. 564 o Tspec 566 PATH message may optionally carry a Tspec that defines an 567 upper bound on the traffic level that the sender will 568 generate. This Tspec can be used by RSVP to prevent over- 569 reservation (and perhaps unnecessary Admission Control 570 failure) on the non-shared links starting at the sender. 572 o Adspec 574 The PATH message may carry a package of OPWA advertising 575 information, known as an "Adspec". An Adspec received in a 576 PATH message is passed to the local traffic control routines, 577 which return an updated Adspec; the updated version is 578 forwarded downstream. 580 Previous Incoming Outgoing Next 581 Hops Interfaces Interfaces Hops 583 _____ _____________________ _____ 584 | | data --> | | data --> | | 585 | A |-----------| a c |--------------| C | 586 |_____| <-- Resv | | <-- Resv |_____| 587 Path --> | | Path --> _____ 588 _____ | ROUTER | | | | 589 | | | | | |--| D | 590 | B |--| data-->| | data --> | |_____| 591 |_____| |--------| b d |-----------| 592 |<-- Resv| | <-- Resv | _____ 593 _____ | Path-->|_____________________| Path --> | | | 594 | | | |--| D' | 595 | B' |--| | |_____| 596 |_____| | | 598 Figure 5: Router Using RSVP 600 Figure 5 illustrates RSVP's model of a router node. Each data 601 stream arrives from a previous hop through a corresponding 602 incoming interface and departs through one or more outgoing 603 interface(s). The same physical interface may act in both the 604 incoming and outgoing roles (for different data flows but the same 605 session). 607 As illustrated in Figure 5, there may be multiple previous hops 608 and/or next hops through a given physical interface. This may 609 result from the connected network being a shared medium or from 610 the existence of non-RSVP routers in the path to the next RSVP hop 611 (see Section 2.6). An RSVP daemon must preserve the next and 612 previous hop addresses in its reservation and path state, 613 respectively. A RESV message is sent with a unicast destination 614 address, the address of a previous hop. PATH messages, on the 615 other hand, are sent with the session destination address, unicast 616 or multicast. 618 Although multiple next hops may send reservation requests through 619 the same physical interface, the final effect should be to install 620 a reservation on that interface, which is defined by an effective 621 flowspec. This effective flowspec will be the "maximum" of the 622 flowspecs requested by the different next hops. In turn, a RESV 623 message forwarded to a particular previous hop carries a flowspec 624 that is the "maximum" over the effective reservations on the 625 corresponding outgoing interfaces. Both cases represent merging, 626 which is discussed further below. 628 There are a number of ways for a syntactically valid reservation 629 request to fail in a given node: 631 1. The effective flowspec, computed using the new request, may 632 fail admission control. 634 2. Administrative policy or control may prevent the requested 635 reservation. 637 3. There may be no matching path state (i.e., the scope may be 638 empty), which would prevent the reservation being propagated 639 upstream. 641 4. A reservation style that requires a unique sender may have a 642 filter spec that matches more than one sender in the path 643 state, due to the use of wildcards. 645 5. The requested style may be incompatible with the style(s) of 646 existing reservations for the same session on the same 647 outgoing interface, so an effective flowspec cannot be 648 computed. 650 6. The requested style may be incompatible with the style(s) of 651 reservations that exist on other outgoing interfaces but will 652 be merged with this reservation to create a refresh message 653 for the previous hop. 655 In any of these cases, an error message is returned to the 656 receiver(s) responsible for the erroneous message. An error 657 message does not modify state in the nodes through which it 658 passes. Therefore, any reservations established downstream of the 659 node where the failure was detected will persist until the 660 receiver(s) responsible cease attempting the reservation. 662 The erroneous message may or may not be propagated forward. In 663 general, if the error is likely to be repeated at every node 664 further along the path, it is best to drop the erroneous message 665 rather than generate a flood of error messages; this is the case 666 for the last four error classes listed above. The first two error 667 classes, admission control and administrative policy, may or may 668 not allow propagation of the message, depending upon the detailed 669 reason and perhaps on local administrative policy and/or the 670 particular service request. More complete rules are given in the 671 error definitions in Appendix B. 673 An erroneous FILTER_SPEC object in a RESV message will normally be 674 detected at the first RSVP hop from the receiver application, 675 i.e., within the receiver host. However, an admission control 676 failure caused by a FLOWSPEC or a POLICY_DATA object may be 677 detected anywhere along the path(s) to the sender(s). 679 When admission control fails for a reservation request, any 680 existing reservation is left in place. This prevents a new, very 681 large, reservation from disrupting the existing QoS by merging 682 with an existing reservation and then failing admission control 683 (this has been called the "killer reservation" problem). 685 A node may be allowed to preempt an established reservation, in 686 accordance with administrative policy; this will also trigger an 687 error message to all affected receivers. 689 2.2 Merging and Packing 691 A previous section explained that reservation requests in RESV 692 messages are necessarily merged, to match the multicast 693 distribution tree. As a result, only the essential (i.e., the 694 "largest") reservation requests are forwarded, once per refresh 695 period. A successful reservation request will propagate as far as 696 the closest point(s) along the sink tree to the sender(s) where a 697 reservation level equal or greater than that being requested has 698 been made. At that point, the merging process will drop it in 699 favor of another, equal or larger, reservation request. 701 For protocol efficiency, RSVP also allows multiple sets of path 702 (or reservation) information for the same session to be "packed" 703 into a single PATH (or RESV) message, respectively. (For 704 simplicity, the protocol currently prohibits packing different 705 sessions into the same RSVP message). Unlike merging, packing 706 preserves information. 708 In order to merge reservations, RSVP must be able to merge 709 flowspecs and to merge filterspecs. Merging flowspecs requires 710 calculating the the "largest" of a set of flowspecs, which are 711 otherwise opaque to RSVP. Merging flowspecs is required both to 712 calculate the effective flowspec to install on a given physical 713 interface (see the discussion in connection with Figure 5), and to 714 merge flowspecs when sending a refresh message upstream. Since 715 flowspecs are generally multi-dimensional vectors (they contain 716 both Tspec and Rspec components, each of which may itself be 717 multi-dimensional), they are not strictly ordered. When it cannot 718 take the larger of two flowspecs, RSVP must compute and use a 719 third flowspec that is at least as large as each, i.e., a "least 720 upper bound" (LUB). It is also possible for two flowspecs to be 721 incomparable, which is treated as an error. The definition and 722 implementation of the rules for comparing flowspecs are outside 723 RSVP proper, but they are defined as part of the service templates 724 [ServTempl95a] 726 We can now give the complete rules for calculating the effective 727 flowspec (Te, Re), to be installed on an interface. Here Te is 728 the effective Tspec and Re is the effective Rspec. As an example, 729 consider interface (d) in Figure 5. 731 o Re is calculated as the largest (using an LUB if necessary) 732 of the Rspecs in RESV messages from different next hops 733 (e.g., D and D') but the same outgoing interface (d). 735 o The Tspecs supplied in PATH messages from different previous 736 hops which may send data packets to this reservation (e.g., 737 some or all of A, B, and B' in Figure 5) are summed; call 738 this sum Path_Te. 740 o The maximum Tspec supplied in RESV messages from different 741 next hops (e.g., D and D') is calculated; call this Resv_Te. 743 o Te is the GLB (greatest lower bound) of Path_Te and Resv_Te. 744 For Tspecs defined by token bucket parameters, this means to 745 take the smaller of the bucket size and the rate parameters. 747 Two filter specs can be merged only they are identical or if one 748 contains the other through wild-carding. The result is the more 749 general of the two, i.e., the one with more wildcard fields. 751 2.3 Soft State 753 To maintain reservation state, RSVP keeps "soft state" in router 754 and host nodes. RSVP soft state is created and periodically 755 refreshed by PATH and RESV messages. The state is deleted if no 756 matching refresh messages arrive before the expiration of a 757 "cleanup timeout" interval. It may also be deleted as the result 758 of an explicit "teardown" message, described in the next section. 759 At the expiration of each "refresh timeout" period, RSVP scans its 760 state to build and forward PATH and RESV refresh messages to 761 succeeding hops. 763 When a route changes, the next PATH message will initialize the 764 path state on the new route, and future RESV messages will 765 establish reservation state there; the state on the now-unused 766 segment of the route will time out. Thus, whether a message is 767 "new" or a "refresh" is determined separately at each node, 768 depending upon the existence of state at that node. 770 RSVP sends its messages as IP datagrams without reliability 771 enhancement. Periodic transmission of refresh messages by hosts 772 and routers is expected to replace any lost RSVP messages. To 773 tolerate K-1 successive packet losses, the effective cleanup 774 timeout must be at least K times the refresh timeout. In 775 addition, the traffic control mechanism in the network should be 776 statically configured to grant high-reliability service to RSVP 777 messages, to protect RSVP messages from congestion losses. 779 The "soft" state maintained by RSVP is dynamic; to change the set 780 of senders Si or receivers Rj or to change any QoS request, a host 781 simply starts sending revised PATH and/or RESV messages. The 782 result should be an appropriate adjustment in the RSVP state and 783 immediate propagation to all nodes along the path. 785 In steady state, refreshing is performed hop-by-hop, which allows 786 merging and packing as described in the previous section. If the 787 received state differs from the stored state, the stored state is 788 updated. Furthermore, if the result will be to modify the refresh 789 messages to be generated, these refresh messages must be generated 790 and forwarded immediately. This will result in state changes 791 propagating end-to-end without delay. However, propagation of a 792 change stops when and if it reaches a point where merging causes 793 no resulting state change. This minimizes RSVP control traffic 794 due to changes and is essential for scaling to large multicast 795 groups. 797 The RSVP state associated with a session in a particular node is 798 divided into atomic elements that are created, refreshed, and 799 timed out independently. The atomicity is determined by the 800 requirement that any sender or receiver may enter or leave the 801 session at any time, so its state should be created and timed out 802 independently. 804 2.4 Teardown 806 RSVP teardown messages remove path and reservation state without 807 waiting for the cleanup timeout period, as an optimization to 808 release resources quickly. It is not necessary to explicitly tear 809 down an old reservation, although it may be desirable in many 810 cases. 812 A teardown request may be initiated either by an application in an 813 end system (sender or receiver), or by a router as the result of 814 state timeout. Once initiated, a teardown request should be 815 forwarded hop-by-hop without delay. 817 Teardown messages (like other RSVP messages) are not delivered 818 reliably. However, loss of a teardown message is not considered a 819 problem because the state will time out even if it is not 820 explicitly deleted. If one or more teardown message hops are 821 lost, the router that failed to receive a teardown message will 822 time out its state and initiate a new teardown message beyond the 823 loss point. Assuming that RSVP message loss probability is small, 824 the longest time to delete state will seldom exceed one refresh 825 timeout period. 827 There are two types of RSVP teardown message, PTEAR and RTEAR. A 828 PTEAR message travels towards all receivers downstream from its 829 point of initiation and deletes path state along the way. A RTEAR 830 message deletes reservation state and travels towards all senders 831 upstream from its point of initiation. A PTEAR (RTEAR) message 832 may be conceptualized as a reversed-sense Path message (Resv 833 message, respectively). 835 A teardown message deletes the specified state in the node where 836 it is received. Like any other state change, this will be 837 propagated immediately to the next node, but only if it represents 838 a net change after merging. As a result, an RTEAR message will 839 prune the reservation state back (only) as far as possible. 841 2.5 Admission Policy and Security 843 RSVP-mediated QoS requests will result in particular user(s) 844 getting preferential access to network resources. To prevent 845 abuse, some form of back pressure on users will be required. This 846 back pressure might take the form of administrative rules, or of 847 some form of real or virtual billing for the `cost' of a 848 reservation. The form and contents of such back pressure is a 849 matter of administrative policy that may be determined 850 independently by each administrative domain in the Internet. 852 Therefore, admission control at each node is likely to contain a 853 policy component as well as a resource reservation component. As 854 input to the policy-based admission decision, RSVP messages may 855 carry policy data. This data may include credentials identifying 856 users or user classes, account numbers, limits, quotas, etc. 858 To protect the integrity of the policy-based admission control 859 mechanisms, it may be necessary to ensure the integrity of RSVP 860 messages against corruption or spoofing, hop by hop. For this 861 purpose, RSVP messages may carry integrity objects that can be 862 created and verified by neighboring RSVP-capable nodes. These 863 objects are expected to contain an encrypted part and to assume a 864 shared secret between neighbors. 866 User policy data in reservation request messages presents a 867 scaling problem. When a multicast group has a large number of 868 receivers, it will not be possible or desirable to carry all the 869 receivers' policy data upstream to the sender(s). The policy data 870 will have to be administratively merged, near enough to the 871 receivers to avoid excessive policy data. Administrative merging 872 implies checking the user credentials and accounting data and then 873 substituting a token indicating the check has succeeded. A chain 874 of trust established using an integrity field will allow upstream 875 nodes to accept these tokens. 877 Note that the merge points for policy data are likely to be at the 878 boundaries of administrative domains. It may be necessary to 879 carry accumulated and unmerged policy data upstream through 880 multiple nodes before reaching one of these merge points. 882 2.6 Automatic RSVP Tunneling 884 It is impossible to deploy RSVP (or any new protocol) at the same 885 moment throughout the entire Internet. Furthermore, RSVP may 886 never be deployed everywhere. RSVP must therefore provide correct 887 protocol operation even when two RSVP-capable routers are joined 888 by an arbitrary "cloud" of non-RSVP routers. Of course, an 889 intermediate cloud that does not support RSVP is unable to perform 890 resource reservation, so service guarantees cannot be made. 891 However, if such a cloud has sufficient excess capacity, it may 892 provide acceptable and useful realtime service. 894 RSVP will automatically tunnel through such a non-RSVP cloud. 895 Both RSVP and non-RSVP routers forward PATH messages towards the 896 destination address using their local uni-/multicast routing 897 table. Therefore, the routing of PATH messages will be unaffected 898 by non-RSVP routers in the path. When a PATH message traverses a 899 non-RSVP cloud, the copies that emerge will carry as a Previous 900 Hop address the IP address of the last RSVP-capable router before 901 entering the cloud. This will effectively construct a tunnel 902 through the cloud for RESV messages, which will be forwarded 903 directly to the next RSVP-capable router on the path(s) back 904 towards the source. 906 Automatic tunneling is not perfect; in some circumstances it may 907 distribute path information to RSVP-capable routers not included 908 in the data distribution paths, which may create unused 909 reservations at these routers. This is because PATH messages 910 carry the IP source address of the previous hop, not of the 911 original sender, and multicast routing may depend upon the source 912 as well as the destination address. This can be overcome by 913 manual configuration of the neighboring RSVP programs, when 914 necessary. 916 2.7 Host Model 918 Before a session can be created, the session identification, 919 comprised of DestAddress and perhaps the generalized destination 920 port, must be assigned and communicated to all the senders and 921 receivers by some out-of-band mechanism. When an RSVP session is 922 being set up, the following events happen at the end systems. 924 H1 A receiver joins the multicast group specified by 925 DestAddress, using IGMP. 927 H2 A potential sender starts sending RSVP PATH messages to the 928 DestAddress, using RSVP. 930 H3 A receiver application receives a PATH message. 932 H4 A receiver starts sending appropriate RESV messages, 933 specifying the desired flow descriptors, using RSVP. 935 H5 A sender application receives a RESV message. 937 H6 A sender starts sending data packets. 939 There are several synchronization considerations. 941 o Suppose that a new sender starts sending data (H6) but no 942 receivers have joined the group (H1). Then there will be no 943 multicast routes beyond the host (or beyond the first RSVP- 944 capable router) along the path; the data will be dropped at 945 the first hop until receivers(s) do appear (assuming a 946 multicast routing protocol that "prunes off" or otherwise 947 avoids unnecessary paths). 949 o Suppose that a new sender starts sending PATH messages (H2) 950 and immediately starts sending data (H6), and there are 951 receivers but no RESV messages have reached the sender yet 952 (e.g., because its PATH messages have not yet propagated to 953 the receiver(s)). Then the initial data may arrive at 954 receivers without the desired QoS. The sender could mitigate 955 this problem by awaiting arrival of the first RESV message 956 [H5]; however, receivers that are farther away may not have 957 reservations in place yet. 959 o If a receiver starts sending RESV messages (H4) before any 960 PATH messages have reached it (H3), RSVP will return error 961 messages to the receiver. The receiver may simply choose to 962 ignore such error messages, or it may avoid them by waiting 963 for PATH messages before sending RESV messages. 965 A specific application program interface (API) for RSVP is not 966 defined in this protocol spec, as it may be host system dependent. 967 However, Section 4.6.1 discusses the general requirements and 968 presents a generic API. 970 3. Examples 972 We use the following notation for a RESV message: 974 1. Wildcard-Filter (WF) 976 WF( *{Q}) 978 Here "*{Q}" represents a Flow Descriptor with a "wildcard" scope 979 (choosing all senders) and a flowspec of quantity Q. 981 2. Fixed-Filter (FF) 983 FF( S1{Q1}, S2{Q2}, ...) 985 A list of (sender, flowspec) pairs, i.e., flow descriptors, 986 packed into a single RESV message. 988 3. Shared Explicit (SE) 990 SE( (S1,S2,...)Q1, (S3,S4,...)Q2, ...) 992 A list of shared reservations, each specified by a single 993 flowspec and a list of senders. 995 For simplicity we assume here that flowspecs are one-dimensional, 996 defining for example the average throughput, and state them as a 997 multiple of some unspecified base resource quantity B. 999 Figure 6 shows schematically a router with two previous hops labeled 1000 (a) and (b) and two outgoing interfaces labeled (c) and (d). This 1001 topology will be assumed in the examples that follow. There are 1002 three upstream senders; packets from sender S1 (S2 and S3) arrive 1003 through previous hop (a) ((b), respectively). There are also three 1004 downstream receivers; packets bound for R1 and R2 (R3) are routed via 1005 outgoing interface (c) ((d) respectively). 1007 In addition to the connectivity shown in 6, we must also specify the 1008 multicast routing within this node. Assume first that data packets 1009 (hence, PATH messages) from each Si shown in Figure 6 is routed to 1010 both outgoing interfaces. Under this assumption, Figures 7, 8, and 9 1011 illustrate Wildcard-Filter, Fixed-Filter, and Shared-Explicit 1012 reservations, respectively. 1014 ________________ 1015 (a)| | (c) 1016 ( S1 ) ---------->| |----------> ( R1, R2) 1017 | Router | 1018 (b)| | (d) 1019 ( S2,S3 ) ------->| |----------> ( R3 ) 1020 |________________| 1022 Figure 6: Router Configuration 1024 In Figure 7, the "Receive" column shows the RESV messages received 1025 over outgoing interfaces (c) and (d) and the "Reserve" column shows 1026 the resulting reservation state for each interface. The "Send" 1027 column shows the RESV messages forwarded to previous hops (a) and 1028 (b). In the "Reserve" column, each box represents one reservation 1029 "channel", with the corresponding filter. As a result of merging, 1030 only the largest flowspec is forwarded upstream to each previous hop. 1032 | 1033 Send | Reserve Receive 1034 | 1035 | _______ 1036 WF( *{3B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} ) 1037 | |_______| 1038 | 1039 -----------------------|---------------------------------------- 1040 | _______ 1041 WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) 1042 | |_______| 1044 Figure 7: Wildcard-Filter (WF) Reservation Example 1046 Figure 8 shows Fixed-Filter (FF) style reservations. The flow 1047 descriptors for senders S2 and S3, received from outgoing interfaces 1048 (c) and (d), are packed into the message forwarded to previous hop b. 1049 On the other hand, the two different flow descriptors for sender S1 1050 are merged into the single message FF( S1{3B} ), which is sent to 1051 previous hop (a). For each outgoing interface, there is a private 1052 reservation for each source that has been requested, but this private 1053 reservation is shared among the receivers that made the request. 1055 | 1056 Send | Reserve Receive 1057 | 1058 | ________ 1059 FF( S1{3B} ) <- (a) | (c) | S1{B} | (c) <- FF( S1{B}, S2{5B} ) 1060 | |________| 1061 | | S2{5B} | 1062 | |________| 1063 ---------------------|--------------------------------------------- 1064 | ________ 1065 <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) 1066 FF( S2{5B}, S3{B} ) | |________| 1067 | | S3{B} | 1068 | |________| 1070 Figure 8: Fixed-Filter (FF) Reservation Example 1072 Figure 9 shows a simple example of Shared-Explicit (SE) style 1073 reservations. Here each outgoing interface has a single reservation 1074 that is shared by a list of senders. 1076 | 1077 Send | Reserve Receive 1078 | 1079 | ________ 1080 SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} ) 1081 | | {B} | 1082 | |________| 1083 ---------------------|--------------------------------------------- 1084 | ________ 1085 <- (b) | (d) |(S1,S3) | (d) <- SE( (S1,S3){3B} ) 1086 SE( (S2,S3){3B} ) | | {3B} | 1087 | |________| 1089 Figure 9: Shared-Explicit (SE) Reservation Example 1091 The three examples just shown assume full routing, i.e., data packets 1092 from S1, S2, and S3 are routed to both outgoing interfaces. The top 1093 part of Figure 10 shows another routing assumption: data packets 1094 from S1 are not forwarded to interface (d), because the mesh topology 1095 provides a shorter path for S1 -> R3 that does not traverse this 1096 node. The bottom of Figure 10 shows WF style reservations under this 1097 assumption. Since there is no route from (a) to (d), the reservation 1098 forwarded out interface (a) considers only the reservation on 1099 interface (c); no merging takes place in this case. 1101 _______________ 1102 (a)| | (c) 1103 ( S1 ) ---------->| --------->--> |----------> ( R1, R2) 1104 | / | 1105 | / | 1106 (b)| / | (d) 1107 ( S2,S3 ) ------->| ->----------> |----------> ( R3 ) 1108 |_______________| 1110 Router Configuration 1112 | 1113 Send | Reserve Receive 1114 | 1115 | _______ 1116 WF( *{B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} ) 1117 | |_______| 1118 | 1119 -----------------------|---------------------------------------- 1120 | _______ 1121 WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) 1122 | |_______| 1124 Figure 10: WF Reservation Example -- Partial Routing 1126 Finally, we note that state that is received through a particular 1127 interface I is never forwarded out the same interface. Conversely, 1128 state that is forwarded out interface I must be computed using only 1129 state that arrived on interfaces different from I. A trivial example 1130 of this rule is illustrated in Figure 11, which shows a transit 1131 router with one sender and one receiver on each interface (and 1132 assumes one next/previous hop per interface). Interfaces (a) and (c) 1133 are both outgoing and incoming interfaces for this session. Both 1134 receivers are making wildcard-scope reservations, in which the RESV 1135 messages are forwarded to all previous hops for senders in the group, 1136 with the exception of the next hop from which they came. These 1137 result in independent reservations in the two directions. 1139 ________________ 1140 a | | c 1141 ( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) 1142 |________________| 1144 Send | Receive 1145 | 1146 WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) 1147 | 1148 Receive | Send 1149 | 1150 WF( *{4B}) --> (a) | (c) --> WF( *{4B}) 1151 | 1152 Reserve on (a) | Reserve on (c) 1153 __________ | __________ 1154 | * {4B} | | | * {3B} | 1155 |__________| | |__________| 1156 | 1158 Figure 11: Independent Reservations 1160 4. RSVP Functional Specification 1162 4.1 RSVP Message Formats 1164 All RSVP messages consist of a common header followed by a 1165 variable number of variable-length typed "objects". The 1166 subsections that follow define the formats of the common header, 1167 the object structures, and each of the RSVP message types. 1169 For each RSVP message type, there is a set of rules for the 1170 permissible ordering and choice of object types. These rules are 1171 specified using Backus-Naur Form (BNF) augmented with square 1172 brackets surrounding optional sub-sequences. 1174 4.1.1 Common Header 1176 0 1 2 3 1177 +-------------+-------------+-------------+-------------+ 1178 | Vers | Flags| Type | RSVP Checksum | 1179 +-------------+-------------+-------------+-------------+ 1180 | RSVP Length | (Reserved) | 1181 +-------------+-------------+-------------+-------------+ 1182 | Message ID | 1183 +----------+--+-------------+-------------+-------------+ 1184 |(Reserved)|MF| Fragment offset | 1185 +----------+--+-------------+-------------+-------------+ 1187 The fields in the common header are as follows: 1189 Vers: 4 bits 1191 Protocol version number. This is version 1. 1193 Flags: 4 bits 1195 (None defined yet) 1197 Type: 8 bits 1199 1 = PATH 1201 2 = RESV 1203 3 = PERR 1205 4 = RERR 1206 5 = PTEAR 1208 6 = RTEAR 1210 RSVP Checksum: 16 bits 1212 A standard TCP/UDP checksum over the contents of the RSVP 1213 message, with the checksum field replaced by zero. 1215 RSVP Length: 16 bits 1217 The total length of this RSVP packet in bytes, including 1218 the common header and the variable-length objects that 1219 follow. If the MF flag is on or the Fragment Offset field 1220 is non-zero, this is the length of the current fragment of 1221 a larger message. 1223 Message ID: 32 bits 1225 A label shared by all fragments of one message from a 1226 given next/previous RSVP hop. An RSVP implementation 1227 assignes a unique Message ID to each message it sends. 1229 MF: More Fragments Flag: 1 bit 1231 This flag is the low-order bit of a byte; the seven high- 1232 order bits are reserved. It is on for all but the last 1233 fragment of a message. 1235 Fragment Offset: 24 bits 1237 This field gives the byte offset of the fragment in the 1238 message. 1240 4.1.2 Object Formats 1242 An object consists of one or more 32-bit words with a one-word 1243 header, in the following format: 1245 0 1 2 3 1246 +-------------+-------------+-------------+-------------+ 1247 | Length (bytes) | Class-Num | C-Type | 1248 +-------------+-------------+-------------+-------------+ 1249 | | 1250 // (Object contents) // 1251 | | 1252 +-------------+-------------+-------------+-------------+ 1253 An object header has the following fields: 1255 Length 1257 A 16-bit field containing the total object length in 1258 bytes. Must always be a multiple of 4, and at least 4. 1260 Class-Num 1262 Identifies the object class; values of this field are 1263 defined in Appendix A. Each object class has a name, 1264 which will always be capitalized in this document. An 1265 RSVP implementation must recognize the following classes: 1267 NULL 1269 A NULL object has a Class-Num of zero, and its C-Type 1270 is ignored. Its length must be at least 4, but can 1271 be any multiple of 4. A NULL object may appear 1272 anywhere in a sequence of objects, and its contents 1273 will be ignored by the receiver. 1275 SESSION 1277 Contains the IP destination address (DestAddress) and 1278 possibly a generalized destination port, to define a 1279 specific session for the other objects that follow. 1280 Required in every RSVP message. 1282 RSVP_HOP 1284 Carries the IP address of the RSVP-capable node that 1285 sent this message. This document refers to a 1286 RSVP_HOP object as a PHOP ("previous hop") object for 1287 downstream messages or as a NHOP ("next hop") object 1288 for upstream messages. 1290 TIME_VALUES 1292 If present, contains values for the refresh period R 1293 and the state time-to-live T (see section 4.5), to 1294 override the default values of R and T. 1296 STYLE 1298 Defines the reservation style plus style-specific 1299 information that is not a FLOWSPEC or FILTER_SPEC 1300 object, in a RESV message. 1302 FLOWSPEC 1304 Defines a desired QoS, in a RESV message. 1306 FILTER_SPEC 1308 Defines a subset of session data packets that should 1309 receive the desired QoS (specified by an FLOWSPEC 1310 object), in a RESV message. 1312 SENDER_TEMPLATE 1314 Contains a sender IP address and perhaps some 1315 additional demultiplexing information to identify a 1316 sender, in a PATH message. 1318 SENDER_TSPEC 1320 Defines the traffic characteristics of a sender's 1321 data stream, in a PATH message. 1323 ADSPEC 1325 Carries an Adspec containing OPWA data, in a PATH 1326 message. 1328 ERROR_SPEC 1330 Specifies an error, in a PERR or RERR message. 1332 POLICY_DATA 1334 Carries information that will allow a local policy 1335 module to decide whether an associated reservation is 1336 administratively permitted. May appear in a PATH or 1337 RESV message. 1339 INTEGRITY 1341 Contains cryptographic data to authenticate the 1342 originating node, and perhaps to verify the contents, 1343 of this RSVP message. 1345 SCOPE 1347 An explicit specification of the scope for forwarding 1348 a RESV message. 1350 C-Type 1352 Object type, unique within Class-Num. Values are defined 1353 in Appendix A. 1355 The maximum object content length is 65528 bytes. The Class- 1356 Num and C-Type fields (together with the 'Optional' flag bit) 1357 may be used together as a 16-bit number to define a unique type 1358 for each object. 1360 The high-order bit of the Class-Num is used to determine what 1361 action a node should take if it does not recognize the Class- 1362 Num of an object. If Class-Num < 128, then the node should 1363 ignore the object but forward it (unmerged). If Class-Num >= 1364 128, the message should be rejected and an "Unknown Object 1365 Class" error returned. Note that merging cannot be performed 1366 on unknown object types; as a result, unmerged objects may be 1367 forwarded to the first node that does know how to merge them. 1368 The scaling limitations that this imposes must be considered 1369 when defining and deploying new object types. 1371 4.1.3 Path Message 1373 PATH messages carry information from senders to receivers along 1374 the paths used by the data packets. The IP destination address 1375 of a PATH message is the DestAddress for the session; the 1376 source address is an address of the node that sent the message 1377 (preferably the address of the interface through which it was 1378 sent). The PHOP (i.e., the RSVP_HOP) object of each PATH 1379 message must contain the address of the interface through which 1380 the PATH message was sent. 1382 The format of a PATH message is as follows: 1384 ::= 1386 [ ] [ ] 1388 1390 ::= | 1392 1394 ::= [ ] 1396 [ ] [ ] 1398 Each sender descriptor defines a sender, and the sender 1399 descriptor list allows multiple sender descriptors to be packed 1400 into a PATH message. For each sender in the list, the 1401 SENDER_TEMPLATE object defines the format of data packets; in 1402 addition, a SENDER_TSPEC object may specify the traffic flow, a 1403 POLICY_DATA object may specify user credential and accounting 1404 information, and an ADSPEC object may carry advertising (OPWA) 1405 data. 1407 Each sender host must periodically send PATH message(s) 1408 containing a sender descriptor for each its own data stream(s). 1409 Each sender descriptor is forwarded and replicated as necessary 1410 to follow the delivery path(s) for a data packet from the same 1411 sender, finally reaching the applications on all receivers 1412 (except that it is not looped back to a receiver included in 1413 the same application process as the sender). 1415 It is an error to send ambiguous path state, i.e., two or more 1416 Sender Templates that are different but overlap, due to 1417 wildcards. For example, if we represent a Sender Template as 1418 (IP address, sender port, protocol id and use `*' to represent 1419 a wildcard, then each of the following pairs of Sender 1420 Templates would be an error: 1422 (10.1.2.3, 34567, *) and (10.1.2.3, *, *) 1424 (10.1.2.3, 34567, *) and (10.1.2.3, 34567, 17) 1426 A PATH message received at a node is processed to create path 1427 state for all senders defined by SENDER_TEMPLATE objects in the 1428 sender descriptor list. If present, any POLICY_DATA, 1429 SENDER_TSPEC, and ADSPEC objects are also saved in the path 1430 state. If an error is encountered while processing a PATH 1431 message, a PERR message is sent to all senders implied by the 1432 SENDER_TEMPLATEs. 1434 Periodically, the path state is scanned to create new PATH 1435 messages to be forwarded downstream. A node must independently 1436 compute the route for each sender descriptor being forwarded. 1437 These routes, obtained from uni-/multicast routing, generally 1438 depend upon the (sender host address, DestAddress) pairs and 1439 consist of a list of outgoing interfaces. The descriptors 1440 being forwarded through the same outgoing interface may be 1441 packed into as few PATH messages as possible. Note that 1442 multicast routing of path information is based on the sender 1443 address(es) from the sender descriptors, not the IP source 1444 address; this is necessary to prevent routing loops; see 1445 Section 4.3. 1447 Multicast routing may also report the expected incoming 1448 interface (i.e., the shortest path back to the sender). If so, 1449 any PATH message that arrives on a different interface should 1450 be discarded immediately. 1452 It is possible that routing will report no routes for a 1453 (sender, DestAddress) pair; path state for this sender should 1454 be stored locally but not forwarded. 1456 4.1.4 Resv Messages 1458 RESV messages carry reservation requests hop-by-hop from 1459 receivers to senders, along the reverse paths of data flow for 1460 the session. The IP destination address of a RESV message is 1461 the unicast address of a previous-hop node, obtained from the 1462 path state. The IP source address is an address of the node 1463 that sent the message. The NHOP (i.e., the RSVP_HOP) object 1464 must contain the IP address of the (incoming) interface through 1465 which the RESV message is sent. 1467 The RESV message format is as follows: 1469 ::= 1471 [ ] [ ] 1473 [ ] [ ] 1475