idnits 2.17.1 draft-ietf-issll-atm-imp-req-02.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-25) 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 ([5], [6], [9]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 399 has weird spacing: '...ols can provi...' == 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 [11] 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 [12], RSVP over ATM implementations MUST not use an inactivity timer to clear any received connections. -- 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 (January 5, 1998) is 9607 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) -- Looks like a reference, but probably isn't: 'Note 1' on line 475 -- 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' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 1483 (ref. '10') (Obsoleted by RFC 2684) -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft L. Berger 2 Expires: July 1998 FORE Systems 3 File: draft-ietf-issll-atm-imp-req-02.txt 5 RSVP over ATM Implementation Requirements 7 January 5, 1998 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 [5] provides specific guidelines 34 for running over today's ATM networks. The general problem is 35 discussed in [9]. Integrated Services to ATM service mappings are 36 covered in [6]. 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 RSVP Message VC Usage ...........................................5 47 2.2 VC Initiation ...................................................5 48 2.3 VC Teardown .....................................................6 49 2.4 Dynamic QoS .....................................................7 50 2.5 Encapsulation ...................................................7 51 3. Multicast RSVP Session Support ......................................8 52 3.1 Data VC Management for Heterogeneous Sessions ...................8 53 3.2 Multicast End-Point Identification ..............................9 54 3.3 Multicast Data Distribution .....................................10 55 3.4 Receiver Transitions ............................................12 56 4. Security ............................................................12 57 5. Acknowledgments .....................................................12 58 6. Author's Address ....................................................13 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[8] over ATM have been covered in several 66 papers including [9] and other earlier work. This document is 67 intended as a companion to [9,5]. The reader should be familiar with 68 both documents. 70 This document defines the 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 [5]. 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 [8] 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 105 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in 107 RFC 2119 [7]. 109 1.2 Assumptions 111 The following assumptions are made: 113 o RSVP 115 We assume RSVP as the internet signaling protocol which is 116 described in [8]. The reader is assumed to be familiar with 117 [8]. 119 o IPv4 and IPv6 121 RSVP support has been defined for both IPv4 and IPv6. The 122 guidelines in this document are intended to be used to 123 support RSVP with either IPv4 or IPv6. This document does 124 not require one version over the other. 126 o Best effort service model 128 The current Internet only supports best effort service. We 129 assume that as additional components of the Integrated 130 Services model that best effort service must continue to be 131 supported. 133 o ATM UNI 3.x and 4.0 135 We assume ATM service as defined by UNI 3.x and 4.0. ATM 136 provides both point-to-point and point-to-multipoint Virtual 137 Circuits (VCs) with a specified Quality of Service (QoS). 138 ATM provides both Permanent Virtual Circuits (PVCs) and 139 Switched Virtual Circuits (SVCs). In the Permanent Virtual 140 Circuit (PVC) environment, PVCs are typically used as point- 141 to-point link replacements. So the support issues are 142 similar to point-to-point links. This draft assumes that 143 SVCs are used to support RSVP over ATM. 145 2. General RSVP Session Support 147 This section provides implementation requirements that are common for 148 all (both unicast and multicast) RSVP sessions. The section covers 149 VC usage, QoS VC initiation, VC teardown, handling requested changes 150 in QoS, and encapsulation. 152 2.1 RSVP Message VC Usage 154 There are several RSVP Message VC Usage options available to 155 implementers. Implementers must select which VC to use for RSVP 156 messages and how to aggregate RSVP sessions over QoS VCs. These 157 options have been covered in [9] and some specific implementation 158 guidelines are stated in [5]. In order to ensure interoperability 159 between implementations that follow different options, RSVP over 160 ATM implementations MUST NOT send RSVP (control) messages on the 161 same QoS VC as RSVP associated data packets. RSVP over ATM 162 implementations MAY send RSVP messages on either the best effort 163 data path or on a separate control VC. 165 Since RSVP (control) messages and RSVP associated data packets are 166 not sent on the same VCs, it is possible for a VC supporting one 167 type of traffic to fail while the other remains in place. When 168 the VC associated with data packets fails and cannot be 169 reestablished, RSVP SHOULD treat this as an allocation failure. 170 When the VC used to forward RSVP control messages is abnormally 171 released and cannot be reestablished, the RSVP associated QoS VCs 172 MUST also be released. The release of the associated data VCs is 173 required to maintain the synchronization between forwarding and 174 reservation states for the associated data flows. 176 2.2 VC Initiation 178 There is an apparent mismatch between RSVP and ATM. Specifically, 179 RSVP control is receiver oriented and ATM control is sender 180 oriented. This initially may seem like a major issue but really 181 is not. While RSVP reservation (RESV) requests are generated at 182 the receiver, actual allocation of resources takes place at the 183 subnet sender. 185 For data flows, this means that subnet senders MUST establish all 186 QoS VCs and the RSVP enabled subnet receiver MUST be able to 187 accept incoming QoS VCs. These restrictions are consistent with 188 RSVP version 1 processing rules and allow senders to use different 189 flow to VC mappings and even different QoS renegotiation 190 techniques without interoperability problems. All RSVP over ATM 191 approaches that have VCs initiated and controlled by the subnet 192 senders will interoperate. Figure 1 shows this model of data flow 193 VC initiation. 195 Data Flow ==========> 197 +-----+ 198 | | --------------> +----+ 199 | Src | --------------> | R1 | 200 | *| --------------> +----+ 201 +-----+ QoS VCs 202 /\ 203 || 204 VC || 205 Initiator 207 Figure 1: Data Flow VC Initiation 209 RSVP over ATM implementations MAY send data in the backwards 210 direction on an RSVP initiated QoS point-to-point VC. When 211 sending in the backwards data path, the sender MUST ensure that 212 the data conforms to the backwards direction traffic parameters. 213 Since the traffic parameters are set by the VC initiator, it is 214 quite likely that no resources will be requested for traffic 215 originating at the called party. It should be noted that the 216 backwards data path is not available with point-to-multipoint VCs. 218 2.3 VC Teardown 220 VCs supporting IP over ATM data are typically torndown based on 221 inactivity timers. This mechanism is used since IP is 222 connectionless and there is therefore no way to know when a VC is 223 no longer needed. Since RSVP provides explicit mechanisms 224 (messages and timeouts) to determine when an associated data VC is 225 no longer needed, the traditional VC timeout mechanisms are not 226 needed. Additionally, under normal operations RSVP implementations 227 expect to be able to allocate resources and have those resources 228 remain allocated until released at the direction of RSVP. 229 Therefore, data VCs set up to support RSVP controlled flows should 230 only be released at the direction of RSVP. Such VCs must not be 231 timed out due to inactivity by either the VC initiator or the VC 232 receiver. This conflicts with VCs timing out as described in RFC 233 1755[11], section 3.4 on VC Teardown. RFC 1755 recommends tearing 234 down a VC that is inactive for a certain length of time. Twenty 235 minutes is recommended. This timeout is typically implemented at 236 both the VC initiator and the VC receiver. Although, section 3.1 237 of the update to RFC 1755[12] states that inactivity timers must 238 not be used at the VC receiver. 240 In RSVP over ATM implementations, the configurable inactivity 241 timer mentioned in [11] MUST be set to "infinite" for VCs 242 initiated at the request of RSVP. Setting the inactivity timer 243 value at the VC initiator should not be problematic since the 244 proper value can be relayed internally at the originator. Setting 245 the inactivity timer at the VC receiver is more difficult, and 246 would require some mechanism to signal that an incoming VC was 247 RSVP initiated. To avoid this complexity and to conform to [12], 248 RSVP over ATM implementations MUST not use an inactivity timer to 249 clear any received connections. 251 2.4 Dynamic QoS 253 As stated in [9], there is a mismatch in the service provided by 254 RSVP and that provided by ATM UNI3.x and 4.0. RSVP allows 255 modifications to QoS parameters at any time while ATM does not 256 support any modifications to QoS parameters post VC setup. See 257 [9] for more detail. 259 The method for supporting changes in RSVP reservations is to 260 attempt to replace an existing VC with a new appropriately sized 261 VC. During setup of the replacement VC, the old VC MUST be left in 262 place unmodified. The old VC is left unmodified to minimize 263 interruption of QoS data delivery. Once the replacement VC is 264 established, data transmission is shifted to the new VC, and only 265 then is the old VC closed. 267 If setup of the replacement VC fails, then the old QoS VC MUST 268 continue to be used. When the new reservation is greater than the 269 old reservation, the reservation request MUST be answered with an 270 error. When the new reservation is less than the old reservation, 271 the request MUST be treated as if the modification was successful. 272 While leaving the larger allocation in place is suboptimal, it 273 maximizes delivery of service to the user. The behavior is also 274 required in order to conform to RSVP error handling as defined in 275 sections 2.5, 3.1.8 and 3.11.2 of [8]. Implementations SHOULD 276 retry replacing a too large VC after some appropriate elapsed 277 time. 279 One additional issue is that only one QoS change can be processed 280 at one time per reservation. If the (RSVP) requested QoS is 281 changed while the first replacement VC is still being setup, then 282 the replacement VC SHOULD BE released and the whole VC replacement 283 process is restarted. Implementations MAY also limit number of 284 changes processed in a time period per [9]. 286 2.5 Encapsulation 288 There are multiple encapsulation options for data sent over RSVP 289 triggered QoS VCs. All RSVP over ATM implementations MUST be able 290 to support LLC encapsulation per RFC 1483[10] on such QoS VCs. 291 Implementations MAY negotiate alternative encapsulations using the 292 B-LLI negotiation procedures defined in ATM Signalling, see [11] 293 for details. When a QoS VC is only being used to carry IP 294 packets, implementations SHOULD negotiate VC based multiplexing to 295 avoid incurring the overhead of the LLC header. 297 3. Multicast RSVP Session Support 299 There are several aspects to running RSVP over ATM that are unique to 300 multicast sessions. This section addresses multicast end-point 301 identification, multicast data distribution, multicast receiver 302 transitions and next-hops requesting different QoS values 303 (heterogeneity) which includes the handling of multicast best effort 304 receivers. Handling of best effort receivers is not strictly an RSVP 305 issue, but needs to be addressed by any RSVP over ATM implementation 306 in order to maintain expected best effort internet service. 308 3.1 Data VC Management for Heterogeneous Sessions 310 The issues relating to data VC management of heterogeneous 311 sessions are covered in detail in [9]. In summary, heterogeneity 312 occurs when receivers request different levels of QoS within a 313 single session, and also when some receivers do not request any 314 QoS. Both types of heterogeneity are shown in figure 2. 316 +----+ 317 +------> | R1 | 318 | +----+ 319 | 320 | +----+ 321 +-----+ -----+ +--> | R2 | 322 | | ---------+ +----+ Receiver Request Types: 323 | Src | ----> QoS 1 and QoS 2 324 | | .........+ +----+ ....> Best-Effort 325 +-----+ .....+ +..> | R3 | 326 : +----+ 327 /\ : 328 || : +----+ 329 || +......> | R4 | 330 || +----+ 331 Single 332 IP Mulicast 333 Group 335 Figure 2: Types of Multicast Receivers 337 [9] provides four models for dealing with heterogeneity: full 338 heterogeneity, limited heterogeneity, homogeneous, and modified 339 homogeneous models. No matter which model or combination of 340 models is used by an implementation, implementations MUST NOT 341 normally send more than one copy of a particular data packet to a 342 particular next-hop (ATM end-point). Some transient duplicate 343 transmission is acceptable, but only during VC setup and 344 transition. 346 Implementations MUST also ensure that data traffic is sent to best 347 effort receivers. Data traffic MAY be sent to best effort 348 receivers via best effort or QoS VCs as is appropriate for the 349 implemented model. In all cases, implementations MUST NOT create 350 VCs in such a way that data cannot be sent to best effort 351 receivers. This includes the case of not being able to add a best 352 effort receiver to a QoS VC, but does not include the case where 353 best effort VCs cannot be setup. The failure to establish best 354 effort VCs is considered to be a general IP over ATM failure and 355 is therefore beyond the scope of this document. 357 There is an interesting interaction between dynamic QoS and 358 heterogeneous requests when using the limited heterogeneity, 359 homogeneous, or modified homogeneous models. In the case where a 360 RESV message is received from a new next-hop and the requested 361 resources are larger than any existing reservation, both dynamic 362 QoS and heterogeneity need to be addressed. A key issue is 363 whether to first add the new next-hop or to change to the new QoS. 364 This is a fairly straight forward special case. Since the older, 365 smaller reservation does not support the new next-hop, the dynamic 366 QoS process SHOULD be initiated first. Since the new QoS is only 367 needed by the new next-hop, it SHOULD be the first end-point of 368 the new VC. This way signaling is minimized when the setup to the 369 new next-hop fails. 371 3.2 Multicast End-Point Identification 373 Implementations must be able to identify ATM end-points 374 participating in an IP multicast group. The ATM end-points will 375 be IP multicast receivers and/or next-hops. Both QoS and best 376 effort end-points must be identified. RSVP next-hop information 377 will usually provide QoS end-points, but not best effort end- 378 points. 380 There is a special case where RSVP next-hop information will not 381 provide the appropriate end-points. This occurs when a next-hop 382 is not RSVP capable and RSVP is being automatically tunneled. In 383 this case a PATH message travels through a non-RSVP egress router 384 on the way to the next-hop RSVP node. When the next-hop RSVP node 385 sends a RESV message it may arrive at the source via a different 386 route than used by the PATH message. The source will get the RESV 387 message, but will not know which ATM end-point should be 388 associated with the reservation. For unicast sessions, there is no 389 problem since the ATM end-point will be the IP next-hop router. 390 There is a problem with multicast, since multicast routing may not 391 be able to uniquely identify the IP next-hop router. It is 392 therefore possible for a multicast end-point to not be properly 393 identified. 395 In certain cases it is also possible to identify the list of all 396 best effort end-points. Some multicast over ATM control 397 mechanisms, such as MARS in mesh mode, can be used to identify all 398 end-points of a multicast group. Also, some multicast routing 399 protocols can provide all next-hops for a particular multicast 400 group. In both cases, RSVP over ATM implementations can obtain a 401 full list of end-points, both QoS and non-QoS, using the 402 appropriate mechanisms. The full list can then be compared 403 against the RSVP identified end-points to determine the list of 404 best effort receivers. 406 While there are cases where QoS and best effort end-points can be 407 identified, there is no straightforward solution to uniquely 408 identifying end-points of multicast traffic handled by non-RSVP 409 next-hops. The preferred solution is to use multicast control 410 mechanisms and routing protocols that support unique end-point 411 identification. In cases where such mechanisms and routing 412 protocols are unavailable, all IP routers that will be used to 413 support RSVP over ATM should support RSVP. To ensure proper 414 behavior, baseline RSVP over ATM implementations MUST only 415 establish RSVP-initiated VCs to RSVP capable end-points. It is 416 permissible to allow a user to override this behavior. 418 3.3 Multicast Data Distribution 420 Two basic models exist for IP multicast data distribution over 421 ATM. In one model, senders establish point-to-multipoint VCs to 422 all ATM attached destinations, and data is then sent over these 423 VCs. This model is often called "multicast mesh" or "VC mesh" 424 mode distribution. In the second model, senders send data over 425 point-to-point VCs to a central point and the central point relays 426 the data onto point-to-multipoint VCs that have been established 427 to all receivers of the IP multicast group. This model is often 428 referred to as "multicast server" mode distribution. Figure 3 429 shows data flow for both modes of IP multicast data distribution. 431 _________ 432 / \ 433 / Multicast \ 434 \ Server / 435 \_________/ 436 ^ | | 437 | | +--------+ 438 +-----+ | | | 439 | | -------+ | | Data Flow: 440 | Src | ...+......|....+ V ----> Server 441 | | : | : +----+ ....> Mesh 442 +-----+ : | +...>| R1 | 443 : | +----+ 444 : V 445 : +----+ 446 +..> | R2 | 447 +----+ 449 Figure 3: IP Multicast Data Distribution Over ATM 451 The goal of RSVP over ATM solutions is to ensure that IP multicast 452 data is distributed with appropriate QoS. Current multicast 453 servers [1,2] do not support any mechanisms for communicating QoS 454 requirements to a multicast server. For this reason, RSVP over 455 ATM implementations SHOULD support "mesh-mode" distribution for 456 RSVP controlled multicast flows. When using multicast servers 457 that do not support QoS requests, a sender MUST set the service, 458 not global, break bit(s). Use of the service-specific break bit 459 tells the receiver(s) that RSVP and Integrated Services are 460 supported by the router but that the service cannot be delivered 461 over the ATM network for the specific request. 463 In the case of MARS[1], the selection of distribution modes is 464 administratively controlled. Therefore network administrators 465 that desire proper RSVP over ATM operation MUST appropriately 466 configure their network to support mesh mode distribution for 467 multicast groups that will be used in RSVP sessions. For LANE1.0 468 networks the only multicast distribution option is over the LANE 469 BUS [Note 1] , which means that the break bit MUST always be set. 470 For LANE2.0 [3] there are provisions that allow for non-BUS 471 solutions with which it may be possible to ensure proper QoS 472 delivery. 474 _________________________ 475 [Note 1] Broadcast and Unknown Server 476 3.4 Receiver Transitions 478 When setting up a point-to-multipoint VCs there will be a time 479 when some receivers have been added to a QoS VC and some have not. 480 During such transition times it is possible to start sending data 481 on the newly established VC. If data is sent both on the new VC 482 and the old VC, then data will be delivered with proper QoS to 483 some receivers and with the old QoS to all receivers. 484 Additionally, the QoS receivers would get duplicate data. If data 485 is sent just on the new QoS VC, the receivers that have not yet 486 been added will miss data. So, the issue comes down to whether to 487 send to both the old and new VCs, or to just send to one of the 488 VCs. In one case duplicate data will be received, in the other 489 some data may not be received. This issue needs to be considered 490 for three cases: when establishing the first QoS VC, when 491 establishing a VC to support a QoS change, and when adding a new 492 end-point to an already established QoS VC. 494 The first two cases are essentially the same. In both, it is 495 possible to send data on the partially completed new VC. In both, 496 there is the option of duplicate or lost data. In order to ensure 497 predictable behavior and to conform to the requirement to deliver 498 data to all receivers, data MUST NOT be sent on new VCs until all 499 parties have been added. This will ensure that all data is only 500 delivered once to all receivers. 502 The last case differs from the others and occurs when an end-point 503 must be added to an existing QoS VC. In this case the end-point 504 must be both added to the QoS VC and dropped from a best effort 505 VC. The issue is which to do first. If the add is first 506 requested, then the end-point may get duplicate data. If the drop 507 is requested first, then the end-point may miss data. In order to 508 avoid loss of data, the add MUST be completed first and then 509 followed by the drop. This behavior requires receivers to be 510 prepared to receive some duplicate packets at times of QoS setup. 512 4. Security 514 The same considerations stated in [8] and [11] apply to this 515 document. There are no additional security issues raised in this 516 document. 518 5. Acknowledgments 520 This work is based on earlier drafts and comments from the ISSLL 521 working group. The author would like to acknowledge their 522 contribution, most notably Steve Berson who coauthored one of the 523 drafts. 525 6. Author's Address 527 Lou Berger 528 FORE Systems 529 1595 Spring Hill Road 530 5th Floor 531 Vienna, VA 22182 533 Phone: +1 703-245-4527 534 EMail: lberger@fore.com 536 REFERENCES 538 [1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM 539 Networks," RFC 2022, November 1996. 541 [2] The ATM Forum, "LAN Emulation Over ATM Specification", Version 1.0. 543 [3] The ATM Forum, "LAN Emulation over ATM Version 2 - LUNI 544 Specification ", April 1997. 546 [4] The ATM Forum, "MPOA Baseline Version 1", May 1997. 548 [5] Berger, L., "RSVP over ATM Implementation Guidelines", Internet 549 Draft, January 1998. 551 [6] Borden, M., and Garrett, M., "Interoperation of Controlled-Load and 552 Guaranteed-Service with ATM," Internet Draft, November 1997. 554 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 555 Levels," RFC 2119, March 1997. 557 [8] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., 558 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 559 Specification," RFC 2205, September 1997. 561 [9] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and 562 Krawczyk, J, "Issues for Integrated Services and RSVP over ATM," 563 Internet Draft, Novemver 1997. 565 [10] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation 566 Layer 5," RFC 1483. 568 [11] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and 569 Malis, A., "ATM Signalling Support for IP over ATM," RFC 1755. 571 [12] Maher, M., "ATM Signalling Support for IP over ATM - UNI 4.0 572 Update" Internet Draft, May 1997.