diff options
Diffstat (limited to 'doc/rfc/rfc4105.txt')
-rw-r--r-- | doc/rfc/rfc4105.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc4105.txt b/doc/rfc/rfc4105.txt new file mode 100644 index 0000000..676fde9 --- /dev/null +++ b/doc/rfc/rfc4105.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group J.-L. Le Roux, Ed. +Request for Comments: 4105 France Telecom +Category: Informational J.-P. Vasseur, Ed. + Cisco Systems, Inc. + J. Boyle, Ed. + PDNETs + June 2005 + + + Requirements for Inter-Area 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 (2005). + +Abstract + + This document lists a detailed set of functional requirements for the + support of inter-area MPLS Traffic Engineering (inter-area MPLS TE). + It is intended that solutions that specify procedures and protocol + extensions for inter-area MPLS TE satisfy these requirements. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Conventions Used in This Document ...............................3 + 3. Terminology .....................................................3 + 4. Current Intra-Area Uses of MPLS Traffic Engineering .............4 + 4.1. Intra-Area MPLS Traffic Engineering Architecture ...........4 + 4.2. Intra-Area MPLS Traffic Engineering Applications ...........4 + 4.2.1. Intra-Area Resource Optimization ....................4 + 4.2.2. Intra-Area QoS Guarantees ...........................5 + 4.2.3. Fast Recovery within an IGP Area ....................5 + 4.3. Intra-Area MPLS TE and Routing .............................6 + 5. Problem Statement, Requirements, and Objectives of Inter-Area ...6 + 5.1. Inter-Area Traffic Engineering Problem Statement ...........6 + 5.2. Overview of Requirements for Inter-Area MPLS TE ............7 + 5.3. Key Objectives for an Inter-Area MPLS-TE Solution ..........8 + 5.3.1. Preserving the IGP Hierarchy Concept ................8 + 5.3.2. Preserving Scalability ..............................8 + 6. Application Scenario.............................................9 + + + + +Le Roux, et al. Informational [Page 1] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + + 7. Detailed Requirements for Inter-Area MPLS TE ...................10 + 7.1. Inter-Area MPLS TE Operations and Interoperability ........10 + 7.2. Inter-Area TE-LSP Signaling ...............................10 + 7.3. Path Optimality ...........................................11 + 7.4. Inter-Area MPLS-TE Routing ................................11 + 7.5. Inter-Area MPLS-TE Path Computation .......................12 + 7.6. Inter-Area Crankback Routing ..............................12 + 7.7. Support of Diversely-Routed Inter-Area TE LSPs ............13 + 7.8. Intra/Inter-Area Path Selection Policy ....................13 + 7.9. Reoptimization of Inter-Area TE LSP .......................13 + 7.10. Inter-Area LSP Recovery ..................................14 + 7.10.1. Rerouting of Inter-Area TE LSPs ..................14 + 7.10.2. Fast Recovery of Inter-Area TE LSP ...............14 + 7.11. DS-TE support ............................................15 + 7.12. Hierarchical LSP Support .................................15 + 7.13. Hard/Soft Preemption .....................................15 + 7.14. Auto-Discovery of TE Meshes ..............................16 + 7.15. Inter-Area MPLS TE Fault Management Requirements .........16 + 7.16. Inter-Area MPLS TE and Routing ...........................16 + 8. Evaluation criteria ............................................17 + 8.1. Performances ..............................................17 + 8.2. Complexity and Risks ......................................17 + 8.3. Backward Compatibility ....................................17 + 9. Security Considerations ........................................17 + 10. Acknowledgements ..............................................17 + 11. Contributing Authors ..........................................18 + 12. Normative References ..........................................19 + 13. Informative References ........................................19 + +1. Introduction + + The set of MPLS Traffic Engineering components, defined in [RSVP-TE], + [OSPF-TE], and [ISIS-TE], which supports the requirements defined in + [TE-REQ], is used today by many network operators to achieve major + Traffic Engineering objectives defined in [TE-OVW]. These objectives + include: + + - Aggregated Traffic measurement + - Optimization of network resources utilization + - Support for services requiring end-to-end QoS guarantees + - Fast recovery against link/node/Shared Risk Link Group (SRLG) + failures + + Furthermore, the applicability of MPLS to traffic engineering in IP + networks is discussed in [TE-APP]. + + The set of MPLS Traffic Engineering mechanisms, to date, has been + limited to use within a single Interior Gateway Protocol (IGP) area. + + + +Le Roux, et al. Informational [Page 2] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + + This document discusses the requirements for an inter-area MPLS + Traffic Engineering mechanism that may be used to achieve the same + set of objectives across multiple IGP areas. + + Basically, it would be useful to extend MPLS TE capabilities across + IGP areas to support inter-area resources optimization, to provide + strict QoS guarantees between two edge routers located within + distinct areas, and to protect inter-area traffic against Area Border + Router (ABR) failures. + + First, this document addresses current uses of MPLS Traffic + Engineering within a single IGP area. Then, it discusses a set of + functional requirements that a solution must or should satisfy in + order to support inter-area MPLS Traffic Engineering. Because the + scope of requirements will vary between operators, some requirements + will be mandatory (MUST), whereas others will be optional (SHOULD). + Finally, a set of evaluation criteria for any solution meeting these + requirements is given. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Terminology + + LSR: Label Switching Router + + LSP: Label Switched Path + + TE LSP: Traffic Engineering Label Switched Path + + Inter-area TE LSP: TE LSP whose head-end LSR and tail-end LSR do not + reside within the same IGP area or whose head-end + LSR and tail-end LSR are both in the same IGP area + although the TE-LSP transiting path is across + different IGP areas. + + IGP area: OSPF area or IS-IS level. + + ABR: Area Border Router, a router used to connect two + IGP areas (ABR in OSPF, or L1/L2 router in IS-IS). + + CSPF: Constraint-based Shortest Path First. + + SRLG: Shared Risk Link Group. + + + + +Le Roux, et al. Informational [Page 3] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + +4. Current Intra-Area Uses of MPLS Traffic Engineering + + This section addresses architecture, capabilities, and uses of MPLS + TE within a single IGP area. It first summarizes the current MPLS-TE + architecture, then addresses various MPLS-TE capabilities, and + finally lists various approaches to integrate MPLS TE into routing. + This section is intended to help define the requirements for MPLS-TE + extensions across multiple IGP areas. + +4.1. Intra-Area MPLS Traffic Engineering Architecture + + The MPLS-TE control plane allows establishing explicitly routed MPLS + LSPs whose paths follow a set of TE constraints. It is used to + achieve major TE objectives such as resource usage optimization, QoS + guarantee and fast failure recovery. It consists of three main + components: + + - The routing component, responsible for the discovery of the TE + topology. This is ensured thanks to extensions of link state IGP: + [ISIS-TE], [OSPF-TE]. + - The path computation component, responsible for the placement of + the LSP. It is performed on the head-end LSR thanks to a CSPF + algorithm, which takes TE topology and LSP constraints as input. + - The signaling component, responsible for the establishment of the + LSP (explicit routing, label distribution, and resources + reservation) along the computed path. This is ensured thanks to + RSVP-TE [RSVP-TE]. + +4.2. Intra-Area MPLS Traffic Engineering Applications + +4.2.1. Intra-Area Resource Optimization + + MPLS TE can be used within an area to redirect paths of aggregated + flows away from over-utilized resources within a network. In a small + scale, this may be done by explicitly configuring a path to be used + between two routers. On a grander scale, a mesh of LSPs can be + established between central points in a network. LSPs paths can be + defined statically in configuration or arrived at by an algorithm + that determines the shortest path given administrative constraints + such as bandwidth. In this way, MPLS TE allows for greater control + over how traffic demands are routed over a network topology and + utilize a network's resources. + + Note also that TE LSPs allow measuring traffic matrix in a simple and + scalable manner. The aggregated traffic rate between two LSRs is + easily measured by accounting of traffic sent onto a TE LSP + provisioned between the two LSRs in question. + + + + +Le Roux, et al. Informational [Page 4] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + +4.2.2. Intra-Area QoS Guarantees + + The DiffServ IETF working group has defined a set of mechanisms + described in [DIFF-ARCH], [DIFF-AF], and [DIFF-EF] or [MPLS-DIFF], + that can be activated at the edge of or over a DiffServ domain to + contribute to the enforcement of a QoS policy (or set of policies), + which can be expressed in terms of maximum one-way transit delay, + inter-packet delay variation, loss rate, etc. Many Operators have + some or full deployment of DiffServ implementations in their networks + today, either across the entire network or at least at its edge. + + In situations where strict QoS bounds are required, admission control + inside the backbone of a network is in some cases required in + addition to current DiffServ mechanisms. When the propagation delay + can be bounded, the performance targets, such as maximum one-way + transit delay, may be guaranteed by providing bandwidth guarantees + along the DiffServ-enabled path. + + MPLS TE can be simply used with DiffServ: in that case, it only + ensures aggregate QoS guarantees for the whole traffic. It can also + be more intimately combined with DiffServ to perform per-class of + service admission control and resource reservation. This requires + extensions to MPLS TE called DiffServ-Aware TE, which are defined in + [DSTE-PROTO]. DS-TE allows ensuring strict end-to-end QoS + guarantees. For instance, an EF DS-TE LSP may be provisioned between + voice gateways within the same area to ensure strict QoS to VoIP + traffic. + + MPLS TE allows computing intra-area shortest paths, which satisfy + various constraints, including bandwidth. For the sake of + illustration, if the IGP metrics reflects the propagation delay, it + allows finding a minimum propagation delay path, which satisfies + various constraints, such as bandwidth. + +4.2.3. Fast Recovery within an IGP Area + + As quality-sensitive applications are deployed, one of the key + requirements is to provide fast recovery mechanisms, allowing traffic + recovery to be guaranteed on the order of tens of msecs, in case of + network element failure. Note that this cannot be achieved by + relying only on classical IGP rerouting. + + Various recovery mechanisms can be used to protect traffic carried + onto TE LSPs. They are defined in [MPLS-RECOV]. Protection + mechanisms are based on the provisioning of backup LSPs that are used + to recover traffic in case of failure of protected LSPs. Among those + protection mechanisms, local protection (also called Fast Reroute) is + intended to achieve sub-50ms recovery in case of link/node/SRLG + + + +Le Roux, et al. Informational [Page 5] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + + failure along the LSP path [FAST-REROUTE]. Fast Reroute is currently + used by many operators to protect sensitive traffic inside an IGP + area. + + [FAST-REROUTE] defines two modes for backup LSPs. The first, called + one-to-one backup, consists of setting up one detour LSP per + protected LSP and per element to protect. The second, called + facility backup, consists of setting up one or several bypass LSPs to + protect a given facility (link or node). In case of failure, all + protected LSPs are nested into the bypass LSPs (benefiting from the + MPLS label stacking property). + +4.3. Intra-Area MPLS TE and Routing + + There are several possibilities for directing traffic into intra-area + TE LSPs: + + 1) Static routing to the LSP destination address or any other + addresses. + 2) IGP routes beyond the LSP destination, from an IGP SPF perspective + (IGP shortcuts). + 3) BGP routes announced by a BGP peer (or an MP-BGP peer) that is + reachable through the TE LSP by means of a single static route to + the corresponding BGP next-hop address (option 1) or by means of + IGP shortcuts (option 2). This is often called BGP recursive + routing. + 4) The LSP can be advertised as a link into the IGP to become part of + IGP database for all nodes, and thus can be taken into account + during SPF for all nodes. Note that, even if similar in concept, + this is different from the notion of Forwarding-Adjacency, as + defined in [LSP-HIER]. Forwarding-Adjacency is when the LSP is + advertised as a TE-link into the IGP-TE to become part of the TE + database and taken into account in CSPF. + +5. Problem Statement, Requirements, and Objectives of Inter-Area + MPLS TE + +5.1. Inter-Area Traffic Engineering Problem Statement + + As described in Section 4, MPLS TE is deployed today by many + operators to optimize network bandwidth usage, to provide strict QoS + guarantees, and to ensure sub-50ms recovery in case of link/node/SRLG + failure. + + However, MPLS-TE mechanisms are currently limited to a single IGP + area. The limitation comes more from the Routing and Path + computation components than from the signaling component. This is + basically because the hierarchy limits topology visibility of head- + + + +Le Roux, et al. Informational [Page 6] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + + end LSRs to their IGP area, and consequently head-end LSRs can no + longer run a CSPF algorithm to compute the shortest constrained path + to the tail-end, as CSPF requires the whole topology to compute an + end-to-end shortest constrained path. + + Several operators have multi-area networks, and many operators that + are still using a single IGP area may have to migrate to a multi-area + environment, as their network grows and single area scalability + limits are approached. + + Thus, those operators may require inter-area traffic engineering to: + + - Perform inter-area resource optimization. + - Provide inter-area QoS guarantees for traffic between edge nodes + located in different areas. + - Provide fast recovery across areas, to protect inter-area traffic + in case of link or node failure, including ABR node failures. + + For instance, an operator running a multi-area IGP may have voice + gateways located in different areas. Such VoIP transport requires + inter-area QoS guarantees and inter-area fast protection. + + One possible approach for inter-area traffic engineering could + consist of deploying MPLS TE on a per-area basis, but such an + approach has several limitations: + + - Traffic aggregation at the ABR levels implies some constraints that + do not lead to efficient traffic engineering. Actually, this per- + area TE approach might lead to sub-optimal resource utilization, by + optimizing resources independently in each area. What many + operators want is to optimize their resources as a whole; in other + words, as if there was only one area (flat network). + - This does not allow computing an inter-area constrained shortest + path and thus does not ensure end-to-end QoS guarantees across + areas. + - Inter-area traffic cannot be protected with local protection + mechanisms such as [FAST-REROUTE] in case of ABR failure. + + Therefore, existing MPLS TE mechanisms have to be enhanced to support + inter-area TE LSPs. + +5.2. Overview of Requirements for Inter-Area MPLS TE + + For the reasons mentioned above, it is highly desired to extend the + current set of MPLS-TE mechanisms across multiple IGP areas in order + to support the intra-area applications described in Section 4 across + areas. + + + + +Le Roux, et al. Informational [Page 7] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + + The solution MUST allow setting up inter-area TE LSPs; i.e., LSPs + whose path crosses at least two IGP areas. + + Inter-area MPLS-TE extensions are highly desired in order to provide: + + - Inter-area resources optimization. + - Strict inter-area QoS guarantees. + - Fast recovery across areas, particularly to protect inter-area + traffic against ABR failures. + + It may be desired to compute inter-area shortest paths that satisfy + some bandwidth constraints or any other constraints, as is currently + possible within a single IGP area. For the sake of illustration, if + the IGP metrics reflects the propagation delay, it may be necessary + to be able to find the optimal (shortest) path satisfying some + constraints (e.g., bandwidth) across multiple IGP areas. Such a path + would be the inter-area path offering the minimal propagation delay. + + Thus, the solution SHOULD provide the ability to compute inter-area + shortest paths satisfying a set of constraints (i.e., bandwidth). + +5.3. Key Objectives for an Inter-Area MPLS-TE Solution + + Any solution for inter-area MPLS TE should be designed with + preserving IGP hierarchy concept, and preserving routing and + signaling scalability as key objectives. + +5.3.1. Preserving the IGP Hierarchy Concept + + The absence of a full link-state topology database makes the + computation of an end-to-end optimal path by the head-end LSR not + possible without further signaling and routing extensions. There are + several reasons that network operators choose to break up their + network into different areas. These often include scalability and + containment of routing information. The latter can help isolate most + of a network from receiving and processing updates that are of no + consequence to its routing decisions. Containment of routing + information MUST not be compromised to allow inter-area traffic + engineering. Information propagation for path-selection MUST + continue to be localized. In other words, the solution MUST entirely + preserve the concept of IGP hierarchy. + +5.3.2. Preserving Scalability + + Achieving the requirements listed in this document MUST be performed + while preserving the IGP scalability, which is of the utmost + importance. The hierarchy preservation objective addressed in the + above section is actually an element to preserve IGP scalability. + + + +Le Roux, et al. Informational [Page 8] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + + The solution also MUST not increase IGP load unreasonably, which + could compromise IGP scalability. In particular, a solution + satisfying those requirements MUST not require the IGP to carry some + unreasonable amount of extra information and MUST not unreasonably + increase the IGP flooding frequency. + + Likewise, the solution MUST also preserve scalability of RSVP-TE + ([RSVP-TE]). + + Additionally, the base specification of MPLS TE is architecturally + structured and relatively devoid of excessive state propagation in + terms of routing or signaling. Its strength in extensibility can + also be seen as an Achilles heel, as there is no real limit to what + is possible with extensions. It is paramount to maintain + architectural vision and discretion when adapting it for use for + inter-area MPLS TE. Additional information carried within an area or + propagated outside of an area (via routing or signaling) should be + neither excessive, patchwork, nor non-relevant. + + Particularly, as mentioned in Section 5.2, it may be desired for some + inter-area TE LSP carrying highly sensitive traffic to compute a + shortest inter-area path, satisfying a set of constraints such as + bandwidth. This may require an additional routing mechanism, as base + CSPF at head-end can no longer be used due to the lack of topology + and resource information. Such a routing mechanism MUST not + compromise the scalability of the overall system. + +6. Application Scenario + + ---area1--------area0------area2-- + ------R1-ABR1-R2-------ABR3------- + | \ | / | | + | R0 \ | / | R4 | + | R5 \ |/ | | + ---------ABR2----------ABR4------- + + - ABR1, ABR2: Area0-Area1 ABRs + - ABR3, ABR4: Area0-Area2 ABRs + + - R0, R1, R5: LSRs in area 1 + - R2: an LSR in area 0 + - R4: an LSR in area 2 + + Although the terminology and examples provided in this document make + use of the OSPF terminology, this document equally applies to IS-IS. + + + + + + +Le Roux, et al. Informational [Page 9] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + + Typically, an inter-area TE LSP will be set up between R0 and R4, + where both LSRs belong to different IGP areas. Note that the + solution MUST support the capability to protect such an inter-area TE + LSP from the failure on any Link/SRLG/Node within any area and the + failure of any traversed ABR. For instance, if the TE LSP R0->R4 + goes through R1->ABR1->R2, then it can be protected against ABR1 + failure, thanks to a backup LSP (detour or bypass) that may follow + the alternate path R1->ABR2->R2. + + For instance, R0 and R4 may be two voice gateways located in distinct + areas. An inter-area DS-TE LSP with class-type EF is set up from R1 + to R4 to route VoIP traffic classified as EF. Per-class inter-area + constraint-based routing allows the DS-TE LSP to be routed over a + path that will ensure strict QoS guarantees for VoIP traffic. + + In another application, R0 and R4 may be two pseudo wire gateways + residing in different areas. An inter-area LSP may be set up to + carry pseudo wires. + + In some cases, it might also be possible to have an inter-area TE LSP + from R0 to R5 transiting via the backbone area (or any other levels + with IS-IS). There may be cases where there are no longer enough + resources on any intra area path R0-to-R5, and where there is a + feasible inter-area path through the backbone area. + +7. Detailed Requirements for Inter-Area MPLS TE + +7.1. Inter-Area MPLS TE Operations and Interoperability + + The inter-area MPLS TE solution MUST be consistent with requirements + discussed in [TE-REQ], and the derived solution MUST interoperate + seamlessly with current intra-area MPLS TE mechanisms and inherit its + capability sets from [RSVP-TE]. + + The proposed solution MUST allow provisioning at the head-end with + end-to-end RSVP signaling (potentially with loose paths) traversing + across the interconnected ABRs, without further provisioning required + along the transit path. + +7.2. Inter-Area TE-LSP Signaling + + The solution MUST allow for the signaling of inter-area TE LSPs, + using RSVP-TE. + + In addition to the signaling of classical TE constraints (bandwidth, + admin-groups), the proposed solution MUST allow the head-end LSR to + specify a set of LSRs explicitly, including ABRs, by means of strict + or loose hops for the inter-area TE LSP. + + + +Le Roux, et al. Informational [Page 10] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + + In addition, the proposed solution SHOULD also provide the ability to + specify and signal certain resources to be explicitly excluded in the + inter-area TE-LSP path establishment. + +7.3. Path Optimality + + In the context of this requirement document, an optimal path is + defined as the shortest path across multiple areas, taking into + account either the IGP or TE metric [METRIC]. In other words, such a + path is the path that would have been computed by making use of some + CSPF algorithm in the absence of multiple IGP areas. + + As mentioned in Section 5.2, the solution SHOULD provide the + capability to compute an optimal path dynamically, satisfying a set + of specified constraints (defined in [TE-REQ]) across multiple IGP + areas. Note that this requirement document does not mandate that all + inter-area TE LSPs require the computation of an optimal (shortest) + inter-area path. Some inter-area TE-LSP paths may be computed via + some mechanisms that do not guarantee an optimal end-to-end path, + whereas some other inter-area TE-LSP paths carrying sensitive traffic + could be computed by making use of mechanisms allowing an optimal + end-to-end path to be computed dynamically. Note that regular + constraints such as bandwidth, affinities, IGP/TE metric + optimization, path diversity, etc., MUST be taken into account in the + computation of an optimal end-to-end path. + +7.4. Inter-Area MPLS-TE Routing + + As mentioned in Section 5.3, IGP hierarchy does not allow the head- + end LSR to compute an end-to-end optimal path. Additional mechanisms + are required to compute an optimal path. These mechanisms MUST not + alter the IGP hierarchy principles. Particularly, in order to + maintain containment of routing information and to preserve the + overall IGP scalability, the solution SHOULD avoid any dynamic-TE- + topology-related information from leaking across areas, even in a + summarized form. + + Conversely, this does not preclude the leaking of non-topology- + related information that is not taken into account during path + selection, such as static TE Node information (TE router ids or TE + node capabilities). + + + + + + + + + + +Le Roux, et al. Informational [Page 11] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + +7.5. Inter-Area MPLS-TE Path Computation + + Several methods may be used for path computation, including the + following: + + - Per-area path computation based on ERO expansion on the head-end + LSR and on ABRs, with two options for ABR selection: + + 1) Static configuration of ABRs as loose hops at the head-end + LSR. + 2) Dynamic ABR selection. + + - Inter-area end-to-end path computation, which may be based on (for + instance) a recursive constraint-based searching thanks to + collaboration between ABRs. + + Note that any path computation method may be used provided that it + respect key objectives pointed out in Section 5.3. + + If a solution supports more than one method, it should allow the + operator to select by configuration, and on a per-LSP basis, the + desired option. + +7.6. Inter-Area Crankback Routing + + Crankback routing, as defined in [CRANKBACK], may be used for inter- + area TE LSPs. For paths computed thanks to ERO expansions with a + dynamic selection of downstream ABRs, crankback routing can be used + when there is no feasible path from a selected downstream ABR to the + destination. The upstream ABR or head-end LSR selects another + downstream ABR and performs ERO expansion. + + Note that this method does not allow computing an optimal path but + just a feasible path. Note also that there can be 0(N^2) LSP setup + failures before finding a feasible path, where N is the average + number of ABR between two areas. This may have a non-negligible + impact on the LSP setup delay. + + Crankback may also be used for inter-area LSP recovery. If a + link/node/SRLG failure occurs in the backbone or tail-end area, the + ABR upstream to the failure computes an alternate path and reroutes + the LSP locally. + + An inter-area MPLS-TE solution MAY support [CRANKBACK]. A solution + that does, MUST allow [CRANKBACK] to be activated/deactivated via + signaling, on a per-LSP basis. + + + + + +Le Roux, et al. Informational [Page 12] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + +7.7. Support of Diversely-Routed Inter-Area TE LSPs + + There are several cases where the ability to compute diversely-routed + TE-LSP paths may be desirable. For instance, in the case of LSP + protection, primary and backup LSPs should be diversely routed. + Another example is the requirement to set up multiple diversely- + routed TE LSPs between a pair of LSRs residing in different IGP + areas. For instance, when a single TE LSP satisfying the bandwidth + constraint cannot be found between two end-points, a solution would + consist of setting up multiple TE LSPs so that the sum of their + bandwidth satisfy the bandwidth requirement. In this case, it may be + desirable to have these TE LSPs diversely routed in order to minimize + the impact of a failure, on the traffic between the two end-points. + + Thus, the solution MUST be able to establish diversely-routed inter- + area TE LSPs when diverse paths exist. It MUST support all kinds of + diversity (link, node, SRLG). + + The solution SHOULD allow computing an optimal placement of + diversely-routed LSPs. There may be various criteria to determine an + optimal placement. For instance, the placement of two diversely + routed LSPs for load-balancing purposes may consist of minimizing + their cumulative cost. The placement of two diversely-routed LSPs + for protection purposes may consist of minimizing the cost of the + primary LSP while bounding the cost or hop count of the backup LSP. + +7.8. Intra/Inter-Area Path Selection Policy + + For inter-area TE LSPs whose head-end and tail-end LSRs reside in the + same IGP area, there may be intra-area and inter-area feasible paths. + If the shortest path is an inter-area path, an operator either may + want to avoid, as far as possible, crossing area and thus may prefer + selecting a sub-optimal intra-area path or, conversely, may prefer to + use a shortest path, even if it crosses areas. Thus, the solution + should allow IGP area crossing to be enabled/disabled, on a per-LSP + basis, for TE LSPs whose head-end and tail-end reside in the same IGP + area. + +7.9. Reoptimization of Inter-Area TE LSP + + The solution MUST provide the ability to reoptimize in a minimally + disruptive manner (make before break) an inter-area TE LSP, should a + more optimal path appear in any traversed IGP area. The operator + should be able to parameterize such a reoptimization according to a + timer or event-driven basis. It should also be possible to trigger + such a reoptimization manually. + + + + + +Le Roux, et al. Informational [Page 13] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + + The solution SHOULD provide the ability to reoptimize an inter-area + TE LSP locally within an area; i.e., while retaining the same set of + transit ABRs. The reoptimization process in that case MAY be + controlled by the head-end LSR of the inter-area LSP, or by an ABR. + The ABR should check for local optimality of the inter-area TE LSPs + established through it on a timer or event driven basis. The option + of a manual trigger to check for optimality should also be provided. + + In some cases it is important to restrict the control of + reoptimization to the Head-End LSR only. Thus, the solution MUST + allow for activating/deactivating ABR control of reoptimization, via + signaling on a per LSP-basis. + + The solution SHOULD also provide the ability to perform an end-to-end + reoptimization, potentially resulting in a change on the set of + transit ABRs. Such reoptimization can only be controlled by the + Head-End LSR. + + In the case of head-end control of reoptimization, the solution + SHOULD provide the ability for the inter-area head-end LSR to be + informed of the existence of a more optimal path in a downstream area + and keep a strict control over the reoptimization process. Thus, the + inter-area head-end LSR, once informed of a more optimal path in some + downstream IGP areas, could decide to perform a make-before-break + reoptimization gracefully (or not to), according to the inter-area + TE-LSP characteristics. + +7.10. Inter-Area LSP Recovery + +7.10.1. Rerouting of Inter-Area TE LSPs + + The solution MUST support rerouting of an inter-area TE LSP in case + of SRLG/link/node failure or preemption. Such rerouting may be + controlled by the Head-End LSR or by an ABR (see Section 7.6, on + crankback). + +7.10.2. Fast Recovery of Inter-Area TE LSP + + The solution MUST provide the ability to benefit from fast recovery, + making use of the local protection techniques specified in + [FAST-REROUTE] both in the case of an intra-area network element + failure (link/SRLG/node) and in that of an ABR node failure. Note + that different protection techniques SHOULD be usable in different + parts of the network to protect an inter-area TE LSP. This is of the + utmost importance, particularly in the case of an ABR node failure, + as this node typically carries a great deal of inter-area traffic. + Moreover, the solution SHOULD allow computing and setting up a backup + tunnel following an optimal path that offers bandwidth guarantees + + + +Le Roux, et al. Informational [Page 14] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + + during failure, along with other potential constraints (such as + bounded propagation delay increase along the backup path). + + The solution SHOULD allow ABRs to be protected, while providing the + same level of performances (recovery delay, bandwidth consumption) as + provided today within an area. + + Note that some signaling approaches may have an impact on FRR + performances (recovery delay, bandwidth consumption). Typically, + when some intra-area LSPs (LSP-Segment, FA-LSPs) are used to support + the inter-area TE LSP, the protection of ABR using [FAST-REROUTE] may + lead to higher bandwidth consumption and higher recovery delays. The + use of [FAST-REROUTE] to protect ABRs, although ensuring the same + level of performances, currently requires a single end-to-end RSVP + session (contiguous LSP) to be used, without any intra-area LSP. + Thus, the solution MUST provide the ability, via signalling on a + per-LSP basis, to allow or preclude the use of intra-area LSPs to + support the inter-area LSPs. + +7.11. DS-TE support + + The proposed inter-area MPLS TE solution SHOULD also satisfy core + requirements documented in [DSTE-REQ] and interoperate seamlessly + with current intra-area MPLS DS-TE mechanism [DSTE-PROTO]. + +7.12. Hierarchical LSP Support + + In the case of a large inter-area MPLS deployment, potentially + involving a large number of LSRs, it may be desirable/necessary to + introduce some level of hierarchy in order to reduce the number of + states on LSRs (such a solution implies other challenges). Thus, the + proposed solution SHOULD allow inter-area TE-LSP aggregation (also + referred to as LSP nesting) so that individual TE LSPs can be carried + onto one or more aggregating LSPs. One such mechanism, for example, + is described in [LSP-HIER]. + +7.13. Hard/Soft Preemption + + As defined in [MPLS-PREEMPT], two preemption models are applicable to + MPLS: Soft and Hard Preemption. + + An inter-area MPLS-TE solution SHOULD support the two models. + + In the case of hard preemption, the preempted inter-area TE LSP + should be rerouted, following requirements defined in Section 7.10.1. + + + + + + +Le Roux, et al. Informational [Page 15] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + + In the case of soft preemption, the preempted inter-area TE LSP + should be re-optimized, following requirements defined in Section + 7.9. + +7.14. Auto-Discovery of TE Meshes + + A TE mesh is a set of LSRs that are fully interconnected by a full + mesh of TE LSPs. Because the number of LSRs participating in some TE + mesh might be quite large, it might be desirable to provide some + discovery mechanisms allowing an LSR to discover automatically the + LSRs members of the TE mesh(es) that it belongs to. The discovery + mechanism SHOULD be applicable across multiple IGP areas, and SHOULD + not impact the IGP scalability, provided that IGP extensions are used + for such a discovery mechanism. + +7.15. Inter-Area MPLS TE Fault Management Requirements + + The proposed solution SHOULD be able to interoperate with fault + detection mechanisms of intra-area MPLS TE. + + The solution SHOULD support [LSP-PING] and [MPLS-TTL]. + + The solution SHOULD also support fault detection on backup LSPs, in + case [FAST-REROUTE] is deployed. + +7.16. Inter-Area MPLS TE and Routing + + In the case of intra-area MPLS TE, there are currently several + possibilities for routing traffic into an intra-area TE LSP. They + are listed in Section 4.2. + + In the case of inter-area MPLS TE, the solution MUST support static + routing into the LSP, and also BGP recursive routing with a static + route to the BGP next-hop address. + + ABRs propagate IP reachability information (summary LSA in OSPF and + IP reachability TLV in ISIS), that MAY be used by the head-end LSR to + route traffic to a destination beyond the TE-LSP tail-head LSR (e.g., + to an ASBR). + + The use of IGP shortcuts MUST be precluded when TE-LSP head-end and + tail-end LSRs do not reside in the same IGP area. It MAY be used + when they reside in the same area. + + The advertisement of an inter-area TE LSP as a link into the IGP, in + order to attract traffic to an LSP source, MUST be precluded when + TE-LSP head-end and tail-end LSRs do not reside in the same IGP area. + It MAY be used when they reside in the same area. + + + +Le Roux, et al. Informational [Page 16] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + +8. Evaluation criteria + +8.1. Performances + + The solution will be evaluated with respect to the following + criteria: + + (1) Optimality of the computed inter-area TE-LSP primary and backup + paths, in terms of path cost. + (2) Capability to share bandwidth among inter-area backup LSPs + protecting independent facilities. + (3) Inter-area TE-LSP setup time (in msec). + (4) RSVP-TE and IGP scalability (state impact, number of messages, + message size). + +8.2. Complexity and Risks + + The proposed solution SHOULD not introduce complexity to the current + operating network to such a degree that it would affect the stability + and diminish the benefits of deploying such a solution over SP + networks. + +8.3. Backward Compatibility + + In order to allow for a smooth migration or co-existence, the + deployment of inter-area MPLS TE SHOULD not affect existing MPLS TE + mechanisms. In particular, the solution SHOULD allow the setup of an + inter-area TE LSP among transit LSRs that do not support inter-area + extensions, provided that these LSRs do not participate in the + inter-area TE procedure. For illustration purposes, the solution MAY + require inter-area extensions only on end-point LSRs, on ABRs, and, + potentially, on Points of Local Repair (PLR) protecting an ABR. + +9. Security Considerations + + This document does not introduce new security issues beyond those + inherent in MPLS TE [RSVP-TE] and an inter-area MPLS-TE solution may + use the same mechanisms proposed for that technology. It is, + however, specifically important that manipulation of administratively + configurable parameters be executed in a secure manner by authorized + entities. + +10. Acknowledgements + + We would like to thank Dimitri Papadimitriou, Adrian Farrel, Vishal + Sharma, and Arthi Ayyangar for their useful comments and suggestions. + + + + + +Le Roux, et al. Informational [Page 17] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + +11. Contributing Authors + + This document was the collective work of several authors. 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 14 and is not repeated below): + + Ting-Wo Chung Yuichi Ikejiri + Bell Canada NTT Communications Corporation + 181 Bay Street, Suite 350, 1-1-6, Uchisaiwai-cho, + Toronto, Chiyoda-ku, Tokyo 100-8019 + Ontario, Canada, M5J 2T3 JAPAN + + EMail: ting_wo.chung@bell.ca EMail: y.ikejiri@ntt.com + + + Raymond Zhang Parantap Lahiri + Infonet Services Corporation MCI + 2160 E. Grand Ave. 22001 Loudoun Cty Pky + El Segundo, CA 90025 Ashburn, VA 20147 + USA USA + + EMail: raymond_zhang@infonet.com EMail: parantap.lahiri@mci.com + + + Kenji Kumaki + KDDI Corporation + Garden Air Tower + Iidabashi, Chiyoda-ku, + Tokyo 102-8460, + JAPAN + + EMail: ke-kumaki@kddi.com + + + + + + + + + + + + + + + + + + +Le Roux, et al. Informational [Page 18] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + +12. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to indicate + requirements levels", RFC 2119, March 1997. + + [TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and + J. McManus, "Requirements for Traffic Engineering Over + MPLS", RFC 2702, September 1999. + + [DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support + of Differentiated Services-aware MPLS Traffic + Engineering", RFC 3564, July 2003. + +13. Informative References + + [TE-OVW] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and + X. Xiao, "Overview and Principles of Internet Traffic + Engineering", RFC 3272, May 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. + + [OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic + Engineering (TE) Extensions to OSPF Version 2", RFC + 3630, September 2003. + + [ISIS-TE] Smit, H. and T. Li, "Intermediate System to + Intermediate System (IS-IS) Extensions for Traffic + Engineering (TE)", RFC 3784, June 2004. + + [TE-APP] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, + D., Christian, B., and W. Lai, "Applicability + Statement for Traffic Engineering with MPLS", RFC + 3346, August 2002. + + [FAST-REROUTE] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., + "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", + RFC 4090, May 2005. + + [LSP-PING] Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow, + G., Wadhwa, S., Bonica, R., "Detecting Data Plane + Liveliness in MPLS", Work in Progress. + + [MPLS-TTL] Agarwal, P. and B. Akyol, "Time To Live (TTL) + Processing in Multi-Protocol Label Switching (MPLS) + Networks", RFC 3443, January 2003. + + + + +Le Roux, et al. Informational [Page 19] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + + [LSP-HIER] Kompella, K., and Y. Rekhter, "LSP Hierarchy with + Generalized MPLS TE", Work in Progress. + + [MPLS-RECOV] Sharma, V. and F. Hellstrand, "Framework for Multi- + Protocol Label Switching (MPLS)-based Recovery", RFC + 3469, February 2003. + + [CRANKBACK] Farrel, A., Ed., "Crankback Signaling Extensions for + MPLS Signaling", Work in Progress. + + [MPLS-DIFF] 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. + + [DSTE-PROTO] Le Faucheur, F., et al., "Protocol Extensions for + Support of Differentiated-Service-aware MPLS Traffic + Engineering", Work in Progress. + + [DIFF-ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, + Z., and W. Weiss, "An Architecture for Differentiated + Service", RFC 2475, December 1998. + + [DIFF-AF] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, + "Assured Forwarding PHB Group", RFC 2597, June 1999. + + [DIFF-EF] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le + Boudec, J., Courtney, W., Davari, S., Firoiu, V., and + D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop + Behavior)", RFC 3246, March 2002. + + [MPLS-PREEMPT] Farrel, A., "Interim Report on MPLS Pre-emption", Work + in Progress. + + [METRIC] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., + and T. Telkamp, "Use of Interior Gateway Protocol + (IGP) Metric as a second MPLS Traffic Engineering (TE) + Metric", BCP 87, RFC 3785, May 2004. + + + + + + + + + + + + +Le Roux, et al. Informational [Page 20] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + +14. Editors' Addresses + + Jean-Louis Le Roux + France Telecom + 2, avenue Pierre-Marzin + 22307 Lannion Cedex + France + + EMail: jeanlouis.leroux@francetelecom.com + + + Jean-Philippe Vasseur + Cisco Systems, Inc. + 300 Beaver Brook Road + Boxborough, MA - 01719 + USA + + EMail: jpv@cisco.com + + + Jim Boyle + + EMail: jboyle@pdnets.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Le Roux, et al. Informational [Page 21] + +RFC 4105 Inter-Area MPLS TE Reqs June 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Le Roux, et al. Informational [Page 22] + |