INTERNET-DRAFTDifferentiated Services                                  S.Blake, et al

Document: draft-ietf-diffserv-framework-01.txt

                                                Yoram Bernet
Diffserv Working Group Bernet, Microsoft
Expires: November 1998
                                                    James Binder
                                                                    3Com Binder, 3-Com
                          Steven Blake
                                                                     IBM Blake, Torrent Networking Technologies
                                         Mark Carlson Carlson, Redcape Software
                                  Srinivasan Keshav, Cornell University
                                                Elwyn Davies Davies, Nortel UK
                                                 Borje Ohlman Ohlman, Ericsson
                                                      Dinesh Verma Verma, IBM
                              Zheng Wang Wang, Bell Labs Lucent Technologies
                                      Walter Weiss Weiss, Lucent Technologies

       A Framework for Differentiated Services

                  <draft-ietf-diffserv-framework-00.txt>
        <draft-ietf-diffserv-framework-01.txt>

 Status of This this Memo

   This document is an Internet-Draft.  Internet-Drafts Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas, Areas,
   and its working groups. Working Groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   and
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is inappropriate not appropriate to use Internet-Drafts Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress." progress".

   To view learn the entire list of current Internet-Drafts, status of any Internet-Draft, please check the
   "1id-abstracts.txt"
   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). ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or
   munnari.oz.au.

   A revised version of this draft document will be submitted to the
   RFC editor as a Proposed Standard for the Internet Community.
   Discussion and suggestions for improvement are requested.  This
   document will expire before April, 1999. Distribution of this draft
   is unlimited.

1. Abstract

   This document provides a general description of issues related to
   the definition, configuration, configuration and management of services enabled by
   the differentiated services architecture [DSARCH].  It This document
   should be
   considered as a work-in-progress.

Bernet, et. al. read along with its companion documents, the
   differentiated services architecture [DSARCH] and the definition of
   the DS field [DSHEAD]. A glossary of specialist terms used may be
   found in [DSARCH].

Blake, et al             Expires: November 1998              [Page  1]
   Sec. April 1999                         1 provides a

2. Structure of this Draft

   Section 3 defines Differentiated Services and explains the
   motivation for behind its deployment. Section 4 defines the deployment concept of differentiated
   services.  Sec. 2 examines a
   service and the range of services components that are enabled
   by the differentiated services architecture.  Sec. 3 examines comprise a service. Section 5
   discusses several service instantiation, configuration, examples. Section 6 examines intra-domain
   provisioning, configuration and management issues.  Sec. 4 Section 7
   examines inter-domain provisioning, configuration and management.
   Section 8 addresses interoperability with Integrated Services and
   RSVP. Section 9 discusses issues relating to the deployment interaction 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 multicast and its customer,
   which outlines the characteristics tunnelling. Section 10 addresses security
   concerns.

3. Differentiated Services - Motivation and behavior of network
   connectivity offered by the provider to the customer.  The Definition

   Traditionally, network
   provider may be an Internet Service Provider whose service providers (both enterprise and
   traditional ISPs) provide all customers include
   individual users or corporations, an I/T department within an
   enterprise, or a networking company to which with the operations same level of an
   enterprise network
   performance (best-effort service). Most service differentiation 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 (individual vs. business rates) or the
   connectivity structure (dial-in type (dial-up access versus vs. leased line T1 access, line, etc.). However, the size
   in recent years, increased usage of the Internet continues to grow at an astounding rate, and network
   capacity has become a scarce resource.  Given new types resulted in
   scarcity of media and
   the further reliance on the network as a capacity, compromising performance of
   traditional, mission critical resource,
   there is a need felt by applications. At the network same time, new
   applications have emerged which demand much improved service
   quality. As a result, service providers are finding it necessary to
   offer different
   types or grades their customers alternative levels of performance to customers, with network service. As well as
   meeting new customer expectations, this allows service providers
   offering better performance to customers who are willing to pay more.

   The key aspects determining service performance are availability
   improve their revenues through premium pricing and
   responsiveness.  Availability refers to competitive
   differentiation of service offerings, which in turn can fund the ability
   necessary expansion of the network.

   The Differentiated Services architecture offers a framework within
   which service providers can offer each customer to
   maintain connectivity between its access points a range of network
   services which are differentiated 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 basis of a differentiated service domain as

Bernet, et. al.            Expires: November 1998              [Page  2]
   described performance in [DSARCH].

2.  Services

2.1  Service Categorization

   In order
   addition to provide the notion of differentiated services, pricing tiers used in the
   network provider needs to be able to categorize traffic entering its
   network into multiple categories.  Each of past. Customers request a
   specific performance level on a packet by packet basis, by marking
   the categories DS field of traffic
   is marked each packet 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 value (see [DSHEAD] for
   more details). This value specifies the Network Provider Per-hop Behavior (PHB) to the customer.
   Service differentiation may be made along multiple dimensions.

   A provider may offer a customer a service which provides different
   performance assurances
   allotted to packets being received by the customer from packet within the provider network, or to packets being sent from provider's network. Typically, the
   customer
   network into the and provider network, or negotiate a combination of profile (policing profile)
   describing the above.  A
   business hosting a web-site might have a contract with its ISP, rate at which
   enables the responses out from the web-server to traffic can be carried submitted at a
   better performance level than the default.  One business each
   service level. Packets submitted in excess of this profile may not want
   to pay for a better performance
   be allotted the service level for requests trying to reach requested. A salient feature of
   differentiated services is its server, while a third business may be willing scalability, which allows it to pay more both
   for its requests as well be
   deployed in very large networks.  This scalability is achieved by
   forcing as responses.   Depending on much complexity out of the type core 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 edge
   devices which is dependent on the time-of-day.  A
   customer may want a better performance process lower volumes of service during business
   hours, traffic and may choose to revert to the default behavior during off-
   hours.  A customer may require that lesser numbers of
   flows, and offering services for aggregated traffic rather than on a different path be offered to
   its packets which satisfy certain constraints (e.g.,
   per-micro-flow basis.

Blake, et al             Expires: April 1999                         2

4. Services

   [DSARCH] defines a minimum Service as "the overall treatment of T1
   capacity along any link connecting the service), or meet certain
   geographical a defined
   subset of a customer's traffic within a DS-domain, or topological constraints (e.g., packets must not leave end-to-end".
   Although PHBs are at the boundaries heart of the United States).

   A service may be defined based on differentiated services
   architecture, it is the performance level to be
   expected between service obtained as a pair result of customer access points to the network.
   Thus, one may define marking
   traffic for a service, specific PHB, which would offer statistical bounds
   on the delay or loss rate is of value to be experienced between two access-
   points.  While such performance bounds may be different the customer. PHBs
   are merely building blocks for different
   access-points, some services. Service providers may choose combine
   PHB implementations with traffic conditioners, provisioning
   strategies and billing models which enable them 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 services to
   their customers. Providers and customers negotiate agreements with constraints on how
   much traffic a customer may inject into
   respect to the provider's network.

   A service may services to be defined on provided at each customer/provider
   boundary. These take the basis form of Service Level Agreements (SLAs).

   Bear in mind when considering the fault tolerance
   properties services that are offered to the customer.  The service may specify

Bernet, et. al.            Expires: November 1998              [Page  3]
   resumption of the service within in a certain limit DS-
   domain that:
   * DS services are all for unidirectional traffic only
   * DS services are for traffic aggregates, not individual micro-flows

4.1 Customer/Provider Boundaries

   Present day network traffic generally traverses a concatenation of time,
   networks which may include hosts, home or promise
   upper bounds on the total connectivity downtime over a period office networks, campus or
   corporate networks and several large transit networks. Home and
   office networks are typically customers of time campus or corporate
   networks, which are in turn customers of large transit networks.
   While one would expect the amount initial deployment of traffic which is dropped due differentiated
   services to congestion over a
   given period of time.

   Services, as be within large transit networks, its deployment may
   also be obvious from extended to the preceding paragraphs, could be
   quite varied smaller campus and corporate networks and rich in context.  Different ISP's or vendors may
   offer different types of services to their customers over
   special cases, all the
   network.  These diverse services need way to individual hosts. As such, there may
   be supported and mapped onto
   a few PHBs within the DS domain of numerous customer/provider boundaries at which the network provider.  In Section
   2.3, we offer some examples concept of the services that may be offered by a
   network provider,
   'service' applies.

4.2 SLAs and illustrate how they could be supported using a
   few simple PHBs.

   A TCAs

   At each differentiated service agreement between a customer and a provider customer/provider boundary, the
   service provided is usually
   captured defined in the form of a an SLA. The SLA is normally in the form of a
   binding business contract,
   contract which specifies the overall 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 which
   can be static or dynamic.  Static SLAs, that are the norm at expected by the
   present time, customer. Because DS services are defined at service initiation time, and do not
   change frequently.  Static SLAs may include
   unidirectional the provision two directions of specific
   performance levels to a selected set flow across the boundary will
   need to be considered separately.  An important subset of applications, time-of-day
   changes in the SLA is
   the traffic conditioning agreement, or TCA. The TCA specifies
   detailed service parameters for each service level. Such parameters
   include:
   1. Detailed service performance requirements, and changes dependent on network
   load, parameters such as long expected
      throughput, drop probability, latency.
   2. Traffic profiles which must be adhered to for the requested
      service to be provided, such as token bucket parameters.

Blake, et al             Expires: April 1999                         3
   3. Disposition of traffic submitted in excess of the specific agreement between specified
      profile.
   4. Marking services provided.
   5. Shaping services provided.

   In addition to the customer and
   provider does not change.  Dynamic SLAs, on details in the other hand, are
   possibly subject to frequent changes, and TCA, the SLA may require an automated
   protocol specify more
   general service characteristics such as:
   1. Availability/Reliability, which may include behavior in the event
      of failures resulting in rerouting of traffic
   2. Encryption services
   3. Routing constraints
   4. Authentication mechanisms
   5. Mechanisms for monitoring and auditing the service
   6. Responsibilities such as location of the bandwidth broker [BB] or other methods between equipment and
      functionality, action if the customer contract is broken, support
      capabilities
   7. Pricing and billing mechanisms

   These additional characteristics are important, and in the network.

2.1.1  Sample SLA

   The following example illustrates a boundary between two networks case of
   pricing and
   a simple static SLA:

   The customer's network sends traffic billing, fundamental to the provider's network via service offering but they do
   not affect the customer's egress router. service itself and are not considered further here.

4.3 Service Taxonomy: Quantitative through Qualitative and alternatives

   The provider's network receives
   traffic from Differentiated Services architecture can support a broad
   spectrum of different kinds of service.  Categorizing these services
   provides some constraints on the customer's network via corresponding SLAs that can be
   offered for the provider's ingress
   router.  The SLA takes service.

   Some services can be clearly categorized as qualitative or
   quantitative depending on 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 type 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]
   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 performance parameters
   offered. Examples of a qualitative performance guarantee would be "Traffic from stream services are as follows:
   1. Traffic offered at service level A will be given priority over traffic from stream B".  An example delivered with low
      latency.
   2. Traffic offered at service level B will be delivered with low
      loss.

   The assurances offered in examples 1 and 2 are relative and can only
   be verified by comparison.

   Examples of a quantitative performance guarantee would be "Traffic from stream A,
   if provisioned at an average rate services are as follows:
   3. 90% of 100 Kbps, with bursts not
   exceeding 64 KB allowed in profile traffic delivered at a peak rate of 1 Mbps, service level C will then have a
   loss rate of
      experience no more than 0.001%, when averaged over 50 msec latency.
   4. 95% of in profile traffic delivered at service level D will be
      delivered.

   Examples 3 and 4 both provide concrete guarantees that could be
   verified by suitable measurements on the interval example service
   irrespective of
   1 hour".

   2.1.1.2  Throughput Characteristics

   Throughput characteristics (sometimes referred to as Token Bucket
   Models) any other services offered in parallel with it.

