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

Versions: 00 01 02 03 04 05 06 07 rfc3564                               
                                            Francois Le Faucheur, Editor
                                                           Thomas Nadeau
                                                     Cisco Systems, Inc.

                                                           Martin Tatham
                                                                      BT

                                                          Thomas Telkamp
                                                            David Cooper
                                                         Global Crossing

                                                               Jim Boyle
                                                            Luca Martini
                                             Level 3 Communications, LLC

                                                             Luyuan Fang
                                                              Waisum Lai
                                                               Jerry Ash
                                                                    AT&T

                                                              Pete Hicks
                                                            Core Express

                                                             Angela Chiu
                                                         Celion Networks

                                                        William Townsend
                                                          Tenor Networks

                                                          Darek Skalecki
                                                         Nortel Networks


IETF Internet Draft
Expires: November, 2001
Document: draft-ietf-tewg-diff-te-reqts-01.txt         June, 2001


                      Requirements for support of
                Diff-Serv-aware MPLS Traffic Engineering


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet-Drafts are
   Working documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents


Le Faucheur, et. al                                                  1



            Requirements for Diff-Serv Traffic Engineering   June 2001

   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This document presents the Service Provider requirements for support
   of Diff-Serv aware MPLS Traffic Engineering (DS-TE) as discussed in
   the Traffic Engineering Working Group Framework document [TEWG-FW].


1.      Problem Statement

   Diff-Serv is becoming prominent in providing scalable multi-class of
   services in IP networks.

   In some Diff-Serv networks where optimization of transmission
   resources on a network-wide basis is not sought, MPLS Traffic
   Engineering mechanisms may simply not be used in complement to Diff-
   Serv mechanisms.

   In other networks, where some optimization of transmission resources
   is sought, Diff-Serv mechanisms ([DIFF-MPLS]) may be complemented by
   existing MPLS Traffic Engineering mechanisms ([TE-REQ], [ISIS-TE],
   [OSPF-TE], [RSVP-TE], [CR-LDP]) which operate on an aggregate basis
   across all Diff-Serv Behavior Aggregates. In that case, Diff-Serv
   and MPLS TE both provides their respective benefits (i.e. Diff-Serv
   performs service differentiation at every hop, Traffic Engineering
   achieves better distribution of the aggregate traffic load across
   the set of network resources). However, they operate independently
   of each other. In other words, MPLS Traffic Engineering performs
   Constraint Based Routing and Admission Control with the same set of
   global constraints for all Behavior Aggregates and without the
   ability to use different sets of constraints for different Behavior
   Aggregates.

   In yet other networks where fine optimization of transmission
   resources is sought, it may be beneficial to perform traffic
   engineering at a per-class level instead of an aggregate level, in
   order to further enhance networks in performance and efficiency as
   discussed in [TEWG-FW]. By mapping a traffic trunk in a given class
   on a separate LSP, it allows the traffic trunk to utilize resources
   available to the given class on both shortest path(s) and non-
   shortest paths and follow paths that meet constraints which are
   specific to the given class. This is what we refer to as "Diff-Serv-
   aware Traffic Engineering (DS-TE)".


 Le Faucheur et. al                                                  2



            Requirements for Diff-Serv Traffic Engineering   June 2001

   This document focuses exclusively on the specific environments which
   would benefit from DS-TE. In preview, networks where bandwidth is
   scarce (e.g. transcontinental networks), where high priority traffic
   can be significant compared to link speed on some links (e.g.
   service provider networks with very large voice trunks), and where
   the relative proportion of traffic across Behavior Aggregates is not
   uniform across the whole topology are examples of networks where
   Diff-Serv-aware Traffic Engineering may yield significant benefits.

   This document focuses on intra-domain operations. Inter-domain
   operations is not considered.

   Below are examples of specific scenarios where Service Providers
   require DS-TE.


