idnits 2.17.1 draft-ietf-rsvp-spec-13.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-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 32 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 834 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 (August 12, 1996) is 10120 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: 'ISrsvp96' is mentioned on line 2647, but not defined == Missing Reference: 'S4' is mentioned on line 2125, but not defined == Missing Reference: 'S1' is mentioned on line 2121, but not defined == Missing Reference: 'S2' is mentioned on line 2125, but not defined == Missing Reference: 'S3' is mentioned on line 2125, but not defined == Missing Reference: 'RA' is mentioned on line 4924, but not defined == Missing Reference: 'Note 1' is mentioned on line 4930, but not defined == Missing Reference: 'Note 2' is mentioned on line 4934, but not defined == Missing Reference: 'Note 3' is mentioned on line 4937, but not defined == Unused Reference: 'ISdata96' is defined on line 4994, but no explicit reference was found in the text == Unused Reference: 'ISrsvp' is defined on line 4998, but no explicit reference was found in the text == Unused Reference: 'ISTempl96' is defined on line 5002, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Baker96' ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. 'ISInt93') -- Possible downref: Non-RFC (?) normative reference: ref. 'FJ94' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSEC96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Katz95' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISdata96' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISrsvp' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISTempl96' -- Possible downref: Non-RFC (?) normative reference: ref. 'OPWA95' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP93' Summary: 9 errors (**), 0 flaws (~~), 15 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Braden, Ed. 3 Expiration: February 1997 ISI 4 File: draft-ietf-rsvp-spec-13.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 August 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 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 33 Directories on ds.internic.net (US East Coast), nic.nordu.net 34 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 35 Rim). 37 Abstract 39 This memo describes version 1 of RSVP, a resource reservation setup 40 protocol designed for an integrated services Internet. RSVP provides 41 receiver-initiated setup of resource reservations for multicast or 42 unicast data flows, with good scaling and robustness properties. 44 Table of Contents 46 1. Introduction ........................................................3 47 1.1 Data Flows ......................................................6 48 1.2 Reservation Model ...............................................7 49 1.3 Reservation Styles ..............................................10 50 1.4 Examples of Styles ..............................................12 51 2. RSVP Protocol Mechanisms ............................................17 52 2.1 RSVP Messages ...................................................17 53 2.2 Port Usage ......................................................19 54 2.3 Merging Flowspecs ...............................................20 55 2.4 Soft State ......................................................21 56 2.5 Teardown ........................................................23 57 2.6 Errors ..........................................................24 58 2.7 Confirmation ....................................................26 59 2.8 Policy and Security .............................................26 60 2.9 Non-RSVP Clouds .................................................27 61 2.10 Host Model .....................................................28 62 3. RSVP Functional Specification .......................................30 63 3.1 RSVP Message Formats ............................................30 64 3.2 Sending RSVP Messages ...........................................43 65 3.3 Avoiding RSVP Message Loops .....................................45 66 3.4 Blockade State ..................................................48 67 3.5 Local Repair ....................................................50 68 3.6 Time Parameters .................................................51 69 3.7 Traffic Policing and Non-Integrated Service Hops ................52 70 3.8 Multihomed Hosts ................................................53 71 3.9 Future Compatibility ............................................55 72 3.10 RSVP Interfaces ................................................57 73 4. Message Processing Rules ............................................69 74 5. Acknowledgments .....................................................91 75 APPENDIX A. Object Definitions .........................................93 76 APPENDIX B. Error Codes and Values .....................................108 77 APPENDIX C. UDP Encapsulation ..........................................114 78 1. Introduction 80 This document defines RSVP, a resource reservation setup protocol 81 designed for an integrated services Internet [RSVP93,ISInt93]. 83 The RSVP protocol is used by a host, on behalf of an application data 84 stream, to request a specific quality of service (QoS) from the 85 network. The RSVP protocol is also used by routers to deliver QoS 86 control requests to all nodes along the path(s) of the data stream 87 and to establish and maintain state to provide the requested service. 88 RSVP requests will generally, although not necessarily, result in 89 resources being reserved in each node along the data path. 91 RSVP requests resources for simplex data streams, i.e., it requests 92 resources in only one direction. Therefore, RSVP treats a sender as 93 logically distinct from a receiver, although the same application 94 process may act as both a sender and a receiver at the same time. 95 RSVP operates on top of IP (either IPv4 or IPv6), occupying the place 96 of a transport protocol in the protocol stack. However, RSVP does 97 not transport application data but is rather an Internet control 98 protocol, like ICMP, IGMP, or routing protocols. Like the 99 implementations of routing and management protocols, an 100 implementation of RSVP will typically execute in the background, not 101 in the data forwarding path, as shown in Figure 1. 103 RSVP is not itself a routing protocol; RSVP is designed to operate 104 with current and future unicast and multicast routing protocols. An 105 RSVP daemon consults the local routing database(s) to obtain routes. 106 In the multicast case, for example, a host sends IGMP messages to 107 join a multicast group and then sends RSVP messages to reserve 108 resources along the delivery path(s) of that group. Routing 109 protocols determine where packets get forwarded; RSVP is only 110 concerned with the QoS of those packets that are forwarded in 111 accordance with routing. 113 In order to efficiently accommodate large groups, dynamic group 114 membership, and heterogeneous receiver requirements, RSVP makes 115 receivers responsible for requesting QoS control [RSVP93]. A QoS 116 control request from a receiver host application is passed to the 117 local RSVP implementation, shown as a daemon process in Figure 1. 118 The RSVP protocol then carries the request to all the nodes (routers 119 and hosts) along the reverse data path(s) to the data source(s). 121 HOST ROUTER 123 HOST ROUTER 125 _____________________________ ____________________________ 126 | | .-----------. | 127 | _______ ______ | / | ________ . ______ | 128 | | | | | | RSVP || | . | | | RSVP 129 | |Applic-| | RSVP <---------/ ||Routing | -> RSVP <----------> 130 | | ation<--->daemon| _____ | ||Protocol| |daemon| _____ | 131 | |_._____| | >|Polcy|| || daemon <---> >|Polcy|| 132 | | |__.__.||Cntrl|| ||__._____| |__.__.||Cntrl|| 133 | |data | .|_____|| | | | .|_____|| 134 |===|============|====.======| |===|============|====.======| 135 | | ..........| .____ | | | ..........| .____ | 136 | _V__V_ ____V___ |Admis|| | _V__V_ ____V___ |Admis|| 137 | |Class-| | ||Cntrl|| | |Class-| | ||Cntrl|| 138 | | ifier|==> Packet ||_____|| .===> ifier|==> Packet ||_____|| 139 | |______| |Schedulr|===========/ | |______| |Schedulr|===========> 140 | |________| | data | |________| | data 141 |____________________________| |____________________________| 143 Figure 1: RSVP in Hosts and Routers 145 Each node that is capable of QoS control passes incoming data packets 146 through a "packet classifier", which determines the route and the QoS 147 class for each packet. On each outgoing interface, a "packet 148 scheduler" then makes forwarding decisions for every packet, to 149 achieve the promised QoS on the particular link-layer medium used by 150 that interface. 152 At each node, an RSVP QoS control request is passed to two local 153 decision modules, "admission control" and "policy control". 154 Admission control determines whether the node has sufficient 155 available resources to supply the requested QoS. Policy control 156 determines whether the user has administrative permission to make the 157 reservation. If both checks succeed, parameters are set in the 158 packet classifier and in the scheduler, to obtain the desired QoS. 159 If either check fails, the RSVP program returns an error notification 160 to the application process that originated the request. We refer to 161 the packet classifier, packet scheduler, and admission control 162 components as "traffic control". The packet schedular and admission 163 control components implement QoS service models defined by the 164 Integrated Services Working Group. 166 RSVP protocol mechanisms provide a general facility for creating and 167 maintaining distributed reservation state across a mesh of multicast 168 or unicast delivery paths. RSVP itself transfers and manipulates QoS 169 control parameters as opaque data, passing them to the appropriate 170 traffic control modules for interpretation. The structure and 171 contents of the QoS parameters are documented in specifications 172 developed by the Integrated Services Working Group. In particular, 173 [ISrsvp96] describes these data structures and how RSVP fits into the 174 larger integrated service architecture. 176 RSVP is designed to scale well for very large multicast groups. 177 Since both the membership of a large group and the topology of large 178 multicast trees are likely to change with time, the RSVP design 179 assumes that router state for traffic control will be built and 180 destroyed incrementally. For this purpose, RSVP uses "soft state" in 181 the routers. That is, RSVP sends periodic refresh messages to 182 maintain the state along the reserved path(s); in absence of 183 refreshes, the state will automatically time out and be deleted. 185 In summary, RSVP has the following attributes: 187 o RSVP makes resource reservations for both unicast and many-to- 188 many multicast applications, adapting dynamically to changing 189 group membership as well as to changing routes. 191 o RSVP is simplex, i.e., it makes reservations for unidirectional 192 data flows. 194 o RSVP is receiver-oriented, i.e., the receiver of a data flow 195 initiates and maintains the resource reservation used for that 196 flow. 198 o RSVP maintains "soft state" in the routers, providing graceful 199 support for dynamic membership changes and automatic adaptation 200 to routing changes. 202 o RSVP is not a routing protocol but depends upon present and 203 future routing protocols. 205 o RSVP transports and maintains opaque state for traffic control, 206 and policy control. 208 o RSVP provides several reservation models or "styles" (defined 209 below) to fit a variety of applications. 211 o RSVP provides transparent operation through routers that do not 212 support it. 214 o RSVP supports both IPv4 and IPv6. 216 Further discussion on the objectives and general justification for 217 RSVP design are presented in [RSVP93] and [ISInt93]. 219 The remainder of this section describes the RSVP reservation 220 services. Section 2 presents an overview of the RSVP protocol 221 mechanisms. Section 3 contains the functional specification of RSVP, 222 while Section 4 presents explicit message processing rules. Appendix 223 A defines the variable-length typed data objects used in the RSVP 224 protocol. Appendix B defines error codes and values. Appendix C 225 defines an extension for UDP encapsulation of RSVP messages. 227 1.1 Data Flows 229 RSVP defines a "session" to be a data flow with a particular 230 destination and transport-layer protocol. The destination of a 231 session is defined by DestAddress, the IP destination address of 232 the data packets, by the IP protocol ID, and perhaps by DstPort, a 233 "generalized destination port", i.e., some further demultiplexing 234 point in the transport or application protocol layer. RSVP treats 235 each session independently, and this document often omits the 236 implied qualification "for the same session". 238 DestAddress is a group address for multicast delivery or the 239 unicast address of a single receiver. DstPort could be defined by 240 a UDP/TCP destination port field, by an equivalent field in 241 another transport protocol, or by some application-specific 242 information. Although the RSVP protocol is designed to be easily 243 extensible for greater generality, the basic protocol documented 244 here supports only UDP/TCP ports as generalized ports. Note that 245 it is not strictly necessary to include DstPort in the session 246 definition when DestAddress is multicast, since different sessions 247 can always have different multicast addresses. However, DstPort 248 is necessary to allow more than one unicast session addressed to 249 the same receiver host. 251 Figure 2 illustrates the flow of data packets in a single RSVP 252 session, assuming multicast data distribution. The arrows 253 indicate data flowing from senders S1 and S2 to receivers R1, R2, 254 and R3, and the cloud represents the distribution mesh created by 255 multicast routing. Multicast distribution forwards a copy of each 256 data packet from a sender Si to every receiver Rj; a unicast 257 distribution session has a single receiver R. Each sender Si may 258 be running in a unique Internet host, or a single host may contain 259 multiple senders distinguished by "generalized source ports". 261 Senders Receivers 262 _____________________ 263 ( ) ===> R1 264 S1 ===> ( Multicast ) 265 ( ) ===> R2 266 ( distribution ) 267 S2 ===> ( ) 268 ( by Internet ) ===> R3 269 (_____________________) 271 Figure 2: Multicast Distribution Session 273 For unicast transmission, there will be a single destination host 274 but there may be multiple senders; RSVP can set up reservations 275 for multipoint-to-single-point transmission. 277 1.2 Reservation Model 279 An elementary RSVP reservation request consists of a "flowspec" 280 together with a "filter spec"; this pair is called a "flow 281 descriptor". The flowspec specifies a desired QoS. The filter 282 spec, together with a session specification, defines the set of 283 data packets -- the "flow" -- to receive the QoS defined by the 284 flowspec. The flowspec is used to set parameters in the node's 285 packet scheduler (assuming that admission control succeeds), while 286 the filter spec is used to set parameters in the packet 287 classifier. Data packets that are addressed to a particular 288 session but do not match any of the filter specs for that session 289 are handled as best-effort traffic. 291 Note that the action to control QoS occurs at the place where the 292 data enters the medium, i.e., at the upstream end of the logical 293 or physical link, although an RSVP reservation request originates 294 from receiver(s) downstream. In this document, we define the 295 directional terms "upstream" vs. "downstream", "previous hop" vs. 296 "next hop", and "incoming interface" vs "outgoing interface" with 297 respect to the direction of data flow. 299 If the link-layer medium is QoS-active, i.e., if it has its own 300 QoS management capability, then the packet scheduler is 301 responsible for negotiation with the link layer to obtain the QoS 302 requested by RSVP. This mapping to the link layer QoS may be 303 accomplished in a number of possible ways; the details will be 304 medium-dependent. On a QoS-passive medium such as a leased line, 305 the scheduler itself allocates packet transmission capacity. The 306 scheduler may also allocate other system resources such as CPU 307 time or buffers. 309 The flowspec in a reservation request will generally include a 310 service class and two sets of numeric parameters: (1) an "Rspec" 311 (R for `reserve') that defines the desired QoS, and (2) a "Tspec" 312 (T for `traffic') that describes the data flow. The formats and 313 contents of Tspecs and Rspecs are determined by the integrated 314 service models [ISrsvp96] and are generally opaque to RSVP. 316 The exact format of a filter spec depends upon whether IPv4 or 317 IPv6 is in use; see Appendix A. In the most general approach 318 [RSVP93], filter specs may select arbitrary subsets of the packets 319 in a given session. Such subsets might be defined in terms of 320 senders (i.e., sender IP address and generalized source port), in 321 terms of a higher-level protocol, or generally in terms of any 322 fields in any protocol headers in the packet. For example, filter 323 specs might be used to select different subflows in a 324 hierarchically-encoded signal by selecting on fields in an 325 application-layer header. In the interest of simplicity (and to 326 minimize layer violation), the present RSVP version uses a much 327 more restricted form of filter spec, consisting of sender IP 328 address and optionally the UDP/TCP port number SrcPort. 330 Because the UDP/TCP port numbers are used for packet 331 classification, each router must be able to examine these fields. 332 This raises three potential problems. 334 1. It is necessary to avoid IP fragmentation of a data stream 335 for which a resource reservation is desired. 337 Document [ISrsvp96] specifies a procedure for applications 338 using RSVP facilities to compute the minimum MTU over a 339 multicast tree and return the result to the senders. 341 2. IPv6 inserts a variable number of variable-length Internet- 342 layer headers before the transport header, increasing the 343 difficulty and cost of packet classification for QoS. 345 Efficient classification of IPv6 data packets could be 346 obtained using the Flow Label field of the IPv6 header. The 347 details will be provided in the future. 349 3. IP-level Security, under either IPv4 or IPv6, may encrypt the 350 entire transport header, hiding the port numbers of data 351 packets from intermediate routers. 353 A small extension to RSVP for IP Security under IPv4 and IPv6 354 is described separately in [IPSEC96]. 356 RSVP messages carrying reservation requests originate at receivers 357 and are passed upstream towards the sender(s). At each 358 intermediate node, two general actions are taken on a request. 360 1. Make a reservation 362 The request is passed to admission control and policy 363 control. If either test fails, the reservation is rejected 364 and RSVP returns an error message to the appropriate 365 receiver(s). If both succeed, the node uses the flowspec to 366 set up the packet scheduler for the desired QoS and the 367 filter spec to set the packet classifier to select the 368 appropriate data packets. 370 2. Forward the request upstream 372 The reservation request is propagated upstream towards the 373 appropriate senders. The set of sender hosts to which a 374 given reservation request is propagated is called the "scope" 375 of that request. 377 The reservation request that a node forwards upstream may differ 378 from the request that it received from downstream, for two 379 reasons. First, the traffic control mechanism may modify the 380 flowspec hop-by-hop. Second, reservations for the same sender, or 381 the same set of senders, from different downstream branches of the 382 multicast tree(s) are "merged" as reservations travel upstream; as 383 a result, a node forwards upstream only the reservation request 384 with the "maximum" flowspec. 386 When a receiver originates a reservation request, it can also 387 request a confirmation message to indicate that its request was 388 (probably) installed in the network. A successful reservation 389 request propagates upstream along the multicast tree until it 390 reaches a point where an existing reservation is equal or greater 391 than that being requested. At that point, the arriving request is 392 merged with the reservation in place and need not be forwarded 393 further; the node may then send a reservation confirmation message 394 back to the receiver. Note that the receipt of a confirmation is 395 only a high-probability indication, not a guarantee, that the 396 requested service is in place all the way to the sender(s), as 397 explained in Section 2.7. 399 The basic RSVP reservation model is "one pass": a receiver sends a 400 reservation request upstream, and each node in the path either 401 accepts or rejects the request. This scheme provides no easy way 402 for a receiver to find out the resulting end-to-end service. 403 Therefore, RSVP supports an enhancement to one-pass service known 404 as "One Pass With Advertising" (OPWA) [OPWA95]. With OPWA, RSVP 405 control packets are sent downstream, following the data paths, to 406 gather information that may be used to predict the end-to-end QoS. 407 The results ("advertisements") are delivered by RSVP to the 408 receiver hosts and perhaps to the receiver applications. The 409 advertisements may then be used by the receiver to construct, or 410 to dynamically adjust, an appropriate reservation request. 412 1.3 Reservation Styles 414 A reservation request includes a set of options that are 415 collectively called the reservation "style". 417 One reservation option concerns the treatment of reservations for 418 different senders within the same session: establish a "distinct" 419 reservation for each upstream sender, or else make a single 420 reservation that is "shared" among all packets of selected 421 senders. 423 Another reservation option controls the selection of senders; it 424 may be an "explicit" list of all selected senders, or a "wildcard" 425 that implicitly selects all the senders to the session. In an 426 explicit sender-selection reservation, each filter spec must match 427 exactly one sender, while in a wildcard sender-selection no filter 428 spec is needed. 430 Sender || Reservations: 431 Selection || Distinct | Shared 432 _________||__________________|____________________ 433 || | | 434 Explicit || Fixed-Filter | Shared-Explicit | 435 || (FF) style | (SE) Style | 436 __________||__________________|____________________| 437 || | | 438 Wildcard || (None defined) | Wildcard-Filter | 439 || | (WF) Style | 440 __________||__________________|____________________| 442 Figure 3: Reservation Attributes and Styles 444 The following styles are currently defined (see Figure 3): 446 o Wildcard-Filter (WF) Style 448 The WF style implies the options: "shared" reservation and 449 "wildcard" sender selection. Thus, a WF-style reservation 450 creates a single reservation shared by flows from all 451 upstream senders. This reservation may be thought of as a 452 shared "pipe", whose "size" is the largest of the resource 453 requests from all receivers, independent of the number of 454 senders using it. A WF-style reservation is propagated 455 upstream towards all sender hosts, and it automatically 456 extends to new senders as they appear. 458 Symbolically, we can represent a WF-style reservation request 459 by: 461 WF( * {Q}) 463 where the asterisk represents wildcard sender selection and Q 464 represents the flowspec. 466 o Fixed-Filter (FF) Style 468 The FF style implies the options: "distinct" reservations and 469 "explicit" sender selection. Thus, an elementary FF-style 470 reservation request creates a distinct reservation for data 471 packets from a particular sender, not sharing them with other 472 senders' packets for the same session. 474 Symbolically, we can represent an elementary FF reservation 475 request by: 477 FF( S{Q}) 479 where S is the selected sender and Q is the corresponding 480 flowspec; the pair forms a flow descriptor. RSVP allows 481 multiple elementary FF-style reservations to be requested at 482 the same time, using a list of flow descriptors: 484 FF( S1{Q1}, S2{Q2}, ...) 486 The total reservation on a link for a given session is the 487 `sum' of Q1, Q2, ... for all requested senders. 489 o Shared Explicit (SE) Style 491 The SE style implies the options: "shared" reservation and 492 "explicit" sender selection. Thus, an SE-style reservation 493 creates a single reservation shared by selected upstream 494 senders. Unlike the WF style, the SE style allows a receiver 495 to explicitly specify the set of senders to be included. 497 We can represent an SE reservation request containing a 498 flowspec Q and a list of senders S1, S2, ... by: 500 SE( (S1,S2,...){Q} ) 502 Shared reservations, created by WF and SE styles, are appropriate 503 for those multicast applications in which multiple data sources 504 are unlikely to transmit simultaneously. Packetized audio is an 505 example of an application suitable for shared reservations; since 506 a limited number of people talk at once, each receiver might issue 507 a WF or SE reservation request for twice the bandwidth required 508 for one sender (to allow some over-speaking). On the other hand, 509 the FF style, which creates distinct reservations for the flows 510 from different senders, is appropriate for video signals. 512 The RSVP rules disallow merging of shared reservations with 513 distinct reservations, since these modes are fundamentally 514 incompatible. They also disallow merging explicit sender 515 selection with wildcard sender selection, since this might produce 516 an unexpected service for a receiver that specified explicit 517 selection. As a result of these prohibitions, WF, SE, and FF 518 styles are all mutually incompatible. 520 It would seem possible to simulate the effect of a WF reservation 521 using the SE style. When an application asked for WF, the RSVP 522 daemon on the receiver host could use local state to create an 523 equivalent SE reservation that explicitly listed all senders. 524 However, an SE reservation forces the packet classifier in each 525 node to explicitly select each sender in the list, while a WF 526 allows the packet classifier to simply "wild card" the sender 527 address and port. When there is a large list of senders, a WF 528 style reservation can therefore result in considerably less 529 overhead than an equivalent SE style reservation. For this 530 reason, both SE and WF are included in the protocol. 532 Other reservation options and styles may be defined in the future. 534 1.4 Examples of Styles 536 This section presents examples of each of the reservation styles 537 and shows the effects of merging. 539 Figure 4 illustrates a router with two incoming interfaces, 540 labeled (a) and (b), through which data streams will arrive, and 541 two outgoing interfaces, labeled (c) and (d), through which data 542 will be forwarded. This topology will be assumed in the examples 543 that follow. There are three upstream senders; packets from 544 sender S1 (S2 and S3) arrive through previous hop (a) ((b), 545 respectively). There are also three downstream receivers; packets 546 bound for R1 (R2 and R3) are routed via outgoing interface (c) 547 ((d), respectively). We furthermore assume that outgoing 548 interface (d) is connected to a broadcast LAN, and that R2 and R3 549 are reached via different next hop routers (not shown). 551 We must also specify the multicast routes within the node of 552 Figure 4. Assume first that data packets from each Si shown in 553 Figure 4 are routed to both outgoing interfaces. Under this 554 assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter, 555 Fixed-Filter, and Shared-Explicit reservations, respectively. 557 ________________ 558 (a)| | (c) 559 ( S1 ) ---------->| |----------> ( R1 ) 560 | Router | | 561 (b)| | (d) |---> ( R2 ) 562 ( S2,S3 ) ------->| |------| 563 |________________| |---> ( R3 ) 564 | 565 Figure 4: Router Configuration 567 For simplicity, these examples show flowspecs as one-dimensional 568 multiples of some base resource quantity B. The "Receive" column 569 shows the RSVP reservation requests received over outgoing 570 interfaces (c) and (d), and the "Reserve" column shows the 571 resulting reservation state for each interface. The "Send" 572 column shows the reservation requests that are sent upstream to 573 previous hops (a) and (b). In the "Reserve" column, each box 574 represents one reserved "pipe" on the outgoing link, with the 575 corresponding flow descriptor. 577 Figure 5, showing the WF style, illustrates two distinct 578 situations in which merging is required. (1) Each of the two next 579 hops on interface (d) results in a separate RSVP reservation 580 request, as shown; these two requests must be merged into the 581 effective flowspec, 3B, that is used to make the reservation on 582 interface (d). (2) The reservations on the interfaces (c) and (d) 583 must be merged in order to forward the reservation requests 584 upstream; as a result, the larger flowspec 4B is forwarded 585 upstream to each previous hop. 587 | 588 Send | Reserve Receive 589 | 590 | _______ 591 WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) 592 | |_______| 593 | 594 -----------------------|---------------------------------------- 595 | _______ 596 WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) 597 | |_______| <- WF( *{2B} ) 599 Figure 5: Wildcard-Filter (WF) Reservation Example 601 Figure 6 shows Fixed-Filter (FF) style reservations. The flow 602 descriptors for senders S2 and S3, received from outgoing 603 interfaces (c) and (d), are packed (not merged) into the request 604 forwarded to previous hop (b). On the other hand, the three 605 different flow descriptors specifying sender S1 are merged into 606 the single request FF( S1{4B} ) that is sent to previous hop (a). 607 For each outgoing interface, there is a separate reservation for 608 each source that has been requested, but this reservation will be 609 shared among all the receivers that made the request. 611 | 612 Send | Reserve Receive 613 | 614 | ________ 615 FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} ) 616 | |________| 617 | | S2{5B} | 618 | |________| 619 ---------------------|--------------------------------------------- 620 | ________ 621 <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) 622 FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} ) 623 | | S3{B} | 624 | |________| 626 Figure 6: Fixed-Filter (FF) Reservation Example 628 Figure 7 shows an example of Shared-Explicit (SE) style 629 reservations. When SE-style reservations are merged, the 630 resulting filter spec is the union of the original filter specs, 631 and the resulting flowspec is the largest flowspec. 633 | 634 Send | Reserve Receive 635 | 636 | ________ 637 SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} ) 638 | | {B} | 639 | |________| 640 ---------------------|--------------------------------------------- 641 | __________ 642 <- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} ) 643 SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} ) 644 | |__________| 646 Figure 7: Shared-Explicit (SE) Reservation Example 648 The three examples just shown assume that data packets from S1, 649 S2, and S3 are routed to both outgoing interfaces. The top part 650 of Figure 8 shows another routing assumption: data packets from S2 651 and S3 are not forwarded to interface (c), e.g., because the 652 network topology provides a shorter path for these senders towards 653 R1, not traversing this node. The bottom part of Figure 8 shows 654 WF style reservations under this assumption. Since there is no 655 route from (b) to (c), the reservation forwarded out interface (b) 656 considers only the reservation on interface (d). 658 _______________ 659 (a)| | (c) 660 ( S1 ) ---------->| >-----------> |----------> ( R1 ) 661 | - | 662 | - | 663 (b)| - | (d) 664 ( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 ) 665 |_______________| 667 Router Configuration 669 | 670 Send | Reserve Receive 671 | 672 | _______ 673 WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) 674 | |_______| 675 | 676 -----------------------|---------------------------------------- 677 | _______ 678 WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) 679 | |_______| <- WF( * {2B} ) 681 Figure 8: WF Reservation Example -- Partial Routing 683 2. RSVP Protocol Mechanisms 685 2.1 RSVP Messages 687 Previous Incoming Outgoing Next 688 Hops Interfaces Interfaces Hops 690 _____ _____________________ _____ 691 | | data --> | | data --> | | 692 | A |-----------| a c |--------------| C | 693 |_____| Path --> | | Path --> |_____| 694 <-- Resv | | <-- Resv _____ 695 _____ | ROUTER | | | | 696 | | | | | |--| D | 697 | B |--| data-->| | data --> | |_____| 698 |_____| |--------| b d |-----------| 699 | Path-->| | Path --> | _____ 700 _____ | <--Resv|_____________________| <-- Resv | | | 701 | | | |--| D' | 702 | B' |--| | |_____| 703 |_____| | | 705 Figure 9: Router Using RSVP 707 Figure 9 illustrates RSVP's model of a router node. Each data 708 stream arrives from a "previous hop" through a corresponding 709 "incoming interface" and departs through one or more "outgoing 710 interface"(s). The same physical interface may act in both the 711 incoming and outgoing roles for different data flows in the same 712 session. Multiple previous hops and/or next hops may be reached 713 through a given physical interface, as a result of the connected 714 network being a shared medium, or the existence of non-RSVP 715 routers in the path to the next RSVP hop (see Section 2.9). 717 There are two fundamental RSVP message types: Resv and Path. 719 Each receiver host sends RSVP reservation request (Resv) messages 720 upstream towards the senders. These messages must follow exactly 721 the reverse of the path(s) the data packets will use, upstream to 722 all the sender hosts included in the sender selection. They 723 create and maintain "reservation state" in each node along the 724 path(s). Resv messages must finally be delivered to the sender 725 hosts themselves, so that the hosts can set up appropriate traffic 726 control parameters for the first hop. The processing of Resv 727 messages was discussed previously in Section 1.2. 729 Each RSVP sender host transmits RSVP "Path" messages downstream 730 along the uni-/multicast routes provided by the routing 731 protocol(s), following the paths of the data. These Path messages 732 store "path state" in each node along the way. This path state 733 includes at least the unicast IP address of the previous hop node, 734 which is used to route the Resv messages hop-by-hop in the reverse 735 direction. (In the future, some routing protocols may supply 736 reverse path forwarding information directly, replacing the 737 reverse-routing function of path state). 739 A Path message contains the following information in addition to 740 the previous hop address: 742 o Sender Template 744 A Path message is required to carry a Sender Template, which 745 describes the format of data packets that the sender will 746 originate. This template is in the form of a filter spec 747 that could be used to select this sender's packets from 748 others in the same session on the same link. 750 Sender Templates have exactly the same expressive power and 751 format as filter specs that appear in Resv messages. 752 Therefore a Sender Template may specify only the sender IP 753 address and optionally the UDP/TCP sender port, and it 754 assumes the protocol Id specified for the session. 756 o Sender Tspec 758 A Path message is required to carry a Sender Tspec, which 759 defines the traffic characteristics of the data stream that 760 the sender will generate. This Tspec is used by traffic 761 control to prevent over-reservation, and perhaps unnecessary 762 Admission Control failures. 764 o Adspec 766 A Path message may carry a package of OPWA advertising 767 information, known as an "Adspec". An Adspec received in a 768 Path message is passed to the local traffic control, which 769 returns an updated Adspec; the updated version is then 770 forwarded in Path messages sent downstream. 772 Path messages are sent with the same source and destination 773 addresses as the data, so that they will be routed correctly 774 through non-RSVP clouds (see Section 2.9). On the other hand, 775 Resv messages are sent hop-by-hop; each RSVP-speaking node 776 forwards a Resv message to the unicast address of a previous RSVP 777 hop. 779 2.2 Port Usage 781 An RSVP session is normally defined by the triple: (DestAddress, 782 ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port 783 field (i.e., a 16-bit quantity carried at octet offset +2 in the 784 transport header). DstPort may be omitted (set to zero) if the 785 ProtocolId specifies a protocol that does not have a destination 786 port field in the format used by UDP and TCP. 788 RSVP allows any value for ProtocolId. However, end-system 789 implementations of RSVP may know about certain values for this 790 field, and in particular the values for UDP and TCP (17 and 6, 791 respectively). An end system may give an error to an application 792 that either: 794 o specifies a non-zero DstPort for a protocol that does not 795 have UDP/TCP-like ports, or 797 o specifies a zero DstPort for a protocol that does have 798 UDP/TCP-like ports. 800 Filter specs and sender templates specify the pair: (SrcAddress, 801 SrcPort), where SrcPort is a UDP/TCP source port field (i.e., a 802 16-bit quantity carried at octet offset +0 in the transport 803 header). SrcPort may be omitted (set to zero) in certain cases. 805 The following rules hold for the use of zero DstPort and/or 806 SrcPort fields in RSVP. 808 1. Destination ports must be consistent. 810 Path state and reservation state for the same DestAddress and 811 ProtocolId must each have DstPort values that are all zero or 812 all non-zero. Violation of this condition in a node is a 813 "Conflicting Dest Port" error. 815 2. Destination ports rule. 817 If DstPort in a session definition is zero, all SrcPort 818 fields used for that session must also be zero. The 819 assumption here is that the protocol does not have UDP/TCP- 820 like ports. Violation of this condition in a node is a 821 "Conflicting Src Port" error. 823 3. Source Ports must be consistent. 825 A sender host must not send path state both with and without 826 a zero SrcPort. Violation of this condition is an "Ambiguous 827 Path" error. 829 2.3 Merging Flowspecs 831 As noted earlier, a single physical interface may receive multiple 832 reservation requests from different next hops for the same session 833 and with the same filter spec, but RSVP should install only one 834 reservation on that interface. The installed reservation should 835 have an effective flowspec that is the "largest" of the flowspecs 836 requested by the different next hops. Similarly, a Resv message 837 forwarded to a previous hop should carry a flowspec that is the 838 "largest" of the flowspecs requested by the different next hops 839 (however, in certain cases the "smallest" is taken rather than the 840 largest, see Section 3.4). These cases both represent flowspec 841 merging. 843 Flowspec merging requires calculation of the "largest" of a set of 844 flowspecs. However, since flowspecs are generally multi- 845 dimensional vectors (they may contain both Tspec and Rspec 846 components, each of which may itself be multi-dimensional), it may 847 not be possible to strictly order two flowspecs. For example, if 848 one request calls for a higher bandwidth and another calls for a 849 tighter delay bound, one is not "larger" than the other. In such 850 a case, instead of taking the larger, RSVP must compute and use a 851 third flowspec that is at least as large as each. Mathematically, 852 RSVP merges flowspecs using the "least upper bound" (LUB) instead 853 of the maximum. Typically, the LUB is calculated by creating a 854 new flowspec whose components are individually either the max or 855 the min of corresponding components of the flowspecs being merged. 856 For example, the LUB of Tspecs defined by token bucket parameters 857 is computed by taking the maximums of the bucket size and the rate 858 parameters. In some cases, the GLB (Greatest Lower Bound) is 859 required instead of the LUB; this simply interchanges max and min 860 operations. 862 The following steps are used to calculate the effective flowspec 863 (Te, Re) to be installed on an interface. Here Te is the 864 effective Tspec and Re is the effective Rspec. As an example, 865 consider interface (d) in Figure 9. 867 1. RSVP calculates the LUB of the flowspecs that arrived in Resv 868 messages from different next hops (e.g., D and D') but the 869 same outgoing interface (d). 871 This calculation yields a flowspec that is opaque to RSVP but 872 actually consists of the pair (Re, Resv_Te), where Re is the 873 LUB of the Rspecs and Resv_Te is the LUB of the Tspecs from 874 the Resv messages. 876 2. RSVP calculates Path_Te, the sum of all Tspecs that were 877 supplied in Path messages from different previous hops (e.g., 878 some or all of A, B, and B' in Figure 9). 880 3. RSVP passes these two results, (Re, Resv_Te) and Path_Te, to 881 traffic control. Traffic control will compute the "minimum" 882 of Path_Te and Resv_Te in an appropriate, perhaps service- 883 dependent, manner. 885 The definition and implementation of the rules for comparing 886 flowspecs, calculating LUBs and GLBs, and summing Tspecs are 887 outside the definition of RSVP. Section 3.10.5 shows generic 888 calls that an RSVP daemon could use for these functions. 890 2.4 Soft State 892 RSVP takes a "soft state" approach to managing the reservation 893 state in routers and hosts. RSVP soft state is created and 894 periodically refreshed by Path and Resv messages. The state is 895 deleted if no matching refresh messages arrive before the 896 expiration of a "cleanup timeout" interval. State may also be 897 deleted by an explicit "teardown" message, described in the next 898 section. At the expiration of each "refresh timeout" period and 899 after a state change, RSVP scans its state to build and forward 900 Path and Resv refresh messages to succeeding hops. 902 Path and Resv messages are idempotent. When a route changes, the 903 next Path message will initialize the path state on the new route, 904 and future Resv messages will establish reservation state there; 905 the state on the now-unused segment of the route will time out. 906 Thus, whether a message is "new" or a "refresh" is determined 907 separately at each node, depending upon the existence of state at 908 that node. 910 RSVP sends its messages as IP datagrams with no reliability 911 enhancement. Periodic transmission of refresh messages by hosts 912 and routers is expected to handle the occasional loss of an RSVP 913 message. If the effective cleanup timeout is set to K times the 914 refresh timeout period, then RSVP can tolerate K-1 successive RSVP 915 packet losses without falsely deleting state. The network traffic 916 control mechanism should be statically configured to grant some 917 minimal bandwidth for RSVP messages to protect them from 918 congestion losses. 920 The state maintained by RSVP is dynamic; to change the set of 921 senders Si or to change any QoS request, a host simply starts 922 sending revised Path and/or Resv messages. The result will be an 923 appropriate adjustment in the RSVP state in all nodes along the 924 path; unused state will time out if it is not explicitly torn 925 down. 927 In steady state, refreshing is performed hop-by-hop, to allow 928 merging. When the received state differs from the stored state, 929 the stored state is updated. If this update results in 930 modification of state to be forwarded in refresh messages, these 931 refresh messages must be generated and forwarded immediately, so 932 that state changes can be propagated end-to-end without delay. 933 However, propagation of a change stops when and if it reaches a 934 point where merging causes no resulting state change. This 935 minimizes RSVP control traffic due to changes and is essential for 936 scaling to large multicast groups. 938 State that is received through a particular interface I* should 939 never be forwarded out the same interface. Conversely, state that 940 is forwarded out interface I* must be computed using only state 941 that arrived on interfaces different from I*. A trivial example 942 of this rule is illustrated in Figure 10, which shows a transit 943 router with one sender and one receiver on each interface (and 944 assumes one next/previous hop per interface). Interfaces (a) and 945 (c) serve as both outgoing and incoming interfaces for this 946 session. Both receivers are making wildcard-style reservations, 947 in which the Resv messages are forwarded to all previous hops for 948 senders in the group, with the exception of the next hop from 949 which they came. The result is independent reservations in the 950 two directions. 952 There is an additional rule governing the forwarding of Resv 953 messages: state from Resv messages received from outgoing 954 interface Io should be forwarded to incoming interface Ii only if 955 Path messages from Ii are forwarded to Io. 957 ________________ 958 a | | c 959 ( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) 960 |________________| 962 Send | Receive 963 | 964 WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) 965 | 966 Receive | Send 967 | 968 WF( *{4B}) --> (a) | (c) --> WF( *{4B}) 969 | 970 Reserve on (a) | Reserve on (c) 971 __________ | __________ 972 | * {4B} | | | * {3B} | 973 |__________| | |__________| 974 | 976 Figure 10: Independent Reservations 978 2.5 Teardown 980 Upon arrival, RSVP "teardown" messages remove path and reservation 981 state immediately. Although it is not necessary to explicitly 982 tear down an old reservation, we recommend that all end hosts send 983 a teardown request as soon as an application finishes. 985 There are two types of RSVP teardown message, PathTear and 986 ResvTear. A PathTear message travels towards all receivers 987 downstream from its point of initiation and deletes path state, as 988 well as all dependent reservation state, along the way. An 989 ResvTear message deletes reservation state and travels towards all 990 senders upstream from its point of initiation. A PathTear 991 (ResvTear) message may be conceptualized as a reversed-sense Path 992 message (Resv message, respectively). 994 A teardown request may be initiated either by an application in an 995 end system (sender or receiver), or by a router as the result of 996 state timeout or service preemption. Once initiated, a teardown 997 request must be forwarded hop-by-hop without delay. A teardown 998 message deletes the specified state in the node where it is 999 received. As always, this state change will be propagated 1000 immediately to the next node, but only if there will be a net 1001 change after merging. As a result, a ResvTear message will prune 1002 the reservation state back (only) as far as possible. 1004 Like all other RSVP messages, teardown requests are not delivered 1005 reliably. The loss of a teardown request message will not cause a 1006 protocol failure because the unused state will eventually time out 1007 even though it is not explicitly deleted. If a teardown message 1008 is lost, the router that failed to receive that message will time 1009 out its state and initiate a new teardown message beyond the loss 1010 point. Assuming that RSVP message loss probability is small, the 1011 longest time to delete state will seldom exceed one refresh 1012 timeout period. 1014 It should be possible to tear down any subset of the established 1015 state. For path state, the granularity for teardown is a single 1016 sender. For reservation state, the granularity is an individual 1017 filter spec. For example, refer to Figure 7. Receiver R1 could 1018 send a ResvTear message for sender S2 only (or for any subset of 1019 the filter spec list), leaving S1 in place. 1021 A ResvTear message specifies the style and filters; any flowspec 1022 is ignored. Whatever flowspec is in place will be removed if all 1023 its filter specs are torn down. 1025 2.6 Errors 1027 There are two RSVP error messages, ResvErr and PathErr. PathErr 1028 messages are very simple; they are simply sent upstream to the 1029 sender that created the error, and they do not change path state 1030 in the nodes though which they pass. There are only a few 1031 possible causes of path errors. 1033 However, there are a number of ways for a syntactically valid 1034 reservation request to fail at some node along the path. A node 1035 may also decide to preempt an established reservation. The 1036 handling of ResvErr messages is somewhat complex (Section 3.4). 1037 Since a request that fails may be the result of merging a number 1038 of requests, a reservation error must be reported to all of the 1039 responsible receivers. In addition, merging heterogeneous 1040 requests creates a potential difficulty known as the "killer 1041 reservation" problem, in which one request could deny service to 1042 another. There are actually two killer-reservation problems. 1044 1. The first killer reservation problem (KR-I) arises when there 1045 is already a reservation Q0 in place. If another receiver 1046 now makes a larger reservation Q1 > Q0, the result of merging 1047 Q0 and Q1 may be rejected by admission control in some 1048 upstream node. This must not deny service to Q0. 1050 The solution to this problem is simple: when admission 1051 control fails for a reservation request, any existing 1052 reservation is left in place. 1054 2. The second killer reservation problem (KR-II) is the 1055 converse: the receiver making a reservation Q1 is persistent 1056 even though Admission Control is failing for Q1 in some node. 1057 This must not prevent a different receiver from now 1058 establishing a smaller reservation Q0 that would succeed if 1059 not merged with Q1. 1061 To solve this problem, a ResvErr message establishes 1062 additional state, called "blockade state", in each node 1063 through which it passes. Blockade state in a node modifies 1064 the merging procedure to omit the offending flowspec (Q1 in 1065 the example) from the merge, allowing a smaller request to be 1066 forwarded and established. The Q1 reservation state is said 1067 to be "blockaded". Detailed rules are presented in Section 1068 3.4. 1070 A reservation request that fails Admission Control creates 1071 blockade state but is left in place in nodes downstream of the 1072 failure point. It has been suggested that these reservations 1073 downstream from the failure represent "wasted" reservations and 1074 should be timed out if not actively deleted. However, the 1075 downstream reservations are left in place, for the following 1076 reasons: 1078 o There are two possible reasons for a receiver persisting in a 1079 failed reservation: (1) it is polling for resource 1080 availability along the entire path, or (2) it wants to obtain 1081 the desired QoS along as much of the path as possible. 1082 Certainly in the second case, and perhaps in the first case, 1083 the receiver will want to hold onto the reservations it has 1084 made downstream from the failure. 1086 o If these downstream reservations were not retained, the 1087 responsiveness of RSVP to certain transient failures would be 1088 impaired. For example, suppose a route "flaps" to an 1089 alternate route that is congested, so an existing reservation 1090 suddenly fails, then quickly recovers to the original route. 1091 The blockade state in each downstream router must not remove 1092 the state or prevent its immediate refresh. 1094 o If we did not refresh the downstream reservations, they might 1095 time out, to be restored every Tb seconds (where Tb is the 1096 blockade state timeout interval). Such intermittent behavior 1097 might be very distressing for users. 1099 2.7 Confirmation 1101 To request a confirmation for its reservation request, a receiver 1102 Rj includes in the Resv message a confirmation-request object 1103 containing Rj's IP address. At each merge point, only the largest 1104 flowspec and any accompanying confirmation-request object is 1105 forwarded upstream. If the reservation request from Rj is equal 1106 to or smaller than the reservation in place on a node, its Resv 1107 are not forwarded further, and if the Resv included a 1108 confirmation-request object, a ResvConf message is sent back to 1109 Rj. If the confirmation request is forwarded, it is forwarded 1110 immediately, and no more than once for each request. 1112 This confirmation mechanism has the following consequences: 1114 o A new reservation request with a flowspec larger than any in 1115 place for a session will normally result in either a ResvErr 1116 or a ResvConf message back to the receiver from each sender. 1117 In this case, the ResvConf message will be an end-to-end 1118 confirmation. 1120 o The receipt of a ResvConf gives no guarantees. Assume the 1121 first two reservation requests from receivers R1 and R2 1122 arrive at the node where they are merged. R2, whose 1123 reservation was the second to arrive at that node, may 1124 receive a ResvConf from that node while R1's request has not 1125 yet propagated all the way to a matching sender and may still 1126 fail. Thus, R2 may receive a ResvConf although there is no 1127 end-to-end reservation in place; furthermore, R2 may receive 1128 a ResvConf followed by a ResvErr. 1130 2.8 Policy and Security 1132 RSVP-mediated QoS requests will result in particular user(s) 1133 getting preferential access to network resources. To prevent 1134 abuse, some form of back pressure on users is likely to be 1135 required. This back pressure might take the form of 1136 administrative rules, or of some form of real or virtual billing 1137 for the "cost" of a reservation. The form and contents of such 1138 back pressure is a matter of administrative policy that may be 1139 determined independently by each administrative domain in the 1140 Internet. 1142 Therefore, there is likely to be policy control as well as 1143 admission control over the establishment of reservations. As 1144 input to policy control, RSVP messages may carry "policy data". 1145 Policy data may include credentials identifying users or user 1146 classes, account numbers, limits, quotas, etc. RSVP will pass the 1147 "policy data" to a "Local Policy Module" (LPM) for a decision. 1149 To protect the integrity of the policy control mechanisms, it may 1150 be necessary to ensure the integrity of RSVP messages against 1151 corruption or spoofing, hop by hop. For this purpose, RSVP 1152 messages may carry integrity objects that can be created and 1153 verified by neighbor RSVP-capable nodes. These objects use a 1154 keyed cryptographic digest technique and assume that RSVP 1155 neighbors share a secret [Baker96]. 1157 User policy data in reservation request messages presents a 1158 scaling problem. When a multicast group has a large number of 1159 receivers, it will be impossible or undesirable to carry all 1160 receivers' policy data upstream to the sender(s). The policy data 1161 will have to be administratively merged at places near the 1162 receivers, to avoid excessive policy data. Administrative merging 1163 implies checking the user credentials and accounting data and then 1164 substituting a token indicating the check has succeeded. A chain 1165 of trust established using integrity fields will allow upstream 1166 nodes to accept these tokens. 1168 In summary, different administrative domains in the Internet may 1169 have different policies regarding their resource usage and 1170 reservation. The role of RSVP is to carry policy data associated 1171 with each reservation to the network as needed. Note that the 1172 merge points for policy data are likely to be at the boundaries of 1173 administrative domains. It may be necessary to carry accumulated 1174 and unmerged policy data upstream through multiple nodes before 1175 reaching one of these merge points. 1177 This document does not specify the contents of policy data, the 1178 structure of an LPM, or any generic policy models. These will be 1179 defined in the future. 1181 2.9 Non-RSVP Clouds 1183 It is impossible to deploy RSVP (or any new protocol) at the same 1184 moment throughout the entire Internet. Furthermore, RSVP may 1185 never be deployed everywhere. RSVP must therefore provide correct 1186 protocol operation even when two RSVP-capable routers are joined 1187 by an arbitrary "cloud" of non-RSVP routers. Of course, an 1188 intermediate cloud that does not support RSVP is unable to perform 1189 resource reservation. However, if such a cloud has sufficient 1190 capacity, it may still provide useful realtime service. 1192 RSVP is designed to operate correctly through such a non-RSVP 1193 cloud. Both RSVP and non-RSVP routers forward Path messages 1194 towards the destination address using their local uni-/multicast 1195 routing table. Therefore, the routing of Path messages will be 1196 unaffected by non-RSVP routers in the path. When a Path message 1197 traverses a non-RSVP cloud, it carries to the next RSVP-capable 1198 node the IP address of the last RSVP-capable router before 1199 entering the cloud. An Resv message is then forwarded directly to 1200 the next RSVP-capable router on the path(s) back towards the 1201 source. 1203 Even though RSVP operates correctly through a non-RSVP cloud, the 1204 non-RSVP-capable nodes will in general perturb the QoS provided to 1205 a receiver. Therefore, RSVP passes a `NonRSVP' flag bit to the 1206 local traffic control mechanism when there are non-RSVP-capable 1207 hops in the path to a given sender. Traffic control combines this 1208 flag bit with its own sources of information, and forwards the 1209 composed information on integrated service capability along the 1210 path to receivers using Adspecs [ISrsvp96]. 1212 Some topologies of RSVP routers and non-RSVP routers can cause 1213 Resv messages to arrive at the wrong RSVP-capable node, or to 1214 arrive at the wrong interface of the correct node. An RSVP daemon 1215 must be prepared to handle either situation. If the destination 1216 address does not match any local interface and the message is not 1217 a Path or PathTear, the message must be forwarded without further 1218 processing by this node. To handle the wrong interface case, a 1219 "Logical Interface Handle" (LIH) is used. The previous hop 1220 information included in a Path message includes not only the IP 1221 address of the previous node but also an LIH defining the logical 1222 outgoing interface; both values are stored in the path state. A 1223 Resv message arriving at the addressed node carries both the IP 1224 address and the LIH of the correct outgoing interface, i.e, the 1225 interface that should receive the requested reservation, 1226 regardless of which interface it arrives on. 1228 The LIH may also be useful when RSVP reservations are made over a 1229 complex link layer, to map between IP layer and link layer flow 1230 entities. 1232 2.10 Host Model 1234 Before a session can be created, the session identification, 1235 comprised of DestAddress, ProtocolId, and perhaps the generalized 1236 destination port, must be assigned and communicated to all the 1237 senders and receivers by some out-of-band mechanism. When an RSVP 1238 session is being set up, the following events happen at the end 1239 systems. 1241 H1 A receiver joins the multicast group specified by 1242 DestAddress, using IGMP. 1244 H2 A potential sender starts sending RSVP Path messages to the 1245 DestAddress. 1247 H3 A receiver application receives a Path message. 1249 H4 A receiver starts sending appropriate Resv messages, 1250 specifying the desired flow descriptors. 1252 H5 A sender application receives a Resv message. 1254 H6 A sender starts sending data packets. 1256 There are several synchronization considerations. 1258 o H1 and H2 may happen in either order. 1260 o Suppose that a new sender starts sending data (H6) but there 1261 are no multicast routes because no receivers have joined the 1262 group (H1). Then the data will be dropped at some router 1263 node (which node depends upon the routing protocol) until 1264 receivers(s) appear. 1266 o Suppose that a new sender starts sending Path messages (H2) 1267 and data (H6) simultaneously, and there are receivers but no 1268 Resv messages have reached the sender yet (e.g., because its 1269 Path messages have not yet propagated to the receiver(s)). 1270 Then the initial data may arrive at receivers without the 1271 desired QoS. The sender could mitigate this problem by 1272 awaiting arrival of the first Resv message (H5); however, 1273 receivers that are farther away may not have reservations in 1274 place yet. 1276 o If a receiver starts sending Resv messages (H4) before 1277 receiving any Path messages (H3), RSVP will return error 1278 messages to the receiver. 1280 The receiver may simply choose to ignore such error messages, 1281 or it may avoid them by waiting for Path messages before 1282 sending Resv messages. 1284 A specific application program interface (API) for RSVP is not 1285 defined in this protocol spec, as it may be host system dependent. 1286 However, Section 3.10.1 discusses the general requirements and 1287 outlines a generic interface. 1289 3. RSVP Functional Specification 1291 3.1 RSVP Message Formats 1293 An RSVP message consists of a common header, followed by a body 1294 consisting of a variable number of variable-length, typed 1295 "objects". The following subsections define the formats of the 1296 common header, the standard object header, and each of the RSVP 1297 message types. 1299 For each RSVP message type, there is a set of rules for the 1300 permissible choice of object types. These rules are specified 1301 using Backus-Naur Form (BNF) augmented with square brackets 1302 surrounding optional sub-sequences. The BNF implies an order for 1303 the objects in a message. However, in many (but not all) cases, 1304 object order makes no logical difference. An implementation 1305 should create messages with the objects in the order shown here, 1306 but accept the objects in any permissible order. 1308 3.1.1 Common Header 1310 0 1 2 3 1311 +-------------+-------------+-------------+-------------+ 1312 | Vers | Flags| Msg Type | RSVP Checksum | 1313 +-------------+-------------+-------------+-------------+ 1314 | Send_TTL | (Reserved) | RSVP Length | 1315 +-------------+-------------+-------------+-------------+ 1317 The fields in the common header are as follows: 1319 Vers: 4 bits 1321 Protocol version number. This is version 1. 1323 Flags: 4 bits 1325 0x01-0x08: Reserved 1327 No flag bits are defined yet. 1329 Msg Type: 8 bits 1331 1 = Path 1333 2 = Resv 1334 3 = PathErr 1336 4 = ResvErr 1338 5 = PathTear 1340 6 = ResvTear 1342 7 = ResvConf 1344 RSVP Checksum: 16 bits 1346 The one's complement of the one's complement sum of the 1347 message, with the checksum field replaced by zero for the 1348 purpose of computing the checksum. An all-zero value 1349 means that no checksum was transmitted. 1351 Send_TTL: 8 bits 1353 The IP TTL value with which the message was sent. See 1354 Section 3.7. 1356 RSVP Length: 16 bits 1358 The total length of this RSVP message in bytes, including 1359 the common header and the variable-length objects that 1360 follow. 1362 3.1.2 Object Formats 1364 Every object consists of one or more 32-bit words with a one- 1365 word header, in the following format: 1367 0 1 2 3 1368 +-------------+-------------+-------------+-------------+ 1369 | Length (bytes) | Class-Num | C-Type | 1370 +-------------+-------------+-------------+-------------+ 1371 | | 1372 // (Object contents) // 1373 | | 1374 +-------------+-------------+-------------+-------------+ 1376 An object header has the following fields: 1378 Length 1380 A 16-bit field containing the total object length in 1381 bytes. Must always be a multiple of 4, and at least 4. 1383 Class-Num 1385 Identifies the object class; values of this field are 1386 defined in Appendix A. Each object class has a name, 1387 which is always capitalized in this document. An RSVP 1388 implementation must recognize the following classes: 1390 NULL 1392 A NULL object has a Class-Num of zero, and its C-Type 1393 is ignored. Its length must be at least 4, but can 1394 be any multiple of 4. A NULL object may appear 1395 anywhere in a sequence of objects, and its contents 1396 will be ignored by the receiver. 1398 SESSION 1400 Contains the IP destination address (DestAddress), 1401 the IP protocol id, and some form of generalized 1402 destination port, to define a specific session for 1403 the other objects that follow. Required in every 1404 RSVP message. 1406 RSVP_HOP 1408 Carries the IP address of the RSVP-capable node that 1409 sent this message and a logical outgoing interface 1410 handle (LIH; see Section 3.2). This document refers 1411 to a RSVP_HOP object as a PHOP ("previous hop") 1412 object for downstream messages or as a NHOP (" next 1413 hop") object for upstream messages. 1415 TIME_VALUES 1417 Contains the value for the refresh period R used by 1418 the creator of the message; see Section 3.6. 1419 Required in every Path and Resv message. 1421 STYLE 1423 Defines the reservation style plus style-specific 1424 information that is not in FLOWSPEC or FILTER_SPEC 1425 objects. Required in every Resv message. 1427 FLOWSPEC 1428 Defines a desired QoS, in a Resv message. 1430 FILTER_SPEC 1432 Defines a subset of session data packets that should 1433 receive the desired QoS (specified by a FLOWSPEC 1434 object), in a Resv message. 1436 SENDER_TEMPLATE 1438 Contains a sender IP address and perhaps some 1439 additional demultiplexing information to identify a 1440 sender. Required in a Path message. 1442 SENDER_TSPEC 1444 Defines the traffic characteristics of a sender's 1445 data stream. Required in a Path message. 1447 ADSPEC 1449 Carries OPWA data, in a Path message. 1451 ERROR_SPEC 1453 Specifies an error in a PathErr, ResvErr, or a 1454 confirmation in a ResvConf message. 1456 POLICY_DATA 1458 Carries information that will allow a local policy 1459 module to decide whether an associated reservation is 1460 administratively permitted. May appear in Path, 1461 Resv, PathErr, or ResvErr message. 1463 The use of POLICY_DATA objects is not fully specified 1464 at this time; a future document will fill this gap. 1466 INTEGRITY 1468 Carries cryptographic data to authenticate the 1469 originating node and to verify the contents of this 1470 RSVP message. The use of the INTEGRITY object is 1471 described in [Baker96]. 1473 SCOPE 1475 Carries an explicit list of sender hosts towards 1476 which the information in the message is to be 1477 forwarded. May appear in a Resv, ResvErr, or 1478 ResvTear message. See Section 3.3. 1480 RESV_CONFIRM 1482 Carries the IP address of a receiver that requested a 1483 confirmation. May appear in a Resv or ResvConf 1484 message. 1486 C-Type 1488 Object type, unique within Class-Num. Values are defined 1489 in Appendix A. 1491 The maximum object content length is 65528 bytes. The Class- 1492 Num and C-Type fields may be used together as a 16-bit number 1493 to define a unique type for each object. 1495 The high-order two bits of the Class-Num is used to determine 1496 what action a node should take if it does not recognize the 1497 Class-Num of an object; see Section 3.9. 1499 3.1.3 Path Messages 1501 Each sender host periodically sends a Path message for each 1502 data stream it originates. The Path message travels from a 1503 sender to receiver(s) along the same path(s) used by the data 1504 packets. The IP source address of a Path message is an address 1505 of the sender it describes, while the destination address is 1506 the DestAddress for the session. These addresses assure that 1507 the message will be correctly routed through a non-RSVP cloud. 1509 The format of a Path message is as follows: 1511 ::= [ ] 1513 1515 1517 [ ... ] 1519 1521 ::= 1523 [ ] 1525 If the INTEGRITY object is present, it must immediately follow 1526 the common header. There are no other requirements on 1527 transmission order, although the above order is recommended. 1528 Any number of POLICY_DATA objects may appear. 1530 The PHOP (i.e., the RSVP_HOP) object of each Path message 1531 contains the previous hop address, i.e., the IP address of the 1532 interface through which the Path message was most recently 1533 sent. It also carries a logical interface handle (LIH). 1535 The SENDER_TEMPLATE object defines the format of data packets 1536 from this sender, while the SENDER_TSPEC object specifies the 1537 traffic characteristics of the flow. Optionally, there may be 1538 an ADSPEC object carrying advertising (OPWA) data. 1540 Each RSVP-capable node along the path(s) captures a Path 1541 message and processes it to create path state for the sender 1542 defined by the SENDER_TEMPLATE and SESSION objects. Any 1543 POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in 1544 the path state. If an error is encountered while processing a 1545 Path message, a PathErr message is sent to the originating 1546 sender of the Path message. Path messages must satisfy the 1547 rules on SrcPort and DstPort in Section 2.2. 1549 Periodically, the RSVP daemon at a node scans the path state to 1550 create new Path messages to forward towards the receiver(s). 1551 Each message contains a sender descriptor defining one sender, 1552 and carries the original sender's IP address as its IP source 1553 address. Path messages eventually reach the applications on 1554 all receivers; however, they are not looped back to a receiver 1555 running in the same application process as the sender. 1557 The RSVP daemon forwards Path messages, and replicates them as 1558 required, using routing information it obtains from the 1559 appropriate uni-/multicast routing daemon. The route depends 1560 upon the session DestAddress, and for some routing protocols 1561 also upon the source (sender's IP) address. The routing 1562 information generally includes the list of zero or more 1563 outgoing interfaces to which the Path message is to be 1564 forwarded. Because each outgoing interface has a different IP 1565 address, the Path messages sent out different interfaces 1566 contain different PHOP addresses. In addition, ADSPEC objects 1567 carried in Path messages will also generally differ for 1568 different outgoing interfaces. 1570 Some IP multicast routing protocols (e.g., DVMRP, PIM, and 1571 MOSPF) also keep track of the expected incoming interface for 1572 each source host to a multicast group. Whenever this 1573 information is available, RSVP should check the incoming 1574 interface of each Path message and do special handling of those 1575 messages Path messages that have arrived on the wrong 1576 interface; see Section 3.8. 1578 3.1.4 Resv Messages 1580 Resv messages carry reservation requests hop-by-hop from 1581 receivers to senders, along the reverse paths of data flows for 1582 the session. The IP destination address of a Resv message is 1583 the unicast address of a previous-hop node, obtained from the 1584 path state. The IP source address is an address of the node 1585 that sent the message. 1587 The Resv message format is as follows: 1589 ::= [ ] 1591 1593 1595 [ ] [ ] 1597 [ ... ] 1599