Blake, et al             Expires: April 1999                         4
   There are another means to define a also services which are not readily categorized as
   qualitative or quantitative SLA.  This model
   could be used to describe a as in the following examples:
   5. Traffic offered at service that guarantees to deliver level E will be allotted twice the
      bandwidth of traffic delivered at service level F.
   6. Traffic with drop precedence AF12 has a certain sustained rate and to accommodate bursts lower probability 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
      delivery than traffic stream within a
   certain with drop precedence AF13.

   In example 5, the provider is quantifying the relative benefit of
   submitting traffic profile.

   2.1.1.4  Packet Loss (or Drop) Probability

   A at service may guarantee level E vs. service level F, but the
   customer cannot expect any particular quantifiable throughput.  This
   can be described as a limit on `Relative Quantification Service'.

   In general, when a provider offers a quantitative service, it will
   be necessary to specify quantitative policing profiles. In many
   cases, quantitative policing profiles will be specified even for
   services that do not offer quantitative performance.

   Determining how to monitor and audit the percentage delivery of packets dropped
   from a certain flow.  Typically, qualitative
   or relative quantification service in such a service way as to convince the
   user that he has received fair measure requires careful attention.
   It will be up to the customer to determine if the advantage offered
   is defined using
   token bucket parameters and sufficient to make the service worthwhile.  The SLA must clearly
   avoid making quantitative commitments for these services.

4.4 The Scope of a drop probability.

   This is typically Service

   The scope of a relative contract. service refers to the topological extent over which
   the service is offered. For example - "When example, assume that a provider offers a
   service to a customer which connects to their network at ingress
   point A. The service may apply to:
   1. all traffic from flow ingress point A conforms to X token bucket parameters, it is 90% less
   likely to be dropped than any egress point
   2. all traffic between ingress point A and egress point B
   3. all traffic from flow B.  If it does not
   conform ingress point A 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 egress points

   Egress points 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]
   and egress points.  Others may allow combinations of various same domain as the ingress point or egress points.  For example, services may
   be offered:

     a. For all traffic between in other domains which are either directly or indirectly
   connected to the ingress point A and domain. If the egress point B.

     b. For all traffic originating at is in another
   domain, it will be necessary for the ingress A, provider to any egress
        point.

     c. For all traffic originating at any ingress point, negotiate
   SLAs with the relevant peer domains, which will recursively
   negotiate with their peers to egress
        point B.

     d. For traffic from ensure that the group of service offered at
   ingress points point A can indeed be extended to the group
        of egress points B.

   2.1.2.2  Time based Constraints

   These SLAs would typically specify
   specified. The scope of a reduced or improved performance service for certain hours of the day and/or days is part 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 SLA governing
   ingress point A.

Blake, et al             Expires: April 1999                         5
   In general, providers will be
   offered as part of able to offer quantitative services
   most efficiently when a contract.

   Examples specific set of these non-performance-based characteristics might
   include: availability and reliability, security (e.g., encryption).

   The egress points is specified.
   Quantitative services which span multiple domains also require
   tighter coupling between the SLA shown in Sec. 2.1.1 defines two levels of service offered to the customer at ingress
   point A and 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 SLAs negotiated with intermediate domains.
   Qualitative services can more readily be offered to arbitrary sets
   of egress points and require looser coupling between the PHBs that it supports.  One
   of the preconditions for satisfactory performance SLA at
   ingress point A and SLAs at intermediate domain boundaries.

4.4.1 Services Governing Received Traffic

   A special case of the network service scope is a service that the provider provision its network so as to governs all
   traffic between any ingress point and egress point B. The SLA that
   defines this service would be able to meet the
   performance needs of the customers under normal operating conditions
   according to at egress point B and would
   effectively allow the negotiated SLAs.  Thus, adequate attention must be
   given customer to control the right selection of the speed mix of traffic
   received from the network links
   available within provider. While such a service is theoretically
   possible, it conflicts with the DS domain more traditional use of diffserv
   which governs the network provider.

   The provisioning quality with which traffic is sent, rather than
   received.

   A number of the network concerns would have to be done on addressed by such a service,
   including:
     Traffic going to point B from an ingress point A under the basis terms
      of the
   predicted (or contracted) traffic, which the network provider would
   expect from its customers. SLA of this service may also be governed by an SLA for
      traffic submitted at point A.  The provisioning decision has SLAs may conflict and it will
      not, in general, be possible to take
   into account resolve all such conflicts across
      all the needs for ingress points.
   -  Establishing a traffic belonging to different PHBs.

   Let us examine two simple cases profile for this service at every possible
      ingress which prevents overload of PHBs that the receiver 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]
   Forwarding PHB more
      complex than for other service scopes: Static profiles are put likely
      to be either inefficient (e.g. dividing the egress profile into a queue which is serviced frequently, and
   packets belonging
      fixed proportions) or risky (e.g. allowing every ingress to send
      the Default PHB are serviced less frequently
   when whole profile) whilst dynamic profiles require processes and
      communication mechanisms to coordinate the Expedited Forwarding queue is non-empty.  Within this
   context, settings.
   -  Without effective ingress profiles for the network may expect service, denial of
      service attacks will be a certain amount serious problem.

   Some of traffic marked
   with the Expedited Forwarding PHB between its various access points,
   and a different amount characteristics of traffic marked receiver oriented services can be
   provided by local policies and the Default PHB between SLA for the different access-points.  In order domain to meet which
   traffic is sent via the desired
   performance goals of egress point as described in Sec. 4.6.4.

Blake, et al             Expires: April 1999                         6

4.5 Dynamic vs. Static SLAs

   SLAs may be static or dynamic. Static SLAs are the network, norm at the network
   present time. These are instantiated as a result of negotiation
   between human agents representing provider and customer. A static
   SLA is first instantiated at the agreed upon service start date and
   may decide to
   provision periodically be renegotiated (on the links in its network, order of days or weeks or
   months). The SLA may specify that service levels change at certain
   times of day or conversely, certain days of the week, but the agreement itself
   remains static.

   Dynamic SLAs, so that on the expected other hand, may change frequently. Such changes
   may result for example, from variations in offered traffic load due
   relative to Expedited Forwarding traffic on any node/
   link preset thresholds or from changes in pricing offered by
   the network does not exceed a fixed percentage (e.g., 10%),
   and provider as the expected traffic load due to the combined (Expedited Forwarding fluctuates. Dynamic SLAs change
   without human intervention and
   Default) traffic on any other element does not exceed another
   (higher) percentage (e.g., 90%).  There are well-established tools thus require an automated agent and algorithms, which would enable the network provider
   protocol, in effect, a bandwidth broker to obtain an
   optimum configuration of represent the
   differentiated service provider's domain (such as suggested in
   [BB]).

   Dynamic SLAs also present challenging problems to both end users and
   network providers:
   -  Network providers have to satisfy these constraints.

   Another PHB case may consist of defining a limited number of output
   queues (e.g., four) at each of balance frequently changing loads on
      different routes within the routers provider network. This requires the
      provider to adopt dynamic, automated resource provisioning
      mechanisms rather than relying on static provisioning.
   -  Customer equipment will have to adapt to dynamic SLAs in order to
      make the DS domain.  A
   packet marked with one most out of the distinct codepoints is placed into one changing SLA.
   -  End user applications may have to adapt their behavior during a
      session to make the most of (or even, cope with) dynamic SLAs.

   It is worth reiterating that the four queues SLAs in the network.  The queues are served using Differentiated Services
   apply to aggregates of traffic and not individual flows.  For
   scalability, it is undesirable to envisage modifying an SLA every
   time a
   algorithm according new micro-flow is added or removed from an aggregate.

4.6 Provisioning Traffic Conditioners in Boundary Devices to weights which are configured by the network
   provider at Provide
Services

   Once an SLA has been negotiated, the different routers.  The network service provider would
   compute (and
   optionally the expected distribution of customer) will configure traffic conditioning
   components at each of the network
   elements belonging to each codepoint.  It would then assign weights
   at boundary between the different routers two networks. The service
   provider does so that they match the ratio of the
   different traffic load expected at with the specific router.  With this
   provisioning goal of protecting the network, provider's network
   such that the provider can expect resources granted to satisfy the
   average load on customer meet but do not
   exceed the network in a satisfactory manner.

   In either terms of the two cases (or any other network provisioning case)
   described above, TCA. The customer does so with the network provider's predictions goal of traffic may
   not match
   making the actual usage best use of the network.   When service purchased from the actual usage provider. In
   this section, we will briefly describe configuration of traffic exceeds the provisioned traffic for any specified codepoint,
   the network provider may choose to regulate
   conditioners in boundary devices.

Blake, et al             Expires: April 1999                         7
   Note that the amount of traffic provider's self interests require only that could be allowed into the network
   provider identify
   -  for a which service level 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 is submitted,
   -  by the network provider.

   A network provider would typically run metering which customer it is submitted, and accounting
   software on
   -  for traffic with double-ended SLAs (i.e. SLA scope is type 2 or 3
      of Sec. 4.4) only, the access points destination address to estimate which the amount of traffic
   flowing between its different customer access-points.   An estimation
   of the these
      is directed.

   Customer traffic flows can then may be used in order to provide
   admission control of traffic belonging to different codepoints in authenticated either by the
   network (assuming some form of admission control protocol physical
   connection on which it arrives or policy by some sophisticated
   cryptographic means which 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 beyond the amount scope of traffic it can inject into the network. this draft. The limit may

Bernet, et. al.            Expires: November 1998              [Page  7]
   provider need not be enforced as an aggregate depending only on concerned with the codepoint customer's individual micro-
   flows in delivering basic Differentiated Services (see Sec. 4.6.3
   for additional services).

   [DSARCH] identifies four traffic conditioning components:
   1. Meters
   2. Markers
   3. Shapers
   4. Droppers

   The combination and interaction of the traffic entering the network, or enforced conditioning
   components is selected on separate traffic streams
   which may be defined a packet-by-packet basis by the codepoint of DS
   codepoint.  The configuration parameters for the traffic as well as components at each
   codepoint are determined by
   other header field values, including the destination access-point
   (prefix) of policies and profiles applied, so
   that the stream.  Access control on conditioner polices the basis of separate traffic flows or streams is better from in the perspective of efficient
   network resource usage, but requires BA specified by the ingress access-point to
   maintain more routing information
   codepoint.  Meters measure submitted traffic for conformance to determine a
   profile, providing control input for the egress access-
   point.  The shaping of other components which
   implement the policing:
   -  Shapers police by delaying submitted traffic based on some form of admission
   control could be distributed to the edges of such that it does
      not exceed the network (i.e., host
   or first-hop router) as needed.  If this is done, then minimal state traffic rate specified in a profile.
   -  Droppers police by dropping traffic that is needed within the core of the network while still maintaining submitted at a rate
      exceeding that specified in a profile.
   -  Markers police by re-marking the
   SLA.

   In traffic with a different
      codepoint either
      -  to demote out-of-profile traffic to a different PHB,
      -  as a result of the two modes of access-control defined above, the DS
   network needs an SLA which specifies codepoint mutation, or
      -  to determine ensure that only valid codepoints are used within the amount of bandwidth
         domain.

   In addition to be assigned these four components, traffic classifiers are
   required in order to
   a specific codepoint at each access-node.  The amount of bandwidth separate submitted traffic into different
   classes. Classifiers may be obtained by management software in the network which
   determines separate traffic based only on the routing topology DS-field
   of submitted packets (BA classifiers) or may do so based on multiple
   fields within the network, obtains packet header and even the expected packet payload (MF
   classifiers).  MF classifiers may be used at boundaries to provide
   certain per-micro-flow services to customers. Examples of such
   services include per-flow marking or shaping.  Typically, traffic
   will arrive at each access-point, and determines the correct admission
   control limits for the traffic boundary of a DS domain pre-marked and
   pre-shaped. However, at each access-point.  A distributed
   version interfaces 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 non-DS customer

Blake, et al             Expires: April 1999                         8
   networks, it is possible that traffic will require marking 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
   shaping.

   Even if a weighed basis as configured by customer has pre-marked and pre-shaped, the network
   provider [DSPREC].

2.3.1  Services Enabled by First set of PHBs.

   The ISP offers three levels of service
   provider will wish to police the businesses that are
   hosting web-servers on its DS domain.  The "Preferred Service"
   enables users trying traffic at the ingress boundary to access
   meet the business sites with better
   performance for both domain's self-interests.  This may result in traffic being
   re-marked or dropped.

   Traffic conditioning components (in particular, meters) will also be
   the request and response primary source of the web-server. The
   "Special Service" enables users trying to access the business sites
   with better performance billing information for a differentiated
   Services network.

4.6.1 Minimal Functionality at Provider's Ingress

   At the web-responses, while very least, the "Normal
   Service" provides service provider must limit traffic carried
   on behalf of the default performance for both requests and
   responses.

   In order customer to provide the services using constraints specified in the Expedited Forwarding and
   Default PHBs, TCA. A
   simplified TCA can be represented in the network provider maintains form of a list table wherein
   each row has the format:

   DS-Mark : Profile : Disposition of non-conforming traffic

   This row indicates that the addresses
   and ports provider commits to carry traffic marked
   with 'DS-Mark' at which the preferred corresponding service level, provided that it
   conforms to the 'Profile'. Traffic that is submitted with 'DS-Mark'
   and special clients' web-servers are
   operational.  For all packets in which either does not conform to the source host/port

Bernet, et. al.            Expires: November 1998              [Page  8]
   combination or the destination host/port combination identifies 'Profile', is subjected to
   'Disposition of non-conforming traffic'. This is generally a
   preferred web-server, the packets are marked with the Expedited
   Forwarding codepoint.  If the source host/port combination indicates
   policing action such as re-marking to a special lower service web-server, the packets are also marked expedited.
   All other packets are marked with the default codepoint.  Using this
   scheme, level,
   delaying in a shaper, or dropping. Alternatively, it may be carried
   at the right type of performance is given requested service level, but subjected to the customers
   hosting a preferred web-server.

   A second surcharge.  The
   SLA for this type of classification service may would normally be provided by an ISP expected to
   its business clients using this PHB set.  For each be of the business
   customers, some set
   type 1 of web-sites are identified as being more
   relevant to their business.  The ISP would provide expedited
   forwarding to Sec. 4.4.1, where the traffic from destination can take it
   through any egress point of the web-sites that are considered relevant
   to its business by domain.

   To provide this minimal functionality, the customer.  As opposed provider must configure a
   BA classifier to separate traffic into the preferred/special different service definition presented above, the customer accessing the web-
   site, not level
   requested, based on DS-Mark. Following the person hosting BA classifier, each class
   must be metered for conformance to the web-site, drives corresponding profile.
   Following the classification.
   Such profiler, either a marking can dropper, shaper or re-marker is
   likely to be done by supporting employed.  The Better than Best Efforts service
   described in Sec. 5.1 is an example of a PICS capable web-proxy at
   each ISP access-point service for which uses this
   functionality is sufficient.

4.6.2 Functionality at Provider's Ingress for Double-ended SLAs

   If quantitative or other services needing double-ended SLAs (types 2
   and 3 of Sec. 4.4.1) are implemented in a business rating system to classify DS Domain, these services
   specify the web-pages into those relevant/irrelevant possible egress port(s) for a specific customer,
   and marking traffic conforming to the packets as Expedited Forwarding/Default
   appropriately.

   Another example
   SLA.  The traffic conditioner needs to consider the destination
   address of service the packet as additional input to the policing process,
   so that can be provided using this traffic 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, not accepted for egress ports for 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 SLA
   does not exist.  The Virtual Leased Line service described in

Blake, et al             Expires: April 1999                         9
   Sec. 5.2 is an out-
   sourced example of a service that would require this
   functionality.

   A QoS VPN which is replicating can be constructed by provisioning 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 instances                                                                                                                                    o                                                                   f
   services of type 2, building in effect, a mesh of point to point QoS
   links.

   Services of type 3 are most likely to be classified as "Preferred
   Service" used for multicast
   applications (see Sec. 9).

4.6.3 Added Value Functionality at Provider's Ingress

   The functionality described in Secs. 4.6.1 and given priority across the VPN (similar 4.6.2 serves only to a virtual
   leased line).  User traffic from outside
   protect the provider's network destined resources in line with the terms of
   the TCA. It provides no assistance to
   specific servers within the network (i.e., web-servers) might be
   given a different level customer. The burden of access called "Response Service".  This
   service would have other specific characteristics such as minimum
   response time, latency
   marking packets and availability requirements.  Any other shaping traffic falls entirely on the VPN would be marked as "Normal Service" and would be
   considered a best effort service, associated with customer.
   In some cases, the default PHB.

2.3.2  Services Enabled by SLA may call for the Second Set of PHBs

   An ISP offers two provider to provide
   additional services to its the customer.  The "voice" Such services may include:
   1. Marking traffic
   results in from specific micro-flows to a low bandwidth low-delay communication across specific behaviour
      aggregate (marking the ISP
   network.  The "video" DS-field).
   2. Policing traffic results from specific micro-flows or sets of micro-
      flows, either in a high-bandwidth low-delay
   communication across the ISP network.

   The  "data" traffic provides behavior equivalent form of dropping or shaping.

   In order to that found provide such services, the provider must generally
   employ an MF classifier in

Bernet, et. al.            Expires: November 1998              [Page  9]
   current IP networks.

   The ISP supports these three modes of services by mapping them into addition to the three different queues at each router. BA classifier. The ISP periodically
   recomputes need
   for an MF classifier arises only when the load and routing patterns of its voice and video
   connections, regenerates customer requires the weights on each backbone router
   provider to
   support this set of services, and reconfigures the router.

   A second service offered by the same ISP is that provide some form of a fixed bandwidth
   pipe.  The ISP offers a specific bandwidth between two access-points traffic separation or
   authentication on behalf of its the customer. The ISP adjusts provider may charge
   dearly for these services depending on the weights degree of granularity and
   the different queues
   to meet the bandwidth requirements amount of all the customers passing
   through a router work required. For example, shaping thousands of
   customer micro-flows might consume considerable resources 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
   provider's edge device. On the
   appropriate packet classification rules.  At each of other hand marking based on source
   subnet addresses would consume considerably fewer resources.

4.6.4 Functionality at Customer's Egress

   Strictly speaking, the access-
   points, customer need not apply any specific traffic
   conditioning. In this case, the customer relies on the provider of a specific DS-domain to
   mark as per negotiated MF classification criteria. In many cases it
   is either a provider preferable for the customer to
   a customer, or mark. Customer marking may be a
   necessary when customer of yet another provider.  The
   support of a SLA requires that packets are encrypted (as in the configuration case of functional
   components at the boundary be done with parameters that are designed
   to support
   end-to-end IPSec). Customer marking enables the required SLA performance levels.  In order customer to support direct
   specific services, traffic from specific functionality users or applications to specific
   service classes. This may be required of the
   classifiers, meters, markers, shapers and policers at an access-
   point [DSARCH].

   Boundaries between two DS networks and between difficult or impossible for a DS and non-DS
   network, are provider
   to do on behalf of particular interest.  At each such boundary, at least
   one network is a customer when, for example,  applications use
   volatile ports and one is a provider. The provider agrees users are assigned IP addresses based on DHCP.

   In addition to carry certain subsets of marking, it is in the customer's traffic best interest to at certain
   least shape per service
   levels.  This agreement is captured in the form of an SLA.  Specific
   functionality is required level, 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 network's egress
   point. Otherwise, customer traffic 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 policed by human interaction.  Dynamic SLA's change frequently
   and typically are renegotiated via the service

Blake, et al             Expires: April 1999                        10
   provider with undesirable consequences (e.g. dropped packets).
   Shaping per service level does not however, provide for micro-flow
   traffic separation. As a machine to machine negotiation
   protocol of some sort.  Note that consequence, a static SLA renegade traffic source may call for different
   service levels
   cause the profile to be supported at different times of day, in exceeded for a specific service level,
   negatively impacting all customer flows which
   case, the are marked for that
   service covered by the SLA changes automatically and
   somewhat frequently, however, the agreement itself does not change
   frequently.

   In order to adhere to a SLA, level. Therefore, it is useful often in the customer's interest to configure certain
   functional components
   shape or at access-points.  These may include
   classifiers, meters, markers, shapers, and policers, as explained
   below.

   An access-point least to police, with micro-flow granularity.

4.6.5 Functionality at Provider's Egress

   At the egress from a DS provider's domain can run there may be an SLA in one of two modes of
   classification, as place
   with a microflow or traffic stream classifier (MFC), peer DS domain, which might be either another provider or a bandwidth aggregate classifier (BAC). an
   end user domain.  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 in Sec. 4.6.4, it is in the DS field
   according provider's best
   interests to shape the classification rules that are configured for it.  As
   a BAC, the access-point expects that the customer has already marked traffic leaving the DS field appropriately after running a MFC function domain.

   Depending on its own
   behalf, and only looks at the DS field.  Even as a BAC, SLA, the access-
   point egress may choose be required to remark and/or
   police or shape the DS field as it may check the
   aggregated traffic level associated with traffic.  Note that the DS field forwarding treatment
   applied 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 packet in the aggregate stream as a result egress node of the classification process.

   In domain would be that
   selected by the first mode, codepoint before it was remarked (otherwise, the
   egress node has to support multiple codepoint to PHB mappings).

   The provider may also wish to offer additional services to a
   customer applies no by policing egress 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, micro-flow granularity if
   the customer applies per-microflow/stream classification
   and marking.  In this case, the provider applies aggregate (per-
   service level) classification and policing, might expect to assure compliance with
   the SLA.  It is assumed that all receive excessive traffic from in a single customer
   arrives at an interface dedicated to the customer.  If multiple
   customers share a single interface, it will be necessary
   BA and wishes to apply
   additional finer-grain classification for the purpose of
   conditioning.  Provider marking will typically greater control than could be applied at the
   periphery achieved by
   normal policing of the DS domains, where a DS network connects to
   non-DS, stub networks.

   Shaping is not included in the above discussion, but may aggregate.  This would be
   recommended specified via an
   SLA in the customer's network, or usual way.

4.7 Internal Provisioning

   The provider must provision internal nodes in the provider's provider 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
   to meet the aggregate DS domain resources guaranteed assurances offered 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 SLAs 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 boundaries
   of the service provider's network.

   Devices that To do full microflow classification will be more complex
   than so, the provider may use similar traffic
   conditioning mechanisms to those that just offer bandwidth aggregation classification
   support.  The costs associated with these devices will should be
   considered when determining where used at the network boundaries.
   However, providers are unlikely to apply MF classification and flow shaping
   should occur within
   the DS domain.  In certain cases, interior of the customer network.  The provider may contract to have police periodically
   within the provider apply microflow network, by reshaping, remarking or aggregate
   shaping.  This is a form of value-add which discarding traffic.
   Service providers may offer
   customers that are incapable of providing their own shaping.

   Obviously, wherever shaping is applied at a microflow level,
   microflow classifiers experienced in provisioning large networks
   which offer uniform service, assisted by predictive tools, traffic
   modeling tools and real time measurements. Current techniques will
   likely 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 differentiated services networks, although, the
   co-existence
   complexity 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 provisioning will increase significantly.  In a BA policer at
   differentiated service network, the ingress access-point.  A static SLA with provider marking would require must ensure that the access-point support a MFC
   and BA policer
   resources granted to traffic of one service level does not
   inappropriately compromise assurances regarding traffic at the ingress access-point.

3.1.2  Service Configuration

   Configuration requirements may vary depending on several parameters:

   Variations other
   service levels (for example, in example service 6, traffic in AF13
   can legitimately compromise traffic in AF11 if an increase in AF13
   traffic causes more AF11 traffic to be dropped).  As mentioned
   previously, internal provisioning in the distribution case of dynamic SLAs will
   likely require dynamic resource allocation protocols.

Blake, et al             Expires: April 1999                        11

4.8 End-to-End Service Construction

   The Differentiated Services architecture proposes that an end-to-end
   service can be constructed by the configured functionality, e.g.,
   use concatenation of the MFC mode versus the BA mode, specific functional
   components being configured (policers versus markers), domain services
   and the nature
   of the their associated customer-provider 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 each of the classification domains
   which the service traffic has to work efficiently, it must cross.

   Clearly, not all PHBs and services can be
   simple meaningfully concatenated,
   and easy to configure.  Furthermore, the configuration definition of
   different access-points must suitable services and their associated PHBs
   will be consistent.  Otherwise, the
   performance a major focus 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 future Differentiated Services development.
   This is identical for all the access-points. discussed at greater length in Sect. 7.

5. Service Examples

   In the special
   ISP this section, we describe service described in Section 2.3.1, the configuration entry for
   each web-server needs to examples and show how they can
   be only present at the access-point to supported by specific PHBs.  We base these examples on PHBs which
   the web-server is attached.

   The simplest approach to the configuration problem is
   are defined in [AF]and [EF].  These examples are intended to ignore it.
   The assumption would be
   illustrative of the wide range of services that can be employed
   using the ISP would configure each router
   manually, differentiated services model, and in a static manner. are not intended to be
   an exhaustive list.

5.1 Better than Best-Effort (BBE) Service

   This solution requires extensive
   manual upgrade is a qualitative service which promises to each ISP router whenever carry specific web
   server traffic at a higher priority than competing best-effort
   traffic. Such a new service or offers relatively loose (not quantifiable)
   performance from a
   customer given ingress point to any egress point. Such a
   service is added or deleted.  The solution would not work well in
   practice.

   Another option might be suitable for the DS field example for businesses offering access 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
   web based on this
   service) network as described. content. The ideal solution should BBE service enables the web content provider
   to provide content at a single administration point where generally higher rate than other content
   providers are able to, in so reducing the ISP can enter latency experienced by
   consumers of  the configuration rules from a centralized web site.
   The configuration information should also permit scalability, in

5.1.1 Service Implementation

   In this example, we assume that
   a large number of different ingress routers should be capable of
   receiving there is an SLA which defines the configuration information.  At
   service at the same time, customer's ingress point. This is the
   configuration information should not become a single point of
   failure, at which can bring
   the entire network to a halt.  One solution
   to customer injects web server responses into  the configuration problem is a protocol, which permits differentiated
   services network. The information in the
   administration at a single master site, but allows replication to
   several slave/mirror sites, which TCA can be looked up represented in
   the following form [AF]:

   AF13 Mark : 1 Mbps : Any egress point : Excess traffic handled by a large set of
   access-points to permit a scalable operation.

   Another desirable attribute
   marking with AF11 mark.

   Packets submitted for scalability would the BBE service should be marked with the DS-
   field codepoint corresponding to the AF13 PHB. The provider is
   promising to carry up to 1 Mbps of traffic from the ability ingress point to
   cache
   any egress point at a limited set higher priority than best-effort traffic. A
   lesser class of classification rules and service corresponding to query other rules
   as and when needed.

   Several alternatives exist the AF11 PHB will be
   applied to traffic submitted for such a configuration policy.  Some the AF13 PHB, in excess of
   these alternatives are outlined below: 1 Mbps.

Blake, et al             Expires: April 1999                        12
   The SNMP MIB approach:

   One may define provider will provision a diffserv-specific SNMP MIB that needs policer at the ingress point. Traffic
   submitted up to the 1 Mbps limit will be directed to the AF13 PHB.
   Traffic submitted in excess of 1 Mbps will be
   supported at each remarked for the AF11
   PHB. Note that the scheme will preserve ordering of packets since
   AF13 and AF11 use a single queue..

   In order to provide this service, the provider will have to
   implement the access-routers, AF13 and AF11 PHBs in core network equipment. The AF13
   and AF11 PHBs can be populated implemented for example, using a
   SNMP manager. single RIO
   queue. The MIB definition approach would enable a centralized
   administration provider will also have to provision equipment within the
   core of the configuration information.

   However, provider's network to provide the MIB approach does not enable caching in an efficient
   manner.  Since AF13/AF11 service. By
   provisioning the MIB appropriate RED parameters, 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 example, the LDAP protocol.  The directory
   provider is looked up at able to control the
   initialization priority of the access-point.  Directories permit centralized
   administration at one master site, and support replication AF13 traffic relative to
   different slave sites.  The access-point can also cache portions of
   AF11 traffic at each network node. Since there are no quantitative
   guarantees, the classification rules, and provider can query the appropriate rule when
   they detect be quite liberal in its provisioning
   strategy and may realize significant statistical multiplexing gains.
   Also, the initiation absence of a new session (e.g. seeing a TCP header
   with the SYN flag).  The directory schemata also permit a way quantitative guarantees makes it easy to
   provide configuration information for a group this type of access-point in a
   single entry, which can provide consistent configuration service across
   several access-points.  The one drawback of the directory protocol multiple DS provider domains.
   This is
   inadequate support for asynchronous notification, which because is currently
   being discussed, in the various working groups.  A tentative schema
   for classification rules using this schema has been proposed in
   [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 necessary to be augmented with negotiate, then provision and
   enforce quantitative guarantees at multiple boundaries.

5.2 Leased Line Emulation Service

   This is a negotiation
   protocol between the quantitative service which emulates traditional leased
   line service. As such, it promises to deliver customer traffic with
   very low latency and provider network very low drop probability, up to negotiate the
   current details of the service levels.  To this end, a standard
   protocol is required between customers and providers. negotiated
   rate. Above this rate, traffic is dropped. Such a protocol
   would enable customers to present requests to providers that would
   result in changes service is
   typically offered between two specific points. It is suitable for
   many customer applications. However, due to the SLA.  Entities within the provider's network
   would respond high quality
   guarantees, it is likely to these requests by determining if the requested SLA
   could be met, adjusting the policers accordingly priced higher than alternate services
   and responding therefore, 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 used only for applications which really require
   this purpose.

   3.1.2.1  Functionality Required at Boundary Equipment

   In the interest type 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 service. An example 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 such an application is IP
   telephony. A corporate customer might purchase leased line emulation
   service level
     and marks DS field accordingly.  Provider polices based on
     aggregate.

     MFC - MF Classifier
     BAC - BA Classifier

     M - Marker

     P - Policer (policing shaper) between each pair of a number of corporate network sites.

5.2.1 Service Implementation

   In the first this example, the customer applies no traffic conditioning.
   Instead, the we consider a customer contracts with the three geographically
   dispersed networks interconnected via a single provider to do per-microflow
   classification, marking network.
   Customer attachment points are represented as A, B and policing.  In the second example, C. At each
   attachment point, an SLA describes the
   customer applies per-microflow classification and marking.  In this
   case, leased line service to be
   provided to the provider applies aggregate (per-service level)
   classification and policing, to assure compliance with other two points. The table below represents the SLA.  It
   is assumed that all traffic from a single customer arrives
   information required in the TCA at an
   interface dedicated attachment point A:

   EF-Mark : 100 Kbps : Egress point B : Discard non-conforming traffic

   EF-Mark : 50 Kbps : Egress point C : Discard non-conforming traffic

   Packets submitted for leased line service should be marked with the
   DS-field codepoint corresponding to the customer.  If multiple customers share a
   single interface, it will be necessary EF PHB [EF]. From the
   ingress point A, to apply additional finer-
   grain classification for the purpose egress point B, the provider is promising to

Blake, et al             Expires: April 1999                        13
   carry up to 100 Kbps of policing.

   Provider marking traffic. Excess traffic will typically be applied at discarded.
   From ingress point A, to egress point C, the periphery provider promises to
   carry 50 Kbps of traffic. Of course, there is some tolerance
   required in policing the DS
   domains, where traffic and thus, there may be a DS network connects to
   specification of tolerated jitter or burst size. However, for 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,
   leased line service, the
   provider's network, or both.

   Typically, flows will primary traffic profile parameter would be shaped within
   the customer's network.  By
   shaping sustained traffic rate.

   The provider will provision a policer at the microflow level, the customer can maintain ingress point A to limit
   traffic
   separation, ensuring that no microflow destined for egress point B, to 100 Kbps. Similarly, a
   policer will seize more than its share
   of be configured to limit traffic destined for egress
   point C, to 50 Kbps. These policers will require classification
   based on the aggregate DS domain resources guaranteed by DS-Mark and the SLA.  By
   shaping at destination address in each packet.

   In order to provide this service, the aggregate stream level, provider will have to
   implement the customer can assure
   aggregate compliance with the SLA and for example EF PHB in core network equipment. The EF PHB can avoid charges
   that may have been negotiated as part of the SLA, for excess traffic.
   However, be
   implemented using strict priority queuing or alternatively, by shaping at
   assigning EF marked packets to a heavily weighted queue in a WFQ
   scheme. The provider will have to provision equipment within the aggregate level only,
   core of the customer cannot
   assure provider's network. For example, routers carrying
   traffic separation.

   In certain cases, the customer may contract to between point A and points B and/or C will have to be
   provisioned considering the provider
   apply microflow or aggregate shaping. resources committed by the TCA at point
   A. This is a form of value-add
   which providers may offer customers means that are incapable of providing
   their own shaping.  Obviously, wherever shaping is applied at a
   microflow level, MF classifiers will be required.  Wherever shaping router which is applied at both in the behavior aggregate level, BA classifiers path from A to B
   and from A to C, will have to be
   required.  In general, classifiers are required only considered to support other
   functionality such as meters, markers, or shapers.  Subsequent
   discussion have committed 150
   Kbps of specific functionality implies the co-existence bandwidth as a result of the
   appropriate classifier.

   3.1.2.2  Configuration of Functionality TCA in place at Boundary Equipment

   Configuration requirements may vary depending on the following
   parameters:

     1. Variations A. A router
   that is only in the distribution path from A to B, will have to be considered to
   have committed 100 Kbps as a result of configured functionality, this TCA, and so on. Of
   course, routing is subject to change and so, failover paths may have
   to be provisioned as
        described well. These may be provisioned to provide some
   fraction of the service in the previous section.

     2. The functional component configured (for example, policing vs.
        shapers vs. markers).

     3. The nature case of failover or alternatively,
   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. point A BA policer at the provider's ingress node.

   The SLA specifies the traffic profiles that should be configured per- might reflect appropriate service level for the policer at availability
   parameters. To enhance the ingress node of assurances offered by EF service,
   providers may employ route pinning mechanisms or QoS routing
   mechanisms.

5.3 Quantitative Assured Media Playback Service

   This service offers looser assurances than the provider's
   network.  The format leased line service
   described above, but is still considered a quantitative service. In
   particular, it promises to deliver traffic with a high degree of the information
   reliability and with variable but bounded latency, up to be configured is tabulated
   in Sec. 2.1.1.  Since the SLA is static, a
   negotiated rate. Above this information changes
   infrequently and likely requires human intervention.

   Therefore, the policer will typically be configured remotely via SNMP rate, traffic is subject to significant
   delay or via drop. Such a command-line interface.

   The marker configuration service is actually independent typically offered between a
   specific set of the SLA.

   The points. It is suitable for many customer may contract the provider
   applications. It would likely be priced lower than a leased line
   service, due to mark any service level
   based on the results of the MF classification.

   Configuring the marker is similar latency variability. However, due 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 latency
   bound and
   error prone.  In addition, high degree of delivery, it is subject likely to change more frequently be priced higher
   than alternate services. This service is particularly suitable for
   video or audio playback, in which considerable bandwidth is required
   on a static SLA and, does not require continual basis, but the approval non-interactive nature of the provider.

   While traffic
   makes 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 somewhat delay tolerant.

Blake, et al             Expires: April 1999                        14

5.3.1 Service Implementation

   In this example, we again consider a customer with three
   geographically dispersed networks interconnected via a standard protocol that is available to single
   provider network. The table below represents 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 information
   required in a previous section, is
   when the receiver is allowed TCA at attachment point A:

   AF13-Mark : 100 Kbps sustained, 100 Kb bursts tolerated at up to control how the marking of the DS
   field is performed 200
   Kbps : Egress point B : Excess burst traffic over sustained rate
   marked with AF12-mark : Non-conforming traffic marked with AF11-mark
   : Max latency = 1 second

   AF13-Mark : 50 Kbps sustained, 100 Kb bursts tolerated at up to 100
   Kbps : Egress point C : Excess burst traffic over sustained rate
   marked with AF12-mark : Non-conforming traffic marked with AF11-mark
   : Max latency = 2 seconds

   Packets submitted for the sender side.  This can assured playback service should be done either in
   accordance marked
   with a static SLA that the user has with DS-field codepoint corresponding to the provider, or
   by use of application- or session-level signaling which induces AF13 PHB. From the
   sender (or a DS edge node)
   ingress point A, to mark the packets in accordance with egress point B, the
   receiver's preferences.

   Another type provider is when the receivers need promising to control
   carry up to 100 Kbps of sustained traffic with bursts of 100 Kb in
   size at a peak rate of 200 Kbps. Excess burst traffic will be marked
   with the priority codepoint for AF12 and out of
   packets that arrive from profile traffic will be
   carried but with the network onto his/her access link.  There AF13 codepoint. So long as these conditions are two reasons why this is important.  One is that it provides
   protection from certain types of denial-of-service attacks.  The
   other is
   met, latency will be limited to 1 second. Note that for this is important on low bandwidth access links, in
   particular for mobile IP hosts.

   At the last-hop router, before
   service, the egress link, traffic from
   different sources profile is described using a full set of token
   bucket parameters. Since the latency bounds for such a service are merged onto
   less strict than those required for the access link leased line service, a
   certain degree of traffic burstiness can be tolerated.

   The provider must support the receiver
   (destination).  Some packets AF11, AF12 and AF13 PHBs in core
   network routers. These PHBs might have been be provided, for example, by
   assigning AF11, AF12 and AF13 marked with respect traffic to
   the SLA the receiver has a single RIO queue
   with high drop thresholds. The policers at the ISP, others might not.  To allow
   the receiver to control which edge would limit
   competing 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 line with the marking TCA, in order to assure that
   was made with respect the
   latency bounds can be met. In addition, the service provider will
   have to provision devices in the sender's SLA) packets at core of the egress
   node, network. The
   provisioning considerations discussed in accordance with a "receiver marking policy".  This can be
   thought the context of the leased
   line service apply here as a special case well, however, in general, the service
   provider has the liberty of a static or dynamic SLA between a
   downstream network (the ISP) being less conservative in provisioning
   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 realizing better statistical gains.

5.4 Superposition of requests have been described which can result Quantitative and Qualitative Services in
   allocation of resources to particular users (at the expense of
   others), Same
Network

   A compelling model would provide both quantitative and which may result qualitative
   services in charges to customers.  The two types
   of requests are requests to mark traffic for prioritized treatment
   (subject to the terms same differentiated service network(s) as follows. A
   number of an existing SLA), and requests to change
   the existing SLA.  These requests should corporate campus networks would be governed interconnected by policy
   decisions.  Information required to make policy decisions must be
   conveyed to policy servers.  These must reply with approval or
   rejection a
   differentiated service network providing quantitative services
   between the sites. For example, a mesh of leased line services would

Blake, et al             Expires: April 1999                        15
   enable IP telephony between the request.  COPS is an example sites. A mesh of a policy protocol
   suitable for carrying such requests.

3.2  Requirements for Measurement and Management. media playback
   service using the AF11 PHB would enable audio/video playback between
   the sites. In order to validate conformance addition, each corporate site would be allotted some
   level of BBE service to arbitrary destinations. In this model, the specific SLA's within a DS
   domain, the
   differentiated service network operator should measure the performance is effectively providing a mesh of the
   traffic belong
   quantitative services between fixed locations (similar to specific codepoints within its domain. a VPN).
   This mesh is superimposed on a cloud supporting BBE service.

6. Provisioning and Configuration

   The
   measurement of traffic can be done in one provision of two modes:

   Single Point Measurements: These measurements would monitor differentiated services requires careful network
   wide provisioning and configuration. Provisioning refers to the
   traffic in
   determination and allocation of the network resources needed at a single point various
   points in the network.   Such a
   measurement can be done at Provisioning may dictate the access-point addition or
   removal of physical resources at various points (physical
   provisioning). Provisioning may also dictate the modification of
   operating parameters within existing physical network after
   classification, and reported equipment to
   alter the network management tools using
   RMON MIBs [RMON].  A network operator can also station real-time flow
   monitors, and collect a more comprehensive record relative share of the type equipment's resources which are
   allotted to one or another class of traffic flowing in the network [RTFlow].

   Dual Point Measurements: These measurements would monitor (logical provisioning).
   Configuration refers to the
   performance distribution 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 appropriate
   operating parameters to network performance monitoring
   protocols stationed equipment to realize the
   provisioning objectives.

   In Secs. 4.6 and 4.7, we briefly discussed provisioning and
   configuration requirements both at the two egress points.  Network performance
   monitoring protocols tend to be relatively heavyweight network boundaries and in their use
   of the
   network bandwidth, interior. In this section we will focus primarily on the
   coordination of provisioning and these protocols should configuration throughout the
   network, such that end-to-end services can be used only when a
   potential violation provided reliably. We
   will discuss the roles of protocols such as SNMP, CLI, RSVP, COPS
   and LDAP in the SLA is suspected between provisioning process.

6.1 Boundary vs. Interior Provisioning and Configuration

   For the two access-
   points. sake of brevity, consider the term 'provisioning' to refer
   both to provisioning and configuration, except where otherwise
   noted. It would be desirable for a DS domain operator is helpful to have a continuous
   low-overhead monitoring consider provisioning at the network
   boundaries, separately from provisioning of the service-levels obtained by packets
   within its domain using a passive monitoring scheme.  When interior. Since the
   passive monitoring scheme suspects
   differentiated service provider is selling a potential problem, contract (SLA) at the more
   heavyweight performance monitor
   network boundary, we can be activated.  A SNMP manager may
   be used as an intermediary consider the boundary provisioning which
   supports SLAs, to trigger this activation, with drive the
   passive monitoring protocol generating interior provisioning. The two are not
   entirely separable in that each affects the other. For example, a
   network operator cannot offer 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 which cannot be met by 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
   resources available in the Internet requires that there is support for service
   differentiation in a uniform manner across several ISP's. interior of the network. In general, communication across the Internet traverses several ISP
   boundaries.  When a browser accesses a web-server, the connection
   traverses
   overall provisioning process iterates between the client (browser) network; multiple ISP networks, boundaries and
   eventually reaches the server network.  The response from the server
   traverses a (possibly asymmetric) path back
   interior. From here on we will refer to provisioning with respect to
   the client host.  In
   these cases, SLAs are usually only specified between the client and
   its ISP, TCA rather than the server and its ISP, and between SLA, since the neighboring pairs of
   ISP's.  Within this context, one must enable TCA is the definition component 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
   SLA that defines detailed traffic handling parameters.

Blake, et al             Expires: April 1999                        16

6.1.1 Boundary Provisioning

   Boundary provisioning was considered briefly in Section
   2.3.1.  When the preferred service is provided, any client accessing Sec. 2.6. We
   discussed the web-server minimal provisioning that a provider must be provided Expedited Forwarding service for its
   requests as well as its response stream.  As long as the client
   browser connects implement to the same ISP as the server, the preferred service
   is straightforward
   enforce a TCA. We also discussed additional configuration which a
   provider may use to provide.  However, when the client browser is
   connecting provide additional (especially per-flow)
   services to a different ISP, expedited processing for request
   packets customer. The latter is not enabled until they reach actually related to the domain
   provisioning of resources within the ISP
   immediately connected to differentiated services
   network, but rather assists the server.

   Similarly, customer by determining which
   subsets of the expedited processing for response packets may not be
   honored once customer's traffic make use of the response packets leave resources
   provisioned within the domain differentiated services network. As such, it
   is out of the ISP.

   Some scope of this section. Here, we consider only the methods by which
   minimal provisioning required at the service concept can be extended
   across multiple ISP's are outlined in boundary.

   At a minimum, the following sections.

4.1  Service Provisioning Across Boundaries

   There provider must assure that sufficient physical
   resources 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 provisioned at the second scheme consists of negotiating a microflow or traffic
   stream classification boundary to a neighboring ISP.

   An aggregated bandwidth negotiation is useful in preserving meet the
   desired service levels requirements
   of packets that are leaving an ISP DS domain.
   If an ISP A is sending packets into the DS domain TCA. For example, if the sum of an ISP B, ISP A
   would negotiate the profiles supported at a SLA which
   particular ingress point would honor the DS field marking created
   by ISP A.  As packets enter the domain allow 10 Mbps of ISP A, they would traffic to be marked
   with
   supported, it is unacceptable to provision a specific codepoint.  Before the packets leave the domain of
   ISP T-1 access link. A and cross over to ISP B, they T-3
   however, 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 sufficient. Once the same PHB as long as physical provisioning is
   implemented, it is necessary to apply the aggregate inbound packet
   rate appropriate logical
   provisioning. This is less than a certain limit.  For achieved by configuring policers which limit
   the service category amount of
   "special service" as described in Section 2.3.1, ISP A would mark all
   response packets originating traffic accepted from the special web-servers for
   Expedited Forwarding. T-3 access link, at each
   service level.  It would may also negotiate the SLA with ISP B so
   as to obtain a rate for Expedited packets, which would be adequate necessary to
   meet set up the demand amount of
   buffering available for its servers.  Since ISP B would carry the packets queues used for the service.  Similar
   provisioning is also appropriate at expedited level through its domain, each egress point if 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
   aggregate of profiles provisioned to the
   service being special to all clients in egress exceeds the capacity
   of the Internet. output link.

6.1.2 Interior Provisioning

   For boundaries where the aggregated bandwidth is negotiated, one ISP
   can simply act as purpose of provisioning the customer interior 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 network, it is connecting
   desirable to ISP B and
   trying understand or to access a preferred web-server (as defined in ISP B's SLA
   with ISP A) will not receive the Expedited Forwarding treatment in control the domain volume 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 traffic of the ways in each
   class which ISP A traverses each network node. The greater this
   understanding, the more efficiently the network can manage to extend be provisioned
   while still meeting the preferred
   service agreement requirements of the TCAs. It is feasible to clients in
   understand the domain volume of ISP B traffic traversing each node if this
   traffic is admitted according 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) TCA which need dictates egress point
   as well as ingress point. (This case generally applies to be treated preferentially.  In
    return ISP A would configure all
   quantitative services and was discussed in the context of its access-points to mark the
   packets headed to EF PHB
   and the preferred leased line 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 in Sec. 3.2.1). While traffic volumes
   cannot be anticipated with some other
   ISP.  There 100% accuracy, it is also an associated scaling problem with too many
   microflow/stream classifier entries floating across multiple ISP
   boundaries.  The ISP may want possible to export
   approximate them quite well, especially with the microflows/streams
   classifier designations only across a certain number help 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 route
   pinning mechanisms. It is
   extended therefore possible to all the clients in provision 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
   network reasonably accurately for Service Level Agreements traffic submitted for quantitative
   services. Although the differentiated service architecture focuses on
   differentiated treatment within such provisioning may be quite difficult in a single domain,
   large network, it is expected that
   different DS domains nonetheless a tractable problem. We will be linked refer
   to each this component of the provisioning problem as quantitative
   provisioning.

Blake, et al             Expires: April 1999                        17
   On the other through mutual
   agreements and hand, many (if not most) of the DS region will expand in an incremental fashion.
   How two different DS domains are interconnected is governed services offered by the
   SLA between two-DS domains.  The SLA
   differentiated service networks will not specify details as to how
   each other's traffic egress points (as
   is conditioned at the boundary of the two
   domains, case for qualitative services) and how packets are re-marked will not restrict
   submitted traffic to specific egress points, let alone specific
   routes. Thus, interior nodes will have 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 provisioned without an
   a-priori understanding 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 volume 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 submitted for
   qualitative services which will arrive at each PHB, actions for packets out-of-profile (marked
   with node. It is necessary
   to be able to provision differentiated service networks to support
   both quantitative services with specific egress points as well as
   qualitative services, which do not have specific egress points on
   the same physical resources. To this end, it is necessary to isolate
   the impact of qualitative traffic on the resources reserved for
   quantitative traffic. This can only be achieved if the former is
   treated with lower priority than the latter. Thus, in general,
   resources will have to be provisioned first for quantitative
   traffic, using quantitative provisioning mechanisms. Then,
   qualitative provisioning can be used to allocate remaining resources
   to qualitative traffic.  Qualitative provisioning can also be
   applied to services which offer a different PHB or shaped/discarded).

   Mapping relative quantification of traffic
   volumes.

   The impact of PHBs between two domains: If the two DS domains use two
   distinct types of traffic will have to be isolated by
   ensuring that they do not share PHB groups, codepoints. PHBs used for
   quantitative services will always have higher priority access to
   resources than those used for qualitative services. As a result, it may be
   is necessary to establish some rules carefully police traffic submitted for
   mapping one PHB quantitative
   PHBs. Failure to another.

   Location do so can result in the starvation of traffic conditioning: The packets lower
   priority traffic. In general it can be conditioned by expected that only a small
   fraction of the egress resources at each node will be provisioned for
   quantitative traffic.

   Similarly, a significant fraction of one DS domain before the traffic crosses capacity should
   remain for best-efforts service to the
   next DS domain, provide a 'soft' target for
   traffic dropping if congestion occurs or by it is necessary to redirect
   non-best efforts traffic in the ingress node event of failure.

6.1.2.1 Quantitative Provisioning 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 Interior

   As discussed previously, quantitative provisioning is a different PHB with difficult
   but tractable problem. With knowledge of the
   same PHB group.  Such promotion network routing
   topology and demotion take place when there the TCAs at the boundaries, it is
   a mis-match between possible to compute
   the resources required at each interior node to carry the
   quantitative traffic rate specified in offered at the SLA edges. Based on the results of
   this computation, interior nodes must be provisioned and configured
   with sufficient capacity to accommodate the
   actual traffic rate.  For example, two ISP's both offer three quantitative traffic
   classes: premium, standard and best effort.  If
   which will arrive at the node, while leaving sufficient capacity
   remaining to accommodate some amount of premium
   traffic crossing the boundary is greater than the rate specified qualitative traffic.

   The provisioning mechanism described assumes a top-down approach, in
   which the SLA, some of network administrator studies the premium network topology and
   traffic may be demoted routing and computes the provisioning requirements. An

Blake, et al             Expires: April 1999                        18
   alternative approach uses signalling to standard
   class.  On automate the other hand, if there is less premium traffic than
   specified in process [MPLS].
   For example, RSVP messages could be launched along the SLA, standard traffic may paths that
   will be promoted to premium.

4.1.3  Mapping followed by submitted quantitative traffic. If a TCA calls
   for 100 Kbps of PHBs at Boundaries

   When two DS domains are based on very different PHB groups, the SLA
   has leased-line service from ingress point A to specify how one PHB in one DS domain is mapped egress
   point B, an RSVP message could be transmitted from point A towards
   point B, with a flowspec specifying 100 Kbps. This message would
   traverse each node at which resources would have to be committed.
   Conventional RSVP routers would install a PHB in
   another domain.  If reservation. In a
   differentiated service network, RSVP could be adapted to provision
   the PHBs have different values but similar
   semantics, resources required per the mapping may differentiated services model. In a
   network which offers a number of static TCAs, such RSVP messages
   could be simple.  However, in some launched from the TCA ingress point at the time the TCA is
   initially instantiated with the effect of instantiating the
   appropriate cumulative provisioning in routers along the various
   routes. The advantage of this approach is that it does not require
   explicit knowledge of the network topology. We will revisit these
   two approaches to quantitative provisioning of the interior in a
   later section.

   Once the resources required for quantitative traffic at each node
   have been determined, provisioning of the node consists of
   installing or configuring interfaces of the appropriate capacity to
   easily accommodate the quantitative traffic that will traverse the
   node. Note that we do not state the precise meaning of 'to easily
   accommodate'. A number of factors must be considered when
   determining the appropriate capacity, given a certain volume of
   predicted quantitative traffic. These include:
   1. Margin of error
   2. Statistical gain desired
   3. Capacity remaining for qualitative (including best efforts)
      traffic

   The first, margin of error, accommodates mistakes in computation,
   effects of transient route changes which are not otherwise accounted
   for, effects of traffic clustering as it moves through the network
   and so on. The statistical gain desired refers to the degree to
   which a provider is willing to gamble that not all sources of
   quantitative traffic will be simultaneously active at the limit
   dictated by the TCAs at the ingress points (vs. the penalty the
   provider would be willing to pay in terms of refunded charges or
   lost customers). Finally, the provider must determine how much
   capacity will be reserved for qualitative traffic at each node.
   Thus, if it is determined that 1 Mbps of quantitative traffic might
   traverse a specific node in a specific direction, the provider might
   install a 10 Mbps interface in the node, to serve the corresponding
   traffic direction. This would leave 9 Mbps of capacity quite safely
   for qualitative traffic. In this case, the
   mapping can provider would be
   assuming that statistical gains which might be realized will be used
   to offset the margin of error which would compromise the resources
   available.

Blake, et al             Expires: April 1999                        19
   In addition to installing or configuring the appropriate capacity at
   each interface, it may be desirable to configure policers to assure
   that the resources actually consumed by the higher priority
   quantitative traffic do not exceed expectations. This is especially
   important if the provider is attempting to achieve a high degree of
   statistical gain or has not allowed for a reasonable margin of
   error. Policers need not be configured at each interior node, but
   should probably be configured at certain key nodes.  It may also be
   necessary to configure the internal resources of the router (queues
   and buffers) to deliver the services required.

6.1.2.2 Qualitative Provisioning of the Interior

   As explained previously, it is necessary first to determine the
   resources which must be provisioned at each node for quantitative
   traffic. Once these have been determined, interfaces must be
   installed or provisioned to accommodate the required resources while
   leaving sufficient capacity for qualitative traffic. In order to do
   so, it is necessary to determine the resources required at the node
   for qualitative traffic. Since qualitative traffic cannot be assumed
   to follow specific routes with the same degree of predictability as
   quantitative traffic, this provisioning problem is far more
   difficult and provisioning parameters must be estimated based on
   heuristics, experience and possibly on real time measurement.

   Once physical interfaces have been selected to accommodate the
   resources required by the computed quantitative traffic load and the
   estimated qualitative traffic load, additional configuration is
   required to support qualitative traffic. Such configuration amounts
   to the selection of relative weights for queues for different
   service levels (in a WFQ scheme), or the selection of RIO or RED
   thresholds or alternate logical resource provisioning parameters. It
   is assumed that if quantitative traffic is accommodated via similar
   queuing mechanisms (as opposed to strict priority queuing), that the
   weighting parameters chosen for quantitative traffic isolate it
   effectively from the effects of qualitative traffic. However, the
   configuration parameters which differentiate the various qualitative
   services may not provide such a degree of isolation among the
   qualitative services. Thus, it may be necessary to attempt to
   estimate the relative traffic arriving for each qualitative service
   and to anticipate the interaction between traffic of different
   qualitative services. It may be impossible to both efficiently and
   conservatively provision a network for certain combinations of
   qualitative services. To aid in the provisioning of a network for
   qualitative services, it may be useful to configure policers to
   control the volume of traffic arriving at a given node. However,
   such policing might have to be restricted to shaping (rather than
   discarding) in order to avoid violating TCAs in place at the network
   boundaries.

Blake, et al             Expires: April 1999                        20

6.2. Static vs. Dynamic Provisioning

   So far, we have considered static provisioning techniques. Even the
   example of RSVP usage for provisioning assumed that the RSVP
   messages were launched at the time a TCA was instantiated as opposed
   to dynamically. In the case that TCAs are static, static
   provisioning is adequate for quantitative traffic. However, since
   qualitative traffic [e.b.1] offers less predictable patterns, it is
   likely to cause traffic volumes at different nodes in the network to
   change dynamically, even when the TCA is static. For this reason,
   dynamic provisioning techniques are desirable and may assist the
   service provider in making better use of network resources. In
   addition, dynamic provisioning may enable the service provider to
   provision more liberally for quantitative services, realizing
   statistical gains. If we consider further, that it may be desirable
   to provide dynamically changing TCAs, then the appeal of dynamic
   provisioning techniques is even stronger.

   Dynamic provisioning may be signalling based, measurement based or
   both. For example, a conventional RSVP router supports signalling
   based dynamic provisioning. Hosts signal the router to request more
   or less resources and the router adjusts accordingly. The host may
   or may not actually submit traffic at the rate at which it signalled
   it would, but regardless, the resources are committed in case it
   does. Measurement based provisioning would adjust the resources
   committed in response to the traffic loads actually measured at the
   device. While differentiated services does not specify any form of
   signalled or measurement based provisioning, both may be useful.

6.3 Distributing Configuration Information

   The process of physical provisioning is by necessity relatively
   static and cannot be automated since it requires installation of
   physical equipment. However, logical provisioning and configuration
   can and should be automated to the degree possible. In this section,
   we look at techniques for distributing configuration information.

6.3.1 Top Down Distribution of Configuration Information

   In the simplest case, TCAs are static and both the boundaries and
   interior of the network are provisioned statically by 'pushing'
   configuration information down to the appropriate network nodes.
   Configuration of boundary nodes requires primarily the pushing of
   policing information to enforce the TCAs in place. (Additional fine
   grain information may be pushed to provide traffic separation
   services on behalf of the customer, but these are not addressed in
   this context). Configuration information for boundary nodes is
   determined at the time the TCA is negotiated. At this time, the
   nodes are configured by the provider. The network administrator may
   use one of several protocols to do so, including for example SNMP or
   CLI.

Blake, et al             Expires: April 1999                        21
   In order to accommodate the traffic submitted by the provisioning of
   new TCAs, it is necessary to provision the interior of the network.
   As discussed previously, it is possible to compute the resources
   required for quantitative traffic. Assuming that sufficient physical
   capacity has been provisioned, configuration amounts to logically
   provisioning sufficient capacity at each interior interface and to
   configuring policers for the quantitative traffic at various
   interior nodes. In addition, qualitative provisioning requires the
   configuration of queues, WFQ weights and/or RIO parameters at
   various interior nodes, and may also include the configuration of
   some number of policers. In the case, of static, top down
   configuration, interior configuration information is also pushed
   down via a configuration protocol such as SNMP or CLI.

   The difficulty of such top down provisioning is that it requires the
   network administrator to coordinate the provisioning of each network
   node, at boundaries as well as in the interior, such that the
   network is provisioned end-to-end in a consistent manner and is able
   to efficiently deliver the services promised by the TCAs. In order
   to assist the network administrator in this task, it is useful to
   consider a database which holds both current topology information as
   well as the current TCAs instantiated at the network boundaries.
   This information is stored in a format dictated by a standard schema
   as suggested in [Elleson].

   Of course, the database is ideally maintained in a way which is
   logically centralized (for ease of programming and modifying) but is
   physically distributed (for the sake of robustness and fault
   tolerance). Policy servers may be used to extract information from
   the database and to convert it to configuration information which is
   pushed down to individual nodes. In this scenario, policy servers
   would likely use a directory access protocol such as LDAP to
   retrieve information from the directory and would use a
   configuration protocol such as SNMP or CLI to push the configuration
   information down to the network nodes. Note that in this example,
   the policy servers and the directory schemas are in effect
   fulfilling the role of bandwidth broker [BB]. In particular, the
   policy servers use an awareness of the network topology to provision
   interior nodes such that certain end-to-end QoS routes can be
   constructed and assurances implied by the TCAs at the boundaries can
   be delivered.

6.3.2 Distribution of Configuration Information via Signalling

   An alternate mechanism of distributing configuration information is
   via signalling messages transmitted between boundary nodes of the
   same differentiated service domain (intra-domain signalling). It is
   also interesting to consider inter-domain signalling, but this will
   be addressed separately. An example of such signalling was described
   previously, in the usage of a modified form of RSVP. Such signalling

Blake, et al             Expires: April 1999                        22
   is particularly useful for the purpose of installing configuration
   information for quantitative services which affect specific paths
   and is somewhat less useful (though not useless) for the purpose of
   configuring qualitative services. It is likely that such a
   signalling approach would be used in conjunction with top down
   provisioning. For example, the directory schema might dictate the
   amount of resources to be available for high priority quantitative
   services at each node. These limits might be pushed down to
   individual nodes a- priori. Signalling from the network boundaries,
   at TCA instantiation time, would then be used to claim resources
   from the pool of quantitative resources available at each node.
   Alternatively, nodes might consult policy servers as the signalling
   resource requests arrive at each node. The latter model is similar
   to the use of per- flow RSVP signalling and PEP/PDP policy usage in
   traditional RSVP networks. Qualitative configuration information
   would still be pushed in a top down manner. The advantage of the
   latter model is that policy servers would be dynamically updated
   with information regarding the current usage of network resources.
   In this model, it is likely that a variant of COPS would be used to
   communicate between network nodes and the policy servers. Note that
   COPS may be used for distribution of top down configuration
   information as well, though it is not specifically designed for this
   purpose.

   One of the advantages of configuration via signalling, is that it
   facilitates the support of dynamic TCAs. TCAs could be dynamically
   renegotiated using inter-domain signalling. Such renegotiation would
   require dynamically modifying the provisioning within the affected
   domain, a process which requires some automated signalling protocol
   such as an aggregated form of RSVP signalling between boundary nodes
   in a provider's domain. This protocol would in effect, represent a
   distributed bandwidth broker [BB] for the domain.

6.3.3 Modification of Configuration Information Based on Real-Time
Measurement

   A third mechanism for the configuration of interior nodes would be
   based on measurement of current traffic loads at key network nodes.
   Measurement based configuration is less necessary for quantitative
   provisioning, since quantitative traffic patterns are relatively
   predictable. However, it can significantly enhance the efficiency
   with which qualitative provisioning can be achieved. For example,
   network nodes may feed policy servers with current qualitative
   traffic load measurements. In response, bandwidth brokers and policy
   servers might recompute the relative weights for different service
   queues in a WFQ node and push the new configuration information to
   the routers. It is likely that measurement based configuration for
   qualitative services would be used in conjunction with signalling
   based configuration for quantitative services.

Blake, et al             Expires: April 1999                        23

7. Inter-Domain Considerations and End-to-End Services

   So far we have considered differentiated service primarily in the
   context of a single DS domain providing service to a single
   customer. The ultimate customers of the differentiated service
   network are hosts and end users residing on peripheral stub
   networks. In general, these are interconnected by multiple domains
   and require service which spans these domains. Therefore, it is
   important to consider the interaction of services provided by a
   concatenation of differentiated service domains and the peripheral
   stub networks, rather than the service provided by a single domain.
   In this section, we discus inter-domain issues related to TCAs,
   provisioning and service and PHB mapping.

7.1 TCAs

   Each service provider is expected to negotiate bilateral agreements
   at each boundary node at which it connects to an adjacent provider's
   network. Such agreements are captured in the form of two TCAs, one
   governing the services provided to provider A's traffic by provider
   B and the other governing the services provided to provider B's
   traffic by provider A. Note that provider A serves as a provider to
   provider B with respect to traffic flowing from provider B to
   provider A. On the other hand provider A is a customer of provider B
   with respect to traffic flowing from provider A to provider B. The
   two TCAs can be considered separately.

   In general, the TCAs negotiated by a provider at any boundary will
   be dictated by TCAs negotiated at other boundaries. For example,
   assume that provider A offers leased line service to a customer with
   an ingress point in provider A's domain, but an egress point in
   provider B's domain. In this case, it is necessary that the TCA
   between provider A and provider B be sufficient to accommodate the
   assurance made by provider A to its leased line service customer.
   Provider A may serve a number of customers with leased line services
   terminating at various boundary points in provider B's network.
   Thus, the TCA between provider A and provider B must represent the
   aggregate requirements of the TCAs of all of provider A's customers.

7.2 Inter-Domain Provisioning

   The inter-domain provisioning problem is not unlike the intra-
   domain provisioning problem. The provider would generally begin by
   evaluating the TCAs it has negotiated with its customers, and then
   computing the impact of each of these TCAs on the TCAs it has
   negotiated with its providers. For quantitative services, the
   provider can compute the quantitative requirements of TCAs at each
   of its provider's boundary nodes, as described above in the context
   of the leased line service. For qualitative services, the process of
   determining the requirements from its providers is fuzzier, since

Blake, et al             Expires: April 1999                        24
   the volume of qualitative traffic expected to be carried through any
   boundary is less deterministic.

   In the simplest case, provisioning is based on static TCAs. In this
   case, provisioning is an iterative process in which providers
   negotiate TCAs with each of their customers, then apply the
   appropriate internal provisioning techniques to meet these
   requirements. In the process of internal provisioning, a provider
   might determine that a particular TCA cannot be met due to internal
   resource constraints. The provider would then either have to add
   internal resources or renegotiate one or more customer TCAs.
   Although the process may be somewhat iterative, it is relatively
   static in that changes in boundary TCAs and internal provisioning
   occur relatively infrequently (on the order of hours, days or
   months) and require human intervention.

   Internal provisioning to meet the requirements of TCAs relies on
   provisioning techniques described previously. As TCAs are
   negotiated, the provider must check that the existing internal
   provisioning is sufficient to meet the requirements of the new TCA,
   or must alter the internal provisioning. Recall that internal
   provisioning might be pushed in a top down manner, from a domain's
   logically centralized point of administration, or alternatively
   might be distributed from the edges via signalling. In the former
   case, some form of a bandwidth broker would be directly consulted or
   notified regarding changes in TCAs negotiated at the domain
   boundaries. In the case that signalling is used, provisioning
   messages (such as described previously) would be launched from the
   boundary at which the new TCA is negotiated. These would claim a
   share of existing provisioned resources, or would notify the
   bandwidth broker in the case that additional resources are required.

   A more sophisticated model would allow TCAs to be renegotiated
   dynamically. In this case, the process would be automatic, and would
   not require human intervention. Each domain would in effect,
   represent a bandwidth broker, via one protocol or another. A
   specific inter-domain protocol might be used to communicate between
   centralized bandwidth broker agents, or alternatively, an inter-
   domain variant of RSVP might be used.  In the latter case, there is
   no direct interaction with a bandwidth broker per-se. However, the
   collection of network nodes, policy servers and directory behave
   collectively as a bandwidth broker which communicates using RSVP. In
   either case, TCA renegotiations would be triggered by load
   measurements at boundary nodes. These could be in the form of
   changes in actual measured traffic volume, or alternatively, based
   on explicit fine grain RSVP resource requests from hosts at the
   periphery. Domains would approve renegotiations based both on
   resource constraints as well as predetermined policy constraints.

Blake, et al             Expires: April 1999                        25

7.3 Service, PHB and Codepoint Mapping

   In order to provide end-to-end service to customers, it must be
   possible to extend services across multiple domains. Several
   complexities may arise at inter-domain boundaries, as follows:
   1. The services provided by a certain domain may not be compatible
      with the services provided by a neighbour domain.
   2. The services provided by a certain domain may be compatible with
      those provided by the neighbour domain, but the PHB used to
      obtain the service might be different.
   3. The PHB might be the same, but the codepoint used to request the
      PHB might be different.
   4. The PHB and codepoint are the same but differences in
      provisioning and charging models results in different services.

   Resolution of these complexities requires determination of the
   compatible services and negotiation of the PHB codepoints which will
   be used to request the services. This process is greatly simplified
   by the provision of a set of universal services using universally
   recognized codepoints. The leased line service and EF codepoint is
   likely to be one such example. Generally, extension of quantitative
   services across multiple domains will require more uniformity in the
   nature of the services provided. Qualitative services on the other
   hand, may be extended end-to-end by a concatenation of services
   which vary from domain to domain. For example, one domain may base a
   qualitative service on a WFQ scheme with RED while another may use
   priority queuing with RIO. Since the assurances provided by
   qualitative services tend to be looser, it is possible that a
   meaningful service can be provided end-to-end by concatenating these
   two service types.

7.4 Host-Domain Boundaries

   In certain cases, a host may be directly attached to a
   differentiated service domain. This is likely both in the case of
   campus networks that provide differentiated services within the
   network or in the case of dial-up users connecting to a
   differentiated service provider. In these cases, the host can be
   considered the customer of the differentiated service network.
   Legacy hosts are unlikely to mark their own packets for the
   appropriate DS-field and are also unlikely to shape or police their
   traffic. In the case of legacy hosts, the differentiated service
   provider will have to provide these services on behalf of the
   customer. In the case of campus networks, some network wide policy
   would likely be used to configure these services in the DS boundary
   devices. In the case of dial-up hosts, marking, shaping and
   resources provided would likely be negotiated at the time the
   customer signs up with the provider.

   Newer hosts may be capable both of marking and of traffic shaping.
   In this case, the overall per-host resource constraints are still

Blake, et al             Expires: April 1999                        26
   likely to be somewhat static. However, the manner in which the host
   shares these resources among its various traffic flows is determined
   by the host. Of course, the provider will have to configure policers
   to assure that the host does not seize more than its share of
   resources in the differentiated service network.

8. Inter-operability with RSVP/Integrated Services

   In this section, we discuss alternatives for inter-operability
   between differentiated services and RSVP/Integrated services.

8.1 RSVP/Integrated Services Over Differentiated Services

   This scenario is discussed in detail in [E2EQOS]. It assumes a model
   in which peripheral stub networks are RSVP and Intserv aware. These
   are interconnected by differentiated service networks. In this
   model, the scalability of differentiated service networks helps to
   extend the reach of RSVP/Integrated service (Intserv)networks.
   Intervening differentiated service networks appear as a single RSVP
   hop to the RSVP/Intserv networks. Hosts attached to the peripheral
   RSVP/Intserv networks signal to each other for per-flow resource
   requests across the differentiated service networks. Standard
   RSVP/Intserv processing is applied within the RSVP/Intserv
   peripheral networks. RSVP signalling messages are carried
   transparently through the differentiated service networks. Devices
   at the boundaries between the RSVP/Intserv networks and the
   differentiated service networks process the RSVP messages and
   provide admission control based on the availability of appropriate
   resources within the differentiated service network.

   This model is predicated on the availability of services within the
   differentiated service network which can extend the reach of intserv
   type services. For example, the leased line service can extend the
   intserv guaranteed service across a differentiated service network.
   Multiple guaranteed service micro-flows which exist in peripheral
   networks are aggregated into the EF behaviour aggregate at the edge
   of the diffserv network. When an RSVP request for guaranteed service
   arrives at the edge of a differentiated service network, RSVP style
   admission control is applied based on the amount of resources
   requested in the intserv flowspec and the availability of
   differentiated services at the corresponding service level (per the
   TCA). If admission control succeeds, the originating host (or its
   agent) marks traffic on the signalled microflow, for the appropriate
   differentiated service level.

   The RSVP/Intserv over differentiated service model is especially
   suitable for providing quantitative end-to-end services. The use of
   differentiated services eliminates the scalability concerns of
   RSVP/Intserv networks. The use of RSVP signalling provides admission
   control to the differentiated service network, based on resource
   availability and policy decisions. It also greatly simplifies the

Blake, et al             Expires: April 1999                        27
   configuration of differentiated service classifiers, policers and
   other traffic conditioning components.

   Variations on this theme would enable some number of nodes within
   the differentiated service networks to process the per-flow RSVP
   messages passing through. These could be used to aid in dynamic
   provisioning without necessarily requiring any per-flow state or
   processing within the differentiated service network. In yet another
   model, the transition of per-flow RSVP messages through the
   differentiated service network might trigger aggregated RSVP
   signalling between differentiated service domain edges, for the
   purpose of renegotiating TCAs and adjusting provisioning dynamically
   [GBH97, CLASSY].

8.2 Parallel Operation

   Another alternative for the interoperation of differentiated service
   and RSVP/Intserv networks is simple parallel operation. In this
   mode, each node within the differentiated service network may also
   be an RSVP capable node. Some strategy would have to be selected for
   determining which packets are handled using RSVP and which are
   handled using differentiated services. For example, those that
   classify to an RSVP installed filter might be very difficult.  For example, one DS domain uses
   queueing priorities handled using RSVP,
   while the other is based on discard priorities.
   However, in general, a "better" treatment in one PHB group should those not classifying to specific RSVP filters would be
   mapped
   handled according to another "better" treatment.

4.2  Host Interactions

   In the previous sections, we discuss the DS-field using differentiated services
   primarily from the perspective of a service provider.
   mechanisms. Such a model is likely to be deployed in smaller
   networks (since the RSVP/Intserv component is less suited for large
   networks). In this
   section we look at how particular, the users can make use of stub networks cited in [E2EQOS] would
   likely provide differentiated services offered by
   DS-capable networks.  A host for those qualitative
   applications which is DS aware is just another DS
   egress device; do not a special case.

4.2.1  Traffic Conditioning signal, while providing RSVP/Intserv
   services for Directly Connected Users

   A user can gain access to those quantitative applications which do signal.

9. Multicast Services

   Because the Differentiated Services Architecture deals only with
   unidirectional flows, a 'multicast' service in a DS-capable DS network directly or through will in
   fact offer a
   customer domain.  Users who are directly connected point-to-multipoint unidirectional service.  Each
   source of traffic that wishes to send to the multicast group using
   this service needs a DS-capable
   ISP (e.g., a dial-up user) should have a separate SLA with which applies at the ingress point
   where the ISP.  Complex traffic conditioning functions ideally should ideally enters the network.

   The network resources that must be provisioned for a multicast
   service will be performed affected by the hosts mechanisms used by the routers to
   provide the service.  Depending on the capabilities of the users rather than routers
   and the access nodes, which multicast routing protocol employed, sub-optimal replication
   of a packet may have result in multiple copies travelling over the same
   link.

   If receivers can be added dynamically to a multicast group whilst a
   flow is in progress, the complexity of provisioning grows
   considerably:  The amount of network resources that will be consumed

Blake, et al             Expires: April 1999                        28
   by multicast traffic originating from a particular upstream network
   may be difficult to forecast in advance.  Consequently, it may not
   be possible to handle tens of thousands offer quantitative services where dynamic addition of users.

   However, mechanisms have
   receivers adds to be in place so that the ISPs are assured
   that they can trust paths through the self-policing network already used by the users.

   Users
   flow.

9.1  Codepoints and PHBs for Multicast Services

   To achieve resource isolation of multicast traffic from unicast
   traffic, it may have be necessary to install DS control software from ISPs.  When use separate codepoints and separate
   instances of a user
   dials in, the authentication process also configures the DS control
   module in the user's host according to the SLA between PHB or different PHBs for the user multicast and unicast
   services.  If the ISP.  Random checking can also be done to ensure that the SLA multicast traffic is
   maintained.

4.2.2  Service Allocation within Customer Domain

   When users are part not adequately isolated,
   dynamic addition of a customer domain, there is an issue new members of local
   resource allocation.  The customer domain should have the multicast group can adversely
   affect existing unicast traffic.

   Because a policy as to
   what packets multicast service traffic flow can exit from a domain to
   several peer domains, care must be set taken to use a particular codepoint and PHB group.  Some form of
   allocation, either static or dynamic,
   that is needed in order to share compatible with the
   profiles that peering SLAs at the customer domain has obtained.  The egress node of
   the customer domain points.  This
   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 be a central allocation server more stringent requirement than for
   the customer domain and as a client to request additional resources
   from the ISP [BB].  RSVP may also unicast service where
   a flow need only be adopted as compatible with a single egress point SLA.

9.2  Provisioning Multicast Services

   The scope of a multicast service would normally be either case 1
   (any egress point) or case 3 (a pre-defined set of egress points) of
   Sec. 4.4.

   For a mechanism for
   requesting bandwidth with the customer domain and quantitative service the resources scope will, in general, need to
   the ISP [RSVP].

4.2.3  End-to-End Services be
   case 3.  The differentiated services architecture is designed to service can 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 provisioned in a similar way to
   extend the
   corresponding unicast 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 same volume of traffic pattern, provisioning becomes much harder
   when more DS domains are linked together.  The level along
   each of provisioning
   depends on the economic factors in the differentiated services and
   varies paths from ISP ingress to ISP.  In general, when egress, but taking into account
   that all paths will be used simultaneously and allowing for multiple
   copies of traffic if necessary.  If the packets leave multicast routing protocol
   used can generate different multicast trees depending on the ISP
   to order
   in which members join the customer has a SLA, group, provisioning may not be possible.
   Solving this problem may require pinning of the level multicast tree
   branch points; the solution of service may degrade. this problem is outside the scope of
   this framework.

   For example, if a qualitative service, provisioning is essentially the same as
   the unicast case, but statistical multiplexing gains are likely to
   be less because all paths may be used at once.

   The traffic aggregate conditioning mechanisms for multicast services are not
   significantly different from those for a particular PHB were over
   the rate the next ISP would accept, some packets unicast services but
   multiple shapers may be demoted required where traffic exits from several
   interfaces on a single router or multiple replicas exit from one
   interface.

Blake, et al             Expires: April 1999                        29

10. Security and Tunnelling Considerations

   The security and tunnelling implications for the actual data
   transport of the services of the Differentiated Services
   Architecture have been extensively discussed in {DSARCH] and
   [DSHEAD] to a
   PHB with worse treatment.  The more ISPs a packet traverses, which the less
   control reader is referred.

   Additional security considerations arise from the originating ISP has. services overlaid
   on the data transport:
   1. The extensibility services are the subject of differential charging.
      Accordingly, the differentiated services model allows many
   different schemes service users have to be tried out authenticated and developed further.

   One possible approach is
      authorised, and the accounting data needed must be secured.
   2. The mechanisms used to establish an ISP-to-ISP pipe across
   multiple ISPs.  So, create and distribute the originating ISP policy and terminating ISP know
   exactly how traffic between them is provisioned.  This is similar
      resource allocations must be secured.
   3. Statistical data needed to audit service delivery must be
      secured.

   The mechanisms used to provide this security are outside the VPN services that an ISP offers for connecting different sites scope
   of
   an organization.

5.  Interoperability with Integrated Services

   In this section, we discuss three possible options for the
   interoperability between framework, but are under consideration by the differentiated services and Integrated
   Services [IntServ].

5.1  Parallel Operation

   Both differentiated services AAA working
   group.

   The use of tunnels in general and Integrated Services may operate IPsec tunnels in
   parallel over the same network infrastructure.  It may be necessary
   to set limits on particular
   impedes the amount work of bandwidth available for Integrated
   Services reservations so that MF Classifiers by concealing 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 fields used to make
   reservation for long-lasting by
   L4 and high-bandwidth flows.  This is
   similar to higher layer classifiers.  Thus traffic conditioners within
   the current telephone networks.  One does not area where IPsec encryption is used will need to make
   a prior reservation in order to make a phone call.  The likelihood of
   blocking inside rely only on IP
   header fields, including the network is very small as capacity DS field (BA Classifiers will work
   normally).  If more sophisticated Mf classification 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 required it
   will have to take place before the tunnel ingress and Integrated the
   application of IPsec encryption.  If IPsec encryption is used end-
   to-end, then Differentiated Services may be
   tightly coupled by means of require host marking.

   If a hierarchical bandwidth allocation
   scheme.  Differentiated services tunnel carries multiple flows with different traffic types,
   they may be used marked with different DS codepoints so that they are
   subjected to allocate bandwidth appropriate behaviors in
   bulk quantity to individual customer networks.  Each customer the network interior.  This
   may use Integrated Services mechanisms be considered 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 be a
   special DS security breach as it allows traffic
   patterns to become visible.  If just one codepoint is used for all
   traffic it should be selected carefully to convey aggregated classification state (the
   service class, and possibly an in- or out-of-profile indicator).
   Examples of this model include [GBH97, CLASSY].

6. be appropriate for all
   the traffic in the tunnel.

11. 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.

Blake, et al             Expires: April 1999                        30

12. 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>, Draft, 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>,
   Draft, 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>,
   Draft, 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",

   [AF]  J.Heinanen, _Assured Forwarding PHB Group_Internet Draft,
   August 1998.

   [EF]  V.Jacobson, _Expedited Fowarding Per Hop Behavior_, Internet Draft
               <draft-ietf-diffserv-precedence-00.txt>, April
   Draft, August 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>, Draft, 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>, Draft, March 1998.

   [GBH97] R. Guerin, S. Blake, and S. Herzog, "Aggregating RSVP- based
   QoS Requests", Internet Draft
               <draft-guerin-aggreg-rsvp-00.txt>, Draft, 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'

Blake, et al             Expires: April 1999                        31

11. Author's Addresses

   Bernet, Yoram Bernet
   Microsoft
   One Microsoft Way, Way
   Redmond, WA 98052
   Phone:  +1-425-936-9568
   E-mail: +1 (425) 936-9568
   Email: yoramb@microsoft.com

   Binder, James Binder
   3Com Corp.
   5400 Bayfront Plaza
   Santa Clara, CA 95052
   Phone:  +1-408-326-6051
   E-mail: +1 (408) 326-6051
   Email: james_binder@3com.com

   Blake, Steven Blake
   IBM Corporation
   800 Park Offices Drive
   Research Triangle Park,
   Torrent Networking Technologies
   3000 Aerial Center, Suite 140
   Morrisville, NC  27709  27560
   Phone:  +1-919-254-2030
   E-mail: slblake@raleigh.ibm.com  +1-919-468-8466 x232
   Fax:    +1-919-468-0174
   Email: slblake@torrentnet.com

   Carlson, Mark A. Carlson
   Redcape Software,
   RedCape Software Inc.
   2990 Center Green Court South
   Boulder, CO 80301
   Phone:  +1-303-448-0048 +1 (303) 448-0048 x115
   E-mail:
   Email: mac@redcape.com

   Davies, Elwyn Davies
   Nortel UK
   London Road
   Harlow, Essex CM17 9NA, UK UA
   Phone: +44-1279-405498
   E-mail:
   Email: elwynd@nortel.co.uk

   Ohlman, Borje Ohlman
   Ericsson Radio
   Dialoggatan 1 (Kungens Kurva)
   S-126 25 Stockholm
   Sweden
   Phone: +46-8-719 3187
   E-mail:
   Email: Borje.Ohlman@ericsson.com

Blake, et al             Expires: April 1999                        32
   Srinivasan Keshav
   4107B Uspon Hall
   Cornell University
   Ithaca, NY 14853
   Phone: +607-255-5395
   Email: skeshav@cs.cornell.edu

   Dinesh C. Verma IBM TJ T. J. Watson Research Center
   PO
   P.O. Box 218 704
   Yorktown Heights, NY 10598
   E-mail:
   Phone: +1 (914) 784-7466
   Email: dverma@watson.ibm.com

   Zheng Wang
   Bell Labs Lucent Tech
   101 Crawfords Corner Road
   Holmdel, NJ 07733
   E-mail:
   Email: zhwang@bell-labs.com

   Walter Weiss
   Lucent Technologies
   300 Baker Avenue, Suite 100, 100 Concord, MA 01742-2168
   E-mail:
   Email: wweiss@lucent.com

Blake, et al             Expires: April 1999                        33