[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
   Differentiated Services                       Y. Bernet, Microsoft
   Internet Draft                                D. Durham, Intel
   Document: draft-bernet-diffedge-01.txt        F. Reichmeyer, Bay
                                                 November, 1998



                Requirements of Diff-serv Boundary Routers


   Status of this Memo

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

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

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on 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.






















Bernet                                                               1

              Requirements of Diff-serv Boundary Routers November 1998



   1. Abstract........................................................3
   2. Conventions used in this document...............................3
   3. Introduction....................................................3
   4. Functional Components...........................................4
   4.1 Interfaces, Traffic Conditioning, PHBs and the Routing Core....5
   4.2 Diff-serv Provisioning Interface...............................5
   4.3 Monitoring.....................................................5
   4.4 RSVP...........................................................5
   4.5 Traffic Conditioning Agreements and PHB Capacity Tables........6
   5. Traffic Conditioning............................................6
   5.1 Classifiers....................................................6
   5.2 Meters.........................................................7
   5.3 Markers........................................................7
   5.4 Shapers........................................................8
   5.5 Droppers.......................................................8
   5.6 Basic Configurations of Traffic Conditioning Components........8
   5.7 Traffic Conditioning Configurations Supporting Value-Added
   Services..........................................................10
   6. Configuration Information Required at Boundary Routers.........11
   6.1 PHB Configuration Information.................................12
   6.2 Traffic Conditioning Configuration Information................12
   6.2.1 Elements of Traffic Conditioning Configuration Information..13
   6.2.2 Customer Classification Information.........................13
   6.2.3 The Traffic Conditioning Agreement (TCA)....................14
   6.2.3.1 The Constraint TCA........................................14
   6.2.3.2 Fine-Grain TCA............................................16
   6.3 Relationship Among the CCI, Constraint TCA and Fine-Grain TCA.17
   6.4 Additional Configuration Information..........................19
   7. Configuration Mechanisms.......................................19
   7.1 Installing PHB Configuration Information......................19
   7.2 Installing the Constraint TCA.................................19
   7.3 Installing the Fine-Grain TCA.................................20
   8. Admission Control..............................................21
   8.1 Reflection of PHB Configuration at Ingress Interfaces.........21
   8.2 Admitting the Constraint TCA..................................22
   8.3 Admitting the Fine-Grain TCA..................................23
   8.4 Summing Profiles..............................................23
   9. Support for RSVP Admission Control.............................24
   9.1 Overview of RSVP and Diff-serv Interoperation.................24
   9.2 Example of Admission Control to a Diff-serv Network...........24
   9.3 Implementing RSVP Admission Control in Boundary Routers.......25
   9.3.1 RSVP Reservations Expressed as Fine-Grain TCA Entries.......26
   9.3.2 Modifying Marked DSCPs......................................26
   9.3.3 RSVP and IP Security........................................26
   10. Intercepting or Ignoring RSVP Messages........................26
   8. Security Considerations........................................27
   9. References.....................................................27
   11. Author's Addresses............................................28
   Appendix A. COPS-DS Constraint TCA PIB Format.....................29
   Appendix B. COPS-DS Fine-Grain TCA PIB Format.....................30



Bernet                                                               2

              Requirements of Diff-serv Boundary Routers November 1998




1. Abstract

   This draft discusses requirements of routers that serve as
   ingress/egress points to/from differentiated services (diff-serv)
   networks. We discuss the traffic conditioning components required
   and associated configuration mechanisms and protocols. We also
   discuss admission control to diff-serv networks in support of
   signaled QoS.


2. Conventions used in this document

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


3. Introduction

   Diff-serv [DSARCH, DSFWK] is a mechanism by which network service
   providers can offer differing levels of network service to different
   traffic, in so providing quality of service (QoS) to their
   customers. The basic premise of diff-serv networks is that routers
   within the networks handle packets different traffic flows by
   applying different per-hop behaviours (PHBs). The PHB to be applied
   is specified by a code (the diff-serv code-point or DSCP) in the IP
   header of each packet.

   The advantage of such a scheme is that many traffic flows can be
   aggregated to one of a small number of PHBs, thereby simplifying the
   processing and storage associated with packet classification. In
   addition, there is no signaling state or related processing required
   in the diff-serv network since QoS is invoked on a packet-by-packet
   basis.

   In this draft, we discuss the requirements on diff-serv boundary
   routers. These are the routers that reside at the ingress or egress
   points to or from diff-serv networks (from here on referred to as
   diff-serv boundary routers). The requirements of these routers are
   generally a superset of the requirements of routers that reside in
   the core of the diff-serv network. This is because boundary routers
   must enforce the SLAs that are in effect at the network boundaries
   (in addition to providing the PHBs required in core routers). Note
   that although the requirement set for boundary routers is broader
   than that for core routers, the performance demands on core routers
   may be significantly greater than those on boundary routers.
   Specific performance requirements are not addressed in this draft.

   The purposes of this draft are:



Bernet                                                               3

              Requirements of Diff-serv Boundary Routers November 1998


   1. To establish baseline functionality for diff-serv boundary
      routers.
   2. To provide a conceptual model for the general configuration
      information required at boundary routers.
   3. To provide a structured model of the required traffic
      conditioning configuration information which is conveyed via
      COPS.
   4. To discuss interactions of the boundary routers with various wire
      protocols, in particular COPS and RSVP [RFC2205].

4. Functional Components

   In order to support a diff-serv network, certain functionality is
   required from the boundary routers, which reside at the ingress and
   egress points to and from the diff-serv network. This functionality
   is discussed in the following sections.

   The following diagram illustrates the major functional blocks of a
   diff-serv boundary router:





           ------------
        ---|monitoring|
        |  ------------
        |
   mgmt.|  ----------------
   COPS,|  | diff-serv    |
   <------>| provisioning |------------------------
   SNMP,|  |     i/f      |                       |
   etc. |  ----------------                       |
        |       |       |                         |
        |       |       |                         |
        |       v       |                         v
   data |  -----------  |    ---------       ------------
   ------->| inbound |------>|routing|------>| outbound |---->
        |  |  (TC)   |  |    ---------       |  (PHB)   |
        |  -----------  |                    ------------
        |       ^       |                         ^
        |       |       |                         |
        |  -----------  |                         |
        -->|         |  |                         |
   ------->|  RSVP   |-----------------------------
   RSVP    |         |  |---------------------
   cntl    -----------  |                    |
   msgs         ^       v                    v
                |  -------------       -------------
                ---| diff-serv |       | TCAs, PHB |
                   |    a/c    |       | capacity  |
                   -------------       | tables    |
                                       -------------

Bernet                                                               4

              Requirements of Diff-serv Boundary Routers November 1998



4.1 Interfaces, Traffic Conditioning, PHBs and the Routing Core

   An inbound interface, routing component and outbound interface are
   illustrated at the center of the diagram. In actual router
   implementations, there may be an arbitrary number of inbound and
   outbound interfaces interconnected by the routing core. The
   components of interest on these interfaces are the traffic
   conditioning components (TC) and the PHB queuing implementations
   [DSARCH]. These are illustrated as residing at the inbound and
   outbound interfaces, respectively. However, this is a conceptual
   representation only and in general, these functions may each be
   distributed across both inbound and outbound interfaces.

   Conceptually, it is helpful to think of TC as a 'front-end' to the
   diff-serv network, which conditions traffic submitted by the
   customer and directs it, through the routing core, to the
   appropriate PHB on the egress interfaces of the boundary router and
   in subsequent hops in the diff-serv network. The combination of
   traffic conditioning (at ingress interfaces) and PHB treatment (at
   egress interfaces) results in a diff-serv service.

4.2 Diff-serv Provisioning Interface

   Diff-serv operating parameters are provisioned through this
   interface. These are primarily PHB and TC configuration parameters.
   The diff-serv admission control component can also verify these
   parameters do not conflict with other configuration parameters and
   the router's physical constraints, as described in subsequent
   sections. The network administrator interacts with the diff-serv
   provisioning interface via one of a number of management protocols
   such as SNMP or COPS [COPS].

4.3 Monitoring

   A monitoring interface enables collection of statistics regarding
   traffic carried at various diff-serv service levels. These
   statistics are important for accounting purposes and for tracking
   compliance to service level agreements (SLAs [DSARCH]) negotiated
   with customers.

   Specifically, counter information on how many packets/bytes were
   transferred in-profile vs. out-of-profile would be useful on a
   customer-by-customer basis. This same information should be provided
   for the courser granularity DSCPs all the way down to the finer
   granularity flow-by-flow profiling where applicable.

4.4 RSVP

   The RSVP component includes standard RSVP protocol processing. It
   enables dynamic configuration of diff-serv traffic conditioning
   components in response to host initiated RSVP signaling and provides
   admission control feedback to the hosts. It interacts with the diff-

Bernet                                                               5

              Requirements of Diff-serv Boundary Routers November 1998


   serv admission control component in order to coordinate signaled
   resource requests with provisioned resource requests, subject to the
   constraints of the TCA and local resources. Note that diff-serv PHBs
   rather than RSVP dictate the actual packet forwarding behaviour in a
   diff-serv boundary router.

   The RSVP component is optional. However, the inclusion of this
   component provides the following benefits for traffic originating
   from quantitative applications (E2E):

   1. Dynamic, closed loop and topology-aware admission control to the
      diff-serv network.
   2. The ability to apply policy in determining which users or
      applications can access resources in the diff-serv network.
   3. Significant reduction in management burden.
   4. The ability to classify IPSec encrypted traffic that would
      otherwise be un-classifiable.

4.5 Traffic Conditioning Agreements and PHB Capacity Tables

   A service level agreement (SLA) [DSARCH] represents the high-level
   agreement between the diff-serv service provider operating the
   boundary router and the customer(s) served by it. The TCA is a
   subset of the SLA, which specifies detailed TC parameters to be
   applied to the customer's traffic. In its simplest form, the TCA is
   a static set of tables. In more sophisticated routers, the TCA may
   be modified dynamically via signaling within the diff-serv network
   and between the diff-serv and customer network.

   We will see that the TCA has two sub-components, a constraint TCA
   and a fine-grain TCA. The former is essential, and is used to
   protect the resources of the diff-serv network. The latter may be
   used to specify value-added functionality offered by the diff-serv
   network. Since one TCA is installed for each customer on each
   ingress interface, there will typically be multiple TCAs on a single
   router.

   The network administrator configures PHB capacity tables based on
   the PHBs supported by the router, it's physical capacity and
   policies that determine the allocation of resources among the
   various PHBs. PHB capacity tables are configured for each interface.
   These will be described in detail in a subsequent section.

5. Traffic Conditioning

   TC is a fundamental component of a diff-serv boundary router. It is
   defined in [DSARCH]]. The following paragraphs describe the TC
   components and their functionality in greater detail.

