IETF Internet Draft                             Arthi Ayyangar(Editor)
Network Working Group                                          A. Farrel
Proposed Status: Standards Track                      Juniper Networks                      Old Dog Consulting
Updates: RFC 3209, RFC 3473
Expires: September 2006
                                         Jean-Philippe Vasseur(Editor) July 2007                                           A. Ayyangar
                                                           Nuova Systems

                                                             JP. Vasseur
                                                     Cisco Systems, Inc.

                                                            January 2007

  Inter domain MPLS and GMPLS Traffic Engineering - RSVP-TE extensions

              draft-ietf-ccamp-inter-domain-rsvp-te-03.txt

              draft-ietf-ccamp-inter-domain-rsvp-te-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 6, 2006.

Copyright Notice

Copyright (C) The Internet Society (2006).  All Rights Reserved.

Abstract

   This document describes procedures and protocol extensions to Generalized Multi-Protocol Label
Switching (GMPLS) for the
   use of Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)
   signaling required in Multiprotocol Label Switching Traffic Engineering
   (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and
   non-packet networks to support mechanisms for the establishment and maintenance of GMPLS Traffic Engineering (TE)
   Label Switched Paths

(LSPs), both packet and non-packet, that traverse multiple domains. cross domain boundaries.

   For the purpose of this document, a domain is considered to be any
   collection of network elements within a common realm of address space
   or path computation responsibility. Examples of such domains include
   Autonomous Systems, IGP areas routing areas, and GMPLS overlay networks.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3  2
     1.1   Conventions used in this document Used In This Document  . . . . . . . . . . . .  3
     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Signaling overview Overview   . . . . . . . . . . . . . . . . . . . . .  4
     2.1   Signaling options Options  . . . . . . . . . . . . . . . . . . . .  4
   3.  Procedures on the domain boundary node Domain Border Node . . . . . . . . . . . . .  5
     3.1   Rules on ERO processing Processing  . . . . . . . . . . . . . . . . .  6
     3.2   LSP setup failure Setup Failure and crankback Crankback  . . . . . . . . . . . . .  8
     3.3   RRO processing across domains Processing Across Domains  . . . . . . . . . . . . . .  8
     3.4   Notify Message Processing  . . . . . . . . . . . . . . . .  9
   4.  RSVP-TE signaling extensions Signaling Extensions . . . . . . . . . . . . . . . . .  9
     4.1   Control of downstream choice Downstream Choice of signaling method Signaling Method . . . . .  9
   5.   Protection and recovery Recovery of inter-domain Inter-Domain TE LSPs . . . . . . . 11 10
     5.1   Fast Recovery support using MPLS TE Support Using MPLS-TE Fast Reroute . . . . . 11
       5.1.1   Failure within Within a domain (link Domain (Link or node failure) Node Failure) . . . . 11
       5.1.2   Failure of link Link at domain boundaries Domain Borders  . . . . . . . . . . 11
       5.1.3   Failure of a boundary node Border Node . . . . . . . . . . . . . . . 12
     5.2   Protection and recovery Recovery of GMPLS LSPs  . . . . . . . . . . 13 12
   6.   Re-optimization   Re-Optimization of inter-domain Inter-Domain TE LSPs . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15 14
     8.1   Attribute Flags for LSP_ATTRIBUTES object LSP_Attributes Object  . . . . . . . . 15
     8.2   New Error Codes  . . . . . . . . . . . . . . . . . . . . . 16 15
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16 15
  10.  References   . . . . . . . . . . . . . . . . . . . . . . . . . 16 15
      10.1   Normative References . . . . . . . . . . . . . . . . . . 16 15
      10.2   Informative References . . . . . . . . . . . . . . . . . 17
   Appendix 1:   Examples . . . . . . . . . . . . . . . . . . . . . . 18 16
  11. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . 22
       Intellectual Property and Copyright Statements . . . . . . . . 23 17

1. Introduction

   The requirements for inter-area and inter-AS MPLS Traffic Engineering
   have been developed by the Multiprotocol Label
   Switching (MPLS) Traffic Engineering Working Group and have
   been (TE) are stated in [INTER-AREA-TE-REQS] [RFC4105] and [INTER-AS-TE-REQS]
   [RFC4216] respectively. Many of these requirements also apply to GMPLS
   Generalized MPLS (GMPLS) networks. The framework for inter-domain GMPLS Traffic Engineering
   has been
   MPLS-TE is provided in [INTER-DOMAIN-FRAMEWORK].

   This document presents the RSVP-TE signaling procedures and extensions to Resource
   Reservation Protocol Traffic Engineering (RSVP-TE) signaling for the
   setup and maintenance of TE LSPs traffic engineered Label Switched Paths (TE
   LSPs) that span multiple domains. The signaling
   procedures domains in MPLS-TE or GMPLS networks. The
   signaling procedures described in this document are applicable to both MPLS
   MPLS-TE packet LSPs ([RSVP-TE]) established using RSVP-TE ([RFC3209]) and all
   LSPs (packet and non-packet) that use RSVP-TE GMPLS extensions as
   described in [RSVP-GMPLS]. [RFC3473].

   Three different signaling methods along with the corresponding for inter-domain RSVP-TE extensions and signaling
   are identified in [INTER-DOMAIN-FRAMEWORK]. Contiguous LSPs are
   achieved using the procedures of [RFC3209] and [RFC3473] to create a
   single end-to-end LSP that spans all domains. Nested LSPs are proposed
   established using the techniques described in this document. [RFC4206] to carry the
   end-to-end LSP in a separate tunnel across each domain. Stitched LSPs
   are established using the procedures of [LSP-STITCHING] to construct
   an end-to-end LSP from the concatenation of separate LSPs each
   spanning a domain.

   This document defines the RSVP-TE protocol extensions necessary to
   control and select which of the three signaling mechanisms is used
   for any one end-to-end inter-domain TE LSP.

   For the purpose of this document, a domain is considered to be any
   collection of network elements within a common realm of address space
   or path computation responsibility. Examples of such domains include
   Autonomous Systems, IGP areas areas, and GMPLS overlay networks ([GMPLS-
   OVERLAY]).
   ([RFC4208]).

1.1. Conventions used in this document 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].

1.2. Terminology

   AS: Autonomous System.

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

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

   ERO: Explicit Route Object

   H-LSP: Hierarchical LSP

   FA-LSP: Object.

   FA: Forwarding Adjacency LSP

   LSP: MPLS Adjacency.

   LSR: Label Switched Path Switching Router.

   MP: Merge Point. The node where bypass tunnels meet the protected
   LSP.

   NHOP bypass tunnel: Next-Hop Bypass Tunnel. A backup tunnel, which
   bypasses a single link of the protected LSP.

   NNHOP bypass tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel,
   which bypasses a single node of the protected LSP.

   PLR: Point of Local Repair. The head-end ingress of a bypass tunnel.

   Protected LSP: an LSP is said to be protected at a given hop if it
   has one or multiple associated backup tunnels originating at that
   hop.

   RRO -

   RRO: Record Route Object

   TE: Traffic Engineering

   TE LSP: Traffic Engineering Label Switched Path Object.

   TE link: Traffic Engineering link

   TED: MPLS Traffic Engineering Database link.

2. Signaling overview Overview

   The RSVP-TE signaling of a TE LSP within a single domain is described
   in [RSVP-TE] [RFC3209] and [RSVP-GMPLS]. [RFC3473]. Inter-domain TE LSPs can be supported by
   one of three options as described in the next section:
   - contiguous LSPs
   - nested LSPs
   - stitched LSPs.

   This document focuses on describes the RSVP-TE signaling extensions required to
   control and select which of the three signaling mechanisms is used
   for any one end-to-end inter-domain TE LSP.

   The specific protocol extensions required to signal each LSP setup and
   maintenance. Any type are
   described in other extensions that may be needed documents and are out of scope for this document.
   Similarly, the routing or extensions and path computation are outside techniques
   necessary for the scope establishment of this document. inter-domain LSPs are out of
   scope.

