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

Versions: 00 01 02 draft-ietf-ccamp-inter-domain-rsvp-te

IETF Internet Draft                             Arthi Ayyangar(Editor)
Proposed Status: Standards Track                      Juniper Networks
Expires: April 2005
                                         Jean-Philippe Vasseur(Editor)
                                                   Cisco Systems, Inc.


                                                          October 2004


      Inter domain GMPLS Traffic Engineering - RSVP-TE extensions


            draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt


Status of this Memo


This document is an Internet-Draft and is subject to all provisions of
section 3 of RFC 3667. 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
become aware will be disclosed, in accordance with RFC 3668.


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.


Copyright Notice


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


Abstract


This document describes extensions to Generalized Multi-Protocol Label
Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering
(RSVP-TE) signaling required 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. 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




Ayyangar and Vasseur                                            [Page 1]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



path computation responsibility. Examples of such domains include
Autonomous Systems, IGP areas and GMPLS overlay networks.



1. Introduction


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


   This document presents the RSVP-TE signaling extensions for the setup
   and maintenance of TE LSPs that span multiple domains. The signaling
   procedures described in this document are applicable to both packet
   LSPs ([RSVP-TE]) and non-packet LSPs that use RSVP-TE GMPLS
   extensions as described in [RSVP-GMPLS]. Three different signaling
   methods along with the corresponding RSVP-TE extensions and
   procedures are proposed in this document.


   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 and GMPLS overlay networks ([GMPLS-
   OVERLAY]).


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


1.2. Terminology


   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


   FA: Forwarding Adjacency


   FA-LSP:  Forwarding Adjacency LSP


   LSP: MPLS Label Switched Path




Ayyangar and Vasseur                                            [Page 2]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



   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 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 - Record Route Object


   TE: Traffic Engineering


   TE LSP: Traffic Engineering Label Switched Path


   TE-link: Traffic Engineering link


   TED: MPLS Traffic Engineering Database



2. Signaling overview


   The RSVP-TE signaling of a TE LSP within a single domain is described
   in [RSVP-TE] and [RSVP-GMPLS]. This document focuses on the RSVP-TE
   signaling extensions required for inter-domain TE LSP setup and
   maintenance. Any other extensions that may be needed for routing or
   path computation are outside the scope of this document.


2.1. Signaling 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 across multiple domains using RSVP-TE signaling procedures
   described in [RSVP-TE]and [RSVP-GMPLS]. No additional TE LSPs are
   required to signal 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 more TE LSPs into another TE LSP is
   described in [LSP-HIERARCHY]. This technique can also be used to nest
   one or more inter-domain TE LSPs into an intra-domain FA-LSP. While




Ayyangar and Vasseur                                            [Page 3]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



   similar to stitching in the control plane, in the data plane, nesting
   allows for one or more inter-domain LSPs to be transported over a
   single intra-domain FA-LSP using the label stacking construct.


   Stitching - A stitched TE LSP is a TE LSP made up of different TE LSP
   segments within each domain which are "stitched" together in the data
   plane so that an end-to-end LSP is achieved in the data plane. In the
   control plane, however, the different LSP segments are signaled as
   distinct RSVP sessions which are independent from the RSVP session
   for the inter-domain LSP. Signaling procedures described in [LSP-
   HIERARCHY] are used to stitch an inter-domain TE LSP to a local LSP
   segment. The concept of LSP stitching and additional signaling
   extensions needed are described in detail in the following section.


   On receipt of an LSP setup request 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 signaled TE LSP
   characteristics or the local node configuration, when not explicitly
   signaled. Also, the TE LSP segment or FA-LSP within the domain may
   either be pre-configured or signaled dynamically based on the arrival
   of the inter-domain TE LSP setup request.



3. LSP Stitching


   LSP stitching is a special case of LSP hierarchy ([LSP-HIERARCHY])
   where the desired switching type of the LSP and the switching
   capability of the LSP segment are such that exactly one LSP may be
   admitted into an LSP segment. E.g. an inter-domain lambda LSP may be
   stitched into an intra-domain lambda LSP, an MPLS LSP (PSC) can be
   stitched into another MPLS LSP (PSC). The following sections analyze
   the similarities and differences of various aspects associated with
   nesting and stitching and describe additional signaling extensions
   required for LSP stitching.


