diff options
Diffstat (limited to 'doc/rfc/rfc2998.txt')
| -rw-r--r-- | doc/rfc/rfc2998.txt | 1739 |
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc2998.txt b/doc/rfc/rfc2998.txt new file mode 100644 index 0000000..7aad550 --- /dev/null +++ b/doc/rfc/rfc2998.txt @@ -0,0 +1,1739 @@ + + + + + + +Network Working Group Y. Bernet +Request for Comments: 2998 P. Ford +Category: Informational Microsoft + R. Yavatkar + Intel + F. Baker + Cisco + L. Zhang + UCLA + M. Speer + Sun Microsystems + R. Braden + ISI + B. Davie + Cisco + J. Wroclawski + MIT LCS + E. Felstaine + SANRAD + November 2000 + + + A Framework for Integrated Services Operation over Diffserv Networks + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + The Integrated Services (Intserv) architecture provides a means for + the delivery of end-to-end Quality of Service (QoS) to applications + over heterogeneous networks. To support this end-to-end model, the + Intserv architecture must be supported over a wide variety of + different types of network elements. In this context, a network that + supports Differentiated Services (Diffserv) may be viewed as a + network element in the total end-to-end path. This document + describes a framework by which Integrated Services may be supported + over Diffserv networks. + + + + + + +Bernet, et al. Informational [Page 1] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + +Table of Contents + + 1. Introduction ................................................. 3 + 1.1 Integrated Services Architecture ............................ 3 + 1.2 RSVP ........................................................ 3 + 1.3 Diffserv .................................................... 4 + 1.4 Roles of Intserv, RSVP and Diffserv ......................... 4 + 1.5 Components of Intserv, RSVP and Diffserv .................... 5 + 1.6 The Framework ............................................... 6 + 1.7 Contents .................................................... 6 + 2. Benefits of Using Intserv with Diffserv ...................... 7 + 2.1 Resource Based Admission Control ............................ 7 + 2.2 Policy Based Admission Control .............................. 8 + 2.3 Assistance in Traffic Identification/Classification ......... 8 + 2.3.1 Host Marking .............................................. 9 + 2.3.2 Router Marking ............................................ 9 + 2.4 Traffic Conditioning ........................................ 10 + 3. The Framework ................................................ 10 + 3.1 Reference Network ........................................... 11 + 3.1.1 Hosts ..................................................... 11 + 3.1.2 End-to-End RSVP Signaling ................................. 12 + 3.1.3 Edge Routers .............................................. 12 + 3.1.4 Border Routers ............................................ 12 + 3.1.5 Diffserv Network Region ................................... 13 + 3.1.6 Non-Diffserv Network Regions .............................. 13 + 3.2 Service Mapping ............................................. 13 + 3.2.1 Default Mapping ........................................... 14 + 3.2.2 Network Driven Mapping .................................... 14 + 3.2.3 Microflow Separation ...................................... 14 + 3.3 Resource Management in Diffserv Regions ..................... 15 + 4. Detailed Examples of the Operation of + Intserv over Diffserv Regions ................................ 16 + 4.1 Statically Provisioned Diffserv Network Region .............. 16 + 4.1.1 Sequence of Events in Obtaining End-to-end QoS ............ 16 + 4.2 RSVP-Aware Diffserv Network Region .......................... 18 + 4.2.1 Aggregated or Tunneled RSVP ............................... 19 + 4.2.3 Per-flow RSVP ............................................. 20 + 4.2.4 Granularity of Deployment of RSVP Aware Routers ........... 20 + 4.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region ..... 21 + 5. Implications of the Framework for Diffserv Network Regions ... 21 + 5.1 Requirements from Diffserv Network Regions .................. 21 + 5.2 Protection of Intserv Traffic from Other Traffic ............ 22 + 6. Multicast .................................................... 22 + 6.1 Remarking of packets in branch point routers ................ 24 + 6.2 Multicast SLSs and Heterogeneous Trees ...................... 25 + 7. Security Considerations ...................................... 26 + 7.1 General RSVP Security ....................................... 26 + 7.2 Host Marking ................................................ 26 + + + +Bernet, et al. Informational [Page 2] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + 8. Acknowledgments .............................................. 27 + 9. References ................................................... 27 + 10. Authors' Addresses .......................................... 29 + 11. Full Copyright Statement ................................... 31 + +1. Introduction + + Work on QoS-enabled IP networks has led to two distinct approaches: + the Integrated Services architecture (Intserv) [10] and its + accompanying signaling protocol, RSVP [1], and the Differentiated + Services architecture (Diffserv) [8]. This document describes ways + in which a Diffserv network can be used in the context of the Intserv + architecture to support the delivery of end-to-end QOS. + +1.1 Integrated Services Architecture + + The integrated services architecture defined a set of extensions to + the traditional best effort model of the Internet with the goal of + allowing end-to-end QOS to be provided to applications. One of the + key components of the architecture is a set of service definitions; + the current set of services consists of the controlled load and + guaranteed services. The architecture assumes that some explicit + setup mechanism is used to convey information to routers so that they + can provide requested services to flows that require them. While + RSVP is the most widely known example of such a setup mechanism, the + Intserv architecture is designed to accommodate other mechanisms. + + Intserv services are implemented by "network elements". While it is + common for network elements to be individual nodes such as routers or + links, more complex entities, such as ATM "clouds" or 802.3 networks + may also function as network elements. As discussed in more detail + below, a Diffserv network (or "cloud") may be viewed as a network + element within a larger Intserv network. + +1.2 RSVP + + RSVP is a signaling protocol that applications may use to request + resources from the network. The network responds by explicitly + admitting or rejecting RSVP requests. Certain applications that have + quantifiable resource requirements express these requirements using + Intserv parameters as defined in the appropriate Intserv service + specification. As noted above, RSVP and Intserv are separable. RSVP + is a signaling protocol which may carry Intserv information. Intserv + defines the models for expressing service types, quantifying resource + requirements and for determining the availability of the requested + resources at relevant network elements (admission control). + + + + + +Bernet, et al. Informational [Page 3] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + The current prevailing model of RSVP usage is based on a combined + RSVP/Intserv architecture. In this model, RSVP signals per-flow + resource requirements to network elements, using Intserv parameters. + These network elements apply Intserv admission control to signaled + requests. In addition, traffic control mechanisms on the network + element are configured to ensure that each admitted flow receives the + service requested in strict isolation from other traffic. To this + end, RSVP signaling configures microflow (MF) [8] packet classifiers + in Intserv capable routers along the path of the traffic flow. These + classifiers enable per-flow classification of packets based on IP + addresses and port numbers. + + The following factors have impeded deployment of RSVP (and the + Intserv architecture) in the Internet at large: + + 1. The use of per-flow state and per-flow processing raises + scalability concerns for large networks. + + 2. Only a small number of hosts currently generate RSVP signaling. + While this number is expected to grow dramatically, many + applications may never generate RSVP signaling. + + 3. The necessary policy control mechanisms -- access control, + authentication, and accounting -- have only recently become + available [17]. + +1.3 Diffserv + + In contrast to the per-flow orientation of RSVP, Diffserv networks + classify packets into one of a small number of aggregated flows or + "classes", based on the Diffserv codepoint (DSCP) in the packet's IP + header. This is known as behavior aggregate (BA) classification [8]. + At each Diffserv router, packets are subjected to a "per-hop + behavior" (PHB), which is invoked by the DSCP. The primary benefit + of Diffserv is its scalability. Diffserv eliminates the need for + per-flow state and per-flow processing and therefore scales well to + large networks. + +1.4 Roles of Intserv, RSVP and Diffserv + + We view Intserv, RSVP and Diffserv as complementary technologies in + the pursuit of end-to-end QoS. Together, these mechanisms can + facilitate deployment of applications such as IP-telephony, video- + on-demand, and various non-multimedia mission-critical applications. + Intserv enables hosts to request per-flow, quantifiable resources, + along end-to-end data paths and to obtain feedback regarding + admissibility of these requests. Diffserv enables scalability across + large networks. + + + +Bernet, et al. Informational [Page 4] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + +1.5 Components of Intserv, RSVP and Diffserv + + Before proceeding, it is helpful to identify the following components + of the QoS technologies described: + + RSVP signaling - This term refers to the standard RSVP signaling + protocol. RSVP signaling is used by hosts to signal application + resource requirements to the network (and to each other). Network + elements use RSVP signaling to return an admission control decision + to hosts. RSVP signaling may or may not carry Intserv parameters. + + Admission control at a network element may or may not be based on the + Intserv model. + + MF traffic control - This term refers to traffic control which is + applied independently to individual traffic flows and therefore + requires recognizing individual traffic flows via MF classification. + + Aggregate traffic control - This term refers to traffic control which + is applied collectively to sets of traffic flows. These sets of + traffic flows are recognized based on BA (DSCP) classification. In + this document, we use the terms "aggregate traffic control" and + "Diffserv" interchangeably. + + Aggregate RSVP. While the existing definition of RSVP supports only + per-flow reservations, extensions to RSVP are being developed to + enable RSVP reservations to be made for aggregated traffic, i.e., + sets of flows that may be recognized by BA classification. This use + of RSVP may be useful in controlling the allocation of bandwidth in + Diffserv networks. + + Per-flow RSVP. The conventional usage of RSVP to perform resource + reservations for individual microflows. + + RSVP/Intserv - This term is used to refer to the prevailing model of + RSVP usage which includes RSVP signaling with Intserv parameters, + Intserv admission control and per-flow traffic control at network + elements. + + Diffserv Region. A set of contiguous routers which support BA + classification and traffic control. While such a region may also + support MF classification, the goal of this document is to describe + how such a region may be used in delivery of end-to-end QOS when only + BA classification is performed inside the Diffserv region. + + Non-Diffserv Region. The portions of the network outside the + Diffserv region. Such a region may also offer a variety of different + types of classification and traffic control. + + + +Bernet, et al. Informational [Page 5] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + Note that, for the purposes of this document, the defining features + of a Diffserv region is the type of classification and traffic + control that is used for the delivery of end-to-end QOS for a + particular application. Thus, while it may not be possible to + identify a certain region as "purely Diffserv" with respect to all + traffic flowing through the region, it is possible to define it in + this way from the perspective of the treatment of traffic from a + single application. + +1.6 The Framework + + In the framework we present, end-to-end, quantitative QoS is provided + by applying the Intserv model end-to-end across a network containing + one or more Diffserv regions. The Diffserv regions may, but are not + required to, participate in end-to-end RSVP signaling for the purpose + of optimizing resource allocation and supporting admission control. + + From the perspective of Intserv, Diffserv regions of the network are + treated as virtual links connecting Intserv capable routers or hosts + (much as an 802.1p network region is treated as a virtual link in + [5]). Within the Diffserv regions of the network routers implement + specific PHBs (aggregate traffic control). The total amount of + traffic that is admitted into the Diffserv region that will receive a + certain PHB may be limited by policing at the edge. As a result we + expect that the Diffserv regions of the network will be able to + support the Intserv style services requested from the periphery. In + our framework, we address the support of end-to-end Integrated + Services over the Diffserv regions of the network. Our goal is to + enable seamless inter-operation. As a result, the network + administrator is free to choose which regions of the network act as + Diffserv regions. In one extreme the Diffserv region is pushed all + the way to the periphery, with hosts alone having full Intserv + capability. In the other extreme, Intserv is pushed all the way to + the core, with no Diffserv region. + +1.7 Contents + + In section 3 we discuss the benefits that can be realized by using + the aggregate traffic control provided by Diffserv network regions in + the broader context of the Intserv architecture. In section 4, we + present the framework and the reference network. Section 5 details + two possible realizations of the framework. Section 6 discusses the + implications of the framework for Diffserv. Section 7 presents some + issues specific to multicast flows. + + + + + + + +Bernet, et al. Informational [Page 6] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + +2. Benefits of Using Intserv with Diffserv + + The primary benefit of Diffserv aggregate traffic control is its + scalability. In this section, we discuss the benefits that + interoperation with Intserv can bring to a Diffserv network region. + Note that this discussion is in the context of servicing quantitative + QoS applications specifically. By this we mean those applications + that are able to quantify their traffic and QoS requirements. + +2.1 Resource Based Admission Control + + In Intserv networks, quantitative QoS applications use an explicit + setup mechanism (e.g., RSVP) to request resources from the network. + The network may accept or reject these requests in response. This is + "explicit admission control". Explicit and dynamic admission control + helps to assure that network resources are optimally used. To + further understand this issue, consider a Diffserv network region + providing only aggregate traffic control with no signaling. In the + Diffserv network region, admission control is applied in a relatively + static way by provisioning policing parameters at network elements. + For example, a network element at the ingress to a Diffserv network + region could be provisioned to accept only 50 Kbps of traffic for the + EF DSCP. + + While such static forms of admission control do protect the network + to some degree, they can be quite ineffective. For example, consider + that there may be 10 IP telephony sessions originating outside the + Diffserv network region, each requiring 10 Kbps of EF service from + the Diffserv network region. Since the network element protecting + the Diffserv network region is provisioned to accept only 50 Kbps of + traffic for the EF DSCP, it will discard half the offered traffic. + This traffic will be discarded from the aggregation of traffic marked + EF, with no regard to the microflow from which it originated. As a + result, it is likely that of the ten IP telephony sessions, none will + obtain satisfactory service when in fact, there are sufficient + resources available in the Diffserv network region to satisfy five + sessions. + + In the case of explicitly signaled, dynamic admission control, the + network will signal rejection in response to requests for resources + that would exceed the 50 Kbps limit. As a result, upstream network + elements (including originating hosts) and applications will have the + information they require to take corrective action. The application + might respond by refraining from transmitting, or by requesting + admission for a lesser traffic profile. The host operating system + might respond by marking the application's traffic for the DSCP that + corresponds to best-effort service. Upstream network elements might + respond by re-marking packets on the rejected flow to a lower service + + + +Bernet, et al. Informational [Page 7] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + level. In some cases, it may be possible to reroute traffic over + alternate paths or even alternate networks (e.g., the PSTN for voice + calls). In any case, the integrity of those flows that were admitted + would be preserved, at the expense of the flows that were not + admitted. Thus, by appointing an Intserv-conversant admission + control agent for the Diffserv region of the network it is possible + to enhance the service that the network can provide to quantitative + QoS applications. + +2.2 Policy Based Admission Control + + In network regions where RSVP is used, resource requests can be + intercepted by RSVP-aware network elements and can be reviewed + against policies stored in policy databases. These resource requests + securely identify the user and the application for which the + resources are requested. Consequently, the network element is able + to consider per-user and/or per-application policy when deciding + whether or not to admit a resource request. So, in addition to + optimizing the use of resources in a Diffserv network region (as + discussed in 3.1) RSVP conversant admission control agents can be + used to apply specific customer policies in determining the specific + customer traffic flows entitled to use the Diffserv network region's + resources. Customer policies can be used to allocate resources to + specific users and/or applications. + + By comparison, in Diffserv network regions without RSVP signaling, + policies are typically applied based on the Diffserv customer network + from which traffic originates, not on the originating user or + application within the customer network. + +2.3 Assistance in Traffic Identification/Classification + + Within Diffserv network regions, traffic is allotted service based on + the DSCP marked in each packet's IP header. Thus, in order to obtain + a particular level of service within the Diffserv network region, it + is necessary to effect the marking of the correct DSCP in packet + headers. There are two mechanisms for doing so, host marking and + router marking. In the case of host marking, the host operating + system marks the DSCP in transmitted packets. In the case of router + marking, routers in the network are configured to identify specific + traffic (typically based on MF classification) and to mark the DSCP + as packets transit the router. There are advantages and + disadvantages to each scheme. Regardless of the scheme used, + explicit signaling offers significant benefits. + + + + + + + +Bernet, et al. Informational [Page 8] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + +2.3.1 Host Marking + + In the case of host marking, the host operating system marks the DSCP + in transmitted packets. This approach has the benefit of shifting + per-flow classification and marking to the source of the traffic, + where it scales best. It also enables the host to make decisions + regarding the mark that is appropriate for each transmitted packet + and hence the relative importance attached to each packet. The host + is generally better equipped to make this decision than the network. + Furthermore, if IPSEC encryption is used, the host may be the only + device in the network that is able to make a meaningful determination + of the appropriate marking for each packet, since various fields such + as port numbers would be unavailable to routers for MF + classification. + + Host marking requires that the host be aware of the interpretation of + DSCPs by the network. This information can be configured into each + host. However, such configuration imposes a management burden. + Alternatively, hosts can use an explicit signaling protocol such as + RSVP to query the network to obtain a suitable DSCP or set of DSCPs + to apply to packets for which a certain Intserv service has been + requested. An example of how this can be achieved is described in + [14]. + +2.3.2 Router Marking + + In the case of router marking, MF classification criteria must be + configured in the router in some way. This may be done dynamically + (e.g., using COPS provisioning), by request from the host operating + system, or statically via manual configuration or via automated + scripts. + + There are significant difficulties in doing so statically. In many + cases, it is desirable to allot service to traffic based on the + application and/or user originating the traffic. At times it is + possible to identify packets associated with a specific application + by the IP port numbers in the headers. It may also be possible to + identify packets originating from a specific user by the source IP + address. However, such classification criteria may change + frequently. Users may be assigned different IP addresses by DHCP. + Applications may use transient ports. To further complicate matters, + multiple users may share an IP address. These factors make it very + difficult to manage static configuration of the classification + information required to mark traffic in routers. + + An attractive alternative to static configuration is to allow host + operating systems to signal classification criteria to the router on + behalf of users and applications. As we will show later in this + + + +Bernet, et al. Informational [Page 9] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + document, RSVP signaling is ideally suited for this task. In + addition to enabling dynamic and accurate updating of MF + classification criteria, RSVP signaling enables classification of + IPSEC [13] packets (by use of the SPI) which would otherwise be + unrecognizable. + +2.4 Traffic Conditioning + + Intserv-capable network elements are able to condition traffic at a + per-flow granularity, by some combination of shaping and/or policing. + Pre-conditioning traffic in this manner before it is submitted to the + Diffserv region of the network is beneficial. In particular, it + enhances the ability of the Diffserv region of the network to provide + quantitative services using aggregate traffic control. + +3. The Framework + + In the general framework we envision an Internet in which the + Integrated Services architecture is used to deliver end-to-end QOS to + applications. The network includes some combination of Intserv + capable nodes (in which MF classification and per-flow traffic + control is applied) and Diffserv regions (in which aggregate traffic + control is applied). Individual routers may or may not participate + in RSVP signaling regardless of where in the network they reside. + + We will consider two specific realizations of the framework. In the + first, resources within the Diffserv regions of the network are + statically provisioned and these regions include no RSVP aware + devices. In the second, resources within the Diffserv region of the + network are dynamically provisioned and select devices within the + Diffserv network regions participate in RSVP signaling. + + + + + + + + + + + + + + + + + + + + +Bernet, et al. Informational [Page 10] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + +3.1 Reference Network + + The two realizations of the framework will be discussed in the + context of the following reference network: + + ________ ______________ ________ + / \ / \ / \ + / \ / \ / \ + |---| | |---| |---| |---| |---| | |---| + |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx | + |---| | |-- | |---| |---| |---| | |---| + \ / \ / \ / + \________/ \______________/ \________/ + + Non-Diffserv region Diffserv region Non-Diffserv region + + Figure 1: Sample Network Configuration + + The reference network includes a Diffserv region in the middle of a + larger network supporting Intserv end-to-end. The Diffserv region + contains a mesh of routers, at least some of which provide aggregate + traffic control. The regions outside the Diffserv region (non- + Diffserv regions) contain meshes of routers and attached hosts, at + least some of which support the Integrated Services architecture. + + In the interest of simplicity we consider a single QoS sender, Tx + communicating across this network with a single QoS receiver, Rx. + The edge routers (ER1, ER2) which are adjacent to the Diffserv region + interface to the border routers (BR1, BR2) within the Diffserv + region. + + From an economic viewpoint, we may consider that the Diffserv region + sells service to the network outside the Diffserv region, which in + turn provides service to hosts. Thus, we may think of the non- + Diffserv regions as clients or customers of the Diffserv region. In + the following, we use the term "customer" for the non-Diffserv + regions. Note that the boundaries of the regions may or may not + align with administrative domain boundaries, and that a single region + might contain multiple administrative domains. + + We now define the major components of the reference network. + +3.1.1 Hosts + + We assume that both sending and receiving hosts use RSVP to + communicate the quantitative QoS requirements of QoS-aware + applications running on the host. In principle, other mechanisms may + be used to establish resource reservations in Intserv-capable nodes, + + + +Bernet, et al. Informational [Page 11] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + but RSVP is clearly the prevalent mechanism for this purpose. + + Typically, a QoS process within the host operating system generates + RSVP signaling on behalf of applications. This process may also + invoke local traffic control. + + As discussed above, traffic control in the host may mark the DSCP in + transmitted packets, and shape transmitted traffic to the + requirements of the Intserv service in use. Alternatively, the first + Intserv-capable router downstream from the host may provide these + traffic control functions. + +3.1.2 End-to-End RSVP Signaling + + We assume that RSVP signaling messages travel end-to-end between + hosts Tx and Rx to support RSVP/Intserv reservations outside the + Diffserv network region. We require that these end-to-end RSVP + messages are at least carried across the Diffserv region. Depending + on the specific realization of the framework, these messages may be + processed by none, some or all of the routers in the Diffserv region. + +3.1.3 Edge Routers + + ER1 and ER2 are edge routers, residing adjacent to the Diffserv + network regions. The functionality of the edge routers varies + depending on the specific realization of the framework. In the case + in which the Diffserv network region is RSVP unaware, edge routers + act as admission control agents to the Diffserv network. They + process signaling messages from both Tx and Rx, and apply admission + control based on resource availability within the Diffserv network + region and on customer defined policy. In the case in which the + Diffserv network region is RSVP aware, the edge routers apply + admission control based on local resource availability and on + customer defined policy. In this case, the border routers act as the + admission control agent to the Diffserv network region. + + We will later describe the functionality of the edge routers in + greater depth for each of the two realizations of the framework. + +3.1.4 Border Routers + + BR1 and BR2 are border routers, residing in the Diffserv network + region. The functionality of the border routers varies depending on + the specific realization of the framework. In the case in which the + Diffserv network region is RSVP-unaware, these routers act as pure + Diffserv routers. As such, their sole responsibility is to police + submitted traffic based on the service level specified in the DSCP + and the agreement negotiated with the customer (aggregate + + + +Bernet, et al. Informational [Page 12] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + trafficcontrol). In the case in which the Diffserv network region is + RSVP-aware, the border routers participate in RSVP signaling and act + as admission control agents for the Diffserv network region. + + We will later describe the functionality of the border routers in + greater depth for each of the two realizations of the framework. + +3.1.5 Diffserv Network Region + + The Diffserv network region supports aggregate traffic control and is + assumed not to be capable of MF classification. Depending on the + specific realization of the framework, some number of routers within + the Diffserv region may be RSVP aware and therefore capable of per- + flow signaling and admission control. If devices in the Diffserv + region are not RSVP aware, they will pass RSVP messages transparently + with negligible performance impact (see [6]). + + The Diffserv network region provides two or more levels of service + based on the DSCP in packet headers. It may be a single + administrative domain or may span multiple domains. + +3.1.6 Non-Diffserv Network Regions + + The network outside of the Diffserv region consists of Intserv + capable hosts and other network elements. Other elements may include + routers and perhaps various types of network (e.g., 802, ATM, etc.). + These network elements may reasonably be assumed to support Intserv, + although this might not be required in the case of over-provisioning. + Even if these elements are not Intserv capable, we assume that they + will pass RSVP messages unhindered. Routers outside of the Diffserv + network region are not precluded from providing aggregate traffic + control to some subset of the traffic passing through them. + +3.2 Service Mapping + + Intserv service requests specify an Intserv service type and a set of + quantitative parameters known as a "flowspec". At each hop in an + Intserv network, the Intserv service requests are interpreted in a + form meaningful to the specific link layer medium. For example at an + 802.1 hop, the Intserv parameters are mapped to an appropriate 802.1p + priority level [5]. + + In our framework, Diffserv regions of the network are analogous to + the 802.1p capable switched segments described in [5]. Requests for + Intserv services must be mapped onto the underlying capabilities of + the Diffserv network region. Aspects of the mapping include: + + + + + +Bernet, et al. Informational [Page 13] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + - selecting an appropriate PHB, or set of PHBs, for the requested + service; + - performing appropriate policing (including, perhaps, shaping or + remarking) at the edges of the Diffserv region; + - exporting Intserv parameters from the Diffserv region (e.g., for + the updating of ADSPECs); + - performing admission control on the Intserv requests that takes + into account the resource availability in the Diffserv region. + + Exactly how these functions are performed will be a function of the + way bandwidth is managed inside the Diffserv network region, which is + a topic we discuss in Section 4.3. + + When the PHB (or set of PHBs) has been selected for a particular + Intserv flow, it may be necessary to communicate the choice of DSCP + for the flow to other network elements. Two schemes may be used to + achieve this end, as discussed below. + +3.2.1 Default Mapping + + In this scheme, there is some standard, well-known mapping from + Intserv service type to a DSCP that will invoke the appropriate + behavior in the Diffserv network. + +3.2.2 Network Driven Mapping + + In this scheme, RSVP conversant routers in the Diffserv network + region (perhaps at its edge) may override the well-known mapping + described in 4.2.1. In the case that DSCPs are marked at the ingress + to the Diffserv region, the DSCPs can simply be remarked at the + boundary routers. However, in the case that DSCP marking occurs + upstream of the Diffserv region, either in a host or a router, then + the appropriate mapping needs to be communicated upstream, to the + marking device. This may be accomplished using RSVP, as described in + [14]. + + The decision regarding where to mark DSCP and whether to override the + well-known service mapping is a mater of policy to be decided by the + administrator of the Diffserv network region in cooperation with the + administrator of the network adjacent to the Diffserv region. + +3.2.3 Microflow Separation + + Boundary routers residing at the edge of the Diffserv region will + typically police traffic submitted from the outside the Diffserv + region in order to protect resources within the Diffserv region. + This policing will be applied on an aggregate basis, with no regard + for the individual microflows making up each aggregate. As a result, + + + +Bernet, et al. Informational [Page 14] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + it is possible for a misbehaving microflow to claim more than its + fair share of resources within the aggregate, thereby degrading the + service provided to other microflows. This problem may be addressed + by: + + 1. Providing per microflow policing at the edge routers - this is + generally the most appropriate location for microflow policing, since + it pushes per-flow work to the edges of the network, where it scales + better. In addition, since Intserv-capable routers outside the + Diffserv region are responsible for providing microflow service to + their customers and the Diffserv region is responsible for providing + aggregate service to its customers, this distribution of + functionality mirrors the distribution of responsibility. + + 2. Providing per microflow policing at the border routers - this + approach tends to be less scalable than the previous approach. It + also imposes a management burden on the Diffserv region of the + network. However, it may be appropriate in certain cases, for the + Diffserv boundary routers to offer per microflow policing as a + value-add to its Intserv customers. + + 3. Relying on upstream shaping and policing - in certain cases, the + customer may trust the shaping of certain groups of hosts + sufficiently to not warrant reshaping or policing at the boundary of + the Diffserv region. Note that, even if the hosts are shaping + microflows properly, these shaped flows may become distorted as they + transit through the non-Diffserv region of the network. Depending on + the degree of distortion, it may be necessary to somewhat over- + provision the aggregate capacities in the Diffserv region, or to re- + police using either 1 or 2 above. The choice of one mechanism or + another is a matter of policy to be decided by the administrator of + the network outside the Diffserv region. + +3.3 Resource Management in Diffserv Regions + + A variety of options exist for management of resources (e.g., + bandwidth) in the Diffserv network regions to meet the needs of end- + to-end Intserv flows. These options include: + + - statically provisioned resources; + - resources dynamically provisioned by RSVP; + - resources dynamically provisioned by other means (e.g., a form of + Bandwidth Broker). + + Some of the details of using each of these different approaches are + discussed in the following section. + + + + + +Bernet, et al. Informational [Page 15] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + +4. Detailed Examples of the Operation of Intserv over Diffserv Regions + + In this section we provide detailed examples of our framework in + action. We discuss two examples, one in which the Diffserv network + region is RSVP unaware, the other in which the Diffserv network + region is RSVP aware. + +4.1 Statically Provisioned Diffserv Network Region + + In this example, no devices in the Diffserv network region are RSVP + aware. The Diffserv network region is statically provisioned. The + customer(s) of the Diffserv network regions and the owner of the + Diffserv network region have negotiated a static contract (service + level specification, or SLS) for the transmit capacity to be provided + to the customer at each of a number of standard Diffserv service + levels. The "transmit capacity" may be simply an amount of bandwidth + or it could be a more complex "profile" involving a number of factors + such as burst size, peak rate, time of day etc. + + It is helpful to consider each edge router in the customer network as + consisting of two halves, a standard Intserv half, which interfaces + to the customer's network regions and a Diffserv half which + interfaces to the Diffserv network region. The Intserv half is able + to identify and process traffic on per-flow granularity. + + The Diffserv half of the router can be considered to consist of a + number of virtual transmit interfaces, one for each Diffserv service + level negotiated in the SLS. The router contains a table that + indicates the transmit capacity provisioned, per the SLS at each + Diffserv service level. This table, in conjunction with the default + mapping described in 4.2.1, is used to perform admission control + decisions on Intserv flows which cross the Diffserv network region. + +4.1.1 Sequence of Events in Obtaining End-to-end QoS + + The following sequence illustrates the process by which an + application obtains end-to-end QoS when RSVP is used by the hosts. + + 1. The QoS process on the sending host Tx generates an RSVP PATH + message that describes the traffic offered by the sending + application. + + 2. The PATH message is carried toward the receiving host, Rx. In the + network region to which the sender is attached, standard RSVP/Intserv + processing is applied at capable network elements. + + 3. At the edge router ER1, the PATH message is subjected to standard + RSVP processing and PATH state is installed in the router. The PATH + + + +Bernet, et al. Informational [Page 16] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + message is sent onward to the Diffserv network region. + + 4. The PATH message is ignored by routers in the Diffserv network + region and then processed at ER2 according to standard RSVP + processing rules. + + 5. When the PATH message reaches the receiving host Rx, the operating + system generates an RSVP RESV message, indicating interest in offered + traffic of a certain Intserv service type. + + 6. The RESV message is carried back towards the Diffserv network + region and the sending host. Consistent with standard RSVP/Intserv + processing, it may be rejected at any RSVP-capable node in the path + if resources are deemed insufficient to carry the traffic requested. + + 7. At ER2, the RESV message is subjected to standard RSVP/Intserv + processing. It may be rejected if resources on the downstream + interface of ER2 are deemed insufficient to carry the resources + requested. If it is not rejected, it will be carried transparently + through the Diffserv network region, arriving at ER1. + + 8. In ER1, the RESV message triggers admission control processing. + ER1 compares the resources requested in the RSVP/Intserv request to + the resources available in the Diffserv network region at the + corresponding Diffserv service level. The corresponding service + level is determined by the Intserv to Diffserv mapping discussed + previously. The availability of resources is determined by the + capacity provisioned in the SLS. ER1 may also apply a policy + decision such that the resource request may be rejected based on the + customer's specific policy criteria, even though the aggregate + resources are determined to be available per the SLS. + + 9. If ER1 approves the request, the RESV message is admitted and is + allowed to continue upstream towards the sender. If it rejects the + request, the RESV is not forwarded and the appropriate RSVP error + messages are sent. If the request is approved, ER1 updates its + internal tables to indicate the reduced capacity available at the + admitted service level on its transmit interface. + + 10. The RESV message proceeds through the network region to which the + sender is attached. Any RSVP node in this region may reject the + reservation request due to inadequate resources or policy. If the + request is not rejected, the RESV message will arrive at the sending + host, Tx. + + 11. At Tx, the QoS process receives the RESV message. It interprets + receipt of the message as indication that the specified traffic flow + has been admitted for the specified Intserv service type (in the + + + +Bernet, et al. Informational [Page 17] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + Intserv-capable nodes). It may also learn the appropriate DSCP + marking to apply to packets for this flow from information provided + in the RESV. + + 12. Tx may mark the DSCP in the headers of packets that are + transmitted on the admitted traffic flow. The DSCP may be the + default value which maps to the Intserv service type specified in the + admitted RESV message, or it may be a value explicitly provided in + the RESV. + + In this manner, we obtain end-to-end QoS through a combination of + networks that support RSVP/Intserv and networks that support + Diffserv. + +4.2 RSVP-Aware Diffserv Network Region + + In this example, the customer's edge routers are standard RSVP + routers. The border router, BR1 is RSVP aware. In addition, there + may be other routers within the Diffserv network region which are + RSVP aware. Note that although these routers are able to participate + in some form of RSVP signaling, they classify and schedule traffic in + aggregate, based on DSCP, not on the per-flow classification criteria + used by standard RSVP/Intserv routers. It can be said that their + control-plane is RSVP while their data-plane is Diffserv. This + approach exploits the benefits of RSVP signaling while maintaining + much of the scalability associated with Diffserv. + + In the preceding example, there is no signaling between the Diffserv + network region and network elements outside it. The negotiation of + an SLS is the only explicit exchange of resource availability + information between the two network regions. ER1 is configured with + the information represented by the SLS and as such, is able to act as + an admission control agent for the Diffserv network region. Such + configuration does not readily support dynamically changing SLSs, + since ER1 requires reconfiguration each time the SLS changes. It is + also difficult to make efficient use of the resources in the Diffserv + network region. This is because admission control does not consider + the availability of resources in the Diffserv network region along + the specific path that would be impacted. + + By contrast, when the Diffserv network region is RSVP aware, the + admission control agent is part of the Diffserv network. As a + result, changes in the capacity available in the Diffserv network + region can be indicated to the Intserv-capable nodes outside the + Diffserv region via RSVP. By including routers interior to the + Diffserv network region in RSVP signaling, it is possible to + simultaneously improve the efficiency of resource usage within the + Diffserv region and to improve the level of confidence that the + + + +Bernet, et al. Informational [Page 18] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + resources requested at admission control are indeed available at this + particular point in time. This is because admission control can be + linked to the availability of resources along the specific path that + would be impacted. We refer to this benefit of RSVP signaling as + "topology aware admission control". A further benefit of supporting + RSVP signaling within the Diffserv network region is that it is + possible to effect changes in the provisioning of the Diffserv + network region (e.g., allocating more or less bandwidth to the EF + queue in a router) in response to resource requests from outside of + the Diffserv region. + + Various mechanisms may be used within the Diffserv network region to + support dynamic provisioning and topology aware admission control. + These include aggregated RSVP, per-flow RSVP and bandwidth brokers, + as described in the following paragraphs. + +4.2.1 Aggregated or Tunneled RSVP + + A number of documents [3,6,15,16] propose mechanisms for extending + RSVP to reserve resources for an aggregation of flows between edges + of a network. Border routers may interact with core routers and + other border routers using aggregated RSVP to reserve resources + between edges of the Diffserv network region. Initial reservation + levels for each service level may be established between major border + routers, based on anticipated traffic patterns. Border routers could + trigger changes in reservation levels as a result of the cumulative + per-flow RSVP requests from the non-Diffserv regions reaching high or + low-water marks. + + In this approach, admission of per-flow RSVP requests from nodes + outside the Diffserv region would be counted against the appropriate + aggregate reservations for the corresponding service level. The size + of the aggregate reservations may or may not be dynamically adjusted + to deal with the changes in per-flow reservations. + + The advantage of this approach is that it offers dynamic, topology + aware admission control to the Diffserv network region without + requiring the level of RSVP signaling processing that would be + required to support per-flow RSVP. + + We note that resource management of a Diffserv region using + aggregated RSVP is most likely to be feasible only within a single + administrative domain, as each domain will probably choose its own + mechanism to manage its resources. + + + + + + + +Bernet, et al. Informational [Page 19] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + +4.2.3 Per-flow RSVP + + In this approach, described in [3], routers in the Diffserv network + region respond to the standard per-flow RSVP signaling originating + from the Intserv-capable nodes outside the Diffserv region. This + approach provides the benefits of the previous approach (dynamic, + topology aware admission control) without requiring aggregated RSVP + support. Resources are also used more efficiently as a result of the + per-flow admission control. However, the demands on RSVP signaling + resources within the Diffserv network region may be significantly + higher than in an aggregated RSVP approach. + + Note that per-flow RSVP and aggregated RSVP are not mutually + exclusive in a single Diffserv region. It is possible to use per-flow + RSVP at the edges of the Diffserv region and aggregation only in some + "core" region within the Diffserv region. + +4.2.4 Granularity of Deployment of RSVP Aware Routers + + In 4.2.2 and 4.2.3 some subset of the routers within the Diffserv + network is RSVP signaling aware (though traffic control is aggregated + as opposed to per-flow). The relative number of routers in the core + that participate in RSVP signaling is a provisioning decision that + must be made by the network administrator. + + In one extreme case, only the border routers participate in RSVP + signaling. In this case, either the Diffserv network region must be + extremely over-provisioned and therefore, inefficiently used, or else + it must be carefully and statically provisioned for limited traffic + patterns. The border routers must enforce these patterns. + + In the other extreme case, each router in the Diffserv network region + might participate in RSVP signaling. In this case, resources can be + used with optimal efficiency, but signaling processing requirements + and associated overhead increase. As noted above, RSVP aggregation + is one way to limit the signaling overhead at the cost of some loss + of optimality in resource utilization. + + It is likely that some network administrators will compromise by + enabling RSVP signaling on some subset of routers in the Diffserv + network region. These routers will likely represent major traffic + switching points with over-provisioned or statically provisioned + regions of RSVP unaware routers between them. + + + + + + + + +Bernet, et al. Informational [Page 20] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + +4.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region + + Border routers might not use any form of RSVP signaling within the + Diffserv network region but might instead use custom protocols to + interact with an "oracle". The oracle is an agent that has + sufficient knowledge of resource availability and network topology to + make admission control decisions. The set of RSVP aware routers in + the previous two examples can be considered collectively as a form of + distributed oracle. In various definitions of the "bandwidth broker" + [4], it is able to act as a centralized oracle. + +5. Implications of the Framework for Diffserv Network Regions + + We have described a framework in which RSVP/Intserv style QoS can be + provided across end-to-end paths that include Diffserv network + regions. This section discusses some of the implications of this + framework for the Diffserv network region. + +5.1 Requirements from Diffserv Network Regions + + A Diffserv network region must meet the following requirements in + order for it to support the framework described in this document. + + 1. A Diffserv network region must be able to provide support for the + standard Intserv QoS services between its border routers. It must be + possible to invoke these services by use of standard PHBs within the + Diffserv region and appropriate behavior at the edge of the Diffserv + region. + + 2. Diffserv network regions must provide admission control + information to their "customer" (non-Diffserv) network regions. This + information can be provided by a dynamic protocol or through static + service level agreements enforced at the edges of the Diffserv + region. + + 3. Diffserv network regions must be able to pass RSVP messages, in + such a manner that they can be recovered at the egress of the + Diffserv network region. The Diffserv network region may, but is not + required to, process these messages. Mechanisms for transparently + carrying RSVP messages across a transit network are described in + [3,6,15,16]. + + To meet these requirements, additional work is required in the areas + of: + + 1. Mapping Intserv style service specifications to services that can + be provided by Diffserv network regions. + + + + +Bernet, et al. Informational [Page 21] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + 2. Definition of the functionality required in network elements to + support RSVP signaling with aggregate traffic control (for network + elements residing in the Diffserv network region). + 3. Definition of mechanisms to efficiently and dynamically provision + resources in a Diffserv network region (e.g., aggregated RSVP, + tunneling, MPLS, etc.). This might include protocols by which an + "oracle" conveys information about resource availability within a + Diffserv region to border routers. One example of such a mechanism + is the so-called "bandwidth broker" proposed in [19,20,21]. + +5.2 Protection of Intserv Traffic from Other Traffic + + Network administrators must be able to share resources in the + Diffserv network region between three types of traffic: + + a. End-to-end Intserv traffic. This is typically traffic associated + with quantitative QoS applications. It requires a specific quantity + of resources with a high degree of assurance. + + b. Non-Intserv traffic. The Diffserv region may allocate resources + to traffic that does not make use of Intserv techniques to quantify + its requirements, e.g., through the use of static provisioning and + SLSs enforced at the edges of the region. Such traffic might be + associated with applications whose QoS requirements are not readily + quantifiable but which require a "better than best-effort" level of + service. + + c. All other (best-effort) traffic. These three classes of traffic + must be isolated from each other by the appropriate configuration of + policers and classifiers at ingress points to the Diffserv network + region, and by appropriate provisioning within the Diffserv network + region. To provide protection for Intserv traffic in Diffserv + regions of the network, we suggest that the DSCPs assigned to such + traffic not overlap with the DSCPs assigned to other traffic. + +6. Multicast + + The use of integrated services over Diffserv networks is + significantly more complex for multicast sessions than for unicast + sessions. With respect to a multicast connection, each participating + region has a single ingress router and zero, one or several egress + routers. The difficulties of multicast are associated with Diffserv + regions that contain several egress routers. (Support of multicast + functionality outside the Diffserv region is relatively + straightforward since every Intserv-capable router along the + multicast tree stores state for each flow.) + + Consider the following reference network: + + + +Bernet, et al. Informational [Page 22] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + Non-Diffserv region 2 + ________ + / \ + | | |---| + ________ _____________ | |-|Rx1| + / \ / |--\ |---| | |---| + / \ / /|BR2\-----\ER2| / + |---| | |---| |---| |--|/ |---| \--|____/ + |Tx |-| |ER1|---|BR1|--|RR| | ________ + |---| | |-- | |---| |--|\ |---| /--| \ + \ / \ \|BR3/-----|ER3| | |---| + \________/ \__________|--/ |---| |-|Rx2| + | | |---| + Non-Diffserv region 1 Diffserv region \ / + \______/ + + Non-Diffserv region 3 + + Figure 2: Sample Multicast Network Configuration + + The reference network is similar to that of Figure 1. However, in + Figure 2, copies of the packets sent by Tx are delivered to several + receivers outside of the Diffserv region, namely to Rx1 and Rx2. + Moreover, packets are copied within the Diffserv region in a "branch + point" router RR. In the reference network BR1 is the ingress router + to the Diffserv region whereas BR2 and BR3 are the egress routers. + + In the simplest case the receivers, Rx1 and Rx2 in the reference + network, require identical reservations. The Diffserv framework [18] + supports service level specifications (SLS) from an ingress router to + one, some or all of the egress routers. This calls for a "one to + many" SLS within the Diffserv region, from BR1 to BR2 and BR3. Given + that the SLS is granted by the Diffserv region, the ingress router + BR1, or perhaps an upstream node such as ER1, marks packets entering + the Diffserv region with the appropriate DSCP. The packets are + routed to the egresses of the Diffserv domain using the original + multicast address. + + The two major problems, explained in the following, are associated + with heterogeneous multicast trees containing branch points within + the Diffserv region, i.e., multicast trees where the level of + resource requirement is not uniform among all receivers. An example + of such a scenario in the network of Figure 2 is the case where both + Rx1 and Rx2 need to receive multicast data from Tx1 but only one of + the receivers has requested a level of service above best effort. We + consider such scenarios in the following paragraphs. + + + + + +Bernet, et al. Informational [Page 23] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + +6.1 Remarking of packets in branch point routers + + In the above scenario, the packets that arrive at BR1 are marked with + an appropriate DSCP for the requested Intserv service and are sent to + RR. Packets arriving at the branch point must be sent towards BR2 + with the same DSCP otherwise the service to Rx1 is degraded. + However, the packets going from RR towards BR3 need not maintain the + high assurance level anymore. They may be demoted to best effort so + that the QoS provided to other packets along this branch of the tree + is not disrupted. Several problems can be observed in the given + scenario: + + - In the Diffserv region, DSCP marking is done at edge routers + (ingress), whereas a branch point router might be a core + router, which does not mark packets. + + - Being a core Diffserv router, RR classifies based on + aggregate traffic streams (BA), as opposed to per flow (MF) + classification. Hence, it does not necessarily have the + capability to distinguish those packets which belong to a + specific multicast tree and require demotion from the other + packets in the behavior aggregate, which carry the same DSCP. + + - Since RR may be RSVP-unaware, it may not participate in the + admission control process, and would thus not store any per- + flow state about the reservations for the multicast tree. + Hence, even if RR were able to perform MF classification and + DSCP remarking, it would not know enough about downstream + reservations to remark the DSCP intelligently. + + These problems could be addressed by a variety of mechanisms. We + list some below, while noting that none is ideal in all cases and + that further mechanisms may be developed in the future: + + 1. If some Intserv-capable routers are placed within the Diffserv + region, it might be possible to administer the network topology and + routing parameters so as to ensure that branch points occur only + within such routers. These routers would support MF classification + and remarking and hold per-flow state for the heterogeneous + reservations for which they are the branch point. Note that in this + case, branch point routers would have essentially the same + functionality as ingress routers of an RSVP-aware Diffserv domain. + + 2. Packets sent on the "non-reserved" branch (from RR towards BR3) + are marked with the "wrong" DSCP; that is, they are not demoted to + best effort but retain their DSCP. This in turn requires over + reservation of resources along that link or runs the risk of + degrading service to packets that legitimately bear the same DSCP + + + +Bernet, et al. Informational [Page 24] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + along this path. However, it allows the Diffserv routers to remain + free of per-flow state. + + 3. A combination of mechanism 1 and 2 may be an effective compromise. + In this case, there are some Intserv-capable routers in the core of + the network, but the network cannot be administered so that ALL + branch points fall at such routers. + + 4. Administrators of Diffserv regions may decide not to enable + heterogeneous sub-trees in their domains. In the case of different + downstream reservations, a ResvErr message would be sent according to + the RSVP rules. This is similar to the approach taken for Intserv + over IEEE 802 Networks [2,5]. + + 5. In [3], a scheme was introduced whereby branch point routers in + the interior of the aggregation region (i.e., the Diffserv region) + keep reduced state information regarding the reservations by using + measurement based admission control. Under this scheme, packets are + tagged by the more knowledgeable Intserv edges routers with + scheduling information that is used in place of the detailed Intserv + state. If the Diffserv region and branch point routers are designed + following that framework, demotion of packets becomes possible. + +6.2 Multicast SLSs and Heterogeneous Trees + + Multicast flows with heterogeneous reservations present some + challenges in the area of SLSs. For example, a common example of an + SLS is one where a certain amount of traffic is allowed to enter a + Diffserv region marked with a certain DSCP, and such traffic may be + destined to any egress router of that region. We call such an SLS a + homogeneous, or uniform, SLS. However, in a multicast environment, a + single packet that is admitted to the Diffserv region may consume + resources along many paths in the region as it is replicated and + forwarded towards many egress routers; alternatively, it may flow + along a single path. This situation is further complicated by the + possibility described above and depicted in Figure 2, in which a + multicast packet might be treated as best effort along some branches + while receiving some higher QOS treatment along others. We simply + note here that the specification of meaningful SLSs which meet the + needs of heterogeneous flows and which can be met be providers is + likely to be challenging. + + Dynamic SLSs may help to address these issues. For example, by using + RSVP to signal the resources that are required along different + branches of a multicast tree, it may be possible to more closely + approach the goal of allocating appropriate resources only where they + are needed rather than overprovisioning or underprovisioning along + certain branches of a tree. This is essentially the approach + + + +Bernet, et al. Informational [Page 25] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + described in [15]. + +7. Security Considerations + +7.1 General RSVP Security + + We are proposing that RSVP signaling be used to obtain resources in + both Diffserv and non-Diffserv regions of a network. Therefore, all + RSVP security considerations apply [9]. In addition, network + administrators are expected to protect network resources by + configuring secure policers at interfaces with untrusted customers. + +7.2 Host Marking + + Though it does not mandate host marking of the DSCP, our proposal + does allow it. Allowing hosts to set the DSCP directly may alarm + network administrators. The obvious concern is that hosts may + attempt to "steal" resources. In fact, hosts may attempt to exceed + negotiated capacity in Diffserv network regions at a particular + service level regardless of whether they invoke this service level + directly (by setting the DSCP) or indirectly (by submitting traffic + that classifies in an intermediate marking router to a particular + DSCP). + + In either case, it will generally be necessary for each Diffserv + network region to protect its resources by policing to assure that + customers do not use more resources than they are entitled to, at + each service level (DSCP). The exception to this rule is when the + host is known to be trusted, e.g., a server that is under the control + of the network administrators. If an untrusted sending host does not + perform DSCP marking, the boundary router (or trusted intermediate + routers) must provide MF classification, mark and police. If an + untrusted sending host does perform marking, the boundary router + needs only to provide BA classification and to police to ensure that + the customer is not exceeding the aggregate capacity negotiated for + the service level. + + In summary, there are no additional security concerns raised by + marking the DSCP at the edge of the network since Diffserv providers + will have to police at their boundaries anyway. Furthermore, this + approach reduces the granularity at which border routers must police, + thereby pushing finer grain shaping and policing responsibility to + the edges of the network, where it scales better and provides other + benefits described in Section 3.3.1. The larger Diffserv network + regions are thus focused on the task of protecting their networks, + while the Intserv-capable nodes are focused on the task of shaping + and policing their own traffic to be in compliance with their + negotiated Intserv parameters. + + + +Bernet, et al. Informational [Page 26] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + +8. Acknowledgments + + Authors thank the following individuals for their comments that led + to improvements to the previous version(s) of this document: David + Oran, Andy Veitch, Curtis Villamizer, Walter Weiss, Francois le + Faucheur and Russell White. + + Many of the ideas in this document have been previously discussed in + the original Intserv architecture document [10]. + +9. References + + [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, + "Resource Reservation Protocol (RSVP) Version 1 Functional + Specification", RFC 2205, September 1997. + + [2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M. Speer, + "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based + Admission Control Over IEEE 802 Style Networks", RFC 2814, May + 2000. + + [3] Berson, S. and R. Vincent, "Aggregation of Internet Integrated + Services State", Work in Progress. + + [4] Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit + Differentiated Services Architecture for the Internet", RFC + 2638, July 1999. + + [5] Seaman, M., Smith, A., Crawley, E. and J. Wroclawski, + "Integrated Service Mappings on IEEE 802 Networks", RFC 2815, + May 2000. + + [6] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based + QoS Requests", Work in Progress. + + [7] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of + the Differentiated Services Field (DS Field) in the IPv4 and + IPv6 Headers", RFC 2474, December 1998. + + [8] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. + Weiss, "An Architecture for Differentiated Services", RFC 2475, + December 1998. + + [9] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic + Authentication", RFC 2747, January 2000. + + [10] Braden, R., Clark, D. and S. Shenker, "Integrated Services in + the Internet Architecture: an Overview", RFC 1633, June 1994. + + + +Bernet, et al. Informational [Page 27] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + [11] Garrett, M. and M. Borden, "Interoperation of Controlled-Load + Service and Guaranteed Service with ATM", RFC 2381, August 1998. + + [12] Weiss, Walter, Private communication, November 1998. + + [13] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [14] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, + November 2000. + + [15] Baker, F., Iturralde, C., le Faucheur, F., and Davie, B. "RSVP + Reservation Aggregation", Work in Progress. + + [16] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP + Operation Over IP Tunnels", RFC 2746, January 2000. + + [17] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, D. and A. + Sastry, "COPS Usage for RSVP", RFC 2749, January 2000. + + [18] Bernet, Y., "A Framework for Differentiated Services", Work in + Progress. + + [19] Jacobson Van, "Differentiated Services Architecture", talk in + the Int-Serv WG at the Munich IETF, August 1997. + + [20] Jacobson, V., Nichols K. and L. Zhang, "A Two-bit Differentiated + Services Architecture for the Internet", RFC 2638, June 1999. + + [21] First Internet2 bandwidth broker operability event + http://www.merit.edu/internet/working.groups/i2-qbone-bb/ + inter-op/index.htm + + + + + + + + + + + + + + + + + + + +Bernet, et al. Informational [Page 28] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + +10. Authors' Addresses + + Yoram Bernet + Microsoft + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425-936-9568 + EMail: yoramb@microsoft.com + + + Raj Yavatkar + Intel Corporation + JF3-206 2111 NE 25th. Avenue + Hillsboro, OR 97124 + + Phone: +1 503-264-9077 + EMail: raj.yavatkar@intel.com + + + Peter Ford + Microsoft + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425-703-2032 + EMail: peterf@microsoft.com + + + Fred Baker + Cisco Systems + 519 Lado Drive + Santa Barbara, CA 93111 + + Phone: +1 408-526-4257 + EMail: fred@cisco.com + + + Lixia Zhang + UCLA + 4531G Boelter Hall + Los Angeles, CA 90095 + + Phone: +1 310-825-2695 + EMail: lixia@cs.ucla.edu + + + + + + +Bernet, et al. Informational [Page 29] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + + Michael Speer + Sun Microsystems + 901 San Antonio Road, UMPK15-215 + Palo Alto, CA 94303 + + Phone: +1 650-786-6368 + EMail: speer@Eng.Sun.COM + + + Bob Braden + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292-6695 + + Phone: +1 310-822-1511 + EMail: braden@isi.edu + + + Bruce Davie + Cisco Systems + 250 Apollo Drive + Chelmsford, MA 01824 + + Phone: +1 978-244-8000 + EMail: bsd@cisco.com + + + Eyal Felstaine + SANRAD Inc. + 24 Raul Wallenberg st + Tel Aviv, Israel + + Phone: +972-50-747672 + Email: eyal@sanrad.com + + + John Wroclawski + MIT Laboratory for Computer Science + 545 Technology Sq. + Cambridge, MA 02139 + + Phone: +1 617-253-7885 + EMail: jtw@lcs.mit.edu + + + + + + + + +Bernet, et al. Informational [Page 30] + +RFC 2998 Integrated Services Over Diffserv Networks November 2000 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Bernet, et al. Informational [Page 31] + |