idnits 2.17.1 draft-ietf-rsvp-spec-06.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-04-26) 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 12 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1562 has weird spacing: '...dresses can b...' == Line 2279 has weird spacing: '...ed flag param...' == Line 3219 has weird spacing: '... object k ...' == Line 3342 has weird spacing: '... object k ...' == Line 3777 has weird spacing: '...ildcard scope...' -- 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 (June 21, 1995) is 10537 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 965, but not defined == Missing Reference: 'S4' is mentioned on line 1934, but not defined == Missing Reference: 'S1' is mentioned on line 1930, but not defined == Missing Reference: 'S2' is mentioned on line 1934, but not defined == Missing Reference: 'S3' is mentioned on line 1934, but not defined == Missing Reference: 'TBD' is mentioned on line 3321, but not defined == Unused Reference: 'CSZ92' is defined on line 3925, but no explicit reference was found in the text == Unused Reference: 'IServ93' is defined on line 3933, but no explicit reference was found in the text == Unused Reference: 'Partridge92' is defined on line 3936, 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 (~~), 16 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: December 1995 ISI 4 File: draft-ietf-rsvp-spec-06.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 June 21, 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 Boston IETF 46 The most important changes in this document from the rsvp-spec-05 draft 47 are: 49 o Added SE (Shared Explicit) style to all parts of the document. 51 o Further clarified reservation options and added table in Figure 52 3. Defined option vector in STYLE object. 54 o Renamed CREDENTIAL object class to POLICY_DATA object class, and 55 rewrote section 2.5 to more fully express its intended usage. 57 o Clarified the relationship between the wildcard scope 58 reservation option and wildcards in individual FILTER_SPEC 59 objects: wildcard is as wildcard does. 61 o Added SCOPE object definition and define the rules for its use 62 to prevent looping of wildcard-scope messages. 64 o Added TAG object. This is needed to do semantic fragmentation 65 in certain cases; however, the rules for its use are not yet 66 written down. Furthermore, there has been some debate about 67 semantic fragmentation. 69 o Added some mechanisms for handling backwards compatibility for 70 future protocol extensions: (1) High bit of object class number; 71 (2) unmerged FLOWSPEC C-Type; (3) unmerged POLICY_DATA C-Type. 73 o Rewrote Section 4.3 on preventing looping. Included rules for 74 SCOPE object. 76 o Specified rules for local repair upon route change notification 77 (Section 4.4). 79 o Specified for each error type whether or not the state 80 information in the erroneous packet is to be stored and 81 forwarded. 83 o Deleted the discussion of retransmitting a Teardown message Q 84 times; assume Q=1 is sufficient. 86 o Moved Session Groups to Appendix D, "Experimental and Open 87 Issues". Session Groups should be revisited as part of a larger 88 context of cross-session reservations. 90 o Changed common header format, removing Object Count (which was 91 redundant) and rearranging the remaining fields. Moved the two 92 common header flags into objects: Entry-Police into SESSION 93 object and LUB-used into ERROR_SPEC object. 95 o Revised the rules for state timeout (Section 4.5) and redefined 96 the TIME_VALUES object format. 98 o Changed the error message format: (1) removed required RSVP_HOP 99 object from PERR and RERR messages; (2) removed CREDENTIAL 100 (i.e., POLICY_DATA) object from RERR messages; (3) specified 101 more carefully what may appear in flow descriptor list of RERR 102 messages. 104 o Revised the definitions of error codes and error values, and 105 moved them into a separate Appendix B. 107 o No longer require CREDENTIAL (i.e., POLICY_DATA) match for 108 teardown. 110 o Revised routing of RERR messages to use SCOPE objects to avoid 111 wildcard-induced looping. 113 o Added LIH (logical interface handle) to RSVP_HOP object, for IP 114 multicast tunnels. 116 o Added two new upcall event types in the API: reservation event 117 and policy data event. 119 o Generalized the generic traffic control calls slightly to allow 120 multiple filter specs per flowspec, for SE style. This 121 introduced a new set of handles, called FHandle. Also added a 122 preemption upcall. 124 o Added route change notification to the generic interface to 125 routing. 127 o Updated the message processing rules (Section 5). 129 o Rewrote Appendix C on UDP encapsulation. 131 o Removed specification of FLOWSPEC object format (but int-serv 132 working group has since reneged on promise to specify it). 134 1. Introduction 136 This document defines RSVP, a resource reservation setup protocol 137 designed for an integrated services Internet [RSVP93,ISInt93]. 139 A host uses the RSVP protocol to request a specific quality of 140 service (QoS) from the network, on behalf of an application data 141 stream. RSVP is also used to deliver QoS requests to routers along 142 the path(s) of the data stream and to maintain router and host state 143 to provide the requested service. This will generally (but not 144 necessarily) require reserving resources along the data path. 146 RSVP reserves resources for simplex data streams, i.e., it reserves 147 resources in only one direction on a link, so that a sender is 148 logically distinct from a receiver. However, the same application 149 may act as both sender and receiver. RSVP operates on top of IP, 150 occupying the place of a transport protocol in the protocol stack. 151 However, like ICMP, IGMP, and routing protocols, RSVP does not 152 transport application data but is rather an Internet control 153 protocol. As shown in Figure 1, an implementation of RSVP, like the 154 implementations of routing and management protocols, will typically 155 execute in the background, not in the data forwarding path. 157 RSVP is not itself a routing protocol; the RSVP daemon consults the 158 local routing protocol(s) to obtain routes. Thus, a host sends IGMP 159 messages to join a multicast group, and it sends RSVP messages to 160 reserve resources along the delivery path(s) from that group. RSVP 161 is designed to operate with existing and future unicast and multicast 162 routing protocols. 164 HOST ROUTER 166 _________________________ RSVP ______________________ 167 | | .---------------. | 168 | _______ ______ | . | ________ . ______ | 169 | | | | | | . || | . | || RSVP 170 | |Applic-| | RSVP <----- ||Routing | -> RSVP <------> 171 | | App <----->daemon| | ||Protocol| |daemon|| 172 | | | | | | || daemon <----> || 173 | |_______| |___.__| | ||_ ._____| |__.___|| 174 |===|===============v=====| |===v=============v====| 175 | data .......... | | . ............ | 176 | | ____v_ ____v____ | | _v__v_ _____v___ | 177 | | |Class-| | || data | |Class-| | || data 178 | |=> ifier|=> Packet =============> ifier|==> Packet |======> 179 | |______| |Scheduler|| | |______| |Scheduler|| 180 | |_________|| | |_________|| 181 |_________________________| |______________________| 183 Figure 1: RSVP in Hosts and Routers 185 Each router that is capable of resource reservation passes incoming 186 data packets to a packet classifier and then queues them as necessary 187 in a packet scheduler. The packet classifier determines the route 188 and the QoS class for each packet. The scheduler allocates resources 189 for transmission on the particular link-layer medium used by each 190 interface. If the link-layer medium is QoS-active, i.e., if it has 191 its own QoS management capability, then the packet scheduler is 192 responsible for negotiation with the link layer to obtain the QoS 193 requested by RSVP. There are many possible ways this might be 194 accomplished, and the details will be medium-dependent. The 195 scheduler itself allocates packet transmission capacity on a QoS- 196 passive medium such as a leased line. The scheduler may also 197 allocate other system resources such as CPU time or buffers. 199 In order to efficiently accommodate heterogeneous receivers and 200 dynamic group membership and to be consistent with IP multicast, RSVP 201 makes receivers responsible for requesting resource reservations 202 [RSVP93]. A QoS request, typically originating in a receiver host 203 application, will be passed to the local RSVP implementation, shown 204 as a user daemon in Figure 1. The RSVP protocol is then used to pass 205 the request to all the nodes (routers and hosts) along the reverse 206 data path(s) to the data source(s). 208 At each node, the RSVP program applies a local decision procedure, 209 called "admission control", to determine if it can supply the 210 requested QoS. If admission control succeeds, the RSVP program sets 211 parameters to the packet classifier and scheduler to obtain the 212 desired QoS. If admission control fails at any node, the RSVP 213 program returns an error indication to the application that 214 originated the request. We refer to the packet classifier, packet 215 scheduler, and admission control components as "traffic control". 217 RSVP is designed to scale well for very large multicast groups. 218 Since the membership of a large group will be constantly changing, 219 the RSVP design assumes that router state for traffic control will be 220 built and destroyed incrementally. For this purpose, RSVP uses "soft 221 state" in the routers, in addition to receiver-initiation. 223 RSVP protocol mechanisms provide a general facility for creating and 224 maintaining distributed reservation state across a mesh of multicast 225 or unicast delivery paths. RSVP transfers reservation parameters as 226 opaque data (except for certain well-defined operations on the data), 227 which it simply passes to traffic control for interpretation. 228 Although the RSVP protocol mechanisms are largely independent of the 229 encoding of these parameters, the encodings must be defined in the 230 reservation model that is presented to an application (see Appendix 231 A). 233 In summary, RSVP has the following attributes: 235 o RSVP supports multicast or unicast data delivery and adapts to 236 changing group membership as well as changing routes. 238 o RSVP is simplex. 240 o RSVP is receiver-oriented, i.e., the receiver of a data flow is 241 responsible for the initiation and maintenance of the resource 242 reservation used for that flow. 244 o RSVP maintains "soft state" in the routers, enabling it to 245 gracefully support dynamic membership changes and automatically 246 adapt to routing changes. 248 o RSVP provides several reservation models or "styles" (defined 249 below) to fit a variety of applications. 251 o RSVP provides transparent operation through routers that do not 252 support it. 254 Further discussion on the objectives and general justification for 255 RSVP design are presented in [RSVP93,ISInt93]. 257 The remainder of this section describes the RSVP reservation 258 services. Section 2 presents an overview of the RSVP protocol 259 mechanisms, while Section 3 gives examples of the services and 260 mechanism. Section 4 contains the functional specification of RSVP. 261 Section 5 presents explicit message processing rules. 263 1.1 Data Flows 265 The set of data flows with the same unicast or multicast 266 destination constitute a session. RSVP treats each session 267 independently. All data packets in a particular session are 268 directed to the same IP destination address DestAddress, and 269 perhaps to some further demultiplexing point defined in a higher 270 layer (transport or application). We refer to the latter as a 271 "generalized destination port". 273 DestAddress is the group address for multicast delivery, or the 274 unicast address of a single receiver. A generalized destination 275 port could be defined by a UDP/TCP destination port field, by an 276 equivalent field in another transport protocol, or by some 277 application-specific information. Although the RSVP protocol is 278 designed to be easily extendible for greater generality, the 279 present version uses only UDP/TCP ports as generalized ports. 281 Figure 2 illustrates the flow of data packets in a single RSVP 282 session, assuming multicast data distribution. The arrows 283 indicate data flowing from senders S1 and S2 to receivers R1, R2, 284 and R3, and the cloud represents the distribution mesh created by 285 the multicast routing protocol. Multicast distribution forwards a 286 copy of each data packet from a sender Si to every receiver Rj; a 287 unicast distribution session has a single receiver R. Each sender 288 Si and each receiver Rj may correspond to a unique Internet host, 289 or a single host may contain multiple logical senders and/or 290 receivers, distinguished by generalized ports. 292 Senders Receivers 293 _____________________ 294 ( ) ===> R1 295 S1 ===> ( Multicast ) 296 ( ) ===> R2 297 ( distribution ) 298 S2 ===> ( ) 299 ( by Internet ) ===> R3 300 (_____________________) 302 Figure 2: Multicast Distribution Session 304 Even if the destination address is unicast, there may be multiple 305 receivers, distinguished by the generalized port. There may also 306 be multiple senders for a unicast destination, i.e., RSVP can set 307 up reservations for multipoint-to-point transmission. 309 1.2 Reservation Model 311 An elementary RSVP reservation request consists of a "flowspec" 312 together with a "filter spec"; this pair is called a "flow 313 descriptor". The flowspec specifies a desired QoS. The filter 314 spec (together with the DestAddress and the generalized 315 destination port defining the session) defines the set of data 316 packets -- the "flow" -- to receive the QoS defined by the 317 flowspec. The flowspec is used to set parameters to the node's 318 packet scheduler (assuming that admission control succeeds), while 319 the filter spec is used to set parameters in the packet 320 classifier. Note that the action to control the QoS occurs at the 321 place where the data enters the medium, i.e., at the upstream end 322 of the link, although the RSVP reservation request originates from 323 receiver(s) downstream. 325 The flowspec in a reservation request will generally include a 326 service type and two sets of numeric parameters: (1) an "Rspec" (R 327 for `reserve'), which defines the desired per-hop reservation, and 328 (2) a "Tspec" (T for `traffic'), which defines the parameters that 329 may be used to police the data flow, i.e., to ensure it does not 330 exceed its promised traffic level. 332 The form and contents of Tspecs and Rspecs are determined by the 333 integrated service model [ServTempl95a], and are generally opaque 334 to RSVP. RSVP delivers the Tspec and Rspec, together with an 335 indication whether traffic policing is needed to the admission 336 control and packet scheduling components of traffic control. A 337 service that requires traffic policing might for example apply it 338 at the edge of the network and at data merge points; RSVP knows 339 when these occur and must so indicate to the traffic control 340 mechanism. On the other hand, RSVP cannot interpret the service 341 embodied in the flowspec and therefore does not know whether 342 policing will actually be applied in a particular case. 344 In the general RSVP reservation model [RSVP93], filter specs may 345 select arbitrary subsets of the packets in a given session. Such 346 subsets might be defined in terms of senders (i.e., sender IP 347 address and generalized source port), in terms of a higher-level 348 protocol, or generally in terms of any fields in any protocol 349 headers in the packet. For example, filter specs might be used to 350 select different subflows in a hierarchically-encoded signal by 351 selecting on fields in an application-layer header. However, in 352 the interest of simplicity (and to minimize layer violation), the 353 present RSVP version uses a much more restricted form of filter 354 spec: select only on sender IP address, on UDP/TCP port number, 355 and perhaps on IP protocol id. 357 RSVP can distinguish subflows of a hierarchically-encoded signal 358 if they are assigned distinct multicast destination addresses, or, 359 for a unicast destination, distinct destination ports. Data 360 packets that are addressed to a particular session but do not 361 match any of the filter specs for that session are expected to be 362 sent as best-effort traffic, and under congested conditions, such 363 packets are likely to experience long delays, and they may be 364 dropped. When a receiver does not wish to receive a particular 365 (sub-)flow, it can economize on network resources by explicitly 366 asking the network to drop unneeded the data packets; it does so 367 by leaving the multicast group(s) to which these packets are 368 addressed. Thus, determining where packets get delivered should 369 be a routing function; RSVP is concerned only with the QoS of 370 those packets that are delivered by routing. 372 RSVP reservation request messages originate at receivers and are 373 passed upstream towards the sender(s). (This document defines the 374 directional terms "upstream" vs. "downstream", "previous hop" vs. 375 "next hop", and "incoming interface" vs "outgoing interface" with 376 respect to the data flow direction.) When an elementary 377 reservation request is received at a node, the RSVP daemon takes 378 two primary actions: 380 1. Daemon makes a reservation 382 The flowspec and the filter spec are passed to traffic 383 control. Admission control determines the admissibility of 384 the request (if it's new); if this test fails, the 385 reservation is rejected and RSVP returns an error message to 386 the appropriate receiver(s). If admission control succeeds, 387 the node uses the flowspec to set up the packet scheduler for 388 the desired QoS and the filter spec to set the packet 389 classifier to select the appropriate data packets. 391 2. Daemon forwards the reservation upstream 393 The reservation request is propagated upstream towards the 394 appropriate senders. The set of sender hosts to which a 395 given reservation request is propagated is called the "scope" 396 of that request. 398 The reservation request that a node forwards upstream may differ 399 from the request that it received, for two reasons. First, it is 400 possible (in theory) for the kernel to modify the flowspec hop- 401 by-hop, although currently no realtime services do this. Second, 402 reservations from different downstream branches of the multicast 403 distribution tree(s) must be "merged" as reservations travel 404 upstream. Merging reservations is a necessary consequence of 405 multicast distribution, which creates a single stream of data 406 packets in a particular router from any Si, regardless of the set 407 of receivers downstream. The reservation for Si on a particular 408 outgoing link L should be the "maximum" of the individual 409 flowspecs from the receivers Rj that are downstream via link L. 410 Merging is discussed further in Section 2.2. 412 The basic RSVP reservation model is "one pass": a receiver sends a 413 reservation request upstream, and each node in the path can only 414 accept or reject the request. This scheme provides no way to make 415 end-to-end service guarantees, since the QoS request must be 416 applied independently at each hop. RSVP also supports an optional 417 reservation model, known as "One Pass With Advertising" (OPWA) 418 [Shenker94]. In OPWA, RSVP control packets sent downstream, 419 following the data paths, are used to gather information on the 420 end-to-end service that would result from a variety of possible 421 reservation requests. The results ("advertisements") are 422 delivered by RSVP to the receiver host, and perhaps to the 423 receiver application. The information may then be used by the 424 receiver to construct an appropriate reservation request. 426 1.3 Reservation Styles 428 A reservation request includes a set of control options. One 429 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" all senders' packets. A distinct 433 reservation requires that the filter spec match exactly one 434 sender, a wildcard reservation must match at least one. Another 435 option controls the scope of the request: an " explicit" sender 436 specification, or a "wildcard" that implicitly selects all sender 437 hosts upstream of the given node. 439 These control options are collectively called the reservation 440 "style", as shown in Figure 3. 442 || Reservations: 443 Scope || Distinct | Shared 444 _________||__________________|____________________ 445 || | | 446 Explicit || Fixed-Filter | Shared-Explicit | 447 || (FF) style | (SE) Style | 448 __________||__________________|____________________| 449 || | | 450 Wildcard || (None defined) | Wildcard-Filter | 451 || | (WF) Style | 452 __________||__________________|____________________| 454 Figure 3: Reservation Attributes and Styles 456 The styles currently defined are as follows: 458 1. Wildcard-Filter (WF) Style 460 The WF style implies the options: "shared" reservation and " 461 wildcard" reservation scope. Thus, a WF-style reservation 462 creates a single reservation into which flows from all 463 upstream senders are mixed; this reservation may be thought 464 of as a shared "pipe", whose "size" is the largest of the 465 resource requests for that link from all receivers, 466 independent of the number of senders using it. A WF-style 467 reservation has wildcard scope, i.e., the reservation is 468 propagated upstream towards all sender hosts. A WF-style 469 reservation automatically extends to new senders as they 470 appear. 472 2. Fixed-Filter (FF) Style 474 The FF style implies the options: "distinct" reservations and 475 "explicit" reservation scope. Thus, an elementary FF-style 476 reservation request creates a distinct reservation for data 477 packets from a particular sender, not sharing them with other 478 senders' packets for the same session. It scope is 479 determined by an explicit list of senders. 481 The total reservation on a link for a given session is the 482 total of the FF reservations for all requested senders. On 483 the other hand, FF reservations requested by different 484 receivers Rj but selecting the same sender Si must 485 necessarily be merged to share a single reservation in a 486 given node. 488 3. Shared Explicit (SE) Style 490 The SE style implies the options: "shared" reservation and " 491 explicit" reservation scope. Thus, an SE-style reservation 492 creates a single reservation into which flows from all 493 upstream senders are mixed. However, like a FF reservation 494 the set of senders (and therefore its scope (and therefore 495 the scope) is specified explicitly by the receiver making the 496 reservation. 498 WF and SE are both shared reservations, appropriate for those 499 multicast applications whose application-specific constraints make 500 it unlikely that multiple data sources will transmit 501 simultaneously. One example is audio conferencing, where a limited 502 number of people talk at once; each receiver might issue a WF or 503 SE reservation request for twice one audio channel (to allow some 504 over-speaking). On the other hand, the FF style, which creates 505 independent reservations for the flows from different senders, is 506 appropriate for video signals. 508 It is not possible to merge shared reservations with distinct 509 reservations. Therefore, WF and SE styles are incompatible with 510 FF, but are compatible with each other. Merging a WF style 511 reservation with an SE style reservation results in a WF 512 reservation. 514 Other reservation options and styles may be defined in the future 515 (see Appendix D.4, for example). 517 2. RSVP Protocol Mechanisms 519 2.1 RSVP Messages 521 There are two fundamental RSVP message types: RESV and PATH . 523 Each receiver host sends RSVP reservation request (RESV) messages 524 towards the senders. These reservation messages must follow in 525 reverse the routes the data packets will use, all the way upstream 526 to the sender hosts included in the scope. RESV messages must be 527 delivered to the sender hosts so that the hosts can set up 528 appropriate traffic control parameters for the first hop. 530 Also note that RSVP sends no positive acknowledgment messages to 531 indicate success (although the delivery of a reservation request 532 to a sender could be used to trigger an acknowledgement at a 533 higher level of protocol.) 534 Sender Receiver 535 _____________________ 536 Path --> ( ) 537 Si =======> ( Multicast ) Path --> 538 <-- Resv ( ) =========> Rj 539 ( distribution ) <-- Resv 540 (_____________________) 542 Figure 4: RSVP Messages 544 Each sender transmits RSVP PATH messages forward along the uni- 545 /multicast routes provided by the routing protocol(s); see Figure 546 4. These "Path" messages store path state in each node. Path 547 state is used by RSVP to route the RESV messages hop-by-hop in the 548 reverse direction. (In the future, some routing protocols may 549 supply reverse path forwarding information directly, replacing the 550 reverse-routing function of path state). 552 PATH messages may also carry the following information: 554 o Sender Template 556 The Sender Template describes the format of data packets that 557 the sender will originate. This template is in the form of a 558 filter spec that could be used to select this sender's 559 packets from others in the same session on the same link. 561 Like a filter spec, the Sender Template is less than fully 562 general at present, specifying only sender IP address, 563 UDP/TCP sender port, and protocol id. The port number 564 and/or protocol id can be wildcarded. 566 o Tspec 568 PATH message may optionally carry a Tspec that defines an 569 upper bound on the traffic level that the sender will 570 generate. This Tspec can be used by RSVP to prevent over- 571 reservation (and perhaps unnecessary Admission Control 572 failure) on the non-shared links starting at the sender. 574 o Adspec 576 The PATH message may carry a package of OPWA advertising 577 information, known as an "Adspec". An Adspec received in a 578 PATH message is passed to the local traffic control routines, 579 which return an updated Adspec; the updated version is 580 forwarded downstream. 582 Previous Incoming Outgoing Next 583 Hops Interfaces Interfaces Hops 585 _____ _____________________ _____ 586 | | data --> | | data --> | | 587 | A |-----------| a c |--------------| C | 588 |_____| <-- Resv | | <-- Resv |_____| 589 Path --> | | Path --> _____ 590 _____ | ROUTER | | | | 591 | | | | | |--| D | 592 | B |--| data-->| | data --> | |_____| 593 |_____| |--------| b d |-----------| 594 |<-- Resv| | <-- Resv | _____ 595 _____ | Path-->|_____________________| Path --> | | | 596 | | | |--| D' | 597 | B' |--| | |_____| 598 |_____| | | 600 Figure 5: Router Using RSVP 602 Figure 5 illustrates RSVP's model of a router node. Each data 603 stream arrives from a previous hop through a corresponding 604 incoming interface and departs through one or more outgoing 605 interface(s). The same physical interface may act in both the 606 incoming and outgoing roles (for different data flows but the same 607 session). 609 As illustrated in Figure 5, there may be multiple previous hops 610 and/or next hops through a given physical interface. This may 611 result from the connected network being a shared medium or from 612 the existence of non-RSVP routers in the path to the next RSVP hop 613 (see Section 2.6). An RSVP daemon must preserve the next and 614 previous hop addresses in its reservation and path state, 615 respectively. A RESV message is sent with a unicast destination 616 address, the address of a previous hop. PATH messages, on the 617 other hand, are sent with the session destination address, unicast 618 or multicast. 620 Although multiple next hops may send reservation requests through 621 the same physical interface, the final effect should be to install 622 a reservation on that interface, which is defined by an effective 623 flowspec. This effective flowspec will be the "maximum" of the 624 flowspecs requested by the different next hops. In turn, a RESV 625 message forwarded to a particular previous hop carries a flowspec 626 that is the "maximum" over the effective reservations on the 627 corresponding outgoing interfaces. Both cases represent merging, 628 which is discussed further below. 630 There are a number of ways for a new or modified reservation 631 request to fail in a given node: 633 1. The effective flowspec, computed using the new request, may 634 fail admission control. 636 2. Administrative policy or control may prevent the requested 637 reservation. 639 3. There may be no matching path state (i.e., the scope may be 640 empty), which would prevent the reservation being propagated 641 upstream. 643 4. A reservation style that requires a unique sender may have a 644 filter spece that matches more than one sender in the path 645 state, due to the use of wildcards. 647 5. The requested style may be incompatible with the style(s) of 648 existing reservations for the same session on the same 649 outgoing interface, so an effective flowspec cannot be 650 computed. 652 6. The requested style may be incompatible with the style(s) of 653 reservations that exist on other outgoing interfaces but will 654 be merged with this reservation to create a refresh message 655 for the previous hop. 657 In any of these cases, an error message is returned to the 658 receiver(s) responsible for the erroneous message, which may or 659 may not be propagated forward along the path. An error message 660 does not modify state in the nodes through which it passes. 661 Therefore, any reservations established downstream of the node 662 where the failure was detected will persist until the receiver(s) 663 responsible cease attempting the reservation. 665 In general, if the error is likely to be repeated at every node 666 further along the path, it is best to drop the errneous message 667 rather than generate a flood of error messages; this is the case 668 for the last four error classes listed above. The first two error 669 classes, admission control and administrative policy, may or may 670 not allow propagation of the message, depending upon the detailed 671 reason and perhaps on local administrative policy and/or the 672 particular service request. More complete rules are given in the 673 error definitions in Appendix B. 675 An erroneous FILTER_SPEC object in a RESV message will normally be 676 detected at the first RSVP hop from the receiver application, 677 i.e., within the receiver host. However, an admission control 678 failure caused by a FLOWSPEC or a POLICY_DATA object may be 679 detected anywhere along the path(s) to the sender(s). 681 When admission control fails for a reservation request, any 682 existing reservation is left in place. This prevents a new, very 683 large, reservation from disrupting the existing QoS by merging 684 with an existing reservation and then failing admission control 685 (this has been called the "killer reservation" problem). 687 A node may be allowed to preempt an established reservation, in 688 accordance with administrative policy; this will also trigger an 689 error message to all affected receivers. 691 2.2 Merging and Packing 693 A previous section explained that reservation requests in RESV 694 messages are necessarily merged, to match the multicast 695 distribution tree. As a result, only the essential (i.e., the 696 "largest") reservation requests are forwarded, once per refresh 697 period. A successful reservation request will propagate as far as 698 the closest point(s) along the sink tree to the sender(s) where a 699 reservation level equal or greater than that being requested has 700 been made. At that point, the merging process will drop it in 701 favor of another, equal or larger, reservation request. 703 For protocol efficiency, RSVP also allows multiple sets of path 704 (or reservation) information for the same session to be "packed" 705 into a single PATH (or RESV) message, respectively. (For 706 simplicity, the protocol currently prohibits packing different 707 sessions into the same RSVP message). Unlike merging, packing 708 preserves information. 710 In order to merge reservations, RSVP must be able to merge 711 flowspecs and to merge filterspecs. Merging flowspecs requires 712 calculating the the "largest" of a set of flowspecs, which are 713 otherwise opaque to RSVP. Merging flowspecs is required both to 714 calculate the effective flowspec to install on a given physical 715 interface (see the discussion in connection with Figure 5), and to 716 merge flowspecs when sending a refresh message upstream. Since 717 flowspecs are generally multi-dimensional vectors (they contain 718 both Tspec and Rspec components, each of which may itself be 719 multi-dimensional), they are not strictly ordered. When it cannot 720 take the larger of two flowspecs, RSVP must compute and use a 721 third flowspec that is at least as large as each, i.e., a "least 722 upper bound" (LUB). It is also possible for two flowspecs to be 723 incomparable, which is treated as an error. The definition and 724 implementation of the rules for comparing flowspecs are outside 725 RSVP proper, but they are defined as part of the service templates 726 [ServTempl95a] 728 We can now give the complete rules for calculating the effective 729 flowspec (Te, Re), to be installed on an interface. Here Te is 730 the effective Tspec and Re is the effective Rspec. As an example, 731 consider interface (d) in Figure 5. 733 o Re is calculated as the largest (using an LUB if necessary) 734 of the Rspecs in RESV messages from different next hops 735 (e.g., D and D') but the same outgoing interface (d). 737 o The Tspecs supplied in PATH messages from different previous 738 hops which may send data packets to this reservation (e.g., 739 some or all of A, B, and B' in Figure 5) are summed; call 740 this sum Path_Te. 742 o The maximum Tspec supplied in RESV messages from different 743 next hops (e.g., D and D') is calculated; call this Resv_Te. 745 o Te is the GLB (greatest lower bound) of Path_Te and Resv_Te. 746 For Tspecs defined by token bucket parameters, this means to 747 take the smaller of the bucket size and the rate parameters. 749 Two filter specs can be merged only they are identical or if one 750 contains the other through wild-carding. The result is the more 751 general of the two, i.e., the one with more wildcard fields. 753 2.3 Soft State 755 To maintain reservation state, RSVP keeps "soft state" in router 756 and host nodes. RSVP soft state is created and periodically 757 refreshed by PATH and RESV messages. The state is deleted if no 758 refreshes arrive before the expiration of a "cleanup timeout" 759 interval; it may also be deleted as the result of an explicit 760 "teardown" message. 762 When a route changes, the next PATH message will initialize the 763 path state on the new route, and future RESV messages will 764 establish reservation state; the state on the now-unused segment 765 of the route will time out. Thus, whether a message is "new" or a 766 "refresh" is determined separately at each node, depending upon 767 the existence of state at that node. (This document uses the term 768 "refresh message" in this effective sense, to indicate an RSVP 769 message that does not modify the existing state at the node in 770 question.) 772 In addition to the cleanup timeout, there is a "refresh timeout" 773 period. As messages arrive, the RSVP daemon checks them against 774 the existing state; if it matches, the cleanup timeout timer on 775 the state is reset and the message is dropped. At the expiration 776 of each refresh timeout period, RSVP scans its state to build and 777 forward PATH and RESV messages to succeeding hops. 779 RSVP sends its messages as IP datagrams without reliability 780 enhancement. Periodic transmission of refresh messages by hosts 781 and routers is expected to replace any lost RSVP messages. To 782 tolerate K-1 successive packet losses, the effective cleanup 783 timeout must be at least K times the refresh timeout. In 784 addition, the traffic control mechanism in the network should be 785 statically configured to grant high-reliability service to RSVP 786 messages, to protect RSVP messages from congestion losses. 788 In steady state, refreshing is performed hop-by-hop, which allows 789 merging and packing as described in the previous section. If the 790 received state differs from the stored state, the stored state is 791 updated. Furthermore, if the result will be to modify the refresh 792 messages to be generated, these refresh messages must be generated 793 and forwarded immediately. This will result in state changes 794 propagating end-to-end without delay. However, propagation of a 795 change stops when and if it reaches a point where merging causes 796 no resulting state change. This minimizes RSVP control traffic 797 due to changes and is essential for scaling to large multicast 798 groups. 800 The "soft" router state maintained by RSVP is dynamic; to change 801 the set of senders Si or receivers Rj or to change any QoS 802 request, a host simply starts sending revised PATH and/or RESV 803 messages. The result should be an appropriate adjustment in the 804 RSVP state and immediate propagation to all nodes along the path. 806 The RSVP state associated with a session in a particular node is 807 divided into atomic elements that are created, refreshed, and 808 timed out independently. The atomicity is determined by the 809 requirement that any sender or receiver may enter or leave the 810 session at any time, so its state should be created and timed out 811 independently. 813 2.4 Teardown 815 RSVP teardown messages remove path and reservation state without 816 waiting for the cleanup timeout period, as an optimization to 817 release resources quickly. It is not necessary (although it may 818 be desirable, since the resources being consumed may be 819 "valuable"), to explicitly tear down an old reservation. 821 A teardown request may be initiated either by an application in an 822 end system (sender or receiver), or by a router as the result of 823 state timeout. Once initiated, a teardown request should be 824 forwarded hop-by-hop without delay. 826 Teardown messages (like other RSVP messages) are not delivered 827 reliably. However, loss of a teardown message is not considered a 828 problem because the state will time out even if it is not 829 explicitly deleted. If one or more teardown message hops are 830 lost, the router that failed to receive a teardown message will 831 time out its state and initiate a new teardown message beyond the 832 loss point. Assuming that RSVP message loss probability is small, 833 the longest time to delete state will seldom exceed one refresh 834 timeout period. 836 There are two types of RSVP teardown message, PTEAR and RTEAR. A 837 PTEAR message travels towards all receivers downstream from its 838 point of initiation and deletes path state along the way. A RTEAR 839 message deletes reservation state and travels towards all senders 840 upstream from its point of initiation. A PTEAR (RTEAR) message 841 may be conceptualized as a reversed-sense Path message (Resv 842 message, respectively). 844 A teardown message deletes the specified state in the node where 845 it is received. Like any other state change, this will be 846 propagated immediately to the next node, but only if it represents 847 a net change after merging. As a result, an RTEAR message will 848 prune the reservation state back (only) as far as possible. 850 2.5 Admission Policy and Security 852 RSVP-mediated QoS requests will result in particular user(s) 853 getting preferential access to network resources. To prevent 854 abuse, some form of back pressure on users will be required. This 855 back pressure might take the form of administrative rules, or of 856 some form of real or virtual billing for the `cost' of a 857 reservation. The form and contents of such back pressure is a 858 matter of administrative policy that may be determined 859 independently by each administrative domain in the Internet. 861 Therefore, admission control at each node is likely to contain a 862 policy component as well as a resource reservation component. As 863 input to the policy-based admission decision, RSVP messages may 864 carry policy data. This data may include credentials identifying 865 users or user classes, account numbers, limits, quotas, etc. 867 To protect the integrity of the policy-based admission control 868 mechanisms, it may be necessary to ensure the integrity of RSVP 869 messages against corruption or spoofing, hop by hop. For this 870 purpose, RSVP messages may carry integrity objects that can be 871 created and verified by neighboring RSVP-capable nodes. These 872 objects are expected to contain an encrypted part and to assume a 873 shared secret between neighbors. 875 User policy data in reservation request messages presents a 876 scaling problem. When a multicast group has a large number of 877 receivers, it will not be possible or desirable to carry all the 878 receivers' policy data upstream to the sender(s). The policy data 879 will have to be administratively merged, near enough to the 880 receivers to avoid excessive policy data. Administrative merging 881 implies checking the user credentials and accounting data and then 882 substituting a token indicating the check has succeeded. A chain 883 of trust established using an integrity field will allow upstream 884 nodes to accept these tokens. 886 Note that the merge points for policy data are likely to be at the 887 boundaries of administrative domains. It may be necessary to 888 carry accumulated and unmerged policy data upstream through 889 multiple nodes before reaching one of these merge points. 891 2.6 Automatic RSVP Tunneling 893 It is impossible to deploy RSVP (or any new protocol) at the same 894 moment throughout the entire Internet. Furthermore, RSVP may 895 never be deployed everywhere. RSVP must therefore provide correct 896 protocol operation even when two RSVP-capable routers are joined 897 by an arbitrary "cloud" of non-RSVP routers. Of course, an 898 intermediate cloud that does not support RSVP is unable to perform 899 resource reservation, so service guarantees cannot be made. 900 However, if such a cloud has sufficient excess capacity, it may 901 provide acceptable and useful realtime service. 903 RSVP will automatically tunnel through such a non-RSVP cloud. 904 Both RSVP and non-RSVP routers forward PATH messages towards the 905 destination address using their local uni-/multicast routing 906 table. Therefore, the routing of PATH messages will be unaffected 907 by non-RSVP routers in the path. When a PATH message traverses a 908 non-RSVP cloud, the copies that emerge will carry as a Previous 909 Hop address the IP address of the last RSVP-capable router before 910 entering the cloud. This will effectively construct a tunnel 911 through the cloud for RESV messages, which will be forwarded 912 directly to the next RSVP-capable router on the path(s) back 913 towards the source. 915 Automatic tunneling is not perfect; in some circumstances it may 916 distribute path information to RSVP-capable routers not included 917 in the data distribution paths, which may create unused 918 reservations at these routers. This is because PATH messages 919 carry the IP source address of the previous hop, not of the 920 original sender, and multicast routing may depend upon the source 921 as well as the destination address. This can be overcome by 922 manual configuration of the neighboring RSVP programs, when 923 necessary. 925 2.7 Host Model 927 Before a session can be created, the session identification, 928 comprised of DestAddress and perhaps the generalized destination 929 port, must be assigned and communicated to all the senders and 930 receivers by some out-of-band mechanism. When an RSVP session is 931 being set up, the following events happen at the end systems. 933 H1 A receiver joins the multicast group specified by 934 DestAddress, using IGMP. 936 H2 A potential sender starts sending RSVP PATH messages to the 937 DestAddress, using RSVP. 939 H3 A receiver application receives a PATH message. 941 H4 A receiver starts sending appropriate RESV messages, 942 specifying the desired flow descriptors, using RSVP. 944 H5 A sender application receives a RESV message. 946 H6 A sender starts sending data packets. 948 There are several synchronization considerations. 950 o Suppose that a new sender starts sending data (H6) but no 951 receivers have joined the group (H1). Then there will be no 952 multicast routes beyond the host (or beyond the first RSVP- 953 capable router) along the path; the data will be dropped at 954 the first hop until receivers(s) do appear (assuming a 955 multicast routing protocol that "prunes off" or otherwise 956 avoids unnecessary paths). 958 o Suppose that a new sender starts sending PATH messages (H2) 959 and immediately starts sending data (H6), and there are 960 receivers but no RESV messages have reached the sender yet 961 (e.g., because its PATH messages have not yet propagated to 962 the receiver(s)). Then the initial data may arrive at 963 receivers without the desired QoS. The sender could mitigate 964 this problem by awaiting arrival of the first RESV message 965 [H5]; however, receivers that are farther away may not have 966 reservations in place yet. 968 o If a receiver starts sending RESV messages (H4) before any 969 PATH messages have reached it (H3), RSVP will return error 970 messages to the receiver. The receiver may simply choose to 971 ignore such error messages, or it may avoid them by waiting 972 for PATH messages before sending RESV messages. 974 A specific application program interface (API) for RSVP is not 975 defined in this protocol spec, as it may be host system dependent. 976 However, Section 4.6.1 discusses the general requirements and 977 presents a generic API. 979 3. Examples 981 We use the following notation for a RESV message: 983 1. Wildcard-Filter (WF) 985 WF( *{Q}) 987 Here "*{Q}" represents a Flow Descriptor with a "wildcard" scope 988 (choosing all senders) and a flowspec of quantity Q. 990 2. Fixed-Filter (FF) 992 FF( S1{Q1}, S2{Q2}, ...) 994 A list of (sender, flowspec) pairs, i.e., flow descriptors, 995 packed into a single RESV message. 997 3. Shared Explicit (SE) 999 SE( (S1,S2,...)Q1, (S3,S4,...)Q2, ...) 1001 A list of shared reservations, each specified by a single 1002 flowspec and a list of senders. 1004 For simplicity we assume here that flowspecs are one-dimensional, 1005 defining for example the average throughput, and state them as a 1006 multiple of some unspecified base resource quantity B. 1008 Figure 6 shows schematically a router with two previous hops labeled 1009 (a) and (b) and two outgoing interfaces labeled (c) and (d). This 1010 topology will be assumed in the examples that follow. There are 1011 three upstream senders; packets from sender S1 (S2 and S3) arrive 1012 through previous hop (a) ((b), respectively). There are also three 1013 downstream receivers; packets bound for R1 and R2 (R3) are routed via 1014 outgoing interface (c) ((d) respectively). 1016 In addition to the connectivity shown in 6, we must also specify the 1017 multicast routing within this node. Assume first that data packets 1018 (hence, PATH messages) from each Si shown in Figure 6 is routed to 1019 both outgoing interfaces. Under this assumption, Figures 7, 8, and 9 1020 illustrate Wildcard-Filter, Fixed-Filter, and Shared-Explicit 1021 reservations, respectively. 1023 ________________ 1024 (a)| | (c) 1025 ( S1 ) ---------->| |----------> ( R1, R2) 1026 | Router | 1027 (b)| | (d) 1028 ( S2,S3 ) ------->| |----------> ( R3 ) 1029 |________________| 1031 Figure 6: Router Configuration 1033 In Figure 7, the "Receive" column shows the RESV messages received 1034 over outgoing interfaces (c) and (d) and the "Reserve" column shows 1035 the resulting reservation state for each interface. The "Send" 1036 column shows the RESV messages forwarded to previous hops (a) and 1037 (b). In the "Reserve" column, each box represents one reservation 1038 "channel", with the corresponding filter. As a result of merging, 1039 only the largest flowspec is forwarded upstream to each previous hop. 1041 | 1042 Send | Reserve Receive 1043 | 1044 | _______ 1045 WF( *{3B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} ) 1046 | |_______| 1047 | 1048 -----------------------|---------------------------------------- 1049 | _______ 1050 WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) 1051 | |_______| 1053 Figure 7: Wildcard-Filter Reservation Example 1 1055 Figure 8 shows Fixed-Filter (FF) style reservations. The flow 1056 descriptors for senders S2 and S3, received from outgoing interfaces 1057 (c) and (d), are packed into the message forwarded to previous hop b. 1058 On the other hand, the two different flow descriptors for sender S1 1059 are merged into the single message FF( S1{3B} ), which is sent to 1060 previous hop (a). For each outgoing interface, there is a private 1061 reservation for each source that has been requested, but this private 1062 reservation is shared among the receivers that made the request. 1064 Finally, Figure 9 shows a simple example of Shared-Explicit (SE) 1065 style reservations. Here each outgoing interface has a single 1066 reservation that is shared by a list of senders. 1068 | 1069 Send | Reserve Receive 1070 | 1071 | ________ 1072 FF( S1{3B} ) <- (a) | (c) | S1{B} | (c) <- FF( S1{B}, S2{5B} ) 1073 | |________| 1074 | | S2{5B} | 1075 | |________| 1076 ---------------------|--------------------------------------------- 1077 | ________ 1078 <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) 1079 FF( S2{5B}, S3{B} ) | |________| 1080 | | S3{B} | 1081 | |________| 1083 Figure 8: Fixed-Filter Reservation Example 1085 | 1086 Send | Reserve Receive 1087 | 1088 | ________ 1089 SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} ) 1090 | | {B} | 1091 | |________| 1092 ---------------------|--------------------------------------------- 1093 | ________ 1094 <- (b) | (d) |(S1,S3) | (d) <- SE( (S1,S3){3B} ) 1095 SE( (S2,S3){3B} ) | | {3B} | 1096 | |________| 1098 Figure 9: Shared-Explicit Reservation Example 1100 The three examples just shown assume full routing, i.e., data packets 1101 from S1, S2, and S3 are routed to both outgoing interfaces. The top 1102 part of Figure 10 shows another routing assumption: data packets 1103 from S1 are not forwarded to interface (d), because the mesh topology 1104 provides a shorter path for S1 -> R3 that does not traverse this 1105 node. The bottom of Figure 10 shows WF style reservations under this 1106 assumption. Since there is no route from (a) to (d), the reservation 1107 forwarded out interface (a) considers only the reservation on 1108 interface (c); no merging takes place in this case. 1110 _______________ 1111 (a)| | (c) 1112 ( S1 ) ---------->| --------->--> |----------> ( R1, R2) 1113 | / | 1114 | / | 1115 (b)| / | (d) 1116 ( S2,S3 ) ------->| ->----------> |----------> ( R3 ) 1117 |_______________| 1119 Router Configuration 1121 | 1122 Send | Reserve Receive 1123 | 1124 | _______ 1125 WF( *{B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} ) 1126 | |_______| 1127 | 1128 -----------------------|---------------------------------------- 1129 | _______ 1130 WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) 1131 | |_______| 1133 Figure 10: Wildcard-Filter Reservation Example -- Partial Routing 1135 Finally, we note that state that is received through a particular 1136 interface Iout in never forwarded out the same interface. 1137 Conversely, state that is forwarded out interface Iout must be 1138 computed using only state that arrived on interfaces different from 1139 Iout. A trivial example of this rule is illustrated in Figure 11, 1140 which shows a transit router with one sender and one receiver on each 1141 interface (and assumes one next/previous hop per interface). 1142 Interfaces (a) and (c) are both outgoing and incoming interfaces for 1143 this session. Both receivers are making wildcard-scope reservations, 1144 in which the RESV messages are forwarded to all previous hops for 1145 senders in the group, with the exception of the next hop from which 1146 they came. These result in independent reservations in the two 1147 directions. 1149 ________________ 1150 a | | c 1151 ( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) 1152 |________________| 1154 Send | Receive 1155 | 1156 WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) 1157 | 1158 Receive | Send 1159 | 1160 WF( *{4B}) --> (a) | (c) --> WF( *{4B}) 1161 | 1162 Reserve on (a) | Reserve on (c) 1163 __________ | __________ 1164 | * {4B} | | | * {3B} | 1165 |__________| | |__________| 1166 | 1168 Figure 11: Independent Reservations 1170 4. RSVP Functional Specification 1172 4.1 RSVP Message Formats 1174 All RSVP messages consist of a common header followed by a 1175 variable number of variable-length typed "objects". The 1176 subsections that follow define the formats of the common header, 1177 the object structures, and each of the RSVP message types. 1179 For each RSVP message type, there is a set of rules for the 1180 permissible ordering and choice of object types. These rules are 1181 specified using Backus-Naur Form (BNF) augmented with square 1182 brackets surrounding optional sub-sequences. 1184 4.1.1 Common Header 1186 0 1 2 3 1187 +-------------+-------------+-------------+-------------+ 1188 | Vers | Flags| Type | RSVP Checksum | 1189 +-------------+-------------+-------------+-------------+ 1190 | Message Length | (Reserved) | 1191 +-------------+-------------+-------------+-------------+ 1193 The fields in the common header are as follows: 1195 Vers 1197 Protocol version number. This is version 2. 1199 Flags 1201 (None defined yet) 1203 Type 1205 1 = PATH 1207 2 = RESV 1209 3 = PERR 1211 4 = RERR 1213 5 = PTEAR 1215 6 = RTEAR 1217 RSVP Checksum 1219 A standard TCP/UDP checksum over the contents of the RSVP 1220 message, with the checksum field replaced by zero. 1222 Message Length 1224 The total length of this RSVP message in bytes, including 1225 this common header and the variable-length objects that 1226 follow. 1228 4.1.2 Object Formats 1230 An object consists of one or more 32-bit words with a one-word 1231 header, in the following format: 1233 0 1 2 3 1234 +-------------+-------------+-------------+-------------+ 1235 | Length (bytes) | Class-Num | C-Type | 1236 +-------------+-------------+-------------+-------------+ 1237 | | 1238 // (Object contents) // 1239 | | 1240 +-------------+-------------+-------------+-------------+ 1242 An object header has the following fields: 1244 Length 1246 A 16-bit field containing the total object length in 1247 bytes. Must always be a multiple of 4, and at least 4. 1249 Class-Num 1251 Identifies the object class; values of this field are 1252 defined in Appendix A. Each object class has a name, 1253 which will always be capitalized in this document. An 1254 RSVP implementation must recognize the following classes: 1256 NULL 1258 A NULL object has a Class-Num of zero, and its C-Type 1259 is ignored. Its length must be at least 4, but can 1260 be any multiple of 4. A NULL object may appear 1261 anywhere in a sequence of objects, and its contents 1262 will be ignored by the receiver. 1264 SESSION 1266 Contains the IP destination address (DestAddress) and 1267 possibly a generalized destination port, to define a 1268 specific session for the other objects that follow. 1269 Required in every RSVP message. 1271 RSVP_HOP 1273 Carries the IP address of the RSVP-capable node that 1274 sent this message. This document refers to a 1275 RSVP_HOP object as a PHOP ("previous hop") object for 1276 downstream messages or as a NHOP ("next hop") object 1277 for upstream messages. 1279 TIME_VALUES 1281 If present, contains values for the refresh period R 1282 and the state time-to-live T (see section 4.5), to 1283 override the default values of R and T. 1285 STYLE 1287 Defines the reservation style plus style-specific 1288 information that is not a FLOWSPEC or FILTER_SPEC 1289 object, in a RESV message. 1291 FLOWSPEC 1293 Defines a desired QoS, in a RESV message. 1295 FILTER_SPEC 1297 Defines a subset of session data packets that should 1298 receive the desired QoS (specified by an FLOWSPEC 1299 object), in a RESV message. 1301 SENDER_TEMPLATE 1303 Contains a sender IP address and perhaps some 1304 additional demultiplexing information to identify a 1305 sender, in a PATH message. 1307 SENDER_TSPEC 1309 Defines the traffic characteristics of a sender's 1310 data stream, in a PATH message. 1312 ADSPEC 1314 Carries an Adspec containing OPWA data, in a PATH 1315 message. 1317 ERROR_SPEC 1319 Specifies an error, in a PERR or RERR message. 1321 POLICY_DATA 1323 Carries information that will allow a local policy 1324 module to decide whether an associated reservation is 1325 administratively permitted. May appear in a PATH or 1326 RESV message. 1328 INTEGRITY 1330 Contains cryptographic data to authenticate the 1331 originating node, and perhaps to verify the contents, 1332 of this RSVP message. 1334 SCOPE 1336 An explicit specification of the scope for forwarding 1337 a RESV message. 1339 TAG 1341 Encloses a list of one or more objects and attaches a 1342 logical name or "tag" value to them. The tag value 1343 is unique to the next/previous hop and the session 1344 (specified by HOP and SESSION objects, respectively). 1345 The enclosed object list is the "tagged sublist", and 1346 the objects in it said to be "tagged" with the tag 1347 value. Objects in a particular tagged sublist must 1348 all have the same class-num. 1350 Tagged objects with the same tag value are declared 1351 to be logically related, i.e., to be members of some 1352 larger logical set of objects. Note that the tagged 1353 sublist implies no ordering; it defines only a set of 1354 objects. 1356 The meaning of the logical relationship depends upon 1357 the class-num of the tagged objects. 1359 C-Type 1360 Object type, unique within Class-Num. Values are defined 1361 in Appendix A. 1363 The maximum object content length is 65528 bytes. The Class- 1364 Num and C-Type fields (together with the 'Optional' flag bit) 1365 may be used together as a 16-bit number to define a unique type 1366 for each object. 1368 The high-order bit of the Class-Num is used to determine what 1369 action a node should take if it does not recognize the Class- 1370 Num of an object. If Class-Num < 128, then the node should 1371 ignore the object but forward it (unmerged). If Class-Num >= 1372 128, the message should be rejected and an "Unknown Object 1373 Class" error returned. Note that merging cannot be performed 1374 on unknown object types; as a result, unmerged objects may be 1375 forwarded to the first node that does know how to merge them. 1376 The scaling limitations that this imposes must be considered 1377 when defining and deploying new object types. 1379 4.1.3 Path Message 1381 PATH messages carry information from senders to receivers along 1382 the paths used by the data packets. The IP destination address 1383 of a PATH message is the DestAddress for the session; the 1384 source address is an address of the node that sent the message 1385 (preferably the address of the interface through which it was 1386 sent). The PHOP (i.e., the RSVP_HOP) object of each PATH 1387 message should contain the IP source address. 1389 The format of a PATH message is as follows: 1391 ::= 1393 [ ] [ ] 1395 1397 ::= | 1399 1401 ::= [ ] 1403 [ ] [ ] 1405 Each sender descriptor defines a sender, and the sender 1406 descriptor list allows multiple sender descriptors to be packed 1407 into a PATH message. For each sender in the list, the 1408 SENDER_TEMPLATE object defines the format of data packets; in 1409 addition, a SENDER_TSPEC object may specify the traffic flow, a 1410 POLICY_DATA object may specify user credential and accounting 1411 information, and an ADSPEC object may carry advertising (OPWA) 1412 data. 1414 Each sender host must periodically send PATH message(s) 1415 containing a sender descriptor for each its own data stream(s). 1416 Each sender descriptor is forwarded and replicated as necessary 1417 to follow the delivery path(s) for a data packet from the same 1418 sender, finally reaching the applications on all receivers 1419 (except that it is not looped back to a receiver included in 1420 the same application process as the sender). 1422 It is an error to send ambiguous path state, i.e., two or more 1423 Sender Templates that are different but overlap, due to 1424 wildcards. For example, if we represent a Sender Template as 1425 (IP address, sender port, protocol id and use `*' to represent 1426 a wildcard, then each of the following pairs of Sender 1427 Templates would be an error: 1429 (10.1.2.3, 34567, *) and (10.1.2.3, *, *) 1431 (10.1.2.3, 34567, *) and (10.1.2.3, 34567, 17) 1433 A PATH message received at a node is processed to create path 1434 state for all senders defined by SENDER_TEMPLATE objects in the 1435 sender descriptor list. If present, any POLICY_DATA, 1436 SENDER_TSPEC, and ADSPEC objects are also saved in the path 1437 state. If an error is encountered while processing a PATH 1438 message, a PERR message is sent to all senders implied by the 1439 SENDER_TEMPLATEs. 1441 Periodically, the path state is scanned to create new PATH 1442 messages which are forwarded upstream. A node must 1443 independently compute the route for each sender descriptor 1444 being forwarded. These routes, obtained from uni-/multicast 1445 routing, generally depend upon the (sender host address, 1446 DestAddress) pairs and consist of a list of outgoing 1447 interfaces. The descriptors being forwarded through the same 1448 outgoing interface may be packed into as few PATH messages as 1449 possible. Note that multicast routing of path information is 1450 based on the sender address(es) from the sender descriptors, 1451 not the IP source address; this is necessary to prevent routing 1452 loops; see Section 4.3. 1454 Multicast routing may also report the expected incoming 1455 interface (i.e., the shortest path back to the sender). If so, 1456 any PATH message that arrives on a different interface should 1457 be discarded immediately. 1459 It is possible that routing will report no routes for a 1460 (sender, DestAddress) pair; path state for this sender should 1461 be stored locally but not forwarded. 1463 4.1.4 Resv Messages 1465 RESV messages carry reservation requests hop-by-hop from 1466 receivers to senders, along the reverse paths of data flow for 1467 the session. The IP destination address of a RESV message is 1468 the unicast address of a previous-hop node, obtained from the 1469 path state. The IP source address is an address of the node 1470 that sent the message. The NHOP (i.e., the RSVP_HOP) object 1471 must contain the IP address of the (incoming) interface through 1472 which the RESV message is sent. 1474 The RESV message format is as follows: 1476 ::= 1478 [ ] [ ] 1480 [ ] 1482