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

Versions: 00 01                                                         
Differentiated Services                           Y. Bernet, Microsoft
Internet Draft                                              July, 1998
Document: draft-bernet-diffedge-00.txt


               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 ds.internic.net, 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 January 1999. Distribution of this draft
   is unlimited.


1. Abstract

   This draft discusses requirements of routers that serve as ingress
   points to diff-serv provider 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 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

Bernet                                                               1

              Requirements of Diff-serv Boundary Routers     July 1998


   premise of diff-serv networks is that routers within the networks
   handle packets on different traffic flows by applying different per-
   hop behaviours (PHBs). The PHB to be applied is specified by a code
   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.

4. Functional Components

   In order to support a diff-serv network, certain functionality is
   required from the boundary routers, which guard the ingress points
   to 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:

   mgmt.   ----------------
   COPS,   | diff-serv    |
   <------>| provisioning |------------------------
   SNMP,|  |     i/f      |                       |
   etc. |  ----------------                       |
        |       |       |                         |
        |       |       |                         |
        |       |       |                         |
   data |  -----------  |    ---------       ------------
   ------->| inbound |------>|routing|------>| outbound |---->
        |  |   t/c   |  |    ---------       | t/c & phb|
        |  -----------  |                    ------------
        |       ^       |                         ^
        |       |       |                         |
        |  -----------  |                         |
        -->|         |  |                         |
   ------->|  RSVP   |-----------------------------
   RSVP    |         |  |
   cntl    -----------  |
   msgs         ^       |
                |  -------------       -------
                ---| diff-serv |<----->| TCA |
                   |    a/c    |       |     |
                   -------------       -------




4.1 Interfaces, Traffic Conditioning and Routing Core



Bernet                                                               2

              Requirements of Diff-serv Boundary Routers     July 1998


   An inbound interface, routing component and outbound interface are
   illustrated at the center of the diagram. In real routers, there may
   be an arbitrary number of inbound and outbound interfaces
   interconnected by the routing core. The components of interest on
   the interfaces are the traffic conditioning [1] components. These
   are primarily at the inbound interface but may include a shaper at
   the outbound interface. Certain queuing functionality, which
   determines the per-hop behaviour [1](PHB) of the router is generally
   implemented at the outbound interface.

4.2 Diff-serv Provisioning Interface

   Diff-serv operating parameters are provisioned through this
   interface. These are primarily traffic conditioning parameters. The
   diff-serv admission control component checks these parameters for
   admissibility subject to a traffic conditioning agreement (TCA) and
   the level of resources currently committed. The network
   administrator interacts with the diff-serv provisioning interface
   via one of a number of management protocols such as SNMP or COPS
   [2].

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

4.4 Traffic Conditioning Agreement (TCA)

   A service level agreement (SLA) represents the high-level agreement
   between the diff-serv service provider operating the boundary router
   and the customer(s) served by it. The TCA [1] is a subset of the
   SLA, which specifies detailed traffic conditioning 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.

5. Traffic Conditioning Components

   Traffic conditioning is a fundamental component of a diff-serv
   router. It is defined in [1]. The diagram in the previous section
   illustrates the traffic conditioning components as an aggregate
   functionality distributed between the inbound and outbound
   interfaces of a diff-serv boundary router. The following paragraphs
   describe the traffic conditioning components in greater detail. Note
   that, with the exception of the shaper, all traffic conditioning

Bernet                                                               3

              Requirements of Diff-serv Boundary Routers     July 1998


   components can be considered to reside at the inbound interfaces to
   the router.

5.1 Classification

   In order for the boundary router to treat traffic differentially it
   must be able to differentiate certain traffic from other traffic.
   This requirement dictates the minimal requirement of a boundary
   router; classification.

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

   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 Metering and Policing

   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 of each class is being submitted. This
   rate can then be compared against a traffic profile that has been
   negotiated between the diff-serv provider and the diff-serv
   customer. Based on the results of the comparison, the meter deems
   particular packets to be conforming to the negotiated profile (in-
   profile) or non-conforming (out-of-profile). Appropriate policing
   actions are then applied to out-of-profile packets. See [1] for a
   definition of Meter and Policing. See [3] for a discussion of the
   metering model applicable to several diff-serv service types.

   Boundary routers should use meters and policers to protect the
   resources within the diff-serv network. These traffic-conditioning
   elements assure that customers cannot seize more than their fair
   share of resources within the diff-serv network. Forms of policing
   that may be used are:

   1. Discarding out-of-profile packets.
   2. Delaying out-of-profile packets until they become conforming
      (Shaping).
   3. Demoting the traffic class of out-of-profile packets by marking
      appropriately (policer marking).
   4. Charging for excess usage.

