idnits 2.17.1 draft-ietf-rsvp-spec-15.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-25) 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. == 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 32 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 27, 1997) is 9830 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: 'IPSEC97' is mentioned on line 1234, but not defined == Missing Reference: 'S4' is mentioned on line 2297, but not defined == Missing Reference: 'S1' is mentioned on line 2293, but not defined == Missing Reference: 'S2' is mentioned on line 2297, but not defined == Missing Reference: 'S3' is mentioned on line 2297, but not defined == Missing Reference: 'Note 1' is mentioned on line 4052, but not defined == Missing Reference: 'Note 2' is mentioned on line 4057, but not defined == Missing Reference: 'Note 3' is mentioned on line 4073, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'Baker96' ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. 'ISInt93') -- Possible downref: Non-RFC (?) normative reference: ref. 'FJ94' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSEC96' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISrsvp96' -- Possible downref: Non-RFC (?) normative reference: ref. 'PolArch96' -- Possible downref: Non-RFC (?) normative reference: ref. 'OPWA95' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP93' Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Braden, Ed. 3 Expiration: November 1997 ISI 4 File: draft-ietf-rsvp-spec-15.txt L. Zhang 5 PARC 6 S. Berson 7 ISI 8 S. Herzog 9 IBM Research 10 S. Jamin 11 Univ. of Michigan 13 Resource ReSerVation Protocol (RSVP) -- 15 Version 1 Functional Specification 17 May 27, 1997 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 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 33 Directories on ds.internic.net (US East Coast), nic.nordu.net 34 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 35 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 Table of Contents 46 1. Introduction ........................................................4 47 1.1 Data Flows ......................................................7 48 1.2 Reservation Model ...............................................8 49 1.3 Reservation Styles ..............................................11 50 1.4 Examples of Styles ..............................................14 51 2. RSVP Protocol Mechanisms ............................................19 52 2.1 RSVP Messages ...................................................19 53 2.2 Merging Flowspecs ...............................................21 54 2.3 Soft State ......................................................22 55 2.4 Teardown ........................................................24 56 2.5 Errors ..........................................................25 57 2.6 Confirmation ....................................................27 58 2.7 Policy Control ..................................................27 59 2.8 Security ........................................................28 60 2.9 Non-RSVP Clouds .................................................29 61 2.10 Host Model .....................................................30 62 3. RSVP Functional Specification .......................................32 63 3.1 RSVP Message Formats ............................................32 64 3.2 Port Usage ......................................................46 65 3.3 Sending RSVP Messages ...........................................47 66 3.4 Avoiding RSVP Message Loops .....................................49 67 3.5 Blockade State ..................................................53 68 3.6 Local Repair ....................................................55 69 3.7 Time Parameters .................................................56 70 3.8 Traffic Policing and Non-Integrated Service Hops ................57 71 3.9 Multihomed Hosts ................................................58 72 3.10 Future Compatibility ...........................................60 73 3.11 RSVP Interfaces ................................................62 74 APPENDIX A. Object Definitions .........................................75 75 APPENDIX B. Error Codes and Values .....................................90 76 APPENDIX C. UDP Encapsulation ..........................................95 77 APPENDIX D. Glossary ...................................................99 78 What's Changed 80 This revision contains the following very minor changes from the ID14 81 version. 83 o For clarity, each message type is now defined separately in 84 Section 3.1. 86 o We added more precise and complete rules for accepting Path 87 messages for unicast and multicast destinations (Section 88 3.1.3). 90 o We added more precise and complete rules for processing and 91 forwarding PathTear messages (Section 3.1.5). 93 o A note was added that a SCOPE object will be ignored if it 94 appears in a ResvTear message (Section 3.1.6). 96 o A note was added that a SENDER_TSPEC or ADSPEC object will be 97 ignored if it appears in a PathTear message (Section 3.1.5). 99 o The obsolete error code Ambiguous Filter Spec (09) was 100 removed, and a new (and more consistent) name was given to 101 error code 08 (Appendix B). 103 o In the generic interface to traffic control, the Adspec was 104 added as a parameter to the AddFlow and ModFlow calls 105 (3.11.2). This is needed to accommodate a node that updates 106 the slack term (S) of Guaranteed service. 108 o An error subtype was added for an Adspec error (Appendix B). 110 o Additional explanation was added for handling a CONFIRM 111 object (Section 3.1.4). 113 o The rules for forwarding objects with unknown class type were 114 clarified. 116 o Additional discussion was added to the Introduction and to 117 Section 3.11.2 about the relationship of RSVP to the link 118 layer. (Section 3.10). 120 o Section 2.7 on Policy and Security was split into two 121 sections, and some additional discussion of security was 122 included. 124 o There were some minor editorial improvements. 126 1. Introduction 128 This document defines RSVP, a resource reservation setup protocol 129 designed for an integrated services Internet [RSVP93,ISInt93]. The 130 RSVP protocol is used by a host to request specific qualities of 131 service from the network for particular application data streams or 132 flows. RSVP is also used by routers to deliver quality-of-service 133 (QoS) requests to all nodes along the path(s) of the flows and to 134 establish and maintain state to provide the requested service. RSVP 135 requests will generally result in resources being reserved in each 136 node along the data path. 138 RSVP requests resources for simplex flows, i.e., it requests 139 resources in only one direction. Therefore, RSVP treats a sender as 140 logically distinct from a receiver, although the same application 141 process may act as both a sender and a receiver at the same time. 142 RSVP operates on top of IPv4 or IPv6, occupying the place of a 143 transport protocol in the protocol stack. However, RSVP does not 144 transport application data but is rather an Internet control 145 protocol, like ICMP, IGMP, or routing protocols. Like the 146 implementations of routing and management protocols, an 147 implementation of RSVP will typically execute in the background, not 148 in the data forwarding path, as shown in Figure 1. 150 RSVP is not itself a routing protocol; RSVP is designed to operate 151 with current and future unicast and multicast routing protocols. An 152 RSVP process consults the local routing database(s) to obtain routes. 153 In the multicast case, for example, a host sends IGMP messages to 154 join a multicast group and then sends RSVP messages to reserve 155 resources along the delivery path(s) of that group. Routing 156 protocols determine where packets get forwarded; RSVP is only 157 concerned with the QoS of those packets that are forwarded in 158 accordance with routing. 160 In order to efficiently accommodate large groups, dynamic group 161 membership, and heterogeneous receiver requirements, RSVP makes 162 receivers responsible for requesting a specific QoS [RSVP93]. A QoS 163 request from a receiver host application is passed to the local RSVP 164 process. The RSVP protocol then carries the request to all the nodes 165 (routers and hosts) along the reverse data path(s) to the data 166 source(s), but only as far as the router where the receiver's data 167 path joins the multicast distribution tree. As a result, RSVP's 168 reservation overhead is in general logarithmic rather than linear in 169 the number of receivers. 171 HOST ROUTER 173 _____________________________ ____________________________ 174 | _______ | | | 175 | | | _______ | | _______ | 176 | |Appli- | | | |RSVP | | | | 177 | | cation| | RSVP <---------------------------> RSVP <----------> 178 | | <--> | | | _______ | | | 179 | | | |process| _____ | ||Routing| |process| _____ | 180 | |_._____| | -->Polcy|| || <--> -->Polcy|| 181 | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl|| 182 | |data | | |_____|| ||__.____| | | |_____|| 183 |===|===========|==|==========| |===|==========|==|==========| 184 | | --------| | _____ | | | --------| | _____ | 185 | | | | ---->Admis|| | | | | ---->Admis|| 186 | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| 187 | | | | | |_____|| | | | | ||_____|| 188 | |Class-| | Packet | | | |Class-| | Packet | | 189 | | ifier|==>Schedulr|================> ifier|==>Schedulr|===========> 190 | |______| |________| |data | |______| |________| |data 191 | | | | 192 |_____________________________| |____________________________| 194 Figure 1: RSVP in Hosts and Routers 196 Quality of service is implemented for a particular data flow by 197 mechanisms collectively called "traffic control". These mechanisms 198 include (1) a packet classifier, (2) admission control, and (3) a 199 "packet scheduler" or some other link-layer-dependent mechanism to 200 determine when particular packets are forwarded. The "packet 201 classifier" determines the QoS class (and perhaps the route) for each 202 packet. For each outgoing interface, the "packet scheduler" or other 203 link-layer-dependent mechanism achieves the promised QoS. Traffic 204 control implements QoS service models defined by the Integrated 205 Services Working Group. 207 During reservation setup, an RSVP QoS request is passed to two local 208 decision modules, "admission control" and "policy control". 209 Admission control determines whether the node has sufficient 210 available resources to supply the requested QoS. Policy control 211 determines whether the user has administrative permission to make the 212 reservation. If both checks succeed, parameters are set in the 213 packet classifier and in the link layer interface (e.g., in the 214 packet scheduler) to obtain the desired QoS. If either check fails, 215 the RSVP program returns an error notification to the application 216 process that originated the request. 218 RSVP protocol mechanisms provide a general facility for creating and 219 maintaining distributed reservation state across a mesh of multicast 220 or unicast delivery paths. RSVP itself transfers and manipulates QoS 221 and policy control parameters as opaque data, passing them to the 222 appropriate traffic control and policy control modules for 223 interpretation. The structure and contents of the QoS parameters are 224 documented in specifications developed by the Integrated Services 225 Working Group; see [ISrsvp96]. The structure and contents of the 226 policy parameters are under development. 228 Since the membership of a large multicast group and the resulting 229 multicast tree topology are likely to change with time, the RSVP 230 design assumes that state for RSVP and traffic control state is to be 231 built and destroyed incrementally in routers and hosts. For this 232 purpose, RSVP establishes "soft" state; that is, RSVP sends periodic 233 refresh messages to maintain the state along the reserved path(s). 234 In the absence of refresh messages, the state automatically times out 235 and is deleted. 237 In summary, RSVP has the following attributes: 239 o RSVP makes resource reservations for both unicast and many-to- 240 many multicast applications, adapting dynamically to changing 241 group membership as well as to changing routes. 243 o RSVP is simplex, i.e., it makes reservations for unidirectional 244 data flows. 246 o RSVP is receiver-oriented, i.e., the receiver of a data flow 247 initiates and maintains the resource reservation used for that 248 flow. 250 o RSVP maintains "soft" state in routers and hosts, providing 251 graceful support for dynamic membership changes and automatic 252 adaptation to routing changes. 254 o RSVP is not a routing protocol but depends upon present and 255 future routing protocols. 257 o RSVP transports and maintains traffic control and policy control 258 parameters that are opaque to RSVP. 260 o RSVP provides several reservation models or "styles" (defined 261 below) to fit a variety of applications. 263 o RSVP provides transparent operation through routers that do not 264 support it. 266 o RSVP supports both IPv4 and IPv6. 268 Further discussion on the objectives and general justification for 269 RSVP design are presented in [RSVP93] and [ISInt93]. 271 The remainder of this section describes the RSVP reservation 272 services. Section 2 presents an overview of the RSVP protocol 273 mechanisms. Section 3 contains the functional specification of RSVP, 274 while Section 4 presents explicit message processing rules. Appendix 275 A defines the variable-length typed data objects used in the RSVP 276 protocol. Appendix B defines error codes and values. Appendix C 277 defines a UDP encapsulation of RSVP messages, for hosts whose 278 operating systems provide inadequate raw network I/O support. 280 1.1 Data Flows 282 RSVP defines a "session" to be a data flow with a particular 283 destination and transport-layer protocol. RSVP treats each 284 session independently, and this document often omits the implied 285 qualification "for the same session". 287 An RSVP session is defined by the triple: (DestAddress, ProtocolId 288 [, DstPort]). Here DestAddress, the IP destination address of the 289 data packets, may be a unicast or multicast address. ProtocolId 290 is the IP protocol ID. The optional DstPort parameter is a 291 "generalized destination port", i.e., some further demultiplexing 292 point in the transport or application protocol layer. DstPort 293 could be defined by a UDP/TCP destination port field, by an 294 equivalent field in another transport protocol, or by some 295 application-specific information. 297 Although the RSVP protocol is designed to be easily extensible for 298 greater generality, the basic protocol documented here supports 299 only UDP/TCP ports as generalized ports. Note that it is not 300 strictly necessary to include DstPort in the session definition 301 when DestAddress is multicast, since different sessions can always 302 have different multicast addresses. However, DstPort is necessary 303 to allow more than one unicast session addressed to the same 304 receiver host. 306 Figure 2 illustrates the flow of data packets in a single RSVP 307 session, assuming multicast data distribution. The arrows 308 indicate data flowing from senders S1 and S2 to receivers R1, R2, 309 and R3, and the cloud represents the distribution mesh created by 310 multicast routing. Multicast distribution forwards a copy of each 311 data packet from a sender Si to every receiver Rj; a unicast 312 distribution session has a single receiver R. Each sender Si may 313 be running in a unique Internet host, or a single host may contain 314 multiple senders distinguished by "generalized source ports". 316 Senders Receivers 317 _____________________ 318 ( ) ===> R1 319 S1 ===> ( Multicast ) 320 ( ) ===> R2 321 ( distribution ) 322 S2 ===> ( ) 323 ( by Internet ) ===> R3 324 (_____________________) 326 Figure 2: Multicast Distribution Session 328 For unicast transmission, there will be a single destination host 329 but there may be multiple senders; RSVP can set up reservations 330 for multipoint-to-single-point transmission. 332 1.2 Reservation Model 334 An elementary RSVP reservation request consists of a "flowspec" 335 together with a "filter spec"; this pair is called a "flow 336 descriptor". The flowspec specifies a desired QoS. The filter 337 spec, together with a session specification, defines the set of 338 data packets -- the "flow" -- to receive the QoS defined by the 339 flowspec. The flowspec is used to set parameters in the node's 340 packet scheduler or other link layer mechanism, while the filter 341 spec is used to set parameters in the packet classifier. Data 342 packets that are addressed to a particular session but do not 343 match any of the filter specs for that session are handled as 344 best-effort traffic. 346 The flowspec in a reservation request will generally include a 347 service class and two sets of numeric parameters: (1) an "Rspec" 348 (R for `reserve') that defines the desired QoS, and (2) a "Tspec" 349 (T for `traffic') that describes the data flow. The formats and 350 contents of Tspecs and Rspecs are determined by the integrated 351 service models [ISrsvp96] and are generally opaque to RSVP. 353 The exact format of a filter spec depends upon whether IPv4 or 354 IPv6 is in use; see Appendix A. In the most general approach 355 [RSVP93], filter specs may select arbitrary subsets of the packets 356 in a given session. Such subsets might be defined in terms of 357 senders (i.e., sender IP address and generalized source port), in 358 terms of a higher-level protocol, or generally in terms of any 359 fields in any protocol headers in the packet. For example, filter 360 specs might be used to select different subflows of a 361 hierarchically-encoded video stream by selecting on fields in an 362 application-layer header. In the interest of simplicity (and to 363 minimize layer violation), the basic filter spec format defined in 364 the present RSVP specification has a very restricted form: sender 365 IP address and optionally the UDP/TCP port number SrcPort. 367 Because the UDP/TCP port numbers are used for packet 368 classification, each router must be able to examine these fields. 369 This raises three potential problems. 371 1. It is necessary to avoid IP fragmentation of a data flow for 372 which a resource reservation is desired. 374 Document [ISrsvp96] specifies a procedure for applications 375 using RSVP facilities to compute the minimum MTU over a 376 multicast tree and return the result to the senders. 378 2. IPv6 inserts a variable number of variable-length Internet- 379 layer headers before the transport header, increasing the 380 difficulty and cost of packet classification for QoS. 382 Efficient classification of IPv6 data packets could be 383 obtained using the Flow Label field of the IPv6 header. The 384 details will be provided in the future. 386 3. IP-level Security, under either IPv4 or IPv6, may encrypt the 387 entire transport header, hiding the port numbers of data 388 packets from intermediate routers. 390 A small extension to RSVP for IP Security under IPv4 and IPv6 391 is described separately in [IPSEC96]. 393 RSVP messages carrying reservation requests originate at receivers 394 and are passed upstream towards the sender(s). Note: in this 395 document, we define the directional terms "upstream" vs. 396 "downstream", "previous hop" vs. "next hop", and "incoming 397 interface" vs "outgoing interface" with respect to the direction 398 of data flow. 400 At each intermediate node, a reservation request triggers two 401 general actions, as follows: 403 1. Make a reservation on a link 405 The RSVP process passes the request to admission control and 406 policy control. If either test fails, the reservation is 407 rejected and the RSVP process returns an error message to the 408 appropriate receiver(s). If both succeed, the node sets the 409 packet classifier to select the data packets defined by the 410 filter spec, and it interacts with the appropriate link layer 411 to obtain the desired QoS defined by the flowspec. 413 The detailed rules for satisfying an RSVP QoS request depend 414 upon the particular link layer technology in use on each 415 interface. Specifications are under development in the ISSLL 416 Working Group for mapping reservation requests into popular 417 link layer technologies. For a simple leased line, the 418 desired QoS will be obtained from the packet scheduler in the 419 link layer driver, for example. If the link-layer technology 420 implements its own QoS management capability, then RSVP must 421 negotiate with the link layer to obtain the requested QoS. 422 Note that the action to control QoS occurs at the place where 423 the data enters the link-layer medium, i.e., at the upstream 424 end of the logical or physical link, although an RSVP 425 reservation request originates from receiver(s) downstream. 427 2. Forward the request upstream 429 A reservation request is propagated upstream towards the 430 appropriate senders. The set of sender hosts to which a 431 given reservation request is propagated is called the "scope" 432 of that request. 434 The reservation request that a node forwards upstream may 435 differ from the request that it received from downstream, for 436 two reasons. The traffic control mechanism may modify the 437 flowspec hop-by-hop. More importantly, reservations from 438 different downstream branches of the multicast tree(s) from 439 the same sender (or set of senders) must be " merged" as 440 reservations travel upstream. 442 When a receiver originates a reservation request, it can also 443 request a confirmation message to indicate that its request was 444 (probably) installed in the network. A successful reservation 445 request propagates upstream along the multicast tree until it 446 reaches a point where an existing reservation is equal or greater 447 than that being requested. At that point, the arriving request is 448 merged with the reservation in place and need not be forwarded 449 further; the node may then send a reservation confirmation message 450 back to the receiver. Note that the receipt of a confirmation is 451 only a high-probability indication, not a guarantee, that the 452 requested service is in place all the way to the sender(s), as 453 explained in Section 2.6. 455 The basic RSVP reservation model is "one pass": a receiver sends a 456 reservation request upstream, and each node in the path either 457 accepts or rejects the request. This scheme provides no easy way 458 for a receiver to find out the resulting end-to-end service. 459 Therefore, RSVP supports an enhancement to one-pass service known 460 as "One Pass With Advertising" (OPWA) [OPWA95]. With OPWA, RSVP 461 control packets are sent downstream, following the data paths, to 462 gather information that may be used to predict the end-to-end QoS. 463 The results ("advertisements") are delivered by RSVP to the 464 receiver hosts and perhaps to the receiver applications. The 465 advertisements may then be used by the receiver to construct, or 466 to dynamically adjust, an appropriate reservation request. 468 1.3 Reservation Styles 470 A reservation request includes a set of options that are 471 collectively called the reservation "style". 473 One reservation option concerns the treatment of reservations for 474 different senders within the same session: establish a "distinct" 475 reservation for each upstream sender, or else make a single 476 reservation that is "shared" among all packets of selected 477 senders. 479 Another reservation option controls the selection of senders; it 480 may be an "explicit" list of all selected senders, or a "wildcard" 481 that implicitly selects all the senders to the session. In an 482 explicit sender-selection reservation, each filter spec must match 483 exactly one sender, while in a wildcard sender-selection no filter 484 spec is needed. 486 Sender || Reservations: 487 Selection || Distinct | Shared 488 _________||__________________|____________________ 489 || | | 490 Explicit || Fixed-Filter | Shared-Explicit | 491 || (FF) style | (SE) Style | 492 __________||__________________|____________________| 493 || | | 494 Wildcard || (None defined) | Wildcard-Filter | 495 || | (WF) Style | 496 __________||__________________|____________________| 498 Figure 3: Reservation Attributes and Styles 500 The following styles are currently defined (see Figure 3): 502 o Wildcard-Filter (WF) Style 504 The WF style implies the options: "shared" reservation and 505 "wildcard" sender selection. Thus, a WF-style reservation 506 creates a single reservation shared by flows from all 507 upstream senders. This reservation may be thought of as a 508 shared "pipe", whose "size" is the largest of the resource 509 requests from all receivers, independent of the number of 510 senders using it. A WF-style reservation is propagated 511 upstream towards all sender hosts, and it automatically 512 extends to new senders as they appear. 514 Symbolically, we can represent a WF-style reservation request 515 by: 517 WF( * {Q}) 519 where the asterisk represents wildcard sender selection and Q 520 represents the flowspec. 522 o Fixed-Filter (FF) Style 524 The FF style implies the options: "distinct" reservations and 525 "explicit" sender selection. Thus, an elementary FF-style 526 reservation request creates a distinct reservation for data 527 packets from a particular sender, not sharing them with other 528 senders' packets for the same session. 530 Symbolically, we can represent an elementary FF reservation 531 request by: 533 FF( S{Q}) 535 where S is the selected sender and Q is the corresponding 536 flowspec; the pair forms a flow descriptor. RSVP allows 537 multiple elementary FF-style reservations to be requested at 538 the same time, using a list of flow descriptors: 540 FF( S1{Q1}, S2{Q2}, ...) 542 The total reservation on a link for a given session is the 543 `sum' of Q1, Q2, ... for all requested senders. 545 o Shared Explicit (SE) Style 547 The SE style implies the options: "shared" reservation and 548 "explicit" sender selection. Thus, an SE-style reservation 549 creates a single reservation shared by selected upstream 550 senders. Unlike the WF style, the SE style allows a receiver 551 to explicitly specify the set of senders to be included. 553 We can represent an SE reservation request containing a 554 flowspec Q and a list of senders S1, S2, ... by: 556 SE( (S1,S2,...){Q} ) 558 Shared reservations, created by WF and SE styles, are appropriate 559 for those multicast applications in which multiple data sources 560 are unlikely to transmit simultaneously. Packetized audio is an 561 example of an application suitable for shared reservations; since 562 a limited number of people talk at once, each receiver might issue 563 a WF or SE reservation request for twice the bandwidth required 564 for one sender (to allow some over-speaking). On the other hand, 565 the FF style, which creates distinct reservations for the flows 566 from different senders, is appropriate for video signals. 568 The RSVP rules disallow merging of shared reservations with 569 distinct reservations, since these modes are fundamentally 570 incompatible. They also disallow merging explicit sender 571 selection with wildcard sender selection, since this might produce 572 an unexpected service for a receiver that specified explicit 573 selection. As a result of these prohibitions, WF, SE, and FF 574 styles are all mutually incompatible. 576 It would seem possible to simulate the effect of a WF reservation 577 using the SE style. When an application asked for WF, the RSVP 578 process on the receiver host could use local state to create an 579 equivalent SE reservation that explicitly listed all senders. 580 However, an SE reservation forces the packet classifier in each 581 node to explicitly select each sender in the list, while a WF 582 allows the packet classifier to simply "wild card" the sender 583 address and port. When there is a large list of senders, a WF 584 style reservation can therefore result in considerably less 585 overhead than an equivalent SE style reservation. For this 586 reason, both SE and WF are included in the protocol. 588 Other reservation options and styles may be defined in the future. 590 1.4 Examples of Styles 592 This section presents examples of each of the reservation styles 593 and shows the effects of merging. 595 Figure 4 illustrates a router with two incoming interfaces, 596 labeled (a) and (b), through which flows will arrive, and two 597 outgoing interfaces, labeled (c) and (d), through which data will 598 be forwarded. This topology will be assumed in the examples that 599 follow. There are three upstream senders; packets from sender S1 600 (S2 and S3) arrive through previous hop (a) ((b), respectively). 601 There are also three downstream receivers; packets bound for R1 602 (R2 and R3) are routed via outgoing interface (c) ((d), 603 respectively). We furthermore assume that outgoing interface (d) 604 is connected to a broadcast LAN, i.e., that replication occurs in 605 the network; R2 and R3 are reached via different next hop routers 606 (not shown). 608 We must also specify the multicast routes within the node of 609 Figure 4. Assume first that data packets from each Si shown in 610 Figure 4 are routed to both outgoing interfaces. Under this 611 assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter, 612 Fixed-Filter, and Shared-Explicit reservations, respectively. 614 ________________ 615 (a)| | (c) 616 ( S1 ) ---------->| |----------> ( R1 ) 617 | Router | | 618 (b)| | (d) |---> ( R2 ) 619 ( S2,S3 ) ------->| |------| 620 |________________| |---> ( R3 ) 621 | 623 Figure 4: Router Configuration 625 For simplicity, these examples show flowspecs as one-dimensional 626 multiples of some base resource quantity B. The "Receives" column 627 shows the RSVP reservation requests received over outgoing 628 interfaces (c) and (d), and the "Reserves" column shows the 629 resulting reservation state for each interface. The "Sends" 630 column shows the reservation requests that are sent upstream to 631 previous hops (a) and (b). In the "Reserves" column, each box 632 represents one reserved "pipe" on the outgoing link, with the 633 corresponding flow descriptor. 635 Figure 5, showing the WF style, illustrates two distinct 636 situations in which merging is required. (1) Each of the two next 637 hops on interface (d) results in a separate RSVP reservation 638 request, as shown; these two requests must be merged into the 639 effective flowspec, 3B, that is used to make the reservation on 640 interface (d). (2) The reservations on the interfaces (c) and (d) 641 must be merged in order to forward the reservation requests 642 upstream; as a result, the larger flowspec 4B is forwarded 643 upstream to each previous hop. 645 | 646 Sends | Reserves Receives 647 | 648 | _______ 649 WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) 650 | |_______| 651 | 652 -----------------------|---------------------------------------- 653 | _______ 654 WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) 655 | |_______| <- WF( *{2B} ) 657 Figure 5: Wildcard-Filter (WF) Reservation Example 659 Figure 6 shows Fixed-Filter (FF) style reservations. For each 660 outgoing interface, there is a separate reservation for each 661 source that has been requested, but this reservation will be 662 shared among all the receivers that made the request. The flow 663 descriptors for senders S2 and S3, received through outgoing 664 interfaces (c) and (d), are packed (not merged) into the request 665 forwarded to previous hop (b). On the other hand, the three 666 different flow descriptors specifying sender S1 are merged into 667 the single request FF( S1{4B} ) that is sent to previous hop (a). 669 | 670 Sends | Reserves Receives 671 | 672 | ________ 673 FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} ) 674 | |________| 675 | | S2{5B} | 676 | |________| 677 ---------------------|--------------------------------------------- 678 | ________ 679 <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) 680 FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} ) 681 | | S3{B} | 682 | |________| 684 Figure 6: Fixed-Filter (FF) Reservation Example 686 Figure 7 shows an example of Shared-Explicit (SE) style 687 reservations. When SE-style reservations are merged, the 688 resulting filter spec is the union of the original filter specs, 689 and the resulting flowspec is the largest flowspec. 691 | 692 Sends | Reserves Receives 693 | 694 | ________ 695 SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} ) 696 | | {B} | 697 | |________| 698 ---------------------|--------------------------------------------- 699 | __________ 700 <- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} ) 701 SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} ) 702 | |__________| 704 Figure 7: Shared-Explicit (SE) Reservation Example 706 The three examples just shown assume that data packets from S1, 707 S2, and S3 are routed to both outgoing interfaces. The top part 708 of Figure 8 shows another routing assumption: data packets from S2 709 and S3 are not forwarded to interface (c), e.g., because the 710 network topology provides a shorter path for these senders towards 711 R1, not traversing this node. The bottom part of Figure 8 shows 712 WF style reservations under this assumption. Since there is no 713 route from (b) to (c), the reservation forwarded out interface (b) 714 considers only the reservation on interface (d). 716 _______________ 717 (a)| | (c) 718 ( S1 ) ---------->| >-----------> |----------> ( R1 ) 719 | > | 720 | > | 721 (b)| > | (d) 722 ( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 ) 723 |_______________| 725 Router Configuration 727 | 728 Sends | Reserves Receives 729 | 730 | _______ 731 WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) 732 | |_______| 733 | 734 -----------------------|---------------------------------------- 735 | _______ 736 WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) 737 | |_______| <- WF( * {2B} ) 739 Figure 8: WF Reservation Example -- Partial Routing 741 2. RSVP Protocol Mechanisms 743 2.1 RSVP Messages 745 Previous Incoming Outgoing Next 746 Hops Interfaces Interfaces Hops 748 _____ _____________________ _____ 749 | | data --> | | data --> | | 750 | A |-----------| a c |--------------| C | 751 |_____| Path --> | | Path --> |_____| 752 <-- Resv | | <-- Resv _____ 753 _____ | ROUTER | | | | 754 | | | | | |--| D | 755 | B |--| data-->| | data --> | |_____| 756 |_____| |--------| b d |-----------| 757 | Path-->| | Path --> | _____ 758 _____ | <--Resv|_____________________| <-- Resv | | | 759 | | | |--| D' | 760 | B' |--| | |_____| 761 |_____| | | 763 Figure 9: Router Using RSVP 765 Figure 9 illustrates RSVP's model of a router node. Each data 766 flow arrives from a "previous hop" through a corresponding 767 "incoming interface" and departs through one or more "outgoing 768 interface"(s). The same interface may act in both the incoming 769 and outgoing roles for different data flows in the same session. 770 Multiple previous hops and/or next hops may be reached through a 771 given physical interface; for example, the figure implies that D 772 and D' are connected to (d) with a broadcast LAN. 774 There are two fundamental RSVP message types: Resv and Path. 776 Each receiver host sends RSVP reservation request (Resv) messages 777 upstream towards the senders. These messages must follow exactly 778 the reverse of the path(s) the data packets will use, upstream to 779 all the sender hosts included in the sender selection. They 780 create and maintain "reservation state" in each node along the 781 path(s). Resv messages must finally be delivered to the sender 782 hosts themselves, so that the hosts can set up appropriate traffic 783 control parameters for the first hop. The processing of Resv 784 messages was discussed previously in Section 1.2. 786 Each RSVP sender host transmits RSVP "Path" messages downstream 787 along the uni-/multicast routes provided by the routing 788 protocol(s), following the paths of the data. These Path messages 789 store "path state" in each node along the way. This path state 790 includes at least the unicast IP address of the previous hop node, 791 which is used to route the Resv messages hop-by-hop in the reverse 792 direction. (In the future, some routing protocols may supply 793 reverse path forwarding information directly, replacing the 794 reverse-routing function of path state). 796 A Path message contains the following information in addition to 797 the previous hop address: 799 o Sender Template 801 A Path message is required to carry a Sender Template, which 802 describes the format of data packets that the sender will 803 originate. This template is in the form of a filter spec 804 that could be used to select this sender's packets from 805 others in the same session on the same link. 807 Sender Templates have exactly the same expressive power and 808 format as filter specs that appear in Resv messages. 809 Therefore a Sender Template may specify only the sender IP 810 address and optionally the UDP/TCP sender port, and it 811 assumes the protocol Id specified for the session. 813 o Sender Tspec 815 A Path message is required to carry a Sender Tspec, which 816 defines the traffic characteristics of the data flow that the 817 sender will generate. This Tspec is used by traffic control 818 to prevent over-reservation, and perhaps unnecessary 819 Admission Control failures. 821 o Adspec 823 A Path message may carry a package of OPWA advertising 824 information, known as an "Adspec". An Adspec received in a 825 Path message is passed to the local traffic control, which 826 returns an updated Adspec; the updated version is then 827 forwarded in Path messages sent downstream. 829 Path messages are sent with the same source and destination 830 addresses as the data, so that they will be routed correctly 831 through non-RSVP clouds (see Section 2.9). On the other hand, 832 Resv messages are sent hop-by-hop; each RSVP-speaking node 833 forwards a Resv message to the unicast address of a previous RSVP 834 hop. 836 2.2 Merging Flowspecs 838 A Resv message forwarded to a previous hop carries a flowspec that 839 is the "largest" of the flowspecs requested by the next hops to 840 which the data flow will be sent (however, see Section 3.5 for a 841 different merging rule used in certain cases). We say the 842 flowspecs have been "merged". The examples shown in Section 1.4 843 illustrated another case of merging, when there are multiple 844 reservation requests from different next hops for the same session 845 and with the same filter spec, but RSVP should install only one 846 reservation on that interface. Here again, the installed 847 reservation should have an effective flowspec that is the 848 "largest" of the flowspecs requested by the different next hops. 850 Since flowspecs are opaque to RSVP, the actual rules for comparing 851 flowspecs must be defined and implemented outside RSVP proper. 852 The comparison rules are defined in the appropriate integrated 853 service specification document. An RSVP implementation will need 854 to call service-specific routines to perform flowspec merging. 856 Note that flowspecs are generally multi-dimensional vectors; they 857 may contain both Tspec and Rspec components, each of which may 858 itself be multi-dimensional. Therefore, it may not be possible to 859 strictly order two flowspecs. For example, if one request calls 860 for a higher bandwidth and another calls for a tighter delay 861 bound, one is not "larger" than the other. In such a case, 862 instead of taking the larger, the service-specific merging 863 routines must be able to return a third flowspec that is at least 864 as large as each; mathematically, this is the "least upper bound" 865 (LUB). In some cases, a flowspec at least as small is needed; 866 this is the "greatest lower bound" (GLB) GLB (Greatest Lower 867 Bound). 869 The following steps are used to calculate the effective flowspec 870 (Re, Te) to be installed on an interface [ISrsvp96]. Here Te is 871 the effective Tspec and Re is the effective Rspec. 873 1. An effective flowspec is determined for the outgoing 874 interface. Depending upon the link-layer technology, this 875 may require merging flowspecs from different next hops; this 876 means computing the effective flowspec as the LUB of the 877 flowspecs. Note that what flowspecs to merge is determined 878 by the link layer medium (see Section 3.11.2), while how to 879 merge them is determined by the service model in use 880 [ISrsvp96]. 882 The result is a flowspec that is opaque to RSVP but actually 883 consists of the pair (Re, Resv_Te), where is Re is the 884 effective Rspec and Resv_Te is the effective Tspec. 886 2. A service-specific calculation of Path_Te, the sum of all 887 Tspecs that were supplied in Path messages from different 888 previous hops (e.g., some or all of A, B, and B' in Figure 889 9), is performed. 891 3. (Re, Resv_Te) and Path_Te are passed to traffic control. 892 Traffic control will compute the effective flowspec as the 893 "minimum" of Path_Te and Resv_Te, in a service-dependent 894 manner. 896 Section 3.11.6 defines a generic set of service-specific calls to 897 compare flowspecs, to compute the LUB and GLB of flowspecs, and to 898 compare and sum Tspecs. 900 2.3 Soft State 902 RSVP takes a "soft state" approach to managing the reservation 903 state in routers and hosts. RSVP soft state is created and 904 periodically refreshed by Path and Resv messages. The state is 905 deleted if no matching refresh messages arrive before the 906 expiration of a "cleanup timeout" interval. State may also be 907 deleted by an explicit "teardown" message, described in the next 908 section. At the expiration of each "refresh timeout" period and 909 after a state change, RSVP scans its state to build and forward 910 Path and Resv refresh messages to succeeding hops. 912 Path and Resv messages are idempotent. When a route changes, the 913 next Path message will initialize the path state on the new route, 914 and future Resv messages will establish reservation state there; 915 the state on the now-unused segment of the route will time out. 916 Thus, whether a message is "new" or a "refresh" is determined 917 separately at each node, depending upon the existence of state at 918 that node. 920 RSVP sends its messages as IP datagrams with no reliability 921 enhancement. Periodic transmission of refresh messages by hosts 922 and routers is expected to handle the occasional loss of an RSVP 923 message. If the effective cleanup timeout is set to K times the 924 refresh timeout period, then RSVP can tolerate K-1 successive RSVP 925 packet losses without falsely deleting state. The network traffic 926 control mechanism should be statically configured to grant some 927 minimal bandwidth for RSVP messages to protect them from 928 congestion losses. 930 The state maintained by RSVP is dynamic; to change the set of 931 senders Si or to change any QoS request, a host simply starts 932 sending revised Path and/or Resv messages. The result will be an 933 appropriate adjustment in the RSVP state in all nodes along the 934 path; unused state will time out if it is not explicitly torn 935 down. 937 In steady state, state is refreshed hop-by-hop to allow merging. 938 When the received state differs from the stored state, the stored 939 state is updated. If this update results in modification of state 940 to be forwarded in refresh messages, these refresh messages must 941 be generated and forwarded immediately, so that state changes can 942 be propagated end-to-end without delay. However, propagation of a 943 change stops when and if it reaches a point where merging causes 944 no resulting state change. This minimizes RSVP control traffic 945 due to changes and is essential for scaling to large multicast 946 groups. 948 State that is received through a particular interface I* should 949 never be forwarded out the same interface. Conversely, state that 950 is forwarded out interface I* must be computed using only state 951 that arrived on interfaces different from I*. A trivial example 952 of this rule is illustrated in Figure 10, which shows a transit 953 router with one sender and one receiver on each interface (and 954 assumes one next/previous hop per interface). Interfaces (a) and 955 (c) serve as both outgoing and incoming interfaces for this 956 session. Both receivers are making wildcard-style reservations, 957 in which the Resv messages are forwarded to all previous hops for 958 senders in the group, with the exception of the next hop from 959 which they came. The result is independent reservations in the 960 two directions. 962 There is an additional rule governing the forwarding of Resv 963 messages: state from Resv messages received from outgoing 964 interface Io should be forwarded to incoming interface Ii only if 965 Path messages from Ii are forwarded to Io. 967 ________________ 968 a | | c 969 ( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) 970 |________________| 972 Send | Receive 973 | 974 WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) 975 | 976 Receive | Send 977 | 978 WF( *{4B}) --> (a) | (c) --> WF( *{4B}) 979 | 980 Reserve on (a) | Reserve on (c) 981 __________ | __________ 982 | * {4B} | | | * {3B} | 983 |__________| | |__________| 984 | 986 Figure 10: Independent Reservations 988 2.4 Teardown 990 RSVP "teardown" messages remove path or reservation state 991 immediately. Although it is not necessary to explicitly tear down 992 an old reservation, we recommend that all end hosts send a 993 teardown request as soon as an application finishes. 995 There are two types of RSVP teardown message, PathTear and 996 ResvTear. A PathTear message travels towards all receivers 997 downstream from its point of initiation and deletes path state, as 998 well as all dependent reservation state, along the way. An 999 ResvTear message deletes reservation state and travels towards all 1000 senders upstream from its point of initiation. A PathTear 1001 (ResvTear) message may be conceptualized as a reversed-sense Path 1002 message (Resv message, respectively). 1004 A teardown request may be initiated either by an application in an 1005 end system (sender or receiver), or by a router as the result of 1006 state timeout or service preemption. Once initiated, a teardown 1007 request must be forwarded hop-by-hop without delay. A teardown 1008 message deletes the specified state in the node where it is 1009 received. As always, this state change will be propagated 1010 immediately to the next node, but only if there will be a net 1011 change after merging. As a result, a ResvTear message will prune 1012 the reservation state back (only) as far as possible. 1014 Like all other RSVP messages, teardown requests are not delivered 1015 reliably. The loss of a teardown request message will not cause a 1016 protocol failure because the unused state will eventually time out 1017 even though it is not explicitly deleted. If a teardown message 1018 is lost, the router that failed to receive that message will time 1019 out its state and initiate a new teardown message beyond the loss 1020 point. Assuming that RSVP message loss probability is small, the 1021 longest time to delete state will seldom exceed one refresh 1022 timeout period. 1024 It should be possible to tear down any subset of the established 1025 state. For path state, the granularity for teardown is a single 1026 sender. For reservation state, the granularity is an individual 1027 filter spec. For example, refer to Figure 7. Receiver R1 could 1028 send a ResvTear message for sender S2 only (or for any subset of 1029 the filter spec list), leaving S1 in place. 1031 A ResvTear message specifies the style and filters; any flowspec 1032 is ignored. Whatever flowspec is in place will be removed if all 1033 its filter specs are torn down. 1035 2.5 Errors 1037 There are two RSVP error messages, ResvErr and PathErr. PathErr 1038 messages are very simple; they are simply sent upstream to the 1039 sender that created the error, and they do not change path state 1040 in the nodes though which they pass. There are only a few 1041 possible causes of path errors. 1043 However, there are a number of ways for a syntactically valid 1044 reservation request to fail at some node along the path. A node 1045 may also decide to preempt an established reservation. The 1046 handling of ResvErr messages is somewhat complex (Section 3.5). 1047 Since a request that fails may be the result of merging a number 1048 of requests, a reservation error must be reported to all of the 1049 responsible receivers. In addition, merging heterogeneous 1050 requests creates a potential difficulty known as the "killer 1051 reservation" problem, in which one request could deny service to 1052 another. There are actually two killer-reservation problems. 1054 1. The first killer reservation problem (KR-I) arises when there 1055 is already a reservation Q0 in place. If another receiver 1056 now makes a larger reservation Q1 > Q0, the result of merging 1057 Q0 and Q1 may be rejected by admission control in some 1058 upstream node. This must not deny service to Q0. 1060 The solution to this problem is simple: when admission 1061 control fails for a reservation request, any existing 1062 reservation is left in place. 1064 2. The second killer reservation problem (KR-II) is the 1065 converse: the receiver making a reservation Q1 is persistent 1066 even though Admission Control is failing for Q1 in some node. 1067 This must not prevent a different receiver from now 1068 establishing a smaller reservation Q0 that would succeed if 1069 not merged with Q1. 1071 To solve this problem, a ResvErr message establishes 1072 additional state, called "blockade state", in each node 1073 through which it passes. Blockade state in a node modifies 1074 the merging procedure to omit the offending flowspec (Q1 in 1075 the example) from the merge, allowing a smaller request to be 1076 forwarded and established. The Q1 reservation state is said 1077 to be "blockaded". Detailed rules are presented in Section 1078 3.5. 1080 A reservation request that fails Admission Control creates 1081 blockade state but is left in place in nodes downstream of the 1082 failure point. It has been suggested that these reservations 1083 downstream from the failure represent "wasted" reservations and 1084 should be timed out if not actively deleted. However, the 1085 downstream reservations are left in place, for the following 1086 reasons: 1088 o There are two possible reasons for a receiver persisting in a 1089 failed reservation: (1) it is polling for resource 1090 availability along the entire path, or (2) it wants to obtain 1091 the desired QoS along as much of the path as possible. 1092 Certainly in the second case, and perhaps in the first case, 1093 the receiver will want to hold onto the reservations it has 1094 made downstream from the failure. 1096 o If these downstream reservations were not retained, the 1097 responsiveness of RSVP to certain transient failures would be 1098 impaired. For example, suppose a route "flaps" to an 1099 alternate route that is congested, so an existing reservation 1100 suddenly fails, then quickly recovers to the original route. 1101 The blockade state in each downstream router must not remove 1102 the state or prevent its immediate refresh. 1104 o If we did not refresh the downstream reservations, they might 1105 time out, to be restored every Tb seconds (where Tb is the 1106 blockade state timeout interval). Such intermittent behavior 1107 might be very distressing for users. 1109 2.6 Confirmation 1111 To request a confirmation for its reservation request, a receiver 1112 Rj includes in the Resv message a confirmation-request object 1113 containing Rj's IP address. At each merge point, only the largest 1114 flowspec and any accompanying confirmation-request object is 1115 forwarded upstream. If the reservation request from Rj is equal 1116 to or smaller than the reservation in place on a node, its Resv is 1117 not forwarded further, and if the Resv included a confirmation- 1118 request object, a ResvConf message is sent back to Rj. If the 1119 confirmation request is forwarded, it is forwarded immediately, 1120 and no more than once for each request. 1122 This confirmation mechanism has the following consequences: 1124 o A new reservation request with a flowspec larger than any in 1125 place for a session will normally result in either a ResvErr 1126 or a ResvConf message back to the receiver from each sender. 1127 In this case, the ResvConf message will be an end-to-end 1128 confirmation. 1130 o The receipt of a ResvConf gives no guarantees. Assume the 1131 first two reservation requests from receivers R1 and R2 1132 arrive at the node where they are merged. R2, whose 1133 reservation was the second to arrive at that node, may 1134 receive a ResvConf from that node while R1's request has not 1135 yet propagated all the way to a matching sender and may still 1136 fail. Thus, R2 may receive a ResvConf although there is no 1137 end-to-end reservation in place; furthermore, R2 may receive 1138 a ResvConf followed by a ResvErr. 1140 2.7 Policy Control 1142 RSVP-mediated QoS requests allow particular user(s) to obtain 1143 preferential access to network resources. To prevent abuse, some 1144 form of back pressure will generally be required on users who make 1145 reservations. For example, such back pressure may be accomplished 1146 by administrative access policies, or it may depend upon some form 1147 of user feedback such as real or virtual billing for the "cost" of 1148 a reservation. In any case, reliable user identification and 1149 selective admission will generally be needed when a reservation is 1150 requested. 1152 The term "policy control" is used for the mechanisms required to 1153 support access policies and back pressure for RSVP reservations. 1154 When a new reservation is requested, each node must answer two 1155 questions: "Are enough resources available to meet this request?" 1156 and "Is this user allowed to make this reservation?" These two 1157 decisions are termed the "admission control" decision and the 1158 "policy control" decision, respectively, and both must be 1159 favorable in order for RSVP to make a reservation. Different 1160 administrative domains in the Internet may have different 1161 reservation policies. 1163 The input to policy control is referred to as "policy data", which 1164 RSVP carries in POLICY_DATA objects. Policy data may include 1165 credentials identifying users or user classes, account numbers, 1166 limits, quotas, etc. Like flowspecs, policy data is opaque to 1167 RSVP, which simply passes it to policy control when required. 1168 Similarly, merging of policy data must be done by the policy 1169 control mechanism rather than by RSVP itself. Note that the merge 1170 points for policy data are likely to be at the boundaries of 1171 administrative domains. It may therefore be necessary to carry 1172 accumulated and unmerged policy data upstream through multiple 1173 nodes before reaching one of these merge points. 1175 Carrying user-provided policy data in Resv messages presents a 1176 potential scaling problem. When a multicast group has a large 1177 number of receivers, it will be impossible or undesirable to carry 1178 all receivers' policy data upstream. The policy data will have to 1179 be administratively merged at places near the receivers, to avoid 1180 excessive policy data. Further discussion of these issues and an 1181 example of a policy control scheme will be found in [PolArch96]. 1182 Specifications for the format of policy data objects and RSVP 1183 processing rules for them are under development. 1185 2.8 Security 1187 RSVP raises the following security issues. 1189 o Message integrity and node authentication 1191 Corrupted or spoofed reservation requests could lead to theft 1192 of service by unauthorized parties or to denial of service 1193 caused by locking up network resources. RSVP protects 1194 against such attacks with a hop-by-hop authentication 1195 mechanism using an encrypted hash function. The mechanism is 1196 supported by INTEGRITY objects that may appear in any RSVP 1197 message. These objects use a keyed cryptographic digest 1198 technique, which assumes that RSVP neighbors share a secret. 1199 Although this mechanism is part of the base RSVP 1200 specification, it is described in a companion document 1201 [Baker96]. 1203 Widespread use of the RSVP integrity mechanism will require 1204 the availability of the long-sought key management and 1205 distribution infrastructure for routers. Until that 1206 infrastructure becomes available, manual key management will 1207 be required to secure RSVP message integrity. 1209 o User authentication 1211 Policy control will depend upon positive authentication of 1212 the user responsible for each reservation request. Policy 1213 data may therefore include cryptographically protected user 1214 certificates. Specification of such certificates is a future 1215 issue. 1217 Even without globally-verifiable user certificates, it may be 1218 possible to provide practical user authentication in many 1219 cases by establishing a chain of trust, using the hop-by-hop 1220 INTEGRITY mechanism described earlier. 1222 o Secure data streams 1224 The first two security issues concerned RSVP's operation. A 1225 third security issue concerns resource reservations for 1226 secure data streams. In particular, the use of IPSEC (IP 1227 Security) in the data stream poses a problem for RSVP: if 1228 the transport and higher level headers are encrypted, RSVP's 1229 generalized port numbers cannot be used to define a session 1230 or a sender. 1232 To solve this problem, an RSVP extension has been defined in 1233 which the security association identifier (IPSEC SPI) plays a 1234 role roughly equivalent to the generalized ports [IPSEC97]. 1236 2.9 Non-RSVP Clouds 1238 It is impossible to deploy RSVP (or any new protocol) at the same 1239 moment throughout the entire Internet. Furthermore, RSVP may 1240 never be deployed everywhere. RSVP must therefore provide correct 1241 protocol operation even when two RSVP-capable routers are joined 1242 by an arbitrary "cloud" of non-RSVP routers. Of course, an 1243 intermediate cloud that does not support RSVP is unable to perform 1244 resource reservation. However, if such a cloud has sufficient 1245 capacity, it may still provide useful realtime service. 1247 RSVP is designed to operate correctly through such a non-RSVP 1248 cloud. Both RSVP and non-RSVP routers forward Path messages 1249 towards the destination address using their local uni-/multicast 1250 routing table. Therefore, the routing of Path messages will be 1251 unaffected by non-RSVP routers in the path. When a Path message 1252 traverses a non-RSVP cloud, it carries to the next RSVP-capable 1253 node the IP address of the last RSVP-capable router before 1254 entering the cloud. An Resv message is then forwarded directly to 1255 the next RSVP-capable router on the path(s) back towards the 1256 source. 1258 Even though RSVP operates correctly through a non-RSVP cloud, the 1259 non-RSVP-capable nodes will in general perturb the QoS provided to 1260 a receiver. Therefore, RSVP passes a `NonRSVP' flag bit to the 1261 local traffic control mechanism when there are non-RSVP-capable 1262 hops in the path to a given sender. Traffic control combines this 1263 flag bit with its own sources of information, and forwards the 1264 composed information on integrated service capability along the 1265 path to receivers using Adspecs [ISrsvp96]. 1267 Some topologies of RSVP routers and non-RSVP routers can cause 1268 Resv messages to arrive at the wrong RSVP-capable node, or to 1269 arrive at the wrong interface of the correct node. An RSVP 1270 process must be prepared to handle either situation. If the 1271 destination address does not match any local interface and the 1272 message is not a Path or PathTear, the message must be forwarded 1273 without further processing by this node. To handle the wrong 1274 interface case, a "Logical Interface Handle" (LIH) is used. The 1275 previous hop information included in a Path message includes not 1276 only the IP address of the previous node but also an LIH defining 1277 the logical outgoing interface; both values are stored in the path 1278 state. A Resv message arriving at the addressed node carries both 1279 the IP address and the LIH of the correct outgoing interface, i.e, 1280 the interface that should receive the requested reservation, 1281 regardless of which interface it arrives on. 1283 The LIH may also be useful when RSVP reservations are made over a 1284 complex link layer, to map between IP layer and link layer flow 1285 entities. 1287 2.10 Host Model 1289 Before a session can be created, the session identification 1290 (DestAddress, ProtocolId [, DstPort]) must be assigned and 1291 communicated to all the senders and receivers by some out-of-band 1292 mechanism. When an RSVP session is being set up, the following 1293 events happen at the end systems. 1295 H1 A receiver joins the multicast group specified by 1296 DestAddress, using IGMP. 1298 H2 A potential sender starts sending RSVP Path messages to the 1299 DestAddress. 1301 H3 A receiver application receives a Path message. 1303 H4 A receiver starts sending appropriate Resv messages, 1304 specifying the desired flow descriptors. 1306 H5 A sender application receives a Resv message. 1308 H6 A sender starts sending data packets. 1310 There are several synchronization considerations. 1312 o H1 and H2 may happen in either order. 1314 o Suppose that a new sender starts sending data (H6) but there 1315 are no multicast routes because no receivers have joined the 1316 group (H1). Then the data will be dropped at some router 1317 node (which node depends upon the routing protocol) until 1318 receivers(s) appear. 1320 o Suppose that a new sender starts sending Path messages (H2) 1321 and data (H6) simultaneously, and there are receivers but no 1322 Resv messages have reached the sender yet (e.g., because its 1323 Path messages have not yet propagated to the receiver(s)). 1324 Then the initial data may arrive at receivers without the 1325 desired QoS. The sender could mitigate this problem by 1326 awaiting arrival of the first Resv message (H5); however, 1327 receivers that are farther away may not have reservations in 1328 place yet. 1330 o If a receiver starts sending Resv messages (H4) before 1331 receiving any Path messages (H3), RSVP will return error 1332 messages to the receiver. 1334 The receiver may simply choose to ignore such error messages, 1335 or it may avoid them by waiting for Path messages before 1336 sending Resv messages. 1338 A specific application program interface (API) for RSVP is not 1339 defined in this protocol spec, as it may be host system dependent. 1340 However, Section 3.11.1 discusses the general requirements and 1341 outlines a generic interface. 1343 3. RSVP Functional Specification 1345 3.1 RSVP Message Formats 1347 An RSVP message consists of a common header, followed by a body 1348 consisting of a variable number of variable-length, typed 1349 "objects". The following subsections define the formats of the 1350 common header, the standard object header, and each of the RSVP 1351 message types. 1353 For each RSVP message type, there is a set of rules for the 1354 permissible choice of object types. These rules are specified 1355 using Backus-Naur Form (BNF) augmented with square brackets 1356 surrounding optional sub-sequences. The BNF implies an order for 1357 the objects in a message. However, in many (but not all) cases, 1358 object order makes no logical difference. An implementation 1359 should create messages with the objects in the order shown here, 1360 but accept the objects in any permissible order. 1362 3.1.1 Common Header 1364 0 1 2 3 1365 +-------------+-------------+-------------+-------------+ 1366 | Vers | Flags| Msg Type | RSVP Checksum | 1367 +-------------+-------------+-------------+-------------+ 1368 | Send_TTL | (Reserved) | RSVP Length | 1369 +-------------+-------------+-------------+-------------+ 1371 The fields in the common header are as follows: 1373 Vers: 4 bits 1375 Protocol version number. This is version 1. 1377 Flags: 4 bits 1379 0x01-0x08: Reserved 1381 No flag bits are defined yet. 1383 Msg Type: 8 bits 1385 1 = Path 1387 2 = Resv 1388 3 = PathErr 1390 4 = ResvErr 1392 5 = PathTear 1394 6 = ResvTear 1396 7 = ResvConf 1398 RSVP Checksum: 16 bits 1400 The one's complement of the one's complement sum of the 1401 message, with the checksum field replaced by zero for the 1402 purpose of computing the checksum. An all-zero value 1403 means that no checksum was transmitted. 1405 Send_TTL: 8 bits 1407 The IP TTL value with which the message was sent. See 1408 Section 3.8. 1410 RSVP Length: 16 bits 1412 The total length of this RSVP message in bytes, including 1413 the common header and the variable-length objects that 1414 follow. 1416 3.1.2 Object Formats 1418 Every object consists of one or more 32-bit words with a one- 1419 word header, with the following format: 1421 0 1 2 3 1422 +-------------+-------------+-------------+-------------+ 1423 | Length (bytes) | Class-Num | C-Type | 1424 +-------------+-------------+-------------+-------------+ 1425 | | 1426 // (Object contents) // 1427 | | 1428 +-------------+-------------+-------------+-------------+ 1430 An object header has the following fields: 1432 Length 1434 A 16-bit field containing the total object length in 1435 bytes. Must always be a multiple of 4, and at least 4. 1437 Class-Num 1439 Identifies the object class; values of this field are 1440 defined in Appendix A. Each object class has a name, 1441 which is always capitalized in this document. An RSVP 1442 implementation must recognize the following classes: 1444 NULL 1446 A NULL object has a Class-Num of zero, and its C-Type 1447 is ignored. Its length must be at least 4, but can 1448 be any multiple of 4. A NULL object may appear 1449 anywhere in a sequence of objects, and its contents 1450 will be ignored by the receiver. 1452 SESSION 1454 Contains the IP destination address (DestAddress), 1455 the IP protocol id, and some form of generalized 1456 destination port, to define a specific session for 1457 the other objects that follow. Required in every 1458 RSVP message. 1460 RSVP_HOP 1462 Carries the IP address of the RSVP-capable node that 1463 sent this message and a logical outgoing interface 1464 handle (LIH; see Section 3.3). This document refers 1465 to a RSVP_HOP object as a PHOP ("previous hop") 1466 object for downstream messages or as a NHOP (" next 1467 hop") object for upstream messages. 1469 TIME_VALUES 1471 Contains the value for the refresh period R used by 1472 the creator of the message; see Section 3.7. 1473 Required in every Path and Resv message. 1475 STYLE 1477 Defines the reservation style plus style-specific 1478 information that is not in FLOWSPEC or FILTER_SPEC 1479 objects. Required in every Resv message. 1481 FLOWSPEC 1482 Defines a desired QoS, in a Resv message. 1484 FILTER_SPEC 1486 Defines a subset of session data packets that should 1487 receive the desired QoS (specified by a FLOWSPEC 1488 object), in a Resv message. 1490 SENDER_TEMPLATE 1492 Contains a sender IP address and perhaps some 1493 additional demultiplexing information to identify a 1494 sender. Required in a Path message. 1496 SENDER_TSPEC 1498 Defines the traffic characteristics of a sender's 1499 data flow. Required in a Path message. 1501 ADSPEC 1503 Carries OPWA data, in a Path message. 1505 ERROR_SPEC 1507 Specifies an error in a PathErr, ResvErr, or a 1508 confirmation in a ResvConf message. 1510 POLICY_DATA 1512 Carries information that will allow a local policy 1513 module to decide whether an associated reservation is 1514 administratively permitted. May appear in Path, 1515 Resv, PathErr, or ResvErr message. 1517 The use of POLICY_DATA objects is not fully specified 1518 at this time; a future document will fill this gap. 1520 INTEGRITY 1522 Carries cryptographic data to authenticate the 1523 originating node and to verify the contents of this 1524 RSVP message. The use of the INTEGRITY object is 1525 described in [Baker96]. 1527 SCOPE 1529 Carries an explicit list of sender hosts towards 1530 which the information in the message is to be 1531 forwarded. May appear in a Resv, ResvErr, or 1532 ResvTear message. See Section 3.4. 1534 RESV_CONFIRM 1536 Carries the IP address of a receiver that requested a 1537 confirmation. May appear in a Resv or ResvConf 1538 message. 1540 C-Type 1542 Object type, unique within Class-Num. Values are defined 1543 in Appendix A. 1545 The maximum object content length is 65528 bytes. The Class- 1546 Num and C-Type fields may be used together as a 16-bit number 1547 to define a unique type for each object. 1549 The high-order two bits of the Class-Num is used to determine 1550 what action a node should take if it does not recognize the 1551 Class-Num of an object; see Section 3.10. 1553 3.1.3 Path Messages 1555 Each sender host periodically sends a Path message for each 1556 data flow it originates. It contains a SENDER_TEMPLATE object 1557 defining the format of the data packets and a SENDER_TSPEC 1558 object specifying the traffic characteristics of the flow. 1559 Optionally, it may contain may be an ADSPEC object carrying 1560 advertising (OPWA) data for the flow. 1562 A Path message travels from a sender to receiver(s) along the 1563 same path(s) used by the data packets. The IP source address 1564 of a Path message must be an address of the sender it 1565 describes, while the destination address must be the 1566 DestAddress for the session. These addresses assure that the 1567 message will be correctly routed through a non-RSVP cloud. 1569 The format of a Path message is as follows: 1571 ::= [ ] 1573 1575 1577 [ ... ] 1579 [ ] 1581 ::= 1583 [ ] 1585 If the INTEGRITY object is present, it must immediately follow 1586 the common header. There are no other requirements on 1587 transmission order, although the above order is recommended. 1588 Any number of POLICY_DATA objects may appear. 1590 The PHOP (i.e., RSVP_HOP) object of each Path message contains 1591 the previous hop address, i.e., the IP address of the interface 1592 through which the Path message was most recently sent. It also 1593 carries a logical interface handle (LIH). 1595 Each RSVP-capable node along the path(s) captures a Path 1596 message and processes it to create path state for the sender 1597 defined by the SENDER_TEMPLATE and SESSION objects. Any 1598 POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in 1599 the path state. If an error is encountered while processing a 1600 Path message, a PathErr message is sent to the originating 1601 sender of the Path message. Path messages must satisfy the 1602 rules on SrcPort and DstPort in Section 3.2. 1604 Periodically, the RSVP process at a node scans the path state 1605 to create new Path messages to forward towards the receiver(s). 1606 Each message contains a sender descriptor defining one sender, 1607 and carries the original sender's IP address as its IP source 1608 address. Path messages eventually reach the applications on 1609 all receivers; however, they are not looped back to a receiver 1610 running in the same application process as the sender. 1612 The RSVP process forwards Path messages and replicates them as 1613 required by multicast sessions, using routing information it 1614 obtains from the appropriate uni-/multicast routing process. 1615 The route depends upon the session DestAddress, and for some 1616 routing protocols also upon the source (sender's IP) address. 1617 The routing information generally includes the list of zero or 1618 more outgoing interfaces to which the Path message is to be 1619 forwarded. Because each outgoing interface has a different IP 1620 address, the Path messages sent out different interfaces 1621 contain different PHOP addresses. In addition, ADSPEC objects 1622 carried in Path messages will also generally differ for 1623 different outgoing interfaces. 1625 Path state for a given session and sender may not necessarily 1626 have a unique PHOP or unique incoming interface. There are two 1627 cases, corresponding to multicast and unicast sessions. 1629 o Multicast Sessions 1631 Multicast routing allows a stable distribution tree in 1632 which Path messages from the same sender arrive from more 1633 than one PHOP, and RSVP must be prepared to maintain all 1634 such path state. The RSVP rules for handling this 1635 situation are contained in Section 3.9. RSVP must not 1636 forward (according to the rules of Section 3.9) Path 1637 messages that arrive on an incoming interface different 1638 from that provided by routing. 1640 o Unicast Sessions 1642 For a short period following a unicast route change 1643 upstream, a node may receive Path messages from multiple 1644 PHOPs for a given (session, sender) pair. The node cannot 1645 reliably determine which is the right PHOP, although the 1646 node will receive data from only one of the PHOPs at a 1647 time. One implementation choice for RSVP is to ignore 1648 PHOP in matching unicast past state, and allow the PHOP to 1649 flip among the candidates. Another implementation choice 1650 is to maintain path state for each PHOP and to send Resv 1651 messages upstream towards all such PHOPs. In either case, 1652 the situation is a transient; the unused path state will 1653 time out or be torn down (because upstream path state 1654 timed out). 1656 3.1.4 Resv Messages 1658 Resv messages carry reservation requests hop-by-hop from 1659 receivers to senders, along the reverse paths of data flows for 1660 the session. The IP destination address of a Resv message is 1661 the unicast address of a previous-hop node, obtained from the 1662 path state. The IP source address is an address of the node 1663 that sent the message. 1665 The Resv message format is as follows: 1667 ::= [ ] 1669 1671 1673 [ ] [ ] 1675 [ ... ] 1677