Internet Engineering Task Force M. Borden, E. Crawley, J. Krawczyk INTERNET-DRAFT Bay Networks draft-crawley-rsvp-over-atm-00 F. Baker Cisco Systems S. Berson ISI February 22, 1996 Issues for RSVP and Integrated Services over ATM Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract The RSVP and Integrated Services working groups have been working towards the goal of an "Integrated Services Internet" where applications can request a Quality of Service (QoS) from the network in order to meet their end-to- end service requirements. Simultaneously, the IP-over-ATM working group has been specifying the requirements and interactions between IP and Asynchronous Transfer Mode (ATM) technology. The internals and interoperability of ATM devices are specified by the ATM Forum and its working groups. One of the features of ATM technology is the ability to request a virtual circuit (VC) with a specified QoS. Obviously, it would be useful for the work of the Integrated Services Internet to be able to take advantage of the QoS abilities of ATM. This document outlines the issues related to running RSVP and Integrated Service models over ATM and presents an initial attempt at dividing up the issues between the various working groups and organizations. This is intended as a starting point for the discussions in the joint IP-ATM, RSVP, and Int-Serv meeting to be held at the Los Angeles IETF meeting in March, 1996. Expires August 22, 1996 Page 1 INTERNET-DRAFT RSVP and INTSERV over ATM Issues February 22, 1996 1. Introduction It is only natural that the RSVP protocol [1] and the Integrated Services (IntServ) models [6,7] would like to utilize the QoS properties of ATM as a subnetwork layer. [2] discusses providing RSVP services over ATM and brings out some of the open issues. Contributions to the ATM Forum MPOA Working Group [e.g. 10, 11, 12] have also investigated some of the issues related to running RSVP over ATM. However, no clear set of directions and plan of action has been determined. Further, there are several groups in the IETF and the ATM Forum that have expressed interest in the issues of RSVP and IntServ over ATM. While it is very important that the issues regarding RSVP and the IntServ models over ATM be addressed, it is important not to duplicate effort between groups. It is also important to avoid considering models and objectives that cannot be demonstrated to be solvable in other switched networks. The purpose of this document is to briefly describe the issues as they are currently known and suggest which working groups should address them. It is not the purpose of this document to describe RSVP, the IntServ models, or IP over ATM. The reader should be familiar with the concepts of these protocols and models. 2. Issues Regarding the Operation of RSVP and IntServ over ATM The issues related to RSVP and IntServ over ATM fall into several general classes: - How to make RSVP run over ATM now and in the future - When to set up a virtual circuit (VC) for a specific Quality of Service (QoS) related to RSVP - How to map the IntServ models to ATM QoS models - How to know that an ATM network is providing the QoS necessary for a flow - How to handle the many-to-many connectionless features of IP multicast and RSVP in the one-to-many connection-oriented world of ATM 2.1 Modes/Models for RSVP and IntServ over ATM [3] Discusses several different models for running IP over ATM networks. Any one of these models would work as long as the RSVP control packets (IP protocol 46) and data packets can follow the same IP path through the network. It is important that the RSVP PATH messages follow the same IP path as the data such that appropriate PATH state may be installed in the routers along the path. For an ATM subnetwork, this means the ingress and egress points must be the same in both directions for the RSVP control and data messages. Within each of these models, there are decisions about using different types of data distribution in ATM as well as different connection initiation. The following sections look at some of the different ways QoS connections can be set up for RSVP. Expires August 22, 1996 Page 2 INTERNET-DRAFT RSVP and INTSERV over ATM Issues February 22, 1996 2.1.1 UNI 3.x In the User Network Interface (UNI) 3.0 and 3.1 specifications, [8,9] both permanent and switched virtual circuits (PVC and SVC) may be established with a specified service category (CBR, VBR, and UBR) and specific traffic descriptors in point-to-point and point-to-multipoint configurations. Additional QoS parameters are not available in UNI 3.x and those that are available are vendor-specific. Consequently, the level of QoS control available in standard UNI 3.x networks is somewhat limited. However, using these building blocks, it is possible to use RSVP and the IntServ models. 2.1.1.1 Permanent Virtual Circuits (PVCs) PVCs emulate dedicated point-to-point lines in a network, so the operation of RSVP can be identical to the operation over any point-to-point network. The QoS of the PVC must be consistent and equivalent to the type of traffic and service model used. The devices on either end of the PVC have to provide traffic control services in order to multiplex multiple flows over the same PVC. With PVCs, there is no issue of when or how long it takes to set up VCs, since they are made in advance but the resources of the PVC are limited to what has been pre-allocated. PVCs that are not fully utilized can tie up ATM network resources that could be used for SVCs. 2.1.1.2 Switched Virtual Circuits (SVCs) SVCs allow paths in the ATM network to be set up "on demand". This allows flexibility in the use of RSVP over ATM along with some complexity. Parallel VCs can be set up to allow best-effort and better service class paths through the network. The cost and time to set up SVCs can impact their use. For example, it may be better to initially route QoS traffic over existing VCs until an SVC with the desired QoS has been set up. Scaling issues can come into play if a single VC is used per RSVP flow. An RSVP flow is a data flow from one or more sources to one or more receivers as defined by an RSVP filter specification. The number of VCs in any ATM device is limited so the number of RSVP flows that can be handled by a device would be strictly limited to the number of VCs available, if we assume one VC per flow. 2.1.1.3 Point to MultiPoint In order to provide QoS for IP multicast, an important feature of RSVP, data flows must be distributed to multiple destinations from a given source. Point-to-multipoint VCs provide such a mechanism. It is important to map the actions of IP multicasting and RSVP (e.g. IGMP JOIN/LEAVE and RSVP RESV/RESV TEAR) to add party and drop party functions for ATM. Point-to-multipoint VCs as defined in UNI 3.x have a single service class for all destinations. This is Expires August 22, 1996 Page 3 INTERNET-DRAFT RSVP and INTSERV over ATM Issues February 22, 1996 contrary to the RSVP "heterogeneous receiver" concept. It is possible to set up a different VC to each receiver requesting a different QoS, but this again could run into scaling problems. RSVP sends messages both up and down the multicast distribution tree. In the case of a large ATM cloud, this could result in a RSVP message implosion at an RSVP traffic source with many receivers. 2.1.1.4 Multicast Servers IP-over-ATM has the concept of a multicast server or reflector that can accept cells from multiple senders and send them via a point-to-multipoint VC to a set of receivers. This moves the VC scaling issues noted previously for point-to-multipoint VCs to the multicast server. Additionally, the multicast server will need to know how to interpret RSVP packets so it will be able to provide VCs of the appropriate QoS for the flows. 2.1.2 ATM Forum Release 4.0 Release 4.0 adds a Leaf Initiated Join (LIJ) capability and standardizes additional QoS parameters for finer control of the characteristics of a VC. LIJ allows an ATM end point to join into an existing point-to-multipoint VC without necessarily contacting the source of the VC. This will reduce the burden on the ATM source point for setting up new branches and more closely matches the receiver-based model of RSVP and IP multicast. However, many of the same scaling issues exist and the new branches added to a point-to- multipoint VC would use the same QoS as existing branches. The ATM Forum Traffic Management (TM) specification 4.0 greatly enhances the flexibility of choosing QoS in an ATM network. Rather than QoS only being defined by a service category, it is possible to request individual traffic parameters. This will aid enormously in matching QoS models between ATM and IntServ. In addition, TM 4.0 defines new classes, such as VBR-rt and ABR that will be helpful in new service models. 2.1.3 Hop-by-Hop vs. Short Cut If the ATM "cloud" is made up a number of logical IP subnets (LISs), then it is possible to use "short cuts" from a node on one LIS directly to a node on another LIS, avoiding router hops between the LISs. NHRP [4], is one mechanism for determining the ATM address of the egress point on the ATM network given a destination IP address. It is a topic for further study to determine if significant benefit is achieved from short cut routes vs. the extra state required. However, if the PATH and RESV messages must follow the same set of IP hops, then short cut paths in both directions must be established. Expires August 22, 1996 Page 4 INTERNET-DRAFT RSVP and INTSERV over ATM Issues February 22, 1996 This is not a problem for point-to- point VCs, but it is a problem for point-to-multipoint connections since they are unidirectional. This topic requires further study and guidelines. 2.1.4 Future Models ATM is constantly evolving. If we assume that RSVP and IntServ applications are going to be wide-spread, it makes sense to consider changes to ATM that would improve the operation of RSVP and IntServ over ATM. Similarly, the RSVP protocol and IntServ models will continue to evolve and changes that affect them should also be considered. 2.1.4.1 Heterogeneous Point-to-MultiPoint The IntServ models and RSVP support the idea of "heterogeneous receivers"; i.e., not all receivers of a particular multicast flow are required to ask for the same QoS from the network. The most important case of this is where some receivers ask for a specific QoS while others receive the flow in a best- effort manner. In some cases where there are multiple senders on a shared-reservation flow (e.g., an audio conference), an individual receiver only needs to reserve enough resources to receive one sender at a time. However, other receivers may elect to reserve more resources, perhaps to allow for some amount of "over- speaking" or in order to record the conference (post processing during playback can separate the senders by their source addresses). In order to prevent denial-of-service attacks via reservations, the service models do not allow the service elements to simply drop non-conforming packets. Guaranteed Delay [6] service requires that the flow must be reshaped before running it through the policing function. Both Guaranteed and Controlled Load [7] assign non-conformant packets to best-effort status (which may result in packet drops if there is congestion). Emulating these behaviors over an ATM network is problematic and needs to be studied. If a single maximum QoS is used over a point-to-multipoint VC, resources could be wasted if cells are sent over certain links where the reassembled packets will eventually be dropped. In addition, the "maximum QoS" may actually be a degradation in service to the best-effort branches. The term "variegated VC" has been coined to describe a point- to-multipoint VC that allows a different QoS on each branch. This approach seems to match the spirit of the Integrated Service and RSVP models, but some thought has to be put into the cell drop strategy when traversing from a "bigger" branch to a "smaller" one. The "best-effort for non- conforming packets" behavior must be retained. Early Packet Discard (EPD) schemes must be used so that all the cells Expires August 22, 1996 Page 5 INTERNET-DRAFT RSVP and INTSERV over ATM Issues February 22, 1996 for a given packet can be discarded at the same time rather than discarding only a few cells from several packets making all the packets useless to the receivers. 2.1.4.2 Lightweight Signalling Q.2931 signalling is very complete and carries with it a significant burden for signalling in all possible public and private connections. It might be worth investigating a lighter weight signalling mechanism for faster connection setup in private networks. 2.1.4.3 QoS Renegotiation Another change that would help RSVP over ATM is the ability to request a different QoS for an active VC. This would eliminate the need to setup and tear down VCs as the QoS changed. RSVP allows receivers to change their reservations and senders to change their traffic descriptors dynamically. This, along with the merging of reservations can create a situation where the QoS needs of a VC can change. Allowing changes to the QoS of an existing VC would allow these features to work without creating a new VC. 2.1.4.4 Group Addressing The model of one-to-many communications provided by point-to- multipoint VCs does not really match the many-to-many communications provided by IP multicasting. It would be nice to have a scaleable mapping from IP multicast addresses to an ATM "group address" to address this problem. 2.1.5 QoS Routing RSVP is explicitly not a routing protocol. However, since it conveys QoS information, it may prove to be a valuable input to a routing protocol that could make path determinations based on QoS and network load information. In other words, instead of asking for just the IP next hop for a given destination address, it might be worthwhile for RSVP to provide information on the QoS needs of the flow if routing has the ability to use this information in order to determine a route. The work in this area is just starting and there are numerous issues to consider. 2.2 Reliance on Multicast Routing RSVP was designed to support both unicast and IP multicast applications. This means that RSVP needs to work closely with multicast and unicast routing. Unicast routing over ATM has been addressed in RFC1577[13] and RFC1755[14]. MARS[5] provides multicast Expires August 22, 1996 Page 6 INTERNET-DRAFT RSVP and INTSERV over ATM Issues February 22, 1996 address resolution for IP over ATM networks, an important part of the solution for multicast routing. Further work is needed for full interoperability of IP multicast routing with ATM. 2.3 Aggregation of Flows Some of the scaling issues noted in previous sections can be addressed by aggregating several RSVP flows over a single VC if the destinations of the VC match for all the flows being aggregated. However, this causes some complexity in the management of VCs and in the scheduling of packets within each VC at the originating point of the VC. Note that he rescheduling of flows within a VC is not possible in the switches in the ATM network. Additionally, virtual paths (VPs) could be used for aggregating multiple VCs. These topics need to be investigated and some guidelines need to be provided. 2.4 Mapping QoS Parameters The mapping of QoS parameters from the IntServ models to the ATM service classes is an important issue in making RSVP and IntServ work over ATM. The issue is that while some guidelines can be developed for mapping the parameters of a given service model to the traffic descriptors of an ATM traffic class, implementation variables, policy, and cost factors can make strict standards problematic. 2.5 Directly Connected ATM Hosts It is obvious that the needs of hosts that are directly connected to ATM networks must be considered for RSVP and IntServ over ATM. Functionality for RSVP over ATM must not assume that an ATM host has all the functionality of a router, but such things as MARS and NHRP clients might be worthwhile features. 2.6 API Issues While it has not been much of a concern to the IETF, there are groups considering how applications can specify QoS parameters to the network in a manner that makes sense to application programmers. It makes sense that APIs specify parameters in a manner that is independent of the layer 2 network. It is also important for the application to be able to renegotiate and change its requested QoS in a manner that is consistent with the RSVP and IntServ models. 2.7 Accounting and Policy Issues Since RSVP and IntServ create classes of preferential service, some form of administrative control or cost allocation is needed to control abuse. There are certain types of policies specific to ATM Expires August 22, 1996 Page 7 INTERNET-DRAFT RSVP and INTSERV over ATM Issues February 22, 1996 and IP over ATM that need to be studied to determine how they interoperate with IP policies being developed. Typical IP policies would be that only certain users are allowed to make reservations. This policy would translate well to IP over ATM. There may be a need for policies specific to IP over ATM. For example, since signalling costs are high relative to IP, an IP over ATM specific policy might restrict the ability to change the prevailing QoS in a VC. If VCs are relatively scarce, there also might be specific accounting costs in creating a new VC. The work so far has been preliminary, and much work remains to be done. 3. Responsibilities for Resolving Issues The following sections list the working groups involved in some of the issues listed in the previous section. Along with each group is a list of issues that the authors believe each group should address for RSVP and IntServ over ATM. The goal is to not have multiple working groups working on the same problem(s). This list is a starting point for discussions. However, it is hoped that the discussions will be brief such that the working groups can get down to business quickly. 3.1 IETF Working Groups The IETF has several working groups that can be involved in RSVP and IntServ over ATM. IETF working groups are chartered to solve specific problems and some of the issues noted in the following may not be specifically in their current charter so it may require amendment of the charter or creation of a new or sub working group. 3.1.1 IP over ATM (IPATM) This group has been most involved in getting IP to work over ATM and is responsible for issues relating to both IP hosts and IP routers. They have spent time on encapsulations and multicast address resolution and have been the focal point for liaison activities between the ATM Forum and the IETF. They should continue to be the focal point for liaison activities as they relate to RSVP and IntServ over ATM and should address specific issues related to the operation of the IP protocols, including RSVP, over ATM. As the focal point for liaison activities, the IPATM WG can encourage contributions for the ATM Forum as needed. 3.1.2 Integrated Services (INTSERV) IntServ has been developing service models for the integrated services internet. These models turn into flow specification formats for RSVP. It is important for IntServ to examine methods by which these flow requirements can be achieved over ATM, using the ATM Expires August 22, 1996 Page 8 INTERNET-DRAFT RSVP and INTSERV over ATM Issues February 22, 1996 notions of QoS. There is typically not a unique method of doing so, and it is expected that the working group would be developing guidelines and not standardized rules. In addition to describing the parameters of the flow there is the problem of managing the flows. This needs to be studied at the same time. The issues involve policies for aggregating flows over a single VC, when new VCs need to be established, and managing point-to-multipoint "variegated" VCs. Since most of these decisions are local, the need not be standardized but guidelines may be appropriate. As new application requirements are generated, the IntServ WG will need to develop new service models, flow specification formats, and methods to achieve the services over ATM. 3.1.3 ReSerVation Protocol (RSVP) The RSVP WG has been focused on developing version 1 of the RSVP protocol in a media and routing independent manner. They should continue addressing further issues with RSVP such as security, authentication, and access control. Related to ATM, the RSVP WG should consider the ramifications of RSVP in Non-Broadcast MultiAccess (NBMA) networks such as ATM and publish guidelines for RSVP over such nets. 3.1.4 InterDomain Multicast Routing (IDMR) The IDMR WG has been concerned with scaleable multicast routing protocols. Obviously, there are going to be issues for multicast routing in NBMA networks and IDMR must consider the implications for the protocols being developed. QoS multicast routing is also something that IDMR should consider as it relates to RSVP and ATM. 3.1.5 Routing Over Large Clouds (ROLC) As an NMBA network that can span a "large cloud," ATM can make use of the NHRP protocol being developed in the ROLC WG. The WG has been very aware of the needs of IP over ATM in the development of NHRP and should continue to do so. As mentioned earlier, the benefit of short cut routing needs to be weighed against the state and cost of establishing direct VCs between nodes on different ATM LISs. The benefit vs. the scaling issues must be considered for RSVP and IntServ. 3.2 ATM Forum The ATM Forum exists for its members and all of its activities must be approved by the members. There are several working groups that Expires August 22, 1996 Page 9 INTERNET-DRAFT RSVP and INTSERV over ATM Issues February 22, 1996 have interest in RSVP and IntServ over ATM. There was a well-attended Birds of a Feather (BOF) session for RSVP and IntServ over ATM as part of the MPOA WG at the February 1996 ATM Forum meeting in Beverly Hills, CA. 3.2.1 Signalling (SIG) Obviously, any changes to ATM signalling to better support RSVP and IntServ will have to be approved by the Signalling WG. Such features include variegated point-to-multipoint VCs and renegotiated QoS for existing VCs. These are not trivial problems and are expected to take some time, but contributions from members are expected in this area soon. The Signalling WG should also be involved in making a "group addressing" scheme to provide many-to-many communications in a scaleable manner, much like the current IP multicast model. 3.2.2 MultiProtocol Over ATM (MPOA) The MPOA WG is addressing the issues of running multiple layer 3 protocols in an ATM environment. The features of ATM such as QoS and short cut routing are expected to be utilized. The features of RSVP that affect the MPOA environment should be considered by MPOA but there will be considerable overlap with the work of the IETF RSVP WG. In these cases, the RSVP WG should address the issues. MPOA is also the focal point for the liaisons between the ATM Forum and the IETF and should continue to do so with feedback from other ATM Forum and IETF working groups feeding into the liaisons. 3.2.3 Traffic Management (TM) The TM working group has recently been concerned with divorcing strict traffic classes from negotiated QoS parameters, and the introduction of the Available Bit Rate (ABR) class. The group is at the point where new work items are being defined, but it is plain that future work in the areas of clarification of QoS objectives and point-to- multipoint QoS is warranted. These are areas in which the developing IntServ ideas can have influence. In addition, it would be helpful for the TM group to provide examples of how IntServ QoS objectives can be obtained with TM models. 3.3 Other Organizations 3.3.1 IEEE IEEE 802.1p and 802.9 have proposed various services that may be useful in running the IntServ models over IEEE- specified Expires August 22, 1996 Page 10 INTERNET-DRAFT RSVP and INTSERV over ATM Issues February 22, 1996 subnetworks. To the extent that these have an impact on ATM, they should also be reflected in the layering of IntServ models on ATM. However, we recommend that IEEE considerations not further complicate these issues beyond liaison activities. 3.3.2 WinSock2 Forum WinSock2 is an API for Windows platforms that can specify QoS parameters independent of the network transport. Obviously, the work of the groups above should be input to WinSock2 so the APIs match the services available. 4. Summary In this paper, we have suggested a preliminary plan of action for addressing the issues in layering the Integrated Services models and RSVP onto an ATM subnetwork. This problem is complicated by the fact that multiple IETF working groups and multiple organizations are involved and by the fact that ATM technology, the Integrated Services models, and RSVP are evolving over time. Our objective is to see the work go forward openly and with a minimum of both duplicated effort and friction. 5. References [1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin. Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. Internet Draft, draft-ietf-rsvp-spec-09. February 1996. [2] M. Borden, E. Crawley, B. Davie, S. Batsell. Integration of Real-time Services in an IP-ATM Network Architecture. Request for Comments (Informational) RFC 1821, August 1995. [3] R. Cole, D. Shur, C. Villamizar. IP over ATM: A Framework Document. Internet Draft, draft-ietf-ipatm- framework-doc-07, February 1996. [4] D. Katz, D. Piscitello, B. Cole, J. Luciani. NBMA Next Hop Resolution Protocol (NHRP). Internet Draft, draft-ietf-rolc-nhrp-07.txt, December 1995. [5] G. Armitage, Support for Multicast over UNI 3.0/3.1 based ATM Networks. Internet Draft, draft-ietf-ipatm-ipmc-11.txt. February 1996. [6] S. Shenker, C. Partridge. Specification of Guaranteed Quality of Service. Internet Draft, draft-ietf-intserv- guaranteed-svc-03.txt, November 1995. Expires August 22, 1996 Page 11 INTERNET-DRAFT RSVP and INTSERV over ATM Issues February 22, 1996 [7] J. Wroclawski. Specification of the Controlled-Load Network Element Service. Internet Draft, draft-ietf-intserv-ctrl-load-svc-01.txt, November 1995. [8] ATM Forum. ATM User-Network Interface Specification Version 3.0. Prentice Hall, September 1993 [9] ATM Forum. ATM User Network Interface (UNI) Specification Version 3.1. Prentice Hall, June 1995. [10] A. Demirtjis, S. Berson, B. Edwards, M. P. Maher, B. Braden, A. Mankin. RSVP and ATM Signalling, ATM Forum Contribution 96-0258, January 1996. [11] M. Borden, K. Faulkner, E. Stern. Support for RSVP in ATM Networks, ATM Forum Contribution 96-0039, February 1996. [12] F. Baker, A. Lin, Y. Rekhter, Support for RSVP and IP Integrated Services over ATM, ATM Forum Contribution 96- 0258, January 1996. [13] M. Laubach, Classical IP and ARP over ATM. Request for Comments (Proposed Standard) RFC1577, January 1994. [14] M. Perez, A. Mankin, E. Hoffman, G. Grossman, A. Malis, ATM Signalling Support for IP over ATM, Request for Comments (Proposed Standard) RFC1755, February 1995. 6. Author's Address Marty Borden Eric S. Crawley John J. Krawczyk Bay Networks 3 Federal Street Billerica, Ma 01821 +1 508 670-8888 mborden@baynetworks.com esc@baynetworks.com jj@baynetworks.com Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111 +1 805 681-0115 fred@cisco.com Steve Berson USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 +1 310 822-1511 berson@isi.edu Expires August 22, 1996 Page 12