idnits 2.17.1 draft-ietf-rsvp-spec-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 866 has weird spacing: '...stalled reser...' -- 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 (March 18, 1996) is 10237 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: 'S4' is mentioned on line 2132, but not defined == Missing Reference: 'S1' is mentioned on line 2128, but not defined == Missing Reference: 'S2' is mentioned on line 2132, but not defined == Missing Reference: 'S3' is mentioned on line 2132, but not defined == Missing Reference: 'ADSPEC' is mentioned on line 3352, but not defined == Missing Reference: 'RA' is mentioned on line 4820, but not defined == Missing Reference: 'Note 1' is mentioned on line 4826, but not defined == Missing Reference: 'Note 2' is mentioned on line 4830, but not defined == Missing Reference: 'Note 3' is mentioned on line 4833, 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. 'Katz95' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISdata95' -- 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. 'ServTempl95') -- Possible downref: Non-RFC (?) normative reference: ref. 'OPWA95' Summary: 10 errors (**), 0 flaws (~~), 12 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: September 1996 ISI 4 File: draft-ietf-rsvp-spec-11.txt L. Zhang 5 PARC 6 S. Berson 7 ISI 8 S. Herzog 9 ISI 10 S. Jamin 11 USC 13 Resource ReSerVation Protocol (RSVP) -- 15 Version 1 Functional Specification 17 March 18, 1996 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 ..............................................13 51 2. RSVP Protocol Mechanisms ............................................18 52 2.1 RSVP Messages ...................................................18 53 2.2 Port Usage ......................................................20 54 2.3 Merging Flowspecs ...............................................21 55 2.4 Soft State ......................................................22 56 2.5 Teardown ........................................................24 57 2.6 Errors ..........................................................25 58 2.7 Confirmation ....................................................27 59 2.8 Policy and Security .............................................27 60 2.9 Non-RSVP Clouds .................................................28 61 2.10 Host Model .....................................................29 62 3. RSVP Functional Specification .......................................31 63 3.1 RSVP Message Formats ............................................31 64 3.2 Sending RSVP Messages ...........................................44 65 3.3 Avoiding RSVP Message Loops .....................................45 66 3.4 Blockade State ..................................................49 67 3.5 Local Repair ....................................................51 68 3.6 Time Parameters .................................................52 69 3.7 Traffic Policing and Non-Integrated Service Hops ................53 70 3.8 Multihomed Hosts ................................................54 71 3.9 Future Compatibility ............................................56 72 3.10 RSVP Interfaces ................................................58 73 4. Message Processing Rules ............................................70 74 5. Acknowledgments .....................................................90 75 APPENDIX A. Object Definitions .........................................91 76 APPENDIX B. Error Codes and Values .....................................107 77 APPENDIX C. UDP Encapsulation ..........................................112 78 What's Changed 80 The most important changes in this document from the rsvp-spec-10 81 draft are: 83 o RSVP-layer fragmentation machinery was removed. 85 However, the common header was rearranged to allow message 86 length to be expanded beyond 16 bits in the future, should 87 that be necessary. 89 o A little more discussion of IPv6 in Introduction. 91 o Service preemption now triggers a ResvTear message. 93 o Traffic Control can return updated FLOWSPEC. (This forced a 94 significant change in the UPDATE TRAFFIC CONTROL processing 95 in section 4). 97 o The discussion at the end of Section 2.3 was rewritten. 99 o The Message Processing Rules were updated. 101 The most important changes in this document from the rsvp-spec-09 102 draft are: 104 o Multiple POLICY_DATA objects in any order are now allowed. 106 o The length field in the common header is now the total 107 message length [Section 3.1.1]. 109 o The meaning of Message Id is refined and more completely 110 specified [Section 3.1.1]. 112 o RSVP fragmentation is specifically called for, and IP 113 fragmentation disallowed [Section 3.1.1]. 115 o The granularity of state timeouts is now specified [Section 116 3.6]. 118 1. Introduction 120 This document defines RSVP, a resource reservation setup protocol 121 designed for an integrated services Internet [RSVP93,ISInt93]. 123 The RSVP protocol is used by a host, on behalf of an application data 124 stream, to request a specific quality of service (QoS) from the 125 network. The RSVP protocol is also used by routers to deliver QoS 126 requests to all nodes along the path(s) of the data stream and to 127 establish and maintain state to provide the requested service. RSVP 128 requests will generally, although not necessarily, result in 129 resources being reserved along the data path. 131 RSVP requests resources for simplex data streams, i.e., it requests 132 resources in only one direction. Therefore, RSVP treats a sender as 133 logically distinct from a receiver, although the same application 134 process may act as both a sender and a receiver at the same time. 135 RSVP operates on top of IP (either IPv4 or IPv6), occupying the place 136 of a transport protocol in the protocol stack. However, RSVP does 137 not transport application data but is rather an Internet control 138 protocol, like ICMP, IGMP, or routing protocols. Like the 139 implementations of routing and management protocols, an 140 implementation of RSVP will typically execute in the background, not 141 in the data forwarding path, as shown in Figure 1. 143 RSVP is not itself a routing protocol; RSVP is designed to operate 144 with current and future unicast and multicast routing protocols. An 145 RSVP daemon consults the local routing database(s) to obtain routes. 146 In the multicast case, for example, a host sends IGMP messages to 147 join a multicast group and then sends RSVP messages to reserve 148 resources along the delivery path(s) of that group. Routing 149 protocols determine where packets get forwarded; RSVP is only 150 concerned with the QoS of those packets that are forwarded in 151 accordance with routing. 153 HOST ROUTER 155 _________________________ RSVP _____________________________ 156 | | .--------------. | 157 | _______ ______ | / | ________ . ______ | 158 | | | | | | / || | . | | | RSVP 159 | |Applic-| | RSVP <----/ ||Routing | -> RSVP <----------> 160 | | App <----->daemon| | ||Protocol| |daemon| _____ | 161 | | | | | | || daemon <----> >|Polcy|| 162 | |_______| |___.__| | ||_ ._____| |__.__.||Cntrl|| 163 | | | | | | | .|_____|| 164 |===|===============|=====| |===|=============|====.======| 165 | data .........| | | | ...........| .____ | 166 | | ____V_ ____V____ | | _V__V_ _____V___ |Admis|| 167 | | |Class-| | || data | |Class-| | ||Cntrl|| 168 | |=> ifier|=> Packet ============> ifier|==> Packet ||_____|| data 169 | |______| |Scheduler|| | |______| |Scheduler|===========> 170 | |_________|| | |_________| | 171 |_________________________| |_____________________________| 173 Figure 1: RSVP in Hosts and Routers 175 Each node that is capable of resource reservation passes incoming 176 data packets through a "packet classifier", which determines the 177 route and the QoS class for each packet. On outgoing interface, a 178 "packet scheduler" then makes forwarding decisions for every packet, 179 to achieve the promised QoS on the particular link-layer medium used 180 by that interface. 182 If the link-layer medium is QoS-active, i.e., if it has its own QoS 183 management capability, then the packet scheduler is responsible for 184 negotiation with the link layer to obtain the QoS requested by RSVP. 185 This mapping to the link layer QoS may be accomplished in a number of 186 possible ways; the details will be medium-dependent. On a QoS- 187 passive medium such as a leased line, the scheduler itself allocates 188 packet transmission capacity. The scheduler may also allocate other 189 system resources such as CPU time or buffers. 191 In order to efficiently accommodate large groups, dynamic group 192 membership, and heterogeneous receiver requirements, RSVP makes 193 receivers responsible for requesting QoS [RSVP93]. A QoS request, 194 which typically originates from a receiver host application, is 195 passed to the local RSVP implementation, shown as a daemon process in 196 Figure 1. The RSVP protocol then carries the request to all the 197 nodes (routers and hosts) along the reverse data path(s) to the data 198 source(s). 200 At each node, the RSVP daemon communicates with two local decision 201 modules, "admission control" and "policy control". Admission control 202 determines whether the node has sufficient available resources to 203 supply the requested QoS. Policy control determines whether the user 204 has administrative permission to make the reservation. If both 205 checks succeed, the RSVP daemon sets parameters in the packet 206 classifier and scheduler to obtain the desired QoS. If either check 207 fails, the RSVP program returns an error notification to the 208 application process that originated the request. We refer to the 209 packet classifier, packet scheduler, and admission control components 210 as "traffic control". 212 RSVP is designed to scale well for very large multicast groups. 213 Since both the membership of a large group and the topology of large 214 multicast trees are likely to change with time, the RSVP design 215 assumes that router state for traffic control will be built and 216 destroyed incrementally. For this purpose, RSVP uses "soft state" in 217 the routers. That is, RSVP sends periodic refresh messages to 218 maintain the state along the reserved path(s); in absence of 219 refreshes, the state will automatically time out and be deleted. 221 RSVP protocol mechanisms provide a general facility for creating and 222 maintaining distributed reservation state across a mesh of multicast 223 or unicast delivery paths. Except for certain well-defined 224 operations on the parameters, RSVP transfers QoS and policy 225 parameters as opaque data, passing them to the appropriate traffic 226 control and policy control modules for interpretation. 228 In summary, RSVP has the following attributes: 230 o RSVP makes resource reservations for both unicast and many-to- 231 many multicast applications, adapting dynamically to changing 232 group membership as well as to changing routes. 234 o RSVP is simplex, i.e., it makes reservations for unidirectional 235 data flows. 237 o RSVP is receiver-oriented, i.e., the receiver of a data flow 238 initiates and maintains the resource reservation used for that 239 flow. 241 o RSVP maintains "soft state" in the routers, providing graceful 242 support for dynamic membership changes and automatic adaptation 243 to routing changes. 245 o RSVP is not a routing protocol but depends upon present and 246 future routing protocols. 248 o RSVP transports and maintains opaque state for traffic control, 249 and policy control. 251 o RSVP provides several reservation models or "styles" (defined 252 below) to fit a variety of applications. 254 o RSVP provides transparent operation through routers that do not 255 support it. 257 o RSVP supports both IPv4 and IPv6. 259 Further discussion on the objectives and general justification for 260 RSVP design are presented in [RSVP93,ISInt93]. 262 The remainder of this section describes the RSVP reservation 263 services. Section 2 presents an overview of the RSVP protocol 264 mechanisms. Section 3 contains the functional specification of RSVP, 265 while Section 4 presents explicit message processing rules. Appendix 266 A defines the variable-length typed data objects used in the RSVP 267 protocol. Appendix B defines error codes and values. Appendix C 268 defines an extension for UDP encapsulation of RSVP messages. 270 1.1 Data Flows 272 RSVP defines a "session" to be a data flow with a particular 273 destination and transport-layer protocol. The destination of a 274 session is defined by DestAddress, the IP destination address of 275 the data packets, and perhaps by DstPort, a "generalized 276 destination port", i.e., some further demultiplexing point in the 277 transport or application protocol layer. RSVP treats each session 278 independently, and this document often omits the implied 279 qualification "for the same session". 281 DestAddress is a group address for multicast delivery or the 282 unicast address of a single receiver. DstPort could be defined by 283 a UDP/TCP destination port field, by an equivalent field in 284 another transport protocol, or by some application-specific 285 information. Although the RSVP protocol is designed to be easily 286 extensible for greater generality, the basic protocol documented 287 here supports only UDP/TCP ports as generalized ports. Note that 288 it is not strictly necessary to include DstPort in the session 289 definition when DestAddress is multicast, since different sessions 290 can always have different multicast addresses. However, DstPort 291 is necessary to allow more than one unicast session addressed to 292 the same receiver host. 294 Figure 2 illustrates the flow of data packets in a single RSVP 295 session, assuming multicast data distribution. The arrows 296 indicate data flowing from senders S1 and S2 to receivers R1, R2, 297 and R3, and the cloud represents the distribution mesh created by 298 multicast routing. Multicast distribution forwards a copy of each 299 data packet from a sender Si to every receiver Rj; a unicast 300 distribution session has a single receiver R. Each sender Si may 301 be running in a unique Internet host, or a single host may contain 302 multiple senders distinguished by "generalized source ports". 304 Senders Receivers 305 _____________________ 306 ( ) ===> R1 307 S1 ===> ( Multicast ) 308 ( ) ===> R2 309 ( distribution ) 310 S2 ===> ( ) 311 ( by Internet ) ===> R3 312 (_____________________) 314 Figure 2: Multicast Distribution Session 316 For unicast transmission, there will be a single destination host 317 but there may be multiple senders; RSVP can set up reservations 318 for multipoint-to-single-point transmission. 320 1.2 Reservation Model 322 An elementary RSVP reservation request consists of a "flowspec" 323 together with a "filter spec"; this pair is called a "flow 324 descriptor". The flowspec specifies a desired QoS. The filter 325 spec, together with a session specification, defines the set of 326 data packets -- the "flow" -- to receive the QoS defined by the 327 flowspec. The flowspec is used to set parameters in the node's 328 packet scheduler (assuming that admission control succeeds), while 329 the filter spec is used to set parameters in the packet 330 classifier. Data packets that are addressed to a particular 331 session but do not match any of the filter specs for that session 332 are handled as best-effort traffic. 334 Note that the action to control QoS occurs at the place where the 335 data enters the medium, i.e., at the upstream end of the logical 336 or physical link, although an RSVP reservation request originates 337 from receiver(s) downstream. In this document, we define the 338 directional terms "upstream" vs. "downstream", "previous hop" vs. 339 "next hop", and "incoming interface" vs "outgoing interface" with 340 respect to the direction of data flow. 342 The flowspec in a reservation request will generally include a 343 service class and two sets of numeric parameters: (1) an "Rspec" 344 (R for `reserve') that defines the desired QoS, and (2) a "Tspec" 345 (T for `traffic') that describes the data flow. The formats and 346 contents of Tspecs and Rspecs are determined by the integrated 347 service model [ServTempl95, ISdata95], and are generally opaque to 348 RSVP. The exact format of a filter spec depends upon whether IPv4 349 or IPv6 is in use; see Appendix A. 351 In the most general approach [RSVP93], filter specs may select 352 arbitrary subsets of the packets in a given session. Such subsets 353 might be defined in terms of senders (i.e., sender IP address and 354 generalized source port), in terms of a higher-level protocol, or 355 generally in terms of any fields in any protocol headers in the 356 packet. For example, filter specs might be used to select 357 different subflows in a hierarchically-encoded signal by selecting 358 on fields in an application-layer header. In the interest of 359 simplicity (and to minimize layer violation), the present RSVP 360 version uses a much more restricted form of filter spec, 361 consisting of sender IP address and optionally the UDP/TCP port 362 number SrcPort. 364 Because the UDP/TCP port numbers are used for packet 365 classification, each router must be able to examine these fields. 366 As a result, it is generally necessary to avoid IP fragmentation 367 of a data stream for which a resource reservation is desired. 369 There are two cases where the use of transport-layer ports for 370 selecting an RSVP flow may cause problems. 372 1. IPv6 inserts a variable number of variable-length Internet- 373 layer headers before the transport header, increasing the 374 difficulty and cost of packet classification for QoS. 376 Efficient classification of IPv6 data packets could be 377 obtained using the Flow Label field of the IPv6 header. The 378 details will be provided in the future. 380 2. IP-level Security, under either IPv4 or IPv6, may encrypt the 381 entire transport header, rendering the port numbers invisible 382 to intermediate routers. 384 A small extension to RSVP for IP Security under IPv4 is 385 described separately in [IPSEC96]. A corresponding solution 386 for IPv6 will be provided in the future. 388 RSVP messages carrying reservation requests originate at receivers 389 and are passed upstream towards the sender(s). At each 390 intermediate node, two general actions are taken on a request. 392 1. Make a reservation 394 The request is passed to admission control and policy 395 control. If either test fails, the reservation is rejected 396 and RSVP returns an error message to the appropriate 397 receiver(s). If both succeed, the node uses the flowspec to 398 set up the packet scheduler for the desired QoS and the 399 filter spec to set the packet classifier to select the 400 appropriate data packets. 402 2. Forward the request upstream 404 The reservation request is propagated upstream towards the 405 appropriate senders. The set of sender hosts to which a 406 given reservation request is propagated is called the "scope" 407 of that request. 409 The reservation request that a node forwards upstream may differ 410 from the request that it received from downstream, for two 411 reasons. First, the traffic control mechanism may modify the 412 flowspec hop-by-hop. Second, reservations for the same sender, or 413 the same set of senders, from different downstream branches of the 414 multicast tree(s) are "merged" as reservations travel upstream; as 415 a result, a node forwards upstream only the reservation request 416 with the "maximum" flowspec. 418 When a receiver originates a reservation request, it can also 419 request a confirmation message to indicate that its request was 420 (probably) installed in the network. A successful reservation 421 request propagates upstream along the multicast tree until it 422 reaches a point where an existing reservation is equal or greater 423 than that being requested. At that point, the arriving request is 424 merged with the reservation in place and need not be forwarded 425 further; the node may then send a reservation confirmation message 426 back to the receiver. Note that the receipt of a confirmation is 427 only a high-probability indication, not a guarantee, that the 428 requested service is in place all the way to the sender(s), as 429 explained in Section 2.7. 431 The basic RSVP reservation model is "one pass": a receiver sends a 432 reservation request upstream, and each node in the path either 433 accepts or rejects the request. This scheme provides no easy way 434 for a receiver to find out the resulting end-to-end service. 435 Therefore, RSVP supports an enhancement to one-pass service known 436 as "One Pass With Advertising" (OPWA) [OPWA95]. With OPWA, RSVP 437 control packets are sent downstream, following the data paths, to 438 gather information that may be used to predict the end-to-end QoS. 439 The results ("advertisements") are delivered by RSVP to the 440 receiver hosts and perhaps to the receiver applications. The 441 advertisements may then be used by the receiver to construct, or 442 to dynamically adjust, an appropriate reservation request. 444 1.3 Reservation Styles 446 A reservation request includes a set of options that are 447 collectively called the reservation "style". 449 One reservation option concerns the treatment of reservations for 450 different senders within the same session: establish a "distinct" 451 reservation for each upstream sender, or else make a single 452 reservation that is "shared" among all packets of selected 453 senders. 455 Another reservation option controls the selection of senders; it 456 may be an "explicit" list of all selected senders, or a "wildcard" 457 that implicitly selects all the senders to the session. In an 458 explicit sender-selection reservation, each filter spec must match 459 exactly one sender, while in a wildcard sender-selection no filter 460 spec is needed. 462 Sender || Reservations: 463 Selection || Distinct | Shared 464 _________||__________________|____________________ 465 || | | 466 Explicit || Fixed-Filter | Shared-Explicit | 467 || (FF) style | (SE) Style | 468 __________||__________________|____________________| 469 || | | 470 Wildcard || (None defined) | Wildcard-Filter | 471 || | (WF) Style | 472 __________||__________________|____________________| 474 Figure 3: Reservation Attributes and Styles 476 The following styles currently defined (see Figure 3): 478 o Wildcard-Filter (WF) Style 480 The WF style implies the options: "shared" reservation and 481 "wildcard" sender selection. Thus, a WF-style reservation 482 creates a single reservation shared by flows from all 483 upstream senders. This reservation may be thought of as a 484 shared "pipe", whose "size" is the largest of the resource 485 requests from all receivers, independent of the number of 486 senders using it. A WF-style reservation is propagated 487 upstream towards all sender hosts, and it automatically 488 extends to new senders as they appear. 490 Symbolically, we can represent a WF-style reservation request 491 by: 493 WF( * {Q}) 495 where the asterisk represents wildcard sender selection and Q 496 represents the flowspec. 498 o Fixed-Filter (FF) Style 500 The FF style implies the options: "distinct" reservations and 501 "explicit" sender selection. Thus, an elementary FF-style 502 reservation request creates a distinct reservation for data 503 packets from a particular sender, not sharing them with other 504 senders' packets for the same session. 506 Symbolically, we can represent an elementary FF reservation 507 request by: 509 FF( S{Q}) 511 where S is the selected sender and Q is the corresponding 512 flowspec; the pair forms a flow descriptor. RSVP allows 513 multiple elementary FF-style reservations to be requested at 514 the same time, using a list of flow descriptors: 516 FF( S1{Q1}, S2{Q2}, ...) 518 The total reservation on a link for a given session is the 519 `sum' of Q1, Q2, ... for all requested senders. 521 o Shared Explicit (SE) Style 523 The SE style implies the options: "shared" reservation and " 524 explicit" sender selection. Thus, an SE-style reservation 525 creates a single reservation shared by selected upstream 526 senders. Unlike the WF style, the SE style allows a receiver 527 to explicitly specify the set of senders to be included. 529 We can represent an SE reservation request containing a 530 flowspec Q and a list of senders S1, S2, ... by: 532 SE( (S1,S2,...){Q} ) 534 Shared reservations, created by WF and SE styles, are appropriate 535 for those multicast applications in which multiple data sources 536 are unlikely to transmit simultaneously. Packetized audio is an 537 example of an application suitable for shared reservations; since 538 a limited number of people talk at once, each receiver might issue 539 a WF or SE reservation request for twice the bandwidth required 540 for one sender (to allow some over-speaking). On the other hand, 541 the FF style, which creates distinct reservations for the flows 542 from different senders, is appropriate for video signals. 544 The RSVP rules disallow merging of shared reservations with 545 distinct reservations, since these modes are fundamentally 546 incompatible. They also disallow merging explicit sender 547 selection with wildcard sender selection, since this might produce 548 an unexpected service for a receiver that specified explicit 549 selection. As a result of these prohibitions, WF, SE, and FF 550 styles are all mutually incompatible. 552 It would seem possible to simulate the effect of a WF reservation 553 using the SE style. When an application asked for WF, the RSVP 554 daemon on the receiver host could use local state to create an 555 equivalent SE reservation that explicitly listed all senders. 556 However, an SE reservation forces the packet classifier in each 557 node to explicitly select each sender in the list, while a WF 558 allows the packet classifier to simply "wild card" the sender 559 address and port. When there is a large list of senders, a WF 560 style reservation can therefore result in considerably less 561 overhead than an equivalent SE style reservation. For this 562 reason, both SE and WF are included in the protocol. 564 Other reservation options and styles may be defined in the future. 566 1.4 Examples of Styles 568 This section presents examples of each of the reservation styles 569 and shows the effects of merging. 571 Figure 4 illustrates a router with two incoming interfaces, 572 labeled (a) and (b), through which data streams will arrive, and 573 two outgoing interfaces, labeled (c) and (d), through which data 574 will be forwarded. This topology will be assumed in the examples 575 that follow. There are three upstream senders; packets from 576 sender S1 (S2 and S3) arrive through previous hop (a) ((b), 577 respectively). There are also three downstream receivers; packets 578 bound for R1 (R2 and R3) are routed via outgoing interface (c) 579 ((d), respectively). We furthermore assume that outgoing 580 interface (d) is connected to a broadcast LAN, and that R2 and R3 581 are reached via different next hop routers (not shown). 583 We must also specify the multicast routes within the nod of Figure 584 4. Assume first that data packets from each Si shown in Figure 4 585 is routed to both outgoing interfaces. Under this assumption, 586 Figures 5, 6, and 7 illustrate Wildcard-Filter, Fixed-Filter, and 587 Shared-Explicit reservations, respectively. 589 ________________ 590 (a)| | (c) 591 ( S1 ) ---------->| |----------> ( R1 ) 592 | Router | | 593 (b)| | (d) |---> ( R2 ) 594 ( S2,S3 ) ------->| |------| 595 |________________| |---> ( R3 ) 596 | 597 Figure 4: Router Configuration 599 For simplicity, these examples show flowspecs as one-dimensional 600 multiples of some base resource quantity B. The "Receive" column 601 shows the RSVP reservation requests received over outgoing 602 interfaces (c) and (d), and the "Reserve" column shows the 603 resulting reservation state for each interface. The "Send" 604 column shows the reservation requests that are sent upstream to 605 previous hops (a) and (b). In the "Reserve" column, each box 606 represents one reserved "pipe" on the outgoing link, with the 607 corresponding flow descriptor. 609 Figure 5, showing the WF style, illustrates two distinct 610 situations in which merging is required. (1) Each of the two next 611 hops on interface (d) results in a separate RSVP reservation 612 request, as shown; these two requests must be merged into the 613 effective flowspec, 3B, that is used to make the reservation on 614 interface (d). (2) The reservations on the interfaces (c) and (d) 615 must be merged in order to forward the reservation requests 616 upstream; as a result, the larger flowspec 4B is forwarded 617 upstream to each previous hop. 619 | 620 Send | Reserve Receive 621 | 622 | _______ 623 WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) 624 | |_______| 625 | 626 -----------------------|---------------------------------------- 627 | _______ 628 WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) 629 | |_______| <- WF( *{2B} ) 631 Figure 5: Wildcard-Filter (WF) Reservation Example 633 Figure 6 shows Fixed-Filter (FF) style reservations. The flow 634 descriptors for senders S2 and S3, received from outgoing 635 interfaces (c) and (d), are packed (not merged) into the request 636 forwarded to previous hop (b). On the other hand, the three 637 different flow descriptors specifying sender S1 are merged into 638 the single request FF( S1{4B} ) that is sent to previous hop (a). 639 For each outgoing interface, there is a separate reservation for 640 each source that has been requested, but this reservation will be 641 shared among all the receivers that made the request. 643 | 644 Send | Reserve Receive 645 | 646 | ________ 647 FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} ) 648 | |________| 649 | | S2{5B} | 650 | |________| 651 ---------------------|--------------------------------------------- 652 | ________ 653 <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) 654 FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} ) 655 | | S3{B} | 656 | |________| 658 Figure 6: Fixed-Filter (FF) Reservation Example 660 Figure 7 shows an example of Shared-Explicit (SE) style 661 reservations. When SE-style reservations are merged, the 662 resulting filter spec is the union of the original filter specs, 663 and the resulting flowspec is the largest flowspec. 665 | 666 Send | Reserve Receive 667 | 668 | ________ 669 SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} ) 670 | | {B} | 671 | |________| 672 ---------------------|--------------------------------------------- 673 | __________ 674 <- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} ) 675 SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} ) 676 | |__________| 678 Figure 7: Shared-Explicit (SE) Reservation Example 680 The three examples just shown assume that data packets from S1, 681 S2, and S3 are routed to both outgoing interfaces. The top part 682 of Figure 8 shows another routing assumption: data packets from S2 683 and S3 are not forwarded to interface (c), e.g., because the 684 network topology provides a shorter path for these senders towards 685 R1, not traversing this node. The bottom part of Figure 8 shows 686 WF style reservations under this assumption. Since there is no 687 route from (b) to (c), the reservation forwarded out interface (b) 688 considers only the reservation on interface (d). 690 _______________ 691 (a)| | (c) 692 ( S1 ) ---------->| >-----------> |----------> ( R1 ) 693 | - | 694 | - | 695 (b)| - | (d) 696 ( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 ) 697 |_______________| 699 Router Configuration 701 | 702 Send | Reserve Receive 703 | 704 | _______ 705 WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) 706 | |_______| 707 | 708 -----------------------|---------------------------------------- 709 | _______ 710 WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) 711 | |_______| <- WF( * {2B} 713 Figure 8: WF Reservation Example -- Partial Routing 715 2. RSVP Protocol Mechanisms 717 2.1 RSVP Messages 719 Previous Incoming Outgoing Next 720 Hops Interfaces Interfaces Hops 722 _____ _____________________ _____ 723 | | data --> | | data --> | | 724 | A |-----------| a c |--------------| C | 725 |_____| Path --> | | Path --> |_____| 726 <-- Resv | | <-- Resv _____ 727 _____ | ROUTER | | | | 728 | | | | | |--| D | 729 | B |--| data-->| | data --> | |_____| 730 |_____| |--------| b d |-----------| 731 | Path-->| | Path --> | _____ 732 _____ | <--Resv|_____________________| <-- Resv | | | 733 | | | |--| D' | 734 | B' |--| | |_____| 735 |_____| | | 737 Figure 9: Router Using RSVP 739 Figure 9 illustrates RSVP's model of a router node. Each data 740 stream arrives from a "previous hop" through a corresponding 741 "incoming interface" and departs through one or more "outgoing 742 interface"(s). The same physical interface may act in both the 743 incoming and outgoing roles for different data flows in the same 744 session. Multiple previous hops and/or next hops may be reached 745 through a given physical interface, as a result of the connected 746 network being a shared medium, or the existence of non-RSVP 747 routers in the path to the next RSVP hop (see Section 2.9). 749 There are two fundamental RSVP message types: Resv and Path. 751 Each receiver host sends RSVP reservation request (Resv) messages 752 upstream towards the senders. These messages must follow exactly 753 the reverse of the path(s) the data packets will use, upstream to 754 all the sender hosts included in the sender selection. They 755 create and maintain "reservation state" in each node along the 756 path(s). Resv messages must finally be delivered to the sender 757 hosts themselves, so that the hosts can set up appropriate traffic 758 control parameters for the first hop. The processing of Resv 759 messages was discussed previously in Section 1.2. 761 Each RSVP sender host transmits RSVP "Path" messages downstream 762 along the uni-/multicast routes provided by the routing 763 protocol(s), following the paths of the data. These Path messages 764 store "path state" in each node along the way. This path state 765 includes at least the unicast IP address of the previous hop node, 766 which is used to route the Resv messages hop-by-hop in the reverse 767 direction. (In the future, some routing protocols may supply 768 reverse path forwarding information directly, replacing the 769 reverse-routing function of path state). 771 A Path message may carry the following information in addition to 772 the previous hop address: 774 o Sender Template 776 A Path message is required to carry a Sender Template, which 777 describes the format of data packets that the sender will 778 originate. This template is in the form of a filter spec 779 that could be used to select this sender's packets from 780 others in the same session on the same link. 782 Sender Templates have exactly the same expressive power and 783 format as filter specs that appear in Resv messages. 784 Therefore a Sender Template may specify only the sender IP 785 address and optionally the UDP/TCP sender port, and it 786 assumes the protocol Id specified for the session. 788 o Sender Tspec 790 A Path message is required to carry a Sender Tspec, which 791 defines the traffic characteristics of the data stream that 792 the sender will generate. This Tspec is used by traffic 793 control to prevent over-reservation, and perhaps unnecessary 794 Admission Control failures. 796 o Adspec 798 A Path message may optionally carry a package of OPWA 799 advertising information, known as an "Adspec". An Adspec 800 received in a Path message is passed to the local traffic 801 control, which returns an updated Adspec; the updated version 802 is then forwarded in Path messages sent downstream. 804 Path messages are sent with the same source and destination 805 addresses as the data, so that they will be routed correctly 806 through non-RSVP clouds (see Section 2.9). On the other hand, 807 Resv messages are sent hop-by-hop; each RSVP-speaking node 808 forwards a Resv message to the unicast address of a previous RSVP 809 hop. 811 2.2 Port Usage 813 An RSVP session is normally defined by the triple: (DestAddress, 814 ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port 815 field (i.e., a 16-bit quantity carried at octet offset +2 in the 816 transport header). DstPort may be omitted (set to zero) if the 817 ProtocolId specifies a protocol that does not have a destination 818 port field in the format used by UDP and TCP. 820 RSVP allows any value for ProtocolId. However, end-system 821 implementations of RSVP may know about certain values for this 822 field, and in particular the values for UDP and TCP (17 and 6, 823 respectively). An end system may give an error to an application 824 that either: 826 o specifies a non-zero DstPort for a protocol that does not 827 have UDP/TCP-like ports, or 829 o specifies a zero DstPort for a protocol that does have 830 UDP/TCP-like ports. 832 Filter specs and sender templates specify the pair: (SrcAddress, 833 SrcPort), where SrcPort is a UDP/TCP source port field (i.e., a 834 16-bit quantity carried at octet offset +0 in the transport 835 header). SrcPort may be omitted (set to zero) in certain cases. 837 The following rules hold for the use of zero DstPort and/or 838 SrcPort fields in RSVP. 840 1. Destination ports must be consistent. 842 Path state and reservation state for the same DestAddress and 843 ProtocolId must each have DstPort values that are all zero or 844 all non-zero. Violation of this condition in a node is a 845 "Conflicting Dest Port" error. 847 2. Destination ports rule. 849 If DstPort in a session definition is zero, all SrcPort 850 fields used for that session must also be zero. The 851 assumption here is that the protocol does not have UDP/TCP- 852 like ports. Violation of this condition in a node is a 853 "Conflicting Src Port" error. 855 3. Source Ports must be consistent. 857 A sender host must not send path state both with and without 858 a zero SrcPort. Violation of this condition is an "Ambiguous 859 Path" error. 861 2.3 Merging Flowspecs 863 As noted earlier, a single physical interface may receive multiple 864 reservation requests from different next hops for the same session 865 and with the same filter spec, but RSVP should install only one 866 reservation on that interface. The installed reservation should 867 have an effective flowspec that is the "largest" of the flowspecs 868 requested by the different next hops. Similarly, a Resv message 869 forwarded to a previous hop should carry a flowspec that is the 870 "largest" of the flowspecs requested by the different next hops 871 (however, in certain cases the "smallest" is taken rather than the 872 largest, see Section 3.4). These cases both represent flowspec 873 merging. 875 Flowspec merging requires calculation of the "largest" of a set of 876 flowspecs. However, since flowspecs are generally multi- 877 dimensional vectors (they may contain both Tspec and Rspec 878 components, each of which may itself be multi-dimensional), it may 879 not be possible to strictly order two flowspecs. For example, if 880 one request calls for a higher bandwidth and another calls for a 881 tighter delay bound, one is not "larger" than the other. In such 882 a case, instead of taking the larger, RSVP must compute and use a 883 third flowspec that is at least as large as each. Mathematically, 884 RSVP merges flowspecs using the "least upper bound" (LUB) instead 885 of the maximum. Typically, the LUB is calculated by creating a 886 new flowspec whose components are individually either the max or 887 the min of corresponding components of the flowspecs being merged. 888 For example, the LUB of Tspecs defined by token bucket parameters 889 is computed by taking the maximums of the bucket size and the rate 890 parameters. In some cases, the GLB (Greatest Lower Bound) is 891 required instead of the LUB; this simply interchanges max and min 892 operations. 894 The following steps are used to calculate the effective flowspec 895 (Te, Re) to be installed on an interface. Here Te is the 896 effective Tspec and Re is the effective Rspec. As an example, 897 consider interface (d) in Figure 9. 899 1. RSVP calculates the LUB of the flowspecs that arrived in Resv 900 messages from different next hops (e.g., D and D') but the 901 same outgoing interface (d). 903 This calculation yields a flowspec that is opaque to RSVP but 904 actually consists of the pair (Re, Resv_Te), where Re is the 905 LUB of the Rspecs and Resv_Te is the LUB of the Tspecs from 906 the Resv messages. 908 2. RSVP calculates Path_Te, the sum of all Tspecs that were 909 supplied in Path messages from different previous hops (e.g., 910 some or all of A, B, and B' in Figure 9). 912 3. RSVP passes these two results, (Re, Resv_Te) and Path_Te, to 913 traffic control. Traffic control will compute the "minimum" 914 of Path_Te and Resv_Te in an appropriate, perhaps service- 915 dependent, manner. 917 The definition and implementation of the rules for comparing 918 flowspecs, calculating LUBs and GLBs, and summing Tspecs are 919 outside the definition of RSVP. Section 3.10.4 shows generic 920 calls that an RSVP daemon could use for these functions. 922 2.4 Soft State 924 RSVP takes a "soft state" approach to managing the reservation 925 state in routers and hosts. RSVP soft state is created and 926 periodically refreshed by Path and Resv messages. The state is 927 deleted if no matching refresh messages arrive before the 928 expiration of a "cleanup timeout" interval. State may also be 929 deleted by an explicit "teardown" message, described in the next 930 section. At the expiration of each "refresh timeout" period and 931 after a state change, RSVP scans its state to build and forward 932 Path and Resv refresh messages to succeeding hops. 934 Path and Resv messages are idempotent. When a route changes, the 935 next Path message will initialize the path state on the new route, 936 and future Resv messages will establish reservation state there; 937 the state on the now-unused segment of the route will time out. 938 Thus, whether a message is "new" or a "refresh" is determined 939 separately at each node, depending upon the existence of state at 940 that node. 942 RSVP sends its messages as IP datagrams with no reliability 943 enhancement. Periodic transmission of refresh messages by hosts 944 and routers is expected to handle the occasional loss of an RSVP 945 message. If the effective cleanup timeout is set to K times the 946 refresh timeout period, then RSVP can tolerate K-1 successive RSVP 947 packet losses without falsely deleting state. the network traffic 948 control mechanism should be statically configured to grant some 949 minimal bandwidth for RSVP messages to protect them from 950 congestion losses. 952 The state maintained by RSVP is dynamic; to change the set of 953 senders Si or to change any QoS request, a host simply starts 954 sending revised Path and/or Resv messages. The result will be an 955 appropriate adjustment in the RSVP state in all nodes along the 956 path; unused state will time out if it is not explicitly torn 957 down. 959 In steady state, refreshing is performed hop-by-hop, to allow 960 merging. When the received state differs from the stored state, 961 the stored state is updated. If this update results in 962 modification of state to be forwarded in refresh messages, these 963 refresh messages must be generated and forwarded immediately, so 964 that state changes can be propagated end-to-end without delay. 965 However, propagation of a change stops when and if it reaches a 966 point where merging causes no resulting state change. This 967 minimizes RSVP control traffic due to changes and is essential for 968 scaling to large multicast groups. 970 State that is received through a particular interface I* should 971 never be forwarded out the same interface. Conversely, state that 972 is forwarded out interface I* must be computed using only state 973 that arrived on interfaces different from I*. A trivial example 974 of this rule is illustrated in Figure 10, which shows a transit 975 router with one sender and one receiver on each interface (and 976 assumes one next/previous hop per interface). Interfaces (a) and 977 (c) serve as both outgoing and incoming interfaces for this 978 session. Both receivers are making wildcard-style reservations, 979 in which the Resv messages are forwarded to all previous hops for 980 senders in the group, with the exception of the next hop from 981 which they came. The result is independent reservations in the 982 two directions. 984 There is an additional rule governing the forwarding of Resv 985 messages: state from RESV messages received from outgoing 986 interface Io should be forwarded to incoming interface Ii only if 987 Path messages from Ii are forwarded to Io. 989 ________________ 990 a | | c 991 ( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) 992 |________________| 994 Send | Receive 995 | 996 WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) 997 | 998 Receive | Send 999 | 1000 WF( *{4B}) --> (a) | (c) --> WF( *{4B}) 1001 | 1002 Reserve on (a) | Reserve on (c) 1003 __________ | __________ 1004 | * {4B} | | | * {3B} | 1005 |__________| | |__________| 1006 | 1008 Figure 10: Independent Reservations 1010 2.5 Teardown 1012 Upon arrival, RSVP "teardown" messages remove path and reservation 1013 state immediately. Although it is not necessary to explicitly 1014 tear down an old reservation, we recommend that all end hosts send 1015 a teardown request as soon as an application finishes. 1017 There are two types of RSVP teardown message, PathTear and 1018 ResvTear. A PathTear message travels towards all receivers 1019 downstream from its point of initiation and deletes path state, as 1020 well as all dependent reservation state, along the way. An 1021 ResvTear message deletes reservation state and travels towards all 1022 senders upstream from its point of initiation. A PathTear 1023 (ResvTear) message may be conceptualized as a reversed-sense Path 1024 message (Resv message, respectively). 1026 A teardown request may be initiated either by an application in an 1027 end system (sender or receiver), or by a router as the result of 1028 state timeout or service preemption. Once initiated, a teardown 1029 request must be forwarded hop-by-hop without delay. A teardown 1030 message deletes the specified state in the node where it is 1031 received. As always, this state change will be propagated 1032 immediately to the next node, but only if there will be a net 1033 change after merging. As a result, an ResvTear message will prune 1034 the reservation state back (only) as far as possible. 1036 Like all other RSVP messages, teardown requests are not delivered 1037 reliably. The loss of a teardown request message will not cause a 1038 protocol failure because the unused state will eventually time out 1039 even though it is not explicitly deleted. If a teardown message 1040 is lost, the router that failed to receive that message will time 1041 out its state and initiate a new teardown message beyond the loss 1042 point. Assuming that RSVP message loss probability is small, the 1043 longest time to delete state will seldom exceed one refresh 1044 timeout period. 1046 It should be possible to tear down any subset of the established 1047 state. For path state, the granularity for teardown is a single 1048 sender. For reservation state, the granularity is an individual 1049 filter spec. For example, refer to Figure 7. Receiver R1 could 1050 send a ResvTear message for sender S2 only (or for any subset of 1051 the filter spec list), leaving S1 in place. 1053 A ResvTear message specifies the style and filters; any flowspec 1054 is ignored. Whatever flowspec is in place will be removed if all 1055 its filter specs are torn down. 1057 2.6 Errors 1059 There are two RSVP error messages, ResvErr and PathErr. PERR 1060 messages are very simple; they are simply sent upstream to the 1061 sender that created the error, and they do not change path state 1062 in the nodes though which they pass. There are only a few 1063 possible causes of path errors. 1065 However, there are a number of ways for a syntactically valid 1066 reservation request to fail at some node along the path. A node 1067 may also decide to preempt an established reservation. The 1068 handling of ResvErr messages is somewhat complex (Section 3.4). 1069 Since a request that fails may be the result of merging a number 1070 of requests, a reservation error must be reported to all of the 1071 responsible receivers. In addition, merging heterogeneous 1072 requests creates a potential difficulty known as the "killer 1073 reservation" problem, in which one request could deny service to 1074 another. There are actually two killer-reservation problems. 1076 1. The first killer reservation problem (KR-I) arises when there 1077 is already a reservation Q0 in place. If another receiver 1078 now makes a larger reservation Q1 > Q0, the result of merging 1079 Q0 and Q1 may be rejected by admission control in some 1080 upstream node. This must not deny service to Q0. 1082 The solution to this problem is simple: when admission 1083 control fails for a reservation request, any existing 1084 reservation is left in place. 1086 2. The second killer reservation problem (KR-II) is the 1087 converse: the receiver making a reservation Q1 is persistent 1088 even though Admission Control is failing for Q1 in some node. 1089 This must not prevent a different receiver from now 1090 establishing a smaller reservation Q0 that would succeed if 1091 not merged with Q1. 1093 To solve this problem, a ResvErr message establishes 1094 additional state, called "blockade state", in each node 1095 through which it passes. Blockade state in a node modifies 1096 the merging procedure to omit the offending flowspec (Q1 in 1097 the example) from the merge, allowing a smaller request to be 1098 forwarded and established. The Q1 reservation state is said 1099 to be "blockaded". Detailed rules are presented in Section 1100 3.4. 1102 A reservation request that fails Admission Control creates 1103 blockade state but is left in place in nodes downstream of the 1104 failure point. It has been suggested that these reservations 1105 downstream from the failure represent "wasted" reservations and 1106 should be timed out if not actively deleted. However, the 1107 downstream reservations are left in place, for the following 1108 reasons: 1110 o There are two possible reasons for a receiver persisting in a 1111 failed reservation: (1) it is polling for resource 1112 availability along the entire path, or (2) it wants to obtain 1113 the desired QoS along as much of the path as possible. 1114 Certainly in the second case, and perhaps in the first case, 1115 the receiver will want to hold onto the reservations it has 1116 made downstream from the failure. 1118 o If these downstream reservations were not retained, the 1119 responsiveness of RSVP to certain transient failures would be 1120 impaired. For example, suppose a route "flaps" to an 1121 alternate route that is congested, so an existing reservation 1122 suddenly fails, then quickly recovers to the original route. 1123 The blockade state in each downstream router must not remove 1124 the state or prevent its immediate refresh. 1126 o If we did not refresh the downstream reservations, they might 1127 time out, to be restored every Tb seconds (where Tb is the 1128 blockade state timeout interval). Such intermittent behavior 1129 might be very distressing for users. 1131 2.7 Confirmation 1133 To request a confirmation for its reservation request, a receiver 1134 Rj includes in the Resv message a confirmation-request object 1135 containing Rj's IP address. At each merge point, only the largest 1136 flowspec and any accompanying confirmation-request object is 1137 forwarded upstream. If the reservation request from Rj is equal 1138 to or smaller than the reservation in place on a node, its Resv 1139 are not forwarded further, and if the Resv included a 1140 confirmation-request object, a ResvConf message is sent back to 1141 Rj. If the confirmation request is forwarded, it is forwarded 1142 immediately, and no more than once for each request. 1144 This confirmation mechanism has the following consequences: 1146 o A new reservation request with a flowspec larger than any in 1147 place for a session will normally result in either a ResvErr 1148 or a ResvConf message back to the receiver from each sender. 1149 In this case, the ResvConf message will be an end-to-end 1150 confirmation. 1152 o The receipt of a ResvConf gives no guarantees. Assume the 1153 first two reservation requests from receivers R1 and R2 1154 arrive at the node where they are merged. R2, whose 1155 reservation was the second to arrive at that node, may 1156 receive a ResvConf from that node while R1's request has not 1157 yet propagated all the way to a matching sender and may still 1158 fail. Thus, R2 may receive a ResvConf although there is no 1159 end-to-end reservation in place; furthermore, R2 may receive 1160 a ResvConf followed by a ResvErr. 1162 2.8 Policy and Security 1164 RSVP-mediated QoS requests will result in particular user(s) 1165 getting preferential access to network resources. To prevent 1166 abuse, some form of back pressure on users is likely to be 1167 required. This back pressure might take the form of 1168 administrative rules, or of some form of real or virtual billing 1169 for the "cost" of a reservation. The form and contents of such 1170 back pressure is a matter of administrative policy that may be 1171 determined independently by each administrative domain in the 1172 Internet. 1174 Therefore, there is likely to be policy control as well as 1175 admission control over the establishment of reservations. As 1176 input to policy control, RSVP messages may carry "policy data". 1177 Policy data may include credentials identifying users or user 1178 classes, account numbers, limits, quotas, etc. Like flowspecs, 1179 policy data will be opaque to RSVP, which will simply pass it to a 1180 "Local Policy Module" (LPM) for a decision. 1182 To protect the integrity of the policy control mechanisms, it may 1183 be necessary to ensure the integrity of RSVP messages against 1184 corruption or spoofing, hop by hop. For this purpose, RSVP 1185 messages may carry integrity objects that can be created and 1186 verified by neighbor RSVP-capable nodes. These objects use a 1187 keyed cryptographic digest technique and assume that RSVP 1188 neighbors share a secret [Baker96]. 1190 User policy data in reservation request messages presents a 1191 scaling problem. When a multicast group has a large number of 1192 receivers, it will be impossible or undesirable to carry all 1193 receivers' policy data upstream to the sender(s). The policy data 1194 will have to be administratively merged at places near the 1195 receivers, to avoid excessive policy data. Administrative merging 1196 implies checking the user credentials and accounting data and then 1197 substituting a token indicating the check has succeeded. A chain 1198 of trust established using integrity fields will allow upstream 1199 nodes to accept these tokens. 1201 In summary, different administrative domains in the Internet may 1202 have different policies regarding their resource usage and 1203 reservation. The role of RSVP is to carry policy data associated 1204 with each reservation to the network as needed. Note that the 1205 merge points for policy data are likely to be at the boundaries of 1206 administrative domains. It may be necessary to carry accumulated 1207 and unmerged policy data upstream through multiple nodes before 1208 reaching one of these merge points. 1210 This document does not specify the contents of policy data, the 1211 structure of an LPM, or any generic policy models. These will be 1212 defined in the future. 1214 2.9 Non-RSVP Clouds 1216 It is impossible to deploy RSVP (or any new protocol) at the same 1217 moment throughout the entire Internet. Furthermore, RSVP may 1218 never be deployed everywhere. RSVP must therefore provide correct 1219 protocol operation even when two RSVP-capable routers are joined 1220 by an arbitrary "cloud" of non-RSVP routers. Of course, an 1221 intermediate cloud that does not support RSVP is unable to perform 1222 resource reservation. However, if such a cloud has sufficient 1223 capacity, it may still provide useful realtime service. 1225 RSVP is designed to operate correctly through such a non-RSVP 1226 cloud. Both RSVP and non-RSVP routers forward Path messages 1227 towards the destination address using their local uni-/multicast 1228 routing table. Therefore, the routing of Path messages will be 1229 unaffected by non-RSVP routers in the path. When a Path message 1230 traverses a non-RSVP cloud, it carries to the next RSVP-capable 1231 node the IP address of the last RSVP-capable router before 1232 entering the cloud. An Resv message is then forwarded directly to 1233 the next RSVP-capable router on the path(s) back towards the 1234 source. 1236 Even though RSVP operates correctly through a non-RSVP cloud, the 1237 non-RSVP-capable nodes will in general perturb the QoS provided to 1238 a receiver. Therefore, RSVP tries to inform the receiver when 1239 there are non-RSVP-capable hops in the path to a given sender, by 1240 means of two flag bits in the SESSION object of a Path message; 1241 see Section 3.7 and Appendix A. 1243 Some topologies of RSVP routers and non-RSVP routers can cause 1244 Resv messages to arrive at the wrong RSVP-capable node, or to 1245 arrive at the wrong interface of the correct node. An RSVP daemon 1246 must be prepared to handle either situation. If the destination 1247 address does not match any local interface and the message is not 1248 a Path or PathTear, the message must be forwarded without further 1249 processing by this node. When a Resv message does arrive at the 1250 addressed node, the IP destination address (or the LIH, defined 1251 later) must be used to determine the interface to receive the 1252 reservation. 1254 2.10 Host Model 1256 Before a session can be created, the session identification, 1257 comprised of DestAddress, ProtocolId, and perhaps the generalized 1258 destination port, must be assigned and communicated to all the 1259 senders and receivers by some out-of-band mechanism. When an RSVP 1260 session is being set up, the following events happen at the end 1261 systems. 1263 H1 A receiver joins the multicast group specified by 1264 DestAddress, using IGMP. 1266 H2 A potential sender starts sending RSVP Path messages to the 1267 DestAddress. 1269 H3 A receiver application receives a Path message. 1271 H4 A receiver starts sending appropriate Resv messages, 1272 specifying the desired flow descriptors. 1274 H5 A sender application receives a Resv message. 1276 H6 A sender starts sending data packets. 1278 There are several synchronization considerations. 1280 o H1 and H2 may happen in either order. 1282 o Suppose that a new sender starts sending data (H6) but there 1283 are no multicast routes because no receivers have joined the 1284 group (H1). Then the data will be dropped at some router 1285 node (which node depends upon the routing protocol) until 1286 receivers(s) appear. 1288 o Suppose that a new sender starts sending Path messages (H2) 1289 and data (H6) simultaneously, and there are receivers but no 1290 Resv messages have reached the sender yet (e.g., because its 1291 Path messages have not yet propagated to the receiver(s)). 1292 Then the initial data may arrive at receivers without the 1293 desired QoS. The sender could mitigate this problem by 1294 awaiting arrival of the first Resv message (H5); however, 1295 receivers that are farther away may not have reservations in 1296 place yet. 1298 o If a receiver starts sending Resv messages (H4) before 1299 receiving any Path messages (H3), RSVP will return error 1300 messages to the receiver. 1302 The receiver may simply choose to ignore such error messages, 1303 or it may avoid them by waiting for Path messages before 1304 sending Resv messages. 1306 A specific application program interface (API) for RSVP is not 1307 defined in this protocol spec, as it may be host system dependent. 1308 However, Section 3.10.1 discusses the general requirements and 1309 outlines a generic interface. 1311 3. RSVP Functional Specification 1313 3.1 RSVP Message Formats 1315 An RSVP message consists of a common header, followed by a body 1316 consisting of a variable number of variable-length, typed " 1317 objects". The following subsections define the formats of the 1318 common header, the standard object header, and each of the RSVP 1319 message types. 1321 For each RSVP message type, there is a set of rules for the 1322 permissible choice of object types. These rules are specified 1323 using Backus-Naur Form (BNF) augmented with square brackets 1324 surrounding optional sub-sequences. The BNF implies an order for 1325 the objects in a message. However, in many (but not all) cases, 1326 object order makes no logical difference. An implementation 1327 should create messages with the objects in the order shown here, 1328 but accept the objects in any permissible order. 1330 3.1.1 Common Header 1332 0 1 2 3 1333 +-------------+-------------+-------------+-------------+ 1334 | Vers | Flags| Msg Type | RSVP Checksum | 1335 +-------------+-------------+-------------+-------------+ 1336 | Send_TTL | (Reserved) | RSVP Length | 1337 +-------------+-------------+-------------+-------------+ 1339 The fields in the common header are as follows: 1341 Vers: 4 bits 1343 Protocol version number. This is version 1. 1345 Flags: 4 bits 1347 0x01-0x08: Reserved 1349 No flag bits are defined yet. 1351 Msg Type: 8 bits 1353 1 = Path 1355 2 = Resv 1356 3 = PathErr 1358 4 = ResvErr 1360 5 = PathTear 1362 6 = ResvTear 1364 7 = ResvConf 1366 RSVP Checksum: 16 bits 1368 The one's complement of the one's complement sum of the 1369 message, with the checksum field replaced by zero for the 1370 purpose of computing the checksum. An all-zero value 1371 means that no checksum was transmitted. 1373 Send_TTL: 8 bits 1375 The IP TTL value with which the message was sent. See 1376 Section 3.7. 1378 RSVP Length: 16 bits 1380 The total length of this RSVP message in bytes, including 1381 the common header and the variable-length objects that 1382 follow. 1384 3.1.2 Object Formats 1386 Every object consists of one or more 32-bit words with a one- 1387 word header, in the following format: 1389 0 1 2 3 1390 +-------------+-------------+-------------+-------------+ 1391 | Length (bytes) | Class-Num | C-Type | 1392 +-------------+-------------+-------------+-------------+ 1393 | | 1394 // (Object contents) // 1395 | | 1396 +-------------+-------------+-------------+-------------+ 1398 An object header has the following fields: 1400 Length 1402 A 16-bit field containing the total object length in 1403 bytes. Must always be a multiple of 4, and at least 4. 1405 Class-Num 1407 Identifies the object class; values of this field are 1408 defined in Appendix A. Each object class has a name, 1409 which is always capitalized in this document. An RSVP 1410 implementation must recognize the following classes: 1412 NULL 1414 A NULL object has a Class-Num of zero, and its C-Type 1415 is ignored. Its length must be at least 4, but can 1416 be any multiple of 4. A NULL object may appear 1417 anywhere in a sequence of objects, and its contents 1418 will be ignored by the receiver. 1420 SESSION 1422 Contains the IP destination address (DestAddress), 1423 the IP protocol id, and some form of generalized 1424 destination port, to define a specific session for 1425 the other objects that follow. Required in every 1426 RSVP message. 1428 RSVP_HOP 1430 Carries the IP address of the RSVP-capable node that 1431 sent this message and a logical outgoing interface 1432 handle (LIH; see Section 3.2). This document refers 1433 to a RSVP_HOP object as a PHOP ("previous hop") 1434 object for downstream messages or as a NHOP (" next 1435 hop") object for upstream messages. 1437 TIME_VALUES 1439 Contains the value for the refresh period R used by 1440 the creator of the message; see 3.6. Required in 1441 every Path and Resv message. 1443 STYLE 1445 Defines the reservation style plus style-specific 1446 information that is not in FLOWSPEC or FILTER_SPEC 1447 objects. Required in every Resv message. 1449 FLOWSPEC 1450 Defines a desired QoS, in a Resv message. 1452 FILTER_SPEC 1454 Defines a subset of session data packets that should 1455 receive the desired QoS (specified by an FLOWSPEC 1456 object), in a Resv message. 1458 SENDER_TEMPLATE 1460 Contains a sender IP address and perhaps some 1461 additional demultiplexing information to identify a 1462 sender. Required in a Path message. 1464 SENDER_TSPEC 1466 Defines the traffic characteristics of a sender's 1467 data stream. Required in a Path message. 1469 ADSPEC 1471 Carries OPWA data, in a Path message. 1473 ERROR_SPEC 1475 Specifies an error in a PathErr, ResvErr, or a 1476 confirmation in a ResvConf message. 1478 POLICY_DATA 1480 Carries information that will allow a local policy 1481 module to decide whether an associated reservation is 1482 administratively permitted. May appear in Path, 1483 Resv, PathErr, or ResvErr message. 1485 INTEGRITY 1487 Carries cryptographic data to authenticate the 1488 originating node and to verify the contents of this 1489 RSVP message. The use of the INTEGRITY object is 1490 described in [Baker96]. 1492 SCOPE 1494 Carries an explicit list of sender hosts towards 1495 which the information in the message is to be 1496 forwarded. May appear in a Resv, ResvErr, or 1497 ResvTear message. See Section 3.3. 1499 RESV_CONFIRM 1501 Carries the IP address of a receiver that requested a 1502 confirmation. May appear in a Resv or ResvConf 1503 message. 1505 C-Type 1507 Object type, unique within Class-Num. Values are defined 1508 in Appendix A. 1510 The maximum object content length is 65528 bytes. The Class- 1511 Num and C-Type fields may be used together as a 16-bit number 1512 to define a unique type for each object. 1514 The high-order two bits of the Class-Num is used to determine 1515 what action a node should take if it does not recognize the 1516 Class-Num of an object; see Section 3.9. 1518 3.1.3 Path Messages 1520 Each sender host periodically sends a Path message containing a 1521 description of each data stream it originates. The Path 1522 message travels from a sender to receiver(s) along the same 1523 path(s) used by the data packets. The IP source address of a 1524 Path message is an address of the sender it describes, while 1525 the destination address is the DestAddress for the session. 1526 These addresses assure that the message will be correctly 1527 routed through a non-RSVP cloud. 1529 The format of a Path message is as follows: 1531 ::= [ ] 1533 1535 1537 [ ... ] 1539 1541 ::= 1543 [ ] 1545 If the INTEGRITY object is present, it must immediately follow 1546 the common header. There are no other requirements on 1547 transmission order, although the above order is recommended. 1548 Any number of POLICY_DATA objects may appear. 1550 The PHOP (i.e., the RSVP_HOP) object of each Path message 1551 contains the previous hop address, i.e., the IP address of the 1552 interface through which the Path message was most recently 1553 sent. It also carries a logical interface handle (LIH). 1555 The SENDER_TEMPLATE object defines the format of data packets 1556 from this sender, while the SENDER_TSPEC object specifies the 1557 traffic characteristics of the flow. Optionally, there may be 1558 an ADSPEC object carrying advertising (OPWA) data. 1560 Each RSVP-capable node along the path(s) captures a Path 1561 message and processes it to create path state for the sender 1562 defined by the SENDER_TEMPLATE and SESSION objects. Any 1563 POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in 1564 the path state. If an error is encountered while processing a 1565 Path message, a PathErr message is sent to the originating 1566 sender of the Path message. PATH messages must satisfy the 1567 rules on SrcPort and DstPort in Section 2.2. 1569 Periodically, the RSVP daemon at a node scans the path state to 1570 create new Path messages to forward towards the receiver(s). 1571 Each message contains a sender descriptor defining one sender, 1572 and carries the original sender's IP address as its IP source 1573 address. Path messages eventually reach the applications on 1574 all receivers; however, they are not looped back to a receiver 1575 running in the same application process as the sender. 1577 The RSVP daemon forwards Path messages, and replicates them as 1578 required, using routing information it obtains from the 1579 appropriate uni-/multicast routing daemon. The route depends 1580 upon the session DestAddress, and for some routing protocols 1581 also upon the source (sender's IP) address. The routing 1582 information generally includes the list of none or more 1583 outgoing interfaces to which the Path message to be forwarded. 1584 Because each outgoing interface has a different IP address, the 1585 Path messages sent out different interfaces contain different 1586 PHOP addresses. In addition, ADSPEC objects carried in Path 1587 messages will also generally differ for different outgoing 1588 interfaces. 1590 Some IP multicast routing protocols (e.g., DVMRP, PIM, and 1591 MOSPF) also keep track of the expected incoming interface for 1592 each source host to a multicast group. Whenever this 1593 information is available, RSVP should check the incoming 1594 interface of each Path message and do special handling of those 1595 messages Path messages that have arrived on the wrong 1596 interface; see Section 3.8. 1598 3.1.4 Resv Messages 1600 Resv messages carry reservation requests hop-by-hop from 1601 receivers to senders, along the reverse paths of data flows for 1602 the session. The IP destination address of a Resv message is 1603 the unicast address of a previous-hop node, obtained from the 1604 path state. The IP source address is an address of the node 1605 that sent the message. 1607 The Resv message format is as follows: 1609 ::= [ ] 1611 1613 1615 [ ] [ ] 1617 [ ... ] 1619