Internet Engineering Task Force Y. Bernet, Microsoft Internet Draft R. Yavatkar, Intel draft-bernet-intdiff-00.txt P. Ford, Microsoft F. Baker, Cisco L. Zhang, UCLA March, 1998 A Framework for End-to-End QoS Combining RSVP/Intserv and Differentiated Services Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before September, 1998. Distribution of this draft is unlimited. 1. Abstract In the past several years, work on QoS enabled networks led to the development of the Integrated Services (Intserv) architecture [12] and the RSVP signaling protocol [1]. RSVP addresses the needs of applications that require QoS, promising per-flow service. As the RSVP/Intserv (from here on abbreviated to intserv) work has proceeded, we have recognized barriers to the deployment of intserv. The reliance of intserv on per-flow state and per-flow processing is an impediment to its deployment in the Internet at large, and in particular in large carrier networks. Additionally, RSVP signaling is supposed to originate from hosts, which as of yet are not RSVP enabled in large numbers. Recently, attention has shifted to Differentiated services (diff- serv). Diff-serv promises to expedite the realization of QoS enabled 1 Framework for End-to-End QoS March, 1998 networks by offering a significantly simpler alternative to intserv, which eliminates scalability concerns and which can be implemented and managed in large networks, without requiring end-to-end deployment. However, unlike intserv, diff-serv focuses on the needs of the large network. This draft proposes a framework for end-to-end QoS, in which intserv and diff-serv are used together to meet the needs of large ISPs who manage the transit networks of the Internet, and the users of QoS applications and hosts, who are the ISPs' ultimate customers. This focus is important, as we believe that in the coming years, there will be a proliferation of applications that depend on QoS and of hosts which are capable of QoS signaling. We envision the deployment of diff-serv capable core networks and intserv capable stub networks at the periphery. Our framework allows each to proceed at its own pace, providing immediate incremental benefits in areas of the network in which one or the other is deployed and additional benefits where both are deployed. This framework builds upon current work in the IETF including diff-serv [10] and RSVP aggregation [8]. Many of the ideas in this document have been previously discussed in the original intserv architecture document [12]. 2. Goals of This Draft This draft is based on the assumption that end-to-end QoS is required to support the needs of certain applications. Such applications include IP-telephony, video-on-demand and various non- multimedia mission-critical applications. In our view, intserv and diff-serv are complementary tools in the pursuit of end-to-end QoS. Each serves an important purpose in the end-to-end QoS enabled network. The primary goal of this draft is to encourage the continued development of each in a manner that does not preclude realization of the proposed framework. To this end, we will: 1. List the requirements of a network that provides end-to-end QoS. 2. Present a framework that uses intserv as a customer of diff-serv to meet these requirements. 3. Identify dependencies of intserv on diff-serv. 3. Requirements for the End-to-End QoS Framework An end-to-end QoS network must serve the requirements of network managers as well as those of applications. We consider these requirements in the context of the following general topology: 2 Framework for End-to-End QoS March, 1998 / Stub \ / Transit \ / Stub \ / Network \ / Network \ / Network \ |---| | |---| |---| |---| |---| | |---| |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx | |---| | |-- | |---| |---| |---| | |---| \ / \ / \ / \ / \ / \ / Figure 1: Sample Network Configuration This network consists of a diff-serv capable transit network and two intserv capable stub networks. In the interest of simplicity, we show a single QoS sender on one of the stub networks and a single QoS receiver on the other. We show edge routers (ER1, ER2) at the interfaces of the intserv networks to the diff-serv network. We show boundary routers (BR1, BR2) at the interfaces of the diff-serv network to the intserv networks. The transit network contains a mesh of routers, at least some of which are diff-serv capable. The stub networks contain a mesh of routers, at least some of which are intserv capable. We define the following requirements of the framework: 3.1 Definition of a Set of Services There must be a set of useful end-to-end services that can be requested by QoS needy applications. Routers internal to the diff- serv network are assumed to provide a set of 'per-hop-behaviours' (PHBs [10]). We expect that concatenation of certain well-defined PHBs will yield certain well-understood services across the diff- serv network. We also expect that the intserv regions of the network will be able to extend these services such that they can be realized in a true end-to-end manner. 3.2 Allotment of Diff-serv Service Levels to Specific Traffic Flows It must be possible to allot specific end-to-end service levels to specific application traffic flows. Within the intserv regions of the network this is achieved by allowing applications to use RSVP to configure classifiers which operate on IP addresses and port numbers. We will refer to such classifiers from here on as 'MF' classifiers [10]. Within the diff-serv regions of the network, traffic is allotted service based on the contents of the DS-byte in packet headers. Therefore, it is necessary for QoS needy applications to effect the 3 Framework for End-to-End QoS March, 1998 correct marking of DS-bytes before their packets are submitted to the diff-serv network. There are two general mechanisms for doing so: 1. Hosts may directly mark DS-bytes in the transmitted packets of QoS needy applications. 2. Routers external to the diff-serv network may mark DS-bytes on behalf of QoS needy applications, based on MF classification. In the first case, marking will be done based on host configuration or local communication between QoS needy applications and the host operating system. In the second case, marking will be done based on manual configuration of the marking router's MF classifier/marker or standard signaling between QoS needy applications and the marking router's classifier/marker. The following three requirements argue either for host based marking or for dynamic configuration of a router's classifier/marker in response to application requests. 3.2.1 Minimal Management Burden The information required to express useful mappings of application traffic flows to service levels is likely to be quite complex and to change frequently. Thus, manual configuration is likely to impose a significant management burden. If the configuration information is very simple and does not change over time, the management burden may be relatively minor. However, this means that the granularity of allotting service levels to flows will be sub-optimal. 3.2.2 Granularity of Allotment The term 'granularity' is used here to refer to the degree of specificity that is available in allotting a specific service level to a specific traffic flow. There are two measures of granularity; one is the granularity with which an individual flow or a group of flows is identified. The other is the frequency at which the service allotted to a flow may change. A fine grain QoS system would allow the following requirement to be expressed: telephony traffic from user X should be allotted service level A, while telephony traffic from user Y should be allotted service level B, and web traffic from any user should be allotted service level C. A coarse grain system would be limited to something of the form: all traffic from subnet 1.0.0.0 should receive service level A, while all traffic from subnet 2.0.0.0 should receive service level B. A temporally fine grain system would allow immediate changes in allotment of service levels to traffic flows. A temporally coarse grain system may allow infrequent changes only. 3.2.3 Allocation of Service Level to Application Flows It must be possible to allot specific service levels to application traffic flows. Routers may not be able to readily identify these flows based on network and/or transport layer fields in a packet. 4 Framework for End-to-End QoS March, 1998 For example, consider the need to give preferential service to a website's home page (over other, less important pages at the site) or the case of encrypted traffic flows (IPSEC). 3.3 Admission Control Applications use RSVP to request that their flows be admitted to intserv regions of the network. When a request is rejected, the host application may avoid sending traffic and/or intermediate RSVP capable nodes will only give best-effort service to traffic on flows that were not admitted. These mechanisms protect traffic on flows that were admitted. In diff-serv regions of the network, admission control is provided implicitly, by policing at ingress points. The problem with implicit admission control is that it breaks the end-to-end validity of explicit admission control. Specifically, an application may gain admission using RSVP signaling, even though there is no capacity for that application's traffic within the diff-serv region of the network. Neither the application, nor intermediate RSVP capable nodes will be aware that the application's traffic is not admissible. As a result, neither can take corrective action and all traffic from that customer, at the corresponding service level, may be compromised. This failure may be partially, but not completely alleviated by policing based on MF classification at the diff-serv ingress (rather than BA classification [10]). End-to-end QoS requires that applications and RSVP capable intserv nodes be explicitly informed of admission control failure in the diff-serv network. This enables them to take corrective action and to avoid overdriving the diff-serv network. If the service agreement between the intserv and diff-serv regions of the network is statically provisioned, then admission control functionality can be provided by static configuration of admission control in intserv edge routers. However, if the service agreement is dynamically variable, then it will be necessary to dynamically propagate current diff-serv resource availability to the intserv network for the purpose of explicit admission control. 3.4 Policy Support End-to-end QoS leads to preferential treatment of certain traffic flows over others. Within diff-serv regions of the network, policy applies on a per-customer basis. In general, the diff-serv network makes multiple service levels available to a single customer's intserv network. In this case the customer must apply policy within its network to assure appropriate allocation of resources (customer network resources as well as diff-serv network resources) to individual hosts in the customer's network. This requires that end- to-end admission control be based on policy as well as resource availability. 4.0 Intserv as a Customer of Diff-serv 5 Framework for End-to-End QoS March, 1998 To meet the above requirements, we propose a network that consists of relatively small intserv capable stub networks, connected by larger, diff-serv capable transit networks. In this section, we will describe the operation of one instantiation of such a network (see figure 1). The following assumptions apply: 4.0.1 Host Capabilities Both sending and receiving hosts use RSVP to communicate QoS requirements of certain QoS aware applications running on the host. A QoS process within the host operating system generates RSVP signaling on behalf of the applications. This process also invokes traffic control. Host traffic control includes marking the DS-byte in transmitted packets and shaping transmitted traffic per token bucket specifications. Note that host traffic control is assumed for this specific example, but is not a requirement of the framework in general. Leaf routers within the intserv network may provide the traffic control functions. 4.0.2 Edge Routers The edge routers are special routers that straddle the boundary between the RSVP/Intserv region of the network and the diff-serv region of the network. It is helpful to think of these routers as consisting of two halves; the standard RSVP half, which interfaces to the stub networks, and the diff-serv half, which interfaces to the transit network. The RSVP half is at least partially RSVP capable; it is able to process PATH and RESV messages but it is not necessarily required to store full RSVP state and it is not required to provide MF classification. The diff-serv half of the router provides the interface to the admission control function for the diff-serv network. We shall refer to this function from here on as the 'DACS' (diff-serv admission control service). The DACS is a process that is likely to (but is not required to) run at least partially, on the routers. If the service agreement between the stub networks and the transit networks is statically provisioned then the DACS can be as simple as a table which specifies capacity at each service level. If the service agreement is dynamic, the DACS may communicate with counterparts within the diff-serv network (such as a bandwidth broker [4]) and may be able to make admission control decisions based on provisioned limits as well as the topology and the capacity of the diff-serv network. 4.0.3 Boundary Routers These are conventional boundary routers. In the example illustrated, they are not required to run RSVP. They are expected to implement the policing function of diff-serv ingress routers, based on the results of a BA classifier. They may, but are not required, to 6 Framework for End-to-End QoS March, 1998 provide MF classification nor to mark the DS-byte (with the possible exception of the in/out bit). [10, 8] Note that this example places the boundary between the RSVP/Intserv network and the diff-serv network, within the edge routers at the stub networks. In general, this boundary could be shifted to the left or to the right. It could for example, be placed within the boundary routers in the transit network. In this case, the DACS is implemented entirely within the diff-serv network (and is essentially, the bandwidth broker proposed in [4]), but the diff- serv boundary routers must be RSVP capable. 4.0.4 Stub Networks The stub networks consist of RSVP capable hosts and some number of leaf routers. Leaf routers within the stub networks may or may not be RSVP capable. Since they are relatively small networks, it is reasonable to assume that they are RSVP capable, but this is not necessary. If they are not RSVP capable, we assume that they will pass RSVP messages unhindered. 4.0.5 Transit Network The transit network is not RSVP capable. It provides two or more levels of service based on the DS-bytes in the headers of carried packets (diff-serv capable). Furthermore, the transit network is able to carry RSVP messages transparently, with minimal or no impact on its performance (see [8]). The transit network may include multiple carrier networks. 4.0.6 Carrier/Customer Agreement The customer (owner(s) of the leaf networks) and the carrier owning the transit network have negotiated a contract for the capacity to be provided at each of a number of standard diff-serv service levels. The capacity may be statically provisioned. In this case, the DACSs are statically configured with the capacity available at each service level and reside entirely within the edge routers. Alternatively, the capacity may be dynamically variable with a pre- negotiated usage fee and/or a pre-negotiated capacity limit. In this case, the DACS would be required to communicate with counterparts within the diff-serv transit network. 4.0.7 Mapping from Intserv Service Type to DS-Byte The current Intserv service types (controlled load and guaranteed) may or may not be practical in the diff-serv network. We assume that a set of end-to-end services that is practical is defined based on concatenation of PHBs (such as proposed in [10]) and that unique code points are allocated for each service in the service type field of the Intserv flowspec. We assume further that there is some standard coding of PHBs in a sub-field of the DS-byte. 7 Framework for End-to-End QoS March, 1998 It follows from the previous two assumptions, that there is a mapping from intserv service type to a sub-field of the DS-byte. Note that there is precedent for the notion of mapping intserv service types to per-packet priority values, specifically in the mapping of service types to 802.1p described in [5]. 4.1 How End-to-End QoS is Obtained The following sequence illustrates the process by which an application obtains end-to-end QoS: 1. The sending host's QoS process generates an RSVP PATH message, describing the traffic offered by the sending application. 2. The PATH message is carried toward the receiving host. In the sending stub network, standard RSVP processing will be applied at RSVP capable nodes (routers, SBMs, etc). 3. At 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 transit network. 4. The PATH message is carried transparently through the transit network. It is processed in the receiving stub network according to standard RSVP processing rules. 5. At the receiving host, the QoS process generates an RSVP RESV message, indicating interest in the offered traffic, at a certain intserv service level. 6. The RESV message is carried back towards the sending host. Consistent with standard RSVP processing, it may be rejected at any RSVP node in the receiving stub network if resources are deemed insufficient to carry the traffic requested. 7. At ER2, the RESV message is subjected to standard RSVP 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 transit network, arriving at ER1. 8. At this point, the RESV message triggers DACS processing. The DACS compares the resources requested to the resources available at the corresponding diff-serv service level, in the diff-serv enabled transit network. If the RESV message is admitted, the DACS updates the available capacity for the service class, by subtracting the approved resources from the available capacity. 9. Assuming the available capacity is sufficient, the RESV message is admitted and is allowed to continue upstream towards the sending host. If the available capacity is insufficient, the RESV message will be rejected. 8 Framework for End-to-End QoS March, 1998 10. The RESV message proceeds through the sending stub network. RSVP nodes in the sending stub network may reject it. If it is not rejected, it will arrive at the sending host. 11. At the sending host, the QoS process receives the RESV message. It interprets receipt of the message as an indication that the specified traffic has been admitted for the specified intserv service type (in the RSVP enabled regions of the network) and for the corresponding diff-serv service level (in the diff-serv enabled regions of the network). It begins to set the DS-byte in the headers of transmitted packets, to the value which maps to the Intserv service type specified in the admitted RESV message. In this manner, we are able to obtain end to end QoS through a combination of networks that support RSVP style reservations and networks that support diff-serv style prioritization. The successful arrival of RESV messages at the original sender indicates that admission control has succeeded both in the RSVP regions of the network and in the diff-serv regions of the network. 4.2 Variations of the Model It is useful to consider a number of variations of the model presented. 4.2.1 Admission Control 4.2.1.1 Statically Provisioned Service Agreements In the simplest model, service agreements are negotiated statically between the stub networks and the transit networks. A service agreement consists of a table of capacities available to a customer's stub network, at each diff-serv service level. In this case, DACS functionality is provided at the edge routers in the stub networks. The 'diff-serv half' of these routers appear to the 'RSVP half' as a sending interface with resource limits defined by the service agreement table. While there may be bandwidth brokers and dynamic provisioning within the transit networks, these are not coupled with the intserv stub networks and admission control in the two regions of the network is completely independent. 4.2.1.2 Dynamic Service Agreements In a more sophisticated model, service agreements between customer stub networks and carrier transit networks are more dynamic. Customers may be able to dynamically request changes to the service agreement. In this case, a statically provisioned edge router cannot provide the required DACS functionality. Instead, DACS functionality must be provided by coupling the stub network's admission control with the transit network's admission control. The two admission control mechanisms meet at the boundary between the diff-serv network and the intserv network. This boundary may be 9 Framework for End-to-End QoS March, 1998 implemented at the edge router (in the stub network) or at the boundary router (in the transit network). 4.2.1.3 Limiting the Impact of Intserv Admission Control on the Diff- serv Network Note that coupling intserv and diff-serv admission control does not imply that each intserv admission control request results in diff- serv admission control work. Instead, intserv admission control requests are aggregated at the boundary between the intserv and the diff-serv network. For example, intserv admission control requests may trigger diff-serv admission control requests to bandwidth brokers only when some high-water or low-water resource threshold is crossed. Separate high-water and low-water thresholds provide hysteresis to prevent thrashing. 4.2.1.4 Roles of Policy and Resource Based Admission Control It is necessary to provide both resource and policy based admission control in the diff-serv network as well as the intserv network. In the diff-serv network, resource and policy based admission control are handled by entities such as bandwidth brokers and reflected to the intserv network as DACS (or RSVP). Policy decisions made within the diff-serv network are likely to be at the per-intserv network (per-customer of the diff-serv network) granularity. In the intserv network, resource based admission control is handled by RSVP enabled routers (and SBMs). Policy based admission control is handled by RSVP capable policy servers. These assure that intserv resources are allotted to intserv customers according to policy specific to the intserv network. In addition, policy servers within the intserv network must also assure that appropriate policy is applied when diff-serv resources are allotted to intserv customers. 4.2.2 Setting the DS-Byte at Intermediate Nodes In the example described, hosts use RSVP signaling and mark the DS- byte corresponding to the admitted service level. Note that these functions can be separated. In the example, the function of RSVP signaling is to invoke QoS in the intserv network and to provide end-to-end admission control. The function of marking the DS-byte is to eliminate the need for MF classification at routers. It is possible to mark the DS-byte at intermediate routers rather than at the host and still to realize many of the benefits of our approach. In this case, intermediate routers may use the RSVP signaling to configure an MF classifier and marker. Therefore, the configuration of MF classifiers and markers is dynamic (minimizing the management burden) and full resource and policy based admission control can be applied. The disadvantages of marking the DS-byte at intermediate routers (instead of the host) are that full MF classifiers are required at 10 Framework for End-to-End QoS March, 1998 the intermediate nodes and that responsibility for traffic separation is shifted away from the host. Nonetheless, this approach is necessary to support those hosts which may be capable of RSVP signaling, but which are not capable of marking the DS-byte. In addition, there may be cases in which the network administrators wish to shift the responsibility for traffic separation away from the hosts. 4.2.3 Supporting Various Levels of Host Functionality We identify four levels of host functionality, as follows: 1. Legacy hosts, incapable of any form of QoS signaling. 2. Hosts capable of RSVP signaling but not of marking DS-bytes. 3. Hosts capable of marking DS-bytes but not of RSVP signaling. 4. Hosts capable of both RSVP signaling and marking DS-bytes. Hosts providing any of the above levels of functionality can co- exist in our model. However, the advantages of the model may not be fully realizable with certain combinations. In the following paragraph, we consider as an example, the coexistence of legacy hosts and of hosts that are capable both of RSVP signaling and of marking DS-bytes. When legacy hosts are required to coexist with hosts that are capable both of RSVP signaling and of marking DS-bytes, stub network administrators partition stub network resources between the two types of hosts. Legacy hosts rely on a router to mark DS-bytes based on the output of a statically configured MF classifier. This router could reside within the stub network or alternatively, the edge or boundary router could be configured to provide this functionality. A policer is also required at this router. The policer is statically configured to limit the consumption of diff-serv resources by the legacy hosts. The network administrator statically allocates the remaining diff-serv resources to the hosts that are capable of RSVP signaling by configuring the appropriate limits in the intserv enabled region of the stub network. We see that support for legacy hosts requires both MF classification and marking in intermediate routers as well as static allocation of resources by the network administrator. Hosts that are capable of marking the DS-byte eliminate the need for intermediate routers to provide MF classification. Hosts that are capable of signaling RSVP (and which use the result of this signaling to control transmission to the network), alleviate the need for static configuration as a form of admission control. 4.3 Issues 4.3.1 Setting the DS-Byte at Hosts The thought of allowing hosts to set the DS-byte directly, may alarm network administrators. The obvious concern is that hosts may 11 Framework for End-to-End QoS March, 1998 attempt to 'steal' resources. In fact, hosts may attempt to exceed the negotiated capacity at a particular service level regardless of whether they invoke this service level directly (by setting the DS- byte) or indirectly (by submitting traffic that classifies in an intermediate router to a particular diff-serv PHB). In either case, it may be necessary to protect the network by policing at various points, both within the stub network and/or at the interface to the transit network. This assures that customers do not use more resources than they are entitled to, at each service level. If the sending host does not do the marking, intermeidate and/or boundary routers must provide MF classification, mark and police. If the sending host does do the marking, these routers need only to provide BA classification and to police to ensure that the customer is not exceeding the aggregate capacity negotiated for the service level. Requiring hosts to mark the DS-byte has the effect of moving responsibility to the edge of the network, in more ways than one. With this approach, boundary routers police in aggregate. As a result, the customer cannot rely on boundary routers to provide traffic isolation between the customer's flows, when policing or shaping. Instead, it is the customer's responsibility to ensure that the customer's flows are properly shaped within the customer's sending network. Ideally, hosts should provide per-flow shaping at their sending interfaces. However, there is always a chance that the customer's traffic will become distorted as it nears the boundary between the customer and the carrier. In this case, the customer may chose to provide per flow policing (or even re-shaping) at the egress point from the customer's network. In summary, the security concerns of marking the DS-byte at the edge of the network can be dismissed since each carrier will have to police at their boundary anyway. Furthermore, this approach reduces the granularity at which boundary routers must police, thereby pushing finer grain shaping and policing responsibility to the edges of the network, where it scales better. The carriers are thus focused on the task of protecting their transit networks, while the customers are focused on the task of shaping and policing their own traffic to be in compliance with their negotiated token bucket parameters. 4.3.2 In/Out Bits Diff-serv proposals call for the DS-byte to be used to indicate a PHB, as well as whether a particular packet is 'in' or 'out' of profile. In our proposal, we recommend that hosts set at least the bits that indicate the PHB. This does not preclude hosts from setting the in/out bit as well. For example, hosts with sophisticated traffic shaping features may allow applications to occasionally burst beyond the negotiated token bucket parameters and may apply their own policing by marking excess packets as 'out'. 12 Framework for End-to-End QoS March, 1998 This does not compromise the transit network, since it will be policing and may remark the in/out bit. 4.3.3 End-to-End Integrity of the DS-Byte Our proposal assumes that hosts use a standard coding for specifying a desired PHB in some sub-field of the DS-byte. It also assumes that packets submitted to the network with a certain PHB specified, will receive a standard service throughout the diff-serv network. Strictly speaking, this does not dictate that the transit network must leave the PHB field intact. However, we see little value in allowing the PHB field to be altered within the network. This is likely to perpetuate local and incompatible interpretations of the field. 4.3.4 Carrying RSVP Messages across Transit Networks Our proposal presumes end-to-end RSVP both as a means for communication between sending host and receiving host and optionally, for the support of true RSVP reservations in stub networks (or in intermediate networks which are interested in the fine grain RSVP information). Therefore, we require that RSVP messages be carried across the transit networks. In [8] mechanisms are proposed for doing so in a manner that does not adversely impact the transit network. 5. Dependencies of Intserv on Diff-Serv We have described a framework for end-to-end QoS in which intserv networks are customers of diff-serv networks. We believe that the benefits of this framework are sufficient to justify the consideration of intserv dependencies as diff-serv work proceeds. In particular, we wish to draw attention to the following dependencies: 1. We expect that we can invoke a standard end-to-end (within the diff-serv network) service by specifying a standard code in a (PHB) sub-field of the DS-byte of a packet launched into a diff-serv network. 2. Diff-serv networks must provide admission control information to the intserv network. At the very least, this is through static service level agreements. Preferably, this is through a dynamic protocol. If the intserv to diff-serv boundary is implemented in the transit network boundary routers, then this protocol is RSVP. 3. We expect that diff-serv networks will carry RSVP messages such that they can be recovered at the egress point from the diff-serv network. 8. Security Considerations We are proposing that RSVP signaling be used to obtain resources in both the diff-serv and intserv regions of the 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. 13 Framework for End-to-End QoS March, 1998 9. 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] Clark, D. and Wroclawski, J., "An Approach to Service Allocation in the Internet", Internet Draft, July 1997 [10] Blake, S. and Nichols, K., "Differentiated Services Operational Model and Definitions", Internet Draft, February 1998 [11] Baker, F., "RSVP Cryptographic Authentication", Internet Draft, August 1997 [12] Braden, R., Clark, D. and Shenker, S., "Integrated Services in the Internet Architecture: an Overview", Internet RFC 1633, June 1994 10. Acknowledgments 11. Author's Addresses Yoram Bernet Microsoft One Microsoft Way, Redmond, WA 98052 Phone: (425) 936-9568 14 Framework for End-to-End QoS March, 1998 Email: yoramb@microsoft.com Raj Yavatkar Intel Corporation, JF3-206 2111 NE 25th. Avenue, Hillsboro, OR 97124 Phone: (503) 264-9077 Email: yavatkar@ibeam.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 UCLA 4531G Boelter Hall Los Angeles, CA 90095 Phone: (310_825-2695 Email: lixia@cs.ucla.edu 15