draft-vasseur-inter-as-te-00.txt February 2003 Jean-Philippe Vasseur (Editor) Cisco Systems, Inc. Raymond Zhang Infonet Services Corporation IETF Internet Draft Expires: August, 2003 February, 2003 draft-vasseur-inter-as-te-00.txt Inter-AS MPLS Traffic Engineering Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are Working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Vasseur and Zhang 1 draft-vasseur-inter-AS-TE-00.txt February 2003 Abstract This draft proposes a set of mechanisms to establish and maintain MPLS Traffic Engineering Label Switched Path that span multiple Autonomous Systems, considering the set of requirements for inter-AS Traffic Engineering listed in [Inter-AS-TE-REQS]. Each mechanism is described along with its applicability to the set of requirements. Vasseur and Zhang 2 draft-vasseur-inter-AS-TE-00.txt February 2003 Content 1. Terminology --------------------------------------------- 4 2. Introduction -------------------------------------------- 5 3. General assumptions-------------------------------------- 5 4. Flooding of inter-AS non TE enabled links -------------- 7 5. Scenario 1: Per-AS Traffic Engineering Path computation - 8 5.1 Static loose hops configuration ------------------------ 9 5.2 Dynamic loose hops computation ------------------------- 9 5.3 Inter-AS TE LSP path set up ---------------------------- 10 5.4 Support of diversely routed paths ---------------------- 11 5.5 Optimality --------------------------------------------- 12 6. Scenario 2: Path Computation Server --------------------- 12 6.1 Path Computation Server discovery ---------------------- 13 6.2 PCC-PCS Signaling protocol ----------------------------- 14 6.3 Inter-AS TE LSP Path set up ---------------------------- 15 6.4 Support of diversely routed paths ---------------------- 18 6.5 Optimality --------------------------------------------- 18 7. Routing traffic onto inter-AS TE LSP -------------------- 18 8. Applicability of MPLS TE Fast Reroute to Inter-AS TE LSP 18 8.1 Within an Autonomous System (link or node failure) ----- 19 8.2 At AS boundary ----------------------------------------- 19 8.2.1 Failure of an ASBR-ASBR link ------------------------- 19 8.2.2 Failure of an ASBR LSR node -------------------------- 20 8.3 Procedures of PLR during Fast Reroute ------------------ 20 9. Failure handling of inter-AS TE LSP --------------------- 22 10. Reoptimization of Inter-AS TE LSP ---------------------- 23 11. Inter-AS MPLS TE Management ---------------------------- 24 12. Scalability and extensibility -------------------------- 25 13. Confidentiality ---------------------------------------- 25 14. Security considerations -------------------------------- 25 15. Policy Control at the AS boundaries -------------------- 26 16. Intellectual Property Considerations ------------------- 26 17. Acknoledgments ----------------------------------------- 26 References ------------------------------------------------- 26 Vasseur and Zhang 3 draft-vasseur-inter-AS-TE-00.txt February 2003 1. Terminology LSR - Label Switch Router LSP - An MPLS Label Switched Path PCS - Path Computation Server (may be any kind of LSR (ABR, ...) or a centralized path computation server PCC - Path Computation Client (any head-end LSR) requesting a path computation of the Path Computation Server. Local Repair - Techniques used to repair LSP tunnels quickly when a node or link along the LSPs path fails. Protected LSP - An LSP is said to be protected at a given hop if it has one or multiple associated backup tunnels originating at that hop. Bypass Tunnel - An LSP that is used to protect a set of LSPs passing over a common facility. PLR - Point of Local Repair. The head-end of a bypass tunnel. MP - Merge Point. The LSR where bypass tunnels meet the protected LSP. NHOP Bypass Tunnel - Next-Hop Bypass Tunnel. A backup tunnel which bypasses a single link of the protected LSP. NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel. A backup tunnel which bypasses a single node of the protected LSP. Reroutable LSP - Any LSP for with the "Local protection desired" bit is set in the Flag field of the SESSION_ATTRIBUTE object of its Path messages. CSPF - Constraint-based Shortest Path First. 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 tunnel transiting path may be across different ASes. Note that this definition also applies to TE LSP whose Head-end and Tail-end LSRs reside in different sub-ASes (BGP confederations). 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. 2. Introduction Vasseur and Zhang 4 draft-vasseur-inter-AS-TE-00.txt February 2003 Considering the set of requirements for inter-AS Traffic Engineering listed in [INTER-AS-TE-REQS], this draft proposes a set of mechanisms to establish and maintain MPLS Traffic Engineering Label Switched Path that span: (1) multiple Autonomous Systems, or (2) sub-ASes in the context of BGP confederation. In this later case, the draft applies to the case of multiple sub-ASes having their own routing domain. Two scenarios are proposed in this draft that differ in term of complexity and optimality. For each scenario, the set of mechanisms is described along with its applicability to the inter-AS TE requirements. Definition of an optimal Path Qualifying a path as optimal requires clarification. Indeed, a globally optimal TE LSP placement usual refers to a set of TE LSP whose placements optimize the network resources (i.e a placement that reduces the maximum or average network load for instance). By contrast, a optimal path for a TE LSP, is the shortest path that obeys the set of required constraints (bandwidth, affinities,...), minimizing either the IGP or TE metric cost (See [SECOND-METRIC] and [MULTIPLE-METRICS]). In this draft, an optimal inter-AS TE path is defined as the optimal path that would be obtained in the absence of AS/Areas, in a totally flat network between the source and destination of the TE LSP. Note that, the path calculated for a TE LSP in a distributed environment, depends on the TE LSP set up order, as in a single area environment. 3. General assumptions In the rest of this draft, we will consider the following general case, built on a superset of the various scenarios defined in [INTER-AS-TE- REQS]: <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> <---BGP---> <---BGP--> CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 |\ \ | / | / | / | | | | \ ASBR2---/ ASBR5 | -- | | | | \ | | |/ | | | R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10----R7---CE2 <======= Inter-AS TE LSP(LSR to LSR)===========> or <======== Inter-AS TE LSP (CE to ASBR => Vasseur and Zhang 5 draft-vasseur-inter-AS-TE-00.txt February 2003 or <================= Inter-AS TE LSP (CE to CE)===============> The diagram depicted above allows covering all the inter-AS TE deployment cases described in [INTER-AS-TE-REQS]. Assumptions: - Three interconnected ASes, respectively AS1, AS2, and AS3. Note that AS3 might be AS1 in some scenarios described in [INTER-AS-TE-REQS], - The various ASBRs are BGP peers, without any IGP running on the single hop link interconnecting the ASBRs, - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE extensions (see [OSPF-TE] and [IS-IS-TE]). In other words, the ASes are TE enabled, - Each AS can be made of several areas. In this case, the TE LSP will rely on the inter-area TE techniques to compute and set up a TE LSP traversing multiple IGP areas (as described in [MULTI-AREA-TE]. Each routing domain will be considered as single area in this draft, - An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 in AS3, - An inter-AS TE LSP T2 originated at CE1 (connected to R0) and terminating at CE2 (connected to R7), - A set of backup tunnels: o B1 from X1 to ASBR4 following the X1-ASBR2-ASBR4 path and protecting against a failure of the ASBR1 node, o B2 from ASBR1 to ASBR4 following the ASBR1-ASBR2-ASBR4 path and protecting against a failure of the ASBR1-ASBR4 link, o B3 from ASBR1 to R3 following the ASBR1-ASBR2-ASBR3-ASBR6- ASBR5-R3 path and protecting against a failure of the ASBR4 node. - ASBR1, ASBR8 and ASBR9 have the function of PCS for respectively the ASes 1, 2 and 3. 4. Flooding of inter-AS non TE enabled links As mentioned earlier, the links interconnecting ASBRs are usually not TE enabled and no IGP is running at the AS boundaries. This implies: Vasseur and Zhang 6 draft-vasseur-inter-AS-TE-00.txt February 2003 (1) that the links interconnecting the ASBRs are not TE enabled, (2) no IGP with TE extensions is running in this region. An implementation supporting inter-AS TE MUST obviously allow the set up of inter-AS TE LSP over the region interconnecting multiple ASBRs. In other words, an ASBR compliant with this draft MUST support the set up of TE LSP over ASBR to ASBR link, performing all the usual operations related to MPLS Traffic Engineering (Call Admission Control, ...) as defined in [RSVP-TE]. So the limitation (1) must be removed. Regarding the second limitation (2), two SPs usually not run an IGP between ASBRs. Although this imposes for the two ASBR to be interconnected via single hop link, this does not constitute a severe limitation. That being said, the ASBRs MUST flood the TE information related to the ASBR-ASBR link(s) although no IGP TE is enabled over those links (and so there is no IGP adjacencies over the ASBR to ASBR links). This allows a HE LSR to make a more appropriate route selection up to the first ASBR in the next hop AS in the case of scenario 1 described bellow and will significantly reduce the number of signaling steps in route computation described in scenario 2. Note that the TE information is only related to the ASBR-ASBR link. In other words, the TE LSA/LSP flooded by the ASBR include not only the links contained in the AS but also the ASBR-ASBR links. No summarized TE information is leaked between ASes in any of the proposed scenarios in this draft. Example: <---BGP---> <---BGP--> CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9---R6 |\ \ | / | / | / | | | | \ ASBR2---/ ASBR5 | -- | | | | \ | | |/ | | | R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2 For example, in the diagram depicted above, ASBR1 floods an IGP TE LSA/LSP reflecting the reservation states and TE properties of the following links: X1-ASBR1, ASBR1-ASBR4, ASBR1-ASBR2. 5. Scenario 1: Per-AS Traffic Engineering Path computation In scenario 1, two modes are supported: (1) Static loose hops configuration Vasseur and Zhang 7 draft-vasseur-inter-AS-TE-00.txt February 2003 Every inter-AS TE LSP path is defined as a set of loose and strict hops but at least the ASBRs traversed by the inter-AS TE LSP must be specified as loose hops on the Head-End LSR. Examples of configuration of T1 on R0: - Example 1 (set of strict hops end to end): R0-X1-ASBR1-ASBR4-ASBR5- R3-ASBR7-ASBR9-R6 - Example 2 (set of loose hops): R0-ASBR4(loose)-ASBR9(loose)-R6(loose) - Example 3: (set of loose hops): R0-ASBR1(loose)-ASBR4(loose)- ASBR7(loose)-ASBR9(loose)-R6(loose) - Example 4 (mix of strict and loose hops): R0-R2-ASBR3-ASBR2-ASBR1- ASBR4(loose)-ASBR10(loose)-ASBR9-R6 - Example 5 (mix of strict and loose hops): R0-ASBR2(loose)- ASBR4(loose)-ASBR7(loose)-ASBR9(loose)-R6 When a next hop is defined as a loose hop, a dynamic path calculation (also called ERO expand) is required taking into account the topology and TE information of its own AS and the set of TE LSP constraints. In the example 1 above, the inter-AS TE LSP path is statically configured as a set of strict hops, so in this case, no dynamic computation is required. In the example 2, a per-AS path computation is performed, respectively on the R0 for AS1, ASBR4 for AS2 and ASBR8 for AS3. Note that when an LSR has to perform an ERO expansion, the next hop must either belong to the same AS, or must be the ASBR directly connected to the next hops AS. In this later case, the ASBR reachability must be announced in the IGP TE LSA/LSP originated by its neighboring ASBR. In the example 2 above, the TE LSP path is defined as: R0-ASBR4(loose)-ASBR9(loose)-R6(loose). This implies that the ERO expansion performed by R0 must compute the path from R0 to ASBR4. As stated in section 4, the TE reservation state related to the ASBR1-ASBR4 link is flooded in ASBR1Æs IGP TE LSA/LSP. In addition, ASBR 1 MUST also announce the IP address of ASBR4 used specified in the T1 path configuration. If not possible/desired, then the set of loose hops must include every traversed ASBRs as in the example 1 above. (2) Dynamic mode Every LSR receiving an RSVP Path message with an ERO object such that the next hop is loose, will have to determine automatically the next hop ASBR, based on the IGP/BGP reachability of the TE LSP destination. Example of configuration of T1 on R0 in dynamic mode: T1 Path: R0-R6(loose) 5.1. Static loose hops configuration At least, the set of ASBRs from the TE LSP Head-end to the Tail-End must be specified as a set of loose hops. Optionally, a set of paths can be configured on the HE LSR, ordered by priority. Example: the T1 path can be defined as an ordered set of paths specified as loose hops: Vasseur and Zhang 8 draft-vasseur-inter-AS-TE-00.txt February 2003 Priority 1: R0-ASBR1(loose)-ASBR4(loose)-ASBR9(loose)-R6(loose) Priority 2: R0-ASBR2(loose)-ASBR7(loose)-ASBR9(loose)-R6(loose) Priority 3: R0-ASBR3(loose)-ASBR6(loose)-ASBR7(loose)-R6 (loose) Priority 4: R0-ASBR3(loose)-ASBR6(loose)-ASBR8(loose)-ASBR10(loose)-R6 (loose) Each priority path can be associated with a different set of constraint. Typically, it might be desirable to systematically have a last resort option with no constraint to ensure the inter-AS TE could always be set up if at least a path exist between the inter-AS TE LSP source and destination. Note that in case of set up failure or when an RSVP Path Error is received indicating the TE LSP has suffered a failure, an implementation might support the possibility to retry a particular path option a specific amount of time (optionally with dynamic intervals between each trial) before trying a lower priority path option. Although this mode requires some manual configuration, it allows exerting control over which ASBRs are traversed, with an order of priority. Moreover, the required extra configuration can be acceptable in environment where both the number of ASBRs and traversed ASes is not too large. In the case of three ASes AS1, AS2 and AS3 having respectively X1, X2 and X3 ASBRs the maximum number of path-options can be as large as X1*X2*X3 combinations. 5.2. Dynamic loose hops computation With this scheme, the HE LSR and every downstream loose hop (except the last loose hop that computes the path to the final destination) automatically determines the next loose hop based on the IGP/BGP reachability of the TE LSP destination. If a particular destination is reachable via multiple loose hops (ASBRs), local heuristics may be implemented by the HE LSRs to select an ASBR among a list of possible choices (closest exit point, metric advertised for the IP destination (ex: OSPF LSA External - Type 2), local policy, ...). Once the next loose hops has been determined, an ERO expansion is performed as in the previous case. (1) IGP reachability In the case of IGP, this implies for every ASBR to redistribute in their IGP the loopback address of every potential TE LSP destination LSR. Note that this may introduce some undesirable effect on the IGP both in term of IGP scalability as the number of redistributed loopback addresses might not be negligible and stability (any change of a loopback reachability in AS x will trigger an IGP LSA flooding and SPF computation in AS y). Note that the ASBR configuration should make sure that loopback reachability information are redistributed in IGP by every ASBR for redundancy purposes. Vasseur and Zhang 9 draft-vasseur-inter-AS-TE-00.txt February 2003 (2) BGP reachability In the case of BGP, this implies for every ASBR to announce to their BGP peers the loopback address of every potential TE LSP destination LSR. Some filtering may be applied at each ASBR. 5.3. Inter-AS TE LSP path set up Once the next loose hop has been determined (via static configuration or dynamic computation), the HE LSR initiates the TE LSP path set up according to the procedures defined in [RSVP-TE]. Loose hops are specified in the ERO object of the Path message with the L flag of the Ipv4 prefix sub-object set, as per [RSVP-TE]. Then each loose hops along the path reiterates the same operation as described above until the TE LSP set up is completed. In case of failure of an LSR to find a path up to the next loose hop obeying the set of required constraint: - with the static exit point configuration, an RSVP Path Error is sent to the HE LSR, - with the dynamic exit point computation, the node might either decide to try to find another loose hop to reach the next hop AS or to send an RSVP Path Error up to the HE LSR. This is a matter of local policy. Example (with static loose hops configuration): Assumption: an inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 in AS3 must be set up. - Step 1: discovery (via configuration) of the next loose hop to reach the destination AS by the HE LSR. - Step 2: the HE LSR computes the TE LSP path up to the first loose hop and builds the ERO as a set of strict hops up (to the next loose hop) followed by a list of loose hops. Ex: ERO generated at the HE LSR (R0): R0(strict)-X1(strict)- ASBR1(strict)-ASBR4(strict)-ASBR8(loose hop)-ASBR9(loose hop)-R6 - Step 3: the inter-AS TE LSP is signaled along the computed path up to the next loose hop that performs a similar operation up to the next loose hop ... until the TE LSP destination node is reached. Ex: in the example above, the next loose hop is ASBR8. ASBR4 computes the TE LSP path up to ASBR8 (ERO= ASBR4-R3-R4-ASBR6-ASBR8) and signals the TE LSP. Then, ASBR8 computes the TE LSP Path up to ASBR9 and expands the ERO which becomes: ASBR10-ASBR9. ASBR9 computes the last segment of the inter-AS TE LSP path: ASBR9-R6. Vasseur and Zhang 10 draft-vasseur-inter-AS-TE-00.txt February 2003 Notes: In case of TE LSP set up failure: - With the static loose hop configuration: an RSVP Path Error messages in sent to the HE LSR that will in turn select another sequence of loose hops, if configured. Alternatively, the HE LSR may decide to retry the same path; this can be useful in case of set up failure due an outdated IGP TE database in some downstream AS. An alternative could also be for the HE LSR to retry to same sequence of loose hops after having relaxed some constraint(s). - With the dynamic loose hop computation, there are two possible modes: an RSVP Path Error message is sent to the HE LSR (as in the previous case) or the previous loose node tries another to find another loose next hop. Example: ASBR4 selects ASBR5 as its next loose hop and receives an RSVP Path Error from R3 (not enough bandwidth on the R3-ASBR5 link - IGP TE database not up to date). In this case, instead of relaying the RSVP Path Error up to the HE LSR RO, ASBR can try to find an alternative loose next hop: ASBR6. This mode is usually referred as "crankback". Note that depending on the network topology crankback may or may not result in more optimal solutions than Head-end rerouting. 5.4. Support of diversely routed paths There are several circumstances where the ability to set up a set of diversely routed TE LSP paths between two LSRs might be desirable: (1) Load balancing When a single TE LSP path satisfying the required constraints cannot be found between two LSRs, an alternative may consist in setting up N TE LSP such that the sum of their bandwidth is equal to the total required bandwidth. In addition, having diverse paths allows limiting the traffic disruption between the two nodes to the set of affected TE LSPs. (2) Path Protection In some networks, Path protection is used to protect TE LSP from link/SRLG/node failure. This requires setting up, for each TE LSP, a diversely routed TE LSP. In case of failure along the primary TE LSP path, the node directly attached to the failed resources signals to the HE LSR that the TE LSP has failed, sending an RSVP Path Error. The HE LSR also detects the TE LSP has suffered a failure when receiving an IGP update reflecting the failed resource. Note that the HE LSR cannot rely on the IGP topology database to detect the failure if the failure does not occur in the Head-End area/AS. Once the HE LSR learns the failure, the traffic is switched onto the pre-established backup TE Vasseur and Zhang 11 draft-vasseur-inter-AS-TE-00.txt February 2003 LSP. Note that a set of TE LSP can potentially share a single backup TE LSP (1:N protection). In the case of scenario 1, the set up of N diversely routed TE LSP paths can be done using the following scenario: - set up the first TE LSP among the set of N TE LSPs and include an RSVP RRO object in the RSVP Resv message to record the Path, - For I=2 to N Set up the TE LSPi, excluding the element traversed by the already set up TE LSP1, ..., TE LSP i-1. The exclusion of a set of resources from a TE LSP path can be performed on the HE LSR by the CSPF and in other ASes by the loose hops along the path, each of them performing the computation of a part of the TE LSP. This requires from the HE to pass the "exclude" constraint; the HE can include in its RSVP Path message the EXCLUDE-ELEMENT object defined in [PATH-COMP]. Important note: such an algorithm does not guarantee that a diverse path can be found for the successive TE LSPs since the TE LSP path are not simultaneously computed, even if such a possible solution exists. 5.5. Optimality In this scenario, the resulting TE LSP path is the first path obeying the required set of constraints. As such, the path might not be the shortest path. 6. Scenario 2: Path Computation Server In this scenario, the inter-AS TE LSP path computation is off-loaded on a PCS. Note that a PCS may be an LSR (like an ASBR) or a centralized path computation tool (in this case the PCS must get the IGP topology and resources information by some means, outside of the scope of this draft). Note that the PCS may or not be along the TE LSP Path. This implies that the PCS is just responsible for the TE LSP path computation only, not for its maintenance. Moreover, the PCS may compute just a path segment, not the whole path end to end; in this case, the returned computed path will contain loose hops. 6.1. Path Computation Server discovery Any HE LSR requiring an inter-AS TE path computation first needs to learn the PCS address in order to send an RSVP path computation request. This can be done via static configuration or dynamic PCS discovery. Vasseur and Zhang 12 draft-vasseur-inter-AS-TE-00.txt February 2003 (1) Static configuration A set of PCS(es) addresses is statically configured on every HE LSR having potentially some inter-AS TE LSP to set up. A dedicated PCS per AS can be configured or a default PCS serving the requests for all the destination ASes. Optionally, more than one PCS address can be configured in case of PCS failure of a PCS. In this case, the HE LSR must implement an algorithm to select a backup PCS in case of non-response of the preferred PCS after a certain amount of time. (2) Dynamic PCS discovery Dynamic PCS discovery can be performed via IGP advertisement. [IGP-CAP] defines IGP extensions for IP/LSR to advertise optional router capabilities. A Router capability TLV is defined for IS-IS while an router information opaque LSA is defined for OSPF. [OSPF-TE-CAP] defines a set of Traffic Engineering TLVs carried in the router capability LSA. Two TE TLVs are currently defined: - the Path Computation Server Discovery (PCSD) TLV that allows a router or a centralized path computation tool to advertise its PCS capabilities within a routing domain, - the Mesh-group TLV used by an LSR to indicate its desire to participate to a mesh of TE LSPs. In particular, the PCSD TLV allows PCS to advertise the following capabilities: - IPv4 to IPV6 address to be used by any PCC to send RSVP path computation request to the PCS, - Path Computation server capabilities (ability to manage Path computation request priorities, support of diverse routes computation, support of network element exclusion in the path computation, multiple metric path computation, ...) - Set of ASes for which the PCS can compute inter-AS TE paths for. Note that if the AS is made of multiple areas/levels, [IGP-CAP] supports the capabilities announcements across the entire routing domain (making use of TLV leaking procedure for IS-IS and OSPF opaque LSA type 11 for OSPF). 6.2. PCC-PCS Signaling protocol Any PCC (i.e LSR) can send an RSVP path computation request to a PCS that will in turn compute a set of TE LSP(s) path and return the corresponding path parameters via an RSVP path computation reply message. The format of the RSVP path computation requests and reply messages are defined in [PATH-COMP] as well as the set of optional objects characterizing the constraints: Vasseur and Zhang 13 draft-vasseur-inter-AS-TE-00.txt February 2003 REQUEST-ID object: must be present in any RSVP Path computation request and reply message and specifies: - The request-ID-number, - Several requests characteristics. Whether: o the Path cost is requested by the PCC, o the Path must be complete (set of strict hops) or can be partial, o the request concerns a reoptimization. In this case, the current path of the TE LSP to be reoptimized is provided in the path computation request to avoid double bandwidth booking, o the TE LSP is a bi-directional TE LSP, o if a path fully satisfying the required constraint cannot be found, the PCC has the possibility to indicate that a less-constrained TE LSP path is of interest, O the PCC can also indicate the urgency of the request (two priorities are currently defined: normal and high). METRIC-TYPE object: allows the PCC to indicate to the PCS the metric to be used to compute the shortest path (currently two metrics are defined: the IGP or TE metric). PATH-COST object: object inserted in the RSVP path computation reply message to indicate the cost of a computed TE LSP in addition to the path. This object is mandatory if the cost has been explicitly requested in the RSVP path computation request and optional in any other case. NO-PATH-AVAILABLE object: when no path satisfying the set of required constraints for a TE LSP can be found, some PCS might have the capability to specify the constraint responsible of the path computation failure. Optionally, a less-constrained path can be provided by the PCS (if an interest in less-constrained TE LSP has been requested in the RSVP path computation request). A PCS might also suggest new constraints for which a path could be found. NB-PATH, PATH-CORRELATED, MIN-BW and LSP-BANDWIDTH objects: a PCC may desire to request the computation of more than one TE LSP. This object allows the PCC to request the computation of a set of TE LSPs such that the sum of their bandwidth is equal to X, with potentially a constraint on the number and minimum bandwidth size of each of the TE LSPs in the set. The N TE LSP may or not share the same set of constraints and can be correlated (diversely routed). EXCLUDE-ELEMENT object: allows the PCC to request a TE LSP path such that the path does not include a set of network elements (link, node or AS). The protocol state machine is also defined in [PATH-COMP]. Vasseur and Zhang 14 draft-vasseur-inter-AS-TE-00.txt February 2003 6.3. Inter-AS TE LSP Path set up The end-to-end inter-AS TE LSP set up will be made of the following steps (at each step, an example is provided, based on the assumptions made in section 3): Hypothesis: an inter-AS TE LSP must be set up between AS1 and ASn (in the example provided bellow n=3 - an inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 in AS3 must be set up). Step 1: discovery by the HE LSR of the PCS serving the source AS that can compute inter-AS TE LSP path terminating in ASn. As mentioned above, the PCS can either be statically configured or dynamically discovered via IGP extensions. Ex: R1 selects ASBR1 as the PCS serving its request for the T1 path computation. Step 2: an RSVP Path computation request is sent to the selected PCS. Note that the RSVP path computation request can be sent either: (1) to a PCS in the same AS as the PCC that will relay the request to a PCS in the next hop AS Ex: R0 sends an RSVP path computation request to ASBR1 or (2) can be directly sent to the PCS in the next hop AS if the HE LSR has a complete topology and TE view up to the next hop PCS (depending on the configuration). Ex: R0 sends an RSVP path computation request to ASBR4 Note on the PCC-PCS and PCS-PCS communication (when a PCC sends a request to a PCS in another AS) and PCS-PCS (when the PCSes belong to different ASes) - some policy may be put in place between SPs, - the communication MIGHT be secured making use of RSVP authentication It is expected that (1) will be the most common inter-AS TE deployment scenario. Step i: the PCS of ASi relays the path computation request to the targeted PCS peer in AS(i+1) located in the next hop AS. Note that the address of the list of PCS(es) in the next hop AS must be statically configured on the PCS. This implies some static configuration on the PCS only as opposed to the PCS address configuration required on every potential PCC with an AS. Ex: ASBR1 sends an RSVP path computation request to ASBR4 Vasseur and Zhang 15 draft-vasseur-inter-AS-TE-00.txt February 2003 Step 3: If the TE LSP destination is in ASi, then the PCS provides the list of shortest path (with their corresponding ERO (potentially partial ERO) + Path-cost) from every ASBR to the inter-AS TE LSP destination. See a detailed example bellow. If the TE LSP destination is not in ASi, the PCS relays the RSVP path computation request to the targeted PCS peer in AS(i+2) in the next hop AS. The process is iterated until the destination AS is reached. Ex: ASBR4 relays the RSVP path computation request to ASBR9 which determines that the T1's destination address belongs to its own AS. ASBR9 will in turn return a path computation reply to the requesting PCS (which is considered as a PCC in this case), e.g ASBR4. The RSVP path computation reply contains two routes: - ERO 1: ASBR9-R6, Cost=c1, - ERO 2: ASBR10-R7-R6, Cost=c2 Note that the ERO object might be made of loose hop to preserve confidentiality. Step 4: Once a requesting PCSi receives an RSVP Path computation reply, the shortest path is computed from ASi to ASi+1 by route concatenation. This is done by running a virtual SPT (Shortest Path Tree) computation using SPF where the nodes are the ABSRs connected by virtual link whose cost are equal to the shortest path connecting the ASBRs. <---BGP---> <---BGP--> CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9---R6 |\ \ | / | / | / | | | | \ ASBR2---/ ASBR5 | -- | | | | \ | | |/ | | | R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2 Resulting Virtual SPT computed by ASBR 4 ASBR4---ASBR7---ASBR9---R6 | | \ / /| \ / | / | | \ / | \/ | / | | / \/ | /\ | / | | / /\ | / \ | / |ASBR5--ASBR8---ASBR10 | | / / | | / / | | / / | |/ / ASBR6 Within ASi, the cost of each ASBR-ASBR virtual link is equal to the shortest path cost. This information is known by PCSi. Vasseur and Zhang 16 draft-vasseur-inter-AS-TE-00.txt February 2003 The cost of the ASBR-ASBR link between ASBR of different ASes is also known by the PCSi (see section 4). Within ASi+1, the cost of the ASBR-ASBR virtual link is provided in the RSVP path computation reply of the PCSi+1. Ex: ASBR4 will then compute the shortest path for the TE LSP traversing AS2 and AS3. Then the process is reiterated recursively until the end-to-end Path computation is computed. The whole path may not be seen by each PCS for confidentiality reason but this process will ensure that the shortest path is selected. Example: the resulting computed virtual SPT computed by ASBR1 will finally be: R0-----ASBR1-----ASBR4----R6 | \ | |\ \ / /|| / / | \ | | \ \ / || / / | \ | | / \/ || / / | \ | | / \/\ ||/ | | \-|-ASBR2-ASBR5 | | | |\ /\/ || | | | | \/ /\ || / | | | /\/ \ || / | | |/ /\ \|| / --------|=ASBR3--ASBR6/ Then once the optimal end to end path is computed, the HE LSR sets up the inter-AS TE using a complete list of ERO if the various PCS have provided the list of ERO or some loose hops in the contrary, similarly to the scenario 1. 6.4. Support of diversely routed paths As mentioned above in section 5.2, the RSVP signaling protocol defined in [PATH-COMP] allows an LSR to request the computation of a set of N diversely routed TE LSPs. Then in this scenario, a set of diversely routed TE LSP between two LSRs can be computed. 6.5. Optimality As opposed to scenario 1, and end-to-end shortest path obeying the set of required constraint is computed. In that sense, the path is optimal. Note that in order for this path computation to be meaningful, a metric normalization between ASes is required. One solution to avoid IGP metric modification would be for the SPs to agree on a TE metric normalization and use the TE metric for TE LSP path computation (in Vasseur and Zhang 17 draft-vasseur-inter-AS-TE-00.txt February 2003 that case, this must be requested in the RSVP Path computation request via the METRIC-COST object). 7. Routing traffic onto inter-AS TE LSPs Once an inter-AS TE LSP has been set up, the Head-end LSR has to determine the set of traffic to be routed onto the inter-AS TE LSP. In the case of intra-area TE LSP, various options are available: (1) modify the IGP SPF such that shortest path calculation can be performed taking into account existing TE LSP, with some path preference, (2) make use of static routing. Note that the recursive route resolution of BGP allows routing any traffic to a particular (MP)BGP peer making use of a unique static route pointing the BGP peer address to the TE LSP. So any routes advertised by the BGP peer (IPv4/VPNv4 routes) will be reached using the TE LSP. With an inter-AS TE LSP, just the mode (2) is available, as the TE LSP Head-end does not have any topology information related to the destination AS. 8. Applicability of MPLS TE Fast Reroute to Inter-AS TE LSP MPLS Traffic Engineering Fast Reroute ([FAST-REROUTE]) defines a local protection scheme that provides fast recovery (in 10s of msecs) of protected TE LSPs upon link/SRLG/Node failure. A backup TE LSP is configured and signaled at each hop and upon detecting a network element failure (via link failure detection mechanisms providing via layer 2 protocol, or IGP/RSVP fast hellos), the node immediately upstream to the failure (called the PLR (Point of Local Repair)) reroutes the set of protected TE LSPs onto the appropriate backup tunnel(s) around the failed resources. In the context of Inter-AS TE LSP, one must consider the following failure scenarios and analyze for each of them the potential required extensions for MPLS TE FRR. [FAST- REROUTE] specifies two modes referred to as the one to one and facility back up mode. This section specifies the use of MPLS TE Fast Reroute for the facility backup mode. 8.1. Within an Autonomous System (link or node failure) The current set of mechanisms defined in [FAST-REROUTE] applies without any restriction to any link/SRLG/Node failure within an AS. In other words, a protected inter-AS TE LSP (an LSP signaled with the "local protection desired" bit set in the SESSION-ATTRIBUTE object or with a FAST-REROUTE object) can be protected via the MPLS TE Fast Reroute mechanism regardless of whether the TE LSP is an intra-AS or inter-AS TE LSP in case of link/SRLG/node failure within the AS. Vasseur and Zhang 18 draft-vasseur-inter-AS-TE-00.txt February 2003 8.2. At AS boundaries 8.2.1. Failure of an ASBR-ASBR link To protect a link connecting two ASBRs with MPLS TE Fast Reroute, the following actions are required: - A set of backup tunnels must be configured between the two ASBRs diversely routed from the protected ASBR to ASBR link. Typically, the region connecting two ASes is not TE enabled. So an implementation will have to support the set up of TE LSP over a non-TE enabled region. The backup tunnel path will be configured on each ASBR as a set of strict hops and then signaled via the RSVP-TE procedure defined in RFC3209. The reason why a set of NHOP backup tunnels might be required is in case of requirement for bandwidth protection if a single backup tunnel satisfying the bandwidth requirement cannot be found (see [BANDWIDTH-PROTECTION]). - For each protected inter-AS TE LSP traversing the protected link, a NHOP backup must be selected by a PLR (i.e ASBR), when the TE LSP is first set up. This requires for the PLR to select a backup tunnel terminating at the NHOP. Finding the NHOP backup tunnel of an inter-AS LSP can be achieved by analyzing the content of the RRO object received in the RSVP Resv message of both the backup tunnel and the protected TE LSP(s). As defined in [RSVP-TE], the addresses specified in the RRO IPv4 subobjects can be node-ids and/or interface addresses (with specific recommendation to use the interface address of the outgoing Path messages). Within a single area, the PLR can easily find whether the backup tunnel intersects the protected TE LSP regardless of whether the node- id or the interfaces are specified in the RRO object as it has the complete topology knowledge in its IGP database. This is not the case when the MP resides in a different AS. [NODEID] proposes a solution to this issue, defining an additional RRO IPv4 suboject that specifies a node-id address. Example: The ASBR1-ASBR4 link is protected by the backup tunnel B1 that follows the ASBR1-ASBR2-ASBR4 path. 8.2.2. Failure of an ASBR LSR node To protect inter-AS TE LSP from an ASBR node failure using MPLS TE Fast Reroute, the following actions are required: (1) a set of backup tunnel(s) must be configured from the penultimate hop in AS1 (penultimate node directly connected to Vasseur and Zhang 19 draft-vasseur-inter-AS-TE-00.txt February 2003 the last ASBR in AS1) to the first ASBR in AS2 to protect against the failure of the last ASBR in AS1. Example: B1 from X1 to ASBR4 follows the X1-ASBR2-ASBR4 path and protects against the failure of the ASBR1 node. (2) a set of backup tunnel(s) must be configured from the last ASBR in AS1 to the next hop of the first ASBR in AS2 to protect against the failure of the first ASBR in AS2. Example: B3 from ASBR1 to R3 follows the ASBR1-ASBR2-ASBR3- ASBR6-ASBR5-R3 path and protects against the failure of the ASBR4 node. - for each protected inter-AS TE LSP traversing the protected link/node, a NNHOP backup must be selected by a PLR (i.e LSR/ASBR). This requires for the PLR to select a backup tunnel terminating at the NNHOP. Finding the NNHOP backup tunnel of an inter-AS LSP can be achieved by analyzing the content of the RRO object received in the RSVP Resv message of both the backup tunnel and the protected TE LSP(s). 8.3. Procedures of PLR during Fast Reroute For the sake of illustration, procedures related to MPLS TE Fast Reroute that indifferently apply to intra-AS or inter-AS TE LSP will be first described followed by the required changes specific to inter-AS TE LSP. Upon link/SRLG/Node failure detection, a PLR must immediately start rerouting the protected TE LSP onto their respective backup tunnel (which has been selected when the protected inter-AS TE LSP has first been set up). In addition, the RSVP control traffic must be sent over the backup tunnel (this includes RSVP Path, PathTear, and ResvConf messages - the MP (Merge Point) sends Resv, ResvTear, and PathErr messages to the address specified in the RSVP_HOP object). The following changes are performed: - The SESSION object is unchanged, - The SESSION-ATTRIBUTE object is unchanged except: The "Local protection desired", "Bandwidth protection desired", and "Node protection desired" flags SHOULD be cleared. The "Label recording desired" MAY be modified. - The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE is set to an address belonging to the PLR (if the PLR is also the Head-End LSR an IP address different from Vasseur and Zhang 20 draft-vasseur-inter-AS-TE-00.txt February 2003 the IP address used in the original SESSION-TEMPLATE must be chosen by the PLR). - The RSVP_HOP object is set to an IP source address belonging to the PLR. Consequently, the MP will send messages back to the PLR using as a destination that IP address. - The PLR must update the EXPLICIT_ROUTE object toward the egress. As mentioned in [FAST-REROUTE], the ERO object must be updated by the PLR before sending the RSVP Path message over the backup tunnel; otherwise the MP would receive an incorrect ERO object and would likely discard the Path message with the cause "Bad initial subobject" (in case of NHOP backup tunnel, the ERO would contain the IP address of a down interface - in case of NNHOP backup tunnel, the MP would receive the PLR's NHOP address). Within a single area, the PLR must: - Remove all the sub-objects preceding the first address belonging to the MP. - Replace this first MP address with an IP address of the MP. In the context of inter-AS TE LSP, there is a specific action that must be performed when protecting the first ASBR of the next AS via a NNHOP backup tunnel (see 5.6.3 (1)). The PLR must: - Identify the MP address in the RRO received in the corresponding Resv message, - Remove all the sub-objects preceding the first address belonging to the MP, - Replace this first MP address with the IP address of the MP (its node-id address). Note that in order to support ASBR Node protection for inter-AS TE LSP in case of failure of the first ASBR in the next hop AS, some specific action must be performed. Example: <---BGP---> <---BGP--> CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9---R6 |\ \ | / | / | / | | | | \ ASBR2---/ ASBR5 | -- | | | | \ | | |/ | | | R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2 Vasseur and Zhang 21 draft-vasseur-inter-AS-TE-00.txt February 2003 - T1: a protected inter-AS TE LSP from R0 to R6, whose path is defined on R0 as a set of loose hops: R0-ASBR1(loose)- ASBR4(loose)-ASBR9(loose)-R6 - B3: a backup tunnel from ASBR1 to R3 following the ASBR1- ASBR2-ASBR3-ASBR6-ASBR5-R3 path and protecting against a failure of the ASBR4 node. - The ERO subobject content signaled in the rerouted RSVP Path message of T1 over B3 by ASBR1 (PLR) must content the MP's as the next hop address (R3). Overwise, R3 will receive an incorrect ERO. A similar mechanism is required when rerouting an inter-AS TE LSP from the failure of the last ASBR of an AS. - The RRO object may need to be updated by inserting an IPv4 or IPv6 subobject corresponding to the outbound interface address the rerouted traffic is forwarded onto (both the "Local protection in use" and "Local Protection Available" flags must be set). Notification of Local repair For each rerouted TE LSP, the PLR MUST send a notification of the local repair by sending an RSVP Path Error message with error code of "Notify" (Error code =25) and an error value field of ss00 cccc cccc cccc where ss=00 and the sub-code = 3 ("Tunnel locally repaired") (see [RSVP-TE]). In the context of inter-AS TE LSP, if the failure occurs in an area/AS different from the HE LSR, the HE LSR exclusively relies on the Path Error message to get informed that a local repair has been performed in order to potentially perform a reoptimization. The RSVP Path Error message SHOULD be sent in reliable mode ([REFRESH- REDUCTION]). 9. Failure handling of inter-AS TE LSP In the context of MPLS Inter-AS Traffic Engineering, if a link/SRLG/Node failure occurs in an AS different from the HE LSR, the HE LSR exclusively relies on the receipt of an RSVP Path Error message to get informed that the TE LSP has suffered a failure in a downstream AS (a "Notify" Path Error "Notify" message if the inter-AS TE has been locally repaired via MPLS TE Fast Reroute. For those reasons, the Path Error message SHOULD be sent in reliable mode ([REFRESH-REDUCTION]). Note that this requires to configure the reliable messaging mechanisms proposed in [REFRESH-REDUCTION] between every pair of LSRs in the network (more precisely between every PLR and any potential HE LSRs). Upon receiving an RSVP Path Error message, a HE LSR must perform a TE reroute (new route computation) in a make before break fashion. Vasseur and Zhang 22 draft-vasseur-inter-AS-TE-00.txt February 2003 It is worth highlighting that the set up of inter-AS TE LSP might be significantly slower than in the case of intra-area TE LSP: - In scenario 1, the process involves several ASBRs performing policy control, partial route computation (ERO expansions), ... In case of set up failure, the number of trials can be significant, which even more increases the set up time. Furthermore, in case of dynamic loose hop computation, both the IGP and BGP reachability solutions have drawbacks in term of convergence upon failure. This is due to the slow convergence property of BGP. With BGP redistribution within ASes, the convergence might be even slower especially when BGP Route Reflector are in use with no multi-paths load balancing. - In scenario 2, some signaling exchange between potentially quite a few PCC and PCS are performed prior to setting up the TE LSP. Note that in scenario 2, the probability of TE LSP set up failure is limited to some lack of synchronization of the TE databases and as such is significantly lower than in the case of scenario 1. Moreover, in case of a large amount of inter-AS TE LSP set up, some non negligible extra signaling and routing computation load will be required on the loose hops (scenario 1) and loose hops/PCS (scenario 2). Some implementation may implement some pacing of inter-AS TE LSP set up rate. Typically a link/node/SRLG failure may impact a large number of TE LSPs. Relying on a local repair mechanism like MPLS TE Fast Reroute allows to relax the load on ASBR/PCS and reduces the need for urgent inter-AS TE LSP reroute. This is the recommended approach. 10. Reoptimization of Inter-AS TE LSP After an inter-AS TE LSP has been set up, a more optimal route might appear in the various traversed ASes. Then in this case, it is desirable to get the ability to reroute an inter-AS TE LSP in a non- disruptive fashion (making use of the so called Make Before Break procedure) to follow this more optimal path. This is a known as a TE LSP reoptimization procedure. [LOOSE-REOPT] proposes a mechanisms allowing: - The Head-end LSR to trigger on every LSR whose next hop is a loose hop the re evaluation of the current path in order to detect a potentially more optimal path. This is done, via explicit signaling request: the HE LSR sets the "ERO Expansion request" bit of the SESSION-ATTRIBUTE object carried in the RSVP Path message. Vasseur and Zhang 23 draft-vasseur-inter-AS-TE-00.txt February 2003 - An LSR whose next hop is a loose-hop to signal to the Head- end LSR that a better path exists. This is performed by sending an RSVP Path Error Notify message (ERROR-CODE = 25). Two new sub-codes are defined: 4 Better path exists: sent by any LSR upon detecting that a better path exists. 5 No better path: sent by any LSR polled by the HE LSR to indicate that no better path exists. This indication may be sent either: - in response to a query sent by the HE LSR, - spontaneously by any LSR having detected a more optimal path The reoptimization event can be either: - timer-based: a timer expires, - event-driven: a link UP event for instance. Note that the reoptimization MUST always be performed in a non disruptive fashion. Once the HE LSR is informed of the existence of a more optimal either in its head-end area/AS or in another AS, the inter-AS TE Path computation is triggered using the same set of mechanisms as when the TE LSP is first set up (per-AS path computation as in scenario 1 or Path Computation Server in scenario 2). Then the inter-AS TE LSP is set up following the more optimal path, making use of the make before break procedure. 11. Inter-AS MPLS TE Management [LSPPING] proposes a solution which can be adopted for inter-AS TE LSPs whereby a HE LSR sends MPLS echo requests over the LSP being tested. When the destination LSR receives the message, it needs to acknowledge the source LSR by sending an LSP_ECHO object in a RSVP Resv message. The TTL processing over inter-AS TE primary or local backup LSPs will be supported as per [MPLS-TTL]. 12. Scalability and extensibility All the features related to intra-area TE LSP are also applicable to inter-AS TE LSP, without any restriction. 13. Policy Control at the AS boundaries Vasseur and Zhang 24 draft-vasseur-inter-AS-TE-00.txt February 2003 As stated in section 5.11 of [INTER-AS-TE-REQS], a set of configurable options may be made available upon which ingress control policies can be implemented governing or honoring inter-AS TE agreements made by two interconnect SPs. During the path-computation process, the inter-AS RSVP path message sent to its downstream loose hop (ASBR also) in a different AS can be firstly passed through an inter-AS TE policy control process on the downstream ASBR prior to its ERO expansion. The inter-AS RSVP path setup request will get rejected resulting in an path-error message will be sent to the HE LSP should it fail the control policy, for example, requesting bandwidth reservation more than agreed upon or wrong preemption priorities. 14. Confidentiality As mentioned in [INTER-AS-REQS], since an inter-AS TE LSP may span multiple ASes belonging to different SPs, the solution should allow to preserve AS confidentiality, by hiding the set of hops followed by the inter-AS TE LSP within an AS. In scenario 1, this requirement can be met via the proper RRO filtering at the AS boundaries (this applies to the RRO object carried in both the Path and Resv message). Note that, if MPLS TE Fast Reroute is required to protect inter-AS TE LSP against the failure of an ASBR, the RRO object carried in the Resv message of an inter-AS TE LSP must not be completely filtered, as mentioned in section 7. As least, the information (label, IPv4 or IPv6 subobject (node-id subobject)) pertaining to the ASBR's next hop must be preserved. In scenario 2, the RSVP Path computation reply can be filtered to provide a partial ERO (an ERO containing loose hops). If the agreement between SPs at AS boundary is such that confidentiality must be guaranteed, then the PCC in AS x MUST send a Path computation request to the PCS in AS y, with the "Partial" flag of the REQUEST-ID object set. The PCS SHOULD control that this flag is appropriately set; if not, the PCS might decide either to provide a partial ERO or to drop the request. Even when the returned ERO is partial, the PCS might provide the cost of the computed path. This can be done by including a PATH-COST object in the RSVP Path computation reply message. If the agreement between SPs at AS boundaries is such that path cost might be provided, then the PCC in AS x might send a Path computation request to the PCS in AS y, with the "cost" flag of the REQUEST-ID object set. The PCS controls that this flag is appropriately set; if set, the PCS should include a PATH-COST object in its RSVP Path Computation reply message. Note that this is required to compute end to end shortest path. 15. Security Considerations Vasseur and Zhang 25 draft-vasseur-inter-AS-TE-00.txt February 2003 When signaling an inter-AS TE, one may make use of the already defined security features related to RSVP (authentication). This may require some coordination between SPs to share the keys (see RFC 2747 and RFC 3097). 16. Intellectual Property Considerations Cisco Systems may have intellectual property rights claimed in regard to some of the specification contained in this document. 17. Acknowledgments We would like to acknowledge input and helpful comments from Carol Iturralde, Francois le Faucheur and Rob Goguen. 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. [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-01.txt, May 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 Vasseur and Zhang 26 draft-vasseur-inter-AS-TE-00.txt February 2003 [PATH-COMP] Vasseur et al, "RSVP Path computation request and reply messages", draft-vasseur-mpls-computation-rsvp-03.txt, November 2001. [OSPF-TE-CAP] Vasseur, Psenak. "OSPF TE TLV capabilities", draft- vasseur-mpls-ospf-te-cap-00.txt, October 2002 (Work in Progress). [IGP-CAP] Aggarwal et all, "Extensions to IS-IS and OSPF for Advertising Optional Router Capabilities", Internet draft, draft- raggarwa-igp-cap-01.txt, October 2002 (Work in progress). [MULTI-AREA-TE] Kompella at all,"Multi-area MPLS Traffic Engineering", draft-kompella-mpls-multiarea-te-03.txt, June 2002. [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G., Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS", Internet Draft <draft-ietf-mpls-lsp-ping-02.txt>, 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-zhang-interas-te-req-01.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- 01.txt, February 2003, Work in Progress. [NODE-ID] Vasseur, Ali and Sivabalan, "Definition of an RRO node-id subobject", draft-vasseur-mpls-nodeid-subobject-00.txt, February 2003, Work in progress. Authors' Address: Jean Philippe Vasseur Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824 USA Email: jpv@cisco.com Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA Email: raymond_zhang@infonet.com Vasseur and Zhang 27