3.1. Routing aspects


   An LSP segment is similar to an FA-LSP in that an LSP segment like an
   FA-LSP is created and treated like a Traffic Engineering link (TE-
   link) between two GMPLS nodes whose path transits zero or more GMPLS
   nodes in the same instance of the GMPLS control plane. These TE-links
   may be numbered or unnumbered. For an unnumbered LSP segment, the
   assignment and handling of the local and remote link identifiers is
   specified in [RSVP-UNNUM]. Like in the case of Forwarding Adjacency
   (FA), a routing adjacency will not usually be established over an LSP
   segment. ISIS/OSPF would, however, flood the TE information
   associated with an LSP segment which will exist in the TE database
   (TED) and can be used for path computation. The TE parameters defined




Ayyangar and Vasseur                                            [Page 4]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



   for an FA in [LSP-HIERARCHY] are also applicable to an LSP segment
   TE-link.


   Note that, while an FA-LSP TE-link can admit one or more LSPs over
   it, an LSP segment can admit exactly one LSP over it. So, once an LSP
   is stitched into an LSP segment, the Unreserved bandwidth on the LSP
   segment is set to and advertised to be zero. This prevents any more
   LSPs from being computed and admitted over the LSP segment TE-link.
   Multiple LSP segments between the same pair of nodes may be bundled
   using the concept of Link Bundling ([BUNDLING]) into a single TE-
   link. When any component LSP segment is allocated for an LSP, its
   Unreserved bandwidth MUST be set to zero and the Minimum and Maximum
   LSP bandwidth of the TE-link SHOULD be recalculated.


3.2. Signaling aspects


   Like any TE-link or FA, a signaling adjacency would be established
   between the end nodes of the LSP segment and this will be used to
   signal an LSP over the LSP segment. When an RSVP-TE LSP is signaled
   over an LSP segment, the Path message MUST contain an IF_ID RSVP_HOP
   object [RSVP-GMPLS] and the data interface identification MUST
   identify the LSP segment. For the purpose of ERO and RRO as well, an
   LSP segment is treated exactly like an FA.


   The main difference between signaling an LSP over an LSP segment
   instead of over an FA-LSP is that no Labels are allocated and
   exchanged for the end-to-end LSP (inter-domain LSP) over the LSP
   segment hop. So, exactly one end-to-end LSP is associated with one
   LSP segment. If a node at the head-end of an LSP segment receives a
   Path Msg for an LSP that identifies the LSP segment in the ERO and
   the LSP segment bandwidth has already been allocated to some other
   LSP, then regular rules of RSVP-TE pre-emption apply. If the LSP
   request over the LSP segment cannot be satisfied, then the node
   SHOULD send back a PathErr with the error codes as described in
   [RSVP-TE].


   Additional signaling extensions for stitching are described in the
   next section.


3.3. RSVP-TE signaling extensions


   The signaling extensions described here MUST be used if a packet LSP
   is being stitched to another packet LSP. These extensions are
   optional for non-packet LSPs and SHOULD be used if no other local
   mechanisms exist to automatically detect a requirement for stitching
   at both the ingress and egress nodes of the LSP segment. Also, these
   extensions are applicable to the local LSP segment and not for the
   inter-domain TE LSP.




