CCAMP
Network Working Group                               JP Vasseur (Editor)
IETF Internet draft                                 Cisco Systems, Inc.
Proposed Status: Standard                       Arthi Ayyangar (Editor)
                                                       Juniper Networks
                                                          Raymond Zhang
                                            Infonet Service Corporation

Expires: October 2005 April 2006
                                                           October 2005

         draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt

           draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt

   A Per-domain path computation method for computing establishing Inter-domain
          Traffic Engineering (TE) Label Switched Path (LSP) Paths (LSPs)

Status of this Memo

By submitting this Internet-Draft, I certify each author represents that any
applicable patent or other IPR claims of which I am he or she is aware have
been or will be disclosed, and any of which
I become he or she becomes aware
will be disclosed, in accordance with RFC 3668.

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 6 of RFC2026. BCP 79.

Internet-Drafts are
Working 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.

Abstract

This document specifies a per-domain path computation method technique for
computing
establishing inter-domain Traffic Engineering (TE) Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched (LSP)
paths. Paths
(LSPs). In this document a domain is referred refers to as a collection of network
elements within a common sphere of address management or path
computational responsibility such as 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

 Vasseur, Ayyangar and Zhang                                         1

LSP, and is not signaled across domain boundaries. This is most likely
to arise owing to TE visibility limitations. The principle of per-domain path computation specified in this document
comprises of a GMPLS or MPLS node along an inter-domain LSP path,
computing a path signaling message
indicates the destination and nodes up to the last reachable hop within its domain. next domain boundary. It
covers cases where this last hop (domain exit point)
may already be
specified in also indicate further domain boundaries or domain identifiers. The
path through each domain, possibly including the signaling message as well choice of exit point
from the case where this last hop
may need to domain, must be determined by within the GMPLS node. domain.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

Table of content

1. Terminology ............................................. 3 Terminology..................................................3
2. Introduction ............................................ 4 Introduction.................................................3
3. General assumptions ..................................... 5 assumptions..........................................4
3.1 Common assumptions..........................................4
3.2 Example of topology for the inter-area TE case .............5
3.3 Example of topology for the inter-AS TE case ...............6
4. Per-Domain Per-domain path computation algorithm ................... 8 procedures.......................7
4.1 Example with an inter-area TE LSP ...................... 9 LSP...........................10
4.1.1 Case 1: T1 is a contiguous TE LSP .................... 9 LSP.........................10
4.1.2 Case 2: T1 is a stitched or nested TE LSP ............ 10 LSP.................11
4.2 Example with an inter-AS TE LSP ........................ 11 LSP.............................11
4.2.1 Case 1: T1 is a contiguous TE LSP ................... 12 LSP.........................12
4.2.2 Case 2: T1 is a stitched or a nested TE LSP ........... 13
5 LSP...............12
5. Path optimality/diversity ................................ 13
6  MPLS Traffic Engineering Fast Reroute for inter-domain
   TE LSPs ................................................. 13
6.1 Failure of an internal network element ................. 14
6.2 Failure of an inter-ASBR links (inter-AS TE) ........... 14
6.3 Failure of an ABR or an ASBR node ...................... 14
7. optimality/diversity....................................13
6. Reoptimization of an inter-domain TE LSP ................ 14
7.1 LSP.....................13
6.1 Contiguous TE LSPs ..................................... 14
7.2 LSPs..........................................13
6.2. Stitched or nested (non-contiguous) TE LSPs ............ 15
8. LSPs................13
6.3 Path characteristics after reoptimization...................15
7. Security Considerations ................................. 16
9. .....................................15
8. Intellectual Property Considerations .................... 17
10 References .............................................. 17 ........................15
9. Acknowledgments..............................................15
10. References..................................................15
10.1 Normative references .................................. 17 Normatives References .....................................16
10.2 Informative references ................................ 18 References ....................................17

 Vasseur, Ayyangar and Zhang                                         2

1. Terminology

ABR Routers: routers used to connect two IGP areas (areas in OSPF or
L1/L2
levels in IS-IS)

ASBR Routers: routers used to connect together ASes 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 MPLS TE or an ASBR in the context of inter-AS MPLS TE.

Bypass Tunnel: an LSP that is used to protect a set of LSPs passing
over a common facility.

CSPF: Constraint-based Shortest Path First.

Fast Reroutable LSP: any LSP for which the "Local protection desired"
bit is set in the Flag field of the SESSION_ATTRIBUTE object of its
Path messages or signaled with a FAST-REROUTE object.

Interconnect routers or ASBR routers: routers used to connect together
ASes of a different or the same Service Provider via one or more Inter-
AS links.

Inter-AS MPLS TE LSP: A TE LSP whose head-end LSR and tail-end LSR do
not reside within the same Autonomous System (AS), or whose head-end
LSR and tail-end LSR are both in the same AS but the TE  LSPĂs 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). crosses an AS boundary.

Inter-area MPLS TE LSP: A TE LSP where the head-end LSR and tail-end
LSR do not reside in the same area or both the head-end and tail end
LSR reside in the same area but the TE LSP transits one or more
different areas along the path. that crosses an IGP area.

LSR: Label Switch Switching Router

LSP: MPLS Label Switched Path

Local Repair: local protection techniques used to repair

TE LSPs
quickly when a node or link along the LSPs path fails.

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.

 Vasseur, Ayyangar and Zhang                                   3 LSP: Traffic Engineering Label Switched Path

PCE: Path Computation Element. An LSR in charge of computing TE LSP
path for which it is not the Head-end. For instance, Element: an ABR (inter-
area) entity (component, application or an ASBR (Inter-AS) can play the role
network node) that is capable of PCE.

PCC: Path Computation Client (any head-end LSR) requesting computing a network path
computation from the Path Computation Element.

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.

PLR: Point of Local Repair. The head-end of route
based on a bypass tunnel. network graph and applying computational constraints.

TED: MPLS Traffic Engineering Database

The notion of contiguous, stitched and nested TE LSPs is defined in
[INTER-DOMAIN-SIG] and [LSP-STITCHING]
[INT-DOMAIN-FRWK] and will not be repeated here.

