INTERNET-DRAFT Yoram Bernet
Diffserv Working Group Microsoft
Expires: November 1998 James Binder
3Com
Steven Blake
IBM
Mark Carlson
Redcape Software
Elwyn Davies
Nortel UK
Borje Ohlman
Ericsson
Dinesh Verma
IBM
Zheng Wang
Bell Labs Lucent Technologies
Walter Weiss
Lucent Technologies
May 1998
A Framework for Differentiated Services
<draft-ietf-diffserv-framework-00.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
This document provides a general description of issues related to the
definition, configuration, and management of services enabled by the
differentiated services architecture [DSARCH]. It should be
considered as a work-in-progress.
Bernet, et. al. Expires: November 1998 [Page 1]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
Sec. 1 provides a motivation for the deployment of differentiated
services. Sec. 2 examines the range of services that are enabled
by the differentiated services architecture. Sec. 3 examines
service instantiation, configuration, and management issues. Sec. 4
discusses issues relating to the deployment of differentiated
services across multiple provider boundaries or end-to-end. Sec. 5
addresses interoperability with the Integrated Services.
1. Motivation
A service is a contract between a network provider and its customer,
which outlines the characteristics and behavior of network
connectivity offered by the provider to the customer. The network
provider may be an Internet Service Provider whose customers include
individual users or corporations, an I/T department within an
enterprise, or a networking company to which the operations of an
enterprise network has been outsourced. Individual users would
typically access the network at a single point, while businesses may
have multiple access-points to the network.
A service level agreement (SLA) may specify different aspects of
network behavior, such as the security to be expected by the
customer, constraints on the type and amount of data that can be sent
on the network, and the performance aspects of communication. The
SLA would typically also include a payment/billing scenario as well
as the performance (both up time as well as throughput) aspects
expected with the associated contract.
While services can be differentiated from each other by various
aspects, we concentrate on service differentiation from the
performance aspect only in this document. Traditionally, network
providers have tended to provide all of their customers with the same
type of performance (a best-effort service), with most
differentiation resulting from the pricing structure (business rates
versus individual rates) or the connectivity structure (dial-in
access versus leased line T1 access, etc.). However, the size of the
Internet continues to grow at an astounding rate, and network
capacity has become a scarce resource. Given new types of media and
the further reliance on the network as a mission critical resource,
there is a need felt by the network providers to offer different
types or grades of performance to customers, with network providers
offering better performance to customers who are willing to pay more.
The key aspects determining service performance are availability and
responsiveness. Availability refers to the ability of a customer to
maintain connectivity between its access points on the provider
network, while responsiveness refers to the round-trip delay and
throughputs seen by the customer on its communication.
This document presents a framework for service definition and service
differentiation in the context of a differentiated service domain as
Bernet, et. al. Expires: November 1998 [Page 2]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
described in [DSARCH].
2. Services
2.1 Service Categorization
In order to provide the notion of differentiated services, the
network provider needs to be able to categorize traffic entering its
network into multiple categories. Each of the categories of traffic
is marked with a codepoint as described in [DSARCH]. These
codepoints (or per-hop behaviors (PHBs)) in turn can be used to build
a specific service offered by the Network Provider to the customer.
Service differentiation may be made along multiple dimensions.
A provider may offer a customer a service which provides different
performance assurances to packets being received by the customer from
the provider network, or to packets being sent from the customer
network into the provider network, or a combination of the above. A
business hosting a web-site might have a contract with its ISP, which
enables the responses out from the web-server to be carried at a
better performance level than the default. One business may not want
to pay for a better performance level for requests trying to reach
its server, while a third business may be willing to pay more both
for its requests as well as responses. Depending on the type of
service contract between the customer and the provider, the network
may control packets being sent into it, packets being sent out of it,
or both.
A service may be defined which is dependent on the time-of-day. A
customer may want a better performance of service during business
hours, and may choose to revert to the default behavior during off-
hours. A customer may require that a different path be offered to
its packets which satisfy certain constraints (e.g., a minimum of T1
capacity along any link connecting the service), or meet certain
geographical or topological constraints (e.g., packets must not leave
the boundaries of the United States).
A service may be defined based on the performance level to be
expected between a pair of customer access points to the network.
Thus, one may define a service, which would offer statistical bounds
on the delay or loss rate to be experienced between two access-
points. While such performance bounds may be different for different
access-points, some providers may choose to offer a service, which
would provide the minimum acceptable performance among any two points
on the customer network.
Such performance assurances may be coupled with constraints on how
much traffic a customer may inject into the provider's network.
A service may be defined on the basis of the fault tolerance
properties that are offered to the customer. The service may specify
Bernet, et. al. Expires: November 1998 [Page 3]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
resumption of the service within a certain limit of time, or promise
upper bounds on the total connectivity downtime over a period of time
or the amount of traffic which is dropped due to congestion over a
given period of time.
Services, as may be obvious from the preceding paragraphs, could be
quite varied and rich in context. Different ISP's or vendors may
offer different types of services to their customers over the
network. These diverse services need to be supported and mapped onto
a few PHBs within the DS domain of the network provider. In Section
2.3, we offer some examples of the services that may be offered by a
network provider, and illustrate how they could be supported using a
few simple PHBs.
A service agreement between a customer and a provider is usually
captured in the form of a SLA. The SLA is normally in the form of a
binding business contract, which specifies the features and
performance requirements of the service provided, as well as traffic
profiles and/or corresponding packet marking requirements that are
captured in a traffic conditioning agreement (TCA) [DSARCH]. SLA's
may be static or dynamic. Static SLAs, that are the norm at the
present time, are defined at service initiation time, and do not
change frequently. Static SLAs may include the provision of specific
performance levels to a selected set of applications, time-of-day
changes in performance requirements, and changes dependent on network
load, as long as the specific agreement between the customer and
provider does not change. Dynamic SLAs, on the other hand, are
possibly subject to frequent changes, and may require an automated
protocol such as the bandwidth broker [BB] or other methods between
the customer and the network.
2.1.1 Sample SLA
The following example illustrates a boundary between two networks and
a simple static SLA:
The customer's network sends traffic to the provider's network via
the customer's egress router. The provider's network receives
traffic from the customer's network via the provider's ingress
router. The SLA takes the following form:
Service Level Profile
Premium R = 100 Kbps, b = 1000 bytes, r = 100 Kbps
Assured Gold R = 1000 Kbps, b = 1000 bytes, r = 250 Kbps
(where R: peak rate, b: burst size, r: average rate)
Some of the characteristics that might be used to describe an SLA
between a customer and a service provider are discussed in the
following paragraphs.
Bernet, et. al. Expires: November 1998 [Page 4]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
2.1.1.1 Qualitative Performance and Quantitative Performance
SLAs may characterize Performance levels in qualitative (i.e.,
relative) terms, or in absolute quantitative terms. An example of a
qualitative performance guarantee would be "Traffic from stream A
will be given priority over traffic from stream B". An example of a
quantitative performance guarantee would be "Traffic from stream A,
if provisioned at an average rate of 100 Kbps, with bursts not
exceeding 64 KB allowed at a peak rate of 1 Mbps, will then have a
loss rate of no more than 0.001%, when averaged over the interval of
1 hour".
2.1.1.2 Throughput Characteristics
Throughput characteristics (sometimes referred to as Token Bucket
Models) are another means to define a quantitative SLA. This model
could be used to describe a service that guarantees to deliver
traffic at a certain sustained rate and to accommodate bursts of a
limited size up to a certain peak rate.
2.1.1.3 Latency Parameters
A SLA may define maximum latency (or delay) as well as jitter bounds
for any packet within a specifically marked traffic stream within a
certain traffic profile.
2.1.1.4 Packet Loss (or Drop) Probability
A service may guarantee a limit on the percentage of packets dropped
from a certain flow. Typically, such a service is defined using
token bucket parameters and a drop probability.
This is typically a relative contract. For example - "When traffic
from flow A conforms to X token bucket parameters, it is 90% less
likely to be dropped than traffic from flow B. If it does not
conform to the profile..."
2.1.1.5 Additional Performance Parameters
Additional performance parameters may be offered using
specific PHBs. differentiated services does not dictate a
specific set of performance parameters.
2.1.2 Service Constraints
SLAs may be offered which meet certain constraints in addition to
those listed above. Two of the most obvious constraints are Locality
and Time.
2.1.2.1 Flow Locality-based Constraints
SLAs may be offered only for communication between specific ingress
Bernet, et. al. Expires: November 1998 [Page 5]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
and egress points. Others may allow combinations of various ingress
or egress points. For example, services may be offered:
a. For all traffic between ingress point A and egress point B.
b. For all traffic originating at ingress A, to any egress
point.
c. For all traffic originating at any ingress point, to egress
point B.
d. For traffic from the group of ingress points A to the group
of egress points B.
2.1.2.2 Time based Constraints
These SLAs would typically specify a reduced or improved performance
service for certain hours of the day and/or days of the week or
month.
2.1.3 Other Service Characteristics
Although differentiated services focuses primarily on performance
related characteristics, other non-performance characteristics may be
offered as part of a contract.
Examples of these non-performance-based characteristics might
include: availability and reliability, security (e.g., encryption).
The SLA shown in Sec. 2.1.1 defines two levels of service to the
customer at the specific boundary [CLARK].
2.2 Service Provisioning
In order to support a range of different services, a network would
map all traffic into one or more of the PHBs that it supports. One
of the preconditions for satisfactory performance of the network is
that the provider provision its network so as to be able to meet the
performance needs of the customers under normal operating conditions
according to the negotiated SLAs. Thus, adequate attention must be
given to the right selection of the speed of the network links
available within the DS domain of the network provider.
The provisioning of the network would be done on the basis of the
predicted (or contracted) traffic, which the network provider would
expect from its customers. The provisioning decision has to take
into account the needs for traffic belonging to different PHBs.
Let us examine two simple cases of PHBs that can be supported in the
provider network. [DSHEAD] specifies two PHBs, an Expedited
Forwarding PHB and a Default PHB. Packets marked with the Expedited
Bernet, et. al. Expires: November 1998 [Page 6]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
Forwarding PHB are put into a queue which is serviced frequently, and
packets belonging to the Default PHB are serviced less frequently
when the Expedited Forwarding queue is non-empty. Within this
context, the network may expect a certain amount of traffic marked
with the Expedited Forwarding PHB between its various access points,
and a different amount of traffic marked by the Default PHB between
the different access-points. In order to meet the desired
performance goals of the network, the network provider may decide to
provision the links in its network, or conversely, the SLAs, so that
the expected load due to Expedited Forwarding traffic on any node/
link in the network does not exceed a fixed percentage (e.g., 10%),
and the expected load due to the combined (Expedited Forwarding and
Default) traffic on any other element does not exceed another
(higher) percentage (e.g., 90%). There are well-established tools
and algorithms, which would enable the network provider to obtain an
optimum configuration of the network to satisfy these constraints.
Another PHB case may consist of defining a limited number of output
queues (e.g., four) at each of the routers in the DS domain. A
packet marked with one of the distinct codepoints is placed into one
of the four queues in the network. The queues are served using a
algorithm according to weights which are configured by the network
provider at the different routers. The network provider would
compute the expected distribution of traffic at each of the network
elements belonging to each codepoint. It would then assign weights
at the different routers so that they match the ratio of the
different traffic load expected at the specific router. With this
provisioning of the network, the provider can expect to satisfy the
average load on the network in a satisfactory manner.
In either of the two cases (or any other network provisioning case)
described above, the network provider's predictions of traffic may
not match the actual usage of the network. When the actual usage of
traffic exceeds the provisioned traffic for any specified codepoint,
the network provider may choose to regulate the amount of traffic
that could be allowed into the network for a specific codepoint. The
excess traffic may be discarded, smoothed, or converted to another
codepoint, or just billed at a different rate depending on the
policies adopted by the network provider.
A network provider would typically run metering and accounting
software on the access points to estimate the amount of traffic
flowing between its different customer access-points. An estimation
of the these traffic flows can then be used in order to provide
admission control of traffic belonging to different codepoints in the
network (assuming some form of admission control protocol or policy
is in place).
When the network provider opts to use admission control to limit the
amount of traffic belonging to different codepoints (and hence
enforce or validate a given SLA), each access-point has a limit on
the amount of traffic it can inject into the network. The limit may
Bernet, et. al. Expires: November 1998 [Page 7]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
be enforced as an aggregate depending only on the codepoint of the
traffic entering the network, or enforced on separate traffic streams
which may be defined by the codepoint of the traffic as well as by
other header field values, including the destination access-point
(prefix) of the stream. Access control on the basis of separate
traffic flows or streams is better from the perspective of efficient
network resource usage, but requires the ingress access-point to
maintain more routing information to determine the egress access-
point. The shaping of the traffic based on some form of admission
control could be distributed to the edges of the network (i.e., host
or first-hop router) as needed. If this is done, then minimal state
is needed within the core of the network while still maintaining the
SLA.
In either of the two modes of access-control defined above, the DS
network needs to determine the amount of bandwidth to be assigned to
a specific codepoint at each access-node. The amount of bandwidth
may be obtained by management software in the network which
determines the routing topology of the network, obtains the expected
traffic at each access-point, and determines the correct admission
control limits for the traffic at each access-point. A distributed
version with admission control daemons that track resource usage at
each of the intermediate routers and hosts participating within the
DS domain can also be used.
2.3 Service Examples
In this section, we describe a few service examples, and show how
some specific PHBs could support them. We use two simple sets of
PHBs. The first set of PHBs consist of two codepoints, one
specifying Expedited Forwarding behavior and the other specifying a
Default behavior [DSHEAD]. The second set of PHBs consist of four
codepoints, each specifying a different queue at each router, the
queues being serviced on a weighed basis as configured by the network
provider [DSPREC].
2.3.1 Services Enabled by First set of PHBs.
The ISP offers three levels of service to the businesses that are
hosting web-servers on its DS domain. The "Preferred Service"
enables users trying to access the business sites with better
performance for both the request and response of the web-server. The
"Special Service" enables users trying to access the business sites
with better performance for the web-responses, while the "Normal
Service" provides the default performance for both requests and
responses.
In order to provide the services using the Expedited Forwarding and
Default PHBs, the network provider maintains a list of the addresses
and ports at which the preferred and special clients' web-servers are
operational. For all packets in which either the source host/port
Bernet, et. al. Expires: November 1998 [Page 8]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
combination or the destination host/port combination identifies a
preferred web-server, the packets are marked with the Expedited
Forwarding codepoint. If the source host/port combination indicates
a special service web-server, the packets are also marked expedited.
All other packets are marked with the default codepoint. Using this
scheme, the right type of performance is given to the customers
hosting a preferred web-server.
A second type of classification service may be provided by an ISP to
its business clients using this PHB set. For each of the business
customers, some set of web-sites are identified as being more
relevant to their business. The ISP would provide expedited
forwarding to traffic from the web-sites that are considered relevant
to its business by the customer. As opposed to the preferred/special
service definition presented above, the customer accessing the web-
site, not the person hosting the web-site, drives the classification.
Such a marking can be done by supporting a PICS capable web-proxy at
each ISP access-point which uses a business rating system to classify
the web-pages into those relevant/irrelevant for a specific customer,
and marking the packets as Expedited Forwarding/Default
appropriately.
Another example of service that can be provided using this is
preferential service that may be given to "Premium Customers" when
they use the network provider to provide connectivity between
different customer premises. The packets, which contain the source
or destination addresses of the premium customers, are marked as
Expedited Forwarding packets while the other packets are marked with
the default codepoint. For example, an enterprise with an out-
sourced VPN which is replicating multiple databases or directories
across different geographies or other mission critical functions
across the VPN.
In this example, all data being transmitted between the mission
critical replicated servers would be classified as "Preferred
Service" and given priority across the VPN (similar to a virtual
leased line). User traffic from outside the network destined to
specific servers within the network (i.e., web-servers) might be
given a different level of access called "Response Service". This
service would have other specific characteristics such as minimum
response time, latency and availability requirements. Any other
traffic on the VPN would be marked as "Normal Service" and would be
considered a best effort service, associated with the default PHB.
2.3.2 Services Enabled by the Second Set of PHBs
An ISP offers two services to its customer. The "voice" traffic
results in a low bandwidth low-delay communication across the ISP
network. The "video" traffic results in a high-bandwidth low-delay
communication across the ISP network.
The "data" traffic provides behavior equivalent to that found in
Bernet, et. al. Expires: November 1998 [Page 9]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
current IP networks.
The ISP supports these three modes of services by mapping them into
the three different queues at each router. The ISP periodically
recomputes the load and routing patterns of its voice and video
connections, regenerates the weights on each backbone router to
support this set of services, and reconfigures the router.
A second service offered by the same ISP is that of a fixed bandwidth
pipe. The ISP offers a specific bandwidth between two access-points
of its customer. The ISP adjusts the weights of the different queues
to meet the bandwidth requirements of all the customers passing
through a router in the appropriate queue. These weights are only
recomputed when a new pipe is added or an existing pipe modified or
deleted.
3. Service Control Mechanisms
3.1 Service Allocation and Configuration
Each access-point to a DS domain needs to be configured with the
appropriate packet classification rules. At each of the access-
points, the provider of a specific DS-domain is either a provider to
a customer, or may be a customer of yet another provider. The
support of a SLA requires that the configuration of functional
components at the boundary be done with parameters that are designed
to support the required SLA performance levels. In order to support
specific services, specific functionality may be required of the
classifiers, meters, markers, shapers and policers at an access-
point [DSARCH].
Boundaries between two DS networks and between a DS and non-DS
network, are of particular interest. At each such boundary, at least
one network is a customer and one is a provider. The provider agrees
to carry certain subsets of the customer's traffic at certain service
levels. This agreement is captured in the form of an SLA. Specific
functionality is required at such boundaries, to serve the needs of
the customer and the provider, subject to the SLA. This section
describes the methods by which such functionality may be configured.
3.1.1 Service Allocation
Two types of SLA may exist, static and dynamic. A static SLA changes
infrequently (typically weekly, or monthly) and typically is
renegotiated by human interaction. Dynamic SLA's change frequently
and typically are renegotiated via a machine to machine negotiation
protocol of some sort. Note that a static SLA may call for different
service levels to be supported at different times of day, in which
case, the service covered by the SLA changes automatically and
somewhat frequently, however, the agreement itself does not change
frequently.
Bernet, et. al. Expires: November 1998 [Page 10]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
In order to adhere to a SLA, it is useful to configure certain
functional components at access-points. These may include
classifiers, meters, markers, shapers, and policers, as explained
below.
An access-point to a DS domain can run in one of two modes of
classification, as a microflow or traffic stream classifier (MFC),
or a bandwidth aggregate classifier (BAC). As a MFC, the access-
point classifies microflows (identified by the 5-tuple of src/dest IP
addresses, src/dest ports and the protocol) or traffic streams
(identified by subsets of the 5-tuple) and marks the DS field
according to the classification rules that are configured for it. As
a BAC, the access-point expects that the customer has already marked
the DS field appropriately after running a MFC function on its own
behalf, and only looks at the DS field. Even as a BAC, the access-
point may choose to remark the DS field as it may check the
aggregated traffic level associated with the DS field to make sure it
fits into limits defined for it by the appropriate SLA. In either of
the two modes, the access-point can perform the policing function on
the aggregate stream as a result of the classification process.
In the first mode, the customer applies no traffic conditioning.
Instead, the customer contracts with the provider to do per-microflow
or per-traffic stream classification, marking and policing. In the
second mode, the customer applies per-microflow/stream classification
and marking. In this case, the provider applies aggregate (per-
service level) classification and policing, to assure compliance with
the SLA. It is assumed that all traffic from a single customer
arrives at an interface dedicated to the customer. If multiple
customers share a single interface, it will be necessary to apply
additional finer-grain classification for the purpose of
conditioning. Provider marking will typically be applied at the
periphery of the DS domains, where a DS network connects to
non-DS, stub networks.
Shaping is not included in the above discussion, but may be
recommended in the customer's network, or the provider's network or
both.
Typically, flows will be shaped within the customer's network. By
shaping at the microflow level, the customer can maintain traffic
separation, ensuring that no microflow will seize more than its share
of the aggregate DS domain resources guaranteed by the SLA. By
shaping at the aggregate stream level, the customer can assure
aggregate compliance with the SLA and for example can avoid charges
that may have been negotiated as part of the SLA for excess traffic.
However, by shaping at the aggregate stream level only, the customer
cannot assure traffic separation once the traffic is injected into
the service provider's network.
Devices that do full microflow classification will be more complex
than those that just offer bandwidth aggregation classification
Bernet, et. al. Expires: November 1998 [Page 11]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
support. The costs associated with these devices will should be
considered when determining where the classification and flow shaping
should occur within the DS domain. In certain cases, the customer
may contract to have the provider apply microflow or aggregate
shaping. This is a form of value-add which providers may offer
customers that are incapable of providing their own shaping.
Obviously, wherever shaping is applied at a microflow level,
microflow classifiers will be required. Wherever shaping is applied
at the behavior aggregate (BA) level, BA classifiers will be
required. In general, classifiers are required only to support other
traffic conditioning functionality such as policing, marking, and/or
shaping. Subsequent discussion of specific functionality implies the
co-existence of the appropriate classifier.
A static SLA with marking performed by customer requires that the
customer provide an MFC at or before its egress, and the provider
provide a BA policer at the ingress access-point. A static SLA with
provider marking would require that the access-point support a MFC
and BA policer at the ingress access-point.
3.1.2 Service Configuration
Configuration requirements may vary depending on several parameters:
Variations in the distribution of the configured functionality, e.g.,
use of the MFC mode versus the BA mode, specific functional
components being configured (policers versus markers), and the nature
of the SLAs (static versus dynamic). The functionality and
operational mode of access-points (egress as well as ingress) need to
be specified within a DS-domain.
In order for the classification to work efficiently, it must be
simple and easy to configure. Furthermore, the configuration of
different access-points must be consistent. Otherwise, the
performance of the service provided to the different customers may be
erratic. For example, assuming the preferred ISP service described
in Section 2.3.1 is being supported, all the access-points must have
an entry classifying the same set of sites into its "Preferred"
class. Note that consistency does not imply that the configuration
information is identical for all the access-points. In the special
ISP service described in Section 2.3.1, the configuration entry for
each web-server needs to be only present at the access-point to which
the web-server is attached.
The simplest approach to the configuration problem is to ignore it.
The assumption would be that the ISP would configure each router
manually, and in a static manner. This solution requires extensive
manual upgrade to each ISP router whenever a new service or a
customer is added or deleted. The solution would not work well in
practice.
Bernet, et. al. Expires: November 1998 [Page 12]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
Another option might be for the DS field to be marked with the
correct PHB service request by hosts or first-hop routers within the
CPE and then expedited through the ISP's (and billed based on this
service) network as described.
The ideal solution should provide a single administration point where
the ISP can enter the configuration rules from a centralized site.
The configuration information should also permit scalability, in that
a large number of different ingress routers should be capable of
receiving the configuration information. At the same time, the
configuration information should not become a single point of
failure, which can bring the entire network to a halt. One solution
to the configuration problem is a protocol, which permits the
administration at a single master site, but allows replication to
several slave/mirror sites, which can be looked up by a large set of
access-points to permit a scalable operation.
Another desirable attribute for scalability would be the ability to
cache a limited set of classification rules and to query other rules
as and when needed.
Several alternatives exist for such a configuration policy. Some of
these alternatives are outlined below:
The SNMP MIB approach:
One may define a diffserv-specific SNMP MIB that needs to be
supported at each of the access-routers, and can be populated using a
SNMP manager. The MIB definition approach would enable a centralized
administration of the configuration information.
However, the MIB approach does not enable caching in an efficient
manner. Since the MIB for each access-point would have distinct
entries, consistency would have to be enforced using a layer above
the SNMP manager.
The LDAP approach:
One can store the configuration entries in a directory accessible
using the LDAP protocol. The directory is looked up at the
initialization of the access-point. Directories permit centralized
administration at one master site, and support replication to
different slave sites. The access-point can also cache portions of
the classification rules, and can query the appropriate rule when
they detect the initiation of a new session (e.g. seeing a TCP header
with the SYN flag). The directory schemata also permit a way to
provide configuration information for a group of access-point in a
single entry, which can provide consistent configuration across
several access-points. The one drawback of the directory protocol is
inadequate support for asynchronous notification, which is currently
being discussed, in the various working groups. A tentative schema
for classification rules using this schema has been proposed in
Bernet, et. al. Expires: November 1998 [Page 13]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
[Ellesson].
The COPS approach:
One can extend the policy query protocol for RSVP to provide
classification information for differentiated services. COPS
supports asynchronous notification in a better way but has not yet
addressed issues of replication of classification rules at different
sites [COPS]. COPS extensions that support diffserv semantics would
need to be developed in order to use this approach.
When dynamic SLA's are being supported, the above mentioned
configuration approaches need to be augmented with a negotiation
protocol between the customer and provider network to negotiate the
current details of the service levels. To this end, a standard
protocol is required between customers and providers. Such a protocol
would enable customers to present requests to providers that would
result in changes to the SLA. Entities within the provider's network
would respond to these requests by determining if the requested SLA
could be met, adjusting the policers accordingly and responding to
the customer's request. The bandwidth broker, as described in [BB]
is such an entity.
One realization of such a protocol is RSVP [RSVP]. Other protocols
could also be devised for this purpose.
3.1.2.1 Functionality Required at Boundary Equipment
In the interest of adhering to the SLA, it is useful to configure
certain functional components at DS boundary nodes. These may
include classifiers, markers, meters, shapers and policers as
described in the following section.
The following basic combinations of functional components are
possible:
Mode Customer's Egress Provider's Ingress
Provider marking None MFC, BAC, M, P
Note: Provider classifies microflows to aggregated service level
and marks DS field accordingly. Provider polices based on
aggregate.
Customer marking MFC, M BAC, P
Note: Customer classifies microflows to aggregated service level
and marks DS field accordingly. Provider polices based on
aggregate.
MFC - MF Classifier
Bernet, et. al. Expires: November 1998 [Page 14]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
BAC - BA Classifier
M - Marker
P - Policer (policing shaper)
In the first example, the customer applies no traffic conditioning.
Instead, the customer contracts with the provider to do per-microflow
classification, marking and policing. In the second example, the
customer applies per-microflow classification and marking. In this
case, the provider applies aggregate (per-service level)
classification and policing, to assure compliance with the SLA. It
is assumed that all traffic from a single customer arrives at an
interface dedicated to the customer. If multiple customers share a
single interface, it will be necessary to apply additional finer-
grain classification for the purpose of policing.
Provider marking will typically be applied at the periphery of the DS
domains, where a DS network connects to a non-DS, stub network.
Note that shapers are absent from the table above. Shapers are not
strictly required but are recommended, at the customer's network, the
provider's network, or both.
Typically, flows will be shaped within the customer's network. By
shaping at the microflow level, the customer can maintain traffic
separation, ensuring that no microflow will seize more than its share
of the aggregate DS domain resources guaranteed by the SLA. By
shaping at the aggregate stream level, the customer can assure
aggregate compliance with the SLA and for example can avoid charges
that may have been negotiated as part of the SLA, for excess traffic.
However, by shaping at the aggregate level only, the customer cannot
assure traffic separation.
In certain cases, the customer may contract to have the provider
apply microflow or aggregate shaping. This is a form of value-add
which providers may offer customers that are incapable of providing
their own shaping. Obviously, wherever shaping is applied at a
microflow level, MF classifiers will be required. Wherever shaping
is applied at the behavior aggregate level, BA classifiers will be
required. In general, classifiers are required only to support other
functionality such as meters, markers, or shapers. Subsequent
discussion of specific functionality implies the co-existence of the
appropriate classifier.
3.1.2.2 Configuration of Functionality at Boundary Equipment
Configuration requirements may vary depending on the following
parameters:
1. Variations in the distribution of configured functionality, as
described in the previous section.
Bernet, et. al. Expires: November 1998 [Page 15]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
2. The functional component configured (for example, policing vs.
shapers vs. markers).
3. The nature of the SLA (static vs. dynamic).
This section describes configuration methods subject to the
variations listed.
3.1.2.3 Static SLA, Provider Marking
In this scenario, it is necessary to configure the following
functional components:
1. A MF classifier + marker at the provider's ingress node.
2. A BA policer at the provider's ingress node.
The SLA specifies the traffic profiles that should be configured per-
service level for the policer at the ingress node of the provider's
network. The format of the information to be configured is tabulated
in Sec. 2.1.1. Since the SLA is static, this information changes
infrequently and likely requires human intervention.
Therefore, the policer will typically be configured remotely via SNMP
or via a command-line interface.
The marker configuration is actually independent of the SLA.
The customer may contract the provider to mark any service level
based on the results of the MF classification.
Configuring the marker is similar to configuring access lists on
standard switches and routers. Such lists take the form of "n-tuple:
service level", where "-tuple" refers to some combination of possibly
masked values in packet headers. Such information is lengthy and
error prone. In addition, it is subject to change more frequently
than a static SLA and, does not require the approval of the provider.
While it is possible to configure markers using the same static
methods as used to configure the policers (SNMP and/or command-line
interfaces), there are strong incentives to provide dynamic marker
configuration via a standard protocol that is available to the
customer. RSVP may be used for this purpose.
3.1.3 Receiver Control
In differentiated services there are two possible types of receiver
control. One, which has been addressed in a previous section, is
when the receiver is allowed to control how the marking of the DS
field is performed at the sender side. This can be done either in
accordance with a static SLA that the user has with the provider, or
by use of application- or session-level signaling which induces the
Bernet, et. al. Expires: November 1998 [Page 16]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
sender (or a DS edge node) to mark the packets in accordance with the
receiver's preferences.
Another type is when the receivers need to control the priority of
packets that arrive from the network onto his/her access link. There
are two reasons why this is important. One is that it provides
protection from certain types of denial-of-service attacks. The
other is that this is important on low bandwidth access links, in
particular for mobile IP hosts.
At the last-hop router, before the egress link, traffic from
different sources are merged onto the access link of the receiver
(destination). Some packets might have been marked with respect to
the SLA the receiver has with the ISP, others might not. To allow
the receiver to control which traffic gets priority on its access
link it should be allowed to direct the egress node re-mark (or use
an alternative PHB than what is in accordance with the marking that
was made with respect to the sender's SLA) packets at the egress
node, in accordance with a "receiver marking policy". This can be
thought of as a special case of a static or dynamic SLA between a
downstream network (the ISP) and an upstream network (the receiver).
Such a "receiver marking policy" could e.g. state that all IP
telephony traffic (e.g., identified by a particular source port
number) should be given priority to all other traffic.
3.1.4 Policy Protocols
Two types of requests have been described which can result in
allocation of resources to particular users (at the expense of
others), and which may result in charges to customers. The two types
of requests are requests to mark traffic for prioritized treatment
(subject to the terms of an existing SLA), and requests to change
the existing SLA. These requests should be governed by policy
decisions. Information required to make policy decisions must be
conveyed to policy servers. These must reply with approval or
rejection of the request. COPS is an example of a policy protocol
suitable for carrying such requests.
3.2 Requirements for Measurement and Management.
In order to validate conformance to the specific SLA's within a DS
domain, the network operator should measure the performance of the
traffic belong to specific codepoints within its domain. The
measurement of traffic can be done in one of two modes:
Single Point Measurements: These measurements would monitor the
traffic in the network at a single point in the network. Such a
measurement can be done at the access-point of the network after
classification, and reported to the network management tools using
RMON MIBs [RMON]. A network operator can also station real-time flow
Bernet, et. al. Expires: November 1998 [Page 17]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
monitors, and collect a more comprehensive record of the type of
traffic flowing in the network [RTFlow].
Dual Point Measurements: These measurements would monitor the
performance of the traffic between ingress access-points and the
egress access-point within the DS domain. The measurement of
performance could be done by means of network performance monitoring
protocols stationed at the two egress points. Network performance
monitoring protocols tend to be relatively heavyweight in their use
of network bandwidth, and these protocols should be used only when a
potential violation of the SLA is suspected between the two access-
points.
It would be desirable for a DS domain operator to have a continuous
low-overhead monitoring of the service-levels obtained by packets
within its domain using a passive monitoring scheme. When the
passive monitoring scheme suspects a potential problem, the more
heavyweight performance monitor can be activated. A SNMP manager may
be used as an intermediary to trigger this activation, with the
passive monitoring protocol generating an SNMP trap on suspicion of
SLA violation and the manager subsequently activating active
performance monitoring.
4. Inter-Domain Considerations and End-to-End Services
While the differentiated services architecture works very well to
enable different service level agreements within a single ISP domain
or in a corporate Intranet, comprehensive service differentiation in
the Internet requires that there is support for service
differentiation in a uniform manner across several ISP's.
In general, communication across the Internet traverses several ISP
boundaries. When a browser accesses a web-server, the connection
traverses the client (browser) network; multiple ISP networks, and
eventually reaches the server network. The response from the server
traverses a (possibly asymmetric) path back to the client host. In
these cases, SLAs are usually only specified between the client and
its ISP, the server and its ISP, and between the neighboring pairs of
ISP's. Within this context, one must enable the definition of
services across the Internet using only bilateral SLAs between the
adjacent providers.
In order to appreciate the issues in service definition; let us
consider the "Preferred Service" web-service described in Section
2.3.1. When the preferred service is provided, any client accessing
the web-server must be provided Expedited Forwarding service for its
requests as well as its response stream. As long as the client
browser connects to the same ISP as the server, the preferred service
is straightforward to provide. However, when the client browser is
connecting to a different ISP, expedited processing for request
packets is not enabled until they reach the domain of the ISP
Bernet, et. al. Expires: November 1998 [Page 18]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
immediately connected to the server.
Similarly, the expedited processing for response packets may not be
honored once the response packets leave the domain of the ISP.
Some of the methods by which the service concept can be extended
across multiple ISP's are outlined in the following sections.
4.1 Service Provisioning Across Boundaries
There are two basic schemes which can be used to provide service
levels across ISP boundaries. The first scheme consists of
negotiating an aggregated bandwidth classification to one neighbor,
and the second scheme consists of negotiating a microflow or traffic
stream classification to a neighboring ISP.
An aggregated bandwidth negotiation is useful in preserving the
desired service levels of packets that are leaving an ISP DS domain.
If an ISP A is sending packets into the DS domain of an ISP B, ISP A
would negotiate a SLA which would honor the DS field marking created
by ISP A. As packets enter the domain of ISP A, they would be marked
with a specific codepoint. Before the packets leave the domain of
ISP A and cross over to ISP B, they would be remarked so that DS
field encoding matches the ones expected by ISP B as per the SLA
between A and B.
For example, let us assume that the SLA between A and B
specifies that A would treat all packets marked for Expedited
Forwarding with the same PHB as long as the aggregate inbound packet
rate is less than a certain limit. For the service category of
"special service" as described in Section 2.3.1, ISP A would mark all
response packets originating from the special web-servers for
Expedited Forwarding. It would also negotiate the SLA with ISP B so
as to obtain a rate for Expedited packets, which would be adequate to
meet the demand for its servers. Since ISP B would carry the packets
at expedited level through its domain, the special service would be
provided to all clients accessing either ISP A or B. A transitive
agreement between B and other service clients would lead to the
service being special to all clients in the Internet.
For boundaries where the aggregated bandwidth is negotiated, one ISP
can simply act as the customer of another ISP. The marking and
policing scheme would work as for any other DS domain boundary
situation.
The aggregated bandwidth negotiation is not adequate for providing
the preferred service described in Section 2.3.1.
The packets originating from a client who is connecting to ISP B and
trying to access a preferred web-server (as defined in ISP B's SLA
with ISP A) will not receive the Expedited Forwarding treatment in
Bernet, et. al. Expires: November 1998 [Page 19]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
the domain of ISP B since ISP B has no information that allows it to
treat these packets specially. The client may have no SLA with ISP
B. One of the ways in which ISP A can manage to extend the preferred
service agreement to clients in the domain of ISP B is to exchange a
microflow- or traffic stream-level SLA with ISP B. In this
negotiation, ISP A would inform ISP B about the set of destination
addresses (or prefixes) which need to be treated preferentially. In
return ISP A would configure all of its access-points to mark the
packets headed to the preferred service for Expedited Forwarding.
An ISP may want to choose some other codepoint for marking packets
belonging to the microflows/streams, which have a SLA with some other
ISP. There is also an associated scaling problem with too many
microflow/stream classifier entries floating across multiple ISP
boundaries. The ISP may want to export the microflows/streams
classifier designations only across a certain number of
administrative domains, and pay different amounts depending on how
far the microflow/stream classification negotiation would be carried.
An ISP may also want to provide different levels of preferred service
to its web-server customers. A service where preferred service is
extended to all the clients in the Internet may cost substantially
more than a service where preferred service is only extended across
one or two ISP domains.
4.1.1 Requirements for Service Level Agreements
Although the differentiated service architecture focuses on
differentiated treatment within a single domain, it is expected that
different DS domains will be linked to each other through mutual
agreements and the DS region will expand in an incremental fashion.
How two different DS domains are interconnected is governed by the
SLA between two-DS domains. The SLA will specify details as to how
each other's traffic is conditioned at the boundary of the two
domains, and how packets are re-marked to be promoted or demoted
within a PHB group.
A SLA is normally a contract between two DS domains, which specifies
details of treatment for traffic crossing the boundary of the two
domains.
A SLA may contain the following:
Performance, Security, Availability between the domains: A bilateral
agreement may dictate when the service is available and what type of
performance and security are expected when the service is running.
Rules for traffic conditioning: A SLA should specify how traffic from
one DS domain will be conditioned crossing the boundary, including
classification rules (MF classification or BA classification),
profiles for each PHB, actions for packets out-of-profile (marked
with a different PHB or shaped/discarded).
Bernet, et. al. Expires: November 1998 [Page 20]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
Mapping of PHBs between two domains: If the two DS domains use two
distinct PHB groups, it may be necessary to establish some rules for
mapping one PHB to another.
Location of traffic conditioning: The packets can be conditioned by
the egress node of one DS domain before the traffic crosses to the
next DS domain, or by the ingress node of the next domain.
4.1.2 Promotion and Demotion within a PHB group
When two DS domains use similar PHB groups, packets crossing the
boundary may be promoted or demoted to use a different PHB with the
same PHB group. Such promotion and demotion take place when there is
a mis-match between the traffic rate specified in the SLA and the
actual traffic rate. For example, two ISP's both offer three traffic
classes: premium, standard and best effort. If the amount of premium
traffic crossing the boundary is greater than the rate specified in
the SLA, some of the premium traffic may be demoted to standard
class. On the other hand, if there is less premium traffic than
specified in the SLA, standard traffic may be promoted to premium.
4.1.3 Mapping of PHBs at Boundaries
When two DS domains are based on very different PHB groups, the SLA
has to specify how one PHB in one DS domain is mapped to a PHB in
another domain. If the PHBs have different values but similar
semantics, the mapping may be simple. However, in some case, the
mapping can be very difficult. For example, one DS domain uses
queueing priorities while the other is based on discard priorities.
However, in general, a "better" treatment in one PHB group should be
mapped to another "better" treatment.
4.2 Host Interactions
In the previous sections, we discuss the differentiated services
primarily from the perspective of a service provider. In this
section we look at how the users can make use of services offered by
DS-capable networks. A host which is DS aware is just another DS
egress device; not a special case.
4.2.1 Traffic Conditioning for Directly Connected Users
A user can gain access to a DS-capable network directly or through a
customer domain. Users who are directly connected to a DS-capable
ISP (e.g., a dial-up user) should have a SLA with the ISP. Complex
traffic conditioning functions ideally should ideally be performed by
the hosts of the users rather than the access nodes, which may have
to handle tens of thousands of users.
However, mechanisms have to be in place so that the ISPs are assured
that they can trust the self-policing by the users.
Bernet, et. al. Expires: November 1998 [Page 21]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
Users may have to install DS control software from ISPs. When a user
dials in, the authentication process also configures the DS control
module in the user's host according to the SLA between the user and
the ISP. Random checking can also be done to ensure that the SLA is
maintained.
4.2.2 Service Allocation within Customer Domain
When users are part of a customer domain, there is an issue of local
resource allocation. The customer domain should have a policy as to
what packets can be set to use a particular PHB group. Some form of
allocation, either static or dynamic, is needed in order to share the
profiles that the customer domain has obtained. The egress node of
the customer domain may perform traffic conditioning on the
aggregated traffic to ensure that the packets crossing the boundary
to the ISP conforms to the SLA between the customer domain and the
ISP.
A number of mechanisms for local allocation have been suggested. One
is bandwidth broker, which acts as a central allocation server for
the customer domain and as a client to request additional resources
from the ISP [BB]. RSVP may also be adopted as a mechanism for
requesting bandwidth with the customer domain and the resources to
the ISP [RSVP].
4.2.3 End-to-End Services
The differentiated services architecture is designed to be deployed
incrementally. ISPs are likely to offer differentiated services
first within their own networks, and conduct experiments. Over time,
ISPs will design business models for the new services and start to
extend the services by signing SLAs with other peering ISPs.
Since the differentiated services model is biased towards long term
allocation rather than on-demand reservation, the guarantees for any
differentiated services come through proper provisioning. Unless
there is a clear traffic pattern, provisioning becomes much harder
when more DS domains are linked together. The level of provisioning
depends on the economic factors in the differentiated services and
varies from ISP to ISP. In general, when the packets leave the ISP
to which the customer has a SLA, the level of service may degrade.
For example, if the traffic aggregate for a particular PHB were over
the rate the next ISP would accept, some packets may be demoted to a
PHB with worse treatment. The more ISPs a packet traverses, the less
control the originating ISP has.
The extensibility of the differentiated services model allows many
different schemes to be tried out and developed further.
One possible approach is to establish an ISP-to-ISP pipe across
multiple ISPs. So, the originating ISP and terminating ISP know
exactly how traffic between them is provisioned. This is similar to
Bernet, et. al. Expires: November 1998 [Page 22]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
the VPN services that an ISP offers for connecting different sites of
an organization.
5. Interoperability with Integrated Services
In this section, we discuss three possible options for the
interoperability between the differentiated services and Integrated
Services [IntServ].
5.1 Parallel Operation
Both differentiated services and Integrated Services may operate in
parallel over the same network infrastructure. It may be necessary
to set limits on the amount of bandwidth available for Integrated
Services reservations so that the bandwidth provisioning for
differentiated services traffic is protected. In general,
differentiated services provides an overall provisioning to
aggregates of traffic while Integrated Services can be used to make
reservation for long-lasting and high-bandwidth flows. This is
similar to the current telephone networks. One does not need to make
a prior reservation in order to make a phone call. The likelihood of
blocking inside the network is very small as capacity is guaranteed
through long-term provisioning. However, if one would like to make a
conference call or video call, an advanced reservation may be
necessary.
5.2 Int-serv Over Diff-serv
Alternatively, differentiated services and Integrated Services may be
tightly coupled by means of a hierarchical bandwidth allocation
scheme. Differentiated services may be used to allocate bandwidth in
bulk quantity to individual customer networks. Each customer network
may use Integrated Services mechanisms to allocate the bandwidth
among individual hosts and application flows. This model works
particularly well for VPNs when a corporation can purchase "virtual
pipes" across the Internet and then run Integrated Services over the
over-laid virtual network. Examples of this model include [E2EQOS].
5.3 Aggregated Int-serv State
In this approach, Integrated Services flow signaling state (e.g.,
RSVP) is aggregated between border nodes within a cooperating network
region. Hop-by-hop signaling messages within this region convey the
aggregated state of a number of Integrated Services flows. Packets
within an aggregated Integrated Services class are marked by a
special DS codepoint to convey aggregated classification state (the
service class, and possibly an in- or out-of-profile indicator).
Examples of this model include [GBH97, CLASSY].
Bernet, et. al. Expires: November 1998 [Page 23]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
6. Acknowledgements
The authors would like to acknowledge the helpful comments and
suggestions of the following individuals: Kathleen Nichols, Brian
Carpenter, David Black, Konstantinos Dovrolis, Shivkumar Kalyana,
Wu-chang Feng, Marty Borden, and Ronald Bonica.
7. References
[BB] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
Internet Draft <draft-nichols-diff-svc-arch-00.txt>,
November 1997.
[CLARK] D. Clark and J. Wroclawski, "An Approach to Service
Allocation in the Internet", Internet Draft
<draft-clark-diff-svc-alloc-00.txt>, July 1997.
[CLASSY] S. Berson and S. Vincent, "Aggregation of Internet
Integrated Services State", Internet Draft
<draft-berson-classy-approach-01.ps>, November 1997.
[COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and
A. Sastry, "COPS (Common Open Policy Service) Protocol",
<draft-ietf-rap-cops-01.txt>, March 1998.
[DSARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and
W. Weiss, "An Architecture for Differentiated Services",
Internet Draft <draft-ietf-diffserv-arch-00.txt>, May
1998.
[DSHEAD] K. Nichols and S. Blake, "Definition of the
Differentiated Services Field (DS Byte) in the IPv4 and
IPv6 Headers", Internet Draft
<draft-ietf-diffserv-header-00.txt>, May 1998.
[DSPREC] 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-ietf-diffserv-precedence-00.txt>, April 1998.
[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.
[E2EQOS] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, and L. Zhang,
"A Framework for End-to-End QoS Combining RSVP/Intserv
and Differentiated Services", Internet Draft
<draft-bernet-intdiff-00.txt>, March 1998.
Bernet, et. al. Expires: November 1998 [Page 24]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
[GBH97] R. Guerin, S. Blake, and S. Herzog, "Aggregating RSVP-
based QoS Requests", Internet Draft
<draft-guerin-aggreg-rsvp-00.txt>, November 1997.
[IntServ] R. Braden, D. Clark, and S. Shenker, "Integrated Services
in the Internet Architecture: An Overview", Internet RFC
1633, July 1994.
[RMON] S. Waldbusser, "Remote Network Monitoring Management
Information Base Version 2 using SMIv2", Internet RFC
2021, January 1997.
[RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification", Internet RFC
2205, September 1997.
[RTFlow] N. Brownlee, C. Mills, and G. Ruth, "Traffic Flow
Measurement: Architecture", Internet Draft
<draft-ietf-rtfm-architecture-02.txt>, Dec. 1997.
Authors' Addresses
Yoram Bernet
Microsoft
One Microsoft Way,
Redmond, WA 98052
Phone: +1-425-936-9568
E-mail: yoramb@microsoft.com
James Binder
3Com Corp.
5400 Bayfront Plaza
Santa Clara, CA 95052
Phone: +1-408-326-6051
E-mail: james_binder@3com.com
Steven Blake
IBM Corporation
800 Park Offices Drive
Research Triangle Park, NC 27709
Phone: +1-919-254-2030
E-mail: slblake@raleigh.ibm.com
Mark A. Carlson
Redcape Software, Inc.
2990 Center Green Court South
Boulder, CO 80301
Phone: +1-303-448-0048 x115
E-mail: mac@redcape.com
Bernet, et. al. Expires: November 1998 [Page 25]
INTERNET-DRAFT A Framework for Differentiated Services May 1998
Elwyn Davies
Nortel UK
London Road
Harlow, Essex CM17 9NA, UK
Phone: +44-1279-405498
E-mail: elwynd@nortel.co.uk
Borje Ohlman
Ericsson Radio
Dialoggatan 1 (Kungens Kurva)
S-126 25 Stockholm
Sweden
Phone: +46-8-719 3187
E-mail: Borje.Ohlman@ericsson.com
Dinesh C. Verma
IBM TJ Watson Research Center
PO Box 218
Yorktown Heights, NY 10598
E-mail: dverma@watson.ibm.com
Zheng Wang
Bell Labs Lucent Tech
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
Bernet, et. al. Expires: November 1998 [Page 26]