Ayyangar and Vasseur                                            [Page 5]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



   If a domain boundary node (or any other node) desires to perform LSP
   stitching of an LSP, then it MUST indicate this in the Path message
   for the intra-domain LSP segment. This signaling explicitly informs
   the egress node for the LSP segment that the ingress node is planning
   to perform stitching over the LSP segment. This will allow the egress
   of the LSP segment to allocate the correct label(s) as explained
   below. Also, so that the head-end node can ensure that correct
   stitching actions were carried out at the egress node, a new flag is
   defined below in the RRO subobject to indicate that the LSP segment
   can be used for stitching.


   In order to request LSP stitching on the LSP segment, we define a new
   flag bit in the Attributes Flags TLV of the LSP_ATTRIBUTES object
   defined in [LSP-ATTRIBUTES]:


   0x02 (TBD): LSP stitching desired bit - This flag will be set in the
   Attributes Flags TLV of the LSP_ATTRIBUTES object in the Path message
   for the local intra-domain LSP segment by the head-end node of the
   LSP segment (boundary node) that desires LSP stitching. This flag
   MUST not be modified by any other nodes in that domain.


   An intra-domain LSP segment can only be used for stitching if
   appropriate label actions were carried out at the egress node of the
   LSP segment. In order to indicate this to the head-end node of the
   LSP segment, the following new flag bit is defined in the RRO
   Attributes sub-object: 0x02 (TBD): LSP segment stitching ready.


   If an egress node receiving a Path message, supports the
   LSP_ATTRIBUTES object and the Attributes Flags TLV, and also
   recognizes the "LSP stitching desired" flag bit, but cannot support
   the requested stitching behavior, then it MUST send back a PathErr
   message with an error code of "Routing Problem" and an error sub-
   code=16 (TBD) "Stitching unsupported" to the head-end node of the
   intra-domain LSP segment.


   If an egress node receiving a Path message with the "LSP stitching
   desired" flag set, recognizes the object, the TLV and the flag and
   also supports the desired stitching behavior, then it MUST allocate a
   non-NULL label for that LSP segment in the corresponding Resv
   message. Now, so that the head-end node can ensure that the correct
   label actions will be carried out by the egress node and that the LSP
   segment can be used for stitching, the egress node MUST set the "LSP
   segment stitching ready" bit defined in the RRO Attribute sub-object.
   Also, when the egress node for the LSP segment receives a Path
   message for an inter-domain LSP using this LSP segment, it SHOULD
   first check if it is also the egress for the inter-domain TE LSP. If
   the egress node is the egress for both the intra-domain LSP segment
   as well as the inter-domain TE LSP, and this is a packet LSP which




Ayyangar and Vasseur                                            [Page 6]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



   requires Penultimate Hop Popping (PHP), then the node MUST send back
   a Resv refresh for the intra-domain LSP segment with a new label
   corresponding to the NULL label.


   Finally, if the egress node for the intra-domain LSP segment supports
   the LSP_ATTRIBUTES object but does not recognize the Attributes Flags
   TLV, or supports the TLV as well but does not recognize this
   particular flag bit, then it SHOULD simply ignore the above request.


   An ingress node requesting stitching MUST examine the RRO Attributes
   sub-object flag corresponding to the egress node for the intra-domain
   LSP segment, to make sure that stitching actions were carried out at
   the egress node. It MUST NOT use the LSP segment for stitching if the
   "LSP segment stitching ready" flag is cleared.


   The egress node MUST not allocate any Label in the Resv message for
   the inter-domain TE LSP. Similarly, in case of bidirectional inter-
   domain TE LSP, no Upstream Label is allocated over the LSP segment in
   the corresponding Path message. An ingress node stitching an inter-
   domain LSP to an LSP segment MUST ignore any Label object received in
   the Resv for the inter-domain TE LSP.




4. Procedures on the domain boundary node


   Whether an inter-domain TE LSP is contiguous, nested or stitched is
   determined mostly by the signaling method supported by or configured
   on the intermediate nodes, usually the domain boundary nodes that the
   inter-domain TE LSP traverses through. It may also depend on certain
   parameters signaled by the head-end node for the inter-domain TE LSP.
   When a domain boundary 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 hop node,
       - apply any locally configured policies
       - determine the signaling method to be used based on any desired
   characteristics signaled by the head-end node of the inter-domain TE
   LSP or if the signaling method is not explicitly signaled, then
   determine the signaling method based on local configuration and
   policies
       - depending on the signaling method, carry out any specific ERO
   procedures, as applicable, as described in the next section
       - based on the signaling method to be used, determine the next
   hop node to forward the RSVP Path message
       - in 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
       - perform any path computations if required. The path computation