1.1.    Scenario 1: High Proportion of Voice

   An IP/MPLS network may need to carry a significant amount of VoIP
   (EF) traffic, compared to its link capacities. For example, 10,000
   uncompressed calls at 20ms packetization result in about 1Gbps of IP
   traffic, which is already significant on an OC-48c based network. In
   case of topology changes such as link/node failure, EF traffic
   levels can even approach the link bandwidths.

   For delay/jitter reasons it is undesirable to carry more than a
   certain percentage of EF traffic on any link. The rest of the
   available link bandwidth can be used to route other classes
   corresponding to delay/jitter insensitive traffic (e.g. Best Effort
   Internet traffic). The exact determination of this percentage is
   outside the scope of this requirements draft.

   During normal operations, the VoIP traffic should be able to preempt
   other classes of traffic (if these other classes are designated as
   preemptable and they have lower preemption priority),
   so that it will be able to use the shortest available path, only
   constrained by the maximum defined VoIP link utilization
   ratio/percentage.

   Existing TE mechanisms only allow to do constraint based routing of
   traffic based on a single bandwidth constraint common to all
   classes, which does not satisfy the needs described here.


1.2.    Scenario 2: Rerouting on Lower Speed facilities

   An IP/MPLS network may support multiple classes of traffic. Assume
   that a network topology includes OC48/192s links including {Chicago
   to New York, New York to Washington DC, Washington DC to Dallas and
   Dallas to Chicago} and some OC3/12s links along {Chicago to
   Cleveland, Cleveland to Philadelphia, Philadelphia to New York}.


 Le Faucheur et. al                                                  3



            Requirements for Diff-Serv Traffic Engineering   June 2001

   Assume also, as in previous scenario, that one (or more) high
   priority class(es) of service has tight quality requirements which
   could not be met if there was more traffic of this class on a link
   than a "moderate" percentage of the link.

   The OC48/192s and OC3/12s links may have been provisioned so that,
   in steady state, there will be less high priority traffic than the
   desired "moderate" percentage. For instance, the amount of high
   priority traffic may be "relatively" small so that, in steady state,
   the network administrator knows that it will never exceed 25 % of
   any link capacity, without having to enforce this via separate
   constraint based routing or Admission Control. To provide the
   appropriate level of quality to each class of service, the network
   administrator only needs to configure the Diff-Serv PHBs (scheduler
   queues) appropriately.

   However, under failure of some links, the remaining links may not
   always be sufficient to ensure that after rerouting, high priority
   traffic does not exceed the "moderate" percentage on all the links.

   Consider a failure scenario in the topology above where the Chicago
   to New York link is down while there is no failure of the OC3/12
   links. As traffic is rerouted, it is possible that the jitter
   sensitive high priority traffic will exceed the desired percentage
   of link capacity of the links along the shorter, but lower capacity
   routes. In our scenario, the "relatively small" amount of high
   priority traffic of 25% worth of OC48/192s may turn into "excessive"
   amount of high priority traffic on the OC3/12 links.

   Current TE mechanisms allow high priority traffic to be rerouted
   separately from the other classes of traffic (i.e. by building
   separate TE-LSPs for high priority and for other classes). However,
   current mechanisms only allow route computation to enforce a common
   bandwidth constraint. Assuming that the network administrator elects
   to give higher preemption priority to the high priority traffic (in
   order to maximize its chances of being rerouted and also maximize
   its chances of being rerouted on its shortest path), this may result
   in high priority tunnels routed onto the OC3/12 links up to the full
   capacity of the link. This would result in unacceptable degradation
   of quality of the high priority traffic.

   This leads to the requirement for DS-TE to be able to enforce a
   different bandwidth constraint for different classes of traffic. In
   the above example, the bandwidth constraint to be enforced for high
   priority traffic may be the "moderate" percentage of each link
   capacity, while the bandwidth constraint to be enforced for the rest
   of the traffic may be the full link capacity. This would result in
   high priority traffic/voice being rerouted first on the {Chicago to
   Cleveland}, {Cleveland to Philadelphia} and {Philadelphia to New
   York} links up to the "moderate" percentage of each of these links
   and other classes of service to be routed on these links to fill up
   the remaining capacity. Additional high priority traffic/voice which

 Le Faucheur et. al                                                  4



            Requirements for Diff-Serv Traffic Engineering   June 2001

   cannot be rerouted over the {Chicago to Cleveland}, {Cleveland to
   Philadelphia} and {Philadelphia to New York} links because it would
   exceed their "moderate" percentage, will be rerouted along other
   paths which excludes these links.


