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