idnits 2.17.1 draft-crawley-rsvp-over-atm-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-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 1996) is 10285 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: '10' is defined on line 558, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 562, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 565, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-rsvp-spec-09 ** Downref: Normative reference to an Informational RFC: RFC 1821 (ref. '2') -- No information found for draft-ietf-ipatm- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-14) exists of draft-ietf-rolc-nhrp-07 -- No information found for draft-ietf-intserv- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-04) exists of draft-ietf-intserv-ctrl-load-svc-01 -- 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' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 1577 (ref. '13') (Obsoleted by RFC 2225) Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force M. Borden, E. Crawley, J. Krawczyk 2 INTERNET-DRAFT Bay Networks 3 draft-crawley-rsvp-over-atm-00 F. Baker 4 Cisco Systems 5 S. Berson 6 ISI 7 February 22, 1996 9 Issues for RSVP and Integrated Services over ATM 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts). 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a "working 22 draft" or "work in progress." 24 Please check the I-D abstract listing contained in each Internet 25 Draft directory to learn the current status of this or any other 26 Internet Draft. 28 Abstract 30 The RSVP and Integrated Services working groups have been working 31 towards the goal of an "Integrated Services Internet" where 32 applications can request a Quality of Service (QoS) from the network 33 in order to meet their end-to- end service requirements. 34 Simultaneously, the IP-over-ATM working group has been specifying the 35 requirements and interactions between IP and Asynchronous Transfer 36 Mode (ATM) technology. The internals and interoperability of ATM 37 devices are specified by the ATM Forum and its working groups. One 38 of the features of ATM technology is the ability to request a virtual 39 circuit (VC) with a specified QoS. Obviously, it would be useful for 40 the work of the Integrated Services Internet to be able to take 41 advantage of the QoS abilities of ATM. 43 This document outlines the issues related to running RSVP and 44 Integrated Service models over ATM and presents an initial attempt at 45 dividing up the issues between the various working groups and 46 organizations. This is intended as a starting point for the 47 discussions in the joint IP-ATM, RSVP, and Int-Serv meeting to be 48 held at the Los Angeles IETF meeting in March, 1996. 50 1. Introduction 52 It is only natural that the RSVP protocol [1] and the Integrated 53 Services (IntServ) models [6,7] would like to utilize the QoS 54 properties of ATM as a subnetwork layer. [2] discusses providing RSVP 55 services over ATM and brings out some of the open issues. 56 Contributions to the ATM Forum MPOA Working Group [e.g. 10, 11, 12] 57 have also investigated some of the issues related to running RSVP 58 over ATM. However, no clear set of directions and plan of action has 59 been determined. Further, there are several groups in the IETF and 60 the ATM Forum that have expressed interest in the issues of RSVP and 61 IntServ over ATM. While it is very important that the issues 62 regarding RSVP and the IntServ models over ATM be addressed, it is 63 important not to duplicate effort between groups. It is also 64 important to avoid considering models and objectives that cannot be 65 demonstrated to be solvable in other switched networks. 67 The purpose of this document is to briefly describe the issues as 68 they are currently known and suggest which working groups should 69 address them. It is not the purpose of this document to describe 70 RSVP, the IntServ models, or IP over ATM. The reader should be 71 familiar with the concepts of these protocols and models. 73 2. Issues Regarding the Operation of RSVP and IntServ over ATM 75 The issues related to RSVP and IntServ over ATM fall into several 76 general classes: 77 - How to make RSVP run over ATM now and in the future 78 - When to set up a virtual circuit (VC) for a specific Quality of 79 Service (QoS) related to RSVP 80 - How to map the IntServ models to ATM QoS models 81 - How to know that an ATM network is providing the QoS necessary for 82 a flow 83 - How to handle the many-to-many connectionless features of IP 84 multicast and RSVP in the one-to-many connection-oriented world of 85 ATM 87 2.1 Modes/Models for RSVP and IntServ over ATM 89 [3] Discusses several different models for running IP over ATM 90 networks. Any one of these models would work as long as the RSVP 91 control packets (IP protocol 46) and data packets can follow the same 92 IP path through the network. It is important that the RSVP PATH 93 messages follow the same IP path as the data such that appropriate 94 PATH state may be installed in the routers along the path. For an 95 ATM subnetwork, this means the ingress and egress points must be the 96 same in both directions for the RSVP control and data messages. 97 Within each of these models, there are decisions about using 98 different types of data distribution in ATM as well as different 99 connection initiation. The following sections look at some of the 100 different ways QoS connections can be set up for RSVP. 102 2.1.1 UNI 3.x 104 In the User Network Interface (UNI) 3.0 and 3.1 specifications, [8,9] 105 both permanent and switched virtual circuits (PVC and SVC) may be 106 established with a specified service category (CBR, VBR, and UBR) and 107 specific traffic descriptors in point-to-point and 108 point-to-multipoint configurations. Additional QoS parameters are 109 not available in UNI 3.x and those that are available are 110 vendor-specific. Consequently, the level of QoS control available in 111 standard UNI 3.x networks is somewhat limited. However, using these 112 building blocks, it is possible to use RSVP and the IntServ models. 114 2.1.1.1 Permanent Virtual Circuits (PVCs) 116 PVCs emulate dedicated point-to-point lines in a network, so the 117 operation of RSVP can be identical to the operation over any 118 point-to-point network. The QoS of the PVC must be consistent and 119 equivalent to the type of traffic and service model used. The 120 devices on either end of the PVC have to provide traffic control 121 services in order to multiplex multiple flows over the same PVC. 122 With PVCs, there is no issue of when or how long it takes to set up 123 VCs, since they are made in advance but the resources of the PVC are 124 limited to what has been pre-allocated. PVCs that are not fully 125 utilized can tie up ATM network resources that could be used for 126 SVCs. 128 2.1.1.2 Switched Virtual Circuits (SVCs) 130 SVCs allow paths in the ATM network to be set up "on demand". This 131 allows flexibility in the use of RSVP over ATM along with some 132 complexity. Parallel VCs can be set up to allow best-effort and 133 better service class paths through the network. The cost and time to 134 set up SVCs can impact their use. For example, it may be better to 135 initially route QoS traffic over existing VCs until an SVC with the 136 desired QoS has been set up. Scaling issues can come into play if a 137 single VC is used per RSVP flow. An RSVP flow is a data flow from 138 one or more sources to one or more receivers as defined by an RSVP 139 filter specification. The number of VCs in any ATM device is limited 140 so the number of RSVP flows that can be handled by a device would be 141 strictly limited to the number of VCs available, if we assume one VC 142 per flow. 144 2.1.1.3 Point to MultiPoint 146 In order to provide QoS for IP multicast, an important feature of 147 RSVP, data flows must be distributed to multiple destinations from a 148 given source. Point-to-multipoint VCs provide such a mechanism. It 149 is important to map the actions of IP multicasting and RSVP 150 (e.g. IGMP JOIN/LEAVE and RSVP RESV/RESV TEAR) to add party and drop 151 party functions for ATM. Point-to-multipoint VCs as defined in UNI 152 3.x have a single service class for all destinations. This is 153 contrary to the RSVP "heterogeneous receiver" concept. It is 154 possible to set up a different VC to each receiver requesting a 155 different QoS, but this again could run into scaling problems. 157 RSVP sends messages both up and down the multicast distribution tree. 158 In the case of a large ATM cloud, this could result in a RSVP message 159 implosion at an RSVP traffic source with many receivers. 161 2.1.1.4 Multicast Servers 163 IP-over-ATM has the concept of a multicast server or reflector that 164 can accept cells from multiple senders and send them via a 165 point-to-multipoint VC to a set of receivers. This moves the VC 166 scaling issues noted previously for point-to-multipoint VCs to the 167 multicast server. Additionally, the multicast server will need to 168 know how to interpret RSVP packets so it will be able to provide VCs 169 of the appropriate QoS for the flows. 171 2.1.2 ATM Forum Release 4.0 173 Release 4.0 adds a Leaf Initiated Join (LIJ) capability and 174 standardizes additional QoS parameters for finer control of the 175 characteristics of a VC. LIJ allows an ATM end point to join into an 176 existing point-to-multipoint VC without necessarily contacting the 177 source of the VC. This will reduce the burden on the ATM source 178 point for setting up new branches and more closely matches the 179 receiver-based model of RSVP and IP multicast. However, many of the 180 same scaling issues exist and the new branches added to a point-to- 181 multipoint VC would use the same QoS as existing branches. 183 The ATM Forum Traffic Management (TM) specification 4.0 greatly 184 enhances the flexibility of choosing QoS in an ATM network. Rather 185 than QoS only being defined by a service category, it is possible to 186 request individual traffic parameters. This will aid enormously in 187 matching QoS models between ATM and IntServ. In addition, TM 4.0 188 defines new classes, such as VBR-rt and ABR that will be helpful in 189 new service models. 191 2.1.3 Hop-by-Hop vs. Short Cut 193 If the ATM "cloud" is made up a number of logical IP subnets (LISs), 194 then it is possible to use "short cuts" from a node on one LIS 195 directly to a node on another LIS, avoiding router hops between the 196 LISs. NHRP [4], is one mechanism for determining the ATM address of 197 the egress point on the ATM network given a destination IP address. 198 It is a topic for further study to determine if significant benefit 199 is achieved from short cut routes vs. the extra state required. 201 However, if the PATH and RESV messages must follow the same set of IP 202 hops, then short cut paths in both directions must be established. 204 This is not a problem for point-to- point VCs, but it is a problem 205 for point-to-multipoint connections since they are unidirectional. 206 This topic requires further study and guidelines. 208 2.1.4 Future Models 210 ATM is constantly evolving. If we assume that RSVP and IntServ 211 applications are going to be wide-spread, it makes sense to consider 212 changes to ATM that would improve the operation of RSVP and IntServ 213 over ATM. Similarly, the RSVP protocol and IntServ models will 214 continue to evolve and changes that affect them should also be 215 considered. 217 2.1.4.1 Heterogeneous Point-to-MultiPoint 219 The IntServ models and RSVP support the idea of "heterogeneous 220 receivers"; i.e., not all receivers of a particular multicast flow 221 are required to ask for the same QoS from the network. 223 The most important case of this is where some receivers ask for a 224 specific QoS while others receive the flow in a best- effort manner. 225 In some cases where there are multiple senders on a 226 shared-reservation flow (e.g., an audio conference), an individual 227 receiver only needs to reserve enough resources to receive one sender 228 at a time. However, other receivers may elect to reserve more 229 resources, perhaps to allow for some amount of "over- speaking" or in 230 order to record the conference (post processing during playback can 231 separate the senders by their source addresses). 233 In order to prevent denial-of-service attacks via reservations, the 234 service models do not allow the service elements to simply drop 235 non-conforming packets. Guaranteed Delay [6] service requires that 236 the flow must be reshaped before running it through the policing 237 function. Both Guaranteed and Controlled Load [7] assign 238 non-conformant packets to best-effort status (which may result in 239 packet drops if there is congestion). 241 Emulating these behaviors over an ATM network is problematic and 242 needs to be studied. If a single maximum QoS is used over a 243 point-to-multipoint VC, resources could be wasted if cells are sent 244 over certain links where the reassembled packets will eventually be 245 dropped. In addition, the "maximum QoS" may actually be a 246 degradation in service to the best-effort branches. 248 The term "variegated VC" has been coined to describe a point- 249 to-multipoint VC that allows a different QoS on each branch. This 250 approach seems to match the spirit of the Integrated Service and RSVP 251 models, but some thought has to be put into the cell drop strategy 252 when traversing from a "bigger" branch to a "smaller" one. The 253 "best-effort for non- conforming packets" behavior must be retained. 254 Early Packet Discard (EPD) schemes must be used so that all the cells 255 for a given packet can be discarded at the same time rather than 256 discarding only a few cells from several packets making all the 257 packets useless to the receivers. 259 2.1.4.2 Lightweight Signalling 261 Q.2931 signalling is very complete and carries with it a significant 262 burden for signalling in all possible public and private connections. 263 It might be worth investigating a lighter weight signalling mechanism 264 for faster connection setup in private networks. 266 2.1.4.3 QoS Renegotiation 268 Another change that would help RSVP over ATM is the ability to 269 request a different QoS for an active VC. This would eliminate the 270 need to setup and tear down VCs as the QoS changed. RSVP allows 271 receivers to change their reservations and senders to change their 272 traffic descriptors dynamically. This, along with the merging of 273 reservations can create a situation where the QoS needs of a VC can 274 change. Allowing changes to the QoS of an existing VC would allow 275 these features to work without creating a new VC. 277 2.1.4.4 Group Addressing 279 The model of one-to-many communications provided by point-to- 280 multipoint VCs does not really match the many-to-many communications 281 provided by IP multicasting. It would be nice to have a scaleable 282 mapping from IP multicast addresses to an ATM "group address" to 283 address this problem. 285 2.1.5 QoS Routing 287 RSVP is explicitly not a routing protocol. However, since it conveys 288 QoS information, it may prove to be a valuable input to a routing 289 protocol that could make path determinations based on QoS and network 290 load information. In other words, instead of asking for just the IP 291 next hop for a given destination address, it might be worthwhile for 292 RSVP to provide information on the QoS needs of the flow if routing 293 has the ability to use this information in order to determine a 294 route. The work in this area is just starting and there are numerous 295 issues to consider. 297 2.2 Reliance on Multicast Routing 299 RSVP was designed to support both unicast and IP multicast 300 applications. This means that RSVP needs to work closely with 301 multicast and unicast routing. Unicast routing over ATM has been 302 addressed in RFC1577[13] and RFC1755[14]. MARS[5] provides multicast 303 address resolution for IP over ATM networks, an important part of the 304 solution for multicast routing. Further work is needed for full 305 interoperability of IP multicast routing with ATM. 307 2.3 Aggregation of Flows 309 Some of the scaling issues noted in previous sections can be 310 addressed by aggregating several RSVP flows over a single VC if the 311 destinations of the VC match for all the flows being aggregated. 312 However, this causes some complexity in the management of VCs and in 313 the scheduling of packets within each VC at the originating point of 314 the VC. Note that he rescheduling of flows within a VC is not 315 possible in the switches in the ATM network. Additionally, virtual 316 paths (VPs) could be used for aggregating multiple VCs. These topics 317 need to be investigated and some guidelines need to be provided. 319 2.4 Mapping QoS Parameters 321 The mapping of QoS parameters from the IntServ models to the ATM 322 service classes is an important issue in making RSVP and IntServ work 323 over ATM. The issue is that while some guidelines can be developed 324 for mapping the parameters of a given service model to the traffic 325 descriptors of an ATM traffic class, implementation variables, 326 policy, and cost factors can make strict standards problematic. 328 2.5 Directly Connected ATM Hosts 330 It is obvious that the needs of hosts that are directly connected to 331 ATM networks must be considered for RSVP and IntServ over ATM. 332 Functionality for RSVP over ATM must not assume that an ATM host has 333 all the functionality of a router, but such things as MARS and NHRP 334 clients might be worthwhile features. 336 2.6 API Issues 338 While it has not been much of a concern to the IETF, there are groups 339 considering how applications can specify QoS parameters to the 340 network in a manner that makes sense to application programmers. It 341 makes sense that APIs specify parameters in a manner that is 342 independent of the layer 2 network. It is also important for the 343 application to be able to renegotiate and change its requested QoS in 344 a manner that is consistent with the RSVP and IntServ models. 346 2.7 Accounting and Policy Issues 348 Since RSVP and IntServ create classes of preferential service, some 349 form of administrative control or cost allocation is needed to 350 control abuse. There are certain types of policies specific to ATM 351 and IP over ATM that need to be studied to determine how they 352 interoperate with IP policies being developed. Typical IP policies 353 would be that only certain users are allowed to make reservations. 354 This policy would translate well to IP over ATM. There may be a need 355 for policies specific to IP over ATM. For example, since signalling 356 costs are high relative to IP, an IP over ATM specific policy might 357 restrict the ability to change the prevailing QoS in a VC. If VCs 358 are relatively scarce, there also might be specific accounting costs 359 in creating a new VC. The work so far has been preliminary, and much 360 work remains to be done. 362 3. Responsibilities for Resolving Issues 364 The following sections list the working groups involved in some of 365 the issues listed in the previous section. Along with each group is 366 a list of issues that the authors believe each group should address 367 for RSVP and IntServ over ATM. The goal is to not have multiple 368 working groups working on the same problem(s). This list is a 369 starting point for discussions. However, it is hoped that the 370 discussions will be brief such that the working groups can get down 371 to business quickly. 373 3.1 IETF Working Groups 375 The IETF has several working groups that can be involved in RSVP and 376 IntServ over ATM. IETF working groups are chartered to solve 377 specific problems and some of the issues noted in the following may 378 not be specifically in their current charter so it may require 379 amendment of the charter or creation of a new or sub working group. 381 3.1.1 IP over ATM (IPATM) 383 This group has been most involved in getting IP to work over ATM and 384 is responsible for issues relating to both IP hosts and IP routers. 385 They have spent time on encapsulations and multicast address 386 resolution and have been the focal point for liaison activities 387 between the ATM Forum and the IETF. They should continue to be the 388 focal point for liaison activities as they relate to RSVP and IntServ 389 over ATM and should address specific issues related to the operation 390 of the IP protocols, including RSVP, over ATM. 392 As the focal point for liaison activities, the IPATM WG can encourage 393 contributions for the ATM Forum as needed. 395 3.1.2 Integrated Services (INTSERV) 397 IntServ has been developing service models for the integrated 398 services internet. These models turn into flow specification formats 399 for RSVP. It is important for IntServ to examine methods by which 400 these flow requirements can be achieved over ATM, using the ATM 401 notions of QoS. There is typically not a unique method of doing so, 402 and it is expected that the working group would be developing 403 guidelines and not standardized rules. 405 In addition to describing the parameters of the flow there is the 406 problem of managing the flows. This needs to be studied at the same 407 time. The issues involve policies for aggregating flows over a 408 single VC, when new VCs need to be established, and managing 409 point-to-multipoint "variegated" VCs. Since most of these decisions 410 are local, the need not be standardized but guidelines may be 411 appropriate. 413 As new application requirements are generated, the IntServ WG will 414 need to develop new service models, flow specification formats, and 415 methods to achieve the services over ATM. 417 3.1.3 ReSerVation Protocol (RSVP) 419 The RSVP WG has been focused on developing version 1 of the RSVP 420 protocol in a media and routing independent manner. They should 421 continue addressing further issues with RSVP such as security, 422 authentication, and access control. Related to ATM, the RSVP WG 423 should consider the ramifications of RSVP in Non-Broadcast 424 MultiAccess (NBMA) networks such as ATM and publish guidelines for 425 RSVP over such nets. 427 3.1.4 InterDomain Multicast Routing (IDMR) 429 The IDMR WG has been concerned with scaleable multicast routing 430 protocols. Obviously, there are going to be issues for multicast 431 routing in NBMA networks and IDMR must consider the implications for 432 the protocols being developed. QoS multicast routing is also 433 something that IDMR should consider as it relates to RSVP and ATM. 435 3.1.5 Routing Over Large Clouds (ROLC) 437 As an NMBA network that can span a "large cloud," ATM can make use of 438 the NHRP protocol being developed in the ROLC WG. The WG has been 439 very aware of the needs of IP over ATM in the development of NHRP and 440 should continue to do so. As mentioned earlier, the benefit of short 441 cut routing needs to be weighed against the state and cost of 442 establishing direct VCs between nodes on different ATM LISs. The 443 benefit vs. the scaling issues must be considered for RSVP and 444 IntServ. 446 3.2 ATM Forum 448 The ATM Forum exists for its members and all of its activities must 449 be approved by the members. There are several working groups that 450 have interest in RSVP and IntServ over ATM. There was a 451 well-attended Birds of a Feather (BOF) session for RSVP and IntServ 452 over ATM as part of the MPOA WG at the February 1996 ATM Forum 453 meeting in Beverly Hills, CA. 455 3.2.1 Signalling (SIG) 457 Obviously, any changes to ATM signalling to better support RSVP and 458 IntServ will have to be approved by the Signalling WG. Such features 459 include variegated point-to-multipoint VCs and renegotiated QoS for 460 existing VCs. These are not trivial problems and are expected to 461 take some time, but contributions from members are expected in this 462 area soon. 464 The Signalling WG should also be involved in making a "group 465 addressing" scheme to provide many-to-many communications in a 466 scaleable manner, much like the current IP multicast model. 468 3.2.2 MultiProtocol Over ATM (MPOA) 470 The MPOA WG is addressing the issues of running multiple layer 3 471 protocols in an ATM environment. The features of ATM such as QoS and 472 short cut routing are expected to be utilized. The features of RSVP 473 that affect the MPOA environment should be considered by MPOA but 474 there will be considerable overlap with the work of the IETF RSVP WG. 475 In these cases, the RSVP WG should address the issues. 477 MPOA is also the focal point for the liaisons between the ATM Forum 478 and the IETF and should continue to do so with feedback from other 479 ATM Forum and IETF working groups feeding into the liaisons. 481 3.2.3 Traffic Management (TM) 483 The TM working group has recently been concerned with divorcing 484 strict traffic classes from negotiated QoS parameters, and the 485 introduction of the Available Bit Rate (ABR) class. The group is at 486 the point where new work items are being defined, but it is plain 487 that future work in the areas of clarification of QoS objectives and 488 point-to- multipoint QoS is warranted. These are areas in which the 489 developing IntServ ideas can have influence. In addition, it would be 490 helpful for the TM group to provide examples of how IntServ QoS 491 objectives can be obtained with TM models. 493 3.3 Other Organizations 495 3.3.1 IEEE 497 IEEE 802.1p and 802.9 have proposed various services that may be 498 useful in running the IntServ models over IEEE- specified 499 subnetworks. To the extent that these have an impact on ATM, they 500 should also be reflected in the layering of IntServ models on ATM. 501 However, we recommend that IEEE considerations not further complicate 502 these issues beyond liaison activities. 504 3.3.2 WinSock2 Forum 506 WinSock2 is an API for Windows platforms that can specify QoS 507 parameters independent of the network transport. Obviously, the work 508 of the groups above should be input to WinSock2 so the APIs match the 509 services available. 511 4. Summary 513 In this paper, we have suggested a preliminary plan of action for 514 addressing the issues in layering the Integrated Services models and 515 RSVP onto an ATM subnetwork. This problem is complicated by the fact 516 that multiple IETF working groups and multiple organizations are 517 involved and by the fact that ATM technology, the Integrated Services 518 models, and RSVP are evolving over time. Our objective is to see the 519 work go forward openly and with a minimum of both duplicated effort 520 and friction. 522 5. References 524 [1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin. Resource 525 ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. 526 Internet Draft, draft-ietf-rsvp-spec-09. February 1996. 528 [2] M. Borden, E. Crawley, B. Davie, S. Batsell. Integration of 529 Real-time Services in an IP-ATM Network Architecture. Request for 530 Comments (Informational) RFC 1821, August 1995. 532 [3] R. Cole, D. Shur, C. Villamizar. IP over ATM: A Framework 533 Document. Internet Draft, draft-ietf-ipatm- framework-doc-07, 534 February 1996. 536 [4] D. Katz, D. Piscitello, B. Cole, J. Luciani. NBMA Next Hop 537 Resolution Protocol (NHRP). Internet Draft, 538 draft-ietf-rolc-nhrp-07.txt, December 1995. 540 [5] G. Armitage, Support for Multicast over UNI 3.0/3.1 based ATM 541 Networks. Internet Draft, draft-ietf-ipatm-ipmc-11.txt. February 542 1996. 544 [6] S. Shenker, C. Partridge. Specification of Guaranteed Quality of 545 Service. Internet Draft, draft-ietf-intserv- guaranteed-svc-03.txt, 546 November 1995. 548 [7] J. Wroclawski. Specification of the Controlled-Load Network 549 Element Service. Internet Draft, 550 draft-ietf-intserv-ctrl-load-svc-01.txt, November 1995. 552 [8] ATM Forum. ATM User-Network Interface Specification Version 553 3.0. Prentice Hall, September 1993 555 [9] ATM Forum. ATM User Network Interface (UNI) Specification Version 556 3.1. Prentice Hall, June 1995. 558 [10] A. Demirtjis, S. Berson, B. Edwards, M. P. Maher, B. Braden, 559 A. Mankin. RSVP and ATM Signalling, ATM Forum Contribution 96-0258, 560 January 1996. 562 [11] M. Borden, K. Faulkner, E. Stern. Support for RSVP in ATM 563 Networks, ATM Forum Contribution 96-0039, February 1996. 565 [12] F. Baker, A. Lin, Y. Rekhter, Support for RSVP and IP Integrated 566 Services over ATM, ATM Forum Contribution 96- 0258, January 1996. 568 [13] M. Laubach, Classical IP and ARP over ATM. Request for Comments 569 (Proposed Standard) RFC1577, January 1994. 571 [14] M. Perez, A. Mankin, E. Hoffman, G. Grossman, A. Malis, ATM 572 Signalling Support for IP over ATM, Request for Comments (Proposed 573 Standard) RFC1755, February 1995. 575 6. Author's Address 577 Marty Borden 578 Eric S. Crawley 579 John J. Krawczyk 580 Bay Networks 581 3 Federal Street 582 Billerica, Ma 01821 583 +1 508 670-8888 584 mborden@baynetworks.com 585 esc@baynetworks.com 586 jj@baynetworks.com 588 Fred Baker 589 Cisco Systems 590 519 Lado Drive 591 Santa Barbara, California 93111 592 +1 805 681-0115 593 fred@cisco.com 595 Steve Berson 596 USC Information Sciences Institute 597 4676 Admiralty Way 598 Marina del Rey, CA 90292 599 +1 310 822-1511 600 berson@isi.edu