An Architecture for Differentiated Services
draft-ietf-diffserv-arch-01

INTERNET-DRAFT Steven Blake
Diffserv Working Group Torrent Networking Technologies
Expires: February 1999 David Black
 The Open Group 
 Mark Carlson
 Sun Microsystems 
 Elwyn Davies 
 Nortel UK
 Zheng Wang
 Bell Labs Lucent Technologies
 Walter Weiss
 Lucent Technologies
 August 1998
 An Architecture for Differentiated Services
 <draft-ietf-diffserv-arch-01.txt>
Status of This Memo
 This document is an Internet-Draft. Internet-Drafts are working
 documents of the Internet Engineering Task Force (IETF), its areas,
 and its working groups. Note that other groups may also distribute
 working documents as Internet-Drafts.
 Internet-Drafts are draft documents valid for a maximum of six months
 and may be updated, replaced, or obsoleted by other documents at any
 time. It is inappropriate to use Internet-Drafts as reference
 material or to cite them other than as "work in progress."
 To view the entire list of current Internet-Drafts, please check the
 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
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
Blake, et. al. Expires: February 1999 [Page 1]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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.
Table of Contents
 1. Introduction ................................................. 3
 1.1 Overview ................................................. 3
 1.2 Terminology ............................................... 4
 1.3 Requirements .............................................. 8
 1.4 Comparisons with Other Approaches ......................... 9
 2. Differentiated Services Architectural Model .................. 11
 2.1 Differentiated Services Domain ............................ 11
 2.1.1 DS Boundary Nodes and Interior Nodes .................. 12
 2.1.2 DS Ingress Node and Egress Node ....................... 12
 2.2 Differentiated Services Region ............................ 13
 2.3 Traffic Classification and Conditioning ................... 13
 2.3.1 Classifiers ........................................... 13
 2.3.2 Traffic Profiles ...................................... 14
 2.3.3 Traffic Conditioners .................................. 15
 2.3.3.1 Meters ............................................ 15
 2.3.3.2 Markers ........................................... 15
 2.3.3.3 Shapers ........................................... 16
 2.3.3.4 Droppers .......................................... 16
 2.3.4 Location of Traffic Conditioners and MF Classifiers ... 16
 2.3.4.1 Within the Source Domain .......................... 16
 2.3.4.2 At the Boundary of a DS Domain .................... 17
 2.3.4.3 In non-DS-Capable Domains ......................... 17
 2.3.4.4 In Interior DS Nodes .............................. 17
 2.4 Per-Hop Behaviors ......................................... 18
 2.5 Network Resource Allocation ............................... 19
 3. Per-Hop Behavior Specification Guidelines .................... 20
 4. Interoperability with Non-Differentiated Services-Compliant
 Nodes ........................................................ 23
 5. Multicast Considerations ..................................... 25
 6. Security and Tunneling Considerations ........................ 26
 6.1 Theft and Denial of Service ............................... 26
 6.2 IPsec and Tunneling Interactions .......................... 28
 6.3 Auditing .................................................. 30
 7. Acknowledgements ............................................. 30
 8. References ................................................... 31
 Authors Addresses' ............................................... 33
 Full Copyright Statement ......................................... 34
Blake, et. al. Expires: February 1999 [Page 2]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
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
 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].
 
Blake, et. al. Expires: February 1999 [Page 3]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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 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.
 This document should be read along with its companion documents, the
 differentiated services framework [DSFWK], the definition of the DS
 field [DSFIELD], and other documents which specify per-hop behaviors.
 It has been heavily influenced by the thoughtful proposals of
 previous authors [Ellesson, EXPLICIT, Ferguson, Heinanen, SIMA, 2BIT,
 Weiss].
1.2 Terminology
 This section gives a general conceptual overview of the terms used
 in this document. Some of these terms are more precisely defined in
 later sections of this document. The choice of terms and definitions
 were influenced by [MPLSFWK].
 Behavior Aggregate (BA) a DS behavior aggregate.
 BA classifier a classifier that selects packets based
 only on the contents of the DS field.
 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.
 
Blake, et. al. Expires: February 1999 [Page 4]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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.
 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. 