2. Introduction

The requirements for inter-area and inter-AS MPLS inter-domain Traffic Engineering (inter-area and
inter-AS TE) have been developed by the Traffic Engineering Working
Group and have been stated in [INTER-AREA-REQS] [INT-AREA-REQS] and [INTER-AS-REQS] respectively. [INT-AS-REQS]. The
framework for inter-domain MPLS Traffic Engineering has been provided
in [INTER-DOMAIN-FRAMEWORK].

The set [INT-DOMAIN-FRWK].

Some of the mechanisms used to establish and maintain inter-domain TE
LSPs are specified in [INTER-DOMAIN-SIG] and [LSP-STITCHING].

This document exclusively focuses on the path computation aspects and
defines a method for computing establishing inter-domain TE LSP paths where each node
in charge of computing a section of an inter-domain TE LSP path is
always along the path of such TE LSP.

When the visibility of an end to end complete path spanning multiple
domains is not available at the head end node, Head-end LSR, one approach described in the
this document consists of using a per-domain path computation scheme
used technique

 Vasseur, Ayyangar and Zhang                                         3

during LSP setup to determine the inter-domain TE LSP path as it traverses
multiple domains.

Note that the

The mechanisms proposed in this document could are also be applicable to MPLS TE
domains other than IGP areas and ASes.

According

The solution described in this document does not attempt to address all
the wide set of requirements defined specified in [INTER-AS-TE-REQS] [INT-AREA-REQS] and [INTER-AREA-TE-REQS], coming up with [INT-AS-REQS]. This
is acceptable according to [INT-AS-REQS] which indicates that a single
solution covering all
the requirements is certainly possible but may be developed to address a particular deployment scenario
and might, therefore, not meet all requirements for other deployment
scenarios.

It must be desired: indeed,
as described in [INTER-AS-TE-REQS] pointed out that the spectrum of deployment scenarios inter-domain path computation technique
proposed in this document is quite large one among many others and designing a solution addressing the super-set choice of all
the appropriate technique must be driven by the set of requirements would lead for
the paths attributes and the applicability to providing a rich set of mechanisms not
required in several cases. Depending on particular technique
with respect to the deployment scenarios of a
SP, certain requirements stated above may be strict while certain other
requirements may be relaxed.

 Vasseur, Ayyangar and Zhang                                   4

There are different ways in which inter-domain TE LSP path computation
may be performed. scenario. For example, if the
requirement is to get an end-to-
end 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. Alternatively, one could
also use some static or discovery mechanisms to determine the next
boundary LSR per domain as the inter-domain TE LSP is being signaled.
domains (see [PCE-ARCH]). Other offline mechanisms for path computation
are not precluded either.
Depending on the Note also that a Service ProviderĂs requirements, one Provider may adopt either
of these techniques for elect
to use different inter-domain path computation.

Note that the adequate path computation method may be chosen based upon
the techniques for different
TE LSP characteristics and requirements. This document specifies an
inter-domain path computation technique based on per-domain path
computation and could be used in place or in conjunction with other
techniques. types.

3. General assumptions

In the rest of this document, we make the following set of assumptions:

1)

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). A domain may itself comprise multiple other domains. E.g. An AS
may itself be composed of several other sub-AS(es) (BGP confederations)
or areas/levels. In this case, the path computation technique described
for inter-area and inter-AS MPLS Traffic Engineering just recursively
applies.

- The inter-domain TE LSPs are signaled using RSVP-TE ([RSVP-TE]).

- The path (ERO) for the an inter-domain TE LSP traversing multiple
areas/ASes may be signaled as a set of
(loose and/or strict) hops. The hops may identify:
      -
        * The complete strict path end to end end-to-end across different
      areas/ASes
      - domains
        * The complete strict path in the source area/AS domain followed by
        boundary LSRs (and (or domain identifiers, e.g. AS numbers)
      -
        * The complete list of boundary LSRs along the path
      -
        * The current boundary LSR and the LSP destination

In this case, the

 Vasseur, Ayyangar and Zhang                                         4

The set of (loose or strict) hops can either be statically configured
on the Head-end LSR or dynamically computed. In
the former case, the resulting path is statically configured on the
Head-end LSR. In the latter case (dynamic computation), a A per-domain path
computation method is defined in this document with some an optional Auto-
discovery mechanism based on BGP and/or IGP and/or BGP information yielding the
next-hop boundary node (domain exit point, say such as ABR/ASBR) along the
path as the TE LSP is being signaled, along with potential crankback
mechanisms. Note

 Vasseur, Ayyangar and Zhang                                   5

that alternatively next-hop Alternatively the domain exit points may be statically
configured on the Head-
end Head-end LSR in which case next-hop boundary node
auto-discovery would not be needed. required.

- Furthermore, the boundary 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 Head-end LSR as a set of strict hops or
if the strict hop is an abstract node (e.g. an AS). This can be done by performing a CSPF computation up to that next
loose hop as opposed to the TE LSP destination or by making use of some
PCEs. In any case, no
topology or resource information needs to be distributed between areas/ASes
domains (as mandated per [INTER-AREA-REQS] [INT-AREA-REQS] and
[INTER-AS-REQS]), [INT-AS-REQS]), which is
critical to preserve IGP/BGP scalability and confidentiality in the
case of TE LSPs spanning multiple routing domains.

Note that PCE-based path computation may be mentioned in this document
for the sake of reference but such techniques are outside the scope of
this document.

- The paths for the intra-domain  FA-LSPs Hierarchical LSPs (H-LSP) or LSP segments S-LSPs
(S-LSP) or for a contiguous TE LSP within the area/AS, domain may be pre-configured pre-
configured or computed dynamically based on the arriving inter-domain
LSP setup request;
depending request (depending on the requirements of the transit area/AS.
domain). Note that this capability is explicitly specified as a
requirement in [INTER-AS-TE-
REQS]. [INT-AS-REQS]. When the paths for the FA-LSPs/LSP segments H-LSPs/S-LSP are
pre-configured, the constraints as well as other parameters like local
protection scheme for the intra-area/AS FA-LSP/LSP segment intra-domain H-LSP/S-LSP are also pre-
configured.

