idnits 2.17.1 draft-ietf-issll-diffserv-rsvp-04.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): ---------------------------------------------------------------------------- ** 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: ---------------------------------------------------------------------------- ** 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 is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1565 lines 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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: '7' is defined on line 1310, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1324, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1328, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-issll-is802-sbm-08 -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 2638 (ref. '4') -- Unexpected draft version: The latest known version of draft-ietf-issll-is802-svc-mapping is -03, but you're referring to -04. -- Possible downref: Normative reference to a draft: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '10') -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 2401 (ref. '13') (Obsoleted by RFC 4301) -- No information found for draft-issll-dclass - is the name correct? -- Possible downref: Normative reference to a draft: ref. '14' -- No information found for draft-ietf-issll-aggregation - is the name correct? -- Possible downref: Normative reference to a draft: ref. '15' -- Possible downref: Normative reference to a draft: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Duplicate reference: RFC2638, mentioned in '20', was also mentioned in '4'. ** Downref: Normative reference to an Informational RFC: RFC 2638 (ref. '20') -- Possible downref: Non-RFC (?) normative reference: ref. '21' Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Y. Bernet, Microsoft 3 R. Yavatkar, Intel 4 P. Ford, Microsoft 5 F. Baker, Cisco 6 L. Zhang, UCLA 7 M. Speer, Sun Microsystems 8 R. Braden, ISI 9 B. Davie, Cisco 10 John Wroclawski, MIT LCS 11 E. Felstaine, Allot Communications 12 Internet Draft 13 Expires: September, 2000 14 Document: draft-ietf-issll-diffserv-rsvp-04.txt March, 2000 16 A Framework For Integrated Services Operation Over Diffserv Networks 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are 22 Working documents of the Internet Engineering Task Force (IETF), its 23 areas, and its working groups. Note that other groups may also 24 distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet- Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2000). All Rights Reserved. 41 1. Abstract 43 The Integrated Services architecture provides a means for the 44 delivery of end-to-end QoS to applications over heterogeneous 45 networks. To support this end-to-end model, the Intserv architecture 46 must be supported over a wide variety of different types of network 47 elements. In this context, a network that supports Differentiated 48 Services (Diffserv) may be viewed as a network element in the total 49 end-to-end path. This document describes a framework by which 50 Integrated Services may be supported over Diffserv networks. 52 Bernet, ed. et al. 1 54 Integrated Services Operation Over Diffserv Networks March, 2000 56 2. Introduction 58 Work on QoS-enabled IP networks has led to two distinct approaches: 59 the Integrated Services architecture (Intserv)[10] and its 60 accompanying signaling protocol, RSVP [1], and the Differentiated 61 Services architecture (Diffserv)[8]. This document describes ways in 62 which a Diffserv network can be used in the context of the Intserv 63 architecture to support the delivery of end-to-end QOS. 65 2.1 Integrated Services Architecture 67 The integrated services architecture defined a set of extensions to 68 the traditional best effort model of the Internet with the goal of 69 allowing end-to-end QOS to be provided to applications. One of the 70 key components of the architecture is a set of service definitions; 71 the current set of services consists of the controlled load and 72 guaranteed services. The architecture assumes that some explicit 73 setup mechanism is used to convey information to routers so that 74 they can provide requested services to flows that require them. 75 While RSVP is the most widely known example of such a setup 76 mechanism, the Intserv architecture is designed to accommodate other 77 mechanisms. 79 Intserv services are implemented by "network elements". While it is 80 common for network elements to be individual nodes such as routers 81 or links, more complex entities, such as ATM "clouds" or 802.3 82 networks may also function as network elements. As discussed in more 83 detail below, a Diffserv network (or "cloud") may be viewed as a 84 network element within a larger Intserv network. 86 2.3 RSVP 88 RSVP is a signaling protocol that applications may use to request 89 resources from the network. The network responds by explicitly 90 admitting or rejecting RSVP requests. Certain applications that have 91 quantifiable resource requirements express these requirements using 92 Intserv parameters as defined in the appropriate Intserv service 93 specification. As noted above, RSVP and Intserv are separable. RSVP 94 is a signaling protocol which may carry Intserv information. Intserv 95 defines the models for expressing service types, quantifying 96 resource requirements and for determining the availability of the 97 requested resources at relevant network elements (admission 98 control). 100 The current prevailing model of RSVP usage is based on a combined 101 RSVP/Intserv architecture. In this model, RSVP signals per-flow 102 resource requirements to network elements, using Intserv parameters. 103 These network elements apply Intserv admission control to signaled 104 requests. In addition, traffic control mechanisms on the network 105 element are configured to ensure that each admitted flow receives 106 the service requested in strict isolation from other traffic. To 108 Bernet, ed. et al. 2 110 Integrated Services Operation Over Diffserv Networks March, 2000 112 this end, RSVP signaling configures microflow (MF) [8] packet 113 classifiers in Intserv capable routers along the path of the traffic 114 flow. These classifiers enable per-flow classification of packets 115 based on IP addresses and port numbers. 117 The following factors have impeded deployment of RSVP (and the 118 Intserv architecture) in the Internet at large: 120 1. The use of per-flow state and per-flow processing raises 121 scalability concerns for large networks. 123 2. Only a small number of hosts currently generate RSVP signaling. 124 While this number is expected to grow dramatically, many 125 applications may never generate RSVP signaling. 127 3. The necessary policy control mechanisms -- access control, 128 authentication, and accounting -- have only recently become 129 available [17]. 131 2.4 Diffserv 133 In contrast to the per-flow orientation of RSVP, Diffserv networks 134 classify packets into one of a small number of aggregated flows or 135 "classes", based on the Diffserv codepoint (DSCP) in the packet's IP 136 header. This is known as behavior aggregate (BA) classification 137 [8]. At each Diffserv router, packets are subjected to a "per-hop 138 behavior" (PHB), which is invoked by the DSCP. The primary benefit 139 of Diffserv is its scalability. Diffserv eliminates the need for 140 per-flow state and per-flow processing and therefore scales well to 141 large networks. 143 2.5 Roles of Intserv, RSVP and Diffserv 145 We view Intserv, RSVP and Diffserv as complementary technologies in 146 the pursuit of end-to-end QoS. Together, these mechanisms can 147 facilitate deployment of applications such as IP-telephony, video- 148 on-demand, and various non-multimedia mission-critical applications. 149 Intserv enables hosts to request per-flow, quantifiable resources, 150 along end-to-end data paths and to obtain feedback regarding 151 admissibility of these requests. Diffserv enables scalability across 152 large networks. 154 2.6 Components of Intserv, RSVP and Diffserv 156 Before proceeding, it is helpful to identify the following 157 components of the QoS technologies described: 159 RSVP signaling - This term refers to the standard RSVP signaling 160 protocol. RSVP signaling is used by hosts to signal application 161 resource requirements to the network (and to each other). Network 162 elements use RSVP signaling to return an admission control decision 163 to hosts. RSVP signaling may or may not carry Intserv parameters. 165 Bernet, ed. et al. 3 167 Integrated Services Operation Over Diffserv Networks March, 2000 169 Admission control at a network element may or may not be based on 170 the Intserv model. 172 MF traffic control - This term refers to traffic control which is 173 applied independently to individual traffic flows and therefore 174 requires recognizing individual traffic flows via MF classification. 176 Aggregate traffic control - This term refers to traffic control 177 which is applied collectively to sets of traffic flows. These sets 178 of traffic flows are recognized based on BA (DSCP) classification. 179 In this document, we use the terms "aggregate traffic control" and 180 "Diffserv" interchangeably. 182 Aggregate RSVP. While the existing definition of RSVP supports only 183 per-flow reservations, extensions to RSVP are being developed to 184 enable RSVP reservations to be made for aggregated traffic, i.e. 185 sets of flows that may be recognized by BA classification. This use 186 of RSVP may be useful in controlling the allocation of bandwidth in 187 Diffserv networks. 189 Per-flow RSVP. The conventional usage of RSVP to perform resource 190 reservations for individual microflows. 192 RSVP/Intserv - This term is used to refer to the prevailing model of 193 RSVP usage which includes RSVP signaling with Intserv parameters, 194 Intserv admission control and per-flow traffic control at network 195 elements. 197 Diffserv Region. A set of contiguous routers which support BA 198 classification and traffic control. While such a region may also 199 support MF classification, the goal of this document is to describe 200 how such a region may be used in delivery of end-to-end QOS when 201 only BA classification is performed inside the Diffserv region. 203 Non-Diffserv Region. The portions of the network outside the 204 Diffserv region. Such a region may also offer a variety of different 205 types of classification and traffic control. 207 Note that, for the purposes of this document, the defining features 208 of a Diffserv region is the type of classification and traffic 209 control that is used for the delivery of end-to-end QOS for a 210 particular application. Thus, while it may not be possible to 211 identify a certain region as "purely Diffserv" with respect to all 212 traffic flowing through the region, it is possible to define it in 213 this way from the perspective of the treatment of traffic from a 214 single application. 216 2.7 The Framework 218 In the framework we present, end-to-end, quantitative QoS is 219 provided by applying the Intserv model end-to-end across a network 221 Bernet, ed. et al. 4 223 Integrated Services Operation Over Diffserv Networks March, 2000 225 containing one or more Diffserv regions. The Diffserv regions may, 226 but are not required to, participate in end-to-end RSVP signaling 227 for the purpose of optimizing resource allocation and supporting 228 admission control. 230 From the perspective of Intserv, Diffserv regions of the network are 231 treated as virtual links connecting Intserv capable routers or hosts 232 (much as an 802.1p network region is treated as a virtual link in 233 [5]). Within the Diffserv regions of the network routers implement 234 specific PHBs (aggregate traffic control). The total amount of 235 traffic that is admitted into the Diffserv region that will receive 236 a certain PHB may be limited by policing at the edge. As a result 237 we expect that the Diffserv regions of the network will be able to 238 support the Intserv style services requested from the periphery. 239 In our framework, we address the support of end-to-end Integrated 240 Services over the Diffserv regions of the network. Our goal is to 241 enable seamless inter-operation. As a result, the network 242 administrator is free to choose which regions of the network act as 243 Diffserv regions. In one extreme the Diffserv region is pushed all 244 the way to the periphery, with hosts alone having full Intserv 245 capability. In the other extreme, Intserv is pushed all the way to 246 the core, with no Diffserv region. 248 2.8 Contents 250 In section 3 we discuss the benefits that can be realized by using 251 the aggregate traffic control provided by Diffserv network regions 252 in the broader context of the Intserv architecture. In section 4, we 253 present the framework and the reference network. Section 5 details 254 two possible realizations of the framework. Section 6 discusses the 255 implications of the framework for Diffserv. Section 7 presents some 256 issues specific to multicast flows. 258 3. Benefits of Using Intserv with Diffserv 260 The primary benefit of Diffserv aggregate traffic control is its 261 scalability. In this section, we discuss the benefits that 262 interoperation with Intserv can bring to a Diffserv network region. 263 Note that this discussion is in the context of servicing 264 quantitative QoS applications specifically. By this we mean those 265 applications that are able to quantify their traffic and QoS 266 requirements. 268 3.1 Resource Based Admission Control 270 In Intserv networks, quantitative QoS applications use an explicit 271 setup mechanism (e.g. RSVP) to request resources from the network. 272 The network may accept or reject these requests in response. This is 273 "explicit admission control". Explicit admission control helps to 274 assure that network resources are optimally used. To further 275 understand this issue, consider a Diffserv network region providing 276 only aggregate traffic control with no signaling. In the Diffserv 278 Bernet, ed. et al. 5 280 Integrated Services Operation Over Diffserv Networks March, 2000 282 network region, admission control is applied implicitly by 283 provisioning policing parameters at network elements. For example, a 284 network element at the ingress to a Diffserv network region could be 285 provisioned to accept only 50 Kbps of traffic for the EF DSCP. 287 While such implicit admission control does protect the network to 288 some degree, it can be quite ineffective. For example, consider that 289 there may be 10 IP telephony sessions originating outside the 290 Diffserv network region, each requiring 10 Kbps of EF service from 291 the Diffserv network region. Since the network element protecting 292 the Diffserv network region is provisioned to accept only 50 Kbps of 293 traffic for the EF DSCP, it will discard half the offered traffic. 294 This traffic will be discarded from the aggregation of traffic 295 marked EF, with no regard to the microflow from which it originated. 296 As a result, it is likely that of the ten IP telephony sessions, 297 none will obtain satisfactory service when in fact, there are 298 sufficient resources available in the Diffserv network region to 299 satisfy five sessions. 301 In the case of explicit admission control, the network will signal 302 rejection in response to requests for resources that would exceed 303 the 50 Kbps limit. As a result, upstream network elements (including 304 originating hosts) and applications will have the information they 305 require to take corrective action. The application might respond by 306 refraining from transmitting, or by requesting admission for a 307 lesser traffic profile. The host operating system might respond by 308 marking the application's traffic for the DSCP that corresponds to 309 best-effort service. Upstream network elements might respond by re- 310 marking packets on the rejected flow to a lower service level. In 311 some cases, it may be possible to reroute traffic over alternate 312 paths or even alternate networks (e.g. the PSTN for voice calls). In 313 any case, the integrity of those flows that were admitted would be 314 preserved, at the expense of the flows that were not admitted. Thus, 315 by appointing an Intserv-conversant admission control agent for the 316 Diffserv region of the network it is possible to enhance the service 317 that the network can provide to quantitative QoS applications. 319 3.2 Policy Based Admission Control 321 In network regions where RSVP is used, resource requests can be 322 intercepted by RSVP-aware network elements and can be reviewed 323 against policies stored in policy databases. These resource requests 324 securely identify the user and the application for which the 325 resources are requested. Consequently, the network element is able 326 to consider per-user and/or per-application policy when deciding 327 whether or not to admit a resource request. So, in addition to 328 optimizing the use of resources in a Diffserv network region (as 329 discussed in 3.1) RSVP conversant admission control agents can be 330 used to apply specific customer policies in determining the specific 331 customer traffic flows entitled to use the Diffserv network region's 332 resources. Customer policies can be used to allocate resources to 333 specific users and/or applications. 335 Bernet, ed. et al. 6 337 Integrated Services Operation Over Diffserv Networks March, 2000 339 By comparison, in Diffserv network regions without RSVP signaling, 340 policies are typically applied based on the Diffserv customer 341 network from which traffic originates, not on the originating user 342 or application within the customer network. 344 3.3 Assistance in Traffic Identification/Classification 346 Within Diffserv network regions, traffic is allotted service based 347 on the DSCP marked in each packet's IP header. Thus, in order to 348 obtain a particular level of service within the Diffserv network 349 region, it is necessary to effect the marking of the correct DSCP in 350 packet headers. There are two mechanisms for doing so, host marking 351 and router marking. In the case of host marking, the host operating 352 system marks the DSCP in transmitted packets. In the case of router 353 marking, routers in the network are configured to identify specific 354 traffic (typically based on MF classification) and to mark the DSCP 355 as packets transit the router. There are advantages and 356 disadvantages to each scheme. Regardless of the scheme used, 357 explicit signaling offers significant benefits. 359 3.3.1 Host Marking 361 In the case of host marking, the host operating system marks the 362 DSCP in transmitted packets. This approach has the benefit of 363 shifting per-flow classification and marking to the source of the 364 traffic, where it scales best. It also enables the host to make 365 decisions regarding the mark that is appropriate for each 366 transmitted packet and hence the relative importance attached to 367 each packet. The host is generally better equipped to make this 368 decision than the network. Furthermore, if IPSEC encryption is used, 369 the host may be the only device in the network that is able to make 370 a meaningful determination of the appropriate marking for each 371 packet. 373 Host marking requires that the host be aware of the interpretation 374 of DSCPs by the network. This information can be configured into 375 each host. However, such configuration imposes a management burden. 376 Alternatively, hosts can use an explicit signaling protocol such as 377 RSVP to query the network to obtain a suitable DSCP or set of DSCPs 378 to apply to packets for which a certain Intserv service has been 379 requested. An example of how this can be achieved is described in 380 [14]. 382 3.3.2 Router Marking 384 In the case of router marking, MF classification criteria must be 385 configured in the router. This may be done dynamically, by request 386 from the host operating system, or statically via manual 387 configuration or via automated scripts. 389 Bernet, ed. et al. 7 391 Integrated Services Operation Over Diffserv Networks March, 2000 393 There are significant difficulties in doing so statically. 394 Typically, it is desirable to allot service to traffic based on the 395 application and/or user originating the traffic. At times it is 396 possible to identify packets associated with a specific application 397 by the IP port numbers in the headers. It may also be possible to 398 identify packets originating from a specific user by the source IP 399 address. However, such classification criteria may change 400 frequently. Users may be assigned different IP addresses by DHCP. 401 Applications may use transient ports. To further complicate matters, 402 multiple users may share an IP address. These factors make it very 403 difficult to manage static configuration of the classification 404 information required to mark traffic in routers. 406 An attractive alternative to static configuration is to allow host 407 operating systems to signal classification criteria to the router on 408 behalf of users and applications. As we will show later in this 409 document, RSVP signaling is ideally suited for this task. In 410 addition to enabling dynamic and accurate updating of MF 411 classification criteria, RSVP signaling enables classification of 412 IPSEC [13] packets (by use of the SPI) which would otherwise be 413 unrecognizable. 415 3.4 Traffic Conditioning 417 Intserv-capable network elements are able to condition traffic at a 418 per-flow granularity, by some combination of shaping and/or 419 policing. Pre-conditioning traffic in this manner before it is 420 submitted to the Diffserv region of the network is beneficial. In 421 particular, it enhances the ability of the Diffserv region of the 422 network to provide quantitative services using aggregate traffic 423 control. 425 4. The Framework 427 In the general framework we envision an Internet in which the 428 Integrated Services architecture is used to deliver end-to-end QOS 429 to applications. The network includes some combination of Intserv 430 capable nodes (in which MF classification and per-flow traffic 431 control is applied) and Diffserv regions (in which aggregate traffic 432 control is applied). Individual routers may or may not participate 433 in RSVP signaling regardless of where in the network they reside. 435 We will consider two specific realizations of the framework. In the 436 first, resources within the Diffserv regions of the network are 437 statically provisioned and these regions include no RSVP aware 438 devices. In the second, resources within the Diffserv region of the 439 network are dynamically provisioned and select devices within the 440 Diffserv network regions participate in RSVP signaling. 442 4.1 Reference Network 444 Bernet, ed. et al. 8 446 Integrated Services Operation Over Diffserv Networks March, 2000 448 The two realizations of the framework will be discussed in the 449 context of the following reference network: 451 ________ ______________ ________ 452 / \ / \ / \ 453 / \ / \ / \ 454 |---| | |---| |---| |---| |---| | |---| 455 |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx | 456 |---| | |-- | |---| |---| |---| | |---| 457 \ / \ / \ / 458 \________/ \______________/ \________/ 460 Non-Diffserv region Diffserv region Non-Diffserv region 462 Figure 1: Sample Network Configuration 464 The reference network includes a Diffserv region in the middle of a 465 larger network supporting Intserv end-to-end. The Diffserv region 466 contains a mesh of routers, at least some of which provide aggregate 467 traffic control. The regions outside the Diffserv region (non- 468 Diffserv regions) contain meshes of routers and attached hosts, at 469 least some of which support the Integrated Services architecture. 471 In the interest of simplicity we consider a single QoS sender, Tx 472 communicating across this network with a single QoS receiver, Rx. 473 The edge routers (ER1, ER2) which are adjacent to the Diffserv 474 region interface to the border routers (BR1, BR2) within the 475 Diffserv region. 477 From an economic viewpoint, we may consider that the Diffserv region 478 sells service to the network outside the Diffserv region, which in 479 turn provides service to hosts. Thus, we may think of the non- 480 Diffserv regions as clients or customers of the Diffserv region. In 481 the following, we use the term "customer" for the non-Diffserv 482 regions. Note that the boundaries of the regions may or may not 483 align with administrative domain boundaries, and that a single 484 region might contain multiple administrative domains. 486 We now define the major components of the reference network. 488 4.1.1 Hosts 490 We assume that both sending and receiving hosts use RSVP to 491 communicate the quantitative QoS requirements of QoS-aware 492 applications running on the host. In principle, other mechanisms may 493 be used to establish resource reservations in Intserv-capable nodes, 494 but RSVP is clearly the prevalent mechanism for this purpose. 496 Typically, a QoS process within the host operating system generates 497 RSVP signaling on behalf of applications. This process may also 498 invoke local traffic control. 500 Bernet, ed. et al. 9 502 Integrated Services Operation Over Diffserv Networks March, 2000 504 As discussed above, traffic control in the host may mark the DSCP in 505 transmitted packets, and shape transmitted traffic to the 506 requirements of the Intserv service in use. Alternatively, the first 507 Intserv-capable router downstream from the host may provide these 508 traffic control functions. 510 4.1.2 End-to-End RSVP Signaling 512 We assume that RSVP signaling messages travel end-to-end between 513 hosts Tx and Rx to support RSVP/Intserv reservations outside the 514 Diffserv network region. We require that these end-to-end RSVP 515 messages are at least carried across the Diffserv region. Depending 516 on the specific realization of the framework, these messages may be 517 processed by none, some or all of the routers in the Diffserv 518 region. 520 4.1.3 Edge Routers 522 ER1 and ER2 are edge routers, residing adjacent to the Diffserv 523 network regions. The functionality of the edge routers varies 524 depending on the specific realization of the framework. In the case 525 in which the Diffserv network region is RSVP unaware, edge routers 526 act as admission control agents to the Diffserv network. They 527 process signaling messages from both Tx and Rx, and apply admission 528 control based on resource availability within the Diffserv network 529 region and on customer defined policy. In the case in which the 530 Diffserv network region is RSVP aware, the edge routers apply 531 admission control based on local resource availability and on 532 customer defined policy. In this case, the border routers act as the 533 admission control agent to the Diffserv network region. 535 We will later describe the functionality of the edge routers in 536 greater depth for each of the two realizations of the framework. 538 4.1.4 Border Routers 540 BR1 and BR2 are border routers, residing in the Diffserv network 541 region. The functionality of the border routers varies depending on 542 the specific realization of the framework. In the case in which the 543 Diffserv network region is RSVP-unaware, these routers act as pure 544 Diffserv routers. As such, their sole responsibility is to police 545 submitted traffic based on the service level specified in the DSCP 546 and the agreement negotiated with the customer (aggregate traffic 547 control). In the case in which the Diffserv network region is RSVP- 548 aware, the border routers participate in RSVP signaling and act as 549 admission control agents for the Diffserv network region. 551 We will later describe the functionality of the border routers in 552 greater depth for each of the two realizations of the framework. 554 Bernet, ed. et al. 10 556 Integrated Services Operation Over Diffserv Networks March, 2000 558 4.1.5 Diffserv Network Region 560 The Diffserv network region supports aggregate traffic control and 561 is assumed not to be capable of MF classification. Depending on the 562 specific realization of the framework, some number of routers within 563 the Diffserv region may be RSVP aware and therefore capable of per- 564 flow signaling and admission control. If devices in the Diffserv 565 region are not RSVP aware, they will pass RSVP messages 566 transparently with negligible performance impact (see [6]). 568 The Diffserv network region provides two or more levels of service 569 based on the DSCP in packet headers. It may be a single 570 administrative domain or may span multiple domains. 572 4.1.5 Non-Diffserv Network Regions 574 The network outside of the Diffserv region consists of Intserv 575 capable hosts and other network elements. Other elements may include 576 routers and perhaps various types of network (e.g. 802, ATM, etc.). 577 These network elements may reasonably be assumed to support Intserv, 578 although this might not be required in the case of over- 579 provisioning. Even if these elements are not Intserv capable, we 580 assume that they will pass RSVP messages unhindered. Routers outside 581 of the Diffserv network region are not precluded from providing 582 aggregate traffic control to some subset of the traffic passing 583 through them. 585 4.2 Service Mapping 587 Intserv service requests specify an Intserv service type and a set 588 of quantitative parameters known as a "flowspec". At each hop in an 589 Intserv network, the Intserv service requests are interpreted in a 590 form meaningful to the specific link layer medium. For example at 591 an 802.1 hop, the Intserv parameters are mapped to an appropriate 592 802.1p priority level [5]. 594 In our framework, Diffserv regions of the network are analogous to 595 the 802.1p capable switched segments described in [5]. Requests for 596 Intserv services must be mapped onto the underlying capabilities of 597 the Diffserv network region. Aspects of the mapping include: 599 - selecting an appropriate PHB, or set of PHBs, for the requested 600 service; 601 - performing appropriate policing (including, perhaps, shaping or 602 remarking) at the edges of the Diffserv region; 603 - exporting Intserv parameters from the Diffserv region (e.g. for 604 the updating of ADSPECs); 605 - performing admission control on the Intserv requests that takes 606 into account the resource availability in the Diffserv region. 608 Bernet, ed. et al. 11 610 Integrated Services Operation Over Diffserv Networks March, 2000 612 Exactly how these functions are performed will be a function of the 613 way bandwidth is managed inside the Diffserv network region, which 614 is a topic we discuss in Section 4.3. 616 When the PHB (or set of PHBs) has been selected for a particular 617 Intserv flow, it may be necessary to communicate the choice of DSCP 618 for the flow to other network elements. Two schemes may be used to 619 achieve this end, as discussed below. 621 4.2.1 Default Mapping 623 In this scheme, there is some standard, well-known mapping from 624 Intserv service type to a DSCP that will invoke the appropriate 625 behavior in the Diffserv network. 627 4.2.2 Network Driven Mapping 629 In this scheme, RSVP conversant routers in the Diffserv network 630 region (perhaps at its edge) may override the well-known mapping 631 described in 4.2.1. In the case that DSCPs are marked at the ingress 632 to the Diffserv region, the DSCPs can simply be remarked at the 633 boundary routers. However, in the case that DSCP marking occurs 634 upstream of the Diffserv region, either in a host or a router, then 635 the appropriate mapping needs to be communicated upstream, to the 636 marking device. This may be accomplished using RSVP, as described 637 in [14]. 639 The decision regarding where to mark DSCP and whether to override 640 the well-known service mapping is a mater of policy to be decided by 641 the administrator of the Diffserv network region in cooperation with 642 the administrator of the network adjacent to the Diffserv region. 644 4.2.3 Microflow Separation 646 Boundary routers residing at the edge of the Diffserv region will 647 typically police traffic submitted from the outside the Diffserv 648 region in order to protect resources within the Diffserv region. 649 This policing will be applied on an aggregate basis, with no regard 650 for the individual microflows making up each aggregate. As a result, 651 it is possible for a misbehaving microflow to claim more than its 652 fair share of resources within the aggregate, thereby degrading the 653 service provided to other microflows. This problem may be addressed 654 by: 656 1. Providing per microflow policing at the edge routers - this is 657 generally the most appropriate location for microflow policing, 658 since it pushes per-flow work to the edges of the network, where it 659 scales better. In addition, since Intserv-capable routers outside 660 the Diffserv region are responsible for providing microflow service 661 to their customers and the Diffserv region is responsible for 662 providing aggregate service to its customers, this distribution of 663 functionality mirrors the distribution of responsibility. 665 Bernet, ed. et al. 12 667 Integrated Services Operation Over Diffserv Networks March, 2000 669 2. Providing per microflow policing at the border routers - this 670 approach tends to be less scalable than the previous approach. It 671 also imposes a management burden on the Diffserv region of the 672 network. However, it may be appropriate in certain cases, for the 673 Diffserv boundary routers to offer per microflow policing as a 674 value-add to its Intserv customers. 676 3. Relying on upstream shaping and policing - in certain cases, the 677 customer may trust the shaping of certain groups of hosts 678 sufficiently to not warrant reshaping or policing at the boundary of 679 the Diffserv region. Note that, even if the hosts are shaping 680 microflows properly, these shaped flows may become distorted as they 681 transit through the non-Diffserv region of the network. Depending on 682 the degree of distortion, it may be necessary to somewhat over- 683 provision the aggregate capacities in the Diffserv region, or to re- 684 police using either 1 or 2 above. 685 The choice of one mechanism or another is a matter of policy to be 686 decided by the administrator of the network outside the Diffserv 687 region. 689 4.3 Resource Management in Diffserv Regions 691 A variety of options exist for management of resources (e.g., 692 bandwidth) in the Diffserv network regions to meet the needs of end- 693 to-end Intserv flows. These options include: 695 - statically provisioned resources; 696 - resources dynamically provisioned by RSVP; 697 - resources dynamically provisioned by other means (e.g., a form of 698 Bandwidth Broker). 700 Some of the details of using each of these different approaches are 701 discussed in the following section. 703 5. Detailed Examples of the Operation of Intserv over Diffserv Regions 705 In this section we provide detailed examples of our framework in 706 action. We discuss two examples, one in which the Diffserv network 707 region is RSVP unaware, the other in which the Diffserv network 708 region is RSVP aware. 710 5.1 Statically Provisioned Diffserv Network Region 712 In this example, no devices in the Diffserv network region are RSVP 713 aware. The Diffserv network region is statically provisioned. The 714 customer(s) of the Diffserv network regions and the owner of the 715 Diffserv network region have negotiated a static contract (service 716 level specification, or SLS) for the transmit capacity to be 717 provided to the customer at each of a number of standard Diffserv 718 service levels. The "transmit capacity" may be simply an amount of 720 Bernet, ed. et al. 13 722 Integrated Services Operation Over Diffserv Networks March, 2000 724 bandwidth or it could be a more complex "profile" involving a number 725 of factors such as burst size, peak rate, time of day etc. 727 It is helpful to consider each edge router in the customer network 728 as consisting of two halves, a standard Intserv half, which 729 interfaces to the customer's network regions and a Diffserv half 730 which interfaces to the Diffserv network region. The Intserv half is 731 able to identify and process traffic on per-flow granularity. 733 The Diffserv half of the router can be considered to consist of a 734 number of virtual transmit interfaces, one for each Diffserv service 735 level negotiated in the SLS. The router contains a table that 736 indicates the transmit capacity provisioned, per the SLS at each 737 Diffserv service level. This table, in conjunction with the default 738 mapping described in 4.2.1, is used to perform admission control 739 decisions on Intserv flows which cross the Diffserv network region. 741 5.1.1 Sequence of Events in Obtaining End-to-end QoS 743 The following sequence illustrates the process by which an 744 application obtains end-to-end QoS when RSVP is used by the hosts. 746 1. The QoS process on the sending host Tx generates an RSVP PATH 747 message that describes the traffic offered by the sending 748 application. 750 2. The PATH message is carried toward the receiving host, Rx. In the 751 network region to which the sender is attached, standard 752 RSVP/Intserv processing is applied at capable network elements. 754 3. At the edge router ER1, the PATH message is subjected to standard 755 RSVP processing and PATH state is installed in the router. The PATH 756 message is sent onward to the Diffserv network region. 758 4. The PATH message is ignored by routers in the Diffserv network 759 region and then processed at ER2 according to standard RSVP 760 processing rules. 762 5. When the PATH message reaches the receiving host Rx, the 763 operating system generates an RSVP RESV message, indicating interest 764 in offered traffic of a certain Intserv service type. 766 6. The RESV message is carried back towards the Diffserv network 767 region and the sending host. Consistent with standard RSVP/Intserv 768 processing, it may be rejected at any RSVP-capable node in the path 769 if resources are deemed insufficient to carry the traffic requested. 771 7. At ER2, the RESV message is subjected to standard RSVP/Intserv 772 processing. It may be rejected if resources on the downstream 773 interface of ER2 are deemed insufficient to carry the resources 774 requested. If it is not rejected, it will be carried transparently 775 through the Diffserv network region, arriving at ER1. 777 Bernet, ed. et al. 14 779 Integrated Services Operation Over Diffserv Networks March, 2000 781 8. In ER1, the RESV message triggers admission control processing. 782 ER1 compares the resources requested in the RSVP/Intserv request to 783 the resources available in the Diffserv network region at the 784 corresponding Diffserv service level. The corresponding service 785 level is determined by the Intserv to Diffserv mapping discussed 786 previously. The availability of resources is determined by the 787 capacity provisioned in the SLS. ER1 may also apply a policy 788 decision such that the resource request may be rejected based on the 789 customer's specific policy criteria, even though the aggregate 790 resources are determined to be available per the SLS. 792 9. If ER1 approves the request, the RESV message is admitted and is 793 allowed to continue upstream towards the sender. If it rejects the 794 request, the RESV is not forwarded and the appropriate RSVP error 795 messages are sent. If the request is approved, ER1 updates its 796 internal tables to indicate the reduced capacity available at the 797 admitted service level on its transmit interface. 799 10. The RESV message proceeds through the network region to which 800 the sender is attached. Any RSVP node in this region may reject the 801 reservation request due to inadequate resources or policy. If the 802 request is not rejected, the RESV message will arrive at the sending 803 host, Tx. 805 11. At Tx, the QoS process receives the RESV message. It interprets 806 receipt of the message as indication that the specified traffic flow 807 has been admitted for the specified Intserv service type (in the 808 Intserv-capable nodes). It may also learn the appropriate DSCP 809 marking to apply to packets for this flow from information provided 810 in the RESV. 812 12. Tx may mark the DSCP in the headers of packets that are 813 transmitted on the admitted traffic flow. The DSCP may be the 814 default value which maps to the Intserv service type specified in 815 the admitted RESV message, or it may be a value explicitly provided 816 in the RESV. 818 In this manner, we obtain end-to-end QoS through a combination of 819 networks that support RSVP/Intserv and networks that support 820 Diffserv. 822 5.2 RSVP-Aware Diffserv Network Region 824 In this example, the customer's edge routers are standard RSVP 825 routers. The border router, BR1 is RSVP aware. In addition, there 826 may be other routers within the Diffserv network region which are 827 RSVP aware. Note that although these routers are able to participate 828 in some form of RSVP signaling, they classify and schedule traffic 829 in aggregate, based on DSCP, not on the per-flow classification 830 criteria used by standard RSVP/Intserv routers. It can be said that 831 their control-plane is RSVP while their data-plane is Diffserv. This 833 Bernet, ed. et al. 15 835 Integrated Services Operation Over Diffserv Networks March, 2000 837 approach exploits the benefits of RSVP signaling while maintaining 838 much of the scalability associated with Diffserv. 840 In the preceding example, there is no signaling between the Diffserv 841 network region and network elements outside it. The negotiation of 842 an SLS is the only explicit exchange of resource availability 843 information between the two network regions. ER1 is configured with 844 the information represented by the SLS and as such, is able to act 845 as an admission control agent for the Diffserv network region. Such 846 configuration does not readily support dynamically changing SLSs, 847 since ER1 requires reconfiguration each time the SLS changes. It is 848 also difficult to make efficient use of the resources in the 849 Diffserv network region. This is because admission control does not 850 consider the availability of resources in the Diffserv network 851 region along the specific path that would be impacted. 853 By contrast, when the Diffserv network region is RSVP aware, the 854 admission control agent is part of the Diffserv network. As a 855 result, changes in the capacity available in the Diffserv network 856 region can be indicated to the Intserv-capable nodes outside the 857 Diffserv region via RSVP. By including routers interior to the 858 Diffserv network region in RSVP signaling, it is possible to 859 simultaneously improve the efficiency of resource usage within the 860 Diffserv region and to improve the level of confidence that the 861 resources requested at admission control are indeed available at 862 this particular point in time. This is because admission control can 863 be linked to the availability of resources along the specific path 864 that would be impacted. We refer to this benefit of RSVP signaling 865 as "topology aware admission control". A further benefit of 866 supporting RSVP signaling within the Diffserv network region is that 867 it is possible to effect changes in the provisioning of the Diffserv 868 network region (e.g., allocating more or less bandwidth to the EF 869 queue in a router) in response to resource requests from outside of 870 the Diffserv region. 872 Various mechanisms may be used within the Diffserv network region to 873 support dynamic provisioning and topology aware admission control. 874 These include aggregated RSVP, per-flow RSVP and bandwidth brokers, 875 as described in the following paragraphs. 877 5.2.1 Aggregated or Tunneled RSVP 879 A number of drafts [3,6,15, 16] propose mechanisms for extending 880 RSVP to reserve resources for an aggregation of flows between edges 881 of a network. Border routers may interact with core routers and 882 other border routers using aggregated RSVP to reserve resources 883 between edges of the Diffserv network region. Initial reservation 884 levels for each service level may be established between major 885 border routers, based on anticipated traffic patterns. Border 886 routers could trigger changes in reservation levels as a result of 887 the cumulative per-flow RSVP requests from the non-Diffserv regions 888 reaching high or low-water marks. 890 Bernet, ed. et al. 16 892 Integrated Services Operation Over Diffserv Networks March, 2000 894 In this approach, admission of per-flow RSVP requests from nodes 895 outside the Diffserv region would be counted against the appropriate 896 aggregate reservations for the corresponding service level. The size 897 of the aggregate reservations may or may not be dynamically adjusted 898 to deal with the changes in per-flow reservations. 900 The advantage of this approach is that it offers dynamic, topology 901 aware admission control to the Diffserv network region without 902 requiring the level of RSVP signaling processing that would be 903 required to support per-flow RSVP. 905 We note that resource management of a Diffserv region using 906 aggregated RSVP is most likely to be feasible only within a single 907 administrative domain, as each domain will probably choose its own 908 mechanism to manage its resources. 910 5.2.3 Per-flow RSVP 912 In this approach, described in [3], routers in the Diffserv network 913 region respond to the standard per-flow RSVP signaling originating 914 from the Intserv-capable nodes outside the Diffserv region. This 915 approach provides the benefits of the previous approach (dynamic, 916 topology aware admission control) without requiring aggregated RSVP 917 support. Resources are also used more efficiently as a result of the 918 per-flow admission control. However, the demands on RSVP signaling 919 resources within the Diffserv network region may be significantly 920 higher than in an aggregated RSVP approach. 922 Note that per-flow RSVP and aggregated RSVP are not mutually 923 exclusive in a single Diffserv region. It is possible to use per- 924 flow RSVP at the edges of the Diffserv region and aggregation only 925 in some "core" region within the Diffserv region. 927 5.2.4 Granularity of Deployment of RSVP Aware Routers 929 In 5.2.2 and 5.2.3 some subset of the routers within the Diffserv 930 network is RSVP signaling aware (though traffic control is 931 aggregated as opposed to per-flow). The relative number of routers 932 in the core that participate in RSVP signaling is a provisioning 933 decision that must be made by the network administrator. 935 In one extreme case, only the border routers participate in RSVP 936 signaling. In this case, either the Diffserv network region must be 937 extremely over-provisioned and therefore, inefficiently used, or 938 else it must be carefully and statically provisioned for limited 939 traffic patterns. The border routers must enforce these patterns. 941 In the other extreme case, each router in the Diffserv network 942 region might participate in RSVP signaling. In this case, resources 943 can be used with optimal efficiency, but signaling processing 944 requirements and associated overhead increase. As noted above, RSVP 946 Bernet, ed. et al. 17 948 Integrated Services Operation Over Diffserv Networks March, 2000 950 aggregation is one way to limit the signaling overhead at the cost 951 of some loss of optimality in resource utilization. 953 It is likely that some network administrators will compromise by 954 enabling RSVP signaling on some subset of routers in the Diffserv 955 network region. These routers will likely represent major traffic 956 switching points with over-provisioned or statically provisioned 957 regions of RSVP unaware routers between them. 959 5.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region 961 Border routers might not use any form of RSVP signaling within the 962 Diffserv network region but might instead use custom protocols to 963 interact with an "oracle". The oracle is a hypothetical agent that 964 has sufficient knowledge of resource availability and network 965 topology to make admission control decisions. The set of RSVP aware 966 routers in the previous two examples can be considered collectively 967 as a form of distributed oracle. In various definitions of the 968 "bandwidth broker" [4], it is able to act as a centralized oracle. 970 6. Implications of the Framework for Diffserv Network Regions 972 We have described a framework in which RSVP/Intserv style QoS can be 973 provided across end-to-end paths that include Diffserv network 974 regions. This section discusses some of the implications of this 975 framework for the Diffserv network region. 977 6.1 Requirements from Diffserv Network Regions 979 A Diffserv network region must meet the following requirements in 980 order for it to support the framework described in this document. 982 1. A Diffserv network region must be able to provide support for the 983 standard Intserv QoS services between its border routers. It must be 984 possible to invoke these services by use of standard PHBs within the 985 Diffserv region and appropriate behavior at the edge of the Diffserv 986 region. 988 2. Diffserv network regions must provide admission control 989 information to their "customer" (non-Diffserv) network regions. 990 This information can be provided by a dynamic protocol or through 991 static service level agreements enforced at the edges of the 992 Diffserv region. 994 3. Diffserv network regions must be able to pass RSVP messages, in 995 such a manner that they can be recovered at the egress of the 996 Diffserv network region. The Diffserv network region may, but is not 997 required to, process these messages. Mechanisms for transparently 998 carrying RSVP messages across a transit network are described in 999 [3,6,15, 16]. 1001 Bernet, ed. et al. 18 1003 Integrated Services Operation Over Diffserv Networks March, 2000 1005 To meet these requirements, additional work is required in the areas 1006 of: 1008 1. Mapping Intserv style service specifications to services that can 1009 be provided by Diffserv network regions. 1010 2. Definition of the functionality required in network elements to 1011 support RSVP signaling with aggregate traffic control (for network 1012 elements residing in the Diffserv network region). 1013 3. Definition of mechanisms to efficiently and dynamically provision 1014 resources in a Diffserv network region (e.g. aggregated RSVP, 1015 tunneling, MPLS, etc.). This might include protocols by which an 1016 "oracle" (e.g., a centralized server) conveys information about 1017 resource availability within a Diffserv region to border routers. 1018 One example of such a mechanism is the so-called "bandwidth broker" 1019 proposed in [19, 20, 21]. 1021 6.2 Protection of Intserv Traffic from Other Traffic 1023 Network administrators must be able to share resources in the 1024 Diffserv network region between three types of traffic: 1026 a. End-to-end Intserv traffic - this is typically traffic 1027 associated with quantitative QoS applications. It requires a 1028 specific quantity of resources with a high degree of assurance. 1030 b. Non-Intserv traffic. The Diffserv region may allocate resources 1031 to traffic that does not make use of Intserv techniques to quantify 1032 its requirements, e.g. through the use of static provisioning and 1033 SLSs enforced at the edges of the region. Such traffic might be 1034 associated with applications whose QoS requirements are not readily 1035 quantifiable but which require a "better than best-effort" level of 1036 service. 1038 c. All other (best-effort) traffic 1040 These three classes of traffic must be isolated from each other by 1041 the appropriate configuration of policers and classifiers at ingress 1042 points to the Diffserv network region, and by appropriate 1043 provisioning within the Diffserv network region. To provide 1044 protection for Intserv traffic in Diffserv regions of the network, 1045 we suggest that the DSCPs assigned to such traffic not overlap with 1046 the DSCPs assigned to other traffic. 1048 7. Multicast 1049 The use of integrated services over Diffserv networks is 1050 significantly more complex for multicast sessions than for unicast 1051 sessions. With respect to a multicast connection, each participating 1052 region has a single ingress router and zero, one or several egress 1053 routers. The difficulties of multicast are associated with Diffserv 1054 regions that contain several egress routers. (Support of multicast 1055 functionality outside the Diffserv region is relatively 1057 Bernet, ed. et al. 19 1059 Integrated Services Operation Over Diffserv Networks March, 2000 1061 straightforward since every Intserv-capable router along the 1062 multicast tree stores state for each flow.) 1064 Consider the following reference network: 1066 Non-Diffserv region 2 1067 ________ 1068 / \ 1069 | | |---| 1070 ________ _____________ | |-|Rx1| 1071 / \ / |--\ |---| | |---| 1072 / \ / /|BR2\-----\ER2| / 1073 |---| | |---| |---| |--|/ |---| \--|____/ 1074 |Tx |-| |ER1|---|BR1|--|RR| | ________ 1075 |---| | |-- | |---| |--|\ |---| /--| \ 1076 \ / \ \|BR3/-----|ER3| | |---| 1077 \________/ \__________|--/ |---| |-|Rx2| 1078 | | |---| 1079 Non-Diffserv region 1 Diffserv region \ / 1080 \______/ 1082 Non-Diffserv region 3 1084 Figure 2: Sample Multicast Network Configuration 1086 The reference network is similar to that of Figure 1. However, in 1087 Figure 2, copies of the packets sent by Tx are delivered to several 1088 receivers outside of the Diffserv region, namely to Rx1 and Rx2. 1089 Moreover, packets are copied within the Diffserv region in a "branch 1090 point" router RR. In the reference network BR1 is the ingress router 1091 to the Diffserv region whereas BR2 and BR3 are the egress routers. 1093 In the simplest case the receivers, Rx1 and Rx2 in the reference 1094 network, require identical reservations. The Diffserv framework [18] 1095 supports service level specifications (SLS) from an ingress router 1096 to one, some or all of the egress routers. This calls for a "one to 1097 many" SLS within the Diffserv region, from BR1 to BR2 and BR3. Given 1098 that the SLS is granted by the Diffserv region, the ingress router 1099 BR1, or perhaps an upstream node such as ER1, marks packets entering 1100 the Diffserv region with the appropriate DSCP. The packets are 1101 routed to the egresses of the Diffserv domain using the original 1102 multicast address. 1104 The two major problems, explained in the following, are associated 1105 with heterogeneous multicast trees containing branch points within 1106 the Diffserv region, i.e. multicast trees where the level of 1107 resource requirement is not uniform among all receivers. An example 1108 of such a scenario in the network of Figure 2 is the case where both 1109 Rx1 and Rx2 need to receive multicast data from Tx1 but only one of 1111 Bernet, ed. et al. 20 1113 Integrated Services Operation Over Diffserv Networks March, 2000 1115 the receivers has requested a level of service above best effort. We 1116 consider such scenarios in the following paragraphs. 1118 7.1 Remarking of packets in branch point routers 1120 In the above scenario, the packets that arrive at BR1 are marked 1121 with an appropriate DSCP for the requested Intserv service and are 1122 sent to RR. Packets arriving at the branch point must be sent 1123 towards BR2 with the same DSCP otherwise the service to Rx1 is 1124 degraded. However, the packets going from RR towards BR3 need not 1125 maintain the high assurance level anymore. They may be demoted to 1126 best effort so that the QoS provided to other packets along this 1127 branch of the tree is not disrupted. Several problems can be 1128 observed in the given scenario: 1130 - In the Diffserv region, DSCP marking is done at edge routers 1131 (ingress), whereas a branch point router might be a core 1132 router, which does not mark packets. 1134 - Being a core Diffserv router, RR classifies based on 1135 aggregate traffic streams (BA), as opposed to per flow (MF) 1136 classification. Hence, it does not necessarily have the 1137 capability to distinguish those packets which belong to a 1138 specific multicast tree and require demotion from the other 1139 packets in the behavior aggregate, which carry the same DSCP. 1141 - Since RR may be RSVP-unaware, it may not participate in the 1142 admission control process, and would thus not store any per- 1143 flow state about the reservations for the multicast tree. 1144 Hence, even if RR were able to perform MF classification and 1145 DSCP remarking, it would not know enough about downstream 1146 reservations to remark the DSCP intelligently. 1148 These problems can be tackled by the following mechanisms: 1150 1. If some Intserv-capable routers are placed within the Diffserv 1151 region, it might be possible to administer the network topology and 1152 routing parameters so as to ensure that branch points occur only 1153 within such routers. These routers would support MF classification 1154 and remarking and hold per-flow state for the heterogeneous 1155 reservations for which they are the branch point. Note that in this 1156 case, branch point routers would have essentially the same 1157 functionality as ingress routers of an RSVP-aware Diffserv domain. 1159 2. Packets sent on the "non-reserved" branch (from RR towards BR3) 1160 are marked with the "wrong" DSCP; that is, they are not demoted to 1161 best effort but retain their DSCP. This in turn requires over 1162 reservation of resources along that link or runs the risk of 1163 degrading service to packets that legitimately bear the same DSCP 1164 along this path. However, it allows the Diffserv routers to remain 1165 free of per-flow state. 1167 Bernet, ed. et al. 21 1169 Integrated Services Operation Over Diffserv Networks March, 2000 1171 3. A combination of mechanism 1 and 2 may be an effective 1172 compromise. In this case, there are some Intserv-capable routers in 1173 the core of the network, but the network cannot be administered so 1174 that ALL branch points fall at such routers. 1176 4. Administrators of Diffserv regions may decide not to enable 1177 heterogeneous sub-trees in their domains. In the case of different 1178 downstream reservations, a ResvErr message would be sent according 1179 to the RSVP rules. This is similar to the approach taken for Intserv 1180 over IEEE 802 Networks [2,5]. 1182 5. In [3], a scheme was introduced whereby branch point routers in 1183 the interior of the aggregation region (i.e. the Diffserv region) 1184 keep reduced state information regarding the reservations by using 1185 measurement based admission control. Under this scheme, packets are 1186 tagged by the more knowledgeable Intserv edges routers with 1187 scheduling information that is used in place of the detailed Intserv 1188 state. If the Diffserv region and branch point routers are designed 1189 following that framework, demotion of packets becomes possible. 1191 7.2 Multicast SLSs and Heterogeneous Trees 1193 Multicast flows with heterogeneous reservations present some 1194 challenges in the area of SLSs. For example, a common example of an 1195 SLS is one where a certain amount of traffic is allowed to enter a 1196 Diffserv region marked with a certain DSCP, and such traffic may be 1197 destined to any egress router of that region. We call such an SLS a 1198 homogeneous, or uniform, SLS. However, in a multicast environment, a 1199 single packet that is admitted to the Diffserv region may consume 1200 resources along many paths in the region as it is replicated and 1201 forwarded towards many egress routers; alternatively, it may flow 1202 along a single path. This situation is further complicated by the 1203 possibility described above and depicted in Figure 2, in which a 1204 multicast packet might be treated as best effort along some branches 1205 while receiving some higher QOS treatment along others. We simply 1206 note here that the specification of meaningful SLSs which meet the 1207 needs of heterogeneous flows and which can be met be providers is 1208 likely to be challenging. 1210 Dynamic SLSs may help to address these issues. For example, by using 1211 RSVP to signal the resources that are required along different 1212 branches of a multicast tree, it may be possible to more closely 1213 approach the goal of allocating appropriate resources only where 1214 they are needed rather than overprovisioning or underprovisioning 1215 along certain branches of a tree. This is essentially the approach 1216 described in [15]. 1218 8. Security Considerations 1220 8.1 General RSVP Security 1222 Bernet, ed. et al. 22 1224 Integrated Services Operation Over Diffserv Networks March, 2000 1226 We are proposing that RSVP signaling be used to obtain resources in 1227 both Diffserv and non-Diffserv regions of a network. Therefore, all 1228 RSVP security considerations apply [9]. In addition, network 1229 administrators are expected to protect network resources by 1230 configuring secure policers at interfaces with untrusted customers. 1232 8.2 Host Marking 1234 Though it does not mandate host marking of the DSCP, our proposal 1235 does allow it. Allowing hosts to set the DSCP directly may alarm 1236 network administrators. The obvious concern is that hosts may 1237 attempt to "steal" resources. In fact, hosts may attempt to exceed 1238 negotiated capacity in Diffserv network regions at a particular 1239 service level regardless of whether they invoke this service level 1240 directly (by setting the DSCP) or indirectly (by submitting traffic 1241 that classifies in an intermediate marking router to a particular 1242 DSCP). 1244 In either case, it will generally be necessary for each Diffserv 1245 network region to protect its resources by policing to assure that 1246 customers do not use more resources than they are entitled to, at 1247 each service level (DSCP). The exception to this rule is when the 1248 host is known to be trusted, e.g. a server that is under the control 1249 of the network administrators. If an untrusted sending host does not 1250 perform DSCP marking, the boundary router (or trusted intermediate 1251 routers) must provide MF classification, mark and police. If an 1252 untrusted sending host does perform marking, the boundary router 1253 needs only to provide BA classification and to police to ensure that 1254 the customer is not exceeding the aggregate capacity negotiated for 1255 the service level. 1257 In summary, there are no additional security concerns raised by 1258 marking the DSCP at the edge of the network since Diffserv providers 1259 will have to police at their boundaries anyway. Furthermore, this 1260 approach reduces the granularity at which border routers must 1261 police, thereby pushing finer grain shaping and policing 1262 responsibility to the edges of the network, where it scales better 1263 and provides other benefits described in Section 3.3.1. The larger 1264 Diffserv network regions are thus focused on the task of protecting 1265 their networks, while the Intserv-capable nodes are focused on the 1266 task of shaping and policing their own traffic to be in compliance 1267 with their negotiated Intserv parameters. 1269 9. Acknowledgments 1271 Authors thank the following individuals for their comments that led 1272 to improvements to the previous version(s) of this document: David 1273 Oran, Andy Veitch, Curtis Villamizer, Walter Weiss, Francois le 1274 Faucheur and Russell White. 1276 Many of the ideas in this document have been previously discussed in 1277 the original Intserv architecture document [10]. 1279 Bernet, ed. et al. 23 1281 Integrated Services Operation Over Diffserv Networks March, 2000 1283 10. References 1285 [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., 1286 "Resource Reservation Protocol (RSVP) Version 1 Functional 1287 Specification", RFC 2205, Proposed Standard, September 1997 1289 [2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M., 1290 "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based 1291 Admission Control Over IEEE 802 Style Networks", Internet Draft, 1292 draft-ietf-issll-is802-sbm-08.txt, May 1999 1294 [3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated 1295 Services State", Internet Draft, draft-berson-rsvp-aggregation- 1296 00.txt, August 1998. 1298 [4] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit 1299 Differentiated Services Architecture for the Internet", RFC 1300 2638, July 1999. 1302 [5] Seaman, M., Smith, A., Crawley, E., and Wroclawski, J., 1303 "Integrated Service Mappings on IEEE 802 Networks", Internet 1304 Draft, draft-ietf-issll-is802-svc-mapping-04.txt, June 1999 1306 [6] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based 1307 QoS Requests", Internet Draft, draft-guerin-aggreg-rsvp-00.txt, 1308 November 1997. 1310 [7] Nichols, Kathleen, et al., "Definition of the Differentiated 1311 Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 1312 2474, December 1998. 1314 [8] Blake, S., et al., "An Architecture for Differentiated 1315 Services." RFC 2475, December 1998. 1317 [9] Baker, F., "RSVP Cryptographic Authentication", Internet Draft, 1318 draft-ietf-rsvp-md5-08.txt, February 1999 1320 [10] Braden, R., Clark, D. and Shenker, S., "Integrated Services in 1321 the Internet Architecture: an Overview", Internet RFC 1633, 1322 June 1994 1324 [11] Garrett, M. W., and Borden, M., "Interoperation of Controlled- 1325 Load Service and Guaranteed Service with ATM", RFC2381, August 1326 1998. 1328 [12] Weiss, Walter, Private communication, November 1998. 1330 [13] Kent, S., Atkinson, R., "Security Architecture for the Internet 1331 Protocol", RFC 2401, November 1998. 1333 Bernet, ed. et al. 24 1335 Integrated Services Operation Over Diffserv Networks March, 2000 1337 [14] Bernet, Y., "Usage and Format of the DCLASS Object with RSVP 1338 Signaling", Internet Draft, draft-issll-dclass-00.txt, August 1339 1999. 1341 [15] Baker, F., Iturralde, C., le Faucheur, F., and Davie, B. "RSVP 1342 Reservation Aggregation", Internet Draft, draft-ietf-issll- 1343 aggregation-00.txt, September 1999. 1345 [16] Terzis, A., Krawczyk, J., Wroclawski, J., Zhang, L., "RSVP 1346 Operation Over IP Tunnels", Internet Draft, draft-ietf-rsvp- 1347 tunnel-04.txt, May 1999. 1349 [17] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, D., and 1350 Sastry, A., "COPS Usage for RSVP", Internet Draft, draft-ietf- 1351 rap-cops-rsvp-05.txt, June 1999. 1353 [18] Bernet, Y., et al., "A Framework for Differentiated Services", 1354 Internet draft, draft-ietf-diffserv-framework-02.txt, February 1355 1999. 1357 [19] Jacobson Van, "Differentiated Services Architecture", talk in 1358 the Int-Serv WG at the Munich IETF, August 1997. 1360 [20] Jacobson, V., Nichols K., and Zhang, L. "A Two-bit 1361 Differentiated Services Architecture for the Internet", 1362 RFC 2638, June 1999. 1364 [21] First Internet2 bandwidth broker operability event 1365 http://www.merit.edu/internet/working.groups/i2-qbone-bb/ 1366 inter-op/index.htm 1368 11. Author's Addresses: 1370 Yoram Bernet 1371 Microsoft 1372 One Microsoft Way, Redmond, WA 98052 1373 Phone: (425) 936-9568 1374 Email: yoramb@microsoft.com 1376 Raj Yavatkar 1377 Intel Corporation 1378 JF3-448 2111 NE 25th. Avenue, Hillsboro, OR 97124 1379 Phone: (503) 264-9077 1380 Email: raj.yavatkar@intel.com 1382 Peter Ford 1383 Microsoft 1384 One Microsoft Way, Redmond, WA 98052 1385 Phone: (425) 703-2032 1386 Email: peterf@microsoft.com 1388 Fred Baker 1390 Bernet, ed. et al. 25 1392 Integrated Services Operation Over Diffserv Networks March, 2000 1394 Cisco Systems 1395 519 Lado Drive, Santa Barbara, CA 93111 1396 Phone: (408) 526-4257 1397 Email: fred@cisco.com 1399 Lixia Zhang 1400 UCLA 1401 4531G Boelter Hall Los Angeles, CA 90095 1402 Phone: (310) 825-2695 1403 Email: lixia@cs.ucla.edu 1405 Michael Speer 1406 Sun Microsystems 1407 901 San Antonio Road UMPK15-215 Palo Alto, CA 94303 1408 Phone: (650)786-6368 1409 Email: speer@Eng.Sun.COM 1411 Bob Braden 1412 USC Information Sciences Institute 1413 4676 Admiralty Way Marina del Rey, CA 90292-6695 1414 Phone: (310) 822-1511 1415 Email: braden@isi.edu 1417 Bruce Davie 1418 Cisco Systems 1419 250 Apollo Drive, Chelmsford, MA 01824 1420 Phone: (978) 244-8000 1421 Email: bsd@cisco.com 1423 Eyal Felstaine 1424 Dept. of Computer Science 1425 Technion, IIT 1426 32000 Haifa, Israel 1427 Phone: +972-50-747672 1428 Email: eyalfe@cs.technion.ac.il 1430 John Wroclawski 1431 MIT Laboratory for Computer Science 1432 545 Technology Sq. 1433 Cambridge, MA 02139 1434 Phone: (617) 253-7885 1435 E-mail: jtw@lcs.mit.edu 1437 12. Full Copyright Statement 1439 Copyright (C) The Internet Society (2000). All Rights Reserved. 1441 This document and translations of it may be copied and furnished to 1442 others, and derivative works that comment on or otherwise explain it 1443 or assist in its implementation may be prepared, copied, published 1444 and distributed, in whole or in part, without restriction of any 1446 Bernet, ed. et al. 26 1448 Integrated Services Operation Over Diffserv Networks March, 2000 1450 kind, provided that the above copyright notice and this paragraph 1451 are included on all such copies and derivative works. However, this 1452 document itself may not be modified in any way, such as by removing 1453 the copyright notice or references to the Internet Society or other 1454 Internet organizations, except as needed for the purpose of 1455 developing Internet standards in which case the procedures for 1456 copyrights defined in the Internet Standards process must be 1457 followed, or as required to translate it into languages other than 1458 English. 1460 The limited permissions granted above are perpetual and will not be 1461 revoked by the Internet Society or its successors or assigns. 1463 This document and the information contained herein is provided on an 1464 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1465 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1466 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1467 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1468 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1470 This draft expires September, 2000 1472 Bernet, ed. et al. 27