WDIFF

draft-ietf-diffserv-header-00.txt --> draft-ietf-diffserv-header-01.txt

INTERNET-DRAFT Kathleen Nichols
Diffserv Working Group Bay Networks Architecture Lab
Expires: November 1998 January 1999 Steven Blake
IBM Microelectronics

May
Torrent Networking Technologies
Fred Baker
Cisco Systems
David L. Black
The Open Group

July 1998

Definition of the Differentiated Services Field (DS Byte) Field)
in the IPv4 and IPv6 Headers

<draft-ietf-diffserv-header-00.txt>

<draft-ietf-diffserv-header-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).

Abstract

Differentiated services are intended to provide scalable service
discrimination in the Internet without the need for per-flow state
and signaling at every hop. A variety of services may be built from
a small, well-defined set of building blocks which are deployed in
network nodes. The services may be either end-to-end or intra-
domain. Services can be provided constructed by a combination of:

- setting bits in an IP header field at network edges boundaries and
administrative boundaries,
- using those bits to determine how packets are forwarded by the
routers
nodes inside the network, and
- conditioning the marked packets at network boundaries in accordance
with the requirements or rules of each service.

This document defines the IP header field, called the DS (for
differentiated services) byte. In IPv4, it takes the place

The requirements or rules of each service must be set through
administrative policy mechanisms which are outside the TOS
octet; in IPv6, it takes the place scope of the Traffic Class octet. this
document. A differentiated services-capable services-compliant network node includes a
classifier

Nichols, Blake Expires: November 1998 [Page 1]

INTERNET-DRAFT Differentiated Services May 1998 that selects packets based on the value of the DS byte field
and is capable of delivering the specific packet forwarding treatment corresponding
to that
indicated by the DS field value. This document defines two packet forwarding
treatments, or per-hop behaviors. Setting of the DS byte field and other
conditioning of the dynamic temporal behavior of marked packets need only be
performed at network boundaries and may vary in complexity.

This document defines the IP header field, called the DS (for
differentiated services) field. In IPv4, it defines the layout of
the TOS octet; in IPv6, the Traffic Class octet. In addition, a base
set of packet forwarding treatments, or per-hop behaviors, is
defined.

For a more complete understanding of differentiated services, this
document should be read along with its companion documents, see
also the differentiated services architecture [ARCH], the differentiated
services framework [FWK], and other documents which specify
additional per-hop behaviors, such as [Baker]. [ARCH].

1. Introduction

The DS byte is used

Differentiated services are intended to mark provide a packet framework and
building blocks to receive a particular
forwarding treatment, or per-hop behavior, on nodes along its path.
Marking is performed enable deployment of scalable service
discrimination in the Internet. The differentiated services approach
aims to speed deployment by traffic conditioners at network boundaries,
including separating the edges architecture into two
major components, one of the network (first hop router or source host) which is fairly well-understood and administrative boundaries. Traffic conditioners may include the
primitives
other of classification, marking, policing and shaping (these
mechanisms are described in [ARCH]). Services which is just beginning to be understood. In this, we are realized
guided by the
use original design of particular traffic conditioning at boundaries coupled with the
concatenation of per-hop behaviors along Internet where the transit path of decision was
made to separate the
traffic (services are discussed forwarding and routing components. Packet
forwarding is the relatively simple task that needs to be done on a
per-packet basis as quickly as possible. Forwarding uses the packet
header to find an entry in [FWK]). A goal of a routing table that determines the
differentiated services architecture is
packet's output interface. Routing sets the entries in that table
and may need to specify these building
blocks for future extensibility, both reflect a range of the number transit and type other policies as well
as to keep track of route failures. Routing tables are maintained as
a background process to the
building blocks forwarding task. Further, routing is the
more complex task and of it has continued to evolve over the past 20
years.

Analogously, the differentiated services built from them.

Terminology used in this draft architecture contains two
main components. One is defined the fairly well-understood behavior in Sec. 2. The
differentiated services byte definition (DS byte) the
forwarding path and the other is given the more complex and still emerging
background policy and allocation component that configures parameters
used in Sec. 3.
In Sec. 4, two specific the forwarding path. The forwarding path behaviors include
the differential treatment an individual packet receives, as
implemented by queueing service disciplines and/or queue management
disciplines. These per-hop behaviors are defined. Sec. 5
presents guidelines for per-hop behavior standardization. Sec. 6
discusses guidelines for allocation useful and required in
network nodes to deliver differentiated treatment of per-hop behavior codepoints.
Sec. 7 covers security considerations. We present two example
services which packets no
matter how we construct end-to-end or intra-domain services. These
behaviors and the mechanisms to select them on a per-packet basis can
be built from these differentiated services
primitives deployed in the Appendix.

This document is a concise description of the DS byte network nodes today and its uses.
It it is intended to be read along with its companion documents, this aspect of the
differentiated services architecture [ARCH], that is being addressed first.
In addition, the differentiated
services framework [FWK], forwarding path may require that some monitoring,
policing, and other documents which specify
additional per-hop behaviors, such as [Baker].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to shaping be interpreted as described in [RFC2119].

Nichols, Blake Expires: November 1998 [Page 2]

INTERNET-DRAFT Differentiated Services May 1998

2. Terminology Used done on the network traffic designated for
"special" treatment in This Document

Behavior aggregate: a collection of packets order to enforce requirements associated with
the same codepoint
crossing a boundary in a particular direction. The terms "aggregate"
and "behavior aggregate" are used interchangeably in delivery of the special treatment. Mechanisms for this document.

Boundary: Where two network "clouds" kind of
traffic conditioning are linked; also fairly well-understood. The wide
deployment of such traffic conditioners is also important to enable
the "clouds" can
represent different administrative domains or autonomous systems,
different trust regions, different construction of services, though their actual use in constructing
services may evolve over time.

The configuration of network technologies (e.g., cell/
frame), hosts and routers, etc. A boundary can be further sub-
divided into exit elements with respect to which packets
get special treatment and entry nodes, where the exit/entry nodes what kinds of rules are to be applied to
the
upstream/downstream nodes use of a boundary link resources is much less well-understood. Nevertheless,
it is possible to deploy useful differentiated services in networks
by using simple policies and static configurations. As described in
[ARCH], there are a given traffic
direction.