2.1. Signaling options Options

   There are three ways in which an RSVP-TE LSP could be signaled across
   multiple domains:

   Contiguous -
      A contiguous TE LSP is a single end-to-end TE LSP that is setup set up
      across multiple domains using RSVP-TE signaling procedures
      described in [RSVP-TE] [RFC3209] and [RSVP-GMPLS]. [RFC3473]. No additional TE LSPs are
      required to signal create a contiguous TE LSP and the same RSVP-TE
      information for the TE LSP is maintained along the entire LSP
      path.

   Nesting - Nesting one or In particular, the TE LSP has the same RSVP-TE session and
      LSP ID at every LSR along its path.

   Nesting
      One or more TE LSPs into may be nested within another TE LSP is as
      described in [LSP-HIERARCHY]. [RFC4206]. This technique can be used to nest one
      or more inter-domain TE LSPs into an intra-domain hierarchical LSP
      (H-LSP). Label The label stacking construct may be is used to achieve nesting,
   when appropriate, say nesting
      in packet networks. In the rest of this document, the term H-LSP
      is used to refer to an LSP that allows
   nesting of other LSPs into it and that may or to be nested
      within it. An H-LSP may not be advertised as a TE link. Furthermore, an H-LSP may or may not be an FA-LSP [LSP-
   HIERARCHY]. link within the same
      instance of the routing protocol as was used to advertise the TE
      links from which it was created, in which case it is a Forwarding
      Adjacency (FA) [RFC4206].

   Stitching -
     The concept of LSP stitching as well as the required signaling
     procedures is described in [LSP-STITCHING]. This technique can be
     used to stitch together shorter LSPs (LSP segments) to create a
     single, longer LSP. The LSP segments of an inter-domain TE LSP to an may be
     intra-domain LSP
   segment. A LSPs or inter-domain stitched TE LSP is a TE LSP made up LSPs.

     The process of
   different TE LSP segments within each domain which are "stitched"
   together stitching in the data plane so that an results in a single,
     end-to-end LSP is achieved contiguous LSP. But in the data plane. In the control plane, however, the different LSP
   segments are plane each segment is
     signaled as a separate LSP (with distinct RSVP sessions which are independent
   from sessions) and the
     end-to-end LSP is signaled as yet another LSP with its own RSVP session for
     session. Thus the inter-domain LSP. While control plane operation for LSP stitching is very
     similar to nesting in the control plane, in the data plane, stitching
   allows that for only one nesting.

   An end-to-end inter-domain TE LSP to may be associated with any achieved using one
   intra-domain LSP, and does not require or more
   of the use signaling techniques described. The choice is a matter of label stacks.
   policy for the node requesting LSP setup (the ingress) and policy for
   each successive domain border node. On receipt of an LSP setup
   request (RSVP-TE Path message) for an inter-domain TE LSP, the
   decision of whether to signal the LSP contiguously or whether to nest
   or stitch it to another TE LSP, depends on the parameters signaled TE LSP
   characteristics
   from the head-end ingress node or and on the local node
   configuration, when not explicitly signaled. Also, configuration of the TE LSP local node.

   The stitching segment LSP or H-LSP within the domain may either used to cross a domain may be pre-configured
   pre-established or signaled dynamically based on the demand caused by
   the arrival of the inter-domain TE LSP setup request.

