doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc3564.txt b/doc/rfc/rfc3564.txt
new file mode 100644
index 0000000..360a1a0
--- /dev/null
+++ b/doc/rfc/rfc3564.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                     F. Le Faucheur
+Request for Comments: 3564                           Cisco Systems, Inc.
+Category: Informational                                           W. Lai
+                                                                    AT&T
+                                                               July 2003
+
+
+       Requirements for Support of Differentiated Services-aware
+                     MPLS Traffic Engineering
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document presents Service Provider requirements for support of
+   Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering
+   (DS-TE).
+
+   Its objective is to provide guidance for the definition, selection
+   and specification of a technical solution addressing these
+   requirements.  Specification for this solution itself is outside the
+   scope of this document.
+
+   A problem statement is first provided.  Then, the document describes
+   example applications scenarios identified by Service Providers where
+   existing MPLS Traffic Engineering mechanisms fall short and
+   Diff-Serv-aware Traffic Engineering can address the needs.  The
+   detailed requirements that need to be addressed by the technical
+   solution are also reviewed.  Finally, the document identifies the
+   evaluation criteria that should be considered for selection and
+   definition of the technical solution.
+
+
+
+
+
+
+
+
+
+
+
+
+Le Faucheur & Lai            Informational                      [Page 1]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+Table of Contents
+
+   Specification Requirements .......................................  2
+   1.  Introduction .................................................  3
+       1.1.  Problem Statement ......................................  3
+       1.2.  Definitions ............................................  3
+       1.3.  Mapping of traffic to LSPs .............................  5
+   2.  Application Scenarios ........................................  6
+       2.1.  Scenario 1: Limiting Proportion of Classes on a Link ...  6
+       2.2.  Scenario 2: Maintain relative proportion of traffic ....  6
+       2.3.  Scenario 3: Guaranteed Bandwidth Services ..............  8
+   3.  Detailed Requirements for DS-TE ..............................  9
+       3.1.  DS-TE Compatibility ....................................  9
+       3.2.  Class-Types ............................................  9
+       3.3.  Bandwidth Constraints .................................. 11
+       3.4.  Preemption and TE-Classes .............................. 12
+       3.5.  Mapping of Traffic to LSPs ............................. 15
+       3.6.  Dynamic Adjustment of Diff-Serv PHBs ................... 15
+       3.7.  Overbooking ............................................ 16
+       3.8.  Restoration ............................................ 16
+   4.  Solution Evaluation Criteria ................................. 16
+       4.1.  Satisfying detailed requirements ....................... 17
+       4.2.  Flexibility ............................................ 17
+       4.3.  Extendibility .......................................... 17
+       4.4.  Scalability ............................................ 17
+       4.5.  Backward compatibility/Migration ....................... 17
+       4.6.  Bandwidth Constraints Model ............................ 18
+   5.  Security Considerations ...................................... 18
+   6.  Acknowledgment ............................................... 18
+   7.  Normative References ......................................... 18
+   8.  Informative References ....................................... 19
+   9.  Contributing Authors ......................................... 20
+   10. Editors' Addresses ........................................... 21
+   11. Full Copyright Statement ..................................... 22
+
+Specification Requirements
+
+   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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+Le Faucheur & Lai            Informational                      [Page 2]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+1.  Introduction
+
+1.1.  Problem Statement
+
+   Diff-Serv is used by some Service Providers to achieve scalable
+   network designs supporting multiple classes of services.
+
+   In some such Diff-Serv networks, where optimization of transmission
+   resources on a network-wide basis is not sought, MPLS Traffic
+   Engineering (TE) mechanisms may not be used.
+
+   In other networks, where optimization of transmission resources is
+   sought, Diff-Serv mechanisms [DIFF-MPLS] may be complemented by
+   MPLS Traffic Engineering mechanisms [TE-REQ] [ISIS-TE] [OSPF-TE]
+   [RSVP-TE] which operate on an aggregate basis across all
+   Diff-Serv classes of service.  In this case, Diff-Serv and MPLS TE
+   both provide their respective benefits.
+
+   To achieve fine-grained optimization of transmission resources and
+   further enhanced network performance and efficiency, as discussed in
+   [TEWG-FW], it may be desirable to perform traffic engineering at a
+   per-class level instead of at an aggregate level.  By mapping the
+   traffic from a given Diff-Serv class of service on a separate LSP, it
+   allows this traffic to utilize resources available to the given class
+   on both shortest paths and non-shortest paths, and follow paths that
+   meet engineering constraints which are specific to the given class.
+   This is what we refer to as "Diff-Serv-aware Traffic Engineering
+   (DS-TE)".
+
+   This document focuses exclusively on the specific environments which
+   would benefit from DS-TE.  Some examples include:
+
+     -    networks where bandwidth is scarce (e.g., transcontinental
+          networks)
+     -    networks with significant amounts of delay-sensitive traffic
+     -    networks where the relative proportion of traffic across
+          classes of service is not uniform
+
+   This document focuses on intra-domain operation.  Inter-domain
+   operation is not considered.
+
+1.2.  Definitions
+
+   For the convenience of the reader, relevant Diff-Serv ([DIFF-ARCH],
+   [DIFF-NEW] and [DIFF-PDB]) definitions are repeated herein.
+
+      Behavior Aggregate (BA): a collection of packets with the same
+      (Diff-Serv) codepoint crossing a link in a particular direction.
+
+
+
+Le Faucheur & Lai            Informational                      [Page 3]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+      Per-Hop-Behavior (PHB): the externally observable forwarding
+      behavior applied at a DS-compliant node to a Diff-Serv behavior
+      aggregate.
+
+      PHB Scheduling Class (PSC): A PHB group for which a common
+      constraint is that ordering of at least those packets belonging to
+      the same microflow must be preserved.
+
+      Ordered Aggregate (OA): a set of BAs that share an ordering
+      constraint.  The set of PHBs that are applied to this set of
+      Behavior Aggregates constitutes a PHB scheduling class.
+
+      Traffic Aggregate (TA): a collection of packets with a codepoint
+      that maps to the same PHB, usually in a DS domain or some subset
+      of a DS domain.  A traffic aggregate marked for the foo PHB is
+      referred to as the "foo traffic aggregate" or "foo aggregate"
+      interchangeably.  This generalizes the concept of Behavior
+      Aggregate from a link to a network.
+
+      Per-Domain Behavior (PDB): the expected treatment that an
+      identifiable or target group of packets will receive from
+      "edge-to-edge" of a DS domain.  A particular PHB (or, if
+      applicable, list of PHBs) and traffic conditioning requirements
+      are associated with each PDB.
+
+   We also repeat the following definition from [TE-REQ]:
+
+      Traffic Trunk: an aggregation of traffic flows of the same class
+      which are placed inside a Label Switched Path.
+
+   In the context of the present document, "flows of the same class" is
+   to be interpreted as "flows from the same Forwarding Equivalence
+   Class which are to be treated equivalently from the DS-TE
+   perspective".
+
+      We refer to the set of TAs corresponding to the set of PHBs of a
+      given PSC, as a {TA}PSC.  A given {TA}PSC will receive the
+      treatment of the PDB associated with the corresponding PSC.  In
+      this document, we also loosely refer to a {TA}PSC as a "Diff-Serv
+      class of service", or a "class of service".  As an example, the
+      set of packets within a DS domain with a codepoint that maps to
+      the EF PHB may form one {TA}PSC in that domain.  As another
+      example, the set of packets within a DS domain with a codepoint
+      that maps to the AF11 or AF12 or AF13 PHB may form another {TA}PSC
+      in that domain.
+
+
+
+
+
+
+Le Faucheur & Lai            Informational                      [Page 4]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+   We refer to the collection of packets which belong to a given Traffic
+   Aggregate and are associated with a given MPLS Forwarding Equivalence
+   Class (FEC) ([MPLS-ARCH]) as a <FEC/TA>.
+
+   We refer to the set of <FEC/TA> whose TAs belong to a given {TA}PSC
+   as a <FEC/{TA}PSC>.
+
+1.3.  Mapping of traffic to LSPs
+
+   A network may have multiple Traffic Aggregates (TAs) it wishes to
+   service.  Recalling from [DIFF-MPLS], there are several options on
+   how the set of <FEC/{TA}PSC> of a given FEC can be split into Traffic
+   Trunks for mapping onto LSPs when running MPLS Traffic Engineering.
+
+   One option is to not split this set of <FEC/{TA}PSC> so that each
+   Traffic Trunk comprises traffic from all the {TA}/PSC.  This option
+   is typically used when aggregate traffic engineering is deployed
+   using current MPLS TE mechanisms.  In that case, all the
+   <FEC/{TA}PSC> of a given FEC are routed collectively according to a
+   single shared set of constraints and will follow the same path.  Note
+   that the LSP transporting such a Traffic Trunk is, by definition, an
+   E-LSP as defined in [DIFF-MPLS].
+
+   Another option is to split the different <FEC/{TA}PSC> of a given FEC
+   into multiple Traffic Trunks on the basis of the {TA}PSC.  In other
+   words, traffic, from one given node to another, is split, based on
+   the "classes of service", into multiple Traffic Trunks which are
+   transported over separate LSP and can potentially follow different
+   paths through the network.  DS-TE takes advantage of this and
+   computes a separate path for each LSP.  In so doing, DS-TE can take
+   into account the specific requirements of the Traffic Trunk
+   transported on each LSP (e.g., bandwidth requirement, preemption
+   priority).  Moreover DS-TE can take into account the specific
+   engineering constraints to be enforced for these sets of Traffic
+   Trunks (e.g., limit all Traffic Trunks transporting a particular
+   {TA}PSC to x% of link capacity).  DS-TE achieves per LSP constraint
+   based routing with paths that match specific objectives of the
+   traffic while forming the corresponding Traffic Trunk.
+
+   For simplicity, and because this is the specific topic of this
+   document, the above paragraphs in this section only considered
+   splitting traffic of a given FEC into multiple Traffic Aggregates on
+   the basis of {TA}PSC.  However, it should be noted that, in addition
+   to this, traffic from every {TA}PSC may also be split into multiple
+   Traffic Trunks for load balancing purposes.
+
+
+
+
+
+
+Le Faucheur & Lai            Informational                      [Page 5]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+2.  Application Scenarios
+
+2.1.  Scenario 1: Limiting Proportion of Classes on a Link
+
+   An IP/MPLS network may need to carry a significant amount of VoIP
+   traffic compared to its link capacity.  For example, 10,000
+   uncompressed calls at 20ms packetization result in about 1Gbps of IP
+   traffic, which is significant on an OC-48c based network.  In case of
+   topology changes such as link/node failure, VoIP traffic levels can
+   even approach the full bandwidth on certain links.
+
+   For delay/jitter reasons, some network administrators see it as
+   undesirable to carry more than a certain percentage of VoIP traffic
+   on any link.  The rest of the available link bandwidth can be used to
+   route other "classes of service" corresponding to delay/jitter
+   insensitive traffic (e.g.,  Best Effort Internet traffic).  The exact
+   determination of this "certain" percentage is outside the scope of
+   this requirements document.
+
+   During normal operations, the VoIP traffic should be able to preempt
+   other "classes of service" (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 link utilization ratio/percentage of the VoIP class.
+
+   Existing TE mechanisms only allow constraint based routing of traffic
+   based on a single bandwidth constraint common to all "classes of
+   service", which does not satisfy the needs described here.  This
+   leads to the requirement for DS-TE to be able to enforce a different
+   bandwidth constraint for different "classes of service".  In the
+   above example, the bandwidth constraint to be enforced for VoIP
+   traffic may be the "certain" percentage of each link capacity, while
+   the bandwidth constraint to be enforced for the rest of the "classes
+   of service" might have their own constraints or have access to the
+   rest of the link capacity.
+
+2.2.  Scenario 2: Maintain relative proportion of traffic
+
+   Suppose an IP/MPLS network supports 3 "classes of service".  The
+   network administrator wants to perform Traffic Engineering to
+   distribute the traffic load.  Also assume that proportion across
+   "classes of service" varies significantly depending on the
+   source/destination POPs.
+
+
+
+
+
+
+
+
+Le Faucheur & Lai            Informational                      [Page 6]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+   With existing TE mechanisms, the proportion of traffic from each
+   "class of service" on a given link will vary depending on multiple
+   factors including:
+
+   - in which order the different TE-LSPs are established
+   - the preemption priority associated with the different TE-LSPs
+   - link/node failure situations
+
+   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 "class of service" 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
+   service".  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 of service" routed over a link matches the Diff-Serv
+   scheduler configuration on that link to 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 of service" (1,2,3)
+   respectively.  The administrator would then split the traffic into
+   separate Traffic Trunks for each "class of service" and associate a
+   bandwidth to each LSP transporting those Traffic Trunks.  The network
+   administrator may also want to configure preemption priorities of
+   each LSP in order to give highest restoration priority to the highest
+   priority "class of service" and medium priority to the medium "class
+   of service".  Then DS-TE could ensure that after a failure, "class of
+   service" 1 traffic would be rerouted with first access at link
+   capacity without exceeding its service rate of 45% of the link
+   bandwidth.  "Class of service" 2 traffic would be rerouted with
+   second access at the link capacity without exceeding its allotment.
+   Note that where "class of service" 3 is the Best-Effort service, the
+   requirement on DS-TE may be to ensure that the total amount of
+   traffic routed across all "classes of service" 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
+   of service" 1 and "class of service" 2 traffic).
+
+   In this scenario, DS-TE would allow for the maintenance of a more
+   steady distribution of "classes of service", even during rerouting.
+   This would rely on the required capability of DS-TE to adjust the
+   amount of traffic of each "class of service"  routed on a link based
+   on the configuration of the scheduler and the amount of bandwidth
+   available for each "class of service".
+
+
+
+
+Le Faucheur & Lai            Informational                      [Page 7]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+   Alternatively, some network administrators may want to solve the
+   problem by having the scheduler dynamically adjusted based on the
+   amount of bandwidth of the LSPs admitted for each "class of service".
+   This is an optional additional requirement on the DS-TE solution.
+
+2.3.  Scenario 3: 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 an egress port.  The goal is to ensure that all the
+   "guaranteed" traffic under the scope of a subscribed service level
+   specification, will be delivered within the tolerances of this
+   service level specification.
+
+   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 a 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 for the rest of the traffic (i.e.,
+   non-guaranteed traffic) which would require that constraint based
+   routing is also capable of enforcing a different 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.
+
+
+
+
+
+
+
+
+
+Le Faucheur & Lai            Informational                      [Page 8]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+3.  Detailed Requirements for DS-TE
+
+   This section specifies the functionality that the above scenarios
+   require out of the DS-TE solution.  Actual technical protocol
+   mechanisms and procedures to achieve such functionality are outside
+   the scope of this document.
+
+3.1.  DS-TE Compatibility
+
+   Since DS-TE may impact scalability (as discussed later in this
+   document) and operational practices, DS-TE is expected to be used
+   when existing TE mechanisms combined with Diff-Serv cannot address
+   the network design requirements (i.e., where constraint based routing
+   is required and where it needs to enforce different bandwidth
+   constraints for different "classes of service", such as in the
+   scenarios described above in section 2).  Where the benefits of DSTE
+   are only required in a topological subset of their network, some
+   network operators may wish to only deploy DS-TE in this topological
+   subset.
+
+   Thus, the DS-TE solution MUST be developed in such a way that:
+
+   (i)    it raises no interoperability issues with existing deployed TE
+          mechanisms.
+   (ii)   it allows DS-TE deployment to the required level of
+          granularity and scope (e.g., only in a subset of the topology,
+          or only for the number of classes required in the considered
+          network)
+
+3.2.  Class-Types
+
+   The fundamental requirement for DS-TE is to be able to enforce
+   different bandwidth constraints for different sets of Traffic Trunks.
+
+   [TEWG-FW] introduces the concept of Class-Types when discussing
+   operations of MPLS Traffic Engineering in a Diff-Serv environment.
+
+   We refine this definition into the following:
+
+            Class-Type (CT): the set of Traffic Trunks crossing a link,
+            that is governed by a specific set of Bandwidth constraints.
+            CT is used for the purposes of link bandwidth allocation,
+            constraint based routing and admission control.  A given
+            Traffic Trunk belongs to the same CT on all links.
+
+   Note that different LSPs transporting Traffic Trunks from the same CT
+   may be using the same or different preemption priorities as explained
+   in more details in section 3.4 below.
+
+
+
+Le Faucheur & Lai            Informational                      [Page 9]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+   Mapping of {TA}PSC to Class-Types is flexible.  Different {TA}PSC can
+   be mapped to different CTs, multiple {TA}PSC can be mapped to the
+   same CT and one {TA}PSC can be mapped to multiple CTs.
+
+   For illustration purposes, let's consider the case of a network
+   running 4 Diff-Serv PDBs which are respectively based on the EF PHB
+   [EF], the AF1x PSC [AF], the AF2x PSC and the Default (i.e.,
+   Best-Effort) PHB [DIFF-FIELD].  The network administrator may decide
+   to deploy DS-TE in the following way:
+
+         o  from every DS-TE Head-end to every DS-TE Tail-end, split the
+            traffic into 4 Traffic Trunks: one for traffic of each
+            {TA}PSC
+         o  because the QoS objectives for the AF1x PDB and for the AF2x
+            PDB may be of similar nature (e.g., both targeting low loss
+            albeit at different levels perhaps), the same (set of)
+            Bandwidth Constraint(s) may be applied collectively over the
+            AF1x Traffic Trunks and the AF2x Traffic Trunks.  Thus, the
+            network administrator may only define three CTs: one for the
+            EF Traffic Trunks, one for the AF1x and AF2x Traffic Trunks
+            and one for the Best Effort Traffic Trunks.
+
+   As another example of mapping of {TA}PSC to CTs, a network operator
+   may split the traffic from the {TA}PSC associated with EF into two
+   different sets of traffic trunks, so that each set of traffic trunks
+   is subject to different constraints on the bandwidth it can access.
+   In this case, two distinct CTs are defined for the EF {TA}PSC
+   traffic:  one for the traffic subset subject to the first (set of)
+   bandwidth constraint(s), the other for the traffic subset subject to
+   the second (set of) bandwidth constraint(s).
+
+   The DS-TE solution MUST support up to 8 CTs.  Those are referred to
+   as CTc, 0 <= c <= MaxCT-1 = 7.
+   The DS-TE solution MUST be able to enforce a different set of
+   Bandwidth Constraints for each CT.
+   A DS-TE implementation MUST support at least 2 CTs, and MAY support
+   up to 8 CTs.
+
+   In a given network, the DS-TE solution MUST NOT require the network
+   administrator to always deploy the maximum number of CTs.  The DS-TE
+   solution MUST allow the network administrator to deploy only the
+   number of CTs actually utilized.
+
+
+
+
+
+
+
+
+
+Le Faucheur & Lai            Informational                     [Page 10]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+3.3.  Bandwidth Constraints
+
+   We refer to a Bandwidth Constraint Model as the set of rules
+   defining:
+
+   - the maximum number of Bandwidth Constraints; and
+   - which CTs each Bandwidth Constraint applies to and how.
+
+   By definition of CT, each CT is assigned either a Bandwidth
+   Constraint, or a set of Bandwidth Constraints.
+
+   We refer to the Bandwidth Constraints as BCb, 0 <= b <= MaxBC-1
+
+   For a given Class-Type CTc, 0 <= c <= MaxCT-1, let us define
+   "Reserved(CTc)" as the sum of the bandwidth reserved by all
+   established LSPs which belong to CTc.
+
+   Different models of Bandwidth Constraints are conceivable for control
+   of the CTs.
+
+   For example, a model with one separate Bandwidth Constraint per CT
+   could be defined.  This model is referred to as the "Maximum
+   Allocation Model" and is defined by:
+
+        - MaxBC= MaxCT
+        - for each value of b in the range 0 <= b <= (MaxCT - 1):
+               Reserved (CTb) <= BCb
+
+   For illustration purposes, on a link of 100 unit of bandwidth where
+   three CTs are used, the network administrator might then configure
+   BC0=20, BC1= 50, BC2=30 such that:
+
+   - All LSPs supporting Traffic Trunks from CT2 use no more than 30
+     (e.g., Voice <= 30)
+   - All LSPs supporting Traffic Trunks from CT1 use no more than 50
+     (e.g., Premium Data <= 50)
+   - All LSPs supporting Traffic Trunks from CT0 use no more than 20
+     (e.g.,  Best Effort <= 20)
+
+   As another example, a "Russian Doll" model of Bandwidth Constraints
+   may be defined whereby:
+
+        - MaxBC= MaxCT
+        - for each value of b in the range 0 <= b <= (MaxCT - 1):
+               SUM (Reserved (CTc)) <= BCb,
+               for all "c" in the range  b <= c <= (MaxCT - 1)
+
+
+
+
+
+Le Faucheur & Lai            Informational                     [Page 11]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+   For illustration purposes, on a link of 100 units of bandwidth where
+   three CTs are used, the network administrator might then configure
+   BC0=100, BC1= 80, BC2=60 such that:
+
+   - All LSPs supporting Traffic Trunks from CT2 use no more than 60
+     (e.g., Voice <= 60)
+   - All LSPs supporting Traffic Trunks from CT1 or CT2 use no more than
+     80 (e.g., Voice + Premium Data <= 80)
+   - All LSPs supporting Traffic Trunks from CT0 or CT1 or CT2 use no
+     more than 100 (e.g., Voice + Premium Data + Best Effort <= 100).
+
+   Other Bandwidth Constraints model can also be conceived.  Those could
+   involve arbitrary relationships between BCb and CTc.  Those could
+   also involve additional concepts such as associating minimum
+   reservable bandwidth to a CT.
+
+   The DS-TE technical solution MUST have the capability to support
+   multiple Bandwidth Constraints models.  The DS-TE technical solution
+   MUST specify at least one bandwidth constraint model and MAY specify
+   multiple Bandwidth Constraints models.  Additional Bandwidth
+   Constraints models MAY also be specified at a later stage if deemed
+   useful based on operational experience from DS-TE deployments.  The
+   choice of which (or which set of) Bandwidth Constraints model(s) is
+   to be supported by a given DS-TE implementation, is an implementation
+   choice.  For simplicity, a network operator may elect to use the same
+   Bandwidth Constraints Model on all the links of his/her network.
+   However, if he/she wishes/needs to do so, the network operator may
+   elect to use different Bandwidth Constraints models on different
+   links in a given network.
+
+   Regardless of the Bandwidth Constraint Model, the DS-TE solution MUST
+   allow support for up to 8 BCs.
+
+3.4.  Preemption and TE-Classes
+
+   [TEWG-FW] defines the notion of preemption and preemption priority.
+   The DS-TE solution MUST retain full support of such preemption.
+   However, a network administrator preferring not to use preemption for
+   user traffic MUST be able to disable the preemption mechanisms
+   described below.
+
+   The preemption attributes defined in [TE-REQ] MUST be retained and
+   applicable across all Class Types.  The preemption attributes of
+   setup priority and holding priority MUST retain existing semantics,
+   and in particular these semantics MUST not be affected by the Ordered
+   Aggregate transported by the LSP or by the LSP's Class Type.  This
+   means that if LSP1 contends with LSP2 for resources, LSP1 may preempt
+   LSP2 if LSP1 has a higher set-up preemption priority (i.e., lower
+
+
+
+Le Faucheur & Lai            Informational                     [Page 12]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+   numerical priority value) than LSP2's holding preemption priority
+   regardless of LSP1's OA/CT and LSP2's OA/CT.
+
+   We introduce the following definition:
+
+       TE-Class: A pair of:
+               (i)    a Class-Type
+               (ii)   a preemption priority allowed for that
+                      Class-Type.  This means that an LSP transporting a
+                      Traffic Trunk from that Class-Type can use that
+                      preemption priority as the set-up priority, as the
+                      holding priority or both.
+
+   Note that by definition:
+
+   - for a given Class-Type, there may be one or multiple
+     TE-classes using that Class-Type, each using a different preemption
+     priority
+   - for a given preemption priority, there may be one or multiple
+     TE-Class(es) using that preemption priority, each using a different
+     Class-Type.
+
+   The DS-TE solution MUST allow all LSPs transporting Traffic Trunks of
+   a given Class-Type to use the same preemption priority.  In other
+   words, the DS-TE solution MUST allow a Class-Type to be used by
+   single TE-Class.  This effectively allows the network administrator
+   to ensure that no preemption happens within that Class-Type, when so
+   desired.
+
+   As an example, the DS-TE solution MUST allow the network
+   administrator to define a Class-Type comprising a single TE-class
+   using preemption 0.
+
+   The DS-TE solution MUST allow two LSPs transporting Traffic Trunks of
+   the same Class-Type to use different preemption priorities, and allow
+   the LSP with higher (numerically lower) set-up priority to preempt
+   the LSP with lower (numerically higher) holding priority when they
+   contend for resources.  In other words, the DS-TE solution MUST allow
+   multiple TE-Classes to be defined for a given Class-Type. This
+   effectively allows the network administrator to enable preemption
+   within a Class-Type, when so desired.
+
+   As an example, the DS-TE solution MUST allow the network
+   administrator to define a Class-Type comprising three TE-Classes; one
+   using preemption 0, one using preemption 1 and one using preemption
+   4.
+
+
+
+
+
+Le Faucheur & Lai            Informational                     [Page 13]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+   The DS-TE solution MUST allow two LSPs transporting Traffic Trunks
+   from different Class-Types to use different preemption priorities,
+   and allow the LSP with higher setup priority to preempt the one with
+   lower holding priority when they contend for resources.
+
+   As an example, the DS-TE solution MUST allow the network
+   administrator to define two Class-Types (CT0 and CT1) each comprising
+   two TE-Classes where say:
+
+      -one TE-Class groups CT0 and preemption 0
+      -one TE-Class groups CT0 and preemption 2
+      -one TE-Class groups CT1 and preemption 1
+      -one TE-Class groups CT1 and preemption 3
+
+   The network administrator would then, in particular, be able to:
+
+   - transport a CT0 Traffic Trunk over an LSP with setup priority=0 and
+     holding priority=0
+   - transport a CT0 Traffic Trunk over an LSP with setup priority=2 and
+     holding priority=0
+   - transport a CT1 Traffic Trunk over an LSP with setup priority=1 and
+     holding priority=1
+   - transport a CT1 Traffic Trunk over an LSP with setup priority=3 and
+     holding priority=1.
+
+   The network administrator would then, in particular, NOT be able to:
+
+   - transport a CT0 Traffic Trunk over an LSP with setup priority=1 and
+     holding priority=1
+   - transport a CT1 Traffic Trunk over an LSP with setup priority=0 and
+     holding priority=0
+
+   The DS-TE solution MUST allow two LSPs transporting Traffic Trunks
+   from different Class-Types to use the same preemption priority.  In
+   other words, the DS-TE solution MUST allow TE-classes using different
+   CTs to use the same preemption priority.  This effectively allows the
+   network administrator to ensure that no preemption happens across
+   Class-Types, if so desired.
+
+   As an example, the DS-TE solution MUST allow the network
+   administrator to define three Class-Types (CT0, CT1 and CT2) each
+   comprising one TE-Class which uses preemption 0.  In that case, no
+   preemption will ever occur.
+
+   Since there are 8 preemption priorities and up to 8 Class-Types,
+   there could theoretically be up to 64 TE-Classes in a network.  This
+   is felt to be beyond current practical requirements.  The current
+   practical requirement is that the DS-TE solution MUST allow support
+
+
+
+Le Faucheur & Lai            Informational                     [Page 14]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+   for up to 8 TE-classes.  The DS-TE solution MUST allow these
+   TE-classes to comprise any arbitrary subset of 8 (or less) from the
+   (64) possible combinations of (8) Class-Types and (8) preemption
+   priorities.
+
+   As with existing TE, an LSP which gets preempted is torn down at
+   preemption time.  The Head-end of the preempted LSP may then attempt
+   to reestablish that LSP, which involves re-computing a path by
+   Constraint Based Routing based on updated available bandwidth
+   information and then signaling for LSP establishment along the new
+   path.  It is to be noted that there may be cases where the preempted
+   LSP cannot be reestablished (e.g., no possible path satisfying LSP
+   bandwidth constraints as well as other constraints).  In such cases,
+   the Head-end behavior is left to implementation.  It may involve
+   periodic attempts at reestablishing the LSP, relaxing of the LSP
+   constraints, or other behaviors.
+
+3.5.  Mapping of Traffic to LSPs
+
+   The DS-TE solution MUST allow operation over E-LSPs onto which a
+   single <FEC/{TA}PSC> is transported.
+
+   The DS-TE solution MUST allow operation over L-LSPs.
+
+   The DS-TE solution MAY allow operation over E-LSPs onto which
+   multiple <FEC/{TA}PSC> of a given FEC are transported, under the
+   condition that those multiple <FEC/{TA}PSC> can effectively be
+   treated by DS-TE as a single atomic traffic trunk (in particular this
+   means that those multiple <FEC/{TA}PSC> are routed as a whole based
+   on a single collective bandwidth requirement, a single affinity
+   attribute, a single preemption level, a single Class-Type, etc.).  In
+   that case, it is also assumed that the multiple {TA}PSCs are grouped
+   together in a consistent manner throughout the DS-TE domain (e.g., if
+   <FECx/{TA}PSC1> and <FECx/{TA}PSC2> are transported together on an
+   E-LSP, then there will not be any L-LSP transporting <FECy/{TA}PSC1>
+   or <FECy/{TA}PSC2> on its own, and there will not be any E-LSP
+   transporting <FECz/{TA}PSC1> and/or <FECz/{TA}PSC2> with
+   <FECz/{TA}PSC3>).
+
+3.6.  Dynamic Adjustment of Diff-Serv PHBs
+
+   As discussed in section 2.2, the DS-TE solution MAY support
+   adjustment of Diff-Serv PHBs parameters (e.g., queue bandwidth) based
+   on the amount of TE-LSPs established for each OA/Class-Type.  Such
+   dynamic adjustment is optional for DS-TE implementations.
+
+
+
+
+
+
+Le Faucheur & Lai            Informational                     [Page 15]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+   Where this dynamic adjustment is supported, it MUST allow for
+   disabling via configuration (thus reverting to PHB treatment with
+   static scheduler configuration independent of DS-TE operations).  It
+   MAY involve a number of configurable parameters which are outside the
+   scope of this specification.  Those MAY include configurable
+   parameters controlling how scheduling resources (e.g., service rates)
+   need to be apportioned across multiple OAs when those belong to the
+   same Class-Type and are transported together on the same E-LSP.
+
+   Where supported, the dynamic adjustment MUST take account of the
+   performance requirements of each PDB when computing required
+   adjustments.
+
+3.7.  Overbooking
+
+   Existing TE mechanisms allow overbooking to be applied on LSPs for
+   Constraint Based Routing and admission control.  Historically, this
+   has been achieved in TE deployment through factoring overbooking
+   ratios at the time of sizing the LSP bandwidth and/or at the time of
+   configuring the Maximum Reservable Bandwidth on links.
+
+   The DS-TE solution MUST also allow overbooking and MUST effectively
+   allow different overbooking ratios to be enforced for different CTs.
+
+   The DS-TE solution SHOULD optionally allow the effective overbooking
+   ratio of a given CT to be tweaked differently in different parts of
+   the network.
+
+3.8.  Restoration
+
+   With existing TE, restoration policies use standard priority
+   mechanisms such as, for example, the preemption priority to
+   effectively control the order/importance of LSPs for restoration
+   purposes.
+
+   The DS-TE solution MUST ensure that similar application of the use of
+   standard priority mechanisms for implementation of restoration policy
+   are not prevented since those are expected to be required for
+   achieving the survivability requirements of DS-TE networks.
+
+   Further discussion of restoration requirements are presented in the
+   output document of the TEWG Requirements Design Team [SURVIV-REQ].
+
+4.  Solution Evaluation Criteria
+
+   A range of solutions is possible for the support of the DS-TE
+   requirements discussed above.  For example, some solutions may
+   require that all current TE protocols syntax (IGP, RSVP-TE,) be
+
+
+
+Le Faucheur & Lai            Informational                     [Page 16]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+   extended in various ways.  For instance, current TE protocols could
+   be modified 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 semantics to allow for the multiple bandwidth
+   constraints.
+
+   This section identifies the evaluation criteria that MUST be used to
+   assess potential DS-TE solutions for selection.
+
+4.1.  Satisfying detailed requirements
+
+   The solution MUST address all the scenarios described in section 2
+   and satisfy all the requirements listed in section 3.
+
+4.2.  Flexibility
+
+   -  number of Class-Types that can be supported, compared to number
+      identified in Requirements section
+   -  number of PDBs within a Class-Type
+
+4.3.  Extendibility
+
+   -  how far can the solution be extended in the future if requirements
+      for more Class-Types are identified in the future.
+
+4.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/PDBs 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/PDBs, while allowing higher number of
+      Class-Types/PDBs in smaller networks which can bear higher
+      overhead)
+
+4.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.
+
+
+
+
+
+
+
+Le Faucheur & Lai            Informational                     [Page 17]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+4.6.  Bandwidth Constraints Model
+
+   Work is currently in progress to investigate the performance and
+   trade-offs of different operational aspects of Bandwidth Constraints
+   models (for example see [BC-MODEL], [BC-CONS] and [MAR]).  In this
+   investigation, at least the following criteria are expected to be
+   considered:
+
+       (1) addresses the scenarios in Section 2
+       (2) works well under both normal and overload conditions
+       (3) applies equally when preemption is either enabled or disabled
+       (4) minimizes signaling load processing requirements
+       (5) maximizes efficient use of the network
+       (6) Minimizes implementation and deployment complexity.
+
+   In selection criteria (2), "normal condition" means that the network
+   is attempting to establish a volume of DS-TE LSPs for which it is
+   designed; "overload condition" means that the network is attempting
+   to establish a volume of DS-TE LSPs beyond the one it is designed
+   for; "works well" means that under these conditions, the network
+   should be able to sustain the expected performance, e.g., under
+   overload it is x times worse than its normal performance.
+
+5.  Security Considerations
+
+   The solution developed to address the DS-TE requirements defined in
+   this document MUST address security aspects.  DS-TE does not raise
+   any specific additional security requirements beyond the existing
+   security requirements of MPLS TE and Diff-Serv.  The solution MUST
+   ensure that the existing security mechanisms (including those
+   protecting against DOS attacks) of MPLS TE and Diff-Serv are not
+   compromised by the protocol/procedure extensions of the DS-TE
+   solution or otherwise MUST provide security mechanisms to address
+   this.
+
+6.  Acknowledgment
+
+   We thank David Allen for his help in aligning with up-to-date
+   Diff-Serv terminology.
+
+7.  Normative References
+
+   [AF]         Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
+                "Assured Forwarding PHB Group", RFC 2597, June 1999.
+
+   [DIFF-ARCH]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
+                and W. Weiss,  "An Architecture for Differentiated
+                Services", RFC 2475, December 1998.
+
+
+
+Le Faucheur & Lai            Informational                     [Page 18]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+   [DIFF-FIELD] Nichols, K., Blake, S., Baker, F. and D. Black,
+                "Definition of the Differentiated Services Field (DS
+                Field) in the IPv4 and IPv6 Headers", RFC 2474, December
+                1998.
+
+   [MPLS-ARCH]  Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
+                Label Switching Architecture", RFC 3031, January 2001.
+
+   [DIFF-MPLS]  Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
+                Vaananen, P., Krishnan, R., Cheval, P. and J. Heinanen,
+                "Multi-Protocol Label Switching (MPLS) Support of
+                Differentiated Services", RFC 3270, May 2002.
+
+   [DIFF-NEW]   Grossman, D., "New Terminology and Clarifications for
+                Diffserv", RFC 3260, April 2002.
+
+   [EF]         Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
+                Boudec, J.Y., Davari, S., Courtney, W., Firioiu, V. and
+                D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
+                Behavior)", RFC 3246, March 2002.
+
+   [TEWG-FW]    Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X.
+                Xiao, "Overview and Principles of Internet Traffic
+                Engineering", RFC 3272, May 2002.
+
+   [TE-REQ]     Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
+                McManus, "Requirements for Traffic Engineering over
+                MPLS", RFC 2702, September 1999.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+8.  Informative References
+
+   [DIFF-PDB]   Nichols, K. and B. Carpenter, "Definition of
+                Differentiated Services Per Domain Behaviors and Rules
+                for their Specification", RFC 3086, April 2001.
+
+   [ISIS-TE]    Smit, Li, "IS-IS extensions for Traffic Engineering",
+                Work in Progress, December 2002.
+
+   [OSPF-TE]    Katz, et al., "Traffic Engineering Extensions to OSPF",
+                Work in Progress, October 2002.
+
+   [RSVP-TE]    Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
+                and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+                Tunnels", RFC 3209, December 2001.
+
+
+
+
+Le Faucheur & Lai            Informational                     [Page 19]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+   [SURVIV-REQ] Lai, W. and D. McDysan, "Network Hierarchy and
+                Multilayer Survivability", RFC 3386, November 2002.
+
+   [BC-MODEL]   Lai, W., "Bandwidth Constraints Models for
+                Diffserv-aware MPLS Traffic Engineering: Performance
+                Evaluation", Work in Progress, June 2002.
+
+   [BC-CONS]    F. Le Faucheur, "Considerations on Bandwidth Constraints
+                Models for DS-TE", Work in Progress, June 2002.
+
+   [MAR]        Ash, J., "Max Allocation with Reservation Bandwidth
+                Constraint Model for MPLS/DiffServ TE & Performance
+                Comparisons", Work in Progress, May 2003.
+
+9.  Contributing Authors
+
+   This document was the collective work of several people.  The text
+   and content of this document was contributed by the editors and the
+   co-authors listed below.  (The contact information for the editors
+   appears below.)
+
+   Martin Tatham                        Thomas Telkamp
+   BT                                   Global Crossing
+   Adastral Park, Martlesham Heath,     Oudkerkhof 51,  3512 GJ Utrecht
+   Ipswich IP5 3RE, UK                  The Netherlands
+   Phone: +44-1473-606349               Phone: +31 30 238 1250
+   EMail: martin.tatham@bt.com          EMail: telkamp@gblx.net
+
+   David Cooper                         Jim Boyle
+   Global Crossing                      Protocol Driven Networks, Inc.
+   960 Hamlin Court                     1381 Kildaire Farm Road #288
+   Sunnyvale, CA 94089, USA             Cary, NC 27511, USA
+   Phone: (916) 415-0437                Phone: (919) 852-5160
+   EMail: dcooper@gblx.net              EMail: jboyle@pdnets.com
+
+   Luyuan Fang                          Gerald R. Ash
+   AT&T Labs                            AT&T Labs
+   200 Laurel Avenue                    200 Laurel Avenue
+   Middletown, New Jersey 07748, USA    Middletown, New Jersey 07748,USA
+   Phone: (732) 420-1921                Phone: (732) 420-4578
+   EMail: luyuanfang@att.com            EMail: gash@att.com
+
+
+
+
+
+
+
+
+
+
+Le Faucheur & Lai            Informational                     [Page 20]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+   Pete Hicks                           Angela Chiu
+   CoreExpress, Inc                     AT&T Labs-Research
+   12655 Olive Blvd, Suite 500          200 Laurel Ave.  Rm A5-1F13
+   St. Louis, MO 63141, USA             Middletown, NJ 07748, USA
+   Phone: (314) 317-7504                Phone: (732) 420-9061
+   EMail: pete.hicks@coreexpress.net    EMail: chiu@research.att.com
+
+   William Townsend                     Thomas D. Nadeau
+   Tenor Networks                       Cisco Systems, Inc.
+   100 Nagog Park                       300 Beaver Brook Road
+   Acton, MA 01720, USA                 Boxborough, MA  01719
+   Phone: +1 978-264-4900               Phone: +1-978-936-1470
+   EMail:btownsend@tenornetworks.com    EMail: tnadeau@cisco.com
+
+   Darek Skalecki
+   Nortel Networks
+   3500 Carling Ave,
+   Nepean K2H 8E9,
+   Phone: (613) 765-2252
+   EMail: dareks@nortelnetworks.com
+
+10.  Editors' Addresses
+
+   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
+
+
+   Wai Sum Lai
+   AT&T Labs
+   200 Laurel Avenue
+   Middletown, New Jersey 07748, USA
+
+   Phone: (732) 420-3712
+   EMail: wlai@att.com
+
+
+
+
+
+
+
+
+
+
+
+Le Faucheur & Lai            Informational                     [Page 21]
+
+RFC 3564          Requirements for Diff-Serv-aware TE          July 2003
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Faucheur & Lai            Informational                     [Page 22]
+