Codepoint: a specific value number of ways to compose per-hop behaviors and
traffic conditioners to create services. In the PHB field process, additional
experience is gained that will guide more complex policies and
allocations. The basic behaviors in the DS byte.

DS byte: forwarding path can remain
the IPv4 header TOS octet or same while this component of the IPv6 Traffic Class octet
when interpreted in conformance architecture evolves.
Experiences with the definition given in this
document.

Mechanism: The implementation construction of such services will continue for
some time, thus we avoid standardizing this construction as
premature. Further, much of a per-hop behavior according to a
particular algorithm.

Network edge: refers to a particular boundary node, the edge details of service construction are
covered by legal agreements between different business entities and
we avoid this as very much outside the
differentiated services-compliant area. scope of the IETF.

This typically is at document concentrates on the
ingress to forwarding path component. In the first-hop
packet forwarding path, differentiated services-aware router (or
network node) a host's packets traverse, or at services are realized by
mapping the egress of codepoint contained in a field in the
last-hop differentiated services-aware router IP packet header to
a particular forwarding treatment, or per-hop behavior (PHB), at each
network node packets
traverse before arriving at a host. This is sometimes referred to as
the boundary at a leaf router. along its path. The network edge might codepoints may be co-located
with a host, subject to local policy.

Per-hop Behavior: chosen from a description set
of the externally observable
forwarding treatment applied at a differentiated services-enabled
node recommended values or may have purely local meaning. PHBs are
expected to be implemented by employing a behavior aggregate.

Service: a description of the overall treatment range of queue service and/
or queue management disciplines on a customer's
traffic within a particular domain network node's output interface
queue, for example weighted round-robin queue servicing or end-to-end.

Traffic conditioner: an entity which performs drop-
preference queue management.

Marking is performed by traffic conditioning
functions and which may contain header classifiers, meters, policers,
shapers, conditioners at network boundaries,
including the edges of the network (first hop router or source host)
and markers. administrative boundaries. Traffic conditioners are typically deployed in
boundary nodes only.

Traffic conditioning: control functions that can be applied to a
behavior aggregate, application flow, or other operationally useful
subset of traffic, e.g., routing updates. These may include header
classification, metering, policing, shaping, and packet marking.
Traffic conditioning is used to enforce service level agreements
between domains and to condition traffic to receive a differentiated
service within a domain.

Nichols, Blake Expires: November 1998 [Page 3]

INTERNET-DRAFT Differentiated Services May 1998

To summarize, the DS byte is used to designate behaviors. A DS byte
classifier
primitives of marking, metering, policing and per-hop behaviors based on those classifications shaping (these
mechanisms are
required described in all network nodes [ARCH]). Services are realized by the
use of a differentiated services-capable
network. More extensive particular packet classification and traffic conditioners may appear conditioning
mechanisms at
boundaries. Multiple services can be supported by a single per-hop
behavior used in concert boundaries coupled with a range the concatenation of traffic conditioners.

3. Differentiated Services Byte Definition per-hop
behaviors along the transit path of the traffic. A new header field, called goal of the DS byte,
differentiated services architecture is defined. The DS byte then
overrides existing definitions to specify these building
blocks for future extensibility, both of the IPv4 TOS octet [RFC791] number and type of the
IPv6 Traffic Class octet [IPv6].

Six bits
building blocks and of the DS byte are services built from them.

Terminology used to define the per-hop behavior (PHB)
a packet experiences. A two-bit currently unused (CU) in this draft is defined in Sec. 2. The
differentiated services field definition (DS field) is
reserved and may be assigned later, e.g., given in Sec.
3. In Sec. 4, we discuss the desire for explicit congestion
notification [ECN]. The value partial backwards
compatibility with current use of the CU bits MUST be ignored by
differentiated services-compliant nodes when determining the per-hop
behavior to apply to IP precedence field. As a received packet.

The DS byte structure is presented below:

0 1 2 3 4
solution, we introduce Class Selector codepoints and Class Selector
Compliant PHBs. Sec. 5 6 7
+---+---+---+---+---+---+---+---+
| PHB | CU |
+---+---+---+---+---+---+---+---+

PHB: presents guidelines for per-hop behavior
CU: currently unused

Implementors should note that the PHB field is
standardization. Sec. 6 bits wide. Routers
MUST identify PHBs by matching against the entire 6-bit discusses guidelines for allocation of
codepoints. Sec. 7 covers security considerations. We present
examples of class selector compliant PHB field,
e.g., by treating implementations in the value or "codepoint"
Appendix.

This document is a concise description of the PHB DS field as a
table index or a switch/case statement variable which and its uses.
It is used intended to
select a particular packet handling mechanism which has been
implemented in that device. Although the IANA may assume some
structure within be read along with the PHB field when assigning values for new per-hop
behaviors, we define it as an unstructured field differentiated services
architecture [ARCH].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to facilitate the
definition of future per-hop behaviors.

Packets received with an unrecognized codepoint SHOULD be forwarded interpreted as if they were marked for the Default behavior (see Sec. 4).

The structure described in [RFC2119].

2. Terminology Used in This Document

Behavior aggregate: a collection of the DS byte shown above is incompatible packets with the
existing definition of the IPv4 TOS octet same codepoint
crossing a boundary in [RFC791, RFC1349]. a particular direction. The
presumption is that differentiated services-aware networks protect
themselves by deploying re-marking terms "aggregate"
and "behavior aggregate" are used interchangeably in this document.

Boundary: the edge of a DS domain, where classifiers and traffic
conditioners are likely to be deployed. A boundary can be further
sub-divided into ingress and egress nodes, as should networks
using where the RFC 791 Precedence designations. Correct operational
procedure should follow [RFC791], which states: "If ingress/egress
nodes are the actual use of

Nichols, Blake Expires: November 1998 [Page 4]

INTERNET-DRAFT Differentiated Services May 1998

