doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc5152.txt b/doc/rfc/rfc5152.txt
new file mode 100644
index 0000000..2dd3bd7
--- /dev/null
+++ b/doc/rfc/rfc5152.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Networking Working Group                                JP. Vasseur, Ed.
+Request for Comments: 5152                           Cisco Systems, Inc.
+Category: Standards Track                               A. Ayyangar, Ed.
+                                                        Juniper Networks
+                                                                R. Zhang
+                                                                      BT
+                                                           February 2008
+
+
+   A Per-Domain Path Computation Method for Establishing Inter-Domain
+          Traffic Engineering (TE) Label Switched Paths (LSPs)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document specifies a per-domain path computation technique for
+   establishing inter-domain Traffic Engineering (TE) Multiprotocol
+   Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched
+   Paths (LSPs).  In this document, a domain refers to a collection of
+   network elements within a common sphere of address management or path
+   computational responsibility such as Interior Gateway Protocol (IGP)
+   areas and Autonomous Systems.
+
+   Per-domain computation applies where the full path of an inter-domain
+   TE LSP cannot be or is not determined at the ingress node of the TE
+   LSP, and is not signaled across domain boundaries.  This is most
+   likely to arise owing to TE visibility limitations.  The signaling
+   message indicates the destination and nodes up to the next domain
+   boundary.  It may also indicate further domain boundaries or domain
+   identifiers.  The path through each domain, possibly including the
+   choice of exit point from the domain, must be determined within the
+   domain.
+
+
+
+
+
+
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                     [Page 1]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................3
+      2.1. Requirements Language ......................................4
+   3. General Assumptions .............................................4
+      3.1. Common Assumptions .........................................4
+      3.2. Example of Topology for the Inter-Area TE Case .............6
+      3.3. Example of Topology for the Inter-AS TE Case ...............7
+   4. Per-Domain Path Computation Procedures ..........................8
+      4.1. Example with an Inter-Area TE LSP .........................11
+           4.1.1. Case 1: T0 Is a Contiguous TE LSP ..................11
+           4.1.2. Case 2: T0 Is a Stitched or Nested TE LSP ..........12
+      4.2. Example with an Inter-AS TE LSP ...........................13
+           4.2.1. Case 1: T1 Is a Contiguous TE LSP ..................13
+           4.2.2. Case 2: T1 Is a Stitched or Nested TE LSP ..........14
+   5. Path Optimality/Diversity ......................................14
+   6. Reoptimization of an Inter-Domain TE LSP .......................15
+      6.1. Contiguous TE LSPs ........................................15
+      6.2. Stitched or Nested (non-contiguous) TE LSPs ...............16
+      6.3. Path Characteristics after Reoptimization .................17
+   7. Security Considerations ........................................17
+   8. Acknowledgements ...............................................18
+   9. References .....................................................18
+      9.1. Normative References ......................................18
+      9.2. Informative References ....................................18
+
+1.  Introduction
+
+   The requirements for inter-domain Traffic Engineering (inter-area and
+   inter-AS TE) have been developed by the Traffic Engineering Working
+   Group and have been stated in [RFC4105] and [RFC4216].  The framework
+   for inter-domain MPLS Traffic Engineering has been provided in
+   [RFC4726].
+
+   Some of the mechanisms used to establish and maintain inter-domain TE
+   LSPs are specified in [RFC5151] and [RFC5150].
+
+   This document exclusively focuses on the path computation aspects and
+   defines a method for establishing inter-domain TE LSPs where each
+   node in charge of computing a section of an inter-domain TE LSP path
+   is always along the path of such a TE LSP.
+
+   When the visibility of an end-to-end complete path spanning multiple
+   domains is not available at the Head-end LSR (the LSR that initiated
+   the TE LSP), one approach described in this document consists of
+   using a per-domain path computation technique during LSP setup to
+   determine the inter-domain TE LSP as it traverses multiple domains.
+
+
+
+Vasseur, et al.             Standards Track                     [Page 2]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+   The mechanisms proposed in this document are also applicable to MPLS
+   TE domains other than IGP areas and ASs.
+
+   The solution described in this document does not attempt to address
+   all the requirements specified in [RFC4105] and [RFC4216].  This is
+   acceptable according to [RFC4216], which indicates that a solution
+   may be developed to address a particular deployment scenario and
+   might, therefore, not meet all requirements for other deployment
+   scenarios.
+
+   It must be pointed out that the inter-domain path computation
+   technique proposed in this document is one among many others.  The
+   choice of the appropriate technique must be driven by the set of
+   requirements for the path attributes and the applicability to a
+   particular technique with respect to the deployment scenario.  For
+   example, if the requirement is to get an end-to-end constraint-based
+   shortest path across multiple domains, then a mechanism using one or
+   more distributed PCEs could be used to compute the shortest path
+   across different domains (see [RFC4655]).  Other off-line mechanisms
+   for path computation are not precluded either.  Note also that a
+   Service Provider may elect to use different inter-domain path
+   computation techniques for different TE LSP types.
+
+2.  Terminology
+
+   Terminology used in this document:
+
+   AS: Autonomous System.
+
+   ABR: Area Border Router, a router used to connect two IGP areas
+   (areas in OSPF or levels in Intermediate System to Intermediate
+   System (IS-IS)).
+
+   ASBR: Autonomous System Border Router, a router used to connect
+   together ASs of a different or the same Service Provider via one or
+   more inter-AS links.
+
+   Boundary LSR: A boundary LSR is either an ABR in the context of
+   inter-area TE or an ASBR in the context of inter-AS TE.
+
+   ERO: Explicit Route Object.
+
+   IGP: Interior Gateway Protocol.
+
+   Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
+
+   Inter-area TE LSP: A TE LSP that crosses an IGP area.
+
+
+
+
+Vasseur, et al.             Standards Track                     [Page 3]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+   LSR: Label Switching Router.
+
+   LSP: Label Switched Path.
+
+   TE LSP: Traffic Engineering Label Switched Path.
+
+   PCE: Path Computation Element, an entity (component, application, or
+   network node) that is capable of computing a network path or route
+   based on a network graph and applying computational constraints.
+
+   TED: Traffic Engineering Database.
+
+   The notion of contiguous, stitched, and nested TE LSPs is defined in
+   [RFC4726] and will not be repeated here.
+
+2.1.  Requirements Language
+
+   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].
+
+3.  General Assumptions
+
+3.1.  Common Assumptions
+
+   - Each domain 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 (Resource Reservation Protocol Traffic Engineering)).  A
+     domain may itself comprise multiple other domains, e.g., an AS may
+     itself be composed of several other sub-ASs (BGP confederations) or
+     areas/levels.  In this case, the path computation technique
+     described for inter-area and inter-AS MPLS Traffic Engineering
+     applies recursively.
+
+   - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209] and
+     [RFC3473]).
+
+   - The path (specified by an ERO (Explicit Route Object) in an RSVP-TE
+     Path message) for an inter-domain TE LSP may be signaled as a set
+     of (loose and/or strict) hops.
+
+   - The hops may identify:
+
+      * The complete strict path end-to-end across different domains
+
+      * The complete strict path in the source domain followed by
+         boundary LSRs (or domain identifiers, e.g., AS numbers)
+
+
+
+
+Vasseur, et al.             Standards Track                     [Page 4]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+      * The complete list of boundary LSRs along the path
+
+      * The current boundary LSR and the LSP destination
+
+   The set of (loose or strict) hops can be either statically configured
+   on the Head-end LSR or dynamically computed.  A per-domain path
+   computation method is defined in this document with an optional
+   auto-discovery mechanism (e.g., based on IGP, BGP, policy routing
+   information) yielding the next-hop boundary node (domain exit point,
+   such as an Area Border Router (ABR) or an Autonomous System Border
+   Router (ASBR)) along the path as the TE LSP is being signaled, along
+   with potential crankback mechanisms.  Alternatively, the domain exit
+   points may be statically configured on the Head-end LSR, in which
+   case next-hop boundary node auto-discovery would not be required.
+
+   - Boundary LSRs are assumed to be capable of performing local path
+     computation for expansion of a loose next hop in the signaled ERO
+     if the path is not signaled by the Head-end LSR as a set of strict
+     hops or if the strict hop is an abstract node (e.g., an AS).  In
+     any case, no topology or resource information needs to be
+     distributed between domains (as mandated per [RFC4105] and
+     [RFC4216]), which is critical to preserve IGP/BGP scalability and
+     confidentiality in the case of TE LSPs spanning multiple routing
+     domains.
+
+   - The paths for the intra-domain Hierarchical LSP (H-LSP) or Stitched
+     LSP (S-LSP) or for a contiguous TE LSP within the domain may be
+     pre-configured or computed dynamically based on the arriving
+     inter-domain LSP setup request (depending on the requirements of
+     the transit domain).  Note that this capability is explicitly
+     specified as a requirement in [RFC4216].  When the paths for the
+     H-LSP/S-LSP are pre-configured, the constraints as well as other
+     parameters like a local protection scheme for the intra-domain H-
+     LSP/S-LSP are also pre-configured.
+
+   - While certain constraints like bandwidth can be used across
+     different domains, certain other TE constraints like resource
+     affinity, color, metric, etc. as listed in [RFC2702] may need to be
+     translated at domain boundaries.  If required, it is assumed that,
+     at the domain boundary LSRs, there will exist some sort of local
+     mapping based on policy agreement in order to translate such
+     constraints across domain boundaries.  It is expected that such an
+     assumption particularly applies to inter-AS TE: for example, the
+     local mapping would be similar to the inter-AS TE agreement
+     enforcement polices stated in [RFC4216].
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                     [Page 5]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+   - The procedures defined in this document are applicable to any node
+     (not just a boundary node) that receives a Path message with an ERO
+     that constrains a loose hop or an abstract node that is not a
+     simple abstract node (that is, an abstract node that identifies
+     more than one LSR).
+
+3.2.  Example of Topology for the Inter-Area TE Case
+
+   The following example will be used for the inter-area TE case in this
+   document.
+
+                <-area 1-><-- area 0 --><--- area 2 --->
+                ------ABR1------------ABR3-------
+                |    /   |              |  \     |
+               R0--X1    |              |   X2---X3--R1
+                |        |              |  /     |
+                ------ABR2-----------ABR4--------
+               <=========== Inter-area TE LSP =======>
+
+         Figure 1 - Example of topology for the inter-area TE case
+
+   Description of Figure 1:
+
+   - ABR1, ABR2, ABR3, and ABR4 are ABRs.
+   - X1 is an LSR in area 1.
+   - X2 and X3 are LSRs in area 2.
+   - An inter-area TE LSP T0 originated at R0 in area 1 and terminated
+     at R1 in area 2.
+
+   Notes:
+
+   - The terminology used in the example above corresponds to OSPF, but
+     the path computation technique proposed in this document equally
+     applies to the case of an IS-IS multi-level network.
+
+   - Just a few routers in each area are depicted in the diagram above
+     for the sake of simplicity.
+
+   - The example depicted in Figure 1 shows the case where the Head-end
+     and Tail-end areas are connected by means of area 0.  The case of
+     an inter-area TE LSP between two IGP areas that does not transit
+     through area 0 is not precluded.
+
+
+
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                     [Page 6]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+3.3.  Example of Topology for the Inter-AS TE Case
+
+   We consider the following general case, built on a superset of the
+   various scenarios defined in [RFC4216]:
+
+            <-- AS1 ----> <------- AS2 ------><--- AS3 ----->
+
+                     <---BGP--->            <---BGP-->
+      CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
+            |\     \ |       / |   / |   / |          |      |
+            | \     ASBR2---/ ASBR5  | --  |          |      |
+            |  \     |         |     |/    |          |      |
+            R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2
+
+            <======= Inter-AS TE LSP (LSR to LSR)===========>
+      or
+
+      <======== Inter-AS TE LSP (CE to ASBR) =>
+
+      or
+
+      <================= Inter-AS TE LSP (CE to CE)===============>
+
+         Figure 2 - Example of topology for the inter-AS TE case
+
+   The diagram depicted in Figure 2 covers all the inter-AS TE
+   deployment cases described in [RFC4216].
+
+   Description of Figure 2:
+
+   - Three interconnected ASs, respectively AS1, AS2, and AS3.  Note
+     that in some scenarios described in [RFC4216] AS1=AS3.
+
+   - The ASBRs in different ASs are BGP peers.  There is usually no IGP
+     running on the single hop links interconnecting the ASBRs and also
+     referred to as inter-ASBR links.
+
+   - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE
+     extensions (see [RFC3630], [RFC3784], [RFC4203] and [RFC4205]).  In
+     other words, the ASs are TE enabled.
+
+   - CE: Customer Edge router.
+
+   - Each AS can be made of several IGP areas.  The path computation
+     technique described in this document applies to the case of a
+     single AS made of multiple IGP areas, multiple ASs made of a single
+     IGP area, or any combination of the above.  For the sake of
+     simplicity, each routing domain will be considered as a single area
+
+
+
+Vasseur, et al.             Standards Track                     [Page 7]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+     in this document.  The case of an inter-AS TE LSP spanning multiple
+     ASs where some of those ASs are themselves made of multiple IGP
+     areas can be easily derived from the examples above: the per-domain
+     path computation technique described in this document is applied
+     recursively in this case.
+
+   - An inter-AS TE LSP T1 originated at R0 in AS1 and terminated at R6
+     in AS3.
+
+4.  Per-Domain Path Computation Procedures
+
+   The mechanisms for inter-domain TE LSP computation as described in
+   this document can be used regardless of the nature of the
+   inter-domain TE LSP (contiguous, stitched, or nested).
+
+   Note that any path can be defined as a set of loose and strict hops.
+   In other words, in some cases, it might be desirable to rely on the
+   dynamic path computation in some domains, and exert a strict control
+   on the path in other domains (defining strict hops).
+
+   When an LSR that is a boundary node such as an ABR/ASBR receives a
+   Path message with an ERO that contains a strict node, the procedures
+   specified in [RFC3209] apply and no further action is needed.
+
+   When an LSR that is a boundary node such as an ABR/ASBR receives a
+   Path message with an ERO that contains a loose hop or an abstract
+   node that is not a simple abstract node (that is, an abstract node
+   that identifies more than one LSR), then it MUST follow the
+   procedures as described in [RFC5151].
+
+   In addition, the following procedures describe the path computation
+   procedures that SHOULD be carried out on the LSR:
+
+   1) If the next hop is not present in the TED, the two following
+      conditions MUST be checked:
+
+      o  Whether the IP address of the next-hop boundary LSR is outside
+         of the current domain
+
+      o  Whether the next-hop domain is PSC (Packet Switch Capable) and
+         uses in-band control channel
+
+   If the two conditions above are satisfied, then the boundary LSR
+   SHOULD check if the next hop has IP reachability (via IGP or BGP).
+   If the next hop is not reachable, then a signaling failure occurs and
+   the LSR SHOULD send back an RSVP PathErr message upstream with error
+   code=24 ("Routing Problem") and error subcode as described in section
+   4.3.4 of [RFC3209].  If the available routing information indicates
+
+
+
+Vasseur, et al.             Standards Track                     [Page 8]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+   that next hop is reachable, the selected route will be expected to
+   pass through a domain boundary via a domain boundary LSR.  The
+   determination of domain boundary point based on routing information
+   is what we term as "auto-discovery" in this document.  In the absence
+   of such an auto-discovery mechanism, a) the ABR in the case of
+   inter-area TE or the ASBR in the next-hop AS in the case of inter-AS
+   TE should be the signaled loose next hop in the ERO and hence should
+   be accessible via the TED, or b) there needs to be an alternate
+   scheme that provides the domain exit points.  Otherwise, the path
+   computation for the inter-domain TE LSP will fail.
+
+   An implementation MAY support the ability to disable such an IP
+   reachability fall-back option should the next-hop boundary LSR not be
+   present in the TED.  In other words, an implementation MAY support
+   the possibility to trigger a signaling failure whenever the next hop
+   is not present in the TED.
+
+   2) Once the next-hop boundary LSR has been determined (according to
+      the procedure described in 1)) or if the next-hop boundary is
+      present in the TED:
+
+      o  Case of a contiguous TE LSP.  Unless not allowed by policy, the
+         boundary LSR that processes the ERO SHOULD perform an ERO
+         expansion (a process consisting of computing the constrained
+         path up to the next loose hop and adding the list of hops as
+         strict nodes in the ERO).  If no path satisfying the set of
+         constraints can be found, then this is treated as a path
+         computation and signaling failure and an RSVP PathErr message
+         SHOULD be sent for the inter-domain TE LSP based on section
+         4.3.4 of [RFC3209].
+
+      o  Case of a stitched or nested TE LSP
+
+         *  If the boundary LSR is a candidate LSR for intra-area H-LSP/
+            S-LSP setup (the boundary has local policy for nesting or
+            stitching), the TE LSP is a candidate for hierarchy/nesting
+            (the "Contiguous LSP" bit defined in [RFC5151] is not set),
+            and if there is no H-LSP/S-LSP from this LSR to the next-hop
+            boundary LSR that satisfies the constraints, it SHOULD
+            signal an H-LSP/S-LSP to the next-hop boundary LSR.  If a
+            pre-configured H-LSP(s) or S-LSP(s) already exists, then it
+            will try to select from among those intra-domain LSPs.
+            Depending on local policy, it MAY signal a new H-LSP/S-LSP
+            if this selection fails.  If the H-LSP/S-LSP is successfully
+            signaled or selected, it propagates the inter-domain Path
+            message to the next hop following the procedures described
+            in [RFC5151].  If for some reason the dynamic H-LSP/S-LSP
+            setup to the next-hop boundary LSR fails, then this SHOULD
+
+
+
+Vasseur, et al.             Standards Track                     [Page 9]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+            be treated as a path computation and signaling failure and
+            an RSVP PathErr message SHOULD be sent upstream for the
+            inter-domain LSP.  Similarly, if selection of a pre-
+            configured H-LSP/S-LSP fails and local policy prevents
+            dynamic H-LSP/S, this SHOULD be treated as a path
+            computation and signaling failure and an RSVP PathErr
+            message SHOULD be sent upstream for the inter-domain TE LSP.
+            In both of these cases, procedures described in section
+            4.3.4 of [RFC3209] SHOULD be followed to handle the failure.
+
+         *  If, however, the boundary LSR is not a candidate for
+            intra-domain H-LSP/S-LSP (the boundary LSR does not have
+            local policy for nesting or stitching) or the TE LSP is not
+            a candidate for hierarchy/nesting (the "Contiguous LSP" bit
+            defined in [RFC5151] is set), then it SHOULD apply the same
+            procedure as for the contiguous case.
+
+   The ERO of an inter-domain TE LSP may comprise abstract nodes such as
+   ASs.  In such a case, upon receiving the ERO whose next hop is an AS,
+   the boundary LSR has to determine the next-hop boundary LSR, which
+   may be determined based on the auto-discovery process mentioned
+   above.  If multiple ASBR candidates exist, the boundary LSR may apply
+   some policies based on peering contracts that may have been
+   pre-negotiated.  Once the next-hop boundary LSR has been determined,
+   a similar procedure as the one described above is followed.
+
+   Note the following related to the inter-AS TE case:
+
+   In terms of computation of an inter-AS TE LSP path, an interesting
+   optimization technique consists of allowing the ASBRs to flood the TE
+   information related to the inter-ASBR link(s) although no IGP TE is
+   enabled over those links (and so there is no IGP adjacency over the
+   inter-ASBR links).  This of course implies that the inter-ASBR links
+   be TE-enabled although no IGP is running on those links.
+
+            <-- AS1 ----> <------- AS2 ------><--- AS3 ----->
+
+                     <---BGP--->            <---BGP-->
+      CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
+            |\     \ |       / |   / |   / |          |      |
+            | \     ASBR2---/ ASBR5  | --  |          |      |
+            |  \     |         |     |/    |          |      |
+            R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2
+
+      Figure 3 - Flooding of the TE-related information for
+                 the inter-ASBR links
+
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 10]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+   Referring to Figure 3, ASBR1 for example would advertise in its OSPF
+   Link State Advertisement (LSA)/IS-IS LSP the Traffic Engineering TLVs
+   related to the link ASBR1-ASBR4.
+
+   This allows an LSR (could be the entry ASBR) in the previous AS to
+   make a more appropriate route selection up to the entry ASBR in the
+   immediately downstream AS taking into account the constraints
+   associated with the inter-ASBR links.  This reduces the risk of call
+   setup failure due to inter-ASBR links not satisfying the inter-AS TE
+   LSP set of constraints.  Note that the TE information is only related
+   to the inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes
+   not only the TE-enabled links contained in the AS but also the
+   inter-ASBR links.
+
+   Note that no summarized TE information is leaked between ASs, which
+   is compliant with the requirements listed in [RFC4105] and [RFC4216].
+
+   For example, consider the diagram depicted in Figure 2: when ASBR1
+   floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS))
+   in its routing domain, it reflects the reservation states and TE
+   properties of the following links: X1-ASBR1, ASBR1-ASBR2, and
+   ASBR1-ASBR4.
+
+   Thanks to such an optimization, the inter-ASBR TE link information
+   corresponding to the links originated by the ASBR is made available
+   in the TED of other LSRs in the same domain to which the ASBR
+   belongs.  Consequently, the path computation for an inter-AS TE LSP
+   path can also take into account the inter-ASBR link(s).  This will
+   improve the chance of successful signaling along the next AS in case
+   of resource shortage or unsatisfied constraints on inter-ASBR links,
+   and it potentially reduces one level of crankback.  Note that no
+   topology information is flooded, and these links are not used in IGP
+   SPF computations.  Only the TE information for the outgoing links
+   directly connected to the ASBR is advertised.
+
+   Note that an operator may decide to operate a stitched segment or
+   1-hop hierarchical LSP for the inter-ASBR link.
+
+4.1.  Example with an Inter-Area TE LSP
+
+   The following example uses Figure 1 as a reference.
+
+4.1.1.  Case 1: T0 Is a Contiguous TE LSP
+
+   The Head-end LSR (R0) first determines the next-hop ABR (which could
+   be manually configured by the user or dynamically determined by using
+   the auto-discovery mechanism).  R0 then computes the path to reach
+   the selected next-hop ABR (ABR1) and signals the Path message.  When
+
+
+
+Vasseur, et al.             Standards Track                    [Page 11]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+   the Path message reaches ABR1, it first determines the next-hop ABR
+   from its area 0 along the LSP path (say, ABR3), either directly from
+   the ERO (if for example the next-hop ABR is specified as a loose hop
+   in the ERO) or by using the auto-discovery mechanism specified above.
+
+   - Example 1 (set of loose hops):
+     R0-ABR1(loose)-ABR3(loose)-R1(loose)
+
+   - Example 2 (mix of strict and loose hops):
+     R0-X1-ABR1-ABR3(loose)-X2-X3-R1
+
+   Note that a set of paths can be configured on the Head-end LSR,
+   ordered by priority.  Each priority path can be associated with a
+   different set of constraints.  It may be desirable to systematically
+   have a last-resort option with no constraint to ensure that the
+   inter-area TE LSP could always be set up if at least a TE path exists
+   between the inter-area TE LSP source and destination.  In case of
+   setup failure or when an RSVP PathErr is received indicating that the
+   TE LSP has suffered a failure, an implementation might support the
+   possibility of retrying a particular path option a configurable
+   amount of times (optionally with dynamic intervals between each
+   trial) before trying a lower-priority path option.
+
+   Once it has computed the path up to the next-hop ABR (ABR3), ABR1
+   sends the Path message along the computed path.  Upon receiving the
+   Path message, ABR3 then repeats a similar procedure.  If ABR3 cannot
+   find a path obeying the set of constraints for the inter-area TE LSP,
+   the signaling process stops and ABR3 sends a PathErr message to ABR1.
+   Then ABR1 can in turn trigger a new path computation by selecting
+   another egress boundary LSR (ABR4 in the example above) if crankback
+   is allowed for this inter-area TE LSP (see [RFC4920]).  If crankback
+   is not allowed for that inter-area TE LSP or if ABR1 has been
+   configured not to perform crankback, then ABR1 MUST stop the
+   signaling process and MUST forward a PathErr up to the Head-end LSR
+   (R0) without trying to select another ABR.
+
+4.1.2.  Case 2: T0 Is a Stitched or Nested TE LSP
+
+   The Head-end LSR (R0) first determines the next-hop ABR (which could
+   be manually configured by the user or dynamically determined by using
+   the auto-discovery mechanism).  R0 then computes the path to reach
+   the selected next-hop ABR and signals the Path message.  When the
+   Path message reaches ABR1, it first determines the next-hop ABR from
+   its area 0 along the LSP path (say ABR3), either directly from the
+   ERO (if for example the next-hop ABR is specified as a loose hop in
+   the ERO) or by using an auto-discovery mechanism, specified above.
+
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 12]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+   ABR1 then checks whether it has an H-LSP or S-LSP to ABR3 matching
+   the constraints carried in the inter-area TE LSP Path message.  If
+   not, ABR1 computes the path for an H-LSP or S-LSP from ABR1 to ABR3
+   satisfying the constraint and sets it up accordingly.  Note that the
+   H-LSP or S-LSP could have also been pre-configured.
+
+   Once ABR1 has selected the H-LSP/S-LSP for the inter-area LSP, using
+   the signaling procedures described in [RFC5151], ABR1 sends the Path
+   message for the inter-area TE LSP to ABR3.  Note that irrespective of
+   whether ABR1 does nesting or stitching, the Path message for the
+   inter-area TE LSP is always forwarded to ABR3.  ABR3 then repeats the
+   exact same procedures.  If ABR3 cannot find a path obeying the set of
+   constraints for the inter-area TE LSP, ABR3 sends a PathErr message
+   to ABR1.  Then ABR1 can in turn either select another H-LSP/S-LSP to
+   ABR3 if such an LSP exists or select another egress boundary LSR
+   (ABR4 in the example above) if crankback is allowed for this inter-
+   area TE LSP (see [RFC4920]).  If crankback is not allowed for that
+   inter-area TE LSP or if ABR1 has been configured not to perform
+   crankback, then ABR1 forwards the PathErr up to the inter-area Head-
+   end LSR (R0) without trying to select another egress LSR.
+
+4.2.  Example with an Inter-AS TE LSP
+
+   The following example uses Figure 2 as a reference.
+
+   The path computation procedures for establishing an inter-AS TE LSP
+   are very similar to those of an inter-area TE LSP described above.
+   The main difference is related to the presence of inter-ASBR link(s).
+
+4.2.1.  Case 1: T1 Is a Contiguous TE LSP
+
+   The inter-AS TE path may be configured on the Head-end LSR as a set
+   of strict hops, loose hops, or a combination of both.
+
+   - Example 1 (set of loose hops):
+     ASBR4(loose)-ASBR9(loose)-R6(loose)
+
+   - Example 2 (mix of strict and loose hops):
+     R2-ASBR3-ASBR2-ASBR1-ASBR4-ASBR10(loose)-ASBR9-R6
+
+   In example 1 above, a per-AS path computation is performed,
+   respectively on R0 for AS1, ASBR4 for AS2, and ASBR9 for AS3.  Note
+   that when an LSR has to perform an ERO expansion, the next hop either
+   must belong to the same AS or must be the ASBR directly connected to
+   the next hop AS.  In this latter case, the ASBR reachability is
+   announced in the IGP TE LSA/LSP originated by its neighboring ASBR.
+   In example 1 above, the TE LSP path is defined as: ASBR4(loose)-
+   ASBR9(loose)-R6(loose).  This implies that R0 must compute the path
+
+
+
+Vasseur, et al.             Standards Track                    [Page 13]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+   from R0 to ASBR4, hence the need for R0 to get the TE reservation
+   state related to the ASBR1-ASBR4 link (flooded in AS1 by ASBR1).  In
+   addition, ASBR1 must also announce the IP address of ASBR4 specified
+   in T1's path configuration.
+
+   Once it has computed the path up to the next-hop ASBR, ASBR1 sends
+   the Path message for the inter-area TE LSP to ASBR4 (supposing that
+   ASBR4 is the selected next-hop ASBR).  ASBR4 then repeats the exact
+   same procedures.  If ASBR4 cannot find a path obeying the set of
+   constraints for the inter-AS TE LSP, then ASBR4 sends a PathErr
+   message to ASBR1.  Then ASBR1 can in turn either select another ASBR
+   (ASBR5 in the example above) if crankback is allowed for this inter-
+   AS TE LSP (see [RFC4920]), or if crankback is not allowed for that
+   inter-AS TE LSP or if ASBR1 has been configured not to perform
+   crankback, ABR1 stops the signaling process and forwards a PathErr up
+   to the Head-end LSR (R0) without trying to select another egress LSR.
+   In this case, the Head-end LSR can in turn select another sequence of
+   loose hops, if configured.  Alternatively, the Head-end LSR may
+   decide to retry the same path; this can be useful in case of setup
+   failure due to an outdated IGP TE database in some downstream AS.  An
+   alternative could also be for the Head-end LSR to retry the same
+   sequence of loose hops after having relaxed some constraint(s).
+
+4.2.2.  Case 2: T1 Is a Stitched or Nested TE LSP
+
+   The path computation procedures are very similar to the inter-area
+   LSP setup case described earlier.  In this case, the H-LSPs or S-LSPs
+   are originated by the ASBRs at the entry to the AS.
+
+5.  Path Optimality/Diversity
+
+   Since the inter-domain TE LSP is computed on a per-domain (area, AS)
+   basis, one cannot guarantee that the optimal inter-domain path can be
+   found.
+
+   Moreover, computing two diverse paths using a per-domain path
+   computation approach may not be possible in some topologies (due to
+   the well-known "trapping" problem).
+
+   For example, consider the following simple topology:
+
+                            +-------+
+                           /         \
+                          A----B-----C------D
+                               \           /
+                                +---------+
+
+                Figure 4 - Example of the "trapping" problem
+
+
+
+Vasseur, et al.             Standards Track                    [Page 14]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+   In the simple topology depicted in Figure 4, with a serialized
+   approach using the per-domain path computation technique specified in
+   this document, a first TE LSP may be computed following the path
+   A-B-C-D, in which case no diverse path could be found although two
+   diverse paths actually exist: A-C-D and A-B-D.  The aim of that
+   simple example that can easily be extended to the inter-domain case
+   is to illustrate the potential issue of not being able to find
+   diverse paths using the per-domain path computation approach when
+   diverse paths exist.
+
+   As already pointed out, the required path computation method can be
+   selected by the Service Provider on a per-LSP basis.
+
+   If the per-domain path computation technique does not meet the set of
+   requirements for a particular TE LSP (e.g., path optimality,
+   requirements for a set of diversely routed TE LSPs), other techniques
+   such as PCE-based path computation techniques may be used (see
+   [RFC4655]).
+
+6.  Reoptimization of an Inter-Domain TE LSP
+
+   As stated in [RFC4216] and [RFC4105], the ability to reoptimize an
+   already established inter-domain TE LSP constitutes a requirement.
+   The reoptimization process significantly differs based upon the
+   nature of the TE LSP and the mechanism in use for the TE LSP
+   computation.
+
+   The following mechanisms can be used for reoptimization and are
+   dependent on the nature of the inter-domain TE LSP.
+
+6.1.  Contiguous TE LSPs
+
+   After an inter-domain TE LSP has been set up, a better route might
+   appear within any traversed domain.  Then in this case, it is
+   desirable to get the ability to reroute an inter-domain TE LSP in a
+   non-disruptive fashion (making use of the so-called Make-Before-Break
+   procedure) to follow a better path.  This is a known as a TE LSP
+   reoptimization procedure.
+
+   [RFC4736] proposes a mechanism that allows the Head-end LSR to be
+   notified of the existence of a more optimal path in a downstream
+   domain.  The Head-end LSR may then decide to gracefully reroute the
+   TE LSP using the Make-Before-Break procedure.  In case of a
+   contiguous LSP, the reoptimization process is strictly controlled by
+   the Head-end LSR that triggers the Make-Before-Break procedure as
+   defined in [RFC3209], regardless of the location of the better path.
+
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 15]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+6.2.  Stitched or Nested (non-contiguous) TE LSPs
+
+   In the case of a stitched or nested inter-domain TE LSP, the
+   reoptimization process is treated as a local matter to any domain.
+   The main reason is that the inter-domain TE LSP is a different LSP
+   (and therefore different RSVP session) from the intra-domain S-LSP or
+   H-LSP in an area or an AS.  Therefore, reoptimization in a domain is
+   done by locally reoptimizing the intra-domain H-LSP or S-LSP.  Since
+   the inter-domain TE LSPs are transported using S-LSP or H-LSP across
+   each domain, optimality of the inter-domain TE LSP in a domain is
+   dependent on the optimality of the corresponding S-LSP or H-LSP.  If
+   after an inter-domain LSP is set up a more optimal path is available
+   within a domain, the corresponding S-LSP or H-LSP will be reoptimized
+   using Make-Before-Break techniques discussed in [RFC3209].
+   Reoptimization of the H-LSP or S-LSP automatically reoptimizes the
+   inter-domain TE LSPs that the H-LSP or S-LSP transports.
+   Reoptimization parameters like frequency of reoptimization, criteria
+   for reoptimization like metric or bandwidth availability, etc. can
+   vary from one domain to another and can be configured as required,
+   per intra-domain TE S-LSP or H-LSP if it is pre-configured or based
+   on some global policy within the domain.
+
+   Hence, in this scheme, since each domain takes care of reoptimizing
+   its own S-LSPs or H-LSPs, and therefore the corresponding
+   inter-domain TE LSPs, the Make-Before-Break can happen locally and is
+   not triggered by the Head-end LSR for the inter-domain LSP.  So, no
+   additional RSVP signaling is required for LSP reoptimization, and
+   reoptimization is transparent to the Head-end LSR of the inter-domain
+   TE LSP.
+
+   If, however, an operator desires to manually trigger reoptimization
+   at the Head-end LSR for the inter-domain TE LSP, then this solution
+   does not prevent that.  A manual trigger for reoptimization at the
+   Head-end LSR SHOULD force a reoptimization thereby signaling a "new"
+   path for the same LSP (along the more optimal path) making use of the
+   Make-Before-Break procedure.  In response to this new setup request,
+   the boundary LSR either may initiate new S-LSP setup, in case the
+   inter-domain TE LSP is being stitched to the intra-domain S-LSP, or
+   it may select an existing or new H-LSP, in case of nesting.  When the
+   LSP setup along the current path is complete, the Head-end LSR should
+   switch over the traffic onto that path, and the old path is
+   eventually torn down.  Note that the Head-end LSR does not know a
+   priori whether a more optimal path exists.  Such a manual trigger
+   from the Head-end LSR of the inter-domain TE LSP is, however, not
+   considered to be a frequent occurrence.
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 16]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+   Procedures described in [RFC4736] MUST be used if the operator does
+   not desire local reoptimization of certain inter-domain LSPs.  In
+   this case, any reoptimization event within the domain MUST be
+   reported to the Head-end node.  This SHOULD be a configurable policy.
+
+6.3.  Path Characteristics after Reoptimization
+
+   Note that in the case of loose hop reoptimization of contiguous
+   inter-domain TE LSP or local reoptimization of stitched/nested S-LSP
+   where boundary LSRs are specified as loose hops, the TE LSP may
+   follow a preferable path within one or more domain(s) but would still
+   traverse the same set of boundary LSRs.  In contrast, in the case of
+   PCE-based path computation techniques, because the end-to-end optimal
+   path is computed, the reoptimization process may lead to following a
+   completely different inter-domain path (including a different set of
+   boundary LSRs).
+
+7.  Security Considerations
+
+   Signaling of inter-domain TE LSPs raises security issues (discussed
+   in section 7 of [RFC5151]).
+
+   [RFC4726] provides an overview of the requirements for security in an
+   MPLS-TE or GMPLS multi-domain environment.  In particular, when
+   signaling an inter-domain RSVP-TE LSP, an operator may make use of
+   the security features already defined for RSVP-TE ([RFC3209]).  This
+   may require some coordination between the domains to share the keys
+   (see [RFC2747] and [RFC3097]), and care is required to ensure that
+   the keys are changed sufficiently frequently.  Note that this may
+   involve additional synchronization, should the domain border nodes be
+   protected with Fast Reroute ([RFC4090], since the Merge Point (MP)
+   and Point of Local Repair (PLR) should also share the key.  For an
+   inter-domain TE LSP, especially when it traverses different
+   administrative or trust domains, the following mechanisms SHOULD be
+   provided to an operator (also see [RFC4216]):
+
+   1) A way to enforce policies and filters at the domain borders 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, etc. could be part of such a contract.
+
+   2) A way for the operator to rate-limit LSP setup requests or error
+      notifications from a particular domain.
+
+   3) A mechanism to allow policy-based outbound RSVP message processing
+      at the domain border node, which may involve filtering or
+      modification of certain addresses in RSVP objects and messages.
+
+
+
+Vasseur, et al.             Standards Track                    [Page 17]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+   This document relates to inter-domain path computation.  It must be
+   noted that the process for establishing paths described in this
+   document does not increase the information exchanged between ASs and
+   preserves topology confidentiality, in compliance with [RFC4105] and
+   [RFC4216].  That being said, the signaling of inter-domain TE LSP
+   according to the procedure defined in this document requires path
+   computation on boundary nodes that may be exposed to various attacks.
+   Thus, it is RECOMMENDED to support policy decisions to reject the ERO
+   expansion of an inter-domain TE LSP if not allowed.
+
+8.  Acknowledgements
+
+   We would like to acknowledge input and helpful comments from Adrian
+   Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou, and Faisal Aslam.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+               and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+               Tunnels", RFC 3209, December 2001.
+
+   [RFC3473]   Berger, L., Ed., "Generalized Multi-Protocol Label
+               Switching (GMPLS) Signaling Resource ReserVation
+               Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
+               3473, January 2003.
+
+9.2.  Informative References
+
+   [RFC4920]   Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita,
+               N., and G. Ash, "Crankback Signaling Extensions for MPLS
+               and GMPLS RSVP-TE", RFC 4920, July 2007.
+
+   [RFC5151]   Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
+               Domain MPLS and GMPLS Traffic Engineering -- Resource
+               Reservation Protocol-Traffic Engineering (RSVP-TE)
+               Extensions", RFC 5151, February 2008.
+
+   [RFC5150]   Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
+               "Label Switched Path Stitching with Generalized
+               Multiprotocol Label Switching Traffic Engineering (GMPLS
+               TE)", RFC 5150, February 2008.
+
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 18]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+   [RFC2702]   Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
+               McManus, "Requirements for Traffic Engineering Over
+               MPLS", RFC 2702, September 1999.
+
+   [RFC2747]   Baker, F., Lindell, B., and M. Talwar, "RSVP
+               Cryptographic Authentication", RFC 2747, January 2000.
+
+   [RFC3097]   Braden, R. and L. Zhang, "RSVP Cryptographic
+               Authentication -- Updated Message Type Value", RFC 3097,
+               April 2001.
+
+   [RFC3630]   Katz, D., Kompella, K., and D. Yeung, "Traffic
+               Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
+               September 2003.
+
+   [RFC3784]   Smit, H. and T. Li, "Intermediate System to Intermediate
+               System (IS-IS) Extensions for Traffic Engineering (TE)",
+               RFC 3784, June 2004.
+
+   [RFC4090]   Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
+               Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
+               May 2005.
+
+   [RFC4105]   Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle,
+               Ed., "Requirements for Inter-Area MPLS Traffic
+               Engineering", RFC 4105, June 2005.
+
+   [RFC4203]   Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
+               in Support of Generalized Multi-Protocol Label Switching
+               (GMPLS)", RFC 4203, October 2005.
+
+   [RFC4205]   Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate
+               System to Intermediate System (IS-IS) Extensions in
+               Support of Generalized Multi-Protocol Label Switching
+               (GMPLS)", RFC 4205, October 2005.
+
+   [RFC4216]   Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
+               Autonomous System (AS) Traffic Engineering (TE)
+               Requirements", RFC 4216, November 2005.
+
+   [RFC4655]   Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+               Computation Element (PCE)-Based Architecture", RFC 4655,
+               August 2006.
+
+   [RFC4726]   Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework
+               for Inter-Domain Multiprotocol Label Switching Traffic
+               Engineering", RFC 4726, November 2006.
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 19]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+   [RFC4736]   Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang,
+               "Reoptimization of Multiprotocol Label Switching (MPLS)
+               Traffic Engineering (TE) Loosely Routed Label Switched
+               Path (LSP)", RFC 4736, November 2006.
+
+Authors' Addresses
+
+   JP Vasseur (editor)
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA  01719
+   USA
+
+   EMail: jpv@cisco.com
+
+
+   Arthi Ayyangar (editor)
+   Juniper Networks
+   1194 N. Mathilda Ave
+   Sunnyvale, CA  94089
+   USA
+
+   EMail: arthi@juniper.net
+
+
+   Raymond Zhang
+   BT
+   2160 E. Grand Ave.
+   El Segundo, CA  90025
+   USA
+
+   EMail: raymond.zhang@bt.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 20]
+
+RFC 5152          Path Comp. for Inter-Domain TE LSPs      February 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   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.
+
+   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 SOCIETY, 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.
+
+Intellectual Property
+
+   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-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 21]
+