Internet Engineering Task Force R. O. Onvural INTERNET DRAFT V. Srinivasan IBM 26 February 1996 A Framework for Supporting RSVP Flows Over ATM Networks draft-onvural-srinivasan-rsvp-atm-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 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 [1]. This document reviews various issues related to running RSVP and Integrated Service models over ATM and presents a model to address some of these issues. It is intended as a starting point for building an architectural framework to support RSVP/ATM Interworking. Onvural, Srinivasan Expires 31 August 1996 [Page i] Internet Draft RSVP over ATM Framework 26 February 1996 1. Introduction The focus of much recent work has been on identifying issues related to the efficient transport of RSVP flows over ATM networks [10,11,12,13,14,15,16]. This document proposes an architectural framework for supporting RSVP flows over ATM networks. Various areas addressed include: i) support for heterogeneous receivers ii) support for IntServ service models iii) mapping IP layer traffic parameters to ATM traffic parameters iv) support for RSVP merging capability v) support for RSVP filter specs vi) mapping RSVP best effort service to ATM tagging function vi) moving among different service levels vii) mapping guaranteed service delays to ATM maximum cell transfer delay At the time of writing this document, much activity is in progress within the IETF and ATM Forum in addressing issues related to RSVP-based services over ATM networks. Consequently, these topics may not yet be covered in detail in this version of the document, but will be included in future revisions. These topics include API issues, multicast short cuts and QoS routing, detailed traffic management mechanisms, end-system (host) considerations, and the role of network management, to name a few. The document is organized as follows: Section 2 is an overview of RSVP features, particularly as they relate to RSVP/ATM interworking. The intserv service models are reviewed in Section 3. Current capabilities provided in various ATM standards are visited in Section 4. The proposed model is introduced in section 5. 2. IETF Model Overview The IETF model to support real-time services uses the specification of a signaling protocol by the RSVP working group, and of service categories developed by the Integrated Services (intserv) working group. RSVP is a set up protocol used for resource reservation, designed to support integrated services over Internet [2]. It is an Internet style signaling protocol used by the hosts and network elements to request a specific Quality of Service (QoS) on behalf of an application data stream. IETF service categories defined by the intserv model allow a rich set of requirements to support different types of services over Internet. Onvural, Srinivasan Expires 31 August 1996 [Page 1] Internet Draft RSVP over ATM Framework 26 February 1996 The various features of RSVP can be summarized as follows: 1. RSVP requests resources in only one direction, e.g., for a simplex data stream. 2. RSVP operates on top of IP (either IPv4 or IP6), occupying the place of a transport protocol in the protocol stack. However, it is not used to transport application data. 3. RSVP is receiver-oriented. The receiver of a data flow initiates and maintains the resource reservation used for that flow. 4. It can be used to make resource reservations for both unicast and many-to-many multicast applications. 5. It provides features to dynamically adapt to changing group membership and changing routes. 6. RSVP is not a routing protocol and requires the services of unicast and multicast routing protocols. 7. It uses "soft state" in the routers. It generates periodic refresh messages to maintain the state along the reserved path(s); the state will automatically time out and be deleted in the absence of refreshes. 8. RSVP provides different reservation models or "styles" to fit a variety of applications. It provides transparent operation through routers that do not support it. In the remainder of this section, we briefly discuss several of these features of RSVP. RSVP defines a session as a data flow with a particular destination and transport-layer protocol, and treats each session independently. An RSVP reservation request consists of a flow descriptor, composed of a flowspec and a filter spec. The flowspec includes the specification of a service class and two sets of numeric parameters: an "Rspec" that defines the desired QoS and a "Tspec" that describes the data flow. Filter specs may be used to select arbitrary subsets of the packets in a given session. Such subsets might be defined in terms of senders (i.e., sender IP address and generalized source port), in terms of a higher-level protocol, or generally in terms of any fields in any protocol headers in the packet. Following the notation used in the RSVP specification, we use the terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flows. RSVP reservation request messages originate at receivers and are passed upstream towards the sender(s). When a reservation request is received at a node, two general actions are taken: (i) Make a reservation: The flowspec and the filter spec are first used by the admission control module that determines the admissibility of the request. If this test fails, the reservation is rejected and RSVP returns an error message to the appropriate receiver(s). If admission control succeeds, the node uses the Onvural, Srinivasan Expires 31 August 1996 [Page 2] Internet Draft RSVP over ATM Framework 26 February 1996 flowspec to set up the packet scheduler for the desired QoS and the filter spec to set the packet classifier to select the appropriate data packets. (ii) Forward the request upstream: The reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request. The reservation request that a node forwards upstream may differ from the request that it received from downstream. In particular, it is possible for the traffic control mechanism to modify the flowspec hop-by-hop. Reservations for the same sender (or a particular group of senders) from different downstream branches of the multicast tree(s) are merged as reservations travel upstream. In this case, a node forwards upstream only the reservation request with the "maximum" flowspec. In particular, a successful reservation request propagates as far as the closest point(s) along the sink tree to the sender(s) where there is an existing reservation level equal to or greater than that being requested. At that point, the arriving request is dropped in favor of the equal or larger reservation in place. The basic RSVP reservation model is "one pass": a receiver sends a reservation request upstream, and each node in the path either accepts or rejects the request. This scheme provides no easy way for a receiver to find out the resulting end-to-end service. RSVP supports an enhancement to one-pass service known as "One Pass With Advertising" (OPWA) [2]. With OPWA, RSVP control packets are sent downstream, following the data paths, to gather information that may be used to predict the end-to-end QoS. These advertisements are delivered by RSVP to the receiver hosts and perhaps to the receiver applications. They may then be used by the receiver to construct, or to dynamically adjust, an appropriate reservation request. A reservation request includes a set of control options, collectively called the reservation style. There are two options defined: (i) distinct or shared and (ii) explicit or wildcard. The first option concerns the treatment of reservations for different senders within the same session: establish a distinct reservation for each upstream sender or make a single reservation that is shared among selected senders. The second option controls the selection of senders: an explicit list of senders or a wildcard that implicitly selects all the senders to the session. Wildcard-Filter (WF) Style: A single reservation is made for the flows of all upstream senders in a particular group. This reservation may be thought of as a shared "pipe", whose size is the largest of the resource requests from all receivers, independent of the number of senders using it. Symbolically, WF-style reservation request is represented by WF( * Q) where the asterisk represents wildcard sender selection and Q represents the flowspec. Onvural, Srinivasan Expires 31 August 1996 [Page 3] Internet Draft RSVP over ATM Framework 26 February 1996 Fixed-Filter (FF) Style: A distinct reservation is required for each sender. A sender doesn't share the same reservation with other senders' packets for the same session. The total reservation on a link for a given session is the total of all FF reservations in the session. On the other hand, FF reservations requested by different receivers from the same sender are merged to share a single reservation. Symbolically, an FF reservation request is represented by FF( SQ), where S is the selected sender and Q is the corresponding flowspec. Shared Explicit (SE) Style: A single shared reservation is created into which flows from a particular group of upstream senders are mixed. Similar to the FF style, the SE style allows a receiver to explicitly specify the set of senders. Symbolically, an SE reservation request is represented by SE( (S1,S2,...)Q ), where S1, S2, ... is the list of senders and Q is the corresponding flow spec. Both WF and SE are shared reservations, appropriate for multicast applications in which it is unlikely that multiple data sources transmits simultaneously, for example audio conferencing. The FF style creates independent reservations for the flows from different senders, e.g., video conferencing. There are two fundamental RSVP message types: RESV and PATH. Each RSVP sender host transmits RSVP PATH messages downstream along the uni-/multicast routes provided by the routing protocol(s), following the paths of the data. PATH messages cause path states to be established in each node along the way. A PATH message may optionally carry a package of OPWA advertising information, known as an Adspec. An Adspec received in a PATH message is passed to the local traffic control, which returns an updated Adspec which is then forwarded downstream. Each sender host periodically sends a PATH message containing a description of each data stream it originates. The PATH message travels from a sender to receiver(s) along the same path(s) used by the data packets. The IP source address of a PATH message is an address of the sender it describes, while the destination address is the DestAddress for the session. These addresses assure that the message will be correctly routed through a non-RSVP cloud. Each receiver host sends RSVP reservation request (RESV) messages upstream towards the senders. RESV messages are sent hop-by-hop; each RSVP-speaking node forwards a RESV message to the unicast address of a previous RSVP hop. These reservation messages must follow exactly the reverse of the routes the data packets will use, upstream to all the sender hosts included in the sender selection. RESV messages must be delivered to the sender hosts themselves so that the hosts can set up appropriate traffic control parameters for the first hop. The IP destination address of a RESV message is the unicast address of a previous-hop node, obtained from the path state. The IP source address is an address of the node Onvural, Srinivasan Expires 31 August 1996 [Page 4] Internet Draft RSVP over ATM Framework 26 February 1996 that sent the message. In addition to PATH and RESV messages, two messages are used to terminate a session: PTEAR and RTEAR. A PTEAR message deletes path state, and a RTEAR message deletes reservation state. RSVP also includes error messages to report exception events. In the following section, we briefly discuss the various service specifications being studied by the intserv working group of the IETF. These services use RSVP as the signaling mechanism to obtain QoS from the network. We also identify some of the issues involved in supporting the intserv services over ATM networks. 3. Integrated Services Overview The IETF's Integrated Services (intserv) working group is studying several service specifications in the form of Internet Drafts [4,5,6,7]. The purpose of these services is to support the transport of audio, video, real time, and data traffic within a single network infrastructure. The current intserv service specifications include: Guaranteed Delay, Controlled Delay, Predictive, and Controlled Load. Packet delay is the only QoS metric that is quantified within the intserv model. Packet loss, in general, is required to be "low," without any quantitative measures provided or specified as a no-loss service. The Guaranteed Delay class [4] provides firm bounds on the maximum end-to-end packet transfer delay for each session using this service. Every packet from a session conforming to its declared traffic behavior is guaranteed a deterministic (with probability 1) end-to-end delay bound by this service. A rate is reserved at each node that a session from this class traverses. The end-to-end bound, then, is comprised of three parts: the delay experienced by a perfect fluid source with a dedicated "pipe" across the network with a bandwidth equal to the reserved rate, and two error terms that account for deviations from the fluid model and fixed delays along the path. The Guaranteed Delay class provides a lossless service. Controlled Delay service [5] offers applications several levels of delays to choose from. Currently, these levels of services are defined in a way that service level 1 is expected to be better than service level 2, which in turn is expected to be better than service level 3. The delay experienced by packets is controlled in the sense that all three levels of services have better average delays than that of best effort service. However, no assurances about the absolute levels of delay are made. For each level of service, a network element provides an estimate of the maximum delay that Onvural, Srinivasan Expires 31 August 1996 [Page 5] Internet Draft RSVP over ATM Framework 26 February 1996 packets experience over a time period T. Three such intervals are defined: 1 sec, 60 sec, and 3600 sec. In order to obtain estimates of the packet delays over the different time intervals, it is necessary for the network element to take measurements and average these over some set of time intervals. There is no requirement, however, for these measurements to be exact. The Predictive Service class [6] in the intserv model is designed for applications which desire a reserved rate with low packet loss and a maximum bound on end-to-end delay. It differs from the guaranteed delay class however in that occasional late or lost packets can be tolerated. The delay bound is required to be quantified. However, as is the case with the other intserv specifications, the allowable rate of packet loss (except for Guaranteed Delay, which is a lossless service) and delay bound violation is not quantified but simply required to be "very low." Similar to the Controlled Delay class, the Predictive Service specification defines three logical levels of service, each associated with a delay bound with level 1 having the smallest delay and level 3 having the largest. Each Predictive Service module advertises the delay bound as well as measurements of the maximum delay over three different time scales for each of the three levels (twelve quantities in total). The reservation required by an application is specified by the delay level its flow must use at each node along its path. The Controlled Load class is the most minimal of the intserv services in terms of the guarantees provided to sessions. There is only a single level of service associated with this class -- a session can expect to receive, under all conditions, service closely resembling the service which the same session would receive using best-effort delivery under "unloaded" network conditions [7]. The term "unloaded" refers to a "not heavily loaded or congested" network. 4. ATM Standards Overview The ATM Forum Traffic Management (TM) Specification 4.0 [11] enhances the QoS support in an ATM network by extending UNI 3.1 QoS service categories to include individual QoS parameters. In addition, it defines an Available Bit Rate (ABR) service to support best effort traffic effectively in the network. Various ATM service categories defined in UNI 4.0 are Constant Bit Rate (CBR), Real-Time Variable Bit Rate (rt-VBR), Non Real-Time Variable Bit Rate (nrt-VBR), Available Bit Rate (ABR), and Unspecified Bit Rate (UBR). There are also four QoS Classes used to map application requirements, ranging from the very strict circuit emulation to the much less stringent connectionless data transfer, to an ATM connection. Together, QoS Onvural, Srinivasan Expires 31 August 1996 [Page 6] Internet Draft RSVP over ATM Framework 26 February 1996 Classes and service categories map connection traffic characteristics and QoS requirements to network behavior. Various features included in UNI 4.0 include [9]: Point-to-point Calls Point-to-multipoint Calls Leaf Initiated Join Capability Notification of end-to-end Connection Completion ATM Anycast capability (Note 1) Multiple signalling channels Switched Virtual Path (VP) service Proxy signalling Frame Discard Capability (Note 3) ABR Signaling for Point-to-point Calls Generic Identifier Transport Traffic Parameter Negotiation Signalling of Individual QoS Parameters Supplementary Services Direct Dialing In (DDI) Multiple Subscriber Number (MSN) Subaddressing (SUB) (Note 2) User-user Signalling (UUS) Note 1 - This feature is optional for public networks/switching systems and is mandatory for private networks/switching systems. Note 2 - This feature is mandatory for networks/switching systems (public and private) that support only native E.164 address formats. Note 3 - Transport of the Frame Discard indication is Mandatory. Similarly, various capabilities are available in ITU Q.29xx Recommendations. Q.2962 allows the negotiation of the peak cell rate during the call set up. Q.2963 allows peak rate renegotiation (potentially sustainable cell rate and burst size) after the connection set up. Q.298x allows multiple connections to be established for a call. Q.2957 provides user-to-user signaling thereby allowing information exchange during the set up or when the connection is in an active state. 5. Overview of the Working Model 5.1. Objectives The RSVP/ATM interworking function model is developed with the following objectives: Onvural, Srinivasan Expires 31 August 1996 [Page 7] Internet Draft RSVP over ATM Framework 26 February 1996 1. Use existing RFCs and Internet Drafts while imposing minimal, if any, changes to them; 2. Use currently available ATM standards (that are developed by both ATM Forum and ITU) with minimal, if any, changes to them, and 3. Define the required functions in the context of a RSVP Coordination Entity (RCE) thereby allowing a variety of physical configurations that may be configured depending on the specifics of a particular environment. 5.2. Model and Scope of Operation In the proposed model, we consider a network of RSVP-capable routers and hosts with an ATM network providing connectivity between them. These routers are connected to an ATM network via a UNI, and hence are required to support SVC signaling. The scope of the ATM cloud is assumed to be identical to that of a single MARS cluster [17]. We assume that the ATM cloud is served by a MARS that provides resolution of IP multicast addresses to ATM addresses of IP endpoints in the cluster. The interworking function is developed based on a logical function called a RSVP Coordination Entity (RCE). An RCE is required to perform the following functions: 1. ATM multicast. 2. Support ATM UNI (other interfaces such as PNNI may be supported through simple extensions). 3. RSVP capabilities: in this context, RSVP capabilities refer to the ability of the network element to understand, act upon, update and generate RSVP control messages, as required by the RSVP protocol. 4. Interact with the MARS to resolve IP multicast addresses to ATM addresses. RCEs are used to efficiently support various RSVP features over ATM. In particular, various capabilities provided in an RCE include: 1. Efficient merging of RSVP flows: RCEs are points along the end-to-end paths of single or multiple RSVP flows where RSVP merging capability, based on RSVP filters, is provided. There may be one or more RCEs along an end-to-end path. 2. Efficient establishment and maintenance of multicast trees at the ATM layer. 3. Support for receiver heterogeneity in order to provide different levels of QoS. 4. Translation of Tspec into ATM traffic parameters. 5. Translation of Rspec into ATM quality of service framework. Onvural, Srinivasan Expires 31 August 1996 [Page 8] Internet Draft RSVP over ATM Framework 26 February 1996 There may be one or more RCEs present within a MARS cluster. There is no restriction on where the RCE function may reside. In particular, an RCE may be physically resident at a host, a router, or an ATM switch. The actual placement of RCE(s) may depend on various administrative and performance constraints. For illustrative purposes, let us consider a MARS cluster with a Sender, S1, an RCE (RCE1) and a receiver, R1. 1. S1 originates (or forwards) a PATH message on a control VCC to RCE1 2. RCE1 issues a MARS_REQUEST to the MARS to resolve the IP multicast address of the destination group included in the PATH message 3. MARS responds with the ATM address(es) of the members of the group 4. RCE1 assigns a multicast tree id to this session as identified in the path message (if one does not exist already) 5. RCE1 uses control VCCs to forward the PATH message to the endpoints specified in the MARS response message. These control VCCs are point-to-point virtual channels. 6. Endpoints process the PATH message as defined in the RSVP protocol At this time, there are no resources reserved in the ATM network for this session. 7. R1 initiates a RESV message to be transferred back to RCE1. A LEAF INITIATED JOIN message is generated at the receiver's interface with the root option (i.e., the message will be forwarded to the root) where the root of the multicast tree is RCE1. This requires the use of an additional information element at the LEAF INITIATED JOIN message. 8. RCE1 performs RSVP processing based on the information element included in the LEAF INITIATED JOIN message, sets up a new multicast tree or extends an existing multicast tree to that leaf, and forwards the RESV message (if needed) upstream. Alternatively, RCE1 could use a control VCC to send the RESV message to LNE1. Various details of RCE processing such as updating the PATH message, etc. are omitted in this example for reasons of clarity. In particular, topics that need elaboration include: (a) Control connections and their usage. (b) Data connections: establishment, tear-down, and usage. (c) Advertisement of a single multicast identifier or Generic Call Identifier that corresponds to an RSVP session identifier. (d) Handling of RESV messages. (e) The operation of multiple RCEs. We address these issues in the following sections. Onvural, Srinivasan Expires 31 August 1996 [Page 9] Internet Draft RSVP over ATM Framework 26 February 1996 5.3. The RCE Model Consider a MARS cluster with multiple RCEs. Without loss of generality, network elements that have a PATH message for transmission over the ATM network are referred to as Senders. The PATH message may have originated external to the ATM cloud. Accordingly, the ATM end station (i.e., a router, a host, a switch) that accesses the ATM cloud for an RSVP session does not have to be actual originator of the PATH message. Nevertheless, we will refer to this network element as a Sender (for the ATM cloud). Similarly, we will use the term Receiver to refer to the network element attached to the ATM network from which the RSVP messages leave the ATM cloud. Each Sender may have a control VCC to one or more RCEs (either a PVC or an SVC). However, only one RCE is chosen to handle the PATH messages at any given time. The RCE that serves a Sender may be configured dynamically by means of: 1. A preassigned VCC to determine the address of the RCE (perhaps from a configuration server), or 2. ATM ILMI procedures may be used dynamically. Control connections between a Sender and an RCE are bidirectional point-to-point connections. Upon receiving a PATH message from a Sender, an RCE performs various functions that include: - Processing and updating PATH messages as required in RSVP processing - Forwarding PATH messages towards the receivers - Assigning a multicast tree id to this flow, if one was not assigned already In forwarding the PATH message, an RCE uses the appropriate control VCC towards the destination. If there are one or more other RCEs on the route from the RCE that first forwarded the PATH message towards the receiver(s), these other RCEs may or may not be required to process and update the PATH message. Either option has its advantages and disadvantages and these need to be carefully weighed before this decision can be made. However, no resource reservation is made in the ATM network as the PATH message travels from its Sender towards the Receiver. The control VCCs are long-lived and may use ABR, UBR, or VBR traffic class with parameters requiring minimal resource reservation. Processing and updating a PATH message involves saving path state in the RCE and updating the Adspec, if present. The Adspec cannot be updated accurately at this stage as no end-to-end path has been established yet (a path from the Sender to RCE is not established as well). Hence, the best RCE can do at this stage is to update the Onvural, Srinivasan Expires 31 August 1996 [Page 10] Internet Draft RSVP over ATM Framework 26 February 1996 Adspec with an estimate. Different approaches to update Adspec are reviewed in [8]. When a RESV message arrives at the edge of an ATM network, the Receiver can use either UNI 4.0 Leaf Initiated Join (LIJ) procedures to add itself to the multicast tree, or it may use control VCCs to transport RESV messages to the root of the tree. The root of this tree is the first RCE to which the Sender transmitted its initial PATH message. NOTE: Extensions to multiple RCE environment in which the LIJ request travels towards the root via more than one RCE (and perhaps stops being forwarded by one of these RCEs based on the RSVP filter spec/merge functions) can be incorporated relatively easily and will be included in the future versions of this document. LIJ has two modes: with or without root notification. In this proposal, we use the LIJ with root-prompted join mode in which the root handles the join request. Furthermore, we assume here that an information element to carry the related contents of the RESV message is made available in the LIJ capability. Which fields of the RESV message are to be included in this information element is for further study. Alternatively, the RESV message can be sent to the RCE using the same bidirectional control VCC on which the PATH message arrived to the receiver. This would require the receiver to maintain an an association (in a table) between RSVP sessions and control VCCs in order to be able to send the RESV message to the same RCE from which the PATH was received. The choice of using the LIJ mechanism with appropriate information elements, or a control VCC to send the RESV message, will depend on the particular environment. For instance, in environments that support UNI 4.0, it might be simpler to leverage the LIJ function provided by UNI 4.0. On the other hand, in environments that support UNI 3.0/3.1 which do not include LIJ capability, the control VCC option is more appropriate. As discussed in the next section, we assume there are only a few different service levels that needs to be supported in a service model. For example, there are only three levels of services in the controlled delay and predictive service models. Controlled load only has a single service level. While Guaranteed delay service can have a very large number of different rates requested in the Rspec, we assume it is possible to categorize different rates that may be requested for an application to a few distinct values. Based on this framework, RCE can establish different multicast trees, so that Onvural, Srinivasan Expires 31 August 1996 [Page 11] Internet Draft RSVP over ATM Framework 26 February 1996 a particular multicast tree will support receivers with the same service requirement within a session. It is noted that only one multicast tree identifier is used by an RSVP session. Although there will be multiple multicast trees used to support different service levels, each tree does not support the LIJ capability (i.e., they are not made visible outside the ATM cloud). When the root RCE receives the corresponding indication to add a new leaf, it first processes the RESV message to determine the type of the service requested by the receiver. The next step is to determine the multicast tree that best matches the service requirement of the receiver. Then, an ADD PARTY message is sent to add the Receiver to the corresponding multicast tree. 5.3.1. Control Connections and Their Usage Control VCCs can be established using permanent VCCs or switched VCCs. Most likely, these VCCs will use UBR or ABR traffic class service. These connections are used only to pass the PATH and RESV messages from one edge of the network to another. RCEs also use control VCCs to communicate with each other (i.e., forward RSVP messages and related information). Control VCCs are bidirectional, point-to-point connections. 5.3.2. Data connections Data connections that originate at RCEs are always point-to-multipoint connections. Data connections that originate at the Senders, established to an RCE, are always point-to-point VCCs. The traffic category and QoS class requested for a connection depends on receiver requirements. 5.3.3. Advertisement of a single multicast identifier An RCE can advertise a single multicast identifier that corresponds to an RSVP session identifier. This needs to be handled by network management or by other off line means. 5.3.4. Handling RESV messages There is no need to keep forwarding RESV messages for established sessions within an ATM cloud. If the connection is terminated for some reason within the ATM cloud, this will be reported to one or Onvural, Srinivasan Expires 31 August 1996 [Page 12] Internet Draft RSVP over ATM Framework 26 February 1996 more UNIs in the network and the RSVP user will be notified. If a connection is terminated outside the ATM cloud, then the Receiver will receive this message and terminate the connection using ATM signaling procedures. If the RESV message is for a change in the service quality, then this will be treated as if it is a new RESV message, as discussed later in this document. 5.3.5. Operation of Multiple RCEs The details of the operation of multiple RCEs within an ATM cloud are for further study. 5.4. Supporting RSVP features over ATM 5.4.1. Heterogeneous Receivers RSVP provides means to support "heterogeneous receivers". That is, different receivers of a particular flow may ask different service levels from the network. ATM architecture, on the other hand, require all receivers of a point-to-multipoint connection to have the same QoS. One trivial way to support heterogeneous receivers in ATM is to establish different point-to-point connections to each receiver that take into consideration the QoS requirement of the application explicitly. Another alternative is to establish a point-to-multipoint connection with the most stringent QoS requirements of all receivers. The first solution requires managing potentially very large number of point-to-point VCs and does not scale well. The latter proposal solves this scalability problem but results in overallocation of resources in the ATM network. Although there can be thousands of receivers in a session, different levels of quality of service that may be requested by receivers are expected to be a small number. In particular, for each intserv service model, we have: Guaranteed service This is a lossless service in which end-to-end delay experienced by packets in a flow is guaranteed to be less than or equal to a maximum value specified by the receiver. This value is specified by the receiver as a clearing rate R. Although the granularity of R is 1 byte/sec in the RSVP spec, different R's that may be specified for a particular application may be classified into a few values. Controlled Delay Service Onvural, Srinivasan Expires 31 August 1996 [Page 13] Internet Draft RSVP over ATM Framework 26 February 1996 Currently, three levels of services are defined in the controlled service such that service level 1 is expected to be better than service level 2, which in turn is expected to be better than service level 3. The delay experienced by packets is controlled in the sense that all three levels of services have better average delays than that of best effort service. However, no assurances about the absolute levels of delay can be made. It is possible to provision these three levels of delays in the ATM network that meet the service requirements of the controlled service. In this case, receivers request only one of three possible service values. The delay values provided in each service level may be updated using ILMI or offline (network management) at time intervals when the network can not provide the specified delay values (for new connections) or when it can provide significantly better delay values. Predictive Service Predictive service offers applications a number of long term end-to-end delays to choose from. Similar to controlled service, different values of delay values provided in the ATM network may be pre-specified and updated as needed. The number of different delay values provided in the ATM network to support this service is expected to be a small number as well. Controlled Load Service There is only a single level of service associated with this class -- a session can expect to receive, under all conditions, a service closely resembling the service which the same session would receive using best-effort delivery under "unloaded" network conditions. Again the delay value associated with this service in the ATM network can be easily provisioned and updated over long intervals of time as needed. Assuming that different delay values that may be requested by a receiver for each IntServ service model can be classified into a smaller set, the service requirement of a flow from a particular receiver can be supported in the current ATM signaling easily by associating the QoS requirements of service models to ATM QoS classes and using UNI 4.0 maximum cell transfer delay, maximum cell delay variation, cell loss ratio parameters. 5.4.2. Moving between different service levels RSVP allows receivers to change their previously requested service levels depending on their service requirement and their observation of the performance they are currently receiving. Accordingly, Onvural, Srinivasan Expires 31 August 1996 [Page 14] Internet Draft RSVP over ATM Framework 26 February 1996 applications can move to a higher level (better delay) or to a lower level throughout the duration of their session. One trivial method to support this requirement is to terminate the existing connection and establish a new ATM connection based on the most recent service requirement. This solution may impose a significant signaling load to the ATM network, thereby restricting establishment of new connections. In the proposed model, handling service modifications is more efficient than terminating/establishing end-to-end connections. In particular, service intelligence can be easily incorporated into the RCE to support this RSVP feature. For example, if there is already a multicast tree established for the most recently requested service level, then this request can be easily satisfied by dropping the leaf from the current tree and adding it to another that matches the request most closely. This would impose minimal signaling load to the network while meeting the service requirement. 5.4.3. Best Effort Service when resources are not available Another RSVP feature allows receivers to receive the flow in a best-effort manner. In particular, RSVP prevents denial-of-service attacks via reservations by not allowing the network elements to simply drop non-conforming packets. Both Guaranteed and Controlled Load service models assign non-conformant packets to best-effort status (which may result in packet drops if there is congestion). The ATM service model has a similar feature in which non-conforming traffic is tagged and allowed to enter the network. Marked ATM cells are dropped in the intermediate switches if there is not enough resource available to transmit these cells without causing service degradation to conforming traffic. The number of non-conforming cells before a connection is classified non-compliant is network specific. Hence, it is possible to support RSVP best effort packets in ATM using ATM's tagging feature. Early Packet Discard (EPD) schemes may be used in the network elements to increase the effective resource utilization without impacting the service quality to the receiver (as if one or more cells of a packet is dropped in the network, the rest of the information carried in arrived cells at the receiver may not be useful for the application). 5.4.4. Flow aggregation Flow aggregation occurs in the proposed model only at the RCEs. Each RCE terminates incoming flows and originating outgoing flows. Accordingly, supporting flow aggregation can be achieved easily at the RCEs by multiplexing traffic from incoming connections (VCs) to Onvural, Srinivasan Expires 31 August 1996 [Page 15] Internet Draft RSVP over ATM Framework 26 February 1996 an outgoing connection (VC). The multiplexing needs to take into consideration the service levels provided in each outgoing connection and may be required to use more than one VC to support different service requirements. 5.4.5. Mapping RSVP parameters RSVP Tspec maps into ATM traffic parameters in a straightforward manner. Tspec also specifies which ATM traffic class may be used for the connection. Tspec includes the peak rate of the connection and the leaky bucket parameters that matches (after the values are adjusted) the ATM traffic parameters. If the peak rate is equal to the token generation rate (or close enough), CBR service category may be used. Otherwise, it is a variable bit rate connection. ATM defines three different variable bit rate traffic classes i.e., VBR, UBR, ABR. The choice among these three would depend on the service requirement of the receiver which requires for the RCE to wait for the RESV message. Rspec in the RESV message may then be used to determine which ATM traffic category may be used for the ATM connection, together with the QoS profiles defined in the network associated with each QoS class. Note that ATM traffic categories and QoS classes do not have a one-to-one relationship and may be combined in any way that fits the application requirements. RSVP Rspec does not map into any ATM QoS class directly. However, as discussed in section 4.2.1, it is possible to pre-define and manage semi-dynamically various service profiles that can match RSVP service models. 5.4.6. Directly attached ATM hosts In this framework, an ATM host with RCE functionality may use RSVP without the need to support other routing functions (i.e., it does not have to be a router). 5.4.7. Packet level/cell level traffic parameter mapping The RSVP TSpec can be mapped to ATM traffic descriptors in a straightforward manner. A description of this mapping is provided in [8]. Briefly summarizing, if we ignore the segmentation overhead and effects of the granularity of ATM cell size, the following mapping can be used: SCR = r / 48; MBS = b / 48; PCR = P / 48, Onvural, Srinivasan Expires 31 August 1996 [Page 16] Internet Draft RSVP over ATM Framework 26 February 1996 where r and b are the token generation rate and bucket depth, and P corresponds to the minimum of the incoming link and the actual peak rate of the flow (currently, the TSpec does not include a peak rate for any intserv service classes; inclusion of this parameter is currently under study). The above relations can be modified to include the effect of segmentation overhead as: SCR = ar; MBS = ab; PCR = aP where a = (1 + ceil(p / 48)) / p represents the worst case overhead due to the ATM segmentation with AAL5 and a minimum packets size of p (in bytes). The "ceil" operator corresponds to the ceiling function. Further refinements to these relations can be found in [8]. 6. Summary The main objective of this document is to outline a framework to provide RSVP/ATM interworking. The proposed approach takes advantage of the ATM transfer capabilities while supporting RSVP features efficiently. There are several areas that needs to be satisfactorily addressed for this document to be complete. However, several of the related issues have been studied and various solutions do exist to fill in the gaps. We believe those areas that are yet to be addressed may be satisfactorily resolved within the proposed framework. 7. Acknowledgments Rao Cherukuri, Dean Skidmore and Wayne Pace have patiently spent long hours with us, discussing several ideas presented in this document and their contributions are greatly appreciated. 8. References [1] R. Braden, D. Clark, S. Shenker, Integrated Services in the Internet Architecture: an Overview, RFC 1633, June 1994. [2] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin., Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. Internet Draft, draft-ietf-rsvp-spec-10. February 1996. [3] R. Cole, D. Shur, C. Villamizar. IP over ATM: A Framework Document. Internet Draft, draft-ietf-ipatm-framework-doc-07, February 1996. Onvural, Srinivasan Expires 31 August 1996 [Page 17] Internet Draft RSVP over ATM Framework 26 February 1996 [4] S. Shenker and C. Partridge. "Specification of Guaranteed Quality of Service (draft-ietf-intserv-guaranteed- svc-03.txt)." INTERNET-DRAFT, Internet Engineering Task Force - Integrated Services WG, November 1995. [5] S. Shenker, C. Partridge, and JJ. Wroclawski. "Specification of Controlled Delay Quality of Service (draft-ietf-intserv-control-del-svc-02.txt)." INTERNET-DRAFT, Internet Engineering Task Force - Integrated Services WG, November 1995. [6] S. Shenker, C. Partridge, B. Davie, and L. Breslau. "Specification of Predictive Quality of Service (draft-ietf-intserv-predictive-svc-01.txt)." INTERNET-DRAFT, Internet Engineering Task Force - Integrated Services WG, November 1995. [7] J. Wroclawski. "Specification of the Controlled-Load Network Element Service (draft-ietf-intserv-ctrl-load- svc-01.txt)." INTERNET-DRAFT, Internet Engineering Task Force - Integrated Services WG, November 1995. [8] A. Birman, V. Firoiu, R. Guerin, and D. Kandlur. "Provisioning of RSVP-Based Services over Large ATM Networks." IBM Research Report No. RC 20250, October 1995. Available from IBM Research Web Server (CyberJournal) at URL: http://www.watson.ibm.com:8080/. [9] "Draft of UNI Signalling 4.0", ATM Forum/95-1434R8, December 1995. [10] M. Borden, E. Crawley, B. Davie, and S. Batsell. "Integration of Real-time Services in an IP-ATM Network Architecture," RFC 1821, August 1995. [11] "Traffic Management Specification 4.0", ATM Forum/95-0013R10, December 1995. [12] ATM Forum Contribution 96-0096, "Issues in Mapping INTSERV service specifications to ATM Service Categories", R. Onvural, S. Rampal, V. Srinivasan, R. Balay [13] ATM Forum Contribution 96-0094, "Issues in Extending Unicast and Multicast RSVP Flows Across ATM Networks", R. Guerin, D. Kandlur [14] ATM Forum Contribution 96-0097, "RSVP and Integrated Services over ATM and API", R. Guerin, V. Srinivasan, D. Skidmore, R. Cherukuri, D. Kandlur, R. Onvural [15] ATM Forum Contribution 96-0160, "Interworking between IETF RSVP Signaling Protocol and ATM Signaling", R. Cherukuri and D. Skidmore Onvural, Srinivasan Expires 31 August 1996 [Page 18] Internet Draft RSVP over ATM Framework 26 February 1996 [16] ATM Forum Contribution 96-0258, "RSVP and MPOA", S. Berson [17] G. Armitage, "Support for Multicast over UNI 3.1 based ATM Networks", Internet Draft, IP over ATM Working Group, draft-ietf- ipatm-ipmc-12.txt, February 1996. 9. Authors' Address Raif O. Onvural IBM Corporation BUA/664 Research Triangle Park, NC 27709 Phone: +1-919-254-4687 Fax: +1-919-254-5410 E-mail: onvural@vnet.ibm.com Vijay Srinivasan IBM Corporation BUA/664 Research Triangle Park, NC 27709 Phone: +1-919-254-2730 Fax: +1-919-254-5410 E-mail: vijay@raleigh.ibm.com Onvural, Srinivasan Expires 31 August 1996 [Page 19]