idnits 2.17.00 (12 Aug 2021) /tmp/idnits3070/draft-ayandeh-diffserv-atm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 411 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'ITU-T I.356' on line 123 ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '1') ** Obsolete normative reference: RFC 2598 (ref. '2') (Obsoleted by RFC 3246) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2309 (ref. '7') (Obsoleted by RFC 7567) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- No information found for draft-goyal-diffserv-dpstdy - is the name correct? -- Possible downref: Normative reference to a draft: ref. '11' -- Possible downref: Normative reference to a draft: ref. '12' Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mapping to ATM classes of service for 2 Differentiated Services Architecture 4 draft-ayandeh-diffserv-atm-00.txt S. Ayandeh 5 Expiration: April 2000 A. Krishnamurthy 6 A. Malis 7 Lucent Technologies 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC 2026. Internet-Drafts 13 are working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed 28 at http://www.ietf.org/shadow.html. 30 Abstract 32 The guidelines for PHB specifications contained in the Differentiated 33 Services (DS) Architecture [1] require descriptions of: 35 1. How a PHB would map to different link layers 36 2. How a PHB would inter-work with non-DS compliant nodes and networks 38 This draft includes the mapping to ATM classes of service for EF [2] and 39 AF PHBs [3]. 41 65 42 2.0 Introduction 3 43 3.0 Inter-working issues of DiffServ and ATM 3 44 4.0 Differentiated Services Requirements for ATM Classes of Service 4 45 5.0 Recommended Mapping of DiffServ PHBs to ATM Classes of Service 4 46 5.1 Mapping of EF PHB to CBR Class of Service 4 47 5.2 Mapping of AF PHB to ABR Class of Service 5 48 6.0 Example Use of Virtual Circuits 6 49 7.0 Interactions of TCP and UDP 6 50 8.0 Security Considerations 7 51 9.0 References 7 52 10.0 Authors' Addresses 7 54 65 56 2.0 Introduction 57 Multi-service networks form part of the mosaic of existing and emerging 58 data networks. As such there is a need to ensure that characteristics 59 of IP services based on Differentiated Services (DS) architecture are 60 maintained end to end across (intermediate) ATM networks. This is no 61 easy task, as ATM networks standardize a service at the user network 62 interface while allowing for adjustments to a set of well-defined 63 traffic parameters. DS, on the other hand, supplies the supporting 64 traffic conditioning and per-hop behaviors and leaves the service 65 specification to be defined by the service provider. 67 The goal of this document is to specify the mapping of differentiated 68 services PHBs to existing ATM classes of service. The ATM traffic 69 class, its descriptors, and QoS parameters, required to carry a given 70 PHB are discussed. Circuit aggregation issues are limited to a 71 discussion of virtual path connections. 73 The motivation for this approach is: 75 a) To allow for traffic conditioning functions to occur at frame 76 boundaries while the ATM network delivers a given PHB using existing 77 ATM classes of service. Note that ATM Forum's draft addendum [5], 78 which proposes extensions to ATM service categories and signaling 79 scheme, deals with new mechanisms that are in process of being 80 specified. These mechanisms in effect make an ATM switch DiffServ 81 compliant. 82 b) To ensure that the resulting mappings do indeed meet the requirements 83 of the EF and AF PHBs outlined in RFCs 2598 & 2597. For example as 84 we show further on, the approach also recommended by the ATM Forum's 85 draft addendum [5] to their Traffic Management 4.1 Specification [4], 86 of mapping IP services to ATM classes of service may at best 87 approximate the expected behaviors and the resulting IP service. 88 c) To simplify the resulting deployments by offering two existing ATM 89 classes of service that would correspond to the EF and AF per hop 90 behaviors. We label this as the "PHB-mapping" approach. This is in 91 contrast to the "service-mapping" approach taken in the addendum to 92 TM 4.1 [5]. In the latter approach, services resulting from the AF 93 PHB alone may be mapped to five ATM classes of service: rt-VBR, nrt- 94 VBR, ABR, GFR, and Differentiated UBR. 96 3.0 DiffServ and ATM inter-working issues 97 The goal is to meet the requirements of a given differentiated services 98 PHB using a minimum set of resources in an ATM network. Some 99 clarification of the terms used to describe the behavior of the traffic 100 source & QoS parameters in ATM networks is in order. This clarification 101 is intended to highlight the main differences between cell and packet 102 based metrics currently in use: 104 Cell rates: Cell rates have to take into account the adaptation layer 105 overheads of ATM such as padding. Adaptation overheads vary with the 106 size of the packets. Therefore conversion of a given bit rate at a 107 packet interface to cell rate has to take into account the statistical 108 nature of the packet length. Some additional bandwidth may have to be 109 allocated in order to account for the statistical nature of the packet 110 length. 112 Cell Transfer Delay (CTD): This parameter in TM 4.1 is measured as the 114 65 116 interval between a pair of cell entry and exit events. CTD does not 117 cover the transmission time at the egress port. In DS measurements the 118 packet transmission time, which varies with packet size, is often 119 included. 121 Peak-to-peak CDVT: This parameter is measured as the difference CTDx- 122 CTDd, where subscript x refers to an arbitrary cell and d to a defined 123 reference cell [ITU-T I.356] (injected at idle time). The EF-PHB, for 124 example, uses the absolute value of the difference in nodal CTD for two 125 adjacent packets as a measure of jitter experienced at a node. 127 Cell Loss Ratio (CLR): CLR represents a lower bound on the loss 128 probability of the corresponding packets. Settings of CLR would require 129 some understanding of the cell loss process and how it relates to the 130 packet loss ratio. For example, partial and early packet discard 131 mechanisms can realize this lower bound. 133 4.0 Differentiated Services Requirements for ATM Classes of Service 134 Currently defined DiffServ architecture places three basic requirements 135 on the ATM network: marking of packet drop precedence, as well as, 136 minimum cell rate control and active queue management. 138 1. Marking of Packet Drop Precedence: ATM offers a cell loss priority 139 (CLP=0 or 1) mechanism. Cells resulting from in profile packets are 140 marked with CLP=0, while cells resulting from out of profile packets 141 are marked with CLP=1. Marking of cells should therefore be applied 142 to entire frames and occur at frame boundaries. Indiscriminate 143 marking of cells would lead to unacceptable throughput behavior in 144 the face of congestion in the cell network [6]. 146 2. Minimum Cell Rate [cell/s]: Needs to be configured for both the EF 147 and AF PHBs. For EF it ensures that the aggregate has a well-defined 148 minimum departure rate over a time interval equal to or greater than 149 the time it takes to send an output link MTU sized packet at the 150 configured rate of the EF-PHB. This together with policing action at 151 the edge leads to a low loss, delay, and jitter per-hop behavior. 153 3. Active Queue Management: The assured forwarding PHB and hence the 154 resulting services, require the properties of a RED like algorithm 155 for active queue management [7]. ATM services can offer cell discard 156 for CLP=1 cells. However, indiscriminate cell drops are not of any 157 use in support of AF PHB. Both partial and early packet discard 158 mechanisms in ATM lead to a tail packet drop behavior. Tail drop is 159 undesirable for its adverse effects on TCP flows. ATM traffic classes 160 [4] are being enhanced through local policy to offer active queue 161 management. However, any solution to this problem is further 162 aggravated by virtual path connections where individual circuit and 163 frame delineation are not visible by definition. 165 5.0 Recommended Mapping of DiffServ PHBs to ATM Classes of Service 166 The requirements outlined in the previous section are met by the 167 following mappings of differentiated services PHBs to existing ATM 168 classes of service. 170 5.1 Mapping of EF-PHB to the rt-VBR Class of Service 171 Source Traffic Descriptor (VBR.1) 173 65 175 Peak Cell Rate (PCR) (CLP=0+1) = line rate of the connection with 176 its inverse T0+1 178 Sustained Cell Rate (SCR) = configured rate of EF PHB with its 179 inverse Ts 180 Maximum Burst Size (MBS) = max-PDU-size 182 Two conformance definitions apply GCRA(T0+1 , CDVT) to regulate the peak 183 and GCRA(Ts0 , BT0 + CDVT) to regulate the rate of the connection 184 averaged over the life of the connection [4]. Non conforming cells are 185 dropped. 187 QoS Parameters 188 CLR = Cell loss is not expected along the ATM path, 189 however loss may occur at the ingress for non- 190 conforming packets 191 MaxCTD = Is the transfer delay of the ATM network 192 Peak-to-peak CDV = a derivative of MaxCTD is equal to MaxCTD-(fixed 193 propagation, transmission, and switching delays) 195 Note that the network through the traffic descriptor provisions adequate 196 resources to accommodate cells bursting at line rate at the configured 197 rate of the EF-PHB. By using an MBS equal to the max-PDU-size, the 198 network over provisions bandwidth. However since EF-PHB is a policed 199 service, the excess bandwidth would be available for use by other 200 connections. 202 Mapping of EF-PHB to the CBR class of service would introduce shaping 203 induced delays at egress when re-assembling a packet. Low delay 204 requirement of EF-PHB may therefore not be well served with CBR class of 205 traffic. 207 5.2 Mapping of AF PHB to ABR Class of Service 208 Source Traffic Descriptor (ABR) 209 PCR (CLP=0+1) = minimum line rate along the path of the VC with its 210 inverse T0+1 211 MCR = minimum bandwidth allocated to an AF class with its 212 inverse Tm0 214 The conformance definitions is GCRA(Tm0 , CDVT), or based on ideal 215 transmission time of CLP=0 cells resulting from the "Allowed Cell Rate" 216 in response to the feedback mechanism. All data cells are transmitted 217 with CLP=0. Congestion feedback is supplied as an explicit rate, 218 congestion indication, or no increase parameters contained in resource 219 management cells. 221 QoS Parameters 222 CLR = no value needs to be specified. The target value is 223 however intended for conforming connections and is 224 network specific. 226 The use of ABR traffic class is recommended as it allows all of the 227 requirements of the AF-PHB to be met. Note that VBR, GFR, and relative 228 UBR only partially meet the packet drop precedence requirement, and do 229 not offer active queue management. Furthermore, these traffic classes 230 do not support virtual path circuits for reasons already discussed in 231 section-3. 233 65 235 With ABR, the minimum throughput and buffer requirements of the AF PHB 236 can be provisioned. With a minimum amount of cell loss, congestion in 238 the cell network is pushed back to the frame boundaries where active 239 queue management is applied. Any mechanisms to implement back pressure 240 at the frame boundary are implementation specific. 242 Active queue management is applied to the full range of the packet drop 243 precedence markings i.e. AFx1, AFx2, and AFx3. This is in contrast to 244 the three to two levels mapping which would occur with the use of Cell 245 Loss Priority (CLP) in the service-mapping approach. 247 The requirements of the AF PHB are therefore fully met. Given that only 248 a few ABR connections would be carrying large aggregates of AF traffic, 249 any possible concern with the volume of resource management cells does 250 not arise. For list of numerous references regarding IP traffic and ABR 251 see references [8, 9, 10]. 253 6.0 Example Use of Virtual Circuits 254 Please note that the code points are only mentioned for illustrative 255 purpose. The idea is to map PHBs to ATM classes of service and not DS 256 code points. 258 Diffserv code point VC-type 260 101110 EF rt-VBR VCb 262 001010 AF11 ABR VCc CLP=0 263 001100 AF12 CLP=0 264 001110 AF13 CLP=0 266 010010 AF21 ABR VCd CLP=0 267 010100 AF22 CLP=0 268 010110 AF23 CLP=0 270 011010 AF31 ABR Vce CLP=0 271 011100 AF32 CLP=0 272 011110 AF33 CLP=0 274 100010 AF41 ABR VCf CLP=0 275 100100 AF42 CLP=0 276 100110 AF43 CLP=0 278 000000 BE UBR VCg 280 7.0 Interactions of TCP and UDP 281 There are three alternatives available to handle the interactions of TCP 282 and UDP traffic [11, 12]: 284 a) Integrated treatment with two drop precedence: 285 TCP/UDP In Profile -> AFx1 286 TCP/UDP Out Profile -> AFx2 288 In this scenario both TCP and UDP would achieve their committed rates. 289 In the face of persistent congestion UDP would consume the entire excess 290 bandwidth. 292 65 294 b) Integrated treatment with three drop precedence: 295 This scenario can not be supported by the "service-mapping" approach as 296 ATM is limited to two drop precedence levels. However the "PHB-mapping" 298 approach can support this scenario: 300 TCP/UDP In Profile -> AFx1 301 TCP Out Profile -> AFx2 302 UDP Out Profile -> AFx3 304 In this scenario both TCP and UDP would achieve their committed rates. 305 In the face of persistent congestion, TCP and UDP would share the excess 306 bandwidth. This assumes that some excess bandwidth has been 307 provisioned. WRED algorithms that maintain per drop level packet counts 308 further aid the fair allocation of the excess bandwidth. 310 c) Separate treatment (with two drop precedence) 311 TCP and UDP may each be treated as a separate class, given the 312 inadequate sharing of excess bandwidth in scenario "a" above. For 313 example: 315 TCP in profile -> AFx1 316 TCP out profile -> AFx2 318 UDP in profile -> AFy1 319 UDP out profile -> AFy2 321 Use of ABR to support the AF-PHB enables scenario "b" the "integrated 322 treatment with three drop precedence". This saves on the number of AF 323 classes in use and hence the number of virtual circuits required. 325 8.0 Security Considerations 327 As with any other provisioned services, the ATM network must make use of 328 its capabilities for call admission control and police against sources 329 attempting to utilize more network resources than their service contract 330 allows. In addition, when the ABR service class is used, the network 331 provides flow control feedback to sources. This allows these sources to 332 avoid data loss on the ATM network if congestion occurs. Congestion may 333 be due to denial of service attacks from other sources or temporary 334 network outages. 336 9.0 References 337 [1] Blake, S., Black, D., Carlson, M., Davis, E., Wang, W., Weiss, 338 W., "An Architecture for Differentiated Services", RFC 2475, December 339 1998. 341 [2] Jacobson, V., Nichols, K., Poduri, K., "An Expedited Forwarding 342 PHB", RFC 2598, June 1999. 344 [3] Heinanen, J., Baker, F., Weiss, W., Wroclawski, J, "Assured 345 Forwarding PHB Group", RFC 2597, June 1999. 347 [4] ATM Forum Traffic Management 4.1 Specification, ATM Forum/af-tm- 348 0121.000, March 1999. 350 [5] Addendum to TM 4.1: Enhancements to Support IP Differentiated 352 65 354 Services and IEEE 802.1D over ATM, ATM Forum BTD-TM-DIFF-01.02 (work in 355 progress), November/December 1999. 357 [6] Romanow, A., Floyd, S., "Dynamics of TCP traffic over ATM 359 networks", Proceedings of SIGCOMM'94, September 94. 361 [7] Braden, B., Clark, D., Crowcroft, J. , Davie, B. , Deering, S. , 362 Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., 363 Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., Zhang, L., 364 Recommendations on Queue Management and Congestion Avoidance in the 365 Internet, April 1998. Available as RFC 2309 ( text) as an Informational 366 RFC 368 [8] Fahmy, S., Jain, R., Rabie, S., Goyal, R.,Vandalore, B., "Quality 369 of Service for Internet Traffic over ATM Service Categories," Journal of 370 Computer Communications special issue on enterprise networks, 1999 372 [9] Vandalore, B., Kalyanaraman, S., Jain, R., Goyal, R., Fahmy, S., 373 "Simulation Study of World Wide Web traffic over the ATM ABR Service," 374 Proceedings of SPIE Symposium on Voice, Video and Data Communications, 375 Vol. 3530, Conference on Performance and Control of Network Systems II, 376 Boston, MA, November 1998, pp. 415-422 378 [10] Pazos, C. M. D., Signore, V. A., Cavendish Jr., D., Gerla, M., 379 "Performance of TCP over ATM for Various ABR Control Policies," 380 Proceedings of ICCCN'96, Rockville, MD. October, 1996. 382 [11] Goyal, M., Durresi, A., Jain, R., Chunlei, L., "Effect of Number 383 of Drop Precedence in Assured Forwarding", draft-goyal-diffserv-dpstdy- 384 02, July 1999 386 [12] Elloumi, O., Cnodder, S., Pauwels, K., "Usefulness of three drop 387 precedence in Assured Forwarding service", draft-elloumi-diffserv- 388 threevstwo-00.txt, July 1999 390 10.0 Authors' Addresses 391 Siamack Ayandeh 392 Lucent Technologies 393 1 Robbins Road, 394 Westford, MA, 01886 395 (978) 952 7866 396 sayandeh@ascend.com 398 Anand Krishnamurthy 399 Lucent Technologies 400 1 Robbins Road, 401 Westford, MA, 01886 402 (978) 952 1448 403 ak26@lucent.com 405 Andrew Malis 406 Lucent Technologies 407 1 Robbins Road, 408 Westford, MA, 01886 409 (978) 952 7414 410 amalis@lucent.com