idnits 2.17.1 draft-worster-diffserv-gr-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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages 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 ([TM5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 239: '...tolerance to bursts that the node MUST...' RFC 2119 keyword, line 241: '...m specified by S the network node MUST...' RFC 2119 keyword, line 245: '...e service of excess GR traffic MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 304 has weird spacing: '...ld have the a...' -- 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 (June 7, 1998) is 9427 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Hein' -- Possible downref: Non-RFC (?) normative reference: ref. 'TM5' -- Possible downref: Non-RFC (?) normative reference: ref. 'NiBl' -- Possible downref: Non-RFC (?) normative reference: ref. 'Call' -- Possible downref: Non-RFC (?) normative reference: ref. 'HeRo' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Tom Worster 3 INTERNET-DRAFT Avri Doria 4 Expires: November 1998 General DataComm 5 Robert Wentworth 6 Hyundai Network Systems 8 June 7, 1998 10 Guaranteed Rate in Differentiated Services 12 14 Status of This Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 28 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 29 (US West Coast). 31 Abstract 32 We propose a diff-serv per hop behavior (PHB) for the transport 33 of non-real time traffic with a guaranteed rate (GR). This 34 proposal is based on principles developed for the specification 35 of the Guaranteed Frame Rate (GFR) service category currently 36 being specified for ATM [TM5]. It is shown that a diff-serv 37 network using the GR PHB together with a explicit routing 38 capability can support edge-to-edge guaranteed rate service. 39 Interconnection of diff-serv networks deploying GR to achieve 40 end-to-end service and interworking with ATM's GFR service are 41 also discussed. 43 1. Introduction, motivation, goals 45 What is now known at the ATM Forum as the Guaranteed Frame Rate 46 service category (and at ITU-T as the Guaranteed Frame Rate ATM 47 transfer capability) was introduced by Juha Heinanen in April 48 1996 [Hein]. It is currently in the process of specification at 49 both the ATM Forum Traffic Management Working Group and at ITU-T 50 Study Group 13. GFR is part of the draft ATM Forum TM 5.0 51 specification which is planned to go to letter ballot in December 52 1998. 54 The "frame" in GFR comes from that fact that in ATM the 55 definition involves a minimum cell rate where only cells 56 delivered in complete frames count towards fulfilling the 57 service; a complication that is avoided in a diff-serv PHB 58 defined at the IP level. 60 GFR is intended to provide a non-real time service with a 61 guaranteed minimum rate. Traffic offered to the network in 62 excess of the minimum rate is handled with best effort service. 63 The GFR service definition was intended to be simple for the user 64 to understand, simple to tariff, and useful for a wide range of 65 network applications including aggregated router-to-router data. 67 In this ID we propose a Guaranteed Rate (GR) PBH for diff-serv 68 adhering to the operational model proposed in [NiBl]. This 69 proposal is based directly on ideas and definitions developed in 70 the specification of the GFR service. Together with a suitable 71 routeing mechanism, deployment of the GR PHB allows a diff-serv 72 network to provide an edge-to-edge ("edge-to-edge" implies 73 reference points on the exterior interfaces of edge nodes 74 belonging to a diff-serv compliant area) minimum bit rate service 75 guarantee for non-real time traffic. The same service guarantee 76 can also be supported over multiple ISPs' networks. Direct 77 interworking between GR and GFR ATM connections (in either the 78 conventional layering or MPLS architectures) is another goal. 79 The goals of this ID include the stimulation of interest in the 80 proposal, discussion of the technical issues and experimentation. 81 Ultimately it is intended that this effort would end in 82 standardization of a PHB codepoint. 84 2. Guaranteed Rate in the diff-serv model 86 In this section we provide a high-level description of the GR PHB 87 proposal and explain how it can be used together with other 88 mechanisms to provide guaranteed rate edge-to-edge service. 89 While the goal of the current proposal is the definition of the 90 GR PHB we also use the name Guaranteed Rate service (GR service) 91 when speaking of the resulting edge-to-edge or end-to-end 92 service. 94 Several elements of this section have been adapted directly from 95 the text of [TM5]. 97 2.1 High level description of GR PHB and service 99 The GR PHB and service are intended to support non-real time 100 applications. The GR service provides transport of IP data with a 101 minimum bit rate guarantee under the assumption of a given burst 102 limit. 103 This service guarantee implies that if the user sends bursts of 104 packets that in total do not exceed the maximum burst limit then 105 the user should expect to see all of these packets delivered 106 across the network with minimal loss. The GR service also allows 107 the user to send in excess of the committed rate and the 108 associated burst limit but the excess traffic will only be 109 delivered within the limits of available resources. Furthermore 110 the GR PHB specifies that the excess traffic from each user 111 should have access to a fair share of available resources. The 112 definition of fair share is implementation or network specific 113 and is not specified by either the GR PHB or service. 115 2.2 Environmental considerations 117 The current proposal is an attempt to work strictly within the 118 diff-serv framework and operational model [NiBl]. While the GR 119 proposal is clearly intended as a basis for providing a 120 network transport service with guaranteed minimum bit rate we 121 are proposing to do so using a bottom-up approach based on a 122 GR PHB and the goal of this proposal is to define and 123 standardize that PHB. 125 Deployment of a GR service requires protocols and mechanisms 126 besides those discussed here. Specifically, a GR network 127 should be aware of specific network streams, (_stream_ is 128 used in the same sense as in [Call]). These streams may be 129 defined in many different ways and several mechanisms are 130 available to support discrimination of these streams in the 131 network nodes. For example, a stream could be the aggregate of 132 packets from one edge node to another. Or a stream could be 133 the aggregate of packets making up a logical connection in 134 either a layer 2 or layer 3 VPN. The mechanisms that support 135 these discriminations could be based, for example, on hardware 136 accelerated classification of the IP header, on MPLS labels, 137 on ATM VPI/VCIs, on the VPN Identifier [HeRo], or a 138 combination of these. We consider that one of the first areas 139 of application may be in conjunction with MPLS. 141 The GR PHB specifies the requirement on a network node that 142 its behavior with respect to the specified stream should be to 143 provide a minimum service rate according to the committed rate 144 and burst limit parameters. Clearly the network node needs to 145 be told the stream specification and the values of the 146 parameters. Protocols that could be used (or be extended so 147 that they could be used) to carry these data include SNMP, 148 CMIP, LDP, RSVP, BGP4, and the various ATM signalling 149 protocols. The issues involved in distributing the data are 150 not discussed in this draft. The related issues, including 151 resource allocation, route selection, and resource congestion, 152 are also side-stepped by limiting this draft's scope to the 153 diff-serv charter. 155 So far we have only considered applying GR to non-multicast 156 streams. To accommodate multicast applications the proposed GR 157 PHB (section 2.3.2) would need to be extended to allow for 158 multiple-input and/or multiple-output "generalized streams." 160 The GR proposal has been developed around the notion that the 161 GR PBH (with it's rate and burst limit parameters) applies to 162 a specific network stream. However, components of the proposal 163 may have broader applicability. Something akin to GR service, 164 but without the stream orientation, has already been discussed 165 within in the diff-serv framework. In such schemes a traffic 166 conditioner at the network's ingress edge would monitor the 167 rate of user traffic sent to the network (or perhaps the rate 168 of a portion of that traffic as defined by a packet 169 discriminator) and mark the traffic as either "in" or "out" of 170 profile accordingly. Engineering of network resources 171 according to a projected network traffic load matrix is used 172 and the per hop resource reservation associated with the GR 173 PBH is avoided. It may be that the same service representation 174 (we propose a formal service representation for GR in section 175 2.3.1) may be used for both the stream oriented approach to 176 resource allocation and the network traffic engineering 177 approach. 179 2.3 Components of GR 181 The components of the GR service discussed here are the GR PHB, 182 the representation of the GR service and the edge traffic 183 conditioner. Compared to ATM these are related in some way to 184 GFR's conformance definition and service guarantee. Several 185 options are discussed below with an indication of our preference. 187 2.3.1 Service representation 188 The term "service representation" (SR) refers to a description of 189 the service that the network commits to provide to the user. The 190 SR includes a description of guaranteed minimum rate and the 191 packet characteristics that identify the stream of packets to 192 which the service commitment applies. 193 In the context of diff-serv the SR is not the central part of the 194 GR proposal. The motivation for including a formal specification 195 for the SR is to allow us to demonstrate how a formally defined 196 level of network service can be built on the basis of the PHB of 197 the following section. 198 The guaranteed minimum rate is defined using a leaky bucket and 199 rate and credit parameter. Appendix A defines an algorithm we 200 call the GPRA(x, y) (generic packet rate algorithm) where x is 201 the abstract rate parameter in bytes/s and y is the abstract 202 credit limit parameter in bytes. 203 The SR is characterized by the triplet (S, CR, BL). S is the set 204 of characteristics of the packet stream to which service is being 205 committed. The guaranteed minimum rate specification in is 206 defined as GPRA(CR, BL) where CR is the committed rate in bit/s 207 and BL is the burst limit in bytes. 208 The interpretation of this SR is: The network commits to 209 transporting with minimal loss at least those packets belonging 210 to the stream specified by S that pass a hypothetical 211 implementation of the GPRA(CR, BL) located at the network's 212 ingress interface. 214 2.3.1.1 Additional parameters 215 The (CR, BL) portion of the SR is essentially a restricted 216 version of the Tspec (traffic specification) defined in [RFC2212] 217 for use in specifying traffic to be serviced with delay 218 guarantees. In addition to the rate and burst limit (referred to 219 as the "bucket depth" in [RFC2212]), a Tspec contains a peak 220 rate, a minimum policed unit,and a maximum datagram size. 221 Some applications naturally generate packet streams with a 222 bounded short term data rate while other applications may 223 comfortably adapt to such a bounded "peak" rate. If a peak rate 224 limited stream is forwarded across network trunks with a large 225 bandwidth capacity relative to the stream's peak rate then 226 network nodes may be able to make significant savings in resource 227 allocation using knowledge of the peak rate. If these savings 228 were of sufficient value to ISPs it might be worth considering 229 introducing a peak rate specification into both the SR and the 230 PHB. Similarly, introducing a minimum policed unit or a maximum 231 datagram size could be considered. 232 For the time being we consider the additional complexity 233 associated with these extra parameters to be unjustified. 235 2.3.2 The GR PHB 236 The GR PHB is characterized by the triplet (S, R, L) where S is 237 the set of characteristics that exclusively identify a stream of 238 packets. R defines a minimum service rate for the stream in 239 bytes/s and L defines the tolerance to bursts that the node MUST 240 provide. 241 With respect to a stream specified by S the network node MUST 242 forward to the stream's output port, with high probability, at 243 least those packets that would pass a hypothetical GPRA(R, L) 244 algorithm located at the streams input port. 245 Resources available for the service of excess GR traffic MUST be 246 divided fairly among the active GR streams. The definition of 247 fairness is implementation and/or network specific. 249 2.3.3 Traffic conditioning 250 Several possibilities present themselves for traffic 251 conditioning. 252 The most obvious possibility is that the conditioner monitors the 253 rate of the incoming stream relative to the committed rate and 254 burst limit and sets the "IN" bit of the DS octet of incoming 255 packets accordingly. 256 If the peak rate parameter is defined then the conditioner has 257 the possibility of discarding traffic in excess of the specified 258 peak rate. Alternatively if In/Out marking according to the 259 committed rate is not required then In/Out marking could be 260 performed with respect to the peak rate. In the latter case the 261 GR PHB could be modified so that the service commitment in 262 network nodes applies only to "In" packets. 263 For the time being we consider the utility of the above 264 conditioning primitives to be unsubstantiated and therefore not 265 required. 267 3. Concatenation of PHBs 269 We have made the suggestion that the GR PHB is a useful building 270 block from which and edge-to-edge guaranteed rate service may, 271 together with some additional mechanisms outside the scope of 272 diff-serv, be constructed. In this chapter we attempt to show how 273 this might be done and to include some discussion of the 274 reasoning behind the proposal. 276 Assume that a mechanism is in place to identify a particular 277 stream of packets, and that a network node queues these packets 278 and schedules their transmission in a way that attempts to ensure 279 a service rate which is always at least R as defined in the GR 280 PHB. This "guaranteed rate" behavior could take a number of 281 forms. One example of a form this could take is described in the 282 following theorem, which also describes an implication of this 283 particular behavior. 285 THEOREM: Let a_j be the arrival time of the start of 286 packet j, let t_j be the time when the start of packet j 287 is transmitted, and let TL_j be the total length of 288 packet j. Suppose the transmission times satisfy s_j < 289 t_j < s_j + T_2, where s_(j+1) - s_j <= (TL_j/R), and 290 also suppose that if a packet arrives when no other 291 packets in the stream are awaiting transmission, then a_j 292 + T_0 <= s_j < a_j + T_0 + T_1. T_0, T_1, and T_2 are, 293 respectively, the fixed empty-queue packet latency, the 294 maximum variation in the empty-queue packet latency, and 295 the scheduling tolerance. Then, if the arriving packets 296 all pass GPRA(R, B), the transmitted packets will all 297 pass GPRA(R, (B + (T_0 + T_1)*R)) 299 The proof of this theorem is given in Appendix B. 301 Though perhaps not all "guaranteed rate" nodes will schedule 302 packets in a way that fits this form, the preceding theorem 303 suggests that it is reasonable to expect that a significant class 304 of such devices would have the ability to guarantee that if the 305 input packet stream satisfies GPRA(R, B) then the output packet 306 stream will satisfy GPRA(R, B + BTI) where BTI is the devices 307 burst tolerance increment for the stream in question. 308 This result allows us to consider several possible schemes by 309 which an edge-to-edge guaranteed rate service commitment may be 310 made. For example, if we know that each node has a BTI that does 311 not exceed BTI_max then we can establish GR service with 312 parameters {S, CR, and BL} by provisioning a GR PHB with 313 parameters {S, R = CR, and B = BL + BTI_max} along the stream's 314 path though the network. 315 We do not attempt to specify the rules by which a network 316 operator should distribute appropriate GR PHB parameters. To some 317 extent the appropriate scheme will depend on characteristics of 318 the implementation of the GR PBH in network nodes. It may also 319 depend on limitations of the protocol used to distribute the 320 parameters. 321 GR service can also be supported across concatenated GR diff-serv 322 networks. 324 4. Interworking with ATM 326 One of the aims of the GR diff-serv proposal is that it should 327 facilitate interworking with ATM to some extent. So far, the ATM 328 service categories (CBR, VBR-rt, VBR-nrt, ABR and UBR) have not 329 proven to be very well adapted to the needs of data networking or 330 the Internet. On the other hand the GFR proposal is intended to 331 provide a service category designed to work well for applications 332 in IP networks and the Internet. We assume that in the future a 333 mixture of network technologies including ATM will co-exist and 334 interoperate within our networks hence the desire for GR-ATM 335 interworking. 336 There are many ways in which ATM can be incorporated into IP 337 networks and without discussing these we identify two approaches 338 to GR-ATM interworking: 339 - the GR PHB is mapped onto an ATM switch, or 340 - the GR service is mapped onto an ATM connection. 342 5. Implementation example 344 A description of how GR could be deployed in an MPLS context. 345 TBD. 347 6. Security considerations 349 Not thought about yet. 351 References 353 [Hein] J. Heinanen, "MCR for UBR," ATM Forum 354 Contribution 96-0362, April 1996. 356 [TM5] ATM Forum Traffic Management Baseline Text 357 Document, , May 1998. 359 [NiBl] K. Nichols and S. Blake (editors), 360 "Differentiated Services Operational Model and 361 Definitions," Internet Draft , Feb 1998. 364 [Call] R. Callon et al, "A Framework for Multiprotocol 365 Label Switching," Internet Draft , Nov 1997. 368 [HeRo] J. Heinanen and E. Rosen, "VPN support with 369 MPLS," Internet Draft , Mar 1998. 372 [RFC2212] S. Shenker, C. Partridge, R. 373 Guerin,"Specification of Guaranteed Quality of 374 Service," RFC 2212, Sep 1997. 376 Appendix A. 378 The Generic Packet Rate Algorithm GPRA(x, y) 380 Define a Generic Packet Rate Algorithm, GPRA(x, y), where x is a 381 rate specified in bits per second and y is a burst tolerance 382 expressed in bytes. The algorithm has two state variables, the 383 traffic excess over x, W, and the last pass time, LPT. 384 Initially, W = 0, and LPT = 0, assuming t >= 0. 385 Let TL be the total length in bytes of an arriving packet, and 386 let t_a be the arrival time of the start of the packet. When a 387 packet arrives, the algorithm executes as follows. 389 W' = W - (t_a - LPT)*x 390 if ( (W' > y) or (external factor indicates no-pass) ) 391 then 392 pass = false 393 else 394 pass = true 395 end if 397 if (pass) then 398 W = max(W', 0) + TL 399 LPT = t_a 400 end if 401 The output of the algorithm is the variable pass which classifies 402 a stream's packets as being either in (i.e. pass == true) or out 403 of the traffic profile established by the parameters x and y.. 405 Appendix B. 407 Proof of the concatenation theorem 408 To be written. Based on a closely related proof by R. Wentworth 409 given in ATM_Forum contribution 97-0980, Dec 1997. 411 Authors' Addresses 413 Tom Worster Avri Doria 414 General DataComm, Inc. General DataComm, Inc. 415 5 Mount Royal Avenue 5 Mount Royal Avenue 416 Marlboro MA 01752 Marlboro MA 01752 417 Tel: +1 508 624 6723 x224 Tel: +1 508 624 6723 x236 418 Fax: +1 508 481 3668 Fax: +1 508 481 3668 419 tom.worster@gdc.com avri@gdc.com 421 Robert Wentworth 422 Hyundai Network Systems 423 520 Herndon Parkway 424 Herndon, VA 20170-5225 425 Tel: 703-478-2400 426 Fax: 703-478-2405 427 rhw@va.hea.com