these precedence designations is downstream/upstream nodes of concern to a particular network,
it boundary link in a given
traffic direction. A boundary typically is found at the responsibility of that network ingress to control
the access to,
and use of, those precedence designations." Validating first-hop differentiated services-compliant router (or network
node) a host's packets traverse, or at the value egress of the DS byte at last-hop
differentiated services-compliant router or network boundaries is sensible in any case since an
upstream node can easily set it to any random value. Differentiated
services-enabled networks which are not suitably isolated by a
re-marking boundary node may deliver unpredictable service. A
companion document [Baker] describes how packets
traverse before arriving at a minimal necessary amount
of compatibility with RFC 791 Precedence can be maintained under use
of the DS byte.

4. Initial Per-Hop Behavior Definitions

Two per-hop behaviors are already in widespread use and we propose
them for standardization: Default (DE) host. This is sometimes referred to as
the common, best-effort
forwarding behavior available in existing routers and is already
standardized in [RFC1812]. Expedited Forwarding (EF) is boundary at a "high
priority" forwarding behavior such as leaf router. A boundary might be used for delay
sensitive traffic such as audio and video. The codepoints for these
two behaviors are shown below:

Codepoint Behavior name
--------- -------------

000000 Default (DE)
000010 Expedited Forwarding (EF)

and the behaviors are defined as follows:

Default: co-located with a DE-marked packet is queued for
host, subject to local policy.

Classifier: an outgoing interface entity which selects packets based on the content of
packet headers according to defined rules.

Codepoint: a specific value of the availability DSCP portion of buffer resources and according the DS field.
Recommended codepoints SHOULD map to specific, standardized PHBs.
Multiple codepoints MAY map to
any active queue management policy that may be implemented [ACTIVE].
It is not required that all arriving packets are seen at the output,
but it is RECOMMENDED that the aggregate of packets same PHB.

Differentiated Service-compliant: in compliance with this marking
not be completely starved. Forwarding requirements are as soon as
possible, and the corresponding output bandwidth requirements are as
much as possible, subject to the other constraints
specified in this document.

Differentiated Services domain: a contiguous portion of the router's
scheduling and buffer management sub-systems [CCBES]. The Default
behavior is intended to closely approximate the best-effort behavior Internet
over which a consistent set of existing routers. The codepoint chosen for Default behavior is
compatible with existing practice [RFC791, RFC1349].

A packet originating from differentiated services policies are
administered in a node coordinated fashion. A differentiated services
domain can represent different administrative domains or autonomous
systems, different trust regions, different network technologies
(e.g., cell/ frame), hosts and marked for routers, etc. Also DS domain.

Differentiated Services field: the Default behavior
may be re-marked IPv4 header TOS octet or the
IPv6 Traffic Class octet when interpreted in conformance with another PHB codepoint at the
definition given in this document. Also DS field.

Mechanism: The implementation of a downstream network
boundary to enable preferential forwarding within that network,
possibly subject per-hop behavior according to some negotiated agreement.

Expedited Forwarding: for traffic levels a
particular algorithm.

Microflow: a single instance of an application-to-application flow of EF-marked
packets which
are is identified by source address, source port,
destination address, destination port and protocol id.

Per-hop Behavior (PHB): a small fraction of the link rate description of an outgoing interface, the

Nichols, Blake Expires: November 1998 [Page 5]

INTERNET-DRAFT Differentiated Services May 1998

implementation externally observable
forwarding treatment applied at a differentiated services-compliant
node to a behavior aggregate. The description of Expedited Forwarding a PHB should exhibit the following
behavioral characteristics: low absolute delay, low delay variation,
and extremely low loss, irrespective of
be sufficiently detailed to allow the rate construction of non-EF-marked
traffic which is forwarded through predictable
services.

Traffic conditioning: control functions that same outgoing interface. The
delay and loss characteristics should can be similar applied to that observed by a single
behavior aggregate, application flow, or other operationally useful
subset of traffic, e.g., routing updates. These may include
metering, policing, shaping, and packet traversing marking. Traffic
conditioning is used to enforce service level agreements between
domains and to condition traffic to receive a differentiated service
within a domain by marking packets with the appropriate codepoint in
the DS field and by monitoring and altering the temporal
characteristics of the aggregate where necessary.

Traffic conditioner: an otherwise idle router, entity which performs traffic conditioning
functions and should not
vary significantly as which may contain meters, policers, shapers, and
markers. Traffic conditioners are typically deployed in boundary
nodes only.

Service: a description of the rate overall treatment of non-EF-marked a customer's
traffic is increased.
The maximum rate within a particular domain, within a set of EF-marked interconnected
DS domains, or end-to-end. Service descriptions are covered by
administrative policy and services are constructed by applying
traffic conditioning to create behavior aggregates which can be forwarded on an
outgoing link while satisfying experience a
known PHB at each hop within the desired behavioral characteristics
is implementation-dependent. The Expedited Forwarding behavior DS domain. Multiple services can be realized
supported by a variety of mechanisms, including strict priority
queueing, WFQ or variants [HPFQA], weighted round-robin queueing with
a large weight for the EF queue, or CBQ [CBQ].

The Expedited Forwarding single per-hop behavior may be used to implement services
requiring low delay and low jitter. Service guarantees for this
class in concert with a range
of traffic SHOULD depend on conformance to some rate conditioners.

To summarize, classifiers and
burstiness constraints which are enforced by traffic conditioners at
network boundaries, possibly subject are used to some negotiated agreement.
EF-marked aggregates select
which packets are to be added to behavior aggregates. Aggregates receive
differentiated treatment in excess of these constraints may
have some or all of their packets delayed (by a shaper) or discarded.

Note that conforming implementations will commonly employ separate
scheduler queues for DE- and EF-marked packets. Thus it should be
expected that packet streams which include both DE- domain and EF-marked
packets may suffer packet reordering when traversing a conforming
router.

5. Per-Hop Behavior Standardization Guidelines

Thirty-two PHB codepoints are reserved for standardization, and 32
codepoints are reserved for experimental or local use (EXP/LU)
(see Sec. 6 for further details).