3. Procedures on the domain boundary node Domain Border Node

   Whether an inter-domain TE LSP is contiguous, nested nested, or stitched is
   determined mostly
   limited by the signaling method methods supported by or configured on the
   intermediate nodes, and it is usually the domain boundary border nodes that where
   this restriction applies since other transit nodes are oblivious to
   the mechanism in use. The ingress of the
   inter-domain TE LSP traverses. It also depends on certain parameters
   that may be signaled by further restrict the head-end node for
   choice by setting parameters in the inter-domain TE
   LSP. Path message when it is signaled.

   When a domain boundary border node receives the RSVP Path message for an
   inter-domain TE LSP setup, it MUST carry out the following procedures
   before it can forward the Path message to the next node along the
   path:

     1. Apply any locally configured policies. policies for the domain and the domain border node. These
        policies may restrict the establishment of inter-domain TE LSPs.
        In case of a policy failure, the node SHOULD fail the setup of the LSP and
        originate
        send a PathErr message with error code=2 ("Policy code "Policy control
        failure") and error sub-code="Inter-domain failure"/
        "Inter-domain policy failure"
        (TBD). failure".

     2. Determine the signaling method to be used. The head-end used to cross the domain.
        If the ingress node of the inter-domain TE LSP may have explicitly has specified a
        signaling method or if
        restrictions on the signaling method is not explicitly
        signaled, then methods to be used, these MUST be adhered
        to. Within the freedom allowed by the ingress node, the domain
        border node MAY determine the signaling choose any method
        based on according to local
        configuration and policies. If the desired no resultant signaling method signaled by is
        available or allowed, the head-end cannot be supported
        at this domain border node for some reason, then MUST send a PathErr
        message an error code as described in Section 4.1 MUST be generated. 4.1.

     3. Carry out ERO procedures as described in the next section Section 3 in
        addition to the procedures in [RSVP-TE] [RFC3209] and [RSVP-GMPLS]. [RFC3473].

     4. Perform any path computations as required (say for ERO
        expansion). to determine the path
        across the domain and potentially to select the exit point from
        the domain.

        The path computation procedure itself is outside the scope of this
        document. One such A path computation option is
        addressed supplied in [INTER-DOMAIN-PD-PATH-COMP]. Another
        [INTER-DOMAIN-PD-PATH-COMP], and another option is to use a
        Path Computation Element (PCE) ([PCE]) for path
        computation. Path computation may itself involve determining the
        exit point from the TE domain ([INTER-DOMAIN-PD-PATH-COMP]). [RFC4655].

        4a. In the case of nesting or stitching, either find an existing
            intra-domain TE LSP to carry the inter-domain TE LSP or
            signal a new one, depending on local policy.

       4b.

        In case event of a path computation failure, a PathErr message SHOULD
        be
           generated as described in [INTER-DOMAIN-PD-PATH-COMP].

     5. sent with error code "Routing Problem" using an error value
        selected according to the reason for computation failure.

     In case the event of any other RSVP the receipt of a PathErr message reporting
     signaling failures, failure from within the domain or reported from a
     downstream domain, the domain border node MAY apply crankback
     procedures as described in [RSVP-TE] and [RSVP-GMPLS] SHOULD be followed.
        Follow procedures related to LSP setup failure and Section 3.2. If crankback is not
     applied, or is exhausted, the border node MUST continue with
     PathErr processing as described in Section 3.2, where applicable.

     6. Carry [RFC3209] and [RFC3473].

     In the event of successful processing of a Path or Resv message,
     the domain border node MUST carry out RRO procedures as described
     in Section 3.3, if
        applicable. 3.3.

3.1. Rules on ERO processing Processing

   The ERO that a domain boundary border node receives in the Path message for
   an inter-domain was
   supplied by the ingress node of the TE LSP will be dependent and may have been updated
   by other nodes (for example, other domain border nodes) as the Path
   message was propagated. The content of the ERO depends on several
   factors such as including:

   - the level of visibility that path computation techniques used
   - the head-end node degree of the inter-domain TE
   LSP has into other domains, visibility available to the nodes performing
     path computation techniques applied
   - policy at the head-end node, policy agreements nodes creating/modifying the ERO.

   In general, H-LSPs and LSP segments are used between two domains; etc.
   Eventually, when domain border
   nodes, but there is no restriction on the ERO reaches use of such LSPs to span
   multiple hops entirely within a domain. Therefore, the discussion
   that follows may be equally applied to any node within a domain
   although the term 'domain border node' continues to be used for
   clarity.

   When a Path message reaches the domain boundary border node, the following
   rules SHOULD be used for ERO processing and for further signaling.
   Within a domain, there may be no H-LSPs or LSP segments. If they are
   present, then they may originate and terminate on domain boundary
   nodes. There could also be H-LSPs and LSP segments that may originate
   and terminate at other nodes in the domain. In general, these ERO
   processing rules are also applicable to non-boundary nodes that may
   participate in signaling the inter-domain TE LSP.

   1. If there are any policies related to ERO processing for the
      LSP, they SHOULD be applied and corresponding actions should be taken. E.g. For
      example, there could exist might be a policy to reject inter-domain
        LSP setup request containing an ERO with subobjects identifying EROs that identify
      nodes within the domain. In case of inter-domain LSP setup
      failures due to policy failures related to ERO processing, the
      node SHOULD issue a PathErr with error code=2 ("Policy code "Policy control
        failure") and error sub-code="Inter-domain
      failure"/"Inter-domain explicit route
        rejected" (TBD). rejected".

   2. Section 8.2 of [LSP-HIERARCHY] [RFC4206] describes how a node at the edge of a
      region (domain) processes the ERO in the incoming Path message and uses
      this ERO, to either find an existing H-LSP or signal a new H-LSP
      using the ERO hops. This also process includes adjusting the ERO
      before sending the Path message to the next
        hop node. hop. These
      procedures SHOULD also be followed for nesting or stitching of
      inter-domain TE LSPs to H-LSPs or LSP segments
        respectively. While the domain boundaries are tied to link
        switching capabilities in [LSP-HIERARCHY], these procedures are
        also applicable to other domain boundary nodes in the context
        of this document. LSPs.

   3. If the an ERO subobject identifies a TE link formed by a the
      advertisement of an H-LSP or LSP segment within the domain, either (whether numbered or unnumbered,
        then a
      unnumbered), contiguous LSP signaling MUST NOT be signaled. used. The node MUST
      either
        nest use nesting or stitch the inter-domain TE LSP stitching according to the local H-LSP or LSP
        segment. If, however, the head-end node for capabilities of
      the inter-domain LSP
        has requested that forms the inter-domain TE LSP be contiguous, then
        this link, the parameters signaled in the
      Path message, and local policy. If there is a conflict between the
      capabilities of the LSP that forms the TE link indicated in the
      ERO and the parameters on the Path message, the domain border node
      SHOULD send a PathErr with error code=24 ("Routing
        Problem") and error sub-code="ERO code "Routing Problem"/"ERO
      conflicts with inter-domain signaling method" (TBD) SHOULD be issued. method".

   4. In the absence of any An ERO subobjects, the LSP destination in
        the SESSION object SHOULD be considered a Path message received by a domain border node may
      have a loose hop as the next loose hop.
        A node This may also receive be an ERO with explicit IPv4, IPv6 IP address or
      an AS
        number loose hops. number. In such cases, a the ERO MUST be expanded to
      determine the path computation to expand
        this loose the next hop SHOULD be carried out. Path computation as
        described in [INTER-DOMAIN-PD-PATH-COMP] or using a PCE should
        be used to expand some form of path
      computation that may, itself, generate loose hops.

   5. In the absence of any ERO subobjects beyond the local domain
      border node, the LSP egress (the destination encoded in these cases and to determine the
        intermediate hops.

     5. RSVP
      Session object) MUST be considered as the next loose hop and
      rule 4 applied.

   6. In case the event of any other failures in processing the ERO hop(s), ERO, a PathErr
      message with appropriate error codes SHOULD be sent as described in
        [RSVP-TE] [RFC3209] or [RSVP-GMPLS] SHOULD be generated. [RFC3473].

3.2. LSP setup failure Setup Failure and crankback

   In case of any Crankback

   When an error occurs during LSP setup failures along a PathErr message is sent back
   towards the path due LSP ingress node to policy or
   admission control or other reasons, a corresponding
   PathErr/ResvErr/Notify is generated and sent upstream and/or
   downstream. An ERROR_SPEC comprises of information regarding report the
   point of failure (network element) and details about problem. If the failure
   itself. When an LSP
   traverses multiple domains, a failure could this PathErr will be
   generated in any seen successively by
   each domain along the path and an error notification may
   need to be propagated across multiple domains. So, an error
   notification message itself may be subjected to border node.

   Domain border nodes MAY apply local policies as it
   traverses domain boundaries and to restrict the
   propagation of information about the contents of the domain. For
   example, a boundary domain border node MAY modify domain
   specific replace the information carried in the error message. E.g. the error a
   PathErr message that indicates a specific failure at a specific node address in
   with information that report a more general error with the RSVP ERROR_SPEC or IF_ID ERROR_SPEC or entire
   domain. These procedures are similar to those described for the
   Interface Identifier
   borders of overlay networks in IF_ID ERROR_SPEC may be modified at the
   boundary [RFC4208].

   However:
   - A domain border node for confidentiality reasons. MUST NOT suppress the propagation of a PathErr
     message
   - Nodes other than domain
   boundary border nodes SHOULD NOT modify ERROR_SPEC contents. It is also
   RECOMMENDED that such the contents
     of a policy be implemented only on domain boundary PathErr message
   - Domain border nodes for inter-domain LSPs where preserving SHOULD NOT modify the contents of a PathErr
     message unless domain confidentiality is a specific requirement.

   Also, in case

   Domain border nodes provide an opportunity for crankback rerouting
   [CRANKBACK]. On receipt of a PathErr message generated because of an inter-domain
   LSP setup failure, there may be
   cases when the error is not propagated all the way upstream to the
   head-end node. A PathErr may be intercepted by a boundary node in the domain in which the error is generated (or any other border node along MAY hold the
   path) PathErr and this node may attempt to find an alternate path.  Finding
   an alternate path means finding a new path downstream make
   further attempts to establish the node
   performing re-routing LSP if allowed by local policy and avoiding
   by the failed network elements.  This
   may involve finding a path within the domain experiencing the failure
   or it may mean finding new boundary node(s) or new downstream domain.

   Crankback re-routing depends not only on local configuration and
   ability of a boundary node to do local crankback re-routing, but also
   on any specific parameters requested by the head-end node itself for
   that LSP. In certain cases, it may be desirable for the head-end node
   to exert some control signaled on whether crankback re-routing at intermediate
   nodes is desirable or not. Procedures and extensions described in
   [CRANKBACK] should be followed for crankback re-routing.  When
   crankback re-routing is allowed, a node along the TE LSP path may
   either decide to forward the PathErr Path message upstream towards for the
   head-end node of LSP. Such
   attempts might involve the inter-domain TE LSP or try to determine an computation of alternate path around routes through
   the failure. When crankback re-routing is not
   allowed domain, or if the node cannot perform crankback re-routing, then, on
   receiving selection of different downstream domains. If a PathErr message,
   subsequent attempt is successful, the node should propagate domain border router MUST
   discard the held PathErr
   message upstream.

   [RSVP-GMPLS] allows nodes to generate a targeted Notify message in
   addition to a PathErr/ResvErr message, to expedite error
   notification, but if a Notify Request has been received in all subsequent attempts are
   unsuccessful, the
   corresponding Path/Resv message. This is also applicable to inter- domain TE LSPs which implement [RSVP-GMPLS]. However, since border router MUST send the PathErr
   and Notify need not follow upstream
   toward the same path, their recepient nodes could
   be different. This has certain implications on ingress node. In this latter case, the domain border
   router MAY change the information in the PathErr message to provide
   further crankback re-routing.
   Procedures details and recommendations information aggregation as described
   in [CRANKBACK] should [CRANKBACK].

   Crankback rerouting MAY also be followed for
   Notify message processing for crankback re-routing. used to handle the failure of LSPs
   after they have been established [CRANKBACK].

3.3. RRO processing across domains

   [RSVP-TE] Processing Across Domains

   [RFC3209] defines the RECORD_ROUTE object (RRO) RRO as an optional
   object, which is primarily used for loop detection and
   for providing information about the hops traversed by LSPs. [FAST-REROUTE] also
   uses the RRO to record labels and determine MP. The address or ID
   recorded

   As described for overlay networks in the RRO usually represents a link/interface. This
   information by itself may not be useful enough when LSPs traverse
   domains. [NODE-ID] defines extensions which allows [RFC4208], a domain border node to record
   its node ID in
   MAY filter or modify the RRO, to provide information provided in an additional context for the link
   address/ID.

   Note that there may also be cases while traversing administrative
   domain boundaries, where a network may not wish to expose its
   internal addresses/IDs to preserve confidentiality. In such cases RRO
   MAY be subjected for
   confidentiality reasons according to policies, filtering and modifications at local policy. For example, a
   series of identifiers of hops within a domain
   boundaries. Internal network element identities may MAY be masked off and replaced with boundary information or
   the domain identifier (such as the AS information, by number) or be removed entirely
   leaving just the domain
   boundary entities. This is border nodes.

   Note that a domain border router MUST NOT mask its own presence, and
   MUST include itself in the RRO.

   Such filtering of RRO information does not expected to hamper the working of the
   signaling protocol. This does, however, result in protocol, but the subsequent information loss,
   thereby leading to inefficient paths loss may render
   management diagnostic procedures inoperable or at least make them
   more complicated requiring the coordination of administrators of
   multiple domains.

   Similarly protocol procedures that depend on the presence of RRO
   information may become inefficient. For example, the fast reroute
   procedures defined in [RFC4090] use information in the RRO to
   determine the labels to use and the downstream MP.

3.4. Notify Message Processing

   Notify messages are introduced in [RFC3473]. They may be sent direct
   rather than hop-by-hop, and so may speed the propagation of error
   information. If a domain border router is interested in seeing
   such messages (for example, to enable it to provide protection
   switching), it is RECOMMENDED that the domain border router update
   the Notify Request objects in the Path and Resv messages to show its
   own address following the procedures of [RFC3473].

4. RSVP-TE signaling extensions Signaling Extensions

   The following RSVP-TE signaling extensions are introduced in this
   document. defined to enable
   inter-domain LSP setup.

4.1. Control of downstream choice Choice of signaling method Signaling Method

   In certain mixed many network environments with different techniques (contiguous,
   stitched or nested TE LSPs), there may be a head-end node network-wide policy that
   determines which one of the three inter-domain TE LSP techniques is
   used. In these cases, no protocol extensions are required.

   However, in environments that support more than one technique, an
   ingress node may wish to signal its requirement regarding the signaling method
   used at an intermediate node along constrain the path.

   [LSP-ATTRIBUTES] choice made by domain border
   nodes for each inter-domain TE LSP that it originates.

   [RFC4420] defines the format LSP_Attributes object that can be used to
   signal required attributes of the an LSP. The Attributes Flags TLV
   included in the LSP_ATTRIBUTES object carried in an RSVP Path
   message. The following
   includes Boolean flags that define individual attributes.

   This document defines a new bit in the Flags TLV is used that can be set by the head-end
   ingress node of the an inter-domain TE LSP to restrict the signaling method used
   by the intermediate
   nodes to be contiguous.

   Bit Number 4 (TBD): using contiguous signaling.

   Contiguous LSP bit - this (bit number assignment in Section 8.1).

   This flag is set by the
   head-end ingress node that originates the a Path message
   to set up an inter-domain TE LSP if it desires a requires that the contiguous end-to-end TE
   LSP (in technique is used. This flag bit is only to be used in the control & data plane).
   Attributes Flags TLV.

   When set,
   this indicates that an intermediate LSR receives a Path message containing this bit set (one),
   the node MUST NOT perform any stitching or nesting on the TE LSP and in support of the TE
   LSP MUST be routed as
   any other TE LSP (it must be contiguous end to end). being set up. When this bit is
   cleared, clear (zero), an intermediate node
   MAY decide to perform stitching or
   nesting. nesting according to local policy.

   This bit MUST NOT be modified by any downstream transit node.

   An intermdediate intermediate node that supports the LSP_ATTRIBUTES LSP_Attributes object and the
   Attributes Flags TLV, and also recognizes the "Contiguous LSP" bit,
   but cannot support contiguous TE LSP LSPs, MUST send a Path Error message
   upstream
   with an error code=24 ("Routing Problem") and error sub-
   code="Contiguous code "Routing Problem"/"Contiguous LSP type not
   supported" (TBD). if it receives a Path message with this bit set.

   If an intermediate node receiving a Path message with the "Contiguous
   LSP" bit set in the Flags field of the LSP_ATTRIBUTES, LSP_Attributes, recognizes the
   object, the TLV and the bit and also supports the desired contiguous
   LSP behavior, then it MUST signal a contiguous LSP and MUST set LSP. If the
   "Contiguous LSP signaled" bit in node is a
   domain border node, or if the Flags field of node expands a loose hop in the ERO, it
   SHOULD include an RRO Attributes subobject in the RRO of the
   corresponding Resv message. message with the "Contiguous LSP" bit set to
   report its behavior.

   However, if the intermediate node supports the LSP_ATTRIBUTES LSP_Attributes object
   but does not recognize the Attributes Flags TLV, or supports the TLV
   as well,
   but does not recognize this particular "Contiguous LSP" bit, then it SHOULD
   simply ignore MUST reject
   the above request. It MAY signal any type of LSP Path message with a PathErr message as described in
   this case. [RFC4420].

   The "Contiguous LSP signaled" bit in the Flags field choice of
   the RRO Attributes SHOULD NOT be set.

   An action by an ingress node for an inter-domain LSP requesting that receives a contiguous LSP
   SHOULD examine the RRO Attributes subobject Flags to determine if the
   LSP was indeed signaled contiguous end to end. If the "Contiguous LSP
   signaled" bit is cleared, the head end may take appropriate actions
   such as restricting PathErr when
   requesting the type use of traffic that gets mapped to this LSP,
   tearing down the LSP, or rerouting the LSP around the nodes that do
   not support the a contiguous signaling; etc. Choice of action to be
   taken is upto the implementation on the ingress node and it LSP is out of the scope of this document to recommend any particular action.
   document, but may include the computation of an alternate path.

5. Protection and recovery Recovery of inter-domain Inter-Domain TE LSPs

   The procedures described in Section Sections 3 and 4 MUST be applied to all inter-
   domain
   inter-domain TE LSPs, including bypass tunnels, detour LSPs [FAST-REROUTE]
   or
   [RFC4090], and segment recovery LSPs [SEGMENT-PROTECTION] that may cross domains. [SEGMENT-PROTECTION]. This means
   that these LSPs will also be subjected to ERO processing, policies,
   path computation; computation, etc. Also, note

   Note also that the explicit route paths for these backup LSPs needs to be either configured
   pre-configured, computed and signaled with the protected LSP, or
   computed on-demand at the PLR. Just like as with any inter-domain TE LSP, depending on the
   visibility into the subsequent domain,
   the ERO may comprise of strict
   and/or loose hops. So, if there are or loose hops, backup LSPs would
   also need to undergo loose hop expansion at nodes other than and will depend on the PLR.
   So,
   TE visibility of the PLR computation point into the subsequent domain.

   If loose hops are required created in this case needs to signal the node or link that needs
   to be excluded for backup computation to other downstream nodes along path of the backup path. It is also possible that LSP, ERO
   expansion will be required at some protection schemes
   already signal this information in point along the DETOUR object([FAST-REROUTE]).
   However, path: probably at
   a domain border node. In order that the mechanisms for signaling this are out backup path remains disjoint
   from the protected LSP(s) the node performing the ERO expansion must
   be provided with the path of scope the protected LSPs between the PLR and
   the MP. This information can be gathered from the RROs of this
   document. the
   protected LSPs and is signaled in the DETOUR object for Fast Reroute
   [RFC4090], and using route exclusion [EXCLUDE-ROUTE] discusses one such solution to achieve
   this. for other
   protection schemes.

5.1. Fast Recovery support using MPLS TE Support Using MPLS-TE Fast Reroute (FRR)

   [FAST-REROUTE]

   [RFC4090] describes two methods for local protection for a
   packet TE LSP in case of link, SRLG SRLG, or node failure. This section
   describes how these mechanisms work with the proposed signaling
   solutions for inter-domain TE LSP setup.

5.1.1. Failure within Within a domain (link Domain (Link or node failure) Node Failure)

   The mode of operation of MPLS TE MPLS-TE Fast Reroute to protect a
   contiguous, stitched or nested TE LSP within a domain is identical to
   the existing procedures described in [FAST-REROUTE]. In [RFC4090]. Note that, in the
   case of
   nested nesting or stitched inter-domain TE LSPs, protecting stitching, the intra-domain
   TE H-LSP or end-to-end LSP segment will is automatically protect
   protected by the traffic protection operation performed on the
   inter-domain TE H-LSP or
   stitching segment LSP.

   No new protocol extensions are required for any of the
   signaling methods. required.

5.1.2. Failure of link a Link at a Domain Borders

   This cases arises where two domains are connected by a TE link. In
   this case each domain boundaries

   The procedures for doing link protection of the link at has its own domain
   boundaries border node, and these two
   nodes are connected by the TE link. An example of this case is where
   the same ASBRs of two ASes are connected by a TE link.

   A contiguous LSP can be backed up using any PLR and MP, but if the
   LSP uses stitching or nesting in either of the connected domains, the
   PLR and MP MUST be domain border nodes for contiguous, nested those domains. It will be
   usual to attempt to use the local (connected by the filed link)
   domain border nodes as the PLR and stitched TE LSPs. MP.

   To protect an inter-domain link with MPLS TE MPLS-TE Fast Reroute, a set of
   backup tunnels must be configured or dynamically computed between the
   two domain boundary nodes
   PLR and MP such that they are diversely routed from the protected inter-
   domain link. The region connecting two domains may not be TE enabled.
   In this case, an implementation will have to support
   inter-domain link and the set up of TE
   LSP over a non-TE enabled region.

   For each protected inter-domain TE LSPs.

   Each protected inter-domain LSP traversing using the protected link,
   a NHOP backup inter-domain TE
   link must be selected by a PLR (i.e domain exit boundary
   router), when the TE LSP is first set up. This requires for the PLR assigned to select a an NHOP bypass tunnel terminating at the NHOP.  Finding that is diverse from
   the protected LSP. Such an NHOP bypass tunnel of an inter-AS LSP can be achieved selected by
   analyzing the
   content of the RRO object received RROs in the RSVP Resv message messages of both the available bypass tunnel
   tunnels and the protected TE LSP(s). As LSP. It may be helpful to this process
   if the extensions defined in [RSVP-
   TE], [NODE-ID] are used to clearly
   distinguish nodes and links in the addresses specified RROs.

5.1.3. Failure of a Border Node

   Two border node failure cases exist. If the domain border falls on a
   link as described in the RRO IPv4 subobjects can be node-
   ids and/or interface addresses (with specific recommendation to use previous section, the interface address border node at either
   end of the outgoing Path messages). The PLR may or link may not have sufficient topology information to find where the backup
   tunnel intersects fail. Alternatively, if the protected TE LSP based border falls on the RRO. [NODE-ID]
   proposes a solution to this issue, defining an additional RRO IPv4
   suboject
   border node (as is the case with IGP areas) that specifies a node-id address.

5.1.3. Failure of a boundary single border node

   For each protected inter-domain TE LSP traversing
   may fail.

   It can be seen that if stitching or nesting are used, the boundary failed node
   to
   will be protected, the start or end (or both) or a NNHOP backup stitching segment LSP or
   H-LSP in which case, protection must be selected by the PLR. This
   requires the PLR provided to setup a bypass tunnel terminating at the NNHOP.
   Finding the NNHOP bypass tunnel far end of an inter-domain TE LSP can be
   achieved by analyzing the content
   stitching segment or H-LSP. Thus, where one of the RRO object received these two techniques
   is in the
   RSVP Resv message of both the bypass tunnel and the protected TE
   LSP(s) (see [NODE-ID]). The main difference with node protection,
   between a protected contiguous inter-domain TE LSP and a protected
   nested or stitched inter-domain TE LSP is that use, the PLR and NNHOP (MP)
   in case of a contiguous TE-LSP could will be any node within the domain.
   However, upstream domain entry point in the
   case of a nested or stitched TE-LSP the PLR failure of the domain exit point, and the MP can
   only will be the end-points
   downstream domain exit point in the case of the H-LSP or LSP segment. The consequence
   is that failure of the backup path is likely to be longer and if bandwidth
   protection is desired, for instance, ([FAST-REROUTE]) more resources
   may be reserved in
   domian entry point. Where the domain than necessary.  Note, however, that
   even for border falls at a contiguous LSP, there may be cases where the addresses
   within the single domain could have been masked in the RRO for
   confidentiality reasons, in which case, the RRO for
   border node, both cases will apply.

   If the contiguous LSP may only contain boundary nodes, and so mechanism is in use, normal selection of the
   PLR and MP can only be a
   boundary node.

   Also, while a contiguous LSP does allow backup LSPs to terminate
   inside applied and any node within the domain, there could be policies which domains may reject an LSP
   that originates in another domain from carrying addresses in ERO that
   are local be used
   to this domain. In fill these cases, the roles.

   As before, selection of a suitable backup LSP cannot
   terminate inside the domain and tunnel (in this case an
   NNHOP backup) must terminate only at consider the boundary
   node.

   In case paths of stitching or nesting, when the node to be protected is backed up LSPs and the
   H-LSP/S-LSP tail-end node,
   available NNHOP tunnels by examination of their RROs.

   Note that where the PLR is not immediately upstream of
   this node. Hence, the failure detection failed
   node, error propagation time on failure of H-LSP/S-
   LSP tail-end node is bound to may be longer than that in the case where
   PLR is immediately upstream of the node to be protected.  In delayed unless some mechanism
   such
   cases, it as [BFD-MPLS] is RECOMMENDED that implemented, or unless direct reporting, such
   as through the PLR rely on methods proposed in
   [BFD-MPLS] to rapidly detect H-LSP/S-LSP tail-end node failure. This
   would help in fast recovery. GMPLS Notify message [RFC3473] is employed.

5.2. Protection and recovery Recovery of GMPLS LSPs

   [SEGMENT-PROTECTION] describes GMPLS based segment recovery. This
   allows protection against a span failure, a node failure, or failure
   over any particular portion of a network used by an LSP.

   The
   scenarios domain border failure cases described above for MPLS Fast reroute in Section 5.1 may also apply to segment
   protection. No new extensions are needed for
   occur in GMPLS networks (including packet networks) and can be
   protected against using segment protection of
   LSPs without any additional
   protocol extensions.

   Note that span multiple domains. However, if loose hops are used in the inter-domain LSP
   case, it may not always be possible for the upstream node (outside a
   domain) to identify end-points construction of segment recovery LSP in another
   domain. Even if this was somehow determined, SERO and SRRO in the
   recovery LSP MUST be subjected to ERO working
   and RRO processing rules as
   described above, so policy could disallow explicit control of LSP protection paths signaled for segment recovery inside protection then care is
   required to keep these paths disjoint. If the domain by a node outside paths are signaled
   incrementally then route exclusion [EXCLUDE-ROUTE] may be used to
   ensure that the domain.
   This is treated as paths are disjoint. Otherwise a Segment Protection failure and error handling coordinated path
   computation technique such as
   described in Section 4.2.1 of [SEGMENT-PROTECTION]. that offered by cooperating Path
   Computation Elements [RFC4655] can provide suitable paths.

6. Re-optimization Re-Optimization of inter-domain Inter-Domain TE LSPs

   Re-optimization of a TE LSP is the process of moving the LSP from the
   current path to a more prefered preferable path. This usually involves
   computation the determination of
   the new prefered preferred path and make-before-break signaling procedures [RSVP-TE],
   [RFC3209] to minimize traffic disruption.  The path
   computation procedures involved in re-optimization

   Re-optimization of an inter-domain TE LSP are covered may require a new path in [INTER-DOMAIN-PD-PATH-COMP].  Another option is
   to use PCE-based mechanisms ([PCE]) for re-optimization.

   In the context
   more than one domain.

   The nature of an inter-domain TE LSP, since the inter-domain LSP traverses
   multiple domains, setup mechanism defines how
   re-optimization may can be required in one or more
   domains at a time. Again, depending on applied. If the nature LSP is contiguous then the
   signaling of the LSP and/or
   policies and configuration at domain boundaries (or other nodes), one
   may either always want make-before-break process MUST be initiated by the head-end
   ingress node of as defined in [RFC3209]. But if the inter-domain TE LSP re-optimization is
   limited to a change in path within one domain (that is, if there is
   no change to be notified of any local need for re-optimizations and let the
   head-end initiate domain border nodes) and nesting or stitching are in
   use, the make-before-break process H-LSP or one stitching segment may be independently re-optimized
   within the domain without impacting the end-to-end LSP.

   In all cases, however, the ingress LSP may want wish to
   restrict local re-optimizations with exert control and
   coordination over the domain. re-optimization process.

   [LOOSE-REOPT] describes mechanisms that allow,

     o allow:

   - The head-end ingress node to trigger on every request each node whose next hop is with a loose next hop the re-evaluation of to
     re-evaluate the current path in order to
       detect search for a potentially more optimal
     path. This is done via
       explicit signaling request: the head-end node sets the
       "ERO Expansion request" bit of the SESSION-ATTRIBUTE object
       carried in the RSVP Path message.

     o

   - A node whose with a loose next hop is a loose-hop to signal to inform the head-end ingress node that a
     better path exists. This is performed by sending an
       RSVP PathErr Notify message (error-code = 25), sub-code=6 (Better
       path exists). This indication may either be sent in response to
       a query sent by the head-end node or spontaneously by any node
       having detected a more optimal path.

   The above

   These mechanisms SHOULD be used for re-optimization of a contiguous
   inter-domain TE
   LSP LSP.

7. Security Considerations

   A separate document is being prepared to allow examine the head-end node security aspects
   of the inter-domain TE LSP to initiate
   make-before-break procedures. For nested or stitched TE LSPs, it is
   possible RSVP-TE signaling with special reference to re-optimize the local H-LSP or LSP segment without
   involving the head-end node multi-domain
   scenarios. [INTER-DOMAIN-FRAMEWORK] provides an overview of the inter-domain TE LSP.  This will
   automatically re-route the traffic for the inter-domain TE LSP along
   the new path, within the domain. Such local re-optimizations,
   including parameters
   requirements for re-optimization can be controlled by local
   policy or configuration security in that domain.

7. Security Considerations an MPLS-TE or GMPLS multi-domain
   environment.

   When signaling an inter-domain RSVP-TE LSP, an operator may make use
   of the already defined security features related to RSVP-TE
   (authentication). This already defined for RSVP-TE [RFC3209]. This
   may require some coordination between the domains to share the keys
   (see RFC 2747 [RFC2747] and RFC 3097). [RFC3097]), and care is required to ensure that
   the keys are changed sufficiently frequently. Note that this may
   involve additional synchronization, should the domain boundary
   LSR border nodes
   be protected with MPLS TE Fast Reroute, FRR, since the merge point MP and PLR should also share the
   key.

   For an inter-domain TE LSP, especially when it traverses different
   administrative or trust domains, the following mechanisms (also see
   [INTER-AS-TE-REQS]) SHOULD be
   provided to an operator :- (also see [RFC4216]):

     1) a A way to enforce policies and filters at the domain boundaries borders
        to process the incoming inter-domain TE LSP setup requests
        (Path messages) based on certain agreed trust and service
        levels/contracts between domains. Various LSP attributes
        such as bandwidth, priority; etc priority, etc. could be part of such a
        contract.

     2) a A way for the operator to rate limit rate-limit LSP setup requests
        or error notifications from a particular domain.

     3) a A mechanism to allow policy-based outbound RSVP message
        processing at the domain boundary LSR, border node, which may involve
        filtering or modification of certain addresses in RSVP
        objects and messages.

   Some examples of the policies described above are:-

     1)

     A) An operator may choose to implement some kind of ERO filtering
        policy on the domain boundary LSR border node to disallow or ignore hops
        within the domain from being identified in the ERO of an
        incoming Path message.

     2)

     B) In order to preserve confidentiality, confidentiality of network topology, an
        operator may choose to disallow recording of hops within the
        domain in the RRO or may choose to filter out certain recorded
        RRO addresses at the domain boundary LSR.

     3) border node.

     C) An operator may require the boundary LSR border node to modify the addresses
        of certain messages like PathErr or Notify originated from hops
        within the domain.

   Note that the detailed specification of such mechanisms (local
   implementation) is policies and their
   implementation are outside the scope of this document.

