[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

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

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/