5.1 Classifiers

   Strictly speaking, classification is not a TC function [DSARCH];
   however, it is a necessary function for any device that treats

Bernet                                                               6

              Requirements of Diff-serv Boundary Routers November 1998


   certain traffic differently from other traffic. The very nature of a
   diff-serv boundary router is that it treats traffic differentially.
   Therefore, classification is the most basic function required from a
   differentiated service boundary router.

   There are differing degrees of classification functionality. At
   minimum, a boundary router must support behaviour-aggregate (BA)
   classification. In addition, routers may support varying degrees of
   multi-field (MF) classification. See definitions of Classifier, BA
   Classifier and MF Classifier in [DSARCH].

   A boundary router that supports MF classification can offer
   significant functionality beyond that which can be offered by a
   boundary router which supports only BA classification. This
   functionality will be discussed further in a subsequent section.

5.2 Meters

   Boundary routers use classifiers to identify classes of traffic
   submitted for transmission through the diff-serv network. Once
   traffic is classified at the input to the router, traffic from each
   class is typically passed to a meter. The meter is used to measure
   the rate at which traffic is being submitted for each class. This
   rate is then compared against a traffic profile, which is part of
   the TCA. Based on the results of the comparison, the meter deems
   particular packets to be conforming to the profile or non-
   conforming. Appropriate policing actions are then applied to out-of-
   profile packets.

5.3 Markers

   Marking is the function of setting the DSCP in packets that are
   submitted to the router. Boundary routers are not required to
   provide marking functionality but may do so for the following
   reasons:

   1. Marking can be used as a form of policing - the TCA between the
      provider and the customer may specify that packets submitted for
      a certain service level (as specified by the DSCP) and which are
      deemed to be non-conforming, may be re-marked to a lower service
      level. In this case, the marker is used for the purpose of re-
      marking. We refer to this as 'policer marking'.
   2. Marking can be provided as a service to customers - customers may
      be unable or unwilling to mark the DSCP in submitted packets. In
      this case, a fine-grain TCA may call for the provider to mark the
      DSCP based on certain MF classification criteria. We refer to
      this service as 'provider marking'.

   Provider marking is a value-added service to the customer and is not
   required in order to provide basic differentiated service. Policer
   marking is used by the diff-serv provider to protect its network
   resources, but - simpler forms of policing (such as dropping) are


Bernet                                                               7

              Requirements of Diff-serv Boundary Routers November 1998


   sufficient to achieve the protection necessary. Therefore, marking
   is not a required function for boundary routers.

5.4 Shapers

   Shapers delay packets passing through the router such that they are
   brought into compliance with a traffic profile. Boundary routers are
   not required to provide shaping functionality, but may do so for the
   following reasons:

   1. Ingress routers may use shaping as a form of policing - when
      submitted traffic is deemed non-conforming, it must be policed to
      protect the diff-serv network. One form of policing is to delay
      submitted traffic in a shaper until it conforms to the profile
      specified in the TCA. We will refer to this as 'policer shaping'.
   2. Egress routers may shape behaviour aggregate traffic before it is
      submitted to a subsequent provider's network. This is a
      preventative measure that avoids policing action in the
      subsequent network. We refer to this form of shaping as 'egress
      shaping'.
   3. Shaping for traffic isolation - Ingress routers may provide per-
      flow (as opposed to per-behaviour aggregate) shaping services as
      a value-add to customers (as specified in a fine-grain TCA). This
      service is costly in terms of processing requirements but may be
      valuable (to low functionality customers) in that it serves to
      protect customer's traffic flows from each other. We refer to
      this form of shaping as 'provider shaping'.

5.5 Droppers

   Droppers are used to discard non-conforming packets. This is the
   simplest form of policing that may be supported by ingress routers.

