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