Ayyangar and Vasseur                                            [Page 7]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



   procedure itself is outside the scope of this document. The various
   path computation options are addressed in [INTER-DOMAIN-PATH-COMP]
       - in case of any failures (admission control, policy, signaling;
   etc), originate corresponding error notifications


4.1. Rules on ERO processing


   The ERO that a domain boundary node receives in the Path message for
   an inter-domain TE LSP will be dependent on several factors such as
   the level of visibility that the head-end node of the inter-domain TE
   LSP has into other domains, the path computation techniques applied
   at the head-end node, policy agreements between two domains; etc.
   Eventually, when the ERO reaches a domain boundary node, the
   following rules SHOULD be used for ERO processing and signaling.
   Within a domain, there may be no FA-LSPs or LSP segments. If they are
   present, then they may originate and terminate on domain boundary
   nodes. There could also be FA-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.
           - If there are any policies related to ERO processing for
   certain LSPs, they SHOULD be applied and corresponding actions should
   be taken. E.g. if there exists a policy to reject LSP setup request
   containing ERO with sub-objects identifying nodes within the domain,
   then a PathErr with the appropriate error code should be sent back
           - Section 8.2 of [LSP-HIERARCHY] 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 FA-LSP or
   signal a new FA-LSP using the ERO hops. This also includes adjusting
   the ERO before sending the Path message to the next hop node. These
   procedures SHOULD also be followed for nesting or stitching of inter-
   domain TE LSPs to FA-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. E.g. in case of a
   path computation domain, you have reached the boundary when the ERO
   hop is no longer reachable via the TE database (TED).
           - In case of any failure in processing the ERO hop(s), a Path
   Error message with appropriate error code ([RSVP-TE]) SHOULD be
   generated.


4.2. LSP setup failure and crankback


   In case of any setup failures along the path due to policy or
   admission control or other reasons, a corresponding Path Error SHOULD
   be generated and sent upstream. The propagation of Path Error
   upstream may be limited to within the domain or it may be sent all
   the way upstream to the head-end node of the inter-domain TE LSP.




Ayyangar and Vasseur                                            [Page 8]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



   This depends not only on local configuration and ability of a
   boundary node to do local crankback, 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 on the ability for the boundary nodes to make use of
   crankback. See [CRANKBACK] for the definition of those bits. When
   crankback is allowed, the domain boundary node can either decide to
   forward the Path Error message upstream to the head-end node of the
   inter-domain TE LSP or try to select another egress boundary node.
   When crankback is not allowed or if the node has not been configured
   to do a crankback, then a boundary node, when receiving a Path Error
   message from a downstream boundary node MUST propagate the Path Error
   message up to the head-end node of the inter-domain TE LSP.



5. RSVP-TE signaling extensions


   The following RSVP-TE signaling extensions are introduced in this
   document.


5.1. Control of downstream choice of signaling method


   In certain mixed environments with different techniques (contiguous,
   stitched or nested TE LSPs), a head-end node of the inter-domain TE
   LSP may wish to signal its requirement regarding the signaling method
   used at the domain boundaries.


   [LSP-ATTRIBUTES] defines the format of the Attributes Flags TLV
   included in the LSP_ATTRIBUTES object carried in an RSVP Path
   message. The following bit in the Flags TLV is used by the head-end
   node of the inter-domain TE LSP to restrict the signaling method used
   by the domain boundary nodes to be contiguous.


   0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end
   node that originates the inter-domain TE LSP if it desires a
   contiguous end-to-end TE LSP (in the control & data plane). When set,
   this indicates that a boundary node MUST not perform any stitching or
   nesting on the TE LSP and the TE LSP MUST be routed as any other TE
   LSP (it must be contiguous end to end). When this bit is cleared, a
   boundary node may decide to perform stitching or nesting. A mid-point
   node not supporting contiguous TE LSP MUST send a Path Error message
   upstream with an error code of "Routing Problem" and error sub-
   code=17 (TBD) (Contiguous LSP type not supported). This bit MUST not
   be modified by any downstream node.