5.6 Basic Configurations of Traffic Conditioning Components

   The following sections illustrate various configurations of TC
   components on ingress interfaces. These components determine the
   PHBs that will be applied to subsets of submitted traffic after they
   are routed to the appropriate egress interfaces. PHBs and egress
   interfaces are not illustrated.

   DISCLAIMER: Note that these illustrations are provided for
   clarification of concepts and are not intended to depict specific
   implementations or implementation requirements.

   At minimum, an ingress router must police submitted traffic to the
   terms of the constraint TCA. Such a TCA may be represented as
   follows:

   DSCP         Average Rate    Service Level
   ------------------------------------------
   000001       10 Kbps         Best
   000010       100 Kbps        Better

Bernet                                                               8

              Requirements of Diff-serv Boundary Routers November 1998



   This TCA indicates that traffic submitted with the DSCP 000001 will
   be accepted at a rate up to 10 Kbps and will be allotted the 'best'
   service level. Traffic submitted with DSCP 000010 will be accepted
   at a rate up to 100 Kbps and will be allotted the 'better' service
   level. While the TCA offers particular service levels, the
   underlying mechanism by which the service is provided is the PHB
   that is applied to the traffic at the egress interface to which it
   is routed. Hence the 'best' and 'better' services described each
   rely on an underlying PHB.

   The following configuration of TC components can be used to enforce
   the above TCA:

                    -------  -------
                    |     |  |     |
                 |->|     |->|     |-> Best traffic
        -------  |  |     |  |     |
        |     |  |  -------  -------
    --->|     |->|
        |     |  |  -------  -------
        -------  |  |     |  |     |
       BA Class. |->|     |->|     |-> Better traffic
                    |     |  |     |
                    -------  -------
                    Meters   Policers
                            (Re-markers,
                           Shapers or Droppers

   The BA classifier is used to separate traffic based on the diff-serv
   service level requested (as indicated by the DSCP in each submitted
   packet). Meters then determine whether the traffic submitted for
   each service level conforms to the corresponding average rate
   specified in the TCA. The policers handle non-conforming packets
   either by re-marking them for a lower service-level, delaying them
   in a shaper or dropping them.

   This configuration suffers certain limitations. Since it uses only a
   BA classifier, it is able to separate traffic based only on the DSCP
   in submitted packets. If traffic from multiple customers is
   submitted on the same interface, this configuration of TC components
   will be unable to separate traffic by customer. Since TCAs are
   specified on a per-customer basis, TC components will be unable to
   select the appropriate TCA to be applied.

   Furthermore, certain services may be offered only between the
   ingress boundary router and a specific egress point from the diff-
   serv network [DSFWK]. For such services, the TCA would include an
   egress point qualifier and TC components would be required to
   classify and to police based on egress point as well as DSCP. The
   configuration illustrated is unable to do so.



Bernet                                                               9

              Requirements of Diff-serv Boundary Routers November 1998


   MF classifiers can be incorporated to overcome the limitations
   identified. For example, in the following configuration, an MF
   classifier is used to separate traffic according to customer, before
   it is submitted for BA classification:

                            -------  -------
                            |     |  |     |
                         |->|     |->|     |-> Customer A, Best
                 ------- |  |     |  |     |
                 |     | |  -------  -------
              |->|     |-|
              |  |     | |  -------  -------
              |  ------- |  |     |  |     |
              | BA Class.|->|     |->|     |-> Customer A, Better
      ------- |             |     |  |     |
      |     | |             -------  -------
    ->|     |-|
      |     | |             -------  -------
      ------- |             |     |  |     |
     MF Class.|          |->|     |->|     |-> Customer B, Best
              |  ------- |  |     |  |     |
              |  |     | |  -------  -------
              |->|     |-|
                 |     | |  -------  -------
                 ------- |  |     |  |     |
                BA Class.|->|     |->|     |-> Customer B, Better
                            |     |  |     |
                            -------  -------
                            Meters   Policers

   Similar configurations could be used to separate traffic based on
   egress point or other criteria dictated by the constraint TCA. MF
   classifiers are also required to provide value-added services as
   described in the following paragraphs.

5.7 Traffic Conditioning Configurations Supporting Value-Added Services

   More complex TC configurations can enable value-added services such
   as provider marking and provider shaping. The essence of these
   services is that the customer relies on the provider to apply per-
   flow processing to the customer's traffic. This requires the
   provider to classify beyond the minimum level of granularity
   necessary to protect the diff-serv network's resources. Such
   additional functionality is specified in a fine-grain TCA. The
   following configuration of TC components supports value-added
   services:

                -------  -------                -------  -------
                |     |  |     |                |     |  |     | Best
             |->|     |->|     |->|          |->|     |->|     |->
     ------- |  |     |  |     |  |  ------- |  |     |  |     |
     |     | |  -------  -------  |  |     | |  -------  -------
   ->|     |-|  Marker   Policer  |->|     |-|

Bernet                                                              10

              Requirements of Diff-serv Boundary Routers November 1998


     |     | |  -------  -------  |  |     | |  -------  -------
     ------- |  |     |  |     |  |  ------- |  |     |  |     | Better
    MF Class.|->|     |->|     |->| BA Class.|->|     |->|     |->
             |  |     |  |     |  |             |     |  |     |
             |  -------  -------  |             -------  -------
             |  Marker   Policer  |             Meters   Policers
             |  -------  -------  |                     (Re-markers,
             |  |     |  |     |  |                      Shapers or
             |->|     |->|     |->|                      Droppers)
             |  |     |  |     |  |
             |  -------  -------  |
             |  Marker   Policer  |
             |  -------  -------  |
             |  |     |  |     |  |
             |->|     |->|     |->|
             |  |     |  |     |  |
             |  -------  -------  |
             |  Marker   Policer  |
             |     .        .     |
             |     .        .     |
             |     .        .     |
             V     V        V     V

   In this configuration, traffic is first directed to an MF classifier
   which classifies traffic based on miscellaneous classification
   criteria, to a granularity sufficient to identify  individual
   customer flows. Each customer flow can then be marked for a specific
   DSCP and/or policed independently (a metering stage is implied).
   Typically, in this configuration, multiple customer flows would be
   marked with the same DSCP. In this example, all customer flows are
   aggregated into one of two DSCPs - that specifying the 'best'
   service or that specifying the 'better' service. Following the
   marking, flows are policed individually such that they are protected
   from each other and that the total traffic submitted for each DSCP
   does not exceed that specified by the constraint TCA.

   This configuration can be considered to consist of two logical
   halves; a front-end which provides per-flow services to the customer
   (MF classifier, per-flow markers and shapers) and a back-end which
   enforces the terms of the constraint TCA (BA classifier, per service
   level meters and policers). Notice that the back-end is equivalent
   to the minimal configuration illustrated previously.

6. Configuration Information Required at Boundary Routers

   This section describes the configuration information required at
   boundary routers. This information falls into the following general
   categories:

   1. PHB configuration.
   2. Traffic conditioning configuration.
   3. Miscellaneous configuration.


Bernet                                                              11

              Requirements of Diff-serv Boundary Routers November 1998


   DISCLAIMER: In the following sections, we use tables to represent
   specific information that is necessary for the configuration of
   boundary routers. These tables are intended to describe the
   structure of required configuration information but not to dictate
   particular protocol formats, nor to dictate specific implementation
   mechanisms. For detailed protocol formats see appendices to this
   draft and [COPS].

6.1 PHB Configuration Information

   Diff-serv routers implement PHBs that are used to forward traffic of
   different service levels with differing behaviour. PHBs are
   generally implemented via queues and schedulers that reside at the
   router's egress interfaces. There may be multiple configuration
   parameters required to configure PHBs. At minimum, PHB configuration
   must:

   1. Enable or disable specific PHBs.
   2. Provide the quantitative parameters associated with the PHB (e.g.
      relative weights for WFQ based PHBs).
   3. Specify the total capacity admissible to each PHB on each egress
      interface. Capacity should be expressed in the same terms as the
      traffic profile [DSARCH] that applies to the PHB. This capacity
      will generally consider both physical interface capacities as
      well as policies. For example, PHBs which are implemented as
      strict priority queues should include limits on the volume of
      traffic which can be directed to the PHB in order to avoid
      starvation of traffic directed to other PHBs on the same
      interface.
   4. In addition, network administrators must specify policies that
      indicate how the admissible capacity of qualitative PHBs (see
      [DSFWK] for a description of qualitative PHBs) on egress
      interfaces is reflected to each ingress interface. This is
      required for the purpose of applying admission control, and will
      be discussed further in the subsequent section on admission
      control.

   The capacities in 3 and 4 are specified in the form of a PHB
   capacity table. This table specifies capacities for quantitative
   PHBs on each egress interface and capacity for qualitative PHBs on
   each ingress interface.

   Note that certain PHB configuration parameters are required that are
   specific to each PHB. These are beyond the scope of this draft and
   should be addressed in detail in PHB specific drafts.
6.2 Traffic Conditioning Configuration Information

   As TC comprises a major function of diff-serv boundary routers, much
   of the required configuration information will be related to these
   components.

   For the purpose of this discussion, we consider TC configuration
   information to apply independently to each of the boundary router's

Bernet                                                              12

              Requirements of Diff-serv Boundary Routers November 1998


   ingress interfaces. The majority of TC configuration information
   required can be expressed via the TCA. The TCA is a per-customer
   entity. In cases in which an ingress interface is dedicated to a
   single customer, a single TCA is configured on each interface. On
   the other hand, in cases in which multiple customers are served via
   a single interface, multiple TCAs will be installed on the
   interface. In these cases, it is necessary to configure criteria by
   which the boundary router can classify submitted traffic to the
   customer from which it is submitted and the corresponding TCA. This
   requires configuration of 'customer classification information'
   (CCI).

6.2.1 Elements of Traffic Conditioning Configuration Information

   Before proceeding to describe the detailed configuration
   information, we define two elements of configuration information
   that will be referred to throughout the following paragraphs. These
   are:

   1. Filters - these specify the classification criteria which
      classifiers use to classify submitted packets. BA filters are
      quite simple, specifying only a six-bit DSCP. MF filters may be
      arbitrarily complex, specifying multiple classification fields
      and corresponding masks.
   2. Profiles - [DSARCH] defines a traffic profile as "a description
      of the temporal properties of a traffic stream such as rate and
      burst size". Though profiles may take many forms, a typical
      profile would consist of a set of token bucket parameters. These
      include expected average traffic rate, peak rate and the maximum
      burst size that can be expected at the peak rate. Individual PHB
      specifications (in PHB specific drafts) should describe the form
      of the profile which applies to each PHB.

6.2.2 Customer Classification Information

   This information enables a boundary router to correlate submitted
   traffic to a particular TCA for the purpose of applying TC. Customer
   classification information can be conveyed via a table of the
   following format:

   CCI          TCA
   ---          ---
   Filter01     TCA01
   Filter02

   Filter03     TCA02
   Filter04
   Filter05

   Filter06     TCA03

   In this table, the first column lists a set of filters that should
   be used as classification criteria to determine the customer from

Bernet                                                              13

              Requirements of Diff-serv Boundary Routers November 1998


   which a packet originates. The second column specifies the TCA that
   should be applied to traffic from that customer. In general, there
   may be multiple filters required to define a single customer's
   traffic. Typically, CCI filters will specify source subnet addresses
   as classification criteria.

   In the common case that an interface is dedicated to a customer, the
   table above degenerates to the following form:

   CCI          TCA
   ---          ---
    *           TCA01

   In this example, all traffic arriving on the interface is assumed to
   arrive from a single customer and to be subjected to TCA01.

6.2.3 The Traffic Conditioning Agreement (TCA)

   The TCA is a device specific result of the SLA negotiated (either
   statically or dynamically) between the diff-serv provider and the
   customer. There are two subsets of the TCA - the constraint TCA and
   the fine-grain TCA. The constraint TCA serves to protect the
   provider's resources at each diff-serv service level. This part of
   the TCA is required. The fine-grain TCA defines per-flow value-added
   functionality that the provider may offer to the customer. This part
   of the TCA is not required for the purpose of providing basic diff-
   serv service. Fine-grain TCAs are likely to be used only near the
   periphery of the network where the provider offers service to a stub
   network containing hosts. It is unlikely that fine-grain TCAs will
   be used at boundaries between providers (where enforcement of
   aggregate, per-service level resource usage is the primary concern).

6.2.3.1 The Constraint TCA

   Recall that the purpose of the constraint TCA is to protect
   resources in the provider's network by policing submitted traffic to
   the terms of the agreement between the provider and the customer. In
   its simplest form, the agreement offers to carry traffic at the
   service level requested by the customer (via the DSCP) up to a
   certain traffic profile.

   When quantitative services are offered, the agreement is slightly
   more complex. In this case, the agreement may be constrained by
   traffic egress point. For example, the provider might agree to carry
   traffic at a certain quantitative service level, up to a certain
   traffic profile, but only if the traffic is destined to a specific
   egress point. If the customer desires delivery at the same service
   level to another egress point, then an additional profile must be
   specified for that egress point. In this example, we effectively
   specify multiple 'service instances' at the same service level.

   When only qualitative services are offered, we see that it is
   sufficient to police a customer's traffic based only on the service

Bernet                                                              14

              Requirements of Diff-serv Boundary Routers November 1998


   level at which it will be carried. However, when quantitative
   services are offered, it may be necessary to police the customer's
   traffic separately for each 'service instance'. We will use the term
   'service instance' from here on to refer to instances of service
   which must be separately policed in order to protect the provider's
   network.

   The constraint TCA can be represented as a table having the
   following format:

   BA Filter    PHB     MF Filter       Profile     Disposition
   ---------    ---     ---------       -------     -----------
   Filter01     EF      EgressFilter01  Profile01   Discard

   Filter01     EF      EgressFilter02  Profile02   Discard

   Filter02     AFxy        *           Profile03   Re-mark to 001001

   Filter03     AFpq        *           Profile04   Shape to profile

   Each row in this table corresponds to a service instance provided to
   the customer. Note that the first two rows describe two service
   instances, at the same service level.

   The column titled 'BA Filter' specifies a DSCP. This is the
   classification criteria that should be used to determine the PHB
   (and the corresponding service level) that should be allotted to a
   submitted packet.

   The column titled 'PHB' specifies the PHB (and the corresponding
   service level) that should be applied to the submitted packet. As
   such, the first two columns effectively specify a mapping of DSCP to
   PHB.

   The column titled 'MF Filter' is relevant when the PHB corresponds
   to a quantitative service. In this case, it may be insufficient to
   police traffic based on service level alone because there may be
   multiple service instances at the same level. In this example, there
   are two instances of service at the same level, each to a different
   egress point. The additional classification criteria in this column
   specify how the provider should separate traffic for the two service
   instances.

   The column titled 'Profile' specifies the configuration of meters
   that are used to determine the conformance of traffic submitted for
   each service instance. All packets that meters find to be conforming
   to the specified profile are allotted the treatment specified by the
   PHBs.

   The column titled 'Disposition' specifies the disposition of packets
   that are found to be non-conforming to the metered profile. In this
   simple example, these packets are collectively discarded, demoted or
   shaped (as forms of policing). In more complex examples, multiple

Bernet                                                              15

              Requirements of Diff-serv Boundary Routers November 1998


   levels of non-conformance may be specified. In these cases,
   different dispositions may be specified for each degree of non-
   conformance.

6.2.3.2 Fine-Grain TCA

   Recall that the fine-grain TCA is used to provide value-add to the
   customer. Specifically, it enables the provider to process the
   customer's traffic based on classification criteria beyond those
   that are required to protect the provider's resources. Basically,
   the fine-grain TCAs are applied first to police and mark a
   customer's flows and then, based on the resulting marking, the
   appropriate aggregate constraint TCA will be applied as described
   above.

   At a minimum, the fine-grain TCA might be used to invoke provider
   marking of the customer's traffic. In order to mark customer's
   traffic differentially (and usefully), the provider must classify
   the traffic based on MF classification criteria such as source or
   destination IP addresses or ports. For example, MF filters may be
   defined to cause all traffic from IP subnet 2.3.4.0 to be marked
   with the DSCP 001001. In this example, traffic from multiple
   conversations, on multiple hosts, would be collectively marked with
   the specified DSCP.

   The fine-grain TCA could be used to specify additional
   functionality, requiring even finer-grain classification. For
   example, MF filters might be defined to separate traffic originating
   from each individual conversation (microflow [DSARCH]) in the
   customer's network. Traffic corresponding to multiple conversations
   of the same type may still be marked identically, however, the
   finer-grain classification would allow them to be policed or shaped
   separately. The fine grain TCA can be represented as a table having
   the following format:

   MF Filter    DSCP Mark       Profile         Disposition
   ---------    ---------       -------         -----------
   Filter01     001001          Profile01       Remark to DSCP 001000
   Filter02

   Filter03     001011          Profile02       Shape to profile

   Filter04     100100          Profile03       Discard

   Filter05     100100          Profile04       Discard

   In this example, the first entry specifies that two customer traffic
   flows should be marked for DSCP 001001. These flows together should
   be metered to Profile01. Packets from either set that do not conform
   to Profile01 should be remarked to DSCP 001000.

   The second entry specifies a third customer traffic flow. All
   packets belonging to this flow should be marked for DSCP 001011.

Bernet                                                              16

              Requirements of Diff-serv Boundary Routers November 1998


   These should be metered to Profile02. Packets belonging to this flow
   that do not conform to Profile02 should be delayed in a shaper until
   they do.

   The third and fourth entries specify two customer traffic flows that
   should be marked for DSCP 100100. Though packets belonging to both
   flows are marked for the same DSCP, they should be metered
   independently using Profile03 and Profile04. This protects these
   traffic flows from each other by preventing excess traffic from one
   flow compromising the treatment of traffic from the other flow.

6.3 Relationship Among the CCI, Constraint TCA and Fine-Grain TCA

   We've presented three types of tables that collectively specify the
   configuration of TC components. These are:

   1. The customer classification table
   2. The constraint TCA
   3. The fine-grain TCA

   These are related to each other, as illustrated in the following
   diagram:










                             Fine-Grain              Constraint
                                part                    part

                                                 ------------------
                                                 |TCA0 -------    |
                                                 |     |SI 0 |    |
              CCI                                |     -------    |
             Table    |------------------------->|     |SI 1 |    |
                      |                          |     -------    |
                      |                          ------------------
                      |    ----------------------------------------
            -------   |    |  -------     TCA1                    |
            |CU 0 |---|    |  |CF 0 | |                -------    |
            -------        |  ------- |--------------->|SI 2 |    |
        --> |CU 1 |------->|  |CF 1 | |                -------    |
            -------        |  -------           |----->|SI 3 |    |
            |CU 2 |---|    |  |CF 2 | |---------|      -------    |
            -------   |    |  -------             |--->|SI 4 |    |
                      |    |  |CF 3 | |           |    -------    |
                      |    |  ------- |           |               |
                      |    |  |CF 4 | |           |               |

Bernet                                                              17

              Requirements of Diff-serv Boundary Routers November 1998


                      |    |  ------- |-----------|               |
                      |    |  |CF 5 | |                           |
                      |    |  ------- |                           |
                      |    |  |CF 6 | |                           |
                      |    |  -------                             |
                      |    ----------------------------------------
                      |                          ------------------
                      |                          |TCA2 -------    |
                      |                          |     |SI 5 |    |
                      |                          |     -------    |
                      |------------------------->|     |SI 6 |    |
                                                 |     -------    |
                                                 ------------------

   In this general example, three customers are served by the TC
   components on a single physical interface of a boundary router.
   Traffic received on the interface is separated according to the
   customer from which it originates, based on customer classification
   information (CU0, CU1 and CU2) in the CCI table.

   Customer 0 (CU0) implements all marking and fine-grain policing in
   the customer network. Therefore, no fine-grain TCA is necessary in
   the provider's network. The provider is required to apply only the
   constraint TCA. The constraint TCA for customer 0 defines two
   different service instances (SI0, SI1).

   Customer 1 (CU2) relies on the provider to apply certain fine-grain
   functionality on its behalf. A fine-grain TCA defines seven distinct
   sets of customer traffic each of which require special treatment in
   the boundary router. Such treatment may include marking, shaping,
   etc.

   Following the fine-grain TCA, the constraint TCA defines the
   aggregation of the fine-grain sets of customer traffic (CF0-CF6)
   into a smaller number of service instances. After the fine-grain TCA
   is applied, each packet is submitted to the constraint TCA with a
   specific DSCP mark. This DSCP mark is compared against the BA filter
   (and additional packet fields may be compared against the egress
   filter) in the constraint TCA, to define which service instance
   applies (SI2, SI3 or SI4).

   From the diagram, the first two customer traffic flows (CF0-CF1) are
   marked with the same DSCP, directing them to the same service
   instance in the constraint TCA (SI2). The third customer traffic
   flow (CF2) is marked with a DSCP that may or may not be the same as
   the previous flows. If it is the same, then this traffic is directed
   to a different service instance based on egress filter.

   The fourth through seventh customer traffic flows (CF3-CF6) are
   marked with the same DSCP. Again, this may or may not be the same
   DSCP as previous sets. Regardless, these are collectively directed
   to yet another service instance (SI3).


Bernet                                                              18

              Requirements of Diff-serv Boundary Routers November 1998


   Finally, traffic from CU3 is similar to that originating from CU0 in
   that it requires no fine-grain treatment at the boundary router. It
   is subjected directly to the corresponding constraint TCA where it
   is classified to a particular service instance (based on the DSCP
   and the classification criteria in the BA filter entries of the
   constraint TCA, and possibly based on egress filters as well).

6.4 Additional Configuration Information

   A variety of additional miscellaneous configuration information is
   required for any router. Examples include routing information, media
   support, etc. Such information is beyond the scope of this draft.

7. Configuration Mechanisms

   The following sections describe the mechanisms by which the above
   configuration information is installed in the boundary router. It is
   useful to consider a hierarchy of configuration information,
   starting with basic hardware configuration, which is very static and
   ending with the configuration of entries in the fine-grain TCA,
   which is quite dynamic.

7.1 Installing PHB Configuration Information

   PHBs are configured on each egress interface. Routers will generally
   provide support for limited groups of PHBs. Supported PHBs vary
   depending on media type, hardware support and software algorithms.
   Enabling a set of PHBs on each egress interface can be considered
   part of the router's basic hardware configuration. This aspect of
   PHB configuration is therefore very static and is likely to be
   applied as part of the router installation process.

   In addition to enabling PHBs, policies must be configured to
   determine how these PHBs make use of the interface capacity (via the
   PHB capacity table). Allocating interface capacity to various PHBs
   can be considered part of the diff-serv network provisioning. It
   should be possible to provision the network from a central
   management console. Therefore, it must be possible to configure the
   PHB capacity table remotely. This facility can be provided via
   telnet and CLI, SNMP, LDAP or COPS [COPS]. The mechanism used must
   be secure. In early deployments of diff-serv networks, re-
   provisioning is expected to occur infrequently and to require manual
   intervention. In the long term, this process will become more
   dynamic, requiring automated protocols.

7.2 Installing the Constraint TCA

   The constraint TCA effectively specifies the resources that the
   provider is offering to each customer in the diff-serv network. At
   the boundary router, it determines the allocation of resources
   provisioned at PHB configuration time, among the customers served by
   the router's ingress interfaces.


Bernet                                                              19

              Requirements of Diff-serv Boundary Routers November 1998


   Provider and customer must agree upon this part of the TCA since it
   commits resources on the one hand and incurs charges on the other
   hand. Since this part of the TCA requires negotiation between the
   two parties, it tends to be relatively static (yet more dynamic than
   the PHB configuration associated with network provisioning).
   Generally, configuration of constraint TCAs on a customer by
   customer basis occurs after the network has been provisioned via PHB
   configuration. However, to some degree these processes will be
   iterative. This, at certain times, changes in demand will require
   configuration of TCAs that cannot be installed without modifications
   to the basic network provisioning and PHB configuration.

   Typically, human agents for the provider and customer would
   negotiate a constraint TCA as part of an SLA. Following these
   negotiations, an administrator of the provider's network would
   configure the constraint TCA in the boundary router. This process
   would typically occur quite infrequently (for example, monthly).

   In the long term, this process is likely to become more dynamic and
   more automated. Ultimately, bandwidth brokers [BB] representing the
   provider's network and the customer's network will automatically and
   periodically re-negotiate the constraint TCA, based on such triggers
   as changes in usage patterns. Bandwidth brokers will then instruct
   policy servers to install the updated configuration information.

   In the more static example, network administrators will likely
   install constraint TCAs into the boundary router via a management
   console. A user management interface at the console may use any of a
   number of protocols to communicate with the router, such as telnet
   and CLI, SNMP, LDAP, COPS, etc.

   As configuration of the constraint TCA becomes more automated and
   more dynamic, inter-machine protocols will be used. Since COPS is
   targeted at dynamic QoS configuration, it is ideally suited for this
   purpose. By providing COPS interfaces for diff-serv configuration,
   routers will be able to support both near-in static configuration of
   diff-serv parameters as well as long-term dynamic configuration.
   Appendix A shows specifically how the constraint TCA is conveyed
   using the COPS for diff-serv protocol elements defined in [COPS].

7.3 Installing the Fine-Grain TCA

   The provisioning mechanisms used to install the constraint TCA may
   also be used to install the fine-grain TCA. However, requirements
   surrounding configuration of the fine-grain TCA differ significantly
   from those surrounding configuration of the constraint TCA. These
   differences argue for use of a different mechanism, as described in
   the following paragraphs.

   First of all, configuration of the fine grain TCA is likely to be
   far more dynamic than that of the constraint TCA. Recall that the
   constraint TCA describes the aggregate requirements of the customer
   from the provider. Such aggregate requirements are relatively

Bernet                                                              20

              Requirements of Diff-serv Boundary Routers November 1998


   static. By comparison, the fine-grain TCA describes fine-grain
   servicing of individual customer flows, within the aggregate limits
   imposed by the constraint TCA. The requirements of such fine-grain
   service are likely to change quite frequently.

   For example, the customer may be using provider marking to direct
   traffic from certain IP addresses to different service instances, or
   to direct specific application traffic (identified by IP port) to
   different service instances. In these cases, changes in IP address
   assignments internal to the customer's network, or changes in ports
   used by applications will require frequent changes to the fine-grain
   TCA.

   Second, unlike the constraint TCA (which has financial consequences)
   the fine-grain TCA dictates only how the aggregate resources
   available to the customer are shared among the various customer
   flows. Thus, changes to the fine-grain TCA generally do not have
   financial consequences. These changes can more readily be automated.

   In conclusion, it is appropriate to use an automated mechanism to
   configure the fine-grain TCA, which supports frequent customer
   initiated changes with rapid response. To this end, boundary routers
   should support access to the fine-grain TCA via COPS.

   Appendix B shows specifically how the fine-grain TCA is conveyed
   using the COPS for diff-serv protocol elements defined in [COPS].

8. Admission Control

   The configuration information discussed is interrelated by admission
   control. Admission control is the process of approving or denying
   specific configuration requests subject to the constraints of
   previous configuration. Requests to configure PHBs and associated
   capacities on each egress interface are admitted or rejected based
   on the basic hardware resources available on the egress interface.
   PHB capacities at egress interfaces dictate the amount of traffic
   that can be directed to each PHB at ingress interfaces. Therefore,
   requests to configure constraint TCAs at ingress interfaces are
   admitted or rejected subject to PHB configuration. Requests to
   configure fine-grain TCAs are in turn admitted or rejected subject
   to the constraint TCAs that have been installed. In this section we
   discuss these interdependencies.

8.1 Reflection of PHB Configuration at Ingress Interfaces

   PHBs are configured at egress interfaces. TCAs are configured at
   ingress interfaces. Since each service instance in a TCA consumes
   resources configured at egress interfaces, it is necessary to
   understand how these resources are reflected at the ingress
   interfaces.

   For quantitative services there is a well-defined relationship
   between capacities specified on PHBs at egress interfaces (in the

Bernet                                                              21

              Requirements of Diff-serv Boundary Routers November 1998


   PHB capacity table) and service instances configured at TCAs on
   ingress interfaces. This is because each quantitative service
   instance in a TCA specifies an egress filter. The router uses
   routing information to determine the egress interface to which
   traffic classified for a particular egress filter will be directed.
   Therefore, as quantitative service instances are configured at
   ingress interfaces, the appropriate amount of resources can be
   debited on the appropriate PHBs on egress interfaces. In the case
   that insufficient resources are available at an egress interface,
   the service instance must be rejected.

   For qualitative services however, there is no deterministic
   relationship between capacities at egress interfaces and service
   instances at ingress interfaces. Therefore, the network
   administrator must apply policy, (based on expected traffic routes
   within the router) to impose per service level capacity constraints
   (for qualitative services) at ingress interfaces.

   Such policy is configured as part of PHB configuration, at the time
   the network is provisioned. It may be modified subsequently as
   constraint TCAs are negotiated with customers.

   This policy is expressed by specifying limits on the traffic
   profiles admissible at each ingress interface for each qualitative
   PHB supported (in the PHB capacity table). Conservative policies
   would divide the resources available at the most constrained egress
   interface, among all ingress interfaces. Resources may be divided
   equally (if the network administrator has no knowledge of likely
   traffic patterns in the network), or may be divided unequally, based
   on expected traffic patterns. Liberal policies would over-subscribe
   the resources available at egress interfaces by allowing each
   ingress interface to admit more than its fraction of the egress
   capacity. In the case of liberal provisioning care must be exercised
   to prevent undesirable interactions among PHBs on oversubscribed
   egress interfaces.

8.2 Admitting the Constraint TCA

   The constraint TCA must be admitted subject to the resources made
   available by PHB configuration as specified in the PHB capacity
   table. At the time this part of the TCA is installed, the router is
   expected to apply admission control as follows:

   1. All PHBs specified in the constraint TCA must be supported by the
      router and must have been previously configured.
   2. Quantitative service instances consume resources for specific
      PHBs on specific egress interfaces (as determined by egress
      filters and routing information). The sum of profiles for all
      service instances consuming resources on a particular egress
      interface must not exceed the configured limits for the
      corresponding PHB in the PHB capacity table on the appropriate
      egress interface.


Bernet                                                              22

              Requirements of Diff-serv Boundary Routers November 1998


   3. Profiles associated with qualitative service instances (that do
      not specify egress filters) are also subject to admission
      control. These cannot be deterministically related to resources
      configured at egress interfaces. Therefore, the sum of profiles
      for all qualitative service instances must not exceed the
      configured limits for the corresponding PHBs in the PHB capacity
      table on the corresponding ingress interface.

   When COPS is used to configure the router, this process becomes
   somewhat more automated. The policy server (PDP) can directly verify
   that the constraint TCAs are supported by the device. This is
   possible given the device accurately describes its capabilities and
   its available resources per interface in its initial configuration
   request to the PDP.

8.3 Admitting the Fine-Grain TCA

   The fine-grain TCA may cause multiple sets of customer traffic to be
   marked for a specific DSCP and a specific service instance in the
   constraint TCA. The constraint TCA specifies a profile that limits
   the aggregate amount of traffic that can be serviced for each
   service instance. The sum of profiles in the fine-grain TCA, which
   are applied to traffic destined for the same service instance,
   should be less than the aggregate profile in the constraint TCA for
   that service instance. In the case of qualitative services, the
   following steps can easily verify this condition:

   1. For each DSCP that the fine-grain TCA marks, sum the profiles for
      all sets of customer traffic to be marked with the DSCP.
   2. Find the service instance in the constraint TCA that corresponds
      to this DSCP, as indicated by the BA filter in the constraint
      TCA. For qualitative services there will be only a single service
      instance specified for each DSCP.
   3. The profile from the constraint TCA should be greater or equal to
      the sum of profiles for the corresponding DSCP in the fine-grain
      TCA.

   In the case of quantitative services, verification is slightly more
   complicated as it must account for egress point as well as service
   level indicated by the DSCP. In this case, there may be multiple
   service instances in the constraint TCA, for the same DSCP.

   Again, when COPS is used to configure the router, this process
   becomes somewhat more automated. The policy server (PDP) can
   directly verify what fine-grain TCAs are supported by the device.
   This is possible given the device accurately describes its
   capabilities in terms of MF classification and out-of-profile
   disposition in its initial configuration request to the PDP.

8.4 Summing Profiles

   The previous paragraphs on admission control mention the summing of
   profiles for each PHB. Different types of profiles will generally be

Bernet                                                              23

              Requirements of Diff-serv Boundary Routers November 1998


   subject to different summation rules. These should be described in
   the draft defining the PHB.

9. Support for RSVP Admission Control

9.1 Overview of RSVP and Diff-serv Interoperation

   As described in [E2E], diff-serv networks can be used to provide
   end-to-end QoS across large transit networks by supporting RSVP
   admission control at boundaries. This approach is of particular
   interest for quantitative applications [DSFWK], for which RSVP
   signaling is practical.

   To this end, Intserv service-types that are used by RSVP are mapped
   to specific diff-serv PHBs [MAPPING]. The concatenation of these
   PHBs along paths through diff-serv networks, combined with
   appropriate admission control at the boundaries will enable diff-
   serv services that can reasonably extend Intserv style QoS. Routers
   in diff-serv networks should support these PHBs. Boundary routers
   should also provide RSVP signaling for admission to diff-serv
   networks, as described below.

9.2 Example of Admission Control to a Diff-serv Network

   Consider a diff-serv service that offers very low latency such as
   would be suitable for IP telephony. The EF PHB [EF] can provide such
   a service. Assume that a customer uses the diff-serv provider
   network to interconnect two customer networks. The customer has an
   SLA in place with the provider at each of the two boundaries. A
   service instance in each TCA offers 100 Kbps of low latency service
   to the peer attachment point. Now consider that the customer uses
   this service to carry IP telephony calls, each requiring a 16 Kbps
   flow.

   In order to obtain the low latency service, the customer (either by
   direct marking in the host or via provider marking) must mark IP
   telephony traffic for the appropriate diff-serv service level. At
   the same time, it is in the customer's interest to constrain the
   number of marked flows to six or fewer. A seventh flow will cause
   the customer to violate the TCA in place with the diff-serv
   provider. Provider policing may then arbitrarily compromise any
   traffic marked for the low latency service.

   Simple RSVP based admission control from the boundary router can
   prevent such over-subscription of the TCA by notifying the offending
   host that the seventh flow has failed admission control. In
   response, a properly behaving marking host will not mark traffic on
   the seventh flow for the low latency service level (as described in
   [E2E]). As a result, the six flows in place remain protected. Of
   course, the same mechanisms apply to applications other than IP
   telephony, for example - streaming video applications).



