idnits 2.17.1 draft-ietf-diffserv-pdb-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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 18 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 18 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 233 has weird spacing: '...edge to edge"...' == Line 284 has weird spacing: '...ers and polic...' == Line 323 has weird spacing: '...edge to edge"...' == Line 347 has weird spacing: '...results from ...' -- 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: 'RFC2698' is defined on line 1012, but no explicit reference was found in the text == Unused Reference: 'VW' is defined on line 1022, 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) ** Downref: Normative reference to an Informational RFC: RFC 2698 == Outdated reference: A later version (-06) exists of draft-ietf-diffserv-model-02 ** 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 -- No information found for draft-ietf-diff-serv-ba-vw - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'VW' Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 4 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 Packet Design 3 Internet Draft B. Carpenter 4 Expires in December, 2000 IBM 5 draft-ietf-diffserv-pdb-def-00.txt June, 2000 7 Definition of Differentiated Services Per Domain 8 Behaviors and 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. Distribution of this memo is unlim- 32 ited. 34 Copyright Notice 36 Copyright (C) The Internet Society (2000). All Rights Reserved. 38 Abstract 40 The diffserv WG has defined the general architecture for differen- 41 tiated services (RFC 2475) and has been focused on the definition 42 and standardization of the forwarding path behavior required in 43 routers, known as "per-hop forwarding behaviors" (or PHBs) 44 (RFCs 2474, 2597, and 2598). The differentiated services frame- 45 work creates services within a network by applying rules at the 46 network edges to create traffic aggregates and coupling these with 47 a specific forwarding path treatment for the aggregate. The WG 48 has also discussed the behavior required at diffserv network edges 49 or boundaries for conditioning packet aggregates, such elements 50 as policers and shapers [MODEL, MIB]. A major feature of the 51 diffserv architecture is that only the components applying the 52 rules at the edge need to be changed in response to short-term 53 changes in QoS goals in the network, rather than reconfiguring 54 the interior behaviors. 56 The next step for the WG is to formulate examples of how the for- 58 Nichols and Carpenter Expires: December, 2000 [page 1 ] 59 warding path components (PHBs, classifiers, and traffic condi- 60 tioners) can be used within the architectural framework to 61 compose traffic aggregates whose packets experience specific 62 forwarding characteristics as they transit a differentiated services 63 domain. The WG has decided to use the term per-domain behav- 64 ior, or PDB, to describe the behavior experienced by packets of a 65 particular traffic aggregate as they cross a DS domain. PDBs can 66 be used to characterize, by specific metrics, the treatment individ- 67 ual packets with a particular DSCP (or set of DSCPs) will receive 68 as it crosses a DS domain. However, no microflow information 69 should be required as packets transit a differentiated services net- 70 work. A PDB is an expression of a fowarding path treatment, but 71 due to the role that particular choices of edge and PHB configura- 72 tion play in its resulting attributes, it is where the forwarding path 73 and the control plane interact. 75 This document defines and discusses Per Domain Behaviors in 76 detail and lays out the format and required content for contribu- 77 tions to the Diffserv WG on PDBs and the rules that will be 78 applied for individual PDB specifications to advance as WG 79 products. This format is specified to expedite working group 80 review of PDB submissions. 82 A pdf version of this document is available at: ftp://www.packet- 83 design.com/outgoing/ietf/pdb_def.pdf. 85 Table of Contents 87 1. Introduction ........................................ 2 89 2. Definitions ......................................... 3 91 3. The Value of Defining Edge-to-Edge Behavior ......... 4 93 4. Understanding Diffserv PDBs ......................... 5 95 5. Format for Specification of Diffserv PDBs ........... 8 97 6. PDB Attributes ..................................... 10 99 7. Reference Per-Domain Behaviors ..................... 13 101 8. Procedure for Submitting PDBs to Diffserv WG ....... 14 103 9. Acknowledgements ................................... 15 105 1.0 Introduction 107 Differentiated Services allows an approach to IP QoS that is mod- 108 ular, high performance, incrementally deployable, and scalable 109 [RFC2475]. Although an ultimate goal is interdomain quality of 110 service, there remain many untaken steps on the road to achieving 112 Nichols and Carpenter Expires: December, 2000 [page 2 ] 113 this goal. One essential step, the evolution of the business models 114 for interdomain QoS, will necessarily develop outside of the 115 IETF. A goal of the diffserv WG is to provide the firm technical 116 foundation that allows these business models to develop. 118 The Diffserv WG has finished the first phase of standardizing the 119 behaviors required in the forwarding path of all network nodes, 120 the per-hop forwarding behaviors or PHBs. The PHBs defined in 121 RFCs 2474, 2597 and 2598 give a rich toolbox for differential 122 packet handling. A diffserv Conceptual Model [MODEL] 123 describes a model of traffic conditioning and other forwarding 124 behaviors. 126 Although business models will have to evolve over time, there 127 also remain technical issues in moving "beyond the box" to QoS 128 models that apply within a single network domain. Providing 129 QoS on a per-domain basis is useful in itself and will provide use- 130 ful deployment experience for further IETF work as well as for 131 the evolution of business models. The step of specifying forward- 132 ing path attributes on a per-domain basis for a traffic aggregate 133 distinguished only by the mark in the DS field of individual pack- 134 ets is critical in the evolution of Diffserv QoS and should provide 135 the technical input that will aid in the construction of business 136 models. The ultimate goal of creating end to end QoS in the Inter- 137 net imposes the requirement that we can create and quantify a 138 behavior for a group of packets that is preserved when they are 139 aggregated with other packets. This document defines and speci- 140 fies the term "Per-Domain Behavior" or PDB to describe QoS 141 attributes across a DS domain. 143 In diffserv, rules are imposed on packets arriving at the boundary 144 of a DS domain through use of classification and traffic condi- 145 tioning which are set to reflect the policy and traffic goals for 146 that domain. Once packets have crossed the DS boundary, adherence 147 to diffserv principles makes it possible to group packets solely 148 according to the behavior they receive at each hop. This approach 149 has well-known scaling advantages, both in the forwarding path 150 and in the control plane. Less well recognized is that these scaling 151 properties only result if the per-hop behavior definition gives rise 152 to a particular type of invariance under aggregation. Since the 153 per-hop behavior must be equivalent for every node in the domain 154 while the set of packets marked for that PHB may be different at 155 every node, a PHB should be defined such that its defining char- 156 acteristics don't depend on the volume of the associated BA on a 157 router's ingress link nor on a particular path through the DS 158 domain taken by the packets marked for it. If the properties of a 159 PDB using a particular PHB hold regardless of how the marked 160 aggregate mutates as it traverses the domain, then that PDB 161 scales. If there are limits to where the properties hold, that 162 translates to a limit on the size or topology of a DS domain that 163 can use that PDB. Although useful single-link DS domains might 164 exist, PDBs that are invariant with network size or that have sim- 165 ple relationships with network size and whose properties can be 167 Nichols and Carpenter Expires: December, 2000 [page 3 ] 168 recovered by reapplying rules (that is, forming another diffserv 169 boundary or edge to re-enforce the rules for the aggregate) are 170 needed for building scalable end-to-end quality of service. 172 There is a clear distinction between the definition of a Per- 173 Domain Behavior in a DS domain and a service that might be 174 specified in a Service Level Agreement. The PDB definition is a 175 technical building block that couples rules, specific PHBs, and 176 configurations with a resulting set of specific observable 177 attributes which may be characterized in a variety of ways. These 178 definitions are intended to be useful tools in configuring DS 179 domains, but the PDB (or PDBs) used by a provider are not 180 expected to be visible to customers any more than the specific 181 PHBs employed in the provider's network would be. Network 182 providers are expected to select their own measures to make cus- 183 tomer-visible in contracts and these may be stated quite differ- 184 ently from the technical attributes specified in a PDB definition. 185 Similarly, specific PDBs are intended as tools for ISPs to con- 186 struct differentiated services offerings; each may choose different 187 sets of tools, or even develop their own, in order to achieve 188 particular externally observable metrics. 190 This document defines Differentiated Services Per-Domain 191 Behaviors and specifies the format that must be used for submis- 192 sions of particular PDBs to the Diffserv WG. 194 2.0 Definitions 196 The following definitions are stated in RFCs 2474 and 2475 and 197 are repeated here for easy reference: 199 o Behavior Aggregate: a collection of packets with the same codepoint 200 crossing a link in a particular direction. The terms "aggregate" and 201 "behavior aggregate" are used interchangeably in this document. 203 o Differentiated Services Domain: a contiguous portion of the Internet 204 over which a consistent set of differentiated services policies are 205 administered in a coordinated fashion. A differentiated services 206 domain can represent different administrative domains or autono- 207 mous systems, different trust regions, different network technologies 208 (e.g., cell/frame), hosts and routers, etc. Also DS domain. 210 o Differentiated Services Boundary: the edge of a DS domain, where 211 classifiers and traffic conditioners are likely to be deployed. A 212 differentiated services boundary can be further sub-divided into 213 ingress and egress nodes, where the ingress/egress nodes are the down- 214 stream/upstream nodes of a boundary link in a given traffic direction. 215 A differentiated services boundary typically is found at the ingress 216 to the first-hop differentiated services-compliant router (or network 217 node) that a host's packets traverse, or at the egress of the last-hop 218 differentiated services-compliant router or network node that packets 219 traverse before arriving at a host. This is sometimes referred to as 220 the boundary at a leaf router. A differentiated services boundary may 222 Nichols and Carpenter Expires: December, 2000 [page 4 ] 223 be co-located with a host, subject to local policy. Also DS boundary. 225 To these we add: 227 o Traffic Aggregate: a collection of packets with a codepoint that 228 maps to the same PHB, usually in a DS domain or some subset of a DS 229 domain. A traffic aggregate marked for a the foo PHB is referred to 230 as the "foo traffic aggregate" or the "foo aggregate" interchangeably. 232 o Per-Domain Behavior: the expected treatment that an identifiable or 233 target group of packets will receive from "edge to edge" of a DS 234 domain. (Also PDB.) A particular PHB (or, if applicable, list of 235 PHBs) and traffic conditioning requirements are associated with 236 each PDB. 238 3.0 The Value of Defining Edge-to-Edge 239 Behavior 241 Networks of DS domains can be connected to create end-to-end 242 services, but where DS domains are independently administered, 243 the evolution of the necessary business agreements and future sig- 244 naling arrangements will take some time. Early deployments will 245 be within a single administrative domain. Specification of the 246 transit expectations of packets matching a target for a particular 247 diffserv behavior across a DS domain both assists in the deploy- 248 ment of single-domain QoS and will help enable the composition 249 of end-to-end, cross domain services to proceed. Putting aside the 250 business issues, the same technical issues that arise in intercon- 251 necting DS domains with homogeneous administration will arise 252 in interconnecting the autonomous systems (ASs) of the Internet. 254 Today's Internet is composed of multiple independently adminis- 255 tered domains or Autonomous Systems (ASs), represented by the 256 circles in figure 1. To deploy ubiquitous end-to-end quality of ser- 257 vice in the Internet, business models must evolve that include 258 issues of charging and reporting that are not in scope for the 259 IETF. In the meantime, there are many possible uses of quality of 260 service within an AS and the IETF can address the technical 261 issues in creating an intradomain QoS within a Differentiated 262 Services framework. In fact, this approach is quite amenable to 263 incremental deployment strategies. 265 Figure 1: Interconnection of ASs and DS Domains 267 A single AS (for example, AS2 in figure 1) may be composed of 268 subnetworks and, as the definition allows, these can be separate 269 DS domains. For a number of reasons, it might be useful to have 270 multiple DS domains in an AS, most notable being to follow 271 topological and/or technological boundaries and to separate the 272 allocation of resources. If we confine ourselves to the DS bound- 273 aries between these "interior" DS domains, we avoid the non- 274 technical problems of setting up a service and can address the 275 issues of creating characterizable PDBs. 277 Nichols and Carpenter Expires: December, 2000 [page 5 ] 278 The incentive structure for differentiated services is based on 279 upstream domains ensuring their traffic conforms to agreed upon 280 rules and downstream domains enforcing that conformance, thus 281 metrics associated with PDBs can be sensibly computed. The 282 rectangular boxes in figure 1 represent the DS boundary routers 283 and thus would contain the traffic conditioners that ensure and 284 enforce conformance (e.g., shapers and policers). Although we 285 expect that policers and shapers will be required at the DS bound- 286 aries of ASs (dark rectangles), they might appear anywhere, or 287 nowhere, inside the AS. Thus, the boxes at the DS boundaries 288 internal to the AS (shaded rectangles) may or may not condition 289 traffic. Understanding a particular PDB's characteristics under 290 aggregation and multiple hops will result in guidelines for the 291 placement and configuration of DS boundaries. 293 This approach continues the separation of forwarding path and 294 control plane decribed in RFC 2474. The forwarding path charac- 295 teristics are addressed by considering what happens at every hop 296 of a packet's path and what behaviors can be characterized under 297 the merging and branching through multiple hops. The control 298 plane only needs to be employed in the configuration of the DS 299 boundaries. A PDB provides a link between the DS domain level 300 at which control is exercised to form traffic aggregates with qual- 301 ity-of-service goals across the domain and the per-hop and per- 302 link treatments packets receive that results in meeting the quality- 303 of-service goals. 305 4.0 Understanding PDBs 307 4.1 Defining PDBs 309 RFCs 2474 and 2475 define a Differentiated Services Behavior 310 Aggregate as "a collection of packets with the same DS codepoint 311 crossing a link in a particular direction" and further state that 312 packets with the same DSCP get the same per-hop forwarding 313 treatment (or PHB) everywhere inside a single DS domain. Note 314 that even if multiple DSCPs map to the same PHB, this must hold 315 for each DSCP individually. In section 2 of this document, we 316 introduced a more general definition of a traffic aggregate in the 317 diffserv sense so that we might easily refer to the packets which 318 are mapped to the same PHB everywhere within a DS domain. 319 Section 2 also presented a short definition of PDBs which we 320 expand upon in this section: 322 Per-Domain Behavior: the expected treatment that an identifiable or 323 target group of packets will receive from "edge to edge" of a DS 324 domain. A particular PHB (or, if applicable, list of PHBs) and traffic 325 conditioning requirements are associated with each PDB. 327 Measurable, quantifiable, attributes are associated with each PDB 328 and these can be used to describe what will happen to packets of 329 that PDB as they cross the DS domain. These derive from the 331 Nichols and Carpenter Expires: December, 2000 [page 6 ] 332 rules that are enforced during the entry of packets into the DS 333 domain and the forwarding treatment (PHB) the packets get 334 inside the domain. PDB attributes may be absolute or statistical 335 and they may be parameterized by network properties. For exam- 336 ple, a loss attribute might be expressed as "no more than 0.1% of 337 packets will be dropped when measured over any time period 338 larger than T", a delay attribute might be expressed as "50% of 339 deliverd packets will see less than a delay of d milliseconds, 30% 340 will see a delay less than 2d ms, 20% will see a delay of less than 341 3d ms." A wide range of metrics is possible. 343 Identification of the target group of packets is carried out using 344 classification. The Per-Domain Behavior applied to that group of 345 packet is characterized in two parts: 1) the relationship between 346 this target group of packets to the marked traffic aggregate which 347 results from the application of rules (through the use of traffic 348 conditioning) to the identified (classified) packets to create a traf- 349 fic aggregate marked for the associated PHB (see figure 2) and 2) 350 the attributes which result from the treatment experienced by 351 packets from the same traffic aggregate transiting the interior of a 352 DS domain, between and inside of DS boundaries. 354 Figure 2: Relationship of the traffic aggregate associated with a 355 PDB to arriving packets 357 The first part is more straightforward than the second, but might 358 depend on the arriving traffic pattern as well as the configuration 359 of the traffic conditioners. For example, if the EF PHB 360 [RFC2598] and a strict policer of rate R are associated with the 361 foo PDB, then the first part of characterizing the foo PDB is to 362 write the relationship between the arriving target packets and the 363 departing foo traffic aggregate. This would be formulated as the 364 rate of the emerging foo traffic aggregate being less than or equal 365 to the smaller of R and the arrival rate of the target group of pack- 366 ets and additional temporal characteristics of the packets (e.g., 367 burst) would be specified as desired. Thus, there is a "loss rate" 368 that results to the original target group from sending too much 369 traffic or the traffic with the wrong temporal characteristics that 370 should be entirely preventable (or controllable) by the upstream 371 sender conforming to the traffic conditioning associated with the 372 PDB specification. A PDB might also apply traffic conditioning 373 at egress at a DS boundary. This would be treated similarly to 374 the ingress characteristics (the authors may develop more text on 375 this in the future, but it does not materially affect the ideas pre- 376 sented in this document.) In section 4.3, we will revisit this dis- 377 cussion for PHB groups. 379 This aspect of "who is in control" of the loss (or demotion) rate 380 helps to clearly delineate the first part of characterizing packet 381 performance of a PDB from the second part. Further, the relation- 382 ship of the traffic aggregate to the arriving target packet group can 383 usually be expressed more simply that the traffic aggregate's tran- 384 sit attributes and depends on different elements. The second part 386 Nichols and Carpenter Expires: December, 2000 [page 7 ] 387 is illustrated in figure 3 as the quantifiable metrics that can be 388 used to characterize the transit of any packet of a particular traffic 389 aggregate between any two edges of the DS domain boundary 390 shown in figure 3, including those indicated with arrows. Note 391 that the DS domain boundary runs through the DS boundary rout- 392 ers since the traffic aggregate is generally formed in the boundary 393 router before the packets are queued and scheduled for output. (In 394 most cases, this distinction is expected to be important.) 396 Figure 3: Range of applicability of attributes of a traffic aggregate 397 associated with a PDB 399 The traffic aggregate associated with a PDB is formed by the 400 application of rules, through classification and traffic condition- 401 ing, to packets arriving at the DS boundary. Packets that conform 402 to the rules are marked with a DSCP that maps to a particular 403 PHB within a domain. DSCPs should not mutate in the interior of 404 a DS domain as there are no rules being applied. If it is necessary 405 to reapply the kind of rules that could result in remarking, there 406 should probably be a DS domain boundary at that point; an inte- 407 rior one that can have "lighter weight" rules. Thus, if measuring 408 attributes between locations as indicated in figure 3, the DSCP at 409 the egress side can be assumed to have held throughout the 410 domain. 412 Though a DS domain may be as small as a single node, more 413 complex topologies are expected to be the norm, thus the PDB 414 definition must hold as its traffic aggregate is split and merged on 415 the interior links of a DS domain. Packet flow in a network is not 416 part of the PDB definition; the application of rules as packets 417 enter the DS domain and the consistent PHB through the DS 418 domain must suffice. A PDB's definition does not have to hold 419 for arbitrary topologies of networks, but the limits on the range of 420 applicability for a specific PDB must be clearly specified. 422 In general, though, a PDB operates between N ingress points and 423 M egress points at the DS domain boundary. Even in the degener- 424 ate case where N=M=1, PDB attributes are more complex than 425 the definition of PHB attributes since the concatenation of the 426 behavior of intermediate nodes affects the former. A complex 427 case with N and M both greater than one involves splits and 428 merges in the traffic path and is non-trivial to analyze. Analytic, 429 simulation, and experimental work will all be necessary to under- 430 stand even the simplest PDBs. 432 4.2 Constructing PDBs 434 A DS domain is configured to meet the network operator's traffic 435 engineering goals for the domain independently of the perfor- 436 mance goals for a particular flow of a traffic aggregate. Once the 437 interior routers are configured for the number of distinct traffic 438 aggregates that the network will handle, each PDB's allocation at 439 the edge comes from meeting the desired performance goals for 441 Nichols and Carpenter Expires: December, 2000 [page 8 ] 442 the PDB's traffic aggretae subject to that configuration of link 443 schedulers and bandwidth. The rules at the edge may be altered 444 by provisioning or admission control but the decision about 445 which PDB to use and how to apply the rules comes from match- 446 ing performance to goals. 448 For example, consider the diffserv domain of figure 3. A PDB 449 with an attribute of an explicit bound on loss must have rules at 450 the edge to ensure that on the average no more packets are admit- 451 ted than can emerge. Though, queueing internal to the network 452 may result in a difference between input and output traffic over 453 some timescales, the averaging timescale should not exceed what 454 might be expected for reasonably sized buffering inside the net- 455 work. Thus if bursts are allowed to arrive into the interior of the 456 network, there must be enough capacity to ensure that losses 457 don't exceed the bound. Note that explicit bounds on the loss 458 level can be particularly difficult as the exact way in which pack- 459 ets merge inside the network affects the burstiness of the PDB's 460 traffic aggregate and hence, loss. 462 PHBs give explicit expressions of the treatment a traffic aggre- 463 gate can expect at each hop. For a PDB, this behavior must apply 464 to merging and diverging traffic aggregates, thus characterizing a 465 PDB requires exploring what happens to a PHB under aggrega- 466 tion. Rules must be recursively applied to result in a known 467 behavior. As an example, since maximum burst sizes grow with 468 the number of microflows or aggregate flows merged, a PDB 469 specification must address this. A clear advantage of constructing 470 behaviors that aggregate is the ease of concatenating PDBs so that 471 the associated traffi aggregate has known attributes that span inte- 472 rior DS domains and, eventually, farther. For example, in figure 1 473 assume that we have configured the foo PDB on the interior DS 474 domains of AS2. Then traffic aggregates associated with the foo 475 PDB in each interior DS domain of AS2 can be merged at the 476 shaded interior boundary routers. Using the same (or fewer) rules 477 as were applied to create the traffic aggregates at the entrance to 478 AS2, there should be confidence that the attributes of the foo 479 PDB can continue to be used to quantify by the expected behav- 480 ior. Explicit expressions of what happens to the behavior under 481 aggregation, possibly parameterized by node in-degrees or net- 482 work diameters are necessary to determine what to do at the inter- 483 nal aggregation points. One approach might be to completely 484 reapply the edge rules at these points. Another might employ 485 some limited rate-based remarking only. 487 Multiple PDBs might use the same PHB. In the specification of a 488 PDB, there might be a list of PHBs and their required configura- 489 tion, all of which would result in the same characteristics. In 490 operation, though, it is expected that a single domain will use a 491 single PHB to implement a particular PDB. A single PHB might 492 beselected within a domain by a list of DSCPs. Multiple PDBs 493 might use the same PHB in which case the transit performance of 494 traffic aggregates of these PDBs will, of necessity, be the same. 496 Nichols and Carpenter Expires: December, 2000 [page 9 ] 497 Yet, the particular characteristics that the PDB designer wishes to 498 claim as attributes may vary, so two PDBs that use the same PHB 499 might not be specified with the same list of attributes. 501 The specification of the transit expectations of behavior aggre- 502 gates across domains both assists in the deployment of QoS 503 within a DS domain and helps enable the composition of end-to- 504 end, cross-domain services to proceed. 506 4.3 PDBs using PHB Groups 508 When a set of related PDBs are defined using a PHB group, they 509 should be defined in the same document. This would be particu- 510 larly appropriate if the application of the edge rules that create the 511 traffic aggregates associated with each PDB had some relation- 512 ships and interdependencies, as one would expect for the AF PHB 513 group [RFC2597]. Characterizing the traffic conditioning effects 514 should then be described for these PDBs together. The transit 515 attributes will depend on the PHB associated with the PDB and 516 will not be the same for all PHBs in the group, thus each should 517 have a clearly separate treatment, though there may be some 518 parameterized interrelationship between the attributes of each of 519 these PDBs. 521 For example, if the traffic conditioner described in RFC 2698 is 522 used to mark arriving packets for three different AF1x PHBs, then 523 the most reasonable approach is to define and quantify the rela- 524 tionship between the arriving packets and the emerging traffic 525 aggregates as they relate to one another. The transit characteris- 526 tics of packets of each separate AF1x traffic aggregate should be 527 described separately. 529 A set of PDBs might be defined using Class Selector Compliant 530 PHBs [RFC2474] in such a way that the edge rules that create the 531 traffic aggregates are not related, but the transit performance of 532 each traffic aggregate has some parametric relationship to the the 533 other. If it makes sense to specify them in the same document, 534 then the author(s) should do so. 536 4.4 Forwarding path vs. control plane 538 A PDB's associated PHB and edge traffic conditioners are in the 539 packet forwarding path and operate at line rates while the config- 540 uration of the DS domain edge to enforce rules on who gets to use 541 the PDB and how the PDB should behave temporally is done by 542 the control plane on a very different time scale. For example, con- 543 figuration of PHBs might only occur monthly or quarterly. The 544 edge rules might be reconfigured at a few regular intervals during 545 the day or might happen in response to signalling decisions thou- 546 sands of times a day. Even at the shortest time scale, control plane 547 actions are not expected to happen per-packet. Much of the con- 548 trol plane work is still evolving and is outside the charter of the 549 Diffserv WG. We note that this is quite appropriate since the 551 Nichols and Carpenter Expires: December, 2000 [page 10 ] 552 manner in which the configuration is done and the time scale at 553 which it is done should not affect the PDB attributes. 555 5.0 Format for Specification of Diffserv Per-Domain Behaviors 557 PDBs arise from a particular relationship between edge and inte- 558 rior (which may be parameterized). The quantifiable characteris- 559 tics of a PDB must be independent of whether the network edge is 560 configured statically or dynamically. The particular configuration 561 of traffic conditioners at the DS domain edge is critical to how a 562 PDB performs, but the act(s) of configuring the edge is a control 563 plane action which can be separated from the specification of the 564 PDB. 566 The following sections must be present in any specification of a 567 Differentiated Services PDB. Of necessity, their length and con- 568 tent will vary greatly. 570 5.1 Applicability Statement 572 All PDB specs must have an applicability statement that outlines 573 the intended use of this PDB and the limits to its use. 575 5.2 Rules 577 This section describes the rules to be followed in the creation of 578 this PDB. Rules should be distinguished with "may", "must" and 579 "should." The rules specify the edge behavior and configuration 580 and the PHB (or PHBs) to be used and any additional require- 581 ments on their configuration beyond that contained in RFCs. 583 5.3 Attributes 585 A PDB's attributes tell how it behaves under ideal conditions if 586 configured in a specified manner (where the specification may be 587 parameterized). These might include drop rate, throughput, delay 588 bounds measured over some time period. They may be absolute 589 bounds or statistical bounds (e.g., "90% of all packets measured 590 over intervals of at least 5 minutes will cross the DS domain in 591 less than 5 milliseconds"). A wide variety of characteristics may 592 be used but they must be explicit, quantifiable, and defensible. 593 Where particular statistics are used, the document must be precise 594 about how they are to be measured and about how the characteris- 595 tics were derived. 597 Advice to a network operator would be to use these as guidelines 598 in creating a service specification rather than use them directly. 599 For example, a "loss-free" PDB would probably not be sold as 600 such, but rather as a service with a very small packet loss proba- 601 bility. 603 5.4 Parameters 605 Nichols and Carpenter Expires: December, 2000 [page 11 ] 606 The definition and characteristics of a PDB may be parameterized 607 by network-specific features; for example, maximum number of 608 hops, minimum bandwidth, total number of entry/exit points of 609 the PDB to/from the diffserv network, maximum transit delay of 610 network elements, minimum buffer size available for the PDB at 611 a network node, etc. 613 5.5 Assumptions 615 In most cases, PDBs will be specified assuming lossless links, no 616 link failures, and relatively stable routing. This is reasonable 617 since otherwise it would be very difficult to quantify behavior. 618 However, these assumptions must be clearly stated. Some PDBs 619 may be developed without these assumptions, e.g., for high loss 620 rate links, and these must also be made explicit. If additional 621 restrictions, e.g., route pinning, are required, these must be stated. 623 Further, if any assumptions are made about the allocation of 624 resources within a diffserv network in the creation of the PDB, 625 these must be made explicit. 627 5.6 Example Uses 629 A PDB specification must give example uses to motivate the 630 understanding of ways in which a diffserv network could make 631 use of the PDB although these are not expected to be detailed. For 632 example, "A bulk handling behavior aggregate may be used for 633 all packets which should not take any resources from the network 634 unless they would otherwise go unused. This might be useful for 635 Netnews traffic or for traffic rejected from some other PDB due to 636 violation of that PDB's rules." 638 5.7 Environmental Concerns (media, topology, etc.) 640 Note that it is not necessary for a provider to expose which PDB 641 (if a commonly defined one) is being used nor is it necessary for a 642 provider to specify a service by the PDB's attributes. For exam- 643 ple, a service provider might use a PDB with a "no queueing loss" 644 characteristic in order to specify a "very low loss" service. 646 This section is to inject realism into the characteristics described 647 above. Detail the assumptions made there and what constraints 648 that puts on topology or type of physical media or allocation. 650 6.0 PDB Attributes 652 Attributes are associated with each PDB: measurable, quantifi- 653 able, characteristics which can be used to describe what will hap- 654 pen to packets using that PDB as they cross the domain. These 655 expectations result directly from the application of edge rules 656 enforced during the creation of the PDB's traffic aggregate and/or 657 its entry into the domain and the forwarding treatment (PHB) 658 packets of that traffic aggregate get inside the domain. There are 660 Nichols and Carpenter Expires: December, 2000 [page 12 ] 661 many ways in which traffic might be distributed, but creating a 662 quantifiable, realizable service across the DS domain will limit 663 the scenarios which can occur. There is a clear correlation 664 between the strictness of the rules and the quality of the charac- 665 terization of the PDB. 667 There are two ways to characterize PDBs with respect to time. 668 First are its properties over "long" time periods, or average 669 behaviors. In a PDB spec, these would be the rates or throughput 670 seen over some specified time period. In addition, there are prop- 671 erties of "short" time behavior, usually expressed as the allowable 672 burstiness in an aggregate. The short time behavior is important is 673 understanding the buffering (and associated loss characteristics) 674 and in quantifying how packets using the PDB aggregate, either 675 within a DS domain or at the boundaries. For short-time behavior, 676 we are interested primarily in two things: 1) how many back-to- 677 back packets of the PDB's traffic aggregate will we see at any 678 point (this would be metered as a burst) and 2) how large a burst 679 of packets of this PDB's traffic aggregate can appear in a queue at 680 once (gives queue overflow and loss). If other PDBs are using the 681 same PHB within the domain, that must be taken into account. 683 Put simply, a PDB specification should provide the answer to the 684 question: Under what conditions can we join the output of this 685 domain to another under the same rules and expectations? 687 6.1 Considerations in specifying long-term or average PDB attributes 689 To make this more concrete, consider the DS domain of figure 4 690 for which we will define the foo PDB. To characterize the average 691 or long-term behavior that must be specified we must explore a 692 number of questions, for instance: Can the DS domain handle the 693 average foo traffic flow? Is that answer topology-dependent or are 694 there some specific assumptions on routing which must hold for 695 the foo PDB to preserve its "adequately provisioned" capability? 696 In other words, if the topology of D changes suddenly, will the 697 foo PDB's attributes change? Will its loss rate dramatically 698 increase? 700 Figure 4: ISP and DS domain D connected in a ring and connected 701 to DS domain E 703 Let figure 4 be an ISP ringing the U.S. with links of bandwidth B 704 and with N tails to various metropolitan areas. If the link between 705 the node connected to A and the node connected to Z goes down, 706 all the foo traffic aggregate between the two nodes must transit 707 the entire ring: Would the bounded behavior of the foo PDB 708 change? If this outage results in some node of the ring now hav- 709 ing a larger arrival rate to one of its links than the capacity of the 710 link for foo's traffic aggregate, clearly the loss rate would change 711 dramatically. In that case, there were topological assumptions 712 made about the path of the traffic from A to Z that affected the 713 characteristics of the foo PDB. Once these no longer hold, any 715 Nichols and Carpenter Expires: December, 2000 [page 13 ] 716 assumptions on the loss rate of packets of the foo traffic aggregate 717 transiting the domain would change; for example, a characteristic 718 such as "loss rate no greater than 1% over any interval larger than 719 10 minutes" would no longer hold. A PDB specification should 720 spell out the assumptions made on preserving the attributes. 722 6.2 Considerations in specifying short-term or bursty PDB attributes 724 Next, consider the short-time behavior of the traffic aggregate 725 associated with a PDB, specifically whether permitting the maxi- 726 mum bursts to add in the same manner as the average rates will 727 lead to properties that aggregate or under what rules this will lead 728 to properties that aggregate. In our example, if domain D allows 729 each of the uplinks to burst p packets into the foo traffic aggre- 730 gate, the bursts could accumulate as they transit the ring. Packets 731 headed for link L can come from both directions of the ring and 732 back-to-back packets from foo's traffic aggregate can arrive at the 733 same time. If the bandwidth of link L is the same as the links of 734 the ring, this probably does not present a buffering problem. If 735 there are two input links that can send packets to queue for L, at 736 worst, two packets can arrive simultaneously for L. If the band- 737 width of link L equals or exceeds twice B, the packets won't 738 accumulate. Further, if p is limited to one, and the bandwidth of L 739 exceeds the rate of arrival (over the longer term) of foo packets 740 (required for bounding the loss) then the queue of foo packets for 741 link L will empty before new packets arrive. If the bandwidth of L 742 is equal to B, one foo packet must queue while the other is trans- 743 mitted. This would result in N x p back-to-back packets of this 744 traffic aggregate arriving over L during the same time scale as the 745 bursts of p were permitted on the uplinks. Thus, configuring the 746 PDB so that link L can handle the sum of the rates that ingress to 747 the foo PDB doesn't guarantee that L can handle the sum of the N 748 bursts into the foo PDB. 750 If the bandwidth of L is less than B, then the link must buffer 751 Nxpx(B-L)/B foo packets to avoid loss. If the PDB is getting less 752 than the full bandwidth L, this number is larger. For probabilistic 753 bounds, a smaller buffer might do if the probability of exceeding 754 it can be bounded. 756 More generally, for router indegree of d, bursts of foo packets 757 might arrive on each input. Then, in the absence of any additional 758 rules, it is possible that dxpx(# of uplinks) back-to-back foo 759 packets can be sent across link L to domain E. Thus the DS 760 domain E must permit these much larger bursts into the foo PDB 761 than domain D permits on the N uplinks or else the foo traffic 762 aggregate must be made to conform to the rules for entering E 763 (e.g., by shaping). 765 What conditions should be imposed on a PDB and on the associ- 766 ated PHB in order to ensure PDBs can be concatenated, as across 767 the interior DS domains of figure 1? Edge rules for constructing a 768 PDB that has certain attributes across a DS domain should apply 770 Nichols and Carpenter Expires: December, 2000 [page 14 ] 771 independently of the origin of the packets. With reference to the 772 example we've been exploring, the rules for the PDB's traffic 773 aggregate entering link L into domain E should not depend on the 774 number of uplinks into domain D. 776 6.3 Example 778 In this example, we will make the above more concrete. We 779 assume that only the foo PDB is using its associated traffic aggre- 780 gate and we use "foo agggregate" interchangeably with "the traf- 781 fic aggregate associated with the PDB foo." We also use "foo 782 packets" interchangeably with "the packets marked for the PHB 783 associated with PDB foo." 785 Assume the topology of figure 4 and that all the uplinks have the 786 same bandwidth B and link L has bandwidth L which is less than 787 or equal to B. The foo traffic aggregates from the N uplinks each 788 have average rate R and are destined to cross L. If only a fraction 789 a of link L is allocated to foo, then R =axL/N fits the average rate 790 constraint. If each of the N flows can have a burst of p packets 791 and half the flows transit the ring in each direction, then 2xp 792 packets can arrive at the foo queue for link L in the time it took to 793 transmit p packets on the ring, p/B. Although the link scheduler 794 for link L might allow the burst of packets to be transmitted at the 795 line rate L, after the burst allotment has been exceeded, the queue 796 should be expected to clear at only rate axL. Then consider the 797 packets that can accumulate. It takes 2xp/(axL) to clear the queue 798 of the foo packets. In that time, bursts of p packets from the other 799 uplinks can arrive from the ring, so the packets do not even have 800 to be back-to-back. Even if the packets do not arrive back-to- 801 back, but are spaced by less time than it takes to clear the queue 802 of foo packets, either the required buffer size can become large or 803 the burst size of foo packets entering E across L becomes large 804 and is a function of N, the number of uplinks of domain D. 806 Let L = 1.5 Mbps, B = 45 Mbps, a = 1/3, N=10, p = 3. Suppose 807 that the bursts from two streams of foo packets arrive at the queue 808 for link L very close together. Even if 3 of the packets are cleared 809 at the line rate of 1.5 Mbps, there will be 3 packets remaining to 810 be serviced at a 500 kbps rate. In the time allocated to send one of 811 these, 9 packets can arrive on each of the inputs from the ring. If 812 any non-zero number of these 18 packets are foo packets, the 813 queue size will not reduce. If two more bursts (6 of the 18 pack- 814 ets) arrive, the queue increases to 8 packets. Thus, it's possible to 815 build up quite a large queue, one likely to exceed the buffer allo- 816 cated for foo. The rate bound means that each of the uplinks will 817 be idle for the time to send three packets at 50 kbps, possibly by 818 policing at the ring egress, and thus the queue would eventually 819 decrease and clear, however, the queue at link L can still be very 820 large. PDBs where the intention is to permit loss should be con- 821 structed so as to provide a probabilistic bound for the queue size 822 to exceed a reasonable buffer size of one or two bandwidth-delay 823 products. Alternatively or additionally, rules can be used that 825 Nichols and Carpenter Expires: December, 2000 [page 15 ] 826 bound the amount of foo packets that queue by limiting the burst 827 size at the ingress uplinks to one packet, resulting in a maximum 828 queue of N or 10 or to impose additional rules on the PDB. One 829 approach is to limit the domain over which the PDB applies so 830 that interior boundaries are placed at merge points (or between 831 every M merge points) so that a shaping edge conditioner can be 832 reapplied. Another approach is to use a PHB defined such that it 833 strictly limits the burstiness. 835 6.4 Remarks 837 This section has been provided to provide some motivational food 838 for thought for PDB specifiers. It is by no means an exhaustive 839 catalog of possible PDB attributes or what kind of analysis must 840 be done. We expect this to be an interesting and evolutionary part 841 of the work of understanding and deploying differentiated ser- 842 vices in the Internet. There is a potential for much interesting 843 research work. However, in submitting a PDB specification to the 844 Diffserv WG, a PDB must also meet the test of being useful and 845 relevant. 847 7.0 Reference Per-Domain Behaviors 849 The intent of this section is to define one or a few "reference" 850 PDBss; certainly a Best Effort PDB and perhaps others. This sec- 851 tion is very preliminary at this time and meant to be the starting 852 point for discussion rather than its end. These are PDBs that have 853 little in the way of rules or expectations. 855 7.1 Best Effort Behavior PDB 857 7.1.1 Applicability 859 A Best Effort (BE) PDB is for sending "normal internet traffic" 860 across a diffserv network. That is, the definition and use of this 861 PDB is to preserve, to a reasonable extent, the pre-diffserv deliv- 862 ery expectation for packets in a diffserv network that do not 863 require any special differentiation. 865 7.1.2 Rules 867 There are no rules governing rate and bursts of packets beyond 868 the limits imposed by the ingress link. The network edge ensures 869 that packets using the PDB are marked for the Default PHB (as 870 defined in [RFC2474]). Interior network nodes use the Default 871 PHB on these packets. 873 7.1.3 Attributes of this PDB 875 "As much as possible as soon as possible". 877 Packets of this PDB will not be completely starved and when 878 resources are available (i.e., not required by packets from any 880 Nichols and Carpenter Expires: December, 2000 [page 16 ] 881 other traffic aggregate), network elements should be configured 882 to permit packets of this PDB to consume them. 884 Although some network operators may bound the delay and loss 885 rate for this aggregate given knowledge about their network, these 886 attributes are not part of the definition. 888 7.1.4 Parameters 890 None. 892 7.1.5 Assumptions 894 .A properly functioning network, i.e. packets may be delivered 895 from any ingress to any egress. 897 7.1.6 Example uses 899 1. For the normal Internet traffic connection of an organization. 901 2. For the "non-critical" Internet traffic of an organization. 903 3. For standard domestic consumer connections 905 7.2 Bulk Handling Behavior PDB 907 7.2.1 Applicability 909 A Bulk Handling (BH) PDB is for sending extremely non-critical 910 traffic across a diffserv network. There should be an expectation 911 that these packets may be delayed or dropped when other traffic is 912 present. 914 7.2.2 Rules 916 There are no rules governing rate and bursts of packets beyond 917 the limits imposed by the ingress link. The network edge ensures 918 that packets using this PDB are marked for either a CS or an AF 919 PHB. Interior network nodes must have this PHB configured so 920 that its packets may be starved when other traffic is present. For 921 example, using the PHB for Class Selector 1 (DSCP=001000), all 922 routers in the domain could be configured to queue such traffic 923 behind all other traffic, subject to tail drop. 925 7.2.3 Attributes of the BH PHB 927 Packets are forwarded when there are idle resources. 929 7.2.4 Parameters 931 None. 933 7.2.5 Assumptions 935 Nichols and Carpenter Expires: December, 2000 [page 17 ] 936 A properly functioning network. 938 7.2.6 Example uses 940 1. For Netnews and other "bulk mail" of the Internet. 942 2. For "downgraded" traffic from some other PDB. 944 8.0 Procedure for submitting PDB 945 specifications to Diffserv WG 947 1. Following the guidelines of this document, write a draft and 948 submit it as an Internet Draft and bring it to the attention of the 949 WG mailing list. 951 2. Initial discussion on the WG should focus primarily on the 952 merits of the a PDB, though comments and questions on the 953 claimed attributes are reasonable. This is in line with our desire to 954 put relevance before academic interest in spending WG time on 955 PDBs. Academically interesting PDBs are encouraged, but not 956 for submission to the diffserv WG. 958 3. Once consensus has been reached on a version of a draft that it 959 is a useful PDB and that the characteristics "appear" to be correct 960 (i.e., not egregiously wrong) that version of the draft goes to a 961 review panel the WG Co-chairs set up to audit and report on the 962 characteristics. The review panel will be given a deadline for the 963 review. The exact timing of the deadline will be set on a case-by- 964 case basis by the co-chairs to reflect the complexity of the task 965 and other constraints (IETF meetings, major holidays) but is 966 expected to be in the 4-8 week range. During that time, the panel 967 may correspond with the authors directly (cc'ing the WG co- 968 chairs) to get clarifications. This process should result in a revised 969 draft and/or a report to the WG from the panel that either 970 endorses or disputes the claimed characteristics. 972 4. If/when endorsed by the panel, that draft goes to WG last call. 973 If not endorsed, the author(s) can give a itemized response to the 974 panel's report and ask for a WG Last Call. 976 5. If/when passes Last Call, goes to ADs for publication as a WG 977 Informational RFC in our "PDB series". 979 9.0 Acknowledgements 981 The ideas in this document have been heavily influenced by the 982 Diffserv WG and, in particular, by discussions with Van Jacob- 983 son, Dave Clark, Lixia Zhang, Geoff Huston, Scott Bradner, 984 Randy Bush, Frank Kastenholz, Aaron Falk, and a host of other 985 people who should be acknowledged for their useful input but not 986 be held accountable for our mangling of it. Grenville Armitage 987 coined "per domain behavior (PDB)" though some have sug- 989 Nichols and Carpenter Expires: December, 2000 [page 18 ] 990 gested similar terms prior to that. 992 References 994 [RFC2474] RFC 2474, "Definition of the Differentiated Services 995 Field (DS Field) in the IPv4 and IPv6 Headers", 996 K.Nichols, S. Blake, F. Baker, D. Black, www.ietf.org/ 997 rfc/rfc2474.txt 999 [RFC2475] RFC 2475, "An Architecture for Differentiated Ser- 1000 vices", S. Blake, D. Black, M.Carl- 1001 son,E.Davies,Z.Wang,W.Weiss, www.ietf.org/rfc/ 1002 rfc2475.txt 1004 [RFC2597] RFC 2597, "Assured Forwarding PHB Group", F. 1005 Baker, J. Heinanen, W. Weiss, J. Wroclawski, 1006 www.ietf.org/rfc/rfc2597.txt 1008 [RFC2598] RFC 2598, "An Expedited Forwarding PHB", 1009 V.Jacobson, K.Nichols, K.Poduri, www.ietf.org/rfc/ 1010 rfc2598.txt 1012 [RFC2698] RFC 2698, "A Two Rate Three Color Marker", J. 1013 Heinanen, R. Guerin. www.ietf.org/rfc/rfc2698.txt 1015 [MODEL] "A Conceptual Model for Diffserv Routers", draft-ietf- 1016 diffserv-model-02.txt, Bernet et. al. 1018 [MIB] "Management Information Base for the Differentiated 1019 Services Architecture", draft-ietf-diffserv-mib-01.txt, 1020 Baker et. al. 1022 [VW] "The 'Virtual Wire' Behavior Aggregate", draft-ietf-diff- 1023 serv-ba-vw-00.txt, V. Jacobson, K. Nichols, and K. 1024 Poduri (being modified to reflect new terminology). 1026 Authors' Addresses 1028 Kathleen Nichols Brian E. Carpenter 1029 Packet Design, Inc. IBM 1030 66 Willow Place c/o iCAIR 1031 Menlo Park, CA 94025 Suite 150 1032 1890 Maple Avenue 1033 Evanston, IL 60201 1034 USA 1035 email: 1036 nichols@packetdesign.com brian@icair.org