- While certain constraints like bandwidth can be used across different
areas/ASes,
domains, certain other TE constraints like resource affinity, color,
metric, etc. as listed in [RFC2702] could may need to be translated at areas/ASes domain
boundaries. If required, it is assumed that, at the area/AS domain boundary
LSRs, there will exist some sort of local mapping based on offline policy agreement,
agreement in order to translate such constraints across area/AS 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 [INTER-AS-TE-REQS].

2) [INT-AS-REQS].

   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.

<--area1--><---area0---><----area2----->
 ------ABR1------------ABRĂ1-------

<-area 1-><-- area 0 --><--- area 2 --->
 ------ABR1------------ABR3-------
 |    /   |              |  \     |
R0--X1    |              |   X2---X3--R1
 |        |              |  /     |
 -------ABR2-----------ABRĂ2------
 ------ABR2-----------ABR4--------
<=========== Inter-area TE LSP =======>

 Vasseur, Ayyangar and Zhang                                   6

Assumptions                                         5
   Figure 1 - Example of topology for the inter-area TE case

Description of Figure 1:

- ABR1, ABR2, ABRĂ1 ABR3 and ABRĂ2 ABR4 are ABRs,
- X1: an LSR in area 1,
- X2, X3: LSRs in area 2,
- An inter-area TE LSP T0 originated at R0 in area1 area 1 and terminating at
R1 in area2, area 2.

Notes:
- The terminology used in the example above corresponds to OSPF but the
path computation methods technique proposed in this document equally applies to
the case of an IS-IS multi-levels multi-level network.
- Just a few routers in each area are depicted in the diagram above for
the sake of simplicity.

3)
- 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.

   3.3. Example of topology for the inter-AS TE case: case

We will consider the following general case, built on a superset of the
various scenarios defined in [INTER-AS-TE-REQS]: [INT-AS-REQS]:

     <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ---->

               <---BGP--->            <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4¨-R3---ASBR7-¨--ASBR9----R6
CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
      |\     \ |       / |   / |   / |          |     |
      | \     ASBR2---/ ASBR5  | --  |          |     |
      |  \     |         |     |/    |          |     |
      R1-R2¨--ASBR3¨----ASBR6¨-R4---ASBR8¨---ASBR10¨--R7---CE2
      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)===============>             Formatted:

The diagram above

       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 [INTER-AS-TE-REQS].

Assumptions: [INT-AS-REQS].

Description of Figure 2:

 Vasseur, Ayyangar and Zhang                                         6

- Three interconnected ASes, respectively AS1, AS2, and AS3. Note that
AS3 might be AS1
in some scenarios described in [INTER-AS-TE-REQS], [INT-AS-REQS] AS1=AS3.

- The various ASBRs in different ASes are BGP peers, without any peers. There is usually no IGP
running on the single hop links interconnecting the ASBRs and also
referred to as inter-ASBR links,

 Vasseur, Ayyangar and Zhang                                   7 links.

- Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE
extensions (see [OSPF-TE] [OSPF-TE], [ISIS-TE], [G-OSPF] and [IS-IS-TE]). [G-ISIS]). In other
words, the ASes are TE enabled,

- Each AS can be made of several IGP areas. The path computation
techniques
technique described in this document applies to the case of a single AS
made of multiple IGP areas, multiples ASes made of a single IGP areas
or any combination of the above. For the sake of simplicity, each
routing domain will be considered as single area in this document. The
case of an Inter-AS TE LSP spanning multiple ASes where some of those
ASes 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 terminating at R6
in AS3.

4. Per-domain path computation algorithm

Regardless 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), nested).

Note that any path can be defined as a similar set of mechanisms for local TE LSP loose and strict hops. In
other words, in some cases, it might be desirable to rely on the
dynamic path computation (next hop resolution) can be used. in some area, and exert a strict control on
the path in other areas (defining strict hops).

When an ABR/ASBR a boundary LSR (e.g. ABR/ASBR) receives a Path message with an ERO
that contains a loose next-hop hop or an abstract node in the ERO, that is not a simple
abstract node (that is, an abstract node that identifies more than one
LSR), then it carries out MUST follow the procedures as described in [INTER-DOMAIN-
SIG]. In addition, the following actions: procedures describe the path
computation procedures that SHOULD be carried out on the LSR:

1) It checks if If the loose next-hop next hop boundary LSR is accessible via not present in the TED.

If the loose next-hop is not present in the TED, then it checks if the next-
hop at least has IP reachability (via IGP or BGP). following
conditions MUST be checked:
    - If the next-hop is
not reachable, then the path computation stops and IP address of the next hop boundary LSR sends back a is outside of the
      current domain,
    - If the domain is PSC (Packet Switch Capable) and uses in-band
      control channel

 Vasseur, Ayyangar and Zhang                                         7

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 a PathErr upstream. message upstream with error code=24
("Routing Problem") and error subcode as described in section 4.3.4 of
[RSVP-TE]. If the next-hop is reachable, then it finds an
ABR/ASBR SHOULD find a domain
boundary LSR (domain boundary point) to get to the next-hop. 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, otherwise TED or b) there needs to be an alternate scheme that provides
the domain exit points. Otherwise the path computation for the inter-domain inter-
domain TE LSP will fail.