Bernet                                                              24

              Requirements of Diff-serv Boundary Routers November 1998


   Additional benefits of such admission control are described in
   detail in [E2E].

9.3 Implementing RSVP Admission Control in Boundary Routers

   Support for such admission control in boundary routers requires
   implementation of a subset of RSVP. In particular, RSVP signaling is
   required. The RSVP MF classification and scheduling mechanisms are
   not necessarily required. The local admission control functionality
   of standard RSVP routers must be modified as described in the
   following paragraph.

   When a reservation request (RESV) arrives at a standard RSVP router,
   the router must verify admissibility of the reservation on its
   sending interface by querying traffic control for the interface. If
   the resources specified in the Intserv flowspec of the RESV message
   can be accommodated at the Intserv service level specified, then the
   reservation request is admitted, by allowing the RESV message to
   pass on to the sender. If the resources cannot be accommodated, then
   the request is rejected by blocking the RESV and returning an error
   message.

   In a diff-serv boundary router, a similar process is used. Upon
   receiving a RESV from a receiver at a remote customer network, the
   boundary router must compare the request against the constraint TCA
   that is in place. The boundary router does so as follows:

   1. First, the boundary router must find the quantitative service
      instances in the constraint TCA which correspond to the diff-serv
      egress point from which the reservation request originated. It
      uses routing information to do so.
   2. Of the matching entries, the boundary router must find the single
      entry which applies to the PHB mark which maps to the Intserv
      service type specified in the reservation request (see
      [MAPPING]).
   3. The boundary router must then compare the resources requested in
      the Intserv flowspec against the profile permitted by the TCA
      entry.

   If the resources requested are less than the profile permitted by
   the constraint TCA entry, then the reservation can be admitted and
   the RESV message should be allowed to continue flowing upstream
   towards the sender in the customer's network. If the resources
   requested exceed those allowable by the profile in the constraint
   TCA entry, the boundary router should reject the RESV message by
   blocking it and by sending a rejection message towards the receiver.

   The boundary router must maintain an accounting of resources
   allocated to admitted flows at each service level (and if necessary,
   to each egress subnet). This admission control procedure described
   is based on resource availability only. Boundary routers may also
   apply policy based admission control just as standard RSVP routers
   do.

