IETF Internet Draft Arthi Ayyangar(Editor)Network Working Group A. Farrel Proposed Status: Standards Track Juniper NetworksOld Dog Consulting Updates: RFC 3209, RFC 3473 Expires: September 2006 Jean-Philippe Vasseur(Editor)July 2007 A. Ayyangar Nuova Systems JP. Vasseur Cisco Systems, Inc. January 2007 Inter domain MPLS and GMPLS Traffic Engineering - RSVP-TE extensions draft-ietf-ccamp-inter-domain-rsvp-te-03.txtdraft-ietf-ccamp-inter-domain-rsvp-te-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on September 6, 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved.Abstract This document describes procedures and protocol extensions to Generalized Multi-Protocol Label Switching (GMPLS)for the use of Resource ReserVation Protocol -Traffic Engineering (RSVP-TE) signaling requiredin Multiprotocol Label Switching Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support mechanisms forthe establishment and maintenance of GMPLS Traffic Engineering (TE)Label Switched Paths (LSPs), both packet and non-packet,that traverse multiple domains.cross domain boundaries. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, IGP areasrouting areas, and GMPLS overlay networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 32 1.1 Conventions used in this documentUsed In This Document . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Signaling overviewOverview . . . . . . . . . . . . . . . . . . . . . 4 2.1 Signaling optionsOptions . . . . . . . . . . . . . . . . . . . . 4 3. Procedures on the domain boundary nodeDomain Border Node . . . . . . . . . . . . . 5 3.1 Rules on ERO processingProcessing . . . . . . . . . . . . . . . . . 6 3.2 LSP setup failureSetup Failure and crankbackCrankback . . . . . . . . . . . . . 8 3.3 RRO processing across domainsProcessing Across Domains . . . . . . . . . . . . . . 8 3.4 Notify Message Processing . . . . . . . . . . . . . . . . 9 4. RSVP-TE signaling extensionsSignaling Extensions . . . . . . . . . . . . . . . . . 9 4.1 Control of downstream choiceDownstream Choice of signaling methodSignaling Method . . . . . 9 5. Protection and recoveryRecovery of inter-domainInter-Domain TE LSPs . . . . . . . 1110 5.1 Fast Recovery support using MPLS TESupport Using MPLS-TE Fast Reroute . . . . . 11 5.1.1 Failure withinWithin a domain (linkDomain (Link or node failure)Node Failure) . . . . 11 5.1.2 Failure of linkLink at domain boundariesDomain Borders . . . . . . . . . . 11 5.1.3 Failure of a boundary nodeBorder Node . . . . . . . . . . . . . . . 12 5.2 Protection and recoveryRecovery of GMPLS LSPs . . . . . . . . . . 1312 6. Re-optimizationRe-Optimization of inter-domainInter-Domain TE LSPs . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 1413 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 1514 8.1 Attribute Flags for LSP_ATTRIBUTES objectLSP_Attributes Object . . . . . . . . 15 8.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 1615 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 1615 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 1615 10.1 Normative References . . . . . . . . . . . . . . . . . . 1615 10.2 Informative References . . . . . . . . . . . . . . . . . 17 Appendix 1: Examples . . . . . . . . . . . . . . . . . . . . . . 1816 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . 2317 1. Introduction The requirements for inter-area and inter-AS MPLS Traffic Engineering have been developed by theMultiprotocol Label Switching (MPLS) Traffic Engineering Working Group and have been(TE) are stated in [INTER-AREA-TE-REQS][RFC4105] and [INTER-AS-TE-REQS][RFC4216] respectively. Many of these requirements also apply to GMPLSGeneralized MPLS (GMPLS) networks. The framework for inter-domain GMPLS Traffic Engineering has beenMPLS-TE is provided in [INTER-DOMAIN-FRAMEWORK]. This document presents the RSVP-TE signalingprocedures and extensions to Resource Reservation Protocol Traffic Engineering (RSVP-TE) signaling for the setup and maintenance of TE LSPstraffic engineered Label Switched Paths (TE LSPs) that span multiple domains. The signaling proceduresdomains in MPLS-TE or GMPLS networks. The signaling procedures described in this document are applicable to both MPLSMPLS-TE packet LSPs ([RSVP-TE])established using RSVP-TE ([RFC3209]) and all LSPs (packet and non-packet) that use RSVP-TE GMPLS extensions as described in [RSVP-GMPLS].[RFC3473]. Three different signaling methods along with the correspondingfor inter-domain RSVP-TE extensions andsignaling are identified in [INTER-DOMAIN-FRAMEWORK]. Contiguous LSPs are achieved using the procedures of [RFC3209] and [RFC3473] to create a single end-to-end LSP that spans all domains. Nested LSPs are proposedestablished using the techniques described in this document.[RFC4206] to carry the end-to-end LSP in a separate tunnel across each domain. Stitched LSPs are established using the procedures of [LSP-STITCHING] to construct an end-to-end LSP from the concatenation of separate LSPs each spanning a domain. This document defines the RSVP-TE protocol extensions necessary to control and select which of the three signaling mechanisms is used for any one end-to-end inter-domain TE LSP. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, IGP areasareas, and GMPLS overlay networks ([GMPLS- OVERLAY]).([RFC4208]). 1.1. Conventions used in this documentUsed 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]. 1.2. Terminology AS: Autonomous System. ASBR: routers used to connect together ASes of a different or the same Service Provider via one or more Inter-AS links. Bypass Tunnel: an LSP that is used to protect a set of LSPs passing over a common facility. ERO: Explicit Route Object H-LSP: Hierarchical LSP FA-LSP:Object. FA: Forwarding Adjacency LSP LSP: MPLSAdjacency. LSR: Label Switched PathSwitching Router. MP: Merge Point. The node 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. PLR: Point of Local Repair. The head-endingress of a bypass tunnel. 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. RRO -RRO: Record Route Object TE: Traffic Engineering TE LSP: Traffic Engineering Label Switched PathObject. TE link: Traffic Engineering link TED: MPLS Traffic Engineering Databaselink. 2. Signaling overviewOverview The RSVP-TE signaling of a TE LSP within a single domain is described in [RSVP-TE][RFC3209] and [RSVP-GMPLS].[RFC3473]. Inter-domain TE LSPs can be supported by one of three options as described in the next section: - contiguous LSPs - nested LSPs - stitched LSPs. This document focuses ondescribes the RSVP-TE signaling extensions required to control and select which of the three signaling mechanisms is used for any one end-to-end inter-domain TE LSP. The specific protocol extensions required to signal each LSP setup and maintenance. Anytype are described in other extensions that may be neededdocuments and are out of scope for this document. Similarly, the routing orextensions and path computation are outsidetechniques necessary for the scopeestablishment of this document.inter-domain LSPs are out of scope. 2.1. Signaling optionsOptions There are three ways in which an RSVP-TE LSP could be signaled across multiple domains: Contiguous -A contiguous TE LSP is a single end-to-end TE LSP that is setupset up across multiple domains using RSVP-TE signaling procedures described in [RSVP-TE][RFC3209] and [RSVP-GMPLS].[RFC3473]. No additional TE LSPs are required to signalcreate a contiguous TE LSP and the same RSVP-TE information for the TE LSP is maintained along the entire LSP path. Nesting - Nesting one orIn particular, the TE LSP has the same RSVP-TE session and LSP ID at every LSR along its path. Nesting One or more TE LSPs intomay be nested within another TE LSP isas described in [LSP-HIERARCHY].[RFC4206]. This technique can be used to nest one or more inter-domain TE LSPs into an intra-domain hierarchical LSP (H-LSP). LabelThe label stacking construct may beis used to achieve nesting, when appropriate, saynesting in packet networks. In the rest of this document, the term H-LSP is used to refer to an LSP that allows nesting ofother LSPs into it and that may orto be nested within it. An H-LSP may notbe advertised as a TE link. Furthermore, an H-LSP may or may not be an FA-LSP [LSP- HIERARCHY].link within the same instance of the routing protocol as was used to advertise the TE links from which it was created, in which case it is a Forwarding Adjacency (FA) [RFC4206]. Stitching -The concept of LSP stitching as well as the required signaling procedures is described in [LSP-STITCHING]. This technique can be used to stitch together shorter LSPs (LSP segments) to create a single, longer LSP. The LSP segments of an inter-domain TELSP to anmay be intra-domain LSP segment. ALSPs or inter-domain stitched TE LSP is a TE LSP made upLSPs. The process of different TE LSP segments within each domain which are "stitched" togetherstitching in the data plane so that anresults in a single, end-to-end LSP is achievedcontiguous LSP. But in the data plane. In thecontrol plane, however, the different LSP segments areplane each segment is signaled as a separate LSP (with distinct RSVP sessions which are independent fromsessions) and the end-to-end LSP is signaled as yet another LSP with its own RSVP session forsession. Thus the inter-domain LSP. Whilecontrol plane operation for LSP stitching is very similar to nesting in the control plane, in the data plane, stitching allowsthat for only onenesting. An end-to-end inter-domain TE LSP tomay be associated with anyachieved using one intra-domain LSP, and does not requireor more of the usesignaling techniques described. The choice is a matter of label stacks.policy for the node requesting LSP setup (the ingress) and policy for each successive domain border node. On receipt of an LSP setup request (RSVP-TE Path message) for an inter-domain TE LSP, the decision of whether to signal the LSP contiguously or whether to nest or stitch it to another TE LSP, depends on the parameters signaled TE LSP characteristicsfrom the head-endingress node orand on the local node configuration, when not explicitly signaled. Also,configuration of the TE LSPlocal node. The stitching segment LSP or H-LSP within the domain may eitherused to cross a domain may be pre-configuredpre-established or signaled dynamically based on the demand caused by the arrival of the inter-domain TE LSP setup request. 3. Procedures on the domain boundary nodeDomain Border Node Whether an inter-domain TE LSP is contiguous, nestednested, or stitched is determined mostlylimited by the signaling methodmethods supported by or configured on the intermediate nodes, and it is usually the domain boundaryborder nodes thatwhere this restriction applies since other transit nodes are oblivious to the mechanism in use. The ingress of the inter-domain TELSP traverses. It also depends on certain parameters thatmay be signaled byfurther restrict the head-end node forchoice by setting parameters in the inter-domain TE LSP.Path message when it is signaled. When a domain boundaryborder node receives the RSVP Path message for an inter-domain TE LSP setup, it MUST carry out the following procedures before it can forward the Path message to the next node along the path: 1. Apply any locally configured policies.policies for the domain and the domain border node. These policies may restrict the establishment of inter-domain TE LSPs. In case of a policy failure, the node SHOULD fail the setup of the LSPand originatesend a PathErr message with error code=2 ("Policycode "Policy control failure") and error sub-code="Inter-domainfailure"/ "Inter-domain policy failure" (TBD).failure". 2. Determine the signaling method to be used. The head-endused to cross the domain. If the ingress node of the inter-domain TE LSP may have explicitlyhas specified a signaling method or ifrestrictions on the signaling method is not explicitly signaled, thenmethods to be used, these MUST be adhered to. Within the freedom allowed by the ingress node, the domain border node MAY determine the signalingchoose any method based onaccording to local configuration and policies. If the desiredno resultant signaling method signaled byis available or allowed, the head-end cannot be supported at thisdomain border node for some reason, thenMUST send a PathErr message an error code as described in Section 4.1 MUST be generated.4.1. 3. Carry out ERO procedures as described in the next sectionSection 3 in addition to the procedures in [RSVP-TE][RFC3209] and [RSVP-GMPLS].[RFC3473]. 4. Perform any path computations as required (say for ERO expansion).to determine the path across the domain and potentially to select the exit point from the domain. The path computation procedure itselfis outside the scope of this document. One suchA path computation option is addressedsupplied in [INTER-DOMAIN-PD-PATH-COMP]. Another[INTER-DOMAIN-PD-PATH-COMP], and another option is to use a Path Computation Element (PCE) ([PCE]) for path computation. Path computation may itself involve determining the exit point from the TE domain ([INTER-DOMAIN-PD-PATH-COMP]).[RFC4655]. 4a. In the case of nesting or stitching, either find an existing intra-domain TE LSP to carry the inter-domain TE LSP or signal a new one, depending on local policy. 4b.In caseevent of a path computation failure, a PathErr message SHOULD be generated as described in [INTER-DOMAIN-PD-PATH-COMP]. 5.sent with error code "Routing Problem" using an error value selected according to the reason for computation failure. In casethe event of any other RSVPthe receipt of a PathErr message reporting signaling failures,failure from within the domain or reported from a downstream domain, the domain border node MAY apply crankback procedures as described in [RSVP-TE] and [RSVP-GMPLS] SHOULD be followed. Follow procedures related to LSP setup failure andSection 3.2. If crankback is not applied, or is exhausted, the border node MUST continue with PathErr processing as described in Section 3.2, where applicable. 6. Carry[RFC3209] and [RFC3473]. In the event of successful processing of a Path or Resv message, the domain border node MUST carry out RRO procedures as described in Section 3.3, if applicable.3.3. 3.1. Rules on ERO processingProcessing The ERO that a domain boundaryborder node receives in the Path message for an inter-domainwas supplied by the ingress node of the TE LSP will be dependentand may have been updated by other nodes (for example, other domain border nodes) as the Path message was propagated. The content of the ERO depends on several factors such asincluding: - the level of visibility thatpath computation techniques used - the head-end nodedegree of the inter-domainTE LSP has into other domains,visibility available to the nodes performing path computation techniques applied- policy at the head-end node, policy agreementsnodes creating/modifying the ERO. In general, H-LSPs and LSP segments are used between two domains; etc. Eventually, whendomain border nodes, but there is no restriction on the ERO reachesuse of such LSPs to span multiple hops entirely within a domain. Therefore, the discussion that follows may be equally applied to any node within a domain although the term 'domain border node' continues to be used for clarity. When a Path message reaches the domain boundaryborder node, the following rules SHOULD be used for ERO processing and for further signaling. Within a domain, there may be no H-LSPs or LSP segments. If they are present, then they may originate and terminate on domain boundary nodes. There could also be H-LSPs and LSP segments that may originate and terminate at other nodes in the domain. In general, these ERO processing rules are also applicable to non-boundary nodes that may participate in signaling the inter-domain TE LSP.1. If there are any policies related to ERO processing for the LSP, they SHOULD be applied and corresponding actions should betaken. E.g.For example, there could existmight be a policy to reject inter-domain LSP setup request containing an ERO with subobjects identifyingEROs that identify nodes within the domain. In case of inter-domain LSP setup failures due to policy failures related to ERO processing, the node SHOULD issue a PathErr with error code=2 ("Policycode "Policy control failure") and error sub-code="Inter-domainfailure"/"Inter-domain explicit route rejected" (TBD).rejected". 2. Section 8.2 of [LSP-HIERARCHY][RFC4206] describes how a node at the edge of a region (domain)processes the ERO in the incoming Path message and uses this ERO, to either find an existing H-LSP or signal a new H-LSP using the ERO hops. This alsoprocess includes adjusting the ERO before sending the Path message to the next hop node.hop. These procedures SHOULD alsobe followed for nesting or stitching of inter-domain TE LSPs to H-LSPs or LSP segments respectively. While the domain boundaries are tied to link switching capabilities in [LSP-HIERARCHY], these procedures are also applicable to other domain boundary nodes in the context of this document.LSPs. 3. If thean ERO subobject identifies a TE link formed by athe advertisement of an H-LSP or LSP segment within the domain, either(whether numbered or unnumbered, then aunnumbered), contiguous LSPsignaling MUST NOT be signaled.used. The node MUST either nestuse nesting or stitch the inter-domain TE LSPstitching according to the local H-LSP or LSP segment. If, however, the head-end node forcapabilities of the inter-domainLSP has requestedthat forms the inter-domainTE LSP be contiguous, then thislink, the parameters signaled in the Path message, and local policy. If there is a conflict between the capabilities of the LSP that forms the TE link indicated in the ERO and the parameters on the Path message, the domain border node SHOULD send a PathErr with error code=24 ("Routing Problem") and error sub-code="EROcode "Routing Problem"/"ERO conflicts with inter-domain signaling method" (TBD) SHOULD be issued.method". 4. In the absence of anyAn ERO subobjects, the LSP destinationin the SESSION object SHOULD be considereda Path message received by a domain border node may have a loose hop as the next loosehop. A nodeThis may also receivebe an ERO with explicit IPv4, IPv6IP address or an AS number loose hops.number. In such cases, athe ERO MUST be expanded to determine the path computationto expand this loosethe next hop SHOULD be carried out. Path computation as described in [INTER-DOMAIN-PD-PATH-COMP] orusing a PCE should be used to expandsome form of path computation that may, itself, generate loose hops. 5. In the absence of any ERO subobjects beyond the local domain border node, the LSP egress (the destination encoded in these cases and to determinethe intermediate hops. 5.RSVP Session object) MUST be considered as the next loose hop and rule 4 applied. 6. In casethe event of any other failures inprocessing the ERO hop(s),ERO, a PathErr message with appropriate error codesSHOULD be sent as described in [RSVP-TE][RFC3209] or [RSVP-GMPLS] SHOULD be generated.[RFC3473]. 3.2. LSP setup failureSetup Failure and crankback In case of anyCrankback When an error occurs during LSP setup failures alonga PathErr message is sent back towards the path dueLSP ingress node to policy or admission control or other reasons, a corresponding PathErr/ResvErr/Notify is generated and sent upstream and/or downstream. An ERROR_SPEC comprises of information regardingreport the point of failure (network element) and details aboutproblem. If the failure itself. When anLSP traverses multiple domains, a failure couldthis PathErr will be generated in anyseen successively by each domain along the path and an error notification may need to be propagated across multiple domains. So, an error notification message itself may be subjected toborder node. Domain border nodes MAY apply local policies as it traverses domain boundaries andto restrict the propagation of information about the contents of the domain. For example, a boundarydomain border node MAY modify domain specificreplace the information carriedin the error message. E.g. the errora PathErr message that indicates a specific failure at a specific node address inwith information that report a more general error with the RSVP ERROR_SPEC or IF_ID ERROR_SPEC orentire domain. These procedures are similar to those described for the Interface Identifierborders of overlay networks in IF_ID ERROR_SPEC may be modified at the boundary[RFC4208]. However: - A domain border node for confidentiality reasons.MUST NOT suppress the propagation of a PathErr message - Nodes other than domain boundaryborder nodes SHOULD NOT modify ERROR_SPEC contents. It is also RECOMMENDED that suchthe contents of a policy be implemented only on domain boundaryPathErr message - Domain border nodes for inter-domain LSPs where preservingSHOULD NOT modify the contents of a PathErr message unless domain confidentiality is a specific requirement. Also, in caseDomain border nodes provide an opportunity for crankback rerouting [CRANKBACK]. On receipt of a PathErr message generated because of an inter-domainLSP setup failure, there may be cases when the error is not propagated all the way upstream to the head-end node. A PathErr may be intercepted bya boundary node in thedomain in which the error is generated (or any otherborder node alongMAY hold the path)PathErr and this node may attempt to find an alternate path. Finding an alternate path means finding a new path downstreammake further attempts to establish the node performing re-routingLSP if allowed by local policy and avoidingby the failed network elements. This may involve finding a path within the domain experiencing the failure or it may mean finding new boundary node(s) or new downstream domain. Crankback re-routing depends not only on local configuration and ability of a boundary node to do local crankback re-routing, but also on any specificparameters requested by the head-end node itself for that LSP. In certain cases, it may be desirable for the head-end node to exert some controlsignaled on whether crankback re-routing at intermediate nodes is desirable or not. Procedures and extensions described in [CRANKBACK] should be followed for crankback re-routing. When crankback re-routing is allowed, a node along the TE LSP path may either decide to forwardthe PathErrPath message upstream towardsfor the head-end node ofLSP. Such attempts might involve the inter-domain TE LSP or try to determine ancomputation of alternate path aroundroutes through the failure. When crankback re-routing is not alloweddomain, or ifthe node cannot perform crankback re-routing, then, on receivingselection of different downstream domains. If a PathErr message,subsequent attempt is successful, the node should propagatedomain border router MUST discard the held PathErr message upstream. [RSVP-GMPLS] allows nodes to generate a targeted Notify message in addition to a PathErr/ResvErrmessage, to expedite error notification,but if a Notify Request has been received inall subsequent attempts are unsuccessful, the corresponding Path/Resv message. This is also applicable to inter-domain TE LSPs which implement [RSVP-GMPLS]. However, sinceborder router MUST send the PathErr and Notify need not followupstream toward the same path, their recepient nodes could be different. This has certain implications oningress node. In this latter case, the domain border router MAY change the information in the PathErr message to provide further crankback re-routing. Proceduresdetails and recommendationsinformation aggregation as described in [CRANKBACK] should[CRANKBACK]. Crankback rerouting MAY also be followed for Notify message processing for crankback re-routing.used to handle the failure of LSPs after they have been established [CRANKBACK]. 3.3. RRO processing across domains [RSVP-TE]Processing Across Domains [RFC3209] defines the RECORD_ROUTE object (RRO)RRO as an optional object, which is primarilyused for loop detection and for providing information about the hops traversed by LSPs. [FAST-REROUTE] also uses the RRO to record labels and determine MP. The address or ID recordedAs described for overlay networks in the RRO usually represents a link/interface. This information by itself may not be useful enough when LSPs traverse domains. [NODE-ID] defines extensions which allows[RFC4208], a domain border node to record its node ID inMAY filter or modify the RRO, to provideinformation provided in an additional context for the link address/ID. Note that there may also be cases while traversing administrative domain boundaries, where a network may not wish to expose its internal addresses/IDs to preserve confidentiality. In such casesRRO MAY be subjectedfor confidentiality reasons according to policies, filtering and modifications atlocal policy. For example, a series of identifiers of hops within a domain boundaries. Internal network element identities mayMAY be masked off andreplaced with boundary information orthe domain identifier (such as the AS information, bynumber) or be removed entirely leaving just the domain boundary entities. This isborder nodes. Note that a domain border router MUST NOT mask its own presence, and MUST include itself in the RRO. Such filtering of RRO information does not expected tohamper the working of the signaling protocol. This does, however, result inprotocol, but the subsequent information loss, thereby leading to inefficient pathsloss may render management diagnostic procedures inoperable or at least make them more complicated requiring the coordination of administrators of multiple domains. Similarly protocol procedures that depend on the presence of RRO information may become inefficient. For example, the fast reroute procedures defined in [RFC4090] use information in the RRO to determine the labels to use and the downstream MP. 3.4. Notify Message Processing Notify messages are introduced in [RFC3473]. They may be sent direct rather than hop-by-hop, and so may speed the propagation of error information. If a domain border router is interested in seeing such messages (for example, to enable it to provide protection switching), it is RECOMMENDED that the domain border router update the Notify Request objects in the Path and Resv messages to show its own address following the procedures of [RFC3473]. 4. RSVP-TE signaling extensionsSignaling Extensions The following RSVP-TE signaling extensions are introduced in this document.defined to enable inter-domain LSP setup. 4.1. Control of downstream choiceChoice of signaling methodSignaling Method In certain mixedmany network environments with different techniques (contiguous, stitched or nested TE LSPs),there may be a head-end nodenetwork-wide policy that determines which one of the three inter-domain TELSP techniques is used. In these cases, no protocol extensions are required. However, in environments that support more than one technique, an ingress node may wish to signal its requirement regarding the signaling method used at an intermediate node alongconstrain the path. [LSP-ATTRIBUTES]choice made by domain border nodes for each inter-domain TE LSP that it originates. [RFC4420] defines the formatLSP_Attributes object that can be used to signal required attributes of thean LSP. The Attributes Flags TLV included in the LSP_ATTRIBUTES object carried in an RSVP Path message. The followingincludes Boolean flags that define individual attributes. This document defines a new bit in the FlagsTLV is usedthat can be set by the head-endingress node of thean inter-domain TE LSP to restrict the signaling method used by theintermediate nodes to be contiguous. Bit Number 4 (TBD):using contiguous signaling. Contiguous LSP bit - this(bit number assignment in Section 8.1). This flag is set by the head-endingress node that originates thea Path message to set up an inter-domain TE LSP if it desires arequires that the contiguous end-to-end TELSP (intechnique is used. This flag bit is only to be used in the control & data plane).Attributes Flags TLV. When set, this indicates thatan intermediateLSR receives a Path message containing this bit set (one), the node MUST NOT perform anystitching or nesting on the TE LSP andin support of the TE LSP MUST be routed as any other TE LSP (it must be contiguous end to end).being set up. When this bit is cleared,clear (zero), an intermediate node MAY decide toperform stitching or nesting.nesting according to local policy. This bit MUST NOT be modified by any downstreamtransit node. An intermdediateintermediate node that supports the LSP_ATTRIBUTESLSP_Attributes object and the Attributes Flags TLV, and also recognizes the "Contiguous LSP" bit, but cannot support contiguous TE LSPLSPs, MUST send a Path Error message upstreamwith an error code=24 ("Routing Problem") and error sub- code="Contiguouscode "Routing Problem"/"Contiguous LSP type not supported" (TBD).if it receives a Path message with this bit set. If an intermediate node receiving a Path message with the "Contiguous LSP" bit set in the Flags field of the LSP_ATTRIBUTES,LSP_Attributes, recognizes the object, the TLV and the bit and also supports the desired contiguous LSP behavior, then it MUST signal a contiguous LSP and MUST setLSP. If the "Contiguous LSP signaled" bit innode is a domain border node, or if the Flags field ofnode expands a loose hop in the ERO, it SHOULD include an RRO Attributes subobject in the RRO of the corresponding Resv message.message with the "Contiguous LSP" bit set to report its behavior. However, if the intermediate node supports the LSP_ATTRIBUTESLSP_Attributes object but does not recognize the Attributes Flags TLV, or supports the TLV as well,but does not recognize this particular"Contiguous LSP" bit, then it SHOULD simply ignoreMUST reject the above request. It MAY signal any type of LSPPath message with a PathErr message as described in this case.[RFC4420]. The "Contiguous LSP signaled" bit in the Flags fieldchoice of the RRO Attributes SHOULD NOT be set. Anaction by an ingress node for an inter-domain LSP requestingthat receives a contiguous LSP SHOULD examine the RRO Attributes subobject Flags to determine if the LSP was indeed signaled contiguous end to end. If the "Contiguous LSP signaled" bit is cleared, the head end may take appropriate actions such as restrictingPathErr when requesting the typeuse of traffic that gets mapped to this LSP, tearing down the LSP, or rerouting the LSP around the nodes that do not support thea contiguous signaling; etc. Choice of action to be taken is upto the implementation on the ingress node and itLSP is out of the scope of this document to recommend any particular action.document, but may include the computation of an alternate path. 5. Protection and recoveryRecovery of inter-domainInter-Domain TE LSPs The procedures described in SectionSections 3 and 4 MUST be applied to all inter- domaininter-domain TE LSPs, including bypass tunnels, detour LSPs [FAST-REROUTE] or[RFC4090], and segment recovery LSPs [SEGMENT-PROTECTION] that may cross domains.[SEGMENT-PROTECTION]. This means that these LSPs will also be subjected to ERO processing, policies, path computation;computation, etc. Also, noteNote also that the explicit routepaths for these backup LSPs needs to be either configuredpre-configured, computed and signaled with the protected LSP, or computed on-demand at the PLR. Just likeas with any inter-domain TE LSP, depending on the visibility into the subsequent domain,the ERO may comprise of strict and/or loose hops. So, if there areor loose hops, backup LSPs would also need to undergo loose hop expansion at nodes other thanand will depend on the PLR. So,TE visibility of the PLRcomputation point into the subsequent domain. If loose hops are required created in this case needs to signalthe node or link that needs to be excluded for backup computation to other downstream nodes alongpath of the backup path. It is also possible thatLSP, ERO expansion will be required at some protection schemes already signal this information inpoint along the DETOUR object([FAST-REROUTE]). However,path: probably at a domain border node. In order that the mechanisms for signaling this are outbackup path remains disjoint from the protected LSP(s) the node performing the ERO expansion must be provided with the path of scopethe protected LSPs between the PLR and the MP. This information can be gathered from the RROs of this document.the protected LSPs and is signaled in the DETOUR object for Fast Reroute [RFC4090], and using route exclusion [EXCLUDE-ROUTE] discusses one such solution to achieve this.for other protection schemes. 5.1. Fast Recovery support using MPLS TESupport Using MPLS-TE Fast Reroute (FRR) [FAST-REROUTE][RFC4090] describes two methods for local protection for a packet TE LSP in case of link, SRLGSRLG, or node failure. This section describes how these mechanisms work with the proposed signaling solutions for inter-domain TE LSP setup. 5.1.1. Failure withinWithin a domain (linkDomain (Link or node failure)Node Failure) The mode of operation of MPLS TEMPLS-TE Fast Reroute to protect a contiguous, stitched or nested TE LSP within a domain is identical to the existing procedures described in [FAST-REROUTE]. In[RFC4090]. Note that, in the case of nestednesting or stitched inter-domain TE LSPs, protectingstitching, the intra-domain TE H-LSP orend-to-end LSP segment willis automatically protectprotected by the trafficprotection operation performed on the inter-domain TEH-LSP or stitching segment LSP. No newprotocol extensions are required for any of the signaling methods.required. 5.1.2. Failure of linka Link at a Domain Borders This cases arises where two domains are connected by a TE link. In this case each domain boundaries The procedures for doing link protection of the link athas its own domain boundariesborder node, and these two nodes are connected by the TE link. An example of this case is where the sameASBRs of two ASes are connected by a TE link. A contiguous LSP can be backed up using any PLR and MP, but if the LSP uses stitching or nesting in either of the connected domains, the PLR and MP MUST be domain border nodes for contiguous, nestedthose domains. It will be usual to attempt to use the local (connected by the filed link) domain border nodes as the PLR and stitched TE LSPs.MP. To protect an inter-domain link with MPLS TEMPLS-TE Fast Reroute, a set of backup tunnels must be configured or dynamically computed between the two domain boundary nodesPLR and MP such that they are diversely routed from the protected inter- domain link. The region connecting two domains may not be TE enabled. In this case, an implementation will have to supportinter-domain link and the set up of TE LSP over a non-TE enabled region. For eachprotected inter-domain TELSPs. Each protected inter-domain LSP traversingusing the protected link, a NHOP backupinter-domain TE link must be selected by a PLR (i.e domain exit boundary router), when the TE LSP is first set up. This requires for the PLRassigned to select aan NHOP bypass tunnel terminating at the NHOP. Findingthat is diverse from the protected LSP. Such an NHOP bypass tunnel of an inter-AS LSPcan be achievedselected by analyzing the content of the RRO object receivedRROs in the RSVPResv messagemessages of boththe available bypass tunneltunnels and the protected TE LSP(s). AsLSP. It may be helpful to this process if the extensions defined in [RSVP- TE],[NODE-ID] are used to clearly distinguish nodes and links in the addresses specifiedRROs. 5.1.3. Failure of a Border Node Two border node failure cases exist. If the domain border falls on a link as described in the RRO IPv4 subobjects can be node- ids and/or interface addresses (with specific recommendation to useprevious section, the interface addressborder node at either end of the outgoing Path messages). The PLR may orlink may not have sufficient topology information to find where the backup tunnel intersectsfail. Alternatively, if the protected TE LSP basedborder falls on the RRO. [NODE-ID] proposesa solution to this issue, defining an additional RRO IPv4 subojectborder node (as is the case with IGP areas) that specifies a node-id address. 5.1.3. Failure of a boundarysingle border node For each protected inter-domain TE LSP traversingmay fail. It can be seen that if stitching or nesting are used, the boundaryfailed node towill be protected,the start or end (or both) or a NNHOP backupstitching segment LSP or H-LSP in which case, protection must be selected by the PLR. This requires the PLRprovided to setup a bypass tunnel terminating at the NNHOP. Findingthe NNHOP bypass tunnelfar end of an inter-domain TE LSP can be achieved by analyzing the contentstitching segment or H-LSP. Thus, where one of the RRO object receivedthese two techniques is in the RSVP Resv message of both the bypass tunnel and the protected TE LSP(s) (see [NODE-ID]). The main difference with node protection, between a protected contiguous inter-domain TE LSP and a protected nested or stitched inter-domain TE LSP is thatuse, the PLR and NNHOP (MP) in case of a contiguous TE-LSP couldwill be any node withinthe domain. However,upstream domain entry point in the case of a nested or stitched TE-LSPthe PLRfailure of the domain exit point, and the MP can onlywill be the end-pointsdownstream domain exit point in the case of the H-LSP or LSP segment. The consequence is thatfailure of the backup path is likely to be longer and if bandwidth protection is desired, for instance, ([FAST-REROUTE]) more resources may be reserved indomian entry point. Where the domain than necessary. Note, however, that even forborder falls at a contiguous LSP, there may be cases where the addresses within thesingle domain could have been masked in the RRO for confidentiality reasons, in which case, the RRO forborder node, both cases will apply. If the contiguous LSP may only contain boundary nodes, and somechanism is in use, normal selection of the PLR and MP can onlybe a boundary node. Also, while a contiguous LSP does allow backup LSPs to terminate insideapplied and any node within the domain, there could be policies whichdomains may reject an LSP that originates in another domain from carrying addresses in ERO that are localbe used to this domain. Infill these cases, theroles. As before, selection of a suitable backup LSP cannot terminate inside the domain andtunnel (in this case an NNHOP backup) must terminate only atconsider the boundary node. In casepaths of stitching or nesting, whenthe node to be protected isbacked up LSPs and the H-LSP/S-LSP tail-end node,available NNHOP tunnels by examination of their RROs. Note that where the PLR is not immediately upstream of this node. Hence,the failure detectionfailed node, error propagation time on failure of H-LSP/S- LSP tail-end node is bound tomay be longer than that in the case where PLR is immediately upstream of the node to be protected. Indelayed unless some mechanism such cases, itas [BFD-MPLS] is RECOMMENDED thatimplemented, or unless direct reporting, such as through the PLR rely on methods proposed in [BFD-MPLS] to rapidly detect H-LSP/S-LSP tail-end node failure. This would help in fast recovery.GMPLS Notify message [RFC3473] is employed. 5.2. Protection and recoveryRecovery of GMPLS LSPs [SEGMENT-PROTECTION] describes GMPLS based segment recovery. This allows protection against a span failure, a node failure, or failure over any particular portion of a network used by an LSP. The scenariosdomain border failure cases described above for MPLS Fast reroutein Section 5.1 may also apply to segment protection. No new extensions are needed foroccur in GMPLS networks (including packet networks) and can be protected against using segment protection of LSPswithout any additional protocol extensions. Note that span multiple domains. However,if loose hops are used in the inter-domain LSP case, it may not always be possible for the upstream node (outside a domain) to identify end-pointsconstruction of segment recovery LSP in another domain. Even if this was somehow determined, SERO and SRRO inthe recovery LSP MUST be subjected to EROworking and RRO processing rules as described above, so policy could disallow explicit control of LSPprotection paths signaled for segment recovery insideprotection then care is required to keep these paths disjoint. If the domain by a node outsidepaths are signaled incrementally then route exclusion [EXCLUDE-ROUTE] may be used to ensure that the domain. This is treated aspaths are disjoint. Otherwise a Segment Protection failure and error handlingcoordinated path computation technique such as described in Section 4.2.1 of [SEGMENT-PROTECTION].that offered by cooperating Path Computation Elements [RFC4655] can provide suitable paths. 6. Re-optimizationRe-Optimization of inter-domainInter-Domain TE LSPs Re-optimization of a TE LSP is the process of moving the LSP from the current path to a more preferedpreferable path. This usuallyinvolves computationthe determination of the new preferedpreferred path and make-before-break signaling procedures [RSVP-TE],[RFC3209] to minimize traffic disruption. The path computation procedures involved in re-optimizationRe-optimization of an inter-domain TE LSP are coveredmay require a new path in [INTER-DOMAIN-PD-PATH-COMP]. Another option is to use PCE-based mechanisms ([PCE]) for re-optimization. In the contextmore than one domain. The nature of an inter-domain TE LSP, sincethe inter-domain LSP traverses multiple domains,setup mechanism defines how re-optimization maycan be required in one or more domains at a time. Again, depending onapplied. If the natureLSP is contiguous then the signaling of the LSP and/or policies and configuration at domain boundaries (or other nodes), one may either always wantmake-before-break process MUST be initiated by the head-endingress node ofas defined in [RFC3209]. But if the inter-domain TE LSPre-optimization is limited to a change in path within one domain (that is, if there is no change to be notified of any local need for re-optimizations and letthe head-end initiatedomain border nodes) and nesting or stitching are in use, the make-before-break processH-LSP or onestitching segment may be independently re-optimized within the domain without impacting the end-to-end LSP. In all cases, however, the ingress LSP may wantwish to restrict local re-optimizations withexert control and coordination over the domain.re-optimization process. [LOOSE-REOPT] describes mechanisms that allow, oallow: - The head-endingress node to trigger on everyrequest each node whose next hop iswith a loose next hop the re-evaluation ofto re-evaluate the current path in order to detectsearch for a potentiallymore optimal path. This is done via explicit signaling request: the head-end node sets the "ERO Expansion request" bit of the SESSION-ATTRIBUTE object carried in the RSVP Path message. o- A node whosewith a loose next hop is a loose-hop to signalto inform the head-endingress node that a better path exists. This is performed by sending an RSVP PathErr Notify message (error-code = 25), sub-code=6 (Better path exists). This indication may either be sent in response to a query sent by the head-end node or spontaneously by any node having detected a more optimal path. The aboveThese mechanisms SHOULD be used for re-optimization of a contiguous inter-domain TE LSPLSP. 7. Security Considerations A separate document is being prepared to allowexamine the head-end nodesecurity aspects of the inter-domain TE LSP to initiate make-before-break procedures. For nested or stitched TE LSPs, it is possibleRSVP-TE signaling with special reference to re-optimize the local H-LSP or LSP segment without involving the head-end nodemulti-domain scenarios. [INTER-DOMAIN-FRAMEWORK] provides an overview of the inter-domain TE LSP. This will automatically re-route the traffic for the inter-domain TE LSP along the new path, within the domain. Such local re-optimizations, including parametersrequirements for re-optimization can be controlled by local policy or configurationsecurity in that domain. 7. Security Considerationsan MPLS-TE or GMPLS multi-domain environment. When signaling an inter-domain RSVP-TE LSP, an operator may make use of the already definedsecurity features related to RSVP-TE (authentication). Thisalready defined for RSVP-TE [RFC3209]. This may require some coordination between the domains to share the keys (see RFC 2747[RFC2747] and RFC 3097).[RFC3097]), and care is required to ensure that the keys are changed sufficiently frequently. Note that this may involve additional synchronization, should the domain boundary LSRborder nodes be protected with MPLS TE Fast Reroute,FRR, since the merge pointMP and PLR should also share the key. For an inter-domain TE LSP, especially when it traverses different administrative or trust domains, the following mechanisms (also see [INTER-AS-TE-REQS])SHOULD be provided to an operator :-(also see [RFC4216]): 1) aA way to enforce policies and filters at the domain boundariesborders to process the incoming inter-domain TE LSP setup requests (Path messages) based on certain agreed trust and service levels/contracts between domains. Various LSP attributes such as bandwidth, priority; etcpriority, etc. could be part of such a contract. 2) aA way for the operator to rate limitrate-limit LSP setup requests or error notifications from a particular domain. 3) aA mechanism to allow policy-based outbound RSVP message processing at the domain boundary LSR,border node, which may involve filtering or modification of certain addresses in RSVP objects and messages. Some examples of the policies described above are:- 1)A) An operator may choose to implement some kind of ERO filtering policy on the domain boundary LSRborder node to disallow or ignore hops within the domain from being identified in the ERO of an incoming Path message. 2)B) In order to preserve confidentiality,confidentiality of network topology, an operator may choose to disallow recording of hops within the domain in the RRO or may choose to filter out certain recorded RRO addresses at the domain boundary LSR. 3)border node. C) An operator may require the boundary LSRborder node to modify the addresses of certain messages like PathErr or Notify originated from hops within the domain. Note that the detailed specification of such mechanisms (local implementation) ispolicies and their implementation are outside the scope of this document. 8. IANA Considerations The following values have to be defined byIANA for this document. The registry is, http://www.iana.org/assignments/rsvp-parameters.is requested to make the codepoint allocations described in the following sections. 8.1. Attribute Flags for LSP_ATTRIBUTES object The followingLSP_Attributes Object A new flagbit is being defined forto be allocated from the Attributes Flags TLV in"Attributes Flags" sub-registry of the LSP_ATTRIBUTES object."RSVP TE Parameters" registry. Path Resv RRO Bit Name message message sub-object ---- ------------------------------- -------- -------- ---------- XX Contiguous LSP Yes No Yes The numericvalue shouldXX is to be assigneddefined by IANA. Contiguous LSP bit - Bit NumberA value of 4 (Suggested value) This flag bitis only to be used in the Attributes Flags TLV on a Path message. The "Contiguous LSP" bit has a corresponding "Contiguous LSP signaled" bit (Bit Number 4) to be used in the RRO Attributes sub- object.suggested. 8.2. New Error Codes The followingNew RSVP error codes/values are required to be allocated from the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry of the "RSVP Parameters" registry. For the existing error code "Policy control failure" (value 2), two new error sub-codesvalues are being defined undersuggested as follows. The values are suggested and are for IANA determination. 103 = Inter-domain policy failure 104 = Inter-domain explicit route rejected For the RSVP error-codeexisting error code "Routing Problem" (24). The numeric(value 24), two new error sub-code value should be assigned by IANA. Suggestedvalues are, 1.are suggested as follows. The values are suggested and are for IANA determination. 21 = Contiguous LSP type not supported - sub-code 21 2.22 = ERO conflicts with inter-domain signaling method - sub-code 22 These error codes are to be used only in a RSVP PathErr.9. Acknowledgements The following new error sub-codes are being defined under the RSVP error-code "Policy control failure" (2). The numeric error sub-code value should be assigned by IANA. Suggested values are, 1. Inter-domain policy failure - sub-code 102 2. Inter-domain explicit route rejected - sub-code 103 9. Acknowledgements The authors would like to acknowledgeauthors would like to acknowledge the input and helpful comments from Adrian FarrelKireeti Kompella on various aspects discussed in the document. 10. References 10.1. Normative References [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF", RFC 3630 (Updates RFC 2370), September 2003. [ISIS-TE] Smit, H., Li, T., "IS-IS extensions[RFC2119] Bradner, S., "Key words for Traffic Engineering",use in RFCs to Indicate Requirement Levels", BCP 14, RFC 3784 [RSVP-TE]2119, March 1997. [RFC3209] Awduche, D., et al, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RSVP-GMPLS] L.[RFC3473] Berger, L., et al, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-TrafficProtocol - Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [LSP-HIERARCHY][RFC4206] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized MPLS TE", RFC 4206, October 2005. [LSP-STITCHING] Ayyangar[RFC4420] Farrel, A., Vasseur JP., "LSP Stitching with Generalized MPLS TE", (work in progress). [CRANKBACK] Farrel A. et al, "Crankback Signaling Extensions for MPLS Signaling", (work in progress). [LSP-ATTRIBUTES] Farrel A.et al, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", RFC 4420, February 2006. 10.2. Informative References [INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering requirements", RFC 4216, November 2005. [INTER-AREA-TE-REQS] LeRoux JL, Vasseur JP, Boyle J.[LOOSE-REOPT] Vasseur, JP., et al, "Requirements for support"Reoptimization of Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. [INTER-DOMAIN-FRAMEWORK] Farrel A. et al, "A Framework for Inter- Domain MPLS Traffic Engineering", (work in progress). [INTER-DOMAIN-PD-PATH-COMP] Vasseur JP., Ayyangar A., Zhang R., "A Per-domain path computation method for computing Inter-domainMultiprotocol Label Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switched Path",Switch Path (LSP)", draft-ietf-ccamp-loose-path-reopt, (work in progress). [PCE] Ash, G., Farrel,[LSP-STITCHING] Ayyangar, A., Kompella, K., and Vasseur, JP., "Path Computation Element (PCE) Architecture", draft-ietf-pce-architecture, work in progress. [GMPLS-OVERLAY] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the Overlay Model", RFC 4208, October 2005. [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [NODE-ID] Vasseur, Ali and Sivabalan, "Definition of an RRO node-id subobject", (work in progress). [SEGMENT-PROTECTION] L. Berger et al, "GMPLS Based Segment Recovery", (work in progress). [BFD-MPLS] R. Aggarwal et al, "BFD For MPLS LSPs", (work in progress). [LOOSE-REOPT] Vasseur JP. et al, "Reoptimization of an explicit loosely routed"Label Switched Path Stitching with Generalized MPLS TE paths",Traffic Engineering", draft-ietf-ccamp-lsp-stitching, (work in progress). Appendix 1: Examples This Appendix provides some examples to illustrate the inter-domain signaling procedures described in this document. We consider one example topology which covers inter-domain TE LSP signaling across Autonomous systems. Inter-domain TE LSP signaling across other domains covered by this document are also meant to follow similar signaling procedures, but are not covered here. <-- 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 ================> 1.1 Assumptions - Three interconnected ASes, respectively AS-1, AS-2, and AS-3. 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 [ISIS-TE]). In other words, the ASes are TE enabled. Note that each AS can run a different IGP. - 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. For the sake of simplicity, each routing domain will be considered as single area in this document, but the solutions described in this document does not prevent the use of multi-area techniques. In fact, these inter-domain solutions are equally applicable to inter-area TE. - An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R7 in AS3 with following possible explicit paths: o p1 - path defined by ERO with a set of loose node hops crossing AS-2, ASBR1(loose)-ASBR4(loose)-ASBR7(loose)-ASBR9(loose)-R7(loose) o p2 - path defined by ERO containing a set of strict interface hops crossing AS-2, ASBR1(loose)-link[ASBR1-ASBR4](strict)-link[ASBR4-R3](strict) -link[R3-ASBR7](strict)-link[ASBR7-ASBR9](strict)-R7(loose) o p3 - path defined by ERO containing a set of AS number hops crossing AS-2, ASBR1(loose)-link[ASBR1-ASBR4](strict)-AS3(loose)-R7(loose) - The explicit paths (EROs) may have been configured and/or computed at the head-end node using any of the path computation schemes. 1.2 ERO processing Let us consider an inter-AS TE LSP setup from R0 to R7, with example paths p1, p2. In this example, we will examine the behavior on node ASBR4 which is the boundary node for AS-2, for the different signaling methods. Contiguous:- The head-end node, R0, that desires to setup an end-to-end contiguous TE LSP, MAY originate a Path message with LSP_ATTRIBUTES object with the "Contiguous LSP" bit set in the Attributes Flags TLV. For path p1, additional computation to expand the loose hops may be required at various hops along the LSP path. When the Path message arrives at ASBR4, it may carry out a path computation or use some other means to find the intermediate hops to reach ASBR7. It may then adjust the outgoing ERO and forward the Path message through the intermediate hops in AS-2 to ASBR7. For path p2, the ERO next hop points to a node within the domain. ASBR4 will then directly forward the Path message to the next hop in the ERO. For path p3, the ERO nexthop is a loose hop pointing to the subsequent AS number. In this case, ASBR4 will perform path computation to determine the intermediate hops to reach AS-3. It may adjust the ERO based on the computation results. In this case either ASBR7 or ASBR8 may be chosen as the exit points from AS-2. Similarly, either ASBR9 or ASBR10 may be chosen as entry points into AS-3. Nesting and Stitching:- When the Path message for the inter-AS TE LSP from R0 to R7, reaches ASBR4, ASBR4 SHOULD first determine from the ERO hops, the boundary node to the domain along the path. In this example, the domain boundary node for all paths is ASBR7. It SHOULD then use the ERO hops up to ASBR7 to find an existing H-LSP in case of nesting or LSP segment in case of stitching, that satisfies the TE constraints. If there are no existing H-LSPs or LSP segments and ASBR4 is capable of setting up the H-LSP or LSP segment on demand, it SHOULD do so using the ERO hops in the Path message of the inter-domain TE LSP. In either case, ASBR4 will adjust the ERO in the inter-domain TE LSP and will forward the Path message directly to the end-point of the H-LSP or LSP segment using the procedures described in [LSP-HIERARCHY]. In case of path p1, since there are no ERO hops between ASBR4 and ASBR7, and ASBR7 hop is loose, ASBR4 may select any existing H-LSP (nesting) or LSP segment (stitching) that satisfies the constraints or it may compute a path for the H-LSP or LSP segment up to ASBR7 or some other intermediate node in AS-2. In case of path p2, ASBR4 may either select an existing H-LSP or LSP segment with ERO hops link[ASBR4-R3](strict)-link[R3-ASBR7](strict) or it may compute a new path for the H-LSP or LSP segment using the above hops. In either case, the ERO hops for the H-LSP or LSP segment MUST be the same as the signaled strict hops in that domain. Processing of path p3 is similar to p1 except that exit points from AS-2 and entry points into AS-3 are determined as part of path computation. Now, suppose, we have a path p4, defined by an ERO comprising a set of strict node hops crossing AS-2 as shown below, ASBR1(loose)-ASBR4(loose)-ASBR7(strict)-ASBR9(loose)-R7(loose) In this case, the ERO nexthop at ASBR4 is ASBR7(strict). In this case, ASBR4 will try to find or compute a H-LSP or LSP segment directly to ASBR7. The main difference between processing of p1 and p4 for nesting or stitching is that in case of p1, since the ERO nexthop is a loose hop, ASBR4 need not find a H-LSP or LSP segment directly from ASBR4 to ASBR7. So, there could be multiple H-LSPs or LSP segments between ASBR4 and ASBR7 terminating and originating on other nodes. On the other hand, for path p4, since the ERO hop to ASBR7 is a strict hop, ASBR4 MUST find or signal a H-LSP or LSP segment that directly connects ASBR4 and ASBR7. 1.3 Examples of local protection with MPLS FRR - Let us again consider the example topology above and assume that the TE LSP is now protected. Let us consider the following backup tunnels in the above example, o B1 from ASBR1 to ASBR4 following the path link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR4](strict) and protecting against a failure of the ASBR1-ASBR4 link o B2 from ASBR1 to R3 following the path defined by ERO, link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR3](strict)- link[ASBR3-ASBR6](strict)-link[ASBR6-ASBR5](strict)-R3(strict) and protecting against a failure of the ASBR4 node. o B3 from ASBR1 to ASBR7 following the path defined by ERO, link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR3](strict)- link[ASBR3-ASBR6](strict)-ASBR7(loose) and protecting against a failure of the ASBR4 node. In this case B3 will need additional path computation (loose hop expansion) on ASBR6. o B4 from R3 to ASBR9 following the path defined by ERO, link[R3-R4](strict)-link[R4-ASBR8](strict)-ASBR9(loose) and protecting against a failure of the ASBR7 node. B4 may involve loose hop expansion on ASBR8. o B5 from ASBR4 to ASBR9 following the path defined by ERO, ASBR4-ASBR8(loose)-ASBR9(loose) and protecting against a failure of the ASBR7 node. B5 may involve loose hop expansion on ASBR8. Note that in addition to the ERO for backup tunnels, additional information regarding node/link to exclude may need to be signaled as well if backup tunnel setup involves path computation at nodes other than PLR (say for loose hop expansion). The protected inter-domain TE LSP is an inter-AS TE LSP from R0 to R7 with path p1. Also, for nesting or stitching, let us assume that the end-points of the H-LSP or LSP segment in AS-2 are ASBR4 and ASBR7. This gives rise to the following two scenarios for node protection: Protecting the boundary node at the entry to a domain :- Example: protecting against the failure of ASBR4 If the inter-AS TE LSP in this example, is a contiguous LSP, then the PLR is ASBR1 and the NNHOP (MP) could be R3 or any other intermediate node along the LSP path, if this information can be gleaned from the RRO. A backup tunnel B2 may be used to protect the inter-AS TE LSP against failure of ASBR4. However, as explained in Section 5.1.3 if RRO information related to R3 has been masked off or if there are restrictions on terminating the backup tunnel inside AS-2, then B2 cannot be used. In this case B3 may be used to protect the LSP against failure of ASBR4. If the inter-AS TE LSP in this example, is nested or stitched at ASBR4 into an intra-domain TE H-LSP or LSP segment between ASBR4 and ASBR7, then the PLR is ASBR1 and the NNHOP (MP) is ASBR7. A backup tunnel B3 may be used to protect the inter-AS TE LSP against failure of ASBR4. Protecting the boundary node at the exit of a domain :- Example: protecting against failure of ASBR7. If the inter-AS TE LSP in this example, is a contiguous LSP, then the PLR could be R3progress). 10.2. Informative References [RFC2747] Baker, F., Lindell, B., and Talwar, B., "RSVP Cryptographic Authentication", RFC 2747, January 2000. [RFC3097] Braden, R., and the NNHOP (MP) is ASBR9. A backup tunnel B4 may be usedZhang, L., "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001. [RFC4090] Ping Pan, et al, "Fast Reroute Extensions to protect the inter-AS TERSVP-TE for LSP against failure of ASBR7. IfTunnels", RFC 4090, May 2005. [RFC4105] LeRoux, JL., Vasseur, JP., Boyle, J., et al, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. [RFC4208] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the inter-AS TE LSPOverlay Model", RFC 4208, October 2005. [RFC4216] Zhang, R., et al, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005. [RFC4655] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [BFD-MPLS] Aggarwal, R., et al, "BFD For MPLS LSPs", draft-ietf-bfd-mpls, (work in this example, is nested or stitched at ASBR4 into an intra-domain TE H-LSP or LSP segment between ASBR4progress). [CRANKBACK] Farrel, A., et al, "Crankback Signaling Extensions for MPLS and ASBR7, then the PLR is ASBR4GMPLS RSVP-TE", draft-ietf-ccamp-crankback, (work in progress). [EXCLUDE-ROUTE] Lee, CY., Farrel, A., and the NNHOP (MP) is ASBR9. A backup tunnel B5 may be usedDe Cnodder, S., "Exclude Routes - Extension to protect the inter-AS TE LSP against failureRSVP-TE", draft-ietf-ccamp-rsvp-te-exclude-route, (work in progress). [INTER-DOMAIN-FRAMEWORK] Farrel, A., et al, "A Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter-domain-framework, (work in progress). [INTER-DOMAIN-PD-PATH-COMP] Vasseur, JP., Ayyangar, A., and Zhang, R., "A Per-domain path computation method for computing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path-comp, (work in progress). [NODE-ID] Vasseur, JP., Ali, Z., and Sivabalan, S., "Definition of ASBR7. Author's addressesan RRO node-id subobject", draft-ietf-mpls-nodeid-subobject, (work in progress). [SEGMENT-PROTECTION] Berger, L., et al, "GMPLS Based Segment Recovery", draft-ietf-ccamp-gmpls-segment-recovery, (work in progress). 11. Authors' Addresses Adrian Farrel Old Dog Consulting E-mail: email@example.com Arthi Ayyangar Juniper Networks, Inc. 1194 N.Mathilda Ave Sunnyvale,Nuova Systems 2600 San Tomas Expressway Santa Clara, CA 94089 USA e-mail: firstname.lastname@example.org US Email: email@example.com Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA e-mail:Email: firstname.lastname@example.org Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETYSOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006).IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.