An implementation MAY support the ability to disable such 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) If the next-hop boundary LSR is present in the TED.

        a) Case of a contiguous TE LSP. The ABR/ASBR just performs boundary LSR that processes
        the ERO SHOULD perform an ERO expansion (unless not allowed by
        policy) after having computed the path to the next loose hop
        (ABR/ASBR) that obeys the set of required constraints. If no
        path satisfying the set of constraints can be found, the then this
        SHOULD be treated as a path computation stops and signaling failure
        and a
      Path Error MUST PathErr message SHOULD be sent for the inter-domain TE LSP.
        LSP based on section 4.3.4 of [RSVP-TE].

        b) Case of stitched or nested LSP

                i) if the ABR/ASBR (receiving If the LSP setup request) boundary LSR is a candidate LSR for intra-area FA-LSP/LSP segment
             setup, intra-
                area H-LSP/S-LSP setup (the LSR has local policy for
                nesting or stitching), and if there is no FA-LSP/LSP segment H-LSP/S-LSP
                from this LSR to the next-hop boundary LSR (satisfying that
                satisfies the
             constraints) constraints, it SHOULD signal a FA-LSP/LSP segment H-LSP/S-
                LSP to the next-hop boundary LSR. If pre-configured FA-LSP(s)

 Vasseur, Ayyangar and Zhang                                   8 H-
                LSP(s) or LSP segment(s) S-LSP(s) already exist, then it SHOULD will try to
                select from among those intra-area/AS intra-domain LSPs. Depending on
                local policy, it MAY signal a new FA-LSP/LSP segment H-LSP/S-LSP if this
                selection fails. If the FA-LSP/LSP segment 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 [LSP-HIER]. [INTER-DOMAIN-SIG]. If, for some reason
                the dynamic FA-LSP/LSP segment H-LSP/S-LSP setup to the next-hop boundary
                LSR fails, the then this SHOULD be treated as a path

 Vasseur, Ayyangar and Zhang                                         8
                computation stops and signaling failure and a PathErr is message
                SHOULD be sent upstream for the inter-domain LSP.
                Similarly, if selection of a preconfigured FA-LSP/LSP
             segment H-LSP/S-LSP
                fails and local policy prevents dynamic FA-
             LSP/LSP segment setup, then the H-LSP/S this
                SHOULD be treated as a path computation stops and signaling
                failure and a PathErr is SHOULD be sent upstream for the
                inter-domain TE LSP. In both these cases procedures
                described in section 4.3.4 of [RSVP-TE] SHOULD be
                followed to handle the failure.

                ii) If, however, the boundary LSR is not a FA-LSP/LSP
             segment candidate, candidate
                for intra-domain H-LSP/S-LSP (the LSR does not have
                local policy for nesting or stitching), then it SHOULD simply compute a CSPF
             path up to the next-hop boundary LSR carry out an ERO
             expansion to
                apply the next-hop boundary LSR) and propagate
             the Path message downstream. The outgoing ERO is
             modified after the ERO expansion to same procedure as for the loose next-hop. contiguous case.

                Note that in both cases, path computation and signaling
                process may be stopped due to some local policy.

4.1.   Example with policy violation.

The ERO of an inter-area inter-domain TE LSP

4.1.1.  Case 1: T1 is may comprise abstract nodes such as
ASes. In such a contiguous TE LSP

When case, upon receiving the path message reaches ABR1, it first determines ERO whose next hop is an AS,
the egress boundary LSR
from its area 0 along has to determine the LSP path (say ABRĂ1), either directly from next-hop boundary LSR which may
be determined based on the ERO (if for example "auto-discovery" process mentioned above. If
multiple ASBRs candidates exist the next hop ABR is specified as 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 loose hop in similar procedure
as the ERO) or by using some constraint-aware auto-discovery mechanism. In one described above is followed.

Note related to the former case, every inter-AS TE LSP path is defined as a set of
loose case

The links interconnecting ASBRs are usually not TE-enabled and strict hops but no IGP
is running at least the ABRs traversed by the inter-area AS boundaries. An implementation supporting inter-AS
MPLS TE LSP MUST be specified as loose hops on allow the head-End LSR.

- Example 1 (set set up of strict hops end to end): R0-X1-ABR1-ABRĂ1-X2-X3-R1
- Example 2 (set of loose hops): R0-ABR1(loose)-ABRĂ1(loose)-R1(loose)
- Example 3 (mix of strict and loose hops): R0-X1-ASBR1-ABRĂ1(loose)-
X2-X3-R1

At least, inter-AS TE LSP over the region
interconnecting multiple ASBRs. In other words, an ASBR compliant with
this document MUST support the set up of ABRs from the TE LSP head-end to the tail-End over inter-ASBR links
and MUST be present in able to perform all the ERO as a set usual operations related to MPLS
Traffic Engineering (call admission control, ...).

In terms of loose hops. Optionally, a set computation of
paths can be configured on the head-end LSR, ordered by priority. Each
priority path can be associated with a different set an inter-AS TE LSP path, an interesting
optimization technique consists of constraints.
Typically, it might be desirable allowing the ASBRs to systematically have a last resort
option with no constraint flood the TE
information related to ensure that the inter-area inter-ASBR link(s) although no IGP TE LSP could
always is
enabled over those links (and so there is no IGP adjacency over the
inter-ASBR links). This of course implies for the inter-ASBR links to
be set up if at least TE-enabled although no IGP is running on those links. This allows an
LSR (could be entry ASBR) in the previous AS to make a path exists between more appropriate
route selection up to the inter-area TE

 Vasseur, Ayyangar and Zhang                                   9

LSP source and destination. Note that entry ASBR in case the immediately downstream AS
taking into account the constraints associated with the inter-ASBR
links. This reduces the risk of call set up failure or when
an RSVP Path Error is received indicating due to inter-ASBR
links not satisfying the inter-AS TE LSP has suffered a
failure, an implementation might support set of constraints. Note that
the possibility TE information is only related 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. Any path can be defined as a set of loose and strict hops.
In other words, the inter-ASBR links: the TE
LSA/LSP flooded by the ASBR includes not only the TE-enabled links
contained in some cases, it might be desirable to rely on the
dynamic path computation AS but also the inter-ASBR links.

 Vasseur, Ayyangar and Zhang                                         9

Note that no summarized TE information is leaked between ASes which is
compliant with the requirements listed in some area, [INT-AREA-REQS] and exert a strict control on [INT-AS-
REQS].

For example, consider the path diagram depicted in other areas (defining strict hops).

Once Figure 2: when ASBR1
floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS)) in
its routing domain, it has computed the path up to reflects the next ABR, ABR1 sends reservation states and TE
properties of the Path
message for following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1-
ASBR4.

