idnits 2.17.1 draft-ietf-issll-diffserv-rsvp-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 18 longer pages, the longest (page 17) being 60 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '12' on line 977 looks like a reference -- Missing reference section? '1' on line 933 looks like a reference -- Missing reference section? '10' on line 967 looks like a reference -- Missing reference section? '5' on line 949 looks like a reference -- Missing reference section? '17' on line 993 looks like a reference -- Missing reference section? '16' on line 990 looks like a reference -- Missing reference section? '8' on line 960 looks like a reference -- Missing reference section? '18' on line 996 looks like a reference -- Missing reference section? '19' on line 999 looks like a reference -- Missing reference section? '4' on line 945 looks like a reference -- Missing reference section? '11' on line 970 looks like a reference -- Missing reference section? '2' on line 937 looks like a reference -- Missing reference section? '3' on line 942 looks like a reference -- Missing reference section? '6' on line 952 looks like a reference -- Missing reference section? '7' on line 956 looks like a reference -- Missing reference section? '9' on line 963 looks like a reference -- Missing reference section? '13' on line 981 looks like a reference -- Missing reference section? '14' on line 985 looks like a reference -- Missing reference section? '15' on line 987 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 21 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 Internet Draft 10 Expires: September, 1999 11 Document: draft-ietf-issll-diffserv-rsvp-01.txt March, 1999 13 Interoperation of RSVP/Intserv and Diffserv Networks 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are 19 Working documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet- Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 linebreak http://www.ietf.org/shadow.html. 34 1. Abstract 36 RSVP/Integrated Services and Differentiated Services provide 37 complementary approaches to the problem of providing end-to-end QoS 38 in the Internet. These approaches must be able to coexist and 39 effectively inter-operate. This document describes a framework by 40 which the two approaches inter-operate to provide end-to-end QoS for 41 quantitative applications (applications for which QoS requirements 42 are readily quantifiable, and which rely on these QoS requirements 43 to function properly). 45 2. Introduction 47 Work on QoS-enabled IP networks has led to two distinct approaches: 48 the Integrated Services architecture (intserv)[12] and its 49 accompanying signaling protocol, RSVP [1], vs. the Differentiated 50 Services architecture (diffserv)[10]. 52 2.1 RSVP/Intserv 54 Bernet, ed. et. al 1 55 Use of RSVP with Diffserv March, 1999 57 RSVP is a signaling protocol that applications may use to request 58 resources from the network. The network responds by explicitly 59 admitting or rejecting RSVP requests. Certain applications that have 60 quantifiable resource requirements express these requirements using 61 intserv parameters. It is important to emphasize that RSVP and 62 intserv are separable; RSVP is a signaling protocol. Intserv is a 63 set of models for expressing service types, quantifying resource 64 requirements and for determining the availability of the requested 65 resources at relevant network elements (admission control). 67 The current prevailing model of RSVP usage is based on a combined 68 RSVP/intserv architecture. In this model, RSVP signals per-flow 69 resource requirements to network elements, using Intserv parameters. 70 These network elements apply Intserv admission control to signaled 71 requests. In addition, traffic control mechanisms on the network 72 element are configured to ensure that each admitted flow receives 73 the service requested in strict isolation from other traffic. To 74 this end, RSVP signaling configures 'MF' [10] packet classifiers in 75 intserv capable routers along the path of the traffic flow. These 76 classifiers enable per-flow classification of packets based on IP 77 addresses and port numbers. 79 The following factors have impeded deployment of the RSVP/Intserv 80 architecture in the Internet at large: 82 1. The use of per-flow state and per-flow processing raises 83 scalability concerns for large networks. 85 2. Only a small number of hosts currently generate RSVP signaling. 86 While this number is expected to grow dramatically, many 87 applications may never generate RSVP signaling. 89 3. The necessary policy control mechanisms -- access control, 90 authentication, and accounting -- are not available. 92 2.2 Diffserv 94 The market is pushing for immediate deployment of a QoS solution 95 that addresses the needs of the Internet as well as enterprise 96 networks. This push led to the development of diffserv. In contrast 97 to the per-flow orientation of RSVP/intserv, diffserv networks 98 classify packets into one of a small number of aggregated flows or 99 'classes', based on the diffserv codepoint (DSCP) in the packet's IP 100 header. This is known as 'BA' classification [10]. At each diffserv 101 router, packets are subjected to a 'per-hop behaviour' (PHB), which 102 is invoked by the DSCP. The primary benefit of diffserv is its 103 scalability. Diffserv eliminates the need for per-flow state and 104 per-flow processing and therefore scales well to large networks. 106 2.3 Complementary Roles of RSVP/Intserv and Diffserv 108 We view RSVP/intserv and diffserv as complementary technologies in 109 the pursuit of end-to-end QoS. Together, these mechanisms can 110 facilitate deployment of applications such as IP-telephony, video- 112 Bernet, ed. et. al 2 113 Use of RSVP with Diffserv March, 1999 115 on-demand, and various non-multimedia mission-critical applications. 116 RSVP/intserv enables hosts to request per-flow, quantifiable 117 resources, along end-to-end data paths and to obtain feedback 118 regarding admissibility of these requests. Diffserv enables 119 scalability across large networks. 121 2.3 Components of RSVP/intserv and Diffserv 123 Before proceeding, it is helpful to identify the following 124 components of the QoS technologies described: 126 RSVP signaling - This term refers to the standard RSVP per-flow 127 signaling protocol. RSVP signaling is used by hosts to signal per- 128 flow resource requirements to the network (and to each other). 129 Network elements use RSVP signaling to return an admission control 130 decision to hosts. RSVP signaling may or may not carry intserv 131 parameters. Admission control at a network element may or may not be 132 based on the intserv model. 134 RSVP/Intserv - This term is used to refer to the prevailing model of 135 RSVP usage which includes RSVP signaling with intserv parameters, 136 intserv admission control and per-flow traffic control at network 137 elements. 139 MF traffic control - This term refers to traffic control which is 140 applied independently to individual traffic flows and therefore 141 requires recognizing individual traffic flows via MF classification. 143 Aggregate traffic control - This term refers to traffic control 144 which is applied collectively to sets of traffic flows. These sets 145 of traffic flows are recognized based on BA (DSCP) classification. 146 In this draft, we use the terms 'aggregate traffic control' and 147 'diffserv' interchangeably. 149 We will refer to RSVP/intserv regions of the network and diffserv 150 regions of the network. RSVP/intserv regions are those regions in 151 which both RSVP signaling and MF traffic control are supported. 152 These regions include hosts and network elements that are 153 RSVP/intserv capable. (RSVP/intserv regions are not precluded from 154 supporting aggregate traffic control as well as MF traffic control). 155 Diffserv regions are those regions in which aggregate traffic 156 control is supported. 158 2.4 The Framework 160 In the framework we present, end-to-end, quantitative QoS is 161 provided by coupling RSVP/Intserv regions at the periphery of the 162 network with diffserv regions in the core of the network. The 163 diffserv regions may, but are not required to, participate in the 164 end-to-end RSVP signaling for the purpose of optimizing resource 165 allocation and supporting admission control. 167 From the perspective of RSVP/intserv, diffserv regions of the 168 network are treated as virtual links connecting RSVP/Intserv capable 170 Bernet, ed. et. al 3 171 Use of RSVP with Diffserv March, 1999 173 routers or hosts (much as an 802.1p network region is treated as a 174 virtual link in [5]). Within the diffserv regions of the network 175 routers implement specific PHBs (aggregate traffic control). We use 176 RSVP to apply admission control to each PHB in the diffserv region. 177 As a result we expect that the diffserv regions of the network will 178 be able to extend the intserv style services requested from the 179 periphery. As such, we often refer to the RSVP/intserv network 180 regions as 'customers' of the diffserv network regions. 182 In our framework, we address the inter-operability between the 183 RSVP/intserv regions of the network and the diffserv regions of the 184 network. Our goal is to enable seamless inter-operation. As a 185 result, the network administrator is free to choose which regions of 186 the network act as RSVP/intserv regions and which act as diffserv 187 regions. In one extreme the diffserv region is pushed all the way to 188 the periphery, with hosts alone comprising the RSVP/intserv regions 189 of the network. In the other extreme, RSVP/intserv is pushed all the 190 way to the core, with no diffserv region. 192 2.5 Contents 194 In section 3 we discuss the benefits that can be realized by using 195 RSVP/intserv together with the aggregate traffic control provided by 196 diffserv network regions. In section 4, we present the framework and 197 the reference network. Section 5 details two realizations of the 198 framework. Section 6 discusses the implications of the framework for 199 diffserv. Appendix A contains a list of some important terms used in 200 this document. 202 Though the primary goal of this draft is to describe a framework 203 for inter-operation of RSVP/intserv network regions and diffserv 204 network regions, the draft currently does not address the issues 205 specific to IP multicast flows. 207 3. Benefits of Using RSVP/intserv with Diffserv 209 The primary benefit of diffserv aggregate traffic control is its 210 scalability. In this section, we discuss the benefits that 211 interoperation with RSVP/intserv can bring to a diffserv network 212 region. Note that this discussion is in the context of servicing 213 quantitative applications specifically. 215 3.1 Resource Based Admission Control 217 In RSVP/Intserv networks, quantitative QoS applications use RSVP to 218 request resources from the network. The network may accept or reject 219 these requests in response. This is 'explicit admission control'. 220 Explicit admission control helps to assure that network resources 221 are optimally used. To further understand this issue, consider a 222 diffserv network region providing only aggregate traffic control 223 with no signaling. In the diffserv network region, admission control 224 is applied implicitly by provisioning policing parameters at network 225 elements. For example, a network element at the ingress to a 227 Bernet, ed. et. al 4 228 Use of RSVP with Diffserv March, 1999 230 diffserv network region could be provisioned to accept only 50 Kbps 231 of traffic for the EF DSCP. 233 While such implicit admission control does protect the network to 234 some degree, it can be quite ineffective. For example, consider that 235 there may be 10 IP telephony sessions originating outside the 236 diffserv network region, each requiring 10 Kbps of EF service from 237 the diffserv network region. Since the network element protecting 238 the diffserv network region is provisioned to accept only 50 Kbps of 239 traffic for the EF DSCP, it will discard half the offered traffic. 240 This traffic will be discarded from the aggregation of traffic 241 marked EF, with no regard to the microflow from which it originated. 242 As a result, it is likely that of the ten IP telephony sessions, 243 none will obtain satisfactory service when in fact, there are 244 sufficient resources available in the diffserv network region to 245 satisfy five sessions. 247 In the case of explicit admission control, the network will signal 248 rejection in response to requests for resources that would exceed 249 the 50 Kbps limit. As a result, upstream network elements (including 250 originating hosts) and applications will have the information they 251 require to take corrective action. The application might respond by 252 refraining from transmitting, or by requesting admission for a 253 lesser traffic profile. The host operating system might respond by 254 marking the application's traffic for the DSCP that corresponds to 255 best-effort service. Upstream network elements might respond by re- 256 marking packets on the rejected flow to a lower service level. In 257 any case, the integrity of those flows that were admitted would be 258 preserved, at the expense of the flows that were not admitted. Thus, 259 by appointing an RSVP conversant admission control agent for the 260 diffserv region of the network it is possible to enhance the service 261 that the network can provide to quantitative applications. 263 3.2 Policy Based Admission Control 265 In an RSVP/intserv network region, resource requests can be 266 intercepted by RSVP aware network elements and can be reviewed 267 against policies stored in policy databases. These resource requests 268 securely identify the user and the application for which the 269 resources are requested. Consequently, the network element is able 270 to consider per-user and/or per-application policy when deciding 271 whether or not to admit a resource request. So, in addition to 272 optimizing the use of resources in a diffserv network region (as 273 discussed in 3.1) RSVP conversant admission control agents can be 274 used to apply specific customer policies in determining the specific 275 customer traffic flows entitled to use the diffserv network region's 276 resources. Customer policies can be used to allocate resources to 277 specific users and/or applications. 279 By comparison, in diffserv network regions without per-flow RSVP 280 signaling, policies are typically applied based on the diffserv 281 customer network from which traffic originates, not on the 282 originating user or application within the customer network. 284 Bernet, ed. et. al 5 285 Use of RSVP with Diffserv March, 1999 287 3.3 Assistance in Traffic Identification/Classification 289 Within diffserv network regions, traffic is allotted service based 290 on the DSCP marked in each packet's IP header. Thus, in order to 291 obtain a particular level of service within the diffserv network 292 region, it is necessary to effect the marking of the correct DSCP in 293 packet headers. There are two mechanisms for doing so, host marking 294 and router marking. In the case of host marking, the host operating 295 system marks the DSCP in transmitted packets. In the case of router 296 marking, routers in the network are configured to identify specific 297 traffic (based on MF classification) and to mark the DSCP as packets 298 transit the router. There are advantages and disadvantages to each 299 scheme. Regardless of the scheme used, RSVP signaling offers 300 significant benefits. 302 3.3.1 Host Marking 304 In the case of host marking, the host operating system marks the 305 DSCP in transmitted packets. This approach has the benefit of 306 shifting per-flow classification and marking to the edge of the 307 network, where it scales best. It also enables the host to make 308 decisions regarding the mark (and hence the relative priority that 309 is requested) that is appropriate for each transmitted packet. The 310 host is generally better equipped to make this decision than the 311 network. 313 Host marking requires that the host be aware of the interpretation 314 of DSCPs by the network. This information can be configured into 315 each host. However, such configuration imposes a management burden. 316 Alternatively, RSVP/intserv hosts can use RSVP signaling to query 317 the network for a mapping from intserv service type to DSCP. This is 318 achieved via the RSVP DCLASS object [17] and is explained later in 319 this draft. 321 3.3.2 Router Marking 323 In the case of router marking, MF classification criteria must be 324 configured in the router. This may be done dynamically, by request 325 from the host operating system, or statically via manual 326 configuration or via automated scripts. 328 There are significant difficulties in doing so statically. 329 Typically, it is desirable to allot service to traffic based on the 330 application and/or user originating the traffic. At times it is 331 possible to identify packets associated with a specific application 332 by the IP port numbers in the headers. It may also be possible to 333 identify packets originating from a specific user by the source IP 334 address. However, such classification criteria may change 335 frequently. Users may be assigned different IP addresses by DHCP. 336 Applications may use transient ports. To further complicate matters, 337 multiple users may share an IP address. These factors make it very 338 difficult to manage static configuration of the classification 339 information required to mark traffic in routers. 341 Bernet, ed. et. al 6 342 Use of RSVP with Diffserv March, 1999 344 An attractive alternative to static configuration is to allow host 345 operating systems to signal classification criteria to the router on 346 behalf of users and applications. As we will show later in this 347 draft, RSVP signaling is ideally suited for this task. In addition 348 to enabling dynamic and accurate updating of MF classification 349 criteria, RSVP signaling enables classification of IPSec [16] 350 packets (by use of the SPI) which would otherwise be unrecognizable. 352 3.4 Traffic Conditioning 354 Those network elements that do provide RSVP/intserv support will 355 condition traffic at a per-flow granularity, by some combination of 356 shaping and/or policing. Pre-conditioning traffic in this manner 357 before it is submitted to the diffserv region of the network is 358 beneficial. In particular, it enhances the ability of the diffserv 359 region of the network to provide quantitative services using 360 aggregate traffic control. 362 4. The Framework 364 In the general framework we envision an Internet in which hosts use 365 RSVP/intserv to request reservations for specific services from the 366 network. The network includes some combination of RSVP/intserv 367 regions (in which MF classification and per-flow traffic control is 368 applied) and diffserv regions (in which aggregate traffic control is 369 applied). Individual routers may or may not participate in RSVP 370 signaling regardless of the type of network region in which they 371 reside. 373 We will consider two specific realizations of the framework. In the 374 first, resources within the diffserv regions of the network are 375 statically provisioned and these regions include no RSVP aware 376 devices. In the second, resources within the diffserv region of the 377 network are dynamically provisioned and select devices within the 378 diffserv network regions participate in RSVP signaling. 380 4.1 Reference Network 382 The two realizations of the framework will be discussed in the 383 context of the following reference network: 385 / \ / \ / \ 386 / \ / \ / \ 387 |---| | |---| |---| |---| |---| | |---| 388 |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx | 389 |---| | |-- | |---| |---| |---| | |---| 390 \ / \ / \ / 391 \______ / \___ _________ / \__ _____/ 393 RSVP/Intserv region Diffserv region RSVP/Intserv region 395 Figure 1: Sample Network Configuration 397 Bernet, ed. et. al 7 398 Use of RSVP with Diffserv March, 1999 400 The reference network includes a diffserv region interconnecting two 401 RSVP/intserv regions. The diffserv region contains a mesh of 402 routers, at least some of which provide aggregate traffic control. 403 The RSVP/intserv regions contain meshes of routers and attached 404 hosts, at least some of which are RSVP/intserv capable. 406 In the interest of simplicity we consider a single QoS sender, Tx in 407 one of the RSVP/intserv network regions and a single QoS receiver, 408 Rx in the other. The edge routers (ER1, ER2) within the RSVP/intserv 409 regions interface to the border routers (BR1, BR1) within the 410 diffserv regions. 412 From an economic viewpoint, we may consider that the diffserv region 413 sells service to the RSVP/intserv regions, which provide service to 414 hosts. Thus, we may think of the RSVP/intserv regions as customers 415 of the diffserv region. In the following, we use the term 416 'customer' for the RSVP/intserv regions. 418 4.1.1 Components of the Reference Network 420 We now define the major components of the reference network. 422 4.1.1.1 Hosts 424 Both sending and receiving hosts use RSVP/intserv to communicate the 425 quantitative QoS requirements of QoS-aware applications running on 426 the host. Typically, a QoS process within the host operating system 427 generates RSVP signaling on behalf of applications. This process may 428 also invoke local traffic control. 430 In this example, traffic control in the host marks the DSCP in 431 transmitted packets, and it shapes transmitted traffic to the 432 requirements of the intserv service in use. In alternate 433 realizations of the framework, the first-hop router within the 434 RSVP/intserv network regions may provide these traffic control 435 functions. 437 4.1.1.2 End-to-End RSVP Signaling 439 We assume that RSVP signaling messages travel end-to-end between 440 hosts Tx and Rx to support RSVP/intserv reservations in the 441 RSVP/intserv network regions. We require that these end-to-end RSVP 442 messages are carried across the diffserv region. Depending on the 443 specific realization of the framework, these messages may be 444 processed by none, some or all of the routers in the diffserv 445 region. 447 4.1.1.3 Edge Routers 449 ER1 and ER2 are edge routers, residing in the RSVP/intserv network 450 regions. The functionality of the edge routers varies depending on 451 the specific realization of the framework. In the case in which the 452 diffserv network region is RSVP unaware, edge routers act as 453 admission control agents to the diffserv network. They process 455 Bernet, ed. et. al 8 456 Use of RSVP with Diffserv March, 1999 458 signaling messages from both Tx and Rx, and apply admission control 459 based on resource availability within the diffserv network region 460 and on customer defined policy. In the case in which the diffserv 461 network region is RSVP aware, the edge routers apply admission 462 control based on local resource availability and on customer defined 463 policy. In this case, the border routers act as the admission 464 control agent to the diffserv network region. 466 We will later describe the functionality of the edge routers in 467 greater depth for each of the two realizations of the framework. 469 4.1.1.4 Border Routers 471 BR1 and BR2 are border routers, residing in the diffserv network 472 region. The functionality of the border routers varies depending on 473 the specific realization of the framework. In the case in which the 474 diffserv network region is RSVP/intserv unaware, these routers act 475 as pure diffserv routers. As such, their sole responsibility is to 476 police submitted traffic based on the service level specified in the 477 DSCP and the agreement negotiated with the customer (aggregate 478 traffic control). In the case in which the diffserv network region 479 is RSVP/intserv aware, the border routers participate in RSVP 480 signaling and act as admission control agents for the diffserv 481 network region. 483 We will later describe the functionality of the border routers in 484 greater depth for each of the two realizations of the framework. 486 4.1.1.5 RSVP/Intserv Network Regions 488 Each RSVP/intserv network region consists of RSVP/intserv capable 489 hosts and some number of routers. These routers may reasonably be 490 assumed to be RSVP/intserv capable, although this might not be 491 required in the case of a small, over-provisioned network region. If 492 they are not RSVP/intserv capable, we assume that they will pass 493 RSVP messages unhindered. Routers in the RSVP/intserv network region 494 are not precluded from providing aggregate traffic control to non- 495 quantitative traffic passing through them. 497 4.1.1.6 Diffserv Network Region 499 The diffserv network region supports aggregate traffic control and 500 is not capable of MF classification. Depending on the specific 501 realization of the framework, some number of routers within the 502 diffserv region may be RSVP aware and therefore capable of per-flow 503 signaling and admission control. If devices in the diffserv region 504 are not RSVP aware, they will pass RSVP messages transparently with 505 negligible performance impact (see [8]). 507 The diffserv network region provides two or more levels of service 508 based on the DSCP in packet headers. It may include sub-regions 509 managed as different administrative domains. 511 4.1.1.7 Service Mapping 513 Bernet, ed. et. al 9 514 Use of RSVP with Diffserv March, 1999 516 RSVP/intserv signaling requests specify an intserv service type and 517 a set of quantitative parameters known as a 'flowspec'. At each hop 518 in an intserv network, the RSVP/intserv service requests are 519 interpreted in a form meaningful to the specific link layer medium. 520 For example at an 802.1 hop, the intserv parameters are mapped to an 521 appropriate 802.1p priority level [5]. 523 In our framework, diffserv regions of the network are analogous to 524 the 802.1p capable switched segments described in [5]. Admission 525 control agents for diffserv network regions must map intserv service 526 types to a corresponding diffserv service level (DSCP or PHB) that 527 can reasonably extend the intserv service type requested by the 528 application. The admission control agent can then approve or reject 529 resource requests based on the capacity available in the diffserv 530 network region at the mapped service level. 532 One of two schemes may be used to map intserv service types to 533 diffserv service levels. 535 4.1.1.7.1 Default Mapping 537 In this scheme, there is some standard, well-known mapping from 538 intserv service type to a DSCP that will invoke the appropriate 539 behavior in the diffserv network. 541 4.1.1.7.2 Network Driven Mapping 543 In this scheme, RSVP aware routers in the diffserv network region 544 may override the well-known mapping described in 4.1.1.7.1. RSVP 545 RESV messages originating from receivers will carry the usual 546 intserv service type. RSVP aware routers within the diffserv network 547 region may append a DCLASS [17] object to RESV messages as they are 548 forwarded upstream. When a RESV message carrying a DCLASS object 549 arrives at a sending host (or in the case of router marking, at an 550 intermediate router), the sender starts marking transmitted packets 551 with the DSCP indicated. 553 A decision to override the well-known service mapping may be based 554 on configuration and/or a policy decision. 556 5. Detailed Examples of the Interoperation of RSVP/Intserv and Diffserv 558 In this section we provide detailed examples of our framework in 559 action. We discuss two examples, one in which the diffserv network 560 region is RSVP unaware, the other in which the diffserv network 561 region is RSVP aware. 563 5.1 RSVP Unaware Diffserv Network Region 565 In this example, no devices in the diffserv network region are RSVP 566 aware. The diffserv network region is statically provisioned. The 567 owner(s) of the RSVP/intserv network regions and the owner of the 568 diffserv network region have negotiated a static contract (service 570 Bernet, ed. et. al 10 571 Use of RSVP with Diffserv March, 1999 573 level agreement, or SLA) for the transmit capacity to be provided to 574 the customer at each of a number of standard diffserv service 575 levels. 577 It is helpful to consider the edge routers in the customer network, 578 to consist of two halves, a standard RSVP/intserv half, which 579 interfaces to the customer's RSVP/intserv network regions and a 580 diffserv half which interfaces to the diffserv network region. The 581 RSVP/intserv half has full RSVP capability. It is able to 582 participate in RSVP signaling and it is able to identify and process 583 traffic on per-flow granularity. 585 The diffserv half of the router can be considered to consist of a 586 number of virtual transmit interfaces, one for each diffserv service 587 level negotiated in the SLA. The router contains a table that 588 indicates the transmit capacity provisioned, per the SLA at each 589 diffserv service level. This table, in conjunction with the default 590 mapping described in 4.1.1.7.1, is used to apply admission control 591 decisions to the diffserv network region. 593 5.1.1 Sequence of Events in Obtaining End-to-end QoS 595 The following sequence illustrates the process by which an 596 application obtains end-to-end QoS. 598 1. The QoS process on the sending host Tx generates an RSVP PATH 599 message that describes the traffic offered by the sending 600 application. 602 2. The PATH message is carried toward the receiving host, Rx. In the 603 RSVP/intserv network region to which the sender is attached, 604 standard RSVP/intserv processing is applied at capable network 605 elements. 607 3. At the edge router ER1, the PATH message is subjected to standard 608 RSVP processing and PATH state is installed in the router. The PATH 609 message is sent onward to the diffserv network region. 611 4. The PATH message is carried transparently through the diffserv 612 network region and then processed at ER2 according to standard RSVP 613 processing rules. 615 5. When the PATH message reaches the receiving host Rx, the 616 operating system generates an RSVP RESV message, indicating interest 617 in offered traffic of a certain intserv service type. 619 6. The RESV message is carried back towards the diffserv network 620 region and the sending host. Consistent with standard RSVP/intserv 621 processing, it may be rejected at any RSVP node in the RSVP/intserv 622 network region if resources are deemed insufficient to carry the 623 traffic requested. 625 7. At ER2, the RESV message is subjected to standard RSVP/intserv 626 processing. It may be rejected if resources on the downstream 628 Bernet, ed. et. al 11 629 Use of RSVP with Diffserv March, 1999 631 interface of ER2 are deemed insufficient to carry the resources 632 requested. If it is not rejected, it will be carried transparently 633 through the diffserv network region, arriving at ER1. 635 8. In ER1, the RESV message triggers admission control processing. 636 ER1 compares the resources requested in the RSVP/intserv request to 637 the resources available in the diffserv network region at the 638 corresponding diffserv service level. The corresponding service 639 level is determined by the intserv to diffserv mapping discussed 640 previously. The availability of resources is determined by the 641 capacity provisioned in the SLA. ER1 may also apply a policy 642 decision such that the resource request may be rejected based on the 643 customer's specific policy criteria, even though the aggregate 644 resources are determined to be available per the SLA. 646 9. If ER1 approves the request, the RESV message is admitted and is 647 allowed to continue upstream towards the sender. If it rejects the 648 request, the RESV is not forwarded and the appropriate RSVP error 649 messages are sent. If the request is approved, ER1 updates its 650 internal tables to indicate the reduced capacity available at the 651 admitted service level on its transmit interface. 653 10. The RESV message proceeds through the RSVP/intserv network 654 region to which the sender is attached. Any RSVP node in this region 655 may reject the reservation request due to inadequate resources or 656 policy. If the request is not rejected, the RESV message will arrive 657 at the sending host, Tx. 659 11. At Tx, the QoS process receives the RESV message. It interprets 660 receipt of the message as indication that the specified traffic flow 661 has been admitted for the specified intserv service type (in the 662 RSVP/intserv network regions) and for the corresponding diffserv 663 service level (in the diffserv network regions). 665 12. Tx begins to mark the DSCP in the headers of packets that are 666 transmitted on the admitted traffic flow. The DSCP is the value 667 which maps to the intserv service type specified in the admitted 668 RESV message. 670 In this manner, we obtain end-to-end QoS through a combination of 671 networks that support RSVP/Intserv and networks that support 672 diffserv. 674 5.2 RSVP Aware Diffserv Network Region 676 In this example, the customer's edge routers are standard RSVP 677 routers. The border router, BR1 is RSVP aware. In addition, there 678 may be other routers within the diffserv network region which are 679 RSVP aware. Note that although these routers are able to participate 680 in RSVP signaling, they process traffic in aggregate, based on DSCP, 681 not on the per-flow classification criteria used by standard 682 RSVP/Intserv routers. It can be said that their control-plane is 683 RSVP while their data-plane is diffserv. This approach exploits the 685 Bernet, ed. et. al 12 686 Use of RSVP with Diffserv March, 1999 688 benefits of RSVP signaling while maintaining much of the scalability 689 associated with diffserv. 691 In the former example, there is no RSVP signaling between the 692 RSVP/intserv network regions and the diffserv network region. The 693 negotiation of an SLA is the only explicit exchange of resource 694 availability information between the two network regions. ER1 is 695 configured with the information represented by the SLA and as such, 696 is able to act as an admission control agent for the diffserv 697 network region. Such configuration does not readily support 698 dynamically changing SLAs, since ER1 requires reconfiguration each 699 time the SLA changes. It is also difficult to make efficient use of 700 the resources in the diffserv network region. This is because 701 admission control does not consider the availability of resources in 702 the diffserv network region along the specific path that would be 703 impacted. 705 By contrast, when the diffserv network region is RSVP aware, the 706 admission control agent is part of the diffserv network. As a 707 result, changes in the capacity available in the diffserv network 708 region can be indicated to the RSVP/intserv network regions via 709 traditional RSVP. By including routers interior to the diffserv 710 network region in RSVP signaling, it is possible to improve the 711 efficiency of resource usage. This is because admission control can 712 be linked to the availability of resources along the specific path 713 that would be impacted. We refer to this benefit of RSVP signaling 714 as 'topology aware admission control'. A further benefit of 715 supporting RSVP signaling within the diffserv network region is that 716 it is possible to effect changes in the provisioning of the diffserv 717 network region response to resource requests from the RSVP/intserv 718 network regions. 720 Various mechanisms may be used within the diffserv network region to 721 support dynamic provisioning and topology aware admission control. 722 These include aggregated RSVP, per-flow RSVP and bandwidth brokers, 723 as described in the following paragraphs. 725 5.2.1 Aggregated or Tunneled RSVP 727 A number of drafts [8,10,18, 19] propose mechanisms for extending 728 RSVP to reserve resources for an aggregation of flows between edges 729 of a network. Border routers may interact with core routers and 730 other border routers using aggregated RSVP to reserve resources 731 between edges of the diffserv network region. Initial reservation 732 levels for each service level may be established between major 733 border routers, based on anticipated traffic patterns. Border 734 routers could trigger changes in reservation levels as a result of 735 the cumulative per-flow RSVP requests from peripheral RSVP/intserv 736 network regions reaching high or low-water marks. 738 In this approach, admission of per-flow RSVP requests from 739 RSVP/intserv networks would be counted against the appropriate 740 aggregate reservations for the corresponding service level. 742 Bernet, ed. et. al 13 743 Use of RSVP with Diffserv March, 1999 745 The advantage of this approach is that it offers dynamic, topology 746 aware admission control to the diffserv network region without 747 requiring the level of RSVP signaling processing that would be 748 required to support per-flow RSVP. 750 5.2.3 Per-flow RSVP 752 In this approach, routers in the diffserv network region respond to 753 the standard per-flow RSVP signaling originating from the 754 RSVP/intserv network regions. This approach provides the benefits of 755 the previous approach (dynamic, topology aware admission control) 756 without requiring aggregated RSVP support. Resources are also used 757 more efficiently as a result of the per-flow admission control. 758 However, the demands on RSVP signaling resources within the diffserv 759 network region may be significantly higher. 761 5.2.4 Oracle 763 Border routers might not use any form of RSVP signaling within the 764 diffserv network region but might instead use custom protocols to 765 interact with an 'oracle'. The oracle is a hypothetical agent that 766 has sufficient topology awareness to make admission control 767 decisions. The set of RSVP aware routers in the previous two 768 examples can be considered collectively as a distributed oracle. In 769 various definitions of the 'bandwidth broker' [4], it is able to act 770 as a centralized oracle. 772 5.2.5 Granularity of Deployment of RSVP Aware Routers 774 In 5.2.2 and 5.2.3 some subset of the routers within the diffserv 775 network is RSVP signaling aware (though traffic control is 776 aggregated as opposed to per-flow). The relative number of routers 777 in the core that participate in RSVP signaling is a provisioning 778 decision that must be made by the network administrator. 780 In one extreme case, only the border routers participate in RSVP 781 signaling. In this case, either the diffserv network region must be 782 extremely over-provisioned and therefore, inefficiently used, or 783 else it must be carefully and statically provisioned for limited 784 traffic patterns. The border routers must enforce these patterns. 786 In the other extreme case, each router in the diffserv network 787 region might participate in RSVP signaling. In this case, resources 788 can be used with optimal efficiency, but signaling processing 789 requirements and associated overhead increase. 791 It is likely that network administrators will compromise by enabling 792 RSVP signaling on some subset of routers in the diffserv network 793 region. These routers will likely represent major traffic switching 794 points with over-provisioned or statically provisioned regions of 795 RSVP unaware routers between them. 797 6. Implications of the Framework for DiffServ Network Regions 799 Bernet, ed. et. al 14 800 Use of RSVP with Diffserv March, 1999 802 We have described a framework in which RSVP/intserv style QoS can be 803 provided across end-to-end paths that include diffserv network 804 regions. This section discusses some of the implications of this 805 framework for the diffserv network region. 807 6.1 Requirements from Diffserv Network Regions 809 A diffserv network region must meet the following requirements in 810 order for it to support the framework described in this draft. 812 1. A diffserv network region must be able to provide standard QoS 813 services between its border routers. It must be possible to invoke 814 these services by use of a standard DSCP. 816 2. There must be appropriate service mappings from intserv service 817 types to these diffserv services. 819 3. Diffserv network regions must provide admission control 820 information to intserv network regions. This information can be 821 provided by a dynamic protocol or, at the very least, through static 822 service level agreements. 824 4. Diffserv network regions must be able to pass RSVP messages, in 825 such a manner that they can be recovered at the egress of the 826 diffserv network region. The diffserv network region may, but is not 827 required to, process these messages. Mechanisms for transparently 828 carrying RSVP messages across a transit network are described in 829 [8,10,18, 19]. 831 To meet these requirements, additional work is required in the areas 832 of: 834 1. Mapping intserv style service specifications to services that can 835 be provided by diffserv network regions. 836 2. Definition of the functionality required in network elements to 837 support RSVP signaling with aggregate traffic control (for network 838 elements residing in the diffserv network region). 839 3. Definition of mechanisms to efficiently and dynamically provision 840 resources in a diffserv network region (e.g. aggregated RSVP, 841 tunneling, MPLS, etc.). 843 6.2 Protection of Intserv Traffic from Other Traffic 845 Network administrators must be able to share resources in the 846 diffserv network region between three types of traffic: 848 a. RSVP/intserv signaled - this is traffic associated with 849 quantitative applications. It requires a specific quantity of 850 resources with a high degree of assurance. 852 b. Qualitative - this is traffic associated with applications that 853 are not quantitative. Its resource requirements are not readily 854 quantifiable. It requires a 'better than best-effort' level of 855 service. 857 Bernet, ed. et. al 15 858 Use of RSVP with Diffserv March, 1999 860 c. All other (best-effort) traffic 862 These classes of traffic must be isolated from each other by the 863 appropriate configuration of policers and classifiers at ingress 864 points to the diffserv network region, and by appropriate 865 provisioning within the diffserv network region. To provide 866 protection for RSVP/intserv signaled traffic in diffserv regions of 867 the network, we suggest that the DSCPs assigned to such traffic not 868 overlap with the DSCPs assigned to other traffic. 870 7. Multicast 872 To be written. 874 8. Security Considerations 876 8.1 General RSVP Security 878 We are proposing that RSVP signaling be used to obtain resources in 879 both diffserv and RSVP/intserv regions of a network. Therefore, all 880 RSVP security considerations apply [11]. In addition, network 881 administrators are expected to protect network resources by 882 configuring secure policers at interfaces with untrusted customers. 884 8.2 Host Marking 886 Though it does not mandate host marking, our proposal does recommend 887 it. Allowing hosts to set the DSCP directly may alarm network 888 administrators. The obvious concern is that hosts may attempt to 889 'steal' resources. In fact, hosts may attempt to exceed negotiated 890 capacity in diffserv network regions at a particular service level 891 regardless of whether they invoke this service level directly (by 892 setting the DSCP) or indirectly (by submitting traffic that 893 classifies in an intermediate marking router to a particular diff- 894 serv DSCP). 896 In either case, it will be necessary for each diffserv network 897 region to protect its resources by policing to assure that customers 898 do not use more resources than they are entitled to, at each service 899 level (DSCP). If the sending host does not do the marking, the 900 boundary router (or trusted intermediate routers) must provide MF 901 classification, mark and police. If the sending host does do the 902 marking, the boundary router needs only to provide BA classification 903 and to police to ensure that the customer is not exceeding the 904 aggregate capacity negotiated for the service level. 906 In summary, the security concerns of marking the DSCP at the edge of 907 the network can be dismissed since each diffserv provider will have 908 to police at their boundary anyway. Furthermore, this approach 909 reduces the granularity at which border routers must police, thereby 910 pushing finer grain shaping and policing responsibility to the edges 911 of the network, where it scales better. The larger diffserv network 912 regions are thus focused on the task of protecting their networks, 914 Bernet, ed. et. al 16 915 Use of RSVP with Diffserv March, 1999 917 while the RSVP/intserv network regions are focused on the task of 918 shaping and policing their own traffic to be in compliance with 919 their negotiated intserv parameters. 921 7. Acknowledgments 923 Authors thank the following individuals for their comments that led 924 to improvements to the previous version(s) of this draft: David 925 Oran, Andy Veitch, Curtis Villamizer, Walter Weiss, and Russel 926 White. 928 Many of the ideas in this document have been previously discussed in 929 the original intserv architecture document [12]. 931 8. References 933 [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., 934 "Resource Reservation Protocol (RSVP) Version 1 Functional 935 Specification", RFC 2205, Proposed Standard, September 1997 937 [2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M., 938 "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based 939 Admission Control Over IEEE 802 Style Networks", Internet Draft, 940 March 1998 942 [3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated 943 Services State", Internet Draft, December 1997. 945 [4] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit 946 Differentiated Services Architecture for the Internet", Internet 947 Draft, December 1997. 949 [5] Seaman, M., Smith, A. and Crawley, E., "Integrated Services Over 950 IEEE 802.1D/802.1p Networks", Internet Draft, June 1997 952 [6] Elleson, E. and Blake, S., "A Proposal for the Format and 953 Semantics of the TOS Byte and Traffic Class Byte in Ipv4 and 954 Ipv6 Headers", Internet Draft, November 1997 956 [7] Ferguson, P., "Simple Differential Services: IP TOS and 957 Precedence, Delay Indication, and Drop Preference", Internet 958 Draft, November 1997 960 [8] Guerin, R., Blake, S. and Herzog, S.,"Aggregating RSVP based QoS 961 Requests", Internet Draft, November 1997. 963 [9] Nichols, Kathleen, et al., "Definition of the Differentiated 964 Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 965 2474, December 1998. 967 [10] Blake, S., et al., "An Architecture for Differentiated 968 Services." RFC 2475, December 1998. 970 [11] Baker, F., "RSVP Cryptographic Authentication", Internet Draft, 972 Bernet, ed. et. al 17 973 Use of RSVP with Diffserv March, 1999 975 August 1997 977 [12] Braden, R., Clark, D. and Shenker, S., "Integrated Services in 978 the Internet Architecture: an Overview", Internet RFC 1633, 979 June 1994 981 [13] Garrett, M. W., and Borden, M., "Interoperation of Controlled- 982 Load Service and Guaranteed Service with ATM", RFC2381, August 983 1998. 985 [14] Weiss, Walter, Private communication, November 1998. 987 [15] Berson, S. and Vincent, S., "Aggregation of Internet Integrated 988 Services State", Internet Draft, August 1998. 990 [16] Kent, S., Atkinson, R., "Security Architecture for the Internet 991 Protocol", RFC 2401, November 1998. 993 [17] Bernet, Y., "Usage and Format of the DCLASS Object with RSVP 994 Signaling", Internet Draft, February 1999. 996 [18] Baker, F., Iturralde, C., "RSVP Reservation Aggregation", 997 Internet Draft, February 1999. 999 [19] Terzis, A., Krawczyk, J., Wroclawski, J., Zhang, L., "RSVP 1000 Operation Over IP Tunnels", Internet Draft, February 1999. 1002 Author's Addresses: 1004 Yoram Bernet 1005 Microsoft 1006 One Microsoft Way, Redmond, WA 98052 1007 Phone: (425) 936-9568 1008 Email: yoramb@microsoft.com 1010 Raj Yavatkar 1011 Intel Corporation 1012 JF3-206 2111 NE 25th. Avenue, Hillsboro, OR 97124 1013 Phone: (503) 264-9077 1014 Email: raj.yavatkar@intel.com 1016 Peter Ford 1017 Microsoft 1018 One Microsoft Way, Redmond, WA 98052 1019 Phone: (425) 703-2032 1020 Email: peterf@microsoft.com 1022 Fred Baker 1023 Cisco Systems 1024 519 Lado Drive, Santa Barbara, CA 93111 1025 Phone: (408) 526-4257 1026 Email: fred@cisco.com 1028 Lixia Zhang 1030 Bernet, ed. et. al 18 1031 Use of RSVP with Diffserv March, 1999 1033 UCLA 1034 4531G Boelter Hall Los Angeles, CA 90095 1035 Phone: +1 310-825-2695 1036 Email: lixia@cs.ucla.edu 1038 Michael Speer 1039 Sun Microsystems 1040 901 San Antonio Road UMPK15-215 Palo Alto, CA 94303 1041 Phone: +1 650-786-6368 1042 Email: speer@Eng.Sun.COM 1044 Bob Braden 1045 USC Information Sciences Institute 1046 4676 Admiralty Way Marina del Rey, CA 90292-6695 1047 Phone: 310-822-1511 1048 Email: braden@isi.edu 1050 This draft expires September, 1999 1052 Bernet, ed. et. al 19