Bernet                                                              25

              Requirements of Diff-serv Boundary Routers November 1998



9.3.1 RSVP Reservations Expressed as Fine-Grain TCA Entries

   Note that acceptance of a reservation request can be considered to
   have installed a virtual entry in the fine-grain TCA. The same
   admission control process applies as would apply when actual entries
   are configured in the fine grain TCA.

   The virtual entry would not necessarily call for provider marking or
   policing (though it may, especially in the case of hosts that
   support RSVP signaling but are not able to mark packets or shape
   traffic). The entry would specify a quantitative PHB (all PHBs which
   map to Intserv service types are quantitative). The MF filter for
   the entry would consist of a fully specified 5-tuple corresponding
   to the source and destination IP ports and addresses, as well as the
   IP protocol specified in the RSVP filterspec. The profile would
   correspond to that specified in the RSVP flowspec.

   Since COPS supports RSVP messaging as well, a PDP can be used to
   accurately provision and configure the necessary fine-grain TCAs.
   The process involves a single PDP that is handling COPS messaging
   for RSVP as well as COPS for DiffServ. When a COPS signaled RSVP
   request arrives at the PDP, the PDP can install the appropriate
   fine-grain TCA directly utilizing the homogenous management
   infrastructure.

9.3.2 Modifying Marked DSCPs

   To this point, we have assumed a well-known mapping of Intserv
   service type to PHB and DSCP. However, it may be desirable to
   override the well-known mapping in certain scenarios. Routers may do
   so by including a DCLASS object [MAPPING] in the RESV message
   forwarded to the sender of the data stream. This mechanism is
   analogous to use of the TCLASS object as described in [802MAP].