Thanks to such an optimization, the inter-area inter-ASBRs TE LSP link information
corresponding to ABRĂ1. ABRĂ1 then repeats the a
similar procedure and links originated by the Path message for ASBR is made available in
the inter-area TED of other LSRs in the same domain that the ASBR belongs to.
Consequently, the path computation for an inter-AS TE LSP path can also
take into account the inter-ASBR link(s). This will
reach improve the destination R1. If ABRĂ1 cannot find a path obeying chance
of successful signaling along the set next AS in case of resource shortage
or unsatisfied constraints for 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 inter-area
TE LSP, information for the path computation stops
and ABRĂ1 MUST send a PathErr message outgoing links directly connected to ABR1. Then ABR1 can in turn
triggers a new computation by selecting another egress boundary LSR
(ABRĂ2 in the example above) if crankback is allowed for this inter-
area TE LSP (see [CRANBACK]). If crankback ASBR is not allowed for
advertised.

Note that
inter-area TE LSP or if ABR1 has been configured not an Operator may decide to perform
crankback, then ABR1 MUST stop any path computation operate a stitched segment or 1-hop
hierarchical LSP for the inter-ASBR link.

   4.1. Example with an inter-area TE LSP and
MUST forward a PathErr up to the head-end LSR (R0) without trying to
select another egress LSR.

4.1.2.

4.1.1 Case 2: 1: T1 is a stitched or nested 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
auto-discovery mechanism). R0 then computes the path to reach the
selected next hop ABR and signals the Path message. When the path Path
message reaches ABR1, ABR1 it first determines the egress
LSR next hop ABR from its
area 0 along the LSP path (say ABRĂ1), 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 some constraint-aware the auto-discovery
mechanism.

ABR1 will check if it has 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-ASR1-ABR3(loose)-X2-
X3-R1

Note that a FA-LSP or LSP segment to ABRĂ1 matching the
constraints carried in the inter-area TE LSP Path message. If not, ABR1
will compute set of paths can be configured on the Head-end LSR, ordered
by priority. Each priority path for can be associated with a FA-LSP or LSP segment from ABR1 different set
of constraints. It may be desirable to ABRĂ1
satisfying the systematically have a last
resort option with no constraint and will set it up accordingly. Note to ensure that the
FA-LSP or inter-area TE LSP segment
could have also been pre-configured.

Once the ABR has selected the FA-LSP/LSP segment for the inter-area
LSP, using the signaling procedures described in [LSP-HIER], ABR1 sends always be set up if at least a TE path exists between the Path message for inter-area inter-
area TE LSP to ABRĂ1. Note that irrespective source and destination. In case of whether ABR1 does nesting set up failure or stitching, the Path message for when
an RSVP PathErr is received indicating the
inter-area TE LSP is always forwarded to ABRĂ1. ABRĂ1 then repeats has suffered a
failure, an implementation might support the
exact same procedures possibility to retry a

 Vasseur, Ayyangar and Zhang                                        10

particular path option 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 for along the inter-area TE LSP
will reach computed path. Upon receiving the destination R1. Path
message, ABR3 then repeats a similar procedure. If ABRĂ1 ABR3 cannot find a
path obeying the set of constraints for the inter-area TE LSP, then ABRĂ1 MUST send the
signaling process stops and ABR3 sends a PathErr message to ABR1. Then
ABR1 can in turn either select another
FA-LSP/LSP segment to ABRĂ1 if such an LSP exists or select trigger a new path computation by selecting another
egress boundary LSR (ABRĂ2 (ABR4 in the example above) if crankback is allowed
for this inter-area TE LSP (see [CRANBACK]). [CRANKBACK]). 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

 Vasseur, Ayyangar and Zhang                                  10

inter-area head-end Head-end LSR (R0) without trying to
select another egress
LSR.

4.2.   Example with an inter-AS TE LSP

The 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-ASBRs link(s).

The links interconnecting ASBRs are usually not TE enabled and no IGP
is running at the AS boundaries. An implementation supporting inter-AS
MPLS 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 document MUST support the set up of TE LSP over
ASBR to ASBR links, performing all the usual operations related to MPLS
Traffic Engineering (call admission control, Ó) as defined in [RSVP-
TE].

In term of computation of an inter-AS TE LSP path, an interesting
optimization 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 for the inter-ASBR links to be TE-
enabled although no IGP is running on those links. This allows a head-
end LSR to make ABR.

4.1.2 Case 2: T1 is a more appropriate route selection up to the stitched or nested TE LSP

The Head-end LSR (R0) first ASBR
in determines the next hop AS and will significantly reduce ABR (which could be
manually configured by the number of
signaling steps in route computation. This also allows user or dynamically determined by using
auto-discovery mechanism). R0 then computes the entry ASBR
in an AS to make a more appropriate route selection up path to reach the entry
ASBR in the
selected next hop AS taking into account constraints associated with ABR and signals the ASBR-ASBR links. Moreover, this reduces Path message. When the risk of call set up
failure due to inter-ASBR links not satisfying Path
message reaches ABR1, it first determines the next hop ABR from its
area 0 along the inter-AS TE LSP set
of constraints. Note that path (say ABR3), either directly from the TE information is only related to ERO (if
for example the
inter-ASBR links: next hop ABR is specified as a loose hop in the TE LSA/LSP flooded ERO) or
by using an auto-discovery mechanism, specified above.

ABR1 then checks if it has a H-LSP or S-LSP to ABR3 matching the ASBR includes not only
the TE-enabled links contained
constraints carried in the AS but also the inter-ASBR links.

Note that no summarized inter-area TE information is leaked between ASes which is
compliant with the requirements listed in [INTER-AREA-TE-REQS] and
[INTER-AS-TE-REQS].

Example:

               <---BGP--->            <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4¨-R3---ASBR7-¨--ASBR9---R6
      |\     \ |       / |   / |   / |          |     |
      | \     ASBR2---/ ASBR5  | --  |          |     |
      |  \     |         |     |/    |          |     |
      R1-R2¨--ASBR3¨----ASBR6¨-R4---ASBR8¨---ASBR10---R7---CE2

