Network Working Group Arthi Ayyangar (Juniper Networks) Internet Draft Jean Philippe Vasseur (Cisco Systems) Category: Standards Track June 2003 Expires: November 2003 Inter-region MPLS Traffic Engineering draft-ayyangar-inter-region-te-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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This draft proposes mechanisms for the establishment and maintenance of MPLS Traffic Engineering (TE) Label Switched Paths (LSP) that traverse multiple regions, where a region could be an IGP Area or an Autonomous System or a GMPLS overlay network. This document also outlines different mechanisms that an operator could employ within his region to facilitate the setup of these inter-region TE LSPs. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Ayyangar, Vasseur Standards Track [Page 1] Internet Draft Inter-region MPLS Traffic Engineering June 2003 1. Terminology In the context of this document we define an "TE LSP region", or just "region" as either a single IGP area, or a single Autonomous System (AS). Note that a region formed by an AS may itself be composed of multiple regions, each corresponding to an IGP area. The notion of 'TE LSP nesting' refers to the ability to carry one or more inter-region TE LSPs within another intra-region TE LSP by using the MPLS label stacking property at the Head-end of the intra-region LSP. On the other hand, 'stitching a TE LSP' means to split one inter-region LSP and insert (another) intra-region LSP, into the split, which implies a label swap operation at the Head-end of the intra-region LSP. It also implies a swap at the tail-end of the intra-region LSP. Similar to [LSP_HIER], in the context of this document as well, the term FA-LSP always implies one or more LSPs nested within another LSP using the label stack construct. And we use the term 'LSP segment' when one LSP is split and another LSP is inserted into the split (LSP stitching). Other terminologies used are: LSP - An MPLS Label Switched Path LSR - Label Switch Router TE LSP - Traffic Engineering Label Switch Path (also referred as LSP in this draft) TED - TE database FA-LSP - Forwarding Adjacency LSP GMPLS - Generalized MPLS ABR - Area Border Router AS - Autonomous System ASBR - Autonomous System Border Router ERO - Explicit Route Object IGP - Interior Gateway Protocol CSPF - Constraint-based Shortest Path First RRO - Record Route Object Ayyangar, Vasseur Standards Track [Page 2] Internet Draft Inter-region MPLS Traffic Engineering June 2003 Protect TE LSP - a TE LSP requesting local protection in the context of [FAST-REROUTE]: the local protection desired bit of the SESSION- ATTRIBUTE object is set or a FAST-REROUTE object is inserted in the RSVP Path message PLR - Point of Local Repair; i.e. the head end of a bypass tunnel or a detour LSP MP - Merge Point; i.e. the LSR where the bypass tunnel or detour rejoin the protected LSP SP - Service Provider HE LSR - Head End Label Switching Router 2. Introduction When TE LSPs span multiple regions, there can be multiple approaches taken by the solutions. The solution proposed in [INTER-AS] enables an operator to signal a contiguous inter-AS TE LSP and exercise more control at the head-end LSR of the TE LSP. On the other hand, this document focuses on signaling a TE LSP with LSP segments or FA-LSPs in different regions (ASes) and exercise more localized (per region) control on the inter-region TE LSP. There are also other differences between the two solutions that will not be detailed here. This draft builds upon the constructs and mechanisms defined in [LSP- HIER] for the setup of TE LSPs spanning multiple regions (areas and/or ASes). The idea is to separate the inter-region LSP into different segments at the region boundaries such that each region is completely in control of it's segment. Using LSP Hierarchy, not only improves scaling by aggregating the end-to-end LSP requests, it also helps to achieve a common solution to solve the generic problem of establishing LSPs crossing different "regions", without any significant protocol changes. Also, since the operator of a region has complete control on the FA-LSP (with nesting) or the LSP segment (with stitching) in that region and the transit LSPs transported across that region, this solution is also applicable when a TE LSP traverses different administrative domains. The solution, therefore, also aims to be applicable to the GMPLS overlay model ([GMPLS- OVERLAY]), where the client requesting the LSP setup would belong to a region different from the core network region. [LSP-HIER] uses the Interface Switching Capabilities to construct regions and determine region boundaries. This document augments the definition of region in [LSP-HIER] by adding two new types of regions :- an IGP area (for OSPF)/ level (for ISIS) and an Autonomous System Ayyangar, Vasseur Standards Track [Page 3] Internet Draft Inter-region MPLS Traffic Engineering June 2003 (AS). In the former case, the boundaries of the region are the Area Border Routers (ABRs) of the area that forms the region: the boundaries of the region could be determined by examining the IGP information. In the latter case, the boundaries of the region are the Autonomous System Border Routers (ASBRs) of the AS that forms the region: the boundaries of a region could be determined by examining the BGP information. Neither of these cases require the use of the Interface Switching Capabilities to construct regions and determine regions boundaries. The draft also abides by several requirements for Inter-AS Traffic Engineering listed in [INTER-AS-TE-REQTS] for inter-AS LSP setup where a region would correspond to an AS. 3. Assumptions and Requirements - Each region in all the examples below is assumed to be capable of doing Traffic Engineering; i.e running OSPF-TE or ISIS-TE and RSVP-TE and may itself be composed of several other regions (for instance when an AS is made of several IGP areas/levels). - The inter-region LSPs are signaled using RSVP-TE ([RSVP-TE]). - The path (ERO) for the inter-region LSP traversing multiple regions is either configured as a set of (loose and/or strict) hops or the boundary LSRs for each of the regions along the path are capable of dynamically finding the next-hop boundary LSR towards the LSP destination when the LSP setup request arrives. This process of being able to dynamically determine the next-hop boundary LSR for a destination during LSP setup will be referred to as "auto-discovery" mechanism in the rest of this document. In the absence of any auto- discovery mechanism, the configured ERO MUST at least include all the boundary LSRs of each region to be traversed along the path. Then in this case, it is assumed that a boundary LSR has the ability to expand the ERO and compute the TE LSP path up to the next boundary LSR listed as a loose hop in the ERO. While the ability of a region boundary LSR to auto-discover the next-hop boundary LSR needs to be a part of the complete inter-region TE solution, it will not be discussed here. In the absence of any auto-discovery mechanism, the addresses configured in the ERO MUST be reachable by the corresponding previous hop boundary LSR. - The paths for the intra-region FA-LSPs or LSP segments, may be pre- configured or computed dynamically based on the arriving inter-region LSP setup request; depending on the requirement of the operator of the transit region. When the paths for the FA-LSPs/LSP segments are pre-configured, the constraints as well as other parameters like Ayyangar, Vasseur Standards Track [Page 4] Internet Draft Inter-region MPLS Traffic Engineering June 2003 local protection scheme for the intra-region FA-LSP/LSP segment are also pre-configured. Some local algorithm can be used on the HE LSR of a FA-LSP to dynamically adjust the FA-LSP bandwidth based on the number of inter-region TE LSPs carried onto this FA-LSP. It is recommended to use a threshold triggering mechanism to avoid constant bandwidth readjustment as inter-region TE LSP are set up and torn down. - While certain constraints like bandwidth can be used across different regions, certain other constraints like resource affinity, color, metric; etc could be translated differently in different regions. It is assumed that, at the region's boundary LSRs, there will exist some sort of local mapping based on offline policy agreement, in order to translate such constraints across region boundaries. This would be something similar to 'Inter-AS TE Agreement Enforcement Polices' stated in [INTER-AS-TE-REQTS]. - The intra-region FA-LSPs or LSP segments in packet-switched networks are assumed to be unidirectional. - When a region boundary LSR at the exit of a region receives a TE LSP setup request (Path message) for an inter-region TE LSP, then if this LSP had been nested or stitched at the entry region boundary LSR, then this exit boundary LSR can determine the corresponding FA- LSP or LSP segment from the received Path message. - The Record Route Object (RRO) is an optional object, and if the inter-region LSPs do not require features like protection which require the RRO in the RSVP messages, then the inter-region LSPs do not need to carry the RRO. 4. Basic Operation 4.1. Intra-region FA-LSP/LSP segment setup FA-LSPs or LSP segments can be pre-configured on any region boundary LSR. But for dynamic FA-LSP/LSP segment setup, by default, only a region boundary LSR that receives an inter-region LSP setup request (Path) from a different region SHOULD trigger the setup of a FA-LSP or LSP segment in it's region. So all boundary LSRs at the entry to a region, are candidates for dynamic intra-region FA-LSP/LSP segment setup. The source of an inter-region LSP can be treated as an exception to the above clause and MAY be considered as a candidate for dynamic FA-LSP/LSP segment setup. Also, the default behavior MAY be overridden by configuration, if required. When a region boundary LSR receives a Path message with a loose next- Ayyangar, Vasseur Standards Track [Page 5] Internet Draft Inter-region MPLS Traffic Engineering June 2003 hop in the ERO, then it carries out the following actions: - It checks if the loose next-hop is accessible via the TE database. If the loose next-hop is not present in the TED; then it will check if the next-hop at least has IP reachability (via IGP or BGP). If the next-hop is not reachable, then the LSR will be unable to propagate the Path message any further and will send back a PathErr upstream. If the next-hop is reachable and an auto-discovery mechanism exists, then it will find a region boundary LSR to get to the next-hop. - If the next-hop boundary LSR is present in the TED; then if this region boundary LSR (receiving the LSP setup request) is a candidate LSR for intra-region FA-LSP/LSP segment setup, then if there is no FA-LSP/LSP segment from this LSR to the next-hop boundary LSR, (satisfying the constraints) it SHOULD signal a FA-LSP/LSP segment to the next-hop boundary LSR. If pre-configured FA-LSP(s) or LSP segment(s) already exist, then it SHOULD try to select from among those LSPs. Depending on local policy, it MAY signal a new FA-LSP/LSP segment if this selection fails. If the FA-LSP/LSP segment is successfully signaled or selected, it propagates the inter-region Path message to the next-hop following the procedures described in [LSP-HIER]. If, for some reason the dynamic FA-LSP/LSP segment setup to the next-hop boundary LSR fails, a PathErr is sent upstream for the inter-region LSP. Similarly, if selection of a pre-configured FA- LSP/LSP segment fails and local policy prevents dynamic FA-LSP/LSP segment setup, then a PathErr is sent upstream for the inter-region LSP. - If, however, this region boundary LSR is not a FA-LSP/LSP segment candidate, then it SHOULD simply compute a CSPF path upto the next- hop boundary LSR (carry out an ERO expansion to the next-hop boundary LSR) and propagate the Path message downstream. The outgoing ERO may be modified after an ERO expansion to the loose next-hop. The above procedures do not apply when a region boundary LSR receives a Path message with strict next-hop. Note that this mode of operation depends on TE LSP attributes requested in the LSP_ATTRIBUTE object (see [INTER-AS]) of the inter- region TE LSP. As described in Section 1, the solution proposed in [INTER-AS] enables an operator to signal a contiguous inter-AS TE LSP. So, the following bit may be set in the LSP_ATTRIBUTE object to control the desired behavior on the intermediate nodes. 0x02: Contiguous LSP required bit: when set this indicates that a boundary LSR MUST not perform any stitching or nesting on the TE LSP and the TE LSP MUST be routed as any other TE LSP (it must be contiguous end to end). When this bit is cleared, a boundary LSR can Ayyangar, Vasseur Standards Track [Page 6] Internet Draft Inter-region MPLS Traffic Engineering June 2003 decide to perform stitching or nesting. The details of the LSP_ATTRIBUTE object can be found in [INTER-AS]. 4.2. Inter-area LSP setup Several schemes have been proposed for inter-area TE (see [INTER- AREA]). This draft proposed an additional method. In this case, each region corresponds to a single IGP area and the ABRs will form the region boundaries. A-B-C-D: inter-area TE LSP path B, B', C, C': ABRs R1, R0, R2: LSRs within respective areas 1, 0 and 2 +--------------+ +-----------------+ +--------------+ |Area1 | | Area0 | |Area2 | | B C | |A | | | | D| | R1 B' R0 C' R2 | | | | | | | +--------------+ +-----------------+ +--------------+ Let us consider a scenario where A initiates the setup of an inter- area TE LSP from A to D. When the Path message reaches B, B performs the following set of actions: - It determines the egress LSR from its region along the LSP path (say C), either from the ERO or by using some constraint-aware auto- discovery mechanism or based on just reachability information. - B will check if it has a FA-LSP or LSP segment to C matching the constraints carried in the inter-region Path message; if not B will setup a FA-LSP or LSP segment from B to C. Note that once the FA- LSP/LSP segment is setup, it will be advertised as a link within that region (see [LSP-HIER]) (area 0 in this example). The FA-LSP or LSP segment could have also been pre-configured. - In the Path message for the FA-LSP/LSP segment, B also signals whether it will do a one-to-one LSP stitching or whether it will nest the inter-region LSP over the intra-region FA-LSP. The details of how this is signaled, is described in Section 5. - Also, there could be multiple FA-LSPs/LSP segments between B and C. So, B needs to select one FA-LSP/LSP segment from these, for the Ayyangar, Vasseur Standards Track [Page 7] Internet Draft Inter-region MPLS Traffic Engineering June 2003 inter-region LSP through Area 0. The mechanism and the criterion used to select the FA-LSP/LSP segment is local to B and will not be described here in detail. e.g. if we have multiple pre-configured FA- LSPs/LSP segments, a local policy may prefer to use FA-LSPs (nesting) for most inter-region LSP requests. And it may select the LSP segments (stitching) only for some specific inter-region LSPs. - Once it has selected the FA-LSP/LSP segment for the inter-region LSP, using the signaling procedures described in [LSP-HIER] B sends the Path message for inter-region LSP to C. Note that irrespective of whether B does nesting or stitching, the Path message for the inter- region TE LSP is always forwarded to C. C then repeats the exact same procedures and the Path message for the inter-area TE LSP will reach the destination D. If C cannot find a path obeying the set of constraints for the inter-region TE LSP, then C MUST send a PathErr message to B. Then B can in turn either select another FA-LSP/LSP segment to C if such an LSP exists or select another egress boundary LSR (C' in the example above). Note also, that B may be configured to forward the PathErr up to the inter-region HE LSR without trying to select another egress LSR. - The Resv message for the inter-area TE LSP is sent back from D to A. When the Resv message arrives at C, depending on whether C is nesting or stitching, C will install the appropriate label operations for the packets arriving on the inter-region LSP. Similar procedures are carried out at B as well, while processing the Resv message. As the Resv message for the inter-region LSP, traverses back from D to A, each LSR along the Path may record an address into the RRO object carried in the Resv. According to [RSVP-TE], the addresses in the RRO object may be a node or interface addresses. The link corresponding to an unnumbered FA-LSP/LSP segment will have the ingress and egress LSR Router-IDs as the link addresses ([RSVP- UNNUM]). So when C sends the Resv message to B, C will record it's Router ID in the RRO object. So, the inter-area TE LSP from A to D would have an RRO of A-B-C-D or A--B-C-D, depending on whether the source region is setting up a FA-LSP/LSP segment or not. If the FA-LSPs/LSP segments are numbered, then the addresses assigned to the FA-LSP/LSP segment will be recorded in the RRO object. 4.3. Inter-AS LSP setup In this case, each region corresponds to a single AS and the ASBRs define the region boundaries. As per 4.1, however, the FA-LSPs or LSP segments will only be originated by the ASBRs at the entry to the AS. A few examples of the inter-AS LSPs: A to F (LSR to LSR), CE1 to CE2 (CE to CE), R1 to R2 or R1 to R3, CE1 Ayyangar, Vasseur Standards Track [Page 8] Internet Draft Inter-region MPLS Traffic Engineering June 2003 to F (CE to ASBR) AS1, AS2, AS3: Three ASes either belonging to same SP or different SPs B,B',C,C',D,D',E,E': ASBRs R1, R2, R3: Other LSRs within the respective ASes +---------------+ +-----------------+ +---------------+ |AS1 | |AS2 | |AS3 | | B |--|C D |--|E | CE1-|A | | | | F|-CE2 | R1 B'|--|C' R2 D'|--|E' R3 | | | | | | | +---------------+ +-----------------+ +---------------+ The procedures for establishing an inter-AS TE LSP are very similar to that of the inter-area TE LSP described above. The main difference here from the inter-area case, is the presence of the ASBR-ASBR link(s). If the ASBRs are connected by a single hop link, then they typically would not be running an IGP between them. Even when there are multiple hops between the ASBRs, although there would be some IGP running between the ASBRs; the TE information for the ASBR-ASBR links is not usually available. Also, the two adjacent ASes could be running different IGPs. In order to make the ASBR-ASBR links available in the local ASBR TE database, so that the ASBR can use these links in CSPF computation, some additional IGP configuration may be required on the ASBRs, so that links to an LSR may be added to the TED without having any real IGP adjacency with that LSR on those links. Also, in order to make the ASBR-ASBR links available in the TE database of the IGPs running in the adjacent ASes, so that the CSPF path computations in those ASes take into account these links, the IGPs MUST also advertise the TE information for these links into the corresponding IGP TE databases. The details of how exactly this is achieved is seen to be implementation specific and will not be discussed here. If the TE information for the ASBR-ASBR links is not available on the ASBRs, then the ASBRs cannot perform any CSPF computations and any path that the TE LSP takes between the ASBRs (including bypass tunnels, detours) SHOULD be configured as a set of strict interface hops. If the TE information of the ASBR-ASBR links is not advertised, then an entry ASBR can compute the TE LSP path only upto the next exit ASBR in it's own AS (instead of being able to compute a path upto the Ayyangar, Vasseur Standards Track [Page 9] Internet Draft Inter-region MPLS Traffic Engineering June 2003 next entry ASBR in the next-hop AS). While the solution does not mandate the flooding of TE information for basic operation; it is preferable to do so. Also, this solution requires an ASBR to support RSVP-TE signaling in case it is participating in inter-AS TE LSP setup. In the above topology, for an LSP setup from CE1 to CE2, the FA- LSPs/LSP segments may be setup between C-D and potentially E-F. The Path message in this case traverses along CE1-A-B-C-D-E-F-CE2. In the RRO sent in the Resv message, the ASBRs which are ingress into the AS (like C, E, C', E') can record the interface address corresponding to the ASBR-ASBR link in the RRO. Between the ASBRs regular RSVP-TE signaling procedures are carried out. In case the ASBRs (say B and C) are more than one hop away, then instead of creating RSVP state for every inter-AS LSP traversing B and C; one MAY decided to aggregate these requests by setting up a FA-LSP between the ASBRs to nest the inter-AS LSP requests. As per the definition in 4.1, boundary LSR B, by default is not a candidate to initiate a FA-LSP or LSP segment setup. But this behavior MAY be overridden by configuration. In this case, the zone between the ASBRs is treated as another region. 5. Nesting versus Stitching at region boundaries An LSR at the region boundary, may either 'nest' several inter-region LSPs into a single intra-region FA-LSP, or it may choose to split the inter-region LSP and insert an intra-region LSP segment into the split. We refer to the latter action as 'stitching' in this document. Stitching may be done either due to a local configuration or due to technology (e.g., wavelength LSPs). While a boundary LSR in one region may choose to stitch, a boundary LSR in another region could choose to nest. e.g. one may choose to nest the inter-area LSPs and stitch the inter-AS LSPs or vice versa. This can be decided based on various factors like the expected number of transit LSPs, the source and destination of such LSPs, interoperability requirements; etc. E.g. when the Path message for the inter-region LSP arrives at the boundary LSR in the destination region, it MAY choose not to nest that LSP request into an intra-region FA-LSP. Instead it may decide to stitch. This may be desired if one does not expect many LSP requests headed to the same destination in that region. Since it is more scalable and more suitable to most packet-switched networks, nesting will be the prefered default behavior within a region. If, however, the region boundary LSR has to do one-to-one stitching, then it MUST indicate this in the Path message for the LSP Ayyangar, Vasseur Standards Track [Page 10] Internet Draft Inter-region MPLS Traffic Engineering June 2003 segment. This signaling is needed so that the egress LSR for the LSP segment knows in advance, how the ingress for the LSP segment plans to map traffic on to the LSP segment. This will allow it to allocate the correct label(s) as explained below. In order to indicate LSP stitching we define a new flag in the LSP_ATTRIBUTE object defined in [INTER-AS]: 0x04: LSP stitching required This flag will be set in the LSP_ATTRIBUTE object in the Path message for the LSP segment by the source of the LSP segment which is the region boundary LSR. This flag SHOULD not be modified by any LSRs in between. If the egress LSR for the LSP segment does not understand this flag then it will simply ignore it. If the LSR cannot support stitching behavior, then it MUST send back a PathErr message with an error code of "Routing Problem" and an error sub-code=16 "Stitching unsupported" to the head-end of the LSP segment. An egress LSR receiving a Path message with this flag set, MUST allocate a non-NULL label for that LSP. Also, when this LSR receives a Path message for an inter-region LSP using this LSP segment, it SHOULD allocate a NULL label in the Resv message for that inter- region LSP. An ingress LSR stitching an inter-region LSP to an LSP segment MUST ignore any Label received in the Resv for the inter-region LSP. Example: In case of inter-AS LSP setup from CE1 to CE2 as described in 4.3, let us assume that the ASBR C is doing one-to-one LSP stitching as described above. So when C receives the inter-AS LSP Path message, it will first initiate the setup of the intra-region LSP segment to D. In the Path message for this LSP segment C will set the "LSP stitching required" flag in the LSP_ATTRIBUTE object. When D receives this Path message, D will allocate a real label (non-NULL) in the Resv message for this LSP segment. Once the LSP segment is signaled successfully, C will then forward the Path message for the inter-AS LSP to D which propagates it further. Eventually as the Resv message for the inter-AS LSP traverses back from E to D and reaches D, D will remember to swap the LSP segment label with the label received for inter-AS LSP from E. Also, D will itself allocate a NULL label in the Resv message for the inter-AS LSP and sends the Resv message to C. C ignores the Label object in the Resv message received from D for the inter-AS LSP and remembers to swap the label that it allocates in the inter-AS Resv message sent to B with the label that it had received from say LSR R2 for the intra-AS LSP segment. In this manner, the inter-AS LSP is stitched to an LSP segment in AS2. Ayyangar, Vasseur Standards Track [Page 11] Internet Draft Inter-region MPLS Traffic Engineering June 2003 6. Fast Recovery support using MPLS TE Fast Reroute [FAST-REROUTE] describes two methods for local protection for a TE LSP in case of node or link failure. This section describes how these mechanisms work with the proposed solution for inter-region LSP setup. Most of the behavior described in the above Fast Reroute document is directly applicable to the inter-region TE LSP setup case. When a FA-LSP or LSP segment is setup a priori it's local protection scheme SHOULD be pre-decided; if it is signaled dynamically then the desired protection scheme MAY be derived from the inter-region LSP. 6.1. Failure within a region (link or node failure) In case of any failure affecting a FA-LSP or LSP segment, the existing local protection procedures for recovery are applicable directly and will take care of protecting the FA-LSP/LSP segment without requiring any extensions. The failure notification (RSVP Path Error/Notify message "Tunnel Locally Repaired") for the FA-LSP/LSP segment MAY be sent directly to the respective ingress LSR for that FA-LSP/LSP segment in that region. If the ingress LSR for the FA- LSP/LSP segment can re-route the FA-LSP/LSP segment around the failure, then the inter-region LSPs using the FA-LSP/LSP segment will automatically be switched to the new path. In case the failure cannot be handled locally in that region by re-routing; and the FA-LSP or LSP segment fails, only then a PathErr for the affected inter-region LSPs will be propagated to the HE LSRs for those inter-region LSPs. Alternatively, one could choose to always send back PathErrs to the HE LSR in the originating region. Whether failures are always propagated all the way back to the ingress or we do a two-phase approach for handling the failures, could be a local policy decision. Also, no matter which LSR handles the failure, the LSP SHOULD be re- routed around the failure using the "make-before-break" approach. Example: In case of the inter-AS TE LSP setup described in 4.3, let us assume that the FA-LSP/LSP segment traverses R2 in AS2, and is node-protected against the failure of R2. In that case, when R2 or the corresponding link to R2 fails, then the traffic will be locally protected by the corresponding detour or backup path (depending on the local protection scheme) associated with the protected FA-LSP/LSP segment. When the PathErr/Notify message "Tunnel Locally Repaired" reaches C, C may find a new path for the FA-LSP/LSP segment and signal it. During this time, the FA-LSP/LSP segment along the old path was locally repaired and so traffic will continue undisrupted. Once the new path for the FA-LSP/LSP segment is successfully signaled the traffic is switched to the new path and the old path is torn down. Now whether the PathErr/Notify message "Tunnel locally Repaired" is forwarded upstream to the HE LSR of the inter-region LSP Ayyangar, Vasseur Standards Track [Page 12] Internet Draft Inter-region MPLS Traffic Engineering June 2003 could be a local policy decision. 6.2. Failure of link at region boundaries (ASBR-ASBR) In the above example for inter-AS LSP setup, let us consider the failure of link B-C. The LSPs traversing these links are the inter- region LSPs. Depending on the type of local protection desired, B which is the PLR will have either a bypass tunnel or a detour along a path disjoint from link B-C. In order to protect the inter-region LSP(s) from a B-C link failure, a NHOP bypass tunnel (if the "facility backup" method is used) or a set of detours (one for every inter-region protect TE LSP) MUST be pre-configured at B. Since the zone between the ASBRs is not usually TE-enabled, it would usually not be possible for the ASBR to compute a complete path around the protected link B-C. So backup paths with strict ERO configuration must be configured. If, however, the ASBRs do have the TE-information for the ASBR-ASBR links, then depending on the topology, a minimum path configuration specifying the loose hops may suffice. So, in either case, the PLR would select the bypass tunnel or detour for a protect TE LSP, terminating at the NHOP. The NHOP is determined by looking at the RRO object received in the Resv for the protected inter-region TE LSP. e.g. B will select a bypass tunnel terminating on C by looking at the RRO at B which would be C-D-E-F or -D-E-F. Also, the node where the backup intersects the protected LSP (MP : Merge Point) may either be reachable directly from the PLR or it may reside in the other AS. e.g. the bypass could either take path B- B'-C'-C in which case the MP is C itself or the MP may also be D if the only available bypass tunnel path is B-B'-C'-D-C. Therefore, mechanisms like 'automatic discovery' of next-hop LSR and partial CSPF computation to the first reachable LSR may also be applicable to the backup path computation. In this solution, the MP for the inter-region LSP will always be a region boundary LSR. This is because, the FA-LSP/LSP segment is a different LSP (different session) from the inter-region LSP, so the inter-region LSP backup can only intersect the main LSP path at the region boundary LSRs. 6.3. Failure of node at region boundary Let us again consider the example topology in 4.3 for inter-As LSP setup. This gives rise to the following scenarios for protection: Ayyangar, Vasseur Standards Track [Page 13] Internet Draft Inter-region MPLS Traffic Engineering June 2003 6.3.1. Protecting the last hop boundary LSR (ASBR) in a region Example: protecting against failure of node D in AS2. Considering the FA-LSP/LSP segment terminating at D, this is the last hop for the FA-LSP/LSP segment, so there can be no node-protection for D via the FA-LSP/LSP segment. However, as far as the inter-region LSP is concerned, it's path is along A-B-C-D-E-F and the FA-LSP/LSP segment between C and D is a link. So for protecting against D's failure, C is the PLR and C will setup a bypass tunnel to the NNHOP for this LSP, which is E. Again the NNHOP is determined by examining the received RRO for the inter-region LSP. So one or more bypass tunnels following C-D'-E must be configured on C to protect against node D's failure. It is worth mentioning that this may add some additional constraints on the backup path since the bypass tunnel path needs to be diverse from the C-D-E path instead of just being diverse from the X-D-E path where X is the upstream neighbor of D. The consequences are that the path is likely to be longer and if bandwidth protection is desired for instance ([FACILITY-BACKUP] more resources may be reserved in AS2 than necessary. 6.3.2. Protecting against the LSR at the entry to the region Example: protecting against the failure of LSR C in AS2. Again, in this case, the FA-LSP/LSP segment offers no protection; so one or more backups MUST be configured from the previous hop LSR in the inter-region LSP, i.e. B, to the NNHOP with respect to the inter- region LSP, i.e. D. A bypass tunnel B-B'-C'-D would protect against C's failure. Depending on whether discovery mechanisms are available, and whether TE-information for ASBR-ASBR links is available, the configuration required on the PLR for the backup could be minimal or could require specifying the entire path. The same constraints as mentioned above applies in this case. When the FA-LSP/LSP Segment is unnumbered, the Router ID of the boundary LSR will be recorded in the RRO object (see [RSVP-UNNUM]). However, if the FA-LSP/LSP segment is numbered, then bypass tunnel selection to protect an inter-region TE LSP with Fast Reroute "facility backup" ([FAST-REROUTE]) against the failure of an ASBR- ASBR link or an ASBR node would require the support of [NODE-ID]. Ayyangar, Vasseur Standards Track [Page 14] Internet Draft Inter-region MPLS Traffic Engineering June 2003 7. Re-optimization of inter-region LSPs In this solution, re-optimization is treated as a local matter to a particular region. Since the inter-region LSPs traverse FA-LSPs/LSP segments across the region, optimality of the inter-region LSPs in a region is dependent on the optimality of the corresponding FA- LSPs/LSP segments. If after an inter-region LSP is setup, a more optimal path is available within a region; the corresponding FA- LSP(s)/LSP segment(s) would be re-optimized using "make-before-break" techniques discussed in [RSVP-TE]. Re-optimization of the FA-LSP/LSP segment automatically re-optimizes the inter-region LSP that the FA- LSP/LSP segment transports. Re-optimization parameters like frequency of re-optimization, criteria for re-optimization like metric or bandwidth availability; etc can vary from one region to another and can be configured as required, per FA-LSP/LSP segment if it is pre- configured or based on some global policy within the region. So, in this scheme, since each region has its own FA-LSPs/LSP segments, the make-before-break can happen locally and is not triggered by the head-end LSR for the inter-region LSP. So, no additional RSVP signaling is required for LSP re-optimization and reoptimization is transparent to the HE LSR. If, however, an operator desires to manually trigger re-optimization at the HE LSR for the inter-region LSP, then this solution does not prevent that. A manual trigger for re-optimization at the HE LSR, SHOULD force a re-optimization thereby signaling a "new" path for the same LSP (along the optimal path) making use of the make-before-break procedure. In response to this new setup request, the boundary LSR may either initiate new LSP segment setup, in case the inter-region TE LSP is being stitched to the intra-region LSP segment or it may select an existing FA-LSP in case of nesting. When the LSP setup along the current optimal path is complete, the head end should switchover the traffic onto that path and the old path is eventually torn down. Note that the HE LSR does not know a priori whether a more optimal path exists. Such a manual trigger is, however, not considered to be a frequent occurrence. Ayyangar, Vasseur Standards Track [Page 15] Internet Draft Inter-region MPLS Traffic Engineering June 2003 8. Specific requirements for inter-AS TE LSP setup In this section, we discuss the solution in light of some of the requirements specific to inter-AS traffic engineering as listed in [INTER-AS-TE-REQTS]. This covers the Inter-AS TE requirements for a single SP administrative domain as well as across multiple SP administrative domains. Some of the requirements may have be already been covered in previous sections and will not be discussed here again. 8.1. Support of diversely routed inter-region TE LSP There may be a need to support diversely routed paths for an LSP, either for path protection or load balancing. RRO plays an important role in determining the path along which the LSP traverses. In case of an intra-area TE LSP, today this tells us the "links" traversed by a path. This information is used to compute other disjoint paths by excluding the above links in CSPF path computation. One must just mention that this method (also called "2 steps approach") does not always guarranty to find two diverse paths even if such paths exist. Also this simple algorithm does not allow to find two paths such that the sum of their cost is minimal. In case of an inter-region path setup, it is important to note that CSPF computation may be distributed over different LSRs and also the path represented by the RRO, need not represent physical links, they could be other FA- LSPs/LSP segments. e.g in 4.1 let us assume that the primary path for the LSP from A to D takes A-B-C-D. So a diverse path for this LSP may be signaled as A-B'-C'-D. The information for links to "exclude" could be signaled as specified in [RSVP-CONSTRAINTS] as a constraint. 8.2. Inter-AS MPLS TE Management The failure detection and isolation mechanisms proposed by [LSPING] can be applied to inter-AS TE management as well. This solution does not present any issues for support of either [LSPING] or [MPLS-TTL]. 8.3. Confidentiality As mentioned in [INTER-AS-TE-REQTS], an inter-AS LSP can cross different AS boundaries. This solution does not require another region (AS) to expose any of its local addresses within the AS to another AS for any signaling needs. Even for local protection using Fast-Reroute no special requirements are imposed on the nodes within the AS to expose their addresses. This was discussed under Section 6. Ayyangar, Vasseur Standards Track [Page 16] Internet Draft Inter-region MPLS Traffic Engineering June 2003 8.4. Policy Control at the AS boundaries Since this solution is based on per region FA-LSP/LSP segment based approach, it inherently provides more control to an SP in setting up FA-LSPs/LSP segments and deciding their attributes within his AS. Other than that, as stated in [INTER-AS-TE-REQTS], there may be other inter-AS TE agreements made with other ASes and implemented as local policy on the ASBR. Among other behaviors stated in the above document, mapping of constraints and other attributes from the inter- region LSP to the intra-region FA-LSP/LSP segment, nesting versus stitching behavior, overriding the default ASBR behavior with respect to signaling of FA-LSP/LSP segment; etc can also be exercised based on local policy configuration. 8.5. Scalability and Extensibility This draft provides a common solution to be used for LSPs traversing regions of different types and hence can be used not only for inter- area and inter-AS TE, but also for setting up LSP paths across GMPLS overlay regions. The solution adopts a scalable approach based on LSP hierarchy, to aggregate several inter-region LSP requests onto a few intra-region FA-LSPs, thereby reducing the control state belonging to the transit LSPs within the region. 9. Security Considerations This document raises no new security concerns for RSVP. Existing security features can be used for signaling inter-region TE LSPs. 10. Intellectual Property Considerations Juniper Networks and Cisco Systems may have intellectual property rights claimed in regard to some of the specification contained in this document. Ayyangar, Vasseur Standards Track [Page 17] Internet Draft Inter-region MPLS Traffic Engineering June 2003 11. Acknowledgements Many thanks to Yakov Rekhter, Kireeti Kompella, Pedro Marques and Ina Minei for their initial discussions which contributed to the solution proposed in the draft. We would also like to thank Yakov Rekhter and Kireeti Kompella for their useful comments and suggestions towards the draft. 12. References [LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, March 2002. [GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay Model", draft-ietf-ccamp-gmpls-overlay-01.txt, February 2003. [INTER-AREA] Kompella et al, "MPLS Inter-area Traffic Engineering", draft-mpls-kompella-multiarea-te-03.txt. [INTER-AS-TE-REQTS] Zhang et al, "MPLS Inter-AS Traffic Engineering requirements", draft-ietf-tewg-mpls-te-req.00.txt, May 2003. [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RSVP-UNNUM] Kompella K., Rekhter Y., "Signalling Unnumbered Links in RSVP-TE", RFC 3477, January 2003. [INTER-AS] Vasseur, Zhang, "Inter-AS MPLS Traffic Engineering", draft-vasseur-inter-as-te-01.txt, June 2003. [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. [NODE-ID] Vasseur, Ali and Sivabalan,"Definition of an RRO node-id subobject", draft-ieft-mpls-nodeid-subobject-01.txt, May 2003. [FACILITY-BACKUP] Vasseur et al, "MPLS Traffic Engineering Fast reroute: bypass tunnel path computation for bandwidth protection", draft-vasseur-mpls-backup-computation, work in progress. [RSVP-CONSTRAINTS] Kompella, K., "Carrying Constraints in RSVP", draft-kompella-mpls-rsvp-constraints-00.txt, work in progress. [LSPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G., Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS", Ayyangar, Vasseur Standards Track [Page 18] Internet Draft Inter-region MPLS Traffic Engineering June 2003 Internet Draft , October 2002. [MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS Networks", RFC 3443 Updates RFC 3032) ", January 2003. 13. Author Information Arthi Ayyangar Juniper Networks, Inc. 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA e-mail: arthi@juniper.net Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA email: jpv@cisco.com 14. Full Copyright Notice 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 Ayyangar, Vasseur Standards Track [Page 19] Internet Draft Inter-region MPLS Traffic Engineering June 2003 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." 15. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Ayyangar, Vasseur Standards Track [Page 20]