idnits 2.17.1 draft-ietf-rsvp-spec-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 31 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 785 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 (November 5, 1996) is 10034 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 2127, but not defined == Missing Reference: 'S1' is mentioned on line 2123, but not defined == Missing Reference: 'S2' is mentioned on line 2127, but not defined == Missing Reference: 'S3' is mentioned on line 2127, but not defined == Missing Reference: 'RA' is mentioned on line 3838, but not defined == Missing Reference: 'Note 1' is mentioned on line 3809, but not defined == Missing Reference: 'Note 2' is mentioned on line 3814, but not defined == Missing Reference: 'Note 3' is mentioned on line 3830, but not defined == Unused Reference: 'ISdata96' is defined on line 4306, but no explicit reference was found in the text == Unused Reference: 'ISTempl96' is defined on line 4314, 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. 'ISrsvp96' -- 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 (~~), 13 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: May 1997 ISI 4 File: draft-ietf-rsvp-spec-14.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 November 5, 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 Merging Flowspecs ...............................................19 54 2.3 Soft State ......................................................20 55 2.4 Teardown ........................................................22 56 2.5 Errors ..........................................................23 57 2.6 Confirmation ....................................................25 58 2.7 Policy and Security .............................................25 59 2.8 Non-RSVP Clouds .................................................26 60 2.9 Host Model ......................................................27 61 3. RSVP Functional Specification .......................................29 62 3.1 RSVP Message Formats ............................................29 63 3.2 Port Usage ......................................................42 64 3.3 Sending RSVP Messages ...........................................43 65 3.4 Avoiding RSVP Message Loops .....................................45 66 3.5 Blockade State ..................................................48 67 3.6 Local Repair ....................................................50 68 3.7 Time Parameters .................................................51 69 3.8 Traffic Policing and Non-Integrated Service Hops ................52 70 3.9 Multihomed Hosts ................................................53 71 3.10 Future Compatibility ...........................................55 72 3.11 RSVP Interfaces ................................................57 73 APPENDIX A. Object Definitions .........................................69 74 APPENDIX B. Error Codes and Values .....................................84 75 APPENDIX C. UDP Encapsulation ..........................................89 76 APPENDIX D. Glossary ...................................................93 77 1. Introduction 79 This document defines RSVP, a resource reservation setup protocol 80 designed for an integrated services Internet [RSVP93,ISInt93]. 82 The RSVP protocol is used by a host, on behalf of an application data 83 stream, to request a specific quality of service (QoS) from the 84 network for particular data streams or flows. The RSVP protocol is 85 also used by routers to deliver QoS control requests to all nodes 86 along the path(s) of the flows and to establish and maintain state to 87 provide the requested service. RSVP requests will generally, 88 although not necessarily, result in resources being reserved in each 89 node along the data path. 91 RSVP requests resources for simplex flows, 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 process 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 process. The RSVP protocol then carries the request to 118 all the nodes (routers and hosts) along the reverse data path(s) to 119 the data source(s). 121 HOST ROUTER 123 _____________________________ ____________________________ 124 | _______ | | | 125 | | | _______ | | _______ | 126 | |Appli- | | | |RSVP | | | | 127 | | cation| | RSVP <---------------------------> RSVP <----------> 128 | | <--> | | | _______ | | | 129 | | | |process| _____ | ||Routing| |process| _____ | 130 | |_._____| | -->Polcy|| || <--> -->Polcy|| 131 | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl|| 132 | |data | | |_____|| ||__.____| | | |_____|| 133 |===|===========|==|==========| |===|==========|==|==========| 134 | | --------| | _____ | | | --------| | _____ | 135 | | | | ---->Admis|| | | | | ---->Admis|| 136 | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| 137 | | | | | |_____|| | | | | ||_____|| 138 | |Class-| | Packet | | | |Class-| | Packet | | 139 | | ifier|==>Schedulr|================> ifier|==>Schedulr|===========> 140 | |______| |________| |data | |______| |________| |data 141 | | | | 142 |_____________________________| |____________________________| 144 Figure 1: RSVP in Hosts and Routers 146 Each node that is capable of QoS control passes incoming data packets 147 through a "packet classifier", which determines the route and the QoS 148 class for each packet. On each outgoing interface, a "packet 149 scheduler" then makes forwarding decisions for every packet, to 150 achieve the promised QoS on the particular link-layer medium used by 151 that interface. 153 At each node, an RSVP QoS control request is passed to two local 154 decision modules, "admission control" and "policy control". 155 Admission control determines whether the node has sufficient 156 available resources to supply the requested QoS. Policy control 157 determines whether the user has administrative permission to make the 158 reservation. If both checks succeed, parameters are set in the 159 packet classifier and in the scheduler, to obtain the desired QoS. 160 If either check fails, the RSVP program returns an error notification 161 to the application process that originated the request. We refer to 162 the packet classifier, packet scheduler, and admission control 163 components as "traffic control". The packet scheduler and admission 164 control components implement QoS service models defined by the 165 Integrated Services Working Group. 167 RSVP protocol mechanisms provide a general facility for creating and 168 maintaining distributed reservation state across a mesh of multicast 169 or unicast delivery paths. RSVP itself transfers and manipulates QoS 170 control parameters as opaque data, passing them to the appropriate 171 traffic control modules for interpretation. The structure and 172 contents of the QoS parameters are documented in specifications 173 developed by the Integrated Services Working Group. In particular, 174 [ISrsvp96] describes these data structures and how RSVP fits into the 175 larger integrated service architecture. 177 RSVP is designed to scale well for very large multicast groups. 178 Since both the membership of a large group and the topology of large 179 multicast trees are likely to change with time, the RSVP design 180 assumes that router state for traffic control will be built and 181 destroyed incrementally. For this purpose, RSVP uses "soft state" in 182 the routers. That is, RSVP sends periodic refresh messages to 183 maintain the state along the reserved path(s); in absence of 184 refreshes, the state will automatically time out and be deleted. 186 In summary, RSVP has the following attributes: 188 o RSVP makes resource reservations for both unicast and many-to- 189 many multicast applications, adapting dynamically to changing 190 group membership as well as to changing routes. 192 o RSVP is simplex, i.e., it makes reservations for unidirectional 193 data flows. 195 o RSVP is receiver-oriented, i.e., the receiver of a data flow 196 initiates and maintains the resource reservation used for that 197 flow. 199 o RSVP maintains "soft state" in the routers, providing graceful 200 support for dynamic membership changes and automatic adaptation 201 to routing changes. 203 o RSVP is not a routing protocol but depends upon present and 204 future routing protocols. 206 o RSVP transports and maintains opaque state for traffic control, 207 and policy control. 209 o RSVP provides several reservation models or "styles" (defined 210 below) to fit a variety of applications. 212 o RSVP provides transparent operation through routers that do not 213 support it. 215 o RSVP supports both IPv4 and IPv6. 217 Further discussion on the objectives and general justification for 218 RSVP design are presented in [RSVP93] and [ISInt93]. 220 The remainder of this section describes the RSVP reservation 221 services. Section 2 presents an overview of the RSVP protocol 222 mechanisms. Section 3 contains the functional specification of RSVP, 223 while Section 4 presents explicit message processing rules. Appendix 224 A defines the variable-length typed data objects used in the RSVP 225 protocol. Appendix B defines error codes and values. Appendix C 226 defines an extension for UDP encapsulation of RSVP messages. 228 1.1 Data Flows 230 RSVP defines a "session" to be a data flow with a particular 231 destination and transport-layer protocol. The destination of a 232 session is defined by DestAddress, the IP destination address of 233 the data packets, by the IP protocol ID, and perhaps by DstPort, a 234 "generalized destination port", i.e., some further demultiplexing 235 point in the transport or application protocol layer. RSVP treats 236 each session independently, and this document often omits the 237 implied qualification "for the same session". 239 DestAddress is a group address for multicast delivery or the 240 unicast address of a single receiver. DstPort could be defined by 241 a UDP/TCP destination port field, by an equivalent field in 242 another transport protocol, or by some application-specific 243 information. Although the RSVP protocol is designed to be easily 244 extensible for greater generality, the basic protocol documented 245 here supports only UDP/TCP ports as generalized ports. Note that 246 it is not strictly necessary to include DstPort in the session 247 definition when DestAddress is multicast, since different sessions 248 can always have different multicast addresses. However, DstPort 249 is necessary to allow more than one unicast session addressed to 250 the same receiver host. 252 Figure 2 illustrates the flow of data packets in a single RSVP 253 session, assuming multicast data distribution. The arrows 254 indicate data flowing from senders S1 and S2 to receivers R1, R2, 255 and R3, and the cloud represents the distribution mesh created by 256 multicast routing. Multicast distribution forwards a copy of each 257 data packet from a sender Si to every receiver Rj; a unicast 258 distribution session has a single receiver R. Each sender Si may 259 be running in a unique Internet host, or a single host may contain 260 multiple senders distinguished by "generalized source ports". 262 Senders Receivers 263 _____________________ 264 ( ) ===> R1 265 S1 ===> ( Multicast ) 266 ( ) ===> R2 267 ( distribution ) 268 S2 ===> ( ) 269 ( by Internet ) ===> R3 270 (_____________________) 272 Figure 2: Multicast Distribution Session 274 For unicast transmission, there will be a single destination host 275 but there may be multiple senders; RSVP can set up reservations 276 for multipoint-to-single-point transmission. 278 1.2 Reservation Model 280 An elementary RSVP reservation request consists of a "flowspec" 281 together with a "filter spec"; this pair is called a "flow 282 descriptor". The flowspec specifies a desired QoS. The filter 283 spec, together with a session specification, defines the set of 284 data packets -- the "flow" -- to receive the QoS defined by the 285 flowspec. The flowspec is used to set parameters in the node's 286 packet scheduler (assuming that admission control succeeds), while 287 the filter spec is used to set parameters in the packet 288 classifier. Data packets that are addressed to a particular 289 session but do not match any of the filter specs for that session 290 are handled as best-effort traffic. 292 Note that the action to control QoS occurs at the place where the 293 data enters the medium, i.e., at the upstream end of the logical 294 or physical link, although an RSVP reservation request originates 295 from receiver(s) downstream. In this document, we define the 296 directional terms "upstream" vs. "downstream", "previous hop" vs. 297 "next hop", and "incoming interface" vs "outgoing interface" with 298 respect to the direction of data flow. 300 If the link-layer medium is QoS-active, i.e., if it has its own 301 QoS management capability, then the packet scheduler is 302 responsible for negotiation with the link layer to obtain the QoS 303 requested by RSVP. This mapping to the link layer QoS may be 304 accomplished in a number of possible ways; the details will be 305 medium-dependent. On a QoS-passive medium such as a leased line, 306 the scheduler itself allocates packet transmission capacity. The 307 scheduler may also allocate other system resources such as CPU 308 time or buffers. 310 The flowspec in a reservation request will generally include a 311 service class and two sets of numeric parameters: (1) an "Rspec" 312 (R for `reserve') that defines the desired QoS, and (2) a "Tspec" 313 (T for `traffic') that describes the data flow. The formats and 314 contents of Tspecs and Rspecs are determined by the integrated 315 service models [ISrsvp96] and are generally opaque to RSVP. 317 The exact format of a filter spec depends upon whether IPv4 or 318 IPv6 is in use; see Appendix A. In the most general approach 319 [RSVP93], filter specs may select arbitrary subsets of the packets 320 in a given session. Such subsets might be defined in terms of 321 senders (i.e., sender IP address and generalized source port), in 322 terms of a higher-level protocol, or generally in terms of any 323 fields in any protocol headers in the packet. For example, filter 324 specs might be used to select different subflows in a 325 hierarchically-encoded signal by selecting on fields in an 326 application-layer header. In the interest of simplicity (and to 327 minimize layer violation), the present RSVP version uses a much 328 more restricted form of filter spec, consisting of sender IP 329 address and optionally the UDP/TCP port number SrcPort. 331 Because the UDP/TCP port numbers are used for packet 332 classification, each router must be able to examine these fields. 333 This raises three potential problems. 335 1. It is necessary to avoid IP fragmentation of a data flow for 336 which a resource reservation is desired. 338 Document [ISrsvp96] specifies a procedure for applications 339 using RSVP facilities to compute the minimum MTU over a 340 multicast tree and return the result to the senders. 342 2. IPv6 inserts a variable number of variable-length Internet- 343 layer headers before the transport header, increasing the 344 difficulty and cost of packet classification for QoS. 346 Efficient classification of IPv6 data packets could be 347 obtained using the Flow Label field of the IPv6 header. The 348 details will be provided in the future. 350 3. IP-level Security, under either IPv4 or IPv6, may encrypt the 351 entire transport header, hiding the port numbers of data 352 packets from intermediate routers. 354 A small extension to RSVP for IP Security under IPv4 and IPv6 355 is described separately in [IPSEC96]. 357 RSVP messages carrying reservation requests originate at receivers 358 and are passed upstream towards the sender(s). At each 359 intermediate node, two general actions are taken on a request. 361 1. Make a reservation 363 The request is passed to admission control and policy 364 control. If either test fails, the reservation is rejected 365 and RSVP returns an error message to the appropriate 366 receiver(s). If both succeed, the node uses the flowspec to 367 set up the packet scheduler for the desired QoS and the 368 filter spec to set the packet classifier to select the 369 appropriate data packets. 371 2. Forward the request upstream 373 The reservation request is propagated upstream towards the 374 appropriate senders. The set of sender hosts to which a 375 given reservation request is propagated is called the "scope" 376 of that request. 378 The reservation request that a node forwards upstream may differ 379 from the request that it received from downstream, for two 380 reasons. First, the traffic control mechanism may modify the 381 flowspec hop-by-hop. Second, reservations for the same sender, or 382 the same set of senders, from different downstream branches of the 383 multicast tree(s) are "merged" as reservations travel upstream; as 384 a result, a node forwards upstream only the reservation request 385 with the "maximum" flowspec. 387 When a receiver originates a reservation request, it can also 388 request a confirmation message to indicate that its request was 389 (probably) installed in the network. A successful reservation 390 request propagates upstream along the multicast tree until it 391 reaches a point where an existing reservation is equal or greater 392 than that being requested. At that point, the arriving request is 393 merged with the reservation in place and need not be forwarded 394 further; the node may then send a reservation confirmation message 395 back to the receiver. Note that the receipt of a confirmation is 396 only a high-probability indication, not a guarantee, that the 397 requested service is in place all the way to the sender(s), as 398 explained in Section 2.6. 400 The basic RSVP reservation model is "one pass": a receiver sends a 401 reservation request upstream, and each node in the path either 402 accepts or rejects the request. This scheme provides no easy way 403 for a receiver to find out the resulting end-to-end service. 404 Therefore, RSVP supports an enhancement to one-pass service known 405 as "One Pass With Advertising" (OPWA) [OPWA95]. With OPWA, RSVP 406 control packets are sent downstream, following the data paths, to 407 gather information that may be used to predict the end-to-end QoS. 408 The results ("advertisements") are delivered by RSVP to the 409 receiver hosts and perhaps to the receiver applications. The 410 advertisements may then be used by the receiver to construct, or 411 to dynamically adjust, an appropriate reservation request. 413 1.3 Reservation Styles 415 A reservation request includes a set of options that are 416 collectively called the reservation "style". 418 One reservation option concerns the treatment of reservations for 419 different senders within the same session: establish a "distinct" 420 reservation for each upstream sender, or else make a single 421 reservation that is "shared" among all packets of selected 422 senders. 424 Another reservation option controls the selection of senders; it 425 may be an "explicit" list of all selected senders, or a "wildcard" 426 that implicitly selects all the senders to the session. In an 427 explicit sender-selection reservation, each filter spec must match 428 exactly one sender, while in a wildcard sender-selection no filter 429 spec is needed. 431 Sender || Reservations: 432 Selection || Distinct | Shared 433 _________||__________________|____________________ 434 || | | 435 Explicit || Fixed-Filter | Shared-Explicit | 436 || (FF) style | (SE) Style | 437 __________||__________________|____________________| 438 || | | 439 Wildcard || (None defined) | Wildcard-Filter | 440 || | (WF) Style | 441 __________||__________________|____________________| 443 Figure 3: Reservation Attributes and Styles 445 The following styles are currently defined (see Figure 3): 447 o Wildcard-Filter (WF) Style 449 The WF style implies the options: "shared" reservation and 450 "wildcard" sender selection. Thus, a WF-style reservation 451 creates a single reservation shared by flows from all 452 upstream senders. This reservation may be thought of as a 453 shared "pipe", whose "size" is the largest of the resource 454 requests from all receivers, independent of the number of 455 senders using it. A WF-style reservation is propagated 456 upstream towards all sender hosts, and it automatically 457 extends to new senders as they appear. 459 Symbolically, we can represent a WF-style reservation request 460 by: 462 WF( * {Q}) 464 where the asterisk represents wildcard sender selection and Q 465 represents the flowspec. 467 o Fixed-Filter (FF) Style 469 The FF style implies the options: "distinct" reservations and 470 "explicit" sender selection. Thus, an elementary FF-style 471 reservation request creates a distinct reservation for data 472 packets from a particular sender, not sharing them with other 473 senders' packets for the same session. 475 Symbolically, we can represent an elementary FF reservation 476 request by: 478 FF( S{Q}) 480 where S is the selected sender and Q is the corresponding 481 flowspec; the pair forms a flow descriptor. RSVP allows 482 multiple elementary FF-style reservations to be requested at 483 the same time, using a list of flow descriptors: 485 FF( S1{Q1}, S2{Q2}, ...) 487 The total reservation on a link for a given session is the 488 `sum' of Q1, Q2, ... for all requested senders. 490 o Shared Explicit (SE) Style 492 The SE style implies the options: "shared" reservation and 493 "explicit" sender selection. Thus, an SE-style reservation 494 creates a single reservation shared by selected upstream 495 senders. Unlike the WF style, the SE style allows a receiver 496 to explicitly specify the set of senders to be included. 498 We can represent an SE reservation request containing a 499 flowspec Q and a list of senders S1, S2, ... by: 501 SE( (S1,S2,...){Q} ) 503 Shared reservations, created by WF and SE styles, are appropriate 504 for those multicast applications in which multiple data sources 505 are unlikely to transmit simultaneously. Packetized audio is an 506 example of an application suitable for shared reservations; since 507 a limited number of people talk at once, each receiver might issue 508 a WF or SE reservation request for twice the bandwidth required 509 for one sender (to allow some over-speaking). On the other hand, 510 the FF style, which creates distinct reservations for the flows 511 from different senders, is appropriate for video signals. 513 The RSVP rules disallow merging of shared reservations with 514 distinct reservations, since these modes are fundamentally 515 incompatible. They also disallow merging explicit sender 516 selection with wildcard sender selection, since this might produce 517 an unexpected service for a receiver that specified explicit 518 selection. As a result of these prohibitions, WF, SE, and FF 519 styles are all mutually incompatible. 521 It would seem possible to simulate the effect of a WF reservation 522 using the SE style. When an application asked for WF, the RSVP 523 process on the receiver host could use local state to create an 524 equivalent SE reservation that explicitly listed all senders. 525 However, an SE reservation forces the packet classifier in each 526 node to explicitly select each sender in the list, while a WF 527 allows the packet classifier to simply "wild card" the sender 528 address and port. When there is a large list of senders, a WF 529 style reservation can therefore result in considerably less 530 overhead than an equivalent SE style reservation. For this 531 reason, both SE and WF are included in the protocol. 533 Other reservation options and styles may be defined in the future. 535 1.4 Examples of Styles 537 This section presents examples of each of the reservation styles 538 and shows the effects of merging. 540 Figure 4 illustrates a router with two incoming interfaces, 541 labeled (a) and (b), through which flows will arrive, and two 542 outgoing interfaces, labeled (c) and (d), through which data will 543 be forwarded. This topology will be assumed in the examples that 544 follow. There are three upstream senders; packets from sender S1 545 (S2 and S3) arrive through previous hop (a) ((b), respectively). 546 There are also three downstream receivers; packets bound for R1 547 (R2 and R3) are routed via outgoing interface (c) ((d), 548 respectively). We furthermore assume that outgoing interface (d) 549 is connected to a broadcast LAN, and that R2 and R3 are reached 550 via different next hop routers (not shown). 552 We must also specify the multicast routes within the node of 553 Figure 4. Assume first that data packets from each Si shown in 554 Figure 4 are routed to both outgoing interfaces. Under this 555 assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter, 556 Fixed-Filter, and Shared-Explicit reservations, respectively. 558 ________________ 559 (a)| | (c) 560 ( S1 ) ---------->| |----------> ( R1 ) 561 | Router | | 562 (b)| | (d) |---> ( R2 ) 563 ( S2,S3 ) ------->| |------| 564 |________________| |---> ( R3 ) 565 | 566 Figure 4: Router Configuration 568 For simplicity, these examples show flowspecs as one-dimensional 569 multiples of some base resource quantity B. The "Receive" column 570 shows the RSVP reservation requests received over outgoing 571 interfaces (c) and (d), and the "Reserve" column shows the 572 resulting reservation state for each interface. The "Send" 573 column shows the reservation requests that are sent upstream to 574 previous hops (a) and (b). In the "Reserve" column, each box 575 represents one reserved "pipe" on the outgoing link, with the 576 corresponding flow descriptor. 578 Figure 5, showing the WF style, illustrates two distinct 579 situations in which merging is required. (1) Each of the two next 580 hops on interface (d) results in a separate RSVP reservation 581 request, as shown; these two requests must be merged into the 582 effective flowspec, 3B, that is used to make the reservation on 583 interface (d). (2) The reservations on the interfaces (c) and (d) 584 must be merged in order to forward the reservation requests 585 upstream; as a result, the larger flowspec 4B is forwarded 586 upstream to each previous hop. 588 | 589 Send | Reserve Receive 590 | 591 | _______ 592 WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) 593 | |_______| 594 | 595 -----------------------|---------------------------------------- 596 | _______ 597 WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) 598 | |_______| <- WF( *{2B} ) 600 Figure 5: Wildcard-Filter (WF) Reservation Example 602 Figure 6 shows Fixed-Filter (FF) style reservations. The flow 603 descriptors for senders S2 and S3, received from outgoing 604 interfaces (c) and (d), are packed (not merged) into the request 605 forwarded to previous hop (b). On the other hand, the three 606 different flow descriptors specifying sender S1 are merged into 607 the single request FF( S1{4B} ) that is sent to previous hop (a). 608 For each outgoing interface, there is a separate reservation for 609 each source that has been requested, but this reservation will be 610 shared among all the receivers that made the request. 612 | 613 Send | Reserve Receive 614 | 615 | ________ 616 FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} ) 617 | |________| 618 | | S2{5B} | 619 | |________| 620 ---------------------|--------------------------------------------- 621 | ________ 622 <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) 623 FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} ) 624 | | S3{B} | 625 | |________| 627 Figure 6: Fixed-Filter (FF) Reservation Example 629 Figure 7 shows an example of Shared-Explicit (SE) style 630 reservations. When SE-style reservations are merged, the 631 resulting filter spec is the union of the original filter specs, 632 and the resulting flowspec is the largest flowspec. 634 | 635 Send | Reserve Receive 636 | 637 | ________ 638 SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} ) 639 | | {B} | 640 | |________| 641 ---------------------|--------------------------------------------- 642 | __________ 643 <- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} ) 644 SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} ) 645 | |__________| 647 Figure 7: Shared-Explicit (SE) Reservation Example 649 The three examples just shown assume that data packets from S1, 650 S2, and S3 are routed to both outgoing interfaces. The top part 651 of Figure 8 shows another routing assumption: data packets from S2 652 and S3 are not forwarded to interface (c), e.g., because the 653 network topology provides a shorter path for these senders towards 654 R1, not traversing this node. The bottom part of Figure 8 shows 655 WF style reservations under this assumption. Since there is no 656 route from (b) to (c), the reservation forwarded out interface (b) 657 considers only the reservation on interface (d). 659 _______________ 660 (a)| | (c) 661 ( S1 ) ---------->| >-----------> |----------> ( R1 ) 662 | - | 663 | - | 664 (b)| - | (d) 665 ( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 ) 666 |_______________| 668 Router Configuration 670 | 671 Send | Reserve Receive 672 | 673 | _______ 674 WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) 675 | |_______| 676 | 677 -----------------------|---------------------------------------- 678 | _______ 679 WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) 680 | |_______| <- WF( * {2B} ) 682 Figure 8: WF Reservation Example -- Partial Routing 684 2. RSVP Protocol Mechanisms 686 2.1 RSVP Messages 688 Previous Incoming Outgoing Next 689 Hops Interfaces Interfaces Hops 691 _____ _____________________ _____ 692 | | data --> | | data --> | | 693 | A |-----------| a c |--------------| C | 694 |_____| Path --> | | Path --> |_____| 695 <-- Resv | | <-- Resv _____ 696 _____ | ROUTER | | | | 697 | | | | | |--| D | 698 | B |--| data-->| | data --> | |_____| 699 |_____| |--------| b d |-----------| 700 | Path-->| | Path --> | _____ 701 _____ | <--Resv|_____________________| <-- Resv | | | 702 | | | |--| D' | 703 | B' |--| | |_____| 704 |_____| | | 706 Figure 9: Router Using RSVP 708 Figure 9 illustrates RSVP's model of a router node. Each data 709 flow arrives from a "previous hop" through a corresponding 710 "incoming interface" and departs through one or more "outgoing 711 interface"(s). The same physical interface may act in both the 712 incoming and outgoing roles for different data flows in the same 713 session. Multiple previous hops and/or next hops may be reached 714 through a given physical interface, as a result of the connected 715 network being a shared medium, or the existence of non-RSVP 716 routers in the path to the next RSVP hop (see Section 2.8). 718 There are two fundamental RSVP message types: Resv and Path. 720 Each receiver host sends RSVP reservation request (Resv) messages 721 upstream towards the senders. These messages must follow exactly 722 the reverse of the path(s) the data packets will use, upstream to 723 all the sender hosts included in the sender selection. They 724 create and maintain "reservation state" in each node along the 725 path(s). Resv messages must finally be delivered to the sender 726 hosts themselves, so that the hosts can set up appropriate traffic 727 control parameters for the first hop. The processing of Resv 728 messages was discussed previously in Section 1.2. 730 Each RSVP sender host transmits RSVP "Path" messages downstream 731 along the uni-/multicast routes provided by the routing 732 protocol(s), following the paths of the data. These Path messages 733 store "path state" in each node along the way. This path state 734 includes at least the unicast IP address of the previous hop node, 735 which is used to route the Resv messages hop-by-hop in the reverse 736 direction. (In the future, some routing protocols may supply 737 reverse path forwarding information directly, replacing the 738 reverse-routing function of path state). 740 A Path message contains the following information in addition to 741 the previous hop address: 743 o Sender Template 745 A Path message is required to carry a Sender Template, which 746 describes the format of data packets that the sender will 747 originate. This template is in the form of a filter spec 748 that could be used to select this sender's packets from 749 others in the same session on the same link. 751 Sender Templates have exactly the same expressive power and 752 format as filter specs that appear in Resv messages. 753 Therefore a Sender Template may specify only the sender IP 754 address and optionally the UDP/TCP sender port, and it 755 assumes the protocol Id specified for the session. 757 o Sender Tspec 759 A Path message is required to carry a Sender Tspec, which 760 defines the traffic characteristics of the data flow that the 761 sender will generate. This Tspec is used by traffic control 762 to prevent over-reservation, and perhaps unnecessary 763 Admission Control failures. 765 o Adspec 767 A Path message may carry a package of OPWA advertising 768 information, known as an "Adspec". An Adspec received in a 769 Path message is passed to the local traffic control, which 770 returns an updated Adspec; the updated version is then 771 forwarded in Path messages sent downstream. 773 Path messages are sent with the same source and destination 774 addresses as the data, so that they will be routed correctly 775 through non-RSVP clouds (see Section 2.8). On the other hand, 776 Resv messages are sent hop-by-hop; each RSVP-speaking node 777 forwards a Resv message to the unicast address of a previous RSVP 778 hop. 780 2.2 Merging Flowspecs 782 As noted earlier, a single physical interface may receive multiple 783 reservation requests from different next hops for the same session 784 and with the same filter spec, but RSVP should install only one 785 reservation on that interface. The installed reservation should 786 have an effective flowspec that is the "largest" of the flowspecs 787 requested by the different next hops. Similarly, a Resv message 788 forwarded to a previous hop should carry a flowspec that is the 789 "largest" of the flowspecs requested by the different next hops 790 (however, in certain cases the "smallest" is taken rather than the 791 largest, see Section 3.5). These cases both represent flowspec 792 merging. 794 Flowspec merging requires calculation of the "largest" of a set of 795 flowspecs. However, flowspecs are opaque to RSVP, so the actual 796 rules for comparing flowspecs must be defined and implemented 797 outside RSVP proper. The comparison rules are defined in the 798 appropriate integrated service specification document; see 799 [ISrsvp96]. An RSVP implementation will need to call service- 800 specific routines to perform flowspec merging. 802 Note that flowspecs are generally multi-dimensional vectors; they 803 may contain both Tspec and Rspec components, each of which may 804 itself be multi-dimensional. Therefore, it may not be possible to 805 strictly order two flowspecs. For example, if one request calls 806 for a higher bandwidth and another calls for a tighter delay 807 bound, one is not "larger" than the other. In such a case, 808 instead of taking the larger, the service-specific merging 809 routines must be able to return a third flowspec that is at least 810 as large as each; mathematically, this is the "least upper bound" 811 (LUB). In some cases, a flowspec at least as small is needed; 812 this is the "greatest lower bound" (GLB) GLB (Greatest Lower 813 Bound). 815 The following steps are used to calculate the effective flowspec 816 (Te, Re) to be installed on an interface [ISrsvp96]. Here Te is 817 the effective Tspec and Re is the effective Rspec. As an example, 818 consider interface (d) in Figure 9. 820 1. A service-specific calculation of the LUB of the flowspecs 821 that arrived in Resv messages from different next hops (e.g., 822 D and D') but the same outgoing interface (d) is performed. 824 The result is a flowspec that is opaque to RSVP but actually 825 consists of the pair (Re, Resv_Te), where Re is the LUB of 826 the Rspecs and Resv_Te is the LUB of the Tspecs from the Resv 827 messages. 829 2. A service-specific calculation of Path_Te, the sum of all 830 Tspecs that were supplied in Path messages from different 831 previous hops (e.g., some or all of A, B, and B' in Figure 832 9), is performed. 834 3. RSVP passes these two results, (Re, Resv_Te) and Path_Te, to 835 traffic control. Traffic control will compute the "minimum" 836 of Path_Te and Resv_Te in a service-dependent manner, to be 837 the effective flowspec. 839 A generic set of service-specific calls to compare flowspecs and 840 compute the LUB and GLB of flowspecs, and to compare and sum 841 Tspecs, is defined in Section 3.11.5. 843 2.3 Soft State 845 RSVP takes a "soft state" approach to managing the reservation 846 state in routers and hosts. RSVP soft state is created and 847 periodically refreshed by Path and Resv messages. The state is 848 deleted if no matching refresh messages arrive before the 849 expiration of a "cleanup timeout" interval. State may also be 850 deleted by an explicit "teardown" message, described in the next 851 section. At the expiration of each "refresh timeout" period and 852 after a state change, RSVP scans its state to build and forward 853 Path and Resv refresh messages to succeeding hops. 855 Path and Resv messages are idempotent. When a route changes, the 856 next Path message will initialize the path state on the new route, 857 and future Resv messages will establish reservation state there; 858 the state on the now-unused segment of the route will time out. 859 Thus, whether a message is "new" or a "refresh" is determined 860 separately at each node, depending upon the existence of state at 861 that node. 863 RSVP sends its messages as IP datagrams with no reliability 864 enhancement. Periodic transmission of refresh messages by hosts 865 and routers is expected to handle the occasional loss of an RSVP 866 message. If the effective cleanup timeout is set to K times the 867 refresh timeout period, then RSVP can tolerate K-1 successive RSVP 868 packet losses without falsely deleting state. The network traffic 869 control mechanism should be statically configured to grant some 870 minimal bandwidth for RSVP messages to protect them from 871 congestion losses. 873 The state maintained by RSVP is dynamic; to change the set of 874 senders Si or to change any QoS request, a host simply starts 875 sending revised Path and/or Resv messages. The result will be an 876 appropriate adjustment in the RSVP state in all nodes along the 877 path; unused state will time out if it is not explicitly torn 878 down. 880 In steady state, refreshing is performed hop-by-hop, to allow 881 merging. When the received state differs from the stored state, 882 the stored state is updated. If this update results in 883 modification of state to be forwarded in refresh messages, these 884 refresh messages must be generated and forwarded immediately, so 885 that state changes can be propagated end-to-end without delay. 886 However, propagation of a change stops when and if it reaches a 887 point where merging causes no resulting state change. This 888 minimizes RSVP control traffic due to changes and is essential for 889 scaling to large multicast groups. 891 State that is received through a particular interface I* should 892 never be forwarded out the same interface. Conversely, state that 893 is forwarded out interface I* must be computed using only state 894 that arrived on interfaces different from I*. A trivial example 895 of this rule is illustrated in Figure 10, which shows a transit 896 router with one sender and one receiver on each interface (and 897 assumes one next/previous hop per interface). Interfaces (a) and 898 (c) serve as both outgoing and incoming interfaces for this 899 session. Both receivers are making wildcard-style reservations, 900 in which the Resv messages are forwarded to all previous hops for 901 senders in the group, with the exception of the next hop from 902 which they came. The result is independent reservations in the 903 two directions. 905 There is an additional rule governing the forwarding of Resv 906 messages: state from Resv messages received from outgoing 907 interface Io should be forwarded to incoming interface Ii only if 908 Path messages from Ii are forwarded to Io. 910 ________________ 911 a | | c 912 ( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) 913 |________________| 915 Send | Receive 916 | 917 WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) 918 | 919 Receive | Send 920 | 921 WF( *{4B}) --> (a) | (c) --> WF( *{4B}) 922 | 923 Reserve on (a) | Reserve on (c) 924 __________ | __________ 925 | * {4B} | | | * {3B} | 926 |__________| | |__________| 927 | 929 Figure 10: Independent Reservations 931 2.4 Teardown 933 Upon arrival, RSVP "teardown" messages remove path and reservation 934 state immediately. Although it is not necessary to explicitly 935 tear down an old reservation, we recommend that all end hosts send 936 a teardown request as soon as an application finishes. 938 There are two types of RSVP teardown message, PathTear and 939 ResvTear. A PathTear message travels towards all receivers 940 downstream from its point of initiation and deletes path state, as 941 well as all dependent reservation state, along the way. An 942 ResvTear message deletes reservation state and travels towards all 943 senders upstream from its point of initiation. A PathTear 944 (ResvTear) message may be conceptualized as a reversed-sense Path 945 message (Resv message, respectively). 947 A teardown request may be initiated either by an application in an 948 end system (sender or receiver), or by a router as the result of 949 state timeout or service preemption. Once initiated, a teardown 950 request must be forwarded hop-by-hop without delay. A teardown 951 message deletes the specified state in the node where it is 952 received. As always, this state change will be propagated 953 immediately to the next node, but only if there will be a net 954 change after merging. As a result, a ResvTear message will prune 955 the reservation state back (only) as far as possible. 957 Like all other RSVP messages, teardown requests are not delivered 958 reliably. The loss of a teardown request message will not cause a 959 protocol failure because the unused state will eventually time out 960 even though it is not explicitly deleted. If a teardown message 961 is lost, the router that failed to receive that message will time 962 out its state and initiate a new teardown message beyond the loss 963 point. Assuming that RSVP message loss probability is small, the 964 longest time to delete state will seldom exceed one refresh 965 timeout period. 967 It should be possible to tear down any subset of the established 968 state. For path state, the granularity for teardown is a single 969 sender. For reservation state, the granularity is an individual 970 filter spec. For example, refer to Figure 7. Receiver R1 could 971 send a ResvTear message for sender S2 only (or for any subset of 972 the filter spec list), leaving S1 in place. 974 A ResvTear message specifies the style and filters; any flowspec 975 is ignored. Whatever flowspec is in place will be removed if all 976 its filter specs are torn down. 978 2.5 Errors 980 There are two RSVP error messages, ResvErr and PathErr. PathErr 981 messages are very simple; they are simply sent upstream to the 982 sender that created the error, and they do not change path state 983 in the nodes though which they pass. There are only a few 984 possible causes of path errors. 986 However, there are a number of ways for a syntactically valid 987 reservation request to fail at some node along the path. A node 988 may also decide to preempt an established reservation. The 989 handling of ResvErr messages is somewhat complex (Section 3.5). 990 Since a request that fails may be the result of merging a number 991 of requests, a reservation error must be reported to all of the 992 responsible receivers. In addition, merging heterogeneous 993 requests creates a potential difficulty known as the "killer 994 reservation" problem, in which one request could deny service to 995 another. There are actually two killer-reservation problems. 997 1. The first killer reservation problem (KR-I) arises when there 998 is already a reservation Q0 in place. If another receiver 999 now makes a larger reservation Q1 > Q0, the result of merging 1000 Q0 and Q1 may be rejected by admission control in some 1001 upstream node. This must not deny service to Q0. 1003 The solution to this problem is simple: when admission 1004 control fails for a reservation request, any existing 1005 reservation is left in place. 1007 2. The second killer reservation problem (KR-II) is the 1008 converse: the receiver making a reservation Q1 is persistent 1009 even though Admission Control is failing for Q1 in some node. 1010 This must not prevent a different receiver from now 1011 establishing a smaller reservation Q0 that would succeed if 1012 not merged with Q1. 1014 To solve this problem, a ResvErr message establishes 1015 additional state, called "blockade state", in each node 1016 through which it passes. Blockade state in a node modifies 1017 the merging procedure to omit the offending flowspec (Q1 in 1018 the example) from the merge, allowing a smaller request to be 1019 forwarded and established. The Q1 reservation state is said 1020 to be "blockaded". Detailed rules are presented in Section 1021 3.5. 1023 A reservation request that fails Admission Control creates 1024 blockade state but is left in place in nodes downstream of the 1025 failure point. It has been suggested that these reservations 1026 downstream from the failure represent "wasted" reservations and 1027 should be timed out if not actively deleted. However, the 1028 downstream reservations are left in place, for the following 1029 reasons: 1031 o There are two possible reasons for a receiver persisting in a 1032 failed reservation: (1) it is polling for resource 1033 availability along the entire path, or (2) it wants to obtain 1034 the desired QoS along as much of the path as possible. 1035 Certainly in the second case, and perhaps in the first case, 1036 the receiver will want to hold onto the reservations it has 1037 made downstream from the failure. 1039 o If these downstream reservations were not retained, the 1040 responsiveness of RSVP to certain transient failures would be 1041 impaired. For example, suppose a route "flaps" to an 1042 alternate route that is congested, so an existing reservation 1043 suddenly fails, then quickly recovers to the original route. 1044 The blockade state in each downstream router must not remove 1045 the state or prevent its immediate refresh. 1047 o If we did not refresh the downstream reservations, they might 1048 time out, to be restored every Tb seconds (where Tb is the 1049 blockade state timeout interval). Such intermittent behavior 1050 might be very distressing for users. 1052 2.6 Confirmation 1054 To request a confirmation for its reservation request, a receiver 1055 Rj includes in the Resv message a confirmation-request object 1056 containing Rj's IP address. At each merge point, only the largest 1057 flowspec and any accompanying confirmation-request object is 1058 forwarded upstream. If the reservation request from Rj is equal 1059 to or smaller than the reservation in place on a node, its Resv 1060 are not forwarded further, and if the Resv included a 1061 confirmation-request object, a ResvConf message is sent back to 1062 Rj. If the confirmation request is forwarded, it is forwarded 1063 immediately, and no more than once for each request. 1065 This confirmation mechanism has the following consequences: 1067 o A new reservation request with a flowspec larger than any in 1068 place for a session will normally result in either a ResvErr 1069 or a ResvConf message back to the receiver from each sender. 1070 In this case, the ResvConf message will be an end-to-end 1071 confirmation. 1073 o The receipt of a ResvConf gives no guarantees. Assume the 1074 first two reservation requests from receivers R1 and R2 1075 arrive at the node where they are merged. R2, whose 1076 reservation was the second to arrive at that node, may 1077 receive a ResvConf from that node while R1's request has not 1078 yet propagated all the way to a matching sender and may still 1079 fail. Thus, R2 may receive a ResvConf although there is no 1080 end-to-end reservation in place; furthermore, R2 may receive 1081 a ResvConf followed by a ResvErr. 1083 2.7 Policy and Security 1085 RSVP-mediated QoS requests will result in particular user(s) 1086 getting preferential access to network resources. To prevent 1087 abuse, some form of back pressure on users is likely to be 1088 required. This back pressure might take the form of 1089 administrative rules, or of some form of real or virtual billing 1090 for the "cost" of a reservation. The form and contents of such 1091 back pressure is a matter of administrative policy that may be 1092 determined independently by each administrative domain in the 1093 Internet. 1095 Therefore, there is likely to be policy control as well as 1096 admission control over the establishment of reservations. As 1097 input to policy control, RSVP messages may carry "policy data". 1098 Policy data may include credentials identifying users or user 1099 classes, account numbers, limits, quotas, etc. RSVP will pass the 1100 "policy data" to a "Local Policy Module" (LPM) for a decision. 1102 To protect the integrity of the policy control mechanisms, it may 1103 be necessary to ensure the integrity of RSVP messages against 1104 corruption or spoofing, hop by hop. For this purpose, RSVP 1105 messages may carry integrity objects that can be created and 1106 verified by neighbor RSVP-capable nodes. These objects use a 1107 keyed cryptographic digest technique and assume that RSVP 1108 neighbors share a secret [Baker96]. 1110 User policy data in reservation request messages presents a 1111 scaling problem. When a multicast group has a large number of 1112 receivers, it will be impossible or undesirable to carry all 1113 receivers' policy data upstream to the sender(s). The policy data 1114 will have to be administratively merged at places near the 1115 receivers, to avoid excessive policy data. Administrative merging 1116 implies checking the user credentials and accounting data and then 1117 substituting a token indicating the check has succeeded. A chain 1118 of trust established using integrity fields will allow upstream 1119 nodes to accept these tokens. 1121 In summary, different administrative domains in the Internet may 1122 have different policies regarding their resource usage and 1123 reservation. The role of RSVP is to carry policy data associated 1124 with each reservation to the network as needed. Note that the 1125 merge points for policy data are likely to be at the boundaries of 1126 administrative domains. It may be necessary to carry accumulated 1127 and unmerged policy data upstream through multiple nodes before 1128 reaching one of these merge points. 1130 This document does not specify the contents of policy data, the 1131 structure of an LPM, or any generic policy models. These will be 1132 defined in the future. 1134 2.8 Non-RSVP Clouds 1136 It is impossible to deploy RSVP (or any new protocol) at the same 1137 moment throughout the entire Internet. Furthermore, RSVP may 1138 never be deployed everywhere. RSVP must therefore provide correct 1139 protocol operation even when two RSVP-capable routers are joined 1140 by an arbitrary "cloud" of non-RSVP routers. Of course, an 1141 intermediate cloud that does not support RSVP is unable to perform 1142 resource reservation. However, if such a cloud has sufficient 1143 capacity, it may still provide useful realtime service. 1145 RSVP is designed to operate correctly through such a non-RSVP 1146 cloud. Both RSVP and non-RSVP routers forward Path messages 1147 towards the destination address using their local uni-/multicast 1148 routing table. Therefore, the routing of Path messages will be 1149 unaffected by non-RSVP routers in the path. When a Path message 1150 traverses a non-RSVP cloud, it carries to the next RSVP-capable 1151 node the IP address of the last RSVP-capable router before 1152 entering the cloud. An Resv message is then forwarded directly to 1153 the next RSVP-capable router on the path(s) back towards the 1154 source. 1156 Even though RSVP operates correctly through a non-RSVP cloud, the 1157 non-RSVP-capable nodes will in general perturb the QoS provided to 1158 a receiver. Therefore, RSVP passes a `NonRSVP' flag bit to the 1159 local traffic control mechanism when there are non-RSVP-capable 1160 hops in the path to a given sender. Traffic control combines this 1161 flag bit with its own sources of information, and forwards the 1162 composed information on integrated service capability along the 1163 path to receivers using Adspecs [ISrsvp96]. 1165 Some topologies of RSVP routers and non-RSVP routers can cause 1166 Resv messages to arrive at the wrong RSVP-capable node, or to 1167 arrive at the wrong interface of the correct node. An RSVP 1168 process must be prepared to handle either situation. If the 1169 destination address does not match any local interface and the 1170 message is not a Path or PathTear, the message must be forwarded 1171 without further processing by this node. To handle the wrong 1172 interface case, a "Logical Interface Handle" (LIH) is used. The 1173 previous hop information included in a Path message includes not 1174 only the IP address of the previous node but also an LIH defining 1175 the logical outgoing interface; both values are stored in the path 1176 state. A Resv message arriving at the addressed node carries both 1177 the IP address and the LIH of the correct outgoing interface, i.e, 1178 the interface that should receive the requested reservation, 1179 regardless of which interface it arrives on. 1181 The LIH may also be useful when RSVP reservations are made over a 1182 complex link layer, to map between IP layer and link layer flow 1183 entities. 1185 2.9 Host Model 1187 Before a session can be created, the session identification, 1188 comprised of DestAddress, ProtocolId, and perhaps the generalized 1189 destination port, must be assigned and communicated to all the 1190 senders and receivers by some out-of-band mechanism. When an RSVP 1191 session is being set up, the following events happen at the end 1192 systems. 1194 H1 A receiver joins the multicast group specified by 1195 DestAddress, using IGMP. 1197 H2 A potential sender starts sending RSVP Path messages to the 1198 DestAddress. 1200 H3 A receiver application receives a Path message. 1202 H4 A receiver starts sending appropriate Resv messages, 1203 specifying the desired flow descriptors. 1205 H5 A sender application receives a Resv message. 1207 H6 A sender starts sending data packets. 1209 There are several synchronization considerations. 1211 o H1 and H2 may happen in either order. 1213 o Suppose that a new sender starts sending data (H6) but there 1214 are no multicast routes because no receivers have joined the 1215 group (H1). Then the data will be dropped at some router 1216 node (which node depends upon the routing protocol) until 1217 receivers(s) appear. 1219 o Suppose that a new sender starts sending Path messages (H2) 1220 and data (H6) simultaneously, and there are receivers but no 1221 Resv messages have reached the sender yet (e.g., because its 1222 Path messages have not yet propagated to the receiver(s)). 1223 Then the initial data may arrive at receivers without the 1224 desired QoS. The sender could mitigate this problem by 1225 awaiting arrival of the first Resv message (H5); however, 1226 receivers that are farther away may not have reservations in 1227 place yet. 1229 o If a receiver starts sending Resv messages (H4) before 1230 receiving any Path messages (H3), RSVP will return error 1231 messages to the receiver. 1233 The receiver may simply choose to ignore such error messages, 1234 or it may avoid them by waiting for Path messages before 1235 sending Resv messages. 1237 A specific application program interface (API) for RSVP is not 1238 defined in this protocol spec, as it may be host system dependent. 1239 However, Section 3.11.1 discusses the general requirements and 1240 outlines a generic interface. 1242 3. RSVP Functional Specification 1244 3.1 RSVP Message Formats 1246 An RSVP message consists of a common header, followed by a body 1247 consisting of a variable number of variable-length, typed 1248 "objects". The following subsections define the formats of the 1249 common header, the standard object header, and each of the RSVP 1250 message types. 1252 For each RSVP message type, there is a set of rules for the 1253 permissible choice of object types. These rules are specified 1254 using Backus-Naur Form (BNF) augmented with square brackets 1255 surrounding optional sub-sequences. The BNF implies an order for 1256 the objects in a message. However, in many (but not all) cases, 1257 object order makes no logical difference. An implementation 1258 should create messages with the objects in the order shown here, 1259 but accept the objects in any permissible order. 1261 3.1.1 Common Header 1263 0 1 2 3 1264 +-------------+-------------+-------------+-------------+ 1265 | Vers | Flags| Msg Type | RSVP Checksum | 1266 +-------------+-------------+-------------+-------------+ 1267 | Send_TTL | (Reserved) | RSVP Length | 1268 +-------------+-------------+-------------+-------------+ 1270 The fields in the common header are as follows: 1272 Vers: 4 bits 1274 Protocol version number. This is version 1. 1276 Flags: 4 bits 1278 0x01-0x08: Reserved 1280 No flag bits are defined yet. 1282 Msg Type: 8 bits 1284 1 = Path 1286 2 = Resv 1287 3 = PathErr 1289 4 = ResvErr 1291 5 = PathTear 1293 6 = ResvTear 1295 7 = ResvConf 1297 RSVP Checksum: 16 bits 1299 The one's complement of the one's complement sum of the 1300 message, with the checksum field replaced by zero for the 1301 purpose of computing the checksum. An all-zero value 1302 means that no checksum was transmitted. 1304 Send_TTL: 8 bits 1306 The IP TTL value with which the message was sent. See 1307 Section 3.8. 1309 RSVP Length: 16 bits 1311 The total length of this RSVP message in bytes, including 1312 the common header and the variable-length objects that 1313 follow. 1315 3.1.2 Object Formats 1317 Every object consists of one or more 32-bit words with a one- 1318 word header, with the following format: 1320 0 1 2 3 1321 +-------------+-------------+-------------+-------------+ 1322 | Length (bytes) | Class-Num | C-Type | 1323 +-------------+-------------+-------------+-------------+ 1324 | | 1325 // (Object contents) // 1326 | | 1327 +-------------+-------------+-------------+-------------+ 1329 An object header has the following fields: 1331 Length 1333 A 16-bit field containing the total object length in 1334 bytes. Must always be a multiple of 4, and at least 4. 1336 Class-Num 1338 Identifies the object class; values of this field are 1339 defined in Appendix A. Each object class has a name, 1340 which is always capitalized in this document. An RSVP 1341 implementation must recognize the following classes: 1343 NULL 1345 A NULL object has a Class-Num of zero, and its C-Type 1346 is ignored. Its length must be at least 4, but can 1347 be any multiple of 4. A NULL object may appear 1348 anywhere in a sequence of objects, and its contents 1349 will be ignored by the receiver. 1351 SESSION 1353 Contains the IP destination address (DestAddress), 1354 the IP protocol id, and some form of generalized 1355 destination port, to define a specific session for 1356 the other objects that follow. Required in every 1357 RSVP message. 1359 RSVP_HOP 1361 Carries the IP address of the RSVP-capable node that 1362 sent this message and a logical outgoing interface 1363 handle (LIH; see Section 3.3). This document refers 1364 to a RSVP_HOP object as a PHOP ("previous hop") 1365 object for downstream messages or as a NHOP (" next 1366 hop") object for upstream messages. 1368 TIME_VALUES 1370 Contains the value for the refresh period R used by 1371 the creator of the message; see Section 3.7. 1372 Required in every Path and Resv message. 1374 STYLE 1376 Defines the reservation style plus style-specific 1377 information that is not in FLOWSPEC or FILTER_SPEC 1378 objects. Required in every Resv message. 1380 FLOWSPEC 1381 Defines a desired QoS, in a Resv message. 1383 FILTER_SPEC 1385 Defines a subset of session data packets that should 1386 receive the desired QoS (specified by a FLOWSPEC 1387 object), in a Resv message. 1389 SENDER_TEMPLATE 1391 Contains a sender IP address and perhaps some 1392 additional demultiplexing information to identify a 1393 sender. Required in a Path message. 1395 SENDER_TSPEC 1397 Defines the traffic characteristics of a sender's 1398 data flow. Required in a Path message. 1400 ADSPEC 1402 Carries OPWA data, in a Path message. 1404 ERROR_SPEC 1406 Specifies an error in a PathErr, ResvErr, or a 1407 confirmation in a ResvConf message. 1409 POLICY_DATA 1411 Carries information that will allow a local policy 1412 module to decide whether an associated reservation is 1413 administratively permitted. May appear in Path, 1414 Resv, PathErr, or ResvErr message. 1416 The use of POLICY_DATA objects is not fully specified 1417 at this time; a future document will fill this gap. 1419 INTEGRITY 1421 Carries cryptographic data to authenticate the 1422 originating node and to verify the contents of this 1423 RSVP message. The use of the INTEGRITY object is 1424 described in [Baker96]. 1426 SCOPE 1428 Carries an explicit list of sender hosts towards 1429 which the information in the message is to be 1430 forwarded. May appear in a Resv, ResvErr, or 1431 ResvTear message. See Section 3.4. 1433 RESV_CONFIRM 1435 Carries the IP address of a receiver that requested a 1436 confirmation. May appear in a Resv or ResvConf 1437 message. 1439 C-Type 1441 Object type, unique within Class-Num. Values are defined 1442 in Appendix A. 1444 The maximum object content length is 65528 bytes. The Class- 1445 Num and C-Type fields may be used together as a 16-bit number 1446 to define a unique type for each object. 1448 The high-order two bits of the Class-Num is used to determine 1449 what action a node should take if it does not recognize the 1450 Class-Num of an object; see Section 3.10. 1452 3.1.3 Path Messages 1454 The format of a Path message is as follows: 1456 ::= [ ] 1458 1460 1462 [ ... ] 1464 [ ] 1466 ::= 1468 [ ] 1470 If the INTEGRITY object is present, it must immediately follow 1471 the common header. There are no other requirements on 1472 transmission order, although the above order is recommended. 1473 Any number of POLICY_DATA objects may appear. 1475 The PHOP (i.e., the RSVP_HOP) object of each Path message 1476 contains the previous hop address, i.e., the IP address of the 1477 interface through which the Path message was most recently 1478 sent. It also carries a logical interface handle (LIH). 1480 Each sender host periodically sends a Path message for each 1481 data flow it originates. The SENDER_TEMPLATE object defines 1482 the format of the data packets, while the SENDER_TSPEC object 1483 specifies the traffic characteristics of the flow. Optionally, 1484 there may be an ADSPEC object carrying advertising (OPWA) data 1485 for the flow. 1487 The Path message travels from a sender to receiver(s) along the 1488 same path(s) used by the data packets. The IP source address 1489 of a Path message is an address of the sender it describes, 1490 while the destination address is the DestAddress for the 1491 session. These addresses assure that the message will be 1492 correctly routed through a non-RSVP cloud. 1494 Each RSVP-capable node along the path(s) captures a Path 1495 message and processes it to create path state for the sender 1496 defined by the SENDER_TEMPLATE and SESSION objects. Any 1497 POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in 1498 the path state. If an error is encountered while processing a 1499 Path message, a PathErr message is sent to the originating 1500 sender of the Path message. Path messages must satisfy the 1501 rules on SrcPort and DstPort in Section 3.2. 1503 Periodically, the RSVP process at a node scans the path state 1504 to create new Path messages to forward towards the receiver(s). 1505 Each message contains a sender descriptor defining one sender, 1506 and carries the original sender's IP address as its IP source 1507 address. Path messages eventually reach the applications on 1508 all receivers; however, they are not looped back to a receiver 1509 running in the same application process as the sender. 1511 The RSVP process forwards Path messages and replicates them as 1512 required by multicast sessions, using routing information it 1513 obtains from the appropriate uni-/multicast routing process. 1514 The route depends upon the session DestAddress, and for some 1515 routing protocols also upon the source (sender's IP) address. 1516 The routing information generally includes the list of zero or 1517 more outgoing interfaces to which the Path message is to be 1518 forwarded. Because each outgoing interface has a different IP 1519 address, the Path messages sent out different interfaces 1520 contain different PHOP addresses. In addition, ADSPEC objects 1521 carried in Path messages will also generally differ for 1522 different outgoing interfaces. 1524 Some IP multicast routing protocols (e.g., DVMRP, PIM, and 1525 MOSPF) also keep track of the expected incoming interface for 1526 each source host to a multicast group. Whenever this 1527 information is available, RSVP should check the incoming 1528 interface of each Path message and do special handling of those 1529 messages Path messages that have arrived on the wrong 1530 interface; see Section 3.9. 1532 3.1.4 Resv Messages 1534 Resv messages carry reservation requests hop-by-hop from 1535 receivers to senders, along the reverse paths of data flows for 1536 the session. The IP destination address of a Resv message is 1537 the unicast address of a previous-hop node, obtained from the 1538 path state. The IP source address is an address of the node 1539 that sent the message. 1541 The Resv message format is as follows: 1543 ::= [ ] 1545 1547 1549 [ ] [ ] 1551 [ ... ] 1553