Differentiated Services Y. Bernet, Microsoft Internet Draft July, 1998 Document: draft-bernet-diffedge-00.txt Requirements of Diff-serv Boundary Routers 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 January 1999. Distribution of this draft is unlimited. 1. Abstract This draft discusses requirements of routers that serve as ingress points to diff-serv provider networks. We discuss the traffic conditioning components required and associated configuration mechanisms and protocols. We also discuss admission control to diff- serv networks in support of signaled QoS. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 3. Introduction Diff-serv is a mechanism by which network service providers can offer differing levels of network service to different traffic, in so providing quality of service (QoS) to their customers. The basic Bernet 1 Requirements of Diff-serv Boundary Routers July 1998 premise of diff-serv networks is that routers within the networks handle packets on different traffic flows by applying different per- hop behaviours (PHBs). The PHB to be applied is specified by a code in the IP header of each packet. The advantage of such a scheme is that many traffic flows can be aggregated to one of a small number of PHBs, thereby simplifying the processing and storage associated with packet classification. In addition, there is no signaling state or related processing required in the diff-serv network since QoS is invoked on a packet-by-packet basis. 4. Functional Components In order to support a diff-serv network, certain functionality is required from the boundary routers, which guard the ingress points to the diff-serv network. This functionality is discussed in the following sections. The following diagram illustrates the major functional blocks of a diff-serv boundary router: mgmt. ---------------- COPS, | diff-serv | <------>| provisioning |------------------------ SNMP,| | i/f | | etc. | ---------------- | | | | | | | | | | | | | data | ----------- | --------- ------------ ------->| inbound |------>|routing|------>| outbound |----> | | t/c | | --------- | t/c & phb| | ----------- | ------------ | ^ | ^ | | | | | ----------- | | -->| | | | ------->| RSVP |----------------------------- RSVP | | | cntl ----------- | msgs ^ | | ------------- ------- ---| diff-serv |<----->| TCA | | a/c | | | ------------- ------- 4.1 Interfaces, Traffic Conditioning and Routing Core Bernet 2 Requirements of Diff-serv Boundary Routers July 1998 An inbound interface, routing component and outbound interface are illustrated at the center of the diagram. In real routers, there may be an arbitrary number of inbound and outbound interfaces interconnected by the routing core. The components of interest on the interfaces are the traffic conditioning [1] components. These are primarily at the inbound interface but may include a shaper at the outbound interface. Certain queuing functionality, which determines the per-hop behaviour [1](PHB) of the router is generally implemented at the outbound interface. 4.2 Diff-serv Provisioning Interface Diff-serv operating parameters are provisioned through this interface. These are primarily traffic conditioning parameters. The diff-serv admission control component checks these parameters for admissibility subject to a traffic conditioning agreement (TCA) and the level of resources currently committed. The network administrator interacts with the diff-serv provisioning interface via one of a number of management protocols such as SNMP or COPS [2]. 4.3 RSVP The RSVP component includes standard RSVP protocol processing. It enables dynamic configuration of diff-serv traffic conditioning components in response to host initiated RSVP signaling and provides admission control feedback to the hosts. It interacts with the diff- serv admission control component in order to coordinate signaled resource requests with provisioned resource requests, subject to the constraints of the TCA and local resources. Note that diff-serv PHBs rather than RSVP dictate the actual packet forwarding behaviour in a diff-serv boundary router. 4.4 Traffic Conditioning Agreement (TCA) A service level agreement (SLA) represents the high-level agreement between the diff-serv service provider operating the boundary router and the customer(s) served by it. The TCA [1] is a subset of the SLA, which specifies detailed traffic conditioning parameters to be applied to the customer's traffic. In its simplest form, the TCA is a static set of tables. In more sophisticated routers, the TCA may be modified dynamically via signaling within the diff-serv network and between the diff-serv and customer network. 5. Traffic Conditioning Components Traffic conditioning is a fundamental component of a diff-serv router. It is defined in [1]. The diagram in the previous section illustrates the traffic conditioning components as an aggregate functionality distributed between the inbound and outbound interfaces of a diff-serv boundary router. The following paragraphs describe the traffic conditioning components in greater detail. Note that, with the exception of the shaper, all traffic conditioning Bernet 3 Requirements of Diff-serv Boundary Routers July 1998 components can be considered to reside at the inbound interfaces to the router. 5.1 Classification In order for the boundary router to treat traffic differentially it must be able to differentiate certain traffic from other traffic. This requirement dictates the minimal requirement of a boundary router; classification. There are differing degrees of classification functionality. At minimum, a boundary router must support behaviour-aggregate (BA) classification. In addition, routers may support varying degrees of multi-field (MF) classification. See definitions of Classifier, BA Classifier and MF Classifier in [1]. A boundary router that supports MF classification can offer significant functionality beyond that which can be offered by a boundary router which supports only BA classification. This functionality will be discussed further in a subsequent section. 5.2 Metering and Policing Boundary routers use classifiers to identify classes of traffic submitted for transmission through the diff-serv network. Once traffic is classified at the input to the router, traffic from each class is typically passed to a meter. The meter is used to measure the rate at which traffic of each class is being submitted. This rate can then be compared against a traffic profile that has been negotiated between the diff-serv provider and the diff-serv customer. Based on the results of the comparison, the meter deems particular packets to be conforming to the negotiated profile (in- profile) or non-conforming (out-of-profile). Appropriate policing actions are then applied to out-of-profile packets. See [1] for a definition of Meter and Policing. See [3] for a discussion of the metering model applicable to several diff-serv service types. Boundary routers should use meters and policers to protect the resources within the diff-serv network. These traffic-conditioning elements assure that customers cannot seize more than their fair share of resources within the diff-serv network. Forms of policing that may be used are: 1. Discarding out-of-profile packets. 2. Delaying out-of-profile packets until they become conforming (Shaping). 3. Demoting the traffic class of out-of-profile packets by marking appropriately (policer marking). 4. Charging for excess usage. 5.3 Marking Bernet 4 Requirements of Diff-serv Boundary Routers July 1998 Marking refers to setting the code in a packet's DS-field based on a set of rules. We recognize three types of marking: 1. Boundary Marking 2. Customer Marking 3. Policer Marking Routers are configured for one of two marking modes; customer marking or boundary marking. In addition, routers should always apply policer marking, regardless of the marking mode for which they are configured. 5.3.1 Boundary Marking In the case of boundary marking, the boundary router marks packets for a specific service level, as a service to the customer. This mode is generally employed when the customer is unable to mark packets submitted to the diff-serv network. A table is used to determine the DS-field code to be marked based on classification results. 5.3.2 Customer Marking In the case of customer marking, the customer is assumed to mark packets directly, before submission to the diff-serv network. 5.3.3 Policer Marking Regardless of the marking mode for which the boundary router is configured, it may have to re-mark packets that would otherwise receive a higher service level than that to which they are entitled. For example, assume that the agreement between customer and provider allows for 100 packets per second to be allotted the service level invoked by the DS-field code 100100. In the case of customer marking, the customer may submit 101 packets with this code in a single second. In order to protect its resources, the boundary router must select one packet to be discarded, or to delay the transmission of the 101st packet or to re-mark it for a lower service level. This re-marking is a form of policing (employed to protect the diff-serv network's resources) that may be negotiated as part of the service agreement between customer and provider and is known as policer marking. Even if boundary marking is employed, the marking table may cause the boundary router to mark 101 packets for code 100100 in a single second. In this case, the boundary router would either not mark the 101st packet for the code 100100, or would mark it for the code 100100 and would later re-mark it for a lower service level. The result is logically equivalent. Note that re-marking is always within the same PHB group (see [1]). 5.3.4 Classification Requirements Dictated by Marking Mode Bernet 5 Requirements of Diff-serv Boundary Routers July 1998 When boundary marking is employed, the boundary router is required to recognize certain packets based on multiple fields in the packet header (such as IP addresses and ports), and to set an appropriate value in the DS-field of the packet. This requires MF classification in the boundary router. A marking table is used to specify the appropriate mark based on the classification results. When customer marking is employed, only BA classification is required at the boundary router. In this case, the boundary router need only to track submitted packets for each DS-field value and to re-mark in the case that a packet marked for a specific DS-field value does not conform to the profile negotiated for the corresponding service level. MF classification is more costly (in terms of processing and state) than BA classification. Therefore, there is an advantage to customer marking, which avoids the need for MF classification in the router. In addition, customer marking allows the transmitting host to pre- mark non-conforming packets selectively. This is preferable to the boundary marking alternative in which the boundary router will select arbitrary packets for demotion as non-conforming. 5.3.5 The Marking Table As described above, when the boundary router is configured for boundary marking, a marking table is used to select the appropriate mark based on results of MF classification. This table takes the form of a mapping of classification fields to DS-field values. This is illustrated in the following example: IP Src Addr IP Dest Addr IP Src Port IP Dest Port DS-field ----------- ------------ ----------- ------------ -------- 1.2.X.X X.X.X.X X X 100110 1.3.X.X X.X.X.X X X 100111 X.X.X.X X.X.X.X 5000 5001 110000 Notes: 1. The above table presents conflicts. For example; Which DS-field should be marked for a packet with source IP address 1.2.3.4, source IP port 5000 and destination IP port 5001? The agreement between customer and provider must include rules for resolving such conflicts. 2. The example above is based solely on common IP header fields. Complex marking tables might define additional classification fields to be used in submitted packets. 5.4 Configurations of Logical Traffic Conditioning Components The following examples illustrate certain combinations of the traffic conditioning components described. Note that these illustrations are intended to represent logical combinations. The Bernet 6 Requirements of Diff-serv Boundary Routers July 1998 physical realizations of these combinations will vary from implementation to implementation. 5.4.1 Customer Marking Configuration The following diagram illustrates the traffic conditioning components of a boundary router configured for customer marking: --------- --------- --------- | | | | | | --->| |-->| |-->| |--> | | | | | | --------- --------- --------- BA Class. Meter Policer (opt. Re-marking) The BA classifier is used to determine the diff-serv service level requested, as indicated by the marking in the DS-field of each packet. The meter determines whether the packet is conforming per the profile negotiated for the requested service level. The policer handles non-conforming packets either by discarding, delaying or re- marking the packet for a lower service-level. This traffic conditioning configuration is suitable only in the case that it is dedicated to a single customer. This is because it classifies traffic using a BA classifier and therefore is able to discriminate traffic based on diff-serv service level only. In order to support multiple customers, it is necessary to discriminate traffic based on customer as well as service level. This requires an MF-classifier as shown in the following diagram: --------- --------- --------- | | | | | | |--->| |-->| |-->| |--> | | | | | | | | --------- --------- --------- --------- | | |-| BA Class. Meter Policer ----->| | (opt. Re-marking) | |-| --------- | --------- --------- --------- | | | | | | | |--->| |-->| |-->| |--> MF Class. | | | | | | --------- --------- --------- BA Class. Meter Policer (opt. Re-marking) Typically, an interface and its traffic conditioning components would be dedicated to a single customer, obviating the need for the Bernet 7 Requirements of Diff-serv Boundary Routers July 1998 MF classifier illustrated. Such a configuration is preferable since MF classification is more costly than BA classification. In the case that a single interface must be dedicated to multiple customers, an optimization to the illustrated configuration can be realized by inserting a BA classifier in advance of the MF classifier. This would identify all traffic marked for the default DS-field and allow it to bypass the costly MF classifier since it is not requesting preferential treatment. In many cases, the majority of traffic will be marked for the default DS-field. 5.4.2 Boundary Marking Configuration The following diagram illustrates the traffic conditioning components of a boundary router configured for boundary marking. --------- --------- --------- --------- --------- | | | | | | | | | | --->| |-->| |-->| |-->| |-->| |--> | | | | | | | | | | --------- --------- --------- --------- --------- MF Class. Marker BA Class. Meter Policer (opt. Re-marking) In this example, an MF classifier is used to determine which diff- serv service level a packet should be served at. The marker then marks the DS-field of the packet with the appropriate code for the service level. The operation of the classifier and marker is directed by the marking table described in section 5.3.5. Once the DS-field is marked based on the results of the MF classification, the packet is submitted for BA classification. From this point on, the packet is tracked based on the diff-serv service level for which it is targeted, as if the boundary router had been configured for customer marking. Per the illustration, a boundary router configured for boundary marking can logically be considered to concatenate the traffic conditioning components required for customer classification behind the MF classifier and marker required for boundary marking. In practical implementations, the initial marking based on MF classification will likely be combined with the remarking function of the policer. Similarly, the MF and BA classifiers will likely be combined. 5.4.3 Simultaneous Support for Customer and Boundary Marking We previously considered boundary routers to be configured either for boundary marking or customer marking. In practice, it may be useful to support both schemes simultaneously. For example, the diff-serv network provider may choose to support customers that have hosts that are capable and trusted to mark directly, as well as hosts that are not. The diff-serv provider can offer such mixed Bernet 8 Requirements of Diff-serv Boundary Routers July 1998 services either by requiring the customer to isolate hosts of each type behind a dedicated interface to the diff-serv network or by using the traffic conditioning configuration illustrated below. In this example, a full MF classifier is employed to determine which packets should be marked by the boundary router, and which should be left unmodified. This is logically illustrated by the following modification to the boundary marking traffic conditioner configuration: --------- --------- --------- --------- --------- | | | | | | | | | | --->| |-->| |-->| |-->| |-->| |--> | |-| | | ->| | | | | | --------- | --------- | --------- --------- --------- | | ------------- MF Class. Marker BA Class. Meter Policer (opt. Re-marking) Note the arrow connecting the output of the MF classifier to the input of the BA classifier (bypassing the marker). This represents processing of packets that are determined by the MF classifier to be pre-marked and trusted. 5.6 Boundary Shaping vs. Customer Shaping The TCA for certain diff-serv service levels specifies a quantitative profile to which traffic submitted for the service level must conform. In order to assure conformance, it is necessary for the traffic to be shaped to the profile. Ideally, shaping is applied on a per-flow basis, at each host (where it scales best). If the customer's hosts cannot be relied upon to shape, the customer may negotiate a TCA that calls for the provider to shape on behalf of the customer. This is a form of policing, referred to as boundary shaping. The TCA may call for aggregate boundary shaping or for per-flow boundary shaping. Aggregate boundary shaping is a specific method of implementing the aggregate policing which is necessary at boundary routers. It requires only BA classifiers. It does not provide any traffic separation for the customer. Per-flow boundary shaping may be offered as an additional service to the customer. It has the advantage of providing traffic separation for the customer, but requires an MF classifier and multiple shaping queues and will therefore be costly at the boundary router. As illustrated in the context of customer marking vs. boundary marking numerous configurations of traffic conditioning components can be used to support customer shaping vs. boundary shaping. 6. Configuration of Boundary Routers Bernet 9 Requirements of Diff-serv Boundary Routers July 1998 In the previous section we examined the traffic conditioning components which comprise the core diff-serv functionality of the boundary router. This section discusses configuration of the traffic conditioning components via the diff-serv provisioning interface and RSVP (see block diagram in section 4). 6.1 Configuration Information The following configuration information is required. 6.1.1 The Traffic Conditioning Agreement (TCA) The TCA is negotiated (either statically or dynamically) between the diff-serv provider and the customer. At minimum, the TCA defines traffic conditioning parameters on a per diff-serv service level granularity. This granularity reflects the fundamental nature of diff-serv service; the provision of resources at a limited number of service levels. Diff-serv providers may offer additional functionality in boundary routers to assist the customer in providing some degree of finer grain traffic isolation. This is also reflected in the TCA. Boundary marking is an example of such an additional service. As such, it is helpful to consider two subsets of the TCA. One is the subset of the TCA that defines the aggregate per service-level resources that are negotiated between provider and customer. We will refer to this subset informally as the constraint TCA. The other subset of the TCA defines finer grain traffic conditioning which may be provided to the customer as a value-add. We will refer to this subset as the fine-grain TCA. Information in the fine-grain TCA is subject to the constraints of the constraint TCA. The TCA includes at least a policing table and may optionally include a marking table, as described in the following sections. 6.1.2 Policing Table Policing is the mechanism by which diff-serv providers protect their network resources. By policing, the provider is effectively approving or denying instantaneous requests for resources at a particular service-level (as conveyed by the marking in each packet's DS-field). As such, a per-service policing table is a required part of the constraint TCA. Policing configuration information can be expressed as a table of entries having the following format: DS-field : Metering Profile : Disposition of non-conforming traffic The first column specifies the DS-field (in packet headers) to which the entry applies. The second column specifies the traffic profile Bernet 10 Requirements of Diff-serv Boundary Routers July 1998 against which packets with the corresponding DS-field should be measured. (In the case of a token bucket profile, the metering profile would specify, token rate, peak rate and bucket size). The third column specifies the action to be taken for packets that are deemed non-conforming to the profile. Actions typically include: shape to profile, discard, charge for excess usage, or demote to a lower, specified service class by re-marking the PHB. For PHBs that offer tight QoS assurances [4], it is generally necessary to limit these assurances to flows between the ingress boundary router and specific egress points from the diff-serv network. Therefore, a fourth column may be required for certain entries. This column would specify an egress subnet. Such an entry should be understood to assure the service level specified by the DS_field for traffic conforming to the profile and sent from the boundary router ingress point to the specified egress point. A diff-serv provider may offer fine-grain policing (especially in the form of shaping) services to a customer. In this case, a policing table similar to the one above would be incorporated as part of the fine-grain TCA and would be subject to the constraints of the constraint TCA. The first column of this policing table would specify MF-classification criteria rather than DS-field value. 6.1.1.1 Marking Table If boundary marking is to be provided, a marking table as described in section 5.3.5, is required. The marking table is used to configure MF classifiers and Markers. Since the marking table is generally used to effectively map fine- grain traffic flows into a small number of diff-serv service levels, it can be considered part of the fine-grain TCA. Note that marking amounts to generating requests for particular service levels. These requests are then approved or denied by a policer. As such, marking per-se is not subjected to the constraints of the constraint TCA. 6.1.3 PHB Configuration Information Diff-serv routers implement PHBs that are used to forward traffic of different service levels with differing behaviour. PHBs are generally implemented via queues and schedulers that reside at the router's outbound interfaces. There may be multiple configuration parameters required to configure PHBs. These are beyond the scope of this draft. Such parameters should be addressed as part of each PHB specification. 6.1.4 Additional Configuration Information A variety of miscellaneous configuration information is required for any router. Examples include routing information, media support, etc. Such information is beyond the scope of this draft. Bernet 11 Requirements of Diff-serv Boundary Routers July 1998 6.2 Configuration Mechanisms The following sections describe the mechanisms by which the above configuration information is installed in the boundary router. We are concerned primarily with the configuration of the marking table and policing information. A significant distinction is made between signaled configuration (RSVP) and provisioned configuration (all other mechanisms). 6.2.1 Installing the Constraint TCA The constraint TCA effectively specifies the resources that the provider is offering to the customer in the diff-serv network. The two parties must agree upon this part of the TCA since it commits resources on the one hand and incurs charges on the other hand. Since this part of the TCA requires negotiation between the two parties, it tends to be relatively static. Note that protocols between the provider and customer may be used to renegotiate the constraint TCA. This would allow the constraint TCA to be somewhat more dynamic. Static constraint TCAs may be installed into the boundary router via a user management interface or protocol. For example, the constraint TCA could be installed using SNMP or via vendor specific command line interfaces. Alternatively, COPS may be used to install the constraint TCA. Because it is targeted primarily at QoS management, COPS is better suited to support dynamic modifications to the constraint TCA. In either case, the constraint TCA is considered to convey provisioned configuration (as opposed to signaled configuration). 6.2.2 Configuring the Fine-Grain TCA The fine-grain TCA specifies how the customer allocates the resources it is paying for among its various traffic flows. The provisioning mechanisms used to install the constraint TCA (SNMP, COPS and command line interfaces) may also be used to install the fine-grain TCA. However, there are advantages to using a signaling mechanism to configure the fine-grain TCA. These are discussed below. The customer may wish to modify the fine grain TCA quite frequently. In addition, the customer can for the most part, be allowed to modify the fine-grain TCA without requiring the provider's approval. For example, the customer may wish to stop marking packets from subnet 1.X.X.X for a certain diff-serv service level and to start marking packets from subnet 2.X.X.X for that service level. The customer may wish to do so instantly and should not be required to obtain approval from the diff-serv provider to do so. To this end, Bernet 12 Requirements of Diff-serv Boundary Routers July 1998 the customer may use RSVP to modify the marking table that is part of the fine-grain TCA. Similarly, the customer may use RSVP to configure fine-grain policing information. For example, the customer may invoke per-flow packet shaping services from the boundary router (within a diff-serv service level) via RSVP signaling. Using RSVP to configure such information in the fine-grain TCA has the advantages of providing instant response to the customer, with reduced management burden to the provider. In addition, RSVP can be used to configure boundary routers to recognize IPSec [5] (or other) encrypted flows. Without RSVP, MF classifiers will not be able to recognize encrypted flows. Finally, RSVP offers a significant advantage by virtue of supporting admission control. Admission control support in boundary routers is discussed in the next section. 7. Support for RSVP Admission Control 7.1 Overview of RSVP and Diff-serv Interoperation As described in [4], diff-serv networks can be used to provide end- to-end QoS across large transit networks by supporting RSVP. This approach is of particular interest for a certain class of applications for which RSVP signaling is practical, including primarily multi-media applications. These applications generally: 1. Are able to quantify their QoS requirements 2. Require tighter QoS assurances than other applications 3. Operate between specific end-points The Intserv service-types that are used by RSVP are mapped to specific diff-serv PHBs [3,4]. Routers in diff-serv networks should support these PHBs. The concatenation of these PHBs along paths through diff-serv networks, combined with appropriate admission control at the boundaries will enable diff-serv services that can reasonably extend Intserv style QoS. 7.2 How Admission Control is Used Consider a diff-serv service that offers very low latency such as would be suitable for IP telephony. The EF PHB [6] is expected to provide such a service. Assume that a customer uses the diff-serv provider network to interconnect two customer networks. The customer has an SLA in place with the provider at each of the two boundaries. The TCAs offer 100 Kbps of EF service between the two attachment points. Now consider that the customer uses this service to carry voice over IP calls, each requiring a 16 Kbps flow. In order to obtain the low latency service, the customer (either by direct marking or by boundary marking) must mark voice over IP traffic for the appropriate diff-serv service level. At the same Bernet 13 Requirements of Diff-serv Boundary Routers July 1998 time, the customer must constrain the number of marked flows to six or fewer. A seventh flow will cause the customer to violate the TCA in place with the diff-serv provider. Provider policing may then arbitrarily compromise any traffic marked for the low latency service. Simple RSVP based admission control from the boundary router can prevent such over-subscription of the TCA by notifying the offending host that the seventh flow has failed admission control. In response, a properly behaving marking host will mark traffic on the seventh flow for a lower service level (as described in [4]). As a result, the six flows in place remain protected. Of course, the same mechanisms apply to applications other than voice over IP, for example - streaming video applications). Additional benefits of such admission control include: 1. The ability to admit traffic to the diff-serv network based on the approval of policy information carried in RSVP signaling networks. 2. The ability to coordinate reservation of resources in RSVP enabled regions of a network with acquisition of resources in diff-serv regions of a network. For example, consider an end-to- end path which originates and terminates at RSVP enabled campus networks interconnected by a diff-serv enabled transit network. It makes little sense to install reservations in the campus networks if the diff-serv network cannot support the necessary quality. Diff-serv admission control would avert this eventuality by rejecting the reservation request at the diff-serv boundary router. 3. Feedback to applications regarding the end-to-end admissibility of their resource request can be used to cause the applications to retry at a lower bandwidth or to invoke alternate adaptation mechanisms. 7.3 Implementing Diff-serv Admission Control in Boundary Routers Diff-serv admission control in boundary routers requires implementation of a subset of RSVP. In particular, the RSVP protocol state machine is required. The RSVP MF classification and scheduling mechanisms are not necessarily required. The local admission control functionality of standard RSVP routers [7] must be modified as described in the following paragraph. When a reservation request (RESV) arrives at a standard RSVP router, the router must verify admissibility of the reservation on its sending interface by querying traffic control for the interface. If the resources specified in the Intserv flowspec of the RESV message can be accommodated at the Intserv service level specified, then the reservation request is admitted, by allowing the RESV message to pass on to the sender. If the resources cannot be accommodated, then the request is rejected by blocking the RESV and returning an error message. Bernet 14 Requirements of Diff-serv Boundary Routers July 1998 In a diff-serv boundary router, a similar process is used. Upon receiving a reservation request from a receiver at a remote customer network, the boundary router must compare the request against the constraint TCA that is in place. The boundary router does so as follows: 1. First, the boundary router must find the TCA entries corresponding to the diff-serv egress point from which the reservation request originated. It uses routing information to do so. 2. Of the matching entries, the boundary router must find the single entry which applies to the DS-field mark which maps to the Intserv service type specified in the reservation request (see [3]). 3. The boundary router must then compare the resources requested in the Intserv flowspec against the profile permitted by the TCA entry. If the resources requested are less than the profile permitted by the constraint TCA entry, then the reservation can be admitted and the RESV message should be allowed to continue flowing upstream towards the sender in the customer's network. If the resources requested exceed those allowable by the profile in the constraint TCA entry, the boundary router should reject the RESV message by blocking it and by sending a rejection message towards the receiver [8]. The boundary router must maintain an accounting of resources allocated to admitted flows at each service level (and if necessary, to each egress subnet). This admission control procedure described is based on resource availability only. Boundary routers may also apply policy based admission control just as standard RSVP routers do. 7.4 Dynamic Constraint TCAs The admission control procedure described above assumes static constraint TCAs. In certain cases, protocols (such as the bandwidth broker protocol [9]) employed within the diff-serv network (and possibly between the diff-serv network and the customer network) may be used to renegotiate constraint TCAs. Such protocols can be used to dynamically adjust the constraint TCA. For example, a boundary router may maintain a high-water mark against which resources at a particular service level (and to a particular egress subnet) are tracked. The high-water mark would specify a resource level slightly lower than the limit specified by the profile in the constraint TCA. If the level of resources committed to a customer by diff-serv admission control reaches the high-water mark, the boundary router would use a protocol to negotiate a new profile for the appropriate constraint TCA entry. Similarly, a low-water mark would be defined and when the level of resources committed fell below the low-water mark, the profile would Bernet 15 Requirements of Diff-serv Boundary Routers July 1998 again be re-negotiated. Such a mechanism assumes that the SLA between the customer and the provider allows for re-negotiation of TCA entries as needed. 8. Intercepting or Ignoring RSVP Messages RSVP messages are generated with the IP router alert option. This causes the messages to be intercepted by routers, for RSVP processing. It is necessary for boundary routers at diff-serv ingress points to intercept RSVP messages for the purpose of applying admission control to the diff-serv network (as described above). Since routers internal to the diff-serv network are not required to apply RSVP processing, it is preferable, for performance reasons, that they are not alerted by the router alert option. Egress boundary routers need not apply RSVP processing for the purpose of supporting diff-serv admission control and so, are not required to respond to the router alert option on messages passing out of the diff-serv network. However, these routers should respond to the router alert option on RSVP messages passing in the opposite direction (since they are effectively ingress boundary routers for these messages). In addition, egress boundary routers may choose to implement standard RSVP processing (on their customer interfaces), in which case, they must respond to the router alert option on RSVP messages passing out of the diff-serv network. Since certain routers must intercept RSVP messages on certain interfaces and others would prefer not to, a mechanism is required to 'hide' these messages. Such a suggestion is described in [10] and is based on usage of the router alert option field. 8. Security Considerations Standard router security mechanisms should be used to restrict SNMP, COPS and command line configuration. Standard RSVP security mechanisms should be used to restrict configuration via RSVP. 9. References [1], Carson, M., Weiss, W., Blake, S., Wang, Z., Black, D., Davies, E., "An Architecture for Differentiated Services", Internet Draft, May 1998 [2], Herzog, S., Sastry, A., Rajan, R., Cohen, J., Boyle, J., Durham, D., "The COPS (Common Open Policy Service) Protocol", Internet Draft, March 1998 [3], Peter, F., Bernet, Y., "Integrated Services Over Differentiated Services", Internet Draft, March 1998 [4], Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Nichols, K., Speer, M., "A Framework for the Use of RSVP With Diff- serv Networks", Internet Draft, June, 1998 Bernet 16 Requirements of Diff-serv Boundary Routers July 1998 [5], Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol", Internet Draft, July 1998 [6], Nichols, K., Blake, S., "Differentiated Services Operational Model and Definitions", Internet Draft, February 1998 [7], Wroclawski, J., "The Use of RSVP With IETF Integrated Services", RFC 2210, September, 1997 [8], Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., "Resource Reservation Protocl, Version 1 Functional Specification", RFC 2205, Septemeber 1997 [9], Nichols, K., Jacobson, V., Zhang, L., "A Two-Bit Differentiated Services Architecture for the Internet", Internet Draft, November 1997 [10], Guerin, R., Blake, S., Herzog, S., "Aggregating RSVP Based QoS Requests", Internet Draft, November 1997 11. Author's Addresses Bernet, Yoram Microsoft One Microsoft Way Redmond, WA 98052 Phone: (425) 936-9568 E-mail: yoramb@microsoft.com Bernet 17