INTERNET-DRAFT David Black Diffserv Working Group The Open Group Expires: November 1998 Steven Blake IBM Corporation Mark Carlson Redcape Software Elwyn Davies Nortel UK Zheng Wang Bell Labs Lucent Technologies Walter Weiss Lucent Technologies May 1998 An Architecture for Differentiated Services Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document defines an architecture for implementing scalable service differentiation in the Internet. This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field [DSFIELD]. Packets are classified and marked to receive a particular per-hop forwarding behavior on routers along their path. Sophisticated classification, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is conditioned upon entry to a differentiated services-capable network, and how that traffic is Black, et. al. Expires: November 1998 [Page 1] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 forwarded within that network. A wide variety of services can implemented on top of these building blocks. This document should be read along with its companion documents, the the differentiated services framework [DSFWK], the definition of the DS field [DSFIELD], and other documents which specify per-hop behaviors, such as [Baker]. 1. Introduction 1.1 Overview This document defines an architecture for implementing scalable service differentiation in the Internet. "Service" is taken to signify some significant characteristics of packet transmission across a set of one or more paths within a network. These characteristics may be specified in quantitative or statistical terms of throughput, delay, jitter, and/or loss, or may otherwise be specified in terms of some relative priority of access to network resources. Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing of Internet service. This architecture is composed of a number of functional elements implemented in network nodes, including a small set of well-defined per-hop forwarding behaviors, and traffic conditioning functions including classification, metering, marking, shaping, and policing. This architecture achieves scalability by implementing complex conditioning functions only at network edge nodes, and by applying per-hop behaviors to aggregates of traffic which have been appropriately marked using the DS field in the IPv4 or IPv6 headers [DSFIELD]. Per-hop behaviors are defined to permit a reasonably granular means of allocating buffer and bandwidth resources among competing traffic streams. Per-application flow or per-customer forwarding state need not be maintained within the core of the network. Service provisioning and traffic conditioning policies are sufficiently decoupled from the forwarding behaviors within the network interior to permit a wide variety of service behaviors to be implemented, with room for future expansion. Section 1.2 is a glossary of terms used within this document. Section 1.3 lists requirements for this architecture, and Section 1.4 provides a brief comparison to other approaches for service differentiation. Section 2 discusses the components of the architecture in detail. Section 3 proposes requirements for per-hop behavior specifications. Section 4 discusses interoperability issues with networks which do not implement differentiated services as defined in this document and [DSFIELD]. Section 5 discusses issues with multicast traffic (this section is currently left for future study). Section 6 addresses security and tunnel considerations. Black, et. al. Expires: November 1998 [Page 2] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 This document should be read along with its companion documents, the differentiated services framework [DSFWK], the definition of the DS field [DSFIELD], and other documents which specify per-hop behaviors, such as [Baker]. It has been heavily influenced by the thoughtful proposals of previous authors [Clark97, Ellesson, Ferguson, Heinanen, SIMA, 2BIT, Weiss]. 1.2 Terminology This section gives a general conceptual overview of the terms used in this document. Some of these terms are more precisely defined in later sections of this document. The choice of terms and definitions were influenced by [MPLSFWK]. Behavior Aggregate (BA) a DS behavior aggregate. BA classifier a classifier that selects packets based only on the contents of the DS-field. Such classifiers are used in DS interior nodes, and are typically used for policing at a DS ingress node. Boundary a link connecting the edge nodes of two domains. Classifier a logical element of traffic conditioning that selects packets based on the content of packet headers according to defined rules. Customer DS domain a DS domain that has an SLA in place with another directly attached DS domain (the provider DS domain) governing the rules by which traffic from the customer DS domain will be serviced within the provider DS domain. A single DS domain may be both a customer DS domain and a provider DS domain for different directions of traffic at the same time. Differentiated Services a paradigm for providing quality-of-service (DS) (QoS) in the Internet by employing a small, well-defined set of building blocks from which a variety of services may be built. DS behavior aggregate a stream of packets that have the same DS codepoint. DS field the IPv4 TOS octet or IPv6 Traffic Class octet when interpreted according to [DSFIELD]. Black, et. al. Expires: November 1998 [Page 3] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 DS capable able to support differentiated services functions and behaviors as defined in [DSFIELD], this document, and other documents. DS codepoint a specific bit-pattern of the DS field. DS edge node a DS node that connects one DS domain to a node either in another DS domain or in a domain that is not DS capable. DS egress node a DS edge node in its role in handling traffic as it leaves a DS domain. DS destination host a DS host that acts as a DS egress node. DS domain a contiguous set of nodes which operate with a common set of service provisioning policies and PHB definitions. DS host a host computer that can perform certain traffic conditioning functions and therefore acts as a special DS edge node. DS ingress node a DS edge node in its role in handling traffic as it enters a DS domain. DS interior node a DS node that is not a DS edge node. DS node a DS capable node. DS region a set of contiguous DS domains which can offer differentiated services over paths across those DS domains. DS source host a DS host that acts as a DS ingress node. Legacy node a node which implements IPv4 Precedence as defined in [RFC791] but which is otherwise not DS capable. Marker a logical element of traffic conditioning that sets the DS codepoint in the DS field based on defined rules. MF Classifier a classifier which selects packets based on the content of some arbitrary number of header fields; typically some combination of source address, destination address, protocol ID, source port and destination port. Black, et. al. Expires: November 1998 [Page 4] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 Mechanism a specific algorithm or operation (e.g., queueing discipline) that is implemented in a node to realize a set of one or more per- hop behaviors. Meter a logical element of traffic conditioning that measures the properties (e.g., rate) of a packet stream selected by a classifier. Microflow a single instance of an application-to- application flow of packets which is identified by source address, source port, destination address, destination port and protocol id. Per-Hop-Behavior (PHB) the externally observable forwarding behavior applied at a DS capable node to a DS behavior aggregate. PHB group a set of one or more PHBs that can only be meaningfully specified and implemented simultaneously, due to a common constraint applying to all PHBs in the set such as a packet scheduling or discard policy. Policing the process of applying traffic conditioning functions such as marking or discarding to a traffic stream in accordance with the state of a corresponding meter. Provider DS domain a DS domain that has an SLA in place with another directly attached DS domain (the customer DS domain) governing the rules by which traffic from the customer DS domain will be serviced within the provider DS domain. A single DS domain may be both a customer DS domain and a provider DS domain for different directions of traffic at the same time. Service the overall treatment of a defined subset of a customer's traffic within a DS domain or end-to-end. Service Level Agreement a service contract between a customer and a (SLA) service provider that specifies the details of a TCA and the corresponding service behavior a customer should receive. A customer may be a user organization or another DS domain. Black, et. al. Expires: November 1998 [Page 5] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 Service Provisioning a policy which defines how traffic Policy conditioners are configured on DS edge nodes and how traffic streams are mapped to DS behavior aggregates to achieve a range of service behaviors. Shaper a logical element of traffic conditioning that delays packets within a traffic stream to cause it to conform to some defined traffic properties. Traffic conditioner an entity that performs traffic conditioning and which may contain classifiers, markers, meters, and shapers. Traffic conditioning control functions performed to enforce rules specified in a TCA and to prepare traffic for differentiated services, including classifying, metering, marking, policing, and shaping. Traffic Conditioning an agreement specifying classifier rules Agreement (TCA) and the corresponding traffic profiles and metering, marking, policing and/or shaping rules which are to apply to the traffic streams selected by the classifier. Traffic profile a description of the expected properties of a traffic stream such as rate and burst size. Traffic stream an administratively significant set of one or more microflows which traverse a path segment. A traffic stream may consist of the set of active microflows which are selected by a particular classifier. 1.3 Requirements The history of the Internet has been continuous growth in the number of hosts, the number and variety of applications, and the capacity of the network infrastructure, and this growth is expected to continue for the foreseeable future. A scalable architecture for service differentiation must be able to accommodate this continued growth. The following requirements were identified and are addressed in this architecture: o must accommodate a wide variety of service behaviors and provisioning policies, extending end-to-end or within a particular (set of) network(s), Black, et. al. Expires: November 1998 [Page 6] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 o must allow decoupling of the service behavior from the particular application in use, o must work with existing applications (assuming suitable deployment of traffic conditioners), o must decouple traffic conditioning and service provisioning functions from forwarding behaviors implemented within the core network routers, o must not depend on hop-by-hop application signaling, o must require only a small set of forwarding behaviors whose implementation complexity does not dominate the cost of a network device, and which will not introduce bottlenecks for future high- speed system implementations, o must avoid per-microflow or per-customer state within core network routers, o must utilize only aggregated classification state within the network core, o must permit simple packet classification implementations in core network routers (BA classifier), o must permit reasonable interoperability with non-compliant network nodes, o must accommodate incremental deployment. 1.4 Comparisons with Other Approaches The differentiated services architecture specified in this document can be contrasted with other existing models of traffic management and service differentiation. We classify these alternative models into the following categories: relative priority, virtual circuit, Integrated Services/RSVP, and service marking. Implementations of the relative priority model include IPv4 Precedence marking as defined in [RFC791], 802.5 Token Ring priority [TR], and 802.1p priority [802.1p]. In this model the application, host, or proxy node selects a relative priority or "precedence" for a packet (e.g., delay or discard priority), and the network nodes along the transit path apply the appropriate priority forwarding behavior corresponding to the priority value within the packet's header. Our architecture can be considered as a refinement to this model, since we more clearly specify the role and importance of edge nodes and traffic conditioners, and since our per-hop behavior model permits more general forwarding behaviors than relative delay or discard priority. Black, et. al. Expires: November 1998 [Page 7] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 Implementations of the virtual circuit model include Frame Relay, ATM, and MPLS [FRELAY, ATM, PASTE]. In this model path forwarding state and traffic management or QoS state is established for traffic streams on each hop along a path. Traffic aggregates of varying granularity are associated with a virtual circuit, and packets/cells within each virtual circuit are marked with a forwarding label that is used to lookup the next hop, the per-hop forwarding behavior, and the replacement label at each hop. This model permits finer granularity resource allocation to traffic streams, but the amount of forwarding state scales linearly with the number of edges of the network in the best case (assuming multipoint-to-point virtual circuits), and it scales with the square of the number of edges in the worst case, when edge-edge traffic streams with provisioned resources are employed. The Integrated Services/RSVP model relies upon traditional datagram forwarding in the default case, but allows sources and receivers to exchange signaling messages which establish classification and forwarding state on each node along the path between them [IntServ, RSVP]. In the absence of state aggregation, the amount of state on each node scales in proportion to the ratio of the link rate to the average reservation size (in bps), multiplied by some fraction of the link rate which is "reservable". This model also requires application support for the RSVP signaling protocol. An example of a service marking model is IPv4 TOS as defined in [RFC1349]. In this example each packet is marked with a request for a "type of service", which may include "minimize delay", "maximize throughput", "maximize reliability", or "minimize cost". Network nodes may select routing paths or forwarding behaviors which are suitably provisioned to satisfy the service request. This model is subtly different from our architecture. The defined TOS markings are very generic and do not span the range of possible service semantics. Furthermore, the service request is associated with each individual packet, whereas some service semantics may depend on the aggregate forwarding behavior of a sequence of packets. The service marking model does not easily accommodate growth in the number and range of future services, and involves configuration of the "TOS->forwarding behavior" association in each core network router. 2. Differentiated Services Architectural Model The differentiated services architecture is based on a simple model where traffic entering a network is conditioned at the edges of the network, and assigned to different behavior aggregates. Each behavior aggregate is identified with a single DS codepoint. Within the core of the network, packets are forwarded according to the per- hop behavior associated with the DS codepoint. In this section, we discuss the key components in a differentiated services region, traffic conditioning functions, and how differentiated services are achieved through the combination of traffic conditioning and PHB- Black, et. al. Expires: November 1998 [Page 8] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 based forwarding. 2.1 Differentiated Services Regions A differentiated services region (DS Region) is a set of contiguous DS domains, where each DS domain consists of a set of edge nodes and interior nodes. 2.1.1 DS Domain A DS domain is a contiguous set of DS nodes which operate with a common service provisioning policy and set of PHB group definitions. A DS domain has a well-defined boundary consisting of DS edge nodes which condition ingress traffic and ensure that packets which transit the domain are only marked using one of the PHB groups supported in the domain. All nodes inside the DS domain select the forwarding behavior for packets based solely on the DS codepoint as defined for the PHB groups supported in the domain. Inclusion of non-DS capable nodes within a DS domain may result in unpredictable performance and may impede the ability to satisfy SLAs. A DS domain normally consists of one or more networks under the same administration, for example, an organization's intranet or an ISP. Multiple DS domains may be inter-connected through mutual agreements to form a DS region. DS domains in a DS region may implement different PHB groups. However, to permit services which span across the domains, the peering DS domains must each establish a peering SLA which includes a Traffic Conditioning Agreement (TCA) which specifies how transit traffic from one DS domain to another DS domain is conditioned at the boundary of the two DS domains. It is possible that several DS domains within a DS region may adopt a common service provisioning policy and PHB group definitions, thus eliminating the need for traffic conditioning between those DS domains. In such cases, those DS domains are effectively under a single administration and may be considered as a single DS domain. The administration of the domain is responsible for ensuring that adequate resources are provisioned and/or reserved to support the SLAs offered by the domain. 2.1.2 DS Edge Nodes and Interior Nodes A DS domain consists of DS edge nodes and DS interior nodes. While DS edge nodes connect the DS domain to other DS or non-DS domains, DS interior nodes only connect to other DS interior or edge nodes within the DS domain. Both DS edge nodes and interior nodes must be able to forward packets based on the DS codepoint as defined by the PHB groups supported in the domain; otherwise unpredictable behavior may result. In addition, Black, et. al. Expires: November 1998 [Page 9] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 DS edge nodes must be able to perform traffic conditioning functions as described by the TCA between their DS domain and the peering domain which they connect to. Interior nodes may be able to perform limited traffic conditioning functions such as DS codepoint mutation. A host within a DS domain may act as a DS edge node for traffic to and from applications running on that host. If a host is embedded in a DS domain and does not act as an edge node, then the host's first- hop router acts as the DS edge node for the host's traffic. 2.1.3 DS Ingress Node and Egress Node DS edge nodes may act both as a DS ingress node or as a DS egress node. Traffic enters a DS domain at a DS ingress node and leaves a DS domain at a DS egress node. A DS ingress node is responsible for ensuring that the traffic entering the DS domain conforms to the TCA between it and the other domain which the ingress node is connected to. A DS egress node may perform traffic conditioning functions on traffic forwarded to the peering domain, depending on the details of the TCA between two domains. 2.2 Traffic Conditioning Traffic conditioning functions are performed by DS edge nodes in a DS domain to ensure that the traffic entering a DS domain conforms to the rules specified in the TCA, in accordance with the domain's service provisioning policy, and to prepare the traffic for the PHB- based forwarding treatment in the interior routers. 2.2.1 General Architecture of Traffic Conditioners A traffic conditioner may contain the following elements: classifier, meter, marker, and shaper. The classifier and the meter select the packets within a traffic stream and measure the stream against a traffic profile. The marker and shaper perform control actions on the packets depending on whether the traffic stream is within its associated profile. A packet stream normally passes to a classifier first, and the matched packets are measured by a meter against the profile as defined in the TCA. The packets within the profile may leave the traffic conditioner or may be marked by the marker. The packets that are out-of-profile may be either marked or shaped according to the rules specified in the TCA. Note that discard policing can be performed by a specially configured shaper (see Sec. 2.2.3.4). When packets leave the traffic conditioner of a DS ingress node, the DS field of each packet must be set to one of DS codepoints defined by the PHB groups supported in the DS domain. Black, et. al. Expires: November 1998 [Page 10] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 Fig. 1 shows the block diagram of a traffic conditioner. Note that a traffic conditioner may not necessarily contain all four elements. For example, packets may pass from the classifier directly to the marker or shaper (null meter). +-------+ -->| |----> +-------+ +-------+ / +-------+ | | | |/ marker packets -----> | |------>| |--------------------> | | | |\ +-------+ +-------+ \ +-------+ classifier meter -->| |----> +-------+ shaper Fig. 1: Logical View of a Traffic Conditioner 2.2.2 Traffic Conditioning Agreement (TCA) Differentiated services are extended across a DS domain boundary by establishing a SLA between the customer and provider DS domains. The SLA includes a traffic conditioning agreement which usually specifies traffic profiles and actions to in-profile and out-of-profile packets. 2.2.2.1 Traffic Profiles A traffic profile specifies rules for classifying and measuring a traffic stream. It identifies what packets are eligible and rules for determining whether a particular packet is in-profile or out-of- profile. For example, a profile based on token bucket may look like: codepoint=X, use token-bucket r, b The above profile indicates that all packets in the behavior aggregate with DS codepoint X should be measured against a token bucket meter with rate r and burst size b. In this example out-of- profile packets are those packets in the behavior aggregate which arrive when insufficient tokens are available in the bucket. Different conditioning actions may be applied to the in-profile packets and out-of-profile packets, or different accounting actions may be triggered. 2.2.2.2 Actions to In-Profile and Out-of-Profile Packets In-profile packets may be allowed to enter the DS domain without further conditioning as they conform to the TCA; or, alternatively, their DS field may be marked with a new DS codepoint. The latter Black, et. al. Expires: November 1998 [Page 11] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 happens when the DS field is set to a non-Default value for the first time [DSFIELD], or when the packets enter a DS domain that uses a different PHB group for this traffic stream, so the DS codepoint has to be mapped to the new PHB group. The actions to out-of-profile packets may include delaying the packets until they are in-profile (shaping), discarding the packets, marking the DS field to a particular codepoint, or triggering some accounting action. 2.2.3 Components of a Traffic Conditioner 2.2.3.1 Classifiers Packet classifiers select packets in a traffic stream based on the content of some portion of the packet header. The classification may be based on the DS field only (Behavior Aggregate Classification), or on any combination of one or several fields in the packet header such as source address, destination address, DS field, protocol ID, and, transport-layer header fields such as source port and destination port numbers (Multi-Field Classification). Classifiers are used to steer packets matching some specified rule to another element of the traffic conditioner for further processing. Classifiers must be configured by some management procedure in accordance with the appropriate TCA. The classifier should authenticate the information which it uses to classify the packet (see Sec. 6). Note that in the event of upstream packet fragmentation, multi-field classifiers which examine the contents of transport-layer header fields may incorrectly classify packet fragments subsequent to the first. A possible solution to this problem is to maintain fragmentation state; however, this is not a general solution due to the possibility of upstream fragment re-ordering or divergent routing paths. 2.2.3.2 Meters Traffic meters measure the traffic properties of the set of packets selected by a classifier against a traffic profile specified in the TCA. A meter indicates to other conditioning functions whether each individual packet is in- or out-of-profile. A null meter will identify all packets as in-profile. Such a meter may be used when the traffic profile does not specify conforming rate or burst parameters. 2.2.3.3 Markers Packet markers set the DS field of a packet to a particular codepoint, adding the marked packet to a particular DS behavior Black, et. al. Expires: November 1998 [Page 12] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 aggregate. The marker may be configured to mark all packets which are steered to it to a single codepoint, or may be configured to mark a packet to one of a set of codepoints within a PHB group according to the state of a meter. 2.2.3.4 Shapers Shapers delay some or all of the packets in a traffic stream in order to bring the stream into compliance with its associated traffic profile. A shaper usually has a finite-size buffer, and packets may be discarded if there is not enough buffer space to hold the delayed packets. Note that discard policers can be implemented as a special case of a shaper by setting the shaper buffer size to zero (or a few) packets. 2.2.4 Location of Traffic Conditioners Traffic conditioners may be located within a customer DS domain, and at the boundary of a DS domain. Traffic conditioners may also be located in nodes in a non-DS domain. 2.2.4.1 Traffic Conditioners within a Customer DS Domain Traffic sources and nodes within a customer DS domain may perform traffic conditioning functions. The packets originating from the customer DS domain across a boundary may have their DS field marked by the traffic sources or by intermediate routers before leaving the customer DS domain. For example, suppose that a customer domain has a policy that the CEO's packets should have higher priority. The CEO's host may mark the DS field of all outgoing packets with a DS codepoint that indicates higher priority. Alternatively, the first-hop router directly connected to the CEO's host may classify the traffic and mark the CEO's packets with the correct DS codepoint. There are some advantages to marking the DS field close to the traffic source. First, a traffic source can more easily take an application's preferences into account when deciding which packets should receive better forwarding treatment. Also, classification of packets is much simpler before the traffic has been aggregated with packets from other sources, since the number of classification rules which need to be applied within a single node is reduced. Since packet marking may be distributed across different nodes, the customer DS domain is responsible for ensuring that the aggregated traffic towards its provider DS domain conforms to the appropriate TCA. Additional allocation mechanisms such as bandwidth brokers or RSVP may be used to dynamically allocate resources for a particular DS behavior aggregate within the customer's network. The edge node of the customer DS domain should also monitor conformance to the TCA, and triage packets as necessary. Black, et. al. Expires: November 1998 [Page 13] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 2.2.4.2 Traffic Conditioners at the Boundary of a DS Domain Traffic streams may be marked and otherwise conditioned on either end of a boundary link (the DS egress node of the customer DS domain or the DS ingress node of the provider DS domain). The TCA between the domains should specify which domain has responsibility for mapping traffic streams to DS behavior aggregates and conditioning those aggregates in conformance with the TCA. However, a DS ingress node must assume that the incoming traffic may not conform to the TCA and must be prepared to enforce the TCA in accordance with local policy. There is an advantage to performing complex conditioning operations in the customer DS domain since it is then no longer necessary to divulge the local classification and service provisioning rules to the provider DS domain. In this circumstance the provider domain may only need to re-mark or police incoming behavior aggregates to enforce the TCA. However, more sophisticated services which are path- or source-dependent may require multi-field classification in the provider's ingress nodes. Since packet marking may be distributed across different nodes, the If a DS ingress node is connected to a non-DS domain, the DS ingress node must be able to perform all traffic conditioning functions on the incoming traffic. 2.2.4.3 Traffic Conditioners in non-DS Domains Traffic sources or intermediate nodes in a non-DS domain may employ traffic conditioners to pre-mark traffic before it reaches the ingress of a provider DS domain. 2.3 Per-Hop Behaviors A per-hop behavior (PHB) is a description of the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate. "Forwarding behavior" is a general concept in this context. For example, in the event that only one behavior aggregate occupies a link, the observable forwarding behavior (i.e., loss, delay, jitter) will usually depend only on the relative loading of the link (i.e., in the event that the behavior assumes a work- conserving scheduling discipline). Useful behavioral distinctions are only observed when multiple behavior aggregates compete for buffer and bandwidth resources on a node. The PHB is the means by which a node allocates resources to behavior aggregates, and it is on top of this basic hop-by-hop resource allocation mechanism that useful differentiated services may be constructed. The most simple example of a PHB is one which guarantees a minimal bandwidth allocation of X% of a link (over some reasonable time interval) to a behavior aggregate. This PHB can be fairly easily measured under a variety of competing traffic conditions. A slightly Black, et. al. Expires: November 1998 [Page 14] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 more complex PHB would guarantee a minimal bandwidth allocation of X% of a link, with proportional fair sharing of any excess link capacity. Another simple example is taken from [DSFIELD]; the Expedited Forwarding PHB. This PHB provides negligible loss, delay, and delay jitter (similar to that observed by a single packet traversing an otherwise idle router) for a behavior aggregate which is the multiplex of multiple peak-rate regulated traffic streams, under the constraint that the load of the behavior aggregate is a small fraction of the link capacity. This last constraint is a consequence of queueing physics; a multiplex of peak-rate regulated traffic streams may still exhibit arrival burstiness, and the resulting delay and jitter will only be negligible under the circumstance where the relative load of the aggregated traffic is small, even when there is no competing traffic from other behavior aggregates. In general, the observable behavior of a PHB may depend on certain constraints on the traffic characteristics of the associated behavior aggregate, or the characteristics of other behavior aggregates. PHBs may be specified in terms of their resource (e.g., buffer, bandwidth) priority relative to other PHBs, or in terms of their relative observable traffic characteristics (e.g., delay, loss) [Baker]. These PHBs should be specified as a group (PHB group) for consistency. The priority relationship within a PHB group will tend to be hierarchical, and the associated DS codepoints should be assigned in increasing order of relative priority for clarity of interpretation. The priority relationship between PHBs in the group may be absolute (e.g., absolute discard priority) or may be less rigid (e.g., higher probability of loss). A single PHB defined in isolation is a degenerate form of a PHB group. PHBs are implemented in nodes by means of some buffer management and packet scheduling mechanisms. PHBs should be defined in terms of behavior characteristics relevant to service provisioning policies, and not in terms of particular implementation mechanisms. In general, a variety of implementation mechanisms may be suitable for implementing a particular PHB group. Furthermore, it is likely that more than one PHB group may be implemented on a node and utilized within a domain. PHB groups should be defined such that the proper resource allocation between groups can be inferred, and integrated mechanisms can be implemented which can simultaneously support two or more groups. 2.4 Network Resource Allocation The implementation, configuration, operation and administration of the supported PHB groups in the nodes of a DS Domain should effectively partition the resources of those nodes and the inter-node links between the traffic aggregates, in accordance with the domain's service provisioning policy. Traffic conditioners control the usage of these resources through the administrative control of TCAs and Black, et. al. Expires: November 1998 [Page 15] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 possibly through operational feedback from the nodes and traffic conditioners in the domain. The configuration of and interaction between the traffic conditioners and the interior nodes should be managed by the administrative control of the domain and may require operational control through protocols and a control entity. There is a wide range of possible control models [DSFWK]. The precise nature and implementation of the interaction between these components is outside the scope of this architecture. However, scalability requires that the control of the domain does not require micro-management of the network resources. The most scalable control model would operate nodes in open-loop in the operational timeframe, and would only require administrative- timescale management as SLAs are varied. This simple model may be unsuitable in some circumstances, and some automated but relatively long time-constant operational control (minutes rather than seconds) may be desirable to balance the utilization of the network against the recent load profile. 3. Per-Hop Behavior Definition Requirements In order for a Per Hop Behavior (PHB) group to be considered for standardization, a detailed definition of the behavior should be provided as a basis for implementation consistency. This section provides a template for defining a new PHB group. Before a PHB group is considered for standardization it should satisfy the PHB definition requirements in this section, to preserve the integrity of this architecture. 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 [RFC2119]. 3.1. A PHB definition MUST NOT require inspection or modification of any part of the packet other than the DS field. 3.2. The definition of each newly proposed PHB group MUST include an overview of the behavior and the purpose of the behavior being proposed. The overview MUST include a problem or problems statement for which the PHB group is targeted. The overview MUST include the basic concepts behind the PHB group. These concepts SHOULD include, but are not restricted to, queueing behavior, discard behavior, and output link selection behavior. Lastly, the overview MUST specify the method by which the PHB group solves the problem or problems specified in the problem statement. Any configuration or management issues which affect the basic PHB definition MUST be specified in the overview of the behavior. The actual details of the management and configuration of PHB groups in routers or hosts MUST be addressed in a separate, parallel document. Black, et. al. Expires: November 1998 [Page 16] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 3.3. A PHB group definition MUST indicate whether a PHB group consists of one or more codepoints. In the event that multiple codepoints are specified, the interactions between the codepoints within the PHB group and constraints that must be respected globally across all the codepoints within the PHB group MUST be clearly explained in the description of the PHB group. As an example, the definition MUST specify whether packet reordering within a microflow with packets marked by two or more codepoints within the group is likely. 3.4. A PHB group may be standardized for local use within a domain in order to provide some domain specific functionality or domain specific services. In this event, the PHB definition is useful for providing vendors with a consistent definition of the PHB group. The PHB definition can also provide semantics for PHB translation and service mappings with peer domains which do not support the PHB group. However, any PHB group which is defined as local use MUST be considered as an informational standard. In contrast, a PHB group which is proposed for general use will follow a stricter standardization process. Therefore all proposed PHB definitions MUST specifically state whether they are to be considered for general use or local use. It is recognized that PHB groups can be designed with the intent of providing host-to-host, WAN edge-to-WAN edge, or domain edge-to- domain edge services. Use of the term "end-to-end" in a PHB definition MUST be interpreted to mean "host-to-host". Other PHB groups may be defined and deployed locally within domains, for experimental or operational purposes. There is no requirement that these PHB groups must be publically documented, but they SHOULD utilize DS codepoints from one of the EXP/LU pools as defined in [DSFIELD]. 3.5. It may be possible or appropriate for a packet marked with a codepoint within a PHB group to be re-marked to another codepoint within that group either within a domain or across two cooperating domains. Typically there are three reasons for PHB group mutability: 1. The codepoints of the PHB group are collectively intended to carry state about the network. 2. Changes in the network state which require promotion or demotion of traffic marked with a codepoint within the PHB group. 3. A PHB group is not implemented one both sides of a domain boundary; All codepoints of a PHB group have to be mapped to some other PHB or PHB group at the boundary. In contrast, it may also be necessary for specific PHB groups to be preserved within a domain and/or across multiple domains. Typically this is because the PHB groups carry some host-to-host, WAN edge-to- WAN edge, or domain edge-to-domain edge semantics which are difficult to duplicate when the PHB group is mapped to a different PHB group. Black, et. al. Expires: November 1998 [Page 17] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 Further, these semantics may also be difficult to duplicate if packet markings are promoted or demoted within the same PHB group. A PHB definition MUST clearly state whether packets marked by a codepoint within a PHB group MAY, or SHOULD be promoted, demoted (to another codepoint within the group), or preserved within a domain. A PHB definition MUST clearly state whether packets marked by a codepoint within a PHB group MAY, or SHOULD be promoted, demoted, or preserved across multiple, cooperating domains. A PHB definition MUST clearly state whether codepoints within a PHB group MAY, or SHOULD be mapped to a different PHB group. If it is desirable for a PHB group to be changed, the definition SHOULD clearly state the circumstances under which a change is desirable. If it is undesirable for a PHB group to be changed, the definition MUST clearly state what the risks are when a PHB group is modified. A PHB definition may include constraints on actions that change the PHB group. These constraints may be specified as actions the router SHOULD, or MUST perform. 3.6. The PHB definition MUST also include a section defining the implications of tunneling on the PHB group. This section should specify the implications on the PHB group of a newly created outer header when the original PHB group of the inner header is encapsulated in a tunnel. This section should also discuss what possible changes should be applied to the inner header at the egress of the tunnel, when both the PHB groups from the inner header and the outer header are accessible. 3.7. The process of defining PHB groups is incremental in nature. When new PHB groups are defined, their known interactions with previously defined PHB groups MUST be documented. When a new PHB group is created, it can be entirely new in scope or it can be an extension to an existing PHB group. If the PHB group is entirely independent of some or all of the existing PHB definitions, a section MUST be included in the PHB definition which details how the new PHB group co-exists with those PHB groups already defined. For example, this section might indicate the possibility of packet re-ordering within a microflow with packets marked by codepoints within two separate PHB groups. If concurrent operation of two (or more) different PHB groups in the same router is impossible or detrimental this MUST be stated. If the concurrent operation of two (or more) different PHB groups requires some specific behaviors by the router when traffic specifying these different PHB groups are in the router at the same time, these behaviors MUST be stated. If the proposed PHB group is an extension to an existing PHB group, a section MUST be included in the PHB group definition which details how this extension inter-operates with the behavior being extended. Further, if the extension alters or more narrowly defines the existing behavior in some way, this MUST also be clearly specified in the PHB definition. Black, et. al. Expires: November 1998 [Page 18] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 3.8. Each PHB definition MUST include a section specifying minimal conformance to the PHB group. This conformance section is intended to provide a means for specifying the details of a behavior while allowing for implementation variation to the extent permitted by the PHB definition. This conformance section can take the form of rules, tables, pseudo-code or tests. 3.9. A PHB definition MUST include a section detailing the security implications of the behavior. This section should include a discussion of the mutability of the inner header's PHB group at the egress of a tunnel. Further, this section should also discuss how the proposed PHB group could be used in denial-of-service attacks, reduction of service contract attacks, and service contract violation attacks. Lastly, this section should discuss the means for detecting such attacks as they are relevant to the proposed behavior. 3.10. It is strongly RECOMMENDED that an appendix be provided for each PHB definition that considers the implications of the proposed behavior on current and potential services. These services could include but are not restricted to be user specific, device specific, domain specific or end to end services. It is also strongly RECOMMENDED that the appendix include a section describing how the services are verified by users, devices, and/or domains. 3.11. If the PHB definition is targeted for local use within a domain, it is RECOMMENDED that the appendix include a description of how the PHB group is mapped to existing general use PHB groups as well as other local use PHB groups. 3.12. It is RECOMMENDED that an appendix be provided for each PHB definition which considers the impact of the proposed new PHB groups on existing higher-layer protocols. Under some circumstances PHB definitions may allow for possible changes to higher-layer protocols which may increase or decrease the utility of the proposed PHB group. 4. Interoperability with Non-Differentiated Services-Compliant Nodes We define a non-differentiated services-capable node (non-DS-capable node) as a node which does not interpret the DS field as specified in [DSFIELD] and/or does not implement some or all of the standardized PHBs. This may be due to the capabilities or configuration of the node. We distinguish such a node from a one which does not implement differentiated forwarding behaviors which can be selected by the value of the IPv4 TOS byte or the IPv6 Traffic Class byte. We define a legacy node as one which implements IPv4 Precedence as defined in [RFC791], but which is otherwise non-DS capable. Differentiated services depend on the resource allocation mechanisms provided by per-hop behavior implementations on nodes. The quality or statistical assurance level of a service may break down in the event that traffic transits a non-DS-capable node, or a non-DS- Black, et. al. Expires: November 1998 [Page 19] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 capable domain. We will examine two separate cases. The first case concerns the use of non-DS-capable nodes within a DS domain. Note that PHB forwarding is primarily useful for allocating scarce node and link resources in a controlled manner. On high-speed, lightly loaded links, the worst- case packet delay, jitter, and loss may be negligible, and the use of a non-DS-capable node on the upstream end of such a link may not result in service degradation. In more realistic circumstances, the lack of PHB forwarding in a node may make it impossible to offer low- delay, low-loss, or provisioned bandwidth services across paths which traverse the node. However, use of a legacy node may be an acceptable alternative, assuming that the DS domain restricts itself to using only the precedence-compatible PHBs defined in [Baker], and assuming that the particular precedence implementation results in forwarding behaviors which are compatible with the services offered along paths which traverse that node. The second case concerns the behavior of services which traverse non- DS-capable domains. We assume for the sake of argument that a non- DS-capable domain does not deploy traffic conditioning functions on domain edge nodes; therefore, even in the event that the domain consists of legacy or DS-capable interior nodes, the lack of traffic enforcement at the edges will limit the ability to consistently deliver some types of services across the domain. A DS domain and a non-DS-capable domain may negotiate an agreement which governs how egress traffic from the DS-domain should be marked before entry into the non-DS-capable domain. This agreement might be monitored for compliance by traffic sampling instead of by rigorous traffic conditioning. Alternatively, where there is knowledge that the non- DS-capable domain consists of legacy nodes, the upstream DS domain may opportunistically re-mark differentiated services traffic to one or more IPv4 precedence values. Where there is no knowledge of the traffic management capabilities of the domain, and no agreement in place, a DS domain egress node may choose to re-mark the DS field to zero, under the assumption that the non-DS-capable domain will treat the traffic uniformly with best-effort service. In the event that a non-DS-capable peers with a DS domain, traffic flowing from the non-DS-capable domain should be conditioned at the DS ingress node of the DS domain according to the appropriate SLA or policy. 5. Multicast Considerations For future study. 6. Security and Tunneling Considerations This section addresses security issues raised by the introduction of Black, et. al. Expires: November 1998 [Page 20] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 differentiated services, primarily the potential for denial-of- service attacks, and the related potential for theft of service by unauthorized traffic (Section 6.1). In addition, the operation of differentiated services in the presence of IPsec and its interaction with IPsec are also discussed (Section 6.2), as well as auditing requirements (Section 6.3). This section considers issues introduced by the use of both IPsec and non-IPsec tunnels. 6.1 Theft and Denial of Service The primary goal of differentiated services is to allow different levels of service to be provided for traffic streams on a common network infrastructure. A variety of resource management techniques may be used to achieve this, but the end result will be that some packets receive different (e.g., better) service than others. The mapping of network traffic to the specific behaviors that result in different (e.g., better or worse) service is indicated primarily by the DS field, and hence an adversary may be able to obtain better service by modifying the DS field to values indicating behaviors used for enhanced services or by injecting packets with DS field's set to such values. Taken to its limits, this theft of service becomes a denial-of-service attack when the modified or injected traffic depletes the resources available to forward it and other traffic streams. The defense against such theft- and denial-of-service attacks consists of a combination of edge policing and security of the network infrastructure within a DS domain. As described in Section 2.1, DS ingress nodes must ensure that all traffic entering a DS domain has DS field values that are acceptable to that domain's service provision policy. This makes the ingress nodes the first line of defense against theft-of-service and denial- of-service attacks based on modified DS field values (e.g., values to which the traffic is not entitled). An important instance of an ingress node is that any traffic-originating node in a DS domain is the ingress node for that traffic, and must ensure that that traffic carries acceptable DS field values. A domain's service provision policy may require the ingress nodes to change the DS field values on some entering packets (e.g., an ingress router may set the DS field values of a customer's traffic in accordance with the appropriate SLA). Ingress nodes should police all other inbound traffic to ensure that the DS field values are acceptable; packets found to have unacceptable values must either be discarded or must have their DS fields modified to acceptable values before being forwarded. For example, an ingress node receiving traffic from a domain with which no enhanced service agreement exists may reset the DS field to DE(fault) service [DSFIELD]. A service provisioning policy may require traffic authentication to validate the use of some DS field values (e.g., those corresponding to enhanced services), and such authentication may be performed by technical means (e.g., IPsec) and/or non-technical means (e.g., the Black, et. al. Expires: November 1998 [Page 21] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 inbound link is known to be connected to exactly one customer site). An inter-domain agreement may reduce or eliminate the need for ingress node traffic policing by making the upstream domain partly or completely responsible for ensuring that traffic has DS field values acceptable to the downstream domain. In this case, the ingress node may still perform redundant acceptability checks to reduce the dependence on the upstream domain (e.g., such checks can prevent theft-of-service attacks from propagating across the domain boundary). If an acceptability check fails because the upstream domain is not fulfilling its responsibilities, that failure is an auditable event; the generated audit log entry should include the date/time the packet was received, the source and destination IP addresses, and the DS field value that caused the failure. In practice, the limited gains from such checks need to be weighed against their potential performance impact in determining what, if any, checks to perform under these circumstances. Interior nodes in a DS domain may rely on the DS field to associate differentiated services traffic with the behaviors used to implement enhanced services. Any node doing so depends on the correct operation of the DS domain to prevent the arrival of traffic with unacceptable DS field values. Robustness concerns dictate that the arrival of packets with unacceptable DS field values must not cause the failure (e.g., crash) of network nodes. Interior nodes are not responsible for enforcing the service provisioning policy (or individual SLAs) and hence are not required to check DS field values for acceptability. Interior nodes may perform some acceptability checks on DS field values (e.g., check for DS field values that are never used for traffic on a specific link, never used with a source/ destination address outside a specific range, etc.) to improve security and robustness (e.g., resistance to theft of service attacks based on DS field modifications). Any detected failure of such an acceptability check is an auditable event and the generated audit log entry should include the date/time the packet was received, the source and destination IP addresses, and the DS field value that caused the failure. In practice, the limited gains from such checks need to be weighed against their potential performance impact in determining what, if any, checks to perform at interior nodes. Any link that cannot be adequately secured against modification of DS field values or traffic injection by adversaries should be treated as a boundary link (and hence any arriving traffic on that link is treated as if it were entering the domain at an ingress node). Local security policy provides the definition of "adequately secured," and such a definition may include a determination that the risks and consequences of DS field modification and/or traffic injection do not justify any additional security measures for a link. Link security can be enhanced via physical access controls and/or software means such as tunnels that ensure packet integrity. Black, et. al. Expires: November 1998 [Page 22] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 6.2 IPsec and Tunneling interactions The IPsec protocol, as defined in [ESP, AH], does not include the IP header's DS field in any of its cryptographic calculations (in the case of tunnel mode, it is the outer IP header's DS field that is not included). Hence modification of the DS field by a network node has no effect on IPsec's end-to-end security, because it cannot cause any IPsec integrity check to fail. As a consequence, IPsec does not provide any defense against an adversary's modification of the DS field (i.e., a man-in-the-middle attack); the adversary's modification will also have no effect on IPsec's end-to-end security. In some environments, the ability to modify the DS field without affecting IPsec integrity checks may constitute a covert channel; if it is necessary to eliminate such a channel or reduce its bandwidth, the DS domains should be configured so that the required processing (e.g., set all DS fields on sensitive traffic to a single value) can be performed at DS egress nodes where traffic exits higher security domains. IPsec's tunnel mode provides security for the encapsulated IP header's DS field. A tunnel mode IPsec packet contains two IP headers: an outer header supplied by the ingress node and an encapsulated inner header supplied by the original source of the packet. When an IPsec tunnel is hosted (in whole or in part) on a differentiated services network, the intermediate network nodes operate on the DS field in the outer header. At the tunnel egress node, IPsec processing includes stripping the outer header and forwarding the packet (if required) using the inner header. Since the inner IP header has not been processed by a DS ingress node, the tunnel egress node is the DS ingress node for traffic exiting the tunnel, and hence must carry out the corresponding responsibilities (see Section 6.1). If the IPsec processing includes a sufficiently strong cryptographic integrity check of the encapsulated packet (where sufficiency is determined by local security policy), the tunnel egress node can safely assume that the DS field in the inner header has the same value as it had at the tunnel ingress node. If the tunnel ingress node is in the same DS domain as the tunnel egress node, the tunnel egress node can safely treat a packet passing such an integrity check as if it had arrived from another node within the same DS domain and hence omit the DS ingress node policing that would otherwise be required. An important consequence is that otherwise insecure internal links within DS domains can be secured by a sufficiently strong IPsec tunnel. This analysis and its implications apply to any tunneling protocol that performs integrity checks, but the level of assurance of the inner header's DS field depends on the strength of the integrity check performed by the tunneling protocol. In the absence of sufficient assurance for a tunnel that may transit nodes outside the current DS domain (or is otherwise vulnerable), the encapsulated packet must be treated as if it had arrived at a DS ingress node from outside the domain. Black, et. al. Expires: November 1998 [Page 23] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 IPsec currently specifies that the inner header's DS field must not be changed by IPsec decapsulation processing at the tunnel egress node. This ensures that an adversary's modifications to the DS field cannot be used to launch theft- or denial-of-service attacks across an IPsec tunnel endpoint, as any such modifications will be discarded at the tunnel endpoint. Note: the following paragraph requires coordination with and approval by he Security Area of the IETF, and may result in the need for brief modifications of the appropriate security RFCs. A tunnel egress node in a DS domain may modify the DS field in an inner IP header based on the DS field value in the outer header, including copying part or all of the outer DS field to the inner DS field. For a tunnel contained entirely within a single DS domain and for which the links are adequately secured against modifications of the outer DS field, the only limits on modifications are those imposed by the domain's service provisioning policy. Otherwise, the tunnel egress node performing such modifications is acting as a DS ingress node for traffic exiting the tunnel, and must carry out the responsibilities of an ingress node, including ensuring that the resulting DS field values are acceptable (see Section 6.1). If the tunnel enters the DS domain at a node different from the tunnel egress node, the tunnel egress node may depend on the upstream DS ingress node having ensured the acceptability of the outer DS field value. Even in this case, there are some acceptability checks that can only be performed by the tunnel egress node (e.g., a consistency check between the inner and outer DS field values for an encrypted tunnel). Any detected failure of such a check is an auditable event and the generated audit log entry should include the date/time the packet was received, the source and destination IP addresses, and the DS field value that was unacceptable. The requirements in this paragraph apply to any future use of the currently unused (CU) bits in the IPv4 TOS byte and the IPv6 Traffic Class byte [DSFIELD]. 6.3 Auditing Not all systems that support differentiated services will implement auditing. However, if differentiated services support is incorporated into a system that supports auditing, then the differentiated services implementation must also support auditing and must allow a system administrator to enable or disable auditing for differentiated services. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this document and for each of these events a minimum set of information that should be included in an audit log is defined. Additional information also may be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also may result in audit log Black, et. al. Expires: November 1998 [Page 24] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 7. Acknowledgements The authors would like to acknowledge the following individuals for their helpful comments and suggestions: Kathleen Nichols, Brian Carpenter, Konstantinos Dovrolis, Shivkumar Kalyana, Wu-chang Feng, Marty Borden, Yoram Bernet, Ronald Bonica, James Binder, and Borje Ohlman. 8. References [802.1p] ISO/IEC Final CD 15802-3 Information technology - Tele- communications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) bridges, (current draft available as IEEE P802.1D/D15). [AH] S. Kent and R. Atkinson, "IP Authentication Header", Internet Draft , May 1998. [ATM] ATM Traffic Management Specification Version 4.0 , April 1996. [Baker] F. Baker, S. Brim, T. Li, F. Kastenholz, S. Jagannath, and J. Renwick, "IP Precedence in Differentiated Services Using the Assured Service", Internet Draft , April 1998. [DSFIELD] K. Nichols and S. Blake, "Definition of the Differentiated Services Field (DS Byte) in the IPv4 and IPv6 Headers", Internet Draft , May 1998. [DSFWK] Differentiated Services Framework Document (work in preparation). [Clark97] D. Clark and J. Wroclawski, "An Approach to Service Allocation in the Internet", Internet Draft , July 1997. [Ellesson] E. Ellesson and S. Blake, "A Proposal for the Format and Semantics of the TOS Byte and Traffic Class Byte in IPv4 and IPv6", Internet Draft , November 1997. Black, et. al. Expires: November 1998 [Page 25] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 [ESP] S. Kent and R. Atkinson, "IP Encapsulating Security Payload", Internet Draft , May 1998. [Ferguson] P. Ferguson, "Simple Differential Services: IP TOS and Precedence, Delay Indication, and Drop Preference, Internet Draft , April 1998. [FRELAY] ANSI T1S1, "DSSI Core Aspects of Frame Rely", March 1990. [Heinanen] J. Heinanen, "Use of the IPv4 TOS Octet to Support Differentiated Services", Internet Draft , November 1997. [IntServ] R. Braden, D. Clark, and S. Shenker, "Integrated Services in the Internet Architecture: An Overview", Internet RFC 1633, July 1994. [MPLSFWK] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, and A. Viswanathan, "A Framework for Multiprotocol Label Switching", Internet Draft , November 1997. [PASTE] T. Li and Y. Rekhter, "Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", Internet Draft , January 1998. [RFC791] Information Sciences Institute, "Internet Protocol", Internet RFC 791, September 1981. [RFC1349] P. Almquist, "Type of Service in the Internet Protocol Suite", Internet RFC 1349, July 1992. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet RFC 2119, March 1997. [RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", Internet RFC 2205, September 1997. [SIMA] K. Kilkki, "Simple Integrated Media Access (SIMA)", Internet Draft , June 1997. [2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", Internet Draft , November 1997. [TR] ISO/IEC 8802-5 Information technology - Telecommunications and information exchange between Black, et. al. Expires: November 1998 [Page 26] INTERNET-DRAFT An Architecture for Differentiated Services May 1998 systems - Local and metropolitan area networks - Common specifications - Part 5: Token Ring Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.5- 1995), 1995. [Weiss] W. Weiss, "Providing Differentiated Services Through Cooperative Dropping and Delay Indication", Internet Draft , March 1998. Authors' Addresses David Black The Open Group Research Institute Eleven Cambridge Center Cambridge, MA 02142 Phone: +1-617-621-7347 E-mail: d.black@opengroup.org Steven Blake IBM Corporation 800 Park Offices Drive Research Triangle Park, NC 27709 Phone: +1-919-254-2030 E-mail: slblake@raleigh.ibm.com Mark A. Carlson Redcape Software, Inc. 2990 Center Green Court South Boulder, CO 80301 Phone: +1-303-448-0048 x115 E-mail: mac@redcape.com Elwyn Davies Nortel UK London Road Harlow, Essex CM17 9NA, UK Phone: +44-1279-405498 E-mail: elwynd@nortel.co.uk Zheng Wang Bell Labs Lucent Tech 101 Crawfords Corner Road Holmdel, NJ 07733 E-mail: zhwang@bell-labs.com Walter Weiss Lucent Technologies 300 Baker Avenue, Suite 100, Concord, MA 01742-2168 E-mail: wweiss@lucent.com Black, et. al. Expires: November 1998 [Page 27]