The behavioral alter the temporal
characteristics of a PHB are to be standardized, and
not the algorithms or aggregate to conform to some requirements. A
packet's DS field is used to designate the mechanisms packet's behavior
aggregate and is subsequently used to implement them. determine which forwarding
treatment the packet receives. A
router may have a (possibly large) set of parameters that DS field classifier which can be used
to control how packets are scheduled onto an
select a differential output interface (e.g.,
N separate queues with settable priorities, queue lengths, round-
robin weights, drop algorithm, drop preference weights and
thresholds, etc). To illustrate servicing discipline (or PHB)
based on the distinction between a PHB and a
mechanism, we point out that codepoint in the EF PHB might DS field SHOULD be implemented by
several mechanisms, including: strict priority queueing, WFQ or
variants [HPFQA], weighted round-robin queueing with in all network
nodes of a large weight
for the EF queue, or CBQ [CBQ].

Router vendors are free to offer whatever parameters differentiated services domain. The classifiers
and capabilities traffic conditioners are deemed useful or marketable. When a particular, standardized PHB
is implemented configured in accordance with some
service specification, a router, a vendor may use any algorithm that
satisfies the definition matter of administrative policy outside the PHB according to
scope of this document.

Additional differentiated services definitions are in [ARCH].

3. Differentiated Services Field Definition

A new header field, called the standard. The
router's capabilities and its particular configuration determine the

Nichols, Blake Expires: November 1998 [Page 6]

INTERNET-DRAFT Differentiated Services May 1998

different ways that packets can be treated.

Service providers are not required DS field, is defined, which is
intended to use supersede the same router mechanisms
or configurations to enable service differentiation within their
networks, existing definitions of the IPv4 TOS octet
[RFC791] and the IPv6 Traffic Class octet [IPv6].

Six bits of the DS field are free used as a codepoint (DSCP) to configure select the router parameters in whatever
way that
PHB a packet experiences at each node. A two-bit currently unused
(CU) field is appropriate for their service offerings and traffic
engineering objectives. Over time certain common per-hop behaviors
are likely to evolve (i.e., ones that are particularly useful for
implementing end-to-end services) reserved and these may be associated with
particular EXP/LU PHB codepoints in the DS byte, allowing use across
domain boundaries (see Sec. 6). These PHBs are candidates assigned later, e.g., for future
standardization.

Only those per-hop behaviors that are not described by an existing
PHB standard, and have been implemented, deployed, and shown to be
useful, should explicit
congestion notification. The value of the CU bits MUST be standardized. Since current experience with
ignored by differentiated services is quite limited, it is premature to
hypothesize services-compliant nodes when determining
the exact specification of these per-hop behaviors. This
specification has left room in the codepoint space behavior to allow for
evolution, thus the defined space is intentionally sparse.

6. IANA Considerations apply to a received packet.

The PHB field in the DS byte is capable of conveying 64 distinct
codepoints. The codepoint space field structure is divided into three pools for the
purpose of presented below:

0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+

DSCP: differentiated services codepoint assignment and management:
CU: currently unused

Implementors should note that the DSCP field is six bits wide. DS-
compliant nodes MUST select PHBs by matching against the entire 6-
bit DSCP field, e.g., by treating the value of the field as a pool table
index which is used to select a particular packet handling mechanism
which has been implemented in that device. The DSCP field is defined
as an unstructured field to facilitate the definition of future per-
hop behaviors.

With some exceptions noted below, the mapping of 32 codepoints (Pool 1) to PHBs
MUST be assigned by Standards Action as defined in
[CONS], a pool configurable. A DS-compliant node MUST support the logical
equivalent of 16 a configurable mapping table from codepoints (Pool 2) to be reserved for
experimental PHBs.
PHB specifications MUST include a recommended default codepoint, but
operators MAY choose to use different codepoints, either in addition
to or Local Use (EXP/LU) as defined in [CONS], and a pool place of 16 codepoints (Pool 3) which the recommended default. Note that if operators do
so choose, re-marking of DS fields will be necessary at
administrative boundaries even if the same PHBs are initially available implemented on
both sides of the boundary. See [ARCH] for
experimental or local use, but which should further discussion of re-
marking. The recommended default codepoint for a PHB must be preferentially
utilized unique
for standardized assignments if Pool 1 is ever exhausted. codepoints in the standard space (see Sec. 6).

The pools exceptions to configurability are defined for codepoints 'xxx000' and are
noted in Sec. 4.

Packets received with an unrecognized codepoint SHOULD be forwarded
as if they were marked for the following table (where 'x' refers Default behavior (see Sec. 4). Such
packets MUST NOT cause the network node to
either '0' or '1'):

Pool Codepoint space Assignment Policy
---- --------------- -----------------

1 xxxxx0 Standards Action
2 xxxx11 EXP/LU
3 xxxx01 EXP/LU (*)

(*) crash.

The structure of the DS field shown above is incompatible with the
existing definition of the IPv4 TOS octet in [RFC791, RFC1349]. The
presumption is that differentiated services domains protect
themselves by deploying re-marking boundary nodes, as should networks
using the RFC 791 Precedence designations. Correct operational
procedure should follow [RFC791], which states: "If the actual use of
these precedence designations is of concern to a particular network,
it is the responsibility of that network to control the access to,
and use of, those precedence designations." Validating the value of
the DS field at network boundaries is sensible in any case since an
upstream node can easily set it to any random value. Differentiated
services domains which are not suitably isolated by a re-marking
boundary node may be utilized for future Standards Action allocations deliver unpredictable service.

Nodes MAY rewrite the DS field as
necessary

This document defines needed to provide a desired local
or end-to-end service. Specifications of DS field translations at
network boundaries are the subject of Service Level Agreements
between providers and users, and are outside the scope of this
document. Standardized PHBs allow providers to build their services
from a well-known set of packet forwarding treatments that can be
expected to be present in the equipment of many vendors.

4. Historical Codepoint Definitions and PHB Requirements