1.3.    Scenario 3: Maintain relative proportion of traffic classes

   Suppose an IP/MPLS network supports 3 classes of traffic. The
   network administrator wants to perform Traffic Engineering to
   distribute the traffic load. Assume also that proportion across
   traffic classes varies significantly depending on the
   source/destination POPs.

   Then, with existing Traffic Engineering mechanisms, the proportion
   of traffic from each class on a given link will vary depending on
   multiple factors including:
   - in which order the different TE-LSPs are routed
   - the preemption priority associated with the different TE-LSPs
   - failure situations leading to reroute

   This may make it difficult or impossible for the network
   administrator to configure the Diff-Serv PHBs (e.g. queue bandwidth)
   to ensure that each traffic class gets the appropriate treatment.

   This leads again to the requirement for DS-TE to be able to enforce
   a different bandwidth constraint for different classes of traffic.
   This could be used to ensure that, regardless of the order in which
   tunnels are routed, regardless of their preemption priority and
   regardless of the failure situation, the amount of traffic of each
   class routed over a link matches the Diff-Serv scheduler
   configuration on that link for the corresponding class (e.g. queue
   bandwidth).

   As an illustration of how DS-TE would address this scenario, the
   network administrator may configure the service rate of Diff-Serv
   queues to (45%,35%,20%) for classes (1,2,3) respectively. The
   administrator would then build separate TE LSPs for each class and
   associate to each LSP the bandwidth need for its class. The network
   administrator may also want to give highest preemption priority to
   the highest priority class and medium preemption priority to the
   medium class. Then DS-TE could ensure that after a failure, class 1
   traffic would be rerouted with first access at link capacity but
   without exceeding its service rate of 45% of the link bandwidth.
   Class 2 traffic would be rerouted with second access at the link
   capacity but without exceeding its allotment. Note that where class
   3 is the Best-Effort service, the requirement on DS-TE is to ensure
   that the total amount of traffic routed across all classes does not
   exceed the total link capacity of 100 (as opposed to separately
   limiting the amount of Best Effort traffic to 20 even if there was
   little class 1 and class 2 traffic).


 Le Faucheur et. al                                                  5



            Requirements for Diff-Serv Traffic Engineering   June 2001

   In this scenario, DS-TE allowed to maintain a somewhat steady
   distribution of different classes, even during rerouting. This
   relied on the required capability of DS-TE to adjust the amount of
   traffic of each class routed on a link based on the configuration of
   the scheduler for that class.

   Alternatively (or perhaps in addition), some network administrators
   may want to solve the issue in the opposite way through the
   scheduler configuration being dynamically tied into the amount of
   bandwidth of the LSPs admitted for each class. This is an additional
   requirement on DS-TE.


