idnits 2.17.1 draft-ietf-diffserv-ba-def-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: ---------------------------------------------------------------------------- ** 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? ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 959 lines 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 is 1 instance of too long lines in the document, the longest one being 68 characters in excess of 72. ** There are 29 instances of lines with control characters in the document. ** The abstract seems to contain references ([MODEL,MIB]), 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 363: '...eristics of a BA MUST be independent o...' RFC 2119 keyword, line 382: '...d be distinguished with MAY, MUST, and...' RFC 2119 keyword, line 396: '...be used but they MUST be explicit, qua...' RFC 2119 keyword, line 409: '...teristics of a BA MAY be parameterized...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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) == Unused Reference: 'RFC2597' is defined on line 825, but no explicit reference was found in the text == Unused Reference: 'MODEL' is defined on line 833, but no explicit reference was found in the text == Unused Reference: 'MIB' is defined on line 836, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 2598 (Obsoleted by RFC 3246) == Outdated reference: A later version (-06) exists of draft-ietf-diffserv-model-01 ** Downref: Normative reference to an Informational draft: draft-ietf-diffserv-model (ref. 'MODEL') == Outdated reference: A later version (-16) exists of draft-ietf-diffserv-mib-01 Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force K. Nichols 2 Differentiated Services Working Group Cisco Systems 3 Internet Draft Brian Carpenter 4 Expires in August, 2000 IBM 5 draft-ietf-diffserv-ba-def-00.txt February, 2000 7 Definition of Differentiated Services Behavior Aggregates and 8 Rules for their Specification 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance 15 with all provisions of Section 10 of RFC2026. Internet-Drafts are 16 working documents of the Internet Engineering Task Force 17 (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other doc- 22 uments at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in 24 progress." 26 This document is a product of the Diffserv working group. Com- 27 ments on this draft should be directed to the Diffserv mailing list 28 . 30 The list of current Internet-Drafts can be 31 accessed at http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed 34 at http://www.ietf.org/shadow.html. 36 Distribution of this memo is unlimited. 38 Copyright Notice 40 Copyright (C) The Internet Society (2000). All Rights Reserved. 42 Abstract 44 The diffserv WG has defined the general architecture for differen- 45 tiated services (RFC 2475) and has been focused on the definition 46 and standardization of the "per-hop forwarding behaviors" (or 47 PHBs) required in routers (RFCs 2474, 2597, and 2598). The dif- 48 ferentiated services framework creates services within a network 49 by applying rules at the edges in the creation of traffic aggregates 50 (known as Behavior Aggregates) coupled with the forwarding 51 path behavior. The WG has also discussed the behavior required 52 at diffserv network edges or boundaries for conditioning the 53 aggregates, elements such as policers and shapers [MODEL, 54 MIB]. A major feature of diffserv is that only the components 55 applying the rules at the edge need to be changed in response to 56 short-term changes in QoS goals in the network, rather than 58 Nichols and Carpenter Expires: August, 2000 [page 1] 59 The next step for the WG is to lay out how the forwarding path 60 components (PHBs, classifiers, and traffic conditioners) can be 61 used within the architectural framework to compose specific 62 Behavior Aggregates. These BAs should have properties such that 63 the transit of individual packets of a BA through a differentiated 64 services network can be characterized by specific metrics. How- 65 ever, no microflow information should be required as packets 66 transit a differentiated services network. 68 This document defines and discusses Behavior Aggregates in 69 detail and lays out the format and required content for contribu- 70 tions to the Diffserv WG on BAs and the rules that will be applied 71 for individual BA specifications to advance as WG products. This 72 format is specified to expedite working group review of BA sub- 73 missions. 75 A pdf version of this document is available at: 76 ftp://ftp-eng.cisco.com/ftp/kmn-group/docs/ba_def.pdf. 78 Table of Contents 80 1. Introduction................................................ 2 82 2. Some Definitions from RFC 2474.............................. 3 84 3. The Value of Defining Edge-to-Edge BAs...................... 3 86 4. Understanding Diffserv Behavior Aggregates.................. 4 88 5. Format for Specification of Diffserv Behavior Aggregates.... 6 90 6. Structuring BAs to Meet Expectations........................ 7 92 7. Reference Behavior Aggregates............................... 10 94 8. Sketchy Examples of Creating and Using BAs.................. 11 96 9. Procedure for submitting BAs to Diffserv WG................. 12 98 10 Acknowledgements............................................ 13 100 1.0 Introduction 102 Differentiated Services allows an approach to IP QoS that is mod- 103 ular, high performance, incrementally deployable, and scalable 104 [RFC2475]. Although an ultimate goal is interdomain quality of 105 service, there remain many untaken steps on the road to achieving 106 this goal. One essential step, the evolution of the business models 107 for interdomain QoS, will necessarily develop outside of the 108 IETF. A goal of the diffserv WG is to provide the firm technical 110 Nichols and Carpenter Expires: August, 2000 [page 2] 111 The Diffserv WG has finished the first phase of standardizing the 112 behaviors required in the forwarding path of all network nodes, 113 the per-hop forwarding behaviors or PHBs. The PHBs defined in 114 RFCs 2474, 2597 and 2598 give a rich toolbox for differential 115 packet handling. Although business models will have to evolve 116 over time, there are technical issues in moving "beyond the box" 117 that lead to QoS models within a single network, i.e., not crossing 118 administrative domain boundaries. Providing QoS within a single 119 network is useful in itself and will provide useful deployment 120 experience for further IETF work as well as for the evolution of 121 business models. This step is critical in the evolution of Diffserv 122 QoS and should ultimately provide the technical input that will 123 aid in the construction of business models. The ultimate goal of 124 creating end to end QoS in the Internet imposes the requirement 125 that we can create and quantify a behavior for a group of packets 126 that is preserved when they are aggregated with other packets. 128 Once packets have crossed the DS boundary, adherence to the 129 diffserv framework makes it possible to group packets solely 130 according to the behavior they receive at each hop. This approach 131 has well-known scaling advantages, both in the forwarding path 132 and in the control plane. Less well recognized is that these scaling 133 properties only result if the per-hop behavior definition gives rise 134 to a particular type of invariance under aggregation. Since the per- 135 hop behavior must be the same for every node in the domain 136 while the set of packets marked for that PHB may be different at 137 every node, a PHB should be defined such that its treatment of 138 packets of a behavior aggregate doesn't change when other pack- 139 ets join or leave the BA. If the properties of a BA using a particu- 140 lar PHB hold regardless of how the aggregate mutates as it 141 traverses the domain, then that BA scales. If there are limits to 142 where the properties hold, that translates to a limit on the size or 143 topology of a DS domain that can use that BA. Although useful 144 single-link BAs might exist, BAs that are invariant with network 145 size or that have simple relationships with network size and 146 whose properties can recovered by reapplying rules (that is, form- 147 ing another diffserv boundary or edge to re-enforce the rules for 148 the aggregate) are needed for building scalable end-to-end quality 149 of service. 151 There is a clear distinction between the definition of a Behavior 152 Aggregate in a DS domain and a service that might be specified in 153 a Service Level Agreement. The BA definition is a technical 154 building block that couples rules, specific PHBs, and configura- 155 tions with specific observable characteristics. These definitions 156 are intended to be useful tools in configuring DS domains, but the 157 BA (or BAs) used by a provider are not expected to be visible to 158 customers any more than the specific PHBs employed in the pro- 159 vider's network would be. QoS providers are expected to select 160 their own measures to make customer-visible in contracts and 161 these may be stated quite differently from the characteristics in a 163 Nichols and Carpenter Expires: August, 2000 [page 3] 164 ISPs to construct differentiated services offerings; each may 165 choose different sets of tools, or even develop their own, in order 166 to achieve particular externally observable metrics. 168 This document defines Differentiated Services Behavior Aggre- 169 gates more precisely than past documents and specifies the format 170 that must be used for submissions of particular Behavior Aggre- 171 gates to the Diffserv WG. 173 2.0 Some Definitions from RFC 2474 175 The following definitions are stated in RFCs 2474 and 2475 and 176 are repeated here for easy reference: 178 Behavior Aggregate: a collection of packets with the same codepoint 179 crossing a link in a particular direction. The terms "aggregate" and 180 "behavior aggregate" are used interchangeably in this document. 182 Differentiated Services Domain: a contiguous portion of the Internet 183 over which a consistent set of differentiated services policies are 184 administered in a coordinated fashion. A differentiated services 185 domain can represent different administrative domains or autono- 186 mous systems, different trust regions, different network technologies 187 (e.g., cell/frame), hosts and routers, etc. Also DS domain. 189 Differentiated Services Boundary: the edge of a DS domain, where 190 classifiers and traffic conditioners are likely to be deployed. A diff- 191 erentiated services boundary can be further sub-divided into ingress 192 and egress nodes, where the ingress/egress nodes are the downstream/ 193 upstream nodes of a boundary link in a given traffic direction. 194 A differentiated services boundary typically is found at the ingress to 195 the first-hop differentiated services-compliant router (or network 196 node) that a host's packets traverse, or at the egress of the last-hop 197 differentiated services-compliant router or network node that packets 198 traverse before arriving at a host. This is sometimes referred to as theboundary at a leaf router. A differentiated services boundary may be 199 co-located with a host, subject to local policy. Also DS boundary. 201 3.0 The Value of Defining Edge-to-Edge BAs 203 Networks of DS domains can be connected to create end-to-end 204 services, but where DS domains are independently administered, 205 the evolution of the necessary business agreements and future sig- 206 naling arrangements will take some time. Early deployments will 207 be within a single administrative domain. The specification of the 208 transit expectations of behavior aggregates across DS domains 209 both assists in the deployment of that single-domain QoS and will 210 help enable the composition of end-to-end, cross domain services 211 to proceed. Putting aside the business issues, the same technical 212 issues that arise in interconnecting DS domains with homoge- 213 neous administration will arise in interconnecting the autono- 214 mous systems (ASs) of the Internet. 216 Nichols and Carpenter Expires: August, 2000 [page 4] 217 tered domains or Autonomous Systems (ASs), represented by the 218 circles in figure 1. To deploy ubiquitous end-to-end quality of ser- 219 vice in the Internet, a business models must evolve that include 220 issues of charging and reporting that are not in scope for the 221 IETF. In the meantime, there are many possible uses of quality of 222 service within an AS and the IETF can address the technical 223 issues in creating an intradomain QoS within a Differentiated 224 Services framework. In fact, this approach is quite amenable to 225 incremental deployment strategies. 227 Figure 1: Interconnection of ASs and DS Domains 229 A single AS (for example, B in figure 1) may be composed of 230 subnetworks and, as the definition allows, these can be separate 231 DS domains. For a number of reasons, it might be useful to have 232 multiple DS domains in an AS, most notable being to follow 233 topological and/or technological boundaries and to separate the 234 allocation of resources. If we confine ourselves to the DS bound- 235 aries between these "interior" DS domains, we avoid the non- 236 technical problems of setting up a service and can address the 237 issues of creating characterizable behavior aggregates. 239 The incentive structure for differentiated services is based on 240 upstream domains ensuring their traffic conforms to agreed upon 241 rules and downstream domains enforcing that conformance so 242 that characteristics of behavior aggregates might sensibly be com- 243 puted. The filled in boxes in figure 1 represent the conformance 244 ensurers (e.g., shapers) and conformance enforcers (e.g., polic- 245 ers). Although we expect that policers and shapers will be 246 required at the boundaries of ASs, they might appear anywhere, 247 or nowhere, inside the AS. Thus, the boxes at the DS boundaries 248 internal to the AS may or may not condition traffic. Understand- 249 ing behavior under aggregation will result in guidelines for the 250 placement of DS boundaries. 252 4.0 Understanding Diffserv Behavior Aggregates 254 4.1 Defining BAs 256 In this section we expand on the definition of Behavior Aggre- 257 gates given in RFCs 2474 and 2475. Those RFCs define a Differ- 258 entiated Services Behavior Aggregate as "a collection of packets 259 with the same DS codepoint crossing a link in a particular direc- 260 tion" and further state that packets with the same DSCP get the 261 same per-hop forwarding treatment (or PHB) everywhere inside a 262 single DS domain. Note that even if multiple DSCPs map to the 263 same PHB, this must hold for each DSCP individually. 265 Within a DS domain, BAs are formed by the application of rules 266 to packets arriving at the DS boundary, through classification and 267 traffic conditioning. Packets that conform to the rules are marked 268 with the same DSCP (or a known set of DSCPs) within a domain. 270 Nichols and Carpenter Expires: August, 2000 [page 5] 271 remarked, as there are no rules being applied. Though a DS 272 domain may be as small as a single node, more complex topolo- 273 gies are expected to be the norm, thus the BA's definition must 274 hold as it is split and merged on the interior links of a DS domain. 275 Packet flow in a network is not part of the BA definition; the 276 application of rules as packets enter the DS domain and the con- 277 sistent PHB through the DS domain must suffice. (Though limits 278 can be put on the applicability of a specific BA.) 280 Associated with each BA are measurable, quantifiable, character- 281 istics which can be used to describe what will happen to packets 282 of that BA as they cross the DS domain. These expectations 283 derive from the rules that are enforced during the entry of packets 284 into the DS domain (the creation of the BA) and the forwarding 285 treatment (PHB) the BA gets inside the cloud. They may be abso- 286 lute or statistical bounds and they may be parameterized by net- 287 work properties. 289 4.2 Constructing BAs 291 Generally, the forwarding path of a DS domain is configured to 292 meet the network operator's traffic engineering goals for the 293 domain, independently of the performance goals for a particular 294 flow of a BA. Once the interior is configured, the rules on allocat- 295 ing BAs come from meeting the desired performance goals sub- 296 ject to that configuration of link schedulers and bandwidth. The 297 rules at the edge may be altered by provisioning or admission 298 control but the decision about which to use and how to apply the 299 rules comes from matching performance to goals. 301 For example, consider the diffserv domain of figure 1. A BA 302 which specifies explicit bounds on loss must have rules at the 303 edge to ensure that, on the average, no more packets are admitted 304 than can emerge. As the network can contain queues, input traffic 305 may not equal the output traffic over all timescales. However the 306 averaging timescale should not exceed what might be expected 307 for reasonably sized buffering inside the network. Thus if we 308 allow bursts to arrive into the interior of the network, we must 309 know there is enough capacity to ensure that losses don't exceed 310 the BA's bound. Note that explicit bounds on the loss level can be 311 particularly difficult as the exact way in which packets of a partic- 312 ular BA merge inside the network affect the aggregate burstiness 313 and hence, loss. 315 PHBs give explicit expressions of what treatment a BA can 316 expect from each hop. This behavior must continue to apply 317 under aggregation of merging BA flows. Explicit expressions of 318 what happens to this behavior under aggregation, possibly param- 319 eterized by node in-degrees or network diameters are required. 320 This allows us to determine what to do at internal aggregation 321 points. For example, do we reapply edge rules? 323 Nichols and Carpenter Expires: August, 2000 [page 6] 324 under aggregation. Rules must be recursively applied to result in a 325 known behavior. As an example, since maximum burst sizes grow 326 with the number of microflows or BA flows merged, a BA speci- 327 fication must address this. A clear advantage of constructing 328 behaviors that aggregate is the ease of building up BAs that span 329 interior DS domains and eventually farther. For example, a BA 330 with known properties that crosses an interior DS domain of AS 331 B in figure 1, can be merged with the same type of BA at the inte- 332 rior shaded routers. Using the same (or fewer) rules as were 333 applied to create the BA at the entrance to AS B, there should be 334 confidence that the BA can continue to be quantified by the 335 expected behavior. 337 The specification of the transit expectations of behavior aggre- 338 gates across domains both assists in the deployment of QoS 339 within a DS domain and helps enable the composition of end-to- 340 end, cross-domain services to proceed. 342 4.3 Forwarding path vs. control plane for BAs 344 The PHB and the edge rules that form and condition BAs are in 345 the forwarding path and take place at line rates while the configu- 346 ration of the DS domain edge to enforce rules on who goes into a 347 BA and how the BA should behave temporally is done by the con- 348 trol plane on a very different time scale. For example, configura- 349 tion of PHBs might only occur monthly or quarterly. The edge 350 rules might be reconfigured at a few regular intervals during the 351 day or might happen in response to signalling decisions thou- 352 sands of times a day. Even at the shortest time scale, control plane 353 actions are not expected to happen per-packet. Much of the con- 354 trol plane work is still evolving and is outside the charter of the 355 Diffserv WG since how the configuration is done and at what 356 time scale it is done should not affect the characteristics of the 357 BA. 359 5.0 Format for Specification of Diffserv Behavior Aggregates 361 Behavior Aggregates arise from a particular relationship between 362 edge and interior (which may be parameterized). The quantifiable 363 characteristics of a BA MUST be independent of whether the net- 364 work edge is configured statically or dynamically. The particular 365 configuration of traffic conditioners at the DS domain edge is 366 critical to how a BA performs, but the act(s) of configuring the 367 edge is a control plane action which can be separated from the 368 specification of the BA. 370 The following sections must be present in any specification of a 371 Differentiated Services Behavior Aggregate. Of necessity, their 372 length and content will vary greatly. 374 5.1 Applicability Statement 376 Nichols and Carpenter Expires: August, 2000 [page 7] 377 intended use of this BA and the limits to its use. 379 5.2 Rules 381 This section describes the rules to be followed in the creation of 382 this BA. Rules should be distinguished with MAY, MUST, and 383 SHOULD. The rules specify the edge behavior and configuration 384 and the PHB (or PHBs) to be used and any additional require- 385 ments on their configuration beyond that contained in RFCs. 387 5.3 Characteristics 389 The characteristics of a BA tell how it behaves under ideal condi- 390 tions if configured in a specified manner (where the specification 391 may be parameterized). Characteristics of a BA might be drop 392 rate, throughput, delay bounds measured over some time period. 393 They may be absolute bounds or statistical bounds (e.g., "90% of 394 all packets measured over intervals of at least 5 minutes will cross 395 the DS domain in less than 5 milliseconds"). A wide variety of 396 characteristics may be used but they MUST be explicit, quantifi- 397 able, and defensible. Where particular statistics are used, the doc- 398 ument must be precise about how they are to be measured and 399 about how the characteristics were derived. 401 Advice to a network operator would be to use these characteris- 402 tics as guidelines in creating a service specification rather than 403 use them directly. For example, a "loss-free" BA would probably 404 not be sold as such, but rather as a service with a very small 405 packet loss probability. 407 5.4 Parameters 409 The definition and characteristics of a BA MAY be parameterized 410 by network-specific features; for example, maximum number of 411 hops, minimum bandwidth, total number of entry/exit points of 412 the BA to/from the diffserv network, maximum transit delay of 413 network elements, minimum buffer size available for the BA at a 414 network node, etc. 416 5.5 Assumptions 418 In most cases, BAs will be characterized assuming lossless links, 419 no link failures, and relatively stable routing. This is reasonable 420 since otherwise it would be very difficult to quantify behavior. 421 However, these assumptions must be clearly stated. If additional 422 restrictions, e.g., route pinning, are required, these must be stated. 423 Some BAs may be developed without these assumptions, e.g., for 424 high loss rate links, and these must also be made explicit. 426 Further, if any assumptions are made about the allocation of 427 resources within a diffserv network in the creation of the aggre- 428 gate, these must be made explicit. 430 Nichols and Carpenter Expires: August, 2000 [page 8] 431 5.6 Example Uses 433 A BA specification must give example uses to motivate the under- 434 standing of ways in which a diffserv network could make use of 435 the BA although these are not expected to be detailed. For exam- 436 ple, "A bulk handling behavior aggregate may be used for all 437 packets which should not take any resources from the network 438 unless they would otherwise go unused. This might be useful for 439 Netnews traffic or for traffic rejected from some other BA due to 440 violation of that BA's rules." 442 5.7 Environmental Concerns (media, topology, etc.) 444 Note that it is not necessary for a provider to expose what Behav- 445 ior Aggregate (if a commonly defined one) is being used nor is it 446 necessary for a provider to specify the service by the BA's charac- 447 teristics. For example, a service provider might use a BA with a 448 "no queueing loss" characteristic in order to specify a "very low 449 loss" service. 451 This section is to inject realism into the characteristics described 452 above. Detail the assumptions made there and what constraints 453 that puts on topology or type of physical media or allocation. 455 6.0 Structuring BAs to Meet Expectations 457 Associated with each BA is an expectation: measurable, quantifi- 458 able, characteristics which can be used to describe what will hap- 459 pen to packets of that BA as they cross the domain. These 460 expectations result directly from the application of rules enforced 461 during the creation of the BA and/or its entry into the domain and 462 the forwarding treatment (PHB) packets of the BA get inside the 463 domain. There are many ways in which traffic might be distrib- 464 uted, but creating a quantifiable, realizable service across the DS 465 domain will limit the scenarios which can occur. There is a clear 466 correlation between the strictness of the rules and the quality of 467 the characterization of the BA. 469 There are two kinds of BA properties to consider. First are the 470 properties over "long" time periods, or average behaviors. In a 471 description of a BA, these would be the rates or throughput seen 472 over some specified time period. The second set of properties has 473 to do with the "short" time behavior, usually expressed as the 474 allowable burstiness in an aggregate. The short time behavior is 475 important is understanding the buffering (and associated loss 476 characteristics) and in quantifying how the BA aggregates, either 477 within a DS domain or at the boundaries. For short-time behavior, 478 we are interested primarily in two things: 1) how many back-to- 479 back packets of this BA will we see at any point (this would be 480 metered as a burst) and 2) how large a burst of packets of this BA 481 can appear in a queue at once (gives queue overflow and loss). 483 Nichols and Carpenter Expires: August, 2000 [page 9] 484 question: Under what conditions can we join the output of this 485 domain to another under the same rules and expectations? 487 6.1 Considerations in specifying long-term or average BA 488 characteristics 490 To make this more concrete, consider the DS domain of figure 2. 491 First consider the average or long-term behavior that must be 492 specified for a target BA which we designate as BAx. Can the DS 493 domain handle the average traffic flow? Is that answer topology- 494 dependent or are there some specific assumptions on routing 495 which must hold for BAx to preserve its "adequately provi- 496 sioned" capability? In other words, if the topology of D changes 497 suddenly, will the properties of BAx change? Will the loss rate of 498 BAx dramatically increase? 500 Figure 2: ISP and DS domain D connected in a ring and connected 501 to DS domain E 503 Let figure 2 be an ISP ringing the U.S. with links of bandwidth B 504 and with N tails to various metropolitan areas. If the link between 505 the node connected to A and the node connected to Z were to go 506 down, causing all the BAx traffic between the two to transit the 507 entire ring, would the bounded behavior of BAx change? If some 508 node of the ring now has a larger arrival rate to one of its links 509 than the capacity of the link for BAx, clearly the loss rate would 510 change dramatically. In that case, there were topological assump- 511 tions made about the path of the traffic from A to Z that affected 512 the characteristics of BAx. Once these no longer hold, any 513 assumptions on the loss rate of packets of BAx crossing the 514 domain would change; for example, a characteristic such as "loss 515 rate no greater than 1% over any interval larger than 10 minutes" 516 would no longer hold. A BA specification should spell out the 517 assumptions made on preserving the characteristics. 519 6.2 Considerations in specifying short-term or bursty BA 520 characteristics 522 Next, consider the short-time behavior of a BA, specifically 523 whether permitting the maximum bursts to add in the same man- 524 ner as the average rates will lead to properties that aggregate or 525 under what rules this will lead to properties that aggregate. In our 526 example, if domain D allows each of the uplinks to burst of p 527 packets into BAx, they could accumulate as they transit the ring. 528 For packets headed for link L, back-to-back BAx packets can 529 come from both directions and arrive at the same time. If the 530 bandwidth of link L is the same as the links of the ring, this prob- 531 ably does not present a buffering problem. If there are two input 532 links that can send packets to queue for L, at worst, two packets 533 can arrive simultaneously for L. If the bandwidth of link L equals 534 or exceeds twice B, the packets won't accumulate. Further, if p is 535 limited to one, and the bandwidth of L exceeds the rate of arrival 537 Nichols and Carpenter Expires: August, 2000 [page 10] 538 loss) then the queue of BAx packets for link L will empty before 539 new packets arrive. If the bandwidth of L is equal to B, one packet 540 of BAx must queue while the other is transmitted. This would 541 result in N x p back-to-back packets of BAx arriving over L dur- 542 ing the same time scale as the bursts of p were permitted on the 543 uplinks. Link L should be configured to handle the sum of the 544 rates that ingress to BAx, but that doesn't guarantee that it can 545 handle the sum of the N bursts into BAx. 547 If the bandwidth of L is less than B, then the link must buffer 548 Nxpx(B-L)/B BAx packets to avoid loss. If BAx is getting less 549 than the full bandwidth L, this number is larger. For probabilistic 550 bounds, a smaller buffer might do if the probability of exceeding 551 it can be bounded. 553 More generally, for router indegree of d, bursts of BAx packets 554 might arrive on each input. Then, in the absence of any additional 555 rules, it is possible that dxpx(# of uplinks) back-to-back BAx 556 packets can be sent across link L to domain E. Thus the DS 557 domain E must permit these much larger bursts into BAx than 558 domain D permits on the N uplinks or else the flow of BAx pack- 559 ets must be made to conform to the rules for entering E (e.g., by 560 shaping). 562 What conditions should be imposed on a BA and on the PHBs 563 which carry it in order to ensure BAs that can be interconnected 564 as across the interior DS domains of figure 1? Edge rules for con- 565 structing a BA that has certain characteristics across a DS domain 566 should apply independently of the origin of the packets. With ref- 567 erence to the example we've been exploring, the rules for a BA 568 entering link L into domain E should not depend on the number 569 of uplinks into domain D. 571 6.3 Example 573 Consider where all the uplinks have the same bandwidth B and 574 link L has bandwidth L which is less than or equal to B. Flows of 575 BAx packets from the N uplinks each have average rate R and are 576 destined to cross L. If only a fraction a of link L is allocated to 577 BAx, then R =axL/N fits the average rate constraint. If each of the 578 N flows can have a burst of p packets and half the flows transit 579 the ring in each direction, then 2xp packets can arrive at the BAx 580 queue for link L in time it took to transmit p packets on the ring, 581 p/B. Although the link scheduler for link L might allow the burst 582 of packets to be transmitted at the line rate L, after the burst allot- 583 ment has been exceeded, the queue should be expected to clear at 584 only rate axL. Then consider the packets that can accumulate. It 585 takes 2xp/(axL) to clear the queue of BAx packets. In that time, 586 bursts of p packets from the other uplinks can arrive from the 587 ring, so the packets do not even have to be back-to-back. Even if 588 the packets do not arrive back-to-back, but are spaced by less time 589 than it takes to clear the queue of BAx packets, either the required 591 Nichols and Carpenter Expires: August, 2000 [page 11] 592 across L becomes large and is a function of N, the number of 593 uplinks of domain D. 595 Let L = 1.5 Mbps, B = 45 Mbps, a = 1/3, N=10, p = 3. Suppose 596 that the bursts from two streams of BAx arrive at the queue for 597 link L very close together. Even if 3 of the packets are cleared at 598 the line rate of 1.5 Mbps, there will be 3 packets remaining to be 599 serviced at a 500 kbps rate. In the time allocated to send one of 600 these, 9 packets can arrive on each of the inputs from the ring. If 601 any non-zero number of these 18 packets are of BAx, the queue 602 size will not reduce. If two more bursts (6 of the 18 packets) 603 arrive, the queue increases to 8 packets. Thus, it's possible to 604 build up quite a large queue, one likely to exceed the buffer allo- 605 cated for BAx. The rate bound means that each of the uplinks will 606 be idle for the time to send three packets at 50 kbps, possibly by 607 policing at the ring egress, and thus the queue would eventually 608 decrease and clear, however, the queue at link L can still be very 609 large. There may be BAs where the intention is to permit loss, but 610 in that case, it should be constructed so as to provide a probabilis- 611 tic bound for the queue size to exceed a reasonable buffer size of 612 one or two bandwidth-delay products. Alternatively or addition- 613 ally, rules can be used that bound the amount of BAx that queues 614 by limiting the burst size at the ingress uplinks to one packet, 615 resulting in a maximum queue of N or 10 or to impose additional 616 rules on the creation of the aggregate, such as intermediate shap- 617 ing. 619 7.0 Reference Behavior Aggregates 621 The intent of this section is to define one or a few "reference" 622 BAs; certainly a Best Effort BA and perhaps others. This section 623 is very preliminary at this time and meant to be the starting point 624 for discussion rather than its end. These are BAs that have little in 625 the way of rules or expectations. 627 7.1 Best Effort Behavior Aggregate 629 7.1.1 Applicability 631 A Best Effort (BE) BA is for sending "normal internet traffic" 632 across a diffserv network. That is, the definition and use of this 633 BA is to preserve, to a reasonable extent, the pre-diffserv delivery 634 expectation for packets in a diffserv network that do not require 635 any special differentiation. 637 7.1.2 Rules 639 There are no rules governing rate and bursts of packets beyond 640 the limits imposed by the ingress link. At each network node in 641 the interior of the network, packets marked for this BA are given 642 the Default PHB (as defined in [RFC2474]). 644 Nichols and Carpenter Expires: August, 2000 [page 12] 645 "As much as possible as soon as possible". 647 Packets of this BA will not be completely starved and when 648 resources are available, this BA should be configured to consume 649 them. 651 Although some network operators may bound the delay and loss 652 rate for this aggregate given knowledge about their network, such 653 characteristics are not required. 655 7.1.4 Parameters 657 None. 659 7.1.5 Assumptions 661 A properly functioning network. 663 7.1.6 Example uses 665 1. For the normal Internet traffic connection of an organization. 667 2. For the "non-critical" Internet traffic of an organization. 669 7.2 Bulk Handling Behavior Aggregate 671 7.2.1 Applicability 673 A Bulk Handling (BH) BA is for sending extremely non-critical 674 traffic across a diffserv network. There should be an expectation 675 that these packets may be delayed or dropped when other traffic is 676 present. 678 7.2.2 Rules 680 There are no rules governing rate and bursts of packets beyond 681 the limits imposed by the ingress link. At each network node in 682 the interior of the network, packets marked for this BA are given 683 a CS or AF PHB configured so that it may be starved when other 684 traffic is present. 686 7.2.3 Characteristics of this BA 688 Packets are forwarded when there are idle resources. 690 7.2.4 Parameters 692 None. 694 7.2.5 Assumptions 696 Nichols and Carpenter Expires: August, 2000 [page 13] 697 7.2.6 Example uses 699 1. For Netnews and other "bulk mail" of the Internet. 701 2. For "downgraded" traffic from some other BA. 703 8.0 Sketchy Examples of Creating and Using BAs 705 There is a clear interaction between the number and strictness of 706 the rules and the number and strictness of quantifiable character- 707 istics for a BA. Examples of more strictly defined BAs will be 708 necessary to make this document's definitions clearer. This is 709 being addressed in two ways. One, a companion document is in 710 preparation defining a BA that uses the EF PHB and is related to 711 the VLL described in [RFC2598]. In addition, this section 712 includes two "sketchy" examples to motivate thinking and discus- 713 sion on BAs. The following examples are illustrative rather than 714 exhaustive or even complete. 716 The following should be looked at as "mythical" BAs that may 717 never see the light of day and will likely not appear in future revi- 718 sions of this document. 720 8.1 Loss Tolerant Provisioned 722 A loss-tolerant provisioned BA is useful for statistically provi- 723 sioning a BA whose packets should have low delay, but are loss- 724 tolerant. Rules for this aggregate are that entering composite BAs 725 must not exceed a peak rate of Rp and may not burst more than 726 two MTU packet-times at Rp. The BA uses CS3, selected by 727 DSCP03 and configured so that its minimum share of all internal 728 links is Smin (in bps), running active queue management with a 729 low threshold (defined in time rather than packets) and a small 730 maximum queue size (also in time). Characteristics of this BA: 732 Some 90th percentile bound on loss and delay. 734 Parameterized by Smin and Rp. The sum of all the Rp should be on 735 the order of some over provisioning factor (larger than 1). 737 Assumptions on these characteristics are that the network is oper- 738 ating under ideal conditions. 740 8.2 Preferred 742 A Preferred BA is for provisioning traffic so as to give low-load 743 performance across a DS domain. The rules governing it are that 744 the packets of this BA arriving over any ingress to the domain are 745 average rate-limited to Ra with a maximum burst size of Bmax. 746 The BA uses CS4, selected by DSCP04 and configured so that its 747 minimum share of all internal links is Smin (in bps) and the sum 749 Nichols and Carpenter Expires: August, 2000 [page 14] 750 Probabilistic bounds based on the sum of all allocated rates and 751 the burst size. 753 Throughput measured over 5 minute intervals will be at least Ra. 755 Assumptions on these characteristics are that the network is oper- 756 ating under ideal conditions. 758 Example uses: 760 1. A voice service where customer is guaranteed a conformant 761 packet loss rate of less than 0.5% and a latency bound of 20 ms, 762 99th percentile jitter less than 2 packet-times, median jitter of less 763 than a packet-time across the domain. 765 2. A "leased line replacement" where the customer is guaranteed 766 to receive throughput performance indistinguishable from a 767 leased line at Rp with a per-packet delay of less than 20 msec 768 through the cloud. 770 9.0 Procedure for submitting BAs to 771 Diffserv WG 773 1. Following the guidelines of this document, write a draft and 774 submit it as an Internet Draft and bring it to the attention of the 775 WG mailing list. 777 2. Initial discussion on the WG should focus primarily on the 778 merits of such a BA, though comments and questions on the 779 claimed characteristics are reasonable. 781 3. Once consensus has been reached on a version of a draft that it 782 is a useful BA and that the characteristics "appear" to be correct 783 (i.e., not egregiously wrong) that version of the draft goes to a 784 review panel the WG Co-chairs set up to audit and report on the 785 characteristics. The review panel will be given a deadline for the 786 review. The exact timing of the deadline will be set on a case-by- 787 case basis by the co-chairs to reflect the complexity of the task 788 and other constraints (IETF meetings, major holidays) but is 789 expected to be in the 4-8 week range. During that time, the panel 790 may correspond with the authors directly (cc'ing the WG co- 791 chairs) to get clarifications. This process should result in a revised 792 draft and/or a report to the WG from the panel that either 793 endorses or disputes the claimed characteristics. 795 4. If/when endorsed by the panel, that draft goes to WG last call. 796 If not endorsed, the author(s) can give a itemized response to the 797 panel's report and ask for a WG Last Call. 799 5. If/when passes Last Call, goes to ADs for publication as a WG 800 Informational RFC in our "BA series". 802 Nichols and Carpenter Expires: August, 2000 [pag 15] 803 ^L 804 10.0 Acknowledgements 806 The ideas in this document have been heavily influenced by the 807 Diffserv WG and, in particular, by discussions with Van Jacob- 808 son, Dave Clark, Lixia Zhang, Geoff Huston, Scott Bradner, 809 Randy Bush, Frank Kastenholz, Aaron Falk, and a host of other 810 people who should be acknowledged for their useful input but not 811 be held accountable for our mangling of it. 813 11.0 References 815 [RFC2474] RFC 2474, "Definition of the Differentiated Services 816 Field (DS Field) in the IPv4 and IPv6 Headers", 817 K.Nichols, S. Blake, F. Baker, D. Black, www.ietf.org/ 818 rfc/rfc2474.txt 820 [RFC2475] RFC 2475, "An Architecture for Differentiated Ser- 821 vices", S. Blake, D. Black, M.Carl- 822 son,E.Davies,Z.Wang,W.Weiss, www.ietf.org/rfc/ 823 rfc2475.txt 825 [RFC2597] RFC 2597, "Assured Forwarding PHB Group", F. 826 Baker, J. Heinanen, W. Weiss, J. Wroclawski, ftp:// 827 ftp.isi.edu/in-notes/rfc2597.txt 829 [RFC2598] RFC 2598, "An Expedited Forwarding PHB", 830 V.Jacobson, K.Nichols, K.Poduri, ftp://ftp.isi.edu/in- 831 notes/rfc2598.txt 833 [MODEL] "A Conceptual Model for Diffserv Routers", draft-ietf- 834 diffserv-model-01.txt, Bernet et. al. 836 [MIB] "Management Information Base for the Differentiated 837 Services Architecture", draft-ietf-diffserv-mib-01.txt, 838 Baker et. al. 840 Authors' Addresses 842 Kathleen Nichols Brian E. Carpenter 843 Cisco Systems IBM 844 170 West Tasman Drive c/o iCAIR 845 San Jose, CA 95134-1706 Suite 150 846 1890 Maple Avenue 847 email: kmn@cisco.com Evanston, IL 60201 848 USA 849 EMail: brian@icair.org