The DS field will have a limited backwards compatibility with current
practice, described in this section. Backwards compatibility is
addressed in two ways. First, per-hop behaviors that are
already in widespread use MUST be included in a DS-compliant
node. In addition, there are some codepoints that correspond to
historical use of the IP Precedence field and we reserve these
codepoints to map to PHBs that meet the general requirements
specified in [RFC791], though the specific differentiated services
PHBs mapped to by those codepoints MAY have additional
specifications.

4.1 A Default PHB

A "default" PHB MUST be available in a DS-compliant node. This is
the common, best-effort forwarding behavior available in existing
routers as standardized in [RFC1812]. When no other agreements are
in place, it is assumed that packets belong to this aggregate. Such
packets may be sent into a network without adhering to any particular
rules and the network will deliver as many of these packets as
possible and as soon as possible, subject to other resource policy
constraints. A reasonable implementation of this PHB would be a
queueing discipline that sends packets of this aggregate whenever the
output link is not required to satisfy another PHB. A reasonable
policy for constructing services would ensure that the aggregate was
not "starved" or else the network provider might become quite
unpopular. This permits senders that are not differentiated
services-aware to continue to use the network in the same manner as
today and to have the same kinds of expectations from the network
regarding service. The RECOMMENDED codpoint for the Default PHB is
the bit pattern '000000'; the value '000000' MUST map to a PHB that
meets these specifications. The codepoint chosen for Default
behavior is compatible with existing practice [RFC791, RFC1349].

A packet initially marked for the Default behavior MAY be re-marked
with another codepoint as it passes a boundary into another DS domain
so that it will be forwarded using a different PHB within the domain,
possibly subject to some negotiated agreement between the peering
domains.

4.2 Once and Future IP Precedence Field Use

We wish to maintain some form of backward compatibility with present
uses of the IP Precedence Field: bits 0-2 of the IPv4 TOS octet.
Routers exist that use the IP Precedence field to select different
per-hop forwarding treatments quite similarly to the use proposed
here for the DSCP field. Thus, a simple prototype diffserv
architecture can be quickly deployed by appropriately configuring
these routers. Further, IP systems today understand the location of
the IP Precedence field, and thus if these bits are used in a similar
manner as DS-compliant equipment is deployed, significant failures
are not likely during early deployment. In other words, strict DS-
compliance need not be ubiquitous even within a single service
provider's network if bits 0-2 of the DSCP field are employed in a
manner similar to, or subsuming, the deployed uses of the IP
Precedence field.

4.2.1 IP Precedence History and Evolution in Brief

The IP Precedence field is something of a forerunner of the DS field.
IP Precedence, and the IP Precedence Field, were first defined in
[RFC791]. The values that the three-bit IP Precedence Field might
take were assigned to various uses, including network control
traffic, routing traffic, and various levels of privilege. The least
level of privilege was deemed "routine traffic". In [RFC791], the
notion of Precedence was defined broadly as " An independent measure
of the importance of this datagram." Not all values of the IP
Precedence field were assumed to have meaning across boundaries, for
instance "The Network Control precedence designation is intended to
be used within a network only. The actual use and control of that
designation is up to each network." [RFC791]

Although early BBN IMPs implemented the service, early commercial
routers and UNIX IP forwarding code generally did not. As networks
became more complex and customer requirements grew, commercial
routers developed ways to implement various kinds of queueing
services including priority queueing, which were generally based on
policies encoded in filters in the routers, which looked at IP
addresses, IP protocol numbers, TCP or UDP ports, and other header
fields. IP Precedence was and is among the options such filters can
look at.

In short, IP Precedence is widely deployed and widely used, if not in
exactly the manner intended in [RFC791]. This was recognized in
[RFC1122], which states that while the use of the IP Precedence field
is valid, the specific assignment of the priorities in [RFC791] were
merely historical.

4.2.2 Subsuming IP Precedence into Class Selector Codepoints

A specification of the packet forwarding treatments selected by the
IP precedence field today would have to be quite general; probably
not specific enough to build predictable services from in the
differentiated services framework. To preserve partial backwards
compatibility with known current uses of the IP Precedence field
without sacrificing future flexibility, we have taken the approach of
describing minimum requirements on a set of PHBs that are compatible
with most of the existing forwarding treatments selected by the IP
Precedence field. In addition, we give a set of codepoints that MUST
map to PHBs meeting minimum requirements. The PHBs mapped to by
these codepoints MAY have a more detailed list of specifications in
addition to the required ones stated here. Other codepoints MAY map
to the same PHBs. We refer to this set of codepoints as the Class
Selector codepoints and the minimum requirements for PHBs that these
codepoints may map to are called the Class Selector PHB requirements.

4.2.2.1 The Class Selector Codepoints

The DS field values of 'xxx000|xx', or DSCP = 'xxx000' and CU
subfield unspecified are reserved as a set of Class Selector Codepoints.
PHBs which are mapped to by these codepoints MUST meet the Class
Selector PHB requirements in addition to preserving the Default PHB
requirement on codepoint '000000'.

4.2.2.2 The Class Selector PHB Requirements

We refer to a Class Selector codepoint with a larger numerical value
than another Class Selector codepoint as having a higher relative
order while a Class Selector codepoint with a smaller numerical value
than another Class Selector codepoint is said to have a lower
relative order. PHBs selected by a Class Selector codepoint SHOULD
give packets a probability of timely forwarding that is not lower
than that given to packets marked with a Class Selector codepoint of
lower relative order. Although a particular packet marked with a
lower relative order Class Selector codepoint might be observed to be
forwarded earlier than a particular packet marked with a higher
relative order, sample observations that take place over a reasonable
period of network history will conform to this requirement. A
discarded packet is considered to be an extreme case of untimely
forwarding.

Further, PHBs selected by distinct Class Selector codepoints SHOULD
be independently forwarded; that is, packets marked with different
Class Selector codepoints MAY be reordered. A network node MAY have
limits on the amount of the node's resources that can be used by each
of these PHBs.

PHB groups whose specification meets these requirements are referred
to as Class Selector Compliant PHBs.

It is easy to see that the Class Selector PHB Requirements on
codepoint '000000' are compatible with those listed in Sec. 4.1
for the Default PHB.