Blake, et. al. Expires: February 1999 [Page 5]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 Mechanism a specific algorithm or operation (e.g.,
 queueing discipline) that is implemented in
 a node to realize a set of one or more per-
 hop behaviors.
 Meter a 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 in a TCA.
Blake, et. al. Expires: February 1999 [Page 6]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 Pre-mark to set the DS codepoint of a packet prior
 to entry into a downstream DS domain.
 Provider DS domain the DS-capable service provider of 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 details
 of a TCA and the corresponding forwarding
 service a customer should receive. A
 customer may be a user organization (source
 domain) or another DS domain (upstream
 domain). 
 Service Provisioning a policy which defines how traffic
 Policy (SPP) 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.
 Traffic conditioning control functions performed to enforce
 rules specified in a TCA, including
 metering, marking, shaping, and policing.
Blake, et. al. Expires: February 1999 [Page 7]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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.
 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,
 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
Blake, et. al. Expires: February 1999 [Page 8]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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
 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
Blake, et. al. Expires: February 1999 [Page 9]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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, MPLSTE]. 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
 [MPLSTE]. 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 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
Blake, et. al. Expires: February 1999 [Page 10]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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).
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
Blake, et. al. Expires: February 1999 [Page 11]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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 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.
Blake, et. al. Expires: February 1999 [Page 12]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
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 includes 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.
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 will generally include a traffic conditioning
 agreement which specifies packet classification and re-marking policy
 and may also specify traffic profiles and actions to traffic streams
 which are in- or out-of-profile (see Sec. 2.3.2).
 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,
Blake, et. al. Expires: February 1999 [Page 13]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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
 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) which is to be mapped to a behavior
 aggregate. 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 which in-profile packets are mapped to.
Blake, et. al. Expires: February 1999 [Page 14]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 
 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
 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
Blake, et. al. Expires: February 1999 [Page 15]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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.
 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
Blake, et. al. Expires: February 1999 [Page 16]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 application's preferences into account when deciding which packets
 should receive better forwarding treatment. Also, classification of
 packets is much simpler before the traffic has been aggregated with
 packets from other sources, since the number of classification rules
 which need to be applied within a single node is reduced.
 Since packet marking may be distributed across 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 TCA
 between the domains should specify which domain has responsibility
 for mapping traffic streams to DS behavior aggregates and
 conditioning those aggregates in conformance with the TCA. However,
 a DS ingress node must assume that the incoming traffic may not
 conform to the TCA and must be prepared to enforce the TCA in
 accordance with local policy.
 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.
 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
Blake, et. al. Expires: February 1999 [Page 17]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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 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
Blake, et. al. Expires: February 1999 [Page 18]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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.
 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 have
 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
 [DSFWK]. The precise nature and implementation of the interaction
 between these components is outside the scope of this architecture.
 However, scalability requires that the control of the domain does not
 require micro-management of the network resources. The most scalable
 control model would operate nodes in open-loop in the operational
 timeframe, and would only require administrative-timescale management
 as SLAs are varied. This simple model may be unsuitable in some
 circumstances, and some automated but slowly varying operational
 control (minutes rather than seconds) may be desirable to balance the
 utilization of the network against the recent load profile.
Blake, et. al. Expires: February 1999 [Page 19]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
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.
 Any configuration or management issues which affect the basic PHB
 definition should be specified in the overview of the behavior. The
 actual details of the management and configuration of PHB groups in
 DS nodes should be addressed in a separate, parallel document.
 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.
 G.4: 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.
 The PHB specification can also provide semantics for PHB translation
 and service mappings between peer domains, one of which does not
 support this 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