5.3 Marking



Bernet                                                               4

              Requirements of Diff-serv Boundary Routers     July 1998


   Marking refers to setting the code in a packet's DS-field based on a
   set of rules. We recognize three types of marking:

   1. Boundary Marking
   2. Customer Marking
   3. Policer Marking

   Routers are configured for one of two marking modes; customer
   marking or boundary marking. In addition, routers should always
   apply policer marking, regardless of the marking mode for which they
   are configured.

5.3.1 Boundary Marking

   In the case of boundary marking, the boundary router marks packets
   for a specific service level, as a service to the customer. This
   mode is generally employed when the customer is unable to mark
   packets submitted to the diff-serv network. A table is used to
   determine the DS-field code to be marked based on classification
   results.

5.3.2 Customer Marking

   In the case of customer marking, the customer is assumed to mark
   packets directly, before submission to the diff-serv network.

5.3.3 Policer Marking

   Regardless of the marking mode for which the boundary router is
   configured, it may have to re-mark packets that would otherwise
   receive a higher service level than that to which they are entitled.
   For example, assume that the agreement between customer and provider
   allows for 100 packets per second to be allotted the service level
   invoked by the DS-field code 100100. In the case of customer
   marking, the customer may submit 101 packets with this code in a
   single second. In order to protect its resources, the boundary
   router must select one packet to be discarded, or to delay the
   transmission of the 101st packet or to re-mark it for a lower
   service level. This re-marking is a form of policing (employed to
   protect the diff-serv network's resources) that may be negotiated as
   part of the service agreement between customer and provider and is
   known as policer marking.

   Even if boundary marking is employed, the marking table may cause
   the boundary router to mark 101 packets for code 100100 in a single
   second. In this case, the boundary router would either not mark the
   101st packet for the code 100100, or would mark it for the code
   100100 and would later re-mark it for a lower service level. The
   result is logically equivalent.

   Note that re-marking is always within the same PHB group (see [1]).

5.3.4 Classification Requirements Dictated by Marking Mode

Bernet                                                               5

              Requirements of Diff-serv Boundary Routers     July 1998



   When boundary marking is employed, the boundary router is required
   to recognize certain packets based on multiple fields in the packet
   header (such as IP addresses and ports), and to set an appropriate
   value in the DS-field of the packet. This requires MF classification
   in the boundary router. A marking table is used to specify the
   appropriate mark based on the classification results.

   When customer marking is employed, only BA classification is
   required at the boundary router. In this case, the boundary router
   need only to track submitted packets for each DS-field value and to
   re-mark in the case that a packet marked for a specific DS-field
   value does not conform to the profile negotiated for the
   corresponding service level.

   MF classification is more costly (in terms of processing and state)
   than BA classification. Therefore, there is an advantage to customer
   marking, which avoids the need for MF classification in the router.
   In addition, customer marking allows the transmitting host to pre-
   mark non-conforming packets selectively. This is preferable to the
   boundary marking alternative in which the boundary router will
   select arbitrary packets for demotion as non-conforming.

5.3.5 The Marking Table

   As described above, when the boundary router is configured for
   boundary marking, a marking table is used to select the appropriate
   mark based on results of MF classification. This table takes the
   form of a mapping of classification fields to DS-field values. This
   is illustrated in the following example:

   IP Src Addr IP Dest Addr IP Src Port IP Dest Port    DS-field
   ----------- ------------ ----------- ------------    --------
   1.2.X.X     X.X.X.X      X           X               100110
   1.3.X.X     X.X.X.X      X           X               100111
   X.X.X.X     X.X.X.X      5000        5001            110000

   Notes:
   1. The above table presents conflicts. For example; Which DS-field
      should be marked for a packet with source IP address 1.2.3.4,
      source IP port 5000 and destination IP port 5001? The agreement
      between customer and provider must include rules for resolving
      such conflicts.
   2. The example above is based solely on common IP header fields.
      Complex marking tables might define additional classification
      fields to be used in submitted packets.

5.4 Configurations of Logical Traffic Conditioning Components

   The following examples illustrate certain combinations of the
   traffic conditioning components described. Note that these
   illustrations are intended to represent logical combinations. The


Bernet                                                               6

              Requirements of Diff-serv Boundary Routers     July 1998


   physical realizations of these combinations will vary from
   implementation to implementation.

5.4.1 Customer Marking Configuration

   The following diagram illustrates the traffic conditioning
   components of a boundary router configured for customer marking:

        ---------   ---------   ---------
        |       |   |       |   |       |
    --->|       |-->|       |-->|       |-->
        |       |   |       |   |       |
        ---------   ---------   ---------

        BA Class.     Meter      Policer
                              (opt. Re-marking)

   The BA classifier is used to determine the diff-serv service level
   requested, as indicated by the marking in the DS-field of each
   packet. The meter determines whether the packet is conforming per
   the profile negotiated for the requested service level. The policer
   handles non-conforming packets either by discarding, delaying or re-
   marking the packet for a lower service-level.

   This traffic conditioning configuration is suitable only in the case
   that it is dedicated to a single customer. This is because it
   classifies traffic using a BA classifier and therefore is able to
   discriminate traffic based on diff-serv service level only. In order
   to support multiple customers, it is necessary to discriminate
   traffic based on customer as well as service level. This requires an
   MF-classifier as shown in the following diagram:

                        ---------   ---------   ---------
                        |       |   |       |   |       |
                   |--->|       |-->|       |-->|       |-->
                   |    |       |   |       |   |       |
                   |    ---------   ---------   ---------
         --------- |
         |       |-|    BA Class.     Meter      Policer
   ----->|       |                            (opt. Re-marking)
         |       |-|
         --------- |    ---------   ---------   ---------
                   |    |       |   |       |   |       |
                   |--->|       |-->|       |-->|       |-->
         MF Class.      |       |   |       |   |       |
                        ---------   ---------   ---------

                        BA Class.     Meter      Policer
                                              (opt. Re-marking)


   Typically, an interface and its traffic conditioning components
   would be dedicated to a single customer, obviating the need for the

Bernet                                                               7

              Requirements of Diff-serv Boundary Routers     July 1998


   MF classifier illustrated. Such a configuration is preferable since
   MF classification is more costly than BA classification. In the case
   that a single interface must be dedicated to multiple customers, an
   optimization to the illustrated configuration can be realized by
   inserting a BA classifier in advance of the MF classifier. This
   would identify all traffic marked for the default DS-field and allow
   it to bypass the costly MF classifier since it is not requesting
   preferential treatment. In many cases, the majority of traffic will
   be marked for the default DS-field.

5.4.2 Boundary Marking Configuration

   The following diagram illustrates the traffic conditioning
   components of a boundary router configured for boundary marking.

        ---------   ---------   ---------   ---------   ---------
        |       |   |       |   |       |   |       |   |       |
    --->|       |-->|       |-->|       |-->|       |-->|       |-->
        |       |   |       |   |       |   |       |   |       |
        ---------   ---------   ---------   ---------   ---------

        MF Class.    Marker     BA Class.     Meter      Policer
                                                      (opt. Re-marking)

   In this example, an MF classifier is used to determine which diff-
   serv service level a packet should be served at. The marker then
   marks the DS-field of the packet with the appropriate code for the
   service level. The operation of the classifier and marker is
   directed by the marking table described in section 5.3.5.

   Once the DS-field is marked based on the results of the MF
   classification, the packet is submitted for BA classification. From
   this point on, the packet is tracked based on the diff-serv service
   level for which it is targeted, as if the boundary router had been
   configured for customer marking.

   Per the illustration, a boundary router configured for boundary
   marking can logically be considered to concatenate the traffic
   conditioning components required for customer classification behind
   the MF classifier and marker required for boundary marking. In
   practical implementations, the initial marking based on MF
   classification will likely be combined with the remarking function
   of the policer. Similarly, the MF and BA classifiers will likely be
   combined.

5.4.3 Simultaneous Support for Customer and Boundary Marking

   We previously considered boundary routers to be configured either
   for boundary marking or customer marking. In practice, it may be
   useful to support both schemes simultaneously. For example, the
   diff-serv network provider may choose to support customers that have
   hosts that are capable and trusted to mark directly, as well as
   hosts that are not. The diff-serv provider can offer such mixed

Bernet                                                               8

              Requirements of Diff-serv Boundary Routers     July 1998


   services either by requiring the customer to isolate hosts of each
   type behind a dedicated interface to the diff-serv network or by
   using the traffic conditioning configuration illustrated below.

   In this example, a full MF classifier is employed to determine which
   packets should be marked by the boundary router, and which should be
   left unmodified. This is logically illustrated by the following
   modification to the boundary marking traffic conditioner
   configuration:

        ---------   ---------   ---------   ---------   ---------
        |       |   |       |   |       |   |       |   |       |
    --->|       |-->|       |-->|       |-->|       |-->|       |-->
        |       |-| |       | ->|       |   |       |   |       |
        --------- | --------- | ---------   ---------   ---------
                  |           |
                  -------------
        MF Class.    Marker     BA Class.     Meter      Policer
                                                      (opt. Re-marking)


   Note the arrow connecting the output of the MF classifier to the
   input of the BA classifier (bypassing the marker). This represents
   processing of packets that are determined by the MF classifier to be
   pre-marked and trusted.

5.6 Boundary Shaping vs. Customer Shaping

   The TCA for certain diff-serv service levels specifies a
   quantitative profile to which traffic submitted for the service
   level must conform. In order to assure conformance, it is necessary
   for the traffic to be shaped to the profile. Ideally, shaping is
   applied on a per-flow basis, at each host (where it scales best). If
   the customer's hosts cannot be relied upon to shape, the customer
   may negotiate a TCA that calls for the provider to shape on behalf
   of the customer. This is a form of policing, referred to as boundary
   shaping.

   The TCA may call for aggregate boundary shaping or for per-flow
   boundary shaping. Aggregate boundary shaping is a specific method of
   implementing the aggregate policing which is necessary at boundary
   routers. It requires only BA classifiers. It does not provide any
   traffic separation for the customer. Per-flow boundary shaping may
   be offered as an additional service to the customer. It has the
   advantage of providing traffic separation for the customer, but
   requires an MF classifier and multiple shaping queues and will
   therefore be costly at the boundary router.

   As illustrated in the context of customer marking vs. boundary
   marking numerous configurations of traffic conditioning components
   can be used to support customer shaping vs. boundary shaping.

6. Configuration of Boundary Routers

Bernet                                                               9

              Requirements of Diff-serv Boundary Routers     July 1998



   In the previous section we examined the traffic conditioning
   components which comprise the core diff-serv functionality of the
   boundary router. This section discusses configuration of the traffic
   conditioning components via the diff-serv provisioning interface and
   RSVP (see block diagram in section 4).

6.1 Configuration Information

   The following configuration information is required.

6.1.1 The Traffic Conditioning Agreement (TCA)

   The TCA is negotiated (either statically or dynamically) between the
   diff-serv provider and the customer. At minimum, the TCA defines
   traffic conditioning parameters on a per diff-serv service level
   granularity. This granularity reflects the fundamental nature of
   diff-serv service; the provision of resources at a limited number of
   service levels.

   Diff-serv providers may offer additional functionality in boundary
   routers to assist the customer in providing some degree of finer
   grain traffic isolation. This is also reflected in the TCA. Boundary
   marking is an example of such an additional service.

   As such, it is helpful to consider two subsets of the TCA. One is
   the subset of the TCA that defines the aggregate per service-level
   resources that are negotiated between provider and customer. We will
   refer to this subset informally as the constraint TCA. The other
   subset of the TCA defines finer grain traffic conditioning which may
   be provided to the customer as a value-add. We will refer to this
   subset as the fine-grain TCA. Information in the fine-grain TCA is
   subject to the constraints of the constraint TCA.

   The TCA includes at least a policing table and may optionally
   include a marking table, as described in the following sections.

6.1.2 Policing Table

   Policing is the mechanism by which diff-serv providers protect their
   network resources. By policing, the provider is effectively
   approving or denying instantaneous requests for resources at a
   particular service-level (as conveyed by the marking in each
   packet's DS-field). As such, a per-service policing table is a
   required part of the constraint TCA.

   Policing configuration information can be expressed as a table of
   entries having the following format:

   DS-field : Metering Profile : Disposition of non-conforming traffic

   The first column specifies the DS-field (in packet headers) to which
   the entry applies. The second column specifies the traffic profile

Bernet                                                              10

              Requirements of Diff-serv Boundary Routers     July 1998


   against which packets with the corresponding DS-field should be
   measured. (In the case of a token bucket profile, the metering
   profile would specify, token rate, peak rate and bucket size). The
   third column specifies the action to be taken for packets that are
   deemed non-conforming to the profile. Actions typically include:
   shape to profile, discard, charge for excess usage, or demote to a
   lower, specified service class by re-marking the PHB.

   For PHBs that offer tight QoS assurances [4], it is generally
   necessary to limit these assurances to flows between the ingress
   boundary router and specific egress points from the diff-serv
   network. Therefore, a fourth column may be required for certain
   entries. This column would specify an egress subnet. Such an entry
   should be understood to assure the service level specified by the
   DS_field for traffic conforming to the profile and sent from the
   boundary router ingress point to the specified egress point.

   A diff-serv provider may offer fine-grain policing (especially in
   the form of shaping) services to a customer. In this case, a
   policing table similar to the one above would be incorporated as
   part of the fine-grain TCA and would be subject to the constraints
   of the constraint TCA. The first column of this policing table would
   specify MF-classification criteria rather than DS-field value.

6.1.1.1 Marking Table

   If boundary marking is to be provided, a marking table as described
   in section 5.3.5, is required. The marking table is used to
   configure MF classifiers and Markers.

   Since the marking table is generally used to effectively map fine-
   grain traffic flows into a small number of diff-serv service levels,
   it can be considered part of the fine-grain TCA. Note that marking
   amounts to generating requests for particular service levels. These
   requests are then approved or denied by a policer. As such, marking
   per-se is not subjected to the constraints of the constraint TCA.

6.1.3 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 outbound interfaces. There may be multiple configuration
   parameters required to configure PHBs. These are beyond the scope of
   this draft. Such parameters should be addressed as part of each PHB
   specification.

6.1.4 Additional Configuration Information

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


Bernet                                                              11

              Requirements of Diff-serv Boundary Routers     July 1998


6.2 Configuration Mechanisms

   The following sections describe the mechanisms by which the above
   configuration information is installed in the boundary router. We
   are concerned primarily with the configuration of the marking table
   and policing information. A significant distinction is made between
   signaled configuration (RSVP) and provisioned configuration (all
   other mechanisms).

6.2.1 Installing the Constraint TCA

   The constraint TCA effectively specifies the resources that the
   provider is offering to the customer in the diff-serv network. The
   two parties 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.

   Note that protocols between the provider and customer may be used to
   renegotiate the constraint TCA. This would allow the constraint TCA
   to be somewhat more dynamic.

   Static constraint TCAs may be installed into the boundary router via
   a user management interface or protocol. For example, the constraint
   TCA could be installed using SNMP or via vendor specific command
   line interfaces.

   Alternatively, COPS may be used to install the constraint TCA.
   Because it is targeted primarily at QoS management, COPS is better
   suited to support dynamic modifications to the constraint TCA.

   In either case, the constraint TCA is considered to convey
   provisioned configuration (as opposed to signaled configuration).

6.2.2 Configuring the Fine-Grain TCA

   The fine-grain TCA specifies how the customer allocates the
   resources it is paying for among its various traffic flows. The
   provisioning mechanisms used to install the constraint TCA (SNMP,
   COPS and command line interfaces) may also be used to install the
   fine-grain TCA. However, there are advantages to using a signaling
   mechanism to configure the fine-grain TCA. These are discussed
   below.

   The customer may wish to modify the fine grain TCA quite frequently.
   In addition, the customer can for the most part, be allowed to
   modify the fine-grain TCA without requiring the provider's approval.
   For example, the customer may wish to stop marking packets from
   subnet 1.X.X.X for a certain diff-serv service level and to start
   marking packets from subnet 2.X.X.X for that service level. The
   customer may wish to do so instantly and should not be required to
   obtain approval from the diff-serv provider to do so. To this end,


Bernet                                                              12

              Requirements of Diff-serv Boundary Routers     July 1998


   the customer may use RSVP to modify the marking table that is part
   of the fine-grain TCA.

   Similarly, the customer may use RSVP to configure fine-grain
   policing information. For example, the customer may invoke per-flow
   packet shaping services from the boundary router (within a diff-serv
   service level) via RSVP signaling.
   Using RSVP to configure such information in the fine-grain TCA has
   the advantages of providing instant response to the customer, with
   reduced management burden to the provider. In addition, RSVP can be
   used to configure boundary routers to recognize IPSec [5] (or other)
   encrypted flows. Without RSVP, MF classifiers will not be able to
   recognize encrypted flows.

   Finally, RSVP offers a significant advantage by virtue of supporting
   admission control. Admission control support in boundary routers is
   discussed in the next section.

7. Support for RSVP Admission Control

7.1 Overview of RSVP and Diff-serv Interoperation

   As described in [4], diff-serv networks can be used to provide end-
   to-end QoS across large transit networks by supporting RSVP. This
   approach is of particular interest for a certain class of
   applications for which RSVP signaling is practical, including
   primarily multi-media applications. These applications generally:

   1. Are able to quantify their QoS requirements
   2. Require tighter QoS assurances than other applications
   3. Operate between specific end-points

   The Intserv service-types that are used by RSVP are mapped to
   specific diff-serv PHBs [3,4]. Routers in diff-serv networks should
   support these PHBs. 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.

7.2 How Admission Control is Used

   Consider a diff-serv service that offers very low latency such as
   would be suitable for IP telephony. The EF PHB [6] is expected to
   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.
   The TCAs offer 100 Kbps of EF service between the two attachment
   points. Now consider that the customer uses this service to carry
   voice over IP calls, each requiring a 16 Kbps flow.

   In order to obtain the low latency service, the customer (either by
   direct marking or by boundary marking) must mark voice over IP
   traffic for the appropriate diff-serv service level. At the same

Bernet                                                              13

              Requirements of Diff-serv Boundary Routers     July 1998


   time, the customer must 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 mark
   traffic on the seventh flow for a lower service level (as described
   in [4]). As a result, the six flows in place remain protected. Of
   course, the same mechanisms apply to applications other than voice
   over IP, for example - streaming video applications).

   Additional benefits of such admission control include:

   1. The ability to admit traffic to the diff-serv network based on
      the approval of policy information carried in RSVP signaling
      networks.
   2. The ability to coordinate reservation of resources in RSVP
      enabled regions of a network with acquisition of resources in
      diff-serv regions of a network. For example, consider an end-to-
      end path which originates and terminates at RSVP enabled campus
      networks interconnected by a diff-serv enabled transit network.
      It makes little sense to install reservations in the campus
      networks if the diff-serv network cannot support the necessary
      quality. Diff-serv admission control would avert this eventuality
      by rejecting the reservation request at the diff-serv boundary
      router.
   3. Feedback to applications regarding the end-to-end admissibility
      of their resource request can be used to cause the applications
      to retry at a lower bandwidth or to invoke alternate adaptation
      mechanisms.

7.3 Implementing Diff-serv Admission Control in Boundary Routers

   Diff-serv admission control in boundary routers requires
   implementation of a subset of RSVP. In particular, the RSVP protocol
   state machine is required. The RSVP MF classification and scheduling
   mechanisms are not necessarily required. The local admission control
   functionality of standard RSVP routers [7] 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.



Bernet                                                              14

              Requirements of Diff-serv Boundary Routers     July 1998


   In a diff-serv boundary router, a similar process is used. Upon
   receiving a reservation request 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 TCA entries
      corresponding 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 DS-field mark which maps to the
      Intserv service type specified in the reservation request (see
      [3]).
   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
   [8].

   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.

7.4 Dynamic Constraint TCAs

   The admission control procedure described above assumes static
   constraint TCAs. In certain cases, protocols (such as the bandwidth
   broker protocol [9]) employed within the diff-serv network (and
   possibly between the diff-serv network and the customer network) may
   be used to renegotiate constraint TCAs. Such protocols can be used
   to dynamically adjust the constraint TCA.

   For example, a boundary router may maintain a high-water mark
   against which resources at a particular service level (and to a
   particular egress subnet) are tracked. The high-water mark would
   specify a resource level slightly lower than the limit specified by
   the profile in the constraint TCA. If the level of resources
   committed to a customer by diff-serv admission control reaches the
   high-water mark, the boundary router would use a protocol to
   negotiate a new profile for the appropriate constraint TCA entry.
   Similarly, a low-water mark would be defined and when the level of
   resources committed fell below the low-water mark, the profile would

Bernet                                                              15

              Requirements of Diff-serv Boundary Routers     July 1998


   again be re-negotiated. Such a mechanism assumes that the SLA
   between the customer and the provider allows for re-negotiation of
   TCA entries as needed.

8. 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
   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 [10] 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.

9. References

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

   [2], Herzog, S., Sastry, A., Rajan, R., Cohen, J., Boyle, J.,
   Durham, D., "The COPS (Common Open Policy Service) Protocol",
   Internet Draft, March 1998

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

   [4], 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

Bernet                                                              16

              Requirements of Diff-serv Boundary Routers     July 1998


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

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

   [7], Wroclawski, J., "The Use of RSVP With IETF Integrated
   Services", RFC 2210, September, 1997

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

   [9], Nichols, K., Jacobson, V., Zhang, L., "A Two-Bit Differentiated
   Services Architecture for the Internet", Internet Draft, November
   1997

   [10], 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

























Bernet                                                              17