draft-leroux-tewg-inter-area-te-reqs-00.txt December 2003 JP Vasseur (Editor) Cisco Systems, Inc. Jean-Louis Le Roux (Editor) France Telecom Ting-Wo Chung Bell Canada Raymond Zhang Infonet Services Corporation Kenji Kumaki KDDI Corporation Parantap Lahiri MCI Yuichi Ikeriji NTT Communications Corporation IETF Internet Draft Expires: June, 2004 December, 2003 draft-leroux-tewg-inter-area-te-reqs-00.txt MPLS Inter-area Traffic Engineering requirements 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. 1 draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003 Abstract This document lists the detailed set of requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE) which could serve as a guideline to develop the required set of protocol extensions. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Content 1. Terminology 2. Introduction 3. Overview of the requirements and objectives 3.1 Inter-area resources optimizations 3.2 Inter-area Qos guarantees 3.3 Fast recovery acrros IGP areas 4. Application scenario 5. Detailed requirements for inter-area MPLS Traffic Engineering 5.1 Objective to preserve IGP/RSVP scalability 5.2 Inter-area MPLS TE operations and interoperability 5.3 Protocol signalling and path computation 5.4 Path optimality 5.5 Support of diversely routed inter-area TE LSPs 5.6 Reoptimization of inter-area TE LSP 5.7 Support of fast recovery of inter-area TE LSP 5.8 DS-TE support 5.9 Hierarchical TE LSP support 5.10 Soft preemption 5.11 Auto-discovery 5.12 Mapping of traffic to inter-area TE LSP 5.13 Inter-area MPLS TE management 5.13.1 Inter-area MPLS TE MIB requirement 5.13.2 Inter-area MPLS TE fault management requirements 6 Evaluation criteria 6.1 Scalability 6.2 Performances 6.3 Complexity and risks 6.4 Backward compatibility 7. Security issues References 2 draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003 3 draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003 1. Terminology LSR: Label Switch Router LSP: MPLS Label Switched Path CSPF: Constraint-based Shortest Path First. Inter-area MPLS TE: TE LSP whose Head-end LSR and Tail-end LSR do not reside within the same IGP area or both Head-end LSR and Tail-end LSR are in the same IGP area but the TE LSP transiting path may be across different areas IGP area: OSPF area or IS-IS level ABR: Area Border Router (i.e router used to connect two IGP areas (ABR in OSPF or L1/L2 router in IS-IS) 2. Introduction The set of MPLS Traffic Engineering mechanisms documented in [RSVP-TE] may be deployed by Service Providers to achieve some of the most important objectives of network traffic engineering as described in [TE-OVW]. These objectives are summarized as listed below: - Supporting end-to-end services requiring QoS guarantees - Performing network resource optimization - Providing fast recovery However, the current set of MPLS traffic engineering mechanisms can only be used within a single IGP area. This document discusses the set of requirements a solution must or should satisfy in order to support the same set of functionalities across multiple IGP areas. Since the scope of requirements will vary between Operators, some requirements will be mandatory (MUST) whereas others will be optional (SHOULD). 3. Overview of the requirements and objectives 3.1. Introduction MPLS Traffic Engineering has been deployed in many OperatorsÆ networks for its capability to efficiently optimize the network bandwidth usage. One possible approach in the context of inter-area MPLS TE consists in deploying MPLS TE on a per-area basis but such an approach has several limitations: 4 draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003 -Basically per-area TE provides sub-optimal traffic engineering by optimizing resource independently in each area. And what many operators want is to optimize their areas as a whole, i.e. as if there was only one area (flat network). - The required traffic level aggregation at the ABR levels implies some constraints that do not lead to efficient traffic engineering, - The traffic aggregation does not allow to provide bandwidth guarantees on a per inter-area TE LSP basis, - The inter-area traffic cannot be protected with local protection mechanisms such as [FAST-REROUTE] in case of ABR node failure. 3.2. Inter-area resource optimization For the reasons mentioned above, it is desired to extend the current set of [RSVP-TE] mechanisms in order to be able to set up MPLS TE LSP across multiple IGP areas in order to efficiently achieve inter-area TE optimization. 3.3. Inter-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 or over a DiffServ domain to contribute to the enforcement of a (set of) QoS policy(ies), 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 the edge of the network. 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. It may also be desired to compute inter-area paths offering a shortest path across multiple areas that satisfy some bandwidth constraints, as currently possible within a single IGP area. For the sake of illustration, if the IGP metrics reflects the propagation delay, it may be needed to be able to find the optimal (shortest) path satisfying some bandwidth constraints across multiple areas: such a path would be the path offering the minimal propagation delay. One typical example of this requirement is to provide bandwidth guarantees over an end-to-end path for VoIP traffic classified as EF (Expedited Forwarding [DIFF_EF]) class in a Diffserv-enabled network. Another increasing popular deployment is driven by the need to carry pseudo-wire connection between gateways residing in different IGP 5 draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003 areas. When the EF path is extended across multiple IGP areas, inter- area bandwidth guarantee along with other constraints is then required. 3.4. Fast recovery across IGP areas As traffic sensitive application are getting deployed, one of the key requirements is to provide fast recovery (on the order of tens of msecs) mechanisms in case of network element failure (link/SRLG/node), which cannot be achieved with current IGPs. Hence, a strong requirement for inter-area MPLS TE is to provide fast recovery mechanisms to protect (some) inter-area traffic in case of link/node/SRLG failure. Note that this includes the failure of any link/SRLG/node within any IGP area and the failure of ABRs. It is worth highlighting that additional constraint like bandwidth guarantee during failure (while inter-area protected TE LSP are rerouted onto their respective backup tunnel) may also be required. This implies the ability to optimize the backup tunnel path in order to minimize the amount of backup bandwidth and limit the propagation delay increase during failure (along the backup tunnel path) for some traffic. 4. Application scenario <---area1---><---area0---><----area2-----> ------R1-ABR1-R2-------ABR3------- | | | | | R0 | | R4 | | R5 | | | ---------ABR2----------ABR4------ - ABR1, ABR2, ABR3 and ABR4 are ABRs - R0, R1, R5: LSRs in area 1 - R2: an LSR in area 0 - R4: an LSR in area 2 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. In some cases, it might also be possible to have an inter-area TE LSP from R0 to R5 transiting via the back-bone area (or any other levels with IS-IS). 5. Detailed requirements for inter-area MPLS Traffic Engineering 5.1. Objectives to preserve IGP/RSVP scalability Being able to achieve the requirements listed in this document MUST be performed while preserving the IGP scalability, which is of the utmost importance. Hence, the set of mechanisms defined to meet those 6 draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003 requirements MUST not require IGP extra-load which could compromise the IGP scalability. In particular, a solution satisfying those requirements MUST require for the IGP to carry some unreasonable amount of extra information and MUST not significantly increase the frequency of IGP flooding. Likewise, the solution MUST also preserve the scalability of RSVP TE ([RSVP-TE]). Moreover, the solution MUST preserve the concept of IGP hierarchy (no TE link information flooded across areas). 5.2. 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 be such that it will interoperate seamlessly with current intra-area MPLS TE mechanism and inherit its capability sets from [RSVP-TE]. See also [TE-REQ]. The proposed solution MUST allow to provision at the Head/Tail end with end-to-end RSVP signalling (eventually with loose paths) traversing across the interconnected ABRs, without further provisioning required along the transit path. 5.3. Protocol signaling and path computation The proposed solution MUST provide the ability to explicitly specify a set of LSRs including ABRs by means of strict or loose hops for the inter-area TE LSP. The solution SHOULD also allow the head-end LSR to explicitly specify the hops across the transit area on which path the constraints are met. In addition, the proposed solution SHOULD also provide the ability to specify and signal that certain loose or strict nodes and resources to be explicitly excluded in the inter-area TE LSP path establishment. If multiple signaling methods are proposed in the solution (e.g contiguous LSP, stitched or nested LSP), the Head-end LSR MUST have the ability to signal the required signaling method on a per-LSP basis. 5.4. Path optimality As already pointed out, the solution SHOULD provide the capability for the Head-end LSR to dynamically compute an optimal path satisfying a set of specified constraints defined in [TE-REQ] across multiple areas. Note that this requirement document does not mandate that all inter- area TE LSP require the computation of an optimal inter-area path: some inter-area TE LSP path may be computed via some mechanisms not guaranteeing an optimal end to end path whereas some other inter-area TE LSP paths carrying sensitive traffic could be computed making use of some mechanisms allowing to dynamically compute an optimal end to end path. Note that regular constraints like bandwidth, affinities, à MUST also be taken into account in the computation of an optimal end to end path. In the context of this requirement document, an optimal path is 7 draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003 defined as the shortest path across multiple areas taking into account either the IGP or TE metric. In other words, such a path is the path that would have been computed making use of some CSPF algorithm in the absence of areas. 5.5. Support of diversely routed inter-areas TE LSPs There are several cases where the ability to compute diversely routed TE LSP paths may be desirable: (1) A single TE LSP across multiple areas satisfying the required set of constraints cannot be found, in which case this may require load splitting. (2) Multiple TE paths may be required to limit the impact of a network element failure to a portion of the traffic. As an example, two VoIP gateways may load balance the traffic among a set of inter-area TE LSPs. (3) Path protection (e.g. 1:1 or 1:N) as discussed in [MPLS-Recov]. Hence, the solution SHOULD be able to provide the ability to compute diversely routed inter-area TE LSPs paths. In particular, if such paths obeying the set of constraints exist, the solution SHOULD be able to compute them. For the sake of illustration, there are some algorithms that may not always allow to find diversely routed TE LSPs because they make use of a two steps approach that cannot guarantee to compute two diversely routed TE LSP paths even if such a solution exist. This is in contrast with other methods that simultaneously compute the set of diversely routed paths and that can always find such paths if they exist. 5.6. Reoptimization of inter-area TE LSP The solution MUST provide the ability to reoptimize in a non disruptive fashion (make before break) an inter-area TE LSP, should a more optimal appear in any traversed area. The Operator should be able to trigger such a reoptimization on a timer or event-driven basis. It should also be possible to trigger such a reoptimization manually. Moreover, the solution SHOULD provide the ability for the Head-end LSR to be informed of the existence of a more optimal path in a downstream area and keep a strict control on the reoptimization process. Hence, the Head-end LSR, once informed of a more optimal path in some downstream areas, could decide (or not) to gracefully perform an end to end path reoptimization, according to the inter-area TE LSP characteristics. The ABR should check for optimality of the TE LSPs established through it based on a timer or triggered by an event. Option of providing manual trigger to check for optimality should also be provided. 8 draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003 5.7. Support of 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] in both the case of an intra-area network element failure (link/SRLG/Node) and an ABR node failure. Note that different protection techniques SHOULD be usable in different part of the network to protect an inter-area TE LSP. This is of the utmost importance in particular in the case of an ABR node failure that typically carries a great deal of inter-area traffic. Moreover, the solution SHOULD allow to compute and set up a backup tunnel following an optimal path that offers bandwidth guarantees during failure along with other potential constraints (like bounded propagation delay increase along the backup path). 5.8. DS-TE support The proposed inter-area MPLS TE solution SHOULD also satisfy core requirements documented in [DS-TE] and interoperate seamlessly with current intra-AS MPLS DS-TE mechanism [DSTE-PROT]. 5.9. Hierarchical LSP support In case of large inter-area MPLS deployment potentially involving a large number of edge LSRs, it can be desirable/necessary to introduce some level of hierarchy in the core in order to reduce the number of states on core LSRs. Hence, the proposed solution SHOULD allow inter- area TE LSP aggregation (also referred to as LSP nesting) such that individual tunnels can be carried onto one or more aggregating LSP. One such mechanism, for example is described in [MPLS-LSPHIE]. The solution SHOULD also provide the ability to advertise some TE LSPs as links as specified in [MPLS-LSPHIE]. 5.10. Soft preemption The solution MUST support the ability to make use of the soft preemption mechanisms for inter-area TE LSP such as one defined in [SOFT-PREEMP]. 5.11. Auto-discovery 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 automatically discover 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. 5.12. Mapping of traffic to inter-area TE LSP 9 draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003 In the case of intra-area MPLS TE, there are currently several possibilities to steer traffic to some intra-area TE LSP: the TE LSP can be automatically taken into account in the RIB computation, static routing can be used, à In the case of inter-area TE LSP, the proposed solution SHOULD at least support static routing coupled with recursive routing. For instance, an Operator should be able to route all the traffic sent to the set of routes announced by a (MP-)BGP speaker by means of a single static route to the corresponding BGP next hop address. 5.13. Inter-area Path selection policy For inter-area TE LSPs whose Head-End and Tail-End reside in the same IGP area, there may be intra-area and inter-area feasible paths. In case the shortest path is an inter-area path, an operator may either want to avoid, as far as possible, crossing area and thus 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 MUST allow to enable or disable area crossing, for inter-area TE LSPs whose Head-End and Tail-End reside in the same area. 5.14. Inter-area routing policy In case of inter-area TE LSP failure in the backbone or tail-end area, it may be interesting to allow the ABR upstream to the failure to try to recover the LSP using a procedure such as defined in [CRANKBACK]. This may reduce the recovery delay, but with the risk of multiple crankbacks, sub-optimal path, à The solution SHOULD provide the ability to allow/disallow crankback via signaling on a per-LSP basis. 5.15. Inter-area MPLS TE fault management requirements In a MPLS network, a SP wants to detect both control plane and data plane failures. But tools for fault detection over LSPs haven't been widely developed so far. SPs today manually troubleshoot such failures in a hop-by-hop fashion across the data path. If they detect an error on the data plane, they have to check the control plane in order to determine where the faults come from. The proposed solution SHOULD be able to interoperate with fault detection mechanisms of intra-area TE. The solution SHOULD support [LSP-PING] and [MPLS-TTL]. [LSP-PING] provides a mechanism to verify the data plane liveliness of MPLS TE LSPs. However, the mechanism does not include a method to verify the link/node protection paths. As for the backup paths, it is not possible to verify the data plane until such protection paths are actually in use. A control plane 10 draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003 mechanism allowing to check the validity of the backup paths is desired. The solution should be able to automatically verify the backup paths for inter-area TE LSP. 6. Evaluation criteria 6.1. Performances The solution SHOULD clearly be evaluated with respects to the following criteria: (1) Optimality of the computed inter-area TE LSP path, (2) Optimality of the computed backup tunnel path protecting against the failure of an ABR, capability to share bandwidth among backup tunnels protecting independent facilities. (3) Inter-area TE LSP set up time, Other criteria may be added in further revisions of this draft 6.2. Complexity and risks The proposed solution (s) SHOULD not introduce unnecessary complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such solution over SP networks. 6.3. Backward Compatibility The deployment of inter-area MPLS TE SHOULD not have impact on existing MPLS TE mechanisms to allow for a smooth migration or co-existence. 7. Security Considerations Inter-area MPLS-TE does not raise any new security issue, beyond those of intra-area MPLS-TE. References [RSVP] Braden, et al, " Resource ReSerVation Protocol (RSVP) û Version 1, Functional Specificationö, RFC 2205, September 1997. [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [TE-OVW], Awduche, et al, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002. [TE-REQ], Awduche et. al., "Requirements for Traffic Engineering over MPLS", RFC2702, September 1999. 11 draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003 [REFRESH-REDUCTION] Berger et al, ôRSVP Refresh Overhead Reduction Extensionsö, RFC2961, April 2001. [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, December 2003. [BANDWIDTH-PROTECTION] Vasseur et all, ôMPLS Traffic Engineering Fast reroute: bypass tunnel path computation for bandwidth protection ©, draft-vasseur-mpls-backup-computation-01.txt, October 2002, Work in progress. [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic- 09.txt(work in progress). [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", draft-ietf-isis-traffic-04.txt (work in progress) [SECOND-METRIC] Le faucheur, ôUse of IGP Metric as a second TE Metricö, Internet draft, draft-lefaucheur-te-metric-igp-02.txt. [MULTIPLE-METRICS] Fedyk D., Ghanwani A., Ash J., Vedrenne A. ôMultiple Metrics for Traffic Engineering with IS-IS and OSPFö, Internet draft, draft-fedyk-isis-ospf-te-metrics-01.txt [PATH-COMP] Vasseur et al, ôRSVP Path computation request and reply messagesö, draft-vasseur-mpls-computation-rsvp-04.txt, work in progress. [RSVP-CONSTRAINTS] Kompella, K., "Carrying Constraints in RSVP", (work in progress). [OSPF-TE-CAP] Vasseur, Psenak. "OSPF TE TLV capabilities", draft- vasseur-mpls-ospf-te-cap-00.txt, October 2002 (Work in Progress). [OSPF-CAP] Lindem et all ô Extensions to OSPF for Advertising Optional Router Capabilitiesö, draft-ietf-ospf-cap-01.txt, work in progress. [ISIS-CAP] Aggarwal et all, ôExtensions to IS-IS for Advertising Optional Router Capabilitiesö, work in progress [LSP-ATTRIBUTE] Farrel A. et al, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", (work in progress). [GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay Model", (work in progress). [EXCLUDE-ROUTE] Lee et all, Exclude Routes - Extension to RSVP-TE, draft-ietf-ccamp-rsvp-te-exclude-route-00.txt, work in progress. 12 draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003 [INTER-AREA-TE] Kompella et all,öMulti-area MPLS Traffic Engineeringö, draft-kompella-mpls-multiarea-te-04.txt, June 2003. [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G., Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS", Internet Draft , October 2002. (Work in Progress) [MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS Networks", RFC 3443 Updates RFC 3032) ", January 2003 [INTER-AS-TE-REQS] Zhang et al, ôMPLS Inter-AS Traffic Engineering requirementsö, draft-ietf-tewg-interas-mpls-te-req-03.txt (work in progress). [LOOSE-PATH-REOPT] Vasseur and Ikejiri, ôReoptimization of an explicit loosely routed MPLS TE pathsö, draft-vasseur-mpls-loose-path-reopt- 02.txt, June 2003, Work in Progress. [NODE-ID] Vasseur, Ali and Sivabalan, ôDefinition of an RRO node-id subobjectö, draft-ietf-mpls-nodeid-subobject-01.txt, June 2003, Work in progress. [LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, March 2002. [MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS Networks", RFC 3443 (Updates RFC 3032) ", January 2003. [INTER-AS-TE-LINK] JP Vasseur, ½ Inter-ASBR TE Link type ©, draft- vasseur-ccamp-inter-as-link-type-00, Work in progress. [MPLS-Recov] V. Sharma, et al, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469 February 2003 Authors' Address: JP Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: jpv@cisco.com Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France 13 draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003 E-mail: jeanlouis.leroux@francetelecom.com Ting-Wo Chung Bell Canada 181 Bay Street, Suite 350, Toronto, Ontario, Canada, M5J 2T3 Email: ting_wo.chung@bell.ca Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA Email: raymond_zhang@infonet.com Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN E-mail : ke-kumaki@kddi.com Yuichi Ikejiri NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 JAPAN Email: y.ikejiri@ntt.com Parantap Lahiri MCI 22001 louden county pky Ashburn, VA 20147 USA E-mail: parantap.lahiri@mci.com 14