Blake, et. al. Expires: February 1999 [Page 20]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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, 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.5: 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; either
 within a domain or across a domain boundary. Typically there are
 four reasons for PHB modification:
 a. The codepoints associated with the PHB group are collectively
 intended to carry state about the network,
 b. Conditions which require PHB promotion or demotion of a packet
 (this assumes that PHBs within the group can be ranked in some
 order),
 c. A PHB group is not implemented on both sides of a boundary between
 cooperating domains; all codepoints associated with a PHB group
 have to be mapped to some other set of codepoints selecting PHBs
 from another group in the next domain,
 d. 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.
 In contrast, it may also be desirable for specific PHB groups to be
 preserved within a domain and/or across multiple domains. Typically
 this is because the PHB groups carry some host-to-host, WAN edge-to-
 WAN edge, or domain edge-to-domain edge semantics which are difficult
 to duplicate when the PHB group is mapped to a different PHB group.
 Further, these semantics may also be difficult to duplicate if
 packets are promoted or demoted within the same PHB group.
 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,
 or preserved within a domain. A PHB specification should clearly
 state the circumstances under which packets marked for a PHB within a
 PHB group may, or should be mapped, modified, or preserved across
 multiple, cooperating domains when an SLA covering the traffic exists
 among the domains. Recommendations for multi-domain treatment of
 PHBs do not apply to traffic not covered by a SLA among the domains
 involved. A PHB specification should clearly state the circumstances
 under which packets marked for a PHB group may, or should be marked
Blake, et. al. Expires: February 1999 [Page 21]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 for an alternative PHB group.
 If it is undesirable for the packet's PHB (within a PHB group) to be
 modified, the 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. For certain PHB groups, it may be appropriate to
 reflect a state change in the node by changing a PHB. 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. A PHB specification may include constraints on
 actions that change the PHB group. These constraints may be
 specified as actions the node should, or must perform.
 G.6: 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.7: 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.
 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.8: Each PHB specification should include a section specifying
Blake, et. al. Expires: February 1999 [Page 22]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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.9: 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.10: It is strongly recommended that an appendix be provided for
 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.11: If the PHB specification is targeted for local use within a
 domain, it is recommended that the appendix include a description of
 how the PHB group is best mapped to existing general-use PHB groups
 as well as other local-use PHB groups when necessary.
 G.12: 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.13: 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. This may be due to the capabilities or
 configuration of the node. We define a legacy node as a special case
Blake, et. al. Expires: February 1999 [Page 23]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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 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
Blake, et. al. Expires: February 1999 [Page 24]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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 few
 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 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
Blake, et. al. Expires: February 1999 [Page 25]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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.
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.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 traffic
 conditioning agreement(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 SPP. 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.
Blake, et. al. Expires: February 1999 [Page 26]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 Both a domain's service provisioning policy and traffic conditioning
 agreements 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).
 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
Blake, et. al. Expires: February 1999 [Page 27]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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.
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
Blake, et. al. Expires: February 1999 [Page 28]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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
 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
Blake, et. al. Expires: February 1999 [Page 29]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 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
 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
 The authors would like to acknowledge the following individuals for
 their helpful comments and suggestions: Kathleen Nichols, Brian
 Carpenter, Konstantinos Dovrolis, Shivkumar Kalyana, Wu-chang Feng,
 Marty Borden, Yoram Bernet, Ronald Bonica, James Binder, and Borje
 Ohlman, Alessio Casati, Scott Brim, Curtis Villamizar, Brahi, Andrew
 Smith, John Renwick, Werner Almesberger, Alan O'Neill, and James Fu.
Blake, et. al. Expires: February 1999 [Page 30]
INTERNET-DRAFT An Architecture for Differentiated Services August 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] S. Kent and R. Atkinson, "IP Authentication Header",
 Internet Draft <draft-ietf-ipsec-auth-header-07.txt>,
 July 1998.
 [ATM] ATM Traffic Management Specification Version 4.0
 <af-tm-0056.000>, 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", Internet Draft
 <draft-ietf-diffserv-rsvp-00.txt>, June 1998.
 [DSFIELD] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition
 of the Differentiated Services Field (DS Field) in the
 IPv4 and IPv6 Headers", Internet Draft
 <draft-ietf-diffserv-header-02.txt>, August 1998.
 [DSFWK] Y. Bernet, J. Binder, S. Blake, M. Carlson, E. Davies, B.
 Ohlman, D. Verma, Z. Wang, and W. Weiss, "A Framework for
 Differentiated Services", Internet Draft
 <draft-ietf-diffserv-framework-00.txt>, May 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. 
 [Ellesson] E. Ellesson and S. Blake, "A Proposal for the Format and
 Semantics of the TOS Byte and Traffic Class Byte in IPv4
 and IPv6", Internet Draft <draft-ellesson-tos-00.txt>,
 November 1997.
 [ESP] S. Kent and R. Atkinson, "IP Encapsulating Security
 Payload", Internet Draft
 <draft-ietf-ipsec-esp-v2-06.txt>, July 1998.
 [Ferguson] P. Ferguson, "Simple Differential Services: IP TOS and
 Precedence, Delay Indication, and Drop Preference,
 Internet Draft <draft-ferguson-delay-drop-02.txt>,
 April 1998.
 [FRELAY] ANSI T1S1, "DSSI Core Aspects of Frame Rely", March 1990.
