| < draft-ietf-tewg-diff-te-reqts-06.txt | draft-ietf-tewg-diff-te-reqts-07.txt > | |||
|---|---|---|---|---|
| A new Request for Comments is now available in online RFC libraries. | ||||
| Francois Le Faucheur, Editor | RFC 3564 | |||
| Cisco Systems, Inc. | ||||
| Waisum Lai, Co-editor | ||||
| AT&T | ||||
| IETF Internet Draft | ||||
| Expires: March, 2003 | ||||
| Document: draft-ietf-tewg-diff-te-reqts-06.txt September 2002 | ||||
| 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 | ||||
| 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). | ||||
| 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 is required. 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, et. al 1 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| 1. Introduction | ||||
| 1.1. Problem Statement | ||||
| Diff-Serv is becoming prominent in providing scalable network | ||||
| designs supporting multiple classes of services. | ||||
| In some Diff-Serv networks where optimization of transmission | ||||
| resources on a network-wide basis is not sought, MPLS Traffic | ||||
| Engineering (TE) mechanisms may simply not be used. | ||||
| In other networks, where optimization of transmission resources is | ||||
| sought, Diff-Serv mechanisms [DIFF-MPLS] need to 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 classes of service. In this case, Diff-Serv and | ||||
| MPLS TE both provide their respective benefits. | ||||
| Where fine-grained optimization of transmission resources is sought, | ||||
| it is necessary 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 | ||||
| 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 path 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 Diffserv ([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 et. al 2 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| 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. | ||||
| 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. We also loosely refer to a {TA}PSC as a | ||||
| Diff-Serv class of service, or class-of service. | ||||
| 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) 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 | ||||
| Le Faucheur et. al 3 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| <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 a given node to another given node, is | ||||
| split based on the classes of service, into multiple Traffic Trunks | ||||
| which are transported over separate LSPs, which can potentially | ||||
| follow a different path through the network. DS-TE precisely takes | ||||
| advantage of this fact and indeed 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 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). In brief, | ||||
| DS-TE achieves per LSP constraint based routing with paths that | ||||
| tightly match the specific objectives of the traffic 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 must be noted that, in addition to | ||||
| this, traffic from every {TA}PSC may also be split into multiple | ||||
| Traffic Trunks for load balancing purposes. | ||||
| 2. Contributing Authors | ||||
| This document was the collective work of several. 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 in Section 9, and is not repeated 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 | ||||
| Le Faucheur et. al 4 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| 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 | ||||
| Pete Hicks Angela Chiu | ||||
| CoreExpress, Inc Celion Networks | ||||
| 12655 Olive Blvd, Suite 500 1 Sheila Drive, Suite 2 | ||||
| St. Louis, MO 63141, USA Tinton Falls, NJ 07724, USA | ||||
| Phone: (314) 317-7504 Phone: (732) 747-9987 | ||||
| Email: pete.hicks@coreexpress.net Email: angela.chiu@celion.com | ||||
| William Townsend Thomas D. Nadeau | ||||
| Tenor Networks Cisco Systems, Inc. | ||||
| 100 Nagog Park 250 Apollo Drive | ||||
| Acton, MA 01720, USA Chelmsford, MA 01824, USA | ||||
| Phone: +1 978-264-4900 Phone: (978) 244-3051 | ||||
| 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 | ||||
| 3. Application Scenarios | ||||
| 3.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 it is 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 | ||||
| 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 traffic (if these other classes are designated as | ||||
| preemptable and they have lower preemption priority), | ||||
| Le Faucheur et. al 5 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| 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, 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 traffic. 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 | ||||
| might have their own constraints or have access to the rest of the | ||||
| link capacity. | ||||
| 3.2. Scenario 2: 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. | ||||
| With existing TE 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 | ||||
| - 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 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 split the traffic into separate Traffic | ||||
| Trunks for each class 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 and | ||||
| medium priority to the medium class. Then DS-TE could ensure that | ||||
| after a failure, class 1 traffic would be rerouted with first access | ||||
| Le Faucheur et. al 6 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| 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 may be 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). | ||||
| In this scenario, DS-TE allowed for the maintenance of a more steady | ||||
| distribution of 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 | ||||
| and the amount of bandwidth available for each class. | ||||
| 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. This is an | ||||
| additional requirement on DS-TE. | ||||
| 3.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 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 a different bandwidth | ||||
| constraint, which would be less stringent than the one for | ||||
| guaranteed traffic. | ||||
| Le Faucheur et. al 7 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| 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. | ||||
| 4. Detailed Requirements for DS-TE | ||||
| This section specifies the functionality that the above scenarios | ||||
| require out of DS-TE implementations. Actual technical protocol | ||||
| mechanisms and procedures to achieve such functionality are outside | ||||
| the scope of this document. | ||||
| 4.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 cannot 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. | ||||
| (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) | ||||
| 4.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 et. al 8 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| 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 classes of services 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 | ||||
| traffic into 4 Traffic Trunks: one for traffic of each Diff- | ||||
| Serv class | ||||
| o because the QoS objectives for the AF1x Traffic Trunks and | ||||
| for the AF2x Traffic Trunks 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 EF traffic 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 EF: one for the EF traffic subject to | ||||
| the first (set of) bandwidth constraint(s), the other for the EF | ||||
| traffic subject to the second (set of) bandwidth constraint(s). | ||||
| DS-TE must support at least 2 CTs and up to 8 CTs. Those are | ||||
| referred to as CTc, 0 <= c <= MaxCT-1 = 7. | ||||
| In a given network, DS-TE must not require the network administrator | ||||
| to always deploy the maximum number of CTs. The network | ||||
| administrator must be able to deploy only the number of CTs actually | ||||
| utilized. | ||||
| 4.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 | ||||
| Le Faucheur et. al 9 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| 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 defined by: | ||||
| - MaxBC= MaxCT | ||||
| - All LSPs supporting Traffic Trunks from CTc use no more than BCc | ||||
| For illustration purposes, on a link of 100 unit of bandwidth where | ||||
| three CTs are used, the network administrator might then configure | ||||
| BC0=30, BC1= 50, BC2=20 such that: | ||||
| - All LSPs supporting Traffic Trunks from CT0 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 CT2 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 | ||||
| - All LSPs supporting Traffic Trunks from CTc (with b<=c<=7) use no | ||||
| more than BCb | ||||
| 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. | ||||
| At the time of writing this document, it is not clear whether a | ||||
| single model of Bandwidth Constraints is sufficient, which one it | ||||
| should be and how flexible this model really needs to be and what | ||||
| are the implications on the DS-TE technical solution and its | ||||
| implementations. Work is currently in progress to investigate the | ||||
| performance and trade-offs of different operational aspects of | ||||
| Bandwidth Constraints models. The DS-TE technical solution must | ||||
| specify one default bandwidth constraint model which must be | ||||
| supported by any DS-TE implementation. However, additional bandwidth | ||||
| constraint models may also be specified. The purpose of such a | ||||
| default model is to ensure that there is at least one common | ||||
| Bandwidth Constraints model implementation across various vendors | ||||
| equipment and allows for easier deployment of DS-TE. However, this | ||||
| Le Faucheur et. al 10 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| does not preclude a network operator to activate different Bandwidth | ||||
| Constraints models on different links in a network, if he/she wishes | ||||
| to do so. | ||||
| In the selection of a default model, 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 | ||||
| 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 [BC-MODEL]. | ||||
| These selection criteria will be further discussed and refined as | ||||
| part of the ongoing work on BC model selection. In particular, the | ||||
| applicability of criterion (5) needs to be qualified. | ||||
| Regardless of the Bandwidth Constraint Model, the DS-TE solution | ||||
| must allow support for up to 8 BCs. | ||||
| 4.4. Preemption and TE-Classes | ||||
| [TEWG-FW] defines the notion of preemption and preemption priority. | ||||
| DS-TE must retain full support of such preemption. However, a | ||||
| network administrator preferring not to use preemption for user | ||||
| traffic should 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 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 | ||||
| Le Faucheur et. al 11 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| 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. | ||||
| DS-TE must allow all LSPs transporting Traffic Trunks of a given | ||||
| Class-Type to use the same preemption priority. In other words, DS- | ||||
| TE 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. | ||||
| DS-TE 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, DS-TE 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. | ||||
| DS-TE 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 | ||||
| Le Faucheur et. al 12 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| - 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 | ||||
| DS-TE 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 | ||||
| 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 recomputing a path by | ||||
| Constraint Based Routing based on updated available bandwidth | ||||
| information and then signaling for LSP establishment along the new | ||||
| path. It must 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. | ||||
| 4.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. | ||||
| Le Faucheur et. al 13 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| 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, | ||||
| ...). 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>). | ||||
| 4.6. Dynamic Adjustment of Diff-Serv PHBs | ||||
| As discussed in section 2.2, DS-TE 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. It is a local matter to the LSR and as such is outside | ||||
| the scope of this specification. | ||||
| 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. | ||||
| The dynamic adjustment must take account of the performance | ||||
| requirements of each class when computing required adjustments. | ||||
| 4.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. | ||||
| DS-TE must also allow overbooking and must effectively allow | ||||
| different overbooking ratios to be enforced for different CTs. | ||||
| DS-TE should optionally allow the effective overbooking ratio of a | ||||
| given CT to be tweaked differently in different parts of the | ||||
| network. | ||||
| 4.8. Restoration | ||||
| Le Faucheur et. al 14 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| 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. | ||||
| DS-TE 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]. | ||||
| 5. 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, CR-LDP) | ||||
| be 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 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. | ||||
| 5.1. Satisfying detailed requirements | ||||
| The solution must address all the scenarios described in section 2 | ||||
| and satisfy all the requirements listed in section 3. | ||||
| 5.2. Flexibility | ||||
| - number of Class Types that can be supported, compared to | ||||
| number identified in Requirements section | ||||
| - number of Classes within a Class-Type | ||||
| 5.3. Extendibility | ||||
| - how far can the solution be extended in the future if | ||||
| requirements for more Class-Types are identified in the | ||||
| future. | ||||
| 5.4. Scalability | ||||
| - impact on network scalability in what is propagated, | ||||
| processed, stored and computed (IGP signaling, IGP | ||||
| processing, IGP database, TE-Tunnel signaling ,...). | ||||
| Le Faucheur et. al 15 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| - 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) | ||||
| 5.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. | ||||
| 6. 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. | ||||
| 7. Acknowledgemnt | ||||
| We thank David Allen for his help in aligning with up-to-date | ||||
| Diff-Serv terminology. | ||||
| 8. Normative References | ||||
| [AF] Heinanen, J et al., "Assured Forwarding PHB Group", RFC2597 | ||||
| [DIFF-ARCH] Blake et al., "An Architecture for Differentiated | ||||
| Services", RFC2475. | ||||
| [DIFF-MPLS] Le Faucheur et al, "Multi-Protocol Label Switching | ||||
| (MPLS) Support of Differentiated Services", RFC3270, May 2002. | ||||
| [DIFF-NEW] Grossman, " New Terminology and Clarifications for | ||||
| Diffserv ", RFC3260, April 2002. | ||||
| [EF] Davie et al., "An Expedited Forwarding PHB (Per-Hop Behavior)", | ||||
| RFC3246, March 2002. | ||||
| Le Faucheur et. al 16 | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | ||||
| [TEWG-FW] Awduche et al, Overview and Principles of Internet Traffic | ||||
| Engineering, RFC3272, May 2002. | ||||
| [TE-REQ] Awduche et al, Requirements for Traffic Engineering over | ||||
| MPLS, RFC2702, September 1999. | ||||
| 9. Informative References | ||||
| [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", | Title: Requirements for Support of Differentiated | |||
| RFC3212, January 2002 | Services-aware MPLS Traffic Engineering | |||
| Author(s): F. Le Faucheur, W. Lai | ||||
| Status: Informational | ||||
| Date: July 2003 | ||||
| Mailbox: flefauch@cisco.com, wlai@att.com | ||||
| Pages: 22 | ||||
| Characters: 50808 | ||||
| Updates/Obsoletes/SeeAlso: None | ||||
| [DIFF-FIELD] Nichols et al., "Definition of the Differentiated | I-D Tag: draft-ietf-tewg-diff-te-reqts-07.txt | |||
| Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474. | ||||
| [DIFF-PDB] Nichols et al., "Definition of Differentiated Services | URL: ftp://ftp.rfc-editor.org/in-notes/rfc3564.txt | |||
| Per Domain Behaviors and Rules for their Specification", RFC3086. | ||||
| [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- | This document presents Service Provider requirements for support of | |||
| ietf-isis-traffic-04.txt, August 2001. | Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering | |||
| (DS-TE). | ||||
| [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, | Its objective is to provide guidance for the definition, selection | |||
| draft-katz-yeung-ospf-traffic-06.txt, October 2001. | and specification of a technical solution addressing these | |||
| requirements. Specification for this solution itself is outside the | ||||
| scope of this document. | ||||
| [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP | A problem statement is first provided. Then, the document describes | |||
| Tunnels", RFC 3209, December 2001. | 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. | ||||
| [SURVIV-REQ] W.S. Lai, D. McDysan, J. Boyle, M. Carlzon, R. Coltun, | This document is a product of the Internet Traffic Engineering Working | |||
| T, Griffin, E. Kern, and T. Reddington, "Network Hierarchy and | Group of the IETF. | |||
| Multilayer Survivability," work in progress, October 2001. | ||||
| 10. Editors' Address: | This memo provides information for the Internet community. It does | |||
| not specify an Internet standard of any kind. Distribution of this | ||||
| memo is unlimited. | ||||
| Francois Le Faucheur | This announcement is sent to the IETF list and the RFC-DIST list. | |||
| Cisco Systems, Inc. | Requests to be added to or deleted from the IETF distribution list | |||
| Village d'Entreprise Green Side - Batiment T3 | should be sent to IETF-REQUEST@IETF.ORG. Requests to be | |||
| 400, Avenue de Roumanille | added to or deleted from the RFC-DIST distribution list should | |||
| 06410 Biot-Sophia Antipolis, France | be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. | |||
| Phone: +33 4 97 23 26 19 | ||||
| Email: flefauch@cisco.com | ||||
| Wai Sum Lai | Details on obtaining RFCs via FTP or EMAIL may be obtained by sending | |||
| AT&T Labs | an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body | |||
| 200 Laurel Avenue | help: ways_to_get_rfcs. For example: | |||
| Middletown, New Jersey 07748, USA | ||||
| Phone: (732) 420-3712 | ||||
| Email: wlai@att.com | ||||
| Le Faucheur et. al 17 | To: rfc-info@RFC-EDITOR.ORG | |||
| Subject: getting rfcs | ||||
| Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 | help: ways_to_get_rfcs | |||
| Le Faucheur et. al 18 | Requests for special distribution should be addressed to either the | |||
| author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless | ||||
| specifically noted otherwise on the RFC itself, all RFCs are for | ||||
| unlimited distribution.echo | ||||
| Submissions for Requests for Comments should be sent to | ||||
| RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC | ||||
| Authors, for further information. | ||||
| End of changes. 15 change blocks. | ||||
| 923 lines changed or deleted | 44 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||