idnits 2.17.1 draft-ietf-issll-diffserv-rsvp-02.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 is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1331 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 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: '2' is defined on line 1109, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1134, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1148, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1152, 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' == Outdated reference: A later version (-02) exists of draft-nichols-diff-svc-arch-01 ** Downref: Normative reference to an Informational draft: draft-nichols-diff-svc-arch (ref. '4') -- 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) == Outdated reference: A later version (-01) exists of draft-bernet-dclass-00 -- Possible downref: Normative reference to a draft: ref. '14' == Outdated reference: A later version (-01) exists of draft-baker-rsvp-aggregation-00 -- Possible downref: Normative reference to a draft: ref. '15' == Outdated reference: A later version (-04) exists of draft-ietf-rsvp-tunnel-03 Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Y. Bernet, Microsoft 2 R. Yavatkar, Intel 3 P. Ford, Microsoft 4 F. Baker, Cisco 5 L. Zhang, UCLA 6 M. Speer, Sun Microsystems 7 R. Braden, ISI 8 B. Davie, Cisco 9 Internet Draft 10 Expires: December, 1999 11 Document: draft-ietf-issll-diffserv-rsvp-02.txt June, 1999 13 Integrated Services Operation Over 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 http://www.ietf.org/shadow.html. 34 1. Abstract 36 The Integrated Services architecture provides a means for the 37 delivery of end-to-end QoS to applications over heterogeneous 38 networks. To support this end-to-end model, the Intserv architecture 39 must be supported over a wide variety of different types of network 40 elements. In this context, a network that supports Differentiated 41 Services (Diffserv) may be viewed as a network element in the total 42 end-to-end path. This document describes a framework by which 43 Integrated Services may be supported over Diffserv networks. 45 2. Introduction 47 Work on QoS-enabled IP networks has led to two distinct approaches: 48 the Integrated Services architecture (intserv)[10] and its 49 accompanying signaling protocol, RSVP [1], and the Differentiated 50 Services architecture (diffserv)[8]. This document describes ways in 52 Bernet, ed. et. al 1 54 Integrated Services Operation Over Diffserv Networks June, 1999 56 which a Diffserv network can be used in the context of the Intserv 57 architecture to support the delivery of end-to-end QOS. 59 2.1 Integrated Services Architecture 61 The integrated services architecture defined a set of extensions to 62 the traditional best effort model of the Internet with the goal of 63 allowing end-to-end QOS to be provided to applications. One of the 64 key components of the architecture is a set of service definitions; 65 the current set of services consists of the controlled load and 66 guaranteed services. The architecture assumes that some explicit 67 setup mechanism is used to convey information to routers so that 68 they can provide requested services to flows that require them. 69 While RSVP is the most widely known example of such a setup 70 mechanism, the intserv architecture is designed to accommodate other 71 mechanisms. 73 Intserv services are implemented by _network elements_. While it is 74 common for network elements to be individual nodes such as routers 75 or links, more complex entities, such as ATM _clouds_ or 802.3 76 networks may also function as network elements. As discussed in more 77 detail below, a Diffserv network (or _cloud_) may be viewed as a 78 network element within a larger intserv network. 80 2.3 RSVP 82 RSVP is a signaling protocol that applications may use to request 83 resources from the network. The network responds by explicitly 84 admitting or rejecting RSVP requests. Certain applications that have 85 quantifiable resource requirements express these requirements using 86 intserv parameters as defined in the appropriate intserv service 87 specification. As noted above, RSVP and intserv are separable. RSVP 88 is a signaling protocol which may carry intserv information. Intserv 89 defines the models for expressing service types, quantifying 90 resource requirements and for determining the availability of the 91 requested resources at relevant network elements (admission 92 control). 94 The current prevailing model of RSVP usage is based on a combined 95 RSVP/intserv architecture. In this model, RSVP signals per-flow 96 resource requirements to network elements, using Intserv parameters. 97 These network elements apply Intserv admission control to signaled 98 requests. In addition, traffic control mechanisms on the network 99 element are configured to ensure that each admitted flow receives 100 the service requested in strict isolation from other traffic. To 101 this end, RSVP signaling configures microflow (MF) [8] packet 102 classifiers in intserv capable routers along the path of the traffic 103 flow. These classifiers enable per-flow classification of packets 104 based on IP addresses and port numbers. 106 The following factors have impeded deployment of RSVP (and the 107 intserv architecture) in the Internet at large: 109 Bernet, ed. et al. 2 111 Integrated Services Operation Over Diffserv Networks June, 1999 113 1. The use of per-flow state and per-flow processing raises 114 scalability concerns for large networks. 116 2. Only a small number of hosts currently generate RSVP signaling. 117 While this number is expected to grow dramatically, many 118 applications may never generate RSVP signaling. 120 3. The necessary policy control mechanisms -- access control, 121 authentication, and accounting _- have only recently become 122 available [17]. 124 2.4 Diffserv 126 The market is pushing for immediate deployment of a QoS solution 127 that addresses the needs of the Internet as well as enterprise 128 networks. This push led to the development of diffserv. In contrast 129 to the per-flow orientation of RSVP, diffserv networks classify 130 packets into one of a small number of aggregated flows or 'classes', 131 based on the diffserv codepoint (DSCP) in the packet's IP header. 132 This is known as behavior aggregate (BA) classification [8]. At each 133 diffserv router, packets are subjected to a 'per-hop behaviour' 134 (PHB), which is invoked by the DSCP. The primary benefit of diffserv 135 is its scalability. Diffserv eliminates the need for per-flow state 136 and per-flow processing and therefore scales well to large networks. 138 2.5 Roles of Intserv, RSVP and Diffserv 140 We view intserv, RSVP and diffserv as complementary technologies in 141 the pursuit of end-to-end QoS. Together, these mechanisms can 142 facilitate deployment of applications such as IP-telephony, video- 143 on-demand, and various non-multimedia mission-critical applications. 144 Intserv enables hosts to request per-flow, quantifiable resources, 145 along end-to-end data paths and to obtain feedback regarding 146 admissibility of these requests. Diffserv enables scalability across 147 large networks. 149 2.6 Components of Intserv, RSVP and Diffserv 151 Before proceeding, it is helpful to identify the following 152 components of the QoS technologies described: 154 RSVP signaling - This term refers to the standard RSVP signaling 155 protocol. RSVP signaling is used by hosts to signal application 156 resource requirements to the network (and to each other). Network 157 elements use RSVP signaling to return an admission control decision 158 to hosts. RSVP signaling may or may not carry intserv parameters. 159 Admission control at a network element may or may not be based on 160 the intserv model. 162 Bernet, ed. et al. 3 164 Integrated Services Operation Over Diffserv Networks June, 1999 166 MF traffic control - This term refers to traffic control which is 167 applied independently to individual traffic flows and therefore 168 requires recognizing individual traffic flows via MF classification. 170 Aggregate traffic control - This term refers to traffic control 171 which is applied collectively to sets of traffic flows. These sets 172 of traffic flows are recognized based on BA (DSCP) classification. 173 In this draft, we use the terms 'aggregate traffic control' and 174 'diffserv' interchangeably. 176 Aggregate RSVP. While the existing definition of RSVP supports only 177 per-flow reservations, extensions to RSVP are being developed to 178 enable RSVP reservations to be made for aggregated traffic, i.e. 179 sets of flows that may be recognized by BA classification. This use 180 of RSVP may be useful in controlling the allocation of bandwidth in 181 Diffserv networks. 183 Per-flow RSVP. The conventional usage of RSVP to perform resource 184 reservations for individual microflows. 186 RSVP/Intserv - This term is used to refer to the prevailing model of 187 RSVP usage which includes RSVP signaling with intserv parameters, 188 intserv admission control and per-flow traffic control at network 189 elements. 191 Diffserv Region. A set of contiguous routers which support BA 192 classification and traffic control. While such a region may also 193 support MF classification, the goal of this document is to describe 194 how such a region may be used in delivery of end-to-end QOS when 195 only BA classification is performed inside the diffserv region. 197 Intserv Region. The portions of the network outside the diffserv 198 region. We assume MF classification and traffic control is available 199 in such regions. Such a region may also offer BA classification and 200 traffic control. 202 Note that, for the purposes of this document, the key distinction 203 between an Intserv and a Diffserv region is the type of 204 classification and traffic control that is used for the delivery of 205 end-to-end QOS for a particular application. Thus, while it may not 206 be possible to identify a certain region as _purely Diffserv_ or 207 _purely Intserv_ with respect to all traffic flowing through the 208 region, it is possible to make these distinctions from the 209 perspective of the treatment of traffic from a single application. 211 2.7 The Framework 213 In the framework we present, end-to-end, quantitative QoS is 214 provided by coupling Intserv regions at the periphery of the network 215 with diffserv regions in the core of the network. The diffserv 216 regions may, but are not required to, participate in end-to-end RSVP 218 Bernet, ed. et al. 4 220 Integrated Services Operation Over Diffserv Networks June, 1999 222 signaling for the purpose of optimizing resource allocation and 223 supporting admission control. 225 From the perspective of Intserv, diffserv regions of the network are 226 treated as virtual links connecting Intserv capable routers or hosts 227 (much as an 802.1p network region is treated as a virtual link in 228 [5]). Within the diffserv regions of the network routers implement 229 specific PHBs (aggregate traffic control). The total amount of 230 traffic that is admitted into the diffserv region that will receive 231 a certain PHB may be limited by policing at the edge. As a result 232 we expect that the diffserv regions of the network will be able to 233 support the intserv style services requested from the periphery. As 234 such, we often refer to the Intserv network regions as 'customers' 235 of the diffserv network regions. 237 In our framework, we address the inter-operability between the 238 Intserv regions of the network and the diffserv regions of the 239 network. Our goal is to enable seamless inter-operation. As a 240 result, the network administrator is free to choose which regions of 241 the network act as Intserv regions and which act as diffserv 242 regions. In one extreme the diffserv region is pushed all the way to 243 the periphery, with hosts alone comprising the Intserv regions of 244 the network. In the other extreme, Intserv is pushed all the way to 245 the core, with no diffserv region. 247 2.8 Contents 249 In section 3 we discuss the benefits that can be realized by using 250 the aggregate traffic control provided by diffserv network regions 251 in the broader context of the Intserv architecture. In section 4, we 252 present the framework and the reference network. Section 5 details 253 two possible realizations of the framework. Section 6 discusses the 254 implications of the framework for diffserv. Appendix A contains a 255 list of some important terms used in this document. 257 Though the primary goal of this draft is to describe a framework 258 for inter-operation of Intserv network regions and diffserv network 259 regions, the draft currently does not address the issues specific to 260 IP multicast flows. 262 3. Benefits of Using Intserv with Diffserv 264 The primary benefit of diffserv aggregate traffic control is its 265 scalability. In this section, we discuss the benefits that 266 interoperation with Intserv can bring to a diffserv network region. 267 Note that this discussion is in the context of servicing 268 quantitative QoS applications specifically. By this we mean those 269 applications that are able to quantify their traffic and QoS 270 requirements. 272 3.1 Resource Based Admission Control 274 Bernet, ed. et al. 5 276 Integrated Services Operation Over Diffserv Networks June, 1999 278 In Intserv networks, quantitative QoS applications use an explicit 279 setup mechanism (e.g. RSVP) to request resources from the network. 280 The network may accept or reject these requests in response. This is 281 'explicit admission control'. Explicit admission control helps to 282 assure that network resources are optimally used. To further 283 understand this issue, consider a diffserv network region providing 284 only aggregate traffic control with no signaling. In the diffserv 285 network region, admission control is applied implicitly by 286 provisioning policing parameters at network elements. For example, a 287 network element at the ingress to a diffserv network region could be 288 provisioned to accept only 50 Kbps of traffic for the EF DSCP. 290 While such implicit admission control does protect the network to 291 some degree, it can be quite ineffective. For example, consider that 292 there may be 10 IP telephony sessions originating outside the 293 diffserv network region, each requiring 10 Kbps of EF service from 294 the diffserv network region. Since the network element protecting 295 the diffserv network region is provisioned to accept only 50 Kbps of 296 traffic for the EF DSCP, it will discard half the offered traffic. 297 This traffic will be discarded from the aggregation of traffic 298 marked EF, with no regard to the microflow from which it originated. 299 As a result, it is likely that of the ten IP telephony sessions, 300 none will obtain satisfactory service when in fact, there are 301 sufficient resources available in the diffserv network region to 302 satisfy five sessions. 304 In the case of explicit admission control, the network will signal 305 rejection in response to requests for resources that would exceed 306 the 50 Kbps limit. As a result, upstream network elements (including 307 originating hosts) and applications will have the information they 308 require to take corrective action. The application might respond by 309 refraining from transmitting, or by requesting admission for a 310 lesser traffic profile. The host operating system might respond by 311 marking the application's traffic for the DSCP that corresponds to 312 best-effort service. Upstream network elements might respond by re- 313 marking packets on the rejected flow to a lower service level. In 314 some cases, it may be possible to reroute traffic over alternate 315 paths or even alternate networks (e.g. the PSTN for voice calls). In 316 any case, the integrity of those flows that were admitted would be 317 preserved, at the expense of the flows that were not admitted. Thus, 318 by appointing an Intserv-conversant admission control agent for the 319 diffserv region of the network it is possible to enhance the service 320 that the network can provide to quantitative QoS applications. 322 3.2 Policy Based Admission Control 324 In network regions where RSVP is used, resource requests can be 325 intercepted by RSVP-aware network elements and can be reviewed 326 against policies stored in policy databases. These resource requests 327 securely identify the user and the application for which the 328 resources are requested. Consequently, the network element is able 329 to consider per-user and/or per-application policy when deciding 331 Bernet, ed. et al. 6 333 Integrated Services Operation Over Diffserv Networks June, 1999 335 whether or not to admit a resource request. So, in addition to 336 optimizing the use of resources in a diffserv network region (as 337 discussed in 3.1) RSVP conversant admission control agents can be 338 used to apply specific customer policies in determining the specific 339 customer traffic flows entitled to use the diffserv network region's 340 resources. Customer policies can be used to allocate resources to 341 specific users and/or applications. 343 By comparison, in diffserv network regions without RSVP signaling, 344 policies are typically applied based on the diffserv customer 345 network from which traffic originates, not on the originating user 346 or application within the customer network. 348 3.3 Assistance in Traffic Identification/Classification 350 Within diffserv network regions, traffic is allotted service based 351 on the DSCP marked in each packet's IP header. Thus, in order to 352 obtain a particular level of service within the diffserv network 353 region, it is necessary to effect the marking of the correct DSCP in 354 packet headers. There are two mechanisms for doing so, host marking 355 and router marking. In the case of host marking, the host operating 356 system marks the DSCP in transmitted packets. In the case of router 357 marking, routers in the network are configured to identify specific 358 traffic (typically based on MF classification) and to mark the DSCP 359 as packets transit the router. There are advantages and 360 disadvantages to each scheme. Regardless of the scheme used, 361 explicit signaling offers significant benefits. 363 3.3.1 Host Marking 365 In the case of host marking, the host operating system marks the 366 DSCP in transmitted packets. This approach has the benefit of 367 shifting per-flow classification and marking to the edge of the 368 network, where it scales best. It also enables the host to make 369 decisions regarding the mark that is appropriate for each 370 transmitted packet and hence the relative importance attached to 371 each packet. The host is generally better equipped to make this 372 decision than the network. Furthermore, if IPSEC encryption is used, 373 the host may be the only device in the network that is able to make 374 a meaningful determination of the appropriate marking for each 375 packet. 377 Host marking requires that the host be aware of the interpretation 378 of DSCPs by the network. This information can be configured into 379 each host. However, such configuration imposes a management burden. 380 Alternatively, hosts can use an explicit signaling protocol such as 381 RSVP to query the network to obtain a suitable DSCP or set of DSCPs 382 to apply to packets for which a certain intserv service has been 383 requested. An example of how this can be achieved is described in 384 [14]. 386 3.3.2 Router Marking 388 Bernet, ed. et al. 7 390 Integrated Services Operation Over Diffserv Networks June, 1999 392 In the case of router marking, MF classification criteria must be 393 configured in the router. This may be done dynamically, by request 394 from the host operating system, or statically via manual 395 configuration or via automated scripts. 397 There are significant difficulties in doing so statically. 398 Typically, it is desirable to allot service to traffic based on the 399 application and/or user originating the traffic. At times it is 400 possible to identify packets associated with a specific application 401 by the IP port numbers in the headers. It may also be possible to 402 identify packets originating from a specific user by the source IP 403 address. However, such classification criteria may change 404 frequently. Users may be assigned different IP addresses by DHCP. 405 Applications may use transient ports. To further complicate matters, 406 multiple users may share an IP address. These factors make it very 407 difficult to manage static configuration of the classification 408 information required to mark traffic in routers. 410 An attractive alternative to static configuration is to allow host 411 operating systems to signal classification criteria to the router on 412 behalf of users and applications. As we will show later in this 413 draft, RSVP signaling is ideally suited for this task. In addition 414 to enabling dynamic and accurate updating of MF classification 415 criteria, RSVP signaling enables classification of IPSEC [13] 416 packets (by use of the SPI) which would otherwise be unrecognizable. 418 3.4 Traffic Conditioning 420 Intserv-capable network elements are able to condition traffic at a 421 per-flow granularity, by some combination of shaping and/or 422 policing. Pre-conditioning traffic in this manner before it is 423 submitted to the diffserv region of the network is beneficial. In 424 particular, it enhances the ability of the diffserv region of the 425 network to provide quantitative services using aggregate traffic 426 control. 428 4. The Framework 430 In the general framework we envision an Internet in which the 431 Integrated Services architecture is used to deliver end-to-end QOS 432 to applications. The network includes some combination of Intserv 433 regions (in which MF classification and per-flow traffic control is 434 applied) and diffserv regions (in which aggregate traffic control is 435 applied). Individual routers may or may not participate in RSVP 436 signaling regardless of the type of network region in which they 437 reside. 439 We will consider two specific realizations of the framework. In the 440 first, resources within the diffserv regions of the network are 441 statically provisioned and these regions include no RSVP aware 442 devices. In the second, resources within the diffserv region of the 444 Bernet, ed. et al. 8 446 Integrated Services Operation Over Diffserv Networks June, 1999 448 network are dynamically provisioned and select devices within the 449 diffserv network regions participate in RSVP signaling. 451 4.1 Reference Network 453 The two realizations of the framework will be discussed in the 454 context of the following reference network: 456 / \ / \ / \ 457 / \ / \ / \ 458 |---| | |---| |---| |---| |---| | |---| 459 |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx | 460 |---| | |-- | |---| |---| |---| | |---| 461 \ / \ / \ / 462 \______ / \___ _________ / \__ _____/ 464 Intserv region Diffserv region Intserv region 466 Figure 1: Sample Network Configuration 468 The reference network includes a diffserv region interconnecting two 469 Intserv regions. The diffserv region contains a mesh of routers, at 470 least some of which provide aggregate traffic control. The Intserv 471 regions contain meshes of routers and attached hosts, at least some 472 of which support the Integrated Services architecture. 474 In the interest of simplicity we consider a single QoS sender, Tx in 475 one of the Intserv network regions and a single QoS receiver, Rx in 476 the other. The edge routers (ER1, ER2) within the Intserv regions 477 interface to the border routers (BR1, BR1) within the diffserv 478 regions. 480 From an economic viewpoint, we may consider that the diffserv region 481 sells service to the Intserv regions, which provide service to 482 hosts. Thus, we may think of the Intserv regions as customers of 483 the diffserv region. In the following, we use the term 'customer' 484 for the Intserv regions. Note that the boundaries of the regions may 485 or may not align with administrative domain boundaries, and that a 486 single region might contain multiple administrative domains. 488 We now define the major components of the reference network. 490 4.1.1 Hosts 492 We assume that both sending and receiving hosts use RSVP to 493 communicate the quantitative QoS requirements of QoS-aware 494 applications running on the host. In principle, other mechanisms may 495 be used to establish resource reservations in an Intserv region, but 496 RSVP is clearly the prevalent mechanism for this purpose. 498 Bernet, ed. et al. 9 500 Integrated Services Operation Over Diffserv Networks June, 1999 502 Typically, a QoS process within the host operating system generates 503 RSVP signaling on behalf of applications. This process may also 504 invoke local traffic control. 506 As discussed above, traffic control in the host may mark the DSCP in 507 transmitted packets, and shape transmitted traffic to the 508 requirements of the intserv service in use. Alternatively, the 509 first-hop router within the Intserv network regions may provide 510 these traffic control functions. 512 4.1.2 End-to-End RSVP Signaling 514 We assume that RSVP signaling messages travel end-to-end between 515 hosts Tx and Rx to support RSVP/intserv reservations in the Intserv 516 network regions. We require that these end-to-end RSVP messages are 517 carried across the diffserv region. Depending on the specific 518 realization of the framework, these messages may be processed by 519 none, some or all of the routers in the diffserv region. 521 4.1.3 Edge Routers 523 ER1 and ER2 are edge routers, residing in the Intserv network 524 regions. The functionality of the edge routers varies depending on 525 the specific realization of the framework. In the case in which the 526 diffserv network region is RSVP unaware, edge routers act as 527 admission control agents to the diffserv network. They process 528 signaling messages from both Tx and Rx, and apply admission control 529 based on resource availability within the diffserv network region 530 and on customer defined policy. In the case in which the diffserv 531 network region is RSVP aware, the edge routers apply admission 532 control based on local resource availability and on customer defined 533 policy. In this case, the border routers act as the admission 534 control agent to the diffserv network region. 536 We will later describe the functionality of the edge routers in 537 greater depth for each of the two realizations of the framework. 539 4.1.4 Border Routers 541 BR1 and BR2 are border routers, residing in the diffserv network 542 region. The functionality of the border routers varies depending on 543 the specific realization of the framework. In the case in which the 544 diffserv network region is RSVP-unaware, these routers act as pure 545 diffserv routers. As such, their sole responsibility is to police 546 submitted traffic based on the service level specified in the DSCP 547 and the agreement negotiated with the customer (aggregate traffic 548 control). In the case in which the diffserv network region is RSVP- 549 aware, the border routers participate in RSVP signaling and act as 550 admission control agents for the diffserv network region. 552 We will later describe the functionality of the border routers in 553 greater depth for each of the two realizations of the framework. 555 Bernet, ed. et al. 10 557 Integrated Services Operation Over Diffserv Networks June, 1999 559 4.1.5 Intserv Network Regions 561 Each Intserv network region consists of Intserv capable hosts and 562 some number of routers. These routers may reasonably be assumed to 563 be Intserv capable, although this might not be required in the case 564 of a small, over-provisioned network region. Even if they are not 565 Intserv capable, we assume that they will pass RSVP messages 566 unhindered. Routers in the Intserv network region are not precluded 567 from providing aggregate traffic control to some subset of the 568 traffic passing through them. 570 4.1.6 Diffserv Network Region 572 The diffserv network region supports aggregate traffic control and 573 is assumed not to be capable of MF classification. Depending on the 574 specific realization of the framework, some number of routers within 575 the diffserv region may be RSVP aware and therefore capable of per- 576 flow signaling and admission control. If devices in the diffserv 577 region are not RSVP aware, they will pass RSVP messages 578 transparently with negligible performance impact (see [6]). 580 The diffserv network region provides two or more levels of service 581 based on the DSCP in packet headers. It may include sub-regions 582 managed as different administrative domains. 584 4.2 Service Mapping 586 Intserv service requests specify an intserv service type and a set 587 of quantitative parameters known as a 'flowspec'. At each hop in an 588 intserv network, the Intserv service requests are interpreted in a 589 form meaningful to the specific link layer medium. For example at 590 an 802.1 hop, the intserv parameters are mapped to an appropriate 591 802.1p priority level [5]. 593 In our framework, diffserv regions of the network are analogous to 594 the 802.1p capable switched segments described in [5]. Requests for 595 Intserv services must be mapped onto the underlying capabilities of 596 the Diffserv network region. Aspects of the mapping include: 598 - selecting an appropriate PHB, or set of PHBs, for the requested 599 service; 600 - performing appropriate policing (including, perhaps, shaping or 601 remarking) at the edges of the Diffserv region; 602 - exporting Intserv parameters from the Diffserv region (e.g. for 603 the updating of ADSPECs); 604 - performing admission control on the Intserv requests that takes 605 into account the resource availability in the Diffserv region. 607 Exactly how these functions are performed will be a function of the 608 way bandwidth is managed inside the Diffserv network region, which 609 is a topic we discuss in Section 4.3. 611 Bernet, ed. et al. 11 613 Integrated Services Operation Over Diffserv Networks June, 1999 615 When the PHB (or set of PHBs) has been selected for a particular 616 Intserv flow, it may be necessary to communicate the choice of DSCP 617 for the flow to other network elements. Two schemes may be used to 618 achieve this end, as discussed below. 620 4.2.1 Default Mapping 622 In this scheme, there is some standard, well-known mapping from 623 intserv service type to a DSCP that will invoke the appropriate 624 behavior in the diffserv network. 626 4.2.2 Network Driven Mapping 628 In this scheme, RSVP conversant routers in the diffserv network 629 region (perhaps at its edge) may override the well-known mapping 630 described in 4.2.1. In the case that DSCPs are marked at the ingress 631 to the Diffserv region, the DSCPs can simple be remarked at the 632 boundary routers. However, in the case that DSCP marking occurs 633 upstream of the Diffserv region, either in a host or a router, then 634 the appropriate mapping needs to be communicated Upstream, to the 635 marking device. This may be accomplished using RSVP, as described 636 in [14]. 638 The decision regarding where to mark DSCP and whether to override 639 the well-known service mapping is a mater of policy to be decided by 640 the administrator of the diffserv network region in cooperation with 641 the administrator of the intserv network region. 643 4.2.3 Microflow Separation 645 Boundary routers residing at the edge of the Diffserv region will 646 typically police traffic submitted from the Intserv region in order 647 to protect resources within the Diffserv region. This policing will 648 be applied on an aggregate basis, with no regard for the individual 649 microflows making up each aggregate. As a result, it is possible for 650 a misbehaving microflow to claim more than its fair share of 651 resources within the aggregate, thereby degrading the service 652 provided to other microflows. This problem may be addressed by: 654 1. Providing per microflow policing at the edge routers - this is 655 generally the most appropriate location for microflow policing, 656 since it pushes per-flow work to the edges of the network, where it 657 scales better. In addition, since the intserv region is responsible 658 for providing microflow service to its customers and the diffserv 659 region is responsible for providing aggregate service to its 660 customers, this distribution of functionality mirrors the 661 distribution of responsibility. 663 2. Providing per microflow policing at the border routers - this 664 approach tends to be less scalable than the previous approach. It 665 also imposes a management burden on the diffserv region of the 667 Bernet, ed. et al. 12 669 Integrated Services Operation Over Diffserv Networks June, 1999 671 network. However, it may be appropriate in certain cases, for the 672 diffserv boundary routers to offer per microflow policing as a 673 value-add to its intserv customers. 675 3. Relying on upstream shaping and policing - in certain cases, the 676 customer may trust the shaping of certain groups of hosts 677 sufficiently to not warrant reshaping or policing at the boundary 678 between the intserv and diffserv regions. Note that, even if the 679 hosts are shaping microflows properly, these shaped flows may become 680 distorted as they transit through the intserv region of the network. 681 Depending on the degree of distortion, it may be necessary to 682 somewhat over-provision the aggregate capacities in the diffserv 683 region, or to re-police using either 1 or 2 above. 684 The choice of one mechanism or another is a matter of policy to be 685 decided by the administrator of the intserv network region. 687 4.3 Resource Management in Diffserv Regions 689 A variety of options exist for management of resources (e.g., 690 bandwidth) in the Diffserv network regions to meet the needs of end- 691 to-end Intserv flows. These options include: 693 - statically provisioned resources; 694 - resources dynamically provisioned by RSVP; 695 - resources dynamically provisioned by other means (e.g., a form of 696 Bandwidth Broker). 698 Some of the details of using each of these different approaches are 699 discussed in the following section. 701 5. Detailed Examples of the Operation of Intserv over Diffserv Regions 703 In this section we provide detailed examples of our framework in 704 action. We discuss two examples, one in which the diffserv network 705 region is RSVP unaware, the other in which the diffserv network 706 region is RSVP aware. 708 5.1 Statically Provisioned Diffserv Network Region 710 In this example, no devices in the diffserv network region are RSVP 711 aware. The diffserv network region is statically provisioned. The 712 owner(s) of the Intserv network regions and the owner of the 713 diffserv network region have negotiated a static contract (service 714 level specification, or SLS) for the transmit capacity to be 715 provided to the customer at each of a number of standard diffserv 716 service levels. The _transmit capacity_ may be simply an amount of 717 bandwidth or it could be a more complex _profile_ involving a number 718 of factors such as burst size, peak rate, time of day etc. 720 It is helpful to consider each edge router in the customer network 721 as consisting of two halves, a standard Intserv half, which 723 Bernet, ed. et al. 13 725 Integrated Services Operation Over Diffserv Networks June, 1999 727 interfaces to the customer's Intserv network regions and a diffserv 728 half which interfaces to the diffserv network region. The Intserv 729 half is able to identify and process traffic on per-flow 730 granularity. 732 The diffserv half of the router can be considered to consist of a 733 number of virtual transmit interfaces, one for each diffserv service 734 level negotiated in the SLS. The router contains a table that 735 indicates the transmit capacity provisioned, per the SLS at each 736 diffserv service level. This table, in conjunction with the default 737 mapping described in 4.2.1, is used to perform admission control 738 decisions on intserv flows which cross the diffserv network region. 740 5.1.1 Sequence of Events in Obtaining End-to-end QoS 742 The following sequence illustrates the process by which an 743 application obtains end-to-end QoS when RSVP is used within the 744 Intserv region. 746 1. The QoS process on the sending host Tx generates an RSVP PATH 747 message that describes the traffic offered by the sending 748 application. 750 2. The PATH message is carried toward the receiving host, Rx. In the 751 Intserv network region to which the sender is attached, standard 752 RSVP/intserv processing is applied at capable network elements. 754 3. At the edge router ER1, the PATH message is subjected to standard 755 RSVP processing and PATH state is installed in the router. The PATH 756 message is sent onward to the diffserv network region. 758 4. The PATH message is ignored by routers in the diffserv network 759 region and then processed at ER2 according to standard RSVP 760 processing rules. 762 5. When the PATH message reaches the receiving host Rx, the 763 operating system generates an RSVP RESV message, indicating interest 764 in offered traffic of a certain intserv service type. 766 6. The RESV message is carried back towards the diffserv network 767 region and the sending host. Consistent with standard RSVP/intserv 768 processing, it may be rejected at any RSVP node in the Intserv 769 network region if resources are deemed insufficient to carry the 770 traffic requested. 772 7. At ER2, the RESV message is subjected to standard RSVP/intserv 773 processing. It may be rejected if resources on the downstream 774 interface of ER2 are deemed insufficient to carry the resources 775 requested. If it is not rejected, it will be carried transparently 776 through the diffserv network region, arriving at ER1. 778 Bernet, ed. et al. 14 780 Integrated Services Operation Over Diffserv Networks June, 1999 782 8. In ER1, the RESV message triggers admission control processing. 783 ER1 compares the resources requested in the RSVP/intserv request to 784 the resources available in the diffserv network region at the 785 corresponding diffserv service level. The corresponding service 786 level is determined by the intserv to diffserv mapping discussed 787 previously. The availability of resources is determined by the 788 capacity provisioned in the SLS. ER1 may also apply a policy 789 decision such that the resource request may be rejected based on the 790 customer's specific policy criteria, even though the aggregate 791 resources are determined to be available per the SLS. 793 9. If ER1 approves the request, the RESV message is admitted and is 794 allowed to continue upstream towards the sender. If it rejects the 795 request, the RESV is not forwarded and the appropriate RSVP error 796 messages are sent. If the request is approved, ER1 updates its 797 internal tables to indicate the reduced capacity available at the 798 admitted service level on its transmit interface. 800 10. The RESV message proceeds through the Intserv network region to 801 which the sender is attached. Any RSVP node in this region may 802 reject the reservation request due to inadequate resources or 803 policy. If the request is not rejected, the RESV message will arrive 804 at the sending host, Tx. 806 11. At Tx, the QoS process receives the RESV message. It interprets 807 receipt of the message as indication that the specified traffic flow 808 has been admitted for the specified intserv service type (in the 809 Intserv network regions) and for the corresponding diffserv service 810 level (in the diffserv network regions). It may also learn the 811 appropriate DSCP marking to apply to packets for this flow from 812 information provided in the RESV. 814 12. Tx may mark the DSCP in the headers of packets that are 815 transmitted on the admitted traffic flow. The DSCP may be the 816 default value which maps to the intserv service type specified in 817 the admitted RESV message, or it may be a value explicitly provided 818 in the RESV.. 820 In this manner, we obtain end-to-end QoS through a combination of 821 networks that support RSVP/Intserv and networks that support 822 diffserv. 824 5.2 RSVP-Aware Diffserv Network Region 826 In this example, the customer's edge routers are standard RSVP 827 routers. The border router, BR1 is RSVP aware. In addition, there 828 may be other routers within the diffserv network region which are 829 RSVP aware. Note that although these routers are able to participate 830 in some form of RSVP signaling, they classify and schedule traffic 831 in aggregate, based on DSCP, not on the per-flow classification 832 criteria used by standard RSVP/Intserv routers. It can be said that 833 their control-plane is RSVP while their data-plane is diffserv. This 835 Bernet, ed. et al. 15 837 Integrated Services Operation Over Diffserv Networks June, 1999 839 approach exploits the benefits of RSVP signaling while maintaining 840 much of the scalability associated with diffserv. 842 In the preceding example, there is no signaling between the Intserv 843 network regions and the diffserv network region. The negotiation of 844 an SLS is the only explicit exchange of resource availability 845 information between the two network regions. ER1 is configured with 846 the information represented by the SLS and as such, is able to act 847 as an admission control agent for the diffserv network region. Such 848 configuration does not readily support dynamically changing SLSs, 849 since ER1 requires reconfiguration each time the SLS changes. It is 850 also difficult to make efficient use of the resources in the 851 diffserv network region. This is because admission control does not 852 consider the availability of resources in the diffserv network 853 region along the specific path that would be impacted. 855 By contrast, when the diffserv network region is RSVP aware, the 856 admission control agent is part of the diffserv network. As a 857 result, changes in the capacity available in the diffserv network 858 region can be indicated to the Intserv network regions via RSVP. By 859 including routers interior to the diffserv network region in RSVP 860 signaling, it is possible to simultaneously improve the efficiency 861 of resource usage within the diffserv region and to improve the 862 level of confidence that the resources requested at admission 863 control are indeed available at this particular point in time. This 864 is because admission control can be linked to the availability of 865 resources along the specific path that would be impacted. We refer 866 to this benefit of RSVP signaling as 'topology aware admission 867 control'. A further benefit of supporting RSVP signaling within the 868 diffserv network region is that it is possible to effect changes in 869 the provisioning of the diffserv network region (e.g., allocating 870 more or less bandwidth to the EF queue in a router) in response to 871 resource requests from the RSVP/intserv network regions. 873 Various mechanisms may be used within the diffserv network region to 874 support dynamic provisioning and topology aware admission control. 875 These include aggregated RSVP, per-flow RSVP and bandwidth brokers, 876 as described in the following paragraphs. 878 5.2.1 Aggregated or Tunneled RSVP 880 A number of drafts [3,6,15, 16] propose mechanisms for extending 881 RSVP to reserve resources for an aggregation of flows between edges 882 of a network. Border routers may interact with core routers and 883 other border routers using aggregated RSVP to reserve resources 884 between edges of the diffserv network region. Initial reservation 885 levels for each service level may be established between major 886 border routers, based on anticipated traffic patterns. Border 887 routers could trigger changes in reservation levels as a result of 888 the cumulative per-flow RSVP requests from peripheral RSVP/intserv 889 network regions reaching high or low-water marks. 891 Bernet, ed. et al. 16 893 Integrated Services Operation Over Diffserv Networks June, 1999 895 In this approach, admission of per-flow RSVP requests from 896 RSVP/intserv networks would be counted against the appropriate 897 aggregate reservations for the corresponding service level. The size 898 of the aggregate reservations may or may not be dynamically adjusted 899 to deal with the changes in per-flow reservations. 901 The advantage of this approach is that it offers dynamic, topology 902 aware admission control to the diffserv network region without 903 requiring the level of RSVP signaling processing that would be 904 required to support per-flow RSVP. 906 5.2.3 Per-flow RSVP 908 In this approach, described in [3], routers in the diffserv network 909 region respond to the standard per-flow RSVP signaling originating 910 from the Intserv network regions. This approach provides the 911 benefits of the previous approach (dynamic, topology aware admission 912 control) without requiring aggregated RSVP support. Resources are 913 also used more efficiently as a result of the per-flow admission 914 control. However, the demands on RSVP signaling resources within the 915 diffserv network region may be significantly higher than in an 916 aggregated RSVP approach. 918 Note that per-flow RSVP and aggregated RSVP are not mutually 919 exclusive in a single diffserv region. It is possible to use per- 920 flow RSVP at the edges of the diffserv region and aggregation only 921 in some _core_ region within the diffserv region. 923 5.2.4 Granularity of Deployment of RSVP Aware Routers 925 In 5.2.2 and 5.2.3 some subset of the routers within the diffserv 926 network is RSVP signaling aware (though traffic control is 927 aggregated as opposed to per-flow). The relative number of routers 928 in the core that participate in RSVP signaling is a provisioning 929 decision that must be made by the network administrator. 931 In one extreme case, only the border routers participate in RSVP 932 signaling. In this case, either the diffserv network region must be 933 extremely over-provisioned and therefore, inefficiently used, or 934 else it must be carefully and statically provisioned for limited 935 traffic patterns. The border routers must enforce these patterns. 937 In the other extreme case, each router in the diffserv network 938 region might participate in RSVP signaling. In this case, resources 939 can be used with optimal efficiency, but signaling processing 940 requirements and associated overhead increase. As noted above, RSVP 941 aggregation is one way to limit the signaling overhead at the cost 942 of some loss of optimality in resource utilization. 944 It is likely that some network administrators will compromise by 945 enabling RSVP signaling on some subset of routers in the diffserv 946 network region. These routers will likely represent major traffic 948 Bernet, ed. et al. 17 950 Integrated Services Operation Over Diffserv Networks June, 1999 952 switching points with over-provisioned or statically provisioned 953 regions of RSVP unaware routers between them. 955 5.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region 957 Border routers might not use any form of RSVP signaling within the 958 diffserv network region but might instead use custom protocols to 959 interact with an 'oracle'. The oracle is a hypothetical agent that 960 has sufficient knowledge of resource availability and network 961 topology to make admission control decisions. The set of RSVP aware 962 routers in the previous two examples can be considered collectively 963 as a form of distributed oracle. In various definitions of the 964 'bandwidth broker' [4], it is able to act as a centralized oracle. 966 6. Implications of the Framework for Diffserv Network Regions 968 We have described a framework in which RSVP/intserv style QoS can be 969 provided across end-to-end paths that include diffserv network 970 regions. This section discusses some of the implications of this 971 framework for the diffserv network region. 973 6.1 Requirements from Diffserv Network Regions 975 A diffserv network region must meet the following requirements in 976 order for it to support the framework described in this draft. 978 1. A diffserv network region must be able to provide support for the 979 standard intserv QoS services between its border routers. It must be 980 possible to invoke these services by use of standard PHBs within the 981 diffserv region and appropriate behavior at the edge of the diffserv 982 region. 984 2. Diffserv network regions must provide admission control 985 information to intserv network regions. This information can be 986 provided by a dynamic protocol or through static service level 987 agreements enforced at the edges of the diffserv region. 989 3. Diffserv network regions must be able to pass RSVP messages, in 990 such a manner that they can be recovered at the egress of the 991 diffserv network region. The diffserv network region may, but is not 992 required to, process these messages. Mechanisms for transparently 993 carrying RSVP messages across a transit network are described in 994 [3,6,15, 16]. 996 To meet these requirements, additional work is required in the areas 997 of: 999 1. Mapping intserv style service specifications to services that can 1000 be provided by diffserv network regions. 1002 Bernet, ed. et al. 18 1004 Integrated Services Operation Over Diffserv Networks June, 1999 1006 2. Definition of the functionality required in network elements to 1007 support RSVP signaling with aggregate traffic control (for network 1008 elements residing in the diffserv network region). 1009 3. Definition of mechanisms to efficiently and dynamically provision 1010 resources in a diffserv network region (e.g. aggregated RSVP, 1011 tunneling, MPLS, etc.). This might include protocols by which an 1012 _oracle_ conveys information about resource availability within a 1013 diffserv region to border routers. 1015 6.2 Protection of Intserv Traffic from Other Traffic 1017 Network administrators must be able to share resources in the 1018 diffserv network region between three types of traffic: 1020 a. End-to-end Intserv traffic - this is typically traffic 1021 associated with quantitative QoS applications. It requires a 1022 specific quantity of resources with a high degree of assurance. 1024 b. Non-intserv traffic. The Diffserv region may allocate resources 1025 to traffic that does not make use of intserv techniques to quantify 1026 its requirements, e.g. through the use of static provisioning and 1027 SLSs enforced at the edges of the region. Such traffic might be 1028 associated with applications whose QoS requirements are not readily 1029 quantifiable but which require a 'better than best-effort' level of 1030 service. 1032 c. All other (best-effort) traffic 1034 These three classes of traffic must be isolated from each other by 1035 the appropriate configuration of policers and classifiers at ingress 1036 points to the diffserv network region, and by appropriate 1037 provisioning within the diffserv network region. To provide 1038 protection for Intserv traffic in diffserv regions of the network, 1039 we suggest that the DSCPs assigned to such traffic not overlap with 1040 the DSCPs assigned to other traffic. 1042 7. Multicast 1044 To be written. 1046 8. Security Considerations 1048 8.1 General RSVP Security 1050 We are proposing that RSVP signaling be used to obtain resources in 1051 both diffserv and Intserv regions of a network. Therefore, all RSVP 1052 security considerations apply [9]. In addition, network 1053 administrators are expected to protect network resources by 1054 configuring secure policers at interfaces with untrusted customers. 1056 8.2 Host Marking 1058 Bernet, ed. et al. 19 1060 Integrated Services Operation Over Diffserv Networks June, 1999 1062 Though it does not mandate host marking of the DSCP, our proposal 1063 does allow it. Allowing hosts to set the DSCP directly may alarm 1064 network administrators. The obvious concern is that hosts may 1065 attempt to 'steal' resources. In fact, hosts may attempt to exceed 1066 negotiated capacity in diffserv network regions at a particular 1067 service level regardless of whether they invoke this service level 1068 directly (by setting the DSCP) or indirectly (by submitting traffic 1069 that classifies in an intermediate marking router to a particular 1070 diff-serv DSCP). 1072 In either case, it will be necessary for each diffserv network 1073 region to protect its resources by policing to assure that customers 1074 do not use more resources than they are entitled to, at each service 1075 level (DSCP). If the sending host does not do the marking, the 1076 boundary router (or trusted intermediate routers) must provide MF 1077 classification, mark and police. If the sending host does do the 1078 marking, the boundary router needs only to provide BA classification 1079 and to police to ensure that the customer is not exceeding the 1080 aggregate capacity negotiated for the service level. 1082 In summary, there are no additional security concerns raised by 1083 marking the DSCP at the edge of the network since diffserv providers 1084 will have to police at their boundaries anyway. Furthermore, this 1085 approach reduces the granularity at which border routers must 1086 police, thereby pushing finer grain shaping and policing 1087 responsibility to the edges of the network, where it scales better. 1088 The larger diffserv network regions are thus focused on the task of 1089 protecting their networks, while the Intserv network regions are 1090 focused on the task of shaping and policing their own traffic to be 1091 in compliance with their negotiated intserv parameters. 1093 9. Acknowledgments 1095 Authors thank the following individuals for their comments that led 1096 to improvements to the previous version(s) of this draft: David 1097 Oran, Andy Veitch, Curtis Villamizer, Walter Weiss, Francois le 1098 Faucheur and Russell White. 1100 Many of the ideas in this document have been previously discussed in 1101 the original intserv architecture document [10]. 1103 10. References 1105 [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., 1106 "Resource Reservation Protocol (RSVP) Version 1 Functional 1107 Specification", RFC 2205, Proposed Standard, September 1997 1109 [2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M., 1110 "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based 1111 Admission Control Over IEEE 802 Style Networks", Internet Draft, 1112 draft-ietf-issll-is802-sbm-08.txt, May 1999 1114 Bernet, ed. et al. 20 1116 Integrated Services Operation Over Diffserv Networks June, 1999 1118 [3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated 1119 Services State", Internet Draft, draft-berson-rsvp-aggregation- 1120 00.txt, August 1998. 1122 [4] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit 1123 Differentiated Services Architecture for the Internet", Internet 1124 Draft, draft-nichols-diff-svc-arch-01.txt, April 1999. 1126 [5] Seaman, M., Smith, A., Crawley, E., and Wroclawski, J., 1127 "Integrated Service Mappings on IEEE 802 Networks", Internet 1128 Draft, draft-ietf-issll-is802-svc-mapping-03.txt, November 1998 1130 [6] Guerin, R., Blake, S. and Herzog, S.,"Aggregating RSVP based QoS 1131 Requests", Internet Draft, draft-guerin-aggreg-rsvp-00.txt, 1132 November 1997. 1134 [7] Nichols, Kathleen, et al., "Definition of the Differentiated 1135 Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 1136 2474, December 1998. 1138 [8] Blake, S., et al., "An Architecture for Differentiated 1139 Services." RFC 2475, December 1998. 1141 [9] Baker, F., "RSVP Cryptographic Authentication", Internet Draft, 1142 draft-ietf-rsvp-md5-08.txt, February 1999 1144 [10] Braden, R., Clark, D. and Shenker, S., "Integrated Services in 1145 the Internet Architecture: an Overview", Internet RFC 1633, 1146 June 1994 1148 [11] Garrett, M. W., and Borden, M., "Interoperation of Controlled- 1149 Load Service and Guaranteed Service with ATM", RFC2381, August 1150 1998. 1152 [12] Weiss, Walter, Private communication, November 1998. 1154 [13] Kent, S., Atkinson, R., "Security Architecture for the Internet 1155 Protocol", RFC 2401, November 1998. 1157 [14] Bernet, Y., "Usage and Format of the DCLASS Object with RSVP 1158 Signaling", Internet Draft, draft-bernet-dclass-00.txt, 1159 February 1999. 1161 [15] Baker, F., Iturralde, C., le Faucheur, F., and Davie, B. "RSVP 1162 Reservation Aggregation", Internet Draft, draft-baker-rsvp- 1163 aggregation-00.txt, February 1999. 1165 [16] Terzis, A., Krawczyk, J., Wroclawski, J., Zhang, L., "RSVP 1166 Operation Over IP Tunnels", Internet Draft, draft-ietf-rsvp- 1167 tunnel-03.txt, April 1999. 1169 Bernet, ed. et al. 21 1171 Integrated Services Operation Over Diffserv Networks June, 1999 1173 [17] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, D., and 1174 Sastry, A., _COPS Usage for RSVP_, Internet Draft, draft-ietf- 1175 rap-cops-rsvp-05.txt, June 1999. 1177 Author's Addresses: 1179 Yoram Bernet 1180 Microsoft 1181 One Microsoft Way, Redmond, WA 98052 1182 Phone: (425) 936-9568 1183 Email: yoramb@microsoft.com 1185 Raj Yavatkar 1186 Intel Corporation 1187 JF3-206 2111 NE 25th. Avenue, Hillsboro, OR 97124 1188 Phone: (503) 264-9077 1189 Email: raj.yavatkar@intel.com 1191 Peter Ford 1192 Microsoft 1193 One Microsoft Way, Redmond, WA 98052 1194 Phone: (425) 703-2032 1195 Email: peterf@microsoft.com 1197 Fred Baker 1198 Cisco Systems 1199 519 Lado Drive, Santa Barbara, CA 93111 1200 Phone: (408) 526-4257 1201 Email: fred@cisco.com 1203 Lixia Zhang 1204 UCLA 1205 4531G Boelter Hall Los Angeles, CA 90095 1206 Phone: +1 310-825-2695 1207 Email: lixia@cs.ucla.edu 1209 Michael Speer 1210 Sun Microsystems 1211 901 San Antonio Road UMPK15-215 Palo Alto, CA 94303 1212 Phone: +1 650-786-6368 1213 Email: speer@Eng.Sun.COM 1215 Bob Braden 1216 USC Information Sciences Institute 1217 4676 Admiralty Way Marina del Rey, CA 90292-6695 1218 Phone: 310-822-1511 1219 Email: braden@isi.edu 1221 Bruce Davie 1222 Cisco Systems 1223 250 Apollo Drive, Chelmsford, MA 01824 1224 Phone: (978)-244-8000 1226 Bernet, ed. et al. 22 1228 Integrated Services Operation Over Diffserv Networks June, 1999 1230 Email: bsd@cisco.com 1232 This draft expires December, 1999 1234 Bernet, ed. et al. 23