SAMSUNG 1025
`
`1
`
`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]
`

`

`2
`
`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]
`

`

`3
`
`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]
`

`

`4
`
`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]
`

`

`5
`
`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]
`

`

`6
`
`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]
`

`

`7
`
`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]
`

`

`8
`
`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]
`

`

`9
`
`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]
`

`

`10
`
`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]
`

`

`11
`
`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]
`

`

`12
`
`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]
`

`

`13
`
`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]
`

`

`14
`
`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]
`

`

`15
`
`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