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