Blake, et. al. Expires: February 1999 [Page 31]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
 [Heinanen] J. Heinanen, "Use of the IPv4 TOS Octet to Support
 Differentiated Services", Internet Draft
 <draft-heinanen-diff-tos-octet-01.txt>, November 1997.
 [MPLSFWK] R. Callon, P. Doolan, N. Feldman, A. Fredette, G.
 Swallow, and A. Viswanathan, "A Framework for
 Multiprotocol Label Switching", Internet Draft
 <draft-ietf-mpls-framework-02.txt>, November 1997.
 [MPLSTE] D. Awduche, D. H. Gan, T. Li, G. Swallow, and V.
 Srinivasan, "Extensions to RSVP for Traffic Engineering",
 Internet Draft <draft-swallow-mpls-rsvp-trafeng-00.txt>,
 August 1998.
 [RFC791] Information Sciences Institute, "Internet Protocol",
 Internet RFC 791, September 1981.
 [RFC1349] P. Almquist, "Type of Service in the Internet Protocol
 Suite", Internet RFC 1349, July 1992.
 [RFC1633] R. Braden, D. Clark, and S. Shenker, "Integrated Services
 in the Internet Architecture: An Overview", Internet RFC
 1633, July 1994.
 [RFC1812] F. Baker, editor, "Requirements for IP Version 4
 Routers", Internet RFC 1812, June 1995.
 [RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP)
 -- Version 1 Functional Specification", Internet RFC
 2205, September 1997.
 [SIMA] K. Kilkki, "Simple Integrated Media Access (SIMA)",
 Internet Draft <draft-kalevi-simple-media-access-01.txt>,
 June 1997.
 [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.
 [Weiss] W. Weiss, "Providing Differentiated Services Through
 Cooperative Dropping and Delay Indication", Internet
 Draft <draft-weiss-cooperative-drop-00.txt>, March 1998.
Blake, et. al. Expires: February 1999 [Page 32]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
Authors' Addresses
 Steven Blake
 Torrent Networking Technologies
 2221 Broadbirch Drive
 Silver Spring, MD 20904
 Phone: +1-301-625-1600
 E-mail: slblake@torrentnet.com
 David Black
 The Open Group
 11 Cambridge Center
 Cambridge, MA 02142
 Phone: +1-617-621-7347
 E-mail: d.black@opengroup.org
 Mark A. Carlson
 Sun Microsystems, Inc.
 2990 Center Green Court South
 Boulder, CO 80301
 Phone: +1-303-448-0048 x115
 E-mail: mark.carlson@sun.com
 Elwyn Davies
 Nortel UK
 London Road
 Harlow, Essex CM17 9NA, UK
 Phone: +44-1279-405498
 E-mail: elwynd@nortel.co.uk
 Zheng Wang
 Bell Labs Lucent Technologies
 101 Crawfords Corner Road
 Holmdel, NJ 07733
 E-mail: zhwang@bell-labs.com
 Walter Weiss
 Lucent Technologies
 300 Baker Avenue, Suite 100,
 Concord, MA 01742-2168
 E-mail: wweiss@lucent.com
Blake, et. al. Expires: February 1999 [Page 33]
INTERNET-DRAFT An Architecture for Differentiated Services August 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. Expires: February 1999 [Page 34]