9.3.3 RSVP and IP Security

   When IP Security (IPSec [IPSEC]) is used end-to-end between
   communicating hosts, RSVP may be the only mechanism which enables
   diff-serv networks to classify traffic to a granularity finer than
   IP addresses (such as per application, based on port numbers).
   Boundary routers can support classification of RSVP signaled IPSec
   encrypted flows by implementing RFC-2207 [RFC2207] and the
   corresponding classification logic.

10. Intercepting or Ignoring RSVP Messages

   RSVP messages are generated with the IP router alert option. This
   causes the messages to be intercepted by routers, for RSVP
   processing. It is necessary for boundary routers at diff-serv
   ingress points to intercept RSVP messages for the purpose of
   applying admission control to the diff-serv network (as described
   above). Since routers internal to the diff-serv network are not

Bernet                                                              26

              Requirements of Diff-serv Boundary Routers November 1998


   required to apply RSVP processing, it is preferable, for performance
   reasons, that they are not alerted by the router alert option.

   Egress boundary routers need not apply RSVP processing for the
   purpose of supporting diff-serv admission control and so, are not
   required to respond to the router alert option on messages passing
   out of the diff-serv network. However, these routers should respond
   to the router alert option on RSVP messages passing in the opposite
   direction (since they are effectively ingress boundary routers for
   these messages). In addition, egress boundary routers may choose to
   implement standard RSVP processing (on their customer interfaces),
   in which case, they must respond to the router alert option on RSVP
   messages passing out of the diff-serv network.

   Since certain routers must intercept RSVP messages on certain
   interfaces and others would prefer not to, a mechanism is required
   to 'hide' these messages. Such a suggestion is described in [AGGREG]
   and is based on usage of the router alert option field.

