idnits 2.17.1 draft-ietf-rsvp-spec-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 44 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1770 has weird spacing: '...ng, the detai...' == Line 3885 has weird spacing: '... object k ...' == Line 4006 has weird spacing: '... object k ...' == Line 4427 has weird spacing: '...ildcard scope...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 22, 1995) is 10382 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 2041, but not defined == Missing Reference: 'S1' is mentioned on line 2037, but not defined == Missing Reference: 'S2' is mentioned on line 2041, but not defined == Missing Reference: 'S3' is mentioned on line 2041, but not defined == Missing Reference: 'When' is mentioned on line 3010, but not defined == Missing Reference: 'Note 1' is mentioned on line 4256, but not defined == Missing Reference: 'Note 3' is mentioned on line 4262, but not defined == Missing Reference: 'Note 2' is mentioned on line 4259, but not defined == Unused Reference: 'CSZ92' is defined on line 4575, but no explicit reference was found in the text == Unused Reference: 'IServ93' is defined on line 4587, but no explicit reference was found in the text == Unused Reference: 'Partridge92' is defined on line 4593, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CSZ92' -- Possible downref: Non-RFC (?) normative reference: ref. 'FJ94' ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. 'ISInt93') -- Possible downref: Non-RFC (?) normative reference: ref. 'IServ93' == 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. '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: May 1996 ISI 4 File: draft-ietf-rsvp-spec-08.txt L. Zhang 5 PARC 6 S. Berson 7 ISI 8 S. Herzog 9 ISI 10 J. Wroclaswki 11 MIT 13 Resource ReSerVation Protocol (RSVP) -- 15 Version 1 Functional Specification 17 November 22, 1995 19 Status of Memo 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 To learn the current status of any Internet-Draft, please check the 32 linebreak "1id-abstracts.txt" listing contained in the Internet- 33 Drafts Shadow Directories on ds.internic.net (US East Coast), 34 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au 35 (Pacific Rim). 37 Abstract 39 This memo describes version 1 of RSVP, a resource reservation setup 40 protocol designed for an integrated services Internet. RSVP provides 41 receiver-initiated setup of resource reservations for multicast or 42 unicast data flows, with good scaling and robustness properties. 44 Table of Contents 46 1. Introduction ........................................................5 47 1.1 Data Flows ......................................................8 48 1.2 Reservation Model ...............................................9 49 1.3 Reservation Styles ..............................................11 50 1.4 Examples of Styles ..............................................14 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 and Acknowledgments ......................................25 58 2.7 Policy and Security .............................................27 59 2.8 Automatic RSVP Tunneling ........................................28 60 2.9 Host Model ......................................................28 61 3. RSVP Functional Specification .......................................30 62 3.1 RSVP Message Formats ............................................30 63 3.2 Sending RSVP Messages ...........................................42 64 3.3 Avoiding RSVP Message Loops .....................................44 65 3.4 Local Repair ....................................................48 66 3.5 Time Parameters .................................................48 67 3.6 Traffic Policing and TTL ........................................50 68 3.7 Multihomed Hosts ................................................51 69 3.8 Future Compatibility ............................................52 70 3.9 RSVP Interfaces .................................................55 71 4. Message Processing Rules ............................................65 72 APPENDIX A. Object Definitions .........................................82 73 APPENDIX B. Error Codes and Values .....................................97 74 APPENDIX C. UDP Encapsulation ..........................................101 75 APPENDIX D. Experimental and Open Issues ...............................103 76 What's Changed 78 The most important changes in this document from the rsvp-spec-07 draft 79 are: 81 o The role and interpretation of the IP Protocol Id is changed. 82 The Protocol Id is now a required part of the session 83 definition, and filter specs and sender templates now assume 84 the Protocol Id from the session rather than stating it 85 explicitly. 87 o A "soft" reservation confirmation message is added. 89 o The text states explicitly that an erroneous reservation 90 message is not forwarded. A mechanism to allow a receiver 91 more flexible control over forwarding of its messages after 92 an admission control failure has not been designed and is 93 therefore not included in this version of the protocol. 95 o A terminology confusion is eliminated. The term "scope" was 96 used both for a set of senders and for a set of sender hosts. 97 A new term "sender selection" is introduced for the first, 98 leaving "scope" for the second. 100 o The FILTER_SPEC object is dropped from a wildcard sender 101 selection (WF) style reservation, which now selects "all 102 senders" without qualification. 104 o The StyleID byte is dropped from a STYLE object, as 105 redundant. 107 o An SE style flow descriptor is simplified to a single 108 flowspec. 110 o The IP Router Alert option is now required in PATH, PTEAR, 111 and RACK messages. 113 o The TIME_VALUES object is now required in RESV and PATH 114 messages; there is no default. 116 o Policing at branch points is now defined in a new section on 117 policing (3.6). 119 o A 2-second delay is inserted into local repair. 121 o Merging of SE with WF objects is no longer allowed. 123 o The Rmax end-to-end bound on the refresh rate R is removed, 124 since its utility was unclear. 126 o A rule for randomizing refresh timeouts is included. 128 o The suggestion that TCP could be used for carrying RSVP state 129 through a congested non-RSVP cloud is removed. 131 o SENDER_TSPECS are now required in PATH| messages. 133 o There are new sections on multihomed hosts (3.7) and future 134 compatibility (3.8). The latter section makes clear that a 135 message containing an object with unknown C-Type should be 136 rejected. Any more forgiving treatment seems too complex. 138 o Appendix C on UDP encapsulation is completely changed. 140 o Some text was rearranged in Sections 1 and 2. 142 1. Introduction 144 This document defines RSVP, a resource reservation setup protocol 145 designed for an integrated services Internet [RSVP93,ISInt93]. 147 On behalf of an application data stream, a host uses the RSVP 148 protocol to request a specific quality of service (QoS) from the 149 network. RSVP delivers QoS requests to routers along the path(s) of 150 the data stream and maintains router and host state to provide the 151 requested service. RSVP requests will generally, although not 152 necessarily, result in resources being reserved along the data path. 154 RSVP requests resources for simplex data streams, i.e., it requests 155 resources in only one direction. Therefore, a sender is logically 156 distinct from a receiver, although the same application process may 157 act as both a sender and a receiver at the same time. RSVP operates 158 on top of IP (either IPv4 or IP6), occupying the place of a transport 159 protocol in the protocol stack. However, like ICMP, IGMP, and 160 routing protocols, RSVP does not transport application data but is 161 rather an Internet control protocol. Like the implementations of 162 routing and management protocols, an implementation of RSVP will 163 typically execute in the background, not in the data forwarding path, 164 as shown in Figure 1. 166 RSVP is not itself a routing protocol; RSVP is designed to operate 167 with current and future unicast and multicast routing protocols. The 168 RSVP daemon consults the local routing protocol(s) to obtain routes. 169 In the multicast case, for example, a host sends IGMP messages to 170 join a multicast group and then sends RSVP messages to reserve 171 resources along the delivery path(s) of that group. Routing 172 protocols determine where packets get forwarded; RSVP only concerns 173 with the QoS of those packets that are forwarded by routing. 175 HOST ROUTER 177 _________________________ RSVP _____________________________ 178 | | .--------------. | 179 | _______ ______ | / | ________ . ______ | 180 | | | | | | / || | . | | | RSVP 181 | |Applic-| | RSVP <----/ ||Routing | -> RSVP <----------> 182 | | App <----->daemon| | ||Protocol| |daemon| | 183 | | | | | | || daemon <----> | | 184 | |_______| |___.__| | ||_ ._____| |__.__.| | 185 | | | | | | | . | 186 |===|===============|=====| |===|=============|====.======| 187 | data .........| | | | ...........| .____ | 188 | | ____V_ ____V____ | | _V__V_ _____V___ | Adm.|| 189 | | |Class-| | || data | |Class-| | ||Cntrl|| 190 | |=> ifier|=> Packet ============> ifier|==> Packet ||_____|| data 191 | |______| |Scheduler|| | |______| |Scheduler|===========> 192 | |_________|| | |_________| | 193 |_________________________| |_____________________________| 195 Figure 1: RSVP in Hosts and Routers 197 Each router that is capable of resource reservation passes incoming 198 data packets through a packet classifier and then queues them as 199 necessary in a packet scheduler. The packet classifier determines 200 the route and the QoS class for each packet. There is a scheduler 201 for each interface, to allocate resources for transmission on the 202 particular link-layer medium used by that interface. If the link- 203 layer medium is QoS-active, i.e., if it has its own QoS management 204 capability, then the packet scheduler is responsible for negotiation 205 with the link layer to obtain the QoS requested by RSVP. This 206 mapping to the link layer QoS may be accomplished in a number of 207 possible ways; the details will be medium-dependent. On a QoS- 208 passive medium such as a leased line, the scheduler itself allocates 209 packet transmission capacity. The scheduler may also allocate other 210 system resources such as CPU time or buffers. 212 In order to efficiently accommodate heterogeneous receivers and 213 dynamic group membership, RSVP makes receivers responsible for 214 requesting resource reservations [RSVP93]. A QoS request, which 215 typically originates from a receiver host application, is passed to 216 the local RSVP implementation, shown as a user daemon in Figure 1. 217 The RSVP protocol then carries the request to all the nodes (routers 218 and hosts) along the reverse data path(s) to the data source(s). 220 At each node, the RSVP daemon communicates with a local decision 221 module, called "admission control", to determine if the router can 222 supply the requested QoS. If the admission control check succeeds, 223 the RSVP daemon sets parameters in the packet classifier and 224 scheduler to obtain the desired QoS. If the admission control check 225 fails, the RSVP program immediately returns an error notification to 226 the application process that originated the request. We refer to the 227 packet classifier, packet scheduler, and admission control components 228 as " traffic control". 230 RSVP is designed to scale well for very large multicast groups. 231 Since both the membership of a large group and the topology of large 232 multicast trees are likely to change with time, the RSVP design 233 assumes that router state for traffic control will be built and 234 destroyed incrementally. For this purpose, RSVP uses "soft state" in 235 the routers. That is, RSVP sends periodic refresh messages to 236 maintain the state along the reserved path(s); in absence of 237 refreshes, the state will automatically time out and be deleted. 239 RSVP protocol mechanisms provide a general facility for creating and 240 maintaining distributed reservation state across a mesh of multicast 241 or unicast delivery paths. RSVP transfers reservation parameters as 242 opaque data (except for certain well-defined operations on the data), 243 which it simply passes to traffic control for interpretation. 244 Although the RSVP protocol mechanisms are largely independent of the 245 encoding of these parameters, the encodings must be defined in the 246 reservation model that is presented to an application; see Appendix A 247 for more details. 249 In summary, RSVP has the following attributes: 251 o RSVP makes resource reservations for both unicast and many-to- 252 many multicast applications, adapting dynamically to changing 253 group membership as well as changing routes. 255 o RSVP is simplex, i.e., it reserves for data flow in one 256 direction only. 258 o RSVP is receiver-oriented, i.e., the receiver of a data flow 259 initiates and maintains the resource reservation used for that 260 flow. 262 o RSVP maintains "soft state" in the routers, providing graceful 263 support for dynamic membership changes and automatic adaptation 264 to routing changes. 266 o RSVP provides several reservation models or "styles" (defined 267 below) to fit a variety of applications. 269 o RSVP provides transparent operation through routers that do not 270 support it. 272 Further discussion on the objectives and general justification for 273 RSVP design are presented in [RSVP93,ISInt93]. 275 The remainder of this section describes the RSVP reservation 276 services. Section 2 presents an overview of the RSVP protocol 277 mechanisms. Section 3 contains the functional specification of RSVP, 278 while Section 4 presents explicit message processing rules. Appendix 279 A defines the variable-length typed data objects used in the RSVP 280 protocol. Appendix B defines error codes and values. Appendix C 281 defines an extension for UDP encapsulation of RSVP messages. 282 Finally, some experimental RSVP features are documented in Appendix D 283 for future reference. 285 1.1 Data Flows 287 RSVP defines a "session" as a data flow with a particular 288 destination and transport-layer protocol. The destination for a 289 particular session is generally defined by DestAddress, the IP 290 destination address of the data packets, and perhaps by DstPort, a 291 " generalized destination port", i.e., some further demultiplexing 292 point in the transport or application protocol layer. RSVP treats 293 each session independently, and this document often assumes the 294 qualification "for the same session". 296 DestAddress is a group address for multicast delivery or the 297 unicast address of a single receiver. DstPort could be defined by 298 a UDP/TCP destination port field, by an equivalent field in 299 another transport protocol, or by some application-specific 300 information. Although the RSVP protocol is designed to be easily 301 extendible for greater generality, the present version supports 302 only UDP/TCP ports as generalized ports. 304 Figure 2 illustrates the flow of data packets in a single RSVP 305 session assuming multicast data distribution. The arrows indicate 306 data flowing from senders S1 and S2 to receivers R1, R2, and R3, 307 and the cloud represents the distribution mesh created by 308 multicast routing. Multicast distribution forwards a copy of each 309 data packet from a sender Si to every receiver Rj; a unicast 310 distribution session has a single receiver R. Each sender Si and 311 each receiver Rj may be running in a unique Internet host, or a 312 single host may contain multiple senders and/or receivers, 313 distinguished by generalized ports. 315 Senders Receivers 316 _____________________ 317 ( ) ===> R1 318 S1 ===> ( Multicast ) 319 ( ) ===> R2 320 ( distribution ) 321 S2 ===> ( ) 322 ( by Internet ) ===> R3 323 (_____________________) 325 Figure 2: Multicast Distribution Session 327 For unicast transmission, there will be a single destination host 328 but there may be multiple senders; RSVP can set up reservations 329 for multipoint-to-single-point transmission. 331 1.2 Reservation Model 333 An elementary RSVP reservation request consists of a "flowspec" 334 together with a "filter spec"; this pair is called a "flow 335 descriptor". The flowspec specifies a desired QoS. The filter 336 spec, together with session definition, specifies the set of data 337 packets -- the "flow" -- to receive the QoS defined by the 338 flowspec. The flowspec is used to set parameters to the node's 339 packet scheduler (assuming that admission control succeeds), while 340 the filter spec is used to set parameters in the packet 341 classifier. Data packets that are addressed to a particular 342 session but do not match any of the filter specs for that session 343 are handled as best-effort traffic. 345 Note that the action to control QoS occurs at the place where the 346 data enters the medium, i.e., at the upstream end of the link, 347 although an RSVP reservation request originates from receiver(s) 348 downstream. In this document, we define the directional terms 349 "upstream" vs. "downstream", "previous hop" vs. "next hop", and 350 "incoming interface" vs "outgoing interface" with respect to the 351 direction of data flows. 353 The flowspec in a reservation request will generally include a 354 service class and two sets of numeric parameters: (1) an "Rspec" 355 (R for `reserve') that defines the desired QoS, and (2) a "Tspec" 356 (T for `traffic') that describes the data flow. The formats and 357 contents of Tspecs and Rspecs are determined by the integrated 358 service model [ServTempl95a], and are generally opaque to RSVP. 360 In the most general approach [RSVP93], filter specs may select 361 arbitrary subsets of the packets in a given session. Such subsets 362 might be defined in terms of senders (i.e., sender IP address and 363 generalized source port), in terms of a higher-level protocol, or 364 generally in terms of any fields in any protocol headers in the 365 packet. For example, filter specs might be used to select 366 different subflows in a hierarchically-encoded signal by selecting 367 on fields in an application-layer header. However, in the 368 interest of simplicity (and to minimize layer violation), the 369 present RSVP version uses a much more restricted form of filter 370 spec, consisting of sender IP address and optionally the UDP/TCP 371 port number SrcPort. 373 RSVP reservation request messages originate at receivers and are 374 passed upstream towards the sender(s). When a reservation request 375 is received at a node, two general actions are taken. 377 1. Make a reservation 379 The flowspec and the filter spec are passed to traffic 380 control. Admission control determines the admissibility of 381 the request (if it's new); if this test fails, the 382 reservation is rejected and RSVP returns an error message to 383 the appropriate receiver(s). If admission control succeeds, 384 the node uses the flowspec to set up the packet scheduler for 385 the desired QoS and the filter spec to set the packet 386 classifier to select the appropriate data packets. 388 2. Forward the request upstream 390 The reservation request is propagated upstream towards the 391 appropriate senders. The set of sender hosts to which a 392 given reservation request is propagated is called the "scope" 393 of that request. 395 The reservation request that a node forwards upstream may differ 396 from the request that it received from downstream, for two 397 reasons. First, it is possible in theory for the traffic control 398 mechanism to modify the flowspec hop-by-hop, although none of the 399 currently defined services does so. Second, reservations for the 400 same sender, or the same set of senders, from different downstream 401 branches of the multicast tree(s) are "merged" as reservations 402 travel upstream; that is, a node forwards upstream only the 403 reservation request with the "maximum" flowspec. 405 When a receiver originates a reservation request, it can also 406 request a confirmation message to indicate that its request was 407 (probably) installed in the network. A successful reservation 408 request propagates as far as the closest point(s) along the sink 409 tree to the sender(s) where there is an existing reservation level 410 equal or greater than that being requested. At that point, the 411 arriving request will be dropped in favor of the equal or larger 412 reservation in place; the node may then send a reservation 413 confirmation message back to the receiver. Note that the receipt 414 of a confirmation is only a high-probability indication, not a 415 guarantee that the requested service is in place all the way to 416 the sender(s), as explained in Section 2.6. 418 The basic RSVP reservation model is "one pass": a receiver sends a 419 reservation request upstream, and each node in the path either 420 accepts or rejects the request. This scheme provides no easy way 421 for a receiver to find out the resulting end-to-end service. 422 Therefore, RSVP supports an enhancement to one-pass service known 423 as "One Pass With Advertising" (OPWA) [Shenker94]. With OPWA, 424 RSVP control packets are sent downstream, following the data 425 paths, to gather information that may be used to predict the end- 426 to-end QoS. The results ("advertisements") are delivered by RSVP 427 to the receiver hosts and perhaps to the receiver applications. 428 The advertisements may then be used by the receiver to construct, 429 or to dynamically adjust, an appropriate reservation request. 431 1.3 Reservation Styles 433 A reservation request includes a set of control options, which are 434 collectively called the reservation "style". 436 One option concerns the treatment of reservations for different 437 senders within the same session: establish a "distinct" 438 reservation for each upstream sender, or else make a single 439 reservation that is " shared" among all packets of selected 440 senders. 442 Another option controls the selection of senders: an "explicit" 443 list of all selected senders, or a "wildcard" that implicitly 444 selects all the senders to the session. In an explicit-selection 445 reservation, each filter spec must match exactly one sender, while 446 in a wildcard-selection no filter spec is needed. 448 Sender || Reservations: 449 Selection || Distinct | Shared 450 _________||__________________|____________________ 451 || | | 452 Explicit || Fixed-Filter | Shared-Explicit | 453 || (FF) style | (SE) Style | 454 __________||__________________|____________________| 455 || | | 456 Wildcard || (None defined) | Wildcard-Filter | 457 || | (WF) Style | 458 __________||__________________|____________________| 460 Figure 3: Reservation Attributes and Styles 462 The styles currently defined are as follows (see Figure 3): 464 o Wildcard-Filter (WF) Style 466 The WF style implies the options: "shared" reservation and " 467 wildcard" sender selection. Thus, a WF-style reservation 468 creates a single reservation into which flows from all 469 upstream senders are mixed; this reservation may be thought 470 of as a shared "pipe", whose "size" is the largest of the 471 resource requests from all receivers, independent of the 472 number of senders using it. A WF-style reservation is 473 propagated upstream towards all sender hosts, and 474 automatically extends to new senders as they appear. 476 Symbolically, we can represent a WF-style reservation request 477 by: 479 WF( * {Q}) 481 where the asterisk represents wildcard sender selection and Q 482 represents the flowspec. 484 o Fixed-Filter (FF) Style 486 The FF style implies the options: "distinct" reservations and 487 "explicit" sender selection. Thus, an elementary FF-style 488 reservation request creates a distinct reservation for data 489 packets from a particular sender, not sharing them with other 490 senders' packets for the same session. 492 The total reservation on a link for a given session is the 493 total of the FF reservations for all requested senders. On 494 the other hand, FF reservations requested by different 495 receivers Rj but selecting the same sender Si must be merged 496 to share a single reservation. 498 Symbolically, we can represent an elementary FF reservation 499 request by: 501 FF( S{Q}) 503 where S is the selected sender and Q is the corresponding 504 flowspec; the pair forms a flow descriptor. RSVP allows 505 multiple elementary FF-style reservations to be requested at 506 the same time, using a list of flow descriptors: 508 FF( S1{Q1}, S2{Q2}, ...) 510 o Shared Explicit (SE) Style 512 The SE style implies the options: "shared" reservation and " 513 explicit" sender selection. Thus, an SE-style reservation 514 creates a single reservation into which flows from all 515 upstream senders are mixed. However, like the FF style, the 516 SE style allows a receiver to explicitly specify the set of 517 senders. 519 Symbolically, we can represent an SE reservation request by: 521 SE( (S1,S2,...){Q} ), 523 i.e., a flow descriptor composed of a flowspec Q and a list 524 of senders S1, S2, etc. 526 Both WF and SE are shared reservations, appropriate for those 527 multicast applications whose application-specific constraints make 528 it unlikely that multiple data sources will transmit 529 simultaneously. Packetized audio is an example of an application 530 suitable for shared reservations; since a limited number of people 531 talk at once, each receiver might issue a WF or SE reservation 532 request for twice the bandwidth required for one sender (to allow 533 some over-speaking). On the other hand, the FF style, which 534 creates independent reservations for the flows from different 535 senders, is appropriate for video signals. 537 The RSVP rules disallow merging of shared reservations with 538 distinct reservations, since these modes are fundamentally 539 incompatible. They also disallow merging explict sender selection 540 with wildcard sender selection, since this might produce an 541 unexpected service for a receiver that specified explicit 542 selection. As a result of these prohibitions, WF, SE, and FF 543 styles are all mutually incompatible. 545 Other reservation options and styles may be defined in the future 546 (see Appendix D.4, for example). 548 1.4 Examples of Styles 550 This section presents examples of each of the reservation styles 551 and show the effects of merging. 553 Figure 4 shows schematically a router with two incoming interfaces 554 through which data streams will arrive, labeled (a) and (b), and 555 two outgoing interfaces through which data will be forwarded, 556 labeled (c) and (d). This topology will be assumed in the 557 examples that follow. There are three upstream senders; packets 558 from sender S1 (S2 and S3) arrive through previous hop (a) ((b), 559 respectively). There are also three downstream receivers; packets 560 bound for R1 (R2 and R3) are routed via outgoing interface (c) 561 ((d), respectively). We furthermore assume that R2 and R3 arrive 562 via different next hops, e.g., via the two routers D and D' in 563 Figure 9. This illustrates the effect of a non-RSVP cloud or a 564 broadcast LAN on interface (d). 566 In addition to the connectivity shown in 4, we must also specify 567 the multicast routes within this node. Assume first that data 568 packets from each Si shown in Figure 4 is routed to both outgoing 569 interfaces. Under this assumption, Figures 5, 6, and 7 illustrate 570 Wildcard-Filter, Fixed-Filter, and Shared-Explicit reservations, 571 respectively. 573 ________________ 574 (a)| | (c) 575 ( S1 ) ---------->| |----------> ( R1 ) 576 | Router | 577 (b)| | (d) 578 ( S2,S3 ) ------->| |----------> ( R2, R3 ) 579 |________________| 581 Figure 4: Router Configuration 583 For simplicity, these examples show flowspecs as one-dimensional 584 multiples of some base resource quantity B. The "Receive" column 585 shows the RSVP reservation requests received over outgoing 586 interfaces (c) and (d), and the "Reserve" column shows the 587 resulting reservation state for each interface. The "Send" 588 column shows the reservation requests that are sent upstream to 589 previous hops (a) and (b). In the "Reserve" column, each box 590 represents one reserved "pipe" on the outgoing link, with the 591 corresponding flow descriptor. 593 Figure 5, showing the WF style, illustrates the two possible 594 merging situations. Each of the two next hops on interface (d) 595 results in a separate RSVP reservation request, as shown. These 596 two requests are merged into the effective flowspec 3B, which is 597 used to make the reservation on interface (d). To forward the 598 reservation requests upstream, the reservations on the interfaces 599 (c) and (d) are merged; as a result, the larger flowspec 4B is 600 forwarded upstream to each previous hop. 602 | 603 Send | Reserve Receive 604 | 605 | _______ 606 WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) 607 | |_______| 608 | 609 -----------------------|---------------------------------------- 610 | _______ 611 WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) 612 | |_______| <- WF( *{2B} ) 614 Figure 5: Wildcard-Filter (WF) Reservation Example 616 Figure 6 shows Fixed-Filter (FF) style reservations. The flow 617 descriptors for senders S2 and S3, received from outgoing 618 interfaces (c) and (d), are packed into the request forwarded to 619 previous hop (b). On the other hand, the three different flow 620 descriptors for sender S1 are merged into the single request FF( 621 S1{4B} ), which is sent to previous hop (a). For each outgoing 622 interface, there is a separate reservation for each source that 623 has been requested, but this reservation is shared among all the 624 receivers that made the request. 626 | 627 Send | Reserve Receive 628 | 629 | ________ 630 FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} ) 631 | |________| 632 | | S2{5B} | 633 | |________| 634 ---------------------|--------------------------------------------- 635 | ________ 636 <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) 637 FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} ) 638 | | S3{B} | 639 | |________| 641 Figure 6: Fixed-Filter (FF) Reservation Example 643 Figure 7 shows an example of Shared-Explicit (SE) style 644 reservations. When SE-style reservations are merged, the 645 resulting filter spec is the union of the original filter specs. 647 | 648 Send | Reserve Receive 649 | 650 | ________ 651 SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} ) 652 | | {B} | 653 | |________| 654 ---------------------|--------------------------------------------- 655 | __________ 656 <- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} ) 657 SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} ) 658 | |__________| 660 Figure 7: Shared-Explicit (SE) Reservation Example 662 The three examples just shown assume that data packets from S1, 663 S2, and S3 are routed to both outgoing interfaces. The top part 664 of Figure 8 shows another routing assumption: data packets from S2 665 and S3 are not forwarded to interface (c), e.g., because the 666 network topology provides a shorter path for these senders towards 667 R1, not traversing this node. The bottom part of Figure 8 shows 668 WF style reservations under this assumption. Since there is no 669 route from (b) to (c), the reservation forwarded out interface (b) 670 considers only the reservation on interface (d). 672 _______________ 673 (a)| | (c) 674 ( S1 ) ---------->| >-----------> |----------> ( R1 ) 675 | - | 676 | - | 677 (b)| - | (d) 678 ( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 ) 679 |_______________| 681 Router Configuration 683 | 684 Send | Reserve Receive 685 | 686 | _______ 687 WF( *{rB} ) <- (a) | (c) | * {B} | (c) <- WF( *{4B} ) 688 | |_______| 689 | 690 -----------------------|---------------------------------------- 691 | _______ 692 WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) 693 | |_______| <- WF( * {2B} 695 Figure 8: WF Reservation Example -- Partial Routing 697 2. RSVP Protocol Mechanisms 699 2.1 RSVP Messages 701 Previous Incoming Outgoing Next 702 Hops Interfaces Interfaces Hops 704 _____ _____________________ _____ 705 | | data --> | | data --> | | 706 | A |-----------| a c |--------------| C | 707 |_____| Path --> | | Path --> |_____| 708 <-- Resv | | <-- Resv _____ 709 _____ | ROUTER | | | | 710 | | | | | |--| D | 711 | B |--| data-->| | data --> | |_____| 712 |_____| |--------| b d |-----------| 713 | Path-->| | Path --> | _____ 714 _____ | <--Resv|_____________________| <-- Resv | | | 715 | | | |--| D' | 716 | B' |--| | |_____| 717 |_____| | | 719 Figure 9: Router Using RSVP 721 Figure 9 illustrates RSVP's model of a router node. Each data 722 stream arrives from a "previous hop" through a corresponding 723 "incoming interface" and departs through one or more "outgoing 724 interface(s)". The same physical interface may act in both the 725 incoming and outgoing roles for different data flows in the same 726 session. Multiple previous hops and/or next hops may be reached 727 through a given physical interface, as a result of the connected 728 network being a shared medium, or the existence of non-RSVP 729 routers in the path to the next RSVP hop (see Section 2.8). An 730 RSVP daemon preserves the next and previous hop addresses in its 731 reservation and path state, respectively. 733 There are two fundamental RSVP message types: RESV and PATH. 735 Each receiver host sends RSVP reservation request (RESV) messages 736 upstream towards the senders. These reservation messages must 737 follow exactly the reverse of the routes the data packets will 738 use, upstream to all the sender hosts included in the sender 739 selection. RESV messages must be delivered to the sender hosts 740 themselves so that the hosts can set up appropriate traffic 741 control parameters for the first hop. 743 Each RSVP sender host transmits RSVP PATH messages downstream 744 along the uni-/multicast routes provided by the routing 745 protocol(s), following the paths of the data. These "Path" 746 messages store " path state" in each node along the way. This 747 path state includes at least the unicast IP address of the 748 previous hop node, which is used to route the RESV messages hop- 749 by-hop in the reverse direction. (In the future, some routing 750 protocols may supply reverse path forwarding information directly, 751 replacing the reverse-routing function of path state). 753 A PATH message may carry the following information in addition to 754 the previous hop address: 756 o Sender Template 758 A PATH message is required to carry a Sender Template, which 759 describes the format of data packets that the sender will 760 originate. This template is in the form of a filter spec 761 that could be used to select this sender's packets from 762 others in the same session on the same link. 764 Like a filter spec, the Sender Template is less than fully 765 general at present, specifying only the sender IP address and 766 optionally the UDP/TCP sender port. It assumes the protocol 767 Id for the session. 769 o Sender Tspec 771 A PATH message is required to carry a Sender Tspec, which 772 defines the traffic characteristics of the data stream that 773 the sender will generate. This Tspec is used by traffic 774 control to prevent over-reservation (and perhaps unnecessary 775 Admission Control failure) on all links on which the named 776 sender is the only source sending to the session. 778 o Adspec 780 A PATH message may optionally carry a package of OPWA 781 advertising information, known as an "Adspec". An Adspec 782 received in a PATH message is passed to the local traffic 783 control, which returns an updated Adspec; the updated version 784 is then forwarded downstream. 786 For protocol efficiency, RSVP also allows multiple sets of 787 reservation information for the same session to be "packed" into a 788 single RESV message. Unlike merging, packing preserves 789 information. For simplicity, however, the protocol currently 790 prohibits packing reservations of different sessions into the same 791 RSVP message. 793 PATH messages are sent with the same source and destination 794 addresses as the data, so that they will be routed correctly 795 through non-RSVP clouds (see Section 2.8). On the other hand, 796 RESV messages are sent hop-by-hop; each RSVP-speaking node 797 forwards a RESV message to the unicast address of a previous RSVP 798 hop. 800 2.2 Port Usage 802 At present an RSVP session is defined by the triple: (DestAddress, 803 ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port 804 field (i.e., a 16-bit quantity carried at octet offset +2 in the 805 transport header). DstPort may be omitted (set to zero) if the 806 ProtocolId specifies a protocol that does not have a destination 807 port field in the format used by UDP and TCP. 809 RSVP allows any value for ProtocolId. However, end-system 810 implementations of RSVP may know about certain values for this 811 field, and in particular must know about the values for UDP and 812 TCP (17 and 6, respectively). An end system should give an error 813 to an application that either: 815 o specifies a non-zero DstPort for a protocol that does not 816 have UDP/TCP-like ports, or 818 o specifies a zero DstPort for a protocol that does have 819 UDP/TCP-like ports. 821 Filter specs and sender templates are defined by the pair: 822 (SrcAddress, SrcPort), where SrcPort is a UDP/TCP source port 823 field (i.e., a 16-bit quantity carried at octet offset +0 in the 824 transport header). SrcPort may be omitted (set to zero) in 825 certain cases. The following rules hold for the use of zero 826 DstPort and/or 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 TCP/UDP- 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 request 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. This reservation should an 855 effective flowspec that is the "maximum" 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 "maximum" of the flowspecs requested by the different next hops. 859 Both cases represent flowspec merging. 861 Merging flowspecs requires calculating the "largest" of a set of 862 flowspecs, which are otherwise opaque to RSVP. Since flowspecs 863 are multi-dimensional vectors (they contain both Tspec and Rspec 864 components, each of which may itself be multi-dimensional), 865 generally speaking they cannot be strictly ordered. However, in 866 many cases one can easily determine the "larger" of two flowspecs, 867 such as when both request the same bandwidth but one requests a 868 tighter delay, or when one of the two requests both a higher 869 bandwidth and a tighter delay bound. When the "larger" of the two 870 cannot be determined, RSVP must compute and use a third flowspec 871 that is at least as large as each, i.e., a "least upper bound" 872 (LUB). If the two flowspecs are incomparable, their comparison 873 will treated as an error. 875 We can now give the complete rules for calculating the effective 876 flowspec (Te, Re) to be installed on an interface. Here Te is the 877 effective Tspec and Re is the effective Rspec. As an example, 878 consider interface (d) in Figure 9. 880 1. Re is calculated as the largest (using an LUB if necessary) 881 of the Rspecs in RESV messages from different next hops 882 (e.g., D and D') but the same outgoing interface (d). 884 2. All Tspecs that were supplied in PATH messages from different 885 previous hops (e.g., some or all of A, B, and B' in Figure 9) 886 are summed; call this sum Path_Te. 888 3. The maximum Tspec supplied in RESV messages from different 889 next hops (e.g., D and D') is calculated; call this Resv_Te. 891 4. Te is the GLB (greatest lower bound) of Path_Te and Resv_Te. 892 For Tspecs defined by token bucket parameters, this means to 893 take the smaller of the bucket size and the rate parameters. 895 Flowspecs, Tspecs, and Adspecs are opaque to RSVP. Therefore, the 896 last of these steps is actually performed by traffic control. The 897 definition and implementation of the rules for comparing 898 flowspecs, calculating LUB's, and summing Tspecs are outside the 899 definition of RSVP [ServTempl95a]. Section 3.9.4 shows generic 900 calls that an RSVP daemon could use for these functions. 902 2.4 Soft State 904 RSVP takes a "soft state" approach to managing the reservation 905 state in routers and hosts. RSVP soft state is created and 906 periodically refreshed by PATH and RESV messages. The state is 907 deleted if no matching refresh messages arrive before the 908 expiration of a "cleanup timeout" interval. It may also be 909 deleted by an explicit "teardown" message, described in the next 910 section. At the expiration of each "refresh timeout" period and 911 after a state change, RSVP scans its state to build and forward 912 PATH and RESV refresh messages to succeeding hops. 914 PATH and RESV messages are idempotent. When a route changes, the 915 next PATH message will initialize the path state on the new route, 916 and future RESV messages will establish reservation state there; 917 the state on the now-unused segment of the route will time out. 918 Thus, whether a message is "new" or a "refresh" is determined 919 separately at each node, depending upon the existing state at that 920 node. 922 RSVP sends its messages as IP datagrams with no reliability 923 enhancement. Periodic transmission of refresh messages by hosts 924 and routers is expected to handle the occasional loss of RSVP 925 messages. If the effective cleanup timeout is set to K times the 926 refresh timeout period, then RSVP can tolerate K-1 successive RSVP 927 packet losses without falsely erasing a reservation. We recommend 928 that the network traffic control mechanism be statically 929 configured to grant some minimal bandwidth for RSVP messages to 930 protect them from congestion losses. 932 The state maintained by RSVP is dynamic; to change the set of 933 senders Si or to change any QoS request, a host simply starts 934 sending revised PATH and/or RESV messages. The result should be 935 an appropriate adjustment in the RSVP state in all nodes along the 936 path. 938 In steady state, refreshing is performed hop-by-hop to allow 939 merging. If the received state differs from the stored state, the 940 stored state is updated. If this update results in modification 941 of state to be forwarded in refresh messages, these refresh 942 messages must be generated and forwarded immediately, so that 943 state changes can be propagated end-to-end without delay. 944 However, propagation of a change stops when and if it reaches a 945 point where merging causes no resulting state change. This 946 minimizes RSVP control traffic due to changes and is essential for 947 scaling to large multicast groups. 949 State that is received through a particular interface I* should 950 never be forwarded out the same interface. Conversely, state that 951 is forwarded out interface I* must be computed using only state 952 that arrived on interfaces different from I*. A trivial example 953 of this rule is illustrated in Figure 10, which shows a transit 954 router with one sender and one receiver on each interface (and 955 assumes one next/previous hop per interface). Interfaces (a) and 956 (c) serve as both outgoing and incoming interfaces for this 957 session. Both receivers are making wildcard-scope reservations, 958 in which the RESV messages are forwarded to all previous hops for 959 senders in the group, with the exception of the next hop from 960 which they came. The result is independent reservations in the 961 two directions. 963 There is an additional rule governing the forwarding of RESV 964 messages: state from RESV messages received from outgoing 965 interface Io should be forwarded to incoming interface Ii only if 966 PATH messages from Ii are forwarded to Io. 968 ________________ 969 a | | c 970 ( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) 971 |________________| 973 Send | Receive 974 | 975 WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) 976 | 977 Receive | Send 978 | 979 WF( *{4B}) --> (a) | (c) --> WF( *{4B}) 980 | 981 Reserve on (a) | Reserve on (c) 982 __________ | __________ 983 | * {4B} | | | * {3B} | 984 |__________| | |__________| 985 | 987 Figure 10: Independent Reservations 989 2.5 Teardown 991 Upon arrival, RSVP "teardown" messages remove path and reservation 992 state immediately. Although it is not necessary to explicitly 993 tear down an old reservation, we recommend that all end hosts send 994 a teardown request as soon as an application finishes. 996 There are two types of RSVP teardown message, PTEAR and RTEAR. A 997 PTEAR message travels towards all receivers downstream from its 998 point of initiation and deletes path state along the way. An 999 RTEAR message deletes reservation state and travels towards all 1000 senders upstream from its point of initiation. A PTEAR (RTEAR) 1001 message may be conceptualized as a reversed-sense Path message 1002 (Resv message, respectively). 1004 A teardown request may be initiated either by an application in an 1005 end system (sender or receiver), or by a router as the result of 1006 state timeout. Once initiated, a teardown request must be 1007 forwarded hop-by-hop without delay. A teardown message deletes 1008 the specified state in the node where it is received. As always, 1009 this state change will be propagated immediately to the next node, 1010 but only if there will be a net change after merging. As a 1011 result, an RTEAR message will prune the reservation state back 1012 (only) as far as possible. 1014 Like all other RSVP messages, teardown requests are not delivered 1015 reliably. The loss of a teardown request message will not cause a 1016 protocol failure because the unused state will eventually time out 1017 even though it is not explicitly deleted. If a teardown message 1018 is lost, the router that failed to receive that message will time 1019 out its state and initiate a new teardown message beyond the loss 1020 point. Assuming that RSVP message loss probability is small, the 1021 longest time to delete state will seldom exceed one refresh 1022 timeout period. 1024 2.6 Errors and Acknowledgments 1026 There are two RSVP error messages, RERR and PERR, and a 1027 reservation confirmation message RACK. 1029 There are a number of ways for a syntactically valid reservation 1030 request to fail at some node along the path, triggering a RERR 1031 message: 1033 1. The effective flowspec that is computed using the new request 1034 may fail admission control. 1036 2. Administrative policy may prevent the requested reservation. 1038 3. There may be no matching path state, so that the request 1039 cannot be forwarded towards the sender(s). 1041 4. A reservation style that requires the explicit selection of a 1042 unique sender may have a filter spec that is ambiguous, i.e., 1043 that matches more than one sender in the path state, due to 1044 the use of wildcard fields in the filter spec. 1046 5. The requested style may be incompatible with the style(s) of 1047 existing reservations. The incompatibility may occur among 1048 reservations for the same session on the same outgoing 1049 interface, or among effective reservations on different 1050 outgoing interfaces. 1052 In any of these cases, a RERR message is returned to the 1053 receiver(s) responsible for the erroneous request. A node may 1054 also decide to preempt an established reservation. A preemption 1055 will trigger a RERR message to all affected receivers. An error 1056 message does not modify state in the nodes through which it 1057 passes. Therefore, any reservations established downstream of the 1058 node where the failure occurred will persist until the responsible 1059 receiver(s) explicitly tear down the state or allow it to time 1060 out. 1062 In this version of RSVP, detection of an error in a reservation 1063 request not only generates a RERR message, it also prevents the 1064 request from being forwarded further. This may not always be the 1065 desirable behavior; for example, a receiver may want a reservation 1066 request to propagate all the way to the sender despite an 1067 admission control failure at a particular link along the path. 1068 However, design of the appropriate mechanism has proved difficult, 1069 and therefore this version take the simplest approach. 1071 When admission control fails for a reservation request, any 1072 existing reservation is left in place. This prevents a new, very 1073 large, reservation from disrupting the existing QoS by merging 1074 with an existing reservation and then failing admission control 1075 (this has been called the "killer reservation" problem). 1077 To request a confirmation for its reservation request, a receiver 1078 Rj includes in the RESV message a confirmation-request object 1079 containing its IP address. At each merge point, only the largest 1080 flowspec and any accompanying confirmation-request object is 1081 forwarded upstream. If the reservation request from Rj is equal 1082 to or smaller than the reservation in place on a node, its RESV 1083 are not forwarded further, and if the RESV included an 1084 confirmation-request object, a RACK message is sent back to Rj. 1085 This mechanism has the following consequences: 1087 o A new reservation request with a flowspec larger than any in 1088 place for a session will normally result in either a RERR or 1089 a RACK message back to the receiver from each sender. In 1090 this case, the RACK message will be an end-to-end 1091 confirmation. 1093 o The receipt of a RACK gives no guarantees. Assume the first 1094 two reservation requests from receivers R1 and R2 arrive at 1095 the node where they are merged. R2, whose reservation was 1096 the second to arrive at that node, may receive a RACK from 1097 that node while R1's request has not yet propagated all the 1098 way to a matching sender and may still fail. In this case, 1099 R2 will receive a RACK although there is no end-to-end 1100 reservation in place. Furthermore, if the two flowspecs are 1101 equal, R2 may receive a RACK followed by a RERR. However, if 1102 its flowspec is smaller, R2 will receive only the RACK. 1104 o Despite these uncertainties, receipt of a RACK indicates a 1105 high probability that the reservation is in place. 1107 o Finally, note that RERR and/or RACK messages may be lost. 1109 2.7 Policy and Security 1111 RSVP-mediated QoS requests will result in particular user(s) 1112 getting preferential access to network resources. To prevent 1113 abuse, some form of back pressure on users is likely to be 1114 required. This back pressure might take the form of 1115 administrative rules, or of some form of real or virtual billing 1116 for the "cost" of a reservation. The form and contents of such 1117 back pressure is a matter of administrative policy that may be 1118 determined independently by each administrative domain in the 1119 Internet. 1121 Therefore, admission control at each node is likely to contain a 1122 policy component in addition to a resource reservation component. 1123 As input to the policy-based admission decision, RSVP messages may 1124 carry policy data. This data may include credentials identifying 1125 users or user classes, account numbers, limits, quotas, etc. 1127 To protect the integrity of the policy-based admission control 1128 mechanisms, it may be necessary to ensure the integrity of RSVP 1129 messages against corruption or spoofing, hop by hop. For this 1130 purpose, RSVP messages may carry integrity objects that can be 1131 created and verified by neighbor RSVP-capable nodes. These 1132 objects are expected to contain an encrypted part and to assume a 1133 shared secret between neighbors. 1135 User policy data in reservation request messages presents a 1136 scaling problem. When a multicast group has a large number of 1137 receivers, it will be impossible or undesirable to carry all 1138 receivers' policy data upstream to the sender(s). The policy data 1139 will have to be administratively merged at places near the 1140 receivers, to avoid excessive policy data. Administrative merging 1141 implies checking the user credentials and accounting data and then 1142 substituting a token indicating the check has succeeded. A chain 1143 of trust established using an integrity field will allow upstream 1144 nodes to accept these tokens. 1146 In summary, different administrative domain in the Internet may 1147 have different policies regarding their resource usage and 1148 reservation. The role of RSVP is to carry policy data associated 1149 with each reservation to the network as needed. Note that the 1150 merge points for policy data are likely to be at the boundaries of 1151 administrative domains. It may be necessary to carry accumulated 1152 and unmerged policy data upstream through multiple nodes before 1153 reaching one of these merge points. 1155 2.8 Automatic RSVP Tunneling 1157 It is impossible to deploy RSVP (or any new protocol) at the same 1158 moment throughout the entire Internet. Furthermore, RSVP may 1159 never be deployed everywhere. RSVP must therefore provide correct 1160 protocol operation even when two RSVP-capable routers are joined 1161 by an arbitrary "cloud" of non-RSVP routers. Of course, an 1162 intermediate cloud that does not support RSVP is unable to perform 1163 resource reservation. However, if such a cloud has sufficient 1164 capacity, it may still provide acceptable realtime service. 1166 RSVP automatically tunnels through such a non-RSVP cloud. Both 1167 RSVP and non-RSVP routers forward PATH messages towards the 1168 destination address using their local uni-/multicast routing 1169 table. Therefore, the routing of PATH messages will be unaffected 1170 by non-RSVP routers in the path. When a PATH message traverses a 1171 non-RSVP cloud, it carries to the next RSVP-capable node the IP 1172 address of the last RSVP-capable router before entering the cloud. 1173 This effectively constructs a tunnel through the cloud for RESV 1174 messages, which can then be forwarded directly to the next RSVP- 1175 capable router on the path(s) back towards the source. 1177 Some interconnection topologies of RSVP and non-RSVP routers can 1178 cause RESV messages to arrive at the wrong RSVP-capable node, or 1179 to arrive at the wrong interface at the correct node. An RSVP 1180 daemon must be prepared to handle either situation. When a RESV 1181 message arrives, its IP destination address should normally be the 1182 address of one of the local interfaces. If so, the reservation 1183 should be made on the addressed interface, even if it is not the 1184 one on which the message arrived. If the destination address does 1185 not match any local interface and the message is not a PATH or 1186 PTEAR, it should be forwarded without further processing by this 1187 node. 1189 2.9 Host Model 1191 Before a session can be created, the session identification, 1192 comprised of DestAddress and perhaps the generalized destination 1193 port, must be assigned and communicated to all the senders and 1194 receivers by some out-of-band mechanism. When an RSVP session is 1195 being set up, the following events happen at the end systems. 1197 H1 A receiver joins the multicast group specified by 1198 DestAddress, using IGMP. 1200 H2 A potential sender starts sending RSVP PATH messages to the 1201 DestAddress. 1203 H3 A receiver application receives a PATH message. 1205 H4 A receiver starts sending appropriate RESV messages, 1206 specifying the desired flow descriptors. 1208 H5 A sender application receives a RESV message. 1210 H6 A sender starts sending data packets. 1212 There are several synchronization considerations. 1214 o H1 and H2 may happen in either order. 1216 o Suppose that a new sender starts sending data (H6) but there 1217 are no multicast routes because no receivers have joined the 1218 group (H1). Then the data will be dropped at some router 1219 node (which node depends upon the routing protocol) until 1220 receivers(s) appear. 1222 o Suppose that a new sender starts sending PATH messages (H2) 1223 and data (H6) simultaneously, and there are receivers but no 1224 RESV messages have reached the sender yet (e.g., because its 1225 PATH messages have not yet propagated to the receiver(s)). 1226 Then the initial data may arrive at receivers without the 1227 desired QoS. The sender could mitigate this problem by 1228 awaiting arrival of the first RESV message (H5); however, 1229 receivers that are farther away may not have reservations in 1230 place yet. 1232 o If a receiver starts sending RESV messages (H4) before 1233 receiving any PATH messages (H3), RSVP will return error 1234 messages to the receiver. 1236 The receiver may simply choose to ignore such error messages, 1237 or it may avoid them by waiting for PATH messages before 1238 sending RESV messages. [LZ: should recommend that a receiver 1239 wait for at least PATH messages to arrive before sending RESV 1240 messages.] 1242 A specific application program interface (API) for RSVP is not 1243 defined in this protocol spec, as it may be host system dependent. 1244 However, Section 3.9.1 discusses the general requirements and 1245 presen 1247 3. RSVP Functional Specification 1249 3.1 RSVP Message Formats 1251 An RSVP message consists of a common header followed by a variable 1252 number of variable-length, typed "objects". The subsections that 1253 follow define the formats of the common header, the object 1254 structures, and each of the RSVP message types. 1256 For each RSVP message type, there is a set of rules for the 1257 permissible choice and ordering of object types. These rules are 1258 specified using Backus-Naur Form (BNF) augmented with square 1259 brackets surrounding optional sub-sequences. 1261 3.1.1 Common Header 1263 0 1 2 3 1264 +-------------+-------------+-------------+-------------+ 1265 | Vers | Flags| Type | RSVP Checksum | 1266 +-------------+-------------+-------------+-------------+ 1267 | RSVP Length | (Reserved) | Send_TTL | 1268 +-------------+-------------+-------------+-------------+ 1269 | Message ID | 1270 +----------+--+-------------+-------------+-------------+ 1271 |(Reserved)|MF| Fragment offset | 1272 +----------+--+-------------+-------------+-------------+ 1274 The fields in the common header are as follows: 1276 Vers: 4 bits 1278 Protocol version number. This is version 1. 1280 Flags: 4 bits 1282 (None defined yet) 1284 Type: 8 bits 1286 1 = PATH 1288 2 = RESV 1290 3 = PERR 1292 4 = RERR 1293 5 = PTEAR 1295 6 = RTEAR 1297 7 = RACK 1299 RSVP Checksum: 16 bits 1301 A standard TCP/UDP checksum over the contents of the RSVP 1302 message, with the checksum field replaced by zero. 1304 RSVP Length: 16 bits 1306 The total length of this RSVP packet in bytes, including 1307 the common header and the variable-length objects that 1308 follow. If the MF flag is on or the Fragment Offset field 1309 is non-zero, this is the length of the current fragment of 1310 a larger message. 1312 Send_TTL: 8 bits 1314 The IP TTL value with which the message was sent. 1316 Message ID: 32 bits 1318 A label shared by all fragments of one message from a 1319 given next/previous RSVP hop. An RSVP implementation 1320 assigns a unique Message ID to each message it sends. 1322 MF: More Fragments Flag: 1 bit 1324 This flag is the low-order bit of a byte; the seven high- 1325 order bits are reserved. It is on for all but the last 1326 fragment of a message. 1328 Fragment Offset: 24 bits 1330 This field gives the byte offset of the fragment in the 1331 message. 1333 3.1.2 Object Formats 1335 Every object consists of one or more 32-bit words with a one- 1336 word header, in the following format: 1338 0 1 2 3 1339 +-------------+-------------+-------------+-------------+ 1340 | Length (bytes) | Class-Num | C-Type | 1341 +-------------+-------------+-------------+-------------+ 1342 | | 1343 // (Object contents) // 1344 | | 1345 +-------------+-------------+-------------+-------------+ 1347 An object header has the following fields: 1349 Length 1351 A 16-bit field containing the total object length in 1352 bytes. Must always be a multiple of 4, and at least 4. 1354 Class-Num 1356 Identifies the object class; values of this field are 1357 defined in Appendix A. Each object class has a name, 1358 which is always capitalized in this document. An RSVP 1359 implementation must recognize the following classes: 1361 NULL 1363 A NULL object has a Class-Num of zero, and its C-Type 1364 is ignored. Its length must be at least 4, but can 1365 be any multiple of 4. A NULL object may appear 1366 anywhere in a sequence of objects, and its contents 1367 will be ignored by the receiver. 1369 SESSION 1371 Contains the IP destination address (DestAddress), 1372 the IP protocol id, and a generalized destination 1373 port, to define a specific session for the other 1374 objects that follow. Required in every RSVP message. 1376 RSVP_HOP 1378 Carries the IP address of the RSVP-capable node that 1379 sent this message. This document refers to a 1380 RSVP_HOP object as a PHOP ("previous hop") object for 1381 downstream messages or as a NHOP ("next hop") object 1382 for upstream messages. 1384 TIME_VALUES 1386 Contains the value for the refresh period R used by 1387 the creator of the message; see 3.5. Required in 1388 every PATH and RESV message. 1390 STYLE 1392 Defines the reservation style plus style-specific 1393 information that is not in FLOWSPEC or FILTER_SPEC 1394 objects. Required in every RESV message. 1396 FLOWSPEC 1398 Defines a desired QoS, in a RESV message. 1400 FILTER_SPEC 1402 Defines a subset of session data packets that should 1403 receive the desired QoS (specified by an FLOWSPEC 1404 object), in a RESV message. 1406 SENDER_TEMPLATE 1408 Contains a sender IP address and perhaps some 1409 additional demultiplexing information to identify a 1410 sender, in a PATH message. 1412 SENDER_TSPEC 1414 Defines the traffic characteristics of a sender's 1415 data stream, in a PATH message. 1417 ADSPEC 1419 Carries OPWA data, in a PATH message. 1421 ERROR_SPEC 1423 Specifies an error, in a PERR or RERR message. 1425 POLICY_DATA 1427 Carries information that will allow a local policy 1428 module to decide whether an associated reservation is 1429 administratively permitted. May appear in a PATH or 1430 RESV message. 1432 INTEGRITY 1434 Contains cryptographic data to authenticate the 1435 originating node, and perhaps to verify the contents, 1436 of this RSVP message. 1438 SCOPE 1440 An explicit list of sender hosts towards which to 1441 forward a message. May appear in a RESV, RERR, or 1442 RTEAR message. 1444 RESV_CONFIRM 1446 Carries the IP address of a receiver that requested a 1447 confirmation. May appear in a RESV or RACK message. 1449 C-Type 1451 Object type, unique within Class-Num. Values are defined 1452 in Appendix A. 1454 The maximum object content length is 65528 bytes. The Class- 1455 Num and C-Type fields may be used together as a 16-bit number 1456 to define a unique type for each object. 1458 The high-order bit of the Class-Num is used to determine what 1459 action a node should take if it does not recognize the Class- 1460 Num of an object; see Section 3.8. 1462 3.1.3 Path Message 1464 Each sender host periodically sends a PATH message containing a 1465 description of each data stream it originates. The PATH 1466 message travels from a sender to receiver(s) along the same 1467 path(s) used by the data packets. The IP source address of a 1468 PATH message is an address of the sender it describes, while 1469 the destination address is the DestAddress for the session. 1470 These addresses assure that the message will be correctly 1471 routed through a non-RSVP cloud. 1473 Each RSVP-capable node along the path(s) captures PATH messages 1474 and processes them to build local path state. The node then 1475 forwards the PATH messages towards the receiver(s), replicating 1476 it as dictated by multicast routing, while preserving the 1477 original IP source address. PATH messages eventually reach the 1478 applications on all receivers; however, they are not looped 1479 back to a receiver running in the same application process as 1480 the sender. 1482 The format of a PATH message is as follows: 1484 ::= 1486 [ ] 1488 1490 ::= 1492 [ ] [ ] 1494 The PHOP (i.e., the RSVP_HOP) object of each PATH message 1495 contains the address of the interface through which the PATH 1496 message was most recently sent. The SENDER_TEMPLATE object 1497 defines the format of data packets from this sender, while the 1498 SENDER_TSPEC object specifies the traffic characteristics of 1499 the flow. Optionally, there may be a POLICY_DATA object 1500 specifying user credential and accounting information and/or an 1501 ADSPEC object carrying advertising (OPWA) data. 1503 A PATH message received at a node is processed to create path 1504 state for the sender defined by the SENDER_TEMPLATE and SESSION 1505 objects. Any POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are 1506 also saved in the path state. If an error is encountered while 1507 processing a PATH message, a PERR message is sent to the 1508 originating sender of the PATH message. PATH messages must 1509 satisfy the rules on SrcPort and DstPort in Section 2.2. 1511 Periodically, the RSVP daemon at a node scans the path state to 1512 create new PATH messages to forward downstream. Each message 1513 contains a sender descriptor defining one sender. The RSVP 1514 daemon forwards these messages using routing information it 1515 obtains from the appropriate uni-/multicast routing daemon. 1516 The route depends upon the session DestAddress, and for some 1517 routing protocols also upon the source (sender's IP) address. 1518 The routing information generally includes the list of none or 1519 more outgoing interfaces to which the PATH message to be 1520 forwarded. Because each outgoing interface has a different IP 1521 address, the PATH messages sent out different interfaces 1522 contain different PHOP addresses. In addition, any ADSPEC or 1523 POLICY_DATA objects carried in PATH messages will also 1524 generally differ for different outgoing interfaces. 1526 Some IP multicast routing protocols (e.g., DVMRP, PIM, and 1527 MOSPF) also keep track of the expected incoming interface for 1528 each source host to a multicast group. Whenever this 1529 information is available, RSVP should check the incoming 1530 interface of each PATH message and immediately discard those 1531 messages that have arrived on the wrong interface. 1533 3.1.4 Resv Messages 1535 RESV messages carry reservation requests hop-by-hop from 1536 receivers to senders, along the reverse paths of data flows for 1537 the session. The IP destination address of a RESV message is 1538 the unicast address of a previous-hop node, obtained from the 1539 path state. The IP source address is an address of the node 1540 that sent the message. 1542 The RESV message format is as follows: 1544 ::= 1546 [ ] 1548 [ ] 1550 [ ] [ ] 1552