4.2.2.3 Using the Class Selector PHB Requirements for IP Precedence
Compatibility

A DS-compliant network node can be deployed with a set of one or more
Class Selector Compliant PHB groups. This document states that the
set of codepoints 'xxx000' MUST map to such a set of PHBs. As it is
also possible to map multiple codepoints to the same PHB, the vendor
or the network administrator might configure the network node to map
codepoints to PHBs irrespective of bits 3-5 of the DSCP field to
yield a network that is compatible with historical IP Precedence use.
Thus, for example, codepoint '011010' would map to the same PHB as
codepoint '011000'.

4.2.2.4 Example Mechanisms for Implementing Class Selector Compliant
PHB Groups

Class Selector Compliant PHBs can be realized by a variety of
mechanisms, including strict priority queueing, WFQ or variants
[HPFQA], weighted round-robin queueing (WRR), or Class-Based Queuing
[CBQ]. The distinction between PHBs and mechanisms is described in
more detail in Sec. 5.

It is important to note that these mechanisms might be available
through other PHBs (standardized or not) that are available in a
particular vendor's equipment. For example, future documents may
standardize a Strict Priority Queueing PHB for a set of recommended
codepoints. A network administrator might configure those routers to
select the Strict Priority Queueing PHBs with codepoints 'xxx000' in
conformance with the requirements of this document.

As a further example, another vendor might employ a CBQ mechanism in
its routers. The CBQ mechanism could be used to implement the Strict
Priority Queueing PHBs as well as a set of Class Selector Compliant
PHBs with a wider range of features than would be availble in a set
of PHBs that did no more than meet the minimum Class Selector PHB
requirements. More examples are given in the Appendix.

4.3 Summary

This document defines codepoints 'xxx000' as the Class Selector
codepoints, where PHBs selected by these codepoints must meet the
Class Selector PHB Requirements described in Sec. 4.2.2.2. This is
done to preserve a useful level of backward compatibility with
current uses of the IP Precedence field in the Internet without
unduly limiting future flexibility. In addition, codepoint '000000'
is used as the Default PHB value for the Internet and, as such, is
not configurable. The remaining seven non-zero Class Selector
codepoints are configurable only to the extent that they map to PHBs
that meet the requirements in Sec. 4.2.2.2.

5. Per-Hop Behavior Standardization Guidelines

Thirty-two DS codepoints are reserved for standardization as
RECOMMENDED codepoints, and 32 codepoints are reserved for
experimental or local use (EXP/LU) (see Sec. 6 for further details).

Codepoint space Usage Policy
--------------- ------------

xxxxx0 Reserved for RECOMMENDED codepoints
xxxxx1 EXP/LU

The behavioral characteristics of a PHB are to be standardized, and
not the algorithms or the mechanisms used to implement them. A
node may have a (possibly large) set of parameters that can be used
to control how packets are scheduled onto an output interface (e.g.,
N separate queues with settable priorities, queue lengths, round-
robin weights, drop algorithm, drop preference weights and
thresholds, etc). To illustrate the distinction between a PHB and a
mechanism, we point out that Class Selector Compliant PHBs might be
implemented by several mechanisms, including: strict priority
queueing combined with WFQ or variants [HPFQA], weighted round-robin
queueing, or CBQ [CBQ].

It is RECOMMENDED that PHB implementations do not introduce any
packet reordering within a microflow. Where PHBs are defined as a
group, their definitions MUST specify any possible packet re-ordering
implications which may occur if different packets within a microflow
are marked for different PHBs within the group.

Network equipment vendors are free to offer whatever parameters and
capabilities are deemed useful or marketable. When a particular,
standardized PHB is implemented in a node, a vendor may use any
algorithm that satisfies the definition of the PHB according to the
standard. The node's capabilities and its particular configuration
determine the different ways that packets can be treated.

Service providers are not required to use the same node mechanisms
or configurations to enable service differentiation within their
networks, and are free to configure the node parameters in whatever
way that is appropriate for their service offerings and traffic
engineering objectives. Over time certain common per-hop behaviors
are likely to evolve (i.e., ones that are particularly useful for
implementing end-to-end services) and these may be associated with
particular EXP/LU PHB codepoints in the DS field, allowing use across
domain boundaries (see Sec. 6). These PHBs are candidates for future
standardization.

Only those per-hop behaviors that are not described by an existing
PHB standard, and have been implemented, deployed, and shown to be
useful, should be standardized. Since current experience with
differentiated services is quite limited, it is premature to
hypothesize the exact specification of these per-hop behaviors. This
specification has left room in the codepoint space to allow for
evolution, thus the defined space is intentionally sparse.

6. IANA Considerations

The DSCP field in the DS field is capable of conveying 64 distinct
codepoints. The codepoint space is divided into three pools for the
purpose of codepoint assignment and management: a pool of 32
RECOMMENDED codepoints (Pool 1) to be assigned by Standards Action as
defined in [CONS], a pool of 16 codepoints (Pool 2) to be reserved for
experimental or Local Use (EXP/LU) as defined in [CONS], and a pool
of 16 codepoints (Pool 3) which are initially available for
experimental or local use, but which should be preferentially
utilized for standardized assignments if Pool 1 is ever exhausted.
The pools are defined in the following table (where 'x' refers to
either '0' or '1'):

Pool Codepoint space Assignment Policy
---- --------------- -----------------

1 xxxxx0 Standards Action
2 xxxx11 EXP/LU
3 xxxx01 EXP/LU (*)

(*) may be utilized for future Standards Action allocations as
necessary

This document defines the assignment of eight codepoints (xxx000)
which are drawn from Pool 1 above. These codepoints MUST be
mapped, not to specific PHBs, but to PHBs that meet "at least" the
requirements set out in Sec. 4.2.2.2 to provide a minimal level of
backwards compatibility with IP Precedence as defined in [RFC791] and
as deployed in some current equipment.

7. Security Considerations