Ayyangar and Vasseur                                            [Page 9]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



5.2. LSP stitching


   RSVP-TE signaling extensions for LSP stitching have been described in
   section 3. A new flag bit, "LSP stitching desired bit" is defined in
   the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in
   [LSP-ATTRIBUTES], to request stitching over the LSP segment.



6. Example


6.1. Example topology


   In this document, we will consider the following example topology for
   inter-domain TE LSPs setup and maintenance. In this example, a domain
   is an Autonomous system (AS).


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


6.1.1. Assumptions


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


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


   - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE
   extensions (see [OSPF-TE] and [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.





Ayyangar and Vasseur                                           [Page 10]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



   - A protected inter-AS TE LSP T1 originated at R0 in AS1 and
   terminating at R6 in AS3 with following possible paths:


   LSP hops: R0-X1-ASBR1-ASBR4-R3-ASBR7-ASBR9-R6


   o p1 - a set of loose node hops crossing AS-2
     R0-X1-ASBR1(loose)-ASBR4(loose)-ASBR7(loose)-ASBR9(loose)-R6


   o p2 - a set of strict interface hops crossing AS-2
     R0-X1-ASBR1(loose)-link[ASBR1-ASBR4](strict)-link[ASBR4-R3](strict)
     -link[R3-ASBR7](strict)-link[ASBR7-ASBR9](strict)-R6


   - A set of backup tunnels:


   o B1 from ASBR1 to ASBR4 following the path ASBR1-ASBR2-ASBR4 and
   protecting against a failure of the ASBR1-ASBR4 link


   o B2 from ASBR1 to R3 following the path
   ASBR1-ASBR2-ASBR3-ASBR6-ASBR5-R3 and protecting against a failure of
   the ASBR4 node.


   o B3 from ASBR1 to ASBR7 following the path
   ASBR1-ASBR2-ASBR3-ASBR6-ASBR7 and protecting against a failure of the
   ASBR4 node.


   o B4 from R3 to ASBR9 following the path R3-R4-ASBR8-ASBR10-ASBR9 and
   protecting against a failure of the ASBR7 node.


   o B5 from ASBR4 to ASBR9 following the path ASBR4-ASBR8-ASBR10-ASBR9
   and protecting against a failure of the ASBR7 node.


6.2. Setup Operation


   Let us consider an inter-AS TE LSP setup from R0 to R6, with example
   paths p1, p2 each. 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




Ayyangar and Vasseur                                           [Page 11]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



   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 may then directly forward the Path message to the next hop in
   the ERO.


   Nesting and Stitching:-


   When the Path message for the inter-AS TE LSP from R0 to R6, 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
   upto ASBR7 to find an existing FA-LSP in case of nesting or LSP
   segment in case of stitching, that satisfies the TE constraints. If
   there are no existing FA-LSPs or LSP segments and ASBR4 is capable of
   seting up the FA-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 FA-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 FA-LSP
   (nesting) or LSP segment (stitching) that satisfies the constraints
   or it may compute a path for the FA-LSP or LSP segment upto ASBR7 or
   some other intermediate node in AS-2.


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


   Now, suppose, we have a path p3, as a set of strict node hops
   crossing AS-2 as defined below,


   R0-X1-ASBR1(loose)-ASBR4(strict)-ASBR7(strict)-ASBR9(loose)-R6


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


   The main difference between processing of p1 and p3 for nesting or
   stitching is that in case of p1, since the ERO nexthop is a loose
   hop, ASBR4 need not find a FA-LSP or LSP segment directly from ASBR4
   to ASBR7. So, there could be multiple FA-LSPs or LSP segments between
   ASBR4 and ASBR7. On the other hand, for path p3, since ASBR7 is a




Ayyangar and Vasseur                                           [Page 12]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



   strict hop, ASBR4 MUST find or signal a FA-LSP or LSP segment that
   connects ASBR4 and ASBR7.



7. Protection and recovery of inter-domain TE LSPs


7.1. Fast Recovery support using MPLS TE Fast Reroute


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


7.1.1. Failure within a domain (link or node failure)


   The mode of operation of 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 case of
   nested or stitched inter-domain TE LSPs, protecting the intra-domain
   TE FA-LSP or LSP segment will automatically protect the traffic on
   the inter-domain TE LSP. No new extensions are required for any of
   the signaling methods.


7.1.2. Failure of link at domain boundaries


   The procedures for doing link protection of the link at domain
   boundaries is the same for contiguous, nested and stitched TE LSPs.


   To protect an inter-domain link with MPLS TE Fast Reroute, a set of
   backup tunnels must be configured or dynamically computed between the
   two domain boundary nodes 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 the set up of TE
   LSP over a non-TE enabled region.


   For each protected inter-domain TE LSP traversing the protected link,
   a NHOP backup 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
   to select a bypass tunnel terminating at the NHOP. Finding the NHOP
   bypass tunnel of an inter-AS LSP can be achieved by analyzing the
   content of the RRO object received in the RSVP Resv message of both
   the bypass tunnel and the protected TE LSP(s). As defined in [RSVP-
   TE], the addresses specified in the RRO IPv4 subobjects can be node-
   ids and/or interface addresses (with specific recommendation to use
   the interface address of the outgoing Path messages). The PLR may or
   may not have sufficient topology information to find where the backup
   tunnel intersects the protected TE LSP based on the RRO. [NODE-ID]
   proposes a solution to this issue, defining an additional RRO IPv4




Ayyangar and Vasseur                                           [Page 13]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



   suboject that specifies a node-id address.


   Example: The ASBR1-ASBR4 link is protected by the backup tunnel B1
   that follows the ASBR1-ASBR2-ASBR4 path


7.1.3. Failure of a boundary node


   For each protected inter-domain TE LSP traversing the boundary node
   to be protected, a NNHOP backup must be selected by the PLR. This
   requires the PLR to setup a bypass tunnel terminating at the NNHOP.
   Finding the NNHOP bypass tunnel of an inter-domain TE LSP can be
   achieved by analyzing the content of the RRO object received 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 the PLR and NNHOP (MP)
   in case of a contiguous TE-LSP could be any node within the domain.
   However, in case of a nested or stitched TE-LSP the PLR and MP can
   only be the end-points of the FA-LSP or LSP segment. The consequence
   is that the backup path is likely to be longer and if bandwidth
   protection is desired, for instance, ([FAST-REROUTE]) more resources
   may be reserved in the domain than necessary.


   Let us again consider the example topology of section 4.1. The
   protected inter-domain TE LSP is an inter-AS TE LSP from R0 to R6
   with path p1. Also, for nesting or stitching, let us assume that the
   end-points of the FA-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. A backup tunnel B2 may be used to protect
   the inter-AS TE LSP against failure of ASBR4.


   If the inter-AS TE LSP in this example, is nested or sticthed at
   ASBR4 into an intra-domain TE FA-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.





Ayyangar and Vasseur                                           [Page 14]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



   If the inter-AS TE LSP in this example, is a contiguous LSP, then the
   PLR could be R3 and the NNHOP (MP) is ASBR9. A backup tunnel B4 may
   be used to protect the inter-AS TE LSP against failure of ASBR7.


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


7.2. Protection and recovery of GMPLS LSPs


   [E2E-RECOVERY] describes the signaling extensions to support end-to-
   end GMPLS LSP recovery. Signaling methods defined above for inter-
   domain RSVP-TE LSPs also apply to recovery LSPs signaled for end-to-
   end protection of inter-domain GMPLS LSPs. Any other protection
   mechanisms that are developed for GMPLS LSPs SHOULD also take into
   account inter-domain considerations.



8. Re-optimization of 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 path. This usually involves
   computation of the new prefered path and make-before-break signaling
   procedures [RSVP-TE], to minimize traffic disruption. The path
   computation procedures involved in re-optimization of an inter-domain
   TE LSP are covered in [INTER-DOMAIN-PATH-COMP].


   In the context of an inter-domain TE LSP, since the LSP traverses
   multiple domains, re-optimization may be required in one or more
   domains at a time. Again, depending on the nature of the LSP and/or
   policies and configuration at domain boundaries (or other nodes), one
   may either always want the head-end node of the inter-domain TE LSP
   to be notified of any local need for re-optimizations and let the
   head-end initiate the make-before-break process or one may want to
   restrict local re-optimizations with the domain.


   [LOOSE-REOPT] describes mechanisms that allow,
           - The head-end node to trigger on every node 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 node sets the "ERO Expansion request"
   bit of the SESSION-ATTRIBUTE object carried in the RSVP Path message.
           - A node whose next hop is a loose-hop to signal to the head-
   end node 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 either be sent in response to a




Ayyangar and Vasseur                                           [Page 15]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



   query sent by the head-end node or spontaneously by any node having
   detected a more optimal path.


   The above mechanisms SHOULD be used for a contiguous inter-domain TE
   LSP to allow the head-end node of the inter-domain TE LSP to initiate
   make-before-break procedures. For nested or stitched TE LSPs, it is
   possible to re-optimize the local FA-LSP or LSP segment without
   involving the head-end node 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 for re-optimization can be controlled by local
   policy or configuration in that domain.



9. Security Considerations


   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 may require some coordination between the
   domains to share the keys (see RFC 2747 and RFC 3097).



10. IANA Considerations


   The following values have to be defined by IANA for this document.
   The registry is, http://www.iana.org/assignments/rsvp-parameters.


10.1. Attribute Flags for LSP_ATTRIBUTES object


   The following two new flag bits are being defined for the Attributes
   Flags TLV in the LSP_ATTRIBUTES object. The numeric values should be
   assigned by IANA.


   Contiguous LSP bit - 0x01 (Suggested value)


   LSP stitching desired bit - 0x02 (Suggested value)


   Both these flag bits are only to be used in the Attributes Flags TLV
   on a Path message.


   The 'LSP stitching desired bit' has a corresponding 'LSP segment
   stitching ready' bit to be used in the RRO Attributes sub-object.










Ayyangar and Vasseur                                           [Page 16]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



10.2. New Error Codes


   The following two new error sub-codes are being defined under the
   RSVP error-code "Routing Problem" (24). The numeric error sub-code
   values should be assigned by IANA.


   Contiguous LSP type not supported - sub-code 17 (Suggested value)


   Stitching unsupported - sub-code 16 (Suggested value)


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



11. Acknowledgements


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



12. References


12.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 for Traffic
   Engineering", RFC 3784


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


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


   [LSP-HIERARCHY] Kompella K., Rekhter Y., "LSP Hierarchy 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", (work in progress).


   [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
   for LSP Tunnels", (work in progress)




Ayyangar and Vasseur                                           [Page 17]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



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


   [E2E-RECOVERY] J.P. Lang et al, "RSVP-TE Extensions in support of
   End-to-End GMPLS-based Recovery", (work in progress).


12.2. Informative References


   [INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering
   requirements", (work in progress).


   [INTER-AREA-TE-REQS] LeRoux JL, Vasseur JP, Boyle J. et al,
   "Requirements for support of Inter-Area MPLS Traffic Engineering",
   (work in progress).


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


   [INTER-DOMAIN-PATH-COMP] Vasseur JP., Ayyangar A., Zhang R., "Inter-
   domain MPLS Traffic Engineering LSP path computation methods", (work
   in progress).


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


   [RSVP-UNNUM] Kompella K., Rekhter Y., "Signalling Unnumbered Links in
   Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC
   3477, January 2003.


   [BUNDLING] Kompella K., Rekhter Y., "Link Bundling in MPLS Traffic
   Engineering", (work in progress).


   [LOOSE-REOPT] Vasseur JP. et al, "Reoptimization of an explicit
   loosely routed MPLS TE paths", (work in progress).



Author's addresses















Ayyangar and Vasseur                                           [Page 18]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004




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


Jean Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
e-mail: 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.














Ayyangar and Vasseur                                           [Page 19]


draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt            October 2004



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 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 (2004).  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.































Ayyangar and Vasseur                                           [Page 20]


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