For instance, in LSP Path message. If not, ABR1
computes the diagram depicted above, when ASBR1 floods its IGP
TE LSA (opaque LSA for OSPF)/LSP (TLV 22 path for IS-IS) in its routing

 Vasseur, Ayyangar a H-LSP or S-LSP from ABR1 to ABR3 satisfying the
constraint and Zhang                                  11

domain, sets it reflects up accordingly. Note that the reservation states and TE properties of H-LSP or S-LSP
could have also been pre-configured.

Once ABR1 has selected the
following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1-ASBR4.

Thanks to such an optimization, H-LSP/S-LSP for the inter-ASBRs inter-area LSP, using
the signaling procedures described in [INTER-DOMAIN-SIG], ABR1 sends
the Path message for inter-area TE link information
corresponding LSP to ABR3. Note that irrespective
of whether ABR1 does nesting or stitching, the links originated by Path message for the ASBR
inter-area TE LSP is made available in always forwarded to ABR3. ABR3 then repeats the TED
exact same procedures. If ABR3 cannot find a path obeying the set of other LSRs
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 same area/AS example above) if crankback is allowed for this inter-area TE LSP
(see [CRANKBACK]). 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 ASBR belongs to.
Consequently, PathErr up to the CSPF computation for inter-area Head-end LSR (R0) without
trying to select another egress LSR.

   4.2. Example with an inter-AS TE LSP path can also
take into account the inter-ASBR link(s). This will improve the chance
of successful

 Vasseur, Ayyangar and Zhang                                        11

The path computation up to the next AS in case of a
bottleneck on some inter-ASBR links and it potentially reduces one
level of crankback. Note that no topology information is flooded and
these links procedures for establishing an inter-AS TE LSP are not used in IGP SPF computations. Only the
very similar to those of an inter-area TE
information for the links originated by the ASBR LSP described above. The main
difference is advertised. related to the presence of inter-ASBRs 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 Head-end LSR as a set of
strict hops, loose hops or a combination of both.

- 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) ASBR4(loose)-ASBR9(loose)-R6(loose)
- Example 3 2 (mix of strict and loose hops): R0-R2-ASBR3-ASBR2-ASBR1-
ASBR4(loose)-ASBR10(loose)-ASBR9-R6

When a next hop is a loose hop, a dynamic path calculation (also called
ERO expansion) is required taking into account the topology and TE
information of its own AS and the set of TE LSP constraints. R2-ASBR3-ASBR2-ASBR1-ASBR4-
ASBR10(loose)-ASBR9-R6

In the example 1 above, the inter-AS TE LSP path is statically configured as a
set of strict hops; thus, in this case, no dynamic computation is
required. Conversely, in the example 2, 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 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 is announced in
the IGP TE LSA/LSP originated by its neighboring ASBR. Indeed, in In the example 2 1
above, the TE LSP path is defined as: R0-ASBR4(loose)-ASBR9(loose)-R6(loose). ASBR4(loose)-ASBR9(loose)-
R6(loose). This implies that R0 must compute the path 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 must
also announce the IP address of
ASBR4 specified in the T1 path configuration.

If an auto-discovery mechanism is available, every LSR receiving an
RSVP Path message, will have to determine automatically the next hop
ASBR, based on the IGP/BGP reachability of the TE LSP destination. With
such a scheme, the head-end LSR and every downstream ASBR loose hop
(except the last loose hop that computes the path to the final
destination) automatically computes the path up to the next ASBR, the
next loose hop based on the IGP/BGP reachability of the TE LSP
destination. If a particular destination is reachable via multiple

 Vasseur, Ayyangar and Zhang                                  12

loose hops (ASBRs), local heuristics may be implemented by the head-end
LSR/ASBRs to select the next hop 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 ASBR
has been determined, an ERO expansion is performed as IP address of ASBR4 specified in the previous
case. 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
and the Path message for the inter-AS TE LSP will reach the destination
R1.
procedures. If ASBR4 cannot find a path obeying the set of constraints
for the inter-AS TE LSP, then ASBR4 MUST send 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
[CRANBACK]).
[CRANKBACK]). If crankback is not allowed for that inter-AS TE LSP or
if ASBR1 has been configured not to perform crankback, then ABR1 MUST stop stops the path computation
signaling process and MUST forward forwards a PathErr up to the head-end Head-end LSR (R0)
without trying to select another egress LSR. In this case, the
head-end Head-end
LSR can in turn select another sequence of loose hops, if configured.
Alternatively, the head-end Head-end 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 head-end Head-end
LSR to retry to 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 signaling path computation procedures are very similar to the inter-area LSP
setup case described earlier. In this case, the FA-LSPs H-LSPs or LSP segments will
only be S-LSPs are
originated by the ASBRs at the entry to the AS.

 Vasseur, Ayyangar and Zhang                                        12

5. Path optimality/diversity

Since the inter-domain path TE LSP is computed on a per domain (area, AS)
basis, one cannot guarantee that the shortest optimal inter-domain path can be
found.

Moreover, computing two diverse paths might using a per-domain path
computation approach may not be possible in some topologies (due to the
well-known ˘trapping÷ "trapping" problem).

As already pointed out, the required path computation method can be
selected by the Operator Service Provider on a per LSP basis.

6.     MPLS Traffic Engineering Fast Reroute for inter-domain TE LSPs

The signaling aspects of Fast Reroute and related constraints for each
TE LSP types in the case of inter-domain TE LSP has been covered in
[INTER-DOMAIN-SIG] and will not be repeated in this document.

 Vasseur, Ayyangar and Zhang                                  13

There are multiple failure scenarios to consider in the case of Fast
Reroute for inter-domain TE LSPs.

6.1.   Failure of an internal network element

The case of a failure of a network element within an area/AS such as a
link, SRLG or a node does not differ from Fast Reroute for intra-domain
TE LSP.

6.2.   Failure of an inter-ASBR links (inter-AS TE)

