idnits 2.17.1 draft-ietf-diffserv-rsvp-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 20 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Abstract' ) ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 9. Security Considerations' ) ** 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 an Authors' Addresses Section. ** There are 5 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 522 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [10,8], [7], [8], [9], [10], [11], [12], [13], [14], [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) -- Missing reference section? '12' on line 942 looks like a reference -- Missing reference section? '1' on line 904 looks like a reference -- Missing reference section? '10' on line 936 looks like a reference -- Missing reference section? '8' on line 930 looks like a reference -- Missing reference section? '4' on line 915 looks like a reference -- Missing reference section? '13' on line 946 looks like a reference -- Missing reference section? '5' on line 919 looks like a reference -- Missing reference section? '2' on line 908 looks like a reference -- Missing reference section? '14' on line 952 looks like a reference -- Missing reference section? '11' on line 939 looks like a reference -- Missing reference section? '3' on line 912 looks like a reference -- Missing reference section? '6' on line 922 looks like a reference -- Missing reference section? '7' on line 926 looks like a reference -- Missing reference section? '9' on line 933 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 3 warnings (==), 16 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-ietf-diffserv-rsvp-01.txt P. Ford, Microsoft 5 F. Baker, Cisco 6 L. Zhang, UCLA 7 K. Nichols, Cisco Systems 8 M. Speer, Sun Microsystems 10 November, 1998 12 A Framework for Use of RSVP with Diff-serv Networks 14 Status of this Memo 16 This document is an Internet Draft. Internet Drafts are working documents of 17 the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. 18 Note that other groups may also distribute working documents as Internet 19 Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a 25 "working draft" or "work in progress". 26 To view the entire list of current Internet-Drafts, please check 27 the "1id-abstracts.txt" listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 29 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 30 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 31 (US West Coast). 33 A revised version of this draft document will be submitted to the 34 RFC editor as an Informational RFC for the Internet Community. 35 Discussion and suggestions for improvement are requested. This 36 document will expire before May 1999. Distribution of this 37 draft is unlimited. 39 Use Of RSVP with Diffserv June, 1998 41 1. Abstract 43 In the past several years, work on QoS enabled networks led to the 44 development of the Integrated Services (Intserv) architecture [12] and 45 the RSVP signaling protocol [1]. RSVP, as specified, enables applica- 46 tions to signal per-flow requirements to the network. Intserv parame- 47 ters are used to quantify these requirements for the purpose of admis- 48 sion control. However, as work on RSVP and Intserv has proceeded, we 49 have recognized the following basic limitations, which impede deploy- 50 ment of these mechanisms in the Internet at large: 52 1) The reliance of RSVP on per-flow state and per-flow processing 53 raises scalability concerns in large networks. 54 2) Today, only a small number of hosts generate RSVP signaling. 55 While this number is expected to grow dramatically, many 56 applications may never generate RSVP signaling. 57 3) Many applications require a form of QoS, but are unable to 58 express these requirements using the intserv model. 60 At present, the market is pushing for immediate deployment of a QoS 61 solution that addresses the needs of the Internet as well as enter- 62 prise networks. This push has led to the development of Differentiated 63 services (diff-serv). In contrast to RSVP's per-flow orientation, 64 diff-serv networks classify packets to one of a small number of aggre- 65 gated flows, based on the setting of bits in the TOS field of each 66 packet's IP header. Thus, in addition to eliminating the reliance on 67 per-flow state, diff-serv QoS can initially be deployed using top-down 68 provisioning, with no requirement for end-to-end signaling. 70 At the same time however, it is important to assure that the diff-serv 71 mechanisms deployed, interoperate effectively with hosts and networks 72 that provide per-flow QoS in response to end-to-end signaling. This is 73 important, as we believe that in the coming years, there will be a 74 proliferation of applications that depend on QoS and of hosts which 75 will signal end-to-end on their behalf. 77 This draft proposes a framework in which diff-serv capable networks 78 provide aggregate QoS services, and they co-exist and inter-operate 79 with RSVP/Intserv capable hosts and stub networks, which use end-to- 80 end signaling. 82 For instance, in one example of such a model, diff-serv mechanisms are 83 used within transit networks and at the boundaries between them, while 84 either diff-serv or RSVP/Intserv mechanisms are used within stub net- 85 works and at the boundaries between stub networks and transit diff- 86 serv networks. Managers of the transit networks will provision a pool 87 of network resources to be available in response to end-to-end signal- 88 ing. The remaining resources will be allotted using traditional 'top- 90 Use Of RSVP with Diffserv June, 1998 92 down' provisioning methods. 94 However, our model does not preclude other possibilities: use of 95 diff-serv mechanisms and top-down provisioning in both stub and tran- 96 sit networks to support applications that do not use any explicit sig- 97 naling, or use of RSVP signaling for admission control in conjunction 98 with diff-serv mechanisms in transit networks. In particular, the pro- 99 posed framework will allow for a scenario in which RSVP signaling is 100 used for dynamic provisioning and admission control in the diffserv 101 region of the network. In such a case, routers in the diff-serv region 102 will continue use the DSCP value in the IP datagram to identify and 103 offer services to flow aggregates. However, some of these services 104 will use dynamic provisioning and require admission control using 105 explicit signaling when a new flow is to be added to the aggregate. 106 Under such a scenario, one can envision use of RSVP signaling to com- 107 municate the flow specification and desired DSCP (flow aggregate) to 108 the routers in the diff-serv region of the network. 110 Our framework allows the deployment of diff-serv networks and 111 RSVP/Intserv networks to proceed at their own pace, providing immedi- 112 ate incremental benefits in areas of the network in which one or the 113 other is deployed and additional benefits where both are deployed. 114 This framework builds upon current work in the IETF including diff- 115 serv [10] and RSVP aggregation [8]. 117 Many of the ideas in this document have been previously discussed in 118 the original intserv architecture document [12]. 120 2. Goals of This Draft 122 This draft is based on the assumption that end-to-end QoS is required 123 to support the needs of certain applications. Such applications 124 include IP-telephony, video-on-demand, and various non-multimedia 125 mission-critical applications. 127 In our view, intserv and diff-serv are complementary tools in the pur- 128 suit of end-to-end QoS. Each serves an important purpose in the end- 129 to-end QoS enabled network. The primary goal of this draft is to 130 encourage the continued development of each in a manner that does not 131 preclude realization of the proposed framework. To this end, we will: 133 1. List the requirements of a network that provides end-to-end QoS. 134 2. Present a framework that uses intserv as a customer of diff-serv 135 to meet these requirements. 136 3. Identify dependencies of intserv on diff-serv. 138 Ultimately, we aim to clearly define a manner in which RSVP/Intserv 140 Use Of RSVP with Diffserv June, 1998 142 and diff-serv mechanisms interact seamlessly. We expect that by doing 143 so, we will enable network administrators to determine the degree to 144 which diff-serv capabilities are pushed towards the edge of their net- 145 works (or, the degree to which RSVP/Intserv capabilities are pushed 146 towards the core). 148 Even though one of the goals of this draft is to describe a framework 149 for co-existence of RSVP/intserv with diff-serv, the draft currently 150 does not address the issues specific to IP multicast flows such as 151 merging dissimilar reservations. 153 3. Terminology 155 The following terms are used in this draft: 157 a. Intserv region (or intserv capable network) - the part of an 158 internet that uses per-flow identification, signaling, and admission 159 control to deliver per-flow QoS guarantees 161 b. Diff-serv region (or diff-serv capable network) - the part of an 162 internet that provides aggregate QoS services 164 c. Quantitative QoS applications - applications for which QoS 165 requirements are readily quantifiable, and which rely on these QoS 166 requirements to function properly. 168 d. Qualitative QoS applications - applications for which relative 169 QoS requirements exist, but are not readily quantifiable. 171 e. QoS applications - applications that require some form of QoS, 172 either qualitative or quantitative. 174 f. Loose QoS - QoS assurances which are relative, rather than 175 absolute, or generally not quantifiable. 177 g. Tight QoS - QoS assurances which are quantifiable, 178 though they may or may not provide 100% guarantee. 180 h. Top-down (or open-loop) provisioning - traditional provisioning 181 methods which configure network capacities using heuristics and 182 experience, typically from a console, with no explicit knowledge of 183 exact traffic volumes or exact paths taken by the affected traffic. 185 i. RSVP/Intserv - RSVP is a signaling protocol. Intserv (in this 186 context) is a model for quantifying traffic that is useful for 187 admission control purposes. In this document, we use the terms 188 together, to discuss the RSVP/Intserv network, in contrast to the 189 diff-serv network. However, the two are separable and much of the 191 Use Of RSVP with Diffserv June, 1998 193 following discussion could be applied to a model in which RSVP 194 signals using parameters that are not Intserv specific. 196 4. Requirements for the End-to-End QoS Framework An end-to-end QoS 197 network must serve the requirements of network managers as well as 198 those of both quantitative and qualitative QoS applications. We con- 199 sider these requirements in the context of the following general 200 topology: 202 / Stub \ / Transit \ / Stub \ 203 / Network \ / Network \ / Network \ 204 |---| | |---| |---| |---| |---| | |---| 205 |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx | 206 |---| | |-- | |---| |---| |---| | |---| 207 \ / \ / \ / 208 \ / \ / \ / 210 Figure 1: Sample Network Configuration 212 This network consists of a diff-serv capable transit network and two 213 intserv capable stub networks. In the interest of simplicity, we show 214 a single QoS sender on one of the stub networks and a single QoS 215 receiver on the other. We show edge routers (ER1, ER2) at the inter- 216 faces of the intserv networks to the diff-serv network. We show boun- 217 dary routers (BR1, BR2) at the interfaces of the diff-serv network to 218 the intserv networks. 220 The transit network contains a mesh of routers, at least some of which 221 are diff-serv capable. The stub networks contain a mesh of routers, at 222 least some of which are intserv capable. 224 We define the following requirements of the framework: 226 4.1 Definition of a Set of Services 228 There must be a set of useful end-to-end services available to Quanti- 229 tative QoS applications. Routers internal to the diff-serv network are 230 assumed to provide a set of 'per-hop-behaviors' (PHBs [10]). We expect 231 that concatenation of certain well-defined PHBs will yield certain 232 well-understood services across the diff-serv network. We also expect 233 that the intserv regions of the network will be able to extend these 234 services such that they can be realized in a true end-to-end manner. 236 In addition, there must be a set of end-to-end services available to 237 Qualitative QoS applications. However, the services that these 239 Use Of RSVP with Diffserv June, 1998 241 applications require are generally less demanding. They can be loosely 242 provisioned (in a top-down manner) in the diff-serv regions of the 243 network and will likely receive best-effort treatment in the intserv 244 regions of the network. 246 In this draft we focus primarily on the requirements of quantitative 247 QoS applications. Although these may generate only a small fraction of 248 all traffic, servicing this traffic may comprise a significant frac- 249 tion of the revenues associated with QoS. In addition, while qualita- 250 tive QoS applications can be satisfied by conventional diff-serv 251 alone, quantitative QoS applications require additional support. 253 4.2 Allotment of Diff-serv Service Levels to Specific Traffic Flows 255 It must be possible for QoS applications to invoke specific end-to-end 256 service levels for their traffic flows. Within the intserv regions of 257 the network quantitative QoS applications do so by using RSVP signal- 258 ing to configure classifiers which operate on IP addresses and port 259 numbers. We will refer to such classifiers from here on as 'MF' clas- 260 sifiers [10]. 262 Within the diff-serv regions of the network, traffic is allotted ser- 263 vice based on the contents of the DS-field in packet headers. There- 264 fore, it is necessary for QoS applications to effect the correct mark- 265 ing of DS-fields before their packets are submitted to the diff-serv 266 network. (This is particularly true for quantitative QoS applications, 267 less so for qualitative QoS applications that need not play as active 268 a role in securing specific QoS from the network). There are two gen- 269 eral mechanisms for doing so: 271 1. Hosts may directly mark DS-fields in the transmitted packets of 272 QoS applications. 273 2. Routers external to the diff-serv network may mark DS-fields on 274 behalf of QoS applications based on MF classification. 276 In the first case, marking will be done based on host configuration or 277 local communication between QoS applications and the host operating 278 system. In the second case, marking will be done based on top-down 279 configuration of the marking router's MF classifier/marker (by manual 280 configuration or via automated configuration scripts) or based on 281 standard signaling between QoS applications and the marking router's 282 classifier/marker. 284 The following three requirements argue either for host based marking 285 or for dynamic configuration of a router's classifier/marker in 286 response to application requests. 288 4.2.1 Minimal Management Burden 290 Use Of RSVP with Diffserv June, 1998 292 The information required to express useful mappings of application 293 traffic flows to service levels is likely to be quite complex and to 294 change frequently. Thus, manual configuration is likely to impose a 295 significant management burden. If the configuration information is 296 very simple and does not change over time, the management burden may 297 be relatively minor. However, this means that the granularity of 298 allotting service levels to flows will be sub-optimal. 300 4.2.2 Granularity of Allotment 302 The term 'granularity' is used here to refer to the degree of specifi- 303 city that is available in allotting a specific service level to a 304 specific traffic flow. There are two measures of granularity; one is 305 the granularity with which an individual flow or a group of flows is 306 identified. The other is the frequency at which the service allotted 307 to a flow may change. A fine grain QoS system would allow the follow- 308 ing requirement to be expressed: telephony traffic from user X should 309 be allotted service level A, while telephony traffic from user Y 310 should be allotted service level B, and web traffic from any user 311 should be allotted service level C. A coarse grain system would be 312 limited to something of the form: all traffic from subnet 1.0.0.0 313 should receive service level A, while all traffic from subnet 2.0.0.0 314 should receive service level B. A temporally fine grain system would 315 allow immediate changes in allotment of service levels to traffic 316 flows. A temporally coarse grain system may allow infrequent changes 317 only. 319 4.2.3 Difficulties in Identification of Application Flows 321 Routers may not be able to readily identify specific application flows 322 based on network and/or transport layer fields in a packet. 324 For example, consider the need to give preferential service to a 325 website's home page (over other, less important pages at the site) or 326 the case of encrypted traffic flows (IPSEC). 328 4.3 Admission Control 330 Quantitative QoS applications use RSVP to request that their flows be 331 admitted to intserv regions of the network. When a request is 332 rejected, the host application may avoid sending traffic and/or inter- 333 mediate RSVP capable nodes will only give best-effort service to 334 traffic on flows that were not admitted. These mechanisms protect 335 traffic on flows that were admitted. 337 In diff-serv regions of the network, admission control is provided 338 implicitly, by policing at ingress points based on provisioning. The 339 problem with implicit admission control is that it breaks the end-to- 341 Use Of RSVP with Diffserv June, 1998 343 end validity of explicit admission control. Specifically, an applica- 344 tion may gain admission using RSVP signaling, even though there is no 345 capacity for that application's traffic within the diff-serv region of 346 the network. Neither the application, nor intermediate RSVP capable 347 nodes will be aware that the application's traffic is not admissible. 348 As a result, neither can take corrective action and all traffic from 349 that customer, at the corresponding service level, may be compromised. 350 This failure may be partially, but not completely alleviated by polic- 351 ing based on MF classification at the diff-serv ingress (rather than 352 BA classification [10]). 354 End-to-end QoS requires that quantitative QoS applications and RSVP 355 capable intserv nodes be explicitly informed of admission control 356 failure in the diff-serv network. This enables them to take corrective 357 action and to avoid overdriving the diff-serv network. If the service 358 agreement between the intserv and diff-serv regions of the network is 359 statically provisioned, then admission control functionality can be 360 provided by static configuration of admission control in intserv edge 361 routers. However, if the service agreement is dynamically variable, 362 then it will be necessary to dynamically propagate current diff-serv 363 resource availability to the intserv network for the purpose of expli- 364 cit admission control. 366 4.4 Policy Support 368 End-to-end QoS leads to preferential treatment of certain traffic 369 flows over others. Within diff-serv regions of the network, policy 370 applies on a per-customer basis. In general, the diff-serv network 371 makes multiple service levels available to a single customer's intserv 372 network. In this case the customer must apply policy within its net- 373 work to assure appropriate allocation of resources (customer network 374 resources as well as diff-serv network resources) to individual hosts 375 in the customer's network. This requires that end-to-end admission 376 control be based on policy as well as resource availability. 378 5. Intserv as a Customer of Diff-serv 380 To meet the above requirements, we envision a network that consists 381 typically of relatively smaller, intserv capable stub networks, con- 382 nected by larger, diff-serv capable transit networks. In this sec- 383 tion, we will describe the operation of one instantiation of such a 384 network (see figure 1). The following assumptions apply: 386 5.1.1 Host Capabilities 388 Both sending and receiving hosts use RSVP to communicate QoS require- 389 ments of certain QoS aware applications running on the host. A QoS 390 process within the host operating system generates RSVP signaling on 392 Use Of RSVP with Diffserv June, 1998 394 behalf of the applications. This process also invokes traffic control. 395 Host traffic control includes marking the DS-field in transmitted 396 packets and shaping transmitted traffic per token bucket specifica- 397 tions. Note that host traffic control is assumed for this specific 398 example, but is not a requirement of the framework in general. Leaf 399 routers within the intserv network may provide the traffic control 400 functions. 402 5.1.2 Edge Routers 404 The edge routers are special routers that straddle the boundary 405 between the RSVP/Intserv region of the network and the diff-serv 406 region of the network. It is helpful to think of these routers as con- 407 sisting of two halves; the standard RSVP half, which interfaces to the 408 stub networks, and the diff-serv half, which interfaces to the transit 409 network. 411 The RSVP half is at least partially RSVP capable; it is able to pro- 412 cess PATH and RESV messages but it is not necessarily required to 413 store full RSVP state and it is not required to provide MF classifica- 414 tion. 416 The diff-serv half of the router provides the interface to the admis- 417 sion control function for the diff-serv network. We shall refer to 418 this function from here on as the 'DACS' (diff-serv admission control 419 service). The DACS is a process that is likely to (but is not required 420 to) run at least partially, on the routers. If the service agreement 421 between the stub networks and the transit networks is statically pro- 422 visioned then the DACS can be as simple as a table which specifies 423 capacity at each service level. If the service agreement is dynamic, 424 the DACS may communicate with counterparts within the diff-serv net- 425 work (such as a bandwidth broker [4]) and may be able to make admis- 426 sion control decisions based on provisioned limits as well as the 427 topology and the capacity of the diff-serv network. 429 5.1.3 Boundary Routers 431 These are conventional boundary routers. In the example illustrated, 432 they are not required to run RSVP. They are expected to implement the 433 policing function of diff-serv ingress routers, based on the results 434 of a BA classifier. They are neither required to provide MF classifi- 435 cation nor must mark the DS-field (with the possible exception of dif- 436 ferential marking to indicate out of profile traffic [10, 8]). Note 437 that this example places the boundary between the RSVP/Intserv network 438 and the diff-serv network, within the edge routers at the stub net- 439 works. In general, this boundary could be shifted to the left or to 440 the right. It could for example, be placed within the boundary routers 441 in the transit network. In this case, the DACS is implemented 443 Use Of RSVP with Diffserv June, 1998 445 entirely within the diff-serv network (and is essentially, the 446 bandwidth broker proposed in [4]), but the diff-serv boundary routers 447 must be RSVP capable. 449 5.1.4 Stub Networks 451 The stub networks consist of int-serv capable hosts and some number of 452 leaf routers. Leaf routers within the stub networks may or may not be 453 int-serv capable. Since they are relatively small networks, it is rea- 454 sonable to assume that they are int-serv capable, but this is not 455 necessary. If they are not int-serv capable, we assume that they are 456 not capable of per-flow identification, signaling, and admission con- 457 trol and, in that case, will pass RSVP messages (requesting per-flow 458 QoS) unhindered. 460 5.1.5 Transit Network 462 The transit network is not typically capable of per-flow identifica- 463 tion, signaling, and admission control. It provides two or more levels 464 of service based on the DS-field in the headers of carried packets 465 (diff-serv capable). Furthermore, the transit network is able to carry 466 RSVP messages transparently, with minimal or no impact on its perfor- 467 mance (see [8]). The transit network may include multiple carrier net- 468 works. 470 5.1.6 Carrier/Customer Agreement 472 The customer (owner(s) of the leaf networks) and the carrier owning 473 the transit network have negotiated a contract for the capacity to be 474 provided at each of a number of standard diff-serv service levels. The 475 capacity may be statically provisioned. In this case, the DACSs are 476 statically configured with the capacity available at each service 477 level and reside entirely within the edge routers. Alternatively, the 478 capacity may be dynamically variable with a pre-negotiated usage fee 479 and/or a pre-negotiated capacity limit. In this case, the DACS would 480 be required to communicate with counterparts within the diff-serv 481 transit network depending on the granularity of allotment (temporally 482 coarse or temporally fine grained). 484 5.1.7 Mapping from Intserv Service Type to DS-field 486 In our proposal, we use RSVP signaling to provide admission control to 487 specific service levels in the diff-serv, as well as the intserv net- 488 work. RSVP signaling requests carry an intserv service type, describ- 489 ing the type of service they expect from the intserv regions of the 490 network. At each hop in an intserv network, the generic intserv ser- 491 vice requests are interpreted in a form meaningful to the specific 492 media. For example, at an ATM hop, a VC of the correct type (CBR, ABR 494 Use Of RSVP with Diffserv June, 1998 496 or VBR) is established [13]. At an 802.1 hop, the intserv service type 497 is mapped to an appropriate 802.1p priority level [5]. 499 Similar mapping is necessary from Intserv Service type to DS-field. At 500 the boundary between the intserv network and a diff-serv network, it 501 is necessary for edge devices to map the requested intserv service to 502 a diff-serv service level that can reasonably extend the intserv ser- 503 vice type requested by the application. The edge device can then pro- 504 vide admission control to the diff-serv network by accepting or 505 rejecting the request based on the capacity available at the requested 506 diff-serv service level. 508 We assume that one of two schemes is used to map intserv service types 509 to diff-serv service levels. In the first scheme (called "default map- 510 ping"), we propose a standard, well-known mapping from intserv service 511 type to a PHB that will invoke the appropriate behavior in the diff- 512 serv network. The mapping is not necessarily one-to-one. For example, 513 controlled-load interactive voice traffic will likely map to a PHB 514 having different latency characteristics than controlled-load latency 515 tolerant traffic. For this reason we suggest adding a qualifier to the 516 intserv service type indicating its relative latency tolerance (high 517 or low). The qualifier would be defined as a standard object in 518 intserv signaling messages. 520 In an alternate scheme (called "customer-specified mapping"), we allow 521 the devices at the edge of the diff-serv region of the network to 522 modify the well-known mapping. Under this approach, RESV messages ori- 523 ginating at hosts carry the usual intserv service type (with a qualif- 524 ier, as described above). When RESV messages arrive at the interface 525 of the int-serv and diff-serv regions (e.g. router ER1 in Figure 1, 526 where the traffic from the stub network enters the diff-serv region), 527 the edge device will determine the PHB that should be used to obtain 528 the corresponding diff-serv service level. This value is appended to 529 the RESV message by the edge device and is carried to the sending 530 host. When the RESV message arrives at the sending host, the sender 531 (or intermediate intserv routers) will mark outgoing packets with the 532 indicated PHBs. 534 The decision to modify the well-known mapping at the edge devices will 535 be based on edge-device configuration and/or policy decision at the 536 edges. For example, when a reservation arrives at the edge of diff- 537 serv network and if enough reservations have already been accepted to 538 reach the pre-negotiated capacity limit at the corresponding service 539 level, the device may decide to use a PHB corresponding to a different 540 (less assured?) service level based on an administratively set policy. 542 5.2 How End-to-End QoS is Obtained 544 Use Of RSVP with Diffserv June, 1998 546 The following sequence illustrates the process by which an application 547 obtains end-to-end QoS: 549 1. The sending host's QoS process generates an RSVP PATH message, 550 describing the traffic offered by the sending application. 552 2. The PATH message is carried toward the receiving host. In the 553 sending stub network, standard RSVP processing will be applied at 554 RSVP capable nodes (routers, SBMs, etc). 556 3. At ER1, the PATH message is subjected to standard RSVP processing 557 and PATH state is installed in the router. The PATH message is sent 558 onward, to the transit network. 560 4. The PATH message is carried transparently through the transit 561 network. It is processed in the receiving stub network according to 562 standard RSVP processing rules. 564 5. At the receiving host, the QoS process generates an RSVP RESV 565 message, indicating interest in the offered traffic, at a certain 566 intserv service level. 568 6. The RESV message is carried back towards the sending host. 569 Consistent with standard RSVP processing, it may be rejected at any 570 RSVP node in the receiving stub network if resources are deemed 571 insufficient to carry the traffic requested. 573 7. At ER2, the RESV message is subjected to standard RSVP 574 processing. It may be rejected if resources on the downstream 575 interface of ER2 are deemed insufficient to carry the resources 576 requested. If it is not rejected, it will be carried transparently 577 through the transit network, arriving at ER1. 579 8. At this point, the RESV message triggers DACS processing. The 580 DACS compares the resources requested to the resources available at 581 the corresponding diff-serv service level, in the diff-serv enabled 582 transit network. If the RESV message is admitted, the DACS updates 583 the available capacity for the service class, by subtracting the 584 approved resources from the available capacity. 586 9. Assuming the available capacity is sufficient, the RESV message 587 is admitted and is allowed to continue upstream towards the sending 588 host. If the available capacity is insufficient, the RESV message 589 will be rejected and the available capacity for the service class 590 will remain unchanged. 592 10. The RESV message proceeds through the sending stub network. RSVP 593 nodes in the sending stub network may reject it. If it is not 595 Use Of RSVP with Diffserv June, 1998 597 rejected, it will arrive at the sending host. 599 11. At the sending host, the QoS process receives the RESV message. 600 It interprets receipt of the message as an indication that the 601 specified traffic has been admitted for the specified intserv 602 service type (in the RSVP enabled regions of the network) and for 603 the corresponding diff-serv service level (in the diff-serv enabled 604 regions of the network). It begins to set the DS-field in the headers 605 of transmitted packets, to the value which maps to the Intserv 606 service type specified in the admitted RESV message. 608 In this manner, we are able to obtain end to end QoS through a combi- 609 nation of networks that support RSVP style reservations and networks 610 that support diff-serv style prioritization. The successful arrival of 611 RESV messages at the original sender indicates that admission control 612 has succeeded both in the RSVP regions of the network and in the 613 diff-serv regions of the network. 615 5.3 Variations of the Model 617 It is useful to consider a number of variations of the model 618 presented. 620 5.3.1 Admission Control 622 5.3.1.1 Statically Provisioned Service Agreements 624 In the simplest model, service agreements are negotiated statically 625 between the stub networks and the transit networks. A service agree- 626 ment consists of a table of capacities available to a customer's stub 627 network, at each diff-serv service level. In this case, DACS func- 628 tionality is provided at the edge routers in the stub networks. The 629 'diff-serv half' of these routers appear to the 'RSVP half' as a send- 630 ing interface with resource limits defined by the service agreement 631 table. While there may be bandwidth brokers and dynamic provisioning 632 within the transit networks, these are not coupled with the intserv 633 stub networks and admission control in the two regions of the network 634 is completely independent. 636 5.3.1.2 Dynamic Service Agreements 638 In a more sophisticated model, service agreements between customer 639 stub networks and carrier transit networks are more dynamic. Customers 640 may be able to dynamically request changes to the service agreement. 641 In this case, a statically provisioned edge router cannot provide the 642 required DACS functionality. Instead, DACS functionality must be pro- 643 vided by coupling the stub network's admission control with the 645 Use Of RSVP with Diffserv June, 1998 647 transit network's admission control. 649 The two admission control mechanisms meet at the boundary between the 650 diff-serv network and the intserv network. This boundary may be imple- 651 mented at the edge router (in the stub network), at the boundary 652 router (in the transit network), or at the bandwidth broker for the 653 intserv network. 655 5.3.1.3 Limiting the Impact of Intserv Admission Control on the Diff- 656 serv Network 658 Note that coupling intserv and diff-serv admission control does not 659 imply that each intserv admission control request results in diff-serv 660 admission control work. Instead, intserv admission control requests 661 are aggregated at the boundary between the intserv and the diff-serv 662 network. For example, intserv admission control requests may trigger 663 diff-serv admission control requests to bandwidth brokers only when 664 some high-water or low-water resource threshold is crossed. Separate 665 high-water and low-water thresholds provide hysteresis to prevent 666 thrashing. 668 5.3.1.4 Roles of Policy and Resource Based Admission Control 670 It is necessary to provide both resource and policy based admission 671 control in the diff-serv network as well as the intserv network. In 672 the diff-serv network, resource and policy based admission control are 673 handled by entities such as bandwidth brokers and reflected to the 674 intserv network as DACS (or RSVP). Policy decisions made within the 675 diff-serv network are likely to be at the per-intserv network (per- 676 customer of the diff-serv network) granularity. 678 In the intserv network, resource based admission control is handled by 679 RSVP enabled routers (and SBMs [2]). Policy based admission control is 680 handled by RSVP capable policy servers. These assure that intserv 681 resources are allotted to intserv customers according to policy 682 specific to the intserv network. In addition, policy servers within 683 the intserv network must also assure that appropriate policy is 684 applied when diff-serv resources are allotted to intserv customers. 686 5.3.2 Setting the DS-field at Intermediate Nodes 688 In the example described, hosts use RSVP signaling and mark the DS- 689 byte corresponding to the admitted service level. Note that these 690 functions can be separated. In the example, the function of RSVP sig- 691 naling is to invoke QoS in the intserv network and to provide end-to- 692 end admission control. The function of marking the DS-field is to 693 reduce the need for MF classification at routers. (MF classification 694 is required at the ingress to a diff-serv network only to determine 696 Use Of RSVP with Diffserv June, 1998 698 the customer to whom the traffic belongs. If an interface is dedicated 699 to the customer, no MF classification need be done. In this case, any 700 MF classification on behalf of the diff-serv ingress point is provided 701 as a service to the customer and goes beyond policing requirements). 703 It is possible to mark the DS-field at intermediate routers rather 704 than at the host and still to realize many of the benefits of our 705 approach. In this case, intermediate routers may use the RSVP signal- 706 ing to configure an MF classifier and marker. Therefore, the confi- 707 guration of MF classifiers and markers is dynamic (minimizing the 708 management burden) and full resource and policy based admission con- 709 trol can be applied. 711 The disadvantages of marking the DS-field at intermediate routers 712 (instead of the host) are that full MF classifiers are required at the 713 intermediate nodes and that responsibility for traffic separation is 714 shifted away from the host. 716 Nonetheless, this approach is necessary to support those hosts which 717 may be capable of RSVP signaling, but which are not capable of marking 718 the DS-field. In addition, there may be cases in which the network 719 administrators wish to shift the responsibility for traffic separation 720 away from the hosts. In particular, we expect that there will continue 721 to be a need for top-down provisioned MF classification, especially 722 for qualitative (as opposed to quantitative) QoS applications. 724 6. Managing Different Resource Pools 726 We have focused largely on the class of applications that use RSVP to 727 explicitly signal per-flow QoS requirements and which expect end-to- 728 end tight QoS assurances, spanning both the intserv and diff-serv 729 regions of the network. We have been referring to these applications 730 as 'quantitative QoS applications'. 732 However, diff-serv networks also provide loose QoS to applications 733 that do not explicitly signal. Network managers can allot qualitative 734 QoS applications specific QoS in the diff-serv network. This is 735 achieved by configuring classifiers at the ingress to the diff-serv 736 network to recognize traffic from these applications. Thus, the clas- 737 sification fields are used as a form of implicit signaling. 739 Network administrators must therefore share diff-serv network 740 resources between three types of traffic: 742 a. Quantitative (explicitly signaled) QoS application traffic 743 b. Qualitative (implicitly signaled) QoS application traffic 744 c. All other (best-effort) traffic 746 Use Of RSVP with Diffserv June, 1998 748 Quantitative QoS applications rely on explicit admission control for 749 their traffic, at the edges of the diff-serv network. This traffic may 750 be refused admission for a particular diff-serv service level. However 751 - if admitted, the traffic is assured tight QoS. Of course, this is 752 true only to the extent that, at any ingress point, the total offered 753 traffic at each service level does not exceed the resources requested 754 through the sum of admission control requests. 756 Traffic from qualitative QoS applications is provided with implicit 757 admission control as a result of policing at ingress points. However, 758 implicit admission control does not provide explicit feedback to 759 applications. Therefore, it is difficult to assure that the total 760 traffic offered at an ingress point will not exceed the provisioned 761 capacity for a particular service level. When the traffic exceeds the 762 allowed limit, the feedback to the applications is indirect in the 763 form of packet loss or through an ECN CE mark at the bottleneck. 764 Thus, traffic from qualitative applications is offered only loose QoS. 766 From the network manager's perspective, there are three pools of 767 resources in the diff-serv network; one for traffic sourced by quanti- 768 tative QoS applications, one for traffic sourced by qualitative QoS 769 applications and one for best-effort traffic. These pools must be iso- 770 lated from each other by the appropriate configuration of policers and 771 classifiers at ingress points to the diff-serv network, and by 772 appropriate provisioning within the diff-serv network. To provide pro- 773 tection for quantitative QoS traffic in diff-serv regions of the net- 774 work we suggest that the DS codepoints allotted to such traffic must 775 not overlap the codepoints assigned to other traffic (qualitative QoS 776 and best-effort traffic). 778 7. Issues 780 7.1 Setting the DS-field at Hosts 782 The thought of allowing hosts to set the DS-field directly, may alarm 783 network administrators. The obvious concern is that hosts may attempt 784 to 'steal' resources. In fact, hosts may attempt to exceed the nego- 785 tiated capacity at a particular service level regardless of whether 786 they invoke this service level directly (by setting the DS-byte) or 787 indirectly (by submitting traffic that classifies in an intermediate 788 router to a particular diff-serv PHB). 790 In either case, it may sometimes be necessary to protect the network 791 by policing at various points, both within the stub network and/or at 792 the interface to the transit network. For example, within the stub 793 network, routers may police the aggregate traffic coming from a host 794 to ensure that the host is not exceeding its traffic limit. This 795 assures protection against malicious users or malfunctioning equipment 797 Use Of RSVP with Diffserv June, 1998 799 and, overall, ensures that customers do not use more resources than 800 they are entitled to, at each service level. If the sending host does 801 not do the marking, intermediate and/or boundary routers must provide 802 MF classification, mark and police. If the sending host does do the 803 marking, these routers need only to provide BA classification and to 804 police the aggregate to ensure that the customer is not exceeding the 805 aggregate capacity negotiated for the service level. It should, how- 806 ever, be noted that some PHBs (e.g., a "billing" PHB [14]) may not 807 require any policing at all at any point in the network. 809 Requiring hosts to mark the DS-field has the effect of moving respon- 810 sibility to the edge of the network, in more ways than one. With this 811 approach, boundary routers police in aggregate. As a result, the cus- 812 tomer cannot rely on boundary routers to provide traffic isolation 813 between the customer's flows, when policing or shaping. Instead, it 814 is the customer's responsibility to ensure that the customer's flows 815 are properly shaped and policed within the customer's sending network. 816 Overall, this approach simplifies boundary routers and still allows 817 protection against misbehaving hosts/users. 819 Ideally, hosts should provide per-flow shaping at their sending inter- 820 faces. However, there is always a chance that the customer's traffic 821 will become distorted as it nears the boundary between the customer 822 and the carrier. In this case, the customer should do per flow polic- 823 ing (or even re-shaping) at the egress point from the customer's net- 824 work unless the policing agreement at the other side is known to 825 accommodate the transient bursts that can arise from adding the flows. 827 In summary, the security concerns of marking the DS-field at the edge 828 of the network can be dismissed since each carrier will have to do 829 some form of policing (per-flow or per-host) at their boundary anyway. 830 Furthermore, this approach reduces the granularity at which boundary 831 routers must police, thereby pushing finer grain shaping and policing 832 responsibility to the edges of the network, where it scales better. 833 The carriers are thus focused on the task of protecting their transit 834 networks, while the customers are focused on the task of shaping and 835 policing their own traffic to be in compliance with their negotiated 836 token bucket parameters. 838 7.2 End-to-End Integrity of the DS-field 840 Our proposal assumes that hosts use a standard coding for specifying a 841 desired PHB in some sub-field of the DS-field. It also assumes that 842 packets submitted to the network with a certain PHB specified, will 843 receive a standard service throughout the diff-serv network. Strictly 844 speaking, this does not dictate that the transit network must leave 845 the PHB field intact. For example, after a sending host marks the 847 Use Of RSVP with Diffserv June, 1998 849 packets with PHB value based on either the well-known, "default" or 850 "customer-specified" mapping, the boundary router may re-map it to a 851 different value before forwarding the data packets. However, we see 852 little value in allowing the PHB field to be altered within the net- 853 work. This is likely to perpetuate local and incompatible interpreta- 854 tions of the field. 856 7.3 Carrying RSVP Messages across Transit Networks 858 Our proposal presumes end-to-end RSVP both as a means for communica- 859 tion between sending host and receiving host and optionally, for the 860 support of true RSVP reservations in stub networks (or in intermediate 861 networks which are interested in the fine grain RSVP information). 862 Therefore, we require that RSVP messages be carried transparently 863 across the transit networks. In [8], mechanisms are proposed for doing 864 so in a manner that does not require the routers in the transit net- 865 work to understand/interpret RSVP messages and does not adversely 866 impact the transit network. 868 8. Dependencies of Intserv on Diff-Serv 870 We have described a framework for end-to-end QoS in which intserv net- 871 works are customers of diff-serv networks. We believe that the bene- 872 fits of this framework are sufficient to justify the consideration of 873 intserv dependencies as diff-serv work proceeds. In particular, we 874 wish to draw attention to the following dependencies: 876 1. We expect that we can invoke a standard end-to-end (within the 877 diff-serv network) service by specifying a standard code in a (PHB) 878 sub-field of the DS-field of a packet launched into a diff-serv 879 network. 881 2. Diff-serv networks must provide admission control information to 882 the intserv network. At the very least, this is through static 883 service level agreements. Preferably, this is through a dynamic 884 protocol. If the intserv to diff-serv boundary is implemented in the 885 transit network boundary routers, then this protocol is RSVP. 887 3. We expect that diff-serv networks will transparently carry RSVP messages 888 such that they can be recovered at the egress point from the diff-serv 889 network. 891 9. Security Considerations 893 We are proposing that RSVP signaling be used to obtain resources in 894 both the diff-serv and intserv regions of the network. Therefore, all 895 RSVP security considerations apply [11]. In addition, network 897 Use Of RSVP with Diffserv June, 1998 899 administrators are expected to protect network resources by configur- 900 ing secure policers at interfaces with untrusted customers. 902 10. References 904 [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., 905 "Resource Reservation Protocol (RSVP) Version 1 Functional 906 Specification", RFC 2205, Proposed Standard, September 1997 908 [2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M., 909 "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based Admission 910 Control Over IEEE 802 Style Networks", Internet Draft, March 1998 912 [3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated 913 Services State", Internet Draft, December 1997. 915 [4] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit 916 Differentiated Services Architecture for the Internet", Internet 917 Draft, December 1997. 919 [5] Seaman, M., Smith, A. and Crawley, E., "Integrated Services Over 920 IEEE 802.1D/802.1p Networks", Internet Draft, June 1997 922 [6] Elleson, E. and Blake, S., "A Proposal for the Format and 923 Semantics of the TOS Byte and Traffic Class Byte in Ipv4 and Ipv6 924 Headers", Internet Draft, November 1997 926 [7] Ferguson, P., "Simple Differential Services: IP TOS and 927 Precedence, Delay Indication, and Drop Preference", Internet Draft, 928 November 1997 930 [8] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based 931 QoS Requests", Internet Draft, November 1997 933 [9] Clark, D. and Wroclawski, J., "An Approach to Service 934 Allocation in the Internet", Internet Draft, July 1997 936 [10] Blake, S. and Nichols, K., "Differentiated Services Operational 937 Model and Definitions", Internet Draft, February 1998 939 [11] Baker, F., "RSVP Cryptographic Authentication", Internet Draft, 940 August 1997 942 [12] Braden, R., Clark, D. and Shenker, S., "Integrated Services in 943 the Internet Architecture: an Overview", Internet RFC 1633, June 944 1994 946 [13] Garrett, M. W., and Borden, M., "Interoperation of Controlled-Load 948 Use Of RSVP with Diffserv June, 1998 950 Service and Guaranteed Service with ATM", Internet Draft, March 1998 952 [14] Weiss, Walter, "private communication", November 1998. 954 11. Acknowledgments 956 Authors thank the following individuals for their comments that led to 957 improvements to the previous version(s) of this draft: David Oran, 958 Andy Veitch, Curtis Villamizer, Walter Weiss, and Russel white. 960 12. Author's Addresses 962 Yoram Bernet 963 Microsoft 964 One Microsoft Way, 965 Redmond, WA 98052 966 Phone: (425) 936-9568 967 Email: yoramb@microsoft.com 969 Raj Yavatkar 970 Intel Corporation, JF3-206 971 2111 NE 25th. Avenue, 972 Hillsboro, OR 97124 973 Phone: (503) 264-9077 974 Email: raj.yavatkar@intel.com 976 Peter Ford 977 Microsoft 978 One Microsoft Way, 979 Redmond, WA 98052 980 Phone: (425) 703-2032 981 Email: peterf@microsoft.com 983 Fred Baker 984 Cisco Systems 985 519 Lado Drive, 986 Santa Barbara, CA 93111 987 Phone: (408) 526-4257 988 Email: fred@cisco.com 990 Lixia Zhang 991 UCLA 992 4531G Boelter Hall 993 Los Angeles, CA 90095 994 Phone: +1 310-825-2695 995 Email: lixia@cs.ucla.edu 997 Use Of RSVP with Diffserv June, 1998 999 Kathleen Nichols 1000 Cisco Systems 1001 Email: kmn@cisco.com 1003 Michael Speer 1004 Sun Microsystems, Inc 1005 901 San Antonio Road UMPK15-215 1006 Palo Alto, CA 94303 1007 phone: +1 650-786-6368 1008 Email: speer@Eng.Sun.COM