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