In order to protect inter-domain TE LSPs from the failure of an inter-
ASBR link, this requires the computation of a backup tunnel path that
crosses an non IGP TE-enabled region (between two ASes).

If the inter-
ASBR TE related information is flooded in the IGPs, each ASBR is
capable of computing the path according to the backup tunnel
constraints. Otherwise, the backup tunnel path MUST be statically
configured.

6.3.   Failure of an ABR or an ASBR node

The constraints to be taken into account during the backup tunnel path
computation significantly differs upon the TE LSP type, network element
to protect (entry/exit boundary node) and the Fast Reroute method in
use (facility backup versus one-to-one). Those constraints have been
explored in detail in [INTER-DOMAIN-SIG] but since the backup tunnel is
itself an inter-domain TE LSP, its per-domain path computation can be performed
according to technique does no meet the two 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 methods described in this
document.

7. techniques may be used (see [PCE-
ARCH]).

6. Reoptimization of an inter-domain TE LSP

The ability to reoptimize an existing already established inter-domain TE LSP path is of
course
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 path computation.

The following mechanisms can be used for re-optimization, which reoptimization and are
dependent on the nature of the inter-domain TE LSP.

7.1.

   6.1. Contiguous TE LSPs

After an inter-AS inter-domain TE LSP has been set up, a more optimal route
might appear in the various within any traversed ASes. domain. Then in this case, it is
desirable to get the ability to reroute an inter-AS inter-domain TE LSP in a non-
disruptive
non-disruptive fashion (making use of the so called Make Before Break so-called Make-Before-Break
procedure) to follow this such more optimal path. This is a known as a TE
LSP reoptimization procedure.

[LOOSE-REOPT] proposes a mechanisms allowing:

 Vasseur, Ayyangar and Zhang                                  14
      - 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 head-end LSR sets the ˘ERO
      Expansion request÷ bit of the SESSION-ATTRIBUTE object carried
      in the RSVP Path message.

      - 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), sub-code 6
      (Better path exists).

      This indication may be sent either:

            - In response to a query sent by the head-end LSR,
             - Spontaneously by any LSR having detected a more
             optimal path

Such a mechanism allows for the reoptimization of a TE LSP if and only
if a better path is some downstream area/AS is detected.

The reoptimization event can either be timer or event-driven based (a
link UP event for instance).

Note that allows the reoptimization MUST always be performed in a non-
disruptive fashion.

Once the head-end Head-end LSR is informed to be
notified of the existence of a more optimal path 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. Then a downstream
domain. The Head-end LSR may then decide to gracefully reroute the inter-AS TE
LSP is set up
following the more optimal path, making use of using the make before break so-called Make-Before-Break procedure.
In case of a contiguous LSP, the reoptimization process is strictly
controlled by the head-end Head-end LSR which triggers the make-before-
break make-before-break
procedure, regardless of the location where the more optimal path
is.

Note that in the case of loose hop reoptimization, the TE LSP may
follow a preferable path within one or more domain(s) whereas in the
case of PCE-based path computation techniques, the reoptimization
process may lead to following a completely different inter-domain path
(including a different set of ABRs/ASBRs) since end-to-end shortest
path is computed.

7.2. optimal path.

   6.2. Stitched or nested (non-contiguous) TE LSPs

In the case of a stitched or nested inter-domain TE LSP, the re-
optimization
reoptimization process is treated as a local matter to any Area/AS. domain. The

 Vasseur, Ayyangar and Zhang                                        13

main reason is that the inter-domain TE LSP is a different LSP (and
therefore different RSVP session) from the intra-domain LSP segment S-LSP or
FA-LSP H-LSP
in an area or an AS. Therefore, reoptimization in an area/AS a domain is

 Vasseur, Ayyangar and Zhang                                  15 done by
locally reoptimizing the intra-domain FA LSP H-LSP or LSP segment. S-LSP.  Since the inter-domain inter-
domain TE LSPs are transported using LSP segments S-LSP or
FA-LSP H-LSP across each domain,
optimality of the inter-domain TE LSP in an
area/AS a domain is dependent on the
optimality of the corresponding LSP
segments S-LSP or FA-LSPs. H-LSPs. If, after an inter-domain inter-
domain LSP is setup, a more optimal path is available within an area/AS, domain,
the corresponding LSP
segment(s) S-LSP  or FA-LSP H-LSP will be re-optimized reoptimized using "make-before-break" "Make-
Before-Break" techniques discussed in [RSVP-TE]. Reoptimization of the FA LSP
H-LSP or LSP
segment S-LSP automatically reoptimizes the inter-domain TE LSPs that
the LSP
segment H-LSP or the S-LSP transports. Reoptimization parameters like
frequency of reoptimization, criteria for reoptimization like metric or
bandwidth
availability; availability, etc can vary from one area/AS domain to another and can
be configured as required, per intra-area/AS intra-domain TE LSP segment S-LSP or FA-LSP H-LSP if it is
preconfigured or based on some global policy within the area/AS. domain.

Hence, in this scheme, since each area/AS domain takes care of reoptimizing its
own LSP segments S-LSPs or FA-LSPs, H-LSPs, and therefore the corresponding inter-
domain inter-domain TE
LSPs, the make-before-break Make-Before-Break can happen locally and is not triggered by
the head-end Head-end LSR for the inter-domain LSP. So, no additional RSVP
signaling is required for LSP re-optimization reoptimization and reoptimization is
transparent to the HE Head-end LSR of the inter-domain TE LSP.

If, however, an operator desires to manually trigger reoptimization at
the head-end 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 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 Make-
Before-Break procedure. In response to this new setup request, the
boundary LSR may either initiate new LSP segment S-LSP setup, in case the inter-domain inter-
domain TE LSP is being stitched to the intra-area/AS LSP segment intra-domain S-LSP or it may
select an existing or new FA-LSP H-LSP in case of nesting. When the LSP setup
along the current optimal path is complete, the head end Head-end LSR should switchover
the traffic onto that path and the old path is eventually torn down.
Note that the head-end Head-end LSR does not know a priori whether a more
optimal path exists. Such a manual trigger from the head-end Head-end LSR of the
inter-domain TE LSP is, however, not considered to be a frequent
occurrence.