8. IANA Considerations

   The following values have to be defined by

   IANA for this document.
   The registry is, http://www.iana.org/assignments/rsvp-parameters. is requested to make the codepoint allocations described in the
   following sections.

8.1. Attribute Flags for LSP_ATTRIBUTES object

   The following LSP_Attributes Object

   A new flag bit is being defined for to be allocated from the Attributes Flags
   TLV in "Attributes Flags" sub-registry
   of the LSP_ATTRIBUTES object. "RSVP TE Parameters" registry.

                                             Path      Resv      RRO
   Bit   Name                             message   message   sub-object
   ----  -------------------------------  --------  --------  ----------
   XX    Contiguous LSP                     Yes        No        Yes

   The numeric value should XX is to be
   assigned defined by IANA.

   Contiguous LSP bit - Bit Number A value of 4 (Suggested value)

   This flag bit is only to be used in the Attributes Flags TLV on a
   Path message.

   The "Contiguous LSP" bit has a corresponding "Contiguous LSP
   signaled" bit (Bit Number 4) to be used in the RRO Attributes sub-
   object. suggested.

8.2. New Error Codes

   The following

   New RSVP error codes/values are required to be allocated from the
   "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry
   of the "RSVP Parameters" registry.

   For the existing error code "Policy control failure" (value 2), two
   new error sub-codes values are being defined under suggested as follows. The values are suggested
   and are for IANA determination.

     103 = Inter-domain policy failure
     104 = Inter-domain explicit route rejected

   For the RSVP
   error-code existing error code "Routing Problem" (24). The numeric (value 24), two new
   error sub-code value
   should be assigned by IANA. Suggested values are,

     1. are suggested as follows. The values are suggested and
   are for IANA determination.

       21 = Contiguous LSP type not supported - sub-code 21

     2.
       22 = ERO conflicts with inter-domain signaling method - sub-code 22

   These error codes are to be used only in a RSVP PathErr.

