Internet Engineering Task Force A. Birman INTERNET DRAFT R. Guerin D. Kandlur IBM 22 February 1996 Support for RSVP-based Service over an ATM Network draft-birman-ipatm-rsvpatm-00.txt 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, and 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.'' To learn the current status of any Internet-Draft, please check the ``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 In this document we focus on RSVP-based resource reservations in a heterogeneous environment which includes ATM networks. We describe a method for establishing 'shortcuts' through an ATM network which avoids the performance penalty associated with level 3 processing in a 'classical RSVP over ATM' approach. For the case of guaranteed service we show how to map the RSVP flow characteristics to ATM call parameters, and thus enable end-to-end performance guarantees. We also discuss the extensions to RSVP and to ATM signaling required for the implementation of these solutions. Birman, Guerin, Kandlur Expires 31 August 1996 [Page i] Internet Draft RSVP over ATM 22 February 1996 1. Introduction We consider a heterogeneous environment in which legacy networks coexist with ATM networks. For applications that require performance guarantees the reservation of network resources is carried out using RSVP as the reservation setup protocol. The operation of RSVP over an ATM network is the focus of our paper. Our starting point is the classical IP over ATM model [Lau94] in which an ATMARP server is used for address resolution within a LIS, while the inter-LIS traffic is routed through IP routers. For an application with QoS requirements the classical IP over ATM architecture does allow for QoS support over the VCCs between the routers. This solution is not altogether satisfactory, however, since it may not provide the QoS which would be possible if a direct VCC through the ATM network was established along the path through the ATM network. Such a direct connection, first proposed in [Mil95] and referred to as a 'shortcut', eliminates the level 3 processing at the routers and thus allows better performance. We describe below a method to establish such shortcuts over ATM networks, first for unicast and then multicast application flows (for additional details see [BFG+95]). We refer to this approach as 'classical RSVP over ATM with shortcuts'. The approach described here has, without doubt, shortcomings. Some of these can be traced to the differences between RSVP and ATM signaling ([For94],[For95]), and their opposing design principles. This approach is offered as a possible first step in supporting QoS flows in a heterogeneous environment with ATM networks. If adopted and carried through to implementation, the experience thus gathered may be beneficial in the design of a better next scheme. 2. Reservation setup for unicast flows We first consider unicast flows. The parameters necessary for setting up VCCs with QoS guarantees are obtained from RSVP messages Path and Resv. 2.1. Classical RSVP over ATM Figure 1 shows an ATM network consisting of four LISs. A is the ingress router to the ATM network, B is the egress router. RSVP messages follow the IP route AEFGB. Thus, a Path message will travel downstream from A to B, while the corresponding Resv message will travel upstream from B to A. When the Resv message arrives at G the router has sufficient information to set up a VC from G to B. Birman, Guerin, Kandlur Expires 31 August 1996 [Page 1] Internet Draft RSVP over ATM 22 February 1996 Similarly, VCs will be set up from F to G, from E to F, and from A to E. In particular, if the ATM network consists of a single LIS then the route from A to B has only one hop, although there could be multiple hops at the ATM level. For the multi-hop case, while RSVP messages travel over best-effort VCs, data packets flow over QoS VCs and enjoy QoS support in the routers. Traversing the routers, however, entails IP-level processing and thus is less desirable than a shortcut VC from A to B. In the rest of this section we discuss several schemes for RSVP support using ATM shortcuts. 2.2. ATM shortcuts In this scheme, we modify the RSVP operation in order to identify the appropriate egress router for the purpose of establishing a shortcut route through the ATM network. When the first Path message for a session arrives at A (Figure 2), the node determines that the message will be forwarded over an ATM link and thus node A is the ingress node into the ATM network. The Path message is routed along the default IP route, and is modified to carry both the ATM address and the IP address of A (the IP address of A is the `previous hop' or PHOP). At each node along the route an ATM connectivity check is performed to determine whether the current node is the egress point from the ATM network. This decision would be based on the ATM connectivity between the current router, the upstream router, and the downstream router as determined by the logical ATM network in which +-+ +-+ +-+ +-+ +-+ --->|A|------>|E|------>|F|------>|G|------>|B|---> +-+ +-+ +-+ +-+ +-+ LIS 1 LIS 2 LIS 3 LIS 4 <-------> <-------> <-------> <-------> ATM network <--------------------------------------> Figure 1: Reservation setup using ``classical'' RSVP support Birman, Guerin, Kandlur Expires 31 August 1996 [Page 2] Internet Draft RSVP over ATM 22 February 1996 they reside (the concept of the logical ATM network as described in [KP95]). If the current router is not an egress router, it forwards the Path message to the downstream router without updating the PHOP address field. If the current router is an egress router (e.g. B) it processes the Path message by creating a Path state for the session and by storing, along with other data, the IP address and the ATM address of A. A Resv message is considered new when it represents either a reservation requests for a new flow or a request to modify the reservation of an existing flow. When such a Resv message arrives at B, B inserts its own ATM address as an object into this message, and forwards the message along the default routed path to A. Intermediate routers recognize the Resv message but do not create any session or reservation and simply forward the message upstream. When this Resv message arrives at A it carries in addition to the regular RSVP information, both the ATM address of the egress router B and QoS information necessary to determine the type of ATM VC that needs to be setup. Since intermediate nodes do not need to process the Resv message, an alternative here is to encapsulate the Resv message into an IP datagram that is then tunneled from B to A. Tunneling provides the advantage that packet processing is expedited (along the fast-path through the router) since there is no special processing at intermediate nodes. On the other hand, the packet is not treated as a signaling packet and is susceptible to normal loss at intermediate nodes. After the shortcut VC from A to B is set up, B needs to be able to associate the newly created VC with the RSVP flow. In order to achieve this, the flow identifier consisting of the tuple (sourceIPaddress;destinationIPaddress; transportlayer) is carried in the SETUP message in the Broadband High Layer Information (B-HLI) element (the length of this field would have to be extended from its current size of 8 bytes). The source and destination IP addresses cannot be inferred from the ATM addresses in the router--router case. The source and destination addresses themselves further consist of pairs of the form (IPaddress;portnumber): Note also that the receipt of the SETUP message provides an implicit acknowledgment that the Resv message was received at router A. This means that router A also has received all the information necessary to forward Resv messages upstream, i.e. the RSVP filter Birman, Guerin, Kandlur Expires 31 August 1996 [Page 3] Internet Draft RSVP over ATM 22 February 1996 and service specifications that are not directly available from the ATM connection characteristics. As a result, the egress router B now suppresses the transmission of Resv refreshes towards router A, unless they carry a modified service specification. Figure 2 shows a shortcut VC from A to B which bypasses nodes E, F and G. The shortcut VC is used for the RSVP data traffic, but Path messages continue to flow along the default routed path. It is noted that this scheme for creating shortcut routes is independent of the underlying routing mechanism and is oblivious to any IP routing domain boundaries. Moreover, RSVP state is required only in the edge routers A and B. A possible variation to the method described above handles Path messages the same way, but differs from it in that it shifts the responsibility of establishing the ATM shortcut VC from the ingress router A to the egress router B (see Figure 2). This is possible because ATM unicast calls are always duplex, and resources can be reserved in both directions. Specifically, when a Resv message arrives at the egress router B, B can generate a SETUP message towards A and specify the resources required in both directions. The SETUP message will specify QoS requirements in the direction A to B to accommodate the service specifications carried in the Resv message. Conversely, it will not request any QoS or bandwidth guarantees from B to A since there is no data flow in this direction. While the VC setup is now handled by the egress router, it is still necessary to forward the Resv message +-+ +-+ +-+ +-+ +-+ --->|A|------>|E|------>|F|------>|G|------>|B|---> +-+ +-+ +-+ +-+ +-+ : : : VC : ....................................... ATM network <--------------------------------------> Figure 2: Reservation setup using ATM shortcuts Birman, Guerin, Kandlur Expires 31 August 1996 [Page 4] Internet Draft RSVP over ATM 22 February 1996 to the ingress router, so that it can propagate that information upstream (it cannot be accurately inferred for the traffic and QoS parameters carried in the SETUP message). In order to do that, Resv messages including refreshes for reliability purposes, will keep on being forwarded onto the IP route. However, as with the previous method, they are not acted upon at intermediate routers. Another alternative is to include the Resv message as higher layer information in the SETUP message. The main advantage of this scheme is that it is consistent with the preferred solution for multicast flows when the LIJ capability of UNI 4.0 becomes available (see Section 3.2 for details). 3. Reservation setup for multicast flows We consider two methods for establishing shortcuts through an ATM network. The ``root-initiated ATM shortcut'' is better suited to the present UNI 3.1 environment, while the ``leaf-initiated ATM shortcut'' would be preferred when the leaf-initiated join capability of UNI 4.0 becomes available. 3.1. Root-initiated ATM shortcuts We start by extending the unicast scheme of Section 2.2 to single-sender multicast flows, as illustrated in Figure 3. As mentioned before, this is the approach best suited to a UNI 3.1 environment. The determination of the ATM shortcut follows the same steps as in Section 2.2. When a Path message for a session arrives at node A, the node determines that the message will be forwarded over an ATM link and thus node A is the ingress node into the ATM network (note that this step only needs to be performed upon receipt of the first Path message). The ATM address of A is inserted as an object into the Path message, which is fowarded onto the default IP route. In addition, a mechanism such as MARS [Arm95] is used for local multicast delivery on this path. At each node along the route an ATM connectivity check is again performed to determine whether the current node is an egress point from the logical ATM network. If the current node, such as F in Figure 3, is not an egress point then the Path message is forwarded to the downstream nodes without updating the PHOP (previous hop) address field. When the first Resv message arrives at an egress point, say B, B forwards the message along the reverse path to A. The ATM address of B is carried as an object in the Resv message. Intermediate Birman, Guerin, Kandlur Expires 31 August 1996 [Page 5] Internet Draft RSVP over ATM 22 February 1996 +-+ +-+ +-+ +-+ --->|A|------>|E|------>|F|----------->|B|---> +-+ +-+ +-+ +-+ | | +-+ +---------------------->|C|---> +-+ ATM network <----------------------------------> Figure 3: Reservation setup with maximum shortcut routers, F and E in this case, simply forward the message upstream towards A. Specifically, they do not merge Resv messages and do not perform any reservation. As in the unicast case, an alternative is to tunnel the Resv message directly to A by encapsulating it into an IP message. When the first Resv message arrives at A, say from B, A has all the information necessary to create a shortcut point-to-multipoint VC with root A and leaf B. In order for B to associate the newly created VC with the RSVP flow, the flow identifier consisting of the pair (sourceIPaddress; destinationIPaddress) is carried in the SETUP message in the Broadband High Layer Information (B-HLI) element. Later, when the Resv message from C arrives at A, A adds C to the point-to-multipoint VC with an ADD PARTY signaling message. The ADD PARTY message will also carry the flow identifier in the B-HLI element. In order to track route changes and changes in group membership, Path refresh messages keep flowing normally over the IP route. However, Resv refreshes from each router are suppressed as soon as the egress router receives the ATM setup message (ADD PARTY or SETUP for the first leaf). This is because the setup message indicates that the initial Resv message has been received by the ingress router, and that the reservation through the ATM network has been successfully performed. This suppression prevents the steady state implosion of refresh Resv messages at the ingress router. Birman, Guerin, Kandlur Expires 31 August 1996 [Page 6] Internet Draft RSVP over ATM 22 February 1996 However, the ingress router is still required to perform as many ATM connection SETUPs as there are leaves in the ATM network for the multicast address. This is because, the scheme always results in the use of a ``maximum'' ATM shortcut between the ingress and egress routers. The use of a maximum shortcut minimizes IP-level processing at intermediate nodes and thus shortens end-to-end packet delays, but the (signaling) load imposed on the ingress router may become a problem when dealing with large multicast groups. Milliken [MillikenJul9501] proposed a scheme which is intended to alleviate the problem by distributing the (signaling) processing load among the routers. This load distribution is achieved by allowing some flexibility at each router on deciding whether or not to extend an ATM shortcut. A more promising and systematic approach to eliminate the possibility of signaling overload at the ingress router, it to use the Leaf-Initiated Join (LIJ) capability of of UNI 4.0. We discuss such a solution in the next section. 3.2. Leaf-initiated ATM shortcuts Consider the ATM network in Figure 3 and assume the flow of Path messages is as described in the previous section. That is, Path messages continue to use the default IP routed path, and a mechanism such as MARS is used for local multicast delivery on this path. As before, the Path message processing at intermediate routers is changed, in that the PHOP is not modified, while the Path message carries the ATM address of A. In addition, A also chooses a ``global connection identifier'' (GCID) and inserts it into the Path message. This global connection identifier consists of a call identifier uniquely chosen by the root, which is paired with the root's ATM address for LIJ setup. For a given RSVP session, there may be multiple flows transiting through A and, for each flow, A would choose a distinct global connection identifier. This connection identifier will be used by egress routers when generating an ATM LIJ request to join the point-to-multipoint connection associated with the IP multicast address. When the first Resv message reaches an egress router, say B, the router has all the information needed for generating an LIJ request to the GCID it received. The ATM point-to-multipoint connection is then created at this time, with the ingress router A as its root and B as the first leaf. As other egress routers, such as C in Figure 3, also receive their first Resv message, they signal their intention to join the connection in exactly the same manner, i.e. through a LIJ request to the specified GCID. They are then added as new leaves to the existing point-to-multipoint connection, but the ingress router A is not notified of this new join. This eliminates Birman, Guerin, Kandlur Expires 31 August 1996 [Page 7] Internet Draft RSVP over ATM 22 February 1996 the potential processing overload at router A since it is only required to handle a single signaling request, i.e. when the first leaf joins. However, note that as a result of not notifying the ingress router of new leaves joining, the information carried in the Resv messages arriving at the associated egress routers is not forwarded to the ingress router during the ATM setup process. This information is, however, necessary for the ingress router to further propagate Resv messages upstream, i.e. it needs information elements such as the RSVP service and filter specifications, which as mentioned before cannot always be directly inferred from the ATM traffic and QoS parameters. In order to achieve this, Resv messages, including refreshes, will continue to be propagated and merged on the IP path, but no reservation will be triggered at intermediate routers. The merging on the IP path ensures that the ingress router is not overwhelmed by the volume of refresh Resv messages it receives, while providing it with all the information it needs to forward Resv messages to its upstream neighbor. Note that even refreshes are sent in order to ensure reliable delivery of Resv messages to the ingress router. 4. Issues Related to Flow/Call Characteristics The previous sections have dealt with many of the issues related to the mapping between RSVP and ATM control flows. In this section, we focus on similar problems but at the level of the data flows. Specifically, we consider issues related to the mapping of traffic parameters and QoS guarantees as well as connection types. 4.1. Flow mapping RSVP defines a session as the set of data flows with the same (unicast or multicast) destination. As a result, at an endpoint of a flow (sender or receiver) the data flow is uniquely identified by the pair (sourceIPaddress;destinationIPaddress): The source and destination addresses themselves further consist of pairs of the form (IPaddress;portnumber); where the destination IP address can be a multicast IP address. The ATM UNI identifies a connection through the Connection Identifier used in the SETUP, CONNECT, etc. messages. Connection Identifier is associated to an ATM flow from one sender to one or more receivers and is unique at the sender. A call can be uniquely identified Birman, Guerin, Kandlur Expires 31 August 1996 [Page 8] Internet Draft RSVP over ATM 22 February 1996 in the ATM network by the pair (Connection Identifier, sender ATM address). Similarly, in ATM UNI 4.0 which introduces the Leaf Initiated Join (LIJ) capability, each LIJ capable call is uniquely identified by a Global Call Identifier (GCID). The GCID is formed by pairing the LIJ call identifier selected by the the ``ROOT'' of the call (point-to-multipoint connection) and the address of the ROOT itself. Network wide uniqueness is, therefore, ensured. From the above discussion, we see that a node at the boundary between IP and ATM networks can map the quadruplet (source IP address, source port number, destination IP address, destination port number) that uniquely identifies an RSVP flow, to an ATM GCID consisting of (call identifier, sender ATM address). 4.2. Traffic and QoS handling Traffic and QoS specifications are not defined in RSVP. They are deferred to the int-serv IETF draft documents. The Guaranteed Delay int-serv draft [SP95] defines the traffic specification (TSpec) as consisting of a token bucket with a given bucket depth b (in bytes) specifying the maximum allowed burst size for the flow, a bucket rate r (in bytes/second) giving the average rate of the flow, and a peak rate p (in bytes/second) giving the maximum transmission rate of the flow at the source. This traffic specification can be mapped into the corresponding ATM traffic parameters, which are specified in cell-based measures. [SP95] defines the service specification (RSpec), and a procedure that describes how the RSpec is determined as a function of the delay requirements of the flow and the capabilities of the service elements (routers) on its path. The end-to-end delay d and the associated service specifications for the flow are not quantities that are initially provided explicitly. Rather, they are determined at the receiver upon receipt of the Path message carrying the values of the ``error terms'' Ctot= Sum Ci and Dtot = Sum Di, which have been accumulated on the connection's path. The terms Ci and Di correspond to the error contributed by router i when compared to a perfect fluid service model. The RSVP and Int-Serv documents suggest that the resource reservation for a flow from S to D with guaranteed delay requirement is performed in the following way. The source S generates Path messages that contain the traffic characterization (TSpec)of the flow. The Path message, therefore, includes the parameters b, r, p, and two fields Ctot and Dtot which are both initialized to 0. At router i, these fields are incremented using the local values Ci and Birman, Guerin, Kandlur Expires 31 August 1996 [Page 9] Internet Draft RSVP over ATM 22 February 1996 Di: Ctot:= Ctot+Ci; Dtot:= Dtot+ Di At the receiver D, a desired end-to-end delay d is selected, and the required clearing rate R is computed as: R = max(r, ((b + Ctot) / (d - Dtot))) The clearing rate R is then loaded in the RSpec included in the Resv message sent towards S. A key aspect of the above approach, that complicates the interactions with ATM is the decoupling between the advertising (accumulation of Ctot and Dtot as the Path message progresses) and the reservation phases (request for allocation of the clearing rate R). The main issue at the boundary of an ATM network is to determine which values to select for the terms CATM and DATM, when updating the Ctot and Dtot fields in the Path message. Also, delay guarantees based on the specification of a clearing rate may not always be supported by ATM switches and can not be readily expressed through ATM signaling. Hence, the ATM network has to be accounted for as a fixed delay component of the path. This requires information about (a) the ingress and egress points (routers) of the ATM network, (b) a delay bound, DATM, on the flow between the ingress and egress points. The first item is available at the egress point as the Path message exits from the ATM network (as outlined in Section 2.2). The second item may be obtained by the egress router by querying the ATM network to find the best delay that can be guaranteed for a flow with the specific endpoints. While this information is not currently accessible over an ATM UNI, it is available as part of the ATM PNNI control information. The egress router would then be responsible for updating the Ctot and Dtot fields as the Path message exits from the ATM network (intermediate routers would leave these fields unmodified). This mechanism for updating the advertizement information at the egress points is consistent for both unicast and multicast flows. 5. Impact on RSVP and ATM signaling In this document we proposed a method for supporting RSVP-based resource reservations in a heterogeneous environment which includes ATM networks. This method, classical RSVP over ATM with shortcuts, requires a number of modifications to RSVP and to ATM signaling. We review here these requirements. Birman, Guerin, Kandlur Expires 31 August 1996 [Page 10] Internet Draft RSVP over ATM 22 February 1996 5.1. Modifications to RSVP in the UNI 3.1 environment In this environment, the general approach we take can be characterized as root oriented. This means that most of the interactions with the ATM signaling needed to extend RSVP flows across ATM networks, originate in the ingress router. Such extensions require a number of modifications to the processing of Path and Resv messages. The first step at the ingress router is to identify that the flow is to cross an ATM network and should, therefore, be handled differently. Once this has been determined, subsequent modifications to the Path message handling vary somewhat as a function of the approach used. Typically, the Path message will be forwarded on the normal IP path, and extended to carry the ATM address of the ingress router. Path processing is also different at intermediate (non-egress) routers which do not update the PHOP field, so that it still points to the ingress router, and do not maintain state information. This helps lower the processing overhead for such messages. In addition, the Dtot field (and Ctot) is not updated until the Path message reaches the egress router(s), where it is incremented by an estimate of the maximum delay the ATM network would contribute. Path messages continue flowing on the IP route even after an ATM VC shortcut has been established for the flow. The processing of Resv messages is also affected when crossing ATM networks. They are used to trigger the establishment of an ATM shortcut when received at an egress router(s). The connection request originates from the ingress router (ADD-PARTY for multicast flows, or SETUP for unicast flows) upon receipt of a new Resv message from an egress router. This Resv message carries the standard RSVP information, i.e. filter and service specifications, that are needed by the ingress router to forward Resv messages to its upstream neighbor. The Resv message also contains the ATM address of the egress router as well as the delay guarantees needed for the connection across the ATM network. Note that the receipt of the SETUP (or ADD-PARTY for multicast flows) at an egress router provides an implicit acknowledgment that the ingress router has received the Resv message and that the ATM reservation has been successful. Finally, refresh Resv messages are suppressed, i.e. not forwarded on the IP path, and connection liveness is guaranteed by ATM mechanisms. 5.2. Modifications to RSVP in the UNI 4.0 environment The major enhancement in UNI 4.0, from the point-of-view of RSVP support, is the LIJ ability in point-to-multipoint connections. This Birman, Guerin, Kandlur Expires 31 August 1996 [Page 11] Internet Draft RSVP over ATM 22 February 1996 allows us to use a leaf oriented approach to support RSVP flows (both unicast and multicast) which ensures better scalability. The handling of Path messages remain essentially as for the UNI 3.1 case, in that they are forwarded on the normal IP path but not processed at intermediate routers, i.e. PHOP field and OPWA objects are not modified and no state is created. In addition to carrying the ATM address of the ingress router, the Path message also carries a global ATM call identifier (GCID) in the case of multicast flows. This GCID is then specified in the LIJ message generated by egress routers upon receipt of a new Resv message, when they want to join an existing point-to-multipoint connection associated with a given multicast flow. In the case of a unicast flow, the egress router simply initiates a SETUP to the ATM address of the ingress router. Because in the leaf oriented approach the egress routers are responsible for the establishment of ATM connections, it is not necessary to forward Resv messages to the ingress router for that purpose. However, it is still necessary to transmit the RSVP information contained in the Resv message (filter and service specifications) to the ingress router, so that it can propagate it upstream. This is achieved by forwarding all Resv messages (including refreshes for reliability) on the IP route to the ingress router. Note that although Resv messages are processed at intermediate routers they are not acted upon, i.e. merging of Resv messages will take place when required but no reservations will be triggered and no state is maintained. 5.3. Modifications and extensions to ATM signaling As stated above, it is clear that many of the extensions to be included in UNI 4.0 are key to an efficient support of RSVP flows across ATM networks. Foremost among them is the LIJ capability, which is critical to handle large multicast connections. This capability should, however, be such that different leaves are allowed to specify different service requirements. Other desirable extensions to be included in UNI 4.0 are the ability to renegotiate the characteristics of an established connection, and a B-HLI field larger than its current 8 bytes. There are, however, other desirable extensions which may not be provided in UNI 4.0. One such example, is the ability for an RSVP router to query the ATM network for the best delay that can be guaranteed to a given destination. This can be achieved either by allowing ``soft'' requests, or by supporting both ``desired'' and ``acceptable'' QoS parameters. As a second example, the ability to let the root of a point-to-multipoint call assign a GCID even before Birman, Guerin, Kandlur Expires 31 August 1996 [Page 12] Internet Draft RSVP over ATM 22 February 1996 any leaf has requested to join, could simplify some of the processing when establishing such calls. 6. References [Arm95] G. Armitage, "Support for Multicast over UNI 3.1 based ATM Networks", Internet Draft, draft-ietf-ipatm-ipmc-10.txt, December 1995. [BFG+95] A. Birman, V. Firoiu, R. Guerin and D. Kandlur, "Provisioning of RSVP-based Services over a Large ATM Network", IBM Research Report RC20250, October 1995. [BZB+96] 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.txt, February 1996. [For94] ATM Forum, "ATM User-Network Interface Specifications, Version 3.1", September 1994. [For95] ATM Forum, "ATM User-Network Interface Specifications, Version 4.0", ATM Forum/94-1018. [KP95] D. Katz and D. Piscitello, "NBMA Next Hop Resolution Protocol (NHRP)", Internet Draft, draft-ietf-rolc-nhrp-07.txt, December 1995. [Lau94] M. Laubach, "Classical IP and ARP over ATM", Internet Draft, Internet RFC1577, January 1994. [Mil95] W. Milliken, "Integrated Services IP Multicasting over ATM", Internet Draft, draft-ietf-milliken-ipatm-services-00.txt, July 1995. [SP95] S. Shenker and C. Partridge, "Specification of Guaranteed Quality of Service", Internet Draft, draft-ietf-intserv-guaranteed- svc-03.txt, December 1995. 7. Authors' Address Alex Birman T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532 Phone: +1-914-784-7275 Birman, Guerin, Kandlur Expires 31 August 1996 [Page 13] Internet Draft RSVP over ATM 22 February 1996 E-mail: birman@watson.ibm.com Roch Guerin T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532 Phone: +1-914-784-7038 E-mail: guerin@watson.ibm.com Dilip Kandlur T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532 Phone: +1-914-784-7722 E-mail: kandlur@watson.ibm.com Birman, Guerin, Kandlur Expires 31 August 1996 [Page 14]