8. Security Considerations

   Standard router security mechanisms should be used to restrict SNMP,
   COPS and command line configuration. Standard RSVP security
   mechanisms should be used to restrict configuration via RSVP. The
   major security threat to consider is denial of service attacks.
   Refer to the 'Security Considerations' section in [DSARCH] for a
   further discussion of this issue.

9. References

   [DSARCH], Carson, M., Weiss, W., Blake, S., Wang, Z., Black, D.,
   Davies, E., "An Architecture for Differentiated Services", Internet
   Draft, October 1998

   [DSFWK], Davies, E., Keshav, S., Verma, D., Carlson, M., Ohlman, B.,
   Blake, S., Bernet, Y., Binder, J., Wang, Z., Weiss, W., "A Framework
   for Differentiated Services", Internet Draft, October 1998

   [COPS], Reichmeyer, F., Chan, K., Durham, D., Yavatkar, R., Gai, S.,
   McCloghrie, K., Herzog, S., "COPS Usage for Differentiated
   Services", Internet Draft, August 1998

   [MAPPING], Peter, F., Bernet, Y., "Integrated Services Over
   Differentiated Services", Internet Draft, March 1998

   [E2E], Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
   Nichols, K., Speer, M., "A Framework for the Use of RSVP With Diff-
   serv Networks", Internet Draft, June, 1998

   [IPSEC], Kent, S., Atkinson, R., "Security Architecture for the
   Internet Protocol", Internet Draft, July 1998



