idnits 2.17.1 draft-ietf-rsvp-spec-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 5 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 24, 1995) is 10598 days in the past. Is this intentional? 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: 'TBD' is mentioned on line 2584, but not defined == Missing Reference: 'REST TBD' is mentioned on line 2610, but not defined == Unused Reference: 'CSZ92' is defined on line 2760, but no explicit reference was found in the text == Unused Reference: 'IServ93' is defined on line 2768, but no explicit reference was found in the text == Unused Reference: 'Partridge92' is defined on line 2771, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CSZ92' ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. 'ISInt93') -- Possible downref: Non-RFC (?) normative reference: ref. 'IServ93' ** Downref: Normative reference to an Informational RFC: RFC 1363 (ref. 'Partridge92') -- Possible downref: Non-RFC (?) normative reference: ref. 'Shenker94' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP93' Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Braden, Ed. 3 Expiration: September 1995 ISI 4 File: draft-ietf-rsvp-spec-05.txt L.Zhang 5 PARC 6 D. Estrin 7 ISI 8 S. Herzog 9 ISI 10 S. Jamin 11 USC 13 Resource ReSerVation Protocol (RSVP) -- 14 Version 1 Functional Specification 16 March 24, 1995 18 Status of Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 To learn the current status of any Internet-Draft, please check the 31 linebreak "1id-abstracts.txt" listing contained in the Internet- 32 Drafts Shadow Directories on ds.internic.net (US East Coast), 33 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au 34 (Pacific Rim). 36 Abstract 38 This memo describes version 1 of RSVP, a resource reservation setup 39 protocol designed for an integrated services Internet. RSVP provides 40 receiver-initiated setup of resource reservations for multicast or 41 unicast data flows, with good scaling and robustness properties. 43 What's Changed Since Toronto IETF 45 This version of the document incorporates many of the protocol changes 46 agreed to at the December 1994 IETF meeting in San Jose. The most major 47 changes are: 49 o The RSVP packet format has been reorganized to carry most data 50 as typed variable-length objects. 52 o This generality includes provision for 16-byte IP6 addresses. 54 o Filter specs have been simplified. 56 o DF style has been moved to an Appendix, as experimental. 58 o UDP encapsulation has been included. 60 o OPWA has been included. 62 o The Drop flag has been eliminated. 64 o Session groups have been added. 66 o The routing of RERR messages has been changed. 68 1. Introduction 70 This document defines RSVP, a resource reservation setup protocol 71 designed for an integrated services Internet [RSVP93,ISInt93]. 73 A host uses the RSVP protocol to request a specific quality of 74 service (QoS) from the network, on behalf of an application data 75 stream. RSVP is also used to deliver QoS requests to routers along 76 the path(s) of the data stream and to maintain router and host state 77 to provide the requested service. This will generally (but not 78 necessarily) require reserving resources along the data path. 80 RSVP reserves resources for simplex data streams, i.e., it reserves 81 resources in only one direction on a link, so that a sender is 82 logically distinct from a receiver. However, the same application 83 may act as both sender and receiver. RSVP operates on top of IP, 84 occupying the place of a transport protocol in the protocol stack. 85 However, like ICMP, IGMP, and routing protocols, RSVP does not 86 transport application data but is rather an Internet control 87 protocol. As shown in Figure 1, an implementation of RSVP, like the 88 implementations of routing and management protocols, will typically 89 execute in the background, not in the data forwarding path. 91 RSVP is not itself a routing protocol; the RSVP daemon consults the 92 local routing protocol(s) to obtain routes. Thus, a host sends IGMP 93 messages to join a multicast group, and it sends RSVP messages to 94 reserve resources along the delivery path(s) from that group. RSVP 95 is designed to operate with existing and future unicast and multicast 96 routing protocols. 98 HOST ROUTER 100 _________________________ RSVP ______________________ 101 | | .---------------. | 102 | _______ ______ | . | ________ . ______ | 103 | | | | | | . || | . | || RSVP 104 | |Applic-| | RSVP <----- ||Routing | -> RSVP <------> 105 | | App <----->daemon| | ||Protocol| |daemon|| 106 | | | | | | || daemon <----> || 107 | |_______| |___.__| | ||_ ._____| |__.___|| 108 |===|===============v=====| |===v=============v====| 109 | data .......... | | . ............ | 110 | | ____v_ ____v____ | | _v__v_ _____v___ | 111 | | |Class-| | || data | |Class-| | || data 112 | |=> ifier|=> Packet =============> ifier|==> Packet |======> 113 | |______| |Scheduler|| | |______| |Scheduler|| 114 | |_________|| | |_________|| 115 |_________________________| |______________________| 117 Figure 1: RSVP in Hosts and Routers 119 Each router that is capable of resource reservation passes incoming 120 data packets to a packet classifier and then queues them as necessary 121 in a packet scheduler. The packet classifier determines the route 122 and the QoS class for each packet. The scheduler allocates a 123 particular outgoing link for packet transmission, and it may also 124 allocate other system resources such as CPU time or buffers. 126 In order to efficiently accommodate heterogeneous receivers and 127 dynamic group membership and to be consistent with IP multicast, RSVP 128 makes receivers responsible for requesting resource reservations 129 [RSVP93]. A QoS request, typically originating in a receiver host 130 application, will be passed to the local RSVP implementation, shown 131 as a user daemon in Figure 1. The RSVP protocol is then used to pass 132 the request to all the nodes (routers and hosts) along the reverse 133 data path(s) to the data source(s). 135 At each node, the RSVP program applies a local decision procedure, 136 called "admission control", to determine if it can supply the 137 requested QoS. If admission control succeeds, the RSVP program sets 138 parameters to the packet classifier and scheduler to obtain the 139 desired QoS. If admission control fails at any node, the RSVP 140 program returns an error indication to the application that 141 originated the request. We refer to the packet classifier, packet 142 scheduler, and admission control components as "traffic control". 144 RSVP is designed to scale well for very large multicast groups. 145 Since the membership of a large group will be constantly changing, 146 the RSVP design assumes that router state for traffic control will be 147 built and destroyed incrementally. For this purpose, RSVP uses "soft 148 state" in the routers, in addition to receiver-initiation. 150 RSVP protocol mechanisms provide a general facility for creating and 151 maintaining distributed reservation state across a mesh of multicast 152 or unicast delivery paths. RSVP transfers reservation parameters as 153 opaque data (except for certain well-defined operations on the data), 154 which it simply passes to traffic control for interpretation. 155 Although the RSVP protocol mechanisms are largely independent of the 156 encoding of these parameters, the encodings must be defined in the 157 reservation model that is presented to an application (see Appendix 158 A). 160 In summary, RSVP has the following attributes: 162 o RSVP supports multicast or unicast data delivery and adapts to 163 changing group membership as well as changing routes. 165 o RSVP is simplex. 167 o RSVP is receiver-oriented, i.e., the receiver of a data flow is 168 responsible for the initiation and maintenance of the resource 169 reservation used for that flow. 171 o RSVP maintains "soft state" in the routers, enabling it to 172 gracefully support dynamic membership changes and automatically 173 adapt to routing changes. 175 o RSVP provides several reservation models or "styles" (defined 176 below) to fit a variety of applications. 178 o RSVP provides transparent operation through routers that do not 179 support it. 181 Further discussion on the objectives and general justification for 182 RSVP design are presented in [RSVP93,ISInt93]. 184 The remainder of this section describes the RSVP reservation 185 services. Section 2 presents an overview of the RSVP protocol 186 mechanisms, while Section 3 gives examples of the services and 187 mechanism. Section 4 contains the functional specification of RSVP. 188 Section 5 presents explicit message processing rules. 190 1.1 Data Flows 192 The set of data flows with the same unicast or multicast 193 destination constitute a session. RSVP treats each session 194 independently. All data packets in a particular session are 195 directed to the same IP destination address DestAddress, and 196 perhaps to some further demultiplexing point defined in a higher 197 layer (transport or application). We refer to the latter as a 198 "generalized destination port". 200 DestAddress is the group address for multicast delivery, or the 201 unicast address of a single receiver. A generalized destination 202 port could be defined by a UDP/TCP destination port field, by an 203 equivalent field in another transport protocol, or by some 204 application-specific information. Although the RSVP protocol is 205 designed to be easily extendible for greater generality, the 206 present version uses only UDP/TCP ports as generalized ports. 208 Figure 2 illustrates the flow of data packets in a single RSVP 209 session, assuming multicast data distribution. The arrows 210 indicate data flowing from senders S1 and S2 to receivers R1, R2, 211 and R3, and the cloud represents the distribution mesh created by 212 the multicast routing protocol. Multicast distribution forwards a 213 copy of each data packet from a sender Si to every receiver Rj; a 214 unicast distribution session has a single receiver R. Each sender 215 Si and each receiver Rj may correspond to a unique Internet host, 216 or a single host may contain multiple logical senders and/or 217 receivers, distinguished by generalized ports. 219 Senders Receivers 220 _____________________ 221 ( ) ===> R1 222 S1 ===> ( Multicast ) 223 ( ) ===> R2 224 ( distribution ) 225 S2 ===> ( ) 226 ( by Internet ) ===> R3 227 (_____________________) 229 Figure 2: Multicast Distribution Session 231 1.2 Reservation Model 233 An elementary RSVP reservation request consists of a "flowspec" 234 together with a "filter spec"; this pair is called a "flow 235 descriptor". The flowspec specifies a desired QoS. The filter 236 spec (together with the DestAddress and the generalized 237 destination port defining the session) defines the set of data 238 packets -- the "flow" -- to receive the QoS defined by the 239 flowspec. The flowspec is used to set parameters to the packet 240 scheduler in the node (assuming that admission control succeeds), 241 while the filter spec is used to set parameters in the packet 242 classifier. 244 The flowspec in a reservation request will generally include a 245 service type and two sets of numeric parameters: (1) an " Rspec" 246 (R for `reserve'), which defines the desired per-hop reservation, 247 and (2) a "Tspec" (T for `traffic'), which defines the parameters 248 that may be used to police the data flow, i.e., to ensure it does 249 not exceed its promised traffic level. 251 The general RSVP reservation model allows filter specs to select 252 arbitrary subsets of the packets in a given session. Such subsets 253 might be defined in terms of senders (i.e., sender IP address and 254 generalized source port), in terms of a higher-level protocol, or 255 generally in terms of any fields in any protocol headers in the 256 packet. For example, filter specs might be used to select 257 different subflows in a hierarchically-encoded signal, by 258 selecting on fields in an application-layer header. However, 259 considerations of both architectural purity and practical 260 requirements have led to the decision that RSVP should use 261 separate sessions for distinct subflows of hierarchically-encoded 262 signals. For multicast sessions, subflows can be distinguished by 263 multicast destination address; for unicast sessions, they must be 264 distinguished by destination port. As a result of these 265 considerations, the present RSVP version includes a quite 266 restricted definition of filter specs, selecting only on sender IP 267 address and UDP/TCP port number, and on protocol id. However, the 268 design of the protocol would easily handle a more general 269 definition in future versions. 271 Any packets that are addressed to a particular session but do not 272 match any of the filter specs for that session will be sent as 273 best-effort traffic. Under congested conditions, such packets are 274 likely to experience long delays and may be dropped. A receiver 275 may wish to conserve network resources by explicitly asking the 276 network to drop those data packets for which there is no 277 reservation; however, such dropping should be performed by 278 routing, not by RSVP. Determining where packets get delivered 279 should be a routing function; RSVP is concerned only with the QoS 280 of those packets that are delivered by routing. 282 RSVP reservation request messages originate at receivers and are 283 passed upstream towards the sender(s). (Note that this document 284 always uses the directional terms "upstream" vs. "downstream", 285 "previous hop" vs. "next hop", and "incoming interface" vs 286 "outgoing interface" with respect to the data flow direction). 287 When an elementary reservation request is received at a node, the 288 RSVP daemon takes two primary actions. 290 1. Make a reservation 292 The flowspec and the filter spec are passed to traffic 293 control. Admission Control determines the admissibility of 294 the request (if it's new); if it fails this test, the 295 reservation is rejected and RSVP sends back an error message 296 towards the responsible receiver(s). If it passes, the 297 flowspec is used to set up the packet scheduler for the 298 desired QoS and the filter spec is used to set the packet 299 classifier to select the appropriate data packets. 301 2. Forward reservation upstream. 303 The reservation request is propagated upstream towards the 304 appropriate senders. The set of senders to which a given 305 reservation request is propagated is called the "scope" of 306 that request. 308 The reservation request that a node forwards upstream may differ 309 from the request that it received, for two reasons. First, it is 310 possible (at least in theory) for the kernel to modify the 311 flowspec hop-by-hop (although currently no realtime services do 312 this). Second, reservations from different downstream branches of 313 the multicast distribution tree(s) must be "merged" as 314 reservations travel upstream. Merging reservations is a necessary 315 consequence of multicast distribution, which creates a single 316 stream of data packets in a particular router from any Si, 317 regardless of the set of receivers downstream. The reservation 318 for Si on a particular outgoing link L should be the "maximum" of 319 the individual flowspecs from the receivers Rj that are downstream 320 via link L. Merging is discussed further in Section 2.3. 322 For both of these primary actions, there are options controlled by 323 the receiver making the reservation. These options are combined 324 into a control variable called the reservation "style", which is 325 discussed in section 1.3. One option concerns the treatment of 326 reservations for different senders within the same session: 327 establish a "distinct" reservation for each upstream sender, or 328 else "mix" all senders' packets into a single reservation. 329 Another option controls the scope of the request: "unitary" (i.e., 330 a single specified sender), an explicit sender list, or a 331 "wildcard" that implicitly selects all senders upstream of the 332 given node. 334 The basic RSVP reservation model is "one pass": a receiver sends a 335 reservation request upstream, and each node in the path can only 336 accept or reject the request. This scheme provides no way to make 337 end-to-end service guarantees; the QoS request is applied 338 independently at each hop. RSVP also supports an optional 339 reservation model, known as " One Pass With Advertising" (OPWA) 340 [Shenker94]. In OPWA, RSVP control packets sent downstream, 341 following the data paths, are used to gather information on the 342 end-to-end service that would result from a variety of possible 343 reservation requests. The results ("advertisements") are 344 delivered by RSVP to the receiver host, and perhaps to the 345 receiver application. The information may then be used by the 346 receiver to construct an appropriate reservation request. 348 1.3 Reservation Styles 350 Each RSVP reservation request specifies a "reservation style". 351 The following reservation styles are defined in this version of 352 the protocol. 354 1. Wildcard-Filter (WF) Style 356 The WF style specifies the options: "mixing" reservation and 357 " wildcard" reservation scope. Thus, a WF-style reservation 358 creates a single reservation into which flows from all 359 upstream senders are mixed. This reservation may be thought 360 of a shared "pipe", whose "size" is the largest of the 361 resource requests for that link from all receivers, 362 independent of the number of senders using it. A WF-style 363 reservation has wildcard scope, i.e., the reservation is 364 propagated upstream towards all senders. A WF-style 365 reservation automatically extends to new senders to the 366 session as they appear. 368 2. Fixed-Filter (FF) Style 370 The FF style specifies the options: "distinct" reservation 371 and a "unitary" reservation scope. Thus, an elementary FF- 372 style reservation request creates a distinct reservation for 373 data packets from a particular sender, not mixing them with 374 other senders' packets for the same session. 376 The total reservation on a link for a given session is the 377 total of the FF reservations for all requested senders. On 378 the other hand, FF reservations requested by different 379 receivers Rj but selecting the same sender Si must 380 necessarily be merged to share a single reservation in a 381 given node. 383 WF reservations are appropriate for those multicast applications 384 whose application-specific constraints make it unlikely that 385 multiple data sources will transmit simultaneously. One example is 386 audio conferencing, where a limited number of people talk at once; 387 each receiver might issue a WF reservation request for twice one 388 audio channel (to allow some over-speaking). On the other hand, 389 the FF style, which creates independent reservations for the flows 390 from different senders, is appropriate for video signals. 392 The WF and FF styles are incompatible and cannot be combined 393 within a session. Other reservation styles may be defined in the 394 future (see Appendix C). 396 2. RSVP Protocol Mechanisms 398 2.1 RSVP Messages 400 There are two fundamental RSVP message types, RESV messages and 401 PATH messages. 403 Each receiver host sends RSVP reservation request (RESV) messages 404 towards the senders. These reservation messages must follow in 405 reverse the routes the data packets will use, all the way upstream 406 to the senders within the scope. RESV messages are delivered to 407 the sender hosts, so that the hosts can set up appropriate traffic 408 control parameters for the first hop. If a reservation request 409 fails at any node, an RSVP error message is returned to the 410 receiver; however, RSVP sends no positive acknowledgment messages 411 to indicate success. 413 Sender Receiver 414 _____________________ 415 Path --> ( ) 416 Si =======> ( Multicast ) Path --> 417 <-- Resv ( ) =========> Rj 418 ( distribution ) <-- Resv 419 (_____________________) 421 Figure 3: RSVP Messages 423 Each sender transmits RSVP PATH messages forward along the uni- 424 /multicast routes provided by the routing protocol(s); see Figure 425 3. These "Path" messages store path state in each node. Path 426 state is used by RSVP to route the RESV messages hop-by-hop in the 427 reverse direction. (In the future, some routing protocols may 428 supply reverse path forwarding information directly, without path 429 state). 431 PATH messages may also carry the following information: 433 o Sender Template 435 The Sender Template describes the format of data packets that 436 the sender will originate. This template is in the form of a 437 filter spec that could be used to select this sender's 438 packets from others in the same session on the same link. 440 o Tspec 442 The PATH message may optionally carry a flowspec containing 443 only a Tspec, defining an upper bound on the traffic level 444 that the sender will generate. This Tspec can be used by 445 RSVP to prevent over-reservation (and perhaps unnecessary 446 Admission Control failure) on the non-shared links starting 447 at the sender. 449 o Adspec 451 The PATH message may carry a package of OPWA advertising 452 information, known as an "Adspec". 454 Previous Incoming Outgoing Next 455 Hops Interfaces Interfaces Hops 457 _____ _____________________ _____ 458 | | data --> | | data --> | | 459 | A |-----------| a c |--------------| C | 460 |_____| <-- Resv | | <-- Resv |_____| 461 Path --> | | Path --> _____ 462 _____ | ROUTER | | | | 463 | | | | | |--| D | 464 | B |--| data-->| | data --> | |_____| 465 |_____| |--------| b d |-----------| 466 |<-- Resv| | <-- Resv | _____ 467 _____ | Path-->|_____________________| Path --> | | | 468 | | | |--| D' | 469 | B' |--| | |_____| 470 |_____| | | 472 Figure 4: Router Using RSVP 474 Figure 4 illustrates RSVP's model of a router node. Each data 475 stream arrives from a previous hop through a corresponding 476 incoming interface and departs through one or more outgoing 477 interface(s). The same physical interface may act in both the 478 incoming and outgoing roles (for different data flows but the same 479 session). 481 As illustrated in Figure 4, there may be multiple previous hops 482 and/or next hops through a given physical interface. This may 483 result from the connected network being a shared medium or from 484 the existence of non-RSVP routers in the path to the next RSVP hop 485 (see Section 2.6). An RSVP daemon must preserve the next and 486 previous hop addresses in its reservation and path state, 487 respectively. A RESV message is sent with a unicast destination 488 address, the address of a previous hop. PATH messages, on the 489 other hand, are sent with the session destination address, unicast 490 or multicast. 492 Although multiple next hops may send reservation requests through 493 the same physical interface, the final effect should be to install 494 a reservation on that interface, which is defined by an effective 495 flowspec. This effective flowspec will be the "maximum" of the 496 flowspecs requested by the different next hops. In turn, a RESV 497 message forwarded to a particular previous hop carries a flowspec 498 that is the "maximum" over the effective reservations on the 499 corresponding outgoing interfaces. Both cases represent merging, 500 which is discussed further below. 502 There are a number of ways for a new reservation request to fail 503 in a given node. 505 1. There may be no matching path state (i.e., the scope may 506 empty), which would prevent the reservation being propagated 507 upstream. 509 2. Its style may be incompatible with the style(s) of existing 510 reservations for the same session on the same outgoing 511 interface, so an effective flowspec cannot be computed. 513 3. Its style may be incompatible with the style(s) of 514 reservations that exist on other outgoing interfaces but will 515 be merged with this reservation when a refresh message to 516 create a refresh message for the previous hop. 518 4. The effective flowspec may fail admission control. 520 In any of these cases, an error message is returned to the 521 receiver(s) responsible for the message, but any existing 522 reservation is left in place. This prevents a new, very large, 523 reservation from disrupting the existing QoS by merging with an 524 existing reservation and then failing admission control. 526 2.2 Soft State 528 To maintain reservation state, RSVP keeps "soft state" in router 529 and host nodes. RSVP soft state is created and periodically 530 refreshed by PATH and RESV messages. The state is deleted if no 531 refreshes arrive before the expiration of a "cleanup timeout" 532 interval; it may also be deleted as the result of an explicit 533 "Teardown" message. It is not necessary (although it may be 534 desirable, since the resources being consumed may be "valuable"), 535 to explicitly tear down an old reservation. 537 When a route changes, the next PATH message will initialize the 538 path state on the new route, and future RESV messages will 539 establish reservation state, while the state on the now-unused 540 segment of the route will time out. Thus, whether a message is 541 "new" or a "refresh" is determined separately at each node, 542 depending upon the existence of state at that node. (This 543 document uses the term "refresh message" in this effective sense, 544 to indicate an RSVP message that does not modify the existing 545 state at the node in question.) 546 In addition to the cleanup timeout, there is a "refresh timeout" 547 period. As messages arrive, the RSVP daemon checks them against 548 the existing state; if it matches, the cleanup timeout timer on 549 the state is reset and the message is dropped. At the expiration 550 of each refresh timeout period, RSVP scans its state to build and 551 forward PATH and RESV refresh messages to succeeding hops. 553 RSVP sends its messages as IP datagrams without reliability 554 enhancement. Periodic transmission of refresh messages by hosts 555 and routers is expected to replace any lost RSVP messages. To 556 tolerate K successive packet losses, the effective cleanup timeout 557 must be at least K times the refresh timeout. In addition, the 558 traffic control mechanism in the network should be statically 559 configured to grant high-reliability service to RSVP messages, to 560 protect RSVP messages from congestion losses. 562 In steady state, refreshing is performed hop-by-hop, which allows 563 merging and packing as described in the next section. However, if 564 the received state differs from the stored state, the stored state 565 is updated. Furthermore, if the result will be to modify the 566 refresh messages to be generated, these refresh messages must be 567 generated and forwarded immediately. This will result in changes 568 propagating end-to-end without delay. However, propagation of a 569 change stops when and if it reaches a point where merging causes 570 no resulting state change; this minimizes RSVP control traffic due 571 to changes, and is essential for scaling to large multicast 572 groups. 574 The "soft" router state maintained by RSVP is dynamic; to change 575 the set of senders Si or receivers Rj or to change any QoS 576 request, a host simply starts sending revised PATH and/or RESV 577 messages. The result should be the appropriate adjustment in the 578 distributed RSVP state, and immediate propagation to the 579 succeeding nodes. 581 The RSVP state associated with a session in a particular node is 582 divided into atomic elements that are created, refreshed, and 583 timed out independently. The atomicity is determined by the 584 requirement that any sender or receiver may enter or leave the 585 session at any time, and its state should be created and timed out 586 independently. Management of RSVP state is complex because there 587 may not be a one-to-one correspondence between state carried in 588 RSVP control messages and the resulting state in nodes. Due to 589 merging, a single message contain state referring to multiple 590 stored elements. Conversely, due to reservation sharing, a single 591 stored state element may depend upon (typically, the maximum of) 592 state values received in multiple control messages. 594 2.3 Merging and Packing 596 A previous section explained that reservation requests in RESV 597 messages are necessarily merged, to match the multicast 598 distribution tree. As a result, only the essential (i.e., the 599 "largest") reservation requests are forwarded, once per refresh 600 period. A successful reservation request will propagate as far as 601 the closest point(s) along the sink tree to the sender(s) where a 602 reservation level equal or greater than that being requested has 603 been made. At that point, the merging process will drop it in 604 favor of another, equal or larger, reservation request. 606 Although flowspecs are opaque to RSVP, an RSVP daemon must be able 607 to calculate the "largest" of a set of flowspecs. This is 608 required both to calculate the effective flowspec to install on a 609 given physical interface (see the discussion in connection with 610 Figure 4), and to merge flowspecs when sending a refresh message 611 upstream. Since flowspecs are generally multi-dimensional vectors 612 (they contain both Tspec and Rspec components, each of which may 613 itself be multi-dimensional), they are not strictly ordered. When 614 it cannot take the larger of two flowspecs, RSVP must compute and 615 use a third flowspec that is at least as large as each, i.e., a 616 "least upper bound" (LUB). It is also possible for two flowspecs 617 to be incomparable, which is treated as an error. The definition 618 and implementation of the rules for comparing flowspecs are 619 outside RSVP proper, but they are defined as part of the service 620 templates. 622 For protocol efficiency, RSVP also allows multiple sets of path 623 (or reservation) information for the same session to be "packed" 624 into a single PATH (or RESV) message, respectively. (For 625 simplicity, the protocol prohibits packing different sessions into 626 the same RSVP message). 628 2.4 Teardown 630 RSVP teardown messages remove path and reservation state without 631 waiting for the cleanup timeout period, as an optimization to 632 release resources quickly. Although teardown messages (like other 633 RSVP messages) are not delivered reliably, the state will time out 634 even if it is not explicitly deleted. 636 A teardown request may be initiated either by an application in an 637 end system (sender or receiver), or by a router as the result of 638 state timeout. A router may also initiate a teardown message as 639 the result of router or link failures detected by the routing 640 protocol. Once initiated, a teardown request should be forwarded 641 hop-by-hop without delay. 643 To increase the reliability of teardown, Q copies of any given 644 teardown message can be sent. Note that a node cannot actually 645 delete the state being torn down until it has sent Q Teardown 646 messages; it must place the state in a "moribund" status 647 meanwhile. The appropriate value of Q is an engineering issue. Q 648 = 1 would be the simplest and may be adequate, since unrefreshed 649 state will time out anyway; teardown is an optimization. If one 650 or more Teardown message hops are lost, the router that failed to 651 receive a Teardown message will time out its state and initiate a 652 new Teardown message beyond the loss point. Assuming that RSVP 653 message loss probability is small, the longest time to delete 654 state will seldom exceed one refresh timeout period. 656 There are two types of RSVP Teardown message, PTEAR and RTEAR. A 657 PTEAR message travels towards all receivers downstream from its 658 point of initiation and tears down path state along the way. A 659 RTEAR message tears down reservation state and travels towards all 660 senders upstream from its point of initiation. A PTEAR (RTEAR) 661 message may be conceptualized as a reversed-sense Path message 662 (Resv message, respectively). 664 A teardown message deletes the specified state in the node where 665 it is received. Like any other state change, this will be 666 propagated immediately to the next node, but only if it represents 667 a change. As a result, an RTEAR message will prune the 668 reservation state back (only) as far as possible. Note that the 669 RTEAR message will cease to be forwarded at the same node where 670 merging suppresses forwarding of the corresponding RESV messages. 671 The change will be propagated as a new teardown message if the 672 result has been to remove all state for this session at this node. 673 However, the result may simply be to change the propagated 674 information; thus, the receipt of a RTEAR message may result in 675 the immediate forwarding of a modified RESV refresh message. 677 Deletion of path state, whether as the result of a teardown 678 message or because of timeout, may force adjustments in order in 679 related reservation state to maintain consistency in the local 680 node. For example, when a PTEAR deletes the path state for a 681 sender S, the adjustment in reservation depends upon the style: if 682 the style is WF and S is the only sender to the session, delete 683 the reservation; if the style is FF, delete only reservations for 684 sender S. These reservation changes should not trigger an 685 immediate RESV refresh message, since the teardown message will 686 have already made the required changes upstream. However, at the 687 node in which an RTEAR message stops, the change of reservation 688 state may trigger a RESV refresh starting at that node. 690 2.5 Security 692 There are two distinct types of security concerns in RSVP. 694 1. Protecting RSVP Message Integrity 696 It may be necessary to ensure the integrity of RSVP messages 697 against corruption or spoofing, hop by hop. RSVP messages 698 have an optional integrity field that can be created and 699 verified by neighboring RSVP nodes. 701 2. Authenticating Reservation Requests 703 RSVP-mediated resource reservations may reserve network 704 resources, providing special treatment for a particular set 705 of users. Administrative mechanisms will be necessary to 706 control who gets privileged service and to collect billing 707 information. These mechanisms may require secure 708 authentication of senders and/or receivers responsible for 709 the reservation. RSVP messages may contain credential 710 information to verify user identity. 712 The RSVP packet formats provide for both; see Section 4. 714 2.6 Automatic RSVP Tunneling 716 It is impossible to deploy RSVP (or any new protocol) at the same 717 moment throughout the entire Internet. Furthermore, RSVP may 718 never be deployed everywhere. RSVP must therefore provide correct 719 protocol operation even when two RSVP-capable routers are joined 720 by an arbitrary "cloud" of non-RSVP routers. Of course, an 721 intermediate cloud that does not support RSVP is unable to perform 722 resource reservation, so service guarantees cannot be made. 723 However, if there is sufficient excess capacity through such a 724 cloud, acceptable and useful realtime service may still be 725 possible. 727 RSVP will automatically tunnel through such a non-RSVP cloud. 728 Both RSVP and non-RSVP routers forward PATH messages towards the 729 destination address using their local uni-/multicast routing 730 table. Therefore, the routing of Path messages will be 731 unaffected by non-RSVP routers in the path. When a PATH message 732 traverses a non-RSVP cloud, the copies that emerge will carry as a 733 Previous Hop address the IP address of the last RSVP-capable 734 router before entering the cloud. This will effectively construct 735 a tunnel through the cloud for RESV messages, which will be 736 forwarded directly to the next RSVP-capable router on the path(s) 737 back towards the source. 739 Automatic tunneling is not perfect; in some circumstances it may 740 distribute path information to RSVP-capable routers not included 741 in the data distribution paths, which may create unused 742 reservations at these routers. This is because PATH messages 743 carry the IP source address of the previous hop, not of the 744 original sender, and multicast routing may depend upon the source 745 as well as the destination address. This can be overcome by 746 manual configuration of the neighboring RSVP programs, when 747 necessary. 749 2.7 Session Groups 751 Section 1.2 explained that a distinct destination address, and 752 therefore a distinct session, will be used for each of the 753 subflows in a hierarchically encoded flow. However, these 754 separate sessions are logically related. For example it may be 755 necessary to pass reservations for all subflows to Admission 756 Control at the same time (since it would be nonsense to admit high 757 frequency components but reject the baseband component of the 758 session data). Such a logical grouping is indicated in RSVP by 759 defining a "session group", an ordered set of sessions. 761 To declare that a set of sessions form a session group, a receiver 762 includes a data structure we call a SESSION_GROUP object in the 763 RESV message for each of the sessions. A SESSION_GROUP object 764 contains four fields: a reference address, a session group ID, a 765 count, and a rank. 767 o The reference address is an agreed-upon choice from among the 768 DestAddress values of the sessions in the group, for example 769 the smallest numerically. 771 o The session group ID is used to distinguish different groups 772 with the same reference address. 774 o The count is the number of members in the group. 776 o The rank, an integer between 1 and count, is different in 777 each session of the session group. 779 The SESSION_GROUP objects for all sessions in the group will 780 contain the same values of the reference address, the session 781 group ID, and the count value. The rank values establishes the 782 desired order among them. 784 If RSVP at a given node receives a RESV message containing a 785 SESSION_GROUP object, it should wait until RESV messages for all 786 `count' sessions have appeared (or until the end of the refresh 787 cycle) and then pass the RESV requests to Admission Control as a 788 group. It is normally expected that all sessions in the group 789 will be routed through the same nodes. However, if not, only a 790 subset of the session group reservations may appear at a given 791 node; in this case, the RSVP should wait until the end of the 792 refresh cycle and then perform Admission Control on the subset of 793 the session group that it has received. The rank values will 794 identify which are missing. 796 Note that routing different sessions of the session group 797 differently will generally result in delays in establishing or 798 rejecting the desired QoS. A "bundling" facility could be added 799 to multicast routing, to force all sessions in a session group to 800 be routed along the same path. 802 2.8 Host Model 804 Before a session can be created, the session identification, 805 comprised of DestAddress and perhaps the generalized destination 806 port, must be assigned and communicated to all the senders and 807 receivers by some out-of-band mechanism. In order to join an RSVP 808 session, the following events happen at the end systems. 810 H1 A receiver joins the multicast group specified by 811 DestAddress, using IGMP. 813 H2 A potential sender starts sending RSVP PATH messages to the 814 DestAddress, using RSVP. 816 H3 A receiver listens for PATH messages. 818 H4 A receiver starts sending appropriate RESV messages, 819 specifying the desired flow descriptors, using RSVP. 821 H5 A sender starts sending data packets. 823 There are several synchronization considerations. 825 o Suppose that a new sender starts sending data (H5) but no 826 receivers have joined the group (H1). Then there will be no 827 multicast routes beyond the host (or beyond the first RSVP- 828 capable router) along the path; the data will be dropped at 829 the first hop until receivers(s) do appear (assuming a 830 multicast routing protocol that "prunes off" or otherwise 831 avoids unnecessary paths). 833 o Suppose that a new sender starts sending PATH messages (H2) 834 and immediately starts sending data (H5), and there are 835 receivers but no RESV messages have reached the sender yet 836 (e.g., because its PATH messages have not yet propagated to 837 the receiver(s)). Then the initial data may arrive at 838 receivers without the desired QoS. 840 o If a receiver starts sending RESV messages (H4) before any 841 PATH messages have reached it (H5) (and if path state is 842 being used to route RESV messages), RSVP will return error 843 messages to the receiver. The receiver may simply choose to 844 ignore such error messages, or it may avoid them by waiting 845 for PATH messages before sending RESV messages. 847 A specific application program interface (API) for RSVP is not 848 defined in this protocol spec, as it may be host system dependent. 849 However, Section 4.6.1 discusses the general requirements and 850 presents a generic API. 852 3. Examples 854 We use the following notation for a RESV message: 856 1. Wildcard-Filter 858 WF( *{Q}) 860 Here "*{Q}" represents a Flow Descriptor with a "wildcard" scope 861 (choosing all senders) and a flowspec of quantity Q. 863 2. Fixed-Filter 865 FF( S1{Q1}, S2{Q2}, ...) 867 A list of (sender, flowspec) pairs, i.e., flow descriptors, 868 packed into a single RESV message. 870 For simplicity we assume here that flowspecs are one-dimensional, 871 defining for example the average throughput, and state them as a 872 multiple of some unspecified base resource quantity B. 874 Figure 5 shows schematically a router with two previous hops labeled 875 (a) and (b) and two outgoing interfaces labeled (c) and (d). This 876 topology will be assumed in the examples that follow. There are 877 three upstream senders; packets from sender S1 (S2 and S3) arrive 878 through previous hop (a) ((b), respectively). There are also three 879 downstream receivers; packets bound for R1 and R2 (R3) are routed via 880 outgoing interface (c) ((d) respectively). 882 In addition to the connectivity shown in 5, we must also specify the 883 multicast routing within this node. Assume first that data packets 884 (hence, PATH messages) from each Si shown in Figure 5 is routed to 885 both outgoing interfaces. Under this assumption, Figures 6 and 7 886 illustrate Wildcard-Filter reservations and Fixed-Filter 887 reservations, respectively. 889 ________________ 890 (a)| | (c) 891 ( S1 ) ---------->| |----------> ( R1, R2) 892 | Router | 893 (b)| | (d) 894 ( S2,S3 ) ------->| |----------> ( R3 ) 895 |________________| 897 Figure 5: Router Configuration 899 In Figure 6, the "Receive" column shows the RESV messages received 900 over outgoing interfaces (c) and () and the "Reserve" column shows 901 the resulting reservation state for each interface. The "Send" 902 column shows the RESV messages forwarded to previous hops (a) and 903 (b). In the "Reserve" column, each box represents one reservation 904 "channel", with the corresponding filter. As a result of merging, 905 only the largest flowspec is forwarded upstream to each previous hop. 907 | 908 Send | Reserve Receive 909 | 910 | _______ 911 WF( *{3B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} ) 912 | |_______| 913 | 914 -----------------------|---------------------------------------- 915 | _______ 916 WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) 917 | |_______| 919 Figure 6: Wildcard-Filter Reservation Example 1 921 Figure 7 shows Fixed-Filter style reservations. The flow descriptors 922 for senders S2 and S3, received from outgoing interfaces (c) and (d), 923 are packed into the message forwarded to previous hop b. On the 924 other hand, the two different flow descriptors for sender S1 are 925 merged into the single message FF( S1{3B} ), which is sent to 926 previous hop (a), For each outgoing interface, there is a private 927 reservation for each source that has been requested, but this private 928 reservation is shared among the receivers that made the request. 930 | 931 Send | Reserve Receive 932 | 933 | ________ 934 FF( S1{3B} ) <- (a) | (c) | S1{B} | (c) <- FF( S1{B}, S2{5B} ) 935 | |________| 936 | | S2{5B} | 937 | |________| 938 ---------------------|--------------------------------------------- 939 | ________ 940 <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) 941 FF( S2{5B}, S3{B} ) | |________| 942 | | S3{B} | 943 | |________| 945 Figure 7: Fixed-Filter Reservation Example 947 The two examples just shown assume full routing, i.e., data packets 948 from S1, S2, and S3 are routed to both outgoing interfaces. Assume 949 the routing shown in Figure 8, in which data packets from S1 are not 950 forwarded to interface (d) (because the mesh topology provides a 951 shorter path for S1 -> R3 that does not traverse this node). 953 _______________ 954 (a)| | (c) 955 ( S1 ) ---------->| --------->--> |----------> ( R1, R2) 956 | / | 957 | / | 958 (b)| / | (d) 959 ( S2,S3 ) ------->| ->----------> |----------> ( R3 ) 960 |_______________| 962 Figure 8: Router Configuration 964 Under this assumption, Figure 9 shows Wildcard-Filter reservations. 965 Since there is no route from (a) to (d), the reservation forwarded 966 out interface (a) considers only the reservation on interface (c), so 967 no merging takes place in this case. 969 | 970 Send | Reserve Receive 971 | 972 | _______ 973 WF( *{B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} ) 974 | |_______| 975 | 976 -----------------------|---------------------------------------- 977 | _______ 978 WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) 979 | |_______| 981 Figure 9: Wildcard-Filter Reservation Example -- Partial Routing 983 4. RSVP Functional Specification 985 4.1 RSVP Message Formats 987 All RSVP messages consist of a common header followed by a 988 variable number of variable-length typed "objects" using a common 989 structure. The subsections that follow define the formats of the 990 common header, the object structures, and each of the RSVP message 991 types. For each RSVP message type, there is a set of rules for 992 the permissible ordering and choice of object types. These rules 993 are specified using Backus-Naur Form (BNF) augmented with square 994 brackets surrounding optional sub-sequences. 996 4.1.1 Common Header 998 0 1 2 3 999 +-------------+-------------+-------------+-------------+ 1000 | Vers | Type | Flags | Message Length | 1001 +-------------+-------------+-------------+-------------+ 1002 | RSVP Checksum | Object Count | 1003 +-------------+-------------+-------------+-------------+ 1005 The common header fields are as follows: 1007 Vers 1009 Protocol version number. This is version 2. 1011 Type 1013 1 = PATH 1015 2 = RESV 1017 3 = PERR 1019 4 = RERR 1021 5 = PTEAR 1023 6 = RTEAR 1025 Flags 1027 0x01 = Entry-Police 1028 This flag should be on in a PATH message sent by an 1029 RSVP daemon in a sender host. The first RSVP node 1030 that finds the flag on in a PATH message (i.e., the 1031 first-[RSVP-]hop router) should institute policing 1032 for the flow(s) described in this message. This flag 1033 should never be forwarded in PATH refresh messages. 1035 0x02 = LUB-Used 1037 This flag is described below in the section on Error 1038 Messages. 1040 Message Length 1042 The total length of this RSVP message, including this 1043 common header and the objects included in Object Count. 1045 RSVP Checksum 1047 A standard TCP/UDP checksum over the contents of the RSVP 1048 message, with the checksum field replaced by zero. 1050 Object Count 1052 Count of variable-length objects that follow. 1054 4.1.2 Object Formats 1056 An object consists of one or more 32-bit words with a one-word 1057 header, in the following format: 1059 0 1 2 3 1060 +-------------+-------------+-------------+-------------+ 1061 | Length (bytes) | Class | C-Type | 1062 +-------------+-------------+-------------+-------------+ 1063 | | 1064 // (Object contents) // 1065 | | 1066 +-------------+-------------+-------------+-------------+ 1068 An object header has the following fields: 1070 Length 1072 Total length in bytes. Must always be a multiple of 4, 1073 and at least 4. 1075 Class 1077 Object class. In this document, the names of object 1078 classes are capitalized. 1080 0 = NULL 1082 A NULL object has a Class of zero; its C-Type is 1083 ignored. Its length must be at least 4, but can be 1084 any multiple of 4. A NULL object may appear anywhere 1085 in a sequence of objects, and its contents will be 1086 ignored by the receiver. 1088 1 = SESSION 1090 Contains the IP destination address (DestAddress) and 1091 possibly a generalized source port, to define a 1092 specific session for the other objects that follow. 1093 Required in every RSVP message. 1095 2 = SESSION_GROUP 1097 When present, defines a session group, a set of 1098 related sessions whose reservation requests should be 1099 passed collectively to Admission Control. 1101 3 = RSVP_HOP 1103 Carries the IP address of the RSVP-capable node that 1104 sent this message. This document refers to a 1105 RSVP_HOP object as a PHOP ("previous hop") object for 1106 downstream messages or as a NHOP ("next hop") object 1107 for upstream messages. 1109 4 = STYLE 1111 Defines the reservation style plus style-specific 1112 information that is not a FLOWSPEC or FILTER_SPEC 1113 object, in a RESV message. 1115 5 = FLOWSPEC 1117 Defines a desired QoS, in a RESV message. 1119 6 = FILTER_SPEC 1121 Defines a subset of session data packets that should 1122 receive the desired QoS (specified by an FLOWSPEC 1123 object), in a RESV message. 1125 7 = SENDER_TEMPLATE 1127 Contains a sender IP address and perhaps some 1128 additional demultiplexing information to identify a 1129 sender, in a PATH message. 1131 8 = SENDER_TSPEC 1133 Defines the traffic characteristics of a sender's 1134 data stream, in a PATH message. 1136 9 = ADVERT 1138 Carries an Adspec containing OPWA data, in a PATH 1139 message. 1141 10 = TIME_VALUES 1143 If present, contains values for the refresh period R 1144 and the state time-to-live T (see section 4.5), to 1145 override the default values of R and T. 1147 11 = ERROR_SPEC 1149 Specifies an error, in a PERR or RERR message. 1151 12 = CREDENTIAL 1153 Contains user credential and/or information for 1154 policy control and/or accounting. 1156 13 = INTEGRITY 1158 Contains a cryptographic data to authenticate the 1159 originating node, and perhaps verify the contents, of 1160 this RSVP message. 1162 C-Type 1164 Object type; unique within Class. Values defined in 1165 Appendix A. 1167 The Class and C-Type fields may be used together as a 16-bit 1168 number to define a unique type for each object. 1170 The formats of specific object types are defined in Appendix A. 1172 4.1.3 Path Message 1174 PATH messages carry information from senders to receivers along 1175 the same paths, and using the same uni-/multicast routes, as 1176 the data packets. The IP destination address of a PATH message 1177 is the DestAddress for the session, and the source address is 1178 an address of the node that sent the message (if possible, the 1179 address of the particular interface through which it was sent). 1181 The format of a PATH message is as follows: 1183 ::= 1185 [ ] [ ] 1187 1189 ::= | 1191 1193 ::= [ ] 1195 [ ] [ ] 1197 Each sender descriptor defines a sender, and the sender 1198 descriptor list allows multiple sender descriptors to be packed 1199 into a PATH message. For each sender in the list, the 1200 SENDER_TEMPLATE object defines the format of data packets, the 1201 SENDER_TSPEC object may specify the traffic flow, and the 1202 CREDENTIAL object may specify the user credentials. There may 1203 also be an ADVERT object carrying advertising (OPWA) data. 1205 Each sender host must periodically send a PATH message 1206 containing the sender descriptor(s) describing its own data 1207 stream(s), for a given session. Each sender descriptor is 1208 forwarded and replicated as necessary to follow the delivery 1209 path(s) for a data packet from the same sender, finally 1210 reaching the applications on all receivers (except not a 1211 receiver included in the sender process). 1213 At each node, a route must be computed independently for each 1214 sender descriptors being forwarded. These routes, obtained 1215 from the uni/multicast routing table, generally depend upon the 1216 (sender host address, DestAddress) pairs, and consist of a list 1217 of outgoing interfaces. Then the descriptors being forwarded 1218 through the same outgoing interface can be packed into as few 1219 PATH messages as possible. Note that multicast routing of path 1220 information is based on the sender address(es) from the sender 1221 descriptors, not the IP source address; this is necessary to 1222 prevent routing loops; see Section 4.3. PHOP (i.e., the 1223 RSVP_HOP object) of each PATH message should contain the IP 1224 source address, the interface address through which the message 1225 is sent. 1227 PATH messages are processed at each node they reach to create 1228 path state, which includes SENDER_TEMPLATE object and possibly 1229 CREDENTIAL, SENDER_TSPEC, and ADVERT objects. If an error is 1230 encountered while processing a PATH message, a PERR message is 1231 sent to all senders implied by the SENDER_TEMPLATEs in the 1232 sender descriptor list. 1234 4.1.4 Resv Messages 1236 RESV messages carry reservation requests hop-by-hop from 1237 receivers to senders, along the reverse paths of data flow for 1238 the session. The IP destination address of a RESV message is 1239 the unicast address of a previous-hop node, obtained from the 1240 path state. The Next Hop address (in the RSVP_HOP object) 1241 should be the IP address of the (incoming) interface through 1242 which the RESV message is sent. The IP source address is an 1243 address of the node that sent the message (if possible, the 1244 address of the particular interface through which it was sent). 1246 The permissible sequence of objects in a RESV message depends 1247 upon the reservation style specified in the STYLE object. 1248 Currently, object types Style-WF and Style-FF of class STYLE 1249 are defined (see Appendix A). 1251 The RESV message format is as follows: 1253 ::= 1255 [ ] 1257 [ ] [ ] 1259 [ ] 1261 1263 ::= 1265 [ ] | 1266 1268 ::= | 1270 1272 The reservation scope, i.e., the set of senders towards which a 1273 particular reservation is to be forwarded, is determined by 1274 matching FILTER_SPEC objects against the path state created 1275 from SENDER_TEMPLATE objects, considering any wildcards that 1276 may be present. 1278 4.1.5 Error Messages 1280 There are two types of RSVP error messages: 1282 o PERR messages result from PATH messages and travel towards 1283 senders. PERR messages are routed hop-by-hop like RESV 1284 messages; at each hop, the IP destination address is the 1285 unicast address of a previous hop. 1287 o RERR messages result from RESV messages and travel hop- 1288 by-hop towards the appropriate receivers, routed by the 1289 reservation state. At each hop, the IP destination 1290 address is the unicast address of a next-hop node. 1291 Routing is discussed below. 1293 RSVP error messages are triggered only by processing of PATH 1294 and RESV messages; errors encountered while processing error or 1295 teardown messages must not create error messages. 1297 ::= 1299 [ ] 1301 1303 ::= (see earlier definition) 1305 ::= 1307 [ ] 1309 [ ] 1311 ::= (see earlier definition) 1313 The ERROR_SPEC specifies the error. It includes the IP address 1314 of the node that detected the error, called the Error Node 1315 Address. 1317 When a PATH or RESV message has been "packed" with multiple 1318 sets of elementary parameters, the RSVP implementation should 1319 process each set independently and return a separate error 1320 message for each that is in error. 1322 An error message may be duplicated and forwarded unchanged. In 1323 general, error messages should be delivered to the applications 1324 on all the session nodes that (may have) contributed to this 1325 error. 1327 o A PERR message is forwarded to all previous hops for all 1328 senders listed in the Sender Descriptor List. 1330 o The node that creates a RERR message as the result of 1331 processing a RESV message should send the RERR message out 1332 the interface through which the RESV arrived. 1334 In succeeding hops, the routing of a RERR message depends 1335 upon its style and upon routing. In general, a RERR 1336 message is sent out some subset of the outgoing interfaces 1337 specified for multicast routing, using Error Node Address 1338 as the source address and DestAddress as the destination. 1339 (This rule is necessary to prevent packet loops; see 1340 Section 4.3 below). Within this set of outgoing 1341 interfaces, a RERR message is sent only to next hop(s) 1342 whose RESV message(s) created the error; this in turn 1343 depends upon the merging of flowspecs. Assume that a 1344 reservation whose error is being reported was formed by 1345 merging two flowspecs Q1 and Q2 from different next hops. 1347 - If Q1 = Q2, the error message should be forwarded to 1348 both next hops. 1350 - If Q1 < Q2, the error message should be forwarded 1351 only to the next hop for Q2. 1353 - If Q1 and Q2 are incomparable, the error message 1354 should be forwarded to both next hops, and the LUB 1355 flag should be turned on. 1357 The ERROR_SPEC and the LUB-flag should be delivered to the 1358 receiver application. In the case of an Admission Control 1359 error, the style-specific tail will contain the FLOWSPEC 1360 object that failed. If the LUB-flag is off, this should 1361 be the same as a FLOWSPEC in a RESV message sent by this 1362 application; otherwise, they may differ. 1364 An error in a FILTER_SPEC object in a RESV message will 1365 normally be detected at the first RSVP hop from the 1366 receiver application, i.e., within the receiver host. 1367 However, an admission control failure caused by a FLOWSPEC 1368 or a CREDENTIAL object may be detected anywhere along the 1369 path(s) to the sender(s). 1371 4.1.6 Teardown Messages 1373 There are two types of RSVP Teardown message, PTEAR and RTEAR. 1375 o PTEAR messages delete path state (which in turn may delete 1376 reservations state) and travel towards all receivers that 1377 are downstream from the point of initiation. PTEAR 1378 messages are routed like PATH messages, and their IP 1379 destination address is DestAddress for the session. 1381 o RTEAR messages delete reservation state and travel towards 1382 all matching senders upstream from the point of teardown 1383 initiation. RTEAR message are routed like RESV messages, 1384 and their IP destination address is the unicast address of 1385 a previous hop. 1387 ::= 1389 [ ] 1391 1393 ::= (see earlier definition) 1395 ::= 1397 [ ] [ ] 1399 1401 ::= (see earlier definition) 1403 Flowspec objects in the style-specific tail of a RTEAR message 1404 will be ignored and may be omitted. 1406 If the state being deleted was created with user credentials 1407 from a CREDENTIAL field, then the matching PTEAR or RTEAR 1408 message must include matching CREDENTIAL field(s). 1410 [There is a problem here: tearing down path state may 1411 implicitly delete reservation state. But a PTEAR message does 1412 not have credentials for the reservation state, only for the 1413 path state. Some argue that a CREDENTIAL may not be needed in 1414 teardown messages, on the assumption that false teardown 1415 messages can be injected only with the collusion of routers 1416 along the data path, and in that case, the colluding router can 1417 just as well stop delivering the RESV messages, which will have 1418 the same effect.] 1420 4.2 Sending RSVP Messages 1422 RSVP messages are sent hop-by-hop between RSVP-capable routers as 1423 "raw" IP datagrams, protocol number 46. Raw IP datagrams are 1424 similarly intended to be used between an end system and the 1425 first/last hop router; however, it is also possible to encapsulate 1426 RSVP messages as UDP datagrams for end-system communication, as 1427 described in Appendix C. UDP encapsulation will simplify 1428 installation of RSVP on current end systems, particularly when 1429 firewalls are in use. 1431 Under overload conditions, lost RSVP control messages could cause 1432 the loss of resource reservations. Routers should be configured 1433 to give a preferred class of service to RSVP packets. RSVP should 1434 not use significant bandwidth, but the queueing delay for RSVP 1435 messages needs to be controlled. 1437 An RSVP PATH or RESV message consists of a small root segment 1438 followed by a variable-length list of objects, which may overflow 1439 the capacity of one datagram. IP fragmentation is inadvisable, 1440 since it has bad error characteristics; RSVP-level fragmentation 1441 should be used. That is, a message with a long list of 1442 descriptors will be divided into segments that will fit into 1443 individual datagrams, each carrying the same root fields. Each of 1444 these messages will be processed at the receiving node, with a 1445 cumulative effect on the local state. No explicit reassembly is 1446 needed. 1448 Since RSVP messages are normally expected to be generated and sent 1449 hop-by-hop, their MTU should be determined by the MTU of each 1450 interface. 1452 [There may be rare instances in which this does not work very 1453 well, and in which manual configuration would not help. The 1454 problem case is an interface connected to a non-RSVP cloud in 1455 which some particular link far away has a smaller MTU. This would 1456 affect only those sessions that happened to use that link. 1457 Proper solution to this case would require MTU discovery 1458 separately for each interface and each session, which is a very 1459 large amount of machinery and some overhead for a rare (?) case. 1460 Best approach seems to be to rely on IP fragmentation and 1461 reassembly for this case.] 1463 4.3 Avoiding RSVP Message Loops 1465 We must ensure that the rules for forwarding RSVP control messages 1466 avoid looping. In steady state, PATH and RESV messages are 1467 forwarded on each hop only once per refresh period. This avoids 1468 directly looping packets, but there is still the possibility of an 1469 " auto-refresh" loop, clocked by the refresh period. The effect 1470 of such a loop is to keep state active "forever", even if the end 1471 nodes have ceased refreshing it (but the state will be deleted 1472 when the receivers leave the multicast group and/or the senders 1473 stop sending PATH messages). 1475 In addition, error and teardown messages are forwarded immediately 1476 and are therefore subject to direct looping. 1478 PATH messages are forwarded using routes determined by the 1479 appropriate routing protocol. For routing that is source- 1480 dependent (e.g., some multicast routing algorithms), the RSVP 1481 daemon must route each sender descriptor separately using the 1482 source addresses found in the SENDER_TEMPLATE objects. This 1483 should ensure that there will be no auto-refresh loops of PATH 1484 information, even in a topology with cycles. 1486 Since PATH messages don't loop, they create path state defining a 1487 loop-free reverse path to each sender. As a result, RESV and 1488 RTEAR messages directed to particular senders cannot loop. PERR 1489 messages are always directed to particular senders and therefore 1490 cannot loop. However, there is a potential auto-refresh problem 1491 for RESV, RTEAR, and RERR messages with wildcard scope, as we now 1492 discuss. 1494 If the topology has no loops, then auto-refresh can be avoided, 1495 even for wildcard scope, with the following rule: 1497 A reservation request received from next hop N must not be 1498 forwarded to N. 1500 This rule is illustrated in Figure 10, which shows a transit 1501 router with one sender and one receiver on each interface (and 1502 assumes one next/previous hop per interface). Interfaces a and c 1503 are both outgoing and incoming interfaces for this session. Both 1504 receivers are making wildcard-scope reservations, in which the 1505 RESV messages are forwarded to all previous hops for senders in 1506 the group, with the exception of the next hop from which they 1507 came. These result in independent reservation requests in the two 1508 directions, without an auto-refresh loop. 1510 ________________ 1511 a | | c 1512 ( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) 1513 |________________| 1515 Send & Receive on (a) | Send & Receive on (c) 1516 | 1517 WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) 1518 | 1519 WF( *{4B}) --> (a) | (c) --> WF( *{4B}) 1520 | 1521 | 1522 Reserve on (a) | Reserve on (c) 1523 __________ | __________ 1524 | * {4B} | | | * {3B} | 1525 |__________| | |__________| 1526 | 1528 Figure 10: Avoiding Auto-Refresh in Non-Looping Topology 1530 However, further effort is needed to prevent auto-refresh loops 1531 from wildcard-scope reservations in the presence of cycles in the 1532 topology. [TBD!!]. 1534 We treat routing of RERR messages as a special case. They are 1535 sent with unicast addresses of next hops, but the multicast 1536 routing is used to prevent loops. As explained above, RERR 1537 messages are forwarded to a subset of the multicast tree to 1538 DestAddress, rooted at the node on which the error was discovered. 1539 Since multicast routing cannot create loops, this will prevent 1540 loops for RERR messages. 1542 [Open question about Figure 10: should it be possible to have 1543 incompatible reservation styles on the two interfaces? For 1544 example, if R1 requests a WF reservation and R2 requests a FF 1545 reservation, it is logically possible to make the corresponding 1546 reservations on the two different interfaces. The current 1547 implementation does NOT allow this; instead, it prevents mixing of 1548 incompatible styles in the same session on a node, even if they 1549 are on different interfaces.] 1551 4.4 Local Repair 1553 Each RSVP daemon periodically sends refreshes to its next/previous 1554 hops. An important optimization would allow the local routing 1555 protocol module to notify the RSVP daemon of route changes for 1556 particular destinations. The RSVP daemon should use this 1557 information to trigger an immediate refresh of state for these 1558 destinations, using the new route. This allows fast adaptation to 1559 routing changes without the overhead of a short refresh period. 1561 4.5 Time Parameters 1563 For each element of state, there are two time parameters: the 1564 refresh period R and the time-to-live value T. R specifies the 1565 period between sending successive refreshes of this data. T 1566 controls how long state will be retained after refreshes stop 1567 appearing, and depends upon period between receiving successive 1568 refreshes. Specifically, R <= T, and the "cleanout time" is K * 1569 T. Here K is a small integer; K-1 successive messages may be lost 1570 before state is deleted. Currently K = 3 is suggested. 1572 Clearly, a smaller T means increased RSVP overhead. If the router 1573 does not implement local repair, a smaller T improves the speed of 1574 adapting to routing changes. With local repair, a router can be 1575 more relaxed about T, since the periodic refresh becomes only a 1576 backstop robustness mechanism. 1578 There are three possible ways for a router to determine R and T. 1580 o Default values are configured in the router. Current 1581 defaults are 30 seconds for T and R. 1583 o A router may adjust the value of T dynamically to keep a 1584 constant total overhead due to refresh traffic; as more 1585 sessions appear, the period would be lengthened. In this 1586 case, R = T could be used. 1588 o R and T can be specified by the end systems. For this 1589 purpose, PATH and RESV messages may contain the optional 1590 TIM_VALUES object. When messages are merged and forwarded to 1591 the next hop, R should be the minimum R that has been 1592 received, and T should be the maximum T that has been 1593 received. Thus, the largest T determines how long state is 1594 retained, and the smallest R determines the responsiveness of 1595 RSVP to route changes. In the first hop, they are expected 1596 to be equal. The RSVP API might allow an application to 1597 override the default value for a particular session. 1599 4.6 RSVP Interfaces 1601 RSVP on a router has interfaces to routing and to traffic control 1602 in the kernel. RSVP on a host has an interface to applications 1603 (i.e, an API) and also an interface to traffic control (if it 1604 exists on the host). 1606 4.6.1 Application/RSVP Interface 1608 This section describes a generic interface between an 1609 application and an RSVP control process. The details of a real 1610 interface may be operating-system dependent; the following can 1611 only suggest the basic functions to be performed. Some of 1612 these calls cause information to be returned asynchronously. 1614 o Register 1616 Call: REGISTER( DestAddress , DestPort 1618 [ , SESSION_object ] , SND_flag , RCV_flag 1620 [ , Source_Address ] [ , Source_Port ] 1622 [ , Sender_Template ] [ , Sender_Tspec ] 1624 [ , Data_TTL ] [ , UserCredential ] 1626 [ , Upcall_Proc_addr ] ) -> Session-id 1628 This call initiates RSVP processing for a session, defined 1629 by DestAddress together with the TCP/UDP port number 1630 DestPort. If successful, the REGISTER call returns 1631 immediately with a local session identifier Session-id, 1632 which may be used in subsequent calls. 1634 The SESSION_object parameter is included as an escape 1635 mechanism to support some more general definition of the 1636 session ("generalized destination port"), should that be 1637 necessary in the future. Normally SESSION_object will be 1638 omitted; if it is supplied, it should be an 1639 appropriately-formatted representation of a SESSION 1640 object. 1642 SND_flag should be set true if the host will send data, 1643 and RCV_flag should be set true if the host will receive 1644 data. Setting neither true is an error. The optional 1645 parameters Source_Address, Source_Port, Sender_Template, 1646 Sender_Tspec, and Data_TTL are all concerned with a data 1647 source, and they will be ignored unless SND_flag is true. 1649 If SND_FLAG is true, a successful REGISTER call will cause 1650 RSVP to begin sending PATH messages for this session using 1651 these parameters, which are interpreted as follows: 1653 - Source_Address 1655 This is the address of the interface from which the 1656 data will be sent. If it is omitted, a default 1657 interface will be used. 1659 - Source_Port 1661 This is the UDP/TCP port from which the data will be 1662 sent. If it is omitted or zero, the port is "wild" 1663 and can match any port in a FILTERSPEC. 1665 - Sender_Template 1667 This parameter is included as an escape mechanism to 1668 support a more general definition of the sender 1669 ("generalized source port"). Normally this parameter 1670 may be omitted; if it is supplied, it should be an 1671 appropriately formatted representation of a 1672 SENDER_TEMPLATE object. 1674 - Sender_Tspec 1676 This parameter is a Tspec describing the traffic flow 1677 to be sent. It may be included to prevent over- 1678 reservation on the initial hops. 1680 - Data_TTL 1682 This is the (non-default) IP Time-To-Live parameter 1683 that is being supplied on the data packets. It is 1684 needed to ensure that Path messages do not have a 1685 scope larger than multicast data packets. 1687 Finally, Upcall_Proc_addr is the address of an upcall 1688 procedure to receive asynchronous error or event 1689 notification; see below. 1691 o Reserve 1693 Call: RESERVE( session-id, style, style-dependent-parms ) 1694 A receiver uses this call to make a resource reservation 1695 for the session registered as `session-id'. The style 1696 parameter indicates the reservation style. The rest of 1697 the parameters depend upon the style, but generally these 1698 will include appropriate flowspecs and filter specs. 1700 The first RESERVE call will initiate the periodic 1701 transmission of RESV messages. A later RESERVE call may 1702 be given to modify the parameters of the earlier call (but 1703 note that changing the reservations may result in 1704 admission control failure, depending upon the style). 1706 The RESERVE call returns immediately. Following a RESERVE 1707 call, an asynchronous ERROR/EVENT upcall may occur at any 1708 time. 1710 o Release 1712 Call: RELEASE( session-id ) 1714 This call will terminate RSVP state for the session 1715 specified by session-id. It may send appropriate teardown 1716 messages and will cease sending refreshes for this 1717 session-id. 1719 o Error/Event Upcalls 1721 Call: (session-id, Info_type, List_count 1723 [ ,Error_code ,Error_value ,LUB-flag ] 1725 [ ,Filter_spec_list ] [ ,Flowspec_list ] 1727 [ ,Advert_list ] ) 1729 Here "Upcall_Proc" represents the upcall procedure whose 1730 address was supplied in the REGISTER call. 1732 This upcall may occur asynchronously at any time after a 1733 REGISTER call and before a RELEASE call, to indicate an 1734 error or an event. Currently there are three upcall 1735 types, distinguished by the Info_type parameter: 1737 1. Info_type = Path Event 1739 A Path Event upcall indicates the receipt of a PATH 1740 message, indicating to the application that there is 1741 at least one active sender. This upcall provides 1742 synchronizing information to the receiver 1743 application, and it may also provide parallel lists 1744 of senders (in Filter_spec_list), traffic 1745 descriptions (in Flowspec_list), and service 1746 advertisements (in Advert_list). 'List_count' is the 1747 number in each list; where these objects are 1748 missing, corresponding null objects must appear. 1750 Error_code and Error_value, and LUB-flag should be 1751 ignored in a Path Event upcall. 1753 2. Info_type = Path Error 1755 An Path Error event indicates an error in processing 1756 a sender descriptor originated by this sender. The 1757 Error_code parameter will define the error, and 1758 Error_value may supply some additional (perhaps 1759 system-specific) data about the error. `List_count' 1760 will be 1, and Filter_spec_list and Flowspec_list 1761 will contain the Sender_Template and the Sender_Tspec 1762 supplied in the REGISTER call; Advert_list will 1763 contain one NULL object. 1765 3. Info_type = Resv Error 1767 An Resv Error event indicates an error in processing 1768 a RESV message to which this application contributed. 1769 The Error_code parameter will define the error, and 1770 Error_value may supply some additional (perhaps 1771 system-specific) data on the error. 1773 `List_count' will be 1, and Filter_spec_list and 1774 Flowspec_list will contain one FILTER_SPEC and one 1775 FLOWSPEC object. These objects are taken from the 1776 RESV message that caused the error (unless the LUB- 1777 flag is on, in which case FLOWSPEC may differ). 1779 Although RSVP messages indicating path events or errors 1780 may be received periodically, the API should make the 1781 corresponding asynchronous upcall to the application only 1782 on the first occurrence, or when the information to be 1783 reported changes. 1785 4.6.2 RSVP/Traffic Control Interface 1787 In each router and host, enhanced QoS is achieved by a group of 1788 inter-related traffic control functions: a packet classifier, 1789 an admission control module, and a packet scheduler. This 1790 section describes a generic RSVP interface to traffic control. 1792 1. Make a Reservation 1794 Call: Rhandle = TC_AddFlowspec( Flowspec, Police_Flag 1796 [ , Sender_Tspec] 1798 [ , SD_rank , SD_end_flag ] ) 1800 This call passes a Flowspec defining a desired QoS to 1801 admission control. It may also pass Sender_Tspec, the 1802 maximum traffic characteristics computed over the 1803 SENDER_TSPECs of senders that will contribute data packets 1804 to this reservation. Police_Flag is a Boolean parameter 1805 that indicates whether traffic policing should be applied 1806 at this point. 1808 The SD_rank and SD_end_flag fields are used for a member 1809 of a session group. SD_rank is the rank value from the 1810 SESSION_GROUP object. The call is made with each of the 1811 sessions in the group, and SD_end_flag is set true for the 1812 last one. 1814 This call returns an error code if Flowspec is malformed 1815 or if the requested resources are unavailable. Otherwise, 1816 it establishes a new reservation channel corresponding to 1817 Rhandle. It returns the opaque number Rhandle for 1818 subsequent references to this reservation. 1820 2. Add Filter 1822 Call: TC_AddFilter( Rhandle, Session, Filterspec ) 1824 This call is used to define a filter corresponding to the 1825 given handle, following a successful TC_AddFlowspec call. 1827 3. Modify or Delete Filter 1829 Call: TC_ModFilter( Rhandle, Session, 1831 [ new_Filterspec] ) 1833 This call can modify an existing filter or replace an 1834 existing filter with no filter (i.e., delete the filter). 1836 4. Modify or Delete Flowspec 1838 Call: TC_ModFlowspec( Rhandle 1840 [, new_Flowspec [ ,Sender_Tspec]] ) 1842 This call can modify an existing reservation or delete the 1843 reservation. If new_Flowspec is included, it is passed to 1844 Admission Control; if it is rejected, the current flowspec 1845 is left in force. If new_Flowspec is omitted, the 1846 reservation is deleted and Rhandle is invalidated. 1848 5. OPWA Update 1850 Call: TC_Advertise( interface, Adspec 1852 [ ,Sender_TSpec ] ) -> New_Adspec 1854 This call is used for OPWA to compute the outgoing 1855 advertisement New_Adspec for a specified interface. 1857 6. Initialize Traffic Control 1859 Call: TC_Initialize(interface ) 1861 This call is used when RSVP initializes its state, to 1862 clear out all existing classifier and/or packet scheduler 1863 state for a specified interface. 1865 4.6.3 RSVP/Routing Interface 1867 An RSVP implementation needs the following support from the 1868 packet forwarding and routing mechanism of the node. 1870 o Promiscuous receive mode for RSVP messages 1872 Any datagram received for IP protocol 46 is to be diverted 1873 to the RSVP program for processing, without being 1874 forwarded. The identity of the interface on which it is 1875 received should also be available to the RSVP daemon. 1877 o Route discovery 1878 RSVP must be able to discover the route(s) that the 1879 routing algorithm would have used for forwarding a 1880 specific datagram. 1882 GetUcastRoute( DestAddress ) -> OutInterface 1884 GetMcastRoute( SrcAddress, DestAddress ) 1886 -> OutInterface_list 1888 o Route Change Notification 1890 Routing may provide an asynchronous notification to RSVP 1891 that a specified route has changed. 1893 New_Ucast_Route( DestAddress ) -> new_OutInterface 1895 New_Mcast_Route( SrcAddress, DestAddress ) 1897 -> new_OutInterface_list 1899 o Outgoing Link Specification 1901 RSVP must be able to force a (multicast) datagram to be 1902 sent on a specific outgoing virtual link, bypassing the 1903 normal routing mechanism. A virtual link may be a real 1904 outgoing link or a multicast tunnel. Outgoing link 1905 specification is necessary because RSVP may send different 1906 versions of outgoing PATH messages on different 1907 interfaces, for the same source and destination addresses, 1908 and to avoid loops. 1910 o Discover Interface List 1912 RSVP must be able to learn what real and virtual 1913 interfaces exist. 1915 5. Message Processing Rules 1917 This generic description of RSVP operation assumes the following data 1918 structures. An actual implementation may use additional or different 1919 structures to optimize processing. 1921 o PSB -- Path State Block 1923 Each PSB holds path state for a particular (session, sender) 1924 pair, defined by SESSION and SENDER_TEMPLATE objects, 1925 respectively. PSB contents include a PHOP object and possibly 1926 SENDER_TSPEC, CREDENTIAL, and/or ADVERT objects from PATH 1927 messages. 1929 o RSB -- Reservation State Block 1931 RSB's are used to hold reservation state. Each RSB holds 1932 reservation state for the 4-tuple: (session, next hop, style, 1933 filterspec), defined in SESSION, NHOP (i.e., RSVP_HOP), STYLE, 1934 and FILTER_SPEC objects, respectively. We assume that RSB 1935 contents include the outgoing interface OI that is implied by 1936 NHOP. RSB contents also include a FLOWSPEC object and may 1937 include a CERTIFICATE object. 1939 MESSAGE ARRIVES 1941 Verify version number, checksum, and length fields of common header, 1942 and discard message if it fails. 1944 Further processing depends upon message type. 1946 PATH MESSAGE ARRIVES 1948 Start with the Refresh_Needed flag off. 1950 Each sender descriptor object sequence in the message defines a 1951 sender. Process each sender as follows. 1953 1. If there is a CREDENTIAL object, verify it; if it is 1954 unacceptable, build and send a PERR message, drop the PATH 1955 message, and return. 1957 2. If there is no path state block (PSB) for the (session, 1958 sender) pair then: 1960 o Create a new PSB. 1962 o Set a cleanup timer for the PSB. If this is the first 1963 PSB for the session, set a refresh timer for the 1964 session. 1966 o Copy PHOP into the PSB. Copy into the PSB any of the 1967 following objects that are present in the message: 1968 CREDENTIAL, SENDER_TSPEC, and/or ADVERT. Copy the 1969 EntryPolice flag from the common header into the PSB. 1971 o Call the appropriate route discovery routine, using 1972 DestAddress from SESSION and (for multicast routing) 1973 SrcAddress from SENDER_TEMPLATE. Store the resulting 1974 routing bit mask ROUTE_MASK in the PSB. 1976 3. Otherwise (there is a matching PSB): 1978 o If CREDENTIAL differs between message and PSB, verify 1979 new CREDENTIAL. If it is acceptable, copy it into 1980 PSB. Otherwise, build and send a PERR message for 1981 "Bad Credential", drop the PATH message, and return. 1983 o Restart cleanup timer. 1985 o Update the PSB with values from the message, as 1986 follows. Copy the ADVERT object, if any, into the 1987 PSB. Copy the EntryPolice flag into the PSB. 1989 If the values of PHOP or SEND_TSPEC differ between the 1990 message and the PSB, copy the new values into the PSB 1991 and turn on the Refresh_Needed flag. If SEND_TSPEC 1992 has changed, reservations matching S may also change; 1993 this may be deferred until a RESV refresh arrives. 1995 o Call the appropriate route discovery routine and 1996 compare the route mask with the ROUTE_MASK value 1997 already in the PSB; if a new bit (interface) has been 1998 added, turn on the Refresh_Needed flag. Store new 1999 ROUTE_MASK in the PSB. 2001 4. If the Refresh_Needed flag is now set, execute the PATH 2002 REFRESH event sequence (below). 2004 PATH TEAR MESSAGE ARRIVES 2006 o If there is no path state for this destination, drop the 2007 message and return. 2009 o Forward a copy of the PTEAR message using the same rules as 2010 for a PATH message (see PATH REFRESH). 2012 o Each sender descriptor in the PTEAR message contains a 2013 SENDER_TEMPLATE object defines a sender S; process it as 2014 follows. 2016 1. Locate the PSB for the pair: (session, S). If none 2017 exists, continue with next sender descriptor. 2019 2. Examine the RSB's for this session and delete any 2020 reservation state associated with sender S, depending 2021 upon the reservation style. For example: 2023 Delete a WF reservation for which S is the only 2024 sender. 2026 Delete an FF reservation for S. 2028 3. Delete the PSB. 2030 PATH ERROR MESSAGE ARRIVES 2032 o If there are no existing PSB's for SESSION then drop the 2033 PERR message and return. 2035 o Look up the PSB for (session, sender); sender is defined by 2036 SENDER_TEMPLATE. If no PSB is found, drop PERR message and 2037 return. 2039 o If PHOP in PSB is local API, deliver error to application 2040 via an upcall: 2042 Call: ( session-id, Path Error, 1, 2043 Error_code, Error_value, 0, 2044 SENDER_TEMPLATE, NULL, NULL) 2046 Note that CREDENTIAL, SENDER_TSPEC, and ADVERT objects in 2047 the message is ignored. 2049 Otherwise (PHOP is not local API), forward a copy of the 2050 PERR message to the PHOP node. 2052 RESV MESSAGE ARRIVES 2053 A RESV message arrives through outgoing interface OI. 2055 o Check the SESSION object. 2057 If there are no existing PSB's for SESSION then build and 2058 send a RERR message (as described later) specifying "No 2059 Path Information", drop the RESV message, and return. 2060 However, do not send the RERR message if the style has 2061 wildcard reservation scope and this is not the receiver 2062 host itself. 2064 o Check the STYLE object. 2066 If style in the message conflicts with the style of any 2067 reservation for this session in place on any interface, 2068 reject the RESV message by building and sending a RERR 2069 message specifying "Bad Style", drop the RESV message, and 2070 return. 2072 o Check the CREDENTIAL object. 2074 Verify the CREDENTIAL field (if any) to check permission to 2075 create a reservation. [This check may also involve the 2076 CREDENTIAL fields from the PSB's in the scope of this 2077 reservation; in that case, it would better fit below in 2078 processing the individual flow descriptors.] 2080 o Check for path state 2082 If there are no PSB's matching the scope of this 2083 reservation, build and send a RERR message specifying "No 2084 Sender Information", drop the RESV message, and return. 2086 o Make reservations 2088 Process the style-specific tail sequence. 2090 For FF style, execute the following steps for each b flow 2091 descriptor, i.e., each (FLOWSPEC, FILTERSPEC) pair. For WF 2092 style execute the following once, using some internal 2093 placeholder "WILD_FILTER" for FILTERSPEC to indicate 2094 wildcard scope. 2096 1. Find or create a reservation state block (RSB) for the 2097 4-tuple: (SESSION, NHOP, style, FILTERSPEC). 2099 2. Start or restart the cleanout timer on the RSB. 2101 3. Start a refresh timer for this session if none was 2102 started. 2104 4. If the RSB existed and if FLOWSPEC and the 2105 SENDER_TSPEC objects are unchanged, drop the RESV 2106 message and return. 2108 5. Compute Sender_Tspec as the maximum over the 2109 SENDER_TSPEC objects of the PSB's within the scope of 2110 the reservation. 2112 6. Set Police_flag on if any PSB's in the scope have the 2113 EntryPolice flag on, or if the style is WF and there 2114 is more than one PSB in the scope, otherwise off. 2116 7. Computer K_Flowspec, the effective kernel flowspec, as 2117 the maximum of the FLOWSPEC values in all RSB's for 2118 the same (SESSION, OI, FILTERSPEC) triple. Similarly, 2119 the kernel filter spec K_filter is either the 2120 FILTER_SPEC object under consideration (unitary 2121 scope), or it is WILD_FILTER (wildcard scope). 2123 If there was no previous kernel reservation in place 2124 for (SESSION, OI, FILTERSPEC), call the kernel 2125 interface module: 2127 TC_AddFlowspec( Sender_Tspec, K_flowspec, Police_Flag ) 2129 If this call fails, build and send a RERR message 2130 specifying "Admission control failed", drop the RESV 2131 message, and return. Otherwise, record the kernel 2132 handle K_handle returned by the call in the RSB(s). 2133 Then call: 2135 TC_AddFilter( K_handle, K_Filter) 2137 to set the filter, drop the RESV message and return. 2139 /item However, if there was a previous kernel 2140 reservation with handle K_handle, call the kernel 2141 interface module: 2143 TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec) 2145 If this call fails, build and send a RERR message 2146 specifying "Admission control failed". In any case, 2147 drop the RESV message and return. 2149 If processing a RESV message finds an error, a RERR message is 2150 created containing flow descriptor and an ERRORS object. The 2151 Error Node field of the ERRORS object (see Appendix A) is set to 2152 the IP address of OI, and the message is sent unicast to NHOP. 2154 created 2156 RESV TEAR MESSAGE ARRIVES 2158 A RTEAR message arrives on outgoing interface OI. 2160 o If there are no existing PSB's for SESSION then drop the 2161 RTEAR message and return. 2163 o Process the style-specific tail sequence to tear down 2164 reservations. 2166 For FF style, execute the following steps for each b flow 2167 descriptor, i.e., each (FLOWSPEC, FILTERSPEC) pair. For WF 2168 style execute the following once, using some internal 2169 placeholder "WILD_FILTER" for FILTERSPEC to indicate 2170 wildcard scope. 2172 1. Find matching RSB(s) for the 4-tuple: (SESSION, NHOP, 2173 style, FILTERSPEC). If no RSB is found, continue with 2174 next flow descriptor, if any. 2176 2. Delete the RSB(s). 2178 3. If there are no more RSBs for the same (SESSION, OI, 2179 FILTERSPEC/) triple, call the kernel interface module: 2181 TC_ModFlowspec( K_handle ) 2183 to delete the reservation. Then build and forward a 2184 new RERR message. 2186 - WF style: send a copy to each PHOP among all 2187 matching senders. 2189 - FF style: Send to PHOP of matching PSB. 2191 4. Otherwise (there are other RSB's for the same 2192 reservation), recompute K_Flowspec and call the kernel 2193 interface module: 2195 TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec) 2197 to update the reservation, and then execute the RESV 2198 REFRESH sequence (below). If this kernel call fails, 2199 return; the prior reservation will remain in place. 2201 RESV ERROR MESSAGE ARRIVES 2203 o Call the appropriate route discovery routine, using 2204 DestAddress from SESSION and (for multicast routing) 2205 SrcAddress from the Error Node field in the ERRORS object. 2206 Let the resulting routing bit mask be M. 2208 o Determine the set of RSBs matching the triple: (SESSION, 2209 style, FILTERSPEC). If no RSB is found, drop RERR message 2210 and return. 2212 Recompute the maximum over the FLOWSPEC objects of this set 2213 of RSB's. If the LUB was used in this computation, turn on 2214 the LUB-flag in the received RESV message. 2216 o Delete from the set of RSVs any whose OI does not appear in 2217 the bit mask M and whose NHOP is not the local API. If 2218 none remain, drop RERR message and return. 2220 For each PSB in the resulting set, do the following step. 2222 o If NHOP in PSB is local API, deliver error to application 2223 via an upcall: 2225 Call: ( session-id, Resv Error, 1, 2226 Error_code, Error_value, LUB-flag, 2227 FILTER_SPEC, FLOWSPEC, NULL) 2229 Here LUB-flag is taken from the received packet, as 2230 possibly modified above. 2232 Otherwise (NHOP is not local API), forward a copy of the 2233 RERR message to the PHOP node. 2235 PATH REFRESH 2237 This sequence may be entered by either the expiration of the path 2238 refresh timer for a particular session, or immediately as the result 2239 of processing a PATH message turning on the Refresh_Needed flag. 2241 For each virtual outgoing interface ("vif") V, build a PATH message 2242 and send it to V. To build the message, consider each PSB whose 2243 ROUTE_MASK includes V, and do the following: 2245 o Pass the ADVERT and SENDER_TSPEC objects present in the PSB to 2246 the kernel call TC_Advertise, and get back a modified ADVERT 2247 object. Pack this modified object into the PATH message being 2248 built. 2250 o Create a sender descriptor sequence containing the 2251 SENDER_TEMPLATE, CREDENTIAL, and SENDER_TSPEC objects, if 2252 present in the PSB. Pack the sender descriptor into the PATH 2253 message being built. 2255 o If the PSB has the EntryPolice flag on and if interface V is not 2256 capable of policing, turn the EntryPolice flag on in the PATH 2257 message being built. 2259 o If the maximum size of the PATH message is reached, send the 2260 packet out interface V and start packing a new one. 2262 RESV REFRESH 2264 This sequence may be entered by either the expiration of the 2265 reservation refresh timer for a particular session, or immediately as 2266 the result of processing a RESV message. 2268 Each PSB for this session is considered in turn, to compute a style- 2269 dependent tail sequence. These sequences for a given PHOP are then 2270 packed into the same message(s) and sent to that PHOP. The logic is 2271 somewhat different depending upon whether the scope of the 2272 reservations is wildcard or not (they may not be mixed). 2274 For each PSB that does not correspond to the API, do the following. 2276 o Compute (FLOWSPEC, FILTER_SPEC) Pair 2278 Select each RSB in whose reservation scope the PSB falls, and 2279 compute the maximum over the FLOWSPEC objects of this set of 2280 RSB's. Also, select an appropriate FILTER_SPEC. The scope 2281 depends upon the style and the filter spec of the RSB: 2283 1. WF: Select every RSB whose OI matches a bit in the 2284 ROUTE_MASK of the PSB. 2286 In this case, FILTER_SPEC is the standard WILD_FILTER. 2288 2. FF: Select every RSB whose FILTER_SPEC matches 2289 SENDER_TEMPLATE in the RSB. This matching process should 2290 consider wildcards. 2292 In this case, FILTER_SPEC is taken from any of the matching 2293 RSB's. [?? Need to either 'merge' filter specs, which 2294 probably means to remove gratuitous wildcards??] 2296 This computation also yields a style (since style must be 2297 consistent across RSB's for given session). [??Again, need 2298 merging rules]] 2300 o Build RESV packets 2302 Append this (FLOWSPEC, FILTER_SPEC pair) to the RESV message 2303 being built for destination PHOP (from the PSB). When the 2304 packet fills, or upon completion of all PSB's with the same 2305 PHOP, set the NHOP address in the message to the interface 2306 address and send the packet out that interface to the PHOP 2307 address. 2309 appendix 2310 6. Object Type Definitions 2312 C-types are defined for the two Internet address families IPv4 and 2313 IP6. To accomodate other address families, additional C-types could 2314 easily be defined. These definitions are contained as an Appendix to 2315 ease updating. 2317 6.1 SESSION Class 2319 Currently, SESSION objects contain the pair: (DestAddress, 2320 DestPort), where DestAddress is the data destination address and 2321 DestPort is the UDP/TCP destination port. Other SESSION C-Types 2322 could be defined in the future to support other demultiplexing 2323 conventions in the transport-layer or application layer. 2325 o IPv4/UDP SESSION object: Class = 1, C-Type = 1 2327 +-------------+-------------+-------------+-------------+ 2328 | IPv4 DestAddress (4 bytes) | 2329 +-------------+-------------+-------------+-------------+ 2330 | //////////// | DestPort | 2331 +-------------+-------------+-------------+-------------+ 2333 o IP6/UDP SESSION object: Class = 1, C-Type = 129 2335 +-------------+-------------+-------------+-------------+ 2336 | | 2337 + + 2338 | | 2339 + IP6 DestAddress (16 bytes) + 2340 | | 2341 + + 2342 | | 2343 +-------------+-------------+-------------+-------------+ 2344 | //////////// | DestPort | 2345 +-------------+-------------+-------------+-------------+ 2347 6.2 SESSION_GROUP Class 2349 o IPv4 SESSION_GROUP Object: Class = 2, C-Type = 1: 2351 +-------------+-------------+-------------+-------------+ 2352 | IPv4 Reference DestAddress | 2353 +-------------+-------------+-------------+-------------+ 2354 | Session_Group ID | Count | Rank | 2355 +-------------+-------------+-------------+-------------+ 2357 o IP6 SESSION_GROUP Object: Class = 2, C-Type = 129: 2359 +-------------+-------------+-------------+-------------+ 2360 | | 2361 + + 2362 | | 2363 + IP6 Reference DestAddress + 2364 | | 2365 + + 2366 | | 2367 +-------------+-------------+-------------+-------------+ 2368 | Session-Group ID | Count | Rank | 2369 +-------------+-------------+-------------+-------------+ 2371 6.3 RSVP_HOP Class 2373 o IPv4 RSVP_HOP object: Class = 3, C-Type = 1 2375 +-------------+-------------+-------------+-------------+ 2376 | IPv4 Next/Previous Hop Address | 2377 +-------------+-------------+-------------+-------------+ 2379 o IP6 RSVP_HOP object: Class = 3, C-Type = 129 2381 +-------------+-------------+-------------+-------------+ 2382 | | 2383 + + 2384 | | 2385 + IP6 Next/Previous Hop Address + 2386 | | 2387 + + 2388 | | 2389 +-------------+-------------+-------------+-------------+ 2391 This object provides the IP address of the interface through which 2392 the last RSVP-knowledgeable hop forwarded this message. 2394 6.4 STYLE Class 2396 o STYLE-WF object: Class = 4, C-Type = 1 2398 +-------------+-------------+-------------+-------------+ 2399 | Style=1 | //////// | //////// | ///////// | 2400 +-------------+-------------+-------------+-------------+ 2402 o STYLE-FF object: Class = 4, C-Type = 2 2404 +-------------+-------------+-------------+-------------+ 2405 | Style=2 | //////// | //////// | FD Count | 2406 +-------------+-------------+-------------+-------------+ 2408 FD Count 2410 The count of elements in the variable-length object list 2411 that follows. See the RESV message format definition 2412 earlier. 2414 6.5 Flowspec Class 2416 o CSZ FLOWSPEC object: Class = 5, C-Type = 1 2418 +-----------+-----------+-----------+-----------+ 2419 | QoS Service Code | 2420 +-----------+-----------+-----------+-----------+ 2421 | b: Token Bucket Depth (bits) | 2422 +-----------+-----------+-----------+-----------+ 2423 | r: Average data rate (bits/sec) | 2424 +-----------+-----------+-----------+-----------+ 2425 | d: Max end-to-end delay (ms) | 2426 +-----------+-----------+-----------+-----------+ 2427 | (For Future Use) | 2428 +-----------+-----------+-----------+-----------+ 2430 QoS Service Code 2432 Integer value defining what service is being requested. 2433 The values currently defined for this code are: 2435 1 = Guaranteed Service 2437 The Tspec is (b, r), while the Rspec is (r). (d) 2438 is ignored. 2440 2 = Bounded-Delay Predictive Service 2442 The Tspec is (b, r), while the Rspec is (d). 2444 6.6 FILTER_SPEC Class 2446 o IPv4/UDP FILTER_SPEC object: Class = 6, C-Type = 1 2448 +-------------+-------------+-------------+-------------+ 2449 | IPv4 SrcAddress (4 bytes) | 2450 +-------------+-------------+-------------+-------------+ 2451 | Protocol Id | ////// | SrcPort | 2452 +-------------+-------------+-------------+-------------+ 2454 o IP6/UDP FILTER_SPEC object: Class = 6, C-Type = 129 2456 +-------------+-------------+-------------+-------------+ 2457 | | 2458 + + 2459 | | 2460 + IP6 SrcAddress (16 bytes) + 2461 | | 2462 + + 2463 | | 2464 +-------------+-------------+-------------+-------------+ 2465 | Protocol Id | ////// | SrcPort | 2466 +-------------+-------------+-------------+-------------+ 2468 SrcAddress is an IP address for a host, and SrcPort is a UDP/TCP 2469 source port, defining a sender. 2471 6.7 SENDER_TEMPLATE Class 2473 o IPv4/UDP SENDER_TEMPLATE object: Class = 7, C-Type = 1 2475 Definition same as IPv4/UDP FILTER_SPEC object. 2477 o IP6/UDP SENDER_TEMPLATE object: Class = 7, C-Type = 129 2479 Definition same as IP6/UDP FILTER_SPEC object. 2481 6.8 SENDER_TSPEC Class 2483 The most common form of Tspec is a token bucket. 2485 o Token Bucket SENDER_TSPEC object: Class = 8, C-Type = 1 2487 +-----------+-----------+-----------+-----------+ 2488 | b: Token Bucket Depth (bits) | 2489 +-----------+-----------+-----------+-----------+ 2490 | r: Average data rate (bits/sec) | 2491 +-----------+-----------+-----------+-----------+ 2493 6.9 ADVERT Class 2495 [TBD] 2497 6.10 TIME_VALUES Class 2499 o TIME_VALUES Object: Class = 10, C-Type = 1 2501 +-------------+-------------+-------------+-------------+ 2502 | Refresh Period | 2503 +-------------+-------------+-------------+-------------+ 2504 | State TTL Time | 2505 +-------------+-------------+-------------+-------------+ 2507 6.11 ERROR_SPEC Class 2509 o IPv4 ERROR_SPEC object: Class = 11, C-Type = 1 2511 +-------------+-------------+-------------+-------------+ 2512 | IP4 Error Node Address (4 bytes) | 2513 +-------------+-------------+-------------+-------------+ 2514 | Error Code | ////////// | Error Value | 2515 +-------------+-------------+-------------+-------------+ 2517 o IP6 ERROR_SPEC object: Class = 11, C-Type = 129 2519 +-------------+-------------+-------------+-------------+ 2520 | | 2521 + + 2522 | | 2523 + IP6 Error Node Address (16 bytes) + 2524 | | 2525 + + 2526 | | 2527 +-------------+-------------+-------------+-------------+ 2528 | Error Code | ////////// | Error Value | 2529 +-------------+-------------+-------------+-------------+ 2531 Errnor Node 2533 The IP address 2535 Error Code 2537 A one-octet error description. 2539 01 = Insufficient memory 2541 02 = Count Wrong 2543 The FD Count field does not match length of 2544 message. 2546 03 = No path information for this Resv 2548 04 = No Sender information for this Resv 2549 There is path information, but it does not include 2550 the sender specified in any of the Filterspecs 2551 listed in the Resv messager. 2553 05 = Incorrect Dynamic Reservation Count 2555 Dynamic Reservation Count is zero or less than FD 2556 Count. 2558 06 = Filterspec error 2560 07 = Flowspec syntax error 2562 08 = Flowspec value error 2564 Internal inconsistency of values. 2566 [What should be done with Flowspec Feature Not 2567 Supported?] 2569 09 = Resources unavailable [Sub-reasons? Depend upon 2570 traffic control and admission control algorithms?] 2572 10 = Illegal style 2574 Error Value 2576 Specific cause of the error described by the Error Code. 2578 6.12 CREDENTIAL Class 2580 [TBD] 2582 6.13 INTEGRITY Class 2584 [TBD] 2586 7. UDP Encapsulation 2588 As described earlier, RSVP control messages are intended to be 2589 carried as "raw packets", directly within IP datagrams. Implementing 2590 RSVP in a node will typically require an intercept in the packet 2591 forwarding path for protocol 46, which means a kernel change. 2592 However, for ease of installing RSVP on host systems in the short 2593 term, it may be desirable to avoid host kernel changes by supporting 2594 UDP encapsulation of RSVP messages. This encapsulation would be used 2595 between hosts and the last- (or first-) hop router(s). This scheme 2596 will also support the case of an intermediate RSVP router whose 2597 kernel supports multicast but does not have the RSVP intercept, by 2598 allowing UDP encapsulation on each interface. 2600 The UDP encapsulation approach must support a domain that contains a 2601 mix of "UDP-only" hosts, which require UDP encapsulation, and "raw- 2602 capable" host, which can use raw RSVP packets. Raw-capable hosts and 2603 first-hop router(s) must send each RSVP message twice in the local 2604 domain, once as a raw packet and once with UDP encapsulation; these 2605 nodes will also receive some local RSVP packets in both formats. We 2606 assume that the only negative impact of this duplication will be 2607 (negligible) additional packet processing overhead in the raw-capable 2608 hosts and first-hop routers. 2610 [REST TBD] 2612 8. DF Style (Experimental) 2614 In addition to the WF and FF styles defined in this specification, a 2615 Dynamic Filter (DF) style has also been proposed. The following 2616 describes this style and gives examples of its usage. At this time, 2617 DF style is experimental. 2619 8.1 Reservation Styles 2621 A Dynamic-Filter (DF) style reservation decouples reservations 2622 from filters. 2624 Each DF reservation request specifies a number D of distinct 2625 reservations to be made using the same specified flowspec, and 2626 these reservations have a wildcard reservation scope, so they go 2627 everywhere. The number of reservations that are actually made in 2628 a particular node is D' = min(D,Ns), where Ns is the total number 2629 of senders upstream of the node. Like a FF style request, a DF 2630 style request causes distinct reservations for different senders. 2632 In addition to D and the flowspec, a DF style reservation may also 2633 specify a list of K filterspecs, for some K in the range: 0 <= K 2634 <= D'. These filterspecs define particular senders to use the D' 2635 reservations, and this list establishes the scope for the filter 2636 specs. 2638 Once a DF reservation has been established, the receiver may 2639 change the set of filterspecs to specify a different selection of 2640 senders, without a new admission control check (assuming D' and 2641 the common flowspec remain unchanged). This is known as "channel 2642 switching", in analogy with a television set. 2644 In order to provide assured channel switching, each node along the 2645 path must reserve enough bandwidth for all D' channels, even 2646 though some of this bandwidth may be unused at any one time. If 2647 D' changes (because the receiver changed D or because the number 2648 Ns of upstream sources changed), or if the common flowspec 2649 changes, the refresh message is treated as a new reservation that 2650 is subject to admission control and may fail. 2652 The essential difference between the FF and DF styles is that the 2653 DF style allows a receiver to switch channels without danger of an 2654 admission denial due to limited resources (unless a topology 2655 change reroutes traffic along a lower-capacity path or new senders 2656 appear), once the initial reservations have been made. This in 2657 turn implies that the DF style creates reservations that may not 2658 be in use at any given time. 2660 The DF style is compatible with the FF style but not the WF style. 2662 8.2 Examples 2664 To give an example of the DF style, we use the following notation: 2666 o DF Style 2668 DF( n, {r} ; ) or DF( n, {r} ; S1, S2, ...) 2670 This message carries the count n of channels to be reserved, each 2671 using common flowspec r. It also carries a list, perhaps empty, 2672 of filterspecs defining senders. 2674 Figure 11 shows an example of Dynamic-Filter reservations. The 2675 receivers downstream from interface (d) have requested two 2676 reserved channels, but selected only one sender, S1. The node 2677 reserves min(2,3) = 2 channels of size B on interface (d), and it 2678 then applies any specified filters to these channels. Since only 2679 one sender was specified, one channel has no corresponding filter, 2680 as shown by `?'. 2682 Similarly, the receivers downstream of interface (c) have 2683 requested two channels and selected senders S1 and S2. The two 2684 channels might have been one channel each from R1 and R2, or two 2685 channels requested by one of them, for example. 2687 | 2688 Send | Reserve Receive 2689 | 2690 | ________ 2691 DF( 1,{B}; S1) <- (a) | (c) | S1{B} | (c) <- DF( 2,{B}; S1, S2) 2692 | |________| 2693 | | S2{B} | 2694 | |________| 2695 | 2696 ------------------------|------------------------------------------- 2697 | ________ 2698 DF( 2,{B}; S2) <- (b) | (d) | S1{B} | (d) <- DF( 2,{B}; S1) 2699 | |________| 2700 | | ?{B} | 2701 | |________| 2703 Figure 11: Dynamic-Filter Reservation Example 2705 A router should not reserve more Dynamic-Filter channels than the 2706 number of upstream sources (three, in the router of Figure 11). 2707 Since there is only one source upstream from previous hop (a), the 2708 first parameter of the DF message (the count of channels to be 2709 reserved) was decreased to 1 in the forwarded reservations. 2710 However, this is unnecessary, because the routers upstream will 2711 reserve only one channel, regardless. 2713 When a DF reservation is received, it is labeled with the IP 2714 address of the next hop (RSVP-capable) router, downstream from the 2715 current node. Since the outgoing interface may be directly 2716 connected to a shared medium network or to a non-RSVP-capable 2717 router, there may be more than one next-hop node downstream; if 2718 so, each sends independent DF RESV messages for a given session. 2719 The number N' of DF channels reserved on an outgoing interface is 2720 given by the formula: 2722 N' = min( D1+D2+...Dn, Ns), 2724 where Di is the D value (channel reservation count) in a RESV from 2725 the ith next-hop node. 2727 For a DF reservation request with a Dynamic Reservation Count = C, 2728 RSVP should call TC_AddFlowspec C times. 2730 8.3 Resv Messages 2732 Add the following sequence: 2734 ::= 2736 2738 ::= | 2740 8.4 STYLE Class 2742 o STYLE-DF object: Class = 4, C-Type = 3 2744 +-------------+-------------+-------------+-------------+ 2745 | Style=3 | //////// | Dyn Resv Cnt| FD Count | 2746 +-------------+-------------+-------------+-------------+ 2748 Style 2750 3 = Dynamic-Filter 2752 Dyn Resv Count 2754 The number of channels to be reserved for a Dynamic 2755 Filter style reservation. This integer value must not 2756 less than FD Count. 2758 REFERENCES 2760 [CSZ92] Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time 2761 Applications in an Integrated Services Packet Network: Architecture 2762 and Mechanisms", Proc. SIGCOMM '92, Baltimore, MD, August 1992. 2764 [ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services 2765 in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and 2766 PARC, June 1994. 2768 [IServ93] Shenker, S., Clark, D., and L. Zhang, "A Service Model for an 2769 Integrated Services Internet", Work in Progress, October 1993. 2771 [Partridge92] Partridge, C., "A Proposed Flow Specification", RFC 1363, 2772 BBN, September 1992. 2774 [Shenker94] Shenker, S., "Two-Pass or Not Two-Pass", Current Meeting 2775 Report, RSVP Working Group, Proceedings of the Thirtieth Internet 2776 Engineering Task Force, Toronto, Canada, July 1994. 2778 [RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. 2779 Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, 2780 September 1993. 2782 Security Considerations 2784 See Section 2.5. 2786 Authors' Addresses 2788 Lixia Zhang 2789 Xerox Palo Alto Research Center 2790 3333 Coyote Hill Road 2791 Palo Alto, CA 94304 2793 Phone: (415) 812-4415 2794 EMail: Lixia@PARC.XEROX.COM 2796 Bob Braden 2797 USC Information Sciences Institute 2798 4676 Admiralty Way 2799 Marina del Rey, CA 90292 2801 Phone: (310) 822-1511 2802 EMail: Braden@ISI.EDU 2804 Deborah Estrin 2805 Computer Science Department 2806 University of Southern California 2807 Los Angeles, CA 90089-0871 2809 Phone: (213) 740-4524 2810 EMail: estrin@USC.EDU 2811 Shai Herzog 2813 USC Information Sciences Institute 2814 4676 Admiralty Way 2815 Marina del Rey, CA 90292 2816 Palo Alto, CA 94304 2818 Phone: (310) 822 1511 2819 EMail: Herzog@ISI.EDU 2821 Sugih Jamin 2822 Computer Science Department 2823 University of Southern California 2824 Los Angeles, CA 90089-0871 2826 Phone: (213) 740-6578 2827 EMail: jamin@catarina.usc.edu