idnits 2.17.1 draft-ietf-rsvp-spec-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** 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 -- Found 51 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? 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 2 instances of too long lines in the document, the longest one being 11 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 (November 3, 1994) is 10767 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) == Unused Reference: 'IServ93' is defined on line 2134, 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. 'RSVP93' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft L. Zhang 2 Expiration: May 95 PARC 3 File: draft-ietf-rsvp-spec-04.txt R. Braden 4 ISI 5 D. Estrin 6 ISI 7 S. Herzog 8 ISI 9 S. Jamin 10 USC 12 Resource ReSerVation Protocol (RSVP) -- 14 Version 1 Functional Specification 16 **DRAFT** 17 November 3, 1994 19 Status of Memo 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 To learn the current status of any Internet-Draft, please check the 32 linebreak "1id-abstracts.txt" listing contained in the Internet- 33 Drafts Shadow Directories on ds.internic.net (US East Coast), 34 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au 35 (Pacific Rim). 37 Abstract 39 This memo describes version 1 of RSVP, a resource reservation setup 40 protocol designed for an integrated services Internet. RSVP provides 41 receiver-initiated setup of resource reservations for multicast or 42 unicast data flows, with good scaling and robustness properties. 44 What's Changed Since Seattle IETF 46 o Redesign generic RSVP API (section 3.6.2) 48 o Change encoding of style in RESV messages (section 3.1.2) 50 o Clarify filterspec functions (section 2.1) 52 o Simplify definition of DF style (sections 2.2, 2.4). 54 o Revise discussion of flowspec merging (section 2.3.3). 56 o Change format of variable-length filterspecs and flowspecs 57 (section 3.1 and 3.6.1). 59 o Add a user authentication field in all RSVP messages (Section 60 3). 62 o Add short discussion of local repair (Section 3.3.3). 64 o Editorial nits. 66 1. Introduction 68 This memo describes RSVP, a resource reservation setup protocol 69 designed for an integrated services Internet [RSVP93,ISInt93]. An 70 application invokes RSVP to request a specific quality of service ( 71 QoS) for a data stream. Hosts and routers use RSVP to deliver these 72 requests to the routers along the path(s) of the data stream and to 73 maintain router and host state to provide the requested service. 74 This generally requires reserving resources in those nodes. 76 At each "node" (i.e., router or host) along the path, RSVP passes a 77 new resource reservation request to an admission control routine, to 78 determine whether there are sufficient resources available. If there 79 are, the node reserves the resources and updates its packet scheduler 80 and classifier control parameters to provide the requested QoS 81 [ISInt93]. It is expected that RSVP implementations will execute in 82 user space in a host, and in background in a router. On the other 83 hand, the packet scheduler and classifier are expected to execute in 84 the kernel of a host operating system, and in the high-speed packet 85 forwarding path of a router. 87 RSVP messages are sent as IP datagrams; thus, RSVP occupies the place 88 of a transport protocol in the protocol stack. However, like ICMP, 89 IGMP, and routing protocols, RSVP is really an Internet control 90 protocol; it does not carry any application data, and its messages 91 are processed by the routers in the path. 93 RSVP is not itself a routing protocol, but rather it is designed to 94 operate with existing and future unicast and multicast routing 95 protocols. Thus, a host sends IGMP messages to join a multicast 96 group, and then it sends RSVP messages to reserve resources along the 97 deliver path(s) from that group. Unlike a routing protocol, RSVP is 98 explicitly invoked by applications, to obtain a special QoS. 100 The objectives and general justification for RSVP design are 101 presented in [RSVP93,ISInt93]. In summary, RSVP has the following 102 attributes: 104 o RSVP supports multicast or unicast data delivery and adapts to 105 changing group membership as well as changing routes. 107 o RSVP reserves resources for simplex data streams. 109 o RSVP is receiver-oriented, i.e., the receiver of a data flow is 110 responsible for the initiation and maintenance of the resource 111 reservation used for that flow. 113 o RSVP maintains "soft state" in the routers, enabling it to 114 gracefully support dynamic membership changes and automatically 115 adapt to routing changes. 117 o RSVP provides several reservation models or "styles" (defined 118 below) to fit a variety of applications. 120 o RSVP provides transparent operation through routers that do not 121 support it. 123 The RSVP protocol mechanisms provide a general facility for creating 124 and maintaining distributed reservation state across a mesh of 125 multicast delivery paths. These mechanisms treat the reservation 126 parameters as opaque data, except for certain well-defined 127 operations, and simply pass them to the traffic control modules 128 (admission control, packet scheduler, and classifier) for 129 interpretation. Although the RSVP protocol mechanisms are largely 130 independent of the encoding of these parameters, the encodings must 131 be defined in the reservation model that is presented to an 132 application (see section 3.6.1). 134 In order to efficiently accommodate heterogeneous receivers and 135 dynamic group membership, RSVP makes the receivers responsible for 136 requesting resource reservations [RSVP93]. Each receiver can request 137 a reservation that is tailored to its particular requirement, and 138 RSVP will deliver this request to the routers along the reverse 139 path(s) to the sender(s). 141 There are two aspects to RSVP, its reservation model and its protocol 142 mechanisms. Sections 2.1 and 2.2 of this memo summarize the RSVP 143 reservation model, while Sections 2.3 describes the protocol 144 mechanisms. Sections 2.4 gives examples of both model and mechanism, 145 and Section 2.5 summarizes the model of RSVP seen by a host. Section 146 3 presents the functional specification for RSVP. 148 2. RSVP Overview 150 2.1 RSVP Reservation Model 152 Figure 1 illustrates a single multicast distribution session. The 153 arrows indicate data flowing from senders S1 and S2 to receivers 154 R1, R2, and R3, and the cloud represents the distribution mesh 155 created by the multicast routing protocol. Multicast distribution 156 forwards a copy of each data packet from a sender Si to every 157 receiver Rj. Each sender Si and receiver Rj may correspond to a 158 unique Internet host, or there may be multiple logical senders 159 (e.g., multiple TV cameras) and/or receivers in a single host. 161 RSVP reserves resources for simplex data streams, i.e., it 162 reserves resources in only one direction on a link, so that a 163 sender is logically distinct from a receiver. However, the same 164 application may act as both sender and receiver. 166 Senders Receivers 167 _____________________ 168 ( ) ===> R1 169 S1 ===> ( Multicast ) 170 ( ) ===> R2 171 ( distribution ) 172 S2 ===> ( ) 173 ( by Internet ) ===> R3 174 (_____________________) 176 Figure 1: Multicast Distribution Session 178 All data packets in a given session are addressed to the same IP 179 destination address DestAddress. For multicast delivery, 180 DestAddress is the multicast group address to which the data is 181 addressed. For unicast delivery, DestAddress is simply the 182 unicast address of the single receiver. RSVP identifies a session 183 by DestAddress plus a 32-bit stream identifier called the 184 "reservation id" (ResvID). We use the term "session socket" for 185 the (DestAddress, ResvID) pair that defines a session. RSVP 186 treats each session independently. In the rest of this document, 187 a particular session (hence, session socket) is always implied 188 even if not stated. 190 Depending upon the reservation style and the session state already 191 in place, a new or modified reservation request may or may not 192 result in a call to admission control at each node [ISInt93]. If 193 an admission control call fails, the reservation is rejected and 194 an RSVP error message is sent to the receiver(s) responsible for 195 it. 197 A single RSVP resource reservation request is defined by a " 198 flowspec" together with a "filterspec"; this pair is called a " 199 Flow Descriptor". The flowspec specifies the desired QoS in a 200 quantitative manner, e.g., the tolerable delay, the average 201 throughput, the maximum burstiness, etc [Partridge92, ISInt93, 202 IServ93]; it is used to set parameters to the packet scheduling 203 mechanism in the node (router or host). The filterspec (plus the 204 DestAddress) defines the set of data packets to receive this 205 service; it is used to set parameters in the packet classifier 206 component of the node. For all packets that are addressed to a 207 particular session, only those that can match the filter spec(s) 208 of that session will be forwarded according to the flowspec; the 209 rest will be either dropped or sent as best-effort traffic. 211 More specifically, a filterspec may have two distinct functions. 213 o Sender Selection 215 A filterspec may select packets that originate from a 216 particular sender Si, from the entire stream of packets 217 destined to a given DestAddress. The sender is selected 218 using its IP source address and optionally a "generalized 219 source port", i.e., multiplexing field(s) at the transport 220 layer (e.g., a UDP destination port) and/or the application 221 layer (e.g., a particular subset of a hierarchically encoded 222 video stream). 224 o Receiver Sub-selection 226 A filterspec may distinguish different sessions with the same 227 DestAddress by selecting a subset of the packets destined to 228 that address. This subset is defined by a "generalized 229 destination port", which again may include transport-layer 230 (e.g., UDP destination port) and/or application-layer 231 demultiplexing information. An RSVP receiver Rj is defined 232 by the pair (Hj, Pj), where Hj is the IP host address and Pj 233 is the generalized destination port. 235 RSVP needs to distinguish different sessions. It is difficult to 236 do this by matching generalized destination ports buried within 237 the filterspecs, since the part of the filterspec that defines the 238 generalized destination port should be opaque to an RSVP module in 239 a router, which does not not know the structure of transport or 240 application layer protocol headers. Therefore, RSVP identifies a 241 session by the pair (DestAddress, ResvID), where the ResvID's form 242 a simple space of identifiers that RSVP can use to distinguish 243 different sessions with the same DestAddress. The ResvID's need 244 not themselves be (generalized) ports, but the the ResvID values 245 that are used must have a one-to-one correspondence with the 246 generalized ports in use for the given DestAddress. 248 All reservation requests for a given session must use filterspecs 249 that specify the same DestAddress and the same generalized 250 destination port (since receivers of the same substream, 251 downstream of a given node, must share a common resource 252 reservation in that node). 254 2.2 Reservation Styles 256 In addition to the Flow Descriptors, each RSVP reservation request 257 specifies a "reservation style". The following reservation styles 258 have been defined so far. 260 1. Wildcard-Filter (WF) Style 262 A Wildcard-Filter (WF) style reservation creates a single 263 resource "pipe" along each link, shared by data packets from 264 all senders for the given session. The "size" of this pipe 265 is the largest of the resource requests for that link from 266 all receivers, independent of the number of senders using it. 267 (The concept of a "largest" flowspec is discussed later). 269 The term "wildcard" implies a filterspec that selects all 270 senders. A WF reservation automatically extends to new 271 senders to the session, as they appear. 273 2. Fixed-Filter (FF) Style 275 A Fixed-Filter (FF) style reservation request creates 276 reservation(s) for data packets from particular sender(s). A 277 FF reservation request from a particular receiver Rj contains 278 a list of one or more Flow Descriptors, each consisting of a 279 filterspec, which specifies some sender Si, and a 280 corresponding flowspec. 282 FF reservations requested by different receivers Rj but 283 selecting the same sender Si must necessarily share a single 284 reservation in a given node. This is simply the result of 285 multicast distribution, which creates a single stream of data 286 packets in a particular router from any Si, regardless of the 287 number of receivers downstream. The reservation for Si will 288 be the maximum of the individual flowspecs from different 289 downstream receivers Rj (see Section 2.3.3). 291 FF reservations for different senders are distinct; they do 292 NOT share a common pipe. The total reservation on a link for 293 a given session is therefore the cumulative total of the 294 reservations for each requested sender. A receiver that has 295 established a FF style reservation may modify, add, or delete 296 a flow descriptor at any time. However, any additional or 297 modified reservations are subject to admission control and 298 may fail. 300 3. Dynamic-Filter (DF) Style 302 A Dynamic-Filter (DF) style reservation decouples 303 reservations from filters. Each DF reservation request 304 specifies a number D of distinct reservations to be made 305 using the same specified flowspec. The number of 306 reservations that are actually made in a particular node is 307 D' = min(D,Ns), where Ns is the total number of senders 308 upstream of the node. 310 In addition to D and the flowspec, a DF style reservation may 311 also specify a list of K filterspecs, for some K in the 312 range: 0 <= K <= D'. These filterspecs define particular 313 senders to use the D' reservations. Once a DF reservation 314 has been established, the receiver may change the set of 315 filterspecs to specify a different selection of senders, 316 without a new admission control check (assuming D' and the 317 common flowspec remain unchanged). This is known as "channel 318 switching", in analogy with a television set. 320 In order to provide assured channel switching, each node 321 along the path must reserve enough bandwidth for all D' 322 channels, even though some of this bandwidth may be unused at 323 any one time. If D' changes (because the receiver changed D 324 or because the number Ns of upstream sources changed), or if 325 the common flowspec changes, the refresh message is treated 326 as a new reservation that is subject to admission control and 327 may fail. 329 Like a FF style request, a DF style request causes distinct 330 reservations for different senders. 332 As noted earlier, those data packets from senders that are 333 not currently selected may either be dropped or sent best- 334 effort. 336 WF reservations are appropriate for those multicast applications 337 whose application-level constraints prohibit all data sources from 338 transmitting simultaneously; one example is audio conferencing, 339 where a limited number of people talk at once. Thus, each 340 receiver might issue a WF reservation request for twice one audio 341 channel (to allow some over-speaking). On the other hand, the FF 342 and DF styles create independent reservations for the flows from 343 different senders; this is required for video signals, whose 344 `silence' periods, if any, are uncoordinated among different 345 senders. 347 The essential difference between the FF and DF styles is that the 348 DF style allows a receiver to switch channels without danger of an 349 admission denial due to limited resources (unless a topology 350 change reroutes traffic along a lower-capacity path or new senders 351 appear), once the initial reservations have been made. 353 Other reservation styles may be defined in the future. 355 2.3 RSVP Protocol Mechanisms 357 2.3.1 RSVP Messages 359 Each receiver host sends RSVP reservation (RESV) messages into 360 the Internet, carrying Flow Descriptors requesting the desired 361 reservation; see Figure 2. These reservation messages must 362 follow the reverse of the routes the data packets will use, all 363 the way upstream to all the senders. If a reservation request 364 fails at any node, an RSVP error message is returned to the 365 receiver; however, RSVP sends no positive acknowledgment 366 messages to indicate success. RESV messages are finally 367 delivered to the sender hosts, so that the hosts can set up 368 appropriate traffic control parameters for the first hop. 370 Sender Receiver 371 _____________________ 372 Path --> ( ) 373 Si =======> ( Multicast ) Path --> 374 <-- Resv ( ) =========> Rj 375 ( distribution ) <-- Resv 376 (_____________________) 378 Figure 2: RSVP Messages 380 Each sender transmits RSVP PATH messages forward along the 381 uni-/multicast routes provided by the routing protocol(s). 382 These "Path" messages store path state in all the intermediate 383 routers. 385 The path state is currently used by RSVP to route the RESV 386 messages in the reverse direction from each receiver to all 387 selected senders for a given session. In the future, this 388 function may be assumed by routing protocols. PATH messages 389 have other functions; they carry the following additional 390 information: 392 o A sender template, which describes the format of data 393 packets that the sender will originate. 395 The sender template takes the form of two bitstrings 396 forming a (value, mask) pair. Zero mask bits represent 397 "don't care" (variable) bits in data packets. If present, 398 this template is used by RSVP to match the filterspecs in 399 a RESV message. Without such a template in the path 400 state, there will be no feedback (except poor service) to 401 the receiver that sets an impossible filter by mistake. 403 ISSUE: 405 Should sender templates be defined to be precisely 406 filterspecs, or should templates and filterspecs be 407 allowed to use different syntax? 409 o A flowspec defining an upper bound on the traffic that 410 will be generated. 412 This flowspec can be used by RSVP to prevent over- 413 reservation on the non-shared links starting at the 414 sender. 416 A (template, flowspec) pair in a PATH message is called a 417 Sender Descriptor. 419 2.3.2 Soft State 421 To maintain reservation state, RSVP keeps "soft state" in 422 router and host nodes. RSVP soft state is created and 423 periodically refreshed by PATH and RESV messages, and it can be 424 removed at each node by explicit "Teardown" messages. RSVP 425 also has a timer-driven cleanup procedure if no message is 426 received within a cleanup timeout interval. 428 When the route changes, the next PATH message will initialize 429 the path state on the new route, and future RESV messages will 430 establish reservation state while the state on the now-unused 431 segment of the route times out. Thus, whether a message is 432 "new" or a "refresh" is determined separately at each node, 433 depending upon the existence of state at that node. (This 434 document will use the term "refresh message" in this effective 435 sense, to indicate an RSVP message that does not modify the 436 existing state at the node in question.) 438 RSVP sends all its messages as IP datagrams without any 439 reliability enhancement. Periodic transmission of refresh 440 messages by hosts and routers is expected to replace any lost 441 RSVP messages. However, the traffic control mechanism should 442 be statically configured to grant high-reliability service to 443 RSVP messages, to protect RSVP messages from severe congestion. 445 If the set of senders Si or receivers Rj changes, or if any of 446 the receivers' reservation requests change, the RSVP state is 447 adjusted accordingly. RSVP believes the latest PATH and RESV 448 messages (ignoring the possibility of reordering). To modify a 449 reservation, a receiver simply starts sending the new values. 450 It is not necessary (although it may sometimes be desirable, 451 when the resources being consumed are "valuable"), to tear down 452 the old reservation explicitly. 454 When a RESV message is received at a router or sender host, the 455 RSVP module checks whether the message is a new or a modified 456 reservation request, or whether it simply refreshes an existing 457 reservation. A new or modified request is passed to the 458 admission control module for a decision. If the reservation is 459 accepted, RSVP sets up (or modifies) the reservation and filter 460 state. It also forwards the RESV message to the next reverse- 461 hop router(s) or sender host(s), as determined by the path (or 462 routing) state. If RSVP on the node rejects the reservation 463 request due to admission control failure or to some processing 464 error, it discards the RESV message and returns a RSVP error 465 message to the originating receiver host. If the request 466 modifies a previous reservation, RSVP may immediately remove 467 the old state, or it may simply let the old state time out 468 since it is no longer being refreshed; the details depend upon 469 the style and the implementation. 471 Previous Incoming Outgoing Next 472 Hops Interfaces Interfaces Hops 474 _____ _____________________ _____ 475 | | data --> | | data --> | | 476 | |-----------| |------------| | 477 |_____| <-- Resv | | <-- Resv |_____| 478 Path --> | | Path --> 479 | Router | 480 _____ | | _____ 481 | | data --> | | data --> | | 482 | |-----------| |------------| | 483 |_____| <-- Resv | | <-- Resv |_____| 484 Path --> |_____________________| Path --> 486 Figure 3: Router Using RSVP 488 Figure 3 illustrates RSVP's model of a router node. Each data 489 stream arrives from a previous hop through a corresponding 490 incoming interface and departs through one or more outgoing 491 interface(s). Since the same host may be hosting both sender 492 and receiver applications for a given session, the same 493 physical interface may act in both the incoming and outgoing 494 roles (for different data streams). 496 The interfaces shown in Figure 3 may be physical interfaces 497 (e.g., to point-to-point links), or they may be logical 498 interfaces that reach multiple nodes through the same physical 499 interface. Multiple previous hops and/or next hops through a 500 given physical interface can result from either the connected 501 network being a shared medium (e.g., an Ethernet), or from the 502 existence of non-RSVP routers in the path to the next RSVP hop 503 (see Section 3.5). It is generally necessary for RSVP to track 504 both logical and physical interfaces on both the incoming and 505 outgoing sides. 507 2.3.3 Merging RSVP Messages 509 Whenever possible, the control information arriving in RSVP 510 messages for a given session is combined into fewer outgoing 511 messages; this is known generically as "merging". Those 512 messages that cause a state change are forwarded without delay, 513 while the refresh messages may be merged into fewer messages, 514 perhaps only one per session. 516 For PATH messages, merging implies collecting together the 517 Sender Descriptors from multiple incoming messages into a 518 single outgoing PATH message. For RESV messages, merging 519 implies that only the essential (e.g., the largest) reservation 520 requests need be forwarded, once per refresh period; redundant 521 messages are "purged". A successful reservation request will 522 propagate as far as the closest point(s) along the sink tree to 523 the sender(s) where a reservation level equal or greater than 524 that being requested has been made. At that point, the merging 525 process will drop it in favor of another, equal or larger, 526 reservation request. 528 To allow merging, each node must save the state from received 529 messages and then periodically generate cumulative PATH and 530 RESV messages from the saved state, to be forwarded in place of 531 the received messages. Thus, new refresh messages are created 532 hop-by-hop inside the network, at a rate determined by a 533 "refresh period". Since messages that modify the state in a 534 node ("new" messages) are forwarded without delay, the refresh 535 period does not affect the rate at which new state propagates 536 from end to end (when packets are not lost). 538 Although flowspecs are opaque to RSVP, merging requires the 539 ability to determine which of two flowspecs is "larger", i.e. 540 whether one represents a stricter request (and hence represents 541 a larger resource commitment) than the other. However, a 542 flowspec may be a complex multi-dimensional vector, so the 543 "larger-than" relationship may not be defined for a given pair 544 of flowspecs. For example, consider two flowspecs Fls1 and 545 Fls2, where Fls2 asks for a lower throughput but shorter delay 546 that Fls1. It is not clear which is "larger", so we say they 547 are "incompatible". 549 There are several possible solutions to merging incompatible 550 flowspecs. 552 (1) Compare on a single dimension, e.g., compare the 553 throughput requirement (average bit rate) only. 555 (2) Construct a third flowspec that is greater than each 556 of the two being compared. In the example above, we 557 could construct a third flowspec Fls3 by combining 558 the higher throughput from Fls1 with the lower delay 559 from Fls2. 561 (3) Treat the compatibility as an error that should be 562 avoided by applications. 564 The choice of one of these approaches should be governed by 565 flags in the flowspec itself, not by RSVP. 567 Note that this problem cannot be avoided by refraining from 568 merging flowspecs. If incompatible flowspecs were not merged 569 at a particular node A, then they would arrive at the next node 570 upstream, say B, in separate RESV messages. This may also 571 happen if there are multiple next hops across the same outgoing 572 interface. Node B would have to make a reservation for the 573 largest flowspec, if that is defined, or one that dominates all 574 the given flowspecs; that is, it must merge the unmerged 575 reservations. Thus, failing to merge simply moves the problem 576 one node upstream. 578 This mechanism, reserving for the highest demand at each node, 579 allows an application to increase an existing reservation 580 request immediately (assuming admission control does not fail 581 for the larger flowspec). Decreasing a reservation has to be 582 handled more cautiously, however. The arrival of a RESV 583 message with an apparently decreased reservation might be 584 caused by the loss of a merged RESV message downstream. 585 Therefore, an RSVP should not "believe" a reservation decrease 586 until the cleanup timeout has passed. 588 The refresh period and the cleanup timeout must obey the 589 following general principles: 591 A. The refresh period must be long enough to keep RSVP 592 overhead at an acceptable level. 594 B. The refresh period should be short enough to allow 595 quick adaptation to route and multicast membership 596 changes. 598 Applications may differ in their sensitivity to 599 service outages, and therefore they should be able to 600 adjust the refresh period for their session state. 601 However, the technique of "local repair" (see Section 602 3.3.3) can provide rapid adaptation despite a long 603 refresh period. 605 C. The timeout period must be long enough to allow for 606 loss of individual RSVP messages. 608 2.3.4 Teardown 610 As an optimization to release resources quickly, RSVP teardown 611 messages remove path and reservation state without waiting for 612 the cleanup timeout period. RSVP messages are not delivered 613 reliably, but the state will eventually time out even if a 614 teardown message is lost. 616 Teardown may be initiated either by an end system (sender or 617 receiver), or by a router as the result of state timeout. A 618 router may also initiate a teardown message as the result of 619 router or link failures detected by the routing protocol. A 620 teardown, once initiated, will be forwarded hop-by-hop without 621 delay. 623 There are two types of RSVP Teardown message, PTEAR and RTEAR. 624 A PTEAR message travels towards all receivers downstream from 625 its point of initiation and tears down path state along the 626 way, while an RTEAR message tears down reservation state and 627 travels towards all senders upstream from its point of 628 initiation. 630 A particular reservation on a node may be shared among multiple 631 senders and/or receivers, but it must apply to a unique next 632 hop (and outgoing interface). The receipt of an RTEAR message 633 implies that the corresponding reservation state has been 634 removed downstream, so that the reservation can safely be 635 deleted locally. Again, the local node will only forward the 636 teardown message upstream when the state named in the message 637 has been entirely removed locally. As a result, an RTEAR 638 message will prune the reservation state back (only) as far as 639 possible. Note that the RTEAR message will cease to be 640 forwarded at the same node where merging suppresses forwarding 641 of the corresponding RESV messages. 643 Consider the router configuration shown in Figure 4 below. 644 Assume that there are reservations for source S1 on both 645 outgoing interfaces (c) and (d), and that the receiver R1 wants 646 to tear down its reservation state for S1. R1's RTEAR message 647 arriving through interface (c) indicates that all reservation 648 state for (this session and) sender S1 has been removed 649 downstream. The current node therefore removes the S1 650 reservation state from interface (c). However, since there 651 will still be an S1 reservation on interface (d), the RTEAR 652 message will not be forwarded any further. 654 However, if the outgoing interface connects to a shared medium 655 or if there is a non-RSVP router immediately downstream, then 656 there may be multiple next-hop RSVP nodes downstream that are 657 reached through the same outgoing interface, say (c). Then a 658 single reservation may be shared among multiple next hops. 659 RSVP must tag each reservation with the next hop(s) from which 660 the RESV messages came, for use by teardown to avoid deleting 661 shared state. 663 Deletion of path state, whether as the result of a teardown 664 message or because of timeout, may force adjustments in related 665 reservation state to maintain consistency in the local node. 666 Consider the path state for a sender S; the related reservation 667 state would be as follows. 669 o Wildcard-Filter style: If S is the only sender to the 670 session, delete the reservation. 672 o Fixed-Filter style: Delete reservations made for S. 674 o Dynamic-Filter style: Reduce total reservation if it now 675 exceeds the total number of remaining senders. 677 2.4 Examples 679 We use the following notation for a RESV message: 681 1. Wildcard-Filter 683 WF( *{r}) 685 Here "*{r}" represents a Flow Descriptor with a "wildcard" 686 filter (choosing all senders) and a flowspec of quantity r. 687 For simplicity we assume here that flowspecs are one- 688 dimensional, defining for example the average throughput, and 689 state them as a multiple of some unspecified base resource 690 quantity B. 692 2. Fixed-Filter 693 FF( S1{r1}, S2{r2}, ...) 695 This message carries a list of (sender, flowspec) pairs, 696 i.e., Flow Descriptors. 698 3. Dynamic-Filter 700 DF( n, {r} ; ) or DF( n, {r} ; S1, S2, ...) 702 This message carries the count n of channels to be reserved, 703 each using common flowspec r. It also carries a list, 704 perhaps empty, of filterspecs defining senders. 706 Figure 4 shows schematically a router with two previous hops 707 labeled (a) and (b) and two outgoing interfaces labeled (c) and 708 (d). This topology will be assumed in the examples that follow. 709 There are three upstream senders; packets from sender S1 (S2 and 710 S3) arrive through previous hop (a) ((b), respectively). There 711 are also three downstream receivers; packets bound for R1 and R2 712 (R3) are routed via outgoing interface (c) ((d) respectively). 714 In addition to the connectivity shown in 4, we must also specify 715 the multicast routing within this node. Assume first that data 716 packets (hence, PATH messages) from each Si shown in Figure 4 is 717 routed to both outgoing interfaces. Under this assumption, 718 Figures 5, 6, and 7 illustrate Wildcard-Filter reservations, 719 Fixed-Filter reservations, and Dynamic-Filter reservations, 720 respectively. 722 ________________ 723 (a)| | (c) 724 ( S1 ) ---------->| |----------> ( R1, R2) 725 | Router | 726 (b)| | (d) 727 ( S2,S3 ) ------->| |----------> ( R3 ) 728 |________________| 730 Figure 4: Router Configuration 732 In Figure 5, the "Receive" column shows the RESV messages received 733 over outgoing interfaces (c) and () and the "Reserve" column shows 734 the resulting reservation state for each interface. The "Send" 735 column shows the RESV messages forwarded to previous hops (a) and 736 (b). In the "Reserve" column, each box represents one reservation 737 "channel", with the corresponding filter. As a result of merging, 738 only the message with the largest flowspec is forwarded upstream 739 to each previous hop. 741 | 742 Send | Reserve Receive 743 | 744 | _______ 745 WF( *{3B} ) <- (a) | (c) | * {3B}| (c) <- WF( *{B} ) 746 | |_______| 747 | 748 -----------------------|---------------------------------------- 749 | _______ 750 WF( *{3B} ) <- (b) | (d) | * {B} | (d) <- WF( *{3B} ) 751 | |_______| 753 Figure 5: Wildcard-Filter Reservation Example 1 755 Figure 6 shows Fixed-Filter style reservations. Merging takes 756 place among the flow descriptors (i.e., filter spec, flowspec 757 pairs). For example, the message forwarded to previous hop b, 758 towards S2 and S3, contains flow descriptors received from 759 outgoing interfaces (c) and (d). Similarly, when FF( S1{B} ) and 760 FF( S1{3B} ) are merged, the single message FF( S1{3B} ) is sent 761 to previous hop (a), towards S1. 763 For each outgoing interface, there is a private reservation for 764 each source that has been requested, but this private reservation 765 is shared among the receivers that made the request. 767 | 768 Send | Reserve Receive 769 | 770 | ________ 771 FF( S1{3B} ) <- (a) | (c) | S1{B} | (c) <- FF( S1{B}, S2{5B} ) 772 | |________| 773 | | S2{5B} | 774 | |________| 775 -----------------------|--------------------------------------------- 776 | ________ 777 <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) 778 FF( S2{5B}, S3{B} ) | |________| 779 | | S3{B} | 780 | |________| 782 Figure 6: Fixed-Filter Reservation Example 784 Figure 7 shows an example of Dynamic-Filter reservations. The 785 receivers downstream from interface (d) have requested two 786 reserved channels, but selected only one sender, S1. The node 787 reserves min(2,3) = 2 channels of size B on interface (d), and it 788 then applies any specified filters to these channels. Since only 789 one sender was specified, one channel has no corresponding filter, 790 as shown by `?'. 792 Similarly, the receivers downstream of interface (c) have 793 requested two channels and selected senders S1 and S2. The two 794 channels might have been one channel each from R1 and R2, or two 795 channels requested by one of them, for example. 797 | 798 Send | Reserve Receive 799 | 800 | ________ 801 DF( 1,{B}; S1) <- (a) | (c) | S1{B} | (c) <- DF( 2,{B}; S1, S2) 802 | |________| 803 | | S2{B} | 804 | |________| 805 | 806 ------------------------|------------------------------------------- 807 | ________ 808 DF( 2,{B}; S2) <- (b) | (d) | S1{B} | (d) <- DF( 2,{B}; S1) 809 | |________| 810 | | ?{B} | 811 | |________| 813 Figure 7: Dynamic-Filter Reservation Example 815 A router should not reserve more Dynamic-Filter channels than the 816 number of upstream sources (three, in the router of Figure 7). 817 Since there is only one source upstream from previous hop (a), the 818 first parameter of the DF message (the count of channels to be 819 reserved) was decreased to 1 in the forwarded reservations. 820 However, this is unnecessary, because the routers upstream will 821 reserve only one channel, regardless. 823 When a DF reservation is received, it is labeled with the IP 824 address of the next hop (RSVP-capable) router, downstream from the 825 current node. Since the outgoing interface may be directly 826 connected to a shared medium network or to a non-RSVP-capable 827 router, there may be more than one next-hop node downstream; if 828 so, each sends independent DF RESV messages for a given session. 829 The number N' of DF channels reserved on an outgoing interface is 830 given by the formula: 832 N' = min( D1+D2+...Dn, Ns), 834 where Di is the D value (channel reservation count) in a RESV from 835 the ith next-hop node. 837 The three examples just shown assume full routing, i.e., data 838 packets from S1, S2, and S3 are routed to both outgoing 839 interfaces. Assume the routing shown in Figure 8, in which data 840 packets from S1 are not forwarded to interface (d) (because the 841 mesh topology provides a shorter path for S1->R3 that does not 842 traverse this node). 844 _______________ 845 (a)| | (c) 846 ( S1 ) ---------->| --------->--> |----------> ( R1, R2) 847 | / | 848 | / | 849 (b)| / | (d) 850 ( S2,S3 ) ------->| ->----------> |----------> ( R3 ) 851 |_______________| 853 Figure 8: Router Configuration 855 Under this assumption, Figure 9 shows Wildcard-Filter 856 reservations. Since there is no route from (a) to (d), the 857 reservation forwarded out interface (a) considers only the 858 reservation on interface (c), so no merging takes place in this 859 case. 861 | 862 Send | Reserve Receive 863 | 864 | _______ 865 WF( *{B} ) <- (a) | (c) | * {3B}| (c) <- WF( *{B} ) 866 | |_______| 867 | 868 -----------------------|---------------------------------------- 869 | _______ 870 WF( *{3B} ) <- (b) | (d) | * {B} | (d) <- WF( * {3B} ) 871 | |_______| 873 Figure 9: Wildcard-Filter Reservation Example -- Partial Routing 875 2.5 Host Model 877 Before a session can be created, the session socket, comprised of 878 DestAddress and ResvID, must be assigned and communicated to all 879 the senders and receivers by some out-of-band mechanism. In order 880 to join an RSVP session, the end systems perform the following 881 actions. 883 H1 A receiver joins the multicast group specified by 884 DestAddress. 886 H2 A potential sender starts sending RSVP PATH messages to 887 the DestAddress. 889 H3 A receiver listens for PATH messages. 891 H4 A receiver starts sending appropriate RESV messages, 892 specifying the desired Flow Descriptors. 894 There are several synchronization issues. 896 o Suppose that a new sender starts sending data but there are 897 no receivers. There will be no multicast routes beyond the 898 host (or beyond the first RSVP-capable router) along the 899 path; the data will be dropped at the first hop until 900 receivers(s) do appear (assuming a multicast routing protocol 901 that "prunes off" or otherwise avoids unnecessary paths). 903 o Suppose that a new sender starts sending PATH messages (H2) 904 and immediately starts sending data, and there are receivers 905 but no RESV messages have reached the sender yet (e.g., 906 because its PATH messages have not yet propagated to the 907 receiver(s)). Then the initial data may arrive at receivers 908 without the desired QoS. 910 o If a receiver starts sending RESV messages (H4) before any 911 PATH messages have reached it (and if path state is being 912 used to route RESV messages), RSVP will return error messages 913 to the receiver. 915 The receiver may simply choose to ignore such error messages, 916 or it may avoid them by waiting for PATH messages before 917 sending RESV messages. 919 A specific application program interface (API) for RSVP is not 920 defined in this protocol spec, as it may be host system dependent. 921 However, Section 3.6.2 discusses the general requirements and 922 presents a generic API. 924 3. Functional Specification 926 There are currently 6 types of RSVP messages: PATH, RESV, PTEAR, 927 RTEAR, PERR, and RERR. 929 3.1 Message Formats 931 3.1.1 Path Message 933 0 1 2 3 934 +-------------+-------------+-------------+-------------+ 935 | Vers | Type | Flags | RSVP Checksum | 936 +-------------+-------------+-------------+-------------+ 937 | DestAddress | 938 +-------------+-------------+-------------+-------------+ 939 | ResvID | 940 +-------------+-------------+-------------+-------------+ 941 | Refresh Period | 942 +-------------+-------------+-------------+-------------+ 943 | State TTL Time | 944 +-------------+-------------+-------------+-------------+ 945 | Previous Hop Address | 946 +-------------+-------------+-------------+-------------+ 947 | /////////////// | SD Count | 948 +-------------+-------------+-------------+-------------+ 949 | Authentication Field | 950 // ... // 951 +-------------+-------------+-------------+-------------+ 952 | Sender Descriptor List | 953 // ... // 954 +-------------+-------------+-------------+-------------+ 956 IP Fields: 958 Protocol 960 46 962 IP Source Address 964 The IP address of the host or router sending this 965 message. 967 IP Destination Address 969 The IP address of the data destination (DestAddress). 971 RSVP Fields: 973 Vers 975 Version number. This is version 1. 977 Type 979 1 = Path Message 981 Flags 983 8 = Drop 985 If this flag bit is on then data packets will be 986 dropped when they are destined to this session 987 but their sender is not currently selected by 988 any filter. If this flag bit is off, such data 989 packets will still be forwarded but without a 990 reservation, i.e., using a best-effort class. 992 RSVP Checksum 994 A standard TCP/UDP checksum, over the contents of the 995 RSVP message with the checksum field replaced by 996 zero. 998 DestAddress, ResvID 1000 The IP address and stream Id identifying the session, 1001 i.e., the session socket. 1003 Previous Hop Address 1005 The IP address of the interface through which the 1006 host or router last forwarded this message. 1008 The Previous Hop Address is used to support reverse- 1009 path forwarding of RESV messages. This field is 1010 initialized by a sender to its IP address (see IP 1011 Source Address above) and must be updated at each 1012 router hop as the PATH message is forwarded. 1014 Refresh Period 1016 This field specifies the refresh timeout period in 1017 milliseconds. See Section 3.3 below. 1019 State TTL Time 1021 This field specifies the time-to-live for soft state, 1022 in milliseconds. It determines the cleanup timeout 1023 period; see Section 3.3 below. 1025 SD Count 1027 Count of Sender Descriptors that follow. 1029 Authentication Field 1031 A variable-length authentication field to identify 1032 and perhaps authenticate the principal making this 1033 reservation request. The field has the following 1034 form: 1036 +-------------+-------------+-------------+-------------+ 1037 | AuthLen | AuthType | | 1038 +-------------+-------------+ + 1039 // Authentication Info // 1040 +-------------+-------------+-------------+-------------+ 1042 The AuthLen octet contains the integer length of the 1043 field in fullwords, and AuthType specifies the format 1044 of the field. See Section 3.6.1 for currently 1045 defined authentication field formats. If there is no 1046 authentication information, AuthLen will be zero, but 1047 the Authentication Field will still occupy one 1048 fullword in the message. 1050 Sender Descriptor List 1052 A list of Sender Descriptors (see below). The order 1053 of entries in this list is irrelevant. 1055 Each sender must periodically send a PATH message containing a 1056 single Sender Descriptor describing its own data stream. These 1057 messages are addressed to the uni-/multicast destination 1058 address for the session, and they are forwarded to all 1059 receivers, following the same paths as a data packet from the 1060 same sender. PATH messages are received and processed locally 1061 to create path state at each intermediate router along the 1062 path. 1064 If an error is encountered while processing a PATH message, an 1065 RSVP error message is sent to all the sender hosts listed in 1066 the Sender Descriptor List. 1068 PATH messages are distributed from senders to receivers along 1069 the exact paths that the data will traverse, using uni- 1070 /multicast routing. This distribution actually takes place 1071 hop-by-hop, allowing RSVP in each router along the path to 1072 observe and modify the message. Routing of PATH messages is 1073 based on the sender address(es) from the Sender Descriptor(s), 1074 not the IP source address. This is necessary to prevent loops; 1075 see Section 3.2. 1077 Each Sender Descriptor consists of two variable-length fields: 1078 a sender template that defines the format of data packets and a 1079 corresponding Flowspec that describes the traffic 1080 characteristics. The sender template has the form of a 1081 filterspec, and a Sender Descriptor has the form defined below 1082 for a Flow Descriptor (see also Section 3.6.1). The flowspec 1083 may be omitted, in which case its length field will be zero 1084 (but it will still occupy one fullword in the Sender 1085 Descriptor). 1087 The Sender template is retained in the Path state in order to 1088 validate filterspecs in RESV messages. Suppose that a 1089 filterspec consisted of a simple (value,mask) pair (Vf,Mf) to 1090 be applied to the headers of the data packets (the actual 1091 format is slightly more complex; see Section 3.6.1). Then the 1092 corresponding template would be a (value,mask) pair defining 1093 those bits of the data packet headers that are fixed. While 1094 processing a reservation using filterspec (Vf,Mf) for the 1095 sender with template (Vs,Ms), RSVP can then test whether 1096 Vf&(Mf&Ms) = Vs&(M&Ms). If not, this filterspec cannot 1097 possibly match the data stream from this sender at any node 1098 upstream, and the reservation can be rejected with an error 1099 message back to the receiver. 1101 3.1.2 Resv Message 1103 RESV messages are sent from receivers to senders along reverse 1104 paths established by PATH messages. 1106 0 1 2 3 1107 +-------------+-------------+-------------+-------------+ 1108 | Vers | Type | Flags | RSVP Checksum | 1109 +-------------+-------------+-------------+-------------+ 1110 | DestAddress | 1111 +-------------+-------------+-------------+-------------+ 1112 | ResvID | 1113 +-------------+-------------+-------------+-------------+ 1114 | Refresh Period | 1115 +-------------+-------------+-------------+-------------+ 1116 | State TTL Time | 1117 +-------------+-------------+-------------+-------------+ 1118 | Next Hop Address | 1119 +-------------+-------------+-------------+-------------+ 1120 | RecvAddress | 1121 +-------------+-------------+-------------+-------------+ 1122 | Dynamic Reservation Count | FD Count | 1123 +-------------+-------------+-------------+-------------+ 1124 | Authentication Field | 1125 // ... // 1126 +-------------+-------------+-------------+-------------+ 1127 | Flow Descriptor List | 1128 // ... // 1129 +-------------+-------------+-------------+-------------+ 1131 The fields are the same as defined earlier for a PATH message, 1132 except for the following: 1134 IP Fields: 1136 IP Source Address 1138 The IP address of the node sending this message. 1140 IP Destination Address 1142 The IP address of the next-hop router or host to 1143 which this message is being sent. 1145 RSVP Fields: 1147 Type 1149 2 = Resv Message 1151 Flags 1153 The following flag bit combinations define the 1154 reservation style: 1156 001xxxxx = Wildcard-Filter 1158 010xxxxx = Fixed-Filter 1160 011xxxxx = Dynamic-Filter 1162 Next Hop Address 1164 The IP address of the interface through which the 1165 last forwarded this message. 1167 The Next Hop Address is used to support teardown. 1168 This field is initialized by a receiver to its IP 1169 address and must be updated at each router hop as the 1170 RESV message is forwarded. 1172 RecvAddress 1174 The IP address of (one of the) receiver(s) that 1175 originated this message, or one of the RESV messages 1176 that was merged to form this message. 1178 Dynamic Reservation Count 1180 The number of channels to be reserved, for a 1181 Dynamic-Filter style reservation. 1183 If the ResvStyle is Dynamic-Filter, this integer 1184 value must be constant and equal or greater than (FD 1185 Count). For other ResvStyles, this field must be 1186 zero. 1188 FD Count 1190 Count of Flow Descriptors in the Flow Descriptor 1191 List. 1193 Flow Descriptor List 1194 A list of Flow Descriptors, i.e., (Filterspec, 1195 flowspec) pairs, to define individual reservation 1196 requests. The first entry in the list may have 1197 special meaning (see below); the order of later 1198 entries is irrelevant. 1200 Each Flow Descriptor has the following form: 1202 +-------------+-------------+-------------+-------------+ 1203 | FiltSLen | FiltSType | | 1204 +-------------+-------------+ + 1205 // Filter Spec ... // 1206 +-------------+-------------+-------------+-------------+ 1207 | FlowSLen | FlowSType | | 1208 +-------------+-------------+ + 1209 // Flow Spec ... // 1210 +-------------+-------------+-------------+-------------+ 1212 Here FiltSLen and FlowSLen are one-octet fields 1213 specifying the lengths in fullwords (including the 1214 length byte) of the filterspec and flowspec, 1215 respectively, and FiltSType and FlowSType are one- 1216 octet fields defining the corresponding field 1217 formats. See Section 3.6.1 for currently defined 1218 formats. 1220 The following specific rules hold for different reservation 1221 styles. 1223 o Wildcard-Filter 1225 To obtain Wildcard-Filter service, set FD Count = 1 and 1226 include a single Flow Descriptor whose Filterspec part is 1227 a wild card, i.e., selects all senders. and whose 1228 flowspec part defines the desired flow parameters. 1230 o Fixed-Filter 1232 Include a list of FD Count >= 1 Flow Descriptors, each 1233 defining a sender Filterspec and a corresponding flowspec. 1235 o Dynamic-Filter 1237 Include max(1, FD Count) Flow Descriptors in the message. 1238 Here the FD Count specifies the number of sender 1239 Filterspecs that are included. If DC is the Dynamic 1240 Reservation Count, then DC >= FD Count >= 0. 1242 The Flowspec part of the first Flow Descriptor defines the 1243 desired size of all the DC channels that are reserved. 1244 The Flowspec parts of later Flow Descriptors (if any) are 1245 ignored. 1247 3.1.3 Error Messages 1249 There are two types of RSVP error messages: PERR messages 1250 result from PATH messages and travel towards senders, while 1251 RERR messages result from RESV messages and travel towards 1252 receivers. RSVP error messages are triggered only by 1253 processing of PATH and RESV messages; errors encountered while 1254 processing error or teardown messages must not create error 1255 messages. 1257 A PERR message has the following form: 1259 0 1 2 3 1260 +-------------+-------------+-------------+-------------+ 1261 | Vers | Type | Flags | RSVP Checksum | 1262 +-------------+-------------+-------------+-------------+ 1263 | DestAddress | 1264 +-------------+-------------+-------------+-------------+ 1265 | ResvID | 1266 +-------------+-------------+-------------+-------------+ 1267 | Error Code | Error Index | Error Value | 1268 +-------------+-------------+-------------+-------------+ 1269 | ////////////// (ignored) ////////////////// | 1270 +-------------+-------------+-------------+-------------+ 1271 | ////////////// (ignored) ////////////////// | 1272 +-------------+-------------+-------------+-------------+ 1273 | /// Reserved /// | SD Count | 1274 +-------------+-------------+-------------+-------------+ 1275 | Authentication Field | 1276 // ... // 1277 +-------------+-------------+-------------+-------------+ 1278 | Sender Descriptor List | 1279 // ... // 1280 +-------------+-------------+-------------+-------------+ 1282 The fields are the same as in a PATH message, defined earlier, 1283 except for the following: 1285 RSVP Fields: 1287 RSVPType 1289 3 = PERR message 1291 Error Code 1292 A one-octet error description. 1294 01 = Insufficient memory 1296 02 = Count Wrong 1298 The SD Count field does not match length of 1299 message. 1301 Error Index 1303 Position of Sender Descriptor that caused the error 1304 within 1305 Sender Descriptor List. An integer between zero 1306 and SD Count - 1. 1308 Error Value 1310 (Unused) 1312 A RERR message has the following form: 1314 0 1 2 3 1315 +-------------+-------------+-------------+-------------+ 1316 | Vers | Type | Flags | RSVP Checksum | 1317 +-------------+-------------+-------------+-------------+ 1318 | DestAddress | 1319 +-------------+-------------+-------------+-------------+ 1320 | ResvID | 1321 +-------------+-------------+-------------+-------------+ 1322 | Error Code | Error Index | Error Value | 1323 +-------------+-------------+-------------+-------------+ 1324 | ////////////// (ignored) ////////////////// | 1325 +-------------+-------------+-------------+-------------+ 1326 | ////////////// (ignored) ////////////////// | 1327 +-------------+-------------+-------------+-------------+ 1328 | RecvAddress | 1329 +-------------+-------------+-------------+-------------+ 1330 | Dynamic Reservation Count | FD Count | 1331 +-------------+-------------+-------------+-------------+ 1332 | Authentication Field | 1333 // ... // 1334 +-------------+-------------+-------------+-------------+ 1335 | Flow Descriptor List | 1336 // ... // 1337 +-------------+-------------+-------------+-------------+ 1339 The fields are the same as in a RESV message, defined earlier, 1340 except for the following: 1342 RSVP Fields: 1344 RSVPType 1346 4 = RERR message 1348 Error Code 1350 A one-octet error description. 1352 DEFINE THESE VALUES IN AN APPENDIX?? 1354 01 = Insufficient memory 1356 02 = Count Wrong 1358 The FD Count field does not match length of 1359 message. 1361 03 = No path information for this Resv 1363 04 = No Sender information for this Resv 1365 There is path information, but it does not 1366 include the sender specified in any of the 1367 Filterspecs listed in the Resv messager. 1369 05 = Incorrect Dynamic Reservation Count 1371 Dynamic Reservation Count is zero or less 1372 than FD Count. 1374 06 = Filterspec error 1376 07 = Flowspec syntax error 1378 08 = Flowspec value error 1380 Internal inconsistency of values. 1382 [What should be done with Flowspec Feature 1383 Not Supported?] 1385 09 = Resources unavailable 1387 [Sub-reasons? Depend upon traffic control 1388 and admission control algorithms?] 1390 Error Index 1392 Position of Flow Descriptor that caused the error 1393 within 1394 Flow Descriptor List. An integer between zero 1395 and FD Count - 1. 1397 Error Value 1399 Specific cause of the error described by the Error 1400 Code. 1402 DEFINE THESE VALUES IN AN APPENDIX?? 1404 An error message may be duplicated and forwarded unchanged. 1405 Since PATH and RESV messages may be merged, an error condition 1406 must be disseminated to all RSVP client applications whose 1407 requests may have contributed to the error situation. 1408 Therefore, RSVP error messages must be propagated and perhaps 1409 duplicated hop-by-hop. For this purpose, an error message must 1410 include all the information used to route the original message 1411 that caused the error: the Sender Descriptor List, Flags, 1412 RecvAddress, and Flow Descriptor List fields, as appropriate. 1413 In particular, a RERR message carries the same style flags as 1414 the RESV message that caused the error. 1416 To ease implementation, the error message formats are chosen to 1417 match the formats of the messages whose processing caused the 1418 error. In particular, a PATH or RESV message that encounters 1419 an error can be simply converted to the corresponding error 1420 message by overwriting the Type and the Refresh Period fields. 1422 A PERR message is forwarded to all previous hops for all 1423 senders listed in the Sender Descriptor List. The routing of a 1424 RERR message is more complex. 1426 o An error in a filterspec should be detected at the first 1427 RSVP hop from the receiver application, normally within 1428 the receiver host. However, an error caused by a 1429 flowspec, normally an admission control failure, may be 1430 detected somewhere along the path(s) to the sender(s). 1432 o The router that creates a RERR message as the result of 1433 processing a RESV message should send the RERR message out 1434 the interface through which the RESV arrived. 1436 o In succeeding hops, the routing of a RERR message depends 1437 upon its style. In general, a RERR message is sent on a 1438 pruned version of the multicast distribution tree for the 1439 session; those branches that do not have reservations for 1440 any of the specified senders are pruned off. 1442 A DF-style or WF-style RERR message is forwarded on all 1443 outgoing interfaces for which there is already a 1444 reservation of the corresponding style. 1446 A FF-style RERR message is forwarded on all outgoing 1447 interfaces for which there is already a FF-style 1448 reservation for the sender (filterspec) corresponding to 1449 the error. 1451 At the end host, RSVP delivers a copy of every relevant error 1452 message to its local application clients. It examines the set 1453 of RSVP requests that local clients have made through the API, 1454 and notifies every client that contributed to the error 1455 message. A match is required between the session, filters 1456 (senders), and reservation styles of the error message and the 1457 corresponding state in the latest API requests. A particular 1458 notification should include only the information (e.g., 1459 filters) relevant to that application. 1461 3.1.4 Teardown Messages 1463 There are two types of RSVP Teardown message, PTEAR and RTEAR. 1464 A PTEAR message tears down path state and travels towards all 1465 receivers downstream from its point of initiation. A RTEAR 1466 message tears down reservation state and travels towards all 1467 senders upstream from its point of initiation. 1469 A PTEAR message has the same format as a PATH message, except 1470 that in a PTEAR message: 1472 o Type field = 5 1474 o Refresh Period and State TTL Time fields are ignored. 1476 A RTEAR message has the same format as a RESV message, except 1477 that in a RTEAR message: 1479 o Type field = 6 1481 o Refresh Period and State TTL Time fields are ignored. 1483 Any Flowspec components of Flow Descriptors in a RTEAR or PTEAR 1484 message are ignored. 1486 Teardown messages are processed in the following way. 1488 o PTEAR 1490 Processing a PTEAR message is straightforward. For each 1491 sender S in the message, the node removes path state for S 1492 and also deletes all related reservations. Finally, the 1493 node forwards the original PTEAR message to all outgoing 1494 interfaces through which data packets from some S in the 1495 packet would be routed. That is, PTEAR forwarding rules 1496 are the same as those for PATH messages. 1498 o RTEAR 1499 Processing an RTEAR message is more complex. Suppose a 1500 RTEAR message arrives through outgoing interface OI from 1501 next hop NH. For each sender S listed in the RTEAR 1502 message, the node checks the reservation, if any, for S on 1503 OI. If there is a reservation and if this reservation is 1504 shared among more than one next hop, then the only action 1505 is to remove NH from the list of next hops sharing this 1506 reservation. If there is only a single next hop, then the 1507 reservation is deleted. Finally, the node forwards the 1508 original RTEAR message to all incoming interfaces for 1509 senders listed in the message. That is, RTEAR forwarding 1510 rules are the same as those for RESV messages. 1512 3.2 Avoiding Message Loops 1514 RSVP routes its control messages, and every routing procedure must 1515 avoid looping packets. The merging of RSVP messages delays 1516 forwarding at each node for up to one refresh period. This may 1517 avoid high-speed loop, but there can still be "slow" loops, 1518 clocked by the refresh period; the effect of such slow loops is to 1519 keep state active forever, even if the end nodes have ceased 1520 refreshing it. RSVP uses the following rules to prevent looping 1521 messages. 1523 L1: When an RSVP message is received through a particular 1524 incoming interface F, the message must not be forwarded 1525 out F as an outgoing interface. This implies that RSVP 1526 must keep track of the interface through which each 1527 message is received, to avoid forwarding it out that 1528 interface. Note that, although RSVP distinguishes 1529 incoming from outgoing interfaces, in many cases the 1530 same physical interface will play both roles. 1532 L2: Upon receipt of a PATH message in particular, a route 1533 must be computed for each of its sender Flow 1534 Descriptors. These routes, obtained from the 1535 uni/multicast routing table, generally depend upon the 1536 (sender host address, DestAddress) pairs. Each route 1537 consists of a list of outgoing interfaces; these lists 1538 (with the incoming interfaces deleted by rule L1) are 1539 used to create merged PATH messages to be forwarded 1540 through the outgoing interfaces. 1542 Assuming that multicast routing is free of loops, PATH messages 1543 cannot loop even in a topology with cycles. 1545 Since PATH messages don't loop, they create path state defining a 1546 loop-free path to each sender. Similarly, RESV messages directed 1547 to particular senders cannot loop. However, rules L1 and L2 1548 cannot protect against looping RESV messages that are directed 1549 towards all senders (WF or DF styles). The following three rules 1550 are needed for this purpose. 1552 L3: Each RESV message carries a receiver address in the 1553 RecvAddress field. When the choice of address to place 1554 in a merged RESV message is otherwise arbitrary, RSVP 1555 must use the IP address that is numerically largest. 1557 L4: When a RESV message is received, the Reverse Path 1558 Forwarding rule is applied to the receiver address in 1559 the message; that is, the message must be discarded 1560 unless it arrives on the interface that is the preferred 1561 route to the receiver. 1563 L5: A RESV message whose RecvAddress matches one of the IP 1564 addresses of the local node must be discarded without 1565 processing. 1567 Figure 10 illustrates the effect of the rule L1 applied to RESV 1568 messages. It shows a transit router, with one sender and one 1569 receiver on each side; interfaces a and c therefore are both 1570 outgoing interfaces and physical previous hops. Both receivers 1571 are making a Wildcard-Filter style reservation, in which the RESV 1572 message is to be forwarded to all previous hops for senders in the 1573 group, with the exception of the interface through which it 1574 arrived. 1576 ________________ 1577 a | | c 1578 ( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) 1579 |________________| 1581 Send & Receive on (a) | Send & Receive on (c) 1582 | 1583 WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) 1584 | 1585 WF( *{4B}) --> (a) | (c) --> WF( *{4B}) 1586 | 1587 | 1588 Reserve on (a) | Reserve on (c) 1589 __________ | __________ 1590 | * {4B} | | | * {3B} | 1591 |__________| | |__________| 1592 | 1594 Figure 10: Example: Rule (1) for Preventing Loops. 1596 The loop-suppression rules for RESV messages also prevent looping 1597 of RTEAR messages. Note that RTEAR messages are otherwise subject 1598 to fast loops, since they are not delayed by a refresh timeout 1599 period. 1601 PERR messages are routed upstream by the same rules used for FF 1602 and DF RESV messages (there is no equivalent of wildcard-filter 1603 for routing a PERR message). Similarly, RERR messages are routed 1604 by the rules for PATH messages. For reasons explained above, no 1605 special loop-suppression rules are required in either case. 1607 3.3 Soft State Management 1609 The RSVP state associated with a session in a particular node is 1610 divided into atomic elements that are created, refreshed, and 1611 timed out independently. The atomicity is determined by the 1612 requirement that any sender or receiver may enter or leave the 1613 session at any time, and its state should be created and timed out 1614 independently. 1616 Management of RSVP state is complex because there is not generally 1617 a one-to-one correspondence between state carried in RSVP control 1618 messages and the resulting state in nodes. Due to merging, a 1619 single message contain state referring to multiple stored 1620 elements. Conversely, due to reservation sharing, a single stored 1621 state element may depend upon (typically, the maximum of) state 1622 values received in multiple control messages. 1624 3.3.1 Time Parameters 1626 For each element, there are two time parameters controlling the 1627 maintenance of soft state: the refresh period R and the TTL 1628 (time-to-live) value T. R specifies the period between 1629 successive refresh messages over the same link. T controls how 1630 long state will be retained after refreshes stop appearing. 1632 PATH and RESV messages specify both R and T. When messages are 1633 merged and forwarded to the next hop, R should be the minimum R 1634 that has been received, and T should be the maximum T that has 1635 been received. Thus, the largest T determines how long state 1636 is retained, and the smallest R determines the responsiveness 1637 of RSVP to route changes. In the first hop, they are expected 1638 to be equal. The RSVP API should set a configurable default 1639 value, which can be overridden by an application for a 1640 particular session. 1642 To avoid gaps in user service due to lost RSVP messages, RSVP 1643 should be forgiving about missing refresh messages. A node 1644 should not discard an RSVP state element until K * Tmax has 1645 elapsed without a refresh message, where Tmax is the maximum of 1646 the T values it has received. K is some small integer; K-1 1647 successive messages may be lost before state is deleted. 1648 Currently K = 3 is suggested. 1650 Let X indicate a particular message type (either "Path" or 1651 "Resv") and a particular session. Then each X message from 1652 node a to node b carries refresh period Rab and TTL time Tab. 1654 o As X messages arrive at node b, the node computes and 1655 saves both the min over the Rab values (min(Rab)) and the 1656 max over the Tab values (max(Tab)) from these messages. 1658 o The node uses K * max(Tab) as its cleanup timeout 1659 interval. 1661 o The node uses min(Rab's) as the refresh period. 1663 o Each refresh message forwarded by node b to node c has Tbc 1664 = max(Tab) and Rbc = min(Rab) 1666 o A node may impose an upper bound Tmax and a lower bound 1667 Rmin, set by configuration information, and enforce: Rmin 1668 <= R <= T <= Tmax. 1670 The receiver should be conservative about reacting to certain 1671 error messages. For example, during a route change a receiver 1672 may get back "No Path" error messages until Path messages have 1673 propagated along the new route. 1675 3.3.2 Teardown 1677 Teardown messages, like other RSVP messages, are sent as 1678 datagrams and may be lost (although a QoS is used that should 1679 minimize the chances of congestive loss of RSVP messages). To 1680 increase the reliability of teardown, Q copies of any given 1681 teardown message can be sent. Note that if the iteration count 1682 Q on initiating teardown messages is > 1, then the state cannot 1683 actually be deleted until Q teardowns have been sent. The 1684 state would be placed in a "moribund" status meanwhile. 1686 The appropriate value of Q is an engineering issue. Q = 1 1687 would be the simplest and may be adequate, since unrefreshed 1688 state will time out anyway; teardown is an optimization. Note 1689 that if one or more teardown hops are lost, the router that 1690 failed to receive a teardown message will time out its state 1691 and initiate a new teardown message beyond the loss point. 1692 Assuming that RSVP message loss probability is small (but non- 1693 zero), the longest time to delete state will seldom exceed one 1694 state timeout time K*Tab. 1696 Here is an example. Here G1, G2, G3, and G4 are routers 1697 between a sender S and a receiver R. S initiates a PTEAR 1698 message (denoted by "PT"), but this message is lost between 1699 routers G2 and G3. Since G2 has deleted its state for S, G2 1700 will cease refreshing G3 (though G3 is still refreshing G4, 1701 etc.) 1703 PT PT PT 1704 S ---> G1 ---> G2 -->x G3 G4 R 1706 After a time K*Tab, G3's state will time out, and G3 will 1707 initiate a teardown for S path state: 1709 PT PT 1710 G3 ----> G4 ----> R 1712 If some hop of this chain is lost, there will again be state 1713 timeout to continue the teardown. This process should 1714 terminate in a few timeout periods. 1716 3.3.3 Local Repair 1718 To accommodate merging, RSVP uses hop-by-hop refreshing of 1719 state, where each node sends refreshes to its next/previous 1720 hops periodically. However, as an optimization, local events 1721 could be used to trigger the RSVP module to send such refreshes 1722 to any time. For example, suppose that the local routing 1723 protocol module were able to notify the RSVP module that a 1724 route has changed for particular destinations. The RSVP module 1725 could use this information to trigger an immediate refresh of 1726 state for these destinations along the new route. This would 1727 allow fast adaptation to routing changes without the overhead 1728 of a short refresh period. 1730 3.4 Sending RSVP Messages 1732 Under overload conditions, lost RSVP control messages could cause 1733 the loss of resource reservations. It recommended that routers be 1734 configured to give a preferred class of service to RSVP packets. 1735 RSVP should not use significant bandwidth, but the delay of RSVP 1736 packets needs to be controlled. 1738 An RSVP PATH or RESV message consists of a small root segment (24 1739 or 28 bytes) followed by a list of descriptors. The descriptors 1740 are bulky and there could be a large number of them, resulting in 1741 potentially very large messages. IP fragmentation is inadvisable, 1742 since it has bad error characteristics. Instead, RSVP-level 1743 fragmentation should be used. That is, a message with a long list 1744 of descriptors will be divided into segments that will fit into 1745 individual datagrams, each carrying the same root fields. Each of 1746 these messages will be processed at the receiving node, with a 1747 cumulative effect on the local state. No explicit reassembly is 1748 needed. 1750 The largest RSVP message is 556 bytes. 1752 3.5 Automatic Tunneling 1754 It is impractical to deploy RSVP (or any protocol) at the same 1755 moment throughout the Internet, and RSVP may never be deployed 1756 everywhere. RSVP must therefore provide correct protocol 1757 operation even when two RSVP-capable routers are joined by an 1758 arbitrary "cloud" of non-RSVP routers. 1760 RSVP will automatically tunnel through such a non-RSVP cloud. 1761 Both RSVP and non-RSVP routers forward PATH messages towards the 1762 destination address using their local uni-/multicast routing 1763 table. Therefore, the routing of Path messages will be 1764 unaffected by non-RSVP routers in the path. When a PATH message 1765 traverses a non-RSVP cloud, the copies that emerge will carry as a 1766 Previous Hop address the IP address of the last RSVP-capable 1767 router before entering the cloud. This will cause effectively 1768 construct a tunnel through the cloud for RESV messages, which will 1769 be forwarded directly to the next RSVP-capable router on the 1770 path(s) back towards the source. 1772 This automatic tunneling capability of RSVP has a cost: a PATH 1773 message must carry the session DestAddress as its IP destination 1774 address; it cannot be addressed hop-by-hop. As a result, each 1775 RSVP router must have a small change in its multicast forwarding 1776 path to recognize RSVP messages (by the IP protocol number) and 1777 intercept them for local processing. See Section 3.6.5 below. 1779 (There is a potential defect in tunneling. Merged PATH messages 1780 can carry information for a list of senders, and since multicast 1781 routing depends in general upon the sender, it is not possible to 1782 ensure that all the non-RSVP routers along the tunnel will be able 1783 to route the packet properly. The effect turns out to be that 1784 tunnels may distribute path information to RSVP routers where it 1785 should not go, which may in turn lead to unused reservations at 1786 these routers. This is hoped to be an acceptable defect.) 1788 Of course, if an intermediate cloud does not support RSVP, it is 1789 unable to perform resource reservation. In this case, firm end- 1790 to-end service guarantees cannot be made. However, if there is 1791 sufficient excess capacity through such a cloud, acceptable and 1792 useful realtime service may still be possible. 1794 3.6 Interfaces 1796 3.6.1 Reservation Parameters 1798 All variable-length RSVP parameters use the same general 1799 format. They begin with a length octet followed by a type 1800 octet, and occupy an integral number of fullwords. The length 1801 octet specifies the total length of the parameter in fullwords 1802 or zero to indicate no parameter. An RSVP implementation can 1803 store and pass such parameters as opaque objects. 1805 o Flowspec Format 1807 Flowspec type 1 is specific to the CSZ packet scheduler 1808 [CSZ92]. It has the following format: 1810 +-----------+-----------+-----------+-----------+ 1811 | FlowSLen=6|FlowSType=1| VFoffset | 1812 +-----------+-----------+-----------+-----------+ 1813 | QoS Type (Guaranteed, Predictive, ...) | 1814 +-----------+-----------+-----------+-----------+ 1815 | Max end-to-end delay (ms) | 1816 +-----------+-----------+-----------+-----------+ 1817 | Average data rate (bits/ms) | 1818 +-----------+-----------+-----------+-----------+ 1819 | Token Bucket Depth (bits) | 1820 +-----------+-----------+-----------+-----------+ 1821 | Global Share Handle | 1822 +-----------+-----------+-----------+-----------+ 1824 Flowspec format 2 is defined in RFC-1363 [Partridge92]. 1826 o Filterspec Format 1828 For compactness and simplicity of processing, this version 1829 of the RSVP specification defines an RSVP Filterspec to be 1830 composed of an explicit IP address plus an optional 1831 variable-length mask-and-value pair VF, in the following 1832 format: 1834 +-----------+-----------+-----------+-----------+ 1835 | FiltSLen |FiltSType=1| VFoffset | 1836 +-----------+-----------+-----------+-----------+ 1837 | Sender IP Address | 1838 +-----------+-----------+-----------+-----------+ --- 1839 | V: VF Value Part | Nf 1840 / / octets 1841 / / 1842 +-----------+-----------+-----------+-----------+ --- 1843 | M: VF Mask Part | Nf 1844 / / octets 1845 / / 1846 +-----------+-----------+-----------+-----------+ --- 1848 The value M and the mask V each have length: 1850 Nf = (4*FiltSLen - 8)/2 octets. 1852 M and V define a filter that uses a mask-and-match 1853 algorithm applied to the packet at VFoffset octets from 1854 the beginning of the IP header. The minimum length of 1855 this format of sender template is 7 octets (FiltSLen = 2). 1857 A wildcard Filterspec, which will match any sender host, 1858 has zero for the Sender IP Address [If VM part zero also, 1859 could shorten to FiltSLen = 2]. 1861 To speed RSVP processing, a filterspec that appears in an 1862 RSVP message use the following "canonical form". 1864 o 1865 The high-order octet of the mask M must be non-zero 1866 (this can always be achieved by adjusting VFoffset). 1868 o The (V,M) part must not include either the sender or 1869 receiver address of the IP header; these are carried 1870 explicitly. 1871 ISSUE: 1873 There are many possible filter rules that cannot be 1874 expressed using a simple mask and value pair. A 1875 compact and general filter encoding is for further 1876 study. 1878 o Authenticator Format 1880 The following simple form of authenticator is defined: 1882 +-----------+-----------+-----------+-----------+ 1883 | AuthLen | AuthType=1| | 1884 +-----------+-----------+ + 1885 | Mailbox name: user@domain | 1886 // // 1887 +-----------+-----------+-----------+-----------+ 1889 The rules for merging and interpreting this field require 1890 further study. 1892 3.6.2 Application/RSVP Interface 1894 This section describes a generic API from an application to an 1895 RSVP control process. The details of a real interface may be 1896 operating-system dependent; the following can only suggest the 1897 basic functions to be performed. Some of these calls cause 1898 information to be returned asynchronously. 1900 An application could directly send and receive RSVP messages, 1901 just as an application can do file transfer using UDP. 1902 However, we envision that many applications will not want to 1903 know the details of RSVP operation, nor to provide the timing 1904 services necessary to keep the state refreshed, any more than 1905 an application wants to handle TCP retransmission timeouts. 1906 Therefore, a host using RSVP may have an RSVP control process 1907 to handle these functions. Using local IPC, applications will 1908 register or modify resource requests with this process and 1909 receive notifications of success or change of conditions. 1911 Register 1913 Call: REGISTER( DestAddress, ResvID, SND-flag, RCV-flag, 1914 [, DROP-flag] [, rsvpTTL] [, SenderTemplate] [, flowspec] 1915 [, UserCredentials] ) -> session-id 1917 This call initiates RSVP processing for the session 1918 (DestAddress, ResvID). If successful, the call returns 1919 immediately with a local session identifier "session-id", 1920 which may be used in subsequent calls. Following this 1921 call, an asynchronous ERROR or EVENT call (see below) may 1922 occur at any time. 1924 SND-flag should be set true if the host will send data, 1925 and RCV-flag should be set true if the host will receive 1926 data. Setting neither true is an error. The optional 1927 parameters DROP-flag, rsvpTTL, SenderTemplate, and 1928 Flowspec should be supplied only if SND-flag is true. 1930 DROP-flag indicates that session data packets that do not 1931 match any active filter in some node should be dropped at 1932 that node; otherwise, such packets will be forwarded using 1933 a best-effort QoS. The rsvp-TTL parameter specifies the 1934 IP Time-to-Live field that will be used in PATH messages. 1935 The value of rsvp-TTL should match the TTL field to be 1936 sent in data packets, so they will have the same multicast 1937 scope. 1939 A REGISTER call with SND-flag equals TRUE will initiate 1940 the transmission of PATH messages. 1942 Reserve 1944 Call: RESERVE( session-id, style [, DF-chan-count] 1945 Flowspec-list, Filterspec-list) 1947 A receiver uses this call to make a resource reservation 1948 for the session registered as `session-id'. The style 1949 parameter is an integer index indicating the reservation 1950 style. The DF-chan-count parameter, indicating the number 1951 of Dynamic Filter channels to be reserved, should only be 1952 included if the style is DF. 1954 The first RESERVE call will initiate the periodic 1955 transmission of RESV messages. A later RESERVE call may 1956 be given to modify the parameters of the earlier call (but 1957 note that changing the reservations may result in 1958 admission control failure, depending upon the style). 1960 The RESERVE call returns immediately. Following this 1961 call, an asynchronous ERROR or EVENT call may come at any 1962 time. 1964 Release 1966 Call: RELEASE( session-id ) 1968 This call will terminate RSVP state for the session 1969 specified by session-id. It will send appropriate 1970 "Teardown" messages and cease sending refreshes. 1972 Error Upcall 1974 Call: ERROR( ) -> session-id, error-type, error-code 1975 [, flowspec] [, filterspec] 1977 This upcall may occur asynchronously at any time after a 1978 REGISTER call and before a RELEASE call, to indicate an 1979 error. The allowed values of error-type and error-code 1980 depend on whether the node is sending, receiving, or both. 1982 The ERROR upcall reporting an admission control failure to 1983 a receiver will specify in `flowspec' the flowspec that 1984 actually failed. This may differ from the flowspec 1985 specified by this application in a RESERVE call, due to 1986 upstream merging with reservation requests from other 1987 receivers. 1989 Event Upcall 1991 Call: EVENT( ) -> session-id, info-type, 1992 [, flowspec-list] [, filterspec-list] 1994 This upcall may occur asynchronously at any time after a 1995 REGISTER call and before a RELEASE call, to signal an 1996 event and to pass information to the application. 1998 The `info-type' field indicates one of two possible event 1999 types. A Path event indicates the receipt of a PATH 2000 message, indicating to the application that there is at 2001 least one active sender. A Reservation event indicates 2002 the receipt of a RESV message, indicating to the 2003 application that there is at least one receiver. Although 2004 these messages are repeatedly received, the API should 2005 make the corresponding asynchronous upcall to the 2006 application only on the first event, or when the 2007 information to be reported changes. 2009 ISSUE: 2011 The precise form and function of the flowspec-list and 2012 filterspec-list parameters are to be determined. 2014 3.6.3 RSVP/Traffic Control Interface 2016 In each router and host, enhanced QoS is achieved by a group of 2017 inter-related functions: a packet Classifier, an admission 2018 control module, and a packet scheduler. We group these 2019 functions together under the heading traffic control. RSVP 2020 uses the interfaces in this section to invoke the traffic 2021 control functions. 2023 1. Make a Reservation 2025 Call: Rhandle = TCAddFlow( Flowspec, DropFlag, 2026 [SessionFilterspec [, SenderFilterspec]] ) 2028 Returns an internal handle Rhandle for subsequent 2029 references to this reservation. 2031 This call passes Flowspec to admission control and returns 2032 an error code if Flowspec is malformed or if the requested 2033 resources are unavailable. Otherwise, it establishes a 2034 new reservation channel corresponding to Rhandle, and if 2035 Filterspecs are supplied, installs a corresponding filter 2036 in the classifier. 2038 For FF reservation requests, RSVP knows about sharing and 2039 calls AddFlow only for distinct source pipes. 2041 For DF reservation requests: suppose that the RESV message 2042 specifies a Dynamic Reservation Count = D, and F flow 2043 descriptors, where 0 <= F <= D. Then RSVP calls AddFlow D 2044 times, and D - F of those calls have null filterspecs. 2046 2. Switch a Channel 2048 Call: TCModFilter( Rhandle, [new Filterspec]) 2050 This call replaces the filter without calling admission 2051 control. It may replace an existing filter with no 2052 filter, modify an existing filter, or replace no filter by 2053 a filter. 2055 3. Modify Flowspec 2057 Call: TCModFlowspec( Rhandle, oldFlowspec, newFlowspec) 2059 Here newFlowspec may be larger or smaller than 2060 oldFlowspec. 2062 4. Delete Flow 2064 Call: TCDeleteFlow( Rhandle ) 2066 This call kills the reservation and reduces the reference 2067 count of, and deletes if the count is zero, any filter 2068 associated with this handle. 2070 5. Initialize 2072 Call: TCInitialize( ) 2074 This call is used when RSVP initializes its state, to 2075 clear out all existing classifier and/or packet scheduler 2076 state. 2078 3.6.4 RSVP/Routing Interface 2080 An RSVP implementation needs the following support from the 2081 packet forwarding and routing mechanism of the node. 2083 o Promiscuous receive mode for RSVP messages 2085 Any datagram received for IP protocol 46 is to be diverted 2086 to the RSVP program for processing, without being 2087 forwarded. 2089 o Route discovery 2091 RSVP must be able to discover the route(s) that the 2092 routing algorithm would have used for forwarding a 2093 specific datagram. 2095 GetUCRoute( DestAddress ) -> NextHop, Interface 2097 GetMCRoute( SrcAddress, DestAddress ) -> Interface 2099 o Outgoing Link Specification 2101 RSVP must be able to force a (multicast) datagram to be 2102 sent on a specific outgoing virtual link, bypassing the 2103 normal routing mechanism. A virtual link may be a real 2104 outgoing link or a multicast tunnel. 2106 This is necessary because RSVP may send different versions 2107 of outgoing PATH messages on different interfaces, for the 2108 same source and destination addresses. 2110 o Discover (Virtual) Interface List 2112 RSVP must be able to learn what real and virtual 2113 interfaces exist. 2115 4. ACKNOWLEDGMENTS 2117 Lixia Zhang, Scott Shenker, Deborah Estrin, Dave Clark, Sugih Jamin, 2118 Shai Herzog, Steve Berson, Steve Deering, Bob Braden, and Daniel 2119 Zappala have all made contributions to the design of RSVP. We are 2120 grateful to Jamin, Herzog, and Berson for prototype implementations. 2121 The original protocol concepts for RSVP arose out of discussions in 2122 meetings of the End-to-End Research Group. 2124 REFERENCES 2126 [CSZ92] Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time 2127 Applications in an Integrated Services Packet Network: Architecture 2128 and Mechanisms", Proc. SIGCOMM '92, Baltimore, MD, August 1992. 2130 [ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services 2131 in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and 2132 PARC, June 1994. 2134 [IServ93] Shenker, S., Clark, D., and L. Zhang, "A Service Model for an 2135 Integrated Services Internet", Work in Progress, October 1993. 2137 [Partridge92] Partridge, C., "A Proposed Flow Specification", RFC 1363, 2138 BBN, September 1992. 2140 [RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. 2141 Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, 2142 September 1993. 2144 Security Considerations 2146 As noted in Section 2.1, the ability to reserve resources will create 2147 a requirement for authentication of users who request reservations. 2148 An authentication field has been included in this version of the 2149 protocol spec, but further study on its format and usage will be 2150 required. 2152 Authors' Addresses 2154 Lixia Zhang 2155 Xerox Palo Alto Research Center 2156 3333 Coyote Hill Road 2157 Palo Alto, CA 94304 2159 Phone: (415) 812-4415 2160 EMail: Lixia@PARC.XEROX.COM 2162 Bob Braden 2163 USC Information Sciences Institute 2164 4676 Admiralty Way 2165 Marina del Rey, CA 90292 2167 Phone: (310) 822-1511 2168 EMail: Braden@ISI.EDU 2170 Deborah Estrin 2171 Computer Science Department 2172 University of Southern California 2173 Los Angeles, CA 90089-0871 2175 Phone: (213) 740-4524 2176 EMail: estrin@USC.EDU 2177 Shai Herzog 2179 USC Information Sciences Institute 2180 4676 Admiralty Way 2181 Marina del Rey, CA 90292 2182 Palo Alto, CA 94304 2184 Phone: (310) 822 1511 2185 EMail: Herzog@ISI.EDU 2187 Sugih Jamin 2188 Computer Science Department 2189 University of Southern California 2190 Los Angeles, CA 90089-0871 2192 Phone: (213) 740-6578 2193 EMail: jamin@catarina.usc.edu