idnits 2.17.1 draft-ietf-diffserv-framework-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 48 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** There are 75 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([DSHEAD], [DSARCH]), 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 148 has weird spacing: '... source mpt-t...' == Line 416 has weird spacing: '...ervices which...' == Line 766 has weird spacing: '...mers of the w...' == Line 772 has weird spacing: '...es into the...' -- 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) -- Missing reference section? 'DiffEdge' on line 1929 looks like a reference -- Missing reference section? 'E2EQoS' on line 136 looks like a reference -- Missing reference section? 'ROTZY' on line 1932 looks like a reference -- Missing reference section? 'DSARCH' on line 1904 looks like a reference -- Missing reference section? 'DSHEAD' on line 1908 looks like a reference -- Missing reference section? 'AF' on line 1912 looks like a reference -- Missing reference section? 'RFC791' on line 1951 looks like a reference -- Missing reference section? 'RFC1349' on line 1954 looks like a reference -- Missing reference section? 'EF' on line 1915 looks like a reference -- Missing reference section? '2BIT' on line 1891 looks like a reference -- Missing reference section? 'MPLS' on line 1936 looks like a reference -- Missing reference section? 'Ellesson' on line 1921 looks like a reference -- Missing reference section? 'E2EQOS' on line 1925 looks like a reference -- Missing reference section? 'GBH97' on line 1940 looks like a reference -- Missing reference section? 'CLASSY' on line 1898 looks like a reference -- Missing reference section? 'CLARK' on line 1895 looks like a reference -- Missing reference section? 'COPS' on line 1901 looks like a reference -- Missing reference section? 'IntServ' on line 1943 looks like a reference -- Missing reference section? 'RSVP' on line 1947 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Differentiated Services Y.Bernet, et al 2 Internet Draft February, 1999 3 Document: draft-ietf-diffserv-framework-02.txt 5 Yoram Bernet, Microsoft 6 James Binder, 3-Com 7 Steven Blake, Torrent Networking Technologies 8 Mark Carlson, Redcape Software 9 Brian E. Carpenter, IBM 10 Srinivasan Keshav, Cornell University 11 Elwyn Davies, Nortel Networks 12 Borje Ohlman, Ericsson 13 Dinesh Verma, IBM 14 Zheng Wang, Bell Labs Lucent Technologies 15 Walter Weiss, Lucent Technologies 17 A Framework for Differentiated Services 18 20 Status of this Memo 22 This document is an Internet Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. Internet Drafts are 24 working documents of the Internet Engineering Task Force (IETF), 25 its Areas, and its Working Groups. Note that other groups may 26 also distribute working documents as Internet Drafts. 28 Internet Drafts are draft documents valid for a maximum of six 29 months. Internet Drafts may be updated, replaced, or obsoleted by 30 other documents at any time. It is not appropriate to use 31 Internet Drafts as reference material or to cite them other than 32 as a "working draft" or "work in progress". 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 A revised version of this draft document will be submitted to the 41 RFC editor as an Informational Standard for the Internet 42 Community. Discussion and suggestions for improvement are 43 requested. This document will expire before September, 1999. 44 Distribution of this draft is unlimited. 46 Copyright Notice 48 Copyright (C) The Internet Society (1999). All Rights Reserved. 50 Bernet, et al 1 51 Draft-ietf-diffserv-framework-02.txt February, 1999 53 CONTENTS 55 1. Abstract......................................................4 56 2. Structure of this Draft.......................................4 57 3. Differentiated Services - Motivation and Definition...........4 58 4. Services......................................................5 59 4.1 Customer/Provider Boundaries..............................5 60 4.2 SLSs and TCSs.............................................6 61 4.3 Service Taxonomy: Quantitative through Qualitative and 62 alternatives..........................................7 63 4.4 The Scope of a Service....................................8 64 4.4.1 Services where the Scope is Tied to the Receiver....8 65 4.5 Dynamic vs. Static SLSs...................................9 66 4.6 Provisioning Traffic Conditioners in Boundary Devices to 67 Provide Services.....................................10 68 4.6.1 Minimal Functionality at Provider's Ingress........11 69 4.6.2 Functionality at Provider's Ingress for Double-ended 70 SLSs.............................................12 71 4.6.3 Added Value Functionality at Provider's Ingress....12 72 4.6.4 Functionality at Customer's Egress.................13 73 4.6.5 Functionality at Provider's Egress.................13 74 4.7 Internal Provisioning....................................14 75 4.8 End-to-End Service Construction..........................14 76 5. Service Examples.............................................14 77 5.1 Better than Best-Effort (BBE) Service....................14 78 5.1.1 Service Implementation.............................15 79 5.2 Leased Line Emulation Service............................16 80 5.2.1 Service Implementation.............................16 81 5.3 Quantitative Assured Media Playback Service..............17 82 5.3.1 Service Implementation.............................17 83 5.4 Superposition of Quantitative and Qualitative Services in 84 the Same Network.....................................18 85 6. Provisioning and Configuration...............................18 86 6.1 Boundary vs. Interior Provisioning and Configuration.....19 87 6.1.1 Boundary Provisioning..............................19 88 6.1.2 Interior Provisioning..............................20 89 6.1.2.1 Quantitative Provisioning of the Interior..21 90 6.1.2.2 Qualitative Provisioning of the Interior...22 91 6.2. Static vs. Dynamic Provisioning.........................23 92 6.3 Distributing Configuration Information...................24 93 6.3.1 Top Down Distribution of Configuration Information.24 94 6.3.2 Distribution of Configuration Information via 95 Signaling........................................25 96 6.3.3 Modification of Configuration Information Based on 97 Real-Time Measurement............................26 98 7. Inter-Domain Considerations and End-to-End Services..........26 99 7.1 TCSs.....................................................27 100 7.2 Inter-Domain Provisioning................................27 101 7.3 Service, PHB and Codepoint Mapping.......................28 102 7.4 Host-Domain Boundaries...................................29 103 8. Deployment Scenarios.........................................29 104 9. Inter-operability with RSVP/Integrated Services..............31 106 Bernet, et al Expires: September 1999 2 107 Draft-ietf-diffserv-framework-02.txt February, 1999 109 9.1 RSVP/Integrated Services Over Differentiated Services....31 110 9.2 Parallel Operation.......................................32 111 10. Multicast Services..........................................32 112 10.1 Codepoints and PHBs for Multicast Services.............33 113 10.2 Provisioning Multicast Services........................33 114 11. Security and Tunneling Considerations.......................34 115 12. Acknowledgements............................................35 116 13. References..................................................35 117 14. Author's Addresses..........................................36 119 Changes from previous version 121 - Terminology made consistent with architecture _ particularly 122 boundary (node) used in place of edge (node) where appropriate. 123 - Table of contents added. 124 - Traffic Conditioning Agreement (TCA) replaced by Traffic 125 Conditioning Specification (TCS) throughout to avoid 126 connotations of contractual agreement. 127 - Most instances of Service Level Agreement (SLA) replaced by 128 Service Level Specification (SLS) where it is clear that we are 129 talking about the technical specification of the services. The 130 SLS is defined as the technical specification part of the 131 contractual SLA. Emphasized that this document discusses the 132 technical aspects of the SLA whilst acknowledging that it fits 133 in a wider contractual framework which is outside the scope of 134 technical standards. 135 - Deployment scenarios section added. 136 - Whole document coordinated with [DiffEdge] and [E2EQoS]. 137 - Service scope added as a component of TCS. 138 - Connections made to work of MPLS and IP Performance Metrics 139 WGs. 140 - Pointed out that dealing with the interactions of multiple end- 141 to-end services is an open question and is unlikely to have a 142 computable answer in common cases. 143 - Multicast section improved: 144 - Added preamble pointing out that DS should be good for 145 multicast except that provisioning is difficult 146 - Application level unicast is dealt with by multiple 147 instances of point-to-point services 148 - Pointed out that provisioning multiple source mpt-to-mpt is 149 not a straight generalisation of pt-to-mpt 150 - Emphasised that TC for a quantitative service in an IPsec 151 tunnel will be difficult to realize because the relevant packet 152 fields are hidden. 153 - Updated references to reflect current drafts. Added a few new 154 references including [ROTZY] for bandwidth broker. 156 Bernet, et al Expires: September 1999 3 157 Draft-ietf-diffserv-framework-02.txt February, 1999 159 1. Abstract 161 This document provides a general description of issues related to 162 the definition, configuration and management of services enabled 163 by the differentiated services architecture [DSARCH]. This 164 document should be read along with its companion documents, the 165 differentiated services architecture [DSARCH] and the definition 166 of the DS field [DSHEAD]. A glossary of specialist terms used may 167 be found in [DSARCH]. 169 2. Structure of this Draft 171 Section 3 defines Differentiated Services and explains the 172 motivation behind its deployment. Section 4 defines the concept of 173 a service and the components that comprise a service. Section 5 174 discusses several service examples. Section 6 examines intra- 175 domain provisioning, configuration and management issues. Section 176 7 examines inter-domain provisioning, configuration and 177 management. Section 8 describes some possible deployment 178 scenarios. Section 9 addresses interoperability with Integrated 179 Services and RSVP. Section 10 discusses the interaction of 180 differentiated services with multicast and tunneling. Section 11 181 addresses security concerns. 183 3. Differentiated Services - Motivation and Definition 185 Traditionally, network service providers (both enterprise and 186 traditional ISPs) provide all customers with the same level of 187 performance (best-effort service). Most service differentiation 188 has been in the pricing structure (individual vs. business rates) 189 or the connectivity type (dial-up access vs. leased line, etc.). 190 However, in recent years, increased usage of the Internet has 191 resulted in scarcity of network capacity, compromising performance 192 of traditional, mission critical applications. At the same time, 193 new applications have emerged which demand much improved service 194 quality. As a result, service providers are finding it necessary 195 to offer their customers alternative levels of service. As well as 196 meeting new customer expectations, this allows service providers 197 to improve their revenues through premium pricing and competitive 198 differentiation of service offerings, which in turn can fund the 199 necessary expansion of the network. 201 The Differentiated Services architecture offers a framework within 202 which service providers can offer each customer a range of network 203 services which are differentiated on the basis of performance in 204 addition to pricing tiers used in the past. Customers request a 205 specific performance level on a packet by packet basis, by marking 206 the DS field of each packet with a specific value (see [DSHEAD] 207 for more details). This value specifies the Per-hop Behavior (PHB) 208 to be allotted to the packet within the provider's network. 209 Typically, the customer and provider negotiate a profile (policing 210 profile) describing the rate at which traffic can be submitted at 212 Bernet, et al Expires: September 1999 4 213 Draft-ietf-diffserv-framework-02.txt February, 1999 215 each service level. Packets submitted in excess of this profile 216 may not be allotted the service level requested. A salient feature 217 of differentiated services is its scalability, which allows it to 218 be deployed in very large networks. This scalability is achieved 219 by forcing as much complexity out of the core of the network into 220 boundary devices which process lower volumes of traffic and lesser 221 numbers of flows, and offering services for aggregated traffic 222 rather than on a per-micro-flow basis. 224 4. Services 226 [DSARCH] defines a Service as "the overall treatment of a defined 227 subset of a customer's traffic within a DS-domain, or end-to-end". 228 Although PHBs are at the heart of the differentiated services 229 architecture, it is the service obtained as a result of marking 230 traffic for a specific PHB, which is of value to the customer. 231 PHBs are merely building blocks for services. Service providers 232 combine PHB implementations with traffic conditioners, 233 provisioning strategies and billing models which enable them to 234 offer services to their customers. Providers and customers 235 negotiate agreements with respect to the services to be provided 236 at each customer/provider boundary. These are commonly referred to 237 as Service Level Agreements (SLAs). Many of the aspects of SLAs 238 (such as payment terms) are beyond the scope of technical 239 standards and are therefore not considered in this document; the 240 subset of the SLA which provides the technical specification of 241 the service will be referred to as the Service Level Specification 242 (SLS). 244 Bear in mind when considering the services that are offered in a 245 DS-domain that: 246 * DS services are all for unidirectional traffic only 247 * DS services are for traffic aggregates, not individual micro- 248 flows 250 4.1 Customer/Provider Boundaries 252 Present day network traffic generally traverses a concatenation of 253 networks which may include hosts, home or office networks, campus 254 or corporate networks and several large transit networks. Home and 255 office networks are typically customers of campus or corporate 256 networks, which are in turn customers of large transit networks. 257 While one would expect the initial deployment of differentiated 258 services to be within large transit networks, its deployment may 259 also be extended to the smaller campus and corporate networks and 260 in special cases, all the way to individual hosts. As such, there 261 may be numerous customer/provider boundaries at which the concept 262 of a 'service' applies. 264 Bernet, et al Expires: September 1999 5 265 Draft-ietf-diffserv-framework-02.txt February, 1999 267 4.2 SLSs and TCSs 269 At each differentiated service customer/provider boundary, the 270 technical aspects of the service provided is defined in the form 271 of an SLS which specifies the overall features and performance 272 which can be expected by the customer. Because DS services are 273 unidirectional the two directions of flow across the boundary will 274 need to be considered separately. An important subset of the SLS 275 is the traffic conditioning specification, or TCS. The TCS 276 specifies detailed service parameters for each service level. Such 277 parameters include: 278 1. Detailed service performance parameters such as expected 279 throughput, drop probability, latency. 280 2. Constraints on the ingress and egress points at which the 281 service is provided, indicating the `scope' of the service. 282 Service scopes are discussed further in Sec. 4.4. 283 3. Traffic profiles which must be adhered to for the requested 284 service to be provided, such as token bucket parameters. 285 4. Disposition of traffic submitted in excess of the specified 286 profile. 287 5. Marking services provided. 288 6. Shaping services provided. 290 The TCS, the logical components needed to implement it and the 291 configuration needed for those components are discussed in more 292 detail in [DiffEdge]. 294 In addition to the details in the TCS, the SLS may specify more 295 general service characteristics such as: 296 1. Availability/Reliability, which may include behavior in the 297 event of failures resulting in rerouting of traffic 298 2. Encryption services 299 3. Routing constraints 300 4. Authentication mechanisms 301 5. Mechanisms for monitoring and auditing the service 302 6. Responsibilities such as location of the equipment and 303 functionality, action if the contract is broken, support 304 capabilities 305 7. Pricing and billing mechanisms 307 These additional characteristics are important, and in the case of 308 pricing and billing, fundamental to the service offering but they 309 do not affect the service itself and are not considered further 310 here. 312 Metrics which can be used to validate the delivery of the service 313 specified by a TCS have been studied by the IP Performance Metrics 314 Working Group of the IETF and are being published as Informational 315 RFCs. 317 Bernet, et al Expires: September 1999 6 318 Draft-ietf-diffserv-framework-02.txt February, 1999 320 4.3 Service Taxonomy: Quantitative through Qualitative and 321 alternatives 323 The Differentiated Services architecture can support a broad 324 spectrum of different kinds of service. Categorizing these 325 services provides some constraints on the corresponding SLSs that 326 can be offered for the service. 328 Some services can be clearly categorized as qualitative or 329 quantitative depending on the type of performance parameters 330 offered. Examples of qualitative services are as follows: 331 1. Traffic offered at service level A will be delivered with low 332 latency. 333 2. Traffic offered at service level B will be delivered with low 334 loss. 336 The assurances offered in examples 1 and 2 are relative and can 337 only be verified by comparison. 339 Examples of quantitative services are as follows: 340 3. 90% of in profile traffic delivered at service level C will 341 experience no more than 50 msec latency. 342 4. 95% of in profile traffic delivered at service level D will be 343 delivered. 345 Examples 3 and 4 both provide concrete guarantees that could be 346 verified by suitable measurements on the example service 347 irrespective of any other services offered in parallel with it. 349 There are also services which are not readily categorized as 350 qualitative or quantitative as in the following examples: 351 5. Traffic offered at service level E will be allotted twice the 352 bandwidth of traffic delivered at service level F. 353 6. Traffic with drop precedence AF12 has a higher probability of 354 delivery than traffic with drop precedence AF13 [AF]. 356 In example 5, the provider is quantifying the relative benefit of 357 submitting traffic at service level E vs. service level F, but the 358 customer cannot expect any particular quantifiable throughput. 359 This can be described as a `Relative Quantification Service'. 361 In general, when a provider offers a quantitative service, it will 362 be necessary to specify quantitative policing profiles. In many 363 cases, quantitative policing profiles will be specified even for 364 services that do not offer quantitative performance. 366 Determining how to monitor and audit the delivery of a qualitative 367 or relative quantification service in such a way as to convince 368 the user that he has received fair measure requires careful 369 attention. It will be up to the customer to determine if the 370 advantage offered is sufficient to make the service worthwhile. 372 Bernet, et al Expires: September 1999 7 373 Draft-ietf-diffserv-framework-02.txt February, 1999 375 The SLS must clearly avoid making quantitative commitments for 376 these services. 378 4.4 The Scope of a Service 380 The scope of a service refers to the topological extent over which 381 the service is offered. For example, assume that a provider offers 382 a service to a customer which connects to their network at ingress 383 point A. The service may apply to: 384 1. all traffic from ingress point A to any egress point 385 2. all traffic between ingress point A and egress point B 386 3. all traffic from ingress point A to a set of egress points 388 Egress points may be in the same DS Domain as the ingress point or 389 may be in other domains which are either directly or indirectly 390 connected to the ingress domain. If the egress point is in another 391 domain, it will be necessary for the ingress provider to negotiate 392 SLAs with the relevant peer domains, which will recursively 393 negotiate with their peers to ensure that the service offered at 394 ingress point A can indeed be extended to the egress points 395 specified. The scope of a service is part of the TCS governing 396 ingress point A. 398 In general, providers will be able to offer quantitative services 399 most efficiently when a specific set of egress points is 400 specified. Quantitative services which span multiple domains also 401 require tighter coupling between the SLA offered to the customer 402 at ingress point A and the SLAs negotiated with intermediate 403 domains. Qualitative services can more readily be offered to 404 arbitrary sets of egress points and require looser coupling 405 between the SLA at ingress point A and SLAs at intermediate domain 406 boundaries. 408 4.4.1 Services where the Scope is Tied to the Receiver 410 A special case of service scope is a service that governs all 411 traffic between any ingress point and egress point B. The SLS that 412 defines this service would be at egress point B and would 413 effectively allow the customer to control the mix of traffic 414 received from the provider. While such a service is theoretically 415 possible, it appears to be a mismatch with the more usual 416 specification of Differentiated Services which governs the 417 quality with which traffic is sent, rather than received. 419 A number of concerns would have to be addressed by such a service, 420 including: 421 - Traffic going to point B from an ingress point A under the 422 terms of the SLS of this service may also be governed by an SLS 423 for traffic submitted at point A. The SLSs may conflict and it 424 will not, in general, be possible to resolve all such conflicts 425 across all the ingress points 427 Bernet, et al Expires: September 1999 8 428 Draft-ietf-diffserv-framework-02.txt February, 1999 430 - Establishing a traffic profile for this service at every 431 possible ingress which prevents overload of the receiver can be 432 more complex than for other service scopes: Static profiles are 433 likely to be either inefficient (e.g. dividing the egress 434 profile into fixed proportions) or risky (e.g. allowing every 435 ingress to send the whole profile) whilst dynamic profiles 436 require processes and communication mechanisms to coordinate 437 the settings. For example, the sources may offer 1Mb/s when 438 the receiver can only accept 9.6Kb/s. 439 - Without effective ingress profiles for the service, denial of 440 service attacks will be a serious problem. 442 Some of the characteristics of receiver oriented services can be 443 provided by local policies and the SLS for the domain to which 444 traffic is sent via the egress point as described in Sec. 4.6.4. 446 4.5 Dynamic vs. Static SLSs 448 SLSs may be static or dynamic. Static SLSs are the norm at the 449 present time. These are instantiated as a result of negotiation 450 between human agents representing provider and customer. A static 451 SLS is first instantiated at the agreed upon service start date 452 and may periodically be renegotiated (on the order of days or 453 weeks or months). The SLS may specify that service levels change 454 at certain times of day or certain days of the week, but the 455 agreement itself remains static. 457 Dynamic SLSs, on the other hand, may change frequently. Such 458 changes may result for example, from variations in offered traffic 459 load relative to preset thresholds or from changes in pricing 460 offered by the provider as the traffic load fluctuates. Dynamic 461 SLSs change without human intervention and thus require an 462 automated agent and protocol, for example, a bandwidth broker to 463 represent the differentiated service provider's domain (such as 464 suggested in [ROTZY]). 466 Dynamic SLSs also present challenging problems to both end users 467 and network providers: 468 - Network providers have to balance frequently changing loads on 469 different routes within the provider network. This requires the 470 provider to adopt dynamic, automated resource provisioning 471 mechanisms rather than relying on static provisioning. 472 - Customer equipment will have to adapt to dynamic SLSs in order 473 to make the most out of the changing SLS. 474 - End user applications may have to adapt their behavior during a 475 session to make the most of (or even, cope with) dynamic SLSs. 477 It is worth reiterating that the SLSs in Differentiated Services 478 apply to aggregates of traffic and not individual flows. For 479 scalability, it is undesirable to envisage modifying an SLS every 480 time a new micro-flow is added or removed from an aggregate. 482 Bernet, et al Expires: September 1999 9 483 Draft-ietf-diffserv-framework-02.txt February, 1999 485 4.6 Provisioning Traffic Conditioners in Boundary Devices to Provide 486 Services 488 Once an SLS has been negotiated, the service provider (and 489 optionally the customer) will configure traffic conditioning 490 components at the boundary between the two networks. The service 491 provider does so with the goal of protecting the provider's 492 network such that the resources granted to the customer meet but 493 do not exceed the terms of the TCS. The customer does so with the 494 goal of making the best use of the service purchased from the 495 provider. In this section, we will briefly describe configuration 496 of traffic conditioners in boundary devices. Traffic conditioners 497 and their configuration are described in greater detail in 498 [DiffEdge]. 500 Note that the provider's self interests require only that the 501 provider identify 502 - for which service level specific traffic is submitted, 503 - by which customer it is submitted, and 504 - for traffic with double-ended SLSs (i.e. SLS scope is type 2 or 505 3 of Sec. 4.4) only, the destination address to which the 506 traffic is directed. 508 Customer traffic may be authenticated either by the physical 509 connection on which it arrives or by some sophisticated 510 cryptographic means which is beyond the scope of this draft. The 511 provider need not be concerned with the customer's individual 512 micro-flows in delivering basic Differentiated Services (see Sec. 513 4.6.3 for additional services). 515 [DSARCH] identifies four traffic conditioning components: 516 1. Meters 517 2. Markers 518 3. Shapers 519 4. Droppers 521 The combination and interaction of the traffic conditioning 522 components is selected on a packet-by-packet basis by the DS 523 codepoint. The configuration parameters for the components at 524 each codepoint are determined by the policies and profiles 525 applied, so that the conditioner polices the traffic in the BA 526 specified by the codepoint. Meters measure submitted traffic for 527 conformance to a profile, providing control input for the other 528 components which implement the policing: 529 - Shapers police by delaying submitted traffic such that it does 530 not exceed the traffic rate specified in a profile. 531 - Droppers police by dropping traffic that is submitted at a rate 532 exceeding that specified in a profile. 534 Bernet, et al Expires: September 1999 10 535 Draft-ietf-diffserv-framework-02.txt February, 1999 537 - Markers police by re-marking the traffic with a different 538 codepoint either 539 - to demote out-of-profile traffic to a different PHB, 540 - as a result of an SLS which specifies codepoint mutation, or 541 - to ensure that only valid codepoints are used within the 542 domain. 544 In addition to these four components, traffic classifiers are 545 required in order to separate submitted traffic into different 546 classes. Classifiers may separate traffic based only on the DS- 547 field of submitted packets (BA classifiers) or may do so based on 548 multiple fields within the packet header and even the packet 549 payload (MF classifiers). MF classifiers may be used at 550 boundaries to provide certain per-micro-flow services to 551 customers. Examples of such services include per-flow marking or 552 shaping. Typically, traffic will arrive at the boundary of a DS 553 domain pre-marked and pre-shaped. However, at interfaces with some 554 non-DS customer networks, it is possible that traffic will require 555 marking and shaping. 557 Even if a customer has pre-marked and pre-shaped, the service 558 provider will wish to police the traffic at the ingress boundary 559 to meet the domain's self-interests. This may result in traffic 560 being re-marked or dropped. 562 Traffic conditioning components (in particular, meters) will also 563 be the primary source of accounting information for a 564 Differentiated Services network. 566 4.6.1 Minimal Functionality at Provider's Ingress 568 At the very least, the service provider must limit traffic carried 569 on behalf of the customer to the constraints specified in the TCS. 570 A simplified TCS can be represented in the form of a table wherein 571 each row has the format: 573 DS-Mark : Profile : Scope : Disposition of non-conforming traffic 575 This row indicates that the provider commits to carry traffic 576 marked with 'DS-Mark' at the corresponding service level, provided 577 that it conforms to the 'Profile'. Traffic that is submitted with 578 'DS-Mark' and which does not conform to the 'Profile', is 579 subjected to 'Disposition of non-conforming traffic'. This is 580 generally a policing action such as re-marking to a lower service 581 level, delaying in a shaper, or dropping. Alternatively, it may be 582 carried at the requested service level, but subjected to a 583 surcharge. The scope for this type of service would normally be 584 expected to be of type 1 of Sec. 4.4.1, where the traffic 585 destination can take it through any egress point of the domain. 587 To provide this minimal functionality, the provider must configure 588 a BA classifier to separate traffic into the different service 590 Bernet, et al Expires: September 1999 11 591 Draft-ietf-diffserv-framework-02.txt February, 1999 593 level requested, based on DS-Mark. Following the BA classifier, 594 each class must be metered for conformance to the corresponding 595 profile. Following the profiler, either a dropper, shaper or re- 596 marker is likely to be employed. The Better than Best Efforts 597 service described in Sec. 5.1 is an example of a service for which 598 this functionality is sufficient. 600 4.6.2 Functionality at Provider's Ingress for Double-ended SLSs 602 If quantitative or other services needing double-ended SLSs (types 603 2 and 3 of Sec. 4.4.1) are implemented in a DS Domain, these 604 services specify the possible egress port(s) for traffic 605 conforming to the SLS. The traffic conditioner needs to consider 606 the destination address of the packet as additional input to the 607 policing process, so that traffic is not accepted for egress ports 608 for which an SLS does not exist. The Virtual Leased Line service 609 described in Sec. 5.2 is an example of a service that would 610 require this functionality. 612 A QoS VPN can be constructed by provisioning multiple instances of 613 services of type 2, building in effect, a mesh of point to point 614 QoS links. 616 Services of type 3 are most likely to be used for multicast 617 applications (see Sec. 10). 619 4.6.3 Added Value Functionality at Provider's Ingress 621 The functionality described in Secs. 4.6.1 and 4.6.2 serves only 622 to protect the provider's network resources in line with the terms 623 of the TCS. It provides no assistance to the customer. The burden 624 of marking packets and shaping traffic falls entirely on the 625 customer. In some cases, the SLS may call for the provider to 626 provide additional services to the customer. Such services may 627 include: 628 1. Marking traffic from specific micro-flows to a specific 629 behaviour aggregate (marking the DS-field). 630 2. Policing traffic from specific micro-flows or sets of micro- 631 flows, either in the form of dropping or shaping. 633 In order to provide such services, the provider must generally 634 employ an MF classifier in addition to the BA classifier. The need 635 for an MF classifier arises only when the customer requires the 636 provider to provide some form of traffic separation or 637 authentication on behalf of the customer. The provider may charge 638 dearly for these services depending on the degree of granularity 639 and the amount of work required. For example, shaping thousands of 640 customer micro-flows might consume considerable resources in the 641 provider's boundary device. On the other hand marking based on 642 source subnet addresses would consume considerably fewer 643 resources. 645 Bernet, et al Expires: September 1999 12 646 Draft-ietf-diffserv-framework-02.txt February, 1999 648 4.6.4 Functionality at Customer's Egress 650 Strictly speaking, the customer need not apply any specific 651 traffic conditioning. In this case, the customer relies on the 652 provider to mark as per negotiated MF classification criteria. In 653 many cases it is preferable for the customer to mark. Customer 654 marking may be necessary when customer packets are encrypted (as 655 in the case of end-to-end IPSec). Customer marking enables the 656 customer to direct specific traffic from specific users or 657 applications to specific service classes. This may be difficult or 658 impossible for a provider to do on behalf of a customer when, for 659 example, applications use volatile ports and users are assigned 660 IP addresses based on DHCP. 662 In addition to marking, it is in the customer's best interest to 663 at least shape per service level, at the customer network's egress 664 point. Otherwise, customer traffic may be policed by the service 665 provider with undesirable consequences (e.g. dropped packets). 666 Shaping per service level does not however, provide for micro-flow 667 traffic separation. As a consequence, a renegade traffic source 668 may cause the profile to be exceeded for a specific service level, 669 negatively impacting all customer flows which are marked for that 670 service level. Therefore, it is often in the customer's interest 671 to meter and shape or at least to police, with micro-flow 672 granularity. 674 4.6.5 Functionality at Provider's Egress 676 At the egress from a provider's domain there may be an SLA in 677 place with a peer DS domain, which might be either another 678 provider or an end user domain. As in Sec. 4.6.4, it is in the 679 provider's best interests to shape the traffic leaving the domain. 681 Depending on the SLA, the egress may be required to remark and/or 682 police or shape the traffic. Note that the forwarding treatment 683 applied to the packet in the egress node of the domain would be 684 that selected by the codepoint before it was remarked (otherwise, 685 the egress node has to support multiple codepoint to PHB 686 mappings). 688 If the peer domain is a non-DS domain the egress may be required 689 to remark all packets to conform to one of the previous standards 690 for the use of the TOS byte [RFC791,RFC1349]. 692 The provider may also wish to offer additional services to a 693 customer by policing egress traffic with micro-flow granularity if 694 the customer might expect to receive excessive traffic in a single 695 BA and wishes to apply greater control than could be achieved by 696 normal policing of the aggregate. This would be specified via an 697 SLS in the usual way. 699 Bernet, et al Expires: September 1999 13 700 Draft-ietf-diffserv-framework-02.txt February, 1999 702 4.7 Internal Provisioning 704 The provider must provision internal nodes in the provider network 705 to meet the assurances offered by SLSs negotiated at the 706 boundaries of the network. To do so, the provider may use similar 707 traffic conditioning mechanisms to those used at the network 708 boundaries. However, providers are unlikely to apply MF 709 classification within the interior of the network. The provider 710 may police periodically within the network, by reshaping, 711 remarking or discarding traffic. 713 Service providers are experienced in provisioning large networks 714 which offer uniform service. They are assisted in this by 715 predictive tools, traffic modeling tools and real time 716 measurements. Current techniques will likely be applied to 717 differentiated services networks, although, the complexity of 718 provisioning will increase significantly. In a differentiated 719 service network, the provider must ensure that resources granted 720 to traffic of one service level does not inappropriately 721 compromise assurances regarding traffic at other service levels 722 (for example, in example service 6, traffic in AF12 can 723 legitimately compromise traffic in AF13 if an increase in AF12 724 traffic causes more AF13 traffic to be dropped). As mentioned 725 previously, internal provisioning in the case of dynamic SLSs will 726 likely require dynamic resource allocation protocols. 728 4.8 End-to-End Service Construction 730 The Differentiated Services architecture proposes that an end-to- 731 end service can be constructed by the concatenation of domain 732 services and their associated customer-provider SLAs for each of 733 the domains which the service traffic has to cross. 735 Clearly, not all PHBs and services can be meaningfully 736 concatenated, and the definition of suitable services and their 737 associated PHBs will be a major focus of future Differentiated 738 Services development. This is discussed at greater length in Sec. 739 7. 741 5. Service Examples 743 In this section, we describe service examples and show how they 744 can be supported by specific PHBs. We base these examples on PHBs 745 which are defined in [AF]and [EF]. These examples are intended to 746 be illustrative of the wide range of services that can be employed 747 using the differentiated services model, and are not intended to 748 be an exhaustive list. Further examples can be found in the 749 Appendix of [AF] (`Olympic' service _ related gold, silver and 750 bronze service levels, a proportional bandwidth service and an 751 alternative for a low latency service) and [2BIT]. 753 5.1 Better than Best-Effort (BBE) Service 755 Bernet, et al Expires: September 1999 14 756 Draft-ietf-diffserv-framework-02.txt February, 1999 758 This is a qualitative service which promises to carry specific web 759 server traffic at a higher priority than competing best-effort 760 traffic. Such a service offers relatively loose (not quantifiable) 761 performance from a given ingress point to any egress point. Such a 762 service is suitable for example for businesses offering access to 763 web based content. The BBE service enables the web content 764 provider to provide content at a generally higher rate than other 765 content providers are able to, in so reducing the latency 766 experienced by consumers of the web site. 768 5.1.1 Service Implementation 770 In this example, we assume that there is an SLS which defines the 771 service at the customer's ingress point. This is the point at 772 which the customer injects web server responses into the 773 differentiated services network. The information in the TCS can be 774 represented in the following form [AF]: 776 AF11 Mark : 1 Mbps : Any egress point : Excess traffic handled by 777 marking with AF13 mark : . 779 Packets submitted for the BBE service should be marked with the 780 DS- field codepoint corresponding to the AF11 PHB. The provider is 781 promising to carry up to 1 Mbps of traffic from the ingress point 782 to any egress point at a higher priority than best-effort traffic. 783 A lesser class of service corresponding to the AF13 PHB will be 784 applied to traffic submitted for the AF11 PHB, in excess of 1 785 Mbps. 787 The provider will provision a policer at the ingress point. 788 Traffic submitted up to the 1 Mbps limit will be directed to the 789 AF11 PHB. Traffic submitted in excess of 1 Mbps will be remarked 790 for the AF13 PHB. Note that the scheme will preserve ordering of 791 packets since AF11 and AF13 use a single queue.. 793 In order to provide this service, the provider will have to 794 implement the AF11 and AF13 PHBs in core network equipment. The 795 AF11 and AF13 PHBs can be implemented for example, using a single 796 RIO queue. The provider will also have to provision equipment 797 within the core of the provider's network to provide the AF11/AF13 798 service. By provisioning the appropriate RED parameters, for 799 example, the provider is able to control the priority of AF11 800 traffic relative to AF13 traffic at each network node. Since there 801 are no quantitative guarantees, the provider can be quite liberal 802 in its provisioning strategy and may realize significant 803 statistical multiplexing gains. Also, the absence of quantitative 804 guarantees makes it easy to provide this type of service across 805 multiple DS provider domains. This is because is not necessary to 806 negotiate, then provision and enforce quantitative guarantees at 807 multiple boundaries. 809 Bernet, et al Expires: September 1999 15 810 Draft-ietf-diffserv-framework-02.txt February, 1999 812 5.2 Leased Line Emulation Service 814 This is a quantitative service which emulates traditional leased 815 line service. As such, it promises to deliver customer traffic 816 with very low latency and very low drop probability, up to a 817 negotiated rate. Above this rate, traffic is dropped. Such a 818 service is typically offered between two specific points. It is 819 suitable for many customer applications. However, due to the high 820 quality guarantees, it is likely to be priced higher than 821 alternate services and therefore, to be used only for applications 822 which really require this type of service. An example of such an 823 application is IP telephony. A corporate customer might purchase 824 leased line emulation service between each pair of a number of 825 corporate network sites. 827 5.2.1 Service Implementation 829 In this example, we consider a customer with three geographically 830 dispersed networks interconnected via a single provider network. 831 Customer attachment points are represented as A, B and C. At each 832 attachment point, an SLS describes the leased line service to be 833 provided to the other two points. The table below represents the 834 information required in the TCS at attachment point A: 836 EF-Mark : 100 Kbps : Egress point B : Discard non-conforming 837 traffic 839 EF-Mark : 50 Kbps : Egress point C : Discard non-conforming 840 traffic 842 Packets submitted for leased line service should be marked with 843 the DS-field codepoint corresponding to the EF PHB [EF]. From the 844 ingress point A, to the egress point B, the provider is promising 845 to carry up to 100 Kbps of traffic. Excess traffic will be 846 discarded. From ingress point A, to egress point C, the provider 847 promises to carry 50 Kbps of traffic. Of course, there is some 848 tolerance required in policing the traffic and thus, there may be 849 a specification of tolerated jitter or burst size. However, for a 850 leased line service, the primary traffic profile parameter would 851 be the sustained traffic rate. 853 The provider will provision a policer at ingress point A to limit 854 traffic destined for egress point B, to 100 Kbps. Similarly, a 855 policer will be configured to limit traffic destined for egress 856 point C, to 50 Kbps. These policers will require classification 857 based on the DS-Mark and the destination address in each packet. 859 In order to provide this service, the provider will have to 860 implement the EF PHB in core network equipment. The EF PHB can be 861 implemented using strict priority queuing or alternatively, by 862 assigning EF marked packets to a heavily weighted queue in a WFQ 863 scheme. The provider will have to provision equipment within the 865 Bernet, et al Expires: September 1999 16 866 Draft-ietf-diffserv-framework-02.txt February, 1999 868 core of the provider's network. For example, routers carrying 869 traffic between point A and points B and/or C will have to be 870 provisioned considering the resources committed by the TCS at 871 point A. This means that a router which is both in the path from A 872 to B and from A to C, will have to be considered to have committed 873 150 Kbps of bandwidth as a result of the TCS in place at A. A 874 router that is only in the path from A to B, will have to be 875 considered to have committed 100 Kbps as a result of this TCS, and 876 so on. Of course, routing is subject to change and so, failover 877 paths may have to be provisioned as well. These may be provisioned 878 to provide some fraction of the service in the case of failover or 879 alternatively, the SLS at point A might reflect appropriate 880 service availability parameters. To enhance the assurances offered 881 by EF service, providers may employ route pinning mechanisms or 882 QoS routing mechanisms. 884 5.3 Quantitative Assured Media Playback Service 886 This service offers looser assurances than the leased line service 887 described above, but is still considered a quantitative service. 888 In particular, it promises to deliver traffic with a high degree 889 of reliability and with variable but bounded latency, up to a 890 negotiated rate. Above this rate, traffic is subject to 891 significant delay or drop. Such a service is typically offered 892 between a specific set of points. It is suitable for many customer 893 applications. It would likely be priced lower than a leased line 894 service, due to the latency variability. However, due to the 895 latency bound and high degree of delivery, it is likely to be 896 priced higher than alternate services. This service is 897 particularly suitable for video or audio playback, in which 898 considerable bandwidth is required on a continual basis, but the 899 non-interactive nature of the traffic makes it somewhat delay 900 tolerant. 902 5.3.1 Service Implementation 904 In this example, we again consider a customer with three 905 geographically dispersed networks interconnected via a single 906 provider network. The table below represents the information 907 required in the TCS at attachment point A: 909 AF11-Mark : 100 Kbps sustained, 100 Kb bursts tolerated at up to 910 200 Kbps : Egress point B : Excess burst traffic over sustained 911 rate marked with AF12-mark : Non-conforming traffic marked with 912 AF13-mark : Max latency = 1 second 914 AF11-Mark : 50 Kbps sustained, 100 Kb bursts tolerated at up to 915 100 Kbps : Egress point C : Excess burst traffic over sustained 916 rate marked with AF12-mark : Non-conforming traffic marked with 917 AF13-mark : Max latency = 2 seconds 919 Bernet, et al Expires: September 1999 17 920 Draft-ietf-diffserv-framework-02.txt February, 1999 922 Packets submitted for the assured playback service should be 923 marked with the DS-field codepoint corresponding to the AF11 PHB. 924 From the ingress point A, to the egress point B, the provider is 925 promising to carry up to 100 Kbps of sustained traffic with bursts 926 of 100 Kb in size at a peak rate of 200 Kbps. Excess burst traffic 927 will be marked with the codepoint for AF12 and out of profile 928 traffic will be carried but with the AF13 codepoint. So long as 929 these conditions are met, latency will be limited to 1 second. 930 Note that for this service, the traffic profile is described using 931 a full set of token bucket parameters. Since the latency bounds 932 for such a service are less strict than those required for the 933 leased line service, a certain degree of traffic burstiness can be 934 tolerated. 936 The provider must support the AF11, AF12 and AF13 PHBs in core 937 network routers. These PHBs might be provided, for example, by 938 assigning AF11, AF12 and AF13 marked traffic to a single RIO queue 939 with high drop thresholds. The policers at the boundary would 940 limit competing traffic in line with the TCS, in order to assure 941 that the latency bounds can be met. In addition, the service 942 provider will have to provision devices in the core of the 943 network. The provisioning considerations discussed in the context 944 of the leased line service apply here as well, however, in 945 general, the service provider has the liberty of being less 946 conservative in provisioning and realizing better statistical 947 gains. 949 5.4 Superposition of Quantitative and Qualitative Services in the 950 Same Network 952 A compelling model would provide both quantitative and qualitative 953 services in the same differentiated service network(s) as follows. 954 A number of corporate campus networks would be interconnected by a 955 differentiated service network providing quantitative services 956 between the sites. For example, a mesh of leased line services 957 would enable IP telephony between the sites. A mesh of media 958 playback service using the AF11 PHB would enable audio/video 959 playback between the sites. In addition, each corporate site would 960 be allotted some level of BBE service to arbitrary destinations. 961 In this model, the differentiated service network is effectively 962 providing a mesh of quantitative services between fixed locations 963 (similar to a VPN). This mesh is superimposed on a cloud 964 supporting BBE service. 966 6. Provisioning and Configuration 968 The provision of differentiated services requires careful network 969 wide provisioning and configuration. Provisioning refers to the 970 determination and allocation of the resources needed at various 971 points in the network. Provisioning may dictate the addition or 972 removal of physical resources at various points (physical 973 provisioning). Provisioning may also dictate the modification of 975 Bernet, et al Expires: September 1999 18 976 Draft-ietf-diffserv-framework-02.txt February, 1999 978 operating parameters within existing physical network equipment to 979 alter the relative share of the equipment's resources which are 980 allotted to one or another class of traffic (logical 981 provisioning). Configuration refers to the distribution of the 982 appropriate operating parameters to network equipment to realize 983 the provisioning objectives. 985 In Secs. 4.6 and 4.7, we briefly discussed provisioning and 986 configuration requirements both at the network boundaries and in 987 the network interior. In this section we will focus primarily on 988 the coordination of provisioning and configuration throughout the 989 network, such that end-to-end services can be provided reliably. 990 We will discuss the roles of protocols such as SNMP, CLI, RSVP, 991 COPS and LDAP in the provisioning process. 993 6.1 Boundary vs. Interior Provisioning and Configuration 995 For the sake of brevity, consider the term 'provisioning' to refer 996 both to provisioning and configuration, except where otherwise 997 noted. It is helpful to consider provisioning at the network 998 boundaries, separately from provisioning of the interior. Since 999 the differentiated service provider is selling a contract (SLA) at 1000 the network boundary, we can consider the boundary provisioning 1001 which supports SLSs, to drive the interior provisioning. The two 1002 are not entirely separable in that each affects the other. For 1003 example, a network operator cannot offer an SLS which cannot be 1004 met by the resources available in the interior of the network. In 1005 general, the overall provisioning process iterates between the 1006 boundaries and the interior. From here on we will refer to 1007 provisioning with respect to the TCS rather than the SLS, since 1008 the TCS is the component of the SLS that defines detailed traffic 1009 handling parameters. 1011 6.1.1 Boundary Provisioning 1013 Boundary provisioning was considered briefly in Sec. 2.6. We 1014 discussed the minimal provisioning that a provider must implement 1015 to enforce a TCS. We also discussed additional configuration which 1016 a provider may use to provide additional (especially per-flow) 1017 services to a customer. The latter is not actually related to the 1018 provisioning of resources within the differentiated services 1019 network, but rather assists the customer by determining which 1020 subsets of the customer's traffic make use of the resources 1021 provisioned within the differentiated services network. As such, 1022 it is out of the scope of this section. Here, we consider only the 1023 minimal provisioning required at the boundary. 1025 At a minimum, the provider must assure that sufficient physical 1026 resources are provisioned at the boundary to meet the requirements 1027 of the TCS. For example, if the sum of the profiles supported at a 1028 particular ingress point would allow 10 Mbps of traffic to be 1029 supported, it is unacceptable to provision a T-1 access link. A T- 1031 Bernet, et al Expires: September 1999 19 1032 Draft-ietf-diffserv-framework-02.txt February, 1999 1034 3 however, would be sufficient. Once the physical provisioning is 1035 implemented, it is necessary to apply the appropriate logical 1036 provisioning. This is achieved by configuring policers which limit 1037 the amount of traffic accepted from the T-3 access link, at each 1038 service level and, for double ended TCSs, for the appropriate 1039 egress points. It may also be necessary to set up the amount of 1040 buffering available for the queues used for the service. Similar 1041 provisioning is also appropriate at each egress point if the 1042 aggregate of profiles provisioned to the egress exceeds the 1043 capacity of the output link. 1045 6.1.2 Interior Provisioning 1047 For the purpose of provisioning the interior of the network, it is 1048 desirable to understand or to control the volume of traffic of 1049 each class which traverses each network node. The greater this 1050 understanding, the more efficiently the network can be provisioned 1051 while still meeting the requirements of the TCSs. It is feasible 1052 to understand the volume of traffic traversing each node if this 1053 traffic is admitted according to a TCS which dictates egress point 1054 as well as ingress point. (This case generally applies to 1055 quantitative services and was discussed in the context of the EF 1056 PHB and the leased line service in Sec. 3.2.1). While traffic 1057 volumes cannot be anticipated with 100% accuracy, it is possible 1058 to approximate them quite well, especially with the help of route 1059 pinning mechanisms. It is therefore possible to provision the 1060 network reasonably accurately for traffic submitted for 1061 quantitative services. Although such provisioning may be quite 1062 difficult in a large network, it is nonetheless a tractable 1063 problem. We will refer to this component of the provisioning 1064 problem as quantitative provisioning. 1066 On the other hand, many (if not most) of the services offered by 1067 differentiated service networks will not specify egress points (as 1068 is the case for qualitative services) and will not restrict 1069 submitted traffic to specific egress points, let alone specific 1070 routes. Thus, interior nodes will have to be provisioned without 1071 an a-priori understanding of the volume of traffic submitted for 1072 qualitative services which will arrive at each node. It is 1073 necessary to be able to provision differentiated service networks 1074 to support both quantitative services with specific egress points 1075 as well as qualitative services, which do not have specific egress 1076 points on the same physical resources. To this end, it is 1077 necessary to isolate the impact of qualitative traffic on the 1078 resources reserved for quantitative traffic. This can only be 1079 achieved if the former is treated with lower priority than the 1080 latter. Thus, in general, resources will have to be provisioned 1081 first for quantitative traffic, using quantitative provisioning 1082 mechanisms. Then, qualitative provisioning can be used to allocate 1083 remaining resources to qualitative traffic. Qualitative 1084 provisioning can also be applied to services which offer a 1085 relative quantification of traffic volumes. 1087 Bernet, et al Expires: September 1999 20 1088 Draft-ietf-diffserv-framework-02.txt February, 1999 1090 The impact of the two types of traffic will have to be isolated by 1091 ensuring that they do not share PHB codepoints. PHBs used for 1092 quantitative services will always have higher priority access to 1093 resources than those used for qualitative services. As a result, 1094 it is necessary to carefully police traffic submitted for 1095 quantitative PHBs. Failure to do so can result in the starvation 1096 of lower priority traffic. In general it can be expected that only 1097 a small fraction of the resources at each node will be provisioned 1098 for quantitative traffic. 1100 Similarly, a significant fraction of the traffic capacity should 1101 remain for best-efforts service to provide a 'soft' target for 1102 traffic dropping if congestion occurs or it is necessary to 1103 redirect non-best efforts traffic in the event of failure. 1105 6.1.2.1 Quantitative Provisioning of the Interior 1107 As discussed previously, quantitative provisioning is a difficult 1108 but tractable problem. With knowledge of the network routing 1109 topology and the TCSs at the boundaries, it is possible to compute 1110 the resources required at each interior node to carry the 1111 quantitative traffic offered at the edges. Based on the results of 1112 this computation, interior nodes must be provisioned and 1113 configured with sufficient capacity to accommodate the 1114 quantitative traffic which will arrive at the node, while leaving 1115 sufficient capacity remaining to accommodate some amount of 1116 qualitative traffic. 1118 The provisioning mechanism described assumes a top-down approach, 1119 in which the network administrator studies the network topology 1120 and traffic routing and computes the provisioning requirements. An 1121 alternative approach uses signaling to automate the process 1122 [MPLS]. For example, RSVP messages could be launched along the 1123 paths that will be followed by submitted quantitative traffic. If 1124 a TCS calls for 100 Kbps of leased-line service from ingress point 1125 A to egress point B, an RSVP message could be transmitted from 1126 point A towards point B, with a flowspec specifying 100 Kbps. This 1127 message would traverse each node at which resources would have to 1128 be committed. Conventional RSVP routers would install a 1129 reservation. In a differentiated service network, RSVP could be 1130 adapted to provision the resources required per the differentiated 1131 services model. In a network which offers a number of static TCSs, 1132 such RSVP messages could be launched from the TCS ingress point at 1133 the time the TCS is initially instantiated with the effect of 1134 instantiating the appropriate cumulative provisioning in routers 1135 along the various routes. The advantage of this approach is that 1136 it does not require explicit knowledge of the network topology. We 1137 will revisit these two approaches to quantitative provisioning of 1138 the interior in a later section. 1140 Bernet, et al Expires: September 1999 21 1141 Draft-ietf-diffserv-framework-02.txt February, 1999 1143 Once the resources required for quantitative traffic at each node 1144 have been determined, provisioning of the node consists of 1145 installing or configuring interfaces of the appropriate capacity 1146 to easily accommodate the quantitative traffic that will traverse 1147 the node. Note that we do not state the precise meaning of 'to 1148 easily accommodate'. A number of factors must be considered when 1149 determining the appropriate capacity, given a certain volume of 1150 predicted quantitative traffic. These include: 1151 1. Margin of error 1152 2. Statistical gain desired 1153 3. Capacity remaining for qualitative (including best efforts) 1154 traffic 1156 The first, margin of error, accommodates mistakes in computation, 1157 effects of transient route changes which are not otherwise 1158 accounted for, effects of traffic clustering as it moves through 1159 the network and so on. The statistical gain desired refers to the 1160 degree to which a provider is willing to gamble that not all 1161 sources of quantitative traffic will be simultaneously active at 1162 the limit dictated by the TCSs at the ingress points (vs. the 1163 penalty the provider would be willing to pay in terms of refunded 1164 charges or lost customers). Finally, the provider must determine 1165 how much capacity will be reserved for qualitative traffic at each 1166 node. Thus, if it is determined that 1 Mbps of quantitative 1167 traffic might traverse a specific node in a specific direction, 1168 the provider might install a 10 Mbps interface in the node, to 1169 serve the corresponding traffic direction. This would leave 9 Mbps 1170 of capacity quite safely for qualitative traffic. In this case, 1171 the provider would be assuming that statistical gains which might 1172 be realized will be used to offset the margin of error which would 1173 compromise the resources available. 1175 In addition to installing or configuring the appropriate capacity 1176 at each interface, it may be desirable to configure policers to 1177 assure that the resources actually consumed by the higher priority 1178 quantitative traffic do not exceed expectations. This is 1179 especially important if the provider is attempting to achieve a 1180 high degree of statistical gain or has not allowed for a 1181 reasonable margin of error. Policers need not be configured at 1182 each interior node, but should probably be configured at certain 1183 key nodes. It may also be necessary to configure the internal 1184 resources of the router (queues and buffers) to deliver the 1185 services required. 1187 6.1.2.2 Qualitative Provisioning of the Interior 1189 As explained previously, it is necessary first to determine the 1190 resources which must be provisioned at each node for quantitative 1191 traffic. Once these have been determined, interfaces must be 1192 installed or provisioned to accommodate the required resources 1193 while leaving sufficient capacity for qualitative traffic. In 1194 order to do so, it is necessary to determine the resources 1196 Bernet, et al Expires: September 1999 22 1197 Draft-ietf-diffserv-framework-02.txt February, 1999 1199 required at the node for qualitative traffic. Since qualitative 1200 traffic cannot be assumed to follow specific routes with the same 1201 degree of predictability as quantitative traffic, this 1202 provisioning problem is far more difficult and provisioning 1203 parameters must be estimated based on heuristics, experience and 1204 possibly on real time measurement. 1206 Once physical interfaces have been selected to accommodate the 1207 resources required by the computed quantitative traffic load and 1208 the estimated qualitative traffic load, additional configuration 1209 is required to support qualitative traffic. Such configuration 1210 amounts to the selection of relative weights for queues for 1211 different service levels (in a WFQ scheme), or the selection of 1212 RIO or RED thresholds or alternate logical resource provisioning 1213 parameters. It is assumed that if quantitative traffic is 1214 accommodated via similar queuing mechanisms (as opposed to strict 1215 priority queuing), that the weighting parameters chosen for 1216 quantitative traffic isolate it effectively from the effects of 1217 qualitative traffic. However, the configuration parameters which 1218 differentiate the various qualitative services may not provide 1219 such a degree of isolation among the qualitative services. Thus, 1220 it may be necessary to attempt to estimate the relative traffic 1221 arriving for each qualitative service and to anticipate the 1222 interaction between traffic of different qualitative services. It 1223 may be impossible to both efficiently and conservatively provision 1224 a network for certain combinations of qualitative services. To aid 1225 in the provisioning of a network for qualitative services, it may 1226 be useful to configure policers to control the volume of traffic 1227 arriving at a given node. However, such policing might have to be 1228 restricted to shaping (rather than discarding) in order to avoid 1229 violating TCSs in place at the network boundaries. 1231 6.2. Static vs. Dynamic Provisioning 1233 So far, we have considered static provisioning techniques. Even 1234 the example of RSVP usage for provisioning assumed that the RSVP 1235 messages were launched at the time a TCS was instantiated as 1236 opposed to dynamically. In the case that TCSs are static, static 1237 provisioning is adequate for quantitative traffic. However, since 1238 qualitative traffic offers less predictable patterns, it is likely 1239 to cause traffic volumes at different nodes in the network to 1240 change dynamically, even when the TCS is static. For this reason, 1241 dynamic provisioning techniques are desirable and may assist the 1242 service provider in making better use of network resources. In 1243 addition, dynamic provisioning may enable the service provider to 1244 provision more liberally for quantitative services, realizing 1245 statistical gains. If we consider further, that it may be 1246 desirable to provide dynamically changing TCSs, then the appeal of 1247 dynamic provisioning techniques is even stronger. 1249 Dynamic provisioning may be signaling based, measurement based or 1250 both. For example, a conventional RSVP router supports signaling 1252 Bernet, et al Expires: September 1999 23 1253 Draft-ietf-diffserv-framework-02.txt February, 1999 1255 based dynamic provisioning. Hosts signal the router to request 1256 more or less resources and the router adjusts accordingly. The 1257 host may or may not actually submit traffic at the rate at which 1258 it signaled it would, but regardless, the resources are committed 1259 in case it does. Measurement based provisioning would adjust the 1260 resources committed in response to the traffic loads actually 1261 measured at the device. While differentiated services does not 1262 specify any form of signaled or measurement based provisioning, 1263 both may be useful. 1265 6.3 Distributing Configuration Information 1267 The process of physical provisioning is by necessity relatively 1268 static and cannot be automated since it requires installation of 1269 physical equipment. However, logical provisioning and 1270 configuration can and should be automated to the degree possible. 1271 In this section, we look at techniques for distributing 1272 configuration information. 1274 6.3.1 Top Down Distribution of Configuration Information 1276 In the simplest case, TCSs are static and both the boundaries and 1277 interior of the network are provisioned statically by 'pushing' 1278 configuration information down to the appropriate network nodes. 1279 Configuration of boundary nodes requires primarily the pushing of 1280 policing information to enforce the TCSs in place. (Additional 1281 fine grain information may be pushed to provide traffic separation 1282 services on behalf of the customer, but these are not addressed in 1283 this context). Configuration information for boundary nodes is 1284 determined at the time the TCS is negotiated. At this time, the 1285 nodes are configured by the provider. The network administrator 1286 may use one of several protocols to do so, including for example 1287 SNMP or CLI. 1289 In order to accommodate the traffic submitted by the provisioning 1290 of new TCSs, it is necessary to provision the interior of the 1291 network. As discussed previously, it is possible to compute the 1292 resources required for quantitative traffic. Assuming that 1293 sufficient physical capacity has been provisioned, configuration 1294 amounts to logically provisioning sufficient capacity at each 1295 interior interface and to configuring policers for the 1296 quantitative traffic at various interior nodes. In addition, 1297 qualitative provisioning requires the configuration of queues, WFQ 1298 weights and/or RIO parameters at various interior nodes, and may 1299 also include the configuration of some number of policers. In the 1300 case, of static, top down configuration, interior configuration 1301 information is also pushed down via a configuration protocol such 1302 as SNMP or CLI. 1304 The difficulty of such top down provisioning is that it requires 1305 the network administrator to coordinate the provisioning of each 1306 network node, at boundaries as well as in the interior, such that 1308 Bernet, et al Expires: September 1999 24 1309 Draft-ietf-diffserv-framework-02.txt February, 1999 1311 the network is provisioned end-to-end in a consistent manner and 1312 is able to efficiently deliver the services promised by the TCSs. 1313 In order to assist the network administrator in this task, it is 1314 useful to consider a database which holds both current topology 1315 information as well as the current TCSs instantiated at the 1316 network boundaries. This information is stored in a format 1317 dictated by a standard schema as suggested in [Ellesson]. 1319 Of course, the database is ideally maintained in a way which is 1320 logically centralized (for ease of programming and modifying) but 1321 is physically distributed (for the sake of robustness and fault 1322 tolerance). Policy servers may be used to extract information from 1323 the database and to convert it to configuration information which 1324 is pushed down to individual nodes. In this scenario, policy 1325 servers would likely use a directory access protocol such as LDAP 1326 to retrieve information from the directory and would use a 1327 configuration protocol such as SNMP or CLI to push the 1328 configuration information down to the network nodes. Note that in 1329 this example, the policy servers and the directory schemas are in 1330 effect fulfilling the role of bandwidth broker [ROTZY]. In 1331 particular, the policy servers use an awareness of the network 1332 topology to provision interior nodes such that certain end-to-end 1333 QoS routes can be constructed and assurances implied by the TCSs 1334 at the boundaries can be delivered. 1336 6.3.2 Distribution of Configuration Information via Signaling 1338 An alternate mechanism of distributing configuration information 1339 is via signaling messages transmitted between boundary nodes of 1340 the same differentiated service domain (intra-domain signaling). 1341 It is also interesting to consider inter-domain signaling, but 1342 this will be addressed separately. An example of such signaling 1343 was described previously, in the usage of a modified form of RSVP. 1344 Such signaling is particularly useful for the purpose of 1345 installing configuration information for quantitative services 1346 which affect specific paths and is somewhat less useful (though 1347 not useless) for the purpose of configuring qualitative services. 1348 It is likely that such a signaling approach would be used in 1349 conjunction with top down provisioning. For example, the directory 1350 schema might dictate the amount of resources to be available for 1351 high priority quantitative services at each node. These limits 1352 might be pushed down to individual nodes a-priori. Signaling from 1353 the network boundaries, at TCS instantiation time, would then be 1354 used to claim resources from the pool of quantitative resources 1355 available at each node. Alternatively, nodes might consult policy 1356 servers as the signaling resource requests arrive at each node. 1357 The latter model is similar to the use of per- flow RSVP signaling 1358 and PEP/PDP policy usage in traditional RSVP networks. Qualitative 1359 configuration information would still be pushed in a top down 1360 manner. The advantage of the latter model is that policy servers 1361 would be dynamically updated with information regarding the 1362 current usage of network resources. In this model, it is likely 1364 Bernet, et al Expires: September 1999 25 1365 Draft-ietf-diffserv-framework-02.txt February, 1999 1367 that a variant of COPS would be used to communicate between 1368 network nodes and the policy servers. Note that COPS may be used 1369 for distribution of top down configuration information as well, 1370 though it is not specifically designed for this purpose. 1372 One of the advantages of configuration via signaling, is that it 1373 facilitates the support of dynamic TCSs. TCSs could be dynamically 1374 renegotiated using inter-domain signaling. Such renegotiation 1375 would require dynamically modifying the provisioning within the 1376 affected domain, a process which requires some automated signaling 1377 protocol such as an aggregated form of RSVP signaling between 1378 boundary nodes in a provider's domain. This protocol would in 1379 effect, represent a distributed bandwidth broker [ROTZY] for the 1380 domain. 1382 6.3.3 Modification of Configuration Information Based on Real-Time 1383 Measurement 1385 A third mechanism for the configuration of interior nodes would be 1386 based on measurement of current traffic loads at key network 1387 nodes. Measurement based configuration is less necessary for 1388 quantitative provisioning, since quantitative traffic patterns are 1389 relatively predictable. However, it can significantly enhance the 1390 efficiency with which qualitative provisioning can be achieved. 1391 For example, network nodes may feed policy servers with current 1392 qualitative traffic load measurements. In response, bandwidth 1393 brokers and policy servers might recompute the relative weights 1394 for different service queues in a WFQ node and push the new 1395 configuration information to the routers. It is likely that 1396 measurement based configuration for qualitative services would be 1397 used in conjunction with signaling based configuration for 1398 quantitative services. 1400 7. Inter-Domain Considerations and End-to-End Services 1402 So far we have considered differentiated service primarily in the 1403 context of a single DS domain providing service to a single 1404 customer. The ultimate customers of the differentiated service 1405 network are hosts and end users residing on peripheral stub 1406 networks. In general, these are interconnected by multiple domains 1407 and require service which spans these domains. Therefore, it is 1408 important to consider the interaction of services provided by a 1409 concatenation of differentiated service domains and the peripheral 1410 stub networks, rather than the service provided by a single 1411 domain. The interactions of the services and the network 1412 concatenation present a serious challenge to providers seeking to 1413 provision the services scientifically. Whether algorithms or 1414 heuristics can be developed to cover the full spectrum of service 1415 combinations is an open question, but by analogy with QoS Routing 1416 it is very likely that some of the problems are not computable. 1417 In this section, we discuss inter-domain issues related to TCSs, 1418 provisioning and service and PHB mapping. 1420 Bernet, et al Expires: September 1999 26 1421 Draft-ietf-diffserv-framework-02.txt February, 1999 1423 7.1 TCSs 1425 Each service provider is expected to negotiate bilateral 1426 agreements at each boundary node at which it connects to an 1427 adjacent provider's network. Such The technical aspects of these 1428 agreements that relate to delivering differentiated services are 1429 captured in the form of two TCSs, one specifying the services 1430 provided to provider A's traffic by provider B and the other 1431 specifying the services provided to provider B's traffic by 1432 provider A. Note that provider A serves as a provider to provider 1433 B with respect to traffic flowing from provider B to provider A. 1434 On the other hand provider A is a customer of provider B with 1435 respect to traffic flowing from provider A to provider B. The two 1436 TCSs can be considered separately. 1438 In general, the TCSs needed by a provider at any boundary will be 1439 dictated by TCSs negotiated at other boundaries. For example, 1440 assume that provider A offers leased line service to a customer 1441 with an ingress point in provider A's domain, but an egress point 1442 in provider B's domain. In this case, it is necessary that the TCS 1443 between provider A and provider B be sufficient to accommodate the 1444 assurance made by provider A to its leased line service customer. 1445 Provider A may serve a number of customers with leased line 1446 services terminating at various boundary points in provider B's 1447 network. Thus, the TCS between provider A and provider B must 1448 represent the aggregate requirements of the TCSs of all of 1449 provider A's customers. 1451 7.2 Inter-Domain Provisioning 1453 The inter-domain provisioning problem is not unlike the intra- 1454 domain provisioning problem. The provider would generally begin by 1455 evaluating the TCSs it has negotiated with its customers, and then 1456 computing the impact of each of these TCSs on the TCSs it has 1457 negotiated with its providers. For quantitative services, the 1458 provider can compute the quantitative requirements of TCSs at each 1459 of its provider's boundary nodes, as described above in the 1460 context of the leased line service. For qualitative services, the 1461 process of determining the requirements from its providers is 1462 fuzzier, since the volume of qualitative traffic expected to be 1463 carried through any boundary is less deterministic. 1465 In the simplest case, provisioning is based on static TCSs. In 1466 this case, provisioning is an iterative process in which providers 1467 negotiate TCSs with each of their customers, then apply the 1468 appropriate internal provisioning techniques to meet these 1469 requirements. In the process of internal provisioning, a provider 1470 might determine that a particular TCS cannot be met due to 1471 internal resource constraints. The provider would then either have 1472 to add internal resources or renegotiate one or more customer 1473 TCSs. Although the process may be somewhat iterative, it is 1475 Bernet, et al Expires: September 1999 27 1476 Draft-ietf-diffserv-framework-02.txt February, 1999 1478 relatively static in that changes in boundary TCSs and internal 1479 provisioning occur relatively infrequently (on the order of hours, 1480 days or months) and require human intervention. 1482 Internal provisioning to meet the requirements of TCSs relies on 1483 provisioning techniques described previously. As TCSs are 1484 negotiated, the provider must check that the existing internal 1485 provisioning is sufficient to meet the requirements of the new 1486 TCS, or must alter the internal provisioning. Recall that internal 1487 provisioning might be pushed in a top down manner, from a domain's 1488 logically centralized point of administration, or alternatively 1489 might be distributed from the boundaries via signaling. In the 1490 former case, some form of a bandwidth broker would be directly 1491 consulted or notified regarding changes in TCSs negotiated at the 1492 domain boundaries. In the case that signaling is used, 1493 provisioning messages (such as described previously) would be 1494 launched from the boundary at which the new TCS is negotiated. 1495 These would claim a share of existing provisioned resources, or 1496 would notify the bandwidth broker in the case that additional 1497 resources are required. 1499 A more sophisticated model would allow TCSs to be renegotiated 1500 dynamically. In this case, the process would be automatic, and 1501 would not require human intervention. Each domain would in effect, 1502 represent a bandwidth broker, via one protocol or another. A 1503 specific inter-domain protocol might be used to communicate 1504 between centralized bandwidth broker agents, or alternatively, an 1505 inter- domain variant of RSVP might be used. In the latter case, 1506 there is no direct interaction with a bandwidth broker per-se. 1507 However, the collection of network nodes, policy servers and 1508 directory behave collectively as a bandwidth broker which 1509 communicates using RSVP. In either case, TCS renegotiations would 1510 be triggered by load measurements at boundary nodes. These could 1511 be in the form of changes in actual measured traffic volume, or 1512 alternatively, based on explicit fine grain RSVP resource requests 1513 from hosts at the periphery. Domains would approve renegotiations 1514 based both on resource constraints as well as predetermined policy 1515 constraints. 1517 7.3 Service, PHB and Codepoint Mapping 1519 In order to provide end-to-end service to customers, it must be 1520 possible to extend services across multiple domains. Several 1521 complexities may arise at inter-domain boundaries, as follows: 1522 1. The services provided by a certain domain may not be compatible 1523 with the services provided by a neighbour domain. 1524 2. The services provided by a certain domain may be compatible 1525 with those provided by the neighbour domain, but the PHB used 1526 to obtain the service might be different. 1527 3. The PHB might be the same, but the codepoint used to request 1528 the PHB might be different. 1530 Bernet, et al Expires: September 1999 28 1531 Draft-ietf-diffserv-framework-02.txt February, 1999 1533 4. The PHB and codepoint are the same but differences in 1534 provisioning and charging models results in different services. 1536 Resolution of these complexities requires determination of the 1537 compatible services and negotiation of the PHB codepoints which 1538 will be used to request the services. This process is greatly 1539 simplified by the provision of a set of universal services using 1540 universally recognized codepoints. The leased line service and the 1541 recommended EF codepoint is likely to be one such example. 1542 Generally, extension of quantitative services across multiple 1543 domains will require more uniformity in the nature of the services 1544 provided. Qualitative services on the other hand, may be extended 1545 end-to-end by a concatenation of services which vary from domain 1546 to domain. For example, one domain may base a qualitative service 1547 on a WFQ scheme with RED while another may use priority queuing 1548 with RIO. Since the assurances provided by qualitative services 1549 tend to be looser, it is possible that a meaningful service can be 1550 provided end-to-end by concatenating these two service types. 1552 7.4 Host-Domain Boundaries 1554 In certain cases, a host may be directly attached to a 1555 differentiated service domain. This is likely both in the case of 1556 campus networks that provide differentiated services within the 1557 network or in the case of dial-up users connecting to a 1558 differentiated service provider. In these cases, the host can be 1559 considered the customer of the differentiated service network. 1560 Legacy hosts are unlikely to mark their own packets for the 1561 appropriate DS-field and are also unlikely to shape or police 1562 their traffic. In the case of legacy hosts, the differentiated 1563 service provider will have to provide these services on behalf of 1564 the customer. In the case of campus networks, some network wide 1565 policy would likely be used to configure these services in the DS 1566 boundary devices. In the case of dial-up hosts, marking, shaping 1567 and resources provided would likely be negotiated at the time the 1568 customer signs up with the provider. 1570 Newer hosts may be capable both of marking and of traffic shaping. 1571 In this case, the overall per-host resource constraints are still 1572 likely to be somewhat static. However, the manner in which the 1573 host shares these resources among its various traffic flows is 1574 determined by the host. Of course, the provider will have to 1575 configure policers to assure that the host does not seize more 1576 than its share of resources in the differentiated service network. 1578 8. Deployment Scenarios 1580 A number of scenarios can be envisaged for the junction of a non- 1581 DS Domain and a DS Domain, and hence for deployment scenarios: 1582 1. A service provider runs a DS Domain which offers Differentiated 1583 Services to a customer who has a network which has no DS 1584 capability - the junction occurs at the ingress to the service 1586 Bernet, et al Expires: September 1999 29 1587 Draft-ietf-diffserv-framework-02.txt February, 1999 1589 provider's network. The service provider would provide 1590 classification, marking and shaping of traffic as a value-added 1591 service using information provided by the customer. 1592 2. A service provider runs a DS Domain for a customer who has a 1593 network which has mostly no DS capability except that the 1594 customer's first hop or demarcation router acts as a 1595 degenerate, one node DS Domain. The only (boundary) node in 1596 this domain performs classification, marking and shaping, 1597 whilst the provider's equipment just has to police the incoming 1598 aggregate traffic. 1599 3. The customer and provider both have fully capable DS Domains. 1600 Hosts are embedded in the customer's DS Domain - the junction 1601 between the non-DS and DS Domains is logically at the boundary 1602 between the Operating System and the application. 1604 Scenarios 1 and 2 provide simple initial deployment mechanisms for 1605 DS as they do not require general modification of hosts. The 1606 advantage of Scenario 2 over Scenario 1 is that the customer can 1607 use, and keep private, local administrative knowledge to improve 1608 the classification of packets. In Scenario 1 this information 1609 would have to be made available in the service provider's domain 1610 to achieve the same granularity of classification requiring that 1611 the customer have greater trust in the provider. 1613 Scenario 3 requires modification of hosts. Direct interaction 1614 between applications and the DS Ingress node would therefore be 1615 possible giving scope for sophisticated application of the DS 1616 capabilities; even without such interaction, extremely fine- 1617 grained classification of traffic packets would be possible in the 1618 operating system kernel. Authentication of the application/host 1619 and authorization to use DS services requires particular attention 1620 in this case, although care has to be taken to avoid denial of 1621 service attacks in all cases (see Sec. 11 and [DSARCH] for further 1622 discussion of security). 1624 A customer might also deploy a network of DS capable routers 1625 before some or any of the associated hosts were DS capable. 1626 Classification, marking and shaping would be provided by the 1627 `first hop' router which the packet encounters on the first hop 1628 after leaving the host; the core of the customer's network is 1629 fully DS capable and the packets are forwarded in accordance with 1630 their DSCP to another host in the same DS Domain or on to a 1631 provider's domain. 1633 It might be possible to utilize non-DS capable routers in the 1634 interior of a DS Domain without compromising the QoS delivered 1635 provided: 1636 - The non-DS capable routers forward unchanged TOS byte all 1637 packets marked with the values of DSCP used in the DS Domain. 1638 - The non-DS capable routers forward these packets as if they 1639 were best efforts traffic 1641 Bernet, et al Expires: September 1999 30 1642 Draft-ietf-diffserv-framework-02.txt February, 1999 1644 - The non-DS capable routers are used only at points which rarely 1645 or never experience congestion. 1647 9. Inter-operability with RSVP/Integrated Services 1649 In this section, we discuss alternatives for inter-operability 1650 between differentiated services and RSVP/Integrated services. 1652 9.1 RSVP/Integrated Services Over Differentiated Services 1654 This scenario is discussed in detail in [E2EQOS]. It assumes a 1655 model in which peripheral stub networks are RSVP and Intserv 1656 aware. These are interconnected by differentiated service 1657 networks. In this model, the scalability of differentiated service 1658 networks helps to extend the reach of RSVP/Integrated service 1659 (Intserv)networks. Intervening differentiated service networks 1660 appear as a single RSVP hop to the RSVP/Intserv networks. Hosts 1661 attached to the peripheral RSVP/Intserv networks signal to each 1662 other for per-flow resource requests across the differentiated 1663 service networks. Standard RSVP/Intserv processing is applied 1664 within the RSVP/Intserv peripheral networks. RSVP signaling 1665 messages are carried transparently through the differentiated 1666 service networks. Devices at the boundaries between the 1667 RSVP/Intserv networks and the differentiated service networks 1668 process the RSVP messages and provide admission control based on 1669 the availability of appropriate resources within the 1670 differentiated service network. 1672 This model is predicated on the availability of services within 1673 the differentiated service network which can extend the reach of 1674 intserv type services. For example, the leased line service can 1675 extend the intserv guaranteed service across a differentiated 1676 service network. Multiple guaranteed service micro-flows which 1677 exist in peripheral networks are aggregated into the EF behaviour 1678 aggregate at the boundary of the diffserv network. When an RSVP 1679 request for guaranteed service arrives at the boundary of a 1680 differentiated service network, RSVP style admission control is 1681 applied based on the amount of resources requested in the intserv 1682 flowspec and the availability of differentiated services at the 1683 corresponding service level (per the TCS). If admission control 1684 succeeds, the originating host (or its agent) marks traffic on the 1685 signaled microflow, for the appropriate differentiated service 1686 level. 1688 The RSVP/Intserv over differentiated service model is especially 1689 suitable for providing quantitative end-to-end services. The use 1690 of differentiated services eliminates the scalability concerns of 1691 RSVP/Intserv networks. The use of RSVP signaling provides 1692 admission control to the differentiated service network, based on 1693 resource availability and policy decisions. It also greatly 1694 simplifies the configuration of differentiated service 1695 classifiers, policers and other traffic conditioning components. 1697 Bernet, et al Expires: September 1999 31 1698 Draft-ietf-diffserv-framework-02.txt February, 1999 1700 Variations on this theme would enable some number of nodes within 1701 the differentiated service networks to process the per-flow RSVP 1702 messages passing through. These could be used to aid in dynamic 1703 provisioning without necessarily requiring any per-flow state or 1704 processing within the differentiated service network. In yet 1705 another model, the transition of per-flow RSVP messages through 1706 the differentiated service network might trigger aggregated RSVP 1707 signaling between differentiated service domain boundaries, for 1708 the purpose of renegotiating TCSs and adjusting provisioning 1709 dynamically [GBH97, CLASSY]. 1711 9.2 Parallel Operation 1713 Another alternative for the interoperation of differentiated 1714 service and RSVP/Intserv networks is simple parallel operation. In 1715 this mode, each node within the differentiated service network may 1716 also be an RSVP capable node. Some strategy would have to be 1717 selected for determining which packets are handled using RSVP and 1718 which are handled using differentiated services. For example, 1719 those that classify to an RSVP installed filter might be handled 1720 using RSVP, while those not classifying to specific RSVP filters 1721 would be handled according to the DS-field using differentiated 1722 service mechanisms. Such a model is likely to be deployed in 1723 smaller networks (since the RSVP/Intserv component is less suited 1724 for large networks). In particular, the stub networks cited in 1725 [E2EQOS] would likely provide differentiated services for those 1726 qualitative applications which do not signal, while providing 1727 RSVP/Intserv services for those quantitative applications which do 1728 signal. 1730 10. Multicast Services 1732 The basic concept of Differentiated Services appears to offer an 1733 excellent fit with a multicast service insofar as traffic may be 1734 forwarded from an ingress to several egresses. Unfortunately, as 1735 we shall see, provisioning a multicast service is extremely 1736 difficult. 1738 Because the Differentiated Services Architecture deals only with 1739 unidirectional flows, a 'multicast' service in a DS network will 1740 in fact offer a point-to-multipoint unidirectional service. Each 1741 source of traffic that wishes to send to the multicast group using 1742 this service needs a separate SLS which applies at the ingress 1743 point where the traffic enters the network. 1745 The network resources that must be provisioned for a multicast 1746 service will be affected by the mechanisms used by the routers to 1747 provide the service. Depending on the capabilities of the routers 1748 and the multicast routing protocol employed, sub-optimal 1749 replication of a packet may result in multiple copies travelling 1750 over the same link. 1752 Bernet, et al Expires: September 1999 32 1753 Draft-ietf-diffserv-framework-02.txt February, 1999 1755 If receivers can be added dynamically to a multicast group whilst 1756 a flow is in progress, the complexity of provisioning grows 1757 considerably: The amount of network resources that will be 1758 consumed by multicast traffic originating from a particular 1759 upstream network may be difficult to forecast in advance. 1760 Consequently, it may not be possible to offer quantitative 1761 services where dynamic addition of receivers adds to the paths 1762 through the network already used by the flow. 1764 All multicast receivers must also be capable of handling the 1765 existing or proposed traffic on the multicast tree. This is an 1766 extension of the receiver control problem discussed in Sec. 4.4.1 1767 where it is clearly not desirable for a single inadequate receiver 1768 to limit the traffic on a complete tree. It is therefore 1769 essential that a multicast service specify a minimum receiver 1770 capacity _ where the service passes from one domain to another the 1771 TCS on the receiving domain must offer at least this capacity. 1773 Note that application level multicast does not normally fall into 1774 the multicast service category because it is normally realised as 1775 a number of independent unicasts each of which is delivered by a 1776 unicast service. 1778 10.1 Codepoints and PHBs for Multicast Services 1780 To achieve resource isolation of multicast traffic from unicast 1781 traffic, it may be necessary to use separate codepoints and 1782 separate instances of a PHB or different PHBs for the multicast 1783 and unicast services. If the multicast traffic is not adequately 1784 isolated, dynamic addition of new members of the multicast group 1785 can adversely affect existing unicast traffic. 1787 Because a multicast service traffic flow can exit from a domain to 1788 several peer domains, care must be taken to use a codepoint and 1789 PHB that is compatible with the peering SLSs at the egress points. 1790 This may be a more stringent requirement than for a unicast 1791 service where a flow need only be compatible with a single egress 1792 point SLS. 1794 10.2 Provisioning Multicast Services 1796 The scope of a multicast service would normally be either case 1 1797 (any egress point) or case 3 (a pre-defined set of egress points) 1798 of Sec. 4.4. 1800 For a quantitative service the scope will, in general, need to be 1801 case 3. The service can be provisioned in a similar way to 1802 corresponding unicast services with the same volume of traffic 1803 along each of the paths from ingress to egress, but taking into 1804 account that all paths will be used simultaneously and allowing 1805 for multiple copies of traffic if necessary. If the multicast 1807 Bernet, et al Expires: September 1999 33 1808 Draft-ietf-diffserv-framework-02.txt February, 1999 1810 routing protocol used can generate different multicast trees 1811 depending on the order in which members join the group, 1812 provisioning may not be possible. Solving this problem may 1813 require pinning of the multicast tree branch points; the solution 1814 of this problem is outside the scope of this framework. 1816 For a qualitative service, provisioning is essentially the same as 1817 the unicast case, but statistical multiplexing gains are likely to 1818 be less because all paths may be used at once. 1820 The traffic conditioning mechanisms for multicast services are not 1821 significantly different from those for the unicast services but 1822 multiple shapers may be required where traffic exits from several 1823 interfaces on a single router or multiple replicas exit from one 1824 interface. 1826 An additional problem arises when a service is actually used as 1827 part of a multipoint-to-multipoint service. The traffic patterns 1828 resulting from this usage and the required provisioning cannot be 1829 easily generalised from the point-to-multipoint case, with the 1830 result that it is difficult to determine how much extra capacity 1831 should be provisioned when a link is a common path for traffic 1832 from several sources. 1834 11. Security and Tunneling Considerations 1836 The security and tunneling implications for the actual data 1837 transport of the services of the Differentiated Services 1838 Architecture have been extensively discussed in [DSARCH] and 1839 [DSHEAD] to which the reader is referred. 1841 Additional security considerations arise from the services 1842 overlaid on the data transport: 1843 1. The services maybe the subject of differential charging. 1844 Accordingly, the service users have to be authenticated and 1845 authorized, and the accounting data needed must be secured. 1846 2. The mechanisms used to create and distribute the policy and 1847 resource allocations must be secured. 1848 3. Statistical data needed to audit service delivery must be 1849 secured. 1851 The mechanisms used to provide this security are outside the scope 1852 of this framework, but are under consideration by the AAA working 1853 group. 1855 The use of tunnels in general and IPsec tunnels in particular 1856 impedes the work of MF Classifiers by concealing the fields used 1857 by L4 and higher layer classifiers. Thus traffic conditioners 1858 within the area where IPsec encryption is used will need to rely 1859 only on IP header fields, including the DS Field (BA Classifiers 1860 will work normally). If more sophisticated MF classification is 1861 required it will have to take place before the tunnel ingress and 1863 Bernet, et al Expires: September 1999 34 1864 Draft-ietf-diffserv-framework-02.txt February, 1999 1866 the application of IPsec encryption. If IPsec encryption is used 1867 end-to-end, then Differentiated Services may require host marking 1868 Similarly, there is a constraint on quantitative services in 1869 general because IPsec hides the final destination address, so that 1870 it may be difficult to police quantitative services when IPsec is 1871 used because the traffic conditioner cannot determine the egress 1872 address easily. 1874 If a tunnel carries multiple flows with different traffic types, 1875 they may be marked with different DS codepoints so that they are 1876 subjected to appropriate behaviors in the network interior. This 1877 may be considered to be a security breach as it allows traffic 1878 patterns to become visible. If just one codepoint is used for all 1879 traffic it should be selected carefully to be appropriate for all 1880 the traffic in the tunnel. 1882 12. Acknowledgements 1884 The authors would like to acknowledge the helpful comments and 1885 suggestions of the following individuals: Kathleen Nichols, David 1886 Black, Konstantinos Dovrolis, Shivkumar Kalyana, Wu-chang Feng, 1887 Marty Borden, and Ronald Bonica. 1889 13. References 1891 [2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit 1892 Differentiated Services Architecture for the Internet", Internet 1893 Draft 1895 [CLARK] D. Clark and J. Wroclawski, "An Approach to Service 1896 Allocation in the Internet", Internet Draft 1898 [CLASSY] S. Berson and S. Vincent, "Aggregation of Internet 1899 Integrated Services State", Internet Draft, November 1997. 1901 [COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A. 1902 Sastry, "COPS (Common Open Policy Service) Protocol", March 1998. 1904 [DSARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and 1905 W. Weiss, "An Architecture for Differentiated Services", Internet 1906 Draft, May 1998. 1908 [DSHEAD] K. Nichols and S. Blake, "Definition of the 1909 Differentiated Services Field (DS Byte) in the IPv4 and IPv6 1910 Headers", Internet Draft, May 1998. 1912 [AF] J.Heinanen, _Assured Forwarding PHB Group_Internet Draft, 1913 August 1998. 1915 [EF] V.Jacobson, _Expedited Forwarding Per Hop Behavior_, 1916 Internet Draft, August 1998. 1918 Bernet, et al Expires: September 1999 35 1919 Draft-ietf-diffserv-framework-02.txt February, 1999 1921 [Ellesson] E. Ellesson and S. Blake, "A Proposal for the Format 1922 and Semantics of the TOS Byte and Traffic Class Byte in IPv4 and 1923 IPv6", Internet Draft, November 1997. 1925 [E2EQOS] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K. 1926 Nichols and M. Speer, "A Framework for the Use of RSVP with Diff- 1927 serv Networks", Internet Draft, November 1998. 1929 [DiffEdge] Y. Bernet, D. Durham and F. Reichmeyer, _Requirements 1930 of Diff-serv Boundary Routers_, Internet Draft, November 1998. 1932 [ROTZY] F. Reichmeyer, L. Ong, A. Terzis, L. Zhang, and 1933 R. Yavatkar, _A Two-Tier Resource Management Model for 1934 Differentiated Services Networks_, Internet Draft, November 1998 1936 [MPLS] B. Thomas, N. Feldman, P. Doolan, L. Andersson and 1937 A. Fredette, "Label Distribution Protocol Specification", Internet 1938 Draft, January 1999. 1940 [GBH97] R. Guerin, S. Blake, and S. Herzog, "Aggregating RSVP- 1941 based QoS Requests", Internet Draft, November 1997. 1943 [IntServ] R. Braden, D. Clark, and S. Shenker, "Integrated 1944 Services in the Internet Architecture: An Overview", Internet RFC 1945 1633, July 1994. 1947 [RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) -- 1948 Version 1 Functional Specification", Internet RFC 2205, September 1949 1997. 1951 [RFC791] Information Sciences Institute, "Internet Protocol", 1952 Internet RFC 791, September 1981. 1954 [RFC1349] P. Almquist, "Type of Service in the Internet Protocol 1955 Suite", Internet RFC 1349, July 1992. 1957 14. Author's Addresses 1959 Bernet, Yoram 1960 Microsoft 1961 One Microsoft Way 1962 Redmond, WA 98052 1963 Phone: +1 (425) 936-9568 1964 Email: yoramb@microsoft.com 1966 Bernet, et al Expires: September 1999 36 1967 Draft-ietf-diffserv-framework-02.txt February, 1999 1969 Binder, James 1970 3Com Corp. 1971 5400 Bayfront Plaza 1972 Santa Clara, CA 95052 1973 Phone: +1 (408) 326-6051 1974 Email: james_binder@3com.com 1976 Blake, Steven 1977 Torrent Networking Technologies 1978 3000 Aerial Center, Suite 140 1979 Morrisville, NC 27560 1980 Phone: +1-919-468-8466 x232 1981 Fax: +1-919-468-0174 1982 Email: slblake@torrentnet.com 1984 Carlson, Mark 1985 RedCape Software Inc. 1986 2990 Center Green Court South 1987 Boulder, CO 80301 1988 Phone: +1 (303) 448-0048 x115 1989 Email: mac@redcape.com 1991 Carpenter, Brian E 1992 IBM United Kingdom Laboratories 1993 MP185 1994 Hursley Park 1995 Winchester 1996 Hampshire SO21 2JN 1997 UK 1998 Phone: +44 1962 816833 1999 Email: brian@hursley.ibm.com 2001 Davies, Elwyn 2002 Nortel Networks 2003 London Road 2004 Harlow, Essex CM17 9NA, UA 2005 Phone: +44-1279-405498 2006 Email: elwynd@nortelnetworks.com 2008 Ohlman, Borje 2009 Ericsson Radio 2010 Dialoggatan 1 (Kungens Kurva) 2011 S-126 25 Stockholm 2012 Sweden 2013 Phone: +46-8-719 3187 2014 Email: Borje.Ohlman@ericsson.com 2016 Bernet, et al Expires: September 1999 37 2017 Draft-ietf-diffserv-framework-02.txt February, 1999 2019 Srinivasan Keshav 2020 4107B Uspon Hall 2021 Cornell University 2022 Ithaca, NY 14853 2023 Phone: +607-255-5395 2024 Email: skeshav@cs.cornell.edu 2026 Dinesh Verma IBM T. J. Watson Research Center 2027 P.O. Box 704 2028 Yorktown Heights, NY 10598 2029 Phone: +1 (914) 784-7466 2030 Email: dverma@watson.ibm.com 2032 Zheng Wang 2033 Bell Labs Lucent Tech 2034 101 Crawfords Corner Road 2035 Holmdel, NJ 07733 2036 Email: zhwang@bell-labs.com 2038 Walter Weiss 2039 Lucent Technologies 2040 300 Baker Avenue, Suite 100 Concord, MA 01742-2168 2041 Email: wweiss@lucent.com 2043 Bernet, et al Expires: September 1999 38