This section considers 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 (Section 7.1). Section 7.2 addresses the operation
of differentiated services in the presence of IPsec including its
interaction with IPsec tunnel mode and other tunnelling protocols.
More extensive treatment of the security concerns raised by the overall
differentiated services architecture are discussed in [ARCH].

7.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 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 codepoint,
and hence an adversary may be able to obtain better service by
modifying the codepoint to values indicating behaviors used for
enhanced services or by injecting packets with such codepoint values.
Taken to its limits, such 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 this class of theft- and denial-of-service attacks
consists of the combination of traffic conditioning at network boundaries
with security and integrity of the network infrastructure within a
DS domain. Network boundary nodes MUST ensure that all traffic entering
the domain has codepoint values appropriate to the traffic and the domain,
remarking the traffic with new codepoint values if necessary.
These boundary nodes are the primary line of defense against theft-
and denial-of-service attacks based on modified codepoints, as
success of any such attack indicates that the codepoints used
by the attacking traffic were inappropriate. An important instance of a
boundary node is that any traffic-originating node in a DS domain
is the initial boundary node for standardization, that traffic. Interior nodes
in a DS domain rely on DS codepoints to associate traffic with the
forwarding PHBs, and
recommends are not required to check codepoint values before
using them. As a result, the assignment interior nodes depend on the correct
operation of two the DS domain to prevent the arrival of traffic with
inappropriate codepoints (000000 that would disrupt operation of the domain.

7.2 IPsec and 000010) which
are drawn from Pool 1 above.

Nichols, Blake Expires: November 1998 [Page 7]

INTERNET-DRAFT Differentiated Services May 1998 Tunnelling Interactions

The IANA should note 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 a companion document may recommend
assignment is not
included). Hence modification of the codepoint space xxxx00 within Pool 1 for use DS field by
per-hop behaviors which provide a minimal level 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 backwards
compatibility with IP Precedence the DS
field (i.e., a man-in-the-middle attack), as defined the adversary's
modification will also have no effect on IPsec's end-to-end security.

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 [RFC791].

7. Security Considerations 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 removing the outer header and
forwarding the packet (if required) using the inner header.
The IPsec protocol REQUIRES that the inner header's DS field not
be changed by this decapsulation processing to ensure that modifications
to the DS field cannot be used to launch theft- or denial-of-service
attacks across an IPsec tunnel endpoint. This document makes no
change to that requirement. If the inner IP Security Authentication Header (AH) does header has not cover been
processed by a boundary node for the IPv4
TOS octet or tunnel egress node's DS domain,
the IPv6 Traffic Class field in tunnel egress node is the boundary node for traffic exiting the
tunnel, and hence MUST ensure that the resulting traffic has
appropriate DS codepoints.

When IPsec tunnel egress decapsulation processing includes a
sufficiently strong cryptographic integrity check
value computation [AH]. This behavior of the encapsulated
packet (where sufficiency is determined by local security policy), the
tunnel egress node can safely assume that the DS field in fact essential for the
deployment of differentiated services since inner
header has the same value of as it had at the tunnel ingress node.
An important consequence is that otherwise insecure links
within a DS byte
may domain can be changed in transit so secured by a sufficiently strong
IPsec tunnel. This analysis and its implications apply to any
tunneling protocol that performs integrity checks, but the source host does not know what
value will be delivered to level
of assurance of the destination host. Also, since inner header's DS field depends on the
network is free to ignore strength
of the DS byte, end-to-end integrity check performed by the tunneling protocol. In
the absence of a DS
byte value does not guarantee that a differentiated service has been
delivered. Separate measurement and sufficient assurance mechanisms are needed
to ensure that any negotiated differentiated services are being
provided.

Packets marked for Expedited Forwarding receive priority service
relative to packets with other markings. The rate of EF-marked
packets a tunnel that may transit
nodes outside the current DS domain (or is otherwise vulnerable),
the encapsulated packet MUST be regulated to prevent starvation of other traffic.
EF-marked traffic received across treated as if it had arrived at a
boundary link SHOULD be
authenticated (e.g., either by IPsec, by header classification, or by
aggregate policing).

Additional security issues of from outside the general differentiated services
architecture are discussed in [ARCH]. DS domain.

8. Acknowledgements

The authors would like to acknowledge the Differentiated Services
Working Group for discussions which helped shape this document.

9. References

[ACTIVE] B. Braden, et. al., "Recommendations on Queue Management
and Congestion Avoidance in the Internet", Internet RFC
2309, April 1998.

[AH] S. Kent and R. Atkinson, "IP Authentication Header",
Internet Draft <draft-ietf-ipsec-auth-header-05.txt>,
March <draft-ietf-ipsec-auth-header-07.txt>,
July 1998.

[ARCH] Differentiated Services Architecture Document (work in
preparation).

Nichols, Blake Expires: November 1998 [Page 8]

INTERNET-DRAFT Differentiated Services May 1998

[Baker] F. Baker, S. Brim, T. Li, F. Kastenholz, S. Jagannath,
and J. Renwick, "IP Precedence in Differentiated
Services Using the Assured Service", Internet Draft
<draft-diff-serv-precedence-00.txt>, April 1998.

[CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource
Management Models for Packet Networks", IEEE/ACM
Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
August 1995.

[CLARK] D. Clark and W. Fang, "Explicit Allocation of Best
Effort Packet Delivery Service",
http://diffserv.lcs.mit.edu/Papers/exp-alloc-ddc-wf.pdf

[CONS] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", Internet Draft
<draft-iesg-iana-considerations-03.txt>, March 1998.

[CCBES] C. Lefelhocz, B. Lyles, S. Shenker, and L. Zhang,
"Congestion Control for Best-Effort Service: Why We Need
a New Paradigm", IEEE Network, Vol. 10, no. 1, January
1996.

[ECN] K. Ramakrishnan and S. Floyd, "A Proposal to Add Explicit
Congestion Notification (ECN) to IPv6

[ESP] S. Kent and to TCP", R. Atkinson, "IP Encapsulating Security
Payload (ESP)", Internet Draft <draft-kksjf-ecn-00.txt>, November 1997.

[FWK] Differentiated Services Framework Document (work in
preparation).
<draft-ietf-ipsec-esp-v2-06.txt>, July 1998.

[HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair
Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996.

[IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", Internet Draft
<draft-ietf-ipngwg-ipv6-spec-v2-01.txt>, November 1997.

[RFC791] Information Sciences Institute, "Internet Protocol",
Internet RFC 791, September 1981.

[RFC1122] RFC 1122, "Requirements for Internet hosts -
communication layers". R.T. Braden. Oct-01-1989.

[RFC1349] P. Almquist, "Type of Service in the Internet Protocol
Suite", Internet RFC 1349, July 1992.

[RFC1812] F. Baker, editor, "Requirements for IP Version 4
Routers", Internet RFC 1812, June 1995.

[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", Internet RFC 2119, March 1997.

[2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
http://www-nrg.ee.lbl.gov/papers/2bitarch.pdf.

Nichols, Blake Expires: November 1998 [Page 9]

INTERNET-DRAFT Differentiated Services May 1998

Appendix A. Service
ftp://ftp.ee.lbl.gov/papers/dsarch.pdf.

Appendix. Examples in this Framework

We present two example services which may of Class Selector Compliant PHB Implementations

This appendix shows how three different mechanisms can be implemented using the
per-hop behaviors defined in this document. We do not attempt used to
define "quality
implement Class Selector Compliant PHBs.

A.1 Priority Queues

This approach employs eight queues where each of service" for applications nor do we make
assumptions about what service a particular application might use.
Thus, although we give some example uses, we do not characterize the
services as being "for real-time video" or "for file transfer data".
Instead, we characterize eight codepoints
maps to a service by the type of performance packets
of different queue. Queues are ranked in priority order so
that service can expect each queue, from the network. Any IP application perspective of the next lower priority
queue, implements a "low loss, low delay" forwarding behavior. As an
alternative, one can
utilize either employ four queues, where bits 0 and 1 of these services; the choice is up
codepoint are used to select the customer.

Service: Best Effort
PHBs used: Default
Service definition: "like today" (as soon as possible; as much as
possible [CCBES]). At the network edge, packets queue. Bit 2 of the Best Effort
aggregate should be marked with codepoint is
used as a drop preference within the Default PHB (though this queue. RED is also used within the forwarding treatment that a packet
queues according to its usual parameters, but with an unknown marking in-profile traffic
having a higher min-threshold and max-threshold than out-of-profile
traffic, and therefore experiencing a higher probability of timely
delivery. Out-of-profile traffic should
receive). This might be accomplished by marking all packets at consider the
network edge for presence of
lower order in-profile traffic in the Default PHB which can calculation of drop
probability [CLARK].

The strength of this approach is that order is maintained within each
precedence queue, but higher ordered traffic may be changed if the packet
header matches an multi-field classifier set up at sent before lower
ordered traffic. It has a weakness, however, in that apart from
admission control and policing, it affords lower precedence traffic
no assurance of eventual transmission.

A.2 Round Robin Queuing

Like the network edge.

Who/how to use this: previous example, this approach employs a queue per
codepoint, but each queue is emptied at some non-zero rate, in round-
robin order, rather than being given simple priority service.

The basic service strength of the Internet, what one gets
when merely buying connectivity.

Service: Premium
PHBs used: Expedited Forwarding
Service definition: Premium service this approach is that higher ordered traffic is, on
average, queued for a peak-limited, extremely low-
delay service, resembling a leased line [2BIT]. At shorter duration than lower ordered traffic.
It also avoids the network edge,
where lockout issue that priority queuing systems
experience. A counter-intuitive scenario can occur, however, if a Premium aggregate
high rate queue is first created, it must be either shaped
or policed to heavily utilized while a lower rate with no more than a two-packet burst. A policer
for Premium service queue is set
under-utilized; a packet directed to drop packets which exceed the
configured peak rate. For this service, the peak lower rate of the Premium
aggregate across any boundary must queue can
actually be specified better protected from loss and the rate must be
smaller than the link capacity (in practice, it is expected variation in delay when
placed in an empty or very short queue.

A.3 Virtual Circuit or Virtual Channel Selection

The difference between this approach and Round Robin Queuing is
somewhat academic. If one has a serial line to be a
good deal less than routing neighbor,
and manages the link capacity). Policing to this rate is
expected at using a load sharing algorithm, the ingress of any domain and load sharing
algorithm in some sense emulates the policing action taken
may be way the line would behave if it
were in reality a number of different lines, or if it were one
channelized line. In a virtual circuit selection model, the
emulation becomes reality - one deploys a set of two possibilities only: 1) drop the over-rate packet rate-limited VCs to
a routing neighbor, and 2) hold the over-rate packet until it will be uses them in compliance with the peak rate (shaping).

Who/how same way one would otherwise
have used round-robin queues.

The strengths and weaknesses are very similar to use this: Voice-over-IP "trunk", videoconference, fixed
size transfer in fixed time, virtual leased line, low delay
applications.

Nichols, Blake Expires: November 1998 [Page 10]

INTERNET-DRAFT Differentiated Services May 1998 those of Round Robin
Queuing, except that this allows one to capitalize on the
capabilities of a link layer such as ATM or Frame Relay.

Authors' Addresses

Steven Blake
IBM Microelectronics
C5BA 660/HH007
800 Park Offices Drive
Research Triangle Park, NC 27709
Phone: +1-919-254-2030
Fax: +1-919-254-3047
E-mail: slblake@raleigh.ibm.com

Kathleen Nichols
Bay Networks Architecture Lab
4401 Great America Parkway
SC01-04
Santa Clara, CA 95052-8185
Phone: +1-408-495-3252
Fax: +1-408-495-1299
E-mail: knichols@baynetworks.com

Nichols,

Steven Blake Expires: November 1998 [Page 11]
Torrent Networking Technologies (effective 7/15)
E-mail: slblake@intercenter.net

Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
Phone: (408) 526-4257
Email: fred@cisco.com

David L. Black
The Open Group
11 Cambridge Center
Cambridge, MA 02142
Phone: (617) 621-7347
Email: d.black@opengroup.org

----