Internet Draft Y. Bernet, Microsoft R. Yavatkar, Intel P. Ford, Microsoft F. Baker, Cisco L. Zhang, UCLA M. Speer, Sun Microsystems R. Braden, ISI Internet Draft Expires: September, 1999 Document: draft-ietf-issll-diffserv-rsvp-01.txt March, 1999 Interoperation of RSVP/Intserv and Diffserv Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are Working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at linebreak http://www.ietf.org/shadow.html. 1. Abstract RSVP/Integrated Services and Differentiated Services provide complementary approaches to the problem of providing end-to-end QoS in the Internet. These approaches must be able to coexist and effectively inter-operate. This document describes a framework by which the two approaches inter-operate to provide end-to-end QoS for quantitative applications (applications for which QoS requirements are readily quantifiable, and which rely on these QoS requirements to function properly). 2. Introduction Work on QoS-enabled IP networks has led to two distinct approaches: the Integrated Services architecture (intserv)[12] and its accompanying signaling protocol, RSVP [1], vs. the Differentiated Services architecture (diffserv)[10]. 2.1 RSVP/Intserv Bernet, ed. et. al 1 Use of RSVP with Diffserv March, 1999 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. It is important to emphasize that RSVP and intserv are separable; RSVP is a signaling protocol. Intserv is a set of models for expressing service types, quantifying resource requirements and for determining the availability of the requested resources at relevant network elements (admission control). 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 'MF' [10] 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 the RSVP/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 -- are not available. 2.2 Diffserv The market is pushing for immediate deployment of a QoS solution that addresses the needs of the Internet as well as enterprise networks. This push led to the development of diffserv. In contrast to the per-flow orientation of RSVP/intserv, 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 'BA' classification [10]. At each diffserv router, packets are subjected to a 'per-hop behaviour' (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. 2.3 Complementary Roles of RSVP/Intserv and Diffserv We view RSVP/intserv 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- Bernet, ed. et. al 2 Use of RSVP with Diffserv March, 1999 on-demand, and various non-multimedia mission-critical applications. RSVP/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. 2.3 Components of RSVP/intserv 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 per-flow signaling protocol. RSVP signaling is used by hosts to signal per- flow 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. 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. 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 draft, we use the terms 'aggregate traffic control' and 'diffserv' interchangeably. We will refer to RSVP/intserv regions of the network and diffserv regions of the network. RSVP/intserv regions are those regions in which both RSVP signaling and MF traffic control are supported. These regions include hosts and network elements that are RSVP/intserv capable. (RSVP/intserv regions are not precluded from supporting aggregate traffic control as well as MF traffic control). Diffserv regions are those regions in which aggregate traffic control is supported. 2.4 The Framework In the framework we present, end-to-end, quantitative QoS is provided by coupling RSVP/Intserv regions at the periphery of the network with diffserv regions in the core of the network. The diffserv regions may, but are not required to, participate in the end-to-end RSVP signaling for the purpose of optimizing resource allocation and supporting admission control. From the perspective of RSVP/intserv, diffserv regions of the network are treated as virtual links connecting RSVP/Intserv capable Bernet, ed. et. al 3 Use of RSVP with Diffserv March, 1999 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). We use RSVP to apply admission control to each PHB in the diffserv region. As a result we expect that the diffserv regions of the network will be able to extend the intserv style services requested from the periphery. As such, we often refer to the RSVP/intserv network regions as 'customers' of the diffserv network regions. In our framework, we address the inter-operability between the RSVP/intserv regions of the network and 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 RSVP/intserv regions and which act as diffserv regions. In one extreme the diffserv region is pushed all the way to the periphery, with hosts alone comprising the RSVP/intserv regions of the network. In the other extreme, RSVP/intserv is pushed all the way to the core, with no diffserv region. 2.5 Contents In section 3 we discuss the benefits that can be realized by using RSVP/intserv together with the aggregate traffic control provided by diffserv network regions. In section 4, we present the framework and the reference network. Section 5 details two realizations of the framework. Section 6 discusses the implications of the framework for diffserv. Appendix A contains a list of some important terms used in this document. Though the primary goal of this draft is to describe a framework for inter-operation of RSVP/intserv network regions and diffserv network regions, the draft currently does not address the issues specific to IP multicast flows. 3. Benefits of Using RSVP/intserv with Diffserv The primary benefit of diffserv aggregate traffic control is its scalability. In this section, we discuss the benefits that interoperation with RSVP/intserv can bring to a diffserv network region. Note that this discussion is in the context of servicing quantitative applications specifically. 3.1 Resource Based Admission Control In RSVP/Intserv networks, quantitative QoS applications use RSVP to request resources from the network. The network may accept or reject these requests in response. This is 'explicit admission control'. Explicit 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 implicitly by provisioning policing parameters at network elements. For example, a network element at the ingress to a Bernet, ed. et. al 4 Use of RSVP with Diffserv March, 1999 diffserv network region could be provisioned to accept only 50 Kbps of traffic for the EF DSCP. While such implicit admission control does protect the network to some degree, it 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 explicit 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 level. 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 RSVP 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 applications. 3.2 Policy Based Admission Control In an RSVP/intserv network region, 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 per-flow 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. Bernet, ed. et. al 5 Use of RSVP with Diffserv March, 1999 3.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 (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, RSVP signaling offers significant benefits. 3.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 edge of the network, where it scales best. It also enables the host to make decisions regarding the mark (and hence the relative priority that is requested) that is appropriate for each transmitted packet. The host is generally better equipped to make this decision than the network. 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, RSVP/intserv hosts can use RSVP signaling to query the network for a mapping from intserv service type to DSCP. This is achieved via the RSVP DCLASS object [17] and is explained later in this draft. 3.3.2 Router Marking In the case of router marking, MF classification criteria must be configured in the router. This may be done dynamically, by request from the host operating system, or statically via manual configuration or via automated scripts. There are significant difficulties in doing so statically. Typically, 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. Bernet, ed. et. al 6 Use of RSVP with Diffserv March, 1999 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 draft, 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 [16] packets (by use of the SPI) which would otherwise be unrecognizable. 3.4 Traffic Conditioning Those network elements that do provide RSVP/intserv support will 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. 4. The Framework In the general framework we envision an Internet in which hosts use RSVP/intserv to request reservations for specific services from the network. The network includes some combination of RSVP/intserv regions (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 the type of network region in which 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. 4.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 | |---| | |-- | |---| |---| |---| | |---| \ / \ / \ / \______ / \___ _________ / \__ _____/ RSVP/Intserv region Diffserv region RSVP/Intserv region Figure 1: Sample Network Configuration Bernet, ed. et. al 7 Use of RSVP with Diffserv March, 1999 The reference network includes a diffserv region interconnecting two RSVP/intserv regions. The diffserv region contains a mesh of routers, at least some of which provide aggregate traffic control. The RSVP/intserv regions contain meshes of routers and attached hosts, at least some of which are RSVP/intserv capable. In the interest of simplicity we consider a single QoS sender, Tx in one of the RSVP/intserv network regions and a single QoS receiver, Rx in the other. The edge routers (ER1, ER2) within the RSVP/intserv regions interface to the border routers (BR1, BR1) within the diffserv regions. From an economic viewpoint, we may consider that the diffserv region sells service to the RSVP/intserv regions, which provide service to hosts. Thus, we may think of the RSVP/intserv regions as customers of the diffserv region. In the following, we use the term 'customer' for the RSVP/intserv regions. 4.1.1 Components of the Reference Network We now define the major components of the reference network. 4.1.1.1 Hosts Both sending and receiving hosts use RSVP/intserv to communicate the quantitative QoS requirements of QoS-aware applications running on the host. Typically, a QoS process within the host operating system generates RSVP signaling on behalf of applications. This process may also invoke local traffic control. In this example, traffic control in the host marks the DSCP in transmitted packets, and it shapes transmitted traffic to the requirements of the intserv service in use. In alternate realizations of the framework, the first-hop router within the RSVP/intserv network regions may provide these traffic control functions. 4.1.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 in the RSVP/intserv network regions. We require that these end-to-end RSVP messages are 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. 4.1.1.3 Edge Routers ER1 and ER2 are edge routers, residing in the RSVP/intserv 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 Bernet, ed. et. al 8 Use of RSVP with Diffserv March, 1999 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. 4.1.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/intserv 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 traffic control). In the case in which the diffserv network region is RSVP/intserv 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. 4.1.1.5 RSVP/Intserv Network Regions Each RSVP/intserv network region consists of RSVP/intserv capable hosts and some number of routers. These routers may reasonably be assumed to be RSVP/intserv capable, although this might not be required in the case of a small, over-provisioned network region. If they are not RSVP/intserv capable, we assume that they will pass RSVP messages unhindered. Routers in the RSVP/intserv network region are not precluded from providing aggregate traffic control to non- quantitative traffic passing through them. 4.1.1.6 Diffserv Network Region The diffserv network region supports aggregate traffic control and is not 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 [8]). The diffserv network region provides two or more levels of service based on the DSCP in packet headers. It may include sub-regions managed as different administrative domains. 4.1.1.7 Service Mapping Bernet, ed. et. al 9 Use of RSVP with Diffserv March, 1999 RSVP/intserv signaling requests specify an intserv service type and a set of quantitative parameters known as a 'flowspec'. At each hop in an intserv network, the RSVP/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]. Admission control agents for diffserv network regions must map intserv service types to a corresponding diffserv service level (DSCP or PHB) that can reasonably extend the intserv service type requested by the application. The admission control agent can then approve or reject resource requests based on the capacity available in the diffserv network region at the mapped service level. One of two schemes may be used to map intserv service types to diffserv service levels. 4.1.1.7.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. 4.1.1.7.2 Network Driven Mapping In this scheme, RSVP aware routers in the diffserv network region may override the well-known mapping described in 4.1.1.7.1. RSVP RESV messages originating from receivers will carry the usual intserv service type. RSVP aware routers within the diffserv network region may append a DCLASS [17] object to RESV messages as they are forwarded upstream. When a RESV message carrying a DCLASS object arrives at a sending host (or in the case of router marking, at an intermediate router), the sender starts marking transmitted packets with the DSCP indicated. A decision to override the well-known service mapping may be based on configuration and/or a policy decision. 5. Detailed Examples of the Interoperation of RSVP/Intserv and Diffserv 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. 5.1 RSVP Unaware Diffserv Network Region In this example, no devices in the diffserv network region are RSVP aware. The diffserv network region is statically provisioned. The owner(s) of the RSVP/intserv network regions and the owner of the diffserv network region have negotiated a static contract (service Bernet, ed. et. al 10 Use of RSVP with Diffserv March, 1999 level agreement, or SLA) for the transmit capacity to be provided to the customer at each of a number of standard diffserv service levels. It is helpful to consider the edge routers in the customer network, to consist of two halves, a standard RSVP/intserv half, which interfaces to the customer's RSVP/intserv network regions and a diffserv half which interfaces to the diffserv network region. The RSVP/intserv half has full RSVP capability. It is able to participate in RSVP signaling and it 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 SLA. The router contains a table that indicates the transmit capacity provisioned, per the SLA at each diffserv service level. This table, in conjunction with the default mapping described in 4.1.1.7.1, is used to apply admission control decisions to the diffserv network region. 5.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. 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 RSVP/intserv 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 message is sent onward to the diffserv network region. 4. The PATH message is carried transparently through 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 node in the RSVP/intserv network region 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 Bernet, ed. et. al 11 Use of RSVP with Diffserv March, 1999 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 SLA. 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 SLA. 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 RSVP/intserv 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 RSVP/intserv network regions) and for the corresponding diffserv service level (in the diffserv network regions). 12. Tx begins to mark the DSCP in the headers of packets that are transmitted on the admitted traffic flow. The DSCP is the value which maps to the intserv service type specified in the admitted RESV message. In this manner, we obtain end-to-end QoS through a combination of networks that support RSVP/Intserv and networks that support diffserv. 5.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 RSVP signaling, they process 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 Bernet, ed. et. al 12 Use of RSVP with Diffserv March, 1999 benefits of RSVP signaling while maintaining much of the scalability associated with diffserv. In the former example, there is no RSVP signaling between the RSVP/intserv network regions and the diffserv network region. The negotiation of an SLA is the only explicit exchange of resource availability information between the two network regions. ER1 is configured with the information represented by the SLA 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 SLAs, since ER1 requires reconfiguration each time the SLA 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 RSVP/intserv network regions via traditional RSVP. By including routers interior to the diffserv network region in RSVP signaling, it is possible to improve the efficiency of resource usage. 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 response to resource requests from the RSVP/intserv network regions. 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. 5.2.1 Aggregated or Tunneled RSVP A number of drafts [8,10,18, 19] 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 peripheral RSVP/intserv network regions reaching high or low-water marks. In this approach, admission of per-flow RSVP requests from RSVP/intserv networks would be counted against the appropriate aggregate reservations for the corresponding service level. Bernet, ed. et. al 13 Use of RSVP with Diffserv March, 1999 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. 5.2.3 Per-flow RSVP In this approach, routers in the diffserv network region respond to the standard per-flow RSVP signaling originating from the RSVP/intserv network regions. 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. 5.2.4 Oracle 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 a hypothetical agent that has sufficient topology awareness to make admission control decisions. The set of RSVP aware routers in the previous two examples can be considered collectively as a distributed oracle. In various definitions of the 'bandwidth broker' [4], it is able to act as a centralized oracle. 5.2.5 Granularity of Deployment of RSVP Aware Routers In 5.2.2 and 5.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. It is likely that 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. 6. Implications of the Framework for DiffServ Network Regions Bernet, ed. et. al 14 Use of RSVP with Diffserv March, 1999 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. 6.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 draft. 1. A diffserv network region must be able to provide standard QoS services between its border routers. It must be possible to invoke these services by use of a standard DSCP. 2. There must be appropriate service mappings from intserv service types to these diffserv services. 3. Diffserv network regions must provide admission control information to intserv network regions. This information can be provided by a dynamic protocol or, at the very least, through static service level agreements. 4. 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 [8,10,18, 19]. 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. 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.). 6.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. RSVP/intserv signaled - this is traffic associated with quantitative applications. It requires a specific quantity of resources with a high degree of assurance. b. Qualitative - this is traffic associated with applications that are not quantitative. Its resource requirements are not readily quantifiable. It requires a 'better than best-effort' level of service. Bernet, ed. et. al 15 Use of RSVP with Diffserv March, 1999 c. All other (best-effort) traffic These 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 RSVP/intserv signaled 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. 7. Multicast To be written. 8. Security Considerations 8.1 General RSVP Security We are proposing that RSVP signaling be used to obtain resources in both diffserv and RSVP/intserv regions of a network. Therefore, all RSVP security considerations apply [11]. In addition, network administrators are expected to protect network resources by configuring secure policers at interfaces with untrusted customers. 8.2 Host Marking Though it does not mandate host marking, our proposal does recommend 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 diff- serv DSCP). In either case, it will 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). If the sending host does not do the marking, the boundary router (or trusted intermediate routers) must provide MF classification, mark and police. If the sending host does do the 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, the security concerns of marking the DSCP at the edge of the network can be dismissed since each diffserv provider will have to police at their boundary 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. The larger diffserv network regions are thus focused on the task of protecting their networks, Bernet, ed. et. al 16 Use of RSVP with Diffserv March, 1999 while the RSVP/intserv network regions are focused on the task of shaping and policing their own traffic to be in compliance with their negotiated intserv parameters. 7. Acknowledgments Authors thank the following individuals for their comments that led to improvements to the previous version(s) of this draft: David Oran, Andy Veitch, Curtis Villamizer, Walter Weiss, and Russel White. Many of the ideas in this document have been previously discussed in the original intserv architecture document [12]. 8. References [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., "Resource Reservation Protocol (RSVP) Version 1 Functional Specification", RFC 2205, Proposed Standard, September 1997 [2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M., "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based Admission Control Over IEEE 802 Style Networks", Internet Draft, March 1998 [3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated Services State", Internet Draft, December 1997. [4] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit Differentiated Services Architecture for the Internet", Internet Draft, December 1997. [5] Seaman, M., Smith, A. and Crawley, E., "Integrated Services Over IEEE 802.1D/802.1p Networks", Internet Draft, June 1997 [6] Elleson, E. and Blake, S., "A Proposal for the Format and Semantics of the TOS Byte and Traffic Class Byte in Ipv4 and Ipv6 Headers", Internet Draft, November 1997 [7] Ferguson, P., "Simple Differential Services: IP TOS and Precedence, Delay Indication, and Drop Preference", Internet Draft, November 1997 [8] Guerin, R., Blake, S. and Herzog, S.,"Aggregating RSVP based QoS Requests", Internet Draft, November 1997. [9] Nichols, Kathleen, et al., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [10] Blake, S., et al., "An Architecture for Differentiated Services." RFC 2475, December 1998. [11] Baker, F., "RSVP Cryptographic Authentication", Internet Draft, Bernet, ed. et. al 17 Use of RSVP with Diffserv March, 1999 August 1997 [12] Braden, R., Clark, D. and Shenker, S., "Integrated Services in the Internet Architecture: an Overview", Internet RFC 1633, June 1994 [13] Garrett, M. W., and Borden, M., "Interoperation of Controlled- Load Service and Guaranteed Service with ATM", RFC2381, August 1998. [14] Weiss, Walter, Private communication, November 1998. [15] Berson, S. and Vincent, S., "Aggregation of Internet Integrated Services State", Internet Draft, August 1998. [16] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [17] Bernet, Y., "Usage and Format of the DCLASS Object with RSVP Signaling", Internet Draft, February 1999. [18] Baker, F., Iturralde, C., "RSVP Reservation Aggregation", Internet Draft, February 1999. [19] Terzis, A., Krawczyk, J., Wroclawski, J., Zhang, L., "RSVP Operation Over IP Tunnels", Internet Draft, February 1999. Author's Addresses: Yoram Bernet Microsoft One Microsoft Way, Redmond, WA 98052 Phone: (425) 936-9568 Email: yoramb@microsoft.com Raj Yavatkar Intel Corporation JF3-206 2111 NE 25th. Avenue, Hillsboro, OR 97124 Phone: (503) 264-9077 Email: raj.yavatkar@intel.com Peter Ford Microsoft One Microsoft Way, Redmond, WA 98052 Phone: (425) 703-2032 Email: peterf@microsoft.com Fred Baker Cisco Systems 519 Lado Drive, Santa Barbara, CA 93111 Phone: (408) 526-4257 Email: fred@cisco.com Lixia Zhang Bernet, ed. et. al 18 Use of RSVP with Diffserv March, 1999 UCLA 4531G Boelter Hall Los Angeles, CA 90095 Phone: +1 310-825-2695 Email: lixia@cs.ucla.edu 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: 310-822-1511 Email: braden@isi.edu This draft expires September, 1999 Bernet, ed. et. al 19