1.4.    Scenario 4: Guaranteed Bandwidth Services

   In addition to the Best effort service, an IP/MPLS network operator
   may desire to offer a point-to-point "guaranteed bandwidth" service
   whereby the provider pledges to provide a given level of performance
   (bandwidth/delay/loss...) end-to-end through its network from an
   ingress port to and egress port.  The goal is to ensure all
   "guaranteed" traffic within a subscribed traffic contract, will be
   delivered within stated tolerances.

   One approach for deploying such "guaranteed" service involves:
   - dedicating a Diff-Serv PHB (or a Diff-Serv PSC as defined in
     [DIFF-NEW]) to the "guaranteed" traffic
   - policing guaranteed traffic on ingress against the traffic
     contract and marking the "guaranteed" packets with the
     corresponding DSCP/EXP value

   Where very high level of performance is targeted for the
   "guaranteed" service, it may be necessary to ensure that the amount
   of "guaranteed" traffic remains below a given percentage of link
   capacity on every link. Where the proportion of "guaranteed" traffic
   is high, constraint based routing can be used to enforce such a
   constraint.

   However, the network operator may also want to simultaneously
   perform Traffic Engineering of the rest of the traffic (i.e. non-
   guaranteed traffic) which would require that constraint based
   routing is also capable of enforcing another bandwidth constraint,
   which would be less stringent than the one for guaranteed traffic.

   Again, this combination of requirements can not be addressed with
   existing TE mechanisms. DS-TE mechanisms allowing enforcement of a
   different bandwidth constraint for guaranteed traffic and for non-
   guaranteed traffic are required.



2.      Detailed Requirements for DS-TE


 Le Faucheur et. al                                                  6



            Requirements for Diff-Serv Traffic Engineering   June 2001

2.1.    DS-TE Compatibility

   While DS-TE is required in a number of situations such as the ones
   described above, it is important to keep in mind that using DS-TE
   may impact scalability (as discussed later in this document) and
   operational practices. DS-TE should only be used when existing TE
   mechanisms combined with Diff-Serv can not address the network
   design requirements.  Many network operators may choose to not use
   DS-TE, or to only use it in a limited scope within their network.

   Thus, the DS-TE solution must be developed in such a way that:
    (i)    it raises no interoperability issues with existing deployed
           TE mechanisms. Networks which do not require DS-TE must not
           be impacted in any way.
    (ii)   it allows DS-TE deployment to the required level of
           granularity and scope (e.g. only in a subset of the
           topology, e.g. only for the number of Classes required in
           the considered network)


