IETF Internet Draft Raymond Zhang, Editor Internet Engineering Task Force Infonet Services Corporation Document: JP Vasseur, Co-Editor draft-ietf-tewg-interas-mpls-te-req-00.txt CISCO Systems, Inc May 2003 Expires: November 2003 MPLS Inter-AS Traffic Engineering requirements draft-ietf-tewg-interas-mpls-te-req-00.txt 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 discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). The main objective of this document is to present a set of requirements which would result in a set of general guidelines in the definition, selection and specification development for any technical solution(s) meeting these requirements. Summary for Sub-IP related Internet Drafts RELATED DOCUMENTS: None WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK TEWG WHY IS IT TARGETED AT THIS WG(s) It is stated in the charter that documenting SP requirements in this area are one of the work items to be undertaken by TEWG. JUSTIFICATION The TEWG charter further states that "The working group may also consider the problems of traffic engineering across autonomous systems boundaries." Zhang, Vasseur, et. al. [Page 1] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 This draft discusses the requirements for a traffic engineering mechanism across autonomous systems boundaries that would also be interoperable with current intra-AS traffic engineering machismo. 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. Table of Contents 1. Introduction.......................................................3 2. Contributing Authors...............................................3 3. Definitions and Requirements Statement.............................4 3.1. Definitions......................................................4 3.2. Objectives and Requirements of Inter-AS Traffic Engineering......6 3.2.1. Inter-AS Bandwidth Guarantees..................................6 3.2.2. Inter-AS Resource Optimization.................................7 3.2.3. Fast Recovery across ASes......................................8 3.3. Inter-AS Traffic Engineering Requirements Statement..............8 4. Application Scenarios..............................................8 4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees....8 4.1.1. Scenario I - Extended or Virtual PoP...........................8 4.1.2. Scenario II - Extended or Virtual Trunk........................9 4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE......10 4.2. Application Scenarios Requiring Inter-AS Resource Optimization..11 4.2.1. Scenario IV - TE across multi-AS within a Single SP Administrative Domain.........................................11 4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport..12 5. Detailed Requirements for Inter-AS MPLS Traffic Engnineering......13 5.1. Requirements within one SP Administrative Domain................13 5.1.1. Inter-AS MPLS TE Operations and Interoperability..............13 5.1.2. Protocol Signaling and Path Computations......................14 5.1.3. Optimality....................................................14 5.1.4. Support of diversely routed inter-AS TE LSP...................14 5.1.5. Re-optimization...............................................15 5.1.6. Fast Recovery support using MPLS TE Fast Reroute..............15 5.1.7. DS-TE Support.................................................15 5.1.8. Hierarchical LSP Support and Forwarding Adjacency (FA)........16 5.1.9. Mapping of traffic onto Multiple Inter-AS MPLS TE Tunnels.....16 5.1.10. Inter-AS MPLS TE Management..................................16 5.2. Requirements for Inter-AS MPLS TE across Multiple SP Administrative Domains..........................................17 5.2.1. Confidentiality...............................................17 5.2.2. Policy Control................................................17 5.2.2.1. Inter-AS TE Agreement Enforcement Polices...................18 5.2.2.2. Inter-AS TE Rewrite Policies................................18 6. Evaluation Criteria...............................................19 6.1. Detailed Requirement Satisfactions..............................19 6.2. Scalability and Extensibility...................................19 6.3. Complexity and Risks............................................19 6.4. Performance.....................................................19 Zhang, Vasseur, et. al. [Page 2] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 6.5. Backward Compatibility..........................................19 7. Security Considerations...........................................20 8. Acknowledgement...................................................20 9. Editor's Addresses................................................20 10. Normative References.............................................20 11. Informative References...........................................21 12. Full Copyright Statement.........................................22 Appendix A. Brief Description of BGP based Inter-AS Traffic Engineering..............................................23 1. Introduction The MPLS Traffic Engineering mechanism documented in [TE-RSVP] 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, this traffic engineering mechanism can only be used within an Autonomous System (AS). This document discusses requirements for an inter-AS MPLS Traffic Engineering mechanism that may be used to achieve the same set of objectives across AS boundaries within or beyond SPs'administrative domains. The document will also present a set of application scenarios where the inter-AS traffic engineering mechanism may be required. These application scenarios will also be used to further facilitate the discussions for a list of detailed requirements for such an inter-AS Traffic Engineering mechanism along with the evaluation criteria for any technical solution(s) meeting these requirements. Please note that there are other means of traffic engineering including IGP metrics based (for use within an AS) and BGP attribute based (for use across ASes; see Appendix A) traffic engineering mechanisms. However, these means offer coarser control of traffic paths, and do not readily offer bandwidth guarantees or fast restoration, and therefore will not be discussed further in this document. 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.): Zhang, Vasseur, et. al. [Page 3] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 Kenji Kumaki KDDI Corporation KDDI Bldg. 2-3-2, Nishishinjuku, Shinjuku-ku, Tokyo 163-8003, JAPAN E-mail : ke-kumaki@kddi.com Paul Mabey Qwest Communications 950 17th Street, Denver, CO 80202 USA Email: pmabey@qwest.com Nadim Constantine Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA Email: nadim_constantine@infonet.com Pierre Merckx áá EQUANT áá 1041 route des Dolines - BP 347 áá 06906 SOPHIA ANTIPOLIS Cedex áá FRANCE áá Email: pierre.merckx@equant.com Ting Wo Chung Bell Canada 181 Bay Street, Suite 350 Toronto, Ontario, Canada, M5J 2T3 Email: ting_wo.chung@bell.ca Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France E-mail: jeanlouis.leroux@francetelecom.com Yonghwan Kim SBC Technology Resources, Inc. 4698 Willow Road Pleasanton, CA 94588 USA Email: ykim@tri.sbc.com Zhang, Vasseur, et. al. [Page 4] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 3. Definitions and Requirements Statement 3.1. Definitions The following provide a list of abbreviations or acronyms specifically pertaining to this document: SP: Service Providers including regional or global providers SP Administrative Domain: a single SP administration over a network or networks that may consist of one AS or multiple ASes. IP-only networks: SP's network where IP routing protocols such as IGP/ BGP are activated IP/MPLS networks: SP's network where MPLS switching capabilities and signaling controls (e.g. ones described in [MPLS-ARCH]) are activated in addition to IP routing protocols. Intra-AS TE: A generic definition for traffic engineering mechanisms operating over IP-only and/ or IP/MPLS network within an AS. Inter-AS TE: A generic definition for traffic engineering mechanisms operating over IP-only and/ or IP/MPLS network across one or multiple ASes. TE LSP: MPLS Traffic Engineering Label Switched Path Intra-AS MPLS TE: An MPLS Traffic Engineering mechanism where its TE LSPs Head-end LSR and Tail-end LSR reside in the same AS for traffic engineering purposes. Inter-AS MPLS TE: An MPLS Traffic Engineering mechanism where its TE LSPs Head-end LSR and Tail-end LSR do not reside within the same AS or both Head-end LSR and Tail-end LSR are in the same AS but the TE LSP transiting path may be across different ASes ASBR Routers: Border routers used to connect to another AS of a different or the same Service Provider via one or more links inter-connecting between ASes. Inter-AS TE Path: An TE path traversing multiple ASes and ASBRs, e.g. AS1-ASBR1-inter-AS link(s)-ASBR2-AS2...ASBRn-ASn. Inter-AS TE Segment: A portion of the Inter-AS TE path. PCS: Path Computation Server (e.g. an LSR or an off-line tool) PCC: Path Computation Client (e.g. an LSR) Zhang, Vasseur, et. al. [Page 5] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 CE: Customer Edge Equipment PE: Provider Edge Equipment that has direct connections to CEs. P: Provider Equipment that has backbone trunk connections only. VRF:Virtual Private Network (VPN) Routing and Forwarding Instance. PoP: Point of presence or a node in SP's network. SRLG: A set of links may constitute a 'shared risk link group' (SRLG) if they share a resource whose failure may affect all links in the set as defined in [GMPLS-ROUT]. Please note that the terms of CE, PE and P used throughout this document are generic in their definitions. In particular, whenever such acronyms are used, it does not necessarily mean that CE is connected to a PE in a VRF environment described in such IETF drafts as [BGP-MPLSVPN]. 3.2. Objectives and Requirements of Inter-AS Traffic Engineering As mentioned in section 1 above, some SPs have requirements for achieving the same set of traffic engineering objectives as presented in [TE-OVW] across AS boundaries. This section examines these requirements in each of the key corresponding areas: 1) Inter-AS bandwidth guarantees; 2) Inter-AS Resource Optimization and 3) Fast Recovery across ASes, i.e. Recovery of Inter-AS Links/SRLG and ASBR Nodes. 3.2.1. Inter-AS Bandwidth 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 SPs have some or full deployment of Diffserv implementations in their networks today, either across the entire network or at the least, on the edge of the network across CE-PE links. 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. Zhang, Vasseur, et. al. [Page 6] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 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. When the EF path is extended across multiple ASes, inter-AS bandwidth guarantee is then required. Another case for inter-AS bandwidth guarantee is the requirement for guaranteeing a certain amount of transit bandwidth across one or multiple ASes. Several application scenarios are presented to further illustrate this requirement in section 4 below. 3.2.2. Inter-AS Resource Optimization In Service Provider (SP) networks, the BGP protocol [BGP] is deployed to exchange routing information between ASes. The inter-AS capabilities of BGP may also be employed for traffic engineering purposes across the AS boundaries. Appendix A provides a brief description of the current BGP-based inter-AS traffic engineering practices. SPs have managed to survive with this coarse set of BGP-based traffic engineering facilities across inter-AS links in a largely best effort environment. Certainly in many cases ample bandwidth within SP's network and across inter-AS links reduces the need for more elaborated inter-AS TE policies. However, in the case where a SP network is deployed over multiple ASes, for example, as the number of inter-AS links grows, the complexity of the inter-AS policies and the difficulty in inter-AS TE path optimization increase to a level such that it may soon become unmanageable. Another example is where inter-AS links are established between different SP administrative domains. Un-deterministic factors such as un-coordinated routing and network changes as well as sub-optimum traffic conditions would potentially lead to a complex set of Inter-AS traffic engineering policies where current traffic engineering mechanisms would probably not scale well. In these situations where resource optimization is required and/ or specific routing requirements arise, the BGP-based inter-AS facilities will need to be complemented by a more granular inter-AS traffic engineering mechanism. 3.2.3. Fast Recovery across ASes When extending services such as VoIP across ASes, customers often demands SPs to maintain the same level of performance targets such as packet loss and service availability as ones that can be achieved within an AS. As a consequence, fast convergence in a stable Zhang, Vasseur, et. al. [Page 7] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 fashion upon link/SRLG/node failure becomes a strong requirement, clearly difficult to achieve with current inter-domain techniques, especially in cases of link/SRLG failures between ASBRs or ASBR node failures. 3.3. Inter-AS Traffic Engineering Requirements Statement Just as in the applicable case of deploying MPLS TE in a SP's network, an inter-AS TE method in addition to BGP-based traffic engineering capabilities needs to be deployed across inter-AS links over where resource optimization, QOS guarantees and fast recovery are required. This is especially critical in a Diffserv-enabled, multi-class environment described in [PSTE] where statistical performance targets must be maintained consistently over the entire path across different ASes. The approach of extending current intra-AS MPLS TE capabilities [TE-RSVP] across inter-AS links for IP/MPLS networks is considered here because of already available implementations and operational experiences. Please note that the inter-AS traffic engineering over an IP-only network is for future consideration since there is no sufficient interest for similar requirements to those of IP/MPLS networks at this time. 4. Application Scenarios The following sections present a few application scenarios over IP/MPLS networks where requirements cannot be addressed with current intra-AS MPLS TE mechanism and give rise to considerations for inter-AS MPLS traffic engineering requirements. Although not explicitly noted in the following discussions, fast recovery of traffic path(s) crossing multiple ASes in a stable fashion is particularly important in case of link/SRLG/node failure at AS boundaries for all application scenarios presented here. 4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees 4.1.1 Scenario I - Extended or Virtual PoP (VPoP) A global service provider (SP1), for example would like to expand its reach in a region where a regional service provider's (SP2) network has already established an extended coverage in its PoP density. In this scenario, the SP1 may establish interconnections with SP2 in one or multiple points in that region. It may then use SP2's network as an extended transport by co-locating aggregation routers in some SP2's PoPs that are in the regions where SP1 has a larger number of customer sites. Zhang, Vasseur, et. al. [Page 8] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 In order to ensure bandwidth capacity provided by SP2 and achieve some degrees of transparency to SP2's network changes in terms of capacity and network conditions, one or more Inter-AS MPLS TE trunk(s) can be built between SP1's ASBR or PE router inside AS1 and SP1's PE routers co-locating in SP2's PoPs, as illustrated in the diagram below: <===========Inter-AS MPLS TE Tunnel===========> ----- ----- ________|ASBR |___Inter-AS___|ASBR |________ | | RTR | Link | RTR | | ---- ----- ----- ----- ----- |SP1 |_____| SP2 | | SP1 | |VPoP| |P/PE | |P/PE | ---- ----- ----- ----- ----- |________|ASBR |___Inter-AS___|ASBR |________| | RTR | Link | RTR | ----- ----- <=================Inter-AS MPLS TE Tunnel=================> +-SP1 AS1-+ +-------SP2 AS2-----+ +------SP1 AS1------+ In situations where end-to-end Diffserv paths must be maintained, both SP's networks may need to provision Diffserv PHB at each hop supporting a set of traffic classes with compatible performance targets. The subsequent issues regarding Service Level Agreement (SLA) boundaries, reporting and measuring system inter-operability and support demarcations are beyond the scope of this document and will therefore not be discussed here. Note also that either the SP1 or SP2 network may not be a Diffserv-aware network. The scenario would still apply to provide bandwidth guarantees. The SP2, on the other hand, can similarly choose to expand its reach beyond its servicing region over SP1's network via inter-AS MPLS TE paths. It is worth mentioning that these remote aggregation routers co-located in other SP's network will unlikely participate in hosting SP's IGP and BGP routing planes and will most likely maintain its own AS or be part of the SP1's AS. In this case, such TE tunnels may cross several ASes, but the Head-end and Tail-end LSRs of TE tunnel may have the same AS number, as shown in the diagram above. 4.1.2. Scenario II - Extended or Virtual Trunk Instead of co-locating a PE router in SP2's PoP, SP1, for example may also choose to aggregate customer VPN sites onto a SP2's PE router where inter-AS TE tunnels can be built and signaled through SP2's MPLS network between the SP2 PoP (to which SP1 customer CEs are directly connected) and SP1's ASBR or PE routers inside SP2's network. This allows SP1Æs customers connected to SP2 PE router to receive a guaranteed bandwidth service up to the TE LSP tail-end router located in SP1's network. Zhang, Vasseur, et. al. [Page 9] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 In this scenario, there could be two applicable cases: Case 1 - the inter-AS MPLS TE tunnel functions as an extended or virtual trunk aggregating SP1 CE's local-loop access circuits on SP2's MPLS network over which the bandwidth can be guaranteed to the TE LSP tail-end router located in SP1Æs network, as shown in the diagram below: <====Inter-AS MPLS TE Tunnel====> or < ===Inter-AS MPLS TE Tunnel===============> ---- ----- ----- ----- ----- | CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 | | | Loop | PE | | RTR | Link | RTR | |PE | ---- ----- ----- ----- ----- +SP1 Customer AS3+ +-----SP2 AS2---+ +-SP1 AS1-------+ Case 2 - the inter-AS MPLS TE tunnel in this case functions as an extended or virtual local access link from SP1's CE on SP2's network to the SP1's ASBR or PE: <==============Inter-AS MPLS TE Tunnel==============> or <==============Inter-AS MPLS TE Tunnel========================> ---- ----- ----- ----- ----- | CE |____Local_____| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 | | | Loop | PE | | RTR | Link | RTR | |PE | ---- ----- ----- ----- ----- +SP1 Customer AS3+ +------SP2 AS2---+ +--SP1 AS1-----+ In case 2 above, SP2 may elect to establish an aggregating or hierarchical intra-AS MPLS TE tunnel between the transiting P or PE router and SP2's ASBR router just to reduce the number of tunnel states signaled from the SP2 PE to where SP1's CEs are connected. 4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE In this scenario as illustrated below, customers require to establish MPLS TE tunnel from CE1 to CE2 end-to-end across several SP's networks. One application example would be guaranteed bandwidth for services such as voice- or video-over-IP services. <======================Inter-AS MPLS TE Tunnel==================> --- ----- ----- ----- ----- --- |CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2| | | | PE | | RTR | Link | RTR | | PE | | | --- ----- ----- ----- ----- --- +Cust AS1+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASx+ Zhang, Vasseur, et. al. [Page 10] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 The diagram below illustrates another example where CE1 and CE2 are customers of SP1 with eBGP peering relationships established across the CE-PE links. A inter-AS MPLS TE tunnel may then be established from CE1 in AS1 to CE2 which may belong to the same AS or different AS than that of CE1 across SP1's network in AS2. <===============Inter-AS MPLS TE Tunnel=====================> --- ----- ---- ---- ----- --- |CE1|______| SP1 |_____|SP1 |____|SP1 |____| SP1 |_________|CE2| | | | PE1 | |P1 | |P2 | | PE2 | | | --- ----- ---- ---- ----- --- +-Cust AS1-+ +-------------SP1 AS2----------------+ +-Cust ASx-+ The above example shows that SP1's network has a single AS. Obviously, there may be multiple ASes between CE1 and CE2 as well in the SP1's network. In addition, where both CE1 and CE2 residing in the same AS, they likely share the same private AS number. Scenario III however, will not scale well should there be a larger number of nter-AS TE MPLS tunnels in some degrees of partial mesh or full mesh. Therefore, it is expected that this scenario will not have a large number of deployments. 4.2. Application Scenarios Requiring Inter-AS Resource Optimization The scenarios presented in this section mainly deal with inter-AS resource optimization. 4.2.1. Scenario IV - TE across multi-AS within a Single SP Administrative Domain As mentioned in [TE-APP], SPs have generally admitted that the current MPLS TE mechanism provides a great deal of tactical and strategic values in areas of traffic path optimization [TE-RSVP] and rapid local repair capabilities [TE-FRR] via a set of on-line or off-line constraint-based searching algorithms. From a service provider's perspective, another way of stating the objectives of traffic engineering is to be able to deliver more customer traffic with already available capacity in the network without violating performance targets, and/ or to provide better QOS services via an improved network utilization, operating more likely below congestion thresholds. It is worth noting that situations where resource provisioning is not an issue, e.g. low density in inter-AS connectivity or ample inter-AS capacity may not require more scalable and granular TE facilities beyond BGP routing policies since such policies could be rather simple and because inter-AS resource optimization is not an absolute requirement. Zhang, Vasseur, et. al. [Page 11] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 However many SPs, especially those with networks across multiple continents as well as sparsely connected, have designed their multi-AS routing policies, for example, along or within the continental or sub-continental boundaries where the number of ASes can range from a very few to dozens. Generally, inter-continent or sub-continent capacity is very expensive. Some Service Providers have multiple ASes in the same country and would like to optimize resources over their inter-region links. This would demand a more scalable degree of resource optimization, which warrants the consideration of extending current intra-AS MPLS TE capabilities across inter-AS links. In addition, one may only realize higher efficiency in conducting traffic optimization and path protection/ restoration planning when coordinating all network resources (not partially) as a whole. For a network which may consist of many ASes, this could be realized via the establishment of inter-AS TE LSPs. The motivation for inter-AS MPLS TE is even more prominent in a Diffserv-enabled network over which statistical performance targets are to be maintained from any point to any point of the network as illustrated in the diagram below with an inter-AS TE LSP or potentially a DS-TE LSP [DS-TE]: <===================Inter-AS MPLS DS-TE Tunnel=============> ---- ----- ----- ----- ----- ---- | PE |__| P |___|ASBR |___Inter-AS___|ASBR |___|P |___|PE | | RTR| | RTR | | RTR | Link | RTR | |RTR | |RTR | ---- ----- ----- ----- ----- ---- +------------SP1 AS1---------+ +------------SP1 AS2------+ For example , the inter-AS MPLS DS-TE LSP shown in the diagram above could be used to transport a set of L2 Pseudo Wires or VoIP traffic with corresponding QoS requirement. Furthermore, fast recovery in case of ASBR-ASBR link failure or ASBR node failure is a strong requirement for such services. 4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport Scenario V presents another possible deployment case. SP1 with AS1 wants to link a regional network to its core backbone by building an inter-AS MPLS TE tunnel over one or multiple transit ASes belonging to SP2, SP3, etc. as shown in the following diagram: <===========Inter-AS MPLS TE Tunnel=======> [ ] [ ] [ ] [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] [ |P/PE|__|ASBR|]_Inter-AS_[|ASBR|..|ASBR|]_Inter-AS_[|ASBR| |P/PE|] [ |RTR | |RTR |] Link [|RTR | |RTR |] Link [|RTR | |RTR |] [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] [ ] [ ] [ ] <================Inter-AS MPLS TE Tunnel=====================> +SP1 Regional ASx+ +Transit SP2,SP3,etc.ASi+ +------SP1 AS1-+ Zhang, Vasseur, et. al. [Page 12] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 This scenario can be viewed as a broader case of Scenario I shown in section 4.1.1 where the "VPoP" could be expanded into a regional network of SP1. By the same token, the AS number for SP1's regional network ASx may be the same as or different from AS1. The inter-AS MPLS TE LSP in this case may also be used to backup an internal path as depicted in the diagram below, although this could introduce routing complexities: <===========Inter-AS MPLS TE Tunnel=======> +----------------------------SP1 AS1-----------------------------+ [ ] [ ---- ---- ---- ---- ] [ |P/PE|__|ASBR|__________Primary Intera-AS________|P | |PE |] [ |RTR | |RTR | Link |RTR | |RTR |] [ ---- ---- ---- ---- ] [ | | ] [ ---- ---- ] [ |ASBR| |ASBR| ] [ |RTR | |RTR | ] [ ---- ---- ] ^ | | ^ | | | | | | [ ] | | | | [ ---- ---- ] | | | |__ Inter-AS_[|ASBR|..|ASBR|]_Inter-AS_| | | Link [|RTR | |RTR |] Link | | [ ---- ---- ] | | [ ] | | | +======Backup Inter-AS MPLS TE Tunnel======+ +Transit SP2,SP3,etc.ASi+ 5. Detailed Requirements for Inter-AS MPLS Traffic Engnineering This section discusses detailed requirements for inter-AS MPLS TE in two principal areas: 1) requirements for inter-AS MPLS TE in the same SP administrative domain and 2) requirements for inter-AS MPLS TE across different SP administrative domains. 5.1. Requirements within one SP Administrative Domain This section presents detailed requirements for inter-AS MPLS TE within the same SP administrative domain. 5.1.1. Inter-AS MPLS TE Operations and Interoperability The inter-AS MPLS TE solution SHOULD be consistent with requirements discussed in [TE-REQ] and the derived solution MUST be such that it will interoperate seamlessly with current intra-AS MPLS TE mechanism and inherit its capability sets from [TE-RSVP]. Zhang, Vasseur, et. al. [Page 13] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 The proposed solution MUST allow to provision at the Head/Tail end with end-to-end RSVP signaling (eventually with loose paths) traversing across the interconnected ASBRs, without further provisioning required along the transit path. 5.1.2. Protocol Signaling and Path Computations One can conceive that an inter-AS MPLS TE tunnel path signaled across inter-AS links consists of a sequence of intra-AS segments. The proposed solution SHOULD provide the ability to either explicitly select or auto-discover a set of ASBR LSRs over where an inter-AS TE must traverse. For example, one may provide a manual description of all or some of the hops (loose routing) the TE LSP must traverse, allowing to keep the information related to the intra-AS resources confidential while still leaving intra-AS routing decisions to local operators. The solution may allow the Head-end LSR to compute the TE LSP path up to the next entry point in the next hop AS. In another example, an automated way of setting up the TE LSP without any static configuration on the Head-End LSR. In that case, it might require a discovery mechanism of some PCS using IGP extensions (as defined in [OSPF-TE-CAP], for example), as well as some signaling protocol extension to request the computation of an inter-AS TE LSP to a PCS(s) such as one defined in [PATH-COMP]. 5.1.3 Optimality The solution SHOULD allow the set up of an inter-AS TE LSP that complies with a set of TE constraints defined in [TE-REQ]) and follow an optimal path. An optimal path is defined as a path whose end-to-end cost is minimal, based upon either an IGP or a TE metric. Note that in the case of an inter-AS path across several ASes having completely different IGP metric policies, the notion of minimal path might require IGP metric normalization, for example. 5.1.4 Support of diversely routed inter-AS TE LSP In some cases it might be desirable to set up multiple inter-AS TE LSPs between a pair of LSRs, when: (1) A single TE LSP satisfying the required set of constraints cannot be found, in which case it 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-AS TE LSPs. Zhang, Vasseur, et. al. [Page 14] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 (3) Path protection (e.g. 1:1 or 1:N) as discussed in [MPLS-Recov]. In the examples above, being able to set up diversely routed TE LSPs becomes a requirement for inter-AS TE. The solution SHOULD be able to set up a set of link/SRLG/Node diversely routed inter-AS TE LSPs. 5.1.5. Re-optimization Once an inter-AS TE LSP has been established and should there be any resource or other changes inside anyone of transiting ASes, the solution MUST be able to re-optimize the LSP accordingly and non-disruptively, either upon expiration of a configurable timer or triggered by a network event or a manual request at the TE tunnel Head-end. The solution SHOULD support the ability for intermediate nodes to signal the respective Head-End LSRs of the existence of a more optimal path. The solution SHOULD also be such that an inter-AS TE LSP is re-signaled again (via make before break) if and only if a more optimal path exists. Furthermore the solution SHOULD provide the ability of manually rejecting re-optimization at AS boundaries. 5.1.6. Fast Recovery support using MPLS TE Fast Reroute There are in general two or more inter-AS links between multiple pair of ASBRs for redundancy. The topological density between ASes in a multi-AS SP network is generally much higher. In the event of inter-AS link failure, rapid local protection SHOULD also be made available and interoperate with current intra-AS MPLS TE fast re-route mechanism from [TE-FRR]. Moreover, the traffic routed onto an inter-AS TE tunnel SHOULD also be fast protected against any node failure, should the node be internal to an AS or at the AS boundary. 5.1.7. DS-TE Support The proposed inter-AS 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]. It is worth pointing out that the compatibility clause in section 4.1 of [DS-TE] SHOULD also be faithfully applied in the development of the solutions. Zhang, Vasseur, et. al. [Page 15] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 5.1.8. Hierarchical LSP Support and Forwarding Adjacency (FA) It is conceivable that there would potentially be scalability issues as the number of required inter-AS MPLS TE tunnels increases. In order to reduce the number of tunnel states to be maintained by each transiting PoP, the proposed solution SHOULD allow TE LSP aggregation such that individual tunnels can be carried onto one or more aggregating LSP. One such mechanism, for example is described in [MPLS-LSPHIE]. In cases where inter-AS MPLS TE tunnels are terminated at P routers in a PoP where there could also be multiple PE routers, the proposed solution SHOULD provide the ability whereby to "announce" the inter-AS MPLS TE tunnels as a link into the IGPs (ISIS or OSPF) with the link's cost associated with it. By doing so, PE routers that do not participate in the inter-AS TE path computation can take into account such links in its IGP-based SPF computation. One such process, for example, is discussed in details in [MPLS-LSPHIE]. 5.1.9. Mapping of traffic onto Multiple Inter-AS MPLS TE Tunnels There SHOULD be several possibilities to map a particular traffic to a particular destination onto a specific inter-AS TE LSP. For example, static routing could be used if IP destination addresses are known. Another example is to utilize static routing using recursive BGP route resolution. 5.1.10. Inter-AS MPLS TE Management 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-AS TE and MAY or MAY NOT require the inter-AS TE tunnel ending addresses to be known or routable across IGP areas (OSPF) or levels(IS-IS) within the transiting ASes with working return paths. For example, [LSPPING] is being considered as a failure detection mechanism over the data plane against the control plane and could be used to troubleshoot intra-AS TE LSPs. Such facilities, if adopted, SHOULD then be extended to inter-AS TE paths. The above example, however depicts one such mechanism that does require a working return path such that diagnostic test packets can return via an alternate data plane, such as a global IPv4 path in the event that the LSP is broken. Zhang, Vasseur, et. al. [Page 16] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 [MPLS-TTL] presents how TTL may be processed across a hierarchical MPLS networks and such a facility as this SHOULD also be extended to inter-AS TE links. 5.2. Requirements for Inter-AS MPLS TE across Multiple SP Administrative Domains. The requirements for inter-AS MPLS TE across multiple SP admin domains SHOULD include all requirements discussed in section 5.1 above in addition to what are presented in this section here. Please note that the SP with multi-AS networks may choose not to turn on the features discussed in the following two sections when building TE tunnels across ASes in its own domain. 5.2.1. Confidentiality Since an inter-AS TE LSP may span multiple ASes belonging to different SPs, the solution MIGHT allow to "hide" the set of hops used by the TE LSP within an AS as illustrated in the following example: [ ASBR1-----ASBR2 ] [ ] [ ] [ A ] [ B ] [ AS1 ] [ AS2 ] [ SP1 ]-----[ SP2 ] [ ] [ ] Suppose there is an inter-AS TE LSP from A (within AS1 of SP1) to B (within AS2 of SP2). When computing an inter-AS TE LSP path, the set of hops within AS2 might be hidden to AS1. In this case, the solution will allow A to learn that the more optimal TE LSP path to B that complies with the set of constraints traverses ASBR2 without a detailed knowledge of the lists of the hops used within AS2. Optionally, the TE LSP path cost within AS2 could be provided to A, via for example PCC-PCS signaling [PATH-COMP], such that A (PCC) could use this information to compute an optimal path, even if the computed path is not provided by AS2. In addition, the management requirements discussed in section 5.1.10 above, when used across different SP admin domains, SHOULD include similar confidentiality requirements discussed here in terms of "hiding" intermediate hops or interface address and/ or labels in the transiting or peering SPs. 5.2.2. Policy Control In some cases, some policy control might be necessary at the AS boundaries, namely ingress policy controls enabling SPs to enforce the inter-AS policies per interconnect agreements or modify some requested parameters conveyed by incoming inter-AS MPLS TE signaling requests. Zhang, Vasseur, et. al. [Page 17] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 It is worth noting that such policy control mechanism may also be used between ASes within a SP. This section only discusses the elements that may be used to form a set of ingress control policies. However, how exactly SPs establish bilateral or multilateral agreements upon which the control policies can be built are beyond the scope of this document. 5.2.2.1. Inter-AS TE Agreement Enforcement Polices The following provides a set of TE-LSP parameters in the inter-AS TE requests(RSVP Path Message) that could be enforced at the AS boundaries: - RSVP-TE session attributes: affinities and preemption priorities - Per AS or SP bandwidth admission control to ensure that RSVP-TE messages do not request for bandwidth resources over their allocation. - Request origins which can be represented by HE tunnel ending IP address, originating AS#, neighbor AS#, neighbor ASBR interface IP address, etc. - DS-TE TE-Class . - FRR attribute: local protection desired bit, node protection desired bit and bandwidth protection desired bit carried in the SESSION - ATTRIBUTE or the FAST-REROUTE objects in the RSVP Path message as defined in [TE-FRR]. - Optimization allowed or not. In some cases, a TE policy server could also be used for the enforcement of inter-AS TE policies. This requirement could allow SPs to make the inter-AS TE policies scale better. The signaling of a non policy compliant request MAY trigger the generation of a RSVP Path Error message by the policy enforcing node towards the Head-end LSR, optionally indicating the cause. The Head-end LSR SHOULD take appropriate actions, such as re-route, upon receipt of such a message. 5.2.2.2. Inter-AS TE Rewrite Policies In some situations, SPs may need to rewrite some attributes of the incoming inter-AS TE signaling requests due to for example, a lack of resources for a particular TE-Class, non compliant preemption, upon mutual agreements. The following lists a set of parameters that can potentially be rewritten at the AS boundaries: - RSVP-TE session attributes: affinities and preemption priorities - DS-TE TE-Class . - ERO expansion requests Simimarly, the re-writing node can generate a RSVP Path Error Message towards the Head-end LSR, optionally indicating the cause. Zhang, Vasseur, et. al. [Page 18] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 6. Evaluation Criteria There may be multiple solutions to satisfy the requirements for Inter-AS MPLS TE presented in previous sections. This section provides general guidelines, which could be applied in the selection of an optimum solution. 6.1. Detailed Requirement Satisfactions The proposed solution SHOULD include at least all of the Application Scenarios presented in section 4 above. It MUST meet all the requirements described in section 5 each time a MUST is specified. 6.2. Scalability and Extensibility The proposed solution(s) MUST have minimum impact on the network scalability from both intra and inter-AS perspectives. This requirement applies to both of the following: - IGP (impact in terms of IGP flooding, SPF, etc.). - BGP (impact in terms of additional information carried within BGP, number of routes, flaps, overload events, etc.). - RSVP TE (message rate, number of retained states, ,etc.). In addition, the solution(s) MUST allow extensions as both inter-AS MPLS TE and current intra-AS MPLS TE specifications evolve. 6.3. 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.4. Performance The solution SHOULD be evaluated taking into account various performance criteria: - Degree of path optimality of the inter-AS TE LSP path - TE LSP setup time. - Fail and restoration time Other criteria might be added as this draft will evolve. 6.5. Backward Compatibility The deployment of inter-AS MPLS TE SHOULD not have impact on existing BGP-based traffic engineering or MPLS TE mechanisms to allow for a smooth migration or co-existence. Zhang, Vasseur, et. al. [Page 19] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 7. Security Considerations The proposed solution(s) MUST address security issues across multiple SP administrative domains. Although inter-AS MPLS TE is not expected to add specific security extensions beyond those of current intra-AS TE, greater considerations MUST be given in terms of how to establish a trusted model across AS boundaries. SPs SHOULD have a means to authenticating, allowing and possibly denying inter-AS signaling requests and SHOULD be protected from DoS attacks. 8. Acknowledgement We would like to thank Yuichi Ikejiri, David Allan, Kurt Erik Lindqvist, Dave McDysan, Christian Jacquenet and Kireeti Kompella, Ed Kern for their suggestions and helpful comments during our discussions of this draft. 9. Editor's Addresses Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA Email: raymond_zhang@infonet.com JP Vasseur CISCO Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: jpv@cisco.com 10. Normative References [TE-REQ], Awduche et. al., "Requirements for Traffic Engineering over MPLS", RFC2702, September 1999. [TE-RSVP], Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001 [GMPLS-ROUT], Kompella, et. al., "Routing Extensions in Support of Generalized MPLS", draft-ietf-ccamp-gmpls-routing-05.txt, August 2002 [BGP], Rekhter, et. al., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995 [LSPPING], Kompella, et.. al.," Detecting Data Plane Liveliness in MPLS", Internet Draft , October 2002. (Work in Progress) Zhang, Vasseur, et. al. [Page 20] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 [MPLS-TTL], Agarwal, et. al., "Time to Live (TTL) Processing in MPLS Networks", RFC 3443, January 2003 [DS-TE], Le Faucheur, et. al., ''Requirements for support of DiffServ-aware MPLS Traffic Engineering'', draft-ietf-tewg-diff-te-reqts-01.txt, June 2001. (Work in Progress) [DSTE-PROT], Le Faucheur, et. al., "Protocol extensions for support of Diff-Serv-aware MPLS Traffic Engineering", February, 2003 (Work in Progress) [TE-FRR], Pan, et. al., "Fast Reroute Techniques in RSVP-TE", Internet Draft, draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt , October 2002. (Work in Progress) [ISIS-TE], Smit, Li, "IS-IS extensions for Traffic Engineering", draft-ietf-isis-traffic-03.txt, June 2001. (Work in Progress) [OSPF-TE] Katz, Yeung, "Traffic Engineering Extensions to OSPF, draft-katz-yeung-ospf-traffic-05.txt", June 2001. (Work in Progress) [PATH-COMP], Vasseur, et. al., ''RSVP Path computation request and reply messages'', draft-vasseur-mpls-computation-rsvp-03.txt, June 2002. (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) [MPLS-LSPHIE] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt , March 2002. (work in progress) [MPLS-Recov], Sharma V., et al, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, Feb, 2003 [BGP-Label], Rekhter and Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001 [INTER-AS-TE], Vasseur and Zhang, "Inter-AS MPLS Traffic Engineering", draft-vasseur-inter-as-te-00.txt, February 2003 (work in progress) 11. Informative References [MPLS-ARCH], Rosen, et. al., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001 [BGP-MPLSVPN], Rosen, et. al., "BGP/MPLSVPN", draf-ietf-ppvpn -rfc3547bis-02.txt", July 2002 [DIFF_ARCH], Blake, et. al., "An Architecture for Differentiated Services", RFC 2475, December 1998. Zhang, Vasseur, et. al. [Page 21] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 [DIFF_AF], Heinanen,et. al., "Assured Forwarding PHB Group", RFC 2597, June 1999. [DIFF_EF], Davie, et. al., "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [MPLS-Diff], Le Faucheur, et. al., "MPLS Support of Differentiated Services", RFC 3270, May 2002 [TE-OVW], Awduche, et. al., "Overview and Principles of Internet Traffic Engineering", RFC 3272,May 2002 [PSTE], Li, et. al., "A Provider Architecture for Differentiated Services and Traffic Engineering", RFC 2430, October 1998 [TE-APP], Boyle, et. al., "Applicability Statement of Traffic Engineering", RFC 3346, August 2002. [TE-SURVIV], Lai, et. al., "Network Hierachy and Multilayer Suvivability", RFC 3386, November, 2002. 12. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process MUST be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Zhang, Vasseur, et. al. [Page 22] Internet Draft draft-ietf-tewg-interas-mpls-te-req-00.txt May 2003 Appendix A. Brief Description of BGP based Inter-AS Traffic Engineering In today's Service Provider (SP) network, BGP is deployed to meet two different sets of requirements: - Establishing a scalable exterior routing plane separating from data forwarding plane within SP's administrative domain - Exchanging network reachability information with different BGP autonomous systems (ASes) that could belong to a different SP or simply, a different AS within a SP network. Over connections across the AS boundaries, traffic engineering may also be accomplished via a set of BGP capabilities by appropriately enforcing BGP-based inter-AS routing policies. The current BGP-based inter-AS traffic engineering practices may be summarized as follows: - "Closest exit" routing where egress traffic from one SP to another follows the path defined by the lowest IGP or intra-AS MPLS TE tunnel metrics of the BGP next-HOP of exterior routes learned from other AS over the inter-AS links - "BGP path attribute" based routing selection mechanism where the egress traffic path is determined by interconnect (peering or transit) policies based upon one or a combination of BGP path attributes, like AS_PATH, MULTI_EXIT_DISC (MED), and Local_Pref. SPs have often faced a number of un-deterministic factors in their practices of inter-AS traffic engineering employing the methods mentioned above: - Sub-optimum traffic distribution across inter-AS links - Un-deterministic traffic condition changes due to uncoordinated IGP routing policies or topology changes within other AS and uncoordinated BGP routing policy changes (MED or as-prepend, etc) In addition, to achieve some degrees of granularity, SPs may choose to enforce BGP inter-AS policies that are specific to one or a set of inter-AS links for ingress traffic destined to certain PoPs or regions within SP's network from another AS by tagging certain sets of routes with a specific attribute when announcing to another AS. This of course goes under the assumption that the other AS permits automated egress policy by matching the predefined attribute from incoming routes. Zhang, Vasseur, et. al. [Page 23]