diff options
Diffstat (limited to 'doc/rfc/rfc2475.txt')
| -rw-r--r-- | doc/rfc/rfc2475.txt | 2019 |
1 files changed, 2019 insertions, 0 deletions
diff --git a/doc/rfc/rfc2475.txt b/doc/rfc/rfc2475.txt new file mode 100644 index 0000000..fd7b2c8 --- /dev/null +++ b/doc/rfc/rfc2475.txt @@ -0,0 +1,2019 @@ + + + + + + +Network Working Group S. Blake +Request for Comments: 2475 Torrent Networking Technologies +Category: Informational D. Black + EMC Corporation + M. Carlson + Sun Microsystems + E. Davies + Nortel UK + Z. Wang + Bell Labs Lucent Technologies + W. Weiss + Lucent Technologies + December 1998 + + + An Architecture for Differentiated Services + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +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 nodes along their path. Sophisticated + classification, marking, 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 marked and conditioned upon entry to a + differentiated services-capable network, and how that traffic is + forwarded within that network. A wide variety of services can be + implemented on top of these building blocks. + + + + + + + + + +Blake, et. al. Informational [Page 1] + +RFC 2475 Architecture for Differentiated Services December 1998 + + +Table of Contents + + 1. Introduction ................................................. 2 + 1.1 Overview ................................................. 2 + 1.2 Terminology ............................................... 4 + 1.3 Requirements .............................................. 8 + 1.4 Comparisons with Other Approaches ......................... 9 + 2. Differentiated Services Architectural Model .................. 12 + 2.1 Differentiated Services Domain ............................ 12 + 2.1.1 DS Boundary Nodes and Interior Nodes .................. 12 + 2.1.2 DS Ingress Node and Egress Node ....................... 13 + 2.2 Differentiated Services Region ............................ 13 + 2.3 Traffic Classification and Conditioning ................... 14 + 2.3.1 Classifiers ........................................... 14 + 2.3.2 Traffic Profiles ...................................... 15 + 2.3.3 Traffic Conditioners .................................. 15 + 2.3.3.1 Meters ............................................ 16 + 2.3.3.2 Markers ........................................... 16 + 2.3.3.3 Shapers ........................................... 17 + 2.3.3.4 Droppers .......................................... 17 + 2.3.4 Location of Traffic Conditioners and MF Classifiers ... 17 + 2.3.4.1 Within the Source Domain .......................... 17 + 2.3.4.2 At the Boundary of a DS Domain .................... 18 + 2.3.4.3 In non-DS-Capable Domains ......................... 18 + 2.3.4.4 In Interior DS Nodes .............................. 19 + 2.4 Per-Hop Behaviors ......................................... 19 + 2.5 Network Resource Allocation ............................... 20 + 3. Per-Hop Behavior Specification Guidelines .................... 21 + 4. Interoperability with Non-Differentiated Services-Compliant + Nodes ........................................................ 25 + 5. Multicast Considerations ..................................... 26 + 6. Security and Tunneling Considerations ........................ 27 + 6.1 Theft and Denial of Service ............................... 28 + 6.2 IPsec and Tunneling Interactions .......................... 30 + 6.3 Auditing .................................................. 32 + 7. Acknowledgements ............................................. 32 + 8. References ................................................... 33 + Authors' Addresses ............................................... 34 + Full Copyright Statement ......................................... 36 + +1. Introduction + +1.1 Overview + + This document defines an architecture for implementing scalable + service differentiation in the Internet. A "Service" defines some + significant characteristics of packet transmission in one direction + across a set of one or more paths within a network. These + + + +Blake, et. al. Informational [Page 2] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + 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 per-hop + forwarding behaviors, packet classification functions, and traffic + conditioning functions including metering, marking, shaping, and + policing. This architecture achieves scalability by implementing + complex classification and conditioning functions only at network + boundary 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 at each node among competing traffic streams. Per- + application flow or per-customer forwarding state need not be + maintained within the core of the network. A distinction is + maintained between: + + o the service provided to a traffic aggregate, + + o the conditioning functions and per-hop behaviors used to realize + services, + + o the DS field value (DS codepoint) used to mark packets to select a + per-hop behavior, and + + o the particular node implementation mechanisms which realize a + per-hop behavior. + + Service provisioning and traffic conditioning policies are + sufficiently decoupled from the forwarding behaviors within the + network interior to permit implementation of a wide variety of + service behaviors, with room for future expansion. + + This architecture only provides service differentiation in one + direction of traffic flow and is therefore asymmetric. Development + of a complementary symmetric architecture is a topic of current + research but is outside the scope of this document; see for example + [EXPLICIT]. + + Sect. 1.2 is a glossary of terms used within this document. Sec. 1.3 + lists requirements addressed by this architecture, and Sec. 1.4 + provides a brief comparison to other approaches for service + differentiation. Sec. 2 discusses the components of the architecture + + + +Blake, et. al. Informational [Page 3] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + in detail. Sec. 3 proposes guidelines for per-hop behavior + specifications. Sec. 4 discusses interoperability issues with nodes + and networks which do not implement differentiated services as + defined in this document and in [DSFIELD]. Sec. 5 discusses issues + with multicast service delivery. Sec. 6 addresses security and + tunnel considerations. + +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. + + Behavior Aggregate (BA) a DS behavior aggregate. + + BA classifier a classifier that selects packets based + only on the contents of the DS field. + + Boundary link a link connecting the edge nodes of two + domains. + + Classifier an entity which selects packets based on + the content of packet headers according to + defined rules. + + DS behavior aggregate a collection of packets with the same DS + codepoint crossing a link in a particular + direction. + + DS boundary 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-capable capable of implementing differentiated + services as described in this architecture; + usually used in reference to a domain + consisting of DS-compliant nodes. + + DS codepoint a specific value of the DSCP portion of the + DS field, used to select a PHB. + + DS-compliant enabled to support differentiated services + functions and behaviors as defined in + [DSFIELD], this document, and other + differentiated services documents; usually + used in reference to a node or device. + + + + + +Blake, et. al. Informational [Page 4] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + DS domain a DS-capable domain; a contiguous set of + nodes which operate with a common set of + service provisioning policies and PHB + definitions. + + DS egress node a DS boundary node in its role in handling + traffic as it leaves a DS domain. + + DS ingress node a DS boundary node in its role in handling + traffic as it enters a DS domain. + + DS interior node a DS node that is not a DS boundary node. + + DS field the IPv4 header TOS octet or the IPv6 + Traffic Class octet when interpreted in + conformance with the definition given in + [DSFIELD]. The bits of the DSCP field + encode the DS codepoint, while the + remaining bits are currently unused. + + DS node a DS-compliant node. + + DS region a set of contiguous DS domains which can + offer differentiated services over paths + across those DS domains. + + Downstream DS domain the DS domain downstream of traffic flow on + a boundary link. + + Dropper a device that performs dropping. + + Dropping the process of discarding packets based on + specified rules; policing. + + Legacy node a node which implements IPv4 Precedence as + defined in [RFC791,RFC1812] but which is + otherwise not DS-compliant. + + Marker a device that performs marking. + + Marking the process of setting the DS codepoint in + a packet based on defined rules; pre- + marking, re-marking. + + 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. + + + +Blake, et. al. Informational [Page 5] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + Meter a device that performs metering. + + Metering the process of measuring the temporal + properties (e.g., rate) of a traffic stream + selected by a classifier. The + instantaneous state of this process may be + used to affect the operation of a marker, + shaper, or dropper, and/or may be used for + accounting and measurement purposes. + + 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. + + MF Classifier a multi-field (MF) classifier which selects + packets based on the content of some + arbitrary number of header fields; + typically some combination of source + address, destination address, DS field, + protocol ID, source port and destination + port. + + Per-Hop-Behavior (PHB) the externally observable forwarding + behavior applied at a DS-compliant 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 + queue servicing or queue management policy. + A PHB group provides a service building + block that allows a set of related + forwarding behaviors to be specified + together (e.g., four dropping priorities). + A single PHB is a special case of a PHB + group. + + Policing the process of discarding packets (by a + dropper) within a traffic stream in + accordance with the state of a + corresponding meter enforcing a traffic + profile. + + Pre-mark to set the DS codepoint of a packet prior + to entry into a downstream DS domain. + + + +Blake, et. al. Informational [Page 6] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + Provider DS domain the DS-capable provider of services to a + source domain. + + Re-mark to change the DS codepoint of a packet, + usually performed by a marker in accordance + with a TCA. + + 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 + forwarding service a customer should + receive. A customer may be a user + organization (source domain) or another DS + domain (upstream domain). A SLA may + include traffic conditioning rules which + constitute a TCA in whole or in part. + + Service Provisioning a policy which defines how traffic + Policy conditioners are configured on DS boundary + nodes and how traffic streams are mapped to + DS behavior aggregates to achieve a range + of services. + + Shaper a device that performs shaping. + + Shaping the process of delaying packets within a + traffic stream to cause it to conform to + some defined traffic profile. + + Source domain a domain which contains the node(s) + originating the traffic receiving a + particular service. + + Traffic conditioner an entity which performs traffic + conditioning functions and which may + contain meters, markers, droppers, and + shapers. Traffic conditioners are typically + deployed in DS boundary nodes only. A + traffic conditioner may re-mark a traffic + stream or may discard or shape packets to + alter the temporal characteristics of the + stream and bring it into compliance with a + traffic profile. + + + + + +Blake, et. al. Informational [Page 7] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + Traffic conditioning control functions performed to enforce + rules specified in a TCA, including + metering, marking, shaping, and policing. + + Traffic Conditioning an agreement specifying classifier rules + Agreement (TCA) and any corresponding traffic profiles and + metering, marking, discarding and/or + shaping rules which are to apply to the + traffic streams selected by the classifier. + A TCA encompasses all of the traffic + conditioning rules explicitly specified + within a SLA along with all of the rules + implicit from the relevant service + requirements and/or from a DS domain's + service provisioning policy. + + Traffic profile a description of the temporal 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. + + Upstream DS domain the DS domain upstream of traffic flow on a + boundary link. + +1.3 Requirements + + The history of the Internet has been one of 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 should accommodate a wide variety of services and provisioning + policies, extending end-to-end or within a particular (set of) + network(s), + + o should allow decoupling of the service from the particular + application in use, + + + + +Blake, et. al. Informational [Page 8] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + o should work with existing applications without the need for + application programming interface changes or host software + modifications (assuming suitable deployment of classifiers, + markers, and other traffic conditioning functions), + + o should decouple traffic conditioning and service provisioning + functions from forwarding behaviors implemented within the core + network nodes, + + o should not depend on hop-by-hop application signaling, + + o should 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 should avoid per-microflow or per-customer state within core + network nodes, + + o should utilize only aggregated classification state within the + network core, + + o should permit simple packet classification implementations in core + network nodes (BA classifier), + + o should permit reasonable interoperability with non-DS-compliant + network nodes, + + o should 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 service + differentiation. We classify these alternative models into the + following categories: relative priority marking, service marking, + label switching, Integrated Services/RSVP, and static per-hop + classification. + + Examples of the relative priority marking model include IPv4 + Precedence marking as defined in [RFC791], 802.5 Token Ring priority + [TR], and the default interpretation of 802.1p traffic classes + [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 + + + +Blake, et. al. Informational [Page 9] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + specify the role and importance of boundary nodes and traffic + conditioners, and since our per-hop behavior model permits more + general forwarding behaviors than relative delay or discard priority. + + 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 engineered to satisfy the service request. This model is + subtly different from our architecture. Note that we do not describe + the use of the DS field as an input to route selection. The TOS + markings defined in [RFC1349] 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 (since + the codepoint space is small) and involves configuration of the + "TOS->forwarding behavior" association in each core network node. + Standardizing service markings implies standardizing service + offerings, which is outside the scope of the IETF. Note that + provisions are made in the allocation of the DS codepoint space to + allow for locally significant codepoints which may be used by a + provider to support service marking semantics [DSFIELD]. + + Examples of the label switching (or virtual circuit) model include + Frame Relay, ATM, and MPLS [FRELAY, ATM]. In this model path + forwarding state and traffic management or QoS state is established + for traffic streams on each hop along a network path. Traffic + aggregates of varying granularity are associated with a label + switched path at an ingress node, and packets/cells within each label + switched path are marked with a forwarding label that is used to + lookup the next-hop node, the per-hop forwarding behavior, and the + replacement label at each hop. This model permits finer granularity + resource allocation to traffic streams, since label values are not + globally significant but are only significant on a single link; + therefore resources can be reserved for the aggregate of packets/ + cells received on a link with a particular label, and the label + switching semantics govern the next-hop selection, allowing a traffic + stream to follow a specially engineered path through the network. + This improved granularity comes at the cost of additional management + and configuration requirements to establish and maintain the label + switched paths. In addition, the amount of forwarding state + maintained at each node scales in proportion to the number of edge + nodes of the network in the best case (assuming multipoint-to-point + + + + + +Blake, et. al. Informational [Page 10] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + label switched paths), and it scales in proportion with the square of + the number of edge nodes in the worst case, when edge-edge label + switched paths 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 additional packet + classification and forwarding state on each node along the path + between them [RFC1633, RSVP]. In the absence of state aggregation, + the amount of state on each node scales in proportion to the number + of concurrent reservations, which can be potentially large on high- + speed links. This model also requires application support for the + RSVP signaling protocol. Differentiated services mechanisms can be + utilized to aggregate Integrated Services/RSVP state in the core of + the network [Bernet]. + + A variant of the Integrated Services/RSVP model eliminates the + requirement for hop-by-hop signaling by utilizing only "static" + classification and forwarding policies which are implemented in each + node along a network path. These policies are updated on + administrative timescales and not in response to the instantaneous + mix of microflows active in the network. The state requirements for + this variant are potentially worse than those encountered when RSVP + is used, especially in backbone nodes, since the number of static + policies that might be applicable at a node over time may be larger + than the number of active sender-receiver sessions that might have + installed reservation state on a node. Although the support of large + numbers of classifier rules and forwarding policies may be + computationally feasible, the management burden associated with + installing and maintaining these rules on each node within a backbone + network which might be traversed by a traffic stream is substantial. + + Although we contrast our architecture with these alternative models + of service differentiation, it should be noted that links and nodes + employing these techniques may be utilized to extend differentiated + services behaviors and semantics across a layer-2 switched + infrastructure (e.g., 802.1p LANs, Frame Relay/ATM backbones) + interconnecting DS nodes, and in the case of MPLS may be used as an + alternative intra-domain implementation technology. The constraints + imposed by the use of a specific link-layer technology in particular + regions of a DS domain (or in a network providing access to DS + domains) may imply the differentiation of traffic on a coarser grain + basis. Depending on the mapping of PHBs to different link-layer + services and the way in which packets are scheduled over a restricted + set of priority classes (or virtual circuits of different category + and capacity), all or a subset of the PHBs in use may be supportable + (or may be indistinguishable). + + + + +Blake, et. al. Informational [Page 11] + +RFC 2475 Architecture for Differentiated Services December 1998 + + +2. Differentiated Services Architectural Model + + The differentiated services architecture is based on a simple model + where traffic entering a network is classified and possibly + conditioned at the boundaries of the network, and assigned to + different behavior aggregates. Each behavior aggregate is identified + by 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 within + a differentiated services region, traffic classification and + conditioning functions, and how differentiated services are achieved + through the combination of traffic conditioning and PHB-based + forwarding. + +2.1 Differentiated Services Domain + + A DS domain is a contiguous set of DS nodes which operate with a + common service provisioning policy and set of PHB groups implemented + on each node. A DS domain has a well-defined boundary consisting of + DS boundary nodes which classify and possibly condition ingress + traffic to ensure that packets which transit the domain are + appropriately marked to select a PHB from one of the PHB groups + supported within the domain. Nodes within the DS domain select the + forwarding behavior for packets based on their DS codepoint, mapping + that value to one of the supported PHBs using either the recommended + codepoint->PHB mapping or a locally customized mapping [DSFIELD]. + Inclusion of non-DS-compliant nodes within a DS domain may result in + unpredictable performance and may impede the ability to satisfy + service level agreements (SLAs). + + A DS domain normally consists of one or more networks under the same + administration; for example, an organization's intranet or an ISP. + 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.1 DS Boundary Nodes and Interior Nodes + + A DS domain consists of DS boundary nodes and DS interior nodes. DS + boundary nodes interconnect the DS domain to other DS or non-DS- + capable domains, whilst DS interior nodes only connect to other DS + interior or boundary nodes within the same DS domain. + + Both DS boundary nodes and interior nodes must be able to apply the + appropriate PHB to packets based on the DS codepoint; otherwise + unpredictable behavior may result. In addition, DS boundary nodes + may be required to perform traffic conditioning functions as defined + by a traffic conditioning agreement (TCA) between their DS domain and + + + +Blake, et. al. Informational [Page 12] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + the peering domain which they connect to (see Sec. 2.3.3). + + Interior nodes may be able to perform limited traffic conditioning + functions such as DS codepoint re-marking. Interior nodes which + implement more complex classification and traffic conditioning + functions are analogous to DS boundary nodes (see Sec. 2.3.4.4). + + A host in a network containing a DS domain may act as a DS boundary + node for traffic from applications running on that host; we therefore + say that the host is within the DS domain. If a host does not act as + a boundary node, then the DS node topologically closest to that host + acts as the DS boundary node for that host's traffic. + +2.1.2 DS Ingress Node and Egress Node + + DS boundary nodes act both as a DS ingress node and as a DS egress + node for different directions of traffic. 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 any TCA between it and the other domain to + which the ingress node is connected. A DS egress node may perform + traffic conditioning functions on traffic forwarded to a directly + connected peering domain, depending on the details of the TCA between + the two domains. Note that a DS boundary node may act as a DS + interior node for some set of interfaces. + +2.2 Differentiated Services Region + + A differentiated services region (DS Region) is a set of one or more + contiguous DS domains. DS regions are capable of supporting + differentiated services along paths which span the domains within the + region. + + The DS domains in a DS region may support different PHB groups + internally and different codepoint->PHB mappings. However, to permit + services which span across the domains, the peering DS domains must + each establish a peering SLA which defines (either explicitly or + implicitly) a TCA which specifies how transit traffic from one DS + domain to another is conditioned at the boundary between the two DS + domains. + + It is possible that several DS domains within a DS region may adopt a + common service provisioning policy and may support a common set of + PHB groups and codepoint mappings, thus eliminating the need for + traffic conditioning between those DS domains. + + + + + + +Blake, et. al. Informational [Page 13] + +RFC 2475 Architecture for Differentiated Services December 1998 + + +2.3 Traffic Classification and Conditioning + + Differentiated services are extended across a DS domain boundary by + establishing a SLA between an upstream network and a downstream DS + domain. The SLA may specify packet classification and re-marking + rules and may also specify traffic profiles and actions to traffic + streams which are in- or out-of-profile (see Sec. 2.3.2). The TCA + between the domains is derived (explicitly or implicitly) from this + SLA. + + The packet classification policy identifies the subset of traffic + which may receive a differentiated service by being conditioned and/ + or mapped to one or more behavior aggregates (by DS codepoint re- + marking) within the DS domain. + + Traffic conditioning performs metering, shaping, policing and/or re- + marking to ensure that the traffic entering the DS domain conforms to + the rules specified in the TCA, in accordance with the domain's + service provisioning policy. The extent of traffic conditioning + required is dependent on the specifics of the service offering, and + may range from simple codepoint re-marking to complex policing and + shaping operations. The details of traffic conditioning policies + which are negotiated between networks is outside the scope of this + document. + +2.3.1 Classifiers + + Packet classifiers select packets in a traffic stream based on the + content of some portion of the packet header. We define two types of + classifiers. The BA (Behavior Aggregate) Classifier classifies + packets based on the DS codepoint only. The MF (Multi-Field) + classifier selects packets based on the value of a combination of one + or more header fields, such as source address, destination address, + DS field, protocol ID, source port and destination port numbers, and + other information such as incoming interface. + + Classifiers are used to "steer" packets matching some specified rule + to an element of a 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, MF + 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 + + + +Blake, et. al. Informational [Page 14] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + fragmentation state; however, this is not a general solution due to + the possibility of upstream fragment re-ordering or divergent routing + paths. The policy to apply to packet fragments is outside the scope + of this document. + +2.3.2 Traffic Profiles + + A traffic profile specifies the temporal properties of a traffic + stream selected by a classifier. It provides rules for determining + whether a particular packet is in-profile or out-of-profile. For + example, a profile based on a token bucket may look like: + + codepoint=X, use token-bucket r, b + + The above profile indicates that all packets marked 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 traffic stream which arrive when insufficient tokens + are available in the bucket. The concept of in- and out-of-profile + can be extended to more than two levels, e.g., multiple levels of + conformance with a profile may be defined and enforced. + + Different conditioning actions may be applied to the in-profile + packets and out-of-profile packets, or different accounting actions + may be triggered. In-profile packets may be allowed to enter the DS + domain without further conditioning; or, alternatively, their DS + codepoint may be changed. The latter happens when the DS codepoint + 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 or + codepoint->PHB mapping policy for this traffic stream. Out-of- + profile packets may be queued until they are in-profile (shaped), + discarded (policed), marked with a new codepoint (re-marked), or + forwarded unchanged while triggering some accounting procedure. + Out-of-profile packets may be mapped to one or more behavior + aggregates that are "inferior" in some dimension of forwarding + performance to the BA into which in-profile packets are mapped. + + Note that a traffic profile is an optional component of a TCA and its + use is dependent on the specifics of the service offering and the + domain's service provisioning policy. + +2.3.3 Traffic Conditioners + + A traffic conditioner may contain the following elements: meter, + marker, shaper, and dropper. A traffic stream is selected by a + classifier, which steers the packets to a logical instance of a + traffic conditioner. A meter is used (where appropriate) to measure + the traffic stream against a traffic profile. The state of the meter + + + +Blake, et. al. Informational [Page 15] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + with respect to a particular packet (e.g., whether it is in- or out- + of-profile) may be used to affect a marking, dropping, or shaping + action. + + When packets exit the traffic conditioner of a DS boundary node the + DS codepoint of each packet must be set to an appropriate value. + + Fig. 1 shows the block diagram of a classifier and traffic + conditioner. Note that a traffic conditioner may not necessarily + contain all four elements. For example, in the case where no traffic + profile is in effect, packets may only pass through a classifier and + a marker. + + +-------+ + | |-------------------+ + +----->| Meter | | + | | |--+ | + | +-------+ | | + | V V + +------------+ +--------+ +---------+ + | | | | | Shaper/ | + packets =====>| Classifier |=====>| Marker |=====>| Dropper |=====> + | | | | | | + +------------+ +--------+ +---------+ + + + Fig. 1: Logical View of a Packet Classifier and Traffic Conditioner + +2.3.3.1 Meters + + Traffic meters measure the temporal properties of the stream of + packets selected by a classifier against a traffic profile specified + in a TCA. A meter passes state information to other conditioning + functions to trigger a particular action for each packet which is + either in- or out-of-profile (to some extent). + +2.3.3.2 Markers + + Packet markers set the DS field of a packet to a particular + codepoint, adding the marked packet to a particular DS behavior + 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 used to select a PHB in a PHB + group, according to the state of a meter. When the marker changes + the codepoint in a packet it is said to have "re-marked" the packet. + + + + + + +Blake, et. al. Informational [Page 16] + +RFC 2475 Architecture for Differentiated Services December 1998 + + +2.3.3.3 Shapers + + Shapers delay some or all of the packets in a traffic stream in order + to bring the stream into compliance with a traffic profile. A shaper + usually has a finite-size buffer, and packets may be discarded if + there is not sufficient buffer space to hold the delayed packets. + +2.3.3.4 Droppers + + Droppers discard some or all of the packets in a traffic stream in + order to bring the stream into compliance with a traffic profile. + This process is know as "policing" the stream. Note that a dropper + can be implemented as a special case of a shaper by setting the + shaper buffer size to zero (or a few) packets. + +2.3.4 Location of Traffic Conditioners and MF Classifiers + + Traffic conditioners are usually located within DS ingress and egress + boundary nodes, but may also be located in nodes within the interior + of a DS domain, or within a non-DS-capable domain. + +2.3.4.1 Within the Source Domain + + We define the source domain as the domain containing the node(s) + which originate the traffic receiving a particular service. Traffic + sources and intermediate nodes within a source domain may perform + traffic classification and conditioning functions. The traffic + originating from the source domain across a boundary may be marked by + the traffic sources directly or by intermediate nodes before leaving + the source domain. This is referred to as initial marking or "pre- + marking". + + Consider the example of a company that has the policy that its 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. Such high priority + traffic may also be conditioned near the source so that there is a + limit on the amount of high priority traffic forwarded from a + particular source. + + There are some advantages to marking packets 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 + + + + + +Blake, et. al. Informational [Page 17] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + 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 multiple nodes, the + source 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 provider's network [2BIT, Bernet]. + The boundary node of the source domain should also monitor + conformance to the TCA, and may police, shape, or re-mark packets as + necessary. + +2.3.4.2 At the Boundary of a DS Domain + + Traffic streams may be classified, marked, and otherwise conditioned + on either end of a boundary link (the DS egress node of the upstream + domain or the DS ingress node of the downstream domain). The SLA + 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 appropriate + 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. + + When packets are pre-marked and conditioned in the upstream domain, + potentially fewer classification and traffic conditioning rules need + to be supported in the downstream DS domain. In this circumstance + the downstream DS domain may only need to re-mark or police the + incoming behavior aggregates to enforce the TCA. However, more + sophisticated services which are path- or source-dependent may + require MF classification in the downstream DS domain's ingress + nodes. + + If a DS ingress node is connected to an upstream non-DS-capable + domain, the DS ingress node must be able to perform all necessary + traffic conditioning functions on the incoming traffic. + +2.3.4.3 In non-DS-Capable Domains + + Traffic sources or intermediate nodes in a non-DS-capable domain may + employ traffic conditioners to pre-mark traffic before it reaches the + ingress of a downstream DS domain. In this way the local policies + for classification and marking may be concealed. + + + + + + +Blake, et. al. Informational [Page 18] + +RFC 2475 Architecture for Differentiated Services December 1998 + + +2.3.4.4 In Interior DS Nodes + + Although the basic architecture assumes that complex classification + and traffic conditioning functions are located only in a network's + ingress and egress boundary nodes, deployment of these functions in + the interior of the network is not precluded. For example, more + restrictive access policies may be enforced on a transoceanic link, + requiring MF classification and traffic conditioning functionality in + the upstream node on the link. This approach may have scaling + limits, due to the potentially large number of classification and + conditioning rules that might need to be maintained. + +2.4 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 often 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 mainly 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 + more complex PHB would guarantee a minimal bandwidth allocation of X% + of a link, with proportional fair sharing of any excess link + capacity. 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). + These PHBs may be used as building blocks to allocate resources and + should be specified as a group (PHB group) for consistency. PHB + groups will usually share a common constraint applying to each PHB + within the group, such as a packet scheduling or buffer management + policy. The relationship between PHBs in a group may be in terms of + absolute or relative priority (e.g., discard priority by means of + + + +Blake, et. al. Informational [Page 19] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + deterministic or stochastic thresholds), but this is not required + (e.g., N equal link shares). A single PHB defined in isolation is a + special case of a PHB group. + + PHBs are implemented in nodes by means of some buffer management and + packet scheduling mechanisms. PHBs are 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. A + PHB group definition should indicate possible conflicts with + previously documented PHB groups which might prevent simultaneous + operation. + + As described in [DSFIELD], a PHB is selected at a node by a mapping + of the DS codepoint in a received packet. Standardized PHBs have a + recommended codepoint. However, the total space of codepoints is + larger than the space available for recommended codepoints for + standardized PHBs, and [DSFIELD] leaves provisions for locally + configurable mappings. A codepoint->PHB mapping table may contain + both 1->1 and N->1 mappings. All codepoints must be mapped to some + PHB; in the absence of some local policy, codepoints which are not + mapped to a standardized PHB in accordance with that PHB's + specification should be mapped to the Default PHB. + +2.5 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 behavior aggregates, in accordance with the domain's + service provisioning policy. Traffic conditioners can further + control the usage of these resources through enforcement of TCAs and + possibly through operational feedback from the nodes and traffic + conditioners in the domain. Although a range of services can be + deployed in the absence of complex traffic conditioning functions + (e.g., using only static marking policies), functions such as + policing, shaping, and dynamic re-marking enable the deployment of + services providing quantitative performance metrics. + + The configuration of and interaction between traffic conditioners and + 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. + + + +Blake, et. al. Informational [Page 20] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + 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 slowly varying 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 Specification Guidelines + + Basic requirements for per-hop behavior standardization are given in + [DSFIELD]. This section elaborates on that text by describing + additional guidelines for PHB (group) specifications. This is + intended to help foster implementation consistency. Before a PHB + group is proposed for standardization it should satisfy these + guidelines, as appropriate, to preserve the integrity of this + architecture. + + G.1: A PHB standard must specify a recommended DS codepoint selected + from the codepoint space reserved for standard mappings [DSFIELD]. + Recommended codepoints will be assigned by the IANA. A PHB proposal + may recommend a temporary codepoint from the EXP/LU space to + facilitate inter-domain experimentation. Determination of a packet's + PHB must not require inspection of additional packet header fields + beyond the DS field. + + G.2: The specification of each newly proposed PHB group should + include an overview of the behavior and the purpose of the behavior + being proposed. The overview should include a problem or problems + statement for which the PHB group is targeted. The overview should + 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 + should specify the method by which the PHB group solves the problem + or problems specified in the problem statement. + + G.3: A PHB group specification should indicate the number of + individual PHBs specified. In the event that multiple PHBs are + specified, the interactions between these PHBs and constraints that + must be respected globally by all the PHBs within the group should be + clearly specified. As an example, the specification must indicate + whether the probability of packet reordering within a microflow is + increased if different packets in that microflow are marked for + different PHBs within the group. + + + + +Blake, et. al. Informational [Page 21] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + G.4: When proper functioning of a PHB group is dependent on + constraints such as a provisioning restriction, then the PHB + definition should describe the behavior when these constraints are + violated. Further, if actions such as packet discard or re-marking + are required when these constraints are violated, then these actions + should be specifically stipulated. + + G.5: A PHB group may be specified for local use within a domain in + order to provide some domain-specific functionality or domain- + specific services. In this event, the PHB specification is useful + for providing vendors with a consistent definition of the PHB group. + However, any PHB group which is defined for local use should not be + considered for standardization, but may be published as an + Informational RFC. In contrast, a PHB group which is intended for + general use will follow a stricter standardization process. + Therefore all PHB proposals should specifically state whether they + are to be considered for general 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, and/or domain edge-to- + domain edge services. Use of the term "end-to-end" in a PHB + definition should be interpreted to mean "host-to-host" for + consistency. + + 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 publicly documented, but they should + utilize DS codepoints from one of the EXP/LU pools as defined in + [DSFIELD]. + + G.6: It may be possible or appropriate for a packet marked for a PHB + within a PHB group to be re-marked to select another PHB within the + group; either within a domain or across a domain boundary. Typically + there are three reasons for such PHB modification: + + a. The codepoints associated with the PHB group are collectively + intended to carry state about the network, + b. Conditions exist which require PHB promotion or demotion of a + packet (this assumes that PHBs within the group can be ranked in + some order), + c. The boundary between two domains is not covered by a SLA. In this + case the codepoint/PHB to select when crossing the boundary link + will be determined by the local policy of the upstream domain. + + A PHB specification should clearly state the circumstances under + which packets marked for a PHB within a PHB group may, or should be + modified (e.g., promoted or demoted) to another PHB within the group. + If it is undesirable for a packet's PHB to be modified, the + + + +Blake, et. al. Informational [Page 22] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + specification should clearly state the consequent risks when the PHB + is modified. A possible risk to changing a packet's PHB, either + within or outside a PHB group, is a higher probability of packet re- + ordering within a microflow. PHBs within a group may carry some + host-to-host, WAN edge-to-WAN edge, and/or domain edge-to-domain edge + semantics which may be difficult to duplicate if packets are re- + marked to select another PHB from the group (or otherwise). + + For certain PHB groups, it may be appropriate to reflect a state + change in the node by re-marking packets to specify another PHB from + within the group. If a PHB group is designed to reflect the state of + a network, the PHB definition must adequately describe the + relationship between the PHBs and the states they reflect. Further, + if these PHBs limit the forwarding actions a node can perform in some + way, these constraints may be specified as actions the node should, + or must perform. + + G.7: A PHB group specification should include a section defining the + implications of tunneling on the utility of the PHB group. This + section should specify the implications for the utility of the PHB + group of a newly created outer header when the original DS field 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 codepoints from the + inner header and the outer header are accessible (see Sec. 6.2). + + G.8: The process of specifying PHB groups is likely to be + incremental in nature. When new PHB groups are proposed, their known + interactions with previously specified PHB groups should 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 + specifications, a section should be included in the PHB specification + which details how the new PHB group can co-exist with those PHB + groups already standardized. For example, this section might + indicate the possibility of packet re-ordering within a microflow for + packets marked by codepoints associated with two separate PHB groups. + If concurrent operation of two (or more) different PHB groups in the + same node is impossible or detrimental this should be stated. If the + concurrent operation of two (or more) different PHB groups requires + some specific behaviors by the node when packets marked for PHBs from + these different PHB groups are being processed by the node at the + same time, these behaviors should be stated. + + Care should be taken to avoid circularity in the definitions of PHB + groups. + + + + + +Blake, et. al. Informational [Page 23] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + If the proposed PHB group is an extension to an existing PHB group, a + section should be included in the PHB group specification which + details how this extension interoperates with the behavior being + extended. Further, if the extension alters or more narrowly defines + the existing behavior in some way, this should also be clearly + indicated. + + G.9: Each PHB specification should include a section specifying + minimal conformance requirements for implementations of 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 + specification. This conformance section can take the form of rules, + tables, pseudo-code, or tests. + + G.10: A PHB specification should include a section detailing the + security implications of the behavior. This section should include a + discussion of the re-marking of the inner header's codepoint at the + egress of a tunnel and its effect on the desired forwarding behavior. + + 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 possible means for detecting such attacks + as they are relevant to the proposed behavior. + + G.11: A PHB specification should include a section detailing + configuration and management issues which may affect the operation of + the PHB and which may impact candidate services that might utilize + the PHB. + + G.12: It is strongly recommended that an appendix be provided with + each PHB specification 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. + + G.13: It is recommended that an appendix be provided with each PHB + specification that is targeted for local use within a domain, + providing guidance for PHB selection for packets which are forwarded + into a peer domain which does not support the PHB group. + + + + + + + + +Blake, et. al. Informational [Page 24] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + G.14: It is recommended that an appendix be provided with each PHB + specification which considers the impact of the proposed PHB group on + existing higher-layer protocols. Under some circumstances PHBs may + allow for possible changes to higher-layer protocols which may + increase or decrease the utility of the proposed PHB group. + + G.15: It is recommended that an appendix be provided with each PHB + specification which recommends mappings to link-layer QoS mechanisms + to support the intended behavior of the PHB across a shared-medium or + switched link-layer. The determination of the most appropriate + mapping between a PHB and a link-layer QoS mechanism is dependent on + many factors and is outside the scope of this document; however, the + specification should attempt to offer some guidance. + +4. Interoperability with Non-Differentiated Services-Compliant Nodes + + We define a non-differentiated services-compliant node (non-DS- + compliant node) as any node which does not interpret the DS field as + specified in [DSFIELD] and/or does not implement some or all of the + standardized PHBs (or those in use within a particular DS domain). + This may be due to the capabilities or configuration of the node. We + define a legacy node as a special case of a non-DS-compliant node + which implements IPv4 Precedence classification and forwarding as + defined in [RFC791, RFC1812], but which is otherwise not DS- + compliant. The precedence values in the IPv4 TOS octet are + compatible by intention with the Class Selector Codepoints defined in + [DSFIELD], and the precedence forwarding behaviors defined in + [RFC791, RFC1812] comply with the Class Selector PHB Requirements + also defined in [DSFIELD]. A key distinction between a legacy node + and a DS-compliant node is that the legacy node may or may not + interpret bits 3-6 of the TOS octet as defined in [RFC1349] (the + "DTRC" bits); in practice it will not interpret these bit as + specified in [DSFIELD]. We assume that the use of the TOS markings + defined in [RFC1349] is deprecated. Nodes which are non-DS-compliant + and which are not legacy nodes may exhibit unpredictable forwarding + behaviors for packets with non-zero DS codepoints. + + Differentiated services depend on the resource allocation mechanisms + provided by per-hop behavior implementations in nodes. The quality + or statistical assurance level of a service may break down in the + event that traffic transits a non-DS-compliant node, or a non-DS- + capable domain. + + We will examine two separate cases. The first case concerns the use + of non-DS-compliant 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 + + + +Blake, et. al. Informational [Page 25] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + negligible, and the use of a non-DS-compliant 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 Class Selector + Codepoints defined in [DSFIELD], and assuming that the particular + precedence implementation in the legacy node provides forwarding + behaviors which are compatible with the services offered along paths + which traverse that node. Note that it is important to restrict the + codepoints in use to the Class Selector Codepoints, since the legacy + node may or may not interpret bits 3-5 in accordance with [RFC1349], + thereby resulting in unpredictable forwarding results. + + 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 boundary nodes; therefore, even in the event that the + domain consists of legacy or DS-compliant interior nodes, the lack of + traffic enforcement at the boundaries 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 of the Class Selector Codepoints. Where there is no + knowledge of the traffic management capabilities of the downstream + domain, and no agreement in place, a DS domain egress node may choose + to re-mark DS codepoints 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 domain 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 + + Use of differentiated services by multicast traffic introduces a + number of issues for service provisioning. First, multicast packets + which enter a DS domain at an ingress node may simultaneously take + multiple paths through some segments of the domain due to multicast + packet replication. In this way they consume more network resources + + + +Blake, et. al. Informational [Page 26] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + than unicast packets. Where multicast group membership is dynamic, + it is difficult to predict in advance the amount of network resources + that may be consumed by multicast traffic originating from an + upstream network for a particular group. A consequence of this + uncertainty is that it may be difficult to provide quantitative + service guarantees to multicast senders. Further, it may be + necessary to reserve codepoints and PHBs for exclusive use by unicast + traffic, to provide resource isolation from multicast traffic. + + The second issue is the selection of the DS codepoint for a multicast + packet arriving at a DS ingress node. Because that packet may exit + the DS domain at multiple DS egress nodes which peer with multiple + downstream domains, the DS codepoint used should not result in the + request for a service from a downstream DS domain which is in + violation of a peering SLA. When establishing classifier and traffic + conditioner state at an DS ingress node for an aggregate of traffic + receiving a differentiated service which spans across the egress + boundary of the domain, the identity of the adjacent downstream + transit domain and the specifics of the corresponding peering SLA can + be factored into the configuration decision (subject to routing + policy and the stability of the routing infrastructure). In this way + peering SLAs with downstream DS domains can be partially enforced at + the ingress of the upstream domain, reducing the classification and + traffic conditioning burden at the egress node of the upstream + domain. This is not so easily performed in the case of multicast + traffic, due to the possibility of dynamic group membership. The + result is that the service guarantees for unicast traffic may be + impacted. One means of addressing this problem is to establish a + separate peering SLA for multicast traffic, and to either utilize a + particular set of codepoints for multicast packets, or to implement + the necessary classification and traffic conditioning mechanisms in + the DS egress nodes to provide preferential isolation for unicast + traffic in conformance with the peering SLA with the downstream + domain. + +6. Security and Tunneling Considerations + + This section addresses security issues raised by the introduction of + differentiated services, primarily the potential for denial-of- + service attacks, and the related potential for theft of service by + unauthorized traffic (Sec. 6.1). In addition, the operation of + differentiated services in the presence of IPsec and its interaction + with IPsec are also discussed (Sec. 6.2), as well as auditing + requirements (Sec. 6.3). This section considers issues introduced by + the use of both IPsec and non-IPsec tunnels. + + + + + + +Blake, et. al. Informational [Page 27] + +RFC 2475 Architecture for Differentiated Services December 1998 + + +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 codepoints indicating behaviors + used for enhanced services or by injecting packets with the DS field + set to such codepoints. 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 the combination of traffic conditioning + at DS boundary nodes along with security and integrity of the network + infrastructure within a DS domain. + + As described in Sec. 2, DS ingress nodes must condition all traffic + entering a DS domain to ensure that it has acceptable DS codepoints. + This means that the codepoints must conform to the applicable TCA(s) + and the domain's service provisioning policy. Hence, the ingress + nodes are the primary line of defense against theft- and denial-of- + service attacks based on modified DS codepoints (e.g., codepoints to + which the traffic is not entitled), as success of any such attack + constitutes a violation of the applicable TCA(s) and/or service + provisioning policy. 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 all originated traffic carries + acceptable DS codepoints. + + Both a domain's service provisioning policy and TCAs may require the + ingress nodes to change the DS codepoint on some entering packets + (e.g., an ingress router may set the DS codepoint of a customer's + traffic in accordance with the appropriate SLA). Ingress nodes must + condition all other inbound traffic to ensure that the DS codepoints + are acceptable; packets found to have unacceptable codepoints must + either be discarded or must have their DS codepoints 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 codepoint to the Default PHB + codepoint [DSFIELD]. Traffic authentication may be required to + validate the use of some DS codepoints (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 + inbound link is known to be connected to exactly one customer site). + + + +Blake, et. al. Informational [Page 28] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + An inter-domain agreement may reduce or eliminate the need for + ingress node traffic conditioning by making the upstream domain + partly or completely responsible for ensuring that traffic has DS + codepoints acceptable to the downstream domain. In this case, the + ingress node may still perform redundant traffic conditioning 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 such a 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 codepoint 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 codepoints. Robustness concerns dictate that the + arrival of packets with unacceptable DS codepoints 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 codepoints + before using them. Interior nodes may perform some traffic + conditioning checks on DS codepoints (e.g., check for DS codepoints + that are never used for traffic on a specific link) to improve + security and robustness (e.g., resistance to theft-of-service attacks + based on DS codepoint modifications). 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 codepoint 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 + codepoints 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 codepoint 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. + + + + +Blake, et. al. Informational [Page 29] + +RFC 2475 Architecture for Differentiated Services December 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), as 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 tunnel 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. If + the inner IP header has not been processed by a DS ingress node for + the tunnel egress node's DS domain, the tunnel egress node is the DS + ingress node for traffic exiting the tunnel, and hence must carry out + the corresponding traffic conditioning responsibilities (see Sec. + 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. This allows + a tunnel egress node in the same DS domain as the tunnel ingress + node, to safely treat a packet passing such an integrity check as if + it had arrived from another node within the same DS domain, omitting + the DS ingress node traffic conditioning that would otherwise be + required. An important consequence is that otherwise insecure links + internal to a DS domain 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 + + + +Blake, et. al. Informational [Page 30] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + 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. + + The IPsec protocol currently requires that the inner header's DS + field not be changed by IPsec decapsulation processing at a 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. This document makes no change to + that IPsec requirement. + + If the IPsec specifications are modified in the future to permit a + tunnel egress node to modify the DS field in an inner IP header based + on the DS field value in the outer header (e.g., copying part or all + of the outer DS field to the inner DS field), then additional + considerations would apply. 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 inner + DS field modifications would be those imposed by the domain's service + provisioning policy. Otherwise, the tunnel egress node performing + such modifications would be acting as a DS ingress node for traffic + exiting the tunnel and must carry out the traffic conditioning + responsibilities of an ingress node, including defense against theft- + and denial-of-service attacks (See Sec. 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 that the outer DS field values are acceptable. Even in this + case, there are some checks that can only be performed by the tunnel + egress node (e.g., a consistency check between the inner and outer DS + codepoints 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 codepoint that was unacceptable. + + An IPsec tunnel can be viewed in at least two different ways from an + architectural perspective. If the tunnel is viewed as a logical + single hop "virtual wire", the actions of intermediate nodes in + forwarding the tunneled traffic should not be visible beyond the ends + of the tunnel and hence the DS field should not be modified as part + of decapsulation processing. In contrast, if the tunnel is viewed as + a multi-hop participant in forwarding traffic, then modification of + the DS field as part of tunnel decapsulation processing may be + desirable. A specific example of the latter situation occurs when a + tunnel terminates at an interior node of a DS domain at which the + domain administrator does not wish to deploy traffic conditioning + + + +Blake, et. al. Informational [Page 31] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + logic (e.g., to simplify traffic management). This could be + supported by using the DS codepoint in the outer IP header (which was + subject to traffic conditioning at the DS ingress node) to reset the + DS codepoint in the inner IP header, effectively moving DS ingress + traffic conditioning responsibilities from the IPsec tunnel egress + node to the appropriate upstream DS ingress node (which must already + perform that function for unencapsulated traffic). + +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 should also support auditing. + If such support is present the implementation must allow a system + administrator to enable or disable auditing for differentiated + services as a whole, and may allow such auditing to be enabled or + disabled in part. + + 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 (e.g., + packets related to the one that triggered the auditable event) may + also 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 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 + + This document has benefitted from earlier drafts by Steven Blake, + David Clark, Ed Ellesson, Paul Ferguson, Juha Heinanen, Van Jacobson, + Kalevi Kilkki, Kathleen Nichols, Walter Weiss, John Wroclawski, and + Lixia Zhang. + + 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, Borje + Ohlman, Alessio Casati, Scott Brim, Curtis Villamizar, Hamid Ould- + Brahi, Andrew Smith, John Renwick, Werner Almesberger, Alan O'Neill, + James Fu, and Bob Braden. + + + + + + +Blake, et. al. Informational [Page 32] + +RFC 2475 Architecture for Differentiated Services December 1998 + + +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] Kent, S. and R. Atkinson, "IP Authentication Header", RFC + 2402, November 1998. + + [ATM] ATM Traffic Management Specification Version 4.0 <af-tm- + 0056.000>, ATM Forum, April 1996. + + [Bernet] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K. + Nichols, and M. Speer, "A Framework for Use of RSVP with + Diff-serv Networks", Work in Progress. + + [DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, December + 1998. + + [EXPLICIT] D. Clark and W. Fang, "Explicit Allocation of Best Effort + Packet Delivery Service", IEEE/ACM Trans. on Networking, + vol. 6, no. 4, August 1998, pp. 362-373. + + [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security + Payload (ESP)", RFC 2406, November 1998. + + [FRELAY] ANSI T1S1, "DSSI Core Aspects of Frame Rely", March 1990. + + [RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC1349] Almquist, P., "Type of Service in the Internet Protocol + Suite", RFC 1349, July 1992. + + [RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated + Services in the Internet Architecture: An Overview", RFC + 1633, July 1994. + + [RFC1812] Baker, F., Editor, "Requirements for IP Version 4 + Routers", RFC 1812, June 1995. + + [RSVP] Braden, B., Zhang, L., Berson S., Herzog, S. and S. + Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 + Functional Specification", RFC 2205, September 1997. + + + +Blake, et. al. Informational [Page 33] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + [2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit + Differentiated Services Architecture for the Internet", + ftp://ftp.ee.lbl.gov/papers/dsarch.pdf, November 1997. + + [TR] ISO/IEC 8802-5 Information technology - + Telecommunications and information exchange between + 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. + +Authors' Addresses + + Steven Blake + Torrent Networking Technologies + 3000 Aerial Center, Suite 140 + Morrisville, NC 27560 + + Phone: +1-919-468-8466 x232 + EMail: slblake@torrentnet.com + + + David L. Black + EMC Corporation + 35 Parkwood Drive + Hopkinton, MA 01748 + + Phone: +1-508-435-1000 x76140 + EMail: black_david@emc.com + + + Mark A. Carlson + Sun Microsystems, Inc. + 2990 Center Green Court South + Boulder, CO 80301 + + Phone: +1-303-448-0048 x115 + EMail: mark.carlson@sun.com + + + Elwyn Davies + Nortel UK + London Road + Harlow, Essex CM17 9NA, UK + + Phone: +44-1279-405498 + EMail: elwynd@nortel.co.uk + + + + +Blake, et. al. Informational [Page 34] + +RFC 2475 Architecture for Differentiated Services December 1998 + + + Zheng Wang + Bell Labs Lucent Technologies + 101 Crawfords Corner Road + Holmdel, NJ 07733 + + EMail: zhwang@bell-labs.com + + + Walter Weiss + Lucent Technologies + 300 Baker Avenue, Suite 100 + Concord, MA 01742-2168 + + EMail: wweiss@lucent.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blake, et. al. Informational [Page 35] + +RFC 2475 Architecture for Differentiated Services December 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Blake, et. al. Informational [Page 36] + |