2.2.    Separate Bandwidth Constraints

   [TEWG-FW] introduces the concept of Class-Types. The fundamental
   requirement for DS-TE is to be able to enforce different bandwidth
   constraints for different Class Types rather than a single one.

   Based on the scenarios of section 1, DS-TE must allow the network
   operator to configure the bandwidth constraints such that:
     - DS-TE never routes more than P1% of EF on a given link
        - DS-TE never routes more than P0% of EF+BE on that link,where
   P1 and P0 are configurable separately.

   Just for illustration purposes a network operator may configure
   P1=70 and P0=100. In this case, DS-TE could have established at a
   given time, for instance, :
        - 70% worth of EF and 30% worth of BE, OR
        - 50% worth of EF and 50% worth of BE, OR
        - 0% worth of EF and 100% worth of BE.
   Clearly, DS-TE would never establish more than 70% of EF TE-LSPs
   even if there was very little or no BE TE-LSPs routed on the link.

   Where 3 Class-Types are supported (e.g. CT2=EF, CT1=AF1+AF2, CT0=BE)
   in the scenarios of section 1, DS-TE must allow the network operator
   to configure the bandwidth constraints such that:
        - DS-TE never routes more than say P2% of CT2 on a given link
        - DS-TE never routes more than say P1% of CT2+CT1 on that link.
        - DS-TE never routes more than say P0% of CT2+CT1+CT0 on that
   link.

   Just as an example, the network operator may configure P2=60, P1=80
   and P0=100. In that case, DS-TE could have established at a given
   time, for instance, :

 Le Faucheur et. al                                                  7



            Requirements for Diff-Serv Traffic Engineering   June 2001

        - 60% worth of EF, 20% worth of AF and 20% worth of BE, OR
        - 0% worth of EF, 80% worth of AF and 20% worth of BE, OR
        - 40% worth of EF, 40% worth of AF and 20% worth of BE, OR
        - 30% worth of EF, 30% worth of AF and 40% worth of BE.
   Clearly, DS-TE would never establish more than 60% of EF TE-LSPs
   even if there was very little or no AF and BE TE-LSPs routed on the
   link. Similarly, DS-TE would never establish more than 80% worth of
   EF+AF TE-LSPs even if there was very little or no BE TE-LSPs routed
   on the link.

   More generally, the bandwidth constraints enforced by DS-TE must
   allow the following:
   - if a high priority class does not use up all of its bandwidth, the
     next highest priority should be able to make use of this unused
     bandwidth. For instance, in the above example with 3 Class-Types,
     if CT2/EF is only using 30% (instead of its maximum 60%), then
     CT1/AF should be able to use up to 50%. However, if CT2/EF is
     using its 60%, it is obviously necessary to limit CT1/AF to much
     below 50% (i.e. to 20% in our example) in order to maintain CT2's
     performance levels.
   - If a lower priority class (e.g. AF) used some of the unused
     bandwidth of a higher priority class (e.g. EF), the high priority
     class should be able to reclaim this bandwidth where necessary
     (i.e. preempt lower priority class - see section 2.5)
   - lower priority class-Types (e.g Best Effort) should not be
     completely starved by higher priority classes.
   - Highest priority classes, should only be routed away from their
     shortest path when they would exceed their own bandwidth
     constraints. They should not be routed away from their shortest
     path because of lower priority classes.


   Therefore, where N Class-Types are supported, DS-TE must allow the
   network operator to configure the following bandwidth constraints:

        - never route more than P(N-1)% of CT(N-1) on a given link
        - never route more than P(N-2)% of CT(N-1)+CT(N-2) on that
   link.
        - never route more than P(N-3)% of CT(N-1)+CT(N-2)+CT(N-3) on
   that link.
        - etc.
        - never route more than P(0)% of CT(N-1)+CT(N-2)+... + CT(0) on
   that link,

   where P(N-1), P(N-2), ..., P(0) are each configurable separately for
   every link.


   DS-TE may optionally support additional bandwidth constraints.


2.3.    Number of Class-Types

 Le Faucheur et. al                                                  8



            Requirements for Diff-Serv Traffic Engineering   June 2001


   DS-TE must support a minimum of 4 Class-Types.

   In a given network, DS-TE must not force the network administrator
   to support the maximum number of Class-Types. The network
   administrator must be able to deploy DS-TE for only 2, for only 3 or
   for 4 Class-Types.

   DS-TE must minimize the scalability impact when low number of Class-
   Types are actually deployed.

   DS-TE should be extensible to support more Class-Types if required.


2.4.    Number of Classes

   DS-TE should not constrain the number of classes that can be grouped
   in a Class-Type.


2.5.    Preemption

2.5.1.  Preemption Within a Class-Type

   DS-TE must support multiple preemption priorities within a given
   Class-Type (i.e. between two TE LSPs from the same Class-Type).
   Preemption within a Class-Type must operate in a similar way to how
   preemption operates in existing TE:

   expanding on the description of preemption in [TEWG-FW], a traffic
   trunk of Class-Type CTx, say "A", can preempt another traffic trunk
   of same Class-Type CTx, say "B", only if *all* of the following five
   conditions hold:
   (i)    "A" has a relatively higher priority than "B",
   (ii)   "A" contends for a resource utilized by "B" (including link
          bandwidth which must satisfy all the bandwidth constraints
          relevant to CTx),
   (iii)  the resource cannot concurrently accommodate "A" and "B"
          based on certain decision criteria,
   (iv)   "A" is preemptor enabled, and
   (v)    "B" is preemptable.

   DS-TE must also allow the network operator to configure the TE-LSPs
   of a given Class-Type so that they are all at the same preemption
   priority and thus do not preempt each other.

