idnits 2.17.1 draft-onvural-srinivasan-rsvp-atm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 23 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (26 February 1996) is 10259 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 826, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '1') == Outdated reference: A later version (-15) exists of draft-ietf-rsvp-spec-10 -- Unexpected draft version: The latest known version of draft-ietf-ipatm-framework-doc is -06, but you're referring to -07. ** Downref: Normative reference to an Informational draft: draft-ietf-ipatm-framework-doc (ref. '3') -- No information found for draft-ietf-intserv-guaranteed- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' -- No information found for draft-ietf-intserv-ctrl-load- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 1821 (ref. '10') -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Unexpected draft version: The latest known version of draft-ietf-ipatm-ipmc is -11, but you're referring to -12. (However, the state information for draft-ietf-intserv-ctrl-load- is not up-to-date. The last update was unsuccessful) Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. O. Onvural 2 INTERNET DRAFT V. Srinivasan 3 IBM 4 26 February 1996 6 A Framework for Supporting RSVP Flows Over ATM Networks 7 draft-onvural-srinivasan-rsvp-atm-00.txt 9 Status of This Memo 11 This document is an Internet-Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as 19 reference material, or to cite them other than as a ``working draft'' 20 or ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the internet-drafts 24 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Abstract 30 The RSVP and Integrated Services working groups have been working 31 towards the goal of an "Integrated Services Internet" where 32 applications can request a Quality of Service (QoS) from the 33 network in order to meet their end-to-end service requirements 34 [1]. This document reviews various issues related to running RSVP 35 and Integrated Service models over ATM and presents a model to 36 address some of these issues. It is intended as a starting point for 37 building an architectural framework to support RSVP/ATM Interworking. 39 1. Introduction 41 The focus of much recent work has been on identifying issues 42 related to the efficient transport of RSVP flows over ATM networks 43 [10,11,12,13,14,15,16]. This document proposes an architectural 44 framework for supporting RSVP flows over ATM networks. Various areas 45 addressed include: 47 i) support for heterogeneous receivers 48 ii) support for IntServ service models 49 iii) mapping IP layer traffic parameters to ATM traffic parameters 50 iv) support for RSVP merging capability 51 v) support for RSVP filter specs 52 vi) mapping RSVP best effort service to ATM tagging function 53 vi) moving among different service levels 54 vii) mapping guaranteed service delays to ATM maximum cell transfer 55 delay 57 At the time of writing this document, much activity is in progress 58 within the IETF and ATM Forum in addressing issues related to 59 RSVP-based services over ATM networks. Consequently, these topics 60 may not yet be covered in detail in this version of the document, 61 but will be included in future revisions. These topics include 62 API issues, multicast short cuts and QoS routing, detailed traffic 63 management mechanisms, end-system (host) considerations, and the role 64 of network management, to name a few. 66 The document is organized as follows: Section 2 is an overview of 67 RSVP features, particularly as they relate to RSVP/ATM interworking. 68 The intserv service models are reviewed in Section 3. Current 69 capabilities provided in various ATM standards are visited in Section 70 4. The proposed model is introduced in section 5. 72 2. IETF Model Overview 74 The IETF model to support real-time services uses the specification 75 of a signaling protocol by the RSVP working group, and of service 76 categories developed by the Integrated Services (intserv) working 77 group. RSVP is a set up protocol used for resource reservation, 78 designed to support integrated services over Internet [2]. It is 79 an Internet style signaling protocol used by the hosts and network 80 elements to request a specific Quality of Service (QoS) on behalf of 81 an application data stream. IETF service categories defined by the 82 intserv model allow a rich set of requirements to support different 83 types of services over Internet. 85 The various features of RSVP can be summarized as follows: 86 1. RSVP requests resources in only one direction, e.g., for a 87 simplex data stream. 88 2. RSVP operates on top of IP (either IPv4 or IP6), occupying the 89 place of a transport protocol in the protocol stack. However, it is 90 not used to transport application data. 91 3. RSVP is receiver-oriented. The receiver of a data flow initiates 92 and maintains the resource reservation used for that flow. 93 4. It can be used to make resource reservations for both unicast and 94 many-to-many multicast applications. 95 5. It provides features to dynamically adapt to changing group 96 membership and changing routes. 97 6. RSVP is not a routing protocol and requires the services of 98 unicast and multicast routing protocols. 99 7. It uses "soft state" in the routers. It generates periodic 100 refresh messages to maintain the state along the reserved path(s); 101 the state will automatically time out and be deleted in the absence 102 of refreshes. 103 8. RSVP provides different reservation models or "styles" to fit a 104 variety of applications. It provides transparent operation through 105 routers that do not support it. 107 In the remainder of this section, we briefly discuss several of 108 these features of RSVP. RSVP defines a session as a data flow with 109 a particular destination and transport-layer protocol, and treats 110 each session independently. An RSVP reservation request consists of 111 a flow descriptor, composed of a flowspec and a filter spec. The 112 flowspec includes the specification of a service class and two sets 113 of numeric parameters: an "Rspec" that defines the desired QoS and 114 a "Tspec" that describes the data flow. Filter specs may be used to 115 select arbitrary subsets of the packets in a given session. Such 116 subsets might be defined in terms of senders (i.e., sender IP address 117 and generalized source port), in terms of a higher-level protocol, 118 or generally in terms of any fields in any protocol headers in the 119 packet. Following the notation used in the RSVP specification, we 120 use the terms "upstream" vs. "downstream", "previous hop" vs. "next 121 hop", and "incoming interface" vs "outgoing interface" with respect 122 to the direction of data flows. RSVP reservation request messages 123 originate at receivers and are passed upstream towards the sender(s). 125 When a reservation request is received at a node, two general actions 126 are taken: 127 (i) Make a reservation: The flowspec and the filter spec are 128 first used by the admission control module that determines the 129 admissibility of the request. If this test fails, the reservation 130 is rejected and RSVP returns an error message to the appropriate 131 receiver(s). If admission control succeeds, the node uses the 132 flowspec to set up the packet scheduler for the desired QoS and the 133 filter spec to set the packet classifier to select the appropriate 134 data packets. (ii) Forward the request upstream: The reservation 135 request is propagated upstream towards the appropriate senders. 136 The set of sender hosts to which a given reservation request is 137 propagated is called the "scope" of that request. 139 The reservation request that a node forwards upstream may differ from 140 the request that it received from downstream. In particular, it is 141 possible for the traffic control mechanism to modify the flowspec 142 hop-by-hop. Reservations for the same sender (or a particular group 143 of senders) from different downstream branches of the multicast 144 tree(s) are merged as reservations travel upstream. In this case, 145 a node forwards upstream only the reservation request with the 146 "maximum" flowspec. In particular, a successful reservation request 147 propagates as far as the closest point(s) along the sink tree to 148 the sender(s) where there is an existing reservation level equal to 149 or greater than that being requested. At that point, the arriving 150 request is dropped in favor of the equal or larger reservation in 151 place. The basic RSVP reservation model is "one pass": a receiver 152 sends a reservation request upstream, and each node in the path 153 either accepts or rejects the request. This scheme provides no easy 154 way for a receiver to find out the resulting end-to-end service. 155 RSVP supports an enhancement to one-pass service known as "One Pass 156 With Advertising" (OPWA) [2]. With OPWA, RSVP control packets are 157 sent downstream, following the data paths, to gather information that 158 may be used to predict the end-to-end QoS. These advertisements are 159 delivered by RSVP to the receiver hosts and perhaps to the receiver 160 applications. They may then be used by the receiver to construct, or 161 to dynamically adjust, an appropriate reservation request. 163 A reservation request includes a set of control options, collectively 164 called the reservation style. There are two options defined: (i) 165 distinct or shared and (ii) explicit or wildcard. The first option 166 concerns the treatment of reservations for different senders within 167 the same session: establish a distinct reservation for each upstream 168 sender or make a single reservation that is shared among selected 169 senders. The second option controls the selection of senders: an 170 explicit list of senders or a wildcard that implicitly selects all 171 the senders to the session. 173 Wildcard-Filter (WF) Style: A single reservation is made for 174 the flows of all upstream senders in a particular group. This 175 reservation may be thought of as a shared "pipe", whose size is the 176 largest of the resource requests from all receivers, independent 177 of the number of senders using it. Symbolically, WF-style 178 reservation request is represented by WF( * Q) where the asterisk 179 represents wildcard sender selection and Q represents the flowspec. 181 Fixed-Filter (FF) Style: A distinct reservation is required for 182 each sender. A sender doesn't share the same reservation with 183 other senders' packets for the same session. The total reservation 184 on a link for a given session is the total of all FF reservations 185 in the session. On the other hand, FF reservations requested by 186 different receivers from the same sender are merged to share a single 187 reservation. Symbolically, an FF reservation request is represented 188 by FF( SQ), where S is the selected sender and Q is the corresponding 189 flowspec. 191 Shared Explicit (SE) Style: A single shared reservation is created 192 into which flows from a particular group of upstream senders are 193 mixed. Similar to the FF style, the SE style allows a receiver 194 to explicitly specify the set of senders. Symbolically, an SE 195 reservation request is represented by SE( (S1,S2,...)Q ), where S1, 196 S2, ... is the list of senders and Q is the corresponding flow spec. 197 Both WF and SE are shared reservations, appropriate for multicast 198 applications in which it is unlikely that multiple data sources 199 transmits simultaneously, for example audio conferencing. The FF 200 style creates independent reservations for the flows from different 201 senders, e.g., video conferencing. 203 There are two fundamental RSVP message types: RESV and PATH. Each 204 RSVP sender host transmits RSVP PATH messages downstream along 205 the uni-/multicast routes provided by the routing protocol(s), 206 following the paths of the data. PATH messages cause path states 207 to be established in each node along the way. A PATH message may 208 optionally carry a package of OPWA advertising information, known as 209 an Adspec. An Adspec received in a PATH message is passed to the 210 local traffic control, which returns an updated Adspec which is then 211 forwarded downstream. Each sender host periodically sends a PATH 212 message containing a description of each data stream it originates. 213 The PATH message travels from a sender to receiver(s) along the 214 same path(s) used by the data packets. The IP source address of a 215 PATH message is an address of the sender it describes, while the 216 destination address is the DestAddress for the session. These 217 addresses assure that the message will be correctly routed through a 218 non-RSVP cloud. Each receiver host sends RSVP reservation request 219 (RESV) messages upstream towards the senders. RESV messages are sent 220 hop-by-hop; each RSVP-speaking node forwards a RESV message to the 221 unicast address of a previous RSVP hop. These reservation messages 222 must follow exactly the reverse of the routes the data packets 223 will use, upstream to all the sender hosts included in the sender 224 selection. RESV messages must be delivered to the sender hosts 225 themselves so that the hosts can set up appropriate traffic control 226 parameters for the first hop. The IP destination address of a RESV 227 message is the unicast address of a previous-hop node, obtained from 228 the path state. The IP source address is an address of the node 229 that sent the message. In addition to PATH and RESV messages, two 230 messages are used to terminate a session: PTEAR and RTEAR. A PTEAR 231 message deletes path state, and a RTEAR message deletes reservation 232 state. RSVP also includes error messages to report exception events. 234 In the following section, we briefly discuss the various service 235 specifications being studied by the intserv working group of the 236 IETF. These services use RSVP as the signaling mechanism to obtain 237 QoS from the network. We also identify some of the issues involved 238 in supporting the intserv services over ATM networks. 240 3. Integrated Services Overview 242 The IETF's Integrated Services (intserv) working group is studying 243 several service specifications in the form of Internet Drafts 244 [4,5,6,7]. The purpose of these services is to support the transport 245 of audio, video, real time, and data traffic within a single network 246 infrastructure. The current intserv service specifications include: 247 Guaranteed Delay, Controlled Delay, Predictive, and Controlled Load. 249 Packet delay is the only QoS metric that is quantified within the 250 intserv model. Packet loss, in general, is required to be "low," 251 without any quantitative measures provided or specified as a no-loss 252 service. 254 The Guaranteed Delay class [4] provides firm bounds on the maximum 255 end-to-end packet transfer delay for each session using this 256 service. Every packet from a session conforming to its declared 257 traffic behavior is guaranteed a deterministic (with probability 258 1) end-to-end delay bound by this service. A rate is reserved at 259 each node that a session from this class traverses. The end-to-end 260 bound, then, is comprised of three parts: the delay experienced by 261 a perfect fluid source with a dedicated "pipe" across the network 262 with a bandwidth equal to the reserved rate, and two error terms that 263 account for deviations from the fluid model and fixed delays along 264 the path. The Guaranteed Delay class provides a lossless service. 266 Controlled Delay service [5] offers applications several levels of 267 delays to choose from. Currently, these levels of services are 268 defined in a way that service level 1 is expected to be better than 269 service level 2, which in turn is expected to be better than service 270 level 3. The delay experienced by packets is controlled in the 271 sense that all three levels of services have better average delays 272 than that of best effort service. However, no assurances about 273 the absolute levels of delay are made. For each level of service, 274 a network element provides an estimate of the maximum delay that 275 packets experience over a time period T. Three such intervals are 276 defined: 1 sec, 60 sec, and 3600 sec. 278 In order to obtain estimates of the packet delays over the different 279 time intervals, it is necessary for the network element to take 280 measurements and average these over some set of time intervals. 281 There is no requirement, however, for these measurements to be exact. 283 The Predictive Service class [6] in the intserv model is designed for 284 applications which desire a reserved rate with low packet loss and a 285 maximum bound on end-to-end delay. It differs from the guaranteed 286 delay class however in that occasional late or lost packets can be 287 tolerated. The delay bound is required to be quantified. However, 288 as is the case with the other intserv specifications, the allowable 289 rate of packet loss (except for Guaranteed Delay, which is a lossless 290 service) and delay bound violation is not quantified but simply 291 required to be "very low." Similar to the Controlled Delay class, 292 the Predictive Service specification defines three logical levels 293 of service, each associated with a delay bound with level 1 having 294 the smallest delay and level 3 having the largest. Each Predictive 295 Service module advertises the delay bound as well as measurements of 296 the maximum delay over three different time scales for each of the 297 three levels (twelve quantities in total). The reservation required 298 by an application is specified by the delay level its flow must use 299 at each node along its path. 301 The Controlled Load class is the most minimal of the intserv services 302 in terms of the guarantees provided to sessions. There is only a 303 single level of service associated with this class -- a session can 304 expect to receive, under all conditions, service closely resembling 305 the service which the same session would receive using best-effort 306 delivery under "unloaded" network conditions [7]. The term 307 "unloaded" refers to a "not heavily loaded or congested" network. 309 4. ATM Standards Overview 311 The ATM Forum Traffic Management (TM) Specification 4.0 [11] enhances 312 the QoS support in an ATM network by extending UNI 3.1 QoS service 313 categories to include individual QoS parameters. In addition, it 314 defines an Available Bit Rate (ABR) service to support best effort 315 traffic effectively in the network. Various ATM service categories 316 defined in UNI 4.0 are Constant Bit Rate (CBR), Real-Time Variable 317 Bit Rate (rt-VBR), Non Real-Time Variable Bit Rate (nrt-VBR), 318 Available Bit Rate (ABR), and Unspecified Bit Rate (UBR). There are 319 also four QoS Classes used to map application requirements, ranging 320 from the very strict circuit emulation to the much less stringent 321 connectionless data transfer, to an ATM connection. Together, QoS 322 Classes and service categories map connection traffic characteristics 323 and QoS requirements to network behavior. 325 Various features included in UNI 4.0 include [9]: 327 Point-to-point Calls 328 Point-to-multipoint Calls 329 Leaf Initiated Join Capability 330 Notification of end-to-end Connection Completion 331 ATM Anycast capability (Note 1) 332 Multiple signalling channels 333 Switched Virtual Path (VP) service 334 Proxy signalling 335 Frame Discard Capability (Note 3) 336 ABR Signaling for Point-to-point Calls 337 Generic Identifier Transport 338 Traffic Parameter Negotiation 339 Signalling of Individual QoS Parameters 340 Supplementary Services 341 Direct Dialing In (DDI) 342 Multiple Subscriber Number (MSN) 343 Subaddressing (SUB) (Note 2) 344 User-user Signalling (UUS) 346 Note 1 - This feature is optional for public networks/switching 347 systems and is mandatory for private networks/switching systems. 348 Note 2 - This feature is mandatory for networks/switching systems 349 (public and private) that support only native E.164 address formats. 350 Note 3 - Transport of the Frame Discard indication is Mandatory. 352 Similarly, various capabilities are available in ITU Q.29xx 353 Recommendations. Q.2962 allows the negotiation of the peak cell 354 rate during the call set up. Q.2963 allows peak rate renegotiation 355 (potentially sustainable cell rate and burst size) after the 356 connection set up. Q.298x allows multiple connections to be 357 established for a call. Q.2957 provides user-to-user signaling 358 thereby allowing information exchange during the set up or when the 359 connection is in an active state. 361 5. Overview of the Working Model 363 5.1. Objectives 365 The RSVP/ATM interworking function model is developed with the 366 following objectives: 368 1. Use existing RFCs and Internet Drafts while imposing minimal, if 369 any, changes to them; 370 2. Use currently available ATM standards (that are developed by both 371 ATM Forum and ITU) with minimal, if any, changes to them, and 372 3. Define the required functions in the context of a RSVP 373 Coordination Entity (RCE) thereby allowing a variety of physical 374 configurations that may be configured depending on the specifics of a 375 particular environment. 377 5.2. Model and Scope of Operation 379 In the proposed model, we consider a network of RSVP-capable routers 380 and hosts with an ATM network providing connectivity between them. 381 These routers are connected to an ATM network via a UNI, and hence 382 are required to support SVC signaling. The scope of the ATM cloud 383 is assumed to be identical to that of a single MARS cluster [17]. 384 We assume that the ATM cloud is served by a MARS that provides 385 resolution of IP multicast addresses to ATM addresses of IP endpoints 386 in the cluster. 388 The interworking function is developed based on a logical function 389 called a RSVP Coordination Entity (RCE). 391 An RCE is required to perform the following functions: 393 1. ATM multicast. 394 2. Support ATM UNI (other interfaces such as PNNI may be supported 395 through simple extensions). 396 3. RSVP capabilities: in this context, RSVP capabilities refer to 397 the ability of the network element to understand, act upon, update 398 and generate RSVP control messages, as required by the RSVP protocol. 399 4. Interact with the MARS to resolve IP multicast addresses to ATM 400 addresses. 402 RCEs are used to efficiently support various RSVP features over ATM. 403 In particular, various capabilities provided in an RCE include: 405 1. Efficient merging of RSVP flows: RCEs are points along the 406 end-to-end paths of single or multiple RSVP flows where RSVP merging 407 capability, based on RSVP filters, is provided. There may be one or 408 more RCEs along an end-to-end path. 409 2. Efficient establishment and maintenance of multicast trees at the 410 ATM layer. 411 3. Support for receiver heterogeneity in order to provide different 412 levels of QoS. 413 4. Translation of Tspec into ATM traffic parameters. 414 5. Translation of Rspec into ATM quality of service framework. 416 There may be one or more RCEs present within a MARS cluster. 417 There is no restriction on where the RCE function may reside. In 418 particular, an RCE may be physically resident at a host, a router, or 419 an ATM switch. The actual placement of RCE(s) may depend on various 420 administrative and performance constraints. 422 For illustrative purposes, let us consider a MARS cluster with a 423 Sender, S1, an RCE (RCE1) and a receiver, R1. 425 1. S1 originates (or forwards) a PATH message on a control VCC to 426 RCE1 427 2. RCE1 issues a MARS_REQUEST to the MARS to resolve the IP 428 multicast address of the destination group included in the PATH 429 message 430 3. MARS responds with the ATM address(es) of the members of the 431 group 432 4. RCE1 assigns a multicast tree id to this session as identified in 433 the path message (if one does not exist already) 434 5. RCE1 uses control VCCs to forward the PATH message to the 435 endpoints specified in the MARS response message. These control VCCs 436 are point-to-point virtual channels. 437 6. Endpoints process the PATH message as defined in the RSVP 438 protocol At this time, there are no resources reserved in the ATM 439 network for this session. 440 7. R1 initiates a RESV message to be transferred back to RCE1. A 441 LEAF INITIATED JOIN message is generated at the receiver's interface 442 with the root option (i.e., the message will be forwarded to the 443 root) where the root of the multicast tree is RCE1. This requires 444 the use of an additional information element at the LEAF INITIATED 445 JOIN message. 446 8. RCE1 performs RSVP processing based on the information element 447 included in the LEAF INITIATED JOIN message, sets up a new multicast 448 tree or extends an existing multicast tree to that leaf, and forwards 449 the RESV message (if needed) upstream. Alternatively, RCE1 could use 450 a control VCC to send the RESV message to LNE1. 452 Various details of RCE processing such as updating the PATH message, 453 etc. are omitted in this example for reasons of clarity. In 454 particular, topics that need elaboration include: 456 (a) Control connections and their usage. 457 (b) Data connections: establishment, tear-down, and usage. 458 (c) Advertisement of a single multicast identifier or Generic Call 459 Identifier that corresponds to an RSVP session identifier. 460 (d) Handling of RESV messages. 461 (e) The operation of multiple RCEs. 463 We address these issues in the following sections. 465 5.3. The RCE Model 467 Consider a MARS cluster with multiple RCEs. Without loss of 468 generality, network elements that have a PATH message for 469 transmission over the ATM network are referred to as Senders. 470 The PATH message may have originated external to the ATM cloud. 471 Accordingly, the ATM end station (i.e., a router, a host, a switch) 472 that accesses the ATM cloud for an RSVP session does not have to be 473 actual originator of the PATH message. Nevertheless, we will refer 474 to this network element as a Sender (for the ATM cloud). Similarly, 475 we will use the term Receiver to refer to the network element 476 attached to the ATM network from which the RSVP messages leave the 477 ATM cloud. Each Sender may have a control VCC to one or more RCEs 478 (either a PVC or an SVC). However, only one RCE is chosen to handle 479 the PATH messages at any given time. The RCE that serves a Sender 480 may be configured dynamically by means of: 482 1. A preassigned VCC to determine the address of the RCE (perhaps 483 from a configuration server), or 484 2. ATM ILMI procedures may be used dynamically. 486 Control connections between a Sender and an RCE are bidirectional 487 point-to-point connections. Upon receiving a PATH message from a 488 Sender, an RCE performs various functions that include: 490 - Processing and updating PATH messages as required in RSVP 491 processing 492 - Forwarding PATH messages towards the receivers 493 - Assigning a multicast tree id to this flow, if one was not assigned 494 already 496 In forwarding the PATH message, an RCE uses the appropriate control 497 VCC towards the destination. If there are one or more other RCEs 498 on the route from the RCE that first forwarded the PATH message 499 towards the receiver(s), these other RCEs may or may not be required 500 to process and update the PATH message. Either option has its 501 advantages and disadvantages and these need to be carefully weighed 502 before this decision can be made. However, no resource reservation 503 is made in the ATM network as the PATH message travels from its 504 Sender towards the Receiver. The control VCCs are long-lived and may 505 use ABR, UBR, or VBR traffic class with parameters requiring minimal 506 resource reservation. 508 Processing and updating a PATH message involves saving path state 509 in the RCE and updating the Adspec, if present. The Adspec cannot 510 be updated accurately at this stage as no end-to-end path has been 511 established yet (a path from the Sender to RCE is not established as 512 well). Hence, the best RCE can do at this stage is to update the 513 Adspec with an estimate. Different approaches to update Adspec are 514 reviewed in [8]. 516 When a RESV message arrives at the edge of an ATM network, the 517 Receiver can use either UNI 4.0 Leaf Initiated Join (LIJ) procedures 518 to add itself to the multicast tree, or it may use control VCCs to 519 transport RESV messages to the root of the tree. The root of this 520 tree is the first RCE to which the Sender transmitted its initial 521 PATH message. 523 NOTE: Extensions to multiple RCE environment in which the LIJ 524 request travels towards the root via more than one RCE (and perhaps 525 stops being forwarded by one of these RCEs based on the RSVP filter 526 spec/merge functions) can be incorporated relatively easily and will 527 be included in the future versions of this document. 529 LIJ has two modes: with or without root notification. In this 530 proposal, we use the LIJ with root-prompted join mode in which the 531 root handles the join request. Furthermore, we assume here that an 532 information element to carry the related contents of the RESV message 533 is made available in the LIJ capability. Which fields of the RESV 534 message are to be included in this information element is for further 535 study. 537 Alternatively, the RESV message can be sent to the RCE using the 538 same bidirectional control VCC on which the PATH message arrived to 539 the receiver. This would require the receiver to maintain an an 540 association (in a table) between RSVP sessions and control VCCs in 541 order to be able to send the RESV message to the same RCE from which 542 the PATH was received. 544 The choice of using the LIJ mechanism with appropriate information 545 elements, or a control VCC to send the RESV message, will depend 546 on the particular environment. For instance, in environments that 547 support UNI 4.0, it might be simpler to leverage the LIJ function 548 provided by UNI 4.0. On the other hand, in environments that support 549 UNI 3.0/3.1 which do not include LIJ capability, the control VCC 550 option is more appropriate. 552 As discussed in the next section, we assume there are only a few 553 different service levels that needs to be supported in a service 554 model. For example, there are only three levels of services in the 555 controlled delay and predictive service models. Controlled load 556 only has a single service level. While Guaranteed delay service can 557 have a very large number of different rates requested in the Rspec, 558 we assume it is possible to categorize different rates that may be 559 requested for an application to a few distinct values. Based on 560 this framework, RCE can establish different multicast trees, so that 561 a particular multicast tree will support receivers with the same 562 service requirement within a session. It is noted that only one 563 multicast tree identifier is used by an RSVP session. Although there 564 will be multiple multicast trees used to support different service 565 levels, each tree does not support the LIJ capability (i.e., they are 566 not made visible outside the ATM cloud). 568 When the root RCE receives the corresponding indication to add a new 569 leaf, it first processes the RESV message to determine the type of 570 the service requested by the receiver. The next step is to determine 571 the multicast tree that best matches the service requirement of the 572 receiver. Then, an ADD PARTY message is sent to add the Receiver to 573 the corresponding multicast tree. 575 5.3.1. Control Connections and Their Usage 577 Control VCCs can be established using permanent VCCs or switched 578 VCCs. Most likely, these VCCs will use UBR or ABR traffic class 579 service. These connections are used only to pass the PATH and RESV 580 messages from one edge of the network to another. RCEs also use 581 control VCCs to communicate with each other (i.e., forward RSVP 582 messages and related information). 584 Control VCCs are bidirectional, point-to-point connections. 586 5.3.2. Data connections 588 Data connections that originate at RCEs are always point-to-multipoint 589 connections. Data connections that originate at the Senders, 590 established to an RCE, are always point-to-point VCCs. The traffic 591 category and QoS class requested for a connection depends on receiver 592 requirements. 594 5.3.3. Advertisement of a single multicast identifier 596 An RCE can advertise a single multicast identifier that corresponds 597 to an RSVP session identifier. This needs to be handled by network 598 management or by other off line means. 600 5.3.4. Handling RESV messages 602 There is no need to keep forwarding RESV messages for established 603 sessions within an ATM cloud. If the connection is terminated for 604 some reason within the ATM cloud, this will be reported to one or 605 more UNIs in the network and the RSVP user will be notified. If a 606 connection is terminated outside the ATM cloud, then the Receiver 607 will receive this message and terminate the connection using ATM 608 signaling procedures. If the RESV message is for a change in the 609 service quality, then this will be treated as if it is a new RESV 610 message, as discussed later in this document. 612 5.3.5. Operation of Multiple RCEs 614 The details of the operation of multiple RCEs within an ATM cloud are 615 for further study. 617 5.4. Supporting RSVP features over ATM 619 5.4.1. Heterogeneous Receivers 621 RSVP provides means to support "heterogeneous receivers". That is, 622 different receivers of a particular flow may ask different service 623 levels from the network. ATM architecture, on the other hand, 624 require all receivers of a point-to-multipoint connection to have 625 the same QoS. One trivial way to support heterogeneous receivers 626 in ATM is to establish different point-to-point connections to 627 each receiver that take into consideration the QoS requirement of 628 the application explicitly. Another alternative is to establish 629 a point-to-multipoint connection with the most stringent QoS 630 requirements of all receivers. The first solution requires managing 631 potentially very large number of point-to-point VCs and does not 632 scale well. The latter proposal solves this scalability problem but 633 results in overallocation of resources in the ATM network. Although 634 there can be thousands of receivers in a session, different levels of 635 quality of service that may be requested by receivers are expected to 636 be a small number. In particular, for each intserv service model, we 637 have: 639 Guaranteed service 641 This is a lossless service in which end-to-end delay experienced by 642 packets in a flow is guaranteed to be less than or equal to a maximum 643 value specified by the receiver. This value is specified by the 644 receiver as a clearing rate R. Although the granularity of R is 1 645 byte/sec in the RSVP spec, different R's that may be specified for a 646 particular application may be classified into a few values. 648 Controlled Delay Service 649 Currently, three levels of services are defined in the controlled 650 service such that service level 1 is expected to be better than 651 service level 2, which in turn is expected to be better than service 652 level 3. The delay experienced by packets is controlled in the 653 sense that all three levels of services have better average delays 654 than that of best effort service. However, no assurances about the 655 absolute levels of delay can be made. It is possible to provision 656 these three levels of delays in the ATM network that meet the service 657 requirements of the controlled service. In this case, receivers 658 request only one of three possible service values. The delay values 659 provided in each service level may be updated using ILMI or offline 660 (network management) at time intervals when the network can not 661 provide the specified delay values (for new connections) or when it 662 can provide significantly better delay values. 664 Predictive Service 666 Predictive service offers applications a number of long term 667 end-to-end delays to choose from. Similar to controlled service, 668 different values of delay values provided in the ATM network may 669 be pre-specified and updated as needed. The number of different 670 delay values provided in the ATM network to support this service is 671 expected to be a small number as well. 673 Controlled Load Service 675 There is only a single level of service associated with this class 676 -- a session can expect to receive, under all conditions, a service 677 closely resembling the service which the same session would receive 678 using best-effort delivery under "unloaded" network conditions. 679 Again the delay value associated with this service in the ATM network 680 can be easily provisioned and updated over long intervals of time as 681 needed. 683 Assuming that different delay values that may be requested by a 684 receiver for each IntServ service model can be classified into a 685 smaller set, the service requirement of a flow from a particular 686 receiver can be supported in the current ATM signaling easily by 687 associating the QoS requirements of service models to ATM QoS classes 688 and using UNI 4.0 maximum cell transfer delay, maximum cell delay 689 variation, cell loss ratio parameters. 691 5.4.2. Moving between different service levels 693 RSVP allows receivers to change their previously requested service 694 levels depending on their service requirement and their observation 695 of the performance they are currently receiving. Accordingly, 696 applications can move to a higher level (better delay) or to a lower 697 level throughout the duration of their session. One trivial method 698 to support this requirement is to terminate the existing connection 699 and establish a new ATM connection based on the most recent service 700 requirement. This solution may impose a significant signaling 701 load to the ATM network, thereby restricting establishment of new 702 connections. 704 In the proposed model, handling service modifications is more 705 efficient than terminating/establishing end-to-end connections. In 706 particular, service intelligence can be easily incorporated into the 707 RCE to support this RSVP feature. For example, if there is already 708 a multicast tree established for the most recently requested service 709 level, then this request can be easily satisfied by dropping the 710 leaf from the current tree and adding it to another that matches the 711 request most closely. This would impose minimal signaling load to 712 the network while meeting the service requirement. 714 5.4.3. Best Effort Service when resources are not available 716 Another RSVP feature allows receivers to receive the flow in a 717 best-effort manner. In particular, RSVP prevents denial-of-service 718 attacks via reservations by not allowing the network elements to 719 simply drop non-conforming packets. Both Guaranteed and Controlled 720 Load service models assign non-conformant packets to best-effort 721 status (which may result in packet drops if there is congestion). 722 The ATM service model has a similar feature in which non-conforming 723 traffic is tagged and allowed to enter the network. Marked ATM cells 724 are dropped in the intermediate switches if there is not enough 725 resource available to transmit these cells without causing service 726 degradation to conforming traffic. The number of non-conforming 727 cells before a connection is classified non-compliant is network 728 specific. Hence, it is possible to support RSVP best effort packets 729 in ATM using ATM's tagging feature. Early Packet Discard (EPD) 730 schemes may be used in the network elements to increase the effective 731 resource utilization without impacting the service quality to the 732 receiver (as if one or more cells of a packet is dropped in the 733 network, the rest of the information carried in arrived cells at the 734 receiver may not be useful for the application). 736 5.4.4. Flow aggregation 738 Flow aggregation occurs in the proposed model only at the RCEs. 739 Each RCE terminates incoming flows and originating outgoing flows. 740 Accordingly, supporting flow aggregation can be achieved easily at 741 the RCEs by multiplexing traffic from incoming connections (VCs) to 742 an outgoing connection (VC). The multiplexing needs to take into 743 consideration the service levels provided in each outgoing connection 744 and may be required to use more than one VC to support different 745 service requirements. 747 5.4.5. Mapping RSVP parameters 749 RSVP Tspec maps into ATM traffic parameters in a straightforward 750 manner. Tspec also specifies which ATM traffic class may be used 751 for the connection. Tspec includes the peak rate of the connection 752 and the leaky bucket parameters that matches (after the values are 753 adjusted) the ATM traffic parameters. If the peak rate is equal to 754 the token generation rate (or close enough), CBR service category 755 may be used. Otherwise, it is a variable bit rate connection. ATM 756 defines three different variable bit rate traffic classes i.e., 757 VBR, UBR, ABR. The choice among these three would depend on the 758 service requirement of the receiver which requires for the RCE to 759 wait for the RESV message. Rspec in the RESV message may then be 760 used to determine which ATM traffic category may be used for the ATM 761 connection, together with the QoS profiles defined in the network 762 associated with each QoS class. Note that ATM traffic categories 763 and QoS classes do not have a one-to-one relationship and may be 764 combined in any way that fits the application requirements. RSVP 765 Rspec does not map into any ATM QoS class directly. However, as 766 discussed in section 4.2.1, it is possible to pre-define and manage 767 semi-dynamically various service profiles that can match RSVP service 768 models. 770 5.4.6. Directly attached ATM hosts 772 In this framework, an ATM host with RCE functionality may use RSVP 773 without the need to support other routing functions (i.e., it does 774 not have to be a router). 776 5.4.7. Packet level/cell level traffic parameter mapping 778 The RSVP TSpec can be mapped to ATM traffic descriptors in a 779 straightforward manner. A description of this mapping is provided in 780 [8]. Briefly summarizing, if we ignore the segmentation overhead and 781 effects of the granularity of ATM cell size, the following mapping 782 can be used: 784 SCR = r / 48; MBS = b / 48; PCR = P / 48, 785 where r and b are the token generation rate and bucket depth, and 786 P corresponds to the minimum of the incoming link and the actual 787 peak rate of the flow (currently, the TSpec does not include a peak 788 rate for any intserv service classes; inclusion of this parameter 789 is currently under study). The above relations can be modified to 790 include the effect of segmentation overhead as: 792 SCR = ar; MBS = ab; PCR = aP 794 where a = (1 + ceil(p / 48)) / p represents the worst case overhead 795 due to the ATM segmentation with AAL5 and a minimum packets size of p 796 (in bytes). The "ceil" operator corresponds to the ceiling function. 797 Further refinements to these relations can be found in [8]. 799 6. Summary 801 The main objective of this document is to outline a framework to 802 provide RSVP/ATM interworking. The proposed approach takes advantage 803 of the ATM transfer capabilities while supporting RSVP features 804 efficiently. There are several areas that needs to be satisfactorily 805 addressed for this document to be complete. However, several 806 of the related issues have been studied and various solutions do 807 exist to fill in the gaps. We believe those areas that are yet to 808 be addressed may be satisfactorily resolved within the proposed 809 framework. 811 7. Acknowledgments 813 Rao Cherukuri, Dean Skidmore and Wayne Pace have patiently spent long 814 hours with us, discussing several ideas presented in this document 815 and their contributions are greatly appreciated. 817 8. References 819 [1] R. Braden, D. Clark, S. Shenker, Integrated Services in the 820 Internet Architecture: an Overview, RFC 1633, June 1994. 822 [2] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin., Resource 823 ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. 824 Internet Draft, draft-ietf-rsvp-spec-10. February 1996. 826 [3] R. Cole, D. Shur, C. Villamizar. IP over ATM: A Framework 827 Document. Internet Draft, draft-ietf-ipatm-framework-doc-07, 828 February 1996. 830 [4] S. Shenker and C. Partridge. "Specification of Guaranteed 831 Quality of Service (draft-ietf-intserv-guaranteed- svc-03.txt)." 832 INTERNET-DRAFT, Internet Engineering Task Force - Integrated Services 833 WG, November 1995. 835 [5] S. Shenker, C. Partridge, and JJ. Wroclawski. "Specification of 836 Controlled Delay Quality of Service (draft-ietf-intserv-control-del-svc-02.txt)." 837 INTERNET-DRAFT, Internet Engineering Task Force - Integrated Services 838 WG, November 1995. 840 [6] S. Shenker, C. Partridge, B. Davie, and L. Breslau. 841 "Specification of Predictive Quality of Service (draft-ietf-intserv-predictive-svc-01.txt)." 842 INTERNET-DRAFT, Internet Engineering Task Force - Integrated Services 843 WG, November 1995. 845 [7] J. Wroclawski. "Specification of the Controlled-Load Network 846 Element Service (draft-ietf-intserv-ctrl-load- svc-01.txt)." 847 INTERNET-DRAFT, Internet Engineering Task Force - Integrated Services 848 WG, November 1995. 850 [8] A. Birman, V. Firoiu, R. Guerin, and D. Kandlur. "Provisioning 851 of RSVP-Based Services over Large ATM Networks." IBM Research Report 852 No. RC 20250, October 1995. Available from IBM Research Web Server 853 (CyberJournal) at URL: http://www.watson.ibm.com:8080/. 855 [9] "Draft of UNI Signalling 4.0", ATM Forum/95-1434R8, December 856 1995. 858 [10] M. Borden, E. Crawley, B. Davie, and S. Batsell. "Integration 859 of Real-time Services in an IP-ATM Network Architecture," RFC 1821, 860 August 1995. 862 [11] "Traffic Management Specification 4.0", ATM Forum/95-0013R10, 863 December 1995. 865 [12] ATM Forum Contribution 96-0096, "Issues in Mapping INTSERV 866 service specifications to ATM Service Categories", R. Onvural, S. 867 Rampal, V. Srinivasan, R. Balay 869 [13] ATM Forum Contribution 96-0094, "Issues in Extending Unicast and 870 Multicast RSVP Flows Across ATM Networks", R. Guerin, D. Kandlur 872 [14] ATM Forum Contribution 96-0097, "RSVP and Integrated Services 873 over ATM and API", R. Guerin, V. Srinivasan, D. Skidmore, R. 874 Cherukuri, D. Kandlur, R. Onvural 876 [15] ATM Forum Contribution 96-0160, "Interworking between IETF RSVP 877 Signaling Protocol and ATM Signaling", R. Cherukuri and D. Skidmore 879 [16] ATM Forum Contribution 96-0258, "RSVP and MPOA", S. Berson 881 [17] G. Armitage, "Support for Multicast over UNI 3.1 based ATM 882 Networks", Internet Draft, IP over ATM Working Group, draft-ietf- 883 ipatm-ipmc-12.txt, February 1996. 885 9. Authors' Address 887 Raif O. Onvural 888 IBM Corporation 889 BUA/664 890 Research Triangle Park, NC 27709 892 Phone: +1-919-254-4687 893 Fax: +1-919-254-5410 894 E-mail: onvural@vnet.ibm.com 896 Vijay Srinivasan 897 IBM Corporation 898 BUA/664 899 Research Triangle Park, NC 27709 901 Phone: +1-919-254-2730 902 Fax: +1-919-254-5410 903 E-mail: vijay@raleigh.ibm.com