idnits 2.17.1 draft-ietf-rsvp-spec-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 43 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 854 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 (February 12, 1996) is 10301 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: 'Appendix C' is mentioned on line 1352, but not defined == Missing Reference: 'S4' is mentioned on line 2110, but not defined == Missing Reference: 'S1' is mentioned on line 2106, but not defined == Missing Reference: 'S2' is mentioned on line 2110, but not defined == Missing Reference: 'S3' is mentioned on line 2110, but not defined == Missing Reference: 'ADSPEC' is mentioned on line 3309, but not defined == Missing Reference: 'RA' is mentioned on line 4735, but not defined == Missing Reference: 'Note 1' is mentioned on line 4741, but not defined == Missing Reference: 'Note 2' is mentioned on line 4745, but not defined == Missing Reference: 'Note 3' is mentioned on line 4748, but not defined == Unused Reference: 'CSZ92' is defined on line 4795, but no explicit reference was found in the text == Unused Reference: 'Partridge92' is defined on line 4806, but no explicit reference was found in the text == Unused Reference: 'IServ93' is defined on line 4809, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-rsvp-md5-01 ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. 'ISInt93') -- Possible downref: Non-RFC (?) normative reference: ref. 'CSZ92' -- Possible downref: Non-RFC (?) normative reference: ref. 'FJ94' == Outdated reference: A later version (-03) exists of draft-katz-router-alert-01 ** Downref: Normative reference to an Informational RFC: RFC 1363 (ref. 'Partridge92') -- Possible downref: Non-RFC (?) normative reference: ref. 'IServ93' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP93' == Outdated reference: A later version (-02) exists of draft-ietf-intserv-svc-template-00 ** Downref: Normative reference to an Informational draft: draft-ietf-intserv-svc-template (ref. 'ServTempl95a') -- Possible downref: Non-RFC (?) normative reference: ref. 'Shenker94' Summary: 11 errors (**), 0 flaws (~~), 18 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Braden, Ed. 3 Expiration: August 1996 ISI 4 File: draft-ietf-rsvp-spec-09.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 February 12, 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 linebreak "1id-abstracts.txt" listing contained in the Internet- 33 Drafts Shadow Directories on ds.internic.net (US East Coast), 34 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au 35 (Pacific Rim). 37 Abstract 39 This memo describes version 1 of RSVP, a resource reservation setup 40 protocol designed for an integrated services Internet. RSVP provides 41 receiver-initiated setup of resource reservations for multicast or 42 unicast data flows, with good scaling and robustness properties. 44 Table of Contents 46 1. Introduction ........................................................4 47 1.1 Data Flows ......................................................7 48 1.2 Reservation Model ...............................................8 49 1.3 Reservation Styles ..............................................10 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 Automatic RSVP Tunneling ........................................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 .....................................................89 75 APPENDIX A. Object Definitions .........................................90 76 APPENDIX B. Error Codes and Values .....................................106 77 APPENDIX C. UDP Encapsulation ..........................................111 78 What's Changed 80 The most important changes in this document from the rsvp-spec-08 draft 81 are: 83 o The handling of reservation errors has been fundamentally 84 changed, to prevent the "second killer reservation problem". 85 A new kind of state has been introduced into a node, 86 "blockade state", which is created by a RERR message with 87 Error Code = 01, and which controls the merging process for 88 generating reservation refresh messages [Sections 2.6 and 89 3.4]. 91 o RSVP now carries two flag bits in the SESSION object to 92 indicate to a receiver whether there are non-RSVP-capable 93 nodes along the path to a given sender [Sections 2.9 and 94 3.7]. 96 o The optional INTEGRITY object is now specified to immediately 97 follow the common header and to appear in every fragment 98 [Section 3.1]. 100 o There are now two flag bits in an ERROR_SPEC object: InPlace 101 and NotGuilty [Section 3.10]. 103 o The text now states that implementations should be as 104 permissive as possible in accepting objects in any order 105 within a message (and required ordering is specified), but 106 they should follow the BNF-implied order in creating a 107 message. 109 o The text now states that IP fragmentation of data packets is 110 generally not possible when RSVP is in use, since the TCP/UDP 111 port fields may be required for classification [Section 1.2]. 113 o The rules for handling an unrecognized object class are 114 changed to include a third possibility: ignore and do not 115 forward the object [Section 3.9]. 117 o All generic Traffic Control calls are modified to include an 118 interface specification, allowing the Thandle to be 119 interface-specific [Section 3.10.2]. 121 o Disabling an interface for RSVP is allowed [Section 3.10.3]. 123 1. Introduction 125 This document defines RSVP, a resource reservation setup protocol 126 designed for an integrated services Internet [RSVP93,ISInt93]. 128 The RSVP protocol is used by a host, on behalf of an application data 129 stream, to request a specific quality of service (QoS) from the 130 network. The RSVP protocol is also used by routers to deliver QoS 131 requests to all nodes along the path(s) of the data stream and to 132 establish and maintain state to provide the requested service. RSVP 133 requests will generally, although not necessarily, result in 134 resources being reserved along the data path. 136 RSVP requests resources for simplex data streams, i.e., it requests 137 resources in only one direction. Therefore, RSVP treats a sender as 138 logically distinct from a receiver, although the same application 139 process may act as both a sender and a receiver at the same time. 140 RSVP operates on top of IP (either IPv4 or IP6), occupying the place 141 of a transport protocol in the protocol stack. However, RSVP does 142 not transport application data but is rather an Internet control 143 protocol, like ICMP, IGMP, or routing protocols. Like the 144 implementations of routing and management protocols, an 145 implementation of RSVP will typically execute in the background, not 146 in the data forwarding path, as shown in Figure 1. 148 RSVP is not itself a routing protocol; RSVP is designed to operate 149 with current and future unicast and multicast routing protocols. An 150 RSVP daemon consults the local routing database(s) to obtain routes. 151 In the multicast case, for example, a host sends IGMP messages to 152 join a multicast group and then sends RSVP messages to reserve 153 resources along the delivery path(s) of that group. Routing 154 protocols determine where packets get forwarded; RSVP is only 155 concerned with the QoS of those packets that are forwarded in 156 accordance with routing. 158 HOST ROUTER 160 _________________________ RSVP _____________________________ 161 | | .--------------. | 162 | _______ ______ | / | ________ . ______ | 163 | | | | | | / || | . | | | RSVP 164 | |Applic-| | RSVP <----/ ||Routing | -> RSVP <----------> 165 | | App <----->daemon| | ||Protocol| |daemon| _____ | 166 | | | | | | || daemon <----> >|Polcy|| 167 | |_______| |___.__| | ||_ ._____| |__.__.||Cntrl|| 168 | | | | | | | .|_____|| 169 |===|===============|=====| |===|=============|====.======| 170 | data .........| | | | ...........| .____ | 171 | | ____V_ ____V____ | | _V__V_ _____V___ |Admis|| 172 | | |Class-| | || data | |Class-| | ||Cntrl|| 173 | |=> ifier|=> Packet ============> ifier|==> Packet ||_____|| data 174 | |______| |Scheduler|| | |______| |Scheduler|===========> 175 | |_________|| | |_________| | 176 |_________________________| |_____________________________| 178 Figure 1: RSVP in Hosts and Routers 180 Each node that is capable of resource reservation passes incoming 181 data packets through a "packet classifier", which determines the 182 route and the QoS class for each packet. For each outgoing 183 interface, a " packet scheduler" then makes forwarding decisions for 184 each packet to achieve the promised QoS on the particular link-layer 185 medium used by that interface. 187 If the link-layer medium is QoS-active, i.e., if it has its own QoS 188 management capability, then the packet scheduler is responsible for 189 negotiation with the link layer to obtain the QoS requested by RSVP. 190 This mapping to the link layer QoS may be accomplished in a number of 191 possible ways; the details will be medium-dependent. On a QoS- 192 passive medium such as a leased line, the scheduler itself allocates 193 packet transmission capacity. The scheduler may also allocate other 194 system resources such as CPU time or buffers. 196 In order to efficiently accommodate heterogeneous receivers and 197 dynamic group membership, RSVP makes receivers responsible for 198 requesting QoS [RSVP93]. A QoS request, which typically originates 199 from a receiver host application, is passed to the local RSVP 200 implementation, shown as a daemon process in Figure 1. The RSVP 201 protocol then carries the request to all the nodes (routers and 202 hosts) along the reverse data path(s) to the data source(s). 204 At each node, the RSVP daemon communicates with two local decision 205 modules, "admission control" and "policy control". Admission control 206 determines whether the node has sufficient available resources to 207 supply the requested QoS. Policy control determines whether the user 208 has administrative permission to make the reservation. If both 209 checks succeeds, the RSVP daemon sets parameters in the packet 210 classifier and scheduler to obtain the desired QoS. If either check 211 fails, the RSVP program returns an error notification to the 212 application process that originated the request. We refer to the 213 packet classifier, packet scheduler, and admission control components 214 as "traffic control". 216 RSVP is designed to scale well for very large multicast groups. 217 Since both the membership of a large group and the topology of large 218 multicast trees are likely to change with time, the RSVP design 219 assumes that router state for traffic control will be built and 220 destroyed incrementally. For this purpose, RSVP uses "soft state" in 221 the routers. That is, RSVP sends periodic refresh messages to 222 maintain the state along the reserved path(s); in absence of 223 refreshes, the state will automatically time out and be deleted. 225 RSVP protocol mechanisms provide a general facility for creating and 226 maintaining distributed reservation state across a mesh of multicast 227 or unicast delivery paths. RSVP transfers reservation parameters as 228 opaque data (except for certain well-defined operations on the data), 229 which it simply passes to traffic control for interpretation. 230 Although the RSVP protocol mechanisms are largely independent of the 231 encoding of these parameters, the encodings must be defined in the 232 reservation model that is presented to an application; see Appendix A 233 for more details. 235 In summary, RSVP has the following attributes: 237 o RSVP makes resource reservations for both unicast and many-to- 238 many multicast applications, adapting dynamically to changing 239 group membership as well as changing routes. 241 o RSVP is simplex, i.e., it reserves for a data flow in one 242 direction only. 244 o RSVP is receiver-oriented, i.e., the receiver of a data flow 245 initiates and maintains the resource reservation used for that 246 flow. 248 o RSVP maintains "soft state" in the routers, providing graceful 249 support for dynamic membership changes and automatic adaptation 250 to routing changes. 252 o RSVP provides several reservation models or "styles" (defined 253 below) to fit a variety of applications. 255 o RSVP provides transparent operation through routers that do not 256 support it. 258 Further discussion on the objectives and general justification for 259 RSVP design are presented in [RSVP93,ISInt93]. 261 The remainder of this section describes the RSVP reservation 262 services. Section 2 presents an overview of the RSVP protocol 263 mechanisms. Section 3 contains the functional specification of RSVP, 264 while Section 4 presents explicit message processing rules. Appendix 265 A defines the variable-length typed data objects used in the RSVP 266 protocol. Appendix B defines error codes and values. Appendix C 267 defines an extension for UDP encapsulation of RSVP messages. 268 Finally, some experimental RSVP features are documented in Appendix D 269 for future reference. 271 1.1 Data Flows 273 RSVP defines a "session" as a data flow with a particular 274 destination and transport-layer protocol. The destination of a 275 session is generally defined by DestAddress, the IP destination 276 address of the data packets, and perhaps by DstPort, a 277 "generalized destination port", i.e., some further demultiplexing 278 point in the transport or application protocol layer. RSVP treats 279 each session independently, and this document often assumes the 280 qualification "for the same session". 282 DestAddress is a group address for multicast delivery or the 283 unicast address of a single receiver. DstPort could be defined by 284 a UDP/TCP destination port field, by an equivalent field in 285 another transport protocol, or by some application-specific 286 information. Although the RSVP protocol is designed to be easily 287 extensible for greater generality, the present version supports 288 only UDP/TCP ports as generalized ports. 290 Note that it is not strictly necessary to include ports in the 291 session definition when DestAddress is multicast, since different 292 sessions can always have different multicast addresses. However, 293 destination ports are necessary to allow more than one unicast 294 session to the same receiver host. 296 Figure 2 illustrates the flow of data packets in a single RSVP 297 session, assuming multicast data distribution. The arrows 298 indicate data flowing from senders S1 and S2 to receivers R1, R2, 299 and R3, and the cloud represents the distribution mesh created by 300 multicast routing. Multicast distribution forwards a copy of each 301 data packet from a sender Si to every receiver Rj; a unicast 302 distribution session has a single receiver R. Each sender Si may 303 be running in a unique Internet host, or a single host may contain 304 multiple senders, distinguished by generalized source ports. 306 Senders Receivers 307 _____________________ 308 ( ) ===> R1 309 S1 ===> ( Multicast ) 310 ( ) ===> R2 311 ( distribution ) 312 S2 ===> ( ) 313 ( by Internet ) ===> R3 314 (_____________________) 316 Figure 2: Multicast Distribution Session 318 For unicast transmission, there will be a single destination host 319 but there may be multiple senders; RSVP can set up reservations 320 for multipoint-to-single-point transmission. 322 1.2 Reservation Model 324 An elementary RSVP reservation request consists of a "flowspec" 325 together with a "filter spec"; this pair is called a "flow 326 descriptor". The flowspec specifies a desired QoS. The filter 327 spec, together with a session specification, defines the set of 328 data packets -- the "flow" -- to receive the QoS defined by the 329 flowspec. The flowspec is used to set parameters to the node's 330 packet scheduler (assuming that admission control succeeds), while 331 the filter spec is used to set parameters in the packet 332 classifier. Data packets that are addressed to a particular 333 session but do not match any of the filter specs for that session 334 are handled as best-effort traffic. 336 Note that the action to control QoS occurs at the place where the 337 data enters the medium, i.e., at the upstream end of the link, 338 although an RSVP reservation request originates from receiver(s) 339 downstream. In this document, we define the directional terms 340 "upstream" vs. "downstream", "previous hop" vs. "next hop", and 341 "incoming interface" vs "outgoing interface" with respect to the 342 direction of data flow. 344 The flowspec in a reservation request will generally include a 345 service class and two sets of numeric parameters: (1) an "Rspec" 346 (R for `reserve') that defines the desired QoS, and (2) a "Tspec" 347 (T for `traffic') that describes the data flow. The formats and 348 contents of Tspecs and Rspecs are determined by the integrated 349 service model [ServTempl95a], and are generally opaque to RSVP. 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 RSVP reservation request messages originate at receivers and are 370 passed upstream towards the sender(s). At each intermediate node, 371 two general actions are taken on the request. 373 1. Make a reservation 375 The request is passed to admission control and policy 376 control. If either test fails, the reservation is rejected 377 and RSVP returns an error message to the appropriate 378 receiver(s). If both succeed, the node uses the flowspec to 379 set up the packet scheduler for the desired QoS and the 380 filter spec to set the packet classifier to select the 381 appropriate data packets. 383 2. Forward the request upstream 385 The reservation request is propagated upstream towards the 386 appropriate senders. The set of sender hosts to which a 387 given reservation request is propagated is called the "scope" 388 of that request. 390 The reservation request that a node forwards upstream may differ 391 from the request that it received from downstream, for two 392 reasons. First, it is possible in theory for the traffic control 393 mechanism to modify the flowspec hop-by-hop, although none of the 394 currently defined services does so. Second, reservations for the 395 same sender, or the same set of senders, from different downstream 396 branches of the multicast tree(s) are "merged" as reservations 397 travel upstream; a node forwards upstream only the reservation 398 request with the "maximum" flowspec. 400 When a receiver originates a reservation request, it can also 401 request a confirmation message to indicate that its request was 402 (probably) installed in the network. A successful reservation 403 request propagates upstream along the multicast tree until it 404 reaches a point where an existing reservation is equal or greater 405 than that being requested. At that point, the arriving request is 406 merged with the reservation in place, and need not be forwarded 407 further, and the node may then send a reservation confirmation 408 message back to the receiver. Note that the receipt of a 409 confirmation is only a high-probability indication, not a 410 guarantee, that the requested service is in place all the way to 411 the sender(s), as explained in Section 2.7. 413 The basic RSVP reservation model is "one pass": a receiver sends a 414 reservation request upstream, and each node in the path either 415 accepts or rejects the request. This scheme provides no easy way 416 for a receiver to find out the resulting end-to-end service. 417 Therefore, RSVP supports an enhancement to one-pass service known 418 as "One Pass With Advertising" (OPWA) [Shenker94]. With OPWA, 419 RSVP control packets are sent downstream, following the data 420 paths, to gather information that may be used to predict the end- 421 to-end QoS. The results ("advertisements") are delivered by RSVP 422 to the receiver hosts and perhaps to the receiver applications. 423 The advertisements may then be used by the receiver to construct, 424 or to dynamically adjust, an appropriate reservation request. 426 1.3 Reservation Styles 428 A reservation request includes a set of options, which are 429 collectively called the reservation "style". 431 One reservation option concerns the treatment of reservations for 432 different senders within the same session: establish a "distinct" 433 reservation for each upstream sender, or else make a single 434 reservation that is "shared" among all packets of selected 435 senders. 437 Another reservation option controls the selection of senders: an " 438 explicit" list of all selected senders, or a "wildcard" that 439 implicitly selects all the senders to the session. In an explicit 440 sender-selection reservation, each filter spec must match exactly 441 one sender, while in a wildcard sender-selection no filter spec is 442 needed. 444 Sender || Reservations: 445 Selection || Distinct | Shared 446 _________||__________________|____________________ 447 || | | 448 Explicit || Fixed-Filter | Shared-Explicit | 449 || (FF) style | (SE) Style | 450 __________||__________________|____________________| 451 || | | 452 Wildcard || (None defined) | Wildcard-Filter | 453 || | (WF) Style | 454 __________||__________________|____________________| 456 Figure 3: Reservation Attributes and Styles 458 The styles currently defined are as follows (see Figure 3): 460 o Wildcard-Filter (WF) Style 462 The WF style implies the options: "shared" reservation and " 463 wildcard" sender selection. Thus, a WF-style reservation 464 creates a single reservation into which flows from all 465 upstream senders are mixed. This reservation may be thought 466 of as a shared "pipe", whose "size" is the largest of the 467 resource requests from all receivers, independent of the 468 number of senders using it. A WF-style reservation is 469 propagated upstream towards all sender hosts, and 470 automatically extends to new senders as they appear. 472 Symbolically, we can represent a WF-style reservation request 473 by: 475 WF( * {Q}) 477 where the asterisk represents wildcard sender selection and Q 478 represents the flowspec. 480 o Fixed-Filter (FF) Style 482 The FF style implies the options: "distinct" reservations and 483 "explicit" sender selection. Thus, an elementary FF-style 484 reservation request creates a distinct reservation for data 485 packets from a particular sender, not sharing them with other 486 senders' packets for the same session. 488 The total reservation on a link for a given session is the 489 total of the FF reservations for all requested senders. On 490 the other hand, FF reservations requested by different 491 receivers Rj but selecting the same sender Si must be merged 492 to share a single reservation. 494 Symbolically, we can represent an elementary FF reservation 495 request by: 497 FF( S{Q}) 499 where S is the selected sender and Q is the corresponding 500 flowspec; the pair forms a flow descriptor. RSVP allows 501 multiple elementary FF-style reservations to be requested at 502 the same time, using a list of flow descriptors: 504 FF( S1{Q1}, S2{Q2}, ...) 506 o Shared Explicit (SE) Style 508 The SE style implies the options: "shared" reservation and " 509 explicit" sender selection. Thus, an SE-style reservation 510 creates a single reservation into which flows from all 511 upstream senders are mixed. However, like the FF style, the 512 SE style allows a receiver to explicitly specify the set of 513 senders. 515 Symbolically, we can represent an SE reservation request by: 517 SE( (S1,S2,...){Q} ), 519 i.e., a flow descriptor composed of a flowspec Q and a list 520 of senders S1, S2, etc. 522 Both WF and SE styles create shared reservations, appropriate for 523 those multicast applications whose properties make it unlikely 524 that multiple data sources will transmit simultaneously. 525 Packetized audio is an example of an application suitable for 526 shared reservations; since a limited number of people talk at 527 once, each receiver might issue a WF or SE reservation request for 528 twice the bandwidth required for one sender (to allow some over- 529 speaking). On the other hand, the FF style, which creates 530 independent reservations for the flows from different senders, is 531 appropriate for video signals. 533 The RSVP rules disallow merging of shared reservations with 534 distinct reservations, since these modes are fundamentally 535 incompatible. They also disallow merging explicit sender 536 selection with wildcard sender selection, since this might produce 537 an unexpected service for a receiver that specified explicit 538 selection. As a result of these prohibitions, WF, SE, and FF 539 styles are all mutually incompatible. 541 It would seem possible to simulate the effect of a WF reservation 542 using the SE style. When an application asked for WF, the RSVP 543 daemon on the receiver host could use local path state to create 544 an equivalent SE reservation that explicitly listed all senders. 545 However, an SE reservation forces the packet classifier in each 546 node to explicitly select each sender in the list, while a WF 547 allows the packet classifier to simply "wild card" the sender 548 address and port. When there is a large list of senders, a WF 549 style reservation can therefore result in considerably less 550 overhead than an equivalent SE style reservation. For this 551 reason, both SE and WF are included in the protocol. 553 Other reservation options and styles may be defined in the future. 555 1.4 Examples of Styles 557 This section presents examples of each of the reservation styles 558 and shows the effects of merging. 560 Figure 4 illustrates a router with two incoming interfaces through 561 which data streams will arrive, labeled (a) and (b), and two 562 outgoing interfaces through which data will be forwarded, labeled 563 (c) and (d). This topology will be assumed in the examples that 564 follow. There are three upstream senders; packets from sender S1 565 (S2 and S3) arrive through previous hop (a) ((b), respectively). 566 There are also three downstream receivers; packets bound for R1 567 (R2 and R3) are routed via outgoing interface (c) ((d), 568 respectively). We furthermore assume that R2 and R3 arrive via 569 different next hops, e.g., via the two routers D and D' in Figure 570 9. This illustrates the effect of a non-RSVP cloud or a broadcast 571 LAN on interface (d). 573 In addition to the connectivity shown in 4, we must also specify 574 the multicast routes within this node. Assume first that data 575 packets from each Si shown in Figure 4 is routed to both outgoing 576 interfaces. Under this assumption, Figures 5, 6, and 7 illustrate 577 Wildcard-Filter, Fixed-Filter, and Shared-Explicit reservations, 578 respectively. 580 ________________ 581 (a)| | (c) 582 ( S1 ) ---------->| |----------> ( R1 ) 583 | Router | 584 (b)| | (d) 585 ( S2,S3 ) ------->| |----------> ( R2, R3 ) 586 |________________| 588 Figure 4: Router Configuration 590 For simplicity, these examples show flowspecs as one-dimensional 591 multiples of some base resource quantity B. The "Receive" column 592 shows the RSVP reservation requests received over outgoing 593 interfaces (c) and (d), and the "Reserve" column shows the 594 resulting reservation state for each interface. The "Send" 595 column shows the reservation requests that are sent upstream to 596 previous hops (a) and (b). In the "Reserve" column, each box 597 represents one reserved "pipe" on the outgoing link, with the 598 corresponding flow descriptor. 600 Figure 5, showing the WF style, illustrates the two possible 601 merging situations. Each of the two next hops on interface (d) 602 results in a separate RSVP reservation request, as shown. These 603 two requests are merged into the effective flowspec 3B, which is 604 used to make the reservation on interface (d). To forward the 605 reservation requests upstream, the reservations on the interfaces 606 (c) and (d) are merged; as a result, the larger flowspec 4B is 607 forwarded upstream to each previous hop. 609 | 610 Send | Reserve Receive 611 | 612 | _______ 613 WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) 614 | |_______| 615 | 616 -----------------------|---------------------------------------- 617 | _______ 618 WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) 619 | |_______| <- WF( *{2B} ) 621 Figure 5: Wildcard-Filter (WF) Reservation Example 623 Figure 6 shows Fixed-Filter (FF) style reservations. The flow 624 descriptors for senders S2 and S3, received from outgoing 625 interfaces (c) and (d), are packed into the request forwarded to 626 previous hop (b). On the other hand, the three different flow 627 descriptors for sender S1 are merged into the single request FF( 628 S1{4B} ), which is sent to previous hop (a). For each outgoing 629 interface, there is a separate reservation for each source that 630 has been requested, but this reservation is shared among all the 631 receivers that made the request. 633 | 634 Send | Reserve Receive 635 | 636 | ________ 637 FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} ) 638 | |________| 639 | | S2{5B} | 640 | |________| 641 ---------------------|--------------------------------------------- 642 | ________ 643 <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) 644 FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} ) 645 | | S3{B} | 646 | |________| 648 Figure 6: Fixed-Filter (FF) Reservation Example 650 Figure 7 shows an example of Shared-Explicit (SE) style 651 reservations. When SE-style reservations are merged, the 652 resulting filter spec is the union of the original filter specs. 654 | 655 Send | Reserve Receive 656 | 657 | ________ 658 SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} ) 659 | | {B} | 660 | |________| 661 ---------------------|--------------------------------------------- 662 | __________ 663 <- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} ) 664 SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} ) 665 | |__________| 667 Figure 7: Shared-Explicit (SE) Reservation Example 669 The three examples just shown assume that data packets from S1, 670 S2, and S3 are routed to both outgoing interfaces. The top part 671 of Figure 8 shows another routing assumption: data packets from S2 672 and S3 are not forwarded to interface (c), e.g., because the 673 network topology provides a shorter path for these senders towards 674 R1, not traversing this node. The bottom part of Figure 8 shows 675 WF style reservations under this assumption. Since there is no 676 route from (b) to (c), the reservation forwarded out interface (b) 677 considers only the reservation on interface (d). 679 _______________ 680 (a)| | (c) 681 ( S1 ) ---------->| >-----------> |----------> ( R1 ) 682 | - | 683 | - | 684 (b)| - | (d) 685 ( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 ) 686 |_______________| 688 Router Configuration 690 | 691 Send | Reserve Receive 692 | 693 | _______ 694 WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) 695 | |_______| 696 | 697 -----------------------|---------------------------------------- 698 | _______ 699 WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) 700 | |_______| <- WF( * {2B} 702 Figure 8: WF Reservation Example -- Partial Routing 704 2. RSVP Protocol Mechanisms 706 2.1 RSVP Messages 708 Previous Incoming Outgoing Next 709 Hops Interfaces Interfaces Hops 711 _____ _____________________ _____ 712 | | data --> | | data --> | | 713 | A |-----------| a c |--------------| C | 714 |_____| Path --> | | Path --> |_____| 715 <-- Resv | | <-- Resv _____ 716 _____ | ROUTER | | | | 717 | | | | | |--| D | 718 | B |--| data-->| | data --> | |_____| 719 |_____| |--------| b d |-----------| 720 | Path-->| | Path --> | _____ 721 _____ | <--Resv|_____________________| <-- Resv | | | 722 | | | |--| D' | 723 | B' |--| | |_____| 724 |_____| | | 726 Figure 9: Router Using RSVP 728 Figure 9 illustrates RSVP's model of a router node. Each data 729 stream arrives from a "previous hop" through a corresponding 730 "incoming interface" and departs through one or more "outgoing 731 interface"(s). The same physical interface may act in both the 732 incoming and outgoing roles for different data flows in the same 733 session. Multiple previous hops and/or next hops may be reached 734 through a given physical interface, as a result of the connected 735 network being a shared medium, or the existence of non-RSVP 736 routers in the path to the next RSVP hop (see Section 2.9). An 737 RSVP daemon preserves the next and previous hop addresses in its 738 reservation and path state, respectively. 740 There are two fundamental RSVP message types: RESV and PATH. 742 Each receiver host sends RSVP reservation request (RESV) messages 743 upstream towards the senders. These reservation messages must 744 follow exactly the reverse of the routes the data packets will 745 use, upstream to all the sender hosts included in the sender 746 selection. RESV messages are delivered to the sender hosts 747 themselves so that the hosts can set up appropriate traffic 748 control parameters for the first hop. 750 Each RSVP sender host transmits RSVP PATH messages downstream 751 along the uni-/multicast routes provided by the routing 752 protocol(s), following the paths of the data. These "Path" 753 messages store "path state" in each node along the way. This path 754 state includes at least the unicast IP address of the previous hop 755 node, which is used to route the RESV messages hop-by-hop in the 756 reverse direction. (In the future, some routing protocols may 757 supply reverse path forwarding information directly, replacing the 758 reverse-routing function of path state). 760 A PATH message may carry the following information in addition to 761 the previous hop address: 763 o Sender Template 765 A PATH message is required to carry a Sender Template, which 766 describes the format of data packets that the sender will 767 originate. This template is in the form of a filter spec 768 that could be used to select this sender's packets from 769 others in the same session on the same link. 771 Like a filter spec, the Sender Template is less than fully 772 general at present, specifying only the sender IP address and 773 optionally the UDP/TCP sender port. It assumes the protocol 774 Id specified for the session. 776 o Sender Tspec 778 A PATH message is required to carry a Sender Tspec, which 779 defines the traffic characteristics of the data stream that 780 the sender will generate. This Tspec is used by traffic 781 control to prevent over-reservation (and perhaps unnecessary 782 Admission Control failure) on upstream links. 784 o Adspec 786 A PATH message may optionally carry a package of OPWA 787 advertising information, known as an "Adspec". An Adspec 788 received in a PATH message is passed to the local traffic 789 control, which returns an updated Adspec; the updated version 790 is then forwarded in PATH messages sent downstream. 792 PATH messages are sent with the same source and destination 793 addresses as the data, so that they will be routed correctly 794 through non-RSVP clouds (see Section 2.9). On the other hand, 795 RESV messages are sent hop-by-hop; each RSVP-speaking node 796 forwards a RESV message to the unicast address of a previous RSVP 797 hop. 799 2.2 Port Usage 801 At present an RSVP session is defined by the triple: (DestAddress, 802 ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port 803 field (i.e., a 16-bit quantity carried at octet offset +2 in the 804 transport header). DstPort may be omitted (set to zero) if the 805 ProtocolId specifies a protocol that does not have a destination 806 port field in the format used by UDP and TCP. 808 RSVP allows any value for ProtocolId. However, end-system 809 implementations of RSVP may know about certain values for this 810 field, and in particular must know about the values for UDP and 811 TCP (17 and 6, respectively). An end system should give an error 812 to an application that either: 814 o specifies a non-zero DstPort for a protocol that does not 815 have UDP/TCP-like ports, or 817 o specifies a zero DstPort for a protocol that does have 818 UDP/TCP-like ports. 820 Filter specs and sender templates specify the pair: (SrcAddress, 821 SrcPort), where SrcPort is a UDP/TCP source port field (i.e., a 822 16-bit quantity carried at octet offset +0 in the transport 823 header). SrcPort may be omitted (set to zero) in certain cases. 825 The following rules hold for the use of zero DstPort and/or 826 SrcPort fields in RSVP. 828 1. Destination ports must be consistent. 830 Path state and/or reservation state for the same DestAddress 831 and ProtocolId must have DstPort values that are all zero or 832 all non-zero. Violation of this condition in a node is a 833 "Conflicting Dest Port" error. 835 2. Destination ports rule. 837 If DstPort in a session definition is zero, all SrcPort 838 fields used for that session must also be zero. The 839 assumption here is that the protocol does not have UDP/TCP- 840 like ports. Violation of this condition in a node is a 841 "Conflicting Src Port" error. 843 3. Source Ports must be consistent. 845 A sender host must not send path state both with and without 846 a zero SrcPort. Violation of this condition is an "Ambiguous 847 Path" error. 849 2.3 Merging Flowspecs 851 As noted earlier, a single physical interface may receive multiple 852 reservation requests from different next hops for the same session 853 and with the same filter spec, but RSVP should install only one 854 reservation on that interface. The installed reservation should 855 have an effective flowspec that is the "largest" of the flowspecs 856 requested by the different next hops. Similarly, a RESV message 857 forwarded to a previous hop should carry a flowspec that is the 858 "largest" of the flowspecs requested by the different next hops 859 (however, in certain cases the "smallest" is taken rather than the 860 largest, see Section 3.4). These cases all represent flowspec 861 merging. 863 Flowspec merging requires calculation of the "largest" of a set of 864 flowspecs. However, since flowspecs are generally multi- 865 dimensional vectors (they may contain both Tspec and Rspec 866 components, each of which may itself be multi-dimensional), it may 867 not be possible to strictly order two flowspecs. For example, if 868 one request calls for a higher bandwidth and another calls for a 869 tighter delay bound, one is not "larger" than the other. In such 870 a case, instead of taking the larger, RSVP must compute and use a 871 third flowspec that is at least as large as each. Mathematically, 872 RSVP merges flowspecs using the " least upper bound" (LUB) instead 873 of the maximum. Typically, the LUB is calculated by creating a 874 new flowspec whose components are individually either the max or 875 the min of corresponding components of the flowspecs being merged. 876 For example, the LUB of Tspecs defined by token bucket parameters 877 is computed by taking the maximums of the bucket size and the rate 878 parameters. In several cases, the GLB (Greatest Lower Bound) is 879 used instead of the LUB; this simply interchanges max and min 880 operations. 882 We can now give the complete rules for calculating the effective 883 flowspec (Te, Re) to be installed on an interface. Here Te is the 884 effective Tspec and Re is the effective Rspec. As an example, 885 consider interface (d) in Figure 9. 887 1. Re is calculated as the largest (using an LUB if necessary) 888 of the Rspecs in RESV messages from different next hops 889 (e.g., D and D') but the same outgoing interface (d). 891 2. All Tspecs that were supplied in PATH messages from different 892 previous hops (e.g., some or all of A, B, and B' in Figure 9) 893 are summed; call this sum Path_Te. 895 3. The maximum Tspec supplied in RESV messages from different 896 next hops (e.g., D and D') is calculated; call this Resv_Te. 898 4. Te is the GLB (greatest lower bound) of Path_Te and Resv_Te. 900 Flowspecs, Tspecs, and Adspecs are opaque to RSVP. Therefore, the 901 last of these steps is actually performed by traffic control. The 902 definition and implementation of the rules for comparing 903 flowspecs, calculating LUBs and GLBs, and summing Tspecs are 904 outside the definition of RSVP [ServTempl95a]. Section 3.10.4 905 shows generic calls that an RSVP daemon could use for these 906 functions. 908 2.4 Soft State 910 RSVP takes a "soft state" approach to managing the reservation 911 state in routers and hosts. RSVP soft state is created and 912 periodically refreshed by PATH and RESV messages. The state is 913 deleted if no matching refresh messages arrive before the 914 expiration of a "cleanup timeout" interval. State may also be 915 deleted by an explicit "teardown" message, described in the next 916 section. At the expiration of each "refresh timeout" period and 917 after a state change, RSVP scans its state to build and forward 918 PATH and RESV refresh messages to succeeding hops. 920 PATH and RESV messages are idempotent. When a route changes, the 921 next PATH message will initialize the path state on the new route, 922 and future RESV messages will establish reservation state there; 923 the state on the now-unused segment of the route will time out. 924 Thus, whether a message is "new" or a "refresh" is determined 925 separately at each node, depending upon the existing state at that 926 node. 928 RSVP sends its messages as IP datagrams with no reliability 929 enhancement. Periodic transmission of refresh messages by hosts 930 and routers is expected to handle the occasional loss of an RSVP 931 message. If the effective cleanup timeout is set to K times the 932 refresh timeout period, then RSVP can tolerate K-1 successive RSVP 933 packet losses without falsely erasing a reservation. We recommend 934 that the network traffic control mechanism be statically 935 configured to grant some minimal bandwidth for RSVP messages to 936 protect them from congestion losses. 938 The state maintained by RSVP is dynamic; to change the set of 939 senders Si or to change any QoS request, a host simply starts 940 sending revised PATH and/or RESV messages. The result will be an 941 appropriate adjustment in the RSVP state in all nodes along the 942 path. 944 In steady state, refreshing is performed hop-by-hop, to allow 945 merging. When the received state differs from the stored state, 946 the stored state is updated. If this update results in 947 modification of state to be forwarded in refresh messages, these 948 refresh messages must be generated and forwarded immediately, so 949 that state changes can be propagated end-to-end without delay. 950 However, propagation of a change stops when and if it reaches a 951 point where merging causes no resulting state change. This 952 minimizes RSVP control traffic due to changes and is essential for 953 scaling to large multicast groups. 955 State that is received through a particular interface I* should 956 never be forwarded out the same interface. Conversely, state that 957 is forwarded out interface I* must be computed using only state 958 that arrived on interfaces different from I*. A trivial example 959 of this rule is illustrated in Figure 10, which shows a transit 960 router with one sender and one receiver on each interface (and 961 assumes one next/previous hop per interface). Interfaces (a) and 962 (c) serve as both outgoing and incoming interfaces for this 963 session. Both receivers are making wildcard-scope reservations, 964 in which the RESV messages are forwarded to all previous hops for 965 senders in the group, with the exception of the next hop from 966 which they came. The result is independent reservations in the 967 two directions. 969 There is an additional rule governing the forwarding of RESV 970 messages: state from RESV messages received from outgoing 971 interface Io should be forwarded to incoming interface Ii only if 972 PATH messages from Ii are forwarded to Io. 974 ________________ 975 a | | c 976 ( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) 977 |________________| 979 Send | Receive 980 | 981 WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) 982 | 983 Receive | Send 984 | 985 WF( *{4B}) --> (a) | (c) --> WF( *{4B}) 986 | 987 Reserve on (a) | Reserve on (c) 988 __________ | __________ 989 | * {4B} | | | * {3B} | 990 |__________| | |__________| 991 | 993 Figure 10: Independent Reservations 995 2.5 Teardown 997 Upon arrival, RSVP "teardown" messages remove path and reservation 998 state immediately. Although it is not necessary to explicitly 999 tear down an old reservation, we recommend that all end hosts send 1000 a teardown request as soon as an application finishes. 1002 There are two types of RSVP teardown message, PTEAR and RTEAR. A 1003 PTEAR message travels towards all receivers downstream from its 1004 point of initiation and deletes path state, as well as all 1005 dependent reservation state, along the way. An RTEAR message 1006 deletes reservation state and travels towards all senders upstream 1007 from its point of initiation. A PTEAR (RTEAR) message may be 1008 conceptualized as a reversed-sense Path message (Resv message, 1009 respectively). 1011 A teardown request may be initiated either by an application in an 1012 end system (sender or receiver), or by a router as the result of 1013 state timeout. Once initiated, a teardown request must be 1014 forwarded hop-by-hop without delay. A teardown message deletes 1015 the specified state in the node where it is received. As always, 1016 this state change will be propagated immediately to the next node, 1017 but only if there will be a net change after merging. As a 1018 result, an RTEAR message will prune the reservation state back 1019 (only) as far as possible. 1021 Like all other RSVP messages, teardown requests are not delivered 1022 reliably. The loss of a teardown request message will not cause a 1023 protocol failure because the unused state will eventually time out 1024 even though it is not explicitly deleted. If a teardown message 1025 is lost, the router that failed to receive that message will time 1026 out its state and initiate a new teardown message beyond the loss 1027 point. Assuming that RSVP message loss probability is small, the 1028 longest time to delete state will seldom exceed one refresh 1029 timeout period. 1031 2.6 Errors 1033 There are two RSVP error messages, RERR and PERR. PERR messages 1034 are very simple. They are simply sent upstream to the sender that 1035 created the error, and they do not change path state in the nodes 1036 though which they pass. There are only a few possible causes of 1037 path errors. 1039 However, there are a number of ways for a syntactically valid 1040 reservation request to fail at some node along the path, for 1041 example: 1043 1. The effective flowspec that is computed using the new request 1044 may fail admission control. 1046 2. Administrative policy may prevent the requested reservation. 1048 3. There may be no matching path state, so that the request 1049 cannot be forwarded towards the sender(s). 1051 4. A reservation style that requires the explicit selection of a 1052 unique sender may have a filter spec that is ambiguous, i.e., 1053 that matches more than one sender in the path state, due to 1054 the use of wildcard fields in the filter spec. 1056 5. The requested style may be incompatible with the style(s) of 1057 existing reservations. The incompatibility may occur among 1058 reservations for the same session on the same outgoing 1059 interface, or among effective reservations on different 1060 outgoing interfaces. 1062 A node may also decide to preempt an established reservation. 1064 The handling of RERR messages is somewhat complex (Section 3.4). 1065 Since a request that fails may be the result of merging a number 1066 of requests, a reservation error must be reported to all of the 1067 responsible receivers. In addition, merging heterogeneous 1068 requests creates a potential difficulty known as the "killer 1069 reservation" problem, in which one request could deny service to 1070 another. There are actually two killer-reservation problems. 1072 1. The first killer reservation problem (KR-I) arises when there 1073 is already a reservation Q0 in place. If another receiver 1074 now makes a larger reservation Q1 > Q0, the result of merging 1075 Q0 and Q1 may be rejected by admission control in some 1076 upstream node. This must not deny service to Q0. 1078 The solution to this problem is simple: when admission 1079 control fails for a reservation request, any existing 1080 reservation is left in place. 1082 2. The second killer reservation problem (KR-II) is the 1083 converse: the receiver making a reservation Q1 is persistent 1084 even though Admission Control is failing for Q1 in some node. 1085 This must not prevent a different receiver from now 1086 establishing a smaller reservation Q0 that will succeed. 1088 To solve this problem, a RERR message establishes additional 1089 state, called "blockade state", in each node through which it 1090 passes. Blockade state in a node modifies the merging 1091 procedure to omit the offending flowspec (Q1 in the example) 1092 from the merge, allowing a smaller request to be forwarded 1093 and established. The Q1 reservation state is said to be 1094 "blockaded". Detailed rules are presented in Section 3.4. 1096 A reservation request that fails Admission Control creates 1097 blockade state but is left in place in nodes downstream of the 1098 failure point. It has been suggested that these reservations 1099 downstream from the failure represent "wasted" reservations and 1100 should be timed out if not actively deleted. However, in general 1101 the downstream reservations will not be "wasted". 1103 o There are two possible reasons for a receiver persisting in a 1104 failed reservation: (1) it is polling for resource 1105 availability along the entire path, or (2) it wants to obtain 1106 the desired QoS along as much of the path as possible. 1107 Certainly in the second case, and perhaps in the first case, 1108 the receiver will want to hold onto the reservations it has 1109 made downstream from the failure. 1111 o If these downstream reservations were not retained, the 1112 responsiveness of RSVP to certain transient failures would be 1113 impaired. For example, suppose a route "flaps" to an 1114 alternate route that is congested, so an existing reservation 1115 suddenly fails, then quickly recovers to the original route. 1116 The blockade state in each downstream router must not remove 1117 the state or prevent its immediate refresh. 1119 o If we did not refresh the downstream reservations, they might 1120 time out, to be restored every Td seconds. Such on/off 1121 behavior might be very distressing for users. 1123 2.7 Confirmation 1125 To request a confirmation for its reservation request, a receiver 1126 Rj includes in the RESV message a confirmation-request object 1127 containing Rj's IP address. At each merge point, only the largest 1128 flowspec and any accompanying confirmation-request object is 1129 forwarded upstream. If the reservation request from Rj is equal 1130 to or smaller than the reservation in place on a node, its RESV 1131 are not forwarded further, and if the RESV included a 1132 confirmation-request object, a RACK message is sent back to Rj. 1133 This mechanism has the following consequences: 1135 o A new reservation request with a flowspec larger than any in 1136 place for a session will normally result in either a RERR or 1137 a RACK message back to the receiver from each sender. In 1138 this case, the RACK message will be an end-to-end 1139 confirmation. 1141 o The receipt of a RACK gives no guarantees. Assume the first 1142 two reservation requests from receivers R1 and R2 arrive at 1143 the node where they are merged. R2, whose reservation was 1144 the second to arrive at that node, may receive a RACK from 1145 that node while R1's request has not yet propagated all the 1146 way to a matching sender and may still fail. Thus, R2 may 1147 receive a RACK although there is no end-to-end reservation in 1148 place; furthermore, R2 may receive a RACK followed by a RERR. 1150 2.8 Policy and Security 1152 RSVP-mediated QoS requests will result in particular user(s) 1153 getting preferential access to network resources. To prevent 1154 abuse, some form of back pressure on users is likely to be 1155 required. This back pressure might take the form of 1156 administrative rules, or of some form of real or virtual billing 1157 for the "cost" of a reservation. The form and contents of such 1158 back pressure is a matter of administrative policy that may be 1159 determined independently by each administrative domain in the 1160 Internet. 1162 Therefore, there will be policy control as well as admission 1163 control over the establishment of reservations. As input to 1164 policy control, RSVP messages may carry policy data. Policy data 1165 may include credentials identifying users or user classes, account 1166 numbers, limits, quotas, etc. Like flowspecs, policy data will be 1167 opaque to RSVP, which will simply pass it to a "Local Policy 1168 Module" (LPM) for a decision. 1170 To protect the integrity of the policy control mechanisms, it may 1171 be necessary to ensure the integrity of RSVP messages against 1172 corruption or spoofing, hop by hop. For this purpose, RSVP 1173 messages may carry integrity objects that can be created and 1174 verified by neighbor RSVP-capable nodes. These objects use a 1175 keyed cryptographic digest technique and assume that RSVP 1176 neighbors share a secret [Baker96]. 1178 User policy data in reservation request messages presents a 1179 scaling problem. When a multicast group has a large number of 1180 receivers, it will be impossible or undesirable to carry all 1181 receivers' policy data upstream to the sender(s). The policy data 1182 will have to be administratively merged at places near the 1183 receivers, to avoid excessive policy data. Administrative merging 1184 implies checking the user credentials and accounting data and then 1185 substituting a token indicating the check has succeeded. A chain 1186 of trust established using integrity fields will allow upstream 1187 nodes to accept these tokens. 1189 In summary, different administrative domains in the Internet may 1190 have different policies regarding their resource usage and 1191 reservation. The role of RSVP is to carry policy data associated 1192 with each reservation to the network as needed. Note that the 1193 merge points for policy data are likely to be at the boundaries of 1194 administrative domains. It may be necessary to carry accumulated 1195 and unmerged policy data upstream through multiple nodes before 1196 reaching one of these merge points. 1198 This document does not specify the contents of policy data, the 1199 structure of an LPM, or any generic policy models. These will be 1200 defined in the future. 1202 2.9 Automatic RSVP Tunneling 1204 It is impossible to deploy RSVP (or any new protocol) at the same 1205 moment throughout the entire Internet. Furthermore, RSVP may 1206 never be deployed everywhere. RSVP must therefore provide correct 1207 protocol operation even when two RSVP-capable routers are joined 1208 by an arbitrary "cloud" of non-RSVP routers. Of course, an 1209 intermediate cloud that does not support RSVP is unable to perform 1210 resource reservation. However, if such a cloud has sufficient 1211 capacity, it may still provide acceptable realtime service. 1213 RSVP automatically tunnels through such a non-RSVP cloud. Both 1214 RSVP and non-RSVP routers forward PATH messages towards the 1215 destination address using their local uni-/multicast routing 1216 table. Therefore, the routing of PATH messages will be unaffected 1217 by non-RSVP routers in the path. When a PATH message traverses a 1218 non-RSVP cloud, it carries to the next RSVP-capable node the IP 1219 address of the last RSVP-capable router before entering the cloud. 1220 This effectively constructs a tunnel through the cloud for RESV 1221 messages, which can then be forwarded directly to the next RSVP- 1222 capable router on the path(s) back towards the source. 1224 Even though RSVP operates correctly through a non-RSVP cloud, the 1225 non-RSVP-capable nodes will in general perturb the QoS provided to 1226 a receiver. Therefore, RSVP tries to inform the receiver when 1227 there are non-RSVP-capable hops in the path to a given sender, by 1228 means of two flag bits in the SESSION object of a PATH message; 1229 see Section 3.7 and Appendix A. 1231 Some topologies of RSVP routers and non-RSVP routers can cause 1232 RESV messages to arrive at the wrong RSVP-capable node, or to 1233 arrive at the wrong interface of the correct node. An RSVP daemon 1234 must be prepared to handle either situation. If the destination 1235 address does not match any local interface and the message is not 1236 a PATH or PTEAR, the message must be forwarded without further 1237 processing by this node. When a RESV message does arrive at the 1238 addessed node, the IP destination address (or the LIH, defined 1239 later) must be used to determine the interface to receive the 1240 reservation. 1242 2.10 Host Model 1244 Before a session can be created, the session identification, 1245 comprised of DestAddress and perhaps the generalized destination 1246 port, must be assigned and communicated to all the senders and 1247 receivers by some out-of-band mechanism. When an RSVP session is 1248 being set up, the following events happen at the end systems. 1250 H1 A receiver joins the multicast group specified by 1251 DestAddress, using IGMP. 1253 H2 A potential sender starts sending RSVP PATH messages to the 1254 DestAddress. 1256 H3 A receiver application receives a PATH message. 1258 H4 A receiver starts sending appropriate RESV messages, 1259 specifying the desired flow descriptors. 1261 H5 A sender application receives a RESV message. 1263 H6 A sender starts sending data packets. 1265 There are several synchronization considerations. 1267 o H1 and H2 may happen in either order. 1269 o Suppose that a new sender starts sending data (H6) but there 1270 are no multicast routes because no receivers have joined the 1271 group (H1). Then the data will be dropped at some router 1272 node (which node depends upon the routing protocol) until 1273 receivers(s) appear. 1275 o Suppose that a new sender starts sending PATH messages (H2) 1276 and data (H6) simultaneously, and there are receivers but no 1277 RESV messages have reached the sender yet (e.g., because its 1278 PATH messages have not yet propagated to the receiver(s)). 1279 Then the initial data may arrive at receivers without the 1280 desired QoS. The sender could mitigate this problem by 1281 awaiting arrival of the first RESV message (H5); however, 1282 receivers that are farther away may not have reservations in 1283 place yet. 1285 o If a receiver starts sending RESV messages (H4) before 1286 receiving any PATH messages (H3), RSVP will return error 1287 messages to the receiver. 1289 The receiver may simply choose to ignore such error messages, 1290 or it may avoid them by waiting for PATH messages before 1291 sending RESV messages. 1293 A specific application program interface (API) for RSVP is not 1294 defined in this protocol spec, as it may be host system dependent. 1295 However, Section 3.10.1 discusses the general requirements and 1296 outlines a generic interface. 1298 3. RSVP Functional Specification 1300 3.1 RSVP Message Formats 1302 An RSVP message or message fragment consists of a common header, 1303 an optional integrity-check data structure, and a body consisting 1304 of a variable number of variable-length, typed "objects". The 1305 integrity-check data structure is itself an object, of class 1306 INTEGRITY [Baker96]. In a fragmented message, INTEGRITY objects 1307 must occur either in every fragment or else in no fragment. 1308 Fragmentation of a message allows division of an object across two 1309 (or more) successive fragments. 1311 The following subsections define the formats of the common header, 1312 the object structures, and each of the RSVP message types. For 1313 each RSVP message type, there is a set of rules for the 1314 permissible choice of object types. These rules are specified 1315 using Backus-Naur Form (BNF) augmented with square brackets 1316 surrounding optional sub-sequences. The BNF implies an order for 1317 the objects in a message. However, in many (but not all) cases, 1318 object order makes no logical difference. An implementation 1319 should create messages with the objects in the order shown here, 1320 but accept the objects in any order except where the order is 1321 logically required (as noted in the following). 1323 3.1.1 Common Header 1325 0 1 2 3 1326 +-------------+-------------+-------------+-------------+ 1327 | Vers | Flags| Type | RSVP Checksum | 1328 +-------------+-------------+-------------+-------------+ 1329 | RSVP Length | (Reserved) | Send_TTL | 1330 +-------------+-------------+-------------+-------------+ 1331 | Message ID | 1332 +----------+--+-------------+-------------+-------------+ 1333 |(Reserved)|MF| Fragment offset | 1334 +----------+--+-------------+-------------+-------------+ 1336 The fields in the common header are as follows: 1338 Vers: 4 bits 1340 Protocol version number. This is version 1. 1342 Flags: 4 bits 1343 0x01 = INTEGRITY object present 1345 This flag indicates that an INTEGRITY object follows 1346 immediately after the common header. The use of the 1347 INTEGRITY object is described in [Baker96]. 1349 0x02 = UDP': UDP encapsulation marker flag 1351 This flag is reserved for use by UDP encapsulation 1352 [Appendix C]. 1354 Type: 8 bits 1356 1 = PATH 1358 2 = RESV 1360 3 = PERR 1362 4 = RERR 1364 5 = PTEAR 1366 6 = RTEAR 1368 7 = RACK 1370 RSVP Checksum: 16 bits 1372 The one's complement of the one's complement sum of the 1373 message (fragment), with the checksum field replaced by 1374 zero for the purpose of computing the checksum. An all- 1375 zero value means that no checksum was transmitted. 1377 RSVP Length: 16 bits 1379 The total length of this RSVP packet in bytes, including 1380 the common header and the variable-length objects that 1381 follow. If the MF flag is on or the Fragment Offset field 1382 is non-zero, this is the length of the current fragment of 1383 a larger message. 1385 Send_TTL: 8 bits 1387 The IP TTL value with which the message was sent. 1389 Message ID: 32 bits 1390 A label shared by all fragments of one message from a 1391 given next/previous RSVP hop. An RSVP implementation 1392 assigns a unique Message ID to each message it sends. 1394 MF: More Fragments Flag: 1 bit 1396 This flag is the low-order bit of a byte; the seven high- 1397 order bits are reserved. It is on for all but the last 1398 fragment of a message. 1400 Fragment Offset: 24 bits 1402 This field gives the byte offset of the current fragment 1403 in the complete message. 1405 3.1.2 Object Formats 1407 Every object consists of one or more 32-bit words with a one- 1408 word header, in the following format: 1410 0 1 2 3 1411 +-------------+-------------+-------------+-------------+ 1412 | Length (bytes) | Class-Num | C-Type | 1413 +-------------+-------------+-------------+-------------+ 1414 | | 1415 // (Object contents) // 1416 | | 1417 +-------------+-------------+-------------+-------------+ 1419 An object header has the following fields: 1421 Length 1423 A 16-bit field containing the total object length in 1424 bytes. Must always be a multiple of 4, and at least 4. 1426 Class-Num 1428 Identifies the object class; values of this field are 1429 defined in Appendix A. Each object class has a name, 1430 which is always capitalized in this document. An RSVP 1431 implementation must recognize the following classes: 1433 NULL 1435 A NULL object has a Class-Num of zero, and its C-Type 1436 is ignored. Its length must be at least 4, but can 1437 be any multiple of 4. A NULL object may appear 1438 anywhere in a sequence of objects, and its contents 1439 will be ignored by the receiver. 1441 SESSION 1443 Contains the IP destination address (DestAddress), 1444 the IP protocol id, and a generalized destination 1445 port, to define a specific session for the other 1446 objects that follow. Required in every RSVP message. 1448 RSVP_HOP 1450 Carries the IP address of the RSVP-capable node that 1451 sent this message. This document refers to a 1452 RSVP_HOP object as a PHOP ("previous hop") object for 1453 downstream messages or as a NHOP ("next hop") object 1454 for upstream messages. 1456 TIME_VALUES 1458 Contains the value for the refresh period R used by 1459 the creator of the message; see 3.6. Required in 1460 every PATH and RESV message. 1462 STYLE 1464 Defines the reservation style plus style-specific 1465 information that is not in FLOWSPEC or FILTER_SPEC 1466 objects. Required in every RESV message. 1468 FLOWSPEC 1470 Defines a desired QoS, in a RESV message. 1472 FILTER_SPEC 1474 Defines a subset of session data packets that should 1475 receive the desired QoS (specified by an FLOWSPEC 1476 object), in a RESV message. 1478 SENDER_TEMPLATE 1480 Contains a sender IP address and perhaps some 1481 additional demultiplexing information to identify a 1482 sender, in a PATH message. 1484 SENDER_TSPEC 1485 Defines the traffic characteristics of a sender's 1486 data stream, in a PATH message. 1488 ADSPEC 1490 Carries OPWA data, in a PATH message. 1492 ERROR_SPEC 1494 Specifies an error, in a PERR or RERR message. 1496 POLICY_DATA 1498 Carries information that will allow a local policy 1499 module to decide whether an associated reservation is 1500 administratively permitted. May appear in a PATH or 1501 RESV message. 1503 INTEGRITY 1505 Contains cryptographic data to authenticate the 1506 originating node and to verify the contents of this 1507 RSVP message. See [Baker96]. 1509 SCOPE 1511 An explicit list of sender hosts towards which to 1512 forward a message. May appear in a RESV, RERR, or 1513 RTEAR message. 1515 RESV_CONFIRM 1517 Carries the IP address of a receiver that requested a 1518 confirmation. May appear in a RESV or RACK message. 1520 C-Type 1522 Object type, unique within Class-Num. Values are defined 1523 in Appendix A. 1525 The maximum object content length is 65528 bytes. The Class- 1526 Num and C-Type fields may be used together as a 16-bit number 1527 to define a unique type for each object. 1529 The high-order two bits of the Class-Num is used to determine 1530 what action a node should take if it does not recognize the 1531 Class-Num of an object; see Section 3.9. 1533 3.1.3 Path Messages 1535 Each sender host periodically sends a PATH message containing a 1536 description of each data stream it originates. The PATH 1537 message travels from a sender to receiver(s) along the same 1538 path(s) used by the data packets. The IP source address of a 1539 PATH message is an address of the sender it describes, while 1540 the destination address is the DestAddress for the session. 1541 These addresses assure that the message will be correctly 1542 routed through a non-RSVP cloud. 1544 Each RSVP-capable node along the path(s) captures PATH messages 1545 and processes them to build local path state. The node then 1546 forwards the PATH messages towards the receiver(s), replicating 1547 it as dictated by multicast routing, while preserving the 1548 original IP source address. PATH messages eventually reach the 1549 applications on all receivers; however, they are not looped 1550 back to a receiver running in the same application process as 1551 the sender. 1553 The format of a PATH message is as follows: 1555 ::= [ ] 1557 1559 1561 1563 ::= 1565 [ ] [ ] 1567 If the INTEGRITY object is present, there must be an INTEGRITY 1568 object immediately following the common header in every 1569 fragment of the message, in this and all other messages. The 1570 objects included in the sender descriptor must occur after all 1571 other objects in the message. 1573 The PHOP (i.e., the RSVP_HOP) object of each PATH message 1574 contains the address of the interface through which the PATH 1575 message was most recently sent. The SENDER_TEMPLATE object 1576 defines the format of data packets from this sender, while the 1577 SENDER_TSPEC object specifies the traffic characteristics of 1578 the flow. Optionally, there may be a POLICY_DATA object 1579 specifying user credential and accounting information and/or an 1580 ADSPEC object carrying advertising (OPWA) data. 1582 A PATH message received at a node is processed to create path 1583 state for the sender defined by the SENDER_TEMPLATE and SESSION 1584 objects. Any POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are 1585 also saved in the path state. If an error is encountered while 1586 processing a PATH message, a PERR message is sent to the 1587 originating sender of the PATH message. PATH messages must 1588 satisfy the rules on SrcPort and DstPort in Section 2.2. 1590 Periodically, the RSVP daemon at a node scans the path state to 1591 create new PATH messages to forward downstream. Each message 1592 contains a sender descriptor defining one sender. The RSVP 1593 daemon forwards these messages using routing information it 1594 obtains from the appropriate uni-/multicast routing daemon. 1595 The route depends upon the session DestAddress, and for some 1596 routing protocols also upon the source (sender's IP) address. 1597 The routing information generally includes the list of none or 1598 more outgoing interfaces to which the PATH message to be 1599 forwarded. Because each outgoing interface has a different IP 1600 address, the PATH messages sent out different interfaces 1601 contain different PHOP addresses. In addition, any ADSPEC or 1602 POLICY_DATA objects carried in PATH messages will also 1603 generally differ for different outgoing interfaces. 1605 Some IP multicast routing protocols (e.g., DVMRP, PIM, and 1606 MOSPF) also keep track of the expected incoming interface for 1607 each source host to a multicast group. Whenever this 1608 information is available, RSVP should check the incoming 1609 interface of each PATH message and immediately discard those 1610 messages that have arrived on the wrong interface. 1612 3.1.4 Resv Messages 1614 RESV messages carry reservation requests hop-by-hop from 1615 receivers to senders, along the reverse paths of data flows for 1616 the session. The IP destination address of a RESV message is 1617 the unicast address of a previous-hop node, obtained from the 1618 path state. The IP source address is an address of the node 1619 that sent the message. 1621 The RESV message format is as follows: 1623 ::= [ ] 1625 1627 [ ] 1629 [ ] [ ] 1631