2.5.2.  Preemption Across Class-Types

   DS-TE must support multiple preemption priorities across Class-Types
   (i.e. between two TE LSPs from different Class-Types). Preemption
   across Class-Types must operate in the following way:


 Le Faucheur et. al                                                  9



            Requirements for Diff-Serv Traffic Engineering   June 2001

   a traffic trunk of Class-Type CTx, say "A", can preempt another
   traffic trunk of another Class-Type CTy, say "B", only if *all* of
   the following five conditions hold:
   (i)    "A" has a relatively higher priority than "B",
   (ii)   "A" contends for a resource utilized by "B" (including link
          bandwidth which must satisfy all the bandwidth constraints
          relevant to CTx). In other words, where preemption is used
          across Class-Types, the high priority traffic in one Class-
          Type must have the ability to pre-empt lower priority
          traffic, but only while still within the constraint of the
          maximum bandwidth available to that Class-Type.,
   (iii)  the resource cannot concurrently accommodate "A" and "B"
          based on certain decision criteria,
   (iv)   "A" is preemptor enabled, and
   (v)    "B" is preemptable.

   As an example, let's consider the case described in section 2.2
   where the following bandwidth constraints are configured:
   - DS-TE never routes more than say 70% of EF on a given link
   - DS-TE never routes more than 100% of EF+BE on that link.

   Let's assume that DS-TE has actually established at a given time:
   - 50% worth of EF TE-LSPs and
   - 50% worth of BE TE-LSPs.
   Let's also assume that a new EF TE-LSP worth 10% now needs to be
   established and contends for this link.
   Then, DS-TE must allow preemption across Class-Types so that, if so
   desired by the network administrator, it is possible to preempt 10%
   worth of already established BE TE-LSPs in order to establish the
   new EF TE-LSP. Note that in this case, preemption is applicable
   because the new EF TE-LSP contends for link bandwidth which satisfy
   all the bandwidth constraints relevant to EF (new EF TE-LSPs of
   50+10% would be below 70%, and new EF+BE TE-LSPs of 50+10+50-10%
   would be within 100%).

   Let's assume that the above preemption took place and DS-TE now has
   actually established:
   - 60% worth of EF TE-LSPs and
   - 40% worth of BE TE-LSPs.
   Let's also assume that another new TE-LSP worth 15% now needs to be
   established. Then, preemption of BE TE-LSPs is not applicable
   because the new EF TE-LSP would contend for link bandwidth which
   would not satisfy the bandwidth constraints relevant to EF (new EF
   TE-LSPs of 60+15% would exceed the 70%).



   DS-TE must also allow the network operator to configure the TE-LSPs
   so that preemption across Class-Types is precluded.

2.6.    Resource Class Affinity


 Le Faucheur et. al                                                 10



            Requirements for Diff-Serv Traffic Engineering   June 2001

   [TE-REQ] defines Resource class attributes associated with links and
   defines resources affinity attributes associated with a traffic
   trunk which can be used to specify the class of links which are to
   be explicitly included or excluded from the path of the traffic
   trunk. Because these attributes already have an open semantic and
   can be used to implement whatever policy is required by the Service
   Provider, no new attributes, nor extensions on existing attributes
   are required. The only requirement on DS-TE is to allow separate
   configuration of Resource Class Affinity attributes on the traffic
   trunks corresponding to each different Class of Service.

