idnits 2.17.1 draft-birman-ipatm-rsvpatm-00.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-19) 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 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. 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 (22 February 1996) is 10284 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MillikenJul9501' is mentioned on line 315, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-ipatm-ipmc-10 -- Possible downref: Non-RFC (?) normative reference: ref. 'For94' -- Possible downref: Non-RFC (?) normative reference: ref. 'For95' == Outdated reference: A later version (-14) exists of draft-ietf-rolc-nhrp-07 ** Obsolete normative reference: RFC 1577 (ref. 'Lau94') (Obsoleted by RFC 2225) -- No information found for draft-ietf-milliken-ipatm-services - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Mil95' == Outdated reference: A later version (-07) exists of draft-ietf-intserv-guaranteed-svc-03 Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force A. Birman 2 INTERNET DRAFT R. Guerin 3 D. Kandlur 4 IBM 5 22 February 1996 7 Support for RSVP-based Service over an ATM Network 8 draft-birman-ipatm-rsvpatm-00.txt 10 Status of This Memo 12 This document is an Internet-Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months, and may be updated, replaced, or obsoleted by other documents 19 at any time. It is not appropriate to use Internet Drafts as 20 reference material, or to cite them other than as a ``working draft'' 21 or ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the internet-drafts 25 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 Abstract 31 In this document we focus on RSVP-based resource reservations in a 32 heterogeneous environment which includes ATM networks. We describe 33 a method for establishing 'shortcuts' through an ATM network which 34 avoids the performance penalty associated with level 3 processing in 35 a 'classical RSVP over ATM' approach. For the case of guaranteed 36 service we show how to map the RSVP flow characteristics to ATM call 37 parameters, and thus enable end-to-end performance guarantees. We 38 also discuss the extensions to RSVP and to ATM signaling required for 39 the implementation of these solutions. 41 1. Introduction 43 We consider a heterogeneous environment in which legacy networks 44 coexist with ATM networks. For applications that require performance 45 guarantees the reservation of network resources is carried out using 46 RSVP as the reservation setup protocol. The operation of RSVP over 47 an ATM network is the focus of our paper. 49 Our starting point is the classical IP over ATM model [Lau94] in 50 which an ATMARP server is used for address resolution within a LIS, 51 while the inter-LIS traffic is routed through IP routers. For 52 an application with QoS requirements the classical IP over ATM 53 architecture does allow for QoS support over the VCCs between the 54 routers. This solution is not altogether satisfactory, however, 55 since it may not provide the QoS which would be possible if a direct 56 VCC through the ATM network was established along the path through 57 the ATM network. Such a direct connection, first proposed in [Mil95] 58 and referred to as a 'shortcut', eliminates the level 3 processing at 59 the routers and thus allows better performance. We describe below 60 a method to establish such shortcuts over ATM networks, first for 61 unicast and then multicast application flows (for additional details 62 see [BFG+95]). We refer to this approach as 'classical RSVP over ATM 63 with shortcuts'. 65 The approach described here has, without doubt, shortcomings. Some 66 of these can be traced to the differences between RSVP and ATM 67 signaling ([For94],[For95]), and their opposing design principles. 68 This approach is offered as a possible first step in supporting QoS 69 flows in a heterogeneous environment with ATM networks. If adopted 70 and carried through to implementation, the experience thus gathered 71 may be beneficial in the design of a better next scheme. 73 2. Reservation setup for unicast flows 75 We first consider unicast flows. The parameters necessary for 76 setting up VCCs with QoS guarantees are obtained from RSVP messages 77 Path and Resv. 79 2.1. Classical RSVP over ATM 81 Figure 1 shows an ATM network consisting of four LISs. A is the 82 ingress router to the ATM network, B is the egress router. RSVP 83 messages follow the IP route AEFGB. Thus, a Path message will 84 travel downstream from A to B, while the corresponding Resv message 85 will travel upstream from B to A. When the Resv message arrives at 86 G the router has sufficient information to set up a VC from G to B. 88 Similarly, VCs will be set up from F to G, from E to F, and from A 89 to E. 91 In particular, if the ATM network consists of a single LIS then the 92 route from A to B has only one hop, although there could be multiple 93 hops at the ATM level. 95 For the multi-hop case, while RSVP messages travel over best-effort 96 VCs, data packets flow over QoS VCs and enjoy QoS support in 97 the routers. Traversing the routers, however, entails IP-level 98 processing and thus is less desirable than a shortcut VC from A to 99 B. In the rest of this section we discuss several schemes for RSVP 100 support using ATM shortcuts. 102 2.2. ATM shortcuts 104 In this scheme, we modify the RSVP operation in order to identify 105 the appropriate egress router for the purpose of establishing a 106 shortcut route through the ATM network. When the first Path message 107 for a session arrives at A (Figure 2), the node determines that the 108 message will be forwarded over an ATM link and thus node A is the 109 ingress node into the ATM network. The Path message is routed along 110 the default IP route, and is modified to carry both the ATM address 111 and the IP address of A (the IP address of A is the `previous hop' 112 or PHOP). At each node along the route an ATM connectivity check 113 is performed to determine whether the current node is the egress 114 point from the ATM network. This decision would be based on the ATM 115 connectivity between the current router, the upstream router, and the 116 downstream router as determined by the logical ATM network in which 118 +-+ +-+ +-+ +-+ +-+ 119 --->|A|------>|E|------>|F|------>|G|------>|B|---> 120 +-+ +-+ +-+ +-+ +-+ 122 LIS 1 LIS 2 LIS 3 LIS 4 123 <-------> <-------> <-------> <-------> 125 ATM network 126 <--------------------------------------> 128 Figure 1: Reservation setup using ``classical'' RSVP support 130 they reside (the concept of the logical ATM network as described in 131 [KP95]). If the current router is not an egress router, it forwards 132 the Path message to the downstream router without updating the PHOP 133 address field. If the current router is an egress router (e.g. 134 B) it processes the Path message by creating a Path state for the 135 session and by storing, along with other data, the IP address and the 136 ATM address of A. 138 A Resv message is considered new when it represents either a 139 reservation requests for a new flow or a request to modify the 140 reservation of an existing flow. When such a Resv message arrives 141 at B, B inserts its own ATM address as an object into this message, 142 and forwards the message along the default routed path to A. 143 Intermediate routers recognize the Resv message but do not create 144 any session or reservation and simply forward the message upstream. 145 When this Resv message arrives at A it carries in addition to the 146 regular RSVP information, both the ATM address of the egress router 147 B and QoS information necessary to determine the type of ATM VC that 148 needs to be setup. 150 Since intermediate nodes do not need to process the Resv message, 151 an alternative here is to encapsulate the Resv message into an IP 152 datagram that is then tunneled from B to A. Tunneling provides 153 the advantage that packet processing is expedited (along the 154 fast-path through the router) since there is no special processing at 155 intermediate nodes. On the other hand, the packet is not treated as 156 a signaling packet and is susceptible to normal loss at intermediate 157 nodes. 159 After the shortcut VC from A to B is set up, B needs to be able 160 to associate the newly created VC with the RSVP flow. In order to 161 achieve this, the flow identifier consisting of the tuple 163 (sourceIPaddress;destinationIPaddress; transportlayer) 165 is carried in the SETUP message in the Broadband High Layer 166 Information (B-HLI) element (the length of this field would have 167 to be extended from its current size of 8 bytes). The source and 168 destination IP addresses cannot be inferred from the ATM addresses 169 in the router--router case. The source and destination addresses 170 themselves further consist of pairs of the form 172 (IPaddress;portnumber): 174 Note also that the receipt of the SETUP message provides an implicit 175 acknowledgment that the Resv message was received at router A. 176 This means that router A also has received all the information 177 necessary to forward Resv messages upstream, i.e. the RSVP filter 178 and service specifications that are not directly available from the 179 ATM connection characteristics. As a result, the egress router B 180 now suppresses the transmission of Resv refreshes towards router A, 181 unless they carry a modified service specification. 183 Figure 2 shows a shortcut VC from A to B which bypasses nodes E, 184 F and G. The shortcut VC is used for the RSVP data traffic, but 185 Path messages continue to flow along the default routed path. It is 186 noted that this scheme for creating shortcut routes is independent of 187 the underlying routing mechanism and is oblivious to any IP routing 188 domain boundaries. Moreover, RSVP state is required only in the edge 189 routers A and B. 191 A possible variation to the method described above handles Path 192 messages the same way, but differs from it in that it shifts the 193 responsibility of establishing the ATM shortcut VC from the ingress 194 router A to the egress router B (see Figure 2). This is possible 195 because ATM unicast calls are always duplex, and resources can be 196 reserved in both directions. 198 Specifically, when a Resv message arrives at the egress router B, 199 B can generate a SETUP message towards A and specify the resources 200 required in both directions. The SETUP message will specify QoS 201 requirements in the direction A to B to accommodate the service 202 specifications carried in the Resv message. Conversely, it will not 203 request any QoS or bandwidth guarantees from B to A since there is 204 no data flow in this direction. While the VC setup is now handled by 205 the egress router, it is still necessary to forward the Resv message 207 +-+ +-+ +-+ +-+ +-+ 208 --->|A|------>|E|------>|F|------>|G|------>|B|---> 209 +-+ +-+ +-+ +-+ +-+ 210 : : 211 : VC : 212 ....................................... 214 ATM network 215 <--------------------------------------> 217 Figure 2: Reservation setup using ATM shortcuts 219 to the ingress router, so that it can propagate that information 220 upstream (it cannot be accurately inferred for the traffic and QoS 221 parameters carried in the SETUP message). In order to do that, 222 Resv messages including refreshes for reliability purposes, will 223 keep on being forwarded onto the IP route. However, as with the 224 previous method, they are not acted upon at intermediate routers. 225 Another alternative is to include the Resv message as higher layer 226 information in the SETUP message. 228 The main advantage of this scheme is that it is consistent with the 229 preferred solution for multicast flows when the LIJ capability of UNI 230 4.0 becomes available (see Section 3.2 for details). 232 3. Reservation setup for multicast flows 234 We consider two methods for establishing shortcuts through an ATM 235 network. The ``root-initiated ATM shortcut'' is better suited to 236 the present UNI 3.1 environment, while the ``leaf-initiated ATM 237 shortcut'' would be preferred when the leaf-initiated join capability 238 of UNI 4.0 becomes available. 240 3.1. Root-initiated ATM shortcuts 242 We start by extending the unicast scheme of Section 2.2 to 243 single-sender multicast flows, as illustrated in Figure 3. As 244 mentioned before, this is the approach best suited to a UNI 3.1 245 environment. The determination of the ATM shortcut follows the same 246 steps as in Section 2.2. When a Path message for a session arrives 247 at node A, the node determines that the message will be forwarded 248 over an ATM link and thus node A is the ingress node into the ATM 249 network (note that this step only needs to be performed upon receipt 250 of the first Path message). The ATM address of A is inserted as an 251 object into the Path message, which is fowarded onto the default IP 252 route. In addition, a mechanism such as MARS [Arm95] is used for 253 local multicast delivery on this path. 255 At each node along the route an ATM connectivity check is again 256 performed to determine whether the current node is an egress point 257 from the logical ATM network. If the current node, such as F in 258 Figure 3, is not an egress point then the Path message is forwarded 259 to the downstream nodes without updating the PHOP (previous hop) 260 address field. 262 When the first Resv message arrives at an egress point, say B, B 263 forwards the message along the reverse path to A. The ATM address 264 of B is carried as an object in the Resv message. Intermediate 265 +-+ +-+ +-+ +-+ 266 --->|A|------>|E|------>|F|----------->|B|---> 267 +-+ +-+ +-+ +-+ 268 | 269 | +-+ 270 +---------------------->|C|---> 271 +-+ 273 ATM network 274 <----------------------------------> 276 Figure 3: Reservation setup with maximum shortcut 278 routers, F and E in this case, simply forward the message upstream 279 towards A. Specifically, they do not merge Resv messages and do 280 not perform any reservation. As in the unicast case, an alternative 281 is to tunnel the Resv message directly to A by encapsulating it 282 into an IP message. When the first Resv message arrives at A, say 283 from B, A has all the information necessary to create a shortcut 284 point-to-multipoint VC with root A and leaf B. In order for B 285 to associate the newly created VC with the RSVP flow, the flow 286 identifier consisting of the pair 288 (sourceIPaddress; destinationIPaddress) 290 is carried in the SETUP message in the Broadband High Layer 291 Information (B-HLI) element. Later, when the Resv message from C 292 arrives at A, A adds C to the point-to-multipoint VC with an ADD 293 PARTY signaling message. The ADD PARTY message will also carry the 294 flow identifier in the B-HLI element. 296 In order to track route changes and changes in group membership, 297 Path refresh messages keep flowing normally over the IP route. 298 However, Resv refreshes from each router are suppressed as soon 299 as the egress router receives the ATM setup message (ADD PARTY 300 or SETUP for the first leaf). This is because the setup message 301 indicates that the initial Resv message has been received by the 302 ingress router, and that the reservation through the ATM network has 303 been successfully performed. This suppression prevents the steady 304 state implosion of refresh Resv messages at the ingress router. 306 However, the ingress router is still required to perform as many ATM 307 connection SETUPs as there are leaves in the ATM network for the 308 multicast address. This is because, the scheme always results in 309 the use of a ``maximum'' ATM shortcut between the ingress and egress 310 routers. The use of a maximum shortcut minimizes IP-level processing 311 at intermediate nodes and thus shortens end-to-end packet delays, 312 but the (signaling) load imposed on the ingress router may become a 313 problem when dealing with large multicast groups. 315 Milliken [MillikenJul9501] proposed a scheme which is intended to 316 alleviate the problem by distributing the (signaling) processing 317 load among the routers. This load distribution is achieved by 318 allowing some flexibility at each router on deciding whether or not 319 to extend an ATM shortcut. A more promising and systematic approach 320 to eliminate the possibility of signaling overload at the ingress 321 router, it to use the Leaf-Initiated Join (LIJ) capability of of UNI 322 4.0. We discuss such a solution in the next section. 324 3.2. Leaf-initiated ATM shortcuts 326 Consider the ATM network in Figure 3 and assume the flow of Path 327 messages is as described in the previous section. That is, Path 328 messages continue to use the default IP routed path, and a mechanism 329 such as MARS is used for local multicast delivery on this path. 330 As before, the Path message processing at intermediate routers is 331 changed, in that the PHOP is not modified, while the Path message 332 carries the ATM address of A. In addition, A also chooses a 333 ``global connection identifier'' (GCID) and inserts it into the 334 Path message. This global connection identifier consists of a 335 call identifier uniquely chosen by the root, which is paired with 336 the root's ATM address for LIJ setup. For a given RSVP session, 337 there may be multiple flows transiting through A and, for each 338 flow, A would choose a distinct global connection identifier. This 339 connection identifier will be used by egress routers when generating 340 an ATM LIJ request to join the point-to-multipoint connection 341 associated with the IP multicast address. 343 When the first Resv message reaches an egress router, say B, the 344 router has all the information needed for generating an LIJ request 345 to the GCID it received. The ATM point-to-multipoint connection is 346 then created at this time, with the ingress router A as its root 347 and B as the first leaf. As other egress routers, such as C in 348 Figure 3, also receive their first Resv message, they signal their 349 intention to join the connection in exactly the same manner, i.e. 350 through a LIJ request to the specified GCID. They are then added as 351 new leaves to the existing point-to-multipoint connection, but the 352 ingress router A is not notified of this new join. This eliminates 353 the potential processing overload at router A since it is only 354 required to handle a single signaling request, i.e. when the first 355 leaf joins. 357 However, note that as a result of not notifying the ingress router 358 of new leaves joining, the information carried in the Resv messages 359 arriving at the associated egress routers is not forwarded to the 360 ingress router during the ATM setup process. This information is, 361 however, necessary for the ingress router to further propagate Resv 362 messages upstream, i.e. it needs information elements such as the 363 RSVP service and filter specifications, which as mentioned before 364 cannot always be directly inferred from the ATM traffic and QoS 365 parameters. In order to achieve this, Resv messages, including 366 refreshes, will continue to be propagated and merged on the IP 367 path, but no reservation will be triggered at intermediate routers. 368 The merging on the IP path ensures that the ingress router is not 369 overwhelmed by the volume of refresh Resv messages it receives, 370 while providing it with all the information it needs to forward Resv 371 messages to its upstream neighbor. Note that even refreshes are sent 372 in order to ensure reliable delivery of Resv messages to the ingress 373 router. 375 4. Issues Related to Flow/Call Characteristics 377 The previous sections have dealt with many of the issues related to 378 the mapping between RSVP and ATM control flows. In this section, 379 we focus on similar problems but at the level of the data flows. 380 Specifically, we consider issues related to the mapping of traffic 381 parameters and QoS guarantees as well as connection types. 383 4.1. Flow mapping 385 RSVP defines a session as the set of data flows with the same 386 (unicast or multicast) destination. As a result, at an endpoint of a 387 flow (sender or receiver) the data flow is uniquely identified by the 388 pair 389 (sourceIPaddress;destinationIPaddress): 390 The source and destination addresses themselves further consist of 391 pairs of the form 392 (IPaddress;portnumber); 393 where the destination IP address can be a multicast IP address. 395 The ATM UNI identifies a connection through the Connection Identifier 396 used in the SETUP, CONNECT, etc. messages. Connection Identifier is 397 associated to an ATM flow from one sender to one or more receivers 398 and is unique at the sender. A call can be uniquely identified 399 in the ATM network by the pair (Connection Identifier, sender ATM 400 address). Similarly, in ATM UNI 4.0 which introduces the Leaf 401 Initiated Join (LIJ) capability, each LIJ capable call is uniquely 402 identified by a Global Call Identifier (GCID). The GCID is formed by 403 pairing the LIJ call identifier selected by the the ``ROOT'' of the 404 call (point-to-multipoint connection) and the address of the ROOT 405 itself. Network wide uniqueness is, therefore, ensured. 407 From the above discussion, we see that a node at the boundary between 408 IP and ATM networks can map the quadruplet (source IP address, source 409 port number, destination IP address, destination port number) that 410 uniquely identifies an RSVP flow, to an ATM GCID consisting of (call 411 identifier, sender ATM address). 413 4.2. Traffic and QoS handling 415 Traffic and QoS specifications are not defined in RSVP. They are 416 deferred to the int-serv IETF draft documents. The Guaranteed Delay 417 int-serv draft [SP95] defines the traffic specification (TSpec) as 418 consisting of a token bucket with a given bucket depth b (in bytes) 419 specifying the maximum allowed burst size for the flow, a bucket rate 420 r (in bytes/second) giving the average rate of the flow, and a peak 421 rate p (in bytes/second) giving the maximum transmission rate of the 422 flow at the source. This traffic specification can be mapped into 423 the corresponding ATM traffic parameters, which are specified in 424 cell-based measures. 426 [SP95] defines the service specification (RSpec), and a procedure 427 that describes how the RSpec is determined as a function of the 428 delay requirements of the flow and the capabilities of the service 429 elements (routers) on its path. The end-to-end delay d and the 430 associated service specifications for the flow are not quantities 431 that are initially provided explicitly. Rather, they are determined 432 at the receiver upon receipt of the Path message carrying the values 433 of the ``error terms'' Ctot= Sum Ci and Dtot = Sum Di, which have 434 been accumulated on the connection's path. The terms Ci and Di 435 correspond to the error contributed by router i when compared to a 436 perfect fluid service model. 438 The RSVP and Int-Serv documents suggest that the resource reservation 439 for a flow from S to D with guaranteed delay requirement is 440 performed in the following way. The source S generates Path 441 messages that contain the traffic characterization (TSpec)of the 442 flow. The Path message, therefore, includes the parameters b, r, p, 443 and two fields Ctot and Dtot which are both initialized to 0. At 444 router i, these fields are incremented using the local values Ci and 445 Di: 446 Ctot:= Ctot+Ci; Dtot:= Dtot+ Di 447 At the receiver D, a desired end-to-end delay d is selected, and the 448 required clearing rate R is computed as: 450 R = max(r, ((b + Ctot) / (d - Dtot))) 452 The clearing rate R is then loaded in the RSpec included in the Resv 453 message sent towards S. 455 A key aspect of the above approach, that complicates the interactions 456 with ATM is the decoupling between the advertising (accumulation of 457 Ctot and Dtot as the Path message progresses) and the reservation 458 phases (request for allocation of the clearing rate R). The main 459 issue at the boundary of an ATM network is to determine which values 460 to select for the terms CATM and DATM, when updating the Ctot and 461 Dtot fields in the Path message. Also, delay guarantees based on 462 the specification of a clearing rate may not always be supported by 463 ATM switches and can not be readily expressed through ATM signaling. 464 Hence, the ATM network has to be accounted for as a fixed delay 465 component of the path. This requires information about (a) the 466 ingress and egress points (routers) of the ATM network, (b) a delay 467 bound, DATM, on the flow between the ingress and egress points. 469 The first item is available at the egress point as the Path message 470 exits from the ATM network (as outlined in Section 2.2). The 471 second item may be obtained by the egress router by querying the 472 ATM network to find the best delay that can be guaranteed for a 473 flow with the specific endpoints. While this information is not 474 currently accessible over an ATM UNI, it is available as part of 475 the ATM PNNI control information. The egress router would then be 476 responsible for updating the Ctot and Dtot fields as the Path message 477 exits from the ATM network (intermediate routers would leave these 478 fields unmodified). This mechanism for updating the advertizement 479 information at the egress points is consistent for both unicast and 480 multicast flows. 482 5. Impact on RSVP and ATM signaling 484 In this document we proposed a method for supporting RSVP-based 485 resource reservations in a heterogeneous environment which includes 486 ATM networks. This method, classical RSVP over ATM with shortcuts, 487 requires a number of modifications to RSVP and to ATM signaling. We 488 review here these requirements. 490 5.1. Modifications to RSVP in the UNI 3.1 environment 492 In this environment, the general approach we take can be 493 characterized as root oriented. This means that most of the 494 interactions with the ATM signaling needed to extend RSVP flows 495 across ATM networks, originate in the ingress router. Such 496 extensions require a number of modifications to the processing of 497 Path and Resv messages. 499 The first step at the ingress router is to identify that the 500 flow is to cross an ATM network and should, therefore, be handled 501 differently. Once this has been determined, subsequent modifications 502 to the Path message handling vary somewhat as a function of the 503 approach used. Typically, the Path message will be forwarded on 504 the normal IP path, and extended to carry the ATM address of the 505 ingress router. Path processing is also different at intermediate 506 (non-egress) routers which do not update the PHOP field, so that 507 it still points to the ingress router, and do not maintain state 508 information. This helps lower the processing overhead for such 509 messages. In addition, the Dtot field (and Ctot) is not updated 510 until the Path message reaches the egress router(s), where it is 511 incremented by an estimate of the maximum delay the ATM network would 512 contribute. Path messages continue flowing on the IP route even 513 after an ATM VC shortcut has been established for the flow. 515 The processing of Resv messages is also affected when crossing ATM 516 networks. They are used to trigger the establishment of an ATM 517 shortcut when received at an egress router(s). The connection 518 request originates from the ingress router (ADD-PARTY for multicast 519 flows, or SETUP for unicast flows) upon receipt of a new Resv message 520 from an egress router. This Resv message carries the standard 521 RSVP information, i.e. filter and service specifications, that 522 are needed by the ingress router to forward Resv messages to its 523 upstream neighbor. The Resv message also contains the ATM address 524 of the egress router as well as the delay guarantees needed for the 525 connection across the ATM network. Note that the receipt of the 526 SETUP (or ADD-PARTY for multicast flows) at an egress router provides 527 an implicit acknowledgment that the ingress router has received 528 the Resv message and that the ATM reservation has been successful. 529 Finally, refresh Resv messages are suppressed, i.e. not forwarded on 530 the IP path, and connection liveness is guaranteed by ATM mechanisms. 532 5.2. Modifications to RSVP in the UNI 4.0 environment 534 The major enhancement in UNI 4.0, from the point-of-view of RSVP 535 support, is the LIJ ability in point-to-multipoint connections. This 536 allows us to use a leaf oriented approach to support RSVP flows (both 537 unicast and multicast) which ensures better scalability. 539 The handling of Path messages remain essentially as for the UNI 540 3.1 case, in that they are forwarded on the normal IP path but not 541 processed at intermediate routers, i.e. PHOP field and OPWA objects 542 are not modified and no state is created. In addition to carrying 543 the ATM address of the ingress router, the Path message also carries 544 a global ATM call identifier (GCID) in the case of multicast flows. 545 This GCID is then specified in the LIJ message generated by egress 546 routers upon receipt of a new Resv message, when they want to join 547 an existing point-to-multipoint connection associated with a given 548 multicast flow. In the case of a unicast flow, the egress router 549 simply initiates a SETUP to the ATM address of the ingress router. 551 Because in the leaf oriented approach the egress routers are 552 responsible for the establishment of ATM connections, it is not 553 necessary to forward Resv messages to the ingress router for that 554 purpose. However, it is still necessary to transmit the RSVP 555 information contained in the Resv message (filter and service 556 specifications) to the ingress router, so that it can propagate 557 it upstream. This is achieved by forwarding all Resv messages 558 (including refreshes for reliability) on the IP route to the 559 ingress router. Note that although Resv messages are processed at 560 intermediate routers they are not acted upon, i.e. merging of Resv 561 messages will take place when required but no reservations will be 562 triggered and no state is maintained. 564 5.3. Modifications and extensions to ATM signaling 566 As stated above, it is clear that many of the extensions to be 567 included in UNI 4.0 are key to an efficient support of RSVP flows 568 across ATM networks. Foremost among them is the LIJ capability, 569 which is critical to handle large multicast connections. This 570 capability should, however, be such that different leaves are 571 allowed to specify different service requirements. Other desirable 572 extensions to be included in UNI 4.0 are the ability to renegotiate 573 the characteristics of an established connection, and a B-HLI field 574 larger than its current 8 bytes. 576 There are, however, other desirable extensions which may not be 577 provided in UNI 4.0. One such example, is the ability for an RSVP 578 router to query the ATM network for the best delay that can be 579 guaranteed to a given destination. This can be achieved either by 580 allowing ``soft'' requests, or by supporting both ``desired'' and 581 ``acceptable'' QoS parameters. As a second example, the ability to 582 let the root of a point-to-multipoint call assign a GCID even before 583 any leaf has requested to join, could simplify some of the processing 584 when establishing such calls. 586 6. References 588 [Arm95] G. Armitage, "Support for Multicast over UNI 3.1 based ATM 589 Networks", Internet Draft, draft-ietf-ipatm-ipmc-10.txt, December 590 1995. 592 [BFG+95] A. Birman, V. Firoiu, R. Guerin and D. Kandlur, 593 "Provisioning of RSVP-based Services over a Large ATM Network", IBM 594 Research Report RC20250, October 1995. 596 [BZB+96] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, 597 "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional 598 Specification", Internet Draft, draft-ietf-rsvp-spec-09.txt, February 599 1996. 601 [For94] ATM Forum, "ATM User-Network Interface Specifications, 602 Version 3.1", September 1994. 604 [For95] ATM Forum, "ATM User-Network Interface Specifications, 605 Version 4.0", ATM Forum/94-1018. 607 [KP95] D. Katz and D. Piscitello, "NBMA Next Hop Resolution Protocol 608 (NHRP)", Internet Draft, draft-ietf-rolc-nhrp-07.txt, December 1995. 610 [Lau94] M. Laubach, "Classical IP and ARP over ATM", Internet Draft, 611 Internet RFC1577, January 1994. 613 [Mil95] W. Milliken, "Integrated Services IP Multicasting over ATM", 614 Internet Draft, draft-ietf-milliken-ipatm-services-00.txt, July 1995. 616 [SP95] S. Shenker and C. Partridge, "Specification of Guaranteed 617 Quality of Service", Internet Draft, draft-ietf-intserv-guaranteed- 618 svc-03.txt, December 1995. 620 7. Authors' Address 622 Alex Birman 623 T. J. Watson Research Center 624 IBM Corporation 625 30 Saw Mill River Rd. 626 Hawthorne, NY 10532 628 Phone: +1-914-784-7275 629 E-mail: birman@watson.ibm.com 631 Roch Guerin 632 T. J. Watson Research Center 633 IBM Corporation 634 30 Saw Mill River Rd. 635 Hawthorne, NY 10532 637 Phone: +1-914-784-7038 638 E-mail: guerin@watson.ibm.com 640 Dilip Kandlur 641 T. J. Watson Research Center 642 IBM Corporation 643 30 Saw Mill River Rd. 644 Hawthorne, NY 10532 646 Phone: +1-914-784-7722 647 E-mail: kandlur@watson.ibm.com