Bernet                                                              27

              Requirements of Diff-serv Boundary Routers November 1998


   [BB], Nichols, K., Blake, S., "Differentiated Services Operational
   Model and Definitions", Internet Draft, February 1998

   [EF], Jacobson, V., Nichols, K., Poduri, K., "An Expedited
   Forwarding PHB", Internet Draft, August 1998

   [RFC2207] Berger, L., O' Malley, T., "RSVP Extensions for IPSec Data
   Flows", RFC 2207, September 1997

   [RFC2205], Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S.,
   "Resource Reservation Protocl, Version 1 Functional Specification",
   RFC 2205, Septemeber 1997

   [802MAP], Seaman, M., Smith, A., Crawley, E., Wroclawski, J.,
   "Integrated Service Mappings on IEEE 802 Networks", Internet Draft,
   August 1998

   [AGGREG], Guerin, R., Blake, S., Herzog, S., "Aggregating RSVP Based
   QoS Requests", Internet Draft, November 1997

11. Author's Addresses

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

   Durham, David
   Intel Corp.
   2111 N.E. 25th Ave.
   Hillsboro, OR 97124-5961
   Phone: (503) 264-6232
   E-mail: David.Durham@intel.com

   Francis Reichmeyer
   Bay Networks, Inc.
   3 Federal Street
   Billerica, MA 01821
   Phone: (978) 916-3352
   E-mail: freichmeyer@BayNetworks.com












Bernet                                                              28

              Requirements of Diff-serv Boundary Routers November 1998



Appendix A. COPS-DS Constraint TCA PIB Format

   TBD.


















































Bernet                                                              29

              Requirements of Diff-serv Boundary Routers November 1998


Appendix B. COPS-DS Fine-Grain TCA PIB Format

   TBD.



















































Bernet                                                              30