2.7.    Traffic Mapping

   This section describes the requirement for an LSR which is the Head-
   end of Diff-Serv-aware Traffic Engineering LSPs to map incoming
   traffic onto these LSPs.

   DS-TE must allow each Diff-Serv-aware Traffic Engineering LSP to be
   configured with the following attributes:
          - the set of Diff-Serv class(es) (more precisely "Ordered
   Aggregate") that it can transport in accordance with [DIFF-MPLS]
          - the Class-Type that must be taken into account so that
   Constraint Based Routing enforces the relevant bandwidth
   constraints.

   DS-TE must support mapping of incoming traffic onto Diff-Serv-aware
   Traffic Engineering LSPs in accordance with [DIFF-MPLS] so that only
   packets that belong to the (set of) Behavior Aggregate(s)
   transported over a given Diff-Serv-aware TE LSP should be mapped to
   that LSP. In particular, where the Head-end LSR is also the MPLS
   Edge LSR, determination of the Behavior Aggregate (and thus
   determination of the egress Diff-Serv-aware TE LSP) is based on the
   Diffserv Codepoint (DSCP) in the packet header.


2.8.    Dynamic Adjustment of Diff-Serv PHBs

   As discussed in section 1.4, DS-TE may support adjustment of Diff-
   Serv PHBs parameters (e.g. queue bandwidth) based on the amount of
   TE-LSPs established for each Class/Class-Type.

   Where this behavior is supported, it must allow for disabling via
   configuration (thus reverting to PHB treatment with static scheduler
   configuration independent of DS-TE operations).

   The dynamic adjustment must take account of the performance
   requirements of each class when computing required adjustments.


2.9.    Multiple TE Metrics



 Le Faucheur et. al                                                 11



            Requirements for Diff-Serv Traffic Engineering   June 2001

   This document does not specifically discuss the need for multiple TE
   metrics which is already work in progress. However, we note that DS-
   TE can make immediate use of multiple TE metrics once those are
   available simply by allowing TE-LSPs for different Classes of
   Service to be routed based on a different TE Metric.


3.      Solution Evaluation Criteria

   Multiple solutions can be thought of in order to support the Diff-
   Serv-aware TE Requirements discussed above. For example, some
   solutions may require that all current TE protocols syntax (IGP,
   RSVP-TE, CR-LDP) be extended in various ways to support multiple
   bandwidth constraints rather than the existing single aggregate
   bandwidth constraint. Alternatively, other solutions may keep the
   existing TE protocols syntax unchanged but modify their semantic to
   allow for the multiple bandwidth constraints.

   This section identifies the evaluation criteria that should be used
   to assess potential DS-TE solutions for selection.

3.1.    Satisfying detailed requirements

   The solution must address all the scenarios described in section 1
   and satisfy all the requirements listed in section 2.

3.2.    Flexibility

        -      number of Class Types that can be supported, compared to
               number identified in Requirements section
        -      number of Classes within a Class-Type


3.3.    Extendibility

        -      how far can the solution be extended in the future if
               requirements for more Class-Types are  identified in the
               future.


3.4.    Scalability

        -      impact on network scalability in what is propagated,
               processed, stored and computed (IGP signaling, IGP
               processing, IGP database, TE-Tunnel signaling ,...).
        -      how does scalability impact evolve with number of Class-
               Types/Classes actually deployed in a network. In
               particular, is it possible to keep overhead small for a
               large networks which only use a small number of Class-
               Types/Classes, while allowing higher number of Class-
               Types/Classes in smaller networks which can bear higher
               overhead)

 Le Faucheur et. al                                                 12



            Requirements for Diff-Serv Traffic Engineering   June 2001


3.5.    Backward compatibility/Migration

        -      backward compatibility/migration with/from existing TE
               mechanisms
        -      backward compatibility/migration when
               increasing/decreasing the number of Class-Types actually
               deployed in a given network.


4.      Security Considerations

   The solution developed to address the requirements defined in this
   document must address security aspects. DS-TE is not expected to add
   specific security requirements beyond those of Diff-Serv and
   existing TE.  Networks which employ diff-serv techniques might offer
   some protection between classes for denial of service attacks.
   Though depending on how the technology is employed, it is possible
   for some (lower scheduled) traffic to be more susceptible to traffic
   anomalies (which include denial of service attacks) occurring within
   other (higher scheduled) classes.


