idnits 2.17.1 draft-ietf-diffserv-rsvp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Bad filename characters: the document name given in the document, 'draft-ietf-diffserv-rsvp-02.ps', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-diffserv-rsvp-02.ps', does not give the document revision number == Mismatching filename: the document gives the document name as 'draft-ietf-diffserv-rsvp-02.ps', but the file name used is 'draft-ietf-diffserv-rsvp-02' ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 is 1 instance of too long lines in the document, the longest one being 93 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 26, 1999) is 9190 days in the past. Is this intentional? 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 836, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 846, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 850, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 857, 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' ** Downref: Normative reference to an Informational RFC: RFC 2475 (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. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Y. Bernet, Microsoft 3 Expiration: August 1999 R. Yavatkar, Microsoft 4 File: draft-ietf-diffserv-rsvp-02.ps P. Ford, Microsoft 5 F. Baker, Cisco 6 L. Zhang, UCLA 7 K. Nichols, Cisco 8 M. Speer, Sun Microsystems 9 R. Braden, ISI 11 Interoperation of RSVP/Int-Serv and Diff-Serv Networks 13 February 26, 1999 15 Status of Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 linebreak http://www.ietf.org/shadow.html. 34 Abstract 36 Differentiated Services (diff-serv) and RSVP/Integrated Services 37 (RSVP/int-serv) provide complementary approaches to the problem of 38 providing QoS for Internet end systems. These approachs must be able 39 to coexist and effectively interoperate. This document outlines one 40 important model for such interoperation, in which diff-serv is used 41 by transit networks in the core of the Internet while hosts and edge 42 networks use RSVP/int-serv. It also contains a brief discussion of 43 some alternative models for interoperation. 45 1. Introduction 47 Work on QoS-enabled IP networks has led to two distinct approaches: 48 the Integrated Services (int-serv) architecture [12] and its 49 signaling protocol RSVP [1], and the Differentiated Services (diff- 50 serv) architecture [10]. 52 RSVP enables applications to signal per-flow QoS requirements to the 53 network, with explicit admission control. Int-serv uses RSVP 54 signaling to request tight QoS with quantitative parameters. Int- 55 serv also imposes fine-grain policing and scheduling of traffic, to 56 ensure that admitted flows receive their service requests in strict 57 isolation from each other and from best-effort traffic. RSVP 58 signaling configures packet classifiers in the int-serv capable 59 routers along the path of the flow. These classifiers perform a 60 fine-grain or `MF' [10] classification of packets, using on IP 61 addresses and port numbers for example. 63 Some basic limitations to the RSVP/int-serv model have impeded its 64 deployment in the Internet at large. 66 o The use of per-flow state and per-flow processing raises 67 scalability concerns for large networks. 69 o Only a small number of hosts currently generate RSVP signaling. 70 While this number is expected to grow dramatically, some 71 applications may never generate RSVP signaling. 73 o Some applications require a form of QoS that cannot be expressed 74 using the int-serv model. 76 o The necessary policy control mechanisms -- access control, 77 authentication, and accounting -- are not available. 79 The market is pushing for immediate deployment of a QoS solution that 80 addresses the needs of the Internet as well as enterprise networks. 81 This push led to the development of Differentiated Services. In 82 contrast to the per-flow orientation of int-serv and RSVP, diff-serv 83 networks classify packets into one of a small number of aggregated 84 flows or "classes", based on bits set in the TOS field of each 85 packet's IP header. This is known as `BA' classification [10]. In 86 addition to eliminating the requirement for per-flow state, diff-serv 87 QoS can initially be deployed using long-term provisioning rather 88 than short-term reservations established by end-to-end signaling. 90 We view int-serv and diff-serv as complementary tools in the pursuit 91 of end-to-end QoS. For many applications, the loose or "qualitative" 92 QoS provided by diff-serv will be adequate. However, some 93 applications will require the tight quantitative end-to-end QoS 94 assurance provided by int-serv and RSVP. Current examples of 95 applications that need tight QoS include IP-telephony, video-on- 96 demand, and various non-multimedia mission-critical applications, and 97 such applications may proliferate in the future. The diff-serv 98 mechanisms that are deployed must be able to interoperate effectively 99 with hosts and networks that provide per-flow QoS using int-serv 100 models. 102 There are several different models for coexistence and interoperation 103 between RSVP/int-serv and diff-serv. This draft is primarily 104 concerned with one important model, although Section 5 presents a 105 brief look at other models. Under our model, diff-serv mechanisms 106 are used within transit networks in the `core' of the network, while 107 RSVP/int-serv mechanisms are used within stub networks at the 'edge'. 108 From the int-serv viewpoint, the diff-serv transit network is treated 109 as a virtual link connecting int-serv/RSVP capable routers. This 110 model builds upon work in progress on RSVP aggregation [8, 15]. 112 This model will provide a framework that will allow deployment of 113 diff-serv networks and deployment of RSVP/int-serv networks to 114 proceed at their own pace, providing immediate incremental benefits 115 in areas of the network in which one or the other is deployed and 116 additional benefits where both are deployed. Ultimately, we want 117 RSVP/int-serv and diff-serv mechanisms to interact seamlessly. 118 Network administrators should be able to determine for their own 119 networks the degree to which diff-serv capabilities are pushed 120 towards the edge of their networks, or the degree to which RSVP/int- 121 serv capabilities are pushed towards the core of the Internet. 123 Section 2 provides an overview of our model for interoperation 124 between int-serv and diff-serv, and discusses some of the 125 assumptions. Section 3 presents the model in more detail, while 126 Section 4 discusses its implications for diff-serv. Finally, Section 127 5 briefly lists some other possible models for interoperation. 128 Appendix A contains a list of some important terms used in this 129 document. 131 Even though one of the goals of this draft is to describe a framework 132 for co-existence of RSVP/int-serv with diff-serv, the draft currently 133 does not address the issues specific to IP multicast flows. See 134 Section 5. 136 2. Overview of the Model 138 This section examines the issues in providing tight quantitative 139 end-to-end QoS over end-to-end paths that includes both int-serv 140 networks and diff-serv networks, and introduces our model. 142 2.1 Quantitative End-to-End QoS 144 The primary focus of this document on end-to-end quantitative QoS. 145 Although quantitative QoS applications may generate only a small 146 fraction of all traffic, servicing this traffic may comprise a 147 significant fraction of the revenues associated with QoS. In 148 addition, while qualitative QoS applications can be satisfied by 149 conventional diff-serv alone, quantitative QoS applications 150 require additional support. 152 Diff-serv is expected to define some well-defined edge-to-edge 153 services, which will be formed by concatenation of the `per-hop- 154 behaviors' (PHBs [10]) that are being defined for internal diff- 155 serv routers, possibly with some defined shaping and/or policing 156 at the ingress. Our model assumes that it will be possible to map 157 the quantitative QoS services defined by int-serv into these 158 diff-serv services within the diff-serv network, in order to 159 satisfy the end-to-end requirement of a quantitative QoS 160 application. 162 2.2 Packet Marking 164 Within the diff-serv regions of the network, traffic is allotted 165 service based on the contents of the DS-field in the IP headers. 166 Setting the DS-field is referred to as `marking' the packet. QoS 167 applications must be able to effect the correct marking of DS- 168 fields before their packets enter a diff-serv network. There are 169 two choices for accomplishing this. 171 Host Marking 172 Hosts may directly mark DS-fields in the packets transmitted 173 by QoS applications. Such marking may be based on host 174 configuration or on local communication between QoS 175 applications and the host operating system. 177 Int-serv Router Marking 178 Routers external to the diff-serv network may mark DS-fields 179 on behalf of QoS applications, based on MF classification. 180 The MF classifier might be dynamically configured by RSVP 181 signaling between QoS applications, or it might be controlled 182 statically by manual configuration or automated configuration 183 scripts. 185 MF classification is expected to be limited to examination of the 186 network and transport-layer (port) fields of a packet. An 187 advantage of host marking is that it allows marking to depend upon 188 application-specific information that cannot be deduced from MF 189 classification. For example, consider the need to give 190 preferential service to a website's home page (over other, less 191 important pages at the site) or the case of encrypted traffic 192 flows (IPSEC). 194 The information required to express useful mappings of application 195 traffic flows to service levels is likely to be quite complex and 196 to change frequently. Thus, manual configuration is likely to 197 impose a significant management burden. If the configuration 198 information is very simple and does not change over time, the 199 management burden may be relatively minor; however, this means 200 that the granularity of allotting service levels to flows will be 201 sub-optimal. These considerations argue for host-based marking or 202 for dynamic configuration of a router's classifier/marker in 203 response to application requests. 205 2.3 Granularity of Allotment 207 The term `granularity' is used here to refer to the degree of 208 specificity that is available in allotting a specific service 209 level to a specific traffic flow. There are two measures of 210 allotment granularity: granularity of packet classification and 211 temporal granularity. 213 Fine grain classification might implement the following 214 requirement: "Telephony traffic from user X is allotted service 215 level A, while telephony traffic from user Y is allotted service 216 level B, and web traffic from any user is allotted service level 217 C." Coarse grain classification might be limited to something of 218 the form: "All traffic from subnet 1.0.0.0 receives service level 219 A, while all traffic from subnet 2.0.0.0 receives service level 220 B." 222 Temporal granularity determines the frequency with which the 223 service allotted to a flow may change. A temporally fine grain 224 system would allow immediate changes in allotment of service 225 levels to traffic flows, with times of the order of seconds or 226 less. A temporally coarse-grained system might have service 227 levels set by static provisioning with time frames of days or 228 weeks. 230 2.4 Policing 232 It may be necessary to protect the network by policing at various 233 points, within the stub network and/or at the interface to the 234 transit network. For example, within the stub network, first-hop 235 routers may police the aggregate traffic coming from a host to 236 ensure that the host is not exceeding its traffic limit. 238 It should be noted that some diff-serv PHBs (e.g., a "billing" PHB 239 [14]) may not require any policing at all at any point in the 240 network. 242 2.5 Admission Control 244 Under RSVP/int-serv, quantitative QoS applications use RSVP to 245 submit QoS requests to explicit admission control at each hop of 246 the end-to-end path. Integrated Services admission control (ISAC) 247 may be avoided only on hops that are known to be sufficiently 248 over-provisioned to satisfy the service requirements. When a 249 request is rejected, the host application may choose to try again 250 with a smaller request or to accept the best-effort service 251 available everywhere along the path, or it may simply avoid 252 sending traffic. These mechanisms protect traffic on flows that 253 were previously admitted. 255 In diff-serv regions of the network, admission control may be 256 provided implicitly by policing at ingress points, based on 257 provisioning. However, to support end-to-end tight QoS, explicit 258 admission control must be applied to the virtual hop represented 259 by the diff-serv transit network. An diff-serv service level used 260 by the int-serv traffic is provisioned for some maximum level of 261 traffic. The admission control function must ensure that this 262 limit is not exceeded by the total int-serv traffic submitted for 263 this class. 265 2.6 Policy Control 267 QoS support provides preferential treatment to particular traffic 268 flows. As a result, admission control must be based on policy as 269 well as on resource availability. 271 In an int-serv network, resource-based admission control is 272 handled by RSVP enabled routers (and SBMs [2]), and is typically 273 at the granularity of individual users. Policy based admission 274 control is handled by RSVP-capable policy servers. These assure 275 that int-serv network resources are allotted to users according to 276 policy specific to the int-serv network. In addition, policy 277 servers within the int-serv network must assure that appropriate 278 policy is applied when diff-serv resources are allotted to int- 279 serv users. 281 In a diff-serv network, resource and policy-based admission 282 control are handled by entities such as bandwidth brokers. Policy 283 decisions made within the diff-serv network are likely to be at 284 the granularity of peer networks. In general, the diff-serv 285 network may make multiple service levels available to a single 286 peer int-serv network. 288 3. Description of Model 290 We envision an internet that consists of RSVP/int-serv capable stub 291 networks interconnected by diff-serv capable transit networks. The 292 simplest example of this model is a diff-serv capable transit network 293 and two RSVP/int-serv capable stub networks, as shown in Figure 1. 294 The transit network contains a mesh of routers, at least some of 295 which are diff-serv capable. The stub networks contain meshes of 296 routers, at least some of which are int-serv capable. 298 / Stub / Transit / Stub / Network / Network / Network | | | | | | 299 |---| | |---| |---| |---| |---| | |---| 300 |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx | 301 |---| | |-- | |---| |---| |---| | |---| 302 | | | | | | 303 RSVP/ / diff-serv / RSVP/ / 304 int-serv/ / int-serv/ 306 Figure 1: Sample Network Configuration 308 In the interest of simplicity, Figure 1 shows a single QoS sender Tx 309 on one of the stub networks and a single QoS receiver Rx on the 310 other. The edge routers (ER1, ER2) within the RSVP/int-serv networks 311 interface to the border routers (BR1, BR1) of the diff-serv network. 313 From an economic viewpoint, we may consider that the transit network 314 sells service to the stub networks, which in turn sell service to end 315 systems. Thus, we may think of the stub networks as customers of the 316 transit network. In the following, we use the term "customer" for 317 each of the stub networks in Figure 1. 319 3.1 Components of the Model 321 We now define the major components of the proposed model. 323 3.1.1 Hosts 325 Both sending and receiving hosts use RSVP to communicate the 326 quantitative QoS requirements of QoS-aware applications running 327 on the host. Typically, a QoS process within the host 328 operating system generates RSVP signaling on behalf of the 329 applications; this process may also invoke local traffic 330 control. 332 Traffic control in the host may mark the DS-field in 333 transmitted packets, and it may shape transmitted traffic to 334 the requirements of the int-serv service in use. 335 Alternatively, the first-hop router within the int-serv network 336 may provide these traffic control functions. 338 3.1.2 End-to-End RSVP Signaling 340 We assume that RSVP signaling messages travel end-to-end 341 between hosts Tx and Rx to support int-serv reservations in the 342 stub networks. We require that these end-to-end RSVP messages 343 be tunneled transparently across the diff-serv transit network. 344 Mechanisms for this purpose are proposed in [8]; they do not 345 require the routers in the transit network to 346 understand/interpret RSVP messages and do not adversely impact 347 the transit network. 349 3.1.3 Edge Routers 351 We choose to place the boundary between the RSVP/int-serv 352 region and the diff-serv region of the network within the edge 353 routers. It is helpful to think of an edge router as 354 consisting of two halves: a standard RSVP half, which 355 interfaces to a stub network, and a diff-serv half, which 356 interfaces to the transit network. The RSVP half has full RSVP 357 capability. It is able to do MF classification, if required, 358 and it is able to police traffic that will be passed to the 359 border router. 361 The diff-serv half of the edge router provides an interface to 362 the diff-serv network's admission control function, which we 363 refer to as as `DSAC' (Diff-Serv Admission Control). 365 The customer(s) (owner(s) of the stub networks) and the carrier 366 owning the transit network will negotiate a contract for the 367 capacity to be provided at each of a number of standard diff- 368 serv service levels. If the service agreement between the stub 369 networks and the transit networks is statically provisioned, 370 then the DSAC can be simply based upon a table that specifies 371 capacity at each service level. If the service agreement is 372 dynamic, the DSAC may communicate with counterparts within the 373 diff-serv network (such as a bandwidth broker [4]) in order to 374 make admission control decisions based on provisioned limits as 375 well as the topology and the capacity of the diff-serv network. 377 Since the individual int-serv flows are policed according to 378 int-serv rules within the stub network, the edge router needs 379 to shape only the aggregate stream, not the individual flows. 381 3.1.4 Border Routers 383 BR1 and BR2 are diff-serv capable border routers, and are not 384 required to run RSVP. They are expected to implement the 385 policing function of diff-serv ingress routers, based on the 386 results of a BA classifier. They are required neither to 387 provide MF classification nor to mark the DS-field (with the 388 possible exception of differential marking to indicate out-of- 389 profile traffic [10, 8]). 391 3.1.5 Stub Networks 393 A stub network consists of int-serv capable hosts and some 394 number of routers. These routers may reasonably be assumed to 395 be RSVP/int-serv capable, although this might not be required 396 for a small over-provisioned stub network. If they are not 397 int-serv capable, we assume that they are not capable of per- 398 flow classification, signaling, or admission control and will 399 pass RSVP messages unhindered. 401 3.1.6 Transit Network 403 The transit network is not typically capable of per-flow 404 classification, signaling, and admission control. It provides 405 two or more levels of service based on the DS-field in the 406 headers of carried packets (diff-serv capable). Furthermore, 407 the transit network is able to carry RSVP messages 408 transparently, with minimal or no impact on its performance 409 (see [8]). The transit network may include multiple carrier 410 networks. 412 3.1.7 Service Mapping 414 RSVP signaling requests carry an int-serv service type and a 415 set of quantitative parameters known as a "flowspec"; these 416 describe the QoS expected from the int-serv regions of the 417 network. At each hop in an int-serv network, the generic int- 418 serv service requests are interpreted in a form meaningful to 419 the specific link layer medium. For example, at an ATM hop, a 420 VC of the correct type (CBR, ABR or VBR) is established [13]. 421 At an 802.1 hop, the int-serv service type is mapped to an 422 appropriate 802.1p priority level [5]. 424 In our model, the entire diff-serv network plays the role of a 425 single virtual link layer as far as RSVP/int-serv are 426 concerned. Therefore, the int-serv service request must be 427 mapped to the DS-field when the packets enter the diff-serv 428 cloud. The requested int-serv service must be mapped to a 429 diff-serv service level that can reasonably extend the int-serv 430 service type requested by the application. The edge router can 431 then provide admission control to the diff-serv network by 432 accepting or rejecting the request based on the capacity 433 available at the requested diff-serv service level. 435 One of two schemes may be used to map int-serv service types to 436 diff-serv service levels. 438 Default 440 In this scheme, there is some standard, well-known mapping 441 from int-serv service type to a PHB that will invoke the 442 appropriate behavior in the diffserv network. 444 To improve the quality of the mapping, it may prove 445 necessary to add additional information to an int-serv QoS 446 request. For example, consider QoS requests for two 447 different flows, one interactive voice traffic and the 448 other latency-tolerant traffic. They may both have the 449 same int-serv parameters (especially using the Controlled 450 Load service), but they are likely to map to different 451 diff-serv services. For this reason, we suggest adding a 452 qualifier to the int-serv service type indicating its 453 relative latency tolerance (high or low). The qualifier 454 would be defined as a standard object in int-serv 455 signaling messages. 457 Customer-Specified 459 In this scheme, the edge routers in the customer (stub) 460 networks are allowed to modify the service mapping. RESV 461 messages originating at hosts will carry the usual int- 462 serv service type (perhaps with a qualifier, as described 463 above). When a RESV message arrives at the edge router 464 from which the traffic enters the diff-serv region (e.g., 465 router ER1 in Figure 1), the edge router determines the 466 PHB code point that should be used to obtain the 467 corresponding diff-serv service level. This information 468 is appended to the RESV message by ER1 and carried to the 469 sending host. When the RESV message arrives at the 470 sending host, the sender (or intermediate int-serv 471 routers) start marking outgoing packets with the indicated 472 PHB code point. 474 A decision to override the well-known service mapping at the 475 edge router may be based on configuration and/or a policy 476 decision. For example, when a reservation request arrives at 477 the ingress to a diff-serv network, if accepted reservations 478 have already reached the pre-negotiated capacity limit at the 479 corresponding service level then the edge router may decide to 480 use a PHB corresponding to a different service level, based on 481 an administratively-set policy. 483 3.2 Example: Obtaining End-to-End QoS 485 The following sequence illustrates the process by which an 486 application obtains end-to-end QoS. 488 1. The QoS process on the sending host Tx generates an RSVP PATH 489 message that describes the traffic offered by the sending 490 application. 492 2. The PATH message is carried toward the receiving host Rx. In 493 the sender's stub network, standard RSVP processing is 494 applied at RSVP capable nodes (routers, SBMs, etc). 496 3. At the edge router ER1, the PATH message is subjected to 497 standard RSVP processing and PATH state is installed in the 498 router. The PATH message is sent onward, to the transit 499 network. 501 4. The PATH message is carried transparently through the transit 502 network, and then processed in stub router ER2 according to 503 standard RSVP processing rules. 505 5. When the PATH message reaches the receiving host Rx, its QoS 506 process generates an RSVP RESV message, indicating interest 507 in the offered traffic at a certain int-serv service level. 509 6. The RESV message is carried back towards the sending host. 510 Consistent with standard RSVP processing, it may be rejected 511 at any RSVP node in the receiver's stub network if resources 512 are deemed insufficient to carry the traffic requested. 514 7. At ER2, the RESV message is subjected to standard RSVP 515 processing. It may be rejected if resources on the 516 downstream interface of ER2 are deemed insufficient to carry 517 the resources requested. If it is not rejected, it will be 518 carried transparently through the transit network, arriving 519 at ER1. 521 8. In ER1, the RESV message triggers DSAC processing. The DSAC 522 compares the resources requested to the resources available 523 at the corresponding diff-serv service level, in the diff- 524 serv enabled transit network. If the RESV message is 525 admitted, the DSAC updates the available capacity for the 526 service class, by subtracting the approved resources from the 527 available capacity. 529 9. Assuming the available capacity is sufficient, the RESV 530 message is admitted and is allowed to continue upstream 531 towards the sending host. If the available capacity is 532 insufficient, the RESV message is rejected and the available 533 capacity for the service class remains unchanged. 535 10. The RESV message proceeds through the sender's stub network. 536 RSVP nodes in the sending stub network may reject it. If it 537 is not rejected, it will arrive at the sender host Tx. 539 11. At Tx, the QoS process receives the RESV message. It 540 interprets receipt of the message as an indication that the 541 specified traffic has been admitted for the specified int- 542 serv service type (in the RSVP enabled regions of the 543 network) and for the corresponding diff-serv service level 544 (in the diff-serv enabled regions of the network). 546 Tx begins to set the DS-field in the headers of transmitted 547 packets to the value which maps to the Intserv service type 548 specified in the admitted RESV message. 550 In this manner, we obtain end-to-end QoS through a combination of 551 networks that support RSVP style reservations and networks that 552 support diff-serv style prioritization. The successful arrival of 553 RESV messages at the original sender indicates that admission 554 control has succeeded both in the RSVP regions of the network and 555 in the diff-serv regions of the network. 557 3.3 Variations of the Model 559 It is useful to consider some variations of the model just 560 presented. 562 3.3.1 Moving the Boundary 564 We have assumed that the boundary between the RSVP/int-serv 565 network and the diff-serv network lies in the edge routers. 566 Alternative models could shift this boundary to the left or to 567 the right in Figure 1. It could for example, be placed within 568 the border routers in the transit network. In this case, the 569 DSAC would be implemented entirely within the diff-serv network 570 (and would essentially be the bandwidth broker proposed in 571 [4]); however, it would require that the diff-serv border 572 routers be RSVP capable. 574 Alternative, the boundary could be shifted all the way to the 575 end hosts. This would mean that the traffic was using diff- 576 serv mechanisms in the stub networks as well as the transit 577 network, while the int-serv mechanisms would be only in the 578 host. The QoS-aware application could still use RSVP within 579 the lost to signal its needs. The host would implement per- 580 flow policing, the DSAC function, and packet marking. 582 3.3.2 Service Agreements 584 o Statically-Provisioned Service Agreements 586 In the simplest model, service agreements are negotiated 587 statically between stub networks and transit networks. A 588 service agreement consists of a table of capacities 589 available to a stub network, at each diff-serv service 590 level. In this case, DSAC functionality is provided at 591 the edge routers in the stub networks. The `diff-serv 592 half' of these routers appear to the `RSVP half' as a 593 sending interface with resource limits defined by the 594 service agreement table. While there may be bandwidth 595 brokers and dynamic provisioning within the transit 596 networks, these are not coupled with the int-serv stub 597 networks, and admission control in the two regions of the 598 network is completely independent. 600 o Dynamic Service Agreements 602 In a more sophisticated model, service agreements between 603 customer stub networks and carrier transit networks are 604 more dynamic. Customers may be able to dynamically 605 request changes to the service agreement. In this case, a 606 statically provisioned edge router cannot provide the 607 required DSAC functionality. Instead, DSAC functionality 608 must be provided by coupling the stub network's admission 609 control with the transit network's admission control. 611 The two admission control mechanisms meet at the boundary 612 between the diff-serv network and the int-serv network. 613 This boundary may be implemented at the edge router (in 614 the stub network), at the border router (in the transit 615 network), or at the bandwidth broker for the int-serv 616 network. 618 Note that coupling int-serv and diff-serv admission 619 control does not imply that each int-serv admission 620 control request will result in DSAC processing. Int-serv 621 admission control requests may be aggregated at the 622 boundary between the int-serv and the diff-serv network. 623 For example, int-serv admission control requests may 624 trigger DSAC requests to bandwidth brokers only when some 625 high-water or low-water resource threshold is crossed. 626 Separate high-water and low-water thresholds can provide 627 hysteresis to prevent thrashing. 629 %.cm In the latter case, any MF classification on %.cm behalf 630 of the diff-serv ingress point is provided as a service to the 631 %.cm customer and goes beyond policing requirements). 633 3.3.3 Setting the DS-field 635 Allowing hosts to set the DS-field directly may alarm network 636 administrators. The obvious concern is that hosts may attempt 637 to 'steal' resources. In fact, hosts may attempt to exceed the 638 negotiated capacity at a particular service level regardless of 639 whether they invoke this service level directly (by setting the 640 DS-byte) or indirectly (by submitting traffic that classifies 641 in an intermediate router to a particular diff-serv PHB). 643 In summary, the security concerns of marking the DS-field at 644 the edge of the network can be dismissed since each carrier 645 will have to do some form of policing (per-flow or per-host) at 646 their boundary anyway. Furthermore, this approach reduces the 647 granularity at which border routers must police, thereby 648 pushing finer grain shaping and policing responsibility to the 649 edges of the network, where it scales better. The carriers are 650 thus focused on the task of protecting their transit networks, 651 while the customers are focused on the task of shaping and 652 policing their own traffic to be in compliance with their 653 negotiated token bucket parameters. 655 It is also possible to mark the DS-field at intermediate 656 routers rather than at the host and still realize many of the 657 benefits of our approach. In this case, intermediate routers 658 may use the RSVP signaling to configure an MF classifier and 659 marker. Then the configuration of MF classifiers and markers 660 would be dynamic (minimizing the management burden), and full 661 resource- and policy-based admission control could be applied. 663 The disadvantages of marking the DS-field at intermediate 664 routers (instead of the host) are that full MF classifiers are 665 required at the intermediate nodes and that responsibility for 666 traffic separation is shifted away from the host. 668 Nonetheless, marking at intermediate routers will be necessary 669 to support those hosts which support RSVP signaling but are 670 incapable of marking the DS-field. In addition, there may be 671 cases in which the network administrators wish to shift the 672 responsibility for traffic separation away from the hosts. In 673 particular, we expect that there will continue to be a need for 674 top-down provisioned MF classification, especially for 675 qualitative (as opposed to quantitative) QoS applications. See 676 Section 5.2. 678 4. Implications for Diff-Serv 680 We have described a framework for end-to-end QoS in which a diff-serv 681 network can be included as a segment of an int-serv path. This 682 section discusses some of the implications of this framework for 683 diff-serv. 685 4.1 Requirements for Diff-Serv 687 In order to use a diff-serv network as described in this draft, 688 the diff-serv network must satisfy the following requirements. 690 1. A diff-serv network must be able to provide standard QoS 691 services between its border routers, and such a service must 692 be selectable by specifying a standard code in a (PHB) sub- 693 field of the DS-field of a packet. 695 2. There must be appropriate service mappings from int-serv 696 services into these diff-serv services. 698 3. Diff-serv networks must provide admission control information 699 to the int-serv network. This information can be provided by 700 a dynamic protocol or, at the very least, through static 701 service level agreements. 703 4. Diff-serv networks must be able to transparently carry RSVP 704 messages, in such a manner that they can be recovered at the 705 egress point from the diff-serv network. 707 4.2 End-to-End Integrity of the DS-field 709 Our model assumes that int-serv networks uses a code point of the 710 DS-field in order to specify the desired PHB within the transit 711 network. It also assumes that packets submitted to the transit 712 network specifying a certain DS-field will receive a standard 713 service throughout the transit network. Strictly speaking, this 714 does not dictate that the transit network must leave the DS-field 715 field intact. For example, the border router may map a DS-field 716 value set by the host or edge router to a different value before 717 forwarding the data packets. 719 However, we see little value in allowing the PHB field to be 720 altered within the network. This is likely to perpetuate local 721 and incompatible interpretations of the field. 723 4.3 Policing and Shaping 725 We are assuming that border routers will police in aggregate. As 726 a result, the customer cannot rely on border routers to provide 727 traffic isolation between the customer's flows, when policing or 728 shaping. Instead, it is the customer's responsibility to ensure 729 that the customer's flows are properly shaped and policed within 730 the customer's sending network. Overall, this approach simplifies 731 border routers and still allows protection against misbehaving 732 hosts/users. 734 Ideally, hosts should provide per-flow shaping at their sending 735 interfaces. However, there is always a chance that the customer's 736 traffic will become distorted as it nears the boundary between the 737 customer and the carrier. In this case, the customer should do 738 per flow policing (or even re-shaping) at the egress point from 739 the customer's network unless the policing agreement at the other 740 side is known to accommodate the transient bursts that can arise 741 from adding the flows. 743 4.4 Managing Resource Pools 745 Network administrators must be able to share diff-serv network 746 resources between three types of traffic: 748 a. Quantitative (explicitly signaled) QoS application traffic 750 b. Qualitative (implicitly signaled) QoS application traffic 752 c. All other (best-effort) traffic 754 These pools must be isolated from each other by the appropriate 755 configuration of policers and classifiers at ingress points to the 756 diff-serv network, and by appropriate provisioning within the 757 diff-serv network. To provide protection for quantitative QoS 758 traffic in diff-serv regions of the network, we suggest that the 759 DS codepoints allotted to such traffic must not overlap the 760 codepoints assigned to other traffic (qualitative QoS and best- 761 effort traffic). 763 5. Other Models 765 5.1 RSVP and Diff-Serv 767 Since RSVP was originally designed to support int-serv, we use the 768 term "RVSP/int-serv" as the complement to diff-serv. However, 769 RSVP and int-serv are separable, and RSVP may be used as a 770 general-purpose QoS signaling protocol. For example, RSVP might 771 be used for dynamic provisioning and admission control in the 772 diff-serv region of the network. Routers in the diff-serv region 773 would continue use the DS-field in the IP header to identify and 774 offer services to flow aggregates. 776 5.2 Qualitative QoS 778 This document has focused largely on the class of applications 779 that use RSVP to explicitly signal per-flow QoS requirements and 780 that expect end-to-end tight QoS assurances. We have been 781 referring to these applications as `quantitative QoS 782 applications'. Suitable end-to-end services must also be 783 available to qualitative QoS applications. The services that 784 these applications require are generally less demanding. 786 Qualitative services can be obtained from the diff-serv regions of 787 the network with loose top-down provisioning. Network managers 788 can configure classifiers at the ingress to the diff-serv network 789 to recognize traffic requiring specific qualitative service 790 levels. Thus, these classification fields are used as a form of 791 implicit signaling. In the int-serv portion of the network, 792 qualitative QoS applications can get best-effort service, which 793 may be good enough. 795 There would be no explicit admission control for such qualitative 796 QoS applications. Therefore, it is difficult to assure that the 797 total traffic offered at an ingress point will not exceed the 798 provisioned capacity for a particular service level. When the 799 traffic exceeds the allowed limit, there is only indirect feedback 800 to the applications, in the form of packet loss or an Congestion 801 Experienced mark from Explicit Congestion Notification (ECN). 802 Thus, traffic from qualitative applications can be offered only 803 loose QoS. 805 5.3 Multicasting 807 809 6. Security Considerations 811 We are proposing that RSVP signaling be used to obtain resources in 812 both the diff-serv and int-serv regions of the network. Therefore, 813 all RSVP security considerations apply [11]. In addition, network 814 administrators are expected to protect network resources by 815 configuring secure policers at interfaces with untrusted customers. 817 7. Acknowledgments 819 Authors thank the following individuals for their comments that led 820 to improvements to the previous version(s) of this draft: David Oran, 821 Andy Veitch, Curtis Villamizer, Walter Weiss, and Russel white. 823 Many of the ideas in this document have been previously discussed in 824 the original int-serv architecture document [12]. 826 8. References 828 [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., 829 "Resource Reservation Protocol (RSVP) Version 1 Functional 830 Specification", RFC 2205, Proposed Standard, September 1997 832 [2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M., 833 "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based Admission 834 Control Over IEEE 802 Style Networks", Internet Draft, March 1998 836 [3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated 837 Services State", Internet Draft, December 1997. 839 [4] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit 840 Differentiated Services Architecture for the Internet", Internet 841 Draft, December 1997. 843 [5] Seaman, M., Smith, A. and Crawley, E., "Integrated Services Over 844 IEEE 802.1D/802.1p Networks", Internet Draft, June 1997 846 [6] Elleson, E. and Blake, S., "A Proposal for the Format and 847 Semantics of the TOS Byte and Traffic Class Byte in Ipv4 and Ipv6 848 Headers", Internet Draft, November 1997 850 [7] Ferguson, P., "Simple Differential Services: IP TOS and 851 Precedence, Delay Indication, and Drop Preference", Internet Draft, 852 November 1997 854 [8] Guerin, R., Blake, S. and Herzog, S.,"Aggregating RSVP based QoS 855 Requests", Internet Draft, November 1997. 857 [9] Nichols, Kathleen, et al., "Definition of the Differentiated 858 Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, 859 December 1998. 861 [10] Blake, S., et al., "An Architecture for Differentiated 862 Services." RFC 2475, December 1998. 864 [11] Baker, F., "RSVP Cryptographic Authentication", Internet Draft, 865 August 1997 867 [12] Braden, R., Clark, D. and Shenker, S., "Integrated Services in 868 the Internet Architecture: an Overview", Internet RFC 1633, June 1994 870 [13] Garrett, M. W., and Borden, M., "Interoperation of Controlled- 871 Load Service and Guaranteed Service with ATM", RFC2381, August 1998. 873 [14] Weiss, Walter, Private communication, November 1998. 875 [15] Berson, S. and Vincent, S., "Aggregation of Internet Integrated 876 Services State", Internet Draft, August 1998. 878 APPENDIX A. Terminology 880 The following terms were used in this draft. 882 Int-serv 883 The part of an internet that uses per-flow classification, 884 signaling, and admission control to deliver per-flow QoS 885 guarantee. 887 [Diff-serv region (or diff-serv capable network)] The part of an 888 internet that provides aggregate QoS services 890 Quantitative 891 Application for which QoS requirements are readily quantifiable, 892 and which relies on these QoS requirements to function properly. 894 Qualitative 895 Applications for which relative, but not readily quantifiable, 896 QoS requirements exist. 898 QoS Application that requires some form of QoS, either qualitative 899 or quantitative. 901 LooseQoS assurances that are relative, rather than absolute, or 902 generally not quantifiable. 904 TightQoS assurances which are quantifiable, though they may or may 905 not provide 100% guarantee. 907 Top-down 908 Traditional provisioning methods that configure network 909 capacities using heuristics and experience, typically from a 910 console, based upon traffic predictions. 912 Author's Addresses 914 Yoram Bernet 915 Microsoft 916 One Microsoft Way, 917 Redmond, WA 98052 918 Phone: (425) 936-9568 919 Email: yoramb@microsoft.com 921 Raj Yavatkar 922 Intel Corporation, JF3-206 923 2111 NE 25th. Avenue, 924 Hillsboro, OR 97124 925 Phone: (503) 264-9077 926 Email: raj.yavatkar@intel.com 928 Peter Ford 929 Microsoft 930 One Microsoft Way, 931 Redmond, WA 98052 932 Phone: (425) 703-2032 933 Email: peterf@microsoft.com 935 Fred Baker 936 Cisco Systems 937 519 Lado Drive, 938 Santa Barbara, CA 93111 939 Phone: (408) 526-4257 940 Email: fred@cisco.com 942 Lixia Zhang 943 UCLA 944 4531G Boelter Hall 945 Los Angeles, CA 90095 946 Phone: +1 310-825-2695 947 Email: lixia@cs.ucla.edu 949 Kathleen Nichols 950 Cisco Systems 951 Email: kmn@cisco.com 953 Michael Speer 954 Sun Microsystems, Inc 955 901 San Antonio Road UMPK15-215 956 Palo Alto, CA 94303 957 phone: +1 650-786-6368 958 Email: speer@Eng.Sun.COM 959 Bob Braden 960 USC Information Sciences Institute 961 4676 Admiralty Way 962 Marina del Rey, CA 90292-6695 963 phone: 310-822-1511 964 Email: braden@isi.edu