Note that stitching or nesting rely on local optimization: the
reoptimization process allows to locally reoptimize each TE LSP segment S-LSP
or FA-LSP: H-LSP: hence, the reoptimization is not global and consequently the
end to end path may no longer to optimal, be optimal should it be optimal when
being set up.

Procedures described in [LOOSE-REOPT] MUST be used if the operator does
not desire local re-optimization reoptimization of certain inter-domain LSPs. In this
case, any re-optimization reoptimization event within the domain MUST be reported to
the head-end Head-end node. This SHOULD be a configurable policy.

8.     Security Considerations

 Vasseur, Ayyangar and Zhang                                  16

When signaling an inter-AS TE, an Operator                                        14
   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 make use 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 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 the already
defined inter-domain TE LSPs raises security features related to RSVP (authentication). This may
require some coordination between Service Providers to share issues that have been
described in section 7 of [INTER-DOMAIN-SIG]; however the keys
(see RFC 2747 and RFC 3097).

9. path
computation aspects specified in this document do not raise additional
security concerns.

8. Intellectual Property Considerations

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..

  IPR Disclosure Acknowledgement

  By submitting this Internet-Draft, I certify that any applicable
  patent or other IPR claims of which I am aware have been disclosed,
  and any of which I become aware will be disclosed, in accordance with
  RFC 3668.

10.
ipr@ietf.org.

9. Acknowledgments

We would like to acknowledge input and helpful comments from Adrian
Farrel.

11
Farrel, Jean-Louis Le Roux and Dimitri Papadimitriou.

10. References

 Vasseur, Ayyangar and Zhang                                        15
   10.1. Normative References

[RFC]

[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.

[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.

 Vasseur, Ayyangar and Zhang                                  17

[RFC3668]

[RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. 3979, March 2005.

[RSVP] Braden, et al, " Resource "Resource ReSerVation Protocol (RSVP) ű (RSVP)" Version
1, Functional Specification÷, 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-03.txt, December
2003.

[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2", RFC 3630, September 2003.

[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering",
RFC 3784, June 2004.

[G-OSPF]Rekhter Y., Kompella K, et al., "OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-ospf-
gmpls-extensions, work in progress.

[G-ISIS] Rekhter Y., Kompella K, et al., "IS-IS Extensions in Support
of Generalized Multi-Protocol Label Switching", draft-ietf-isis-gmpls-
extensions, work in progress.

   10.2. Informative references

[CRANKBACK] Farrel A., et al., "Crankback Signaling Extensions for MPLS
and GMPLS RSVP-TE", draft-ietf-ccamp-crankback, work in progress.

[INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements
for inter-area MPLS Traffic Engineering", draft-ietf-tewg-interarea-
mpls-te-req-03.txt, work in progress. RFC 4105, June 2005.

[INT-AS-REQ] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic
Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req-09.txt, draft-ietf-tewg-interas-mpls-te-req, work in
progress.

[INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A Framework
for Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter-
domain-framework-00.txt,
domain-framework, work in progress.

[FACILITY-BACKUP] Le Roux, J.L.,

 Vasseur, J.P. et al. "Framework for
PCE based MPLS Facility Backup Path Computation", draft-leroux-pce-
backup-comp-frwk-00.txt, work in progress Ayyangar and Zhang                                        16

[INTER-DOMAIN-SIG] Ayyangar, A., Vasseur, JP. ˘Inter-domain "Inter-domain MPLS
Traffic Engineering ű - RSVP extensions÷, extensions", draft-ietf-ccamp-inter-domain-
rsvp-te, work in progress.

[LSP-STITCHING] Ayyangar, A., Vasseur, JP. ˘Label "Label Switched Path
Stitching with Generalized MPLS Traffic Engineering÷, Engineering", draft-ietf-ccamp-
lsp-stitching-00, Work under progress.

 Vasseur, Ayyangar and Zhang                                  18

[LSP-ATTRIBUTE] Farrel A. et al, "Encoding of Attributes for
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)
Establishment Using RSVP-TE", draft-ietf-mpls-rsvpte-attributes-04,(work
in progress).

[GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay
Model", (work in progress).

[EXCLUDE-ROUTE] Lee et all, Exclude Routes - Extension to RSVP-TE,
draft-ietf-ccamp-rsvp-te-exclude-route-00.txt, work in under progress.

[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

[LOOSE-PATH-REOPT] Vasseur, Ikejiri and Zhang ˘Reoptimization "Reoptimization of an
explicit loosely routed MPLS TE paths÷, paths", draft-ietf-ccamp-loose-path-
reopt-01.txt, July 2004, Work in Progress.

[NODE-ID] Vasseur, Ali and Sivabalan, ˘Definition of an RRO node-id
subobject÷,  draft-ietf-mpls-nodeid-subobject-05.txt,
reopt, work in progress. Progress.

[LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, March 2002.

[MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing

[PCE-ARCH] Farrel A., Vasseur J.P, Ash J, "Path Computation Element
(PCE) Architecture", draft-ietf-pce-architecture, work in MPLS
Networks", RFC 3443 (Updates RFC 3032) ", January 2003. progress.

Authors' Address:

Jean-Philippe Vasseur (Editor)
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: jpv@cisco.com

Arthi Ayyangar (Editor)
Juniper Networks, Inc
1194 N.Mathilda Ave
Sunnyvale, CA 94089
USA
e-mail: arthi@juniper.net

 Vasseur, Ayyangar and Zhang                                  19

Raymond Zhang
Infonet Services Corporation
BT/Infonet
2160 E. Grand Ave.
El Segundo, CA 90025
USA
Email: raymond_zhang@infonet.com

Full Copyright Statement

Copyright (C) The Internet Society (2005).  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 AND THE INTERNET

 Vasseur, Ayyangar and Zhang                                        17

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.

 Vasseur, Ayyangar and Zhang                                  20                                        18