idnits 2.17.1 draft-bernet-intdiff-00.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-25) 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. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 3) 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([8], [10], [12], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 734, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 738, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 748, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 752, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 759, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '12') Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Y. Bernet, Microsoft 3 Internet Draft R. Yavatkar, Intel 4 draft-bernet-intdiff-00.txt P. Ford, Microsoft 5 F. Baker, Cisco 6 L. Zhang, UCLA 8 March, 1998 10 A Framework for End-to-End QoS Combining RSVP/Intserv and 11 Differentiated Services 13 Status of this Memo 15 This document is an Internet Draft. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute 18 working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a 24 "working draft" or "work in progress". 26 To learn the current status of any Internet-Draft, please check the 27 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 28 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 29 munnari.oz.au. 31 A revised version of this draft document will be submitted to the 32 RFC editor as a Proposed Standard for the Internet Community. 33 Discussion and suggestions for improvement are requested. This 34 document will expire before September, 1998. Distribution of this 35 draft is unlimited. 37 1. Abstract 39 In the past several years, work on QoS enabled networks led to the 40 development of the Integrated Services (Intserv) architecture [12] 41 and the RSVP signaling protocol [1]. RSVP addresses the needs of 42 applications that require QoS, promising per-flow service. As the 43 RSVP/Intserv (from here on abbreviated to intserv) work has 44 proceeded, we have recognized barriers to the deployment of intserv. 45 The reliance of intserv on per-flow state and per-flow processing is 46 an impediment to its deployment in the Internet at large, and in 47 particular in large carrier networks. Additionally, RSVP signaling 48 is supposed to originate from hosts, which as of yet are not RSVP 49 enabled in large numbers. 51 Recently, attention has shifted to Differentiated services (diff- 52 serv). Diff-serv promises to expedite the realization of QoS enabled 54 1 55 Framework for End-to-End QoS March, 1998 57 networks by offering a significantly simpler alternative to intserv, 58 which eliminates scalability concerns and which can be implemented 59 and managed in large networks, without requiring end-to-end 60 deployment. However, unlike intserv, diff-serv focuses on the needs 61 of the large network. 63 This draft proposes a framework for end-to-end QoS, in which intserv 64 and diff-serv are used together to meet the needs of large ISPs who 65 manage the transit networks of the Internet, and the users of QoS 66 applications and hosts, who are the ISPs' ultimate customers. This 67 focus is important, as we believe that in the coming years, there 68 will be a proliferation of applications that depend on QoS and of 69 hosts which are capable of QoS signaling. We envision the deployment 70 of diff-serv capable core networks and intserv capable stub networks 71 at the periphery. Our framework allows each to proceed at its own 72 pace, providing immediate incremental benefits in areas of the 73 network in which one or the other is deployed and additional 74 benefits where both are deployed. This framework builds upon current 75 work in the IETF including diff-serv [10] and RSVP aggregation [8]. 77 Many of the ideas in this document have been previously discussed in 78 the original intserv architecture document [12]. 80 2. Goals of This Draft 82 This draft is based on the assumption that end-to-end QoS is 83 required to support the needs of certain applications. Such 84 applications include IP-telephony, video-on-demand and various non- 85 multimedia mission-critical applications. 87 In our view, intserv and diff-serv are complementary tools in the 88 pursuit of end-to-end QoS. Each serves an important purpose in the 89 end-to-end QoS enabled network. The primary goal of this draft is to 90 encourage the continued development of each in a manner that does 91 not preclude realization of the proposed framework. To this end, we 92 will: 94 1. List the requirements of a network that provides end-to-end QoS. 95 2. Present a framework that uses intserv as a customer of diff-serv 96 to meet these requirements. 97 3. Identify dependencies of intserv on diff-serv. 99 3. Requirements for the End-to-End QoS Framework 101 An end-to-end QoS network must serve the requirements of network 102 managers as well as those of applications. We consider these 103 requirements in the context of the following general topology: 105 2 106 Framework for End-to-End QoS March, 1998 108 / Stub \ / Transit \ / Stub \ 109 / Network \ / Network \ / Network \ 110 |---| | |---| |---| |---| |---| | |---| 111 |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx | 112 |---| | |-- | |---| |---| |---| | |---| 113 \ / \ / \ / 114 \ / \ / \ / 116 Figure 1: Sample Network Configuration 118 This network consists of a diff-serv capable transit network and two 119 intserv capable stub networks. In the interest of simplicity, we 120 show a single QoS sender on one of the stub networks and a single 121 QoS receiver on the other. We show edge routers (ER1, ER2) at the 122 interfaces of the intserv networks to the diff-serv network. We show 123 boundary routers (BR1, BR2) at the interfaces of the diff-serv 124 network to the intserv networks. 126 The transit network contains a mesh of routers, at least some of 127 which are diff-serv capable. The stub networks contain a mesh of 128 routers, at least some of which are intserv capable. 130 We define the following requirements of the framework: 132 3.1 Definition of a Set of Services 134 There must be a set of useful end-to-end services that can be 135 requested by QoS needy applications. Routers internal to the diff- 136 serv network are assumed to provide a set of 'per-hop-behaviours' 137 (PHBs [10]). We expect that concatenation of certain well-defined 138 PHBs will yield certain well-understood services across the diff- 139 serv network. We also expect that the intserv regions of the network 140 will be able to extend these services such that they can be realized 141 in a true end-to-end manner. 143 3.2 Allotment of Diff-serv Service Levels to Specific Traffic Flows 145 It must be possible to allot specific end-to-end service levels to 146 specific application traffic flows. Within the intserv regions of 147 the network this is achieved by allowing applications to use RSVP to 148 configure classifiers which operate on IP addresses and port 149 numbers. We will refer to such classifiers from here on as 'MF' 150 classifiers [10]. 152 Within the diff-serv regions of the network, traffic is allotted 153 service based on the contents of the DS-byte in packet headers. 154 Therefore, it is necessary for QoS needy applications to effect the 156 3 157 Framework for End-to-End QoS March, 1998 159 correct marking of DS-bytes before their packets are submitted to 160 the diff-serv network. There are two general mechanisms for doing 161 so: 163 1. Hosts may directly mark DS-bytes in the transmitted packets of 164 QoS needy applications. 165 2. Routers external to the diff-serv network may mark DS-bytes on 166 behalf of QoS needy applications, based on MF classification. 168 In the first case, marking will be done based on host configuration 169 or local communication between QoS needy applications and the host 170 operating system. In the second case, marking will be done based on 171 manual configuration of the marking router's MF classifier/marker or 172 standard signaling between QoS needy applications and the marking 173 router's classifier/marker. 175 The following three requirements argue either for host based marking 176 or for dynamic configuration of a router's classifier/marker in 177 response to application requests. 179 3.2.1 Minimal Management Burden 181 The information required to express useful mappings of application 182 traffic flows to service levels is likely to be quite complex and to 183 change frequently. Thus, manual configuration is likely to impose a 184 significant management burden. If the configuration information is 185 very simple and does not change over time, the management burden may 186 be relatively minor. However, this means that the granularity of 187 allotting service levels to flows will be sub-optimal. 189 3.2.2 Granularity of Allotment 191 The term 'granularity' is used here to refer to the degree of 192 specificity that is available in allotting a specific service level 193 to a specific traffic flow. There are two measures of granularity; 194 one is the granularity with which an individual flow or a group of 195 flows is identified. The other is the frequency at which the service 196 allotted to a flow may change. A fine grain QoS system would allow 197 the following requirement to be expressed: telephony traffic from 198 user X should be allotted service level A, while telephony traffic 199 from user Y should be allotted service level B, and web traffic from 200 any user should be allotted service level C. A coarse grain system 201 would be limited to something of the form: all traffic from subnet 202 1.0.0.0 should receive service level A, while all traffic from 203 subnet 2.0.0.0 should receive service level B. A temporally fine 204 grain system would allow immediate changes in allotment of service 205 levels to traffic flows. A temporally coarse grain system may allow 206 infrequent changes only. 208 3.2.3 Allocation of Service Level to Application Flows 210 It must be possible to allot specific service levels to application 211 traffic flows. Routers may not be able to readily identify these 212 flows based on network and/or transport layer fields in a packet. 213 4 214 Framework for End-to-End QoS March, 1998 216 For example, consider the need to give preferential service to a 217 website's home page (over other, less important pages at the site) 218 or the case of encrypted traffic flows (IPSEC). 220 3.3 Admission Control 222 Applications use RSVP to request that their flows be admitted to 223 intserv regions of the network. When a request is rejected, the host 224 application may avoid sending traffic and/or intermediate RSVP 225 capable nodes will only give best-effort service to traffic on flows 226 that were not admitted. These mechanisms protect traffic on flows 227 that were admitted. 229 In diff-serv regions of the network, admission control is provided 230 implicitly, by policing at ingress points. The problem with implicit 231 admission control is that it breaks the end-to-end validity of 232 explicit admission control. Specifically, an application may gain 233 admission using RSVP signaling, even though there is no capacity for 234 that application's traffic within the diff-serv region of the 235 network. Neither the application, nor intermediate RSVP capable 236 nodes will be aware that the application's traffic is not 237 admissible. As a result, neither can take corrective action and all 238 traffic from that customer, at the corresponding service level, may 239 be compromised. This failure may be partially, but not completely 240 alleviated by policing based on MF classification at the diff-serv 241 ingress (rather than BA classification [10]). 243 End-to-end QoS requires that applications and RSVP capable intserv 244 nodes be explicitly informed of admission control failure in the 245 diff-serv network. This enables them to take corrective action and 246 to avoid overdriving the diff-serv network. If the service agreement 247 between the intserv and diff-serv regions of the network is 248 statically provisioned, then admission control functionality can be 249 provided by static configuration of admission control in intserv 250 edge routers. However, if the service agreement is dynamically 251 variable, then it will be necessary to dynamically propagate current 252 diff-serv resource availability to the intserv network for the 253 purpose of explicit admission control. 255 3.4 Policy Support 257 End-to-end QoS leads to preferential treatment of certain traffic 258 flows over others. Within diff-serv regions of the network, policy 259 applies on a per-customer basis. In general, the diff-serv network 260 makes multiple service levels available to a single customer's 261 intserv network. In this case the customer must apply policy within 262 its network to assure appropriate allocation of resources (customer 263 network resources as well as diff-serv network resources) to 264 individual hosts in the customer's network. This requires that end- 265 to-end admission control be based on policy as well as resource 266 availability. 268 4.0 Intserv as a Customer of Diff-serv 269 5 270 Framework for End-to-End QoS March, 1998 272 To meet the above requirements, we propose a network that consists 273 of relatively small intserv capable stub networks, connected by 274 larger, diff-serv capable transit networks. In this section, we will 275 describe the operation of one instantiation of such a network (see 276 figure 1). The following assumptions apply: 278 4.0.1 Host Capabilities 280 Both sending and receiving hosts use RSVP to communicate QoS 281 requirements of certain QoS aware applications running on the host. 282 A QoS process within the host operating system generates RSVP 283 signaling on behalf of the applications. This process also invokes 284 traffic control. Host traffic control includes marking the DS-byte 285 in transmitted packets and shaping transmitted traffic per token 286 bucket specifications. Note that host traffic control is assumed for 287 this specific example, but is not a requirement of the framework in 288 general. Leaf routers within the intserv network may provide the 289 traffic control functions. 291 4.0.2 Edge Routers 293 The edge routers are special routers that straddle the boundary 294 between the RSVP/Intserv region of the network and the diff-serv 295 region of the network. It is helpful to think of these routers as 296 consisting of two halves; the standard RSVP half, which interfaces 297 to the stub networks, and the diff-serv half, which interfaces to 298 the transit network. 300 The RSVP half is at least partially RSVP capable; it is able to 301 process PATH and RESV messages but it is not necessarily required to 302 store full RSVP state and it is not required to provide MF 303 classification. 305 The diff-serv half of the router provides the interface to the 306 admission control function for the diff-serv network. We shall refer 307 to this function from here on as the 'DACS' (diff-serv admission 308 control service). The DACS is a process that is likely to (but is 309 not required to) run at least partially, on the routers. If the 310 service agreement between the stub networks and the transit networks 311 is statically provisioned then the DACS can be as simple as a table 312 which specifies capacity at each service level. If the service 313 agreement is dynamic, the DACS may communicate with counterparts 314 within the diff-serv network (such as a bandwidth broker [4]) and 315 may be able to make admission control decisions based on provisioned 316 limits as well as the topology and the capacity of the diff-serv 317 network. 319 4.0.3 Boundary Routers 321 These are conventional boundary routers. In the example illustrated, 322 they are not required to run RSVP. They are expected to implement 323 the policing function of diff-serv ingress routers, based on the 324 results of a BA classifier. They may, but are not required, to 325 6 326 Framework for End-to-End QoS March, 1998 328 provide MF classification nor to mark the DS-byte (with the possible 329 exception of the in/out bit). [10, 8] 331 Note that this example places the boundary between the RSVP/Intserv 332 network and the diff-serv network, within the edge routers at the 333 stub networks. In general, this boundary could be shifted to the 334 left or to the right. It could for example, be placed within the 335 boundary routers in the transit network. In this case, the DACS is 336 implemented entirely within the diff-serv network (and is 337 essentially, the bandwidth broker proposed in [4]), but the diff- 338 serv boundary routers must be RSVP capable. 340 4.0.4 Stub Networks 342 The stub networks consist of RSVP capable hosts and some number of 343 leaf routers. Leaf routers within the stub networks may or may not 344 be RSVP capable. Since they are relatively small networks, it is 345 reasonable to assume that they are RSVP capable, but this is not 346 necessary. If they are not RSVP capable, we assume that they will 347 pass RSVP messages unhindered. 349 4.0.5 Transit Network 351 The transit network is not RSVP capable. It provides two or more 352 levels of service based on the DS-bytes in the headers of carried 353 packets (diff-serv capable). Furthermore, the transit network is 354 able to carry RSVP messages transparently, with minimal or no impact 355 on its performance (see [8]). The transit network may include 356 multiple carrier networks. 358 4.0.6 Carrier/Customer Agreement 360 The customer (owner(s) of the leaf networks) and the carrier owning 361 the transit network have negotiated a contract for the capacity to 362 be provided at each of a number of standard diff-serv service 363 levels. The capacity may be statically provisioned. In this case, 364 the DACSs are statically configured with the capacity available at 365 each service level and reside entirely within the edge routers. 366 Alternatively, the capacity may be dynamically variable with a pre- 367 negotiated usage fee and/or a pre-negotiated capacity limit. In this 368 case, the DACS would be required to communicate with counterparts 369 within the diff-serv transit network. 371 4.0.7 Mapping from Intserv Service Type to DS-Byte 373 The current Intserv service types (controlled load and guaranteed) 374 may or may not be practical in the diff-serv network. We assume that 375 a set of end-to-end services that is practical is defined based on 376 concatenation of PHBs (such as proposed in [10]) and that unique 377 code points are allocated for each service in the service type field 378 of the Intserv flowspec. 380 We assume further that there is some standard coding of PHBs in a 381 sub-field of the DS-byte. 382 7 383 Framework for End-to-End QoS March, 1998 385 It follows from the previous two assumptions, that there is a 386 mapping from intserv service type to a sub-field of the DS-byte. 387 Note that there is precedent for the notion of mapping intserv 388 service types to per-packet priority values, specifically in the 389 mapping of service types to 802.1p described in [5]. 391 4.1 How End-to-End QoS is Obtained 393 The following sequence illustrates the process by which an 394 application obtains end-to-end QoS: 396 1. The sending host's QoS process generates an RSVP PATH message, 397 describing the traffic offered by the sending application. 399 2. The PATH message is carried toward the receiving host. In the 400 sending stub network, standard RSVP processing will be applied at 401 RSVP capable nodes (routers, SBMs, etc). 403 3. At ER1, the PATH message is subjected to standard RSVP processing 404 and PATH state is installed in the router. The PATH message is sent 405 onward, to the transit network. 407 4. The PATH message is carried transparently through the transit 408 network. It is processed in the receiving stub network according to 409 standard RSVP processing rules. 411 5. At the receiving host, the QoS process generates an RSVP RESV 412 message, indicating interest in the offered traffic, at a certain 413 intserv service level. 415 6. The RESV message is carried back towards the sending host. 416 Consistent with standard RSVP processing, it may be rejected at any 417 RSVP node in the receiving stub network if resources are deemed 418 insufficient to carry the traffic requested. 420 7. At ER2, the RESV message is subjected to standard RSVP 421 processing. It may be rejected if resources on the downstream 422 interface of ER2 are deemed insufficient to carry the resources 423 requested. If it is not rejected, it will be carried transparently 424 through the transit network, arriving at ER1. 426 8. At this point, the RESV message triggers DACS processing. The 427 DACS compares the resources requested to the resources available at 428 the corresponding diff-serv service level, in the diff-serv enabled 429 transit network. If the RESV message is admitted, the DACS updates 430 the available capacity for the service class, by subtracting the 431 approved resources from the available capacity. 433 9. Assuming the available capacity is sufficient, the RESV message 434 is admitted and is allowed to continue upstream towards the sending 435 host. If the available capacity is insufficient, the RESV message 436 will be rejected. 438 8 439 Framework for End-to-End QoS March, 1998 441 10. The RESV message proceeds through the sending stub network. RSVP 442 nodes in the sending stub network may reject it. If it is not 443 rejected, it will arrive at the sending host. 445 11. At the sending host, the QoS process receives the RESV message. 446 It interprets receipt of the message as an indication that the 447 specified traffic has been admitted for the specified intserv 448 service type (in the RSVP enabled regions of the network) and for 449 the corresponding diff-serv service level (in the diff-serv enabled 450 regions of the network). It begins to set the DS-byte in the headers 451 of transmitted packets, to the value which maps to the Intserv 452 service type specified in the admitted RESV message. 454 In this manner, we are able to obtain end to end QoS through a 455 combination of networks that support RSVP style reservations and 456 networks that support diff-serv style prioritization. The successful 457 arrival of RESV messages at the original sender indicates that 458 admission control has succeeded both in the RSVP regions of the 459 network and in the diff-serv regions of the network. 461 4.2 Variations of the Model 463 It is useful to consider a number of variations of the model 464 presented. 466 4.2.1 Admission Control 468 4.2.1.1 Statically Provisioned Service Agreements 470 In the simplest model, service agreements are negotiated statically 471 between the stub networks and the transit networks. A service 472 agreement consists of a table of capacities available to a 473 customer's stub network, at each diff-serv service level. In this 474 case, DACS functionality is provided at the edge routers in the stub 475 networks. The 'diff-serv half' of these routers appear to the 'RSVP 476 half' as a sending interface with resource limits defined by the 477 service agreement table. While there may be bandwidth brokers and 478 dynamic provisioning within the transit networks, these are not 479 coupled with the intserv stub networks and admission control in the 480 two regions of the network is completely independent. 482 4.2.1.2 Dynamic Service Agreements 484 In a more sophisticated model, service agreements between customer 485 stub networks and carrier transit networks are more dynamic. 486 Customers may be able to dynamically request changes to the service 487 agreement. In this case, a statically provisioned edge router cannot 488 provide the required DACS functionality. Instead, DACS functionality 489 must be provided by coupling the stub network's admission control 490 with the transit network's admission control. 492 The two admission control mechanisms meet at the boundary between 493 the diff-serv network and the intserv network. This boundary may be 495 9 496 Framework for End-to-End QoS March, 1998 498 implemented at the edge router (in the stub network) or at the 499 boundary router (in the transit network). 501 4.2.1.3 Limiting the Impact of Intserv Admission Control on the Diff- 502 serv Network 504 Note that coupling intserv and diff-serv admission control does not 505 imply that each intserv admission control request results in diff- 506 serv admission control work. Instead, intserv admission control 507 requests are aggregated at the boundary between the intserv and the 508 diff-serv network. For example, intserv admission control requests 509 may trigger diff-serv admission control requests to bandwidth 510 brokers only when some high-water or low-water resource threshold is 511 crossed. Separate high-water and low-water thresholds provide 512 hysteresis to prevent thrashing. 514 4.2.1.4 Roles of Policy and Resource Based Admission Control 516 It is necessary to provide both resource and policy based admission 517 control in the diff-serv network as well as the intserv network. In 518 the diff-serv network, resource and policy based admission control 519 are handled by entities such as bandwidth brokers and reflected to 520 the intserv network as DACS (or RSVP). Policy decisions made within 521 the diff-serv network are likely to be at the per-intserv network 522 (per-customer of the diff-serv network) granularity. 524 In the intserv network, resource based admission control is handled 525 by RSVP enabled routers (and SBMs). Policy based admission control 526 is handled by RSVP capable policy servers. These assure that intserv 527 resources are allotted to intserv customers according to policy 528 specific to the intserv network. In addition, policy servers within 529 the intserv network must also assure that appropriate policy is 530 applied when diff-serv resources are allotted to intserv customers. 532 4.2.2 Setting the DS-Byte at Intermediate Nodes 534 In the example described, hosts use RSVP signaling and mark the DS- 535 byte corresponding to the admitted service level. Note that these 536 functions can be separated. In the example, the function of RSVP 537 signaling is to invoke QoS in the intserv network and to provide 538 end-to-end admission control. The function of marking the DS-byte is 539 to eliminate the need for MF classification at routers. 541 It is possible to mark the DS-byte at intermediate routers rather 542 than at the host and still to realize many of the benefits of our 543 approach. In this case, intermediate routers may use the RSVP 544 signaling to configure an MF classifier and marker. Therefore, the 545 configuration of MF classifiers and markers is dynamic (minimizing 546 the management burden) and full resource and policy based admission 547 control can be applied. 549 The disadvantages of marking the DS-byte at intermediate routers 550 (instead of the host) are that full MF classifiers are required at 552 10 553 Framework for End-to-End QoS March, 1998 555 the intermediate nodes and that responsibility for traffic 556 separation is shifted away from the host. 558 Nonetheless, this approach is necessary to support those hosts which 559 may be capable of RSVP signaling, but which are not capable of 560 marking the DS-byte. In addition, there may be cases in which the 561 network administrators wish to shift the responsibility for traffic 562 separation away from the hosts. 564 4.2.3 Supporting Various Levels of Host Functionality 566 We identify four levels of host functionality, as follows: 568 1. Legacy hosts, incapable of any form of QoS signaling. 569 2. Hosts capable of RSVP signaling but not of marking DS-bytes. 570 3. Hosts capable of marking DS-bytes but not of RSVP signaling. 571 4. Hosts capable of both RSVP signaling and marking DS-bytes. 573 Hosts providing any of the above levels of functionality can co- 574 exist in our model. However, the advantages of the model may not be 575 fully realizable with certain combinations. In the following 576 paragraph, we consider as an example, the coexistence of legacy 577 hosts and of hosts that are capable both of RSVP signaling and of 578 marking DS-bytes. 580 When legacy hosts are required to coexist with hosts that are 581 capable both of RSVP signaling and of marking DS-bytes, stub network 582 administrators partition stub network resources between the two 583 types of hosts. Legacy hosts rely on a router to mark DS-bytes based 584 on the output of a statically configured MF classifier. This router 585 could reside within the stub network or alternatively, the edge or 586 boundary router could be configured to provide this functionality. A 587 policer is also required at this router. The policer is statically 588 configured to limit the consumption of diff-serv resources by the 589 legacy hosts. The network administrator statically allocates the 590 remaining diff-serv resources to the hosts that are capable of RSVP 591 signaling by configuring the appropriate limits in the intserv 592 enabled region of the stub network. 594 We see that support for legacy hosts requires both MF classification 595 and marking in intermediate routers as well as static allocation of 596 resources by the network administrator. Hosts that are capable of 597 marking the DS-byte eliminate the need for intermediate routers to 598 provide MF classification. Hosts that are capable of signaling RSVP 599 (and which use the result of this signaling to control transmission 600 to the network), alleviate the need for static configuration as a 601 form of admission control. 603 4.3 Issues 605 4.3.1 Setting the DS-Byte at Hosts 607 The thought of allowing hosts to set the DS-byte directly, may alarm 608 network administrators. The obvious concern is that hosts may 610 11 611 Framework for End-to-End QoS March, 1998 613 attempt to 'steal' resources. In fact, hosts may attempt to exceed 614 the negotiated capacity at a particular service level regardless of 615 whether they invoke this service level directly (by setting the DS- 616 byte) or indirectly (by submitting traffic that classifies in an 617 intermediate router to a particular diff-serv PHB). 619 In either case, it may be necessary to protect the network by 620 policing at various points, both within the stub network and/or at 621 the interface to the transit network. This assures that customers do 622 not use more resources than they are entitled to, at each service 623 level. If the sending host does not do the marking, intermeidate 624 and/or boundary routers must provide MF classification, mark and 625 police. If the sending host does do the marking, these routers need 626 only to provide BA classification and to police to ensure that the 627 customer is not exceeding the aggregate capacity negotiated for the 628 service level. 630 Requiring hosts to mark the DS-byte has the effect of moving 631 responsibility to the edge of the network, in more ways than one. 632 With this approach, boundary routers police in aggregate. As a 633 result, the customer cannot rely on boundary routers to provide 634 traffic isolation between the customer's flows, when policing or 635 shaping. Instead, it is the customer's responsibility to ensure 636 that the customer's flows are properly shaped within the customer's 637 sending network. 639 Ideally, hosts should provide per-flow shaping at their sending 640 interfaces. However, there is always a chance that the customer's 641 traffic will become distorted as it nears the boundary between the 642 customer and the carrier. In this case, the customer may chose to 643 provide per flow policing (or even re-shaping) at the egress point 644 from the customer's network. 646 In summary, the security concerns of marking the DS-byte at the edge 647 of the network can be dismissed since each carrier will have to 648 police at their boundary anyway. Furthermore, this approach reduces 649 the granularity at which boundary routers must police, thereby 650 pushing finer grain shaping and policing responsibility to the edges 651 of the network, where it scales better. The carriers are thus 652 focused on the task of protecting their transit networks, while the 653 customers are focused on the task of shaping and policing their own 654 traffic to be in compliance with their negotiated token bucket 655 parameters. 657 4.3.2 In/Out Bits 659 Diff-serv proposals call for the DS-byte to be used to indicate a 660 PHB, as well as whether a particular packet is 'in' or 'out' of 661 profile. In our proposal, we recommend that hosts set at least the 662 bits that indicate the PHB. This does not preclude hosts from 663 setting the in/out bit as well. For example, hosts with 664 sophisticated traffic shaping features may allow applications to 665 occasionally burst beyond the negotiated token bucket parameters and 666 may apply their own policing by marking excess packets as 'out'. 667 12 668 Framework for End-to-End QoS March, 1998 670 This does not compromise the transit network, since it will be 671 policing and may remark the in/out bit. 673 4.3.3 End-to-End Integrity of the DS-Byte 675 Our proposal assumes that hosts use a standard coding for specifying 676 a desired PHB in some sub-field of the DS-byte. It also assumes that 677 packets submitted to the network with a certain PHB specified, will 678 receive a standard service throughout the diff-serv network. 679 Strictly speaking, this does not dictate that the transit network 680 must leave the PHB field intact. However, we see little value in 681 allowing the PHB field to be altered within the network. This is 682 likely to perpetuate local and incompatible interpretations of the 683 field. 685 4.3.4 Carrying RSVP Messages across Transit Networks 687 Our proposal presumes end-to-end RSVP both as a means for 688 communication between sending host and receiving host and 689 optionally, for the support of true RSVP reservations in stub 690 networks (or in intermediate networks which are interested in the 691 fine grain RSVP information). Therefore, we require that RSVP 692 messages be carried across the transit networks. In [8] mechanisms 693 are proposed for doing so in a manner that does not adversely impact 694 the transit network. 696 5. Dependencies of Intserv on Diff-Serv 698 We have described a framework for end-to-end QoS in which intserv 699 networks are customers of diff-serv networks. We believe that the 700 benefits of this framework are sufficient to justify the 701 consideration of intserv dependencies as diff-serv work proceeds. In 702 particular, we wish to draw attention to the following dependencies: 704 1. We expect that we can invoke a standard end-to-end (within the 705 diff-serv network) service by specifying a standard code in a (PHB) 706 sub-field of the DS-byte of a packet launched into a diff-serv 707 network. 708 2. Diff-serv networks must provide admission control information to 709 the intserv network. At the very least, this is through static 710 service level agreements. Preferably, this is through a dynamic 711 protocol. If the intserv to diff-serv boundary is implemented in the 712 transit network boundary routers, then this protocol is RSVP. 713 3. We expect that diff-serv networks will carry RSVP messages such 714 that they can be recovered at the egress point from the diff-serv 715 network. 717 8. Security Considerations 719 We are proposing that RSVP signaling be used to obtain resources in 720 both the diff-serv and intserv regions of the network. Therefore, 721 all RSVP security considerations apply [11]. In addition, network 722 administrators are expected to protect network resources by 723 configuring secure policers at interfaces with untrusted customers. 725 13 726 Framework for End-to-End QoS March, 1998 728 9. References 730 [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., 731 "Resource Reservation Protocol (RSVP) � Version 1 Functional 732 Specification", RFC 2205, Proposed Standard, September 1997 734 [2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M., 735 "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based Admission 736 Control Over IEEE 802 Style Networks", Internet Draft, March 1998 738 [3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated 739 Services State", Internet Draft, December 1997. 741 [4] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit 742 Differentiated Services Architecture for the Internet", Internet 743 Draft, December 1997. 745 [5] Seaman, M., Smith, A. and Crawley, E., "Integrated Services Over 746 IEEE 802.1D/802.1p Networks", Internet Draft, June 1997 748 [6] Elleson, E. and Blake, S., "A Proposal for the Format and 749 Semantics of the TOS Byte and Traffic Class Byte in Ipv4 and Ipv6 750 Headers", Internet Draft, November 1997 752 [7] Ferguson, P., "Simple Differential Services: IP TOS and 753 Precedence, Delay Indication, and Drop Preference", Internet Draft, 754 November 1997 756 [8] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based 757 QoS Requests", Internet Draft, November 1997 759 [9] Clark, D. and Wroclawski, J., "An Approach to Service 760 Allocation in the Internet", Internet Draft, July 1997 762 [10] Blake, S. and Nichols, K., "Differentiated Services Operational 763 Model and Definitions", Internet Draft, February 1998 765 [11] Baker, F., "RSVP Cryptographic Authentication", Internet Draft, 766 August 1997 768 [12] Braden, R., Clark, D. and Shenker, S., "Integrated Services in 769 the Internet Architecture: an Overview", Internet RFC 1633, June 770 1994 772 10. Acknowledgments 774 11. Author's Addresses 776 Yoram Bernet 777 Microsoft 778 One Microsoft Way, 779 Redmond, WA 98052 780 Phone: (425) 936-9568 781 14 782 Framework for End-to-End QoS March, 1998 784 Email: yoramb@microsoft.com 786 Raj Yavatkar 787 Intel Corporation, JF3-206 788 2111 NE 25th. Avenue, 789 Hillsboro, OR 97124 790 Phone: (503) 264-9077 791 Email: yavatkar@ibeam.intel.com 793 Peter Ford 794 Microsoft 795 One Microsoft Way, 796 Redmond, WA 98052 797 Phone: (425) 703-2032 798 Email: peterf@microsoft.com 800 Fred Baker 801 Cisco Systems 802 519 Lado Drive, 803 Santa Barbara, CA 93111 804 Phone: (408) 526-4257 805 Email: fred@cisco.com 807 Lixia Zhang 808 UCLA 809 4531G Boelter Hall 810 Los Angeles, CA 90095 811 Phone: (310_825-2695 812 Email: lixia@cs.ucla.edu 814 15