One document matched: draft-bernet-diffedge-01.txt
Differences from draft-bernet-diffedge-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-23 04:27:34 |