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]
`
`GUEST TEK EXHIBIT 1011
`Guest Tek v. Nomadix, IPR2019-00211
`
`

`

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