References

   [TE-REQ] Awduche et al, Requirements for Traffic Engineering over
   MPLS, RFC2702, September 1999.

   [TEWG-FW] Awduche et al, A Framework for Internet Traffic
   Engineering, draft-ietf-tewg-framework-04.txt, April 2001.

   [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF,
   draft-katz-yeung-ospf-traffic-04.txt, August 2001.

   [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
   ietf-isis-traffic-02.txt, September 2000.

   [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP
   Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001.

   [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft-
   ietf-mpls-diff-ext-09.txt, April 2001

   [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP",
   draft-ietf-mpls-cr-ldp-05.txt, February 2001

   [DIFF-NEW] Grossman, "New Terminology for Diffserv", work in
   progress, draft-ietf-diffserv-new-terms-04.txt, March 2001.





 Le Faucheur et. al                                                 13



            Requirements for Diff-Serv Traffic Engineering   June 2001

Authors' Address:

   Francois Le Faucheur
   Cisco Systems, Inc.
   Village d'Entreprise Green Side - Batiment T3
   400, Avenue de Roumanille
   06410 Biot-Sophia Antipolis
   France
   Phone: +33 4 97 23 26 19
   Email: flefauch@cisco.com

   Martin Tatham
   BT
   Adastral Park,
   Martlesham Heath,
   Ipswich IP5 3RE
   UK
   Phone: +44-1473-606349
   Email: martin.tatham@bt.com

   Thomas Telkamp
   Global Crossing
   Olympia 6
   1213 NP Hilversum
   The Netherlands
   Phone: +31 35 655 651
   E-mail: telkamp@gblx.net

   David Cooper
   Global Crossing
   960 Hamlin Court
   Sunnyvale, CA 94089
   USA
   Phone: +1 916 415 0437
   E-mail: dcooper@gblx.net

   Jim Boyle
   Level 3 Communications, LLC.
   1025 Eldorado Blvd.
   Broomfield, CO, 80021
   USA
   Email: jboyle@Level3.net

   Luca Martini
   Level 3 Communications, LLC.
   1025 Eldorado Blvd.
   Broomfield, CO, 80021
   USA
   Email: luca@level3.net




 Le Faucheur et. al                                                 14



            Requirements for Diff-Serv Traffic Engineering   June 2001

   Luyuan Fang
   AT&T Labs
   200 Laurel Avenue
   Middletown, New Jersey 07748
   USA
   Phone: +1 732 420-1921
   Email: luyuanfang@att.com

   Gerald R. Ash
   AT&T Labs
   200 Laurel Avenue
   Middletown, New Jersey 07748
   USA
   Phone: +1 732 420-4578
   Email: gash@att.com

   Wai Sum Lai
   AT&T Labs
   200 Laurel Avenue
   Middletown, New Jersey 07748
   USA
   Phone: +1 732 420-3712
   Email: wlai@att.com

   Pete Hicks
   CoreExpress, Inc
   12655 Olive Blvd, Suite 500
   St. Louis, MO 63141
   USA
   Phone: (314) 317-7504
   Email: pete.hicks@coreexpress.net

   Angela Chiu
   Celion Networks
   1 Sheila Drive, Suite 2
   Tinton Falls, NJ 07724
   Phone: +1-732 747 9987
   Email: angela.chiu@celion.com

   William Townsend
   Tenor Networks
   100 Nagog Park
   Acton, MA 01720
   Phone: +1-978-264-4900
   Email: btownsend@tenornetworks.com

   Thomas D. Nadeau
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA 01824
   Phone: +1-978-244-3051
   Email: tnadeau@cisco.com

 Le Faucheur et. al                                                 15



            Requirements for Diff-Serv Traffic Engineering   June 2001


   Darek Skalecki
   Nortel Networks
   3500 Carling Ave,
   Nepean K2H 8E9
   Phone: +1-613-765-2252
   Email: dareks@nortelnetworks.com














































 Le Faucheur et. al                                                 16