idnits 2.17.1 draft-ietf-diffserv-framework-01.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. 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 61 lines 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.) ** 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: ---------------------------------------------------------------------------- == Line 609 has weird spacing: '...mers of the w...' == Line 615 has weird spacing: '...es into the d...' -- 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? 'DSARCH' on line 1612 looks like a reference -- Missing reference section? 'DSHEAD' on line 1616 looks like a reference -- Missing reference section? 'BB' on line 1598 looks like a reference -- Missing reference section? 'AF' on line 1620 looks like a reference -- Missing reference section? 'EF' on line 1623 looks like a reference -- Missing reference section? 'MPLS' on line 955 looks like a reference -- Missing reference section? 'Elleson' on line 1140 looks like a reference -- Missing reference section? 'E2EQOS' on line 1630 looks like a reference -- Missing reference section? 'GBH97' on line 1634 looks like a reference -- Missing reference section? 'CLASSY' on line 1605 looks like a reference -- Missing reference section? 'CLARK' on line 1602 looks like a reference -- Missing reference section? 'COPS' on line 1609 looks like a reference -- Missing reference section? 'Ellesson' on line 1626 looks like a reference -- Missing reference section? 'IntServ' on line 1637 looks like a reference -- Missing reference section? 'RSVP' on line 1641 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Differentiated Services S.Blake, et al 2 Internet Draft October, 1998 3 Document: draft-ietf-diffserv-framework-01.txt 5 Yoram Bernet, Microsoft 6 James Binder, 3-Com 7 Steven Blake, Torrent Networking Technologies 8 Mark Carlson, Redcape Software 9 Srinivasan Keshav, Cornell University 10 Elwyn Davies, Nortel UK 11 Borje Ohlman, Ericsson 12 Dinesh Verma, IBM 13 Zheng Wang, Bell Labs Lucent Technologies 14 Walter Weiss, Lucent Technologies 16 A Framework for Differentiated Services 17 19 Status of this Memo 21 This document is an Internet Draft. Internet Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its Areas, 23 and its Working Groups. Note that other groups may also distribute 24 working documents as Internet Drafts. 26 Internet Drafts are draft documents valid for a maximum of six 27 months. Internet Drafts may be updated, replaced, or obsoleted by 28 other documents at any time. It is not appropriate to use Internet 29 Drafts as reference material or to cite them other than as a 30 "working draft" or "work in progress". 32 To learn the current status of any Internet-Draft, please check the 33 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 34 Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or 35 munnari.oz.au. 37 A revised version of this draft document will be submitted to the 38 RFC editor as a Proposed Standard for the Internet Community. 39 Discussion and suggestions for improvement are requested. This 40 document will expire before April, 1999. Distribution of this draft 41 is unlimited. 43 1. Abstract 45 This document provides a general description of issues related to 46 the definition, configuration and management of services enabled by 47 the differentiated services architecture [DSARCH]. This document 48 should be read along with its companion documents, the 49 differentiated services architecture [DSARCH] and the definition of 50 the DS field [DSHEAD]. A glossary of specialist terms used may be 51 found in [DSARCH]. 53 Blake, et al Expires: April 1999 1 54 Draft-ietf-diffserv-framework-01.txt October, 1998 56 2. Structure of this Draft 58 Section 3 defines Differentiated Services and explains the 59 motivation behind its deployment. Section 4 defines the concept of a 60 service and the components that comprise a service. Section 5 61 discusses several service examples. Section 6 examines intra-domain 62 provisioning, configuration and management issues. Section 7 63 examines inter-domain provisioning, configuration and management. 64 Section 8 addresses interoperability with Integrated Services and 65 RSVP. Section 9 discusses the interaction of differentiated services 66 with multicast and tunnelling. Section 10 addresses security 67 concerns. 69 3. Differentiated Services - Motivation and Definition 71 Traditionally, network service providers (both enterprise and 72 traditional ISPs) provide all customers with the same level of 73 performance (best-effort service). Most service differentiation has 74 been in the pricing structure (individual vs. business rates) or the 75 connectivity type (dial-up access vs. leased line, etc.). However, 76 in recent years, increased usage of the Internet has resulted in 77 scarcity of network capacity, compromising performance of 78 traditional, mission critical applications. At the same time, new 79 applications have emerged which demand much improved service 80 quality. As a result, service providers are finding it necessary to 81 offer their customers alternative levels of service. As well as 82 meeting new customer expectations, this allows service providers to 83 improve their revenues through premium pricing and competitive 84 differentiation of service offerings, which in turn can fund the 85 necessary expansion of the network. 87 The Differentiated Services architecture offers a framework within 88 which service providers can offer each customer a range of network 89 services which are differentiated on the basis of performance in 90 addition to pricing tiers used in the past. Customers request a 91 specific performance level on a packet by packet basis, by marking 92 the DS field of each packet with a specific value (see [DSHEAD] for 93 more details). This value specifies the Per-hop Behavior (PHB) to be 94 allotted to the packet within the provider's network. Typically, the 95 customer and provider negotiate a profile (policing profile) 96 describing the rate at which traffic can be submitted at each 97 service level. Packets submitted in excess of this profile may not 98 be allotted the service level requested. A salient feature of 99 differentiated services is its scalability, which allows it to be 100 deployed in very large networks. This scalability is achieved by 101 forcing as much complexity out of the core of the network into edge 102 devices which process lower volumes of traffic and lesser numbers of 103 flows, and offering services for aggregated traffic rather than on a 104 per-micro-flow basis. 106 Blake, et al Expires: April 1999 2 107 Draft-ietf-diffserv-framework-01.txt October, 1998 109 4. Services 111 [DSARCH] defines a Service as "the overall treatment of a defined 112 subset of a customer's traffic within a DS-domain, or end-to-end". 113 Although PHBs are at the heart of the differentiated services 114 architecture, it is the service obtained as a result of marking 115 traffic for a specific PHB, which is of value to the customer. PHBs 116 are merely building blocks for services. Service providers combine 117 PHB implementations with traffic conditioners, provisioning 118 strategies and billing models which enable them to offer services to 119 their customers. Providers and customers negotiate agreements with 120 respect to the services to be provided at each customer/provider 121 boundary. These take the form of Service Level Agreements (SLAs). 123 Bear in mind when considering the services that are offered in a DS- 124 domain that: 125 * DS services are all for unidirectional traffic only 126 * DS services are for traffic aggregates, not individual micro-flows 128 4.1 Customer/Provider Boundaries 130 Present day network traffic generally traverses a concatenation of 131 networks which may include hosts, home or office networks, campus or 132 corporate networks and several large transit networks. Home and 133 office networks are typically customers of campus or corporate 134 networks, which are in turn customers of large transit networks. 135 While one would expect the initial deployment of differentiated 136 services to be within large transit networks, its deployment may 137 also be extended to the smaller campus and corporate networks and in 138 special cases, all the way to individual hosts. As such, there may 139 be numerous customer/provider boundaries at which the concept of a 140 'service' applies. 142 4.2 SLAs and TCAs 144 At each differentiated service customer/provider boundary, the 145 service provided is defined in the form of an SLA. The SLA is a 146 contract which specifies the overall features and performance which 147 can be expected by the customer. Because DS services are 148 unidirectional the two directions of flow across the boundary will 149 need to be considered separately. An important subset of the SLA is 150 the traffic conditioning agreement, or TCA. The TCA specifies 151 detailed service parameters for each service level. Such parameters 152 include: 153 1. Detailed service performance parameters such as expected 154 throughput, drop probability, latency. 155 2. Traffic profiles which must be adhered to for the requested 156 service to be provided, such as token bucket parameters. 158 Blake, et al Expires: April 1999 3 159 Draft-ietf-diffserv-framework-01.txt October, 1998 161 3. Disposition of traffic submitted in excess of the specified 162 profile. 163 4. Marking services provided. 164 5. Shaping services provided. 166 In addition to the details in the TCA, the SLA may specify more 167 general service characteristics such as: 168 1. Availability/Reliability, which may include behavior in the event 169 of failures resulting in rerouting of traffic 170 2. Encryption services 171 3. Routing constraints 172 4. Authentication mechanisms 173 5. Mechanisms for monitoring and auditing the service 174 6. Responsibilities such as location of the equipment and 175 functionality, action if the contract is broken, support 176 capabilities 177 7. Pricing and billing mechanisms 179 These additional characteristics are important, and in the case of 180 pricing and billing, fundamental to the service offering but they do 181 not affect the service itself and are not considered further here. 183 4.3 Service Taxonomy: Quantitative through Qualitative and alternatives 185 The Differentiated Services architecture can support a broad 186 spectrum of different kinds of service. Categorizing these services 187 provides some constraints on the corresponding SLAs that can be 188 offered for the service. 190 Some services can be clearly categorized as qualitative or 191 quantitative depending on the type of performance parameters 192 offered. Examples of qualitative services are as follows: 193 1. Traffic offered at service level A will be delivered with low 194 latency. 195 2. Traffic offered at service level B will be delivered with low 196 loss. 198 The assurances offered in examples 1 and 2 are relative and can only 199 be verified by comparison. 201 Examples of quantitative services are as follows: 202 3. 90% of in profile traffic delivered at service level C will 203 experience no more than 50 msec latency. 204 4. 95% of in profile traffic delivered at service level D will be 205 delivered. 207 Examples 3 and 4 both provide concrete guarantees that could be 208 verified by suitable measurements on the example service 209 irrespective of any other services offered in parallel with it. 211 Blake, et al Expires: April 1999 4 212 Draft-ietf-diffserv-framework-01.txt October, 1998 214 There are also services which are not readily categorized as 215 qualitative or quantitative as in the following examples: 216 5. Traffic offered at service level E will be allotted twice the 217 bandwidth of traffic delivered at service level F. 218 6. Traffic with drop precedence AF12 has a lower probability of 219 delivery than traffic with drop precedence AF13. 221 In example 5, the provider is quantifying the relative benefit of 222 submitting traffic at service level E vs. service level F, but the 223 customer cannot expect any particular quantifiable throughput. This 224 can be described as a `Relative Quantification Service'. 226 In general, when a provider offers a quantitative service, it will 227 be necessary to specify quantitative policing profiles. In many 228 cases, quantitative policing profiles will be specified even for 229 services that do not offer quantitative performance. 231 Determining how to monitor and audit the delivery of a qualitative 232 or relative quantification service in such a way as to convince the 233 user that he has received fair measure requires careful attention. 234 It will be up to the customer to determine if the advantage offered 235 is sufficient to make the service worthwhile. The SLA must clearly 236 avoid making quantitative commitments for these services. 238 4.4 The Scope of a Service 240 The scope of a service refers to the topological extent over which 241 the service is offered. For example, assume that a provider offers a 242 service to a customer which connects to their network at ingress 243 point A. The service may apply to: 244 1. all traffic from ingress point A to any egress point 245 2. all traffic between ingress point A and egress point B 246 3. all traffic from ingress point A to a set of egress points 248 Egress points may be in the same domain as the ingress point or may 249 be in other domains which are either directly or indirectly 250 connected to the ingress domain. If the egress point is in another 251 domain, it will be necessary for the ingress provider to negotiate 252 SLAs with the relevant peer domains, which will recursively 253 negotiate with their peers to ensure that the service offered at 254 ingress point A can indeed be extended to the egress points 255 specified. The scope of a service is part of the SLA governing 256 ingress point A. 258 Blake, et al Expires: April 1999 5 259 Draft-ietf-diffserv-framework-01.txt October, 1998 261 In general, providers will be able to offer quantitative services 262 most efficiently when a specific set of egress points is specified. 263 Quantitative services which span multiple domains also require 264 tighter coupling between the SLA offered to the customer at ingress 265 point A and the SLAs negotiated with intermediate domains. 266 Qualitative services can more readily be offered to arbitrary sets 267 of egress points and require looser coupling between the SLA at 268 ingress point A and SLAs at intermediate domain boundaries. 270 4.4.1 Services Governing Received Traffic 272 A special case of service scope is a service that governs all 273 traffic between any ingress point and egress point B. The SLA that 274 defines this service would be at egress point B and would 275 effectively allow the customer to control the mix of traffic 276 received from the provider. While such a service is theoretically 277 possible, it conflicts with the more traditional use of diffserv 278 which governs the quality with which traffic is sent, rather than 279 received. 281 A number of concerns would have to be addressed by such a service, 282 including: 283 Traffic going to point B from an ingress point A under the terms 284 of the SLA of this service may also be governed by an SLA for 285 traffic submitted at point A. The SLAs may conflict and it will 286 not, in general, be possible to resolve all such conflicts across 287 all the ingress points. 288 - Establishing a traffic profile for this service at every possible 289 ingress which prevents overload of the receiver can be more 290 complex than for other service scopes: Static profiles are likely 291 to be either inefficient (e.g. dividing the egress profile into 292 fixed proportions) or risky (e.g. allowing every ingress to send 293 the whole profile) whilst dynamic profiles require processes and 294 communication mechanisms to coordinate the settings. 295 - Without effective ingress profiles for the service, denial of 296 service attacks will be a serious problem. 298 Some of the characteristics of receiver oriented services can be 299 provided by local policies and the SLA for the domain to which 300 traffic is sent via the egress point as described in Sec. 4.6.4. 302 Blake, et al Expires: April 1999 6 303 Draft-ietf-diffserv-framework-01.txt October, 1998 305 4.5 Dynamic vs. Static SLAs 307 SLAs may be static or dynamic. Static SLAs are the norm at the 308 present time. These are instantiated as a result of negotiation 309 between human agents representing provider and customer. A static 310 SLA is first instantiated at the agreed upon service start date and 311 may periodically be renegotiated (on the order of days or weeks or 312 months). The SLA may specify that service levels change at certain 313 times of day or certain days of the week, but the agreement itself 314 remains static. 316 Dynamic SLAs, on the other hand, may change frequently. Such changes 317 may result for example, from variations in offered traffic load 318 relative to preset thresholds or from changes in pricing offered by 319 the provider as the traffic load fluctuates. Dynamic SLAs change 320 without human intervention and thus require an automated agent and 321 protocol, in effect, a bandwidth broker to represent the 322 differentiated service provider's domain (such as suggested in 323 [BB]). 325 Dynamic SLAs also present challenging problems to both end users and 326 network providers: 327 - Network providers have to balance frequently changing loads on 328 different routes within the provider network. This requires the 329 provider to adopt dynamic, automated resource provisioning 330 mechanisms rather than relying on static provisioning. 331 - Customer equipment will have to adapt to dynamic SLAs in order to 332 make the most out of the changing SLA. 333 - End user applications may have to adapt their behavior during a 334 session to make the most of (or even, cope with) dynamic SLAs. 336 It is worth reiterating that the SLAs in Differentiated Services 337 apply to aggregates of traffic and not individual flows. For 338 scalability, it is undesirable to envisage modifying an SLA every 339 time a new micro-flow is added or removed from an aggregate. 341 4.6 Provisioning Traffic Conditioners in Boundary Devices to Provide 342 Services 344 Once an SLA has been negotiated, the service provider (and 345 optionally the customer) will configure traffic conditioning 346 components at the boundary between the two networks. The service 347 provider does so with the goal of protecting the provider's network 348 such that the resources granted to the customer meet but do not 349 exceed the terms of the TCA. The customer does so with the goal of 350 making the best use of the service purchased from the provider. In 351 this section, we will briefly describe configuration of traffic 352 conditioners in boundary devices. 354 Blake, et al Expires: April 1999 7 355 Draft-ietf-diffserv-framework-01.txt October, 1998 357 Note that the provider's self interests require only that the 358 provider identify 359 - for which service level specific traffic is submitted, 360 - by which customer it is submitted, and 361 - for traffic with double-ended SLAs (i.e. SLA scope is type 2 or 3 362 of Sec. 4.4) only, the destination address to which the traffic 363 is directed. 365 Customer traffic may be authenticated either by the physical 366 connection on which it arrives or by some sophisticated 367 cryptographic means which is beyond the scope of this draft. The 368 provider need not be concerned with the customer's individual micro- 369 flows in delivering basic Differentiated Services (see Sec. 4.6.3 370 for additional services). 372 [DSARCH] identifies four traffic conditioning components: 373 1. Meters 374 2. Markers 375 3. Shapers 376 4. Droppers 378 The combination and interaction of the traffic conditioning 379 components is selected on a packet-by-packet basis by the DS 380 codepoint. The configuration parameters for the components at each 381 codepoint are determined by the policies and profiles applied, so 382 that the conditioner polices the traffic in the BA specified by the 383 codepoint. Meters measure submitted traffic for conformance to a 384 profile, providing control input for the other components which 385 implement the policing: 386 - Shapers police by delaying submitted traffic such that it does 387 not exceed the traffic rate specified in a profile. 388 - Droppers police by dropping traffic that is submitted at a rate 389 exceeding that specified in a profile. 390 - Markers police by re-marking the traffic with a different 391 codepoint either 392 - to demote out-of-profile traffic to a different PHB, 393 - as a result of an SLA which specifies codepoint mutation, or 394 - to ensure that only valid codepoints are used within the 395 domain. 397 In addition to these four components, traffic classifiers are 398 required in order to separate submitted traffic into different 399 classes. Classifiers may separate traffic based only on the DS-field 400 of submitted packets (BA classifiers) or may do so based on multiple 401 fields within the packet header and even the packet payload (MF 402 classifiers). MF classifiers may be used at boundaries to provide 403 certain per-micro-flow services to customers. Examples of such 404 services include per-flow marking or shaping. Typically, traffic 405 will arrive at the boundary of a DS domain pre-marked and 406 pre-shaped. However, at interfaces with some non-DS customer 408 Blake, et al Expires: April 1999 8 409 Draft-ietf-diffserv-framework-01.txt October, 1998 411 networks, it is possible that traffic will require marking and 412 shaping. 414 Even if a customer has pre-marked and pre-shaped, the service 415 provider will wish to police the traffic at the ingress boundary to 416 meet the domain's self-interests. This may result in traffic being 417 re-marked or dropped. 419 Traffic conditioning components (in particular, meters) will also be 420 the primary source of billing information for a differentiated 421 Services network. 423 4.6.1 Minimal Functionality at Provider's Ingress 425 At the very least, the service provider must limit traffic carried 426 on behalf of the customer to the constraints specified in the TCA. A 427 simplified TCA can be represented in the form of a table wherein 428 each row has the format: 430 DS-Mark : Profile : Disposition of non-conforming traffic 432 This row indicates that the provider commits to carry traffic marked 433 with 'DS-Mark' at the corresponding service level, provided that it 434 conforms to the 'Profile'. Traffic that is submitted with 'DS-Mark' 435 and which does not conform to the 'Profile', is subjected to 436 'Disposition of non-conforming traffic'. This is generally a 437 policing action such as re-marking to a lower service level, 438 delaying in a shaper, or dropping. Alternatively, it may be carried 439 at the requested service level, but subjected to a surcharge. The 440 SLA for this type of service would normally be expected to be of 441 type 1 of Sec. 4.4.1, where the traffic destination can take it 442 through any egress point of the domain. 444 To provide this minimal functionality, the provider must configure a 445 BA classifier to separate traffic into the different service level 446 requested, based on DS-Mark. Following the BA classifier, each class 447 must be metered for conformance to the corresponding profile. 448 Following the profiler, either a dropper, shaper or re-marker is 449 likely to be employed. The Better than Best Efforts service 450 described in Sec. 5.1 is an example of a service for which this 451 functionality is sufficient. 453 4.6.2 Functionality at Provider's Ingress for Double-ended SLAs 455 If quantitative or other services needing double-ended SLAs (types 2 456 and 3 of Sec. 4.4.1) are implemented in a DS Domain, these services 457 specify the possible egress port(s) for traffic conforming to the 458 SLA. The traffic conditioner needs to consider the destination 459 address of the packet as additional input to the policing process, 460 so that traffic is not accepted for egress ports for which an SLA 461 does not exist. The Virtual Leased Line service described in 463 Blake, et al Expires: April 1999 9 464 Draft-ietf-diffserv-framework-01.txt October, 1998 466 Sec. 5.2 is an example of a service that would require this 467 functionality. 469 A QoS VPN can be constructed by provisioning multiple instances 471 o 472 f 473 services of type 2, building in effect, a mesh of point to point QoS 475 links. 477 Services of type 3 are most likely to be used for multicast 478 applications (see Sec. 9). 480 4.6.3 Added Value Functionality at Provider's Ingress 482 The functionality described in Secs. 4.6.1 and 4.6.2 serves only to 483 protect the provider's network resources in line with the terms of 484 the TCA. It provides no assistance to the customer. The burden of 485 marking packets and shaping traffic falls entirely on the customer. 486 In some cases, the SLA may call for the provider to provide 487 additional services to the customer. Such services may include: 488 1. Marking traffic from specific micro-flows to a specific behaviour 489 aggregate (marking the DS-field). 490 2. Policing traffic from specific micro-flows or sets of micro- 491 flows, either in the form of dropping or shaping. 493 In order to provide such services, the provider must generally 494 employ an MF classifier in addition to the BA classifier. The need 495 for an MF classifier arises only when the customer requires the 496 provider to provide some form of traffic separation or 497 authentication on behalf of the customer. The provider may charge 498 dearly for these services depending on the degree of granularity and 499 the amount of work required. For example, shaping thousands of 500 customer micro-flows might consume considerable resources in the 501 provider's edge device. On the other hand marking based on source 502 subnet addresses would consume considerably fewer resources. 504 4.6.4 Functionality at Customer's Egress 506 Strictly speaking, the customer need not apply any specific traffic 507 conditioning. In this case, the customer relies on the provider to 508 mark as per negotiated MF classification criteria. In many cases it 509 is preferable for the customer to mark. Customer marking may be 510 necessary when customer packets are encrypted (as in the case of 511 end-to-end IPSec). Customer marking enables the customer to direct 512 specific traffic from specific users or applications to specific 513 service classes. This may be difficult or impossible for a provider 514 to do on behalf of a customer when, for example, applications use 515 volatile ports and users are assigned IP addresses based on DHCP. 517 In addition to marking, it is in the customer's best interest to at 518 least shape per service level, at the customer network's egress 519 point. Otherwise, customer traffic may be policed by the service 521 Blake, et al Expires: April 1999 10 522 Draft-ietf-diffserv-framework-01.txt October, 1998 524 provider with undesirable consequences (e.g. dropped packets). 525 Shaping per service level does not however, provide for micro-flow 526 traffic separation. As a consequence, a renegade traffic source may 527 cause the profile to be exceeded for a specific service level, 528 negatively impacting all customer flows which are marked for that 529 service level. Therefore, it is often in the customer's interest to 530 shape or at least to police, with micro-flow granularity. 532 4.6.5 Functionality at Provider's Egress 534 At the egress from a provider's domain there may be an SLA in place 535 with a peer DS domain, which might be either another provider or an 536 end user domain. As in Sec. 4.6.4, it is in the provider's best 537 interests to shape the traffic leaving the domain. 539 Depending on the SLA, the egress may be required to remark and/or 540 police or shape the traffic. Note that the forwarding treatment 541 applied to the packet in the egress node of the domain would be that 542 selected by the codepoint before it was remarked (otherwise, the 543 egress node has to support multiple codepoint to PHB mappings). 545 The provider may also wish to offer additional services to a 546 customer by policing egress traffic with micro-flow granularity if 547 the customer might expect to receive excessive traffic in a single 548 BA and wishes to apply greater control than could be achieved by 549 normal policing of the aggregate. This would be specified via an 550 SLA in the usual way. 552 4.7 Internal Provisioning 554 The provider must provision internal nodes in the provider network 555 to meet the assurances offered by SLAs negotiated at the boundaries 556 of the network. To do so, the provider may use similar traffic 557 conditioning mechanisms to those used at the network boundaries. 558 However, providers are unlikely to apply MF classification within 559 the interior of the network. The provider may police periodically 560 within the network, by reshaping, remarking or discarding traffic. 561 Service providers are experienced in provisioning large networks 562 which offer uniform service, assisted by predictive tools, traffic 563 modeling tools and real time measurements. Current techniques will 564 likely be applied to differentiated services networks, although, the 565 complexity of provisioning will increase significantly. In a 566 differentiated service network, the provider must ensure that 567 resources granted to traffic of one service level does not 568 inappropriately compromise assurances regarding traffic at other 569 service levels (for example, in example service 6, traffic in AF13 570 can legitimately compromise traffic in AF11 if an increase in AF13 571 traffic causes more AF11 traffic to be dropped). As mentioned 572 previously, internal provisioning in the case of dynamic SLAs will 573 likely require dynamic resource allocation protocols. 575 Blake, et al Expires: April 1999 11 576 Draft-ietf-diffserv-framework-01.txt October, 1998 578 4.8 End-to-End Service Construction 580 The Differentiated Services architecture proposes that an end-to-end 581 service can be constructed by the concatenation of domain services 582 and their associated customer-provider SLAs for each of the domains 583 which the service traffic has to cross. 585 Clearly, not all PHBs and services can be meaningfully concatenated, 586 and the definition of suitable services and their associated PHBs 587 will be a major focus of future Differentiated Services development. 588 This is discussed at greater length in Sect. 7. 590 5. Service Examples 592 In this section, we describe service examples and show how they can 593 be supported by specific PHBs. We base these examples on PHBs which 594 are defined in [AF]and [EF]. These examples are intended to be 595 illustrative of the wide range of services that can be employed 596 using the differentiated services model, and are not intended to be 597 an exhaustive list. 599 5.1 Better than Best-Effort (BBE) Service 601 This is a qualitative service which promises to carry specific web 602 server traffic at a higher priority than competing best-effort 603 traffic. Such a service offers relatively loose (not quantifiable) 604 performance from a given ingress point to any egress point. Such a 605 service is suitable for example for businesses offering access to 606 web based content. The BBE service enables the web content provider 607 to provide content at a generally higher rate than other content 608 providers are able to, in so reducing the latency experienced by 609 consumers of the web site. 611 5.1.1 Service Implementation 613 In this example, we assume that there is an SLA which defines the 614 service at the customer's ingress point. This is the point at which 615 the customer injects web server responses into the differentiated 616 services network. The information in the TCA can be represented in 617 the following form [AF]: 619 AF13 Mark : 1 Mbps : Any egress point : Excess traffic handled by 620 marking with AF11 mark. 622 Packets submitted for the BBE service should be marked with the DS- 623 field codepoint corresponding to the AF13 PHB. The provider is 624 promising to carry up to 1 Mbps of traffic from the ingress point to 625 any egress point at a higher priority than best-effort traffic. A 626 lesser class of service corresponding to the AF11 PHB will be 627 applied to traffic submitted for the AF13 PHB, in excess of 1 Mbps. 629 Blake, et al Expires: April 1999 12 630 Draft-ietf-diffserv-framework-01.txt October, 1998 632 The provider will provision a policer at the ingress point. Traffic 633 submitted up to the 1 Mbps limit will be directed to the AF13 PHB. 634 Traffic submitted in excess of 1 Mbps will be remarked for the AF11 635 PHB. Note that the scheme will preserve ordering of packets since 636 AF13 and AF11 use a single queue.. 638 In order to provide this service, the provider will have to 639 implement the AF13 and AF11 PHBs in core network equipment. The AF13 640 and AF11 PHBs can be implemented for example, using a single RIO 641 queue. The provider will also have to provision equipment within the 642 core of the provider's network to provide the AF13/AF11 service. By 643 provisioning the appropriate RED parameters, for example, the 644 provider is able to control the priority of AF13 traffic relative to 645 AF11 traffic at each network node. Since there are no quantitative 646 guarantees, the provider can be quite liberal in its provisioning 647 strategy and may realize significant statistical multiplexing gains. 648 Also, the absence of quantitative guarantees makes it easy to 649 provide this type of service across multiple DS provider domains. 650 This is because is not necessary to negotiate, then provision and 651 enforce quantitative guarantees at multiple boundaries. 653 5.2 Leased Line Emulation Service 655 This is a quantitative service which emulates traditional leased 656 line service. As such, it promises to deliver customer traffic with 657 very low latency and very low drop probability, up to a negotiated 658 rate. Above this rate, traffic is dropped. Such a service is 659 typically offered between two specific points. It is suitable for 660 many customer applications. However, due to the high quality 661 guarantees, it is likely to be priced higher than alternate services 662 and therefore, to be used only for applications which really require 663 this type of service. An example of such an application is IP 664 telephony. A corporate customer might purchase leased line emulation 665 service between each pair of a number of corporate network sites. 667 5.2.1 Service Implementation 669 In this example, we consider a customer with three geographically 670 dispersed networks interconnected via a single provider network. 671 Customer attachment points are represented as A, B and C. At each 672 attachment point, an SLA describes the leased line service to be 673 provided to the other two points. The table below represents the 674 information required in the TCA at attachment point A: 676 EF-Mark : 100 Kbps : Egress point B : Discard non-conforming traffic 678 EF-Mark : 50 Kbps : Egress point C : Discard non-conforming traffic 680 Packets submitted for leased line service should be marked with the 681 DS-field codepoint corresponding to the EF PHB [EF]. From the 682 ingress point A, to the egress point B, the provider is promising to 684 Blake, et al Expires: April 1999 13 685 Draft-ietf-diffserv-framework-01.txt October, 1998 687 carry up to 100 Kbps of traffic. Excess traffic will be discarded. 688 From ingress point A, to egress point C, the provider promises to 689 carry 50 Kbps of traffic. Of course, there is some tolerance 690 required in policing the traffic and thus, there may be a 691 specification of tolerated jitter or burst size. However, for a 692 leased line service, the primary traffic profile parameter would be 693 the sustained traffic rate. 695 The provider will provision a policer at ingress point A to limit 696 traffic destined for egress point B, to 100 Kbps. Similarly, a 697 policer will be configured to limit traffic destined for egress 698 point C, to 50 Kbps. These policers will require classification 699 based on the DS-Mark and the destination address in each packet. 701 In order to provide this service, the provider will have to 702 implement the EF PHB in core network equipment. The EF PHB can be 703 implemented using strict priority queuing or alternatively, by 704 assigning EF marked packets to a heavily weighted queue in a WFQ 705 scheme. The provider will have to provision equipment within the 706 core of the provider's network. For example, routers carrying 707 traffic between point A and points B and/or C will have to be 708 provisioned considering the resources committed by the TCA at point 709 A. This means that a router which is both in the path from A to B 710 and from A to C, will have to be considered to have committed 150 711 Kbps of bandwidth as a result of the TCA in place at A. A router 712 that is only in the path from A to B, will have to be considered to 713 have committed 100 Kbps as a result of this TCA, and so on. Of 714 course, routing is subject to change and so, failover paths may have 715 to be provisioned as well. These may be provisioned to provide some 716 fraction of the service in the case of failover or alternatively, 717 the SLA at point A might reflect appropriate service availability 718 parameters. To enhance the assurances offered by EF service, 719 providers may employ route pinning mechanisms or QoS routing 720 mechanisms. 722 5.3 Quantitative Assured Media Playback Service 724 This service offers looser assurances than the leased line service 725 described above, but is still considered a quantitative service. In 726 particular, it promises to deliver traffic with a high degree of 727 reliability and with variable but bounded latency, up to a 728 negotiated rate. Above this rate, traffic is subject to significant 729 delay or drop. Such a service is typically offered between a 730 specific set of points. It is suitable for many customer 731 applications. It would likely be priced lower than a leased line 732 service, due to the latency variability. However, due to the latency 733 bound and high degree of delivery, it is likely to be priced higher 734 than alternate services. This service is particularly suitable for 735 video or audio playback, in which considerable bandwidth is required 736 on a continual basis, but the non-interactive nature of the traffic 737 makes it somewhat delay tolerant. 739 Blake, et al Expires: April 1999 14 740 Draft-ietf-diffserv-framework-01.txt October, 1998 742 5.3.1 Service Implementation 744 In this example, we again consider a customer with three 745 geographically dispersed networks interconnected via a single 746 provider network. The table below represents the information 747 required in the TCA at attachment point A: 749 AF13-Mark : 100 Kbps sustained, 100 Kb bursts tolerated at up to 200 750 Kbps : Egress point B : Excess burst traffic over sustained rate 751 marked with AF12-mark : Non-conforming traffic marked with AF11-mark 752 : Max latency = 1 second 754 AF13-Mark : 50 Kbps sustained, 100 Kb bursts tolerated at up to 100 755 Kbps : Egress point C : Excess burst traffic over sustained rate 756 marked with AF12-mark : Non-conforming traffic marked with AF11-mark 757 : Max latency = 2 seconds 759 Packets submitted for the assured playback service should be marked 760 with the DS-field codepoint corresponding to the AF13 PHB. From the 761 ingress point A, to the egress point B, the provider is promising to 762 carry up to 100 Kbps of sustained traffic with bursts of 100 Kb in 763 size at a peak rate of 200 Kbps. Excess burst traffic will be marked 764 with the codepoint for AF12 and out of profile traffic will be 765 carried but with the AF13 codepoint. So long as these conditions are 766 met, latency will be limited to 1 second. Note that for this 767 service, the traffic profile is described using a full set of token 768 bucket parameters. Since the latency bounds for such a service are 769 less strict than those required for the leased line service, a 770 certain degree of traffic burstiness can be tolerated. 772 The provider must support the AF11, AF12 and AF13 PHBs in core 773 network routers. These PHBs might be provided, for example, by 774 assigning AF11, AF12 and AF13 marked traffic to a single RIO queue 775 with high drop thresholds. The policers at the edge would limit 776 competing traffic in line with the TCA, in order to assure that the 777 latency bounds can be met. In addition, the service provider will 778 have to provision devices in the core of the network. The 779 provisioning considerations discussed in the context of the leased 780 line service apply here as well, however, in general, the service 781 provider has the liberty of being less conservative in provisioning 782 and realizing better statistical gains. 784 5.4 Superposition of Quantitative and Qualitative Services in the Same 785 Network 787 A compelling model would provide both quantitative and qualitative 788 services in the same differentiated service network(s) as follows. A 789 number of corporate campus networks would be interconnected by a 790 differentiated service network providing quantitative services 791 between the sites. For example, a mesh of leased line services would 793 Blake, et al Expires: April 1999 15 794 Draft-ietf-diffserv-framework-01.txt October, 1998 796 enable IP telephony between the sites. A mesh of media playback 797 service using the AF11 PHB would enable audio/video playback between 798 the sites. In addition, each corporate site would be allotted some 799 level of BBE service to arbitrary destinations. In this model, the 800 differentiated service network is effectively providing a mesh of 801 quantitative services between fixed locations (similar to a VPN). 802 This mesh is superimposed on a cloud supporting BBE service. 804 6. Provisioning and Configuration 806 The provision of differentiated services requires careful network 807 wide provisioning and configuration. Provisioning refers to the 808 determination and allocation of the resources needed at various 809 points in the network. Provisioning may dictate the addition or 810 removal of physical resources at various points (physical 811 provisioning). Provisioning may also dictate the modification of 812 operating parameters within existing physical network equipment to 813 alter the relative share of the equipment's resources which are 814 allotted to one or another class of traffic (logical provisioning). 815 Configuration refers to the distribution of the appropriate 816 operating parameters to network equipment to realize the 817 provisioning objectives. 819 In Secs. 4.6 and 4.7, we briefly discussed provisioning and 820 configuration requirements both at the network boundaries and in the 821 network interior. In this section we will focus primarily on the 822 coordination of provisioning and configuration throughout the 823 network, such that end-to-end services can be provided reliably. We 824 will discuss the roles of protocols such as SNMP, CLI, RSVP, COPS 825 and LDAP in the provisioning process. 827 6.1 Boundary vs. Interior Provisioning and Configuration 829 For the sake of brevity, consider the term 'provisioning' to refer 830 both to provisioning and configuration, except where otherwise 831 noted. It is helpful to consider provisioning at the network 832 boundaries, separately from provisioning of the interior. Since the 833 differentiated service provider is selling a contract (SLA) at the 834 network boundary, we can consider the boundary provisioning which 835 supports SLAs, to drive the interior provisioning. The two are not 836 entirely separable in that each affects the other. For example, a 837 network operator cannot offer an SLA which cannot be met by the 838 resources available in the interior of the network. In general, the 839 overall provisioning process iterates between the boundaries and the 840 interior. From here on we will refer to provisioning with respect to 841 the TCA rather than the SLA, since the TCA is the component of the 842 SLA that defines detailed traffic handling parameters. 844 Blake, et al Expires: April 1999 16 845 Draft-ietf-diffserv-framework-01.txt October, 1998 847 6.1.1 Boundary Provisioning 849 Boundary provisioning was considered briefly in Sec. 2.6. We 850 discussed the minimal provisioning that a provider must implement to 851 enforce a TCA. We also discussed additional configuration which a 852 provider may use to provide additional (especially per-flow) 853 services to a customer. The latter is not actually related to the 854 provisioning of resources within the differentiated services 855 network, but rather assists the customer by determining which 856 subsets of the customer's traffic make use of the resources 857 provisioned within the differentiated services network. As such, it 858 is out of the scope of this section. Here, we consider only the 859 minimal provisioning required at the boundary. 861 At a minimum, the provider must assure that sufficient physical 862 resources are provisioned at the boundary to meet the requirements 863 of the TCA. For example, if the sum of the profiles supported at a 864 particular ingress point would allow 10 Mbps of traffic to be 865 supported, it is unacceptable to provision a T-1 access link. A T-3 866 however, would be sufficient. Once the physical provisioning is 867 implemented, it is necessary to apply the appropriate logical 868 provisioning. This is achieved by configuring policers which limit 869 the amount of traffic accepted from the T-3 access link, at each 870 service level. It may also be necessary to set up the amount of 871 buffering available for the queues used for the service. Similar 872 provisioning is also appropriate at each egress point if the 873 aggregate of profiles provisioned to the egress exceeds the capacity 874 of the output link. 876 6.1.2 Interior Provisioning 878 For the purpose of provisioning the interior of the network, it is 879 desirable to understand or to control the volume of traffic of each 880 class which traverses each network node. The greater this 881 understanding, the more efficiently the network can be provisioned 882 while still meeting the requirements of the TCAs. It is feasible to 883 understand the volume of traffic traversing each node if this 884 traffic is admitted according to a TCA which dictates egress point 885 as well as ingress point. (This case generally applies to 886 quantitative services and was discussed in the context of the EF PHB 887 and the leased line service in Sec. 3.2.1). While traffic volumes 888 cannot be anticipated with 100% accuracy, it is possible to 889 approximate them quite well, especially with the help of route 890 pinning mechanisms. It is therefore possible to provision the 891 network reasonably accurately for traffic submitted for quantitative 892 services. Although such provisioning may be quite difficult in a 893 large network, it is nonetheless a tractable problem. We will refer 894 to this component of the provisioning problem as quantitative 895 provisioning. 897 Blake, et al Expires: April 1999 17 898 Draft-ietf-diffserv-framework-01.txt October, 1998 900 On the other hand, many (if not most) of the services offered by 901 differentiated service networks will not specify egress points (as 902 is the case for qualitative services) and will not restrict 903 submitted traffic to specific egress points, let alone specific 904 routes. Thus, interior nodes will have to be provisioned without an 905 a-priori understanding of the volume of traffic submitted for 906 qualitative services which will arrive at each node. It is necessary 907 to be able to provision differentiated service networks to support 908 both quantitative services with specific egress points as well as 909 qualitative services, which do not have specific egress points on 910 the same physical resources. To this end, it is necessary to isolate 911 the impact of qualitative traffic on the resources reserved for 912 quantitative traffic. This can only be achieved if the former is 913 treated with lower priority than the latter. Thus, in general, 914 resources will have to be provisioned first for quantitative 915 traffic, using quantitative provisioning mechanisms. Then, 916 qualitative provisioning can be used to allocate remaining resources 917 to qualitative traffic. Qualitative provisioning can also be 918 applied to services which offer a relative quantification of traffic 919 volumes. 921 The impact of the two types of traffic will have to be isolated by 922 ensuring that they do not share PHB codepoints. PHBs used for 923 quantitative services will always have higher priority access to 924 resources than those used for qualitative services. As a result, it 925 is necessary to carefully police traffic submitted for quantitative 926 PHBs. Failure to do so can result in the starvation of lower 927 priority traffic. In general it can be expected that only a small 928 fraction of the resources at each node will be provisioned for 929 quantitative traffic. 931 Similarly, a significant fraction of the traffic capacity should 932 remain for best-efforts service to provide a 'soft' target for 933 traffic dropping if congestion occurs or it is necessary to redirect 934 non-best efforts traffic in the event of failure. 936 6.1.2.1 Quantitative Provisioning of the Interior 938 As discussed previously, quantitative provisioning is a difficult 939 but tractable problem. With knowledge of the network routing 940 topology and the TCAs at the boundaries, it is possible to compute 941 the resources required at each interior node to carry the 942 quantitative traffic offered at the edges. Based on the results of 943 this computation, interior nodes must be provisioned and configured 944 with sufficient capacity to accommodate the quantitative traffic 945 which will arrive at the node, while leaving sufficient capacity 946 remaining to accommodate some amount of qualitative traffic. 948 The provisioning mechanism described assumes a top-down approach, in 949 which the network administrator studies the network topology and 950 traffic routing and computes the provisioning requirements. An 952 Blake, et al Expires: April 1999 18 953 Draft-ietf-diffserv-framework-01.txt October, 1998 955 alternative approach uses signalling to automate the process [MPLS]. 956 For example, RSVP messages could be launched along the paths that 957 will be followed by submitted quantitative traffic. If a TCA calls 958 for 100 Kbps of leased-line service from ingress point A to egress 959 point B, an RSVP message could be transmitted from point A towards 960 point B, with a flowspec specifying 100 Kbps. This message would 961 traverse each node at which resources would have to be committed. 962 Conventional RSVP routers would install a reservation. In a 963 differentiated service network, RSVP could be adapted to provision 964 the resources required per the differentiated services model. In a 965 network which offers a number of static TCAs, such RSVP messages 966 could be launched from the TCA ingress point at the time the TCA is 967 initially instantiated with the effect of instantiating the 968 appropriate cumulative provisioning in routers along the various 969 routes. The advantage of this approach is that it does not require 970 explicit knowledge of the network topology. We will revisit these 971 two approaches to quantitative provisioning of the interior in a 972 later section. 974 Once the resources required for quantitative traffic at each node 975 have been determined, provisioning of the node consists of 976 installing or configuring interfaces of the appropriate capacity to 977 easily accommodate the quantitative traffic that will traverse the 978 node. Note that we do not state the precise meaning of 'to easily 979 accommodate'. A number of factors must be considered when 980 determining the appropriate capacity, given a certain volume of 981 predicted quantitative traffic. These include: 982 1. Margin of error 983 2. Statistical gain desired 984 3. Capacity remaining for qualitative (including best efforts) 985 traffic 987 The first, margin of error, accommodates mistakes in computation, 988 effects of transient route changes which are not otherwise accounted 989 for, effects of traffic clustering as it moves through the network 990 and so on. The statistical gain desired refers to the degree to 991 which a provider is willing to gamble that not all sources of 992 quantitative traffic will be simultaneously active at the limit 993 dictated by the TCAs at the ingress points (vs. the penalty the 994 provider would be willing to pay in terms of refunded charges or 995 lost customers). Finally, the provider must determine how much 996 capacity will be reserved for qualitative traffic at each node. 997 Thus, if it is determined that 1 Mbps of quantitative traffic might 998 traverse a specific node in a specific direction, the provider might 999 install a 10 Mbps interface in the node, to serve the corresponding 1000 traffic direction. This would leave 9 Mbps of capacity quite safely 1001 for qualitative traffic. In this case, the provider would be 1002 assuming that statistical gains which might be realized will be used 1003 to offset the margin of error which would compromise the resources 1004 available. 1006 Blake, et al Expires: April 1999 19 1007 Draft-ietf-diffserv-framework-01.txt October, 1998 1009 In addition to installing or configuring the appropriate capacity at 1010 each interface, it may be desirable to configure policers to assure 1011 that the resources actually consumed by the higher priority 1012 quantitative traffic do not exceed expectations. This is especially 1013 important if the provider is attempting to achieve a high degree of 1014 statistical gain or has not allowed for a reasonable margin of 1015 error. Policers need not be configured at each interior node, but 1016 should probably be configured at certain key nodes. It may also be 1017 necessary to configure the internal resources of the router (queues 1018 and buffers) to deliver the services required. 1020 6.1.2.2 Qualitative Provisioning of the Interior 1022 As explained previously, it is necessary first to determine the 1023 resources which must be provisioned at each node for quantitative 1024 traffic. Once these have been determined, interfaces must be 1025 installed or provisioned to accommodate the required resources while 1026 leaving sufficient capacity for qualitative traffic. In order to do 1027 so, it is necessary to determine the resources required at the node 1028 for qualitative traffic. Since qualitative traffic cannot be assumed 1029 to follow specific routes with the same degree of predictability as 1030 quantitative traffic, this provisioning problem is far more 1031 difficult and provisioning parameters must be estimated based on 1032 heuristics, experience and possibly on real time measurement. 1034 Once physical interfaces have been selected to accommodate the 1035 resources required by the computed quantitative traffic load and the 1036 estimated qualitative traffic load, additional configuration is 1037 required to support qualitative traffic. Such configuration amounts 1038 to the selection of relative weights for queues for different 1039 service levels (in a WFQ scheme), or the selection of RIO or RED 1040 thresholds or alternate logical resource provisioning parameters. It 1041 is assumed that if quantitative traffic is accommodated via similar 1042 queuing mechanisms (as opposed to strict priority queuing), that the 1043 weighting parameters chosen for quantitative traffic isolate it 1044 effectively from the effects of qualitative traffic. However, the 1045 configuration parameters which differentiate the various qualitative 1046 services may not provide such a degree of isolation among the 1047 qualitative services. Thus, it may be necessary to attempt to 1048 estimate the relative traffic arriving for each qualitative service 1049 and to anticipate the interaction between traffic of different 1050 qualitative services. It may be impossible to both efficiently and 1051 conservatively provision a network for certain combinations of 1052 qualitative services. To aid in the provisioning of a network for 1053 qualitative services, it may be useful to configure policers to 1054 control the volume of traffic arriving at a given node. However, 1055 such policing might have to be restricted to shaping (rather than 1056 discarding) in order to avoid violating TCAs in place at the network 1057 boundaries. 1059 Blake, et al Expires: April 1999 20 1060 Draft-ietf-diffserv-framework-01.txt October, 1998 1062 6.2. Static vs. Dynamic Provisioning 1064 So far, we have considered static provisioning techniques. Even the 1065 example of RSVP usage for provisioning assumed that the RSVP 1066 messages were launched at the time a TCA was instantiated as opposed 1067 to dynamically. In the case that TCAs are static, static 1068 provisioning is adequate for quantitative traffic. However, since 1069 qualitative traffic [e.b.1] offers less predictable patterns, it is 1070 likely to cause traffic volumes at different nodes in the network to 1071 change dynamically, even when the TCA is static. For this reason, 1072 dynamic provisioning techniques are desirable and may assist the 1073 service provider in making better use of network resources. In 1074 addition, dynamic provisioning may enable the service provider to 1075 provision more liberally for quantitative services, realizing 1076 statistical gains. If we consider further, that it may be desirable 1077 to provide dynamically changing TCAs, then the appeal of dynamic 1078 provisioning techniques is even stronger. 1080 Dynamic provisioning may be signalling based, measurement based or 1081 both. For example, a conventional RSVP router supports signalling 1082 based dynamic provisioning. Hosts signal the router to request more 1083 or less resources and the router adjusts accordingly. The host may 1084 or may not actually submit traffic at the rate at which it signalled 1085 it would, but regardless, the resources are committed in case it 1086 does. Measurement based provisioning would adjust the resources 1087 committed in response to the traffic loads actually measured at the 1088 device. While differentiated services does not specify any form of 1089 signalled or measurement based provisioning, both may be useful. 1091 6.3 Distributing Configuration Information 1093 The process of physical provisioning is by necessity relatively 1094 static and cannot be automated since it requires installation of 1095 physical equipment. However, logical provisioning and configuration 1096 can and should be automated to the degree possible. In this section, 1097 we look at techniques for distributing configuration information. 1099 6.3.1 Top Down Distribution of Configuration Information 1101 In the simplest case, TCAs are static and both the boundaries and 1102 interior of the network are provisioned statically by 'pushing' 1103 configuration information down to the appropriate network nodes. 1104 Configuration of boundary nodes requires primarily the pushing of 1105 policing information to enforce the TCAs in place. (Additional fine 1106 grain information may be pushed to provide traffic separation 1107 services on behalf of the customer, but these are not addressed in 1108 this context). Configuration information for boundary nodes is 1109 determined at the time the TCA is negotiated. At this time, the 1110 nodes are configured by the provider. The network administrator may 1111 use one of several protocols to do so, including for example SNMP or 1112 CLI. 1114 Blake, et al Expires: April 1999 21 1115 Draft-ietf-diffserv-framework-01.txt October, 1998 1117 In order to accommodate the traffic submitted by the provisioning of 1118 new TCAs, it is necessary to provision the interior of the network. 1119 As discussed previously, it is possible to compute the resources 1120 required for quantitative traffic. Assuming that sufficient physical 1121 capacity has been provisioned, configuration amounts to logically 1122 provisioning sufficient capacity at each interior interface and to 1123 configuring policers for the quantitative traffic at various 1124 interior nodes. In addition, qualitative provisioning requires the 1125 configuration of queues, WFQ weights and/or RIO parameters at 1126 various interior nodes, and may also include the configuration of 1127 some number of policers. In the case, of static, top down 1128 configuration, interior configuration information is also pushed 1129 down via a configuration protocol such as SNMP or CLI. 1131 The difficulty of such top down provisioning is that it requires the 1132 network administrator to coordinate the provisioning of each network 1133 node, at boundaries as well as in the interior, such that the 1134 network is provisioned end-to-end in a consistent manner and is able 1135 to efficiently deliver the services promised by the TCAs. In order 1136 to assist the network administrator in this task, it is useful to 1137 consider a database which holds both current topology information as 1138 well as the current TCAs instantiated at the network boundaries. 1139 This information is stored in a format dictated by a standard schema 1140 as suggested in [Elleson]. 1142 Of course, the database is ideally maintained in a way which is 1143 logically centralized (for ease of programming and modifying) but is 1144 physically distributed (for the sake of robustness and fault 1145 tolerance). Policy servers may be used to extract information from 1146 the database and to convert it to configuration information which is 1147 pushed down to individual nodes. In this scenario, policy servers 1148 would likely use a directory access protocol such as LDAP to 1149 retrieve information from the directory and would use a 1150 configuration protocol such as SNMP or CLI to push the configuration 1151 information down to the network nodes. Note that in this example, 1152 the policy servers and the directory schemas are in effect 1153 fulfilling the role of bandwidth broker [BB]. In particular, the 1154 policy servers use an awareness of the network topology to provision 1155 interior nodes such that certain end-to-end QoS routes can be 1156 constructed and assurances implied by the TCAs at the boundaries can 1157 be delivered. 1159 6.3.2 Distribution of Configuration Information via Signalling 1161 An alternate mechanism of distributing configuration information is 1162 via signalling messages transmitted between boundary nodes of the 1163 same differentiated service domain (intra-domain signalling). It is 1164 also interesting to consider inter-domain signalling, but this will 1165 be addressed separately. An example of such signalling was described 1166 previously, in the usage of a modified form of RSVP. Such signalling 1168 Blake, et al Expires: April 1999 22 1169 Draft-ietf-diffserv-framework-01.txt October, 1998 1171 is particularly useful for the purpose of installing configuration 1172 information for quantitative services which affect specific paths 1173 and is somewhat less useful (though not useless) for the purpose of 1174 configuring qualitative services. It is likely that such a 1175 signalling approach would be used in conjunction with top down 1176 provisioning. For example, the directory schema might dictate the 1177 amount of resources to be available for high priority quantitative 1178 services at each node. These limits might be pushed down to 1179 individual nodes a- priori. Signalling from the network boundaries, 1180 at TCA instantiation time, would then be used to claim resources 1181 from the pool of quantitative resources available at each node. 1182 Alternatively, nodes might consult policy servers as the signalling 1183 resource requests arrive at each node. The latter model is similar 1184 to the use of per- flow RSVP signalling and PEP/PDP policy usage in 1185 traditional RSVP networks. Qualitative configuration information 1186 would still be pushed in a top down manner. The advantage of the 1187 latter model is that policy servers would be dynamically updated 1188 with information regarding the current usage of network resources. 1189 In this model, it is likely that a variant of COPS would be used to 1190 communicate between network nodes and the policy servers. Note that 1191 COPS may be used for distribution of top down configuration 1192 information as well, though it is not specifically designed for this 1193 purpose. 1195 One of the advantages of configuration via signalling, is that it 1196 facilitates the support of dynamic TCAs. TCAs could be dynamically 1197 renegotiated using inter-domain signalling. Such renegotiation would 1198 require dynamically modifying the provisioning within the affected 1199 domain, a process which requires some automated signalling protocol 1200 such as an aggregated form of RSVP signalling between boundary nodes 1201 in a provider's domain. This protocol would in effect, represent a 1202 distributed bandwidth broker [BB] for the domain. 1204 6.3.3 Modification of Configuration Information Based on Real-Time 1205 Measurement 1207 A third mechanism for the configuration of interior nodes would be 1208 based on measurement of current traffic loads at key network nodes. 1209 Measurement based configuration is less necessary for quantitative 1210 provisioning, since quantitative traffic patterns are relatively 1211 predictable. However, it can significantly enhance the efficiency 1212 with which qualitative provisioning can be achieved. For example, 1213 network nodes may feed policy servers with current qualitative 1214 traffic load measurements. In response, bandwidth brokers and policy 1215 servers might recompute the relative weights for different service 1216 queues in a WFQ node and push the new configuration information to 1217 the routers. It is likely that measurement based configuration for 1218 qualitative services would be used in conjunction with signalling 1219 based configuration for quantitative services. 1221 Blake, et al Expires: April 1999 23 1222 Draft-ietf-diffserv-framework-01.txt October, 1998 1224 7. Inter-Domain Considerations and End-to-End Services 1226 So far we have considered differentiated service primarily in the 1227 context of a single DS domain providing service to a single 1228 customer. The ultimate customers of the differentiated service 1229 network are hosts and end users residing on peripheral stub 1230 networks. In general, these are interconnected by multiple domains 1231 and require service which spans these domains. Therefore, it is 1232 important to consider the interaction of services provided by a 1233 concatenation of differentiated service domains and the peripheral 1234 stub networks, rather than the service provided by a single domain. 1235 In this section, we discus inter-domain issues related to TCAs, 1236 provisioning and service and PHB mapping. 1238 7.1 TCAs 1240 Each service provider is expected to negotiate bilateral agreements 1241 at each boundary node at which it connects to an adjacent provider's 1242 network. Such agreements are captured in the form of two TCAs, one 1243 governing the services provided to provider A's traffic by provider 1244 B and the other governing the services provided to provider B's 1245 traffic by provider A. Note that provider A serves as a provider to 1246 provider B with respect to traffic flowing from provider B to 1247 provider A. On the other hand provider A is a customer of provider B 1248 with respect to traffic flowing from provider A to provider B. The 1249 two TCAs can be considered separately. 1251 In general, the TCAs negotiated by a provider at any boundary will 1252 be dictated by TCAs negotiated at other boundaries. For example, 1253 assume that provider A offers leased line service to a customer with 1254 an ingress point in provider A's domain, but an egress point in 1255 provider B's domain. In this case, it is necessary that the TCA 1256 between provider A and provider B be sufficient to accommodate the 1257 assurance made by provider A to its leased line service customer. 1258 Provider A may serve a number of customers with leased line services 1259 terminating at various boundary points in provider B's network. 1260 Thus, the TCA between provider A and provider B must represent the 1261 aggregate requirements of the TCAs of all of provider A's customers. 1263 7.2 Inter-Domain Provisioning 1265 The inter-domain provisioning problem is not unlike the intra- 1266 domain provisioning problem. The provider would generally begin by 1267 evaluating the TCAs it has negotiated with its customers, and then 1268 computing the impact of each of these TCAs on the TCAs it has 1269 negotiated with its providers. For quantitative services, the 1270 provider can compute the quantitative requirements of TCAs at each 1271 of its provider's boundary nodes, as described above in the context 1272 of the leased line service. For qualitative services, the process of 1273 determining the requirements from its providers is fuzzier, since 1275 Blake, et al Expires: April 1999 24 1276 Draft-ietf-diffserv-framework-01.txt October, 1998 1278 the volume of qualitative traffic expected to be carried through any 1279 boundary is less deterministic. 1281 In the simplest case, provisioning is based on static TCAs. In this 1282 case, provisioning is an iterative process in which providers 1283 negotiate TCAs with each of their customers, then apply the 1284 appropriate internal provisioning techniques to meet these 1285 requirements. In the process of internal provisioning, a provider 1286 might determine that a particular TCA cannot be met due to internal 1287 resource constraints. The provider would then either have to add 1288 internal resources or renegotiate one or more customer TCAs. 1289 Although the process may be somewhat iterative, it is relatively 1290 static in that changes in boundary TCAs and internal provisioning 1291 occur relatively infrequently (on the order of hours, days or 1292 months) and require human intervention. 1294 Internal provisioning to meet the requirements of TCAs relies on 1295 provisioning techniques described previously. As TCAs are 1296 negotiated, the provider must check that the existing internal 1297 provisioning is sufficient to meet the requirements of the new TCA, 1298 or must alter the internal provisioning. Recall that internal 1299 provisioning might be pushed in a top down manner, from a domain's 1300 logically centralized point of administration, or alternatively 1301 might be distributed from the edges via signalling. In the former 1302 case, some form of a bandwidth broker would be directly consulted or 1303 notified regarding changes in TCAs negotiated at the domain 1304 boundaries. In the case that signalling is used, provisioning 1305 messages (such as described previously) would be launched from the 1306 boundary at which the new TCA is negotiated. These would claim a 1307 share of existing provisioned resources, or would notify the 1308 bandwidth broker in the case that additional resources are required. 1310 A more sophisticated model would allow TCAs to be renegotiated 1311 dynamically. In this case, the process would be automatic, and would 1312 not require human intervention. Each domain would in effect, 1313 represent a bandwidth broker, via one protocol or another. A 1314 specific inter-domain protocol might be used to communicate between 1315 centralized bandwidth broker agents, or alternatively, an inter- 1316 domain variant of RSVP might be used. In the latter case, there is 1317 no direct interaction with a bandwidth broker per-se. However, the 1318 collection of network nodes, policy servers and directory behave 1319 collectively as a bandwidth broker which communicates using RSVP. In 1320 either case, TCA renegotiations would be triggered by load 1321 measurements at boundary nodes. These could be in the form of 1322 changes in actual measured traffic volume, or alternatively, based 1323 on explicit fine grain RSVP resource requests from hosts at the 1324 periphery. Domains would approve renegotiations based both on 1325 resource constraints as well as predetermined policy constraints. 1327 Blake, et al Expires: April 1999 25 1328 Draft-ietf-diffserv-framework-01.txt October, 1998 1330 7.3 Service, PHB and Codepoint Mapping 1332 In order to provide end-to-end service to customers, it must be 1333 possible to extend services across multiple domains. Several 1334 complexities may arise at inter-domain boundaries, as follows: 1335 1. The services provided by a certain domain may not be compatible 1336 with the services provided by a neighbour domain. 1337 2. The services provided by a certain domain may be compatible with 1338 those provided by the neighbour domain, but the PHB used to 1339 obtain the service might be different. 1340 3. The PHB might be the same, but the codepoint used to request the 1341 PHB might be different. 1342 4. The PHB and codepoint are the same but differences in 1343 provisioning and charging models results in different services. 1345 Resolution of these complexities requires determination of the 1346 compatible services and negotiation of the PHB codepoints which will 1347 be used to request the services. This process is greatly simplified 1348 by the provision of a set of universal services using universally 1349 recognized codepoints. The leased line service and EF codepoint is 1350 likely to be one such example. Generally, extension of quantitative 1351 services across multiple domains will require more uniformity in the 1352 nature of the services provided. Qualitative services on the other 1353 hand, may be extended end-to-end by a concatenation of services 1354 which vary from domain to domain. For example, one domain may base a 1355 qualitative service on a WFQ scheme with RED while another may use 1356 priority queuing with RIO. Since the assurances provided by 1357 qualitative services tend to be looser, it is possible that a 1358 meaningful service can be provided end-to-end by concatenating these 1359 two service types. 1361 7.4 Host-Domain Boundaries 1363 In certain cases, a host may be directly attached to a 1364 differentiated service domain. This is likely both in the case of 1365 campus networks that provide differentiated services within the 1366 network or in the case of dial-up users connecting to a 1367 differentiated service provider. In these cases, the host can be 1368 considered the customer of the differentiated service network. 1369 Legacy hosts are unlikely to mark their own packets for the 1370 appropriate DS-field and are also unlikely to shape or police their 1371 traffic. In the case of legacy hosts, the differentiated service 1372 provider will have to provide these services on behalf of the 1373 customer. In the case of campus networks, some network wide policy 1374 would likely be used to configure these services in the DS boundary 1375 devices. In the case of dial-up hosts, marking, shaping and 1376 resources provided would likely be negotiated at the time the 1377 customer signs up with the provider. 1379 Newer hosts may be capable both of marking and of traffic shaping. 1380 In this case, the overall per-host resource constraints are still 1382 Blake, et al Expires: April 1999 26 1383 Draft-ietf-diffserv-framework-01.txt October, 1998 1385 likely to be somewhat static. However, the manner in which the host 1386 shares these resources among its various traffic flows is determined 1387 by the host. Of course, the provider will have to configure policers 1388 to assure that the host does not seize more than its share of 1389 resources in the differentiated service network. 1391 8. Inter-operability with RSVP/Integrated Services 1393 In this section, we discuss alternatives for inter-operability 1394 between differentiated services and RSVP/Integrated services. 1396 8.1 RSVP/Integrated Services Over Differentiated Services 1398 This scenario is discussed in detail in [E2EQOS]. It assumes a model 1399 in which peripheral stub networks are RSVP and Intserv aware. These 1400 are interconnected by differentiated service networks. In this 1401 model, the scalability of differentiated service networks helps to 1402 extend the reach of RSVP/Integrated service (Intserv)networks. 1403 Intervening differentiated service networks appear as a single RSVP 1404 hop to the RSVP/Intserv networks. Hosts attached to the peripheral 1405 RSVP/Intserv networks signal to each other for per-flow resource 1406 requests across the differentiated service networks. Standard 1407 RSVP/Intserv processing is applied within the RSVP/Intserv 1408 peripheral networks. RSVP signalling messages are carried 1409 transparently through the differentiated service networks. Devices 1410 at the boundaries between the RSVP/Intserv networks and the 1411 differentiated service networks process the RSVP messages and 1412 provide admission control based on the availability of appropriate 1413 resources within the differentiated service network. 1415 This model is predicated on the availability of services within the 1416 differentiated service network which can extend the reach of intserv 1417 type services. For example, the leased line service can extend the 1418 intserv guaranteed service across a differentiated service network. 1419 Multiple guaranteed service micro-flows which exist in peripheral 1420 networks are aggregated into the EF behaviour aggregate at the edge 1421 of the diffserv network. When an RSVP request for guaranteed service 1422 arrives at the edge of a differentiated service network, RSVP style 1423 admission control is applied based on the amount of resources 1424 requested in the intserv flowspec and the availability of 1425 differentiated services at the corresponding service level (per the 1426 TCA). If admission control succeeds, the originating host (or its 1427 agent) marks traffic on the signalled microflow, for the appropriate 1428 differentiated service level. 1430 The RSVP/Intserv over differentiated service model is especially 1431 suitable for providing quantitative end-to-end services. The use of 1432 differentiated services eliminates the scalability concerns of 1433 RSVP/Intserv networks. The use of RSVP signalling provides admission 1434 control to the differentiated service network, based on resource 1435 availability and policy decisions. It also greatly simplifies the 1437 Blake, et al Expires: April 1999 27 1438 Draft-ietf-diffserv-framework-01.txt October, 1998 1440 configuration of differentiated service classifiers, policers and 1441 other traffic conditioning components. 1443 Variations on this theme would enable some number of nodes within 1444 the differentiated service networks to process the per-flow RSVP 1445 messages passing through. These could be used to aid in dynamic 1446 provisioning without necessarily requiring any per-flow state or 1447 processing within the differentiated service network. In yet another 1448 model, the transition of per-flow RSVP messages through the 1449 differentiated service network might trigger aggregated RSVP 1450 signalling between differentiated service domain edges, for the 1451 purpose of renegotiating TCAs and adjusting provisioning dynamically 1452 [GBH97, CLASSY]. 1454 8.2 Parallel Operation 1456 Another alternative for the interoperation of differentiated service 1457 and RSVP/Intserv networks is simple parallel operation. In this 1458 mode, each node within the differentiated service network may also 1459 be an RSVP capable node. Some strategy would have to be selected for 1460 determining which packets are handled using RSVP and which are 1461 handled using differentiated services. For example, those that 1462 classify to an RSVP installed filter might be handled using RSVP, 1463 while those not classifying to specific RSVP filters would be 1464 handled according to the DS-field using differentiated service 1465 mechanisms. Such a model is likely to be deployed in smaller 1466 networks (since the RSVP/Intserv component is less suited for large 1467 networks). In particular, the stub networks cited in [E2EQOS] would 1468 likely provide differentiated services for those qualitative 1469 applications which do not signal, while providing RSVP/Intserv 1470 services for those quantitative applications which do signal. 1472 9. Multicast Services 1474 Because the Differentiated Services Architecture deals only with 1475 unidirectional flows, a 'multicast' service in a DS network will in 1476 fact offer a point-to-multipoint unidirectional service. Each 1477 source of traffic that wishes to send to the multicast group using 1478 this service needs a separate SLA which applies at the ingress point 1479 where the traffic enters the network. 1481 The network resources that must be provisioned for a multicast 1482 service will be affected by the mechanisms used by the routers to 1483 provide the service. Depending on the capabilities of the routers 1484 and the multicast routing protocol employed, sub-optimal replication 1485 of a packet may result in multiple copies travelling over the same 1486 link. 1488 If receivers can be added dynamically to a multicast group whilst a 1489 flow is in progress, the complexity of provisioning grows 1490 considerably: The amount of network resources that will be consumed 1492 Blake, et al Expires: April 1999 28 1493 Draft-ietf-diffserv-framework-01.txt October, 1998 1495 by multicast traffic originating from a particular upstream network 1496 may be difficult to forecast in advance. Consequently, it may not 1497 be possible to offer quantitative services where dynamic addition of 1498 receivers adds to the paths through the network already used by the 1499 flow. 1501 9.1 Codepoints and PHBs for Multicast Services 1503 To achieve resource isolation of multicast traffic from unicast 1504 traffic, it may be necessary to use separate codepoints and separate 1505 instances of a PHB or different PHBs for the multicast and unicast 1506 services. If the multicast traffic is not adequately isolated, 1507 dynamic addition of new members of the multicast group can adversely 1508 affect existing unicast traffic. 1510 Because a multicast service traffic flow can exit from a domain to 1511 several peer domains, care must be taken to use a codepoint and PHB 1512 that is compatible with the peering SLAs at the egress points. This 1513 may be a more stringent requirement than for a unicast service where 1514 a flow need only be compatible with a single egress point SLA. 1516 9.2 Provisioning Multicast Services 1518 The scope of a multicast service would normally be either case 1 1519 (any egress point) or case 3 (a pre-defined set of egress points) of 1520 Sec. 4.4. 1522 For a quantitative service the scope will, in general, need to be 1523 case 3. The service can be provisioned in a similar way to 1524 corresponding unicast services with the same volume of traffic along 1525 each of the paths from ingress to egress, but taking into account 1526 that all paths will be used simultaneously and allowing for multiple 1527 copies of traffic if necessary. If the multicast routing protocol 1528 used can generate different multicast trees depending on the order 1529 in which members join the group, provisioning may not be possible. 1530 Solving this problem may require pinning of the multicast tree 1531 branch points; the solution of this problem is outside the scope of 1532 this framework. 1534 For a qualitative service, provisioning is essentially the same as 1535 the unicast case, but statistical multiplexing gains are likely to 1536 be less because all paths may be used at once. 1538 The traffic conditioning mechanisms for multicast services are not 1539 significantly different from those for the unicast services but 1540 multiple shapers may be required where traffic exits from several 1541 interfaces on a single router or multiple replicas exit from one 1542 interface. 1544 Blake, et al Expires: April 1999 29 1545 Draft-ietf-diffserv-framework-01.txt October, 1998 1547 10. Security and Tunnelling Considerations 1549 The security and tunnelling implications for the actual data 1550 transport of the services of the Differentiated Services 1551 Architecture have been extensively discussed in {DSARCH] and 1552 [DSHEAD] to which the reader is referred. 1554 Additional security considerations arise from the services overlaid 1555 on the data transport: 1556 1. The services are the subject of differential charging. 1557 Accordingly, the service users have to be authenticated and 1558 authorised, and the accounting data needed must be secured. 1559 2. The mechanisms used to create and distribute the policy and 1560 resource allocations must be secured. 1561 3. Statistical data needed to audit service delivery must be 1562 secured. 1564 The mechanisms used to provide this security are outside the scope 1565 of this framework, but are under consideration by the AAA working 1566 group. 1568 The use of tunnels in general and IPsec tunnels in particular 1569 impedes the work of MF Classifiers by concealing the fields used by 1570 L4 and higher layer classifiers. Thus traffic conditioners within 1571 the area where IPsec encryption is used will need to rely only on IP 1572 header fields, including the DS field (BA Classifiers will work 1573 normally). If more sophisticated Mf classification is required it 1574 will have to take place before the tunnel ingress and the 1575 application of IPsec encryption. If IPsec encryption is used end- 1576 to-end, then Differentiated Services may require host marking. 1578 If a tunnel carries multiple flows with different traffic types, 1579 they may be marked with different DS codepoints so that they are 1580 subjected to appropriate behaviors in the network interior. This 1581 may be considered to be a security breach as it allows traffic 1582 patterns to become visible. If just one codepoint is used for all 1583 traffic it should be selected carefully to be appropriate for all 1584 the traffic in the tunnel. 1586 11. Acknowledgements 1588 The authors would like to acknowledge the helpful comments and 1589 suggestions of the following individuals: Kathleen Nichols, Brian 1590 Carpenter, David Black, Konstantinos Dovrolis, Shivkumar Kalyana, 1591 Wu-chang Feng, Marty Borden, and Ronald Bonica. 1593 Blake, et al Expires: April 1999 30 1594 Draft-ietf-diffserv-framework-01.txt October, 1998 1596 12. References 1598 [BB] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit 1599 Differentiated Services Architecture for the Internet", Internet 1600 Draft 1602 [CLARK] D. Clark and J. Wroclawski, "An Approach to Service 1603 Allocation in the Internet", Internet Draft 1605 [CLASSY] S. Berson and S. Vincent, "Aggregation of Internet 1607 Integrated Services State", Internet Draft, November 1997. 1609 [COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A. 1610 Sastry, "COPS (Common Open Policy Service) Protocol", March 1998. 1612 [DSARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and W. 1613 Weiss, "An Architecture for Differentiated Services", Internet 1614 Draft, May 1998. 1616 [DSHEAD] K. Nichols and S. Blake, "Definition of the Differentiated 1617 Services Field (DS Byte) in the IPv4 and IPv6 Headers", Internet 1618 Draft, May 1998. 1620 [AF] J.Heinanen, _Assured Forwarding PHB Group_Internet Draft, 1621 August 1998. 1623 [EF] V.Jacobson, _Expedited Fowarding Per Hop Behavior_, Internet 1624 Draft, August 1998. 1626 [Ellesson] E. Ellesson and S. Blake, "A Proposal for the Format and 1627 Semantics of the TOS Byte and Traffic Class Byte in IPv4 and IPv6", 1628 Internet Draft, November 1997. 1630 [E2EQOS] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, and L. Zhang, 1631 "A Framework for End-to-End QoS Combining RSVP/Intserv and 1632 Differentiated Services", Internet Draft, March 1998. 1634 [GBH97] R. Guerin, S. Blake, and S. Herzog, "Aggregating RSVP- based 1635 QoS Requests", Internet Draft, November 1997. 1637 [IntServ] R. Braden, D. Clark, and S. Shenker, "Integrated Services 1638 in the Internet Architecture: An Overview", Internet RFC 1633, July 1639 1994. 1641 [RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) -- 1642 Version 1 Functional Specification", Internet RFC 2205, September 1643 1997. 1645 Blake, et al Expires: April 1999 31 1646 Draft-ietf-diffserv-framework-01.txt October, 1998 1648 11. Author's Addresses 1650 Bernet, Yoram 1651 Microsoft 1652 One Microsoft Way 1653 Redmond, WA 98052 1654 Phone: +1 (425) 936-9568 1655 Email: yoramb@microsoft.com 1657 Binder, James 1658 3Com Corp. 1659 5400 Bayfront Plaza 1660 Santa Clara, CA 95052 1661 Phone: +1 (408) 326-6051 1662 Email: james_binder@3com.com 1664 Blake, Steven 1665 Torrent Networking Technologies 1666 3000 Aerial Center, Suite 140 1667 Morrisville, NC 27560 1668 Phone: +1-919-468-8466 x232 1669 Fax: +1-919-468-0174 1670 Email: slblake@torrentnet.com 1672 Carlson, Mark 1673 RedCape Software Inc. 1674 2990 Center Green Court South 1675 Boulder, CO 80301 1676 Phone: +1 (303) 448-0048 x115 1677 Email: mac@redcape.com 1679 Davies, Elwyn 1680 Nortel UK 1681 London Road 1682 Harlow, Essex CM17 9NA, UA 1683 Phone: +44-1279-405498 1684 Email: elwynd@nortel.co.uk 1686 Ohlman, Borje 1687 Ericsson Radio 1688 Dialoggatan 1 (Kungens Kurva) 1689 S-126 25 Stockholm 1690 Sweden 1691 Phone: +46-8-719 3187 1692 Email: Borje.Ohlman@ericsson.com 1694 Blake, et al Expires: April 1999 32 1695 Draft-ietf-diffserv-framework-01.txt October, 1998 1697 Srinivasan Keshav 1698 4107B Uspon Hall 1699 Cornell University 1700 Ithaca, NY 14853 1701 Phone: +607-255-5395 1702 Email: skeshav@cs.cornell.edu 1704 Dinesh Verma IBM T. J. Watson Research Center 1705 P.O. Box 704 1706 Yorktown Heights, NY 10598 1707 Phone: +1 (914) 784-7466 1708 Email: dverma@watson.ibm.com 1710 Zheng Wang 1711 Bell Labs Lucent Tech 1712 101 Crawfords Corner Road 1713 Holmdel, NJ 07733 1714 Email: zhwang@bell-labs.com 1716 Walter Weiss 1717 Lucent Technologies 1718 300 Baker Avenue, Suite 100 Concord, MA 01742-2168 1719 Email: wweiss@lucent.com 1721 Blake, et al Expires: April 1999 33