idnits 2.17.1 draft-ietf-diffserv-rsvp-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-19) 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 1) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages 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. ** There are 7 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** 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: ---------------------------------------------------------------------------- == Line 844 has weird spacing: '... such that t...' -- 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: '3' is defined on line 868, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 878, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 882, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 889, 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') -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 13 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-00.txt P. Ford, Microsoft 5 F. Baker, Cisco 6 L. Zhang, UCLA 7 K. Nichols, Bay Networks 8 M. Speer, Sun Microsystems 10 June, 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". 27 To view the entire list of current Internet-Drafts, please check 28 the "1id-abstracts.txt" listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 30 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 31 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 32 (US West Coast). 34 A revised version of this draft document will be submitted to the 35 RFC editor as an Informational RFC for the Internet Community. 36 Discussion and suggestions for improvement are requested. This 37 document will expire before December, 1998. Distribution of this 38 draft is unlimited. 40 Use Of RSVP with Diffserv June, 1998 42 1. Abstract 44 In the past several years, work on QoS enabled networks led to the 45 development of the Integrated Services (Intserv) architecture [12] and 46 the RSVP signaling protocol [1]. RSVP, as specified, enables applica- 47 tions to signal per-flow requirements to the network. Intserv parame- 48 ters are used to quantify these requirements for the purpose of admis- 49 sion control. However, as work on RSVP and Intserv has proceeded, we 50 have recognized the following basic limitations, which impede deploy- 51 ment of these mechanisms in the Internet at large: 53 1) The reliance of RSVP on per-flow state and per-flow processing 54 raises scalability concerns in large networks. 55 2) Today, only a small number of hosts generate RSVP signaling. 56 While this number is expected to grow dramatically, many 57 applications may never generate RSVP signaling. 58 3) Many applications require a form of QoS, but are unable to 59 express these requirements using the intserv model. 61 At present, the market is pushing for immediate deployment of a QoS 62 solution that addresses the needs of the Internet as well as enter- 63 prise networks. This push has led to the development of Differentiated 64 services (diff-serv). In contrast to RSVP's per-flow orientation, 65 diff-serv networks classify packets to one of a small number of aggre- 66 gated flows, based on the setting of bits in the TOS field of each 67 packet's IP header. Thus, in addition to eliminating the reliance on 68 per-flow state, diff-serv QoS can initially be deployed using top-down 69 provisioning, with no requirement for end- to-end signaling. 71 At the same time however, it is important to assure that the diff- 72 serv mechanisms deployed, interoperate effectively with hosts and net- 73 works that provide per-flow QoS in response to end-to-end signaling. 74 This is important, as we believe that in the coming years, there will 75 be a proliferation of applications that depend on QoS and of hosts 76 which will signal end-to-end on their behalf. 78 This draft proposes a framework in which diff-serv capable transit 79 networks provide aggregate QoS services, in support of RSVP/Intserv 80 capable hosts and stub networks, which use end-to-end signaling. In 81 our model, diff-serv mechanisms are used within transit networks and 82 at the boundaries between them, while either diff-serv or RSVP/Intserv 83 mechanisms are used within stub networks and at the boundaries between 84 stub networks and transit diff-serv networks. Managers of the transit 85 networks will provision a pool of network resources to be available in 86 response to end-to-end signaling. The remaining resources will be 87 allotted using traditional 'top-down' provisioning methods. 89 Our framework allows the deployment of diff-serv networks and 91 Use Of RSVP with Diffserv June, 1998 93 RSVP/Intserv networks to proceed at their own pace, providing immedi- 94 ate incremental benefits in areas of the network in which one or the 95 other is deployed and additional benefits where both are deployed. 96 This framework builds upon current work in the IETF including diff- 97 serv [10] and RSVP aggregation [8]. 99 Many of the ideas in this document have been previously discussed in 100 the original intserv architecture document [12]. 102 2. Goals of This Draft 104 This draft is based on the assumption that end-to-end QoS is required 105 to support the needs of certain applications. Such applications 106 include IP-telephony, video-on-demand and various non- multimedia 107 mission-critical applications. 109 In our view, intserv and diff-serv are complementary tools in the pur- 110 suit of end-to-end QoS. Each serves an important purpose in the end- 111 to-end QoS enabled network. The primary goal of this draft is to 112 encourage the continued development of each in a manner that does not 113 preclude realization of the proposed framework. To this end, we will: 115 1. List the requirements of a network that provides end-to-end QoS. 116 2. Present a framework that uses intserv as a customer of diff-serv 117 to meet these requirements. 118 3. Identify dependencies of intserv on diff-serv. 120 Ultimately, we aim to clearly define a manner in which RSVP/Intserv 121 and diff-serv mechanisms interact seamlessly. We expect that by doing 122 so, we will enable network administrators to determine the degree to 123 which diff-serv capabilities are pushed towards the edge of their net- 124 works (or, the degree to which RSVP/Intserv capabilities are pushed 125 towards the core). 127 3. Terminology 129 The following terms are used in this draft: 131 a. Intserv region (or intserv capable network) - the part of an 132 internet that uses per-flow identification, signaling, and admission 133 control to deliver per-flow QoS guarantees 135 b. Diff-serv region (or diff-serv capable network) - the part of an 136 internet that provides aggregate QoS services 138 c. Quantitative QoS applications - applications for which QoS 140 Use Of RSVP with Diffserv June, 1998 142 requirements are readily quantifiable, and which rely on these QoS 143 requirements to function properly. 145 d. Qualitative QoS applications - applications for which relative 146 QoS requirements exist, but are not readily quantifiable. 148 e. QoS applications - applications that require some form of QoS, 149 either qualitative or quantitative. 151 f. Loose QoS - QoS assurances which are relative, rather than 152 absolute, or generally not quantifiable. 154 g. Tight QoS - QoS assurances which are absolute and quantifiable, 155 though they may or may not provide 100% guarantee. 157 h. Top-down (or open-loop) provisioning - traditional provisioning 158 methods which configure network capacities using heuristics and 159 experience, typically from a console, with no explicit knowledge of 160 exact traffic volumes or exact paths taken by the affected traffic. 162 i. RSVP/Intserv - RSVP is a signaling protocol. Intserv (in this 163 context) is a model for quantifying traffic that is useful for 164 admission control purposes. In this document, we use the terms 165 together, to discuss the RSVP/Intserv network, in contrast to the 166 diff-serv network. However, the two are separable and much of the 167 following discussion could be applied to a model in which RSVP 168 signals using parameters that are not Intserv specific. 170 4. Requirements for the End-to-End QoS Framework An end-to-end QoS 171 network must serve the requirements of network managers as well as 172 those of both quantitative and qualitative QoS applications. We con- 173 sider these requirements in the context of the following general 174 topology: 176 / Stub \ / Transit \ / Stub \ 177 / Network \ / Network \ / Network \ 178 |---| | |---| |---| |---| |---| | |---| 179 |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx | 180 |---| | |-- | |---| |---| |---| | |---| 181 \ / \ / \ / 182 \ / \ / \ / 184 Figure 1: Sample Network Configuration 186 This network consists of a diff-serv capable transit network and two 188 Use Of RSVP with Diffserv June, 1998 190 intserv capable stub networks. In the interest of simplicity, we show 191 a single QoS sender on one of the stub networks and a single QoS 192 receiver on the other. We show edge routers (ER1, ER2) at the inter- 193 faces of the intserv networks to the diff-serv network. We show boun- 194 dary routers (BR1, BR2) at the interfaces of the diff-serv network to 195 the intserv networks. 197 The transit network contains a mesh of routers, at least some of which 198 are diff-serv capable. The stub networks contain a mesh of routers, at 199 least some of which are intserv capable. 201 We define the following requirements of the framework: 203 4.1 Definition of a Set of Services 205 There must be a set of useful end-to-end services available to Quanti- 206 tative QoS applications. Routers internal to the diff-serv network are 207 assumed to provide a set of 'per-hop-behaviours' (PHBs [10]). We 208 expect that concatenation of certain well-defined PHBs will yield cer- 209 tain well-understood services across the diff-serv network. We also 210 expect that the intserv regions of the network will be able to extend 211 these services such that they can be realized in a true end-to-end 212 manner. 214 In addition, there must be a set of end-to-end services available to 215 Qualitative QoS applications. However, the services that these appli- 216 cations require are generally less demanding. They can be loosely pro- 217 visioned (in a top-down manner) in the diff-serv regions of the net- 218 work and will likely receive best-effort treatment in the intserv 219 regions of the network. 221 In this draft we focus primarily on the requirements of quantitative 222 QoS applications. Although these may generate only a small fraction of 223 all traffic, servicing this traffic may comprise a significant frac- 224 tion of the revenues associated with QoS. In addition, while qualita- 225 tive QoS applications can be satisfied by conventional diff- serv 226 alone, quantitative QoS applications require additional support. 228 4.2 Allotment of Diff-serv Service Levels to Specific Traffic Flows 230 It must be possible for QoS applications to invoke specific end-to- 231 end service levels for their traffic flows. Within the intserv regions 232 of the network quantitative QoS applications do so by using RSVP sig- 233 naling to configure classifiers which operate on IP addresses and port 234 numbers. We will refer to such classifiers from here on as 'MF' clas- 235 sifiers [10]. 237 Within the diff-serv regions of the network, traffic is allotted 239 Use Of RSVP with Diffserv June, 1998 241 service based on the contents of the DS-field in packet headers. 242 Therefore, it is necessary for QoS applications to effect the correct 243 marking of DS-fields before their packets are submitted to the diff- 244 serv network. (This is particularly true for quantitative QoS applica- 245 tions, less so for qualitative QoS applications that need not play as 246 active a role in securing specific QoS from the network). There are 247 two general mechanisms for doing so: 249 1. Hosts may directly mark DS-fields in the transmitted packets of 250 QoS applications. 251 2. Routers external to the diff-serv network may mark DS-fields on 252 behalf of QoS applications based on MF classification. 254 In the first case, marking will be done based on host configuration or 255 local communication between QoS applications and the host operating 256 system. In the second case, marking will be done based on top-down 257 configuration of the marking router's MF classifier/marker (by manual 258 configuration or via automated configuration scripts) or based on 259 standard signaling between QoS applications and the marking router's 260 classifier/marker. 262 The following three requirements argue either for host based marking 263 or for dynamic configuration of a router's classifier/marker in 264 response to application requests. 266 4.2.1 Minimal Management Burden 268 The information required to express useful mappings of application 269 traffic flows to service levels is likely to be quite complex and to 270 change frequently. Thus, manual configuration is likely to impose a 271 significant management burden. If the configuration information is 272 very simple and does not change over time, the management burden may 273 be relatively minor. However, this means that the granularity of 274 allotting service levels to flows will be sub-optimal. 276 4.2.2 Granularity of Allotment 278 The term 'granularity' is used here to refer to the degree of specifi- 279 city that is available in allotting a specific service level to a 280 specific traffic flow. There are two measures of granularity; one is 281 the granularity with which an individual flow or a group of flows is 282 identified. The other is the frequency at which the service allotted 283 to a flow may change. A fine grain QoS system would allow the follow- 284 ing requirement to be expressed: telephony traffic from user X should 285 be allotted service level A, while telephony traffic from user Y 286 should be allotted service level B, and web traffic from any user 287 should be allotted service level C. A coarse grain system would be 288 limited to something of the form: all traffic from subnet 1.0.0.0 290 Use Of RSVP with Diffserv June, 1998 292 should receive service level A, while all traffic from subnet 2.0.0.0 293 should receive service level B. A temporally fine grain system would 294 allow immediate changes in allotment of service levels to traffic 295 flows. A temporally coarse grain system may allow infrequent changes 296 only. 298 4.2.3 Difficulties in Identification of Application Flows 300 Routers may not be able to readily identify specific application flows 301 based on network and/or transport layer fields in a packet. 303 For example, consider the need to give preferential service to a 304 website's home page (over other, less important pages at the site) or 305 the case of encrypted traffic flows (IPSEC). 307 4.3 Admission Control 309 Quantitative QoS applications use RSVP to request that their flows be 310 admitted to intserv regions of the network. When a request is 311 rejected, the host application may avoid sending traffic and/or inter- 312 mediate RSVP capable nodes will only give best-effort service to 313 traffic on flows that were not admitted. These mechanisms protect 314 traffic on flows that were admitted. 316 In diff-serv regions of the network, admission control is provided 317 implicitly, by policing at ingress points based on provisioning. The 318 problem with implicit admission control is that it breaks the end-to- 319 end validity of explicit admission control. Specifically, an applica- 320 tion may gain admission using RSVP signaling, even though there is no 321 capacity for that application's traffic within the diff-serv region of 322 the network. Neither the application, nor intermediate RSVP capable 323 nodes will be aware that the application's traffic is not admissible. 324 As a result, neither can take corrective action and all traffic from 325 that customer, at the corresponding service level, may be compromised. 326 This failure may be partially, but not completely alleviated by polic- 327 ing based on MF classification at the diff-serv ingress (rather than 328 BA classification [10]). 330 End-to-end QoS requires that quantitative QoS applications and RSVP 331 capable intserv nodes be explicitly informed of admission control 332 failure in the diff-serv network. This enables them to take corrective 333 action and to avoid overdriving the diff-serv network. If the service 334 agreement between the intserv and diff-serv regions of the network is 335 statically provisioned, then admission control functionality can be 336 provided by static configuration of admission control in intserv edge 337 routers. However, if the service agreement is dynamically variable, 338 then it will be necessary to dynamically propagate current diff-serv 339 resource availability to the intserv network for the purpose of 341 Use Of RSVP with Diffserv June, 1998 343 explicit admission control. 345 4.4 Policy Support 347 End-to-end QoS leads to preferential treatment of certain traffic 348 flows over others. Within diff-serv regions of the network, policy 349 applies on a per-customer basis. In general, the diff-serv network 350 makes multiple service levels available to a single customer's intserv 351 network. In this case the customer must apply policy within its net- 352 work to assure appropriate allocation of resources (customer network 353 resources as well as diff-serv network resources) to individual hosts 354 in the customer's network. This requires that end- to-end admission 355 control be based on policy as well as resource availability. 357 5. Intserv as a Customer of Diff-serv 359 To meet the above requirements, we envision a network that consists 360 typically of relatively smaller, intserv capable stub networks, con- 361 nected by larger, diff-serv capable transit networks. In this sec- 362 tion, we will describe the operation of one instantiation of such a 363 network (see figure 1). The following assumptions apply: 365 5.0.1 Host Capabilities 367 Both sending and receiving hosts use RSVP to communicate QoS require- 368 ments of certain QoS aware applications running on the host. A QoS 369 process within the host operating system generates RSVP signaling on 370 behalf of the applications. This process also invokes traffic control. 371 Host traffic control includes marking the DS-field in transmitted 372 packets and shaping transmitted traffic per token bucket specifica- 373 tions. Note that host traffic control is assumed for this specific 374 example, but is not a requirement of the framework in general. Leaf 375 routers within the intserv network may provide the traffic control 376 functions. 378 5.0.2 Edge Routers 380 The edge routers are special routers that straddle the boundary 381 between the RSVP/Intserv region of the network and the diff-serv 382 region of the network. It is helpful to think of these routers as con- 383 sisting of two halves; the standard RSVP half, which interfaces to the 384 stub networks, and the diff-serv half, which interfaces to the transit 385 network. 387 The RSVP half is at least partially RSVP capable; it is able to pro- 388 cess PATH and RESV messages but it is not necessarily required to 389 store full RSVP state and it is not required to provide MF classifica- 390 tion. 392 Use Of RSVP with Diffserv June, 1998 394 The diff-serv half of the router provides the interface to the admis- 395 sion control function for the diff-serv network. We shall refer to 396 this function from here on as the 'DACS' (diff-serv admission control 397 service). The DACS is a process that is likely to (but is not required 398 to) run at least partially, on the routers. If the service agreement 399 between the stub networks and the transit networks is statically pro- 400 visioned then the DACS can be as simple as a table which specifies 401 capacity at each service level. If the service agreement is dynamic, 402 the DACS may communicate with counterparts within the diff-serv net- 403 work (such as a bandwidth broker [4]) and may be able to make admis- 404 sion control decisions based on provisioned limits as well as the 405 topology and the capacity of the diff-serv network. 407 5.0.3 Boundary Routers 409 These are conventional boundary routers. In the example illustrated, 410 they are not required to run RSVP. They are expected to implement the 411 policing function of diff-serv ingress routers, based on the results 412 of a BA classifier. They may, but are not required, to provide MF 413 classification nor to mark the DS-field (with the possible exception 414 of the in/out bit). [10, 8] 416 Note that this example places the boundary between the RSVP/Intserv 417 network and the diff-serv network, within the edge routers at the stub 418 networks. In general, this boundary could be shifted to the left or to 419 the right. It could for example, be placed within the boundary routers 420 in the transit network. In this case, the DACS is implemented 421 entirely within the diff-serv network (and is essentially, the 422 bandwidth broker proposed in [4]), but the diff- serv boundary routers 423 must be RSVP capable. 425 5.0.4 Stub Networks 427 The stub networks consist of int-serv capable hosts and some number of 428 leaf routers. Leaf routers within the stub networks may or may not be 429 int-serv capable. Since they are relatively small networks, it is rea- 430 sonable to assume that they are int-serv capable, but this is not 431 necessary. If they are not int-serv capable, we assume that they are 432 not capable of per-flow identification, signaling, and admission con- 433 trol and, in that case, will pass RSVP messages (requesting per-flow 434 QoS) unhindered. 436 5.0.5 Transit Network 438 The transit network is not capable of per-flow identification, signal- 439 ing, and admission control. It provides two or more levels of service 440 based on the DS-field in the headers of carried packets (diff-serv 441 capable). Furthermore, the transit network is able to carry RSVP 443 Use Of RSVP with Diffserv June, 1998 445 messages transparently, with minimal or no impact on its performance 446 (see [8]). The transit network may include multiple carrier networks. 448 5.0.6 Carrier/Customer Agreement 450 The customer (owner(s) of the leaf networks) and the carrier owning 451 the transit network have negotiated a contract for the capacity to be 452 provided at each of a number of standard diff-serv service levels. The 453 capacity may be statically provisioned. In this case, the DACSs are 454 statically configured with the capacity available at each service 455 level and reside entirely within the edge routers. Alternatively, the 456 capacity may be dynamically variable with a pre- negotiated usage fee 457 and/or a pre-negotiated capacity limit. In this case, the DACS would 458 be required to communicate with counterparts within the diff-serv 459 transit network. 461 5.0.7 Mapping from Intserv Service Type to DS-field 463 In our proposal, we use RSVP signaling to provide admission control to 464 specific service levels in the diff-serv, as well as the intserv net- 465 work. RSVP signaling requests carry an intserv service type, describ- 466 ing the type of service they expect from the intserv regions of the 467 network. At each hop in an intserv network, the generic intserv ser- 468 vice requests are interpreted in a form meaningful to the specific 469 media. 471 For example, at an ATM hop, a VC of the correct type (CBR, ABR or VBR) 472 is established [13]. At an 802.1 hop, the intserv service type is 473 mapped to an appropriate 802.1p priority level [5]. At the boundary 474 between the intserv network and a diff-serv network, it is necessary 475 for edge devices to map the requested intserv service to a diff-serv 476 service level that can reasonably extend the intserv service type 477 requested by the application. The edge device can then provide admis- 478 sion control to the diff-serv network by accepting or rejecting the 479 request based on the capacity available at the requested diff-serv 480 service level. 482 We assume that one of two schemes is used to map intserv service types 483 to diff-serv service levels. In the first scheme (called "default map- 484 ping"), we propose a standard, well-known mapping from intserv service 485 type to a PHB that will invoke the appropriate behavior in the diff- 486 serv network. The mapping is not necessarily one-to-one. For example, 487 controlled-load interactive voice traffic will likely map to a PHB 488 having different latency characteristics than controlled-load latency 489 tolerant traffic. For this reason we suggest adding a qualifier to the 490 intserv service type indicating its relative latency tolerance (high 491 or low). The qualifier would be defined as a standard object in 492 intserv signaling messages. 494 Use Of RSVP with Diffserv June, 1998 496 In an alternate scheme (called "customer-specified mapping"), we allow 497 the devices at the edge of the diff-serv region of the network to 498 modify the well-known mapping. Under this approach, RESV messages ori- 499 ginating at hosts carry the usual intserv service type (with a qualif- 500 ier, as described above). When RESV messages arrive at the interface 501 of the int-serv and diff-serv regions (e.g. router ER1 in Figure 1, 502 where the traffic from the stub network enters the diff-serv region), 503 the edge device will determine the PHB that should be used to obtain 504 the corresponding diff-serv service level. This value is appended to 505 the RESV message by the edge device and is carried to the sending 506 host. When the RESV message arrives at the sending host, the sender 507 (or intermediate intserv routers) will mark outgoing packets with the 508 indicated PHBs. 510 The decision to modify the well-known mapping at the edge devices will 511 be based on edge-device configuration and/or policy decision at the 512 edges. 514 5.1 How End-to-End QoS is Obtained 516 The following sequence illustrates the process by which an application 517 obtains end-to-end QoS: 519 1. The sending host's QoS process generates an RSVP PATH message, 520 describing the traffic offered by the sending application. 522 2. The PATH message is carried toward the receiving host. In the 523 sending stub network, standard RSVP processing will be applied at 524 RSVP capable nodes (routers, SBMs, etc). 526 3. At ER1, the PATH message is subjected to standard RSVP processing 527 and PATH state is installed in the router. The PATH message is sent 528 onward, to the transit network. 530 4. The PATH message is carried transparently through the transit 531 network. It is processed in the receiving stub network according to 532 standard RSVP processing rules. 534 5. At the receiving host, the QoS process generates an RSVP RESV 535 message, indicating interest in the offered traffic, at a certain 536 intserv service level. 538 6. The RESV message is carried back towards the sending host. 539 Consistent with standard RSVP processing, it may be rejected at any 540 RSVP node in the receiving stub network if resources are deemed 541 insufficient to carry the traffic requested. 543 7. At ER2, the RESV message is subjected to standard RSVP 545 Use Of RSVP with Diffserv June, 1998 547 processing. It may be rejected if resources on the downstream 548 interface of ER2 are deemed insufficient to carry the resources 549 requested. If it is not rejected, it will be carried transparently 550 through the transit network, arriving at ER1. 552 8. At this point, the RESV message triggers DACS processing. The 553 DACS compares the resources requested to the resources available at 554 the corresponding diff-serv service level, in the diff-serv enabled 555 transit network. If the RESV message is admitted, the DACS updates 556 the available capacity for the service class, by subtracting the 557 approved resources from the available capacity. 559 9. Assuming the available capacity is sufficient, the RESV message 560 is admitted and is allowed to continue upstream towards the sending 561 host. If the available capacity is insufficient, the RESV message 562 will be rejected and the available capacity for the service class 563 will remain unchanged. 565 10. The RESV message proceeds through the sending stub network. RSVP 566 nodes in the sending stub network may reject it. If it is not 567 rejected, it will arrive at the sending host. 569 11. At the sending host, the QoS process receives the RESV message. 570 It interprets receipt of the message as an indication that the 571 specified traffic has been admitted for the specified intserv 572 service type (in the RSVP enabled regions of the network) and for 573 the corresponding diff-serv service level (in the diff-serv enabled 574 regions of the network). It begins to set the DS-field in the headers 575 of transmitted packets, to the value which maps to the Intserv 576 service type specified in the admitted RESV message. 578 In this manner, we are able to obtain end to end QoS through a combi- 579 nation of networks that support RSVP style reservations and networks 580 that support diff-serv style priortization. The successful arrival of 581 RESV messages at the original sender indicates that admission control 582 has succeeded both in the RSVP regions of the network and in the 583 diff-serv regions of the network. 585 5.2 Variations of the Model 587 It is useful to consider a number of variations of the model 588 presented. 590 5.2.1 Admission Control 592 5.2.1.1 Statically Provisioned Service Agreements 594 Use Of RSVP with Diffserv June, 1998 596 In the simplest model, service agreements are negotiated statically 597 between the stub networks and the transit networks. A service agree- 598 ment consists of a table of capacities available to a customer's stub 599 network, at each diff-serv service level. In this case, DACS func- 600 tionality is provided at the edge routers in the stub networks. The 601 'diff-serv half' of these routers appear to the 'RSVP half' as a send- 602 ing interface with resource limits defined by the service agreement 603 table. While there may be bandwidth brokers and dynamic provisioning 604 within the transit networks, these are not coupled with the intserv 605 stub networks and admission control in the two regions of the network 606 is completely independent. 608 5.2.1.2 Dynamic Service Agreements 610 In a more sophisticated model, service agreements between customer 611 stub networks and carrier transit networks are more dynamic. Customers 612 may be able to dynamically request changes to the service agreement. 613 In this case, a statically provisioned edge router cannot provide the 614 required DACS functionality. Instead, DACS functionality must be pro- 615 vided by coupling the stub network's admission control with the tran- 616 sit network's admission control. 618 The two admission control mechanisms meet at the boundary between the 619 diff-serv network and the intserv network. This boundary may be imple- 620 mented at the edge router (in the stub network), at the boundary 621 router (in the transit network), or at the bandwidth broker for the 622 intserv network. 624 5.2.1.3 Limiting the Impact of Intserv Admission Control on the Diff- 625 serv Network 627 Note that coupling intserv and diff-serv admission control does not 628 imply that each intserv admission control request results in diff- 629 serv admission control work. Instead, intserv admission control 630 requests are aggregated at the boundary between the intserv and the 631 diff-serv network. For example, intserv admission control requests may 632 trigger diff-serv admission control requests to bandwidth brokers only 633 when some high-water or low-water resource threshold is crossed. 634 Separate high-water and low-water thresholds provide hysteresis to 635 prevent thrashing. 637 5.2.1.4 Roles of Policy and Resource Based Admission Control 639 It is necessary to provide both resource and policy based admission 640 control in the diff-serv network as well as the intserv network. In 641 the diff-serv network, resource and policy based admission control are 642 handled by entities such as bandwidth brokers and reflected to the 643 intserv network as DACS (or RSVP). Policy decisions made within the 645 Use Of RSVP with Diffserv June, 1998 647 diff-serv network are likely to be at the per-intserv network (per- 648 customer of the diff-serv network) granularity. 650 In the intserv network, resource based admission control is handled by 651 RSVP enabled routers (and SBMs [2]). Policy based admission control is 652 handled by RSVP capable policy servers. These assure that intserv 653 resources are allotted to intserv customers according to policy 654 specific to the intserv network. In addition, policy servers within 655 the intserv network must also assure that appropriate policy is 656 applied when diff-serv resources are allotted to intserv customers. 658 5.2.2 Setting the DS-field at Intermediate Nodes 660 In the example described, hosts use RSVP signaling and mark the DS- 661 byte corresponding to the admitted service level. Note that these 662 functions can be separated. In the example, the function of RSVP sig- 663 naling is to invoke QoS in the intserv network and to provide end-to- 664 end admission control. The function of marking the DS-field is to 665 reduce the need for MF classification at routers. (MF classification 666 is required at the ingress to a diff-serv network only to determine 667 the customer to whom the traffic belongs. If an interface is dedicated 668 to the customer, no MF classification need be done. In this case, any 669 MF classification on behalf of the diff-serv ingress point is provided 670 as a service to the customer and goes beyond policing requirements). 672 It is possible to mark the DS-field at intermediate routers rather 673 than at the host and still to realize many of the benefits of our 674 approach. In this case, intermediate routers may use the RSVP signal- 675 ing to configure an MF classifier and marker. Therefore, the confi- 676 guration of MF classifiers and markers is dynamic (minimizing the 677 management burden) and full resource and policy based admission con- 678 trol can be applied. 680 The disadvantages of marking the DS-field at intermediate routers 681 (instead of the host) are that full MF classifiers are required at the 682 intermediate nodes and that responsibility for traffic separation is 683 shifted away from the host. 685 Nonetheless, this approach is necessary to support those hosts which 686 may be capable of RSVP signaling, but which are not capable of marking 687 the DS-field. In addition, there may be cases in which the network 688 administrators wish to shift the responsibility for traffic separation 689 away from the hosts. In particular, we expect that there will continue 690 to be a need for top-down provisioned MF classification, especially 691 for qualitative (as opposed to quantitative) QoS applications. 693 6. Managing Different Resource Pools 695 Use Of RSVP with Diffserv June, 1998 697 We have focused largely on the class of applications that use RSVP to 698 explicitly signal per-flow QoS requirements and which expect end- to- 699 end tight QoS assurances, spanning both the intserv and diff-serv 700 regions of the network. We have been referring to these applications 701 as 'quantitative QoS applications'. 703 However, diff-serv networks also provide loose QoS to applications 704 that do not explicitly signal. Network managers can allot qualitative 705 QoS applications specific QoS in the diff-serv network. This is 706 achieved by configuring classifiers at the ingress to the diff-serv 707 network to recognize traffic from these applications. Thus, the clas- 708 sification fields are used as a form of implicit signaling. 710 Network administrators must therefore share diff-serv network 711 resources between three types of traffic: 713 a. Quantitative (explicitly signaled) QoS application traffic 714 b. Qualitative (implicitly signaled) QoS application traffic 715 c. All other (best-effort) traffic 717 Quantitative QoS applications rely on explicit admission control for 718 their traffic, at the edges of the diff-serv network. This traffic may 719 be refused admission for a particular diff-serv service level. However 720 - if admitted, the traffic is assured tight QoS. Of course, this is 721 true only to the extent that, at any ingress point, the total offered 722 traffic at each service level does not exceed the resources requested 723 through the sum of admission control requests. 725 Traffic from qualitative QoS applications is provided with implicit 726 admission control as a result of policing at ingress points. However, 727 implicit admission control does not provide explicit feedback to 728 applications. Therefore, it is difficult to assure that the total 729 traffic offered at an ingress point will not exceed the levels allowed 730 by policers. Thus, traffic from qualitative applications is offered 731 only loose QoS. 733 From the network manager's perspective, there are three pools of 734 resources in the diff-serv network; one for traffic sourced by quanti- 735 tative QoS applications, one for traffic sourced by qualitative QoS 736 applications and one for best-effort traffic. These pools must be iso- 737 lated from each other by the appropriate configuration of policers and 738 classifiers at ingress points to the diff-serv network, and by 739 appropriate provisioning within the diff- serv network. 741 7. Issues 743 7.1 Setting the DS-field at Hosts 745 Use Of RSVP with Diffserv June, 1998 747 The thought of allowing hosts to set the DS-field directly, may alarm 748 network administrators. The obvious concern is that hosts may attempt 749 to 'steal' resources. In fact, hosts may attempt to exceed the nego- 750 tiated capacity at a particular service level regardless of whether 751 they invoke this service level directly (by setting the DS- byte) or 752 indirectly (by submitting traffic that classifies in an intermediate 753 router to a particular diff-serv PHB). 755 In either case, it may be necessary to protect the network by policing 756 at various points, both within the stub network and/or at the inter- 757 face to the transit network. For example, within the stub network, 758 routers may police the aggregate traffic coming from a host to ensure 759 that the host is not exceeding its traffic limit. This assures protec- 760 tion against malicious users or malfunctioning equipment and, overall, 761 ensures that customers do not use more resources than they are enti- 762 tled to, at each service level. If the sending host does not do the 763 marking, intermediate and/or boundary routers must provide MF classif- 764 ication, mark and police. If the sending host does do the marking, 765 these routers need only to provide BA classification and to police the 766 aggregate to ensure that the customer is not exceeding the aggregate 767 capacity negotiated for the service level. 769 Requiring hosts to mark the DS-field has the effect of moving respon- 770 sibility to the edge of the network, in more ways than one. With this 771 approach, boundary routers police in aggregate. As a result, the cus- 772 tomer cannot rely on boundary routers to provide traffic isolation 773 between the customer's flows, when policing or shaping. Instead, it 774 is the customer's responsibility to ensure that the customer's flows 775 are properly shaped and policed within the customer's sending network. 776 Overall, this approach simplifies boundary routers and still allows 777 protection against misbehaving hosts/users. 779 Ideally, hosts should provide per-flow shaping at their sending inter- 780 faces. However, there is always a chance that the customer's traffic 781 will become distorted as it nears the boundary between the customer 782 and the carrier. In this case, the customer should do per flow polic- 783 ing (or even re-shaping) at the egress point from the customer's net- 784 work unless the policing agreement at the other side is known to 785 accommodate the transient bursts that can arise from adding the flows. 787 In summary, the security concerns of marking the DS-field at the edge 788 of the network can be dismissed since each carrier will have to do 789 some for of policing (per-flow or per-host) at their boundary anyway. 790 Furthermore, this approach reduces the granularity at which boundary 791 routers must police, thereby pushing finer grain shaping and policing 792 responsibility to the edges of the network, where it scales better. 793 The carriers are thus focused on the task of protecting their transit 795 Use Of RSVP with Diffserv June, 1998 797 networks, while the customers are focused on the task of shaping and 798 policing their own traffic to be in compliance with their negotiated 799 token bucket parameters. 801 7.2 End-to-End Integrity of the DS-field 803 Our proposal assumes that hosts use a standard coding for specifying a 804 desired PHB in some sub-field of the DS-field. It also assumes that 805 packets submitted to the network with a certain PHB specified, will 806 receive a standard service throughout the diff-serv network. Strictly 807 speaking, this does not dictate that the transit network must leave 808 the PHB field intact. However, we see little value in allowing the PHB 809 field to be altered within the network. This is likely to perpetuate 810 local and incompatible interpretations of the field. 812 7.3 Carrying RSVP Messages across Transit Networks 814 Our proposal presumes end-to-end RSVP both as a means for communica- 815 tion between sending host and receiving host and optionally, for the 816 support of true RSVP reservations in stub networks (or in intermediate 817 networks which are interested in the fine grain RSVP information). 818 Therefore, we require that RSVP messages be carried transparently 819 across the transit networks. In [8] mechanisms are proposed for doing 820 so in a manner that does not require the routers in the transit net- 821 work to understand/interpret RSVP messages and does not adversely 822 impact the transit network. 824 8. Dependencies of Intserv on Diff-Serv 826 We have described a framework for end-to-end QoS in which intserv net- 827 works are customers of diff-serv networks. We believe that the bene- 828 fits of this framework are sufficient to justify the consideration of 829 intserv dependencies as diff-serv work proceeds. In particular, we 830 wish to draw attention to the following dependencies: 832 1. We expect that we can invoke a standard end-to-end (within the 833 diff-serv network) service by specifying a standard code in a (PHB) 834 sub-field of the DS-field of a packet launched into a diff-serv 835 network. 837 2. Diff-serv networks must provide admission control information to 838 the intserv network. At the very least, this is through static 839 service level agreements. Preferably, this is through a dynamic 840 protocol. If the intserv to diff-serv boundary is implemented in the 841 transit network boundary routers, then this protocol is RSVP. 843 3. We expect that diff-serv networks will transparently carry RSVP messages 844 such that they can be recovered at the egress point from the diff-serv 846 Use Of RSVP with Diffserv June, 1998 848 network. 850 9. Security Considerations 852 We are proposing that RSVP signaling be used to obtain resources in 853 both the diff-serv and intserv regions of the network. Therefore, all 854 RSVP security considerations apply [11]. In addition, network adminis- 855 trators are expected to protect network resources by configuring 856 secure policers at interfaces with untrusted customers. 858 10. References 860 [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., 861 "Resource Reservation Protocol (RSVP) Version 1 Functional 862 Specification", RFC 2205, Proposed Standard, September 1997 864 [2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M., 865 "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based Admission 866 Control Over IEEE 802 Style Networks", Internet Draft, March 1998 868 [3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated 869 Services State", Internet Draft, December 1997. 871 [4] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit 872 Differentiated Services Architecture for the Internet", Internet 873 Draft, December 1997. 875 [5] Seaman, M., Smith, A. and Crawley, E., "Integrated Services Over 876 IEEE 802.1D/802.1p Networks", Internet Draft, June 1997 878 [6] Elleson, E. and Blake, S., "A Proposal for the Format and 879 Semantics of the TOS Byte and Traffic Class Byte in Ipv4 and Ipv6 880 Headers", Internet Draft, November 1997 882 [7] Ferguson, P., "Simple Differential Services: IP TOS and 883 Precedence, Delay Indication, and Drop Preference", Internet Draft, 884 November 1997 886 [8] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based 887 QoS Requests", Internet Draft, November 1997 889 [9] Clark, D. and Wroclawski, J., "An Approach to Service 890 Allocation in the Internet", Internet Draft, July 1997 892 [10] Blake, S. and Nichols, K., "Differentiated Services Operational 893 Model and Definitions", Internet Draft, February 1998 895 Use Of RSVP with Diffserv June, 1998 897 [11] Baker, F., "RSVP Cryptographic Authentication", Internet Draft, 898 August 1997 900 [12] Braden, R., Clark, D. and Shenker, S., "Integrated Services in 901 the Internet Architecture: an Overview", Internet RFC 1633, June 902 1994 904 [13] Garrett, M. W., and Borden, M., "Interoperation of Controlled- 905 Load Service and Guaranteed Service with ATM", Internet Draft, March 906 1998 908 11. Acknowledgments 910 12. Author's Addresses 912 Yoram Bernet 913 Microsoft 914 One Microsoft Way, 915 Redmond, WA 98052 916 Phone: (425) 936-9568 917 Email: yoramb@microsoft.com 919 Raj Yavatkar 920 Intel Corporation, JF3-206 921 2111 NE 25th. Avenue, 922 Hillsboro, OR 97124 923 Phone: (503) 264-9077 924 Email: yavatkar@ibeam.intel.com 926 Peter Ford 927 Microsoft 928 One Microsoft Way, 929 Redmond, WA 98052 930 Phone: (425) 703-2032 931 Email: peterf@microsoft.com 933 Fred Baker 934 Cisco Systems 935 519 Lado Drive, 936 Santa Barbara, CA 93111 937 Phone: (408) 526-4257 938 Email: fred@cisco.com 940 Lixia Zhang 941 UCLA 942 4531G Boelter Hall 943 Los Angeles, CA 90095 945 Use Of RSVP with Diffserv June, 1998 947 Phone: +1 310-825-2695 948 Email: lixia@cs.ucla.edu 950 Kathleen Nichols 951 Bay Networks 952 Email: Kathleen_Nichols@BayNetworks.COM 954 Michael Speer 955 Sun Microsystems, Inc 956 901 San Antonio Road UMPK15-215 957 Palo Alto, CA 94303 958 phone: +1 650-786-6368 959 Email: speer@Eng.Sun.COM