idnits 2.17.1 draft-ietf-issll-atm-imp-req-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-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 18 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([6], [9], [11]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 146: '... implementations MUST be able to recei...' RFC 2119 keyword, line 147: '...both QoS and best-effort VCs, and MUST...' RFC 2119 keyword, line 159: '...hat sub-net senders MUST establish all...' RFC 2119 keyword, line 160: '...abled sub-net receiver MUST be able to...' RFC 2119 keyword, line 183: '... implementations MAY send data in the ...' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In RSVP over ATM implementations, the configurable inactivity timer mentioned in [14] MUST be set to "infinite" for VCs initiated at the request of RSVP. Setting the inactivity timer value at the VC initiator should not be problematic since the proper value can be relayed internally at the originator. Setting the inactivity timer at the VC receiver is more difficult, and would require some mechanism to signal that an incoming VC was RSVP initiated. To avoid this complexity and to conform to [15], RSVP over ATM implementations MUST not use an inactivity timer to clear any received connection. -- 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 (July 11, 1997) is 9776 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '13' is defined on line 543, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-03) exists of draft-ietf-issll-atm-support-02 -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 1483 (ref. '12') (Obsoleted by RFC 2684) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft L. Berger 2 Expires: January 1998 FORE Systems 3 File: draft-ietf-issll-atm-imp-req-00.txt 5 RSVP over ATM Implementation Requirements 7 July 11, 1997 9 Status of Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 Abstract 29 This note presents specific implementation requirements for running 30 RSVP over ATM switched virtual circuits (SVCs). It presents 31 requirements that ensure interoperability between multiple 32 implementations and conformance to the RSVP and Integrated Services 33 specifications. A separate document [6] provides specific guidelines 34 for running over today's ATM networks. The general problem is 35 discussed in [11]. Integrated Services to ATM service mappings are 36 covered in [9]. The full set of documents present the background and 37 information needed to implement Integrated Services and RSVP over 38 ATM. 40 Table of Contents 42 1. Introduction ........................................................3 43 1.1 Terms ...........................................................3 44 1.2 Assumptions .....................................................4 45 2. General RSVP Session Support ........................................4 46 2.1 VC Usage ........................................................4 47 2.2 VC Initiation ...................................................5 48 2.3 VC Teardown .....................................................5 49 2.4 Dynamic QoS .....................................................6 50 2.5 Encapsulation ...................................................7 51 3. Multicast RSVP Session Support ......................................7 52 3.1 Data VC Management for Heterogeneous Sessions ...................7 53 3.2 Multicast End-Point Identification ..............................9 54 3.3 Multicast Data Distribution .....................................10 55 3.4 Receiver Transitions ............................................11 56 4. Security ............................................................12 57 5. Acknowledgments .....................................................12 58 6. Author's Address ....................................................12 59 1. Introduction 61 This note discusses running IP over ATM in an environment where SVCs 62 are used to support QoS flows and RSVP is used as the internet level 63 QoS signaling protocol. It applies when using CLIP/ION, LANE2.0 and 64 MPOA[4] methods for supporting IP over ATM. The general issues 65 related to running RSVP[10] over ATM have been covered in several 66 papers including [11,7,5,8]. This document is intended as a 67 companion to [11,6]. The reader should be familiar with both 68 documents. 70 This document will define specific requirements for implementations 71 using ATM UNI3.x and 4.0. These requirements must be adhered to by 72 all RSVP over ATM implementations to ensure interoperability. 73 Further recommendations to guide implementers of RSVP over ATM are 74 provided in [6]. 76 The rest of this section will define terms and assumptions. Section 2 77 will cover implementation guidelines common to all RSVP session. 78 Section 3 will cover implementation guidelines specific to multicast 79 sessions. 81 1.1 Terms 83 The terms "reservation" and "flow" are used in many contexts, 84 often with different meaning. These terms are used in this 85 document with the following meaning: 87 o Reservation is used in this document to refer to an RSVP 88 initiated request for resources. RSVP initiates requests for 89 resources based on RESV message processing. RESV messages 90 that simply refresh state do not trigger resource requests. 91 Resource requests may be made based on RSVP sessions and RSVP 92 reservation styles. RSVP styles dictate whether the reserved 93 resources are used by one sender or shared by multiple 94 senders. See [10] for details of each. Each new request is 95 referred to in this document as an RSVP reservation, or 96 simply reservation. 98 o Flow is used to refer to the data traffic associated with a 99 particular reservation. The specific meaning of flow is RSVP 100 style dependent. For shared style reservations, there is one 101 flow per session. For distinct style reservations, there is 102 one flow per sender (per session). 104 1.2 Assumptions 106 The following assumptions are made: 108 o RSVP We assume RSVP as the internet signalling protocol which 109 is described in [10]. The reader is assumed to be familiar 110 with [10]. 112 o IPv4 and IPv6 RSVP support has been defined for both IPv4 and 113 IPv6. The guidelines in this document are intended to be 114 used to support RSVP with either IPv4 or IPv6. This document 115 does not require one version over the other. 117 o Best effort service model The current Internet only supports 118 best effort service. We assume that as additional components 119 of the Integrated Services model that best effort service 120 will continue to be a supported. 122 o ATM UNI 3.x and 4.0 We assume ATM service as defined by UNI 123 3.x and 4.0. ATM provides both point-to-point and point-to- 124 multipoint Virtual Circuits (VCs) with a specified Quality of 125 Service (QoS). ATM provides both Permanent Virtual Circuits 126 (PVCs) and Switched Virtual Circuits (SVCs). In the 127 Permanent Virtual Circuit (PVC) environment, PVCs are 128 typically used as point-to-point link replacements. So the 129 support issues are similar to point-to-point links. This 130 draft assumes that SVCs are used to support RSVP over ATM. 132 2. General RSVP Session Support 134 This section provides implementation requirements that are common for 135 all (both unicast and multicast) RSVP sessions. The section covers 136 VC usage, QoS VC initiation, VC teardown, handling requested changes 137 in QoS, and encapsulation. 139 2.1 VC Usage 141 There are several options open to implementations on which VC to 142 use for RSVP messages and how to aggregate RSVP sessions over QoS 143 VCs. These options have been covered in [11] and some specific 144 implementation guidelines are stated in [6]. In order to ensure 145 interoperability between implementations that follow different 146 options, RSVP over ATM implementations MUST be able to receive 147 RSVP (control) messages on both QoS and best-effort VCs, and MUST 148 be able to receive multiple RSVP sessions per QoS VC. 150 2.2 VC Initiation 152 There is an apparent mismatch between RSVP and ATM. Specifically, 153 RSVP control is receiver oriented and ATM control is sender 154 oriented. This initially may seem like a major issue but really 155 is not. While RSVP reservation (RESV) requests are generated at 156 the receiver, actual allocation of resources takes place at the 157 sub-net sender. 159 For data flows, this means that sub-net senders MUST establish all 160 QoS VCs and the RSVP enabled sub-net receiver MUST be able to 161 accept incoming QoS VCs. These restrictions are consistent with 162 RSVP version 1 processing rules and allow senders to use different 163 flow to VC mappings and even different QoS renegotiation 164 techniques without interoperability problems. All RSVP over ATM 165 approaches that have VCs initiated and controlled by the sub-net 166 senders will interoperate. Figure 1 shows this model of data flow 167 VC initiation. 169 Data Flow ==========> 171 +-----+ 172 | | --------------> +----+ 173 | Src | --------------> | R1 | 174 | *| --------------> +----+ 175 +-----+ QoS VCs 176 /\ 177 || 178 VC || 179 Initiator 181 Figure 1: Data Flow VC Initiation 183 RSVP over ATM implementations MAY send data in the backwards 184 direction on a RSVP initiated QoS point-to-point VC. When sending 185 in the backwards data path, the sender MUST ensure that the data 186 conforms to the backwards direction traffic parameters. Since the 187 traffic parameters are set by the VC initiator, it is quite likely 188 that no resources will be requested for traffic originating at the 189 called party. Of course, the backwards data path is not available 190 with point-to-multipoint VCs. 192 2.3 VC Teardown 194 VCs supporting IP over ATM data are typically torndown based on 195 inactivity timers. This mechanism is used since IP is 196 connectionless and there is therefore no way to know when a VC is 197 no longer needed. Since RSVP provides explicit mechanisms 198 (messages and timeouts) to determine when an associated data VC is 199 no longer needed, the traditional VC timeout mechanisms is not 200 needed. Data VCs set up to support RSVP controlled flows should 201 only be released at the direction of RSVP. Such VCs must not be 202 timed out due to inactivity by either the VC initiator or the VC 203 receiver. This conflicts with VCs timing out as described in RFC 204 1755[14], section 3.4 on VC Teardown. RFC 1755 recommends tearing 205 down a VC that is inactive for a certain length of time. Twenty 206 minutes is recommended. This timeout is typically implemented at 207 both the VC initiator and the VC receiver. Although, section 3.1 208 of the update to RFC 1755[15] states that inactivity timers must 209 not be used at the VC receiver. 211 In RSVP over ATM implementations, the configurable inactivity 212 timer mentioned in [14] MUST be set to "infinite" for VCs 213 initiated at the request of RSVP. Setting the inactivity timer 214 value at the VC initiator should not be problematic since the 215 proper value can be relayed internally at the originator. Setting 216 the inactivity timer at the VC receiver is more difficult, and 217 would require some mechanism to signal that an incoming VC was 218 RSVP initiated. To avoid this complexity and to conform to [15], 219 RSVP over ATM implementations MUST not use an inactivity timer to 220 clear any received connection. 222 2.4 Dynamic QoS 224 As stated in [11], there is a mismatch in the service provided by 225 RSVP and that provided by ATM UNI3.x and 4.0. RSVP allows 226 modifications to QoS parameters at any time, while ATM does not 227 support any modifications to QoS parameters after VC setup. See 228 [11] for more detail. 230 The method for supporting changes in RSVP reservations is to 231 attempt to replace an existing VC with a new appropriately sized 232 VC. During setup of the replacement VC, the old VC MUST be left in 233 place unmodified. The old VC is left unmodified to minimize 234 interruption of QoS data delivery. Once the replacement VC is 235 established, data transmission is shifted to the new VC, and only 236 then is the old VC closed. 238 If setup of the replacement VC fails, then the old QoS VC MUST 239 continue to be used. When the new reservation is greater than the 240 old reservation, the reservation request MUST be answered with an 241 error. When the new reservation is less than the old reservation, 242 the request MUST be treated as if the modification was successful. 243 While leaving the larger allocation in place is suboptimal, it 244 maximizes delivery of service to the user. The behavior is also 245 required in order to conform to RSVP error handling as defined in 246 sections 2.5, 3.1.8 and 3.11.2 of [10]. Implementations SHOULD 247 retry replacing the too large VC after some appropriate elapsed 248 time. 250 One additional issue is that only one QoS change can be processed 251 at one time per reservation. If the (RSVP) requested QoS is 252 changed while the first replacement VC is still being setup, then 253 the replacement VC is released and the whole VC replacement 254 process is restarted. Implementations MAY also limit number of 255 changes processed in a time period per [11]. 257 2.5 Encapsulation 259 There are multiple encapsulation options for data sent over RSVP 260 triggered QoS VCs. All RSVP over ATM implementations MUST be able 261 to support LLC encapsulation per RFC 1483[12] on such QoS VCs. 262 Implementations MAY negotiate alternative encapsulations using the 263 B-LLI negotiation procedures defined in ATM Signalling, see [14] 264 for details. When a QoS VC is only being used to carry IP 265 packets, implementations SHOULD negotiate VC based multiplexing to 266 avoid incurring the overhead of the LLC header. 268 3. Multicast RSVP Session Support 270 There are several aspects to running RSVP over ATM that are 271 particular to multicast sessions. These issues result from the 272 nature of ATM point-to-multipoint connections. This section 273 addresses multicast end-point identification, multicast data 274 distribution, multicast receiver transitions and next-hops requesting 275 different QoS values (heterogeneity) which includes the handling of 276 multicast best-effort receivers. Handling of best-effort receivers 277 is not strictly an RSVP issues, but needs to be addressed in any RSVP 278 over ATM implementation in order to maintain expected Internet 279 service. 281 3.1 Data VC Management for Heterogeneous Sessions 283 The issues relating to data VC management of heterogeneous 284 sessions are covered in detail in [11] and not repeated. In 285 summary, heterogeneity occurs when receivers request different 286 levels of QoS within a single session, and also when some 287 receivers do not request any QoS. Both types of heterogeneity are 288 shown in figure 2. 290 +----+ 291 +------> | R1 | 292 | +----+ 293 | 294 | +----+ 295 +-----+ -----+ +--> | R2 | 296 | | ---------+ +----+ Receiver Request Types: 297 | Src | ----> QoS 1 and QoS 2 298 | | .........+ +----+ ....> Best-Effort 299 +-----+ .....+ +..> | R3 | 300 : +----+ 301 /\ : 302 || : +----+ 303 || +......> | R4 | 304 || +----+ 305 Single 306 IP Mulicast 307 Group 309 Figure 2: Types of Multicast Receivers 311 [11] provides four models for dealing with heterogeneity: full 312 heterogeneity, limited heterogeneity, homogeneous, and modified 313 homogeneous models. No matter which model or combination of 314 models is used by an implementation, implementations MUST NOT 315 normally send more than one copy of a particular data packet to a 316 particular next-hop (ATM end-point). Some transient over 317 transmission is acceptable, but only during VC setup and 318 transition. 320 Implementations MUST also ensure that data traffic is sent to 321 best-effort receivers. Data traffic MAY be sent to best-effort 322 receivers via best-effort or QoS VCs as is appropriate for the 323 implemented model. In all cases, implementations MUST NOT create 324 VCs in such a way that data cannot be sent to best-effort 325 receivers. This includes the case of not being able to add a 326 best-effort receiver to a QoS VC, but does not include the case 327 where best-effort VCs cannot be setup. The failure to establish 328 best-effort VCs is considered to be a general IP over ATM failure 329 and is therefore beyond the scope of this document. 331 There is an interesting interaction between dynamic QoS and 332 heterogeneous requests when using the limited heterogeneity, 333 homogeneous, or modified homogeneous models. In the case where a 334 RESV message is received from a new next-hop and the requested 335 resources are larger than any existing reservation, both dynamic 336 QoS and heterogeneity need to be addressed. A key issue is 337 whether to first add the new next-hop or to change to the new QoS. 338 This is a fairly straight forward special case. Since the older, 339 smaller reservation does not support the new next-hop, the dynamic 340 QoS process SHOULD be initiated first. Since the new QoS is only 341 needed by the new next-hop, it SHOULD be the first end-point of 342 the new VC. This way signalling is minimized when the setup to 343 the new next-hop fails. 345 3.2 Multicast End-Point Identification 347 Implementations must be able to identify ATM end-points 348 participating in an IP multicast group. The ATM end-points will 349 be IP multicast receivers and/or next-hops. Both QoS and best- 350 effort end-points must be identified. RSVP next-hop information 351 will usually provide QoS end-points, but not best-effort end- 352 points. 354 There is a special case where RSVP next-hop information will not 355 provide the appropriate end-point. This occurs when the next-hop 356 is not RSVP capable, and RSVP is being automatically tunneled. In 357 this case a PATH message travels through a non-RSVP egress router 358 on the way to the next hop RSVP node. When the next hop RSVP node 359 sends a RESV message it may arrive at the source over a different 360 route than what the data is using. The source will get the RESV 361 message, but will not know which egress router needs the QoS. For 362 unicast sessions, there is no problem since the ATM end-point will 363 be the IP next-hop router. Unfortunately, multicast routing may 364 not be able to uniquely identify the IP next-hop router. It is 365 therefore possible that a multicast end-point can not be properly 366 identified. 368 In the host case, some multicast over ATM control mechanisms, such 369 as MARS, can be used to identify all end-points of a multicast 370 group. In the router to router case, a multicast routing protocol 371 may provide all next-hops for a particular multicast group. In 372 either case, RSVP over ATM implementations must obtain a full list 373 of end-points, both QoS and non-QoS, using the appropriate 374 mechanisms. The full list can be compared against the RSVP 375 identified end-points to determine the list of best-effort 376 receivers. 378 There is no straightforward solution to uniquely identifying end- 379 points of multicast traffic handled by non-RSVP next hops. The 380 preferred solution is to use multicast routing protocols that 381 support unique end-point identification. In cases where such 382 routing protocols are unavailable, all IP routers that will be 383 used to support RSVP over ATM should support RSVP. To ensure 384 proper behavior, baseline RSVP over ATM implementations MUST only 385 establish RSVP-initiated VCs to RSVP capable end-points. It is 386 permissible to allow a user to override this behavior. 388 3.3 Multicast Data Distribution 390 Two models are planned for IP multicast data distribution over 391 ATM. In one model, senders establish point-to-multipoint VCs to 392 all ATM attached destinations, and data is then sent over these 393 VCs. This model is often called "multicast mesh" or "VC mesh" 394 mode distribution. In the second model, senders send data over 395 point-to-point VCs to a central point and the central point relays 396 the data onto point-to-multipoint VCs that have been established 397 to all receivers of the IP multicast group. This model is often 398 referred to as "multicast server" mode distribution. Figure 3 399 shows data flow for both modes of IP multicast data distribution. 400 The goal of RSVP over ATM solutions is to ensure that IP multicast 401 data is distributed with appropriate QoS. 403 _________ 404 / \ 405 / Multicast \ 406 \ Server / 407 \_________/ 408 ^ | | 409 | | +--------+ 410 +-----+ | | | 411 | | -------+ | | Data Flow: 412 | Src | ...+......|....+ V ----> Server 413 | | : | : +----+ ....> Mesh 414 +-----+ : | +...>| R1 | 415 : | +----+ 416 : V 417 : +----+ 418 +..> | R2 | 419 +----+ 421 Figure 3: IP Multicast Data Distribution Over ATM 423 Current multicast servers [1,2] do not support any mechanisms for 424 communicating QoS requirements to a multicast server. For this 425 reason, RSVP over ATM implementations SHOULD support "mesh-mode" 426 distribution for RSVP controlled multicast flows. When using 427 multicast servers that do not support QoS requests, a sender MUST 428 set the service, not global, break bit(s). Use of the service- 429 specific break bit tells the receiver(s) that RSVP and Integrated 430 Services are supported by the router but that the service cannot 431 be delivered over the ATM network for the specific request. 433 In the case of MARS[1], the selection of distribution modes is 434 administratively controlled. Therefore network administrators 435 that desire proper RSVP over ATM operation MUST appropriately 436 configure their network to support mesh mode distribution for 437 multicast groups that will be used in RSVP sessions. For LANE1.0 438 networks the only multicast distribution option is over the BUS, 439 which means that the break bit MUST always be set. For LANE2.0 440 [3] there are provisions that allow for non-BUS solutions with 441 which it may be possible to ensure proper QoS delivery. 443 3.4 Receiver Transitions 445 When setting up a point-to-multipoint VCs there will be a time 446 when some receivers have been added to a QoS VC and some have not. 447 During such transition times it is possible to start sending data 448 on the newly established VC. The issue is when to start send data 449 on the new VC. If data is sent both on the new VC and the old VC, 450 then data will be delivered with proper QoS to some receivers and 451 with the old QoS to all receivers. This means the QoS receivers 452 would get duplicate data. If data is sent just on the new QoS VC, 453 the receivers that have not yet been added will lose information. 454 So, the issue comes down to whether to send to both the old and 455 new VCs, or to send to just one of the VCs. In one case duplicate 456 information will be received, in the other some information may 457 not be received. This issue needs to be considered for three 458 cases: when establishing the first QoS VC, when establishing a VC 459 to support a QoS change, and when adding a new end-point to an 460 already established QoS VC. 462 The first two cases are essentially the same. In both, it is 463 possible to send data on the partially completed new VC, and the 464 issue of duplicate versus lost information is similar. The last 465 case occurs when an end-point must be added to an existing QoS VC. 466 In this case the end-point must be both added to the QoS VC and 467 dropped from a best-effort VC. The issue is which to do first. 468 If the add is first requested, then the end-point may get 469 duplicate information. If the drop is requested first, then the 470 end-point may loose information. 472 In order to ensure predictable behavior and to conform to the 473 requirement to deliver data to all receivers, data MUST NOT be 474 sent on new VCs until all parties have been added. This will 475 ensure that all data is only delivered once to all receivers. 476 This approach does not quite apply for the last case. In the last 477 case, the add MUST be completed first, then the drop. This last 478 behavior requires receivers to be prepared to receive some 479 duplicate packets at times of QoS setup. 481 4. Security 483 The same considerations stated in [10] and [14] apply to this 484 document. There are no additional security issues raised in this 485 document. 487 5. Acknowledgments 489 This work is based on earlier drafts [5,7] and comments from the 490 ISSLL working group. The author would like to acknowledge their 491 contribution, most notably Steve Berson who coauthored [7]. 493 6. Author's Address 495 Lou Berger 496 FORE Systems 497 6905 Rockledge Drive 498 Suite 800 499 Bethesda, MD 20817 501 Phone: +1 301 571 2534 502 EMail: lberger@fore.com 504 REFERENCES 506 [1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM 507 Networks," RFC 2022, November 1996. 509 [2] The ATM Forum, "LAN Emulation Over ATM Specification", Version 1.0. 511 [3] The ATM Forum, "LAN Emulation over ATM Version 2 - LUNI 512 Specification ", April 1997. 514 [4] The ATM Forum, "MPOA Baseline Version 1", May 1997. 516 [5] Berger, L., "RSVP over ATM: Framework and UNI3.0/3.1 Method", 517 Internet Draft, June 1996. 519 [6] Berger, L., "RSVP over ATM Implementation Guidelines", Internet 520 Draft, July 1997. 522 [7] Berson, S., Berger, L., "IP Integrated Services with RSVP over ATM," 523 Internet Draft, draft-ietf-issll-atm-support-02.txt, November 1996. 525 [8] Borden, M., Crawley, E., Krawczyk, J, Baker, F., and Berson, S., 526 "Issues for RSVP and Integrated Services over ATM," Internet Draft, 527 February 1996. 529 [9] Borden, M., and Garrett, M., "Interoperation of Controlled-Load and 530 Guaranteed-Service with ATM," Internet Draft, March 1997. 532 [10] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., 533 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 534 Specification," Internet Draft, June 1997. 536 [11] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and 537 Krawczyk, J, "Issues for Integrated Services and RSVP over ATM," 538 Internet Draft, July 1997. 540 [12] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation 541 Layer 5," RFC 1483. 543 [13] Onvural, R., Srinivasan, V., "A Framework for Supporting RSVP Flows 544 Over ATM Networks," Internet Draft, March 1996. 546 [14] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and 547 Malis, A., "ATM Signalling Support for IP over ATM," RFC 1755. 549 [15] Maher, M., "ATM Signalling Support for IP over ATM - UNI 4.0 550 Update" Internet Draft, May 1997.