9. Acknowledgements

   The following new error sub-codes are being defined under the RSVP
   error-code "Policy control failure" (2). The numeric error sub-code
   value should be assigned by IANA. Suggested values are,

     1. Inter-domain policy failure - sub-code 102

     2. Inter-domain explicit route rejected - sub-code 103

9. Acknowledgements

   The authors would like to acknowledge authors would like to acknowledge the input and helpful comments
   from Adrian Farrel Kireeti Kompella on various aspects discussed in the document.

10. References

10.1. Normative References

   [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
   Extensions to OSPF", RFC 3630 (Updates RFC 2370), September 2003.

   [ISIS-TE] Smit, H., Li, T., "IS-IS extensions

   [RFC2119] Bradner, S., "Key words for Traffic
   Engineering", use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 3784

   [RSVP-TE] 2119, March 1997.

   [RFC3209] Awduche, D., et al, "Extensions to RSVP for LSP Tunnels",
             RFC 3209, December 2001.

   [RSVP-GMPLS] L.

   [RFC3473] Berger, L., et al, "Generalized Multi-Protocol Label
             Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Protocol -
             Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
             January 2003.

   [LSP-HIERARCHY]

   [RFC4206] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized
             MPLS TE", RFC 4206, October 2005.

   [LSP-STITCHING] Ayyangar

   [RFC4420] Farrel, A., Vasseur JP., "LSP Stitching with
   Generalized MPLS TE", (work in progress).

   [CRANKBACK] Farrel A. et al, "Crankback Signaling Extensions for MPLS
   Signaling", (work in progress).

   [LSP-ATTRIBUTES] Farrel A. et al, "Encoding of Attributes for
             Multiprotocol Label Switching (MPLS) Label Switched Path
             (LSP) Establishment Using RSVP-TE", RFC 4420, February
             2006.

10.2. Informative References

   [INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering
   requirements", RFC 4216, November 2005.

   [INTER-AREA-TE-REQS] LeRoux JL, Vasseur JP, Boyle J.

   [LOOSE-REOPT] Vasseur, JP., et al,
   "Requirements for support "Reoptimization of Inter-Area MPLS Traffic Engineering",
   RFC 4105, June 2005.

   [INTER-DOMAIN-FRAMEWORK] Farrel A. et al, "A Framework for Inter-
   Domain MPLS Traffic Engineering", (work in progress).

   [INTER-DOMAIN-PD-PATH-COMP] Vasseur JP., Ayyangar A., Zhang R., "A
   Per-domain path computation method for computing Inter-domain Multiprotocol
             Label Switching (MPLS) Traffic Engineering (TE) loosely
             routed Label Switched Path", Switch Path (LSP)",
             draft-ietf-ccamp-loose-path-reopt, (work in progress).

   [PCE] Ash, G., Farrel,

   [LSP-STITCHING] Ayyangar, A., Kompella, K., and Vasseur, JP., "Path Computation
   Element (PCE) Architecture", draft-ietf-pce-architecture, work in
   progress.

   [GMPLS-OVERLAY] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the
   Overlay Model", RFC 4208, October 2005.

   [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
   for LSP Tunnels",  RFC 4090, May 2005.

   [NODE-ID] Vasseur, Ali and Sivabalan, "Definition of an RRO node-id
   subobject", (work in progress).

   [SEGMENT-PROTECTION] L. Berger et al, "GMPLS Based Segment Recovery",
   (work in progress).

   [BFD-MPLS] R. Aggarwal et al, "BFD For MPLS LSPs", (work in
   progress).

   [LOOSE-REOPT] Vasseur JP. et al, "Reoptimization of an explicit
   loosely routed "Label
             Switched Path Stitching with Generalized MPLS TE paths", Traffic
             Engineering", draft-ietf-ccamp-lsp-stitching, (work in progress).

Appendix 1: Examples

   This Appendix provides some examples to illustrate the inter-domain
   signaling procedures described in this document. We consider one
   example topology which covers inter-domain TE LSP signaling across
   Autonomous systems. Inter-domain TE LSP signaling across other
   domains covered by this document are also meant to follow similar
   signaling procedures, but are not covered here.

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

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

         <================ Inter-AS TE LSP ================>

   1.1 Assumptions

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

   - The various ASBRs are BGP peers, without any IGP running on the
     single hop link interconnecting the ASBRs

   - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE
     extensions (see [OSPF-TE] and [ISIS-TE]). In other words, the ASes
     are TE enabled. Note that each AS can run a different IGP.

   - Each AS can be made of several areas. In this case, the TE LSP will
     rely on the inter-area TE techniques to compute and set up a TE LSP
     traversing multiple IGP areas. For the sake of simplicity, each
     routing domain will be considered as single area in this document,
     but the solutions described in this document does not prevent the
     use of multi-area techniques. In fact, these inter-domain solutions
     are equally applicable to inter-area TE.

   - An inter-AS TE LSP T1 originated at R0 in AS1 and terminating
     at R7 in AS3 with following possible explicit paths:

   o p1 - path defined by ERO with a set of loose node hops crossing
     AS-2, ASBR1(loose)-ASBR4(loose)-ASBR7(loose)-ASBR9(loose)-R7(loose)
   o p2 - path defined by ERO containing a set of strict interface hops
     crossing AS-2,
     ASBR1(loose)-link[ASBR1-ASBR4](strict)-link[ASBR4-R3](strict)
     -link[R3-ASBR7](strict)-link[ASBR7-ASBR9](strict)-R7(loose)

   o p3 - path defined by ERO containing a set of AS number hops
     crossing AS-2,
     ASBR1(loose)-link[ASBR1-ASBR4](strict)-AS3(loose)-R7(loose)

   - The explicit paths (EROs) may have been configured and/or computed
     at the head-end node using any of the path computation schemes.

   1.2 ERO processing

   Let us consider an inter-AS TE LSP setup from R0 to R7, with example
   paths p1, p2. In this example, we will examine the behavior on node
   ASBR4 which is the boundary node for AS-2, for the different
   signaling methods.

   Contiguous:-

   The head-end node, R0, that desires to setup an end-to-end contiguous
   TE LSP, MAY originate a Path message with LSP_ATTRIBUTES object with
   the "Contiguous LSP" bit set in the Attributes Flags TLV.

   For path p1, additional computation to expand the loose hops may be
   required at various hops along the LSP path. When the Path message
   arrives at ASBR4, it may carry out a path computation or use some
   other means to find the intermediate hops to reach ASBR7. It may then
   adjust the outgoing ERO and forward the Path message through the
   intermediate hops in AS-2 to ASBR7.

   For path p2, the ERO next hop points to a node within the domain.
   ASBR4 will then directly forward the Path message to the next hop in
   the ERO.

   For path p3, the ERO nexthop is a loose hop pointing to the
   subsequent AS number. In this case, ASBR4 will perform path
   computation to determine the intermediate hops to reach AS-3. It may
   adjust the ERO based on the computation results. In this case either
   ASBR7 or ASBR8 may be chosen as the exit points from AS-2.
   Similarly, either ASBR9 or ASBR10 may be chosen as entry points into
   AS-3.

   Nesting and Stitching:-

   When the Path message for the inter-AS TE LSP from R0 to R7, reaches
   ASBR4, ASBR4 SHOULD first determine from the ERO hops, the boundary
   node to the domain along the path. In this example, the domain
   boundary node for all paths is ASBR7. It SHOULD then use the ERO hops
   up to ASBR7 to find an existing H-LSP in case of nesting or LSP
   segment in case of stitching, that satisfies the TE constraints. If
   there are no existing H-LSPs or LSP segments and ASBR4 is capable of
   setting up the H-LSP or LSP segment on demand, it SHOULD do so using
   the ERO hops in the Path message of the inter-domain TE LSP. In
   either case, ASBR4 will adjust the ERO in the inter-domain TE LSP and
   will forward the Path message directly to the end-point of the H-LSP
   or LSP segment using the procedures described in [LSP-HIERARCHY].

   In case of path p1, since there are no ERO hops between ASBR4 and
   ASBR7, and ASBR7 hop is loose, ASBR4 may select any existing H-LSP
   (nesting) or LSP segment (stitching) that satisfies the constraints
   or it may compute a path for the H-LSP or LSP segment up to ASBR7 or
   some other intermediate node in AS-2.

   In case of path p2, ASBR4 may either select an existing H-LSP or LSP
   segment with ERO hops link[ASBR4-R3](strict)-link[R3-ASBR7](strict)
   or it may compute a new path for the H-LSP or LSP segment using the
   above hops. In either case, the ERO hops for the H-LSP or LSP segment
   MUST be the same as the signaled strict hops in that domain.

   Processing of path p3 is similar to p1 except that exit points from
   AS-2 and entry points into AS-3 are determined as part of path
   computation.

   Now, suppose, we have a path p4, defined by an ERO comprising a set
   of strict node hops crossing AS-2 as shown below,

   ASBR1(loose)-ASBR4(loose)-ASBR7(strict)-ASBR9(loose)-R7(loose)

   In this case, the ERO nexthop at ASBR4 is ASBR7(strict). In this
   case, ASBR4 will try to find or compute a H-LSP or LSP segment
   directly to ASBR7.

   The main difference between processing of p1 and p4 for nesting or
   stitching is that in case of p1, since the ERO nexthop is a loose
   hop, ASBR4 need not find a H-LSP or LSP segment directly from ASBR4
   to ASBR7. So, there could be multiple H-LSPs or LSP segments between
   ASBR4 and ASBR7 terminating and originating on other nodes. On the
   other hand, for path p4, since the ERO hop to ASBR7 is a strict hop,
   ASBR4 MUST find or signal a H-LSP or LSP segment that directly
   connects ASBR4 and ASBR7.

   1.3 Examples of local protection with MPLS FRR -

   Let us again consider the example topology above and assume that the
   TE LSP is now protected. Let us consider the following backup tunnels
   in the above example,

     o B1 from ASBR1 to ASBR4 following the path
       link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR4](strict) and
       protecting against a failure of the ASBR1-ASBR4 link

     o B2 from ASBR1 to R3 following the path defined by ERO,
       link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR3](strict)-
       link[ASBR3-ASBR6](strict)-link[ASBR6-ASBR5](strict)-R3(strict)
       and protecting against a failure of the ASBR4 node.

     o B3 from ASBR1 to ASBR7 following the path defined by ERO,
       link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR3](strict)-
       link[ASBR3-ASBR6](strict)-ASBR7(loose) and protecting against
       a failure of the ASBR4 node. In this case B3 will need additional
       path computation (loose hop expansion) on ASBR6.

     o B4 from R3 to ASBR9 following the path defined by ERO,
       link[R3-R4](strict)-link[R4-ASBR8](strict)-ASBR9(loose) and
       protecting against a failure of the ASBR7 node. B4 may involve
       loose hop expansion on ASBR8.

     o B5 from ASBR4 to ASBR9 following the path defined by ERO,
       ASBR4-ASBR8(loose)-ASBR9(loose) and protecting against a
       failure of the ASBR7 node. B5 may involve loose hop expansion
       on ASBR8.

   Note that in addition to the ERO for backup tunnels, additional
   information regarding node/link to exclude may need to be signaled as
   well if backup tunnel setup involves path computation at nodes other
   than PLR (say for loose hop expansion).

   The protected inter-domain TE LSP is an inter-AS TE LSP from R0 to R7
   with path p1. Also, for nesting or stitching, let us assume that the
   end-points of the H-LSP or LSP segment in AS-2 are ASBR4 and ASBR7.
   This gives rise to the following two scenarios for node protection:

   Protecting the boundary node at the entry to a domain :-

   Example: protecting against the failure of ASBR4

   If the inter-AS TE LSP in this example, is a contiguous LSP, then the
   PLR is ASBR1 and the NNHOP (MP) could be R3 or any other intermediate
   node along the LSP path, if this information can be gleaned from the
   RRO. A backup tunnel B2 may be used to protect the inter-AS TE LSP
   against failure of ASBR4. However, as explained in Section 5.1.3 if
   RRO information related to R3 has been masked off or if there are
   restrictions on terminating the backup tunnel inside AS-2, then B2
   cannot be used. In this case B3 may be used to protect the LSP
   against failure of ASBR4.

   If the inter-AS TE LSP in this example, is nested or stitched at
   ASBR4 into an intra-domain TE H-LSP or LSP segment between ASBR4 and
   ASBR7, then the PLR is ASBR1 and the NNHOP (MP) is ASBR7. A backup
   tunnel B3 may be used to protect the inter-AS TE LSP against failure
   of ASBR4.

   Protecting the boundary node at the exit of a domain :-

   Example: protecting against failure of ASBR7.

   If the inter-AS TE LSP in this example, is a contiguous LSP, then the
   PLR could be R3
             progress).

