Differentiated Services Y. Bernet, Microsoft Internet Draft D. Durham, Intel Document: draft-bernet-diffedge-01.txt F. Reichmeyer, Bay November, 1998 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 ftp.ietf.org, 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 April 1999. Distribution of this draft is unlimited. Bernet 1 Requirements of Diff-serv Boundary Routers November 1998 1. Abstract........................................................3 2. Conventions used in this document...............................3 3. Introduction....................................................3 4. Functional Components...........................................4 4.1 Interfaces, Traffic Conditioning, PHBs and the Routing Core....5 4.2 Diff-serv Provisioning Interface...............................5 4.3 Monitoring.....................................................5 4.4 RSVP...........................................................5 4.5 Traffic Conditioning Agreements and PHB Capacity Tables........6 5. Traffic Conditioning............................................6 5.1 Classifiers....................................................6 5.2 Meters.........................................................7 5.3 Markers........................................................7 5.4 Shapers........................................................8 5.5 Droppers.......................................................8 5.6 Basic Configurations of Traffic Conditioning Components........8 5.7 Traffic Conditioning Configurations Supporting Value-Added Services..........................................................10 6. Configuration Information Required at Boundary Routers.........11 6.1 PHB Configuration Information.................................12 6.2 Traffic Conditioning Configuration Information................12 6.2.1 Elements of Traffic Conditioning Configuration Information..13 6.2.2 Customer Classification Information.........................13 6.2.3 The Traffic Conditioning Agreement (TCA)....................14 6.2.3.1 The Constraint TCA........................................14 6.2.3.2 Fine-Grain TCA............................................16 6.3 Relationship Among the CCI, Constraint TCA and Fine-Grain TCA.17 6.4 Additional Configuration Information..........................19 7. Configuration Mechanisms.......................................19 7.1 Installing PHB Configuration Information......................19 7.2 Installing the Constraint TCA.................................19 7.3 Installing the Fine-Grain TCA.................................20 8. Admission Control..............................................21 8.1 Reflection of PHB Configuration at Ingress Interfaces.........21 8.2 Admitting the Constraint TCA..................................22 8.3 Admitting the Fine-Grain TCA..................................23 8.4 Summing Profiles..............................................23 9. Support for RSVP Admission Control.............................24 9.1 Overview of RSVP and Diff-serv Interoperation.................24 9.2 Example of Admission Control to a Diff-serv Network...........24 9.3 Implementing RSVP Admission Control in Boundary Routers.......25 9.3.1 RSVP Reservations Expressed as Fine-Grain TCA Entries.......26 9.3.2 Modifying Marked DSCPs......................................26 9.3.3 RSVP and IP Security........................................26 10. Intercepting or Ignoring RSVP Messages........................26 8. Security Considerations........................................27 9. References.....................................................27 11. Author's Addresses............................................28 Appendix A. COPS-DS Constraint TCA PIB Format.....................29 Appendix B. COPS-DS Fine-Grain TCA PIB Format.....................30 Bernet 2 Requirements of Diff-serv Boundary Routers November 1998 1. Abstract This draft discusses requirements of routers that serve as ingress/egress points to/from differentiated services (diff-serv) 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 [DSARCH, DSFWK] 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 premise of diff-serv networks is that routers within the networks handle packets different traffic flows by applying different per-hop behaviours (PHBs). The PHB to be applied is specified by a code (the diff-serv code-point or DSCP) 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. In this draft, we discuss the requirements on diff-serv boundary routers. These are the routers that reside at the ingress or egress points to or from diff-serv networks (from here on referred to as diff-serv boundary routers). The requirements of these routers are generally a superset of the requirements of routers that reside in the core of the diff-serv network. This is because boundary routers must enforce the SLAs that are in effect at the network boundaries (in addition to providing the PHBs required in core routers). Note that although the requirement set for boundary routers is broader than that for core routers, the performance demands on core routers may be significantly greater than those on boundary routers. Specific performance requirements are not addressed in this draft. The purposes of this draft are: Bernet 3 Requirements of Diff-serv Boundary Routers November 1998 1. To establish baseline functionality for diff-serv boundary routers. 2. To provide a conceptual model for the general configuration information required at boundary routers. 3. To provide a structured model of the required traffic conditioning configuration information which is conveyed via COPS. 4. To discuss interactions of the boundary routers with various wire protocols, in particular COPS and RSVP [RFC2205]. 4. Functional Components In order to support a diff-serv network, certain functionality is required from the boundary routers, which reside at the ingress and egress points to and from 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: ------------ ---|monitoring| | ------------ | mgmt.| ---------------- COPS,| | diff-serv | <------>| provisioning |------------------------ SNMP,| | i/f | | etc. | ---------------- | | | | | | | | | | v | v data | ----------- | --------- ------------ ------->| inbound |------>|routing|------>| outbound |----> | | (TC) | | --------- | (PHB) | | ----------- | ------------ | ^ | ^ | | | | | ----------- | | -->| | | | ------->| RSVP |----------------------------- RSVP | | |--------------------- cntl ----------- | | msgs ^ v v | ------------- ------------- ---| diff-serv | | TCAs, PHB | | a/c | | capacity | ------------- | tables | ------------- Bernet 4 Requirements of Diff-serv Boundary Routers November 1998 4.1 Interfaces, Traffic Conditioning, PHBs and the Routing Core An inbound interface, routing component and outbound interface are illustrated at the center of the diagram. In actual router implementations, there may be an arbitrary number of inbound and outbound interfaces interconnected by the routing core. The components of interest on these interfaces are the traffic conditioning components (TC) and the PHB queuing implementations [DSARCH]. These are illustrated as residing at the inbound and outbound interfaces, respectively. However, this is a conceptual representation only and in general, these functions may each be distributed across both inbound and outbound interfaces. Conceptually, it is helpful to think of TC as a 'front-end' to the diff-serv network, which conditions traffic submitted by the customer and directs it, through the routing core, to the appropriate PHB on the egress interfaces of the boundary router and in subsequent hops in the diff-serv network. The combination of traffic conditioning (at ingress interfaces) and PHB treatment (at egress interfaces) results in a diff-serv service. 4.2 Diff-serv Provisioning Interface Diff-serv operating parameters are provisioned through this interface. These are primarily PHB and TC configuration parameters. The diff-serv admission control component can also verify these parameters do not conflict with other configuration parameters and the router's physical constraints, as described in subsequent sections. The network administrator interacts with the diff-serv provisioning interface via one of a number of management protocols such as SNMP or COPS [COPS]. 4.3 Monitoring A monitoring interface enables collection of statistics regarding traffic carried at various diff-serv service levels. These statistics are important for accounting purposes and for tracking compliance to service level agreements (SLAs [DSARCH]) negotiated with customers. Specifically, counter information on how many packets/bytes were transferred in-profile vs. out-of-profile would be useful on a customer-by-customer basis. This same information should be provided for the courser granularity DSCPs all the way down to the finer granularity flow-by-flow profiling where applicable. 4.4 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- Bernet 5 Requirements of Diff-serv Boundary Routers November 1998 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. The RSVP component is optional. However, the inclusion of this component provides the following benefits for traffic originating from quantitative applications (E2E): 1. Dynamic, closed loop and topology-aware admission control to the diff-serv network. 2. The ability to apply policy in determining which users or applications can access resources in the diff-serv network. 3. Significant reduction in management burden. 4. The ability to classify IPSec encrypted traffic that would otherwise be un-classifiable. 4.5 Traffic Conditioning Agreements and PHB Capacity Tables A service level agreement (SLA) [DSARCH] represents the high-level agreement between the diff-serv service provider operating the boundary router and the customer(s) served by it. The TCA is a subset of the SLA, which specifies detailed TC 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. We will see that the TCA has two sub-components, a constraint TCA and a fine-grain TCA. The former is essential, and is used to protect the resources of the diff-serv network. The latter may be used to specify value-added functionality offered by the diff-serv network. Since one TCA is installed for each customer on each ingress interface, there will typically be multiple TCAs on a single router. The network administrator configures PHB capacity tables based on the PHBs supported by the router, it's physical capacity and policies that determine the allocation of resources among the various PHBs. PHB capacity tables are configured for each interface. These will be described in detail in a subsequent section. 5. Traffic Conditioning TC is a fundamental component of a diff-serv boundary router. It is defined in [DSARCH]]. The following paragraphs describe the TC components and their functionality in greater detail. 5.1 Classifiers Strictly speaking, classification is not a TC function [DSARCH]; however, it is a necessary function for any device that treats Bernet 6 Requirements of Diff-serv Boundary Routers November 1998 certain traffic differently from other traffic. The very nature of a diff-serv boundary router is that it treats traffic differentially. Therefore, classification is the most basic function required from a differentiated service boundary router. 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 [DSARCH]. 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 Meters 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 is being submitted for each class. This rate is then compared against a traffic profile, which is part of the TCA. Based on the results of the comparison, the meter deems particular packets to be conforming to the profile or non- conforming. Appropriate policing actions are then applied to out-of- profile packets. 5.3 Markers Marking is the function of setting the DSCP in packets that are submitted to the router. Boundary routers are not required to provide marking functionality but may do so for the following reasons: 1. Marking can be used as a form of policing - the TCA between the provider and the customer may specify that packets submitted for a certain service level (as specified by the DSCP) and which are deemed to be non-conforming, may be re-marked to a lower service level. In this case, the marker is used for the purpose of re- marking. We refer to this as 'policer marking'. 2. Marking can be provided as a service to customers - customers may be unable or unwilling to mark the DSCP in submitted packets. In this case, a fine-grain TCA may call for the provider to mark the DSCP based on certain MF classification criteria. We refer to this service as 'provider marking'. Provider marking is a value-added service to the customer and is not required in order to provide basic differentiated service. Policer marking is used by the diff-serv provider to protect its network resources, but - simpler forms of policing (such as dropping) are Bernet 7 Requirements of Diff-serv Boundary Routers November 1998 sufficient to achieve the protection necessary. Therefore, marking is not a required function for boundary routers. 5.4 Shapers Shapers delay packets passing through the router such that they are brought into compliance with a traffic profile. Boundary routers are not required to provide shaping functionality, but may do so for the following reasons: 1. Ingress routers may use shaping as a form of policing - when submitted traffic is deemed non-conforming, it must be policed to protect the diff-serv network. One form of policing is to delay submitted traffic in a shaper until it conforms to the profile specified in the TCA. We will refer to this as 'policer shaping'. 2. Egress routers may shape behaviour aggregate traffic before it is submitted to a subsequent provider's network. This is a preventative measure that avoids policing action in the subsequent network. We refer to this form of shaping as 'egress shaping'. 3. Shaping for traffic isolation - Ingress routers may provide per- flow (as opposed to per-behaviour aggregate) shaping services as a value-add to customers (as specified in a fine-grain TCA). This service is costly in terms of processing requirements but may be valuable (to low functionality customers) in that it serves to protect customer's traffic flows from each other. We refer to this form of shaping as 'provider shaping'. 5.5 Droppers Droppers are used to discard non-conforming packets. This is the simplest form of policing that may be supported by ingress routers. 5.6 Basic Configurations of Traffic Conditioning Components The following sections illustrate various configurations of TC components on ingress interfaces. These components determine the PHBs that will be applied to subsets of submitted traffic after they are routed to the appropriate egress interfaces. PHBs and egress interfaces are not illustrated. DISCLAIMER: Note that these illustrations are provided for clarification of concepts and are not intended to depict specific implementations or implementation requirements. At minimum, an ingress router must police submitted traffic to the terms of the constraint TCA. Such a TCA may be represented as follows: DSCP Average Rate Service Level ------------------------------------------ 000001 10 Kbps Best 000010 100 Kbps Better Bernet 8 Requirements of Diff-serv Boundary Routers November 1998 This TCA indicates that traffic submitted with the DSCP 000001 will be accepted at a rate up to 10 Kbps and will be allotted the 'best' service level. Traffic submitted with DSCP 000010 will be accepted at a rate up to 100 Kbps and will be allotted the 'better' service level. While the TCA offers particular service levels, the underlying mechanism by which the service is provided is the PHB that is applied to the traffic at the egress interface to which it is routed. Hence the 'best' and 'better' services described each rely on an underlying PHB. The following configuration of TC components can be used to enforce the above TCA: ------- ------- | | | | |->| |->| |-> Best traffic ------- | | | | | | | | ------- ------- --->| |->| | | | ------- ------- ------- | | | | | BA Class. |->| |->| |-> Better traffic | | | | ------- ------- Meters Policers (Re-markers, Shapers or Droppers The BA classifier is used to separate traffic based on the diff-serv service level requested (as indicated by the DSCP in each submitted packet). Meters then determine whether the traffic submitted for each service level conforms to the corresponding average rate specified in the TCA. The policers handle non-conforming packets either by re-marking them for a lower service-level, delaying them in a shaper or dropping them. This configuration suffers certain limitations. Since it uses only a BA classifier, it is able to separate traffic based only on the DSCP in submitted packets. If traffic from multiple customers is submitted on the same interface, this configuration of TC components will be unable to separate traffic by customer. Since TCAs are specified on a per-customer basis, TC components will be unable to select the appropriate TCA to be applied. Furthermore, certain services may be offered only between the ingress boundary router and a specific egress point from the diff- serv network [DSFWK]. For such services, the TCA would include an egress point qualifier and TC components would be required to classify and to police based on egress point as well as DSCP. The configuration illustrated is unable to do so. Bernet 9 Requirements of Diff-serv Boundary Routers November 1998 MF classifiers can be incorporated to overcome the limitations identified. For example, in the following configuration, an MF classifier is used to separate traffic according to customer, before it is submitted for BA classification: ------- ------- | | | | |->| |->| |-> Customer A, Best ------- | | | | | | | | ------- ------- |->| |-| | | | | ------- ------- | ------- | | | | | | BA Class.|->| |->| |-> Customer A, Better ------- | | | | | | | | ------- ------- ->| |-| | | | ------- ------- ------- | | | | | MF Class.| |->| |->| |-> Customer B, Best | ------- | | | | | | | | | ------- ------- |->| |-| | | | ------- ------- ------- | | | | | BA Class.|->| |->| |-> Customer B, Better | | | | ------- ------- Meters Policers Similar configurations could be used to separate traffic based on egress point or other criteria dictated by the constraint TCA. MF classifiers are also required to provide value-added services as described in the following paragraphs. 5.7 Traffic Conditioning Configurations Supporting Value-Added Services More complex TC configurations can enable value-added services such as provider marking and provider shaping. The essence of these services is that the customer relies on the provider to apply per- flow processing to the customer's traffic. This requires the provider to classify beyond the minimum level of granularity necessary to protect the diff-serv network's resources. Such additional functionality is specified in a fine-grain TCA. The following configuration of TC components supports value-added services: ------- ------- ------- ------- | | | | | | | | Best |->| |->| |->| |->| |->| |-> ------- | | | | | | ------- | | | | | | | | ------- ------- | | | | ------- ------- ->| |-| Marker Policer |->| |-| Bernet 10 Requirements of Diff-serv Boundary Routers November 1998 | | | ------- ------- | | | | ------- ------- ------- | | | | | | ------- | | | | | Better MF Class.|->| |->| |->| BA Class.|->| |->| |-> | | | | | | | | | | | ------- ------- | ------- ------- | Marker Policer | Meters Policers | ------- ------- | (Re-markers, | | | | | | Shapers or |->| |->| |->| Droppers) | | | | | | | ------- ------- | | Marker Policer | | ------- ------- | | | | | | | |->| |->| |->| | | | | | | | ------- ------- | | Marker Policer | | . . | | . . | | . . | V V V V In this configuration, traffic is first directed to an MF classifier which classifies traffic based on miscellaneous classification criteria, to a granularity sufficient to identify individual customer flows. Each customer flow can then be marked for a specific DSCP and/or policed independently (a metering stage is implied). Typically, in this configuration, multiple customer flows would be marked with the same DSCP. In this example, all customer flows are aggregated into one of two DSCPs - that specifying the 'best' service or that specifying the 'better' service. Following the marking, flows are policed individually such that they are protected from each other and that the total traffic submitted for each DSCP does not exceed that specified by the constraint TCA. This configuration can be considered to consist of two logical halves; a front-end which provides per-flow services to the customer (MF classifier, per-flow markers and shapers) and a back-end which enforces the terms of the constraint TCA (BA classifier, per service level meters and policers). Notice that the back-end is equivalent to the minimal configuration illustrated previously. 6. Configuration Information Required at Boundary Routers This section describes the configuration information required at boundary routers. This information falls into the following general categories: 1. PHB configuration. 2. Traffic conditioning configuration. 3. Miscellaneous configuration. Bernet 11 Requirements of Diff-serv Boundary Routers November 1998 DISCLAIMER: In the following sections, we use tables to represent specific information that is necessary for the configuration of boundary routers. These tables are intended to describe the structure of required configuration information but not to dictate particular protocol formats, nor to dictate specific implementation mechanisms. For detailed protocol formats see appendices to this draft and [COPS]. 6.1 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 egress interfaces. There may be multiple configuration parameters required to configure PHBs. At minimum, PHB configuration must: 1. Enable or disable specific PHBs. 2. Provide the quantitative parameters associated with the PHB (e.g. relative weights for WFQ based PHBs). 3. Specify the total capacity admissible to each PHB on each egress interface. Capacity should be expressed in the same terms as the traffic profile [DSARCH] that applies to the PHB. This capacity will generally consider both physical interface capacities as well as policies. For example, PHBs which are implemented as strict priority queues should include limits on the volume of traffic which can be directed to the PHB in order to avoid starvation of traffic directed to other PHBs on the same interface. 4. In addition, network administrators must specify policies that indicate how the admissible capacity of qualitative PHBs (see [DSFWK] for a description of qualitative PHBs) on egress interfaces is reflected to each ingress interface. This is required for the purpose of applying admission control, and will be discussed further in the subsequent section on admission control. The capacities in 3 and 4 are specified in the form of a PHB capacity table. This table specifies capacities for quantitative PHBs on each egress interface and capacity for qualitative PHBs on each ingress interface. Note that certain PHB configuration parameters are required that are specific to each PHB. These are beyond the scope of this draft and should be addressed in detail in PHB specific drafts. 6.2 Traffic Conditioning Configuration Information As TC comprises a major function of diff-serv boundary routers, much of the required configuration information will be related to these components. For the purpose of this discussion, we consider TC configuration information to apply independently to each of the boundary router's Bernet 12 Requirements of Diff-serv Boundary Routers November 1998 ingress interfaces. The majority of TC configuration information required can be expressed via the TCA. The TCA is a per-customer entity. In cases in which an ingress interface is dedicated to a single customer, a single TCA is configured on each interface. On the other hand, in cases in which multiple customers are served via a single interface, multiple TCAs will be installed on the interface. In these cases, it is necessary to configure criteria by which the boundary router can classify submitted traffic to the customer from which it is submitted and the corresponding TCA. This requires configuration of 'customer classification information' (CCI). 6.2.1 Elements of Traffic Conditioning Configuration Information Before proceeding to describe the detailed configuration information, we define two elements of configuration information that will be referred to throughout the following paragraphs. These are: 1. Filters - these specify the classification criteria which classifiers use to classify submitted packets. BA filters are quite simple, specifying only a six-bit DSCP. MF filters may be arbitrarily complex, specifying multiple classification fields and corresponding masks. 2. Profiles - [DSARCH] defines a traffic profile as "a description of the temporal properties of a traffic stream such as rate and burst size". Though profiles may take many forms, a typical profile would consist of a set of token bucket parameters. These include expected average traffic rate, peak rate and the maximum burst size that can be expected at the peak rate. Individual PHB specifications (in PHB specific drafts) should describe the form of the profile which applies to each PHB. 6.2.2 Customer Classification Information This information enables a boundary router to correlate submitted traffic to a particular TCA for the purpose of applying TC. Customer classification information can be conveyed via a table of the following format: CCI TCA --- --- Filter01 TCA01 Filter02 Filter03 TCA02 Filter04 Filter05 Filter06 TCA03 In this table, the first column lists a set of filters that should be used as classification criteria to determine the customer from Bernet 13 Requirements of Diff-serv Boundary Routers November 1998 which a packet originates. The second column specifies the TCA that should be applied to traffic from that customer. In general, there may be multiple filters required to define a single customer's traffic. Typically, CCI filters will specify source subnet addresses as classification criteria. In the common case that an interface is dedicated to a customer, the table above degenerates to the following form: CCI TCA --- --- * TCA01 In this example, all traffic arriving on the interface is assumed to arrive from a single customer and to be subjected to TCA01. 6.2.3 The Traffic Conditioning Agreement (TCA) The TCA is a device specific result of the SLA negotiated (either statically or dynamically) between the diff-serv provider and the customer. There are two subsets of the TCA - the constraint TCA and the fine-grain TCA. The constraint TCA serves to protect the provider's resources at each diff-serv service level. This part of the TCA is required. The fine-grain TCA defines per-flow value-added functionality that the provider may offer to the customer. This part of the TCA is not required for the purpose of providing basic diff- serv service. Fine-grain TCAs are likely to be used only near the periphery of the network where the provider offers service to a stub network containing hosts. It is unlikely that fine-grain TCAs will be used at boundaries between providers (where enforcement of aggregate, per-service level resource usage is the primary concern). 6.2.3.1 The Constraint TCA Recall that the purpose of the constraint TCA is to protect resources in the provider's network by policing submitted traffic to the terms of the agreement between the provider and the customer. In its simplest form, the agreement offers to carry traffic at the service level requested by the customer (via the DSCP) up to a certain traffic profile. When quantitative services are offered, the agreement is slightly more complex. In this case, the agreement may be constrained by traffic egress point. For example, the provider might agree to carry traffic at a certain quantitative service level, up to a certain traffic profile, but only if the traffic is destined to a specific egress point. If the customer desires delivery at the same service level to another egress point, then an additional profile must be specified for that egress point. In this example, we effectively specify multiple 'service instances' at the same service level. When only qualitative services are offered, we see that it is sufficient to police a customer's traffic based only on the service Bernet 14 Requirements of Diff-serv Boundary Routers November 1998 level at which it will be carried. However, when quantitative services are offered, it may be necessary to police the customer's traffic separately for each 'service instance'. We will use the term 'service instance' from here on to refer to instances of service which must be separately policed in order to protect the provider's network. The constraint TCA can be represented as a table having the following format: BA Filter PHB MF Filter Profile Disposition --------- --- --------- ------- ----------- Filter01 EF EgressFilter01 Profile01 Discard Filter01 EF EgressFilter02 Profile02 Discard Filter02 AFxy * Profile03 Re-mark to 001001 Filter03 AFpq * Profile04 Shape to profile Each row in this table corresponds to a service instance provided to the customer. Note that the first two rows describe two service instances, at the same service level. The column titled 'BA Filter' specifies a DSCP. This is the classification criteria that should be used to determine the PHB (and the corresponding service level) that should be allotted to a submitted packet. The column titled 'PHB' specifies the PHB (and the corresponding service level) that should be applied to the submitted packet. As such, the first two columns effectively specify a mapping of DSCP to PHB. The column titled 'MF Filter' is relevant when the PHB corresponds to a quantitative service. In this case, it may be insufficient to police traffic based on service level alone because there may be multiple service instances at the same level. In this example, there are two instances of service at the same level, each to a different egress point. The additional classification criteria in this column specify how the provider should separate traffic for the two service instances. The column titled 'Profile' specifies the configuration of meters that are used to determine the conformance of traffic submitted for each service instance. All packets that meters find to be conforming to the specified profile are allotted the treatment specified by the PHBs. The column titled 'Disposition' specifies the disposition of packets that are found to be non-conforming to the metered profile. In this simple example, these packets are collectively discarded, demoted or shaped (as forms of policing). In more complex examples, multiple Bernet 15 Requirements of Diff-serv Boundary Routers November 1998 levels of non-conformance may be specified. In these cases, different dispositions may be specified for each degree of non- conformance. 6.2.3.2 Fine-Grain TCA Recall that the fine-grain TCA is used to provide value-add to the customer. Specifically, it enables the provider to process the customer's traffic based on classification criteria beyond those that are required to protect the provider's resources. Basically, the fine-grain TCAs are applied first to police and mark a customer's flows and then, based on the resulting marking, the appropriate aggregate constraint TCA will be applied as described above. At a minimum, the fine-grain TCA might be used to invoke provider marking of the customer's traffic. In order to mark customer's traffic differentially (and usefully), the provider must classify the traffic based on MF classification criteria such as source or destination IP addresses or ports. For example, MF filters may be defined to cause all traffic from IP subnet 2.3.4.0 to be marked with the DSCP 001001. In this example, traffic from multiple conversations, on multiple hosts, would be collectively marked with the specified DSCP. The fine-grain TCA could be used to specify additional functionality, requiring even finer-grain classification. For example, MF filters might be defined to separate traffic originating from each individual conversation (microflow [DSARCH]) in the customer's network. Traffic corresponding to multiple conversations of the same type may still be marked identically, however, the finer-grain classification would allow them to be policed or shaped separately. The fine grain TCA can be represented as a table having the following format: MF Filter DSCP Mark Profile Disposition --------- --------- ------- ----------- Filter01 001001 Profile01 Remark to DSCP 001000 Filter02 Filter03 001011 Profile02 Shape to profile Filter04 100100 Profile03 Discard Filter05 100100 Profile04 Discard In this example, the first entry specifies that two customer traffic flows should be marked for DSCP 001001. These flows together should be metered to Profile01. Packets from either set that do not conform to Profile01 should be remarked to DSCP 001000. The second entry specifies a third customer traffic flow. All packets belonging to this flow should be marked for DSCP 001011. Bernet 16 Requirements of Diff-serv Boundary Routers November 1998 These should be metered to Profile02. Packets belonging to this flow that do not conform to Profile02 should be delayed in a shaper until they do. The third and fourth entries specify two customer traffic flows that should be marked for DSCP 100100. Though packets belonging to both flows are marked for the same DSCP, they should be metered independently using Profile03 and Profile04. This protects these traffic flows from each other by preventing excess traffic from one flow compromising the treatment of traffic from the other flow. 6.3 Relationship Among the CCI, Constraint TCA and Fine-Grain TCA We've presented three types of tables that collectively specify the configuration of TC components. These are: 1. The customer classification table 2. The constraint TCA 3. The fine-grain TCA These are related to each other, as illustrated in the following diagram: Fine-Grain Constraint part part ------------------ |TCA0 ------- | | |SI 0 | | CCI | ------- | Table |------------------------->| |SI 1 | | | | ------- | | ------------------ | ---------------------------------------- ------- | | ------- TCA1 | |CU 0 |---| | |CF 0 | | ------- | ------- | ------- |--------------->|SI 2 | | --> |CU 1 |------->| |CF 1 | | ------- | ------- | ------- |----->|SI 3 | | |CU 2 |---| | |CF 2 | |---------| ------- | ------- | | ------- |--->|SI 4 | | | | |CF 3 | | | ------- | | | ------- | | | | | |CF 4 | | | | Bernet 17 Requirements of Diff-serv Boundary Routers November 1998 | | ------- |-----------| | | | |CF 5 | | | | | ------- | | | | |CF 6 | | | | | ------- | | ---------------------------------------- | ------------------ | |TCA2 ------- | | | |SI 5 | | | | ------- | |------------------------->| |SI 6 | | | ------- | ------------------ In this general example, three customers are served by the TC components on a single physical interface of a boundary router. Traffic received on the interface is separated according to the customer from which it originates, based on customer classification information (CU0, CU1 and CU2) in the CCI table. Customer 0 (CU0) implements all marking and fine-grain policing in the customer network. Therefore, no fine-grain TCA is necessary in the provider's network. The provider is required to apply only the constraint TCA. The constraint TCA for customer 0 defines two different service instances (SI0, SI1). Customer 1 (CU2) relies on the provider to apply certain fine-grain functionality on its behalf. A fine-grain TCA defines seven distinct sets of customer traffic each of which require special treatment in the boundary router. Such treatment may include marking, shaping, etc. Following the fine-grain TCA, the constraint TCA defines the aggregation of the fine-grain sets of customer traffic (CF0-CF6) into a smaller number of service instances. After the fine-grain TCA is applied, each packet is submitted to the constraint TCA with a specific DSCP mark. This DSCP mark is compared against the BA filter (and additional packet fields may be compared against the egress filter) in the constraint TCA, to define which service instance applies (SI2, SI3 or SI4). From the diagram, the first two customer traffic flows (CF0-CF1) are marked with the same DSCP, directing them to the same service instance in the constraint TCA (SI2). The third customer traffic flow (CF2) is marked with a DSCP that may or may not be the same as the previous flows. If it is the same, then this traffic is directed to a different service instance based on egress filter. The fourth through seventh customer traffic flows (CF3-CF6) are marked with the same DSCP. Again, this may or may not be the same DSCP as previous sets. Regardless, these are collectively directed to yet another service instance (SI3). Bernet 18 Requirements of Diff-serv Boundary Routers November 1998 Finally, traffic from CU3 is similar to that originating from CU0 in that it requires no fine-grain treatment at the boundary router. It is subjected directly to the corresponding constraint TCA where it is classified to a particular service instance (based on the DSCP and the classification criteria in the BA filter entries of the constraint TCA, and possibly based on egress filters as well). 6.4 Additional Configuration Information A variety of additional miscellaneous configuration information is required for any router. Examples include routing information, media support, etc. Such information is beyond the scope of this draft. 7. Configuration Mechanisms The following sections describe the mechanisms by which the above configuration information is installed in the boundary router. It is useful to consider a hierarchy of configuration information, starting with basic hardware configuration, which is very static and ending with the configuration of entries in the fine-grain TCA, which is quite dynamic. 7.1 Installing PHB Configuration Information PHBs are configured on each egress interface. Routers will generally provide support for limited groups of PHBs. Supported PHBs vary depending on media type, hardware support and software algorithms. Enabling a set of PHBs on each egress interface can be considered part of the router's basic hardware configuration. This aspect of PHB configuration is therefore very static and is likely to be applied as part of the router installation process. In addition to enabling PHBs, policies must be configured to determine how these PHBs make use of the interface capacity (via the PHB capacity table). Allocating interface capacity to various PHBs can be considered part of the diff-serv network provisioning. It should be possible to provision the network from a central management console. Therefore, it must be possible to configure the PHB capacity table remotely. This facility can be provided via telnet and CLI, SNMP, LDAP or COPS [COPS]. The mechanism used must be secure. In early deployments of diff-serv networks, re- provisioning is expected to occur infrequently and to require manual intervention. In the long term, this process will become more dynamic, requiring automated protocols. 7.2 Installing the Constraint TCA The constraint TCA effectively specifies the resources that the provider is offering to each customer in the diff-serv network. At the boundary router, it determines the allocation of resources provisioned at PHB configuration time, among the customers served by the router's ingress interfaces. Bernet 19 Requirements of Diff-serv Boundary Routers November 1998 Provider and customer 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 (yet more dynamic than the PHB configuration associated with network provisioning). Generally, configuration of constraint TCAs on a customer by customer basis occurs after the network has been provisioned via PHB configuration. However, to some degree these processes will be iterative. This, at certain times, changes in demand will require configuration of TCAs that cannot be installed without modifications to the basic network provisioning and PHB configuration. Typically, human agents for the provider and customer would negotiate a constraint TCA as part of an SLA. Following these negotiations, an administrator of the provider's network would configure the constraint TCA in the boundary router. This process would typically occur quite infrequently (for example, monthly). In the long term, this process is likely to become more dynamic and more automated. Ultimately, bandwidth brokers [BB] representing the provider's network and the customer's network will automatically and periodically re-negotiate the constraint TCA, based on such triggers as changes in usage patterns. Bandwidth brokers will then instruct policy servers to install the updated configuration information. In the more static example, network administrators will likely install constraint TCAs into the boundary router via a management console. A user management interface at the console may use any of a number of protocols to communicate with the router, such as telnet and CLI, SNMP, LDAP, COPS, etc. As configuration of the constraint TCA becomes more automated and more dynamic, inter-machine protocols will be used. Since COPS is targeted at dynamic QoS configuration, it is ideally suited for this purpose. By providing COPS interfaces for diff-serv configuration, routers will be able to support both near-in static configuration of diff-serv parameters as well as long-term dynamic configuration. Appendix A shows specifically how the constraint TCA is conveyed using the COPS for diff-serv protocol elements defined in [COPS]. 7.3 Installing the Fine-Grain TCA The provisioning mechanisms used to install the constraint TCA may also be used to install the fine-grain TCA. However, requirements surrounding configuration of the fine-grain TCA differ significantly from those surrounding configuration of the constraint TCA. These differences argue for use of a different mechanism, as described in the following paragraphs. First of all, configuration of the fine grain TCA is likely to be far more dynamic than that of the constraint TCA. Recall that the constraint TCA describes the aggregate requirements of the customer from the provider. Such aggregate requirements are relatively Bernet 20 Requirements of Diff-serv Boundary Routers November 1998 static. By comparison, the fine-grain TCA describes fine-grain servicing of individual customer flows, within the aggregate limits imposed by the constraint TCA. The requirements of such fine-grain service are likely to change quite frequently. For example, the customer may be using provider marking to direct traffic from certain IP addresses to different service instances, or to direct specific application traffic (identified by IP port) to different service instances. In these cases, changes in IP address assignments internal to the customer's network, or changes in ports used by applications will require frequent changes to the fine-grain TCA. Second, unlike the constraint TCA (which has financial consequences) the fine-grain TCA dictates only how the aggregate resources available to the customer are shared among the various customer flows. Thus, changes to the fine-grain TCA generally do not have financial consequences. These changes can more readily be automated. In conclusion, it is appropriate to use an automated mechanism to configure the fine-grain TCA, which supports frequent customer initiated changes with rapid response. To this end, boundary routers should support access to the fine-grain TCA via COPS. Appendix B shows specifically how the fine-grain TCA is conveyed using the COPS for diff-serv protocol elements defined in [COPS]. 8. Admission Control The configuration information discussed is interrelated by admission control. Admission control is the process of approving or denying specific configuration requests subject to the constraints of previous configuration. Requests to configure PHBs and associated capacities on each egress interface are admitted or rejected based on the basic hardware resources available on the egress interface. PHB capacities at egress interfaces dictate the amount of traffic that can be directed to each PHB at ingress interfaces. Therefore, requests to configure constraint TCAs at ingress interfaces are admitted or rejected subject to PHB configuration. Requests to configure fine-grain TCAs are in turn admitted or rejected subject to the constraint TCAs that have been installed. In this section we discuss these interdependencies. 8.1 Reflection of PHB Configuration at Ingress Interfaces PHBs are configured at egress interfaces. TCAs are configured at ingress interfaces. Since each service instance in a TCA consumes resources configured at egress interfaces, it is necessary to understand how these resources are reflected at the ingress interfaces. For quantitative services there is a well-defined relationship between capacities specified on PHBs at egress interfaces (in the Bernet 21 Requirements of Diff-serv Boundary Routers November 1998 PHB capacity table) and service instances configured at TCAs on ingress interfaces. This is because each quantitative service instance in a TCA specifies an egress filter. The router uses routing information to determine the egress interface to which traffic classified for a particular egress filter will be directed. Therefore, as quantitative service instances are configured at ingress interfaces, the appropriate amount of resources can be debited on the appropriate PHBs on egress interfaces. In the case that insufficient resources are available at an egress interface, the service instance must be rejected. For qualitative services however, there is no deterministic relationship between capacities at egress interfaces and service instances at ingress interfaces. Therefore, the network administrator must apply policy, (based on expected traffic routes within the router) to impose per service level capacity constraints (for qualitative services) at ingress interfaces. Such policy is configured as part of PHB configuration, at the time the network is provisioned. It may be modified subsequently as constraint TCAs are negotiated with customers. This policy is expressed by specifying limits on the traffic profiles admissible at each ingress interface for each qualitative PHB supported (in the PHB capacity table). Conservative policies would divide the resources available at the most constrained egress interface, among all ingress interfaces. Resources may be divided equally (if the network administrator has no knowledge of likely traffic patterns in the network), or may be divided unequally, based on expected traffic patterns. Liberal policies would over-subscribe the resources available at egress interfaces by allowing each ingress interface to admit more than its fraction of the egress capacity. In the case of liberal provisioning care must be exercised to prevent undesirable interactions among PHBs on oversubscribed egress interfaces. 8.2 Admitting the Constraint TCA The constraint TCA must be admitted subject to the resources made available by PHB configuration as specified in the PHB capacity table. At the time this part of the TCA is installed, the router is expected to apply admission control as follows: 1. All PHBs specified in the constraint TCA must be supported by the router and must have been previously configured. 2. Quantitative service instances consume resources for specific PHBs on specific egress interfaces (as determined by egress filters and routing information). The sum of profiles for all service instances consuming resources on a particular egress interface must not exceed the configured limits for the corresponding PHB in the PHB capacity table on the appropriate egress interface. Bernet 22 Requirements of Diff-serv Boundary Routers November 1998 3. Profiles associated with qualitative service instances (that do not specify egress filters) are also subject to admission control. These cannot be deterministically related to resources configured at egress interfaces. Therefore, the sum of profiles for all qualitative service instances must not exceed the configured limits for the corresponding PHBs in the PHB capacity table on the corresponding ingress interface. When COPS is used to configure the router, this process becomes somewhat more automated. The policy server (PDP) can directly verify that the constraint TCAs are supported by the device. This is possible given the device accurately describes its capabilities and its available resources per interface in its initial configuration request to the PDP. 8.3 Admitting the Fine-Grain TCA The fine-grain TCA may cause multiple sets of customer traffic to be marked for a specific DSCP and a specific service instance in the constraint TCA. The constraint TCA specifies a profile that limits the aggregate amount of traffic that can be serviced for each service instance. The sum of profiles in the fine-grain TCA, which are applied to traffic destined for the same service instance, should be less than the aggregate profile in the constraint TCA for that service instance. In the case of qualitative services, the following steps can easily verify this condition: 1. For each DSCP that the fine-grain TCA marks, sum the profiles for all sets of customer traffic to be marked with the DSCP. 2. Find the service instance in the constraint TCA that corresponds to this DSCP, as indicated by the BA filter in the constraint TCA. For qualitative services there will be only a single service instance specified for each DSCP. 3. The profile from the constraint TCA should be greater or equal to the sum of profiles for the corresponding DSCP in the fine-grain TCA. In the case of quantitative services, verification is slightly more complicated as it must account for egress point as well as service level indicated by the DSCP. In this case, there may be multiple service instances in the constraint TCA, for the same DSCP. Again, when COPS is used to configure the router, this process becomes somewhat more automated. The policy server (PDP) can directly verify what fine-grain TCAs are supported by the device. This is possible given the device accurately describes its capabilities in terms of MF classification and out-of-profile disposition in its initial configuration request to the PDP. 8.4 Summing Profiles The previous paragraphs on admission control mention the summing of profiles for each PHB. Different types of profiles will generally be Bernet 23 Requirements of Diff-serv Boundary Routers November 1998 subject to different summation rules. These should be described in the draft defining the PHB. 9. Support for RSVP Admission Control 9.1 Overview of RSVP and Diff-serv Interoperation As described in [E2E], diff-serv networks can be used to provide end-to-end QoS across large transit networks by supporting RSVP admission control at boundaries. This approach is of particular interest for quantitative applications [DSFWK], for which RSVP signaling is practical. To this end, Intserv service-types that are used by RSVP are mapped to specific diff-serv PHBs [MAPPING]. 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. Routers in diff-serv networks should support these PHBs. Boundary routers should also provide RSVP signaling for admission to diff-serv networks, as described below. 9.2 Example of Admission Control to a Diff-serv Network Consider a diff-serv service that offers very low latency such as would be suitable for IP telephony. The EF PHB [EF] can 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. A service instance in each TCA offers 100 Kbps of low latency service to the peer attachment point. Now consider that the customer uses this service to carry IP telephony calls, each requiring a 16 Kbps flow. In order to obtain the low latency service, the customer (either by direct marking in the host or via provider marking) must mark IP telephony traffic for the appropriate diff-serv service level. At the same time, it is in the customer's interest to 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 not mark traffic on the seventh flow for the low latency service level (as described in [E2E]). As a result, the six flows in place remain protected. Of course, the same mechanisms apply to applications other than IP telephony, for example - streaming video applications). Bernet 24 Requirements of Diff-serv Boundary Routers November 1998 Additional benefits of such admission control are described in detail in [E2E]. 9.3 Implementing RSVP Admission Control in Boundary Routers Support for such admission control in boundary routers requires implementation of a subset of RSVP. In particular, RSVP signaling is required. The RSVP MF classification and scheduling mechanisms are not necessarily required. The local admission control functionality of standard RSVP routers 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. In a diff-serv boundary router, a similar process is used. Upon receiving a RESV 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 quantitative service instances in the constraint TCA which correspond 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 PHB mark which maps to the Intserv service type specified in the reservation request (see [MAPPING]). 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. 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. Bernet 25 Requirements of Diff-serv Boundary Routers November 1998 9.3.1 RSVP Reservations Expressed as Fine-Grain TCA Entries Note that acceptance of a reservation request can be considered to have installed a virtual entry in the fine-grain TCA. The same admission control process applies as would apply when actual entries are configured in the fine grain TCA. The virtual entry would not necessarily call for provider marking or policing (though it may, especially in the case of hosts that support RSVP signaling but are not able to mark packets or shape traffic). The entry would specify a quantitative PHB (all PHBs which map to Intserv service types are quantitative). The MF filter for the entry would consist of a fully specified 5-tuple corresponding to the source and destination IP ports and addresses, as well as the IP protocol specified in the RSVP filterspec. The profile would correspond to that specified in the RSVP flowspec. Since COPS supports RSVP messaging as well, a PDP can be used to accurately provision and configure the necessary fine-grain TCAs. The process involves a single PDP that is handling COPS messaging for RSVP as well as COPS for DiffServ. When a COPS signaled RSVP request arrives at the PDP, the PDP can install the appropriate fine-grain TCA directly utilizing the homogenous management infrastructure. 9.3.2 Modifying Marked DSCPs To this point, we have assumed a well-known mapping of Intserv service type to PHB and DSCP. However, it may be desirable to override the well-known mapping in certain scenarios. Routers may do so by including a DCLASS object [MAPPING] in the RESV message forwarded to the sender of the data stream. This mechanism is analogous to use of the TCLASS object as described in [802MAP]. 9.3.3 RSVP and IP Security When IP Security (IPSec [IPSEC]) is used end-to-end between communicating hosts, RSVP may be the only mechanism which enables diff-serv networks to classify traffic to a granularity finer than IP addresses (such as per application, based on port numbers). Boundary routers can support classification of RSVP signaled IPSec encrypted flows by implementing RFC-2207 [RFC2207] and the corresponding classification logic. 10. 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 Bernet 26 Requirements of Diff-serv Boundary Routers November 1998 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 [AGGREG] 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. The major security threat to consider is denial of service attacks. Refer to the 'Security Considerations' section in [DSARCH] for a further discussion of this issue. 9. References [DSARCH], Carson, M., Weiss, W., Blake, S., Wang, Z., Black, D., Davies, E., "An Architecture for Differentiated Services", Internet Draft, October 1998 [DSFWK], Davies, E., Keshav, S., Verma, D., Carlson, M., Ohlman, B., Blake, S., Bernet, Y., Binder, J., Wang, Z., Weiss, W., "A Framework for Differentiated Services", Internet Draft, October 1998 [COPS], Reichmeyer, F., Chan, K., Durham, D., Yavatkar, R., Gai, S., McCloghrie, K., Herzog, S., "COPS Usage for Differentiated Services", Internet Draft, August 1998 [MAPPING], Peter, F., Bernet, Y., "Integrated Services Over Differentiated Services", Internet Draft, March 1998 [E2E], 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 [IPSEC], Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol", Internet Draft, July 1998 Bernet 27 Requirements of Diff-serv Boundary Routers November 1998 [BB], Nichols, K., Blake, S., "Differentiated Services Operational Model and Definitions", Internet Draft, February 1998 [EF], Jacobson, V., Nichols, K., Poduri, K., "An Expedited Forwarding PHB", Internet Draft, August 1998 [RFC2207] Berger, L., O' Malley, T., "RSVP Extensions for IPSec Data Flows", RFC 2207, September 1997 [RFC2205], Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., "Resource Reservation Protocl, Version 1 Functional Specification", RFC 2205, Septemeber 1997 [802MAP], Seaman, M., Smith, A., Crawley, E., Wroclawski, J., "Integrated Service Mappings on IEEE 802 Networks", Internet Draft, August 1998 [AGGREG], 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 Durham, David Intel Corp. 2111 N.E. 25th Ave. Hillsboro, OR 97124-5961 Phone: (503) 264-6232 E-mail: David.Durham@intel.com Francis Reichmeyer Bay Networks, Inc. 3 Federal Street Billerica, MA 01821 Phone: (978) 916-3352 E-mail: freichmeyer@BayNetworks.com Bernet 28 Requirements of Diff-serv Boundary Routers November 1998 Appendix A. COPS-DS Constraint TCA PIB Format TBD. Bernet 29 Requirements of Diff-serv Boundary Routers November 1998 Appendix B. COPS-DS Fine-Grain TCA PIB Format TBD. Bernet 30