Internet Draft S. Berson Expiration: December 1996 ISI File: File: draft-ietf-issll-atm-support-00.txt IP Integrated Services Support in ATM June 13, 1996 Status of 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the linebreak "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract Integrated Services in the Internet is rapidly becoming a reality. Meanwhile, ATM technology is appearing in the marketplace. It is an important problem to integrate ATM networks into this emerging Integrated Services Internet. "Classical" IP over ATM[11,8] is now widely deployed, effectively solving the problem of "best effort service" in internets with ATM links. A key remaining issue is to provide the Internet Integrated Services (IIS) model over internets with ATM links. This draft provides guidelines for using ATM VCs with QoS as part of an Integrated Services Internet. [NOTE - The .txt version does not currently have all the figures.] Berson Expiration: December 1996 [Page 1] Internet Draft Integrated Services and ATM June 1996 Table of Contents 1. Introduction ........................................................2 2. RSVP ................................................................3 2.1 RSVP messages ...................................................4 2.2 Reservation Styles ..............................................4 2.3 RSVP flows ......................................................5 2.4 RSVP flows and VCs ..............................................6 3. Single VC per RSVP Flow .............................................6 3.1 Dynamic QoS .....................................................7 4. Tear down old VC ............................................8 5. Activate timer ..............................................8 5.1 Mixed data and control traffic ..................................12 5.2 Single RSVP VC per RSVP Flow ....................................12 5.3 Multiplexed point-to-multipoint RSVP VCs ........................12 5.4 Multiplexed point-to-point RSVP VCs .............................13 5.5 QoS for RSVP VCs ................................................14 6. Additional issues ...................................................14 7. Conclusions and Future Work .........................................14 Berson Expiration: December 1996 [Page 2] Internet Draft Integrated Services and ATM June 1996 1. Introduction [NOTE: This draft discusses RSVP and ATM specifically, but most of the issues and approaches are not specific to either RSVP or ATM, but rather would apply to any setup protocol and any Non-Broadcast Multiple Access (NBMA) network. In those cases where an issue is specific to either RSVP or ATM, it will be pointed out in the text. It is the intention of the author in the future to split this draft into two documents, one dealing with RSVP-specific issues, and the other with general integrated services issues.] The Internet currently has one class of service normally referred to as "best effort." This service is typified by first-come, first- serve scheduling at each hop in the network. Best effort service has worked exceptionally well for electronic mail, World Wide Web (WWW) access, file transfer (e.g. ftp), etc. For real-time traffic such as voice and video, the current Internet has performed well only across unloaded networks. In order to provide guaranteed quality real-time traffic, new classes of service and new protocols are being introduced in the Internet[10,4], while retaining the existing best effort service. Signalling for these new services is done by RSVP[3,12], the Resource ReSerVation Protocol. Due to extensive telephone company support, ATM is rapidly becoming an important link layer technology. As this draft was being written, the current version of ATM signalling was UNI 3.1[9], and UNI 3.1 is expected to be predominant in the marketplace in the near term. However, a new version (UNI 4.0) is expected to be standardized soon, and this draft will be updated as appropriate. One of the important features of ATM technology is the ability to request a point-to-point Virtual Circuit (VC) with a specified Quality of Service (QoS). An additional feature of ATM technology is the ability to request point-to-multipoint VCs with a specified QoS. Point-to-multipoint VCs allows leaf nodes to be joined and removed from the VC dynamically and so provide a mechanism for supporting IP multicast. It is only natural that RSVP and the Internet Integrated Services (IIS) model would like to utilize the QoS properties of any underlying link layer, and this draft concentrates on ATM. Classical IP over ATM[11] has solved part of this problem, supporting IP unicast traffic over ATM. Classical IP over ATM is based on a Logical IP Subnetwork (LIS), which is a separately administered IP subnetwork. Hosts within a LIS communicate using the ATM network, while hosts from different subnets communicate only by going through an IP router (even though it may be possible to open a direct VC between the two hosts over the ATM network). Classical IP over ATM provides an Address Resolution Protocol (ATMARP) for ATM edge devices Berson Expiration: December 1996 [Page 3] Internet Draft Integrated Services and ATM June 1996 to resolve IP addresses to native ATM addresses. For any pair of IP/ATM edge devices (i.e. hosts or routers), a single VC is created on demand and shared for all traffic between the two devices. A second part of the RSVP and IIS over ATM problem, IP multicast, is close to being solved with MARS[1], the Multicast Address Resolution Server. The MARS server generalizes ATMARP by allowing an IP address to resolve into a list of native ATM addresses, rather than just a single address. There is work in progress on alternative IP over ATM models (e.g. NHRP[7]) but similar solutions to those described here for the classical model are still expected to apply. But further study is needed. A key remaining issue for IP over ATM is the integration of RSVP signalling and ATM signalling in support of the Internet Integrated Services (IIS) model. There are two main areas involved in supporting the IIS model, QoS translation and VC management. QoS translation concerns mapping a QoS from the IIS model to a proper ATM QoS, while VC management concentrates on how many VCs are needed and which traffic flows are routed over which VCs. This draft concentrates on VC management, and we assume that the QoS for a single RSVP flow can be acceptably translated to an ATM QoS. This assumption is reasonable since the traffic parameters for both IIS and ATM QoS are very similar. The remainder of this draft is organized as follows. Section 2 describes how source traffic is mapped to RSVP flows and then to VCs. Section 3 describes the "single homogeneous VC" model where there is only one VC per RSVP flow even when there are different receivers requesting different reservations. In particular, this section describes how the QoS of the single VC must be dynamically changed over ATM and how to limit excessive signalling using timers. Section 4 examines the case where a single RSVP flow can be fed into several VCs. In particular, this section describes the need for multiple VCs particularly for simultaneously supporting a single QoS service as well as best effort service. Section 5 describes alternatives for VCs used for RSVP signalling messages. Section 6 discusses some additional minor issues. Section 7 concludes the draft and describes continuing and future work. 2. RSVP [NOTE - this section is RSVP specific] RSVP[3,12] provides many important features for signalling in the Internet including receiver initiated reservations, "soft state" in routers, heterogeneous reservations within a multicast session, Berson Expiration: December 1996 [Page 4] Internet Draft Integrated Services and ATM June 1996 dynamic change of reservations, and multiple reservation styles or modes of sharing. Of particular interest for RSVP and ATM [Note 1] are reservation styles, dynamic change of reservations, and heterogeneous reservations within a multicast session. The remainder of this section describes these features. 2.1 RSVP messages In RSVP resources are reserved by use of two types of messages, PATH and RESV. Each RSVP traffic source sends out PATH messages along the same route (unicast or multicast) as the data traffic will travel. PATH messages carry information about the source traffic parameters such as a mean bit rate, and token bucket size. Using information from PATH messages and obtained from higher layer protocols, receivers can then make reservations for specific resources by sending RESV messages along the reverse path of the PATH messages. Resources will be allocated on the proper outgoing link of all nodes along the route from traffic source(s) to the receiver. This is shown in figure with two sources "S1" and "S2," and two receivers "R1" and "R2." [IMAGE] Figure 1: RSVP message flow Multiple receivers can send RESV messages toward the same traffic source(s) as shown in figure . The quantities of resources requested by these receivers may be different. RSVP handles RESV messages for different quantities of resources by doing "merging". A node where multiple different reservation messages arrive (from different receivers) is called a "merge node". In order that RSVP scale well with the number of receivers of a session, only one merged RESV message is forwarded from a merge node towards a source, and this message carries the maximum of the incoming resource reservation requests. In figure , router "r1" is a merge node and would send to traffic sources "S1" and "S2" a reservation message requesting the maximum of the resources requested by receivers "R1" and "R2." 2.2 Reservation Styles RSVP provides several different styles of reservations. The styles that are part of the current version 1 RSVP specification _________________________ [Note 1] Though ATM is sender oriented, it is worth noting that receiver initiated reservations were not an issue at all. Berson Expiration: December 1996 [Page 5] Internet Draft Integrated Services and ATM June 1996 are shown in figure , while noting that additional styles may be defined in the future. The reservation style helps determine how many RSVP flows are needed for a multicast group and which source traffic uses which flow. Reservation styles can be "distinct", where each RSVP flow is used by exactly one sender, or "shared", where multiple senders use the same RSVP flow. Reservation styles can also have either "explicit sender selection", where a reservation is established only for senders explicitly listed in the reservation message, or can have "wildcard sender selection" where traffic from any sender is selected. Different reservation styles are suitable for different types of data traffic. Typically, shared type styles are best for audio conferencing since there would typically be only one person speaking at a time independent of the number of senders. Distinct type styles are typically used for video where each traffic source is continuously sending, and so sharing is difficult. Reservations Sender Selection | Distinct | Shared ----------------------------------------------------------------- Explicit | Fixed-Filter (FF) Style | Shared-Explicit (SE) Style Wildcard | (None defined) | Wildcard-Filter (WF) Style Figure 2: Reservation Styles Three reservation styles have currently been defined. Fixed filter style has explicit sender selection and distinct reservations and is typically used for video conferencing where each video stream has its own RSVP flow. Wildcard filter style has wildcard sender selection and shared style and is typically used for audio conferencing where people naturally take turns speaking. Shared explicit style has explicit sender selection and shared reservations and is similar to wildcard style except it provides better security by explicitly listing senders. Currently, there is no style defined with wildcard sender selection and distinct reservations. [IMAGE] Figure 3: IP over ATM network 2.3 RSVP flows As an example, consider a system with two senders (S1 and S2), two receivers (R1 and R2), and three routers (r1, r2, and r3) as shown above in figure . Assuming that the two receivers are requesting Berson Expiration: December 1996 [Page 6] Internet Draft Integrated Services and ATM June 1996 the same QoS, then the number of RSVP flows at the ATM edge device "r1" needed to support different reservation styles for this configuration can be determined. For a wildcard filter style, only one (point-to-multipoint) flow is needed as all senders for this group can use the shared reservation across the ATM network. For styles with explicit sender selection, assume that both senders are selected. For fixed filter style, three flows are needed, one QoS flow for each of the two senders explicitly listed and one best effort service flow to be shared among any other senders. For the shared explicit style, two flows are needed, one QoS flow to be shared among all the (i.e. two) explicitly listed senders, and one best effort service flow to be shared among the remaining senders. More generally, the following numbers of RSVP flows are created for different filter styles. For a reservation with wildcard filter (WF) style, there is only one RSVP flow, since all senders to a (multicast or unicast) session are part of the same reservation. For shared explicit (SE) style, there are two RSVP flows, one for the senders explicitly listed who receive reserved service, and one for any other senders who receive ordinary best effort service. Finally, the number of RSVP flows created by a fixed filter (FF) style reservation depends on the number of senders listed in the reservation message. If there are n senders listed in the message, then there are n+1 RSVP flows created, one for each of the n senders, and one additional flow for all senders that are not listed. 2.4 RSVP flows and VCs There are different approaches to mapping RSVP flows to ATM VCs. Two approaches are discussed in this draft, while a third remains for future work. Section 3 examines the VC per flow model, where each RSVP flow is mapped to a single ATM VC. This ATM VC can be a point-to-point or point-to-multipoint as appropriate. Section 4 examines the multiple VCs per RSVP flow model where a single flow can be forwarded into several VCs each with a different QoS. Other models allowing aggregation of RSVP flows into VCs (VC for multiple flows model) are being studied and will be briefly discussed in section 7. 3. Single VC per RSVP Flow One approach for mapping RSVP flows into VCs is to have a single (point-to-point or point-to-multipoint) VC for each RSVP flow. The potential problem with this scheme is that different receivers might request different qualities of service. In the "single VC per RSVP flow" model, this heterogeneity problem is handled by using the Berson Expiration: December 1996 [Page 7] Internet Draft Integrated Services and ATM June 1996 maximum of the requested resources of all the receivers of a session. The remainder of this section discusses the issue of dynamically changing the QoS of a VC. The following section allows more heterogeneity in reservations by using additional VCs. 3.1 Dynamic QoS RSVP provides dynamic quality of service (QoS) in that the resources that a reservation requests may change at any time. There are several common reasons for a change of reservation QoS. First, an existing receiver can request a new larger (or smaller) QoS if the current received quality is unacceptable. Second, a sender may change its traffic specification (TSpec), which can trigger a change in the reservation requests of the receivers. Third, a new sender can start sending to a multicast group with a larger traffic specification than existing senders, triggering larger reservations. Finally, a new receiver can make a reservation that is larger than existing reservations. If the merge node for the larger reservation is an ATM edge device, a new larger reservation must be set up across the ATM network. Since ATM service, as currently defined, does not allow renegotiating the QoS of a VC, dynamically changing the reservation means tearing down an established VC, and creating a new VC with the new QoS. Tearing down a VC and setting up a new VC in ATM are complex operations that involve a non-trivial amount of processor time, and have a substantial latency. To prevent excessive signalling load on an ATM network, timers can be used. Each ATM edge device is configured with a time parameter tau that gives the minimum amount of time the edge device will wait between successive changes of the QoS of a particular VC. Thus if the QoS of a VC is changed at time t, all messages that would change the QoS of that VC that arrive before time t+tau would be queued. If several messages changing the QoS of a VC arrive during the interval, redundant messages can be discarded. At time t+tau, the remaining change(s) of QoS, if any, can be executed. This timer approach would apply more generally to any network structure, and might be worthwhile to incorporate into RSVP. The sequence of events for a single VC would be 1. Wait if timer is active 2. Establish VC with new QoS Berson Expiration: December 1996 [Page 8] Internet Draft Integrated Services and ATM June 1996 3. Remap data traffic to new VC 4. Tear down old VC 5. Activate timer 3.2 Limitations There are two major problems with the single VC per RSVP flow approach. The first problem is that a user making a small or no reservation would get a "free ride" across the ATM network on any person(s) making a larger reservation. The second problem is that a user may want to join an existing VC at the established QoS level, but, because of a lack of resources, not be able to join. The rejected user would still like to receive the traffic on a best effort basis, which is the standard method of operation in the Internet. Preserving the homogeneous single VC per RSVP flow model in this case would mean tearing down the QoS VC, and replacing it with a single best effort VC. Clearly it is unacceptable to tear down one customer's existing QoS reservation because a second customer was not able to join the existing VC. A solution to both the "free ride" problem and the best effort service problem involves having multiple VCs carrying identical traffic which is the subject of the next section. 4. Multiple VCs per RSVP Flow The previous "single VC per RSVP flow" model had the advantage that each byte of data traffic was sent over the ATM network exactly once and each leaf of the VC received identical service. This homogeneous model is simple but does not take into account the situation that different users may demand (and be willing to pay for) different levels of service than others. This section discusses solutions to heterogeneous reservation requests from different receivers involving multiple VCs per RSVP flow. Two different approaches are discussed. The first approach requires at most two VCs per RSVP flow, one for best effort traffic, and the other for (homogeneous) QoS traffic. The other approach has one VC per QoS requested, and so potentially has an unlimited number of VCs per RSVP flow. 4.1 Two VCs per RSVP flow RSVP supports heterogeneous QoS, meaning that different receivers of the same multicast group can request a different QoS. But most importantly, some receivers might have no reservation at all, but want to receive the traffic on a best effort service basis. The IP model allows receivers to join a multicast group at any time on a best effort basis, and it is important that ATM as part of the Berson Expiration: December 1996 [Page 9] Internet Draft Integrated Services and ATM June 1996 Internet continue to provide this service. We define the "limited heterogeneity" model as the case where the receivers of a multicast session are limited to use either best effort service or a single alternate quality of service. The alternate QoS can be chosen either by higher level protocols or by dynamic renegotiation of QoS as described in the previous section. [IMAGE] Figure 4: Limited heterogeneity In order to support limited heterogeneity, each ATM edge device participating in a session would need at most two VCs. One VC would be a point-to-multipoint best effort service VC and would serve all best effort service IP destinations for this multicast group. The other VC would be a point to multipoint VC with QoS and would serve all IP destinations for this multicast group that have an RSVP reservation established. This is shown in figure where there are three receivers, R2 requesting best effort service, while R1 and R3 request distinct reservations. One point-to- multipoint VC is set up for best effort traffic which serves R2. Another VC is set up for the QoS traffic to receivers R1 and R3, using the maximum of R1 and R3's reservation. Note that though the VC and hence the QoS for R1 and R3 are the same within the ATM cloud, the reservation outside the ATM cloud (from router r4 to receiver R3) uses the QoS actually requested by R3. The disadvantage of the limited heterogeneity scheme is that each packet will need to be duplicated at the network layer and one copy sent into each of the 2 VCs. Looking at figure , there are two VCs going from router r1 to switch s1. Two copies of every packet will traverse the r1-s1 link. Depending on the network topology and group membership, there may be a large amount of duplicate traffic flowing over the ATM links. Note that two separate VCs for each session will not normally be needed. First, if all the receivers are making reservations, no best effort VC is needed. Second, the best effort traffic for all sessions with the same ATM destinations can be multiplexed on the same best effort VC. In the ideal case, there will be only one best effort VC for all the best effort traffic for all sessions on a single node. This will limit the number of VCs needed. 4.2 Many VCs per RSVP flow Instead of arbitrarily restricting an RSVP flow to at most two VCs, rules can be specified as to when a new QoS VC can be created Berson Expiration: December 1996 [Page 10] Internet Draft Integrated Services and ATM June 1996 (e.g. when the user is willing to pay). This gives a lot of flexibility to a service provider. Full heterogeneity is possible where a separate VC could be created for each distinct QoS for a multicast session. While we advocate the limited heterogeneity approach as in section 4.1, different service providers may choose alternate approaches. RSVP allows for local policy control [6] as well as admission control. Thus a user can request a reservation with a specific QoS and with a policy object that, for example, offers to pay for additional costs setting up a new VC. The policy module at the entry to a service provider can decide how to satisfy that request - either by merging the request in with an existing VC or by creating a new VC for this (and perhaps other) users. This policy can be on a user-provider basis where a user and a provider have an agreement on the type of service offered, or on a provider- provider basis, where two providers have such an agreement. With the ability to do local policy control, service providers can provide services best suited to their own resources and their customers desires. [IMAGE] Figure 5: Limited heterogeneity This is shown in figure . Whereas, in figure , R1 and R3 shared the same VC across the ATM network; in figure , R1 and R3 have a separate VC, so each receives precisely the resources requested. Note that while full heterogeneity gives users exactly what they request, it requires more resources of the network than limited heterogeneity. In figure , three copies of each packet are sent on the link from r1 to s1. Two copies of each packet are then sent from s1 to s2. As with limited heterogeneity, the exact amount of bandwidth dedicated to duplicate traffic depends on the network topology and group membership. 4.3 Making a reservation For the limited heterogeneity case, making an RSVP reservation will mean that a leaf of a point to multipoint VC will need to leave the best effort service VC and join as a new leaf of the QoS VC. If no QoS VC exists, a new QoS VC is created with the receiver as a leaf. If the new QoS leaf cannot be created, an error message will be sent and the user will continue receiving best effort service. If there is a QoS VC, but the QoS needs to be increased for the new reservation, a new VC with the larger QoS Berson Expiration: December 1996 [Page 11] Internet Draft Integrated Services and ATM June 1996 will be requested (for all QoS receivers). If the new VC request fails, the old QoS VC will remain, the new reservation will fail, and the new user will continue to receive best effort service. An RSVP reservation teardown will mean leaving the QoS VC and joining the best effort service VC. If no best effort VC exists, then one would be created. For the full heterogeneity model, making an RSVP reservation is similar to the limited heterogeneity case. The difference is that a change in reservation may attempt to switch a leaf from one QoS VC to another QoS VC. 5. RSVP VCs [NOTE - this section is RSVP specific] One last important issue is providing a data path for the RSVP messages themselves. As mentioned in section 2, there are two main types of messages, PATH and RESV. PATH messages are sent to a multicast address, while RESV messages are sent to a unicast address. Other RSVP messages are handled similar to either PATH or RESV. So ATM VCs used for RSVP signalling messages need to provide both unicast and multicast functionality. There are several different approaches for how to assign VCs to use for RSVP signalling messages. The main approaches are: o use same VC as data o single VC per session o single point-to-multipoint VC multiplexed among sessions o multiple point-to-point VCs multiplexed among sessions There are several different issues that affect the choice of how to assign VCs for RSVP signalling. One issue is the number of additional VCs needed for RSVP signalling. Related to this issue is the degree of multiplexing on the RSVP VCs. In general more multiplexing means less VCs. An additional issue is the latency in dynamically setting up new RSVP signalling VCs. A final issue is complexity of implementation. The remainder of this section discusses the issues and tradeoffs among these different approaches and suggests guidelines for when to use which alternative. Berson Expiration: December 1996 [Page 12] Internet Draft Integrated Services and ATM June 1996 5.1 Mixed data and control traffic In this scheme RSVP signalling messages are sent on the same VCs as is the data traffic. The main advantage of this scheme is that no additional VCs are needed beyond what is needed for the data traffic. An additional advantage is that there is no ATM signalling latency for PATH messages (which follow the same routing as the data messages). However there can be a major problem when data traffic on a VC is nonconforming. With nonconforming traffic, RSVP signalling messages may be dropped. While RSVP is resilient to a moderate level of dropped messages, excessive drops would lead to repeated tearing down and re- establishing QoS VCs, a very undesirable behavior for ATM. Due to these problems, this is not a good choice for providing RSVP signalling messages, even though the number of VCs needed for this scheme is minimized. One variation of this scheme that is hopeful but requires further study is to have a packet scheduling algorithm (before entering the ATM network) that gives priority to the RSVP signalling traffic. In this way, the ATM Cell Loss Priority (CLP) bit could be used to make sure that RSVP signalling messages only rarely get dropped. 5.2 Single RSVP VC per RSVP Flow In this scheme, there is a parallel RSVP signalling VC for each RSVP flow. This scheme results in twice the minimum number of VCs, but means that RSVP signalling messages have the advantage of a separate VC. This separate VC means that RSVP signalling messages have their own traffic contract and compliant signalling messages are not subject to dropping due to other noncompliant traffic (such as can happen with the scheme in section 5.1). The advantage of this scheme is its simplicity - whenever a data VC is created, a separate RSVP signalling VC is created. The disadvantage of the extra VC is that extra ATM signalling needs to be done. This scheme requires twice the minimum number of VCs and also additional latency, but is quite simple. This approach would tend to work well on hosts. 5.3 Multiplexed point-to-multipoint RSVP VCs In this scheme, there is a single point-to-multipoint RSVP signalling VC for each unique ingress router and unique set of egress routers. This scheme allows multiplexing of RSVP signalling traffic that shares the same ingress router and the Berson Expiration: December 1996 [Page 13] Internet Draft Integrated Services and ATM June 1996 same egress routers. This can save on the number of VCs, by multiplexing, but there are problems when the destinations of the multiplexed point-to-multipoint VCs are changing. Several alternatives exist in these cases, that have applicability in different situations. First, when the egress routers change, the ingress router can check if it already has a point-to-multipoint RSVP signalling VC for the new list of egress routers. If the RSVP signalling VC already exists, then the RSVP signalling traffic can be switched to this existing VC. If no such VC exists, one approach would be to create a new VC with the new list of egress routers. Other approaches include modifying the existing VC to add an egress router or using a separate new VC for the new egress routers. When a destination drops out of a group, an alternative would be to keep sending to the existing VC even though some traffic is wasted. The number of VCs used in this scheme is a function of traffic patterns across the ATM network, but is always less than the number used with the Single RSVP VC per data VC. In addition, existing best effort data VCs could be used for RSVP signalling. Reusing best effort VCs saves on the number of VCs at the cost of higher probability of RSVP signalling packet loss. One possible place where this scheme will work well is in the core of the network where there is the most opportunity to take advantage of the savings due to multiplexing. 5.4 Multiplexed point-to-point RSVP VCs In this scheme, multiple point-to-point RSVP signalling VCs are used for a single point-to-multipoint data VC. This scheme allows multiplexing of RSVP signalling traffic but requires the same traffic to be sent on each of several VCs. This scheme is quite flexible and allows a large amount of multiplexing. Since point- to-point VCs can set up a reverse channel at the same time as setting up the forward channel, this scheme could save substantially on signalling cost. In addition, signalling traffic could share existing best effort VCs. Sharing existing VCs reduces the total number of VCs needed, but might cause signalling traffic drops if there is congestion in the ATM network. This pt-pt scheme would work well in the core of the network where there is much opportunity for multiplexing. Also in the core of the network, RSVP VCs can stay permanently established either as Permanent Virtual Circuits (PVCs) or as long lived Switched Virtual Circuits (SVCs). The number of VCs in this scheme will depend on traffic patterns, but in the core of a network would be approximately n(n-1)/2 where n is the number of IP nodes in the network. In the core of the network, this will typically be small Berson Expiration: December 1996 [Page 14] Internet Draft Integrated Services and ATM June 1996 compared to the total number of VCs. 5.5 QoS for RSVP VCs There is an issue for what QoS, if any, to assign to the RSVP VCs. Two solutions have been covered in section 5.1 and in the shared best effort VC variation in section 5.4. For other RSVP VC schemes, a QoS (possibly best effort) will be needed. What QoS to use partially depends on the expected level of multiplexing that is being done on the VCs, and the expected reliability of best effort VCs. Since RSVP signalling is infrequent (typically every 30 seconds), only a relatively small QoS should be needed. This is important since using a larger QoS risks the VC setup being rejected for lack of resources. Falling back to best effort when a QoS call is rejected is possible, but if the ATM net is congested, there will likely be problems with with RSVP packet loss on the best effort VC also. Additional experimentation is needed in this area. 6. Additional issues There is an issue with VCs timing out as described in RFC1755, section 3.4 on VC Teardown. RFC1755 recommends tearing down a VC that is inactive for a certain length of time - 20 minutes is recommended. This timeout could mean that a valid VC with QoS that has been established with RSVP might be torn down unexpectedly. While this behavior is acceptable for best-effort traffic, it is important that if a reservation has been established on a VC, that the VC not be torn down. If there is no choice about the VC being torn down, the RSVP daemon must be notified, so a reservation failure message can be sent. Most of the previous discussion has been concerned with meshes of point-to-multipoint connections. An alternate approach is to use a MultiCast Server[1] (MCS). An MCS provides a relay node that forwards the multicast (e.g. PATH) messages. It is expected that all the previous discussion applies for an MCS as well as meshes, but further experimentation is needed. 7. Conclusions and Future Work We have described a scheme for deploying "classical" RSVP over IP over ATM. We have a prototype system using the limited heterogeneity model running at ISI and we are experimenting with it now. There are a number of other issues that are subjects of continuing research. These issues (and others) are covered in [2], and are briefly repeated here. Berson Expiration: December 1996 [Page 15] Internet Draft Integrated Services and ATM June 1996 One key issue is how to translate an Internet Integrated Services (IIS) QoS to an ATM QoS. Fortunately, this issue seems to be getting easier as the IETF and ATM Forum QoS definitions are getting more similar as they evolve. However there are still potential differences in traffic shaping and policing models. Additional coordination between the IETF and the ATM Forum in testing and standardizing a QoS translation is desirable now. A second issue is to consider the multiple RSVP flows per VC (or aggregation) model. With this model, large VCs could be set up between IP routers in an ATM network. These VCs could be managed the same as how IIS point-to-point links (e.g. T-1, DS-3) are managed now. Traffic from multiple sources over multiple multicast groups might be multiplexed on the same VC. This approach has a number of advantages. First, there is typically no signalling latency as VCs would be in existence when the traffic started flowing, so no time is wasted in setting up VCs. Second, the heterogeneity problem in full over ATM has been reduced to a solved problem. Finally, the dynamic QoS problem for ATM has also been reduced to a solved problem. The problem with this approach is that the choice of what QoS to use for which of the large VCs is difficult. If chosen poorly, there might be many VC setups failing while other bandwidth is unused. An additional problem is that the ability of ATM to do QoS dependent routing is wasted. ATM is currently close to a new standard (UNI 4.0) that promises certain advantages over the current UNI 3.1 version. Current work in the ATM Forum and ITU promises additional advantages. A final issue is to keep current with changes in ATM, and to keep this document up-to-date. Some specific issues are covered in [2,5]. REFERENCES [1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks," Internet Draft. [2] Borden, M., Crawley, E., Krawczyk, J, Baker, F., and Berson, S., "Issues for RSVP and Integrated Services over ATM," Internet Draft. [3] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification," Internet Draft. [4] Clark, D., Shenker, S., and Zhang, L., "Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanisms," SIGCOMM '92. [5] Demirtjis, A., Berson, S., Edwards, B., Maher, M., Braden, B., and Berson Expiration: December 1996 [Page 16] Internet Draft Integrated Services and ATM June 1996 Mankin, A., "RSVP and ATM Signalling," ATM Forum Contribution 96- 0258. [6] Herzog, S., "Building Blocks for Accounting and Access Control in RSVP," Internet Draft. [7] Katz, D., Piscitello, D., Cole, B., Luciani, J., "NBMA Next Hop Resolution Protocol (NHRP)," Internet Draft. [8] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and Malis, A., "ATM Signalling Support for IP over ATM," RFC 1755. [9] "ATM User-Network Interface (UNI) Specification - Version 3.1", Prentice Hall. [10] Braden, R., Clark, D., Shenker, S. "Integrated Services in the Internet Architecture: an Overview," RFC 1633, June 1994. [11] Laubach, M., "Classical IP and ARP over ATM," RFC1577, January 1994. [12] Zhang, L., Deering, S., Estrin, D., Shenker, S., Zappala, D., "RSVP: A New Resource ReSerVation Protocol," IEEE Network, September 1993. Security Considerations Security considerations have not been addressed in this draft. Author's Address Steven Berson USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: (310) 822-1511 EMail: berson@isi.edu Berson Expiration: December 1996 [Page 17]