10.2. Informative References

   [RFC2747] Baker, F., Lindell, B., and Talwar, B., "RSVP Cryptographic
             Authentication", RFC 2747, January 2000.

   [RFC3097] Braden, R., and the NNHOP (MP) is ASBR9. A backup tunnel B4 may
   be used Zhang, L., "RSVP Cryptographic
             Authentication -- Updated Message Type Value", RFC 3097,
             April 2001.

   [RFC4090] Ping Pan, et al, "Fast Reroute Extensions to protect the inter-AS TE RSVP-TE
             for LSP against failure of ASBR7.

   If Tunnels",  RFC 4090, May 2005.

   [RFC4105] LeRoux, JL., Vasseur, JP., Boyle, J., et al, "Requirements
             for Inter-Area MPLS Traffic Engineering", RFC 4105, June
             2005.

   [RFC4208] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the inter-AS TE LSP
             Overlay Model", RFC 4208, October 2005.

   [RFC4216] Zhang, R., et al, "MPLS Inter-Autonomous System (AS)
             Traffic Engineering (TE) Requirements", RFC 4216, November
             2005.

   [RFC4655] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation
             Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [BFD-MPLS] Aggarwal, R., et al, "BFD For MPLS LSPs",
             draft-ietf-bfd-mpls, (work in this example, is nested or stitched at
   ASBR4 into an intra-domain TE H-LSP or LSP segment between ASBR4 progress).

   [CRANKBACK] Farrel, A., et al, "Crankback Signaling Extensions for
             MPLS and
   ASBR7, then the PLR is ASBR4 GMPLS RSVP-TE", draft-ietf-ccamp-crankback, (work
             in progress).

   [EXCLUDE-ROUTE] Lee, CY., Farrel, A., and the NNHOP (MP) is ASBR9. A backup
   tunnel B5 may be used De Cnodder, S., "Exclude
             Routes - Extension to protect the inter-AS TE LSP against failure RSVP-TE",
             draft-ietf-ccamp-rsvp-te-exclude-route, (work in progress).

   [INTER-DOMAIN-FRAMEWORK] Farrel, A., et al, "A Framework for
             Inter-Domain MPLS Traffic Engineering",
             draft-ietf-ccamp-inter-domain-framework, (work in
             progress).

   [INTER-DOMAIN-PD-PATH-COMP] Vasseur, JP., Ayyangar, A., and
             Zhang, R., "A Per-domain path computation method for
             computing Inter-domain Traffic Engineering (TE) Label
             Switched Paths (LSPs)",
             draft-ietf-ccamp-inter-domain-pd-path-comp, (work in
             progress).

   [NODE-ID] Vasseur, JP., Ali, Z., and Sivabalan, S., "Definition of ASBR7.

Author's addresses an
             RRO node-id subobject", draft-ietf-mpls-nodeid-subobject,
             (work in progress).

   [SEGMENT-PROTECTION] Berger, L., et al, "GMPLS Based Segment
             Recovery", draft-ietf-ccamp-gmpls-segment-recovery, (work
             in progress).

11. Authors' Addresses

   Adrian Farrel
   Old Dog Consulting

   E-mail: adrian@olddog.co.uk

   Arthi Ayyangar
Juniper Networks, Inc.
1194 N.Mathilda Ave
Sunnyvale,
   Nuova Systems
   2600 San Tomas Expressway
   Santa Clara, CA 94089
USA
e-mail: arthi@juniper.net  95051
   US

   Email: arthi@nuovasystems.com
   Jean Philippe Vasseur
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough , MA - 01719
   USA
e-mail:

   Email: jpv@cisco.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.