INTERNET DRAFT Raymond Zhang, Editor Internet Engineering Task Force Infonet Services Corporation Document: JP Vasseur, Co-Editor draft-zhang-mpls-interas-te-req-02.txt Cisco Systems, Inc February 2003 Expires: September 2003 MPLS Inter-AS Traffic Engineering requirements draft-zhang-mpls-interas-te-req-02.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. 1. Abstract This document discusses Service Providers requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). The main objectives of this document are to present a set of requirements and applicable deployment cases which would result in some general guidelines in the definition, selection and specification development for a technical solution meeting these requirements that will be covered in a separate draft. The document will first discuss issues in current BGP-based traffic engineering practices across multi-ASes, hence arrive at the requirement for extending the current MPLS TE mechanism beyond BGP AS boundaries. A set of application scenarios will also be presented as potential deployment cases of inter-AS MPLS TE. A list of detailed requirements along with the evaluation criteria for a technical solution is also provided. Discussions presented here will cover inter-AS TE in both IPv4 and VPNv4 addressing planes. Information regarding VPNv4 addressing plane over BGP/MPLS VPNs is detailed in [PPVPN-RFC2547bis]. 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 8, and is not repeated below.) 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 3. Problem Statements 3.1. Definitions The following provide a list of abbreviations or acronyms specifically pertaining to this document: SP: Service Provider. TE LSP: MPLS Traffic Engineering Label Switched Path Intra-AS MPLS TE: Existing MPLS Traffic Engineering mechanism that is widely used today by MPLS network operators for traffic engineering within a BGP AS boundary. Inter-AS MPLS TE: TE LSP whose Head-end LSR and Tail-end LSR do not reside within the same Autonomous System (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 Interconnect or ASBR Routers: Routers used to connect to another AS of a different or the same Service Provider via one or more Inter-AS links. GSP: Global Service Provider whose networks span beyond national and/or continental boundaries. RSP: Regional or National Service Provider. PCS: Path computation Server (an LSR or an off-line tool) PCC: Path Computation Client (an LSR) 3.2. Problem and Requirement Statements In today's Service Provider (SP) network, BGP is widely 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 facilities by appropriately establishing BGP-based inter-AS routing policies. The current BGP- based inter-AS traffic engineering practices may be summarized as below: - "Closest exit" routing where egress traffic from one SP to another follows 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 where the egress traffic path is determined by interconnect (peering or transit) policies based upon one or a combination of BGP path attributes, namely as-path, MED and Local Preference. 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 policy 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 elect to deploy 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. SPs today 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 elaborate inter-AS TE facilities. However, in situations where transmission resource optimization or strict QOS guaranties are required or specific routing requirements arise, the current BGP-based inter-AS traffic engineering will need to be complemented by a MPLS-based Inter-AS mechanism further illustrated in the following discussions. In the case where a SP network is established over multiple ASes, as the density of the network and/or inter-AS links increases, the difficulty in optimizing inter-AS TE paths vs. complexity of polices rises exponentially which may soon become unmanageable due to worsened conditions of sub-optimum traffic distribution. In another case where inter-AS links are built between different SP's administrative domains, un-deterministic factors such as un- coordinated routing and network changes and sub-optimum traffic conditions would potentially lead to a complex set of Inter-AS traffic engineering polices as mentioned above, in which case BGP- based facilities available today would certainly not scale well. This issue becomes much more pronounced when customer's intranet VPNs spans over multiple SPs. In the meantime, the customer still requires to maintain a set of performance targets for VPN traffic classified in one or even multiple Diffserv classes. In both cases, asymmetric paths further complicate TE policies for traffic optimization and protection/restoration across inter-AS link. In some cases such as multi-continental interconnects, it becomes extremely difficult to maintain performance integrity along traffic paths. Moreover, more and more services require a very high degree of reliability. By consequences, fast convergence upon link/SRLG/node failure becomes a strong requirement, clearly difficult to achieve with existing inter-domain techniques. In a word, just as in the applicable case of deploying MPLS TE in a SP's network, an inter-AS TE method different from BGP-based traffic engineering needs to be deployed across inter-AS links over where transmission resource optimization and QOS guaranties are required, especially in a Diffserv-based multi-class environment where statistical performance targets MUST be maintained consistently. Naturally, extending intra-AS MPLS TE capabilities across inter-AS links seems to be the most appropriate approach with the least amount of the development efforts and most amount of operations experiences. 4. Application Scenarios The following sections presents five application scenarios in which requirements cannot be addressed with existing intra-AS MPLS TE mechanisms and give rise to considerations for Inter-AS MPLS TE. Please note that terms of CE and PE used in the following diagrams are generic where it does not necessarily mean that CE is connected in a VRF (MPLS VPN) environment. 4.1. Scenario I - Extended or Virtual PoP A global service provider (GSP), for example would like to expand its reach in a region where a regional service provider's (RSP) network has already established an extended coverage in its PoP density. In this scenario, the GSP may elect to establish inter-AS interconnects in one or multiple points with the RSP in that region. It may then use RSP's network as an extended transport by co-locating distribution routers functioning as PEs in interested RSP's PoPs in sub-regions where GSP has larger number of customer sites. In order to ensure transparency to RSP's network changes in terms of capacity and performance, one or more Inter-AS MPLS TE trunk(s) can be built between GSP's interconnect router and the GSP's PE routers co-locating in RSP's PoPs, as illustrated in the diagram below. Assuming the propagation delay can be bounded, the reserved capacity will ensure the performance predictability by operating inter-AS TE trunks under certain engineering utilization thresholds. <===========Inter-AS MPLS TE Tunnel===========> ----- ----- ________|ASBR |___Inter-AS___|ASBR |________ | | RTR | Link | RTR | | ---- ----- ----- ----- ----- |GSP |_____| RSP | | GSP | |VPOP| |P RTR| |P/PE | ---- ----- ----- ----- ----- |________|ASBR |___Inter-AS___|ASBR |________| | RTR | Link | RTR | ----- ----- <=================Inter-AS MPLS TE Tunnel=================> +--GSP--+ +-------RSP AS-------+ +------GSP AS------+ In situations where end-to-end Diffserv paths MUST be maintained, both SP's networks will need to provision Diffserv PHB at each HoP supporting a set of traffic classes with comparable performance targets. The issues with the 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. Furthermore, these remote PE routers are referred to as Virtual PoPs as extensions to GSP's network and could then be incorporated in GSP's overall TE plane via inter-AS MPLS TEs. The RSP, on the other hand, can similarly choose to expand their reach beyond its servicing region over GSP's network via inter-AS MPLS TEs. It is worth mentioning that these remote PE 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 GSP AS such that TE tunnels may cross several AS and have same source & destination AS. 4.2. Scenario II - Extended or Virtual Trunk As shown in Scenario I, a (GSP), for example who would like to expand its reach in a region where there are one or small number of concentrated customer VPN site(s), may still elect first to build inter-AS interconnects with a RSP in one or multiple points. Instead of co-locating a PE router in RSP's PoP, inter-AS RSVP tunnels can be built and signaled through RSP's MPLS network between the RSP PoP to which GSP customer CEs are directly connected and GSP's interconnect router. 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 GSP CE's local-loop access circuits on RSP's MPLS network over which the bandwidth can be guaranteed as shown in the diagram below: <====Inter-AS MPLS TE Tunnel===> or < ===Inter-AS MPLS TE Tunnel=============> ---- ----- ----- ----- ----- | CE |___Local___| RSP |_____|ASBR |___Inter-AS___|ASBR |___|GSP | | | Loop | PE | | RTR | Link | RTR | |PE | ---- ----- ----- ----- ----- +--Customer--+ +-------RSP AS--------+ +--GSP AS---------+ Case 2 - the inter-AS RSVP tunnel in this case functions as an extended or virtual local access link from GSP's CE on RSP's network to the GSP's ASBR or PE: <==============Inter-AS MPLS TE Tunnel============> or <==============Inter-AS MPLS TE Tunnel=====================> ---- ----- ----- ----- ----- | CE |___Local___| RSP |_____|ASBR |___Inter-AS___|ASBR |___|GSP | | | Loop | PE | | RTR | Link | RTR | |PE | ---- ----- ----- ----- ----- +--Customer--+ +-------RSP AS--------+ +--GSP AS---------+ In case 2, above, RSP may elect to establish an aggregating or hierarchical intra-AS MPLS TE tunnel between the transiting P or PE router and RSP's ASBR router just to reduce the number of tunnel states signaled from the RSP PE to which GSP's CE is connected. Please note also in case 2 that the inter-AS MPLS TE tunnel would be terminated in GSP's ASBR router or PE router inside the network under a customer-specific VRF provisioned directly for all other extended VPN sites of the same customer or in the global space. For instance, a CE can be a voice over IP gateway connected to a PE (Provider Edge) which in this case is an LSR 4.3. Scenario III - End-to-end Inter-AS TE From CE to CE In this scenario as illustrated below, customers require to establish TE tunnel from CE1 to CE2 end to end across one or more SP's networks. One application example would be guaranteed bandwidth services for end-to-end voice- or video-over-IP connections classified as EF traffic from CE to CE, for which it may be necessary to ensure that the required bandwidth is reserved by means of Inter-AS RSVP tunnel signaled across one or multiple SP networks. <======================Inter-AS MPLS TE Tunnel====================> --- ----- ----- ----- ----- --- |CE1|_____| RSP |_____|ASBR |__Inter-AS__|ASBR |_____| GSP |_____|CE2| | | | PE | | RTR | Link | RTR | | PE | | | --- ----- ----- ----- ----- --- +-Cust-+ +-------RSP AS-------+ +-------GSP AS--------+ +-Cust-+ The diagram below illustrates another example where CE1 and CE2 are cutomers of GSP with eBGP provisioned across the CE-PE links. A multi-AS TE tunnel may then be established from CE1 in AS1 to CE2, also in same or different AS from CE1, across GSP's network in AS2: <===============Inter-AS MPLS TE Tunnel===================> --- ----- ---- ---- ----- --- |CE1|______| GSP |_____|GSP |____|GSP |____| GSP |_________|CE2| | | | PE1 | |P1 | |P2 | | PE2 | | | --- ----- ---- ---- ----- --- +-Cust AS1-+ +-------------GSP AS2----------------+ +-Cust ASx-+ In the above example, the GSP's network may have only a single AS. And also in the case of both CE1 and CE2 residing in the same AS, they likely share the same private AS number. 4.4. Scenario IV - TE across multi-AS within SP's Administrative Domain As mentioned in [TE-APP], SPs have generally found that the existing 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, the objectives of traffic engineering are after all to be able to deliver more customer traffic with already available capacity in the network without violating performance targets. For SPs with multi-AS routing architecture in their networks, the existing intra-AS MPLS TE facility will only allow them to deploy regional TE policies within the IGP routing plane, usually confined along a BGP AS boundary, whereas traffic distribution across the inter-AS links is still subject to factors mentioned in section 3.2 above. It is worth noting that situations such as low density in inter-AS connectivity and plenty of inter-AS capacity may not require more scalable and granular TE facilities beyond BGP-based inter-AS polices since Inter-AS policies could be rather simple and inter- AS transmission resource optimization is not an absolute requirement However many SPs, especially those with networks across multiple continents, have engineered their multi-AS routing architecture along the continental boundaries where inter-continent capacity is expensive. This would demand a more scalable degree of transmission resource optimization, which warrants consideration of extending intra-AS MPLS TE capabilities across inter-AS links. In addition, one can only yield high efficiency in conducting traffic optimization and path protection/restoration planning when coordinating all network resources (not partially) as a whole. This requires a seamless TE plane across the entire network which may possibly have many inter-AS segments. The requirement 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 digram below with an inter-AS PE-PE DS-TE tunnel: <===================Inter-AS MPLS DS-TE Tunnel===================> ---- ----- ----- ----- ----- ---- | PE |______| P |_____|ASBR |___Inter-AS___|ASBR |___|P |___|PE | | RTR| | RTR | | RTR | Link | RTR | |RTR | |RTR | ---- ----- ----- ----- ----- ---- +------------GSP AS1---------+ +------------GSP AS2------+ For example , inter-AS DS-TE LSP shown in the digram above could be used to tranport a set of L2 Pseudo Wires with corresponding QoS requirement. Finally, fast recovery of traffic crossing multiple ASes are particularly important in case of link/SRLG/node failure at AS boundaries. In fact, this applies to all the scenarios, not only scenario 4. 4.5. 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, hence forming one "unified" TE plane. The inter- AS MPLS TE LSP in this case may also be used to backup an internal path, although this could introduce routing complexities which may or may not be desirable. 5. Detailed Requirements for Inter-AS MPLS TE 5.1. Inter-AS MPLS TE Operations and Interoperability The inter-AS MPLS TE solution MUST be consistent with requirements discussed in [TE-REQ] and the derived solution SHOULD be such that it will interoperate seamlessly with existing MPLS TE and inherit its capability sets documented in [TE-RSVP]. The developed solution SHOULD allow to provision at the Head/Tail end áá with end-to-end RSVP signaling (eventually with loose paths) traversing áá transparently across the interconnected Autonomous Systems Border Routers (ASBR). Inter-AS MPLS TE MUST ensure similar applications over restoration polices used by existing MPLS TE and presented in [TE-SURVIV]. 5.2. Inter-AS MPLS TE Management In a MPLS network, operators want to have ways to detect both control plane and data plane failures. But tools to check LSPs haven't been established yet. They manually troubleshoot hop by hop across the data path as usual. If they detect an error on the data plane, they have to check the control plane in order to determine where the faults are. Both [LSPPING] and [TUNTRACE] discussed about a data plane. They need the mechanism that detection of a data plane failure to be verified against the control plane. In other words, they automatically want to troubleshoot across the data path and to detect a portion of error. The facilties documented in Both [LSPPING] and [TUNTRACE] SHOULD be extended across inter-AS links. Operators check a TTL along a LSP between head-end and tail-end. From a SP perspective, we see the real hop between them. But, from a customer perspective, they may see 1 hop between customer edge routers. The TTL processing documented in [MPLS-TTL] SHOULD also be extended across the ASBRs as well as over inter-AS links. This way, inter-AS MPLS TE management is just as necessary as in intra-AS MPLS TE management. In some cases, we may have to expand the method proposed at present. It is worth noting that in any of the above implementations, Inter-AS TE tunnel ending addresses need to be known or routeable across IGP areas (OSPF) or levels(IS-IS) within the transiting ASes with working return paths such that diagnostic test packets (ping or traceroute) can return via an alternate data plane, such as a global IPv4 path in the event that the LSP is broken. 5.3. DS-TE Support The developed inter-AS MPLS TE solution SHOULD also satisfy core requirements documented in [DS-TE] and interoperate seamlessly with DS-TE mechanisms. 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 solution. 5.4 Optimality The solution SHOULD allow the set up of an inter-AS TE LSP obeying a set of constraints (as defined in [TE-LSP]) and following an optimal path. An optimal path is defined as a path whose end-to-end cost is minimal, using either the IGP or the 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. 5.5 Support of diversely routed inter-AS TE LSP In some cases it might be desirable to set up multiple TE LSPs between a pair of LSRs: (1) since a single TE LSP satisfying the required set of constraints cannot be found, (2) to limit the impact of a network element failure to a proportion of the traffic. As an example, two VoIP gateways may load balance the traffic among a set of TE LSPs. (3) Path protection (e.g. 1:1 or 1:N) as discussed in [RFC3469]. In the set of examples above, being able to set up diversely routed TE LSPs is a requirement. The solution SHOULD be able to set up a set of link/SRLG/Node diversely routed inter-AS TE LSPs. 5.6. Fast Recovery support using MPLS TE Fast Reroute There are in general two or more inter-AS links between ASes for redundancy reasons. 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 consistent with specifications documented in [TE-FRR]. Moreover, the traffic routed onto an inter-AS TE tunnel MUST also be fast protected against any node failure, should the node be internal to an AS or at the AS boundary. 5.7. Protocol Signaling and Path Computations One can conceive that a MPLS TE tunnel path signaled across inter- AS links consists of a sequence of {intra-AS segment in AS x, inter-AS segment across inter-AS links, intra-AS segment in AS y}. Configurable knobs SHOULD be embedded in the solution enabling the selection of ASBR routers manually or via auto-discovery, the latter of which may need additional IGP extensions beyond what have been documented in [ISIS-TE] and [OSPF-TE]. The solution SHOULD provide the ability to set up a TE LSP crossing multiple ASes with: - a manual specification of all or some of the hops (loose routing) the TE LSP MUST traverse, allowing to keep confidential internal resources and still leaving intra-AS optimization responsibility to local operators. - an automatic 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 (Path Computation Server) 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) as defined in [PATH-COMP] for example. It is worth noting that by employing BGP based label distribution across inter-AS links discussed in [BGP-Label], one would imply the willingness to propagate loopback IP addresses to other ASes, which may or may not be a desirable thing to do in some situations. 5.8. Inter-AS MPLS TE LSP Aggregations for hierarchical LSP support Application Scenario I, II and III presented in section 3 above allow the possibility of multiple TE tunnels to be built over another SP network via the same set of ASBR routers. It would potentially present scalability issues as the number of required TE tunnels grows. In order to reduce the number of tunnel states to be maintained by each transiting PoP, the developed solution SHOULD allow TE LSP aggregation such that individual tunnels can be merged onto one aggregating LSP [MPLS-LSPHIE]. 5.9. Mapping of traffic onto Multiple Inter-AS MPLS TE Tunnels Application Scenario II presented in section 4.2 above requires multiple TE tunnels, one from each CE router to be terminated at the interconnect ASBR router and provisioned under one VRF for each customer's VPN. The developed solution SHOULD update the VRF table and allow traffic destined to these remote CE routers to be correctly mapped to the respective TE tunnels. There may be several possibilities to map a particular traffic to a specific inter-AS TE LSP: - static routing (known IP destination addresses) - static routing using recursive BGP route resolution 5.10 Reoptimization After an inter-AS TE LSP is established, should there be any resource or other changes inside anyone of transiting ASes, the solution must to be able to reoptimize that segment of the LSP non-disruptively, either upon expiration of a configurable timer or triggered by a network event or a mannual request at the TE tunnel HE. The solution SHOULD also support the ability for intermediate nodes to signal the respective Head-End LSRs of the existence of a more optimal path. 5.11 Confidentiality As an inter-AS TE LSP may span multiple AS belonging to different SPs, the solution might allow to "hide" the set of hops followed by the TE LSP within an AS. Example: [ ASBR1-----ASBR2 ] [ A ] [ B ] [ ] [ ] [ AS1 ] [ AS2 ] [ ]-----[ ] [ ] [ ] Suppose there is an inter-AS TE LSP from A (within AS1) to B (within AS2). 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 obeying the set of constraints traverses ASBR2 without a detailed knowledge of the lists of hops followed within AS2. Optionally, the TE LSP path cost within AS2 could be provided to A, via for example PCC-PCS signalling [PATH-COMP], such that A (PCC) could use this information to compute an optimal path,even if the computed path is not provided by the AS2. 5.12 Policy Control In some cases, in particular when the two ASes belong to different SPs, some policy control might be necessary at the AS boundaries, namely ingress policy controls allowing SP to enforce or honor Inter-AS MPLS TE requests per interconnect agreements. The following presents some examples of policies that could be enforced at the AS boundaries: - Whether FRR requests SHOULD be obeyed, - Remarking of DS-TE bits, TE metrics etc. - Remarking of RSVP session attributes such as affinities and preemption priorities - Bandwidth control to ensure LSPs don't ask for BW over their allocation. In some cases, an optional policy server could also be used in managing inter-AS TE policies. This requirement could allow SP to scale inter-AS TE policy better in Scenarios presented in section 4. 6. Evaluation Criteria There may be multiple solutions to satisfy requirements for Inter- AS MPLS TE presented in previous sections. This section provides general guidelines, which could be applied in the section of an optimum solution. 6.1. Detailed Requirement Satisfactions The developed solution SHOULD include all 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 developed solution MUST have minimum impact to the network scalability across inter-AS links but also and more importantly within AS. This requirement both applies to: - the IGP (impact in term of IGP flooding frequency, Link State Database size, SPF, ...) - BGP: (impact in terms of additional information carried within BGP) - RSVP TE (impact in terms of refresh reduction support) In addition, the solution MUST also allow new feature extensions in the future as both inter-AS MPLS TE and existing MPLS TE evolves forward. 6.3 Performances 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. 6.4. 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. 7. Security Considerations The developed solution 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 existing TE, greater considerations MUST be given in terms of how to establish a trust model across AS boundaries. SPs MUST have ways in its implementation to authenticate, allow and deny inter- AS signaling requests and protect from DoS attacks. 8. Acknowledgement We would like to thank Yuichi Ikejiri and David Allan for their suggestions and helpful comments during our further 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 Apollo Drive Chelmsford, MA 01824 USA Email: jpv@cisco.com 10. References [PPVPN-RFC2547bis] Rosen, et al, "BGP/MPLSVPN", draf-ietf-ppvpn- rfc3547bis-02.txt", July 2002 [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 [TE-APP] Boyle, et al, "Applicability Statement of Traffic Engineering", RFC 3346, August 2002. [TE-SURVIV] Lai, et al, "Network Hierachy and Multilayer Suvivability", Oct. 2001. (Work in Progress) [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) [TUNTRACE] Bonica, R., Kompella, K., Meyer, D., "Tracing Requirements for Generic Tunnels", Internet Draft , June 2002. (Work in Progress) [MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS Networks (Updates RFC 3032) ", draft-ietf-mpls-ttl-03.txt, June 2002. (Work in Progress) [DS-TE] Le Faucheur et al, ''Requirements for support of Diff- Serv-aware MPLS Traffic Engineering'', draft-ietf-tewg-diff-te- reqts-01.txt, June 2001. (Work in Progress) [TE-FRR] Pan, P. 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, (Work in Progress) [MPLS-LSPHIE] Kompella, Rekhter, "LSP Hierachy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt , March 2002. (work in progress) [RFC3469] Sharma V., et al, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", 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. Full Copyright Statement Copyright (C) The Internet Society (2000). 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.