Skip to main content

Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)
draft-ietf-ccamp-lsp-stitching-06

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5150.
Authors Kireeti Kompella , Adrian Farrel , JP Vasseur , Arthi Ayyangar
Last updated 2020-01-21 (Latest revision 2007-04-23)
Replaces draft-ayyangar-ccamp-lsp-stitching
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 5150 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Ross Callon
Send notices to (None)
draft-ietf-ccamp-lsp-stitching-06
Network Working Group                                        A. Ayyangar
Internet-Draft                                             Nuova Systems
Intended status: Standards Track                             K. Kompella
Expires: October 2007                                   Juniper Networks
                                                             JP. Vasseur
                                                     Cisco Systems, Inc.
                                                               A. Farrel
                                                      Old Dog Consulting
                                                              April 2007

      Label Switched Path Stitching with Generalized Multiprotocol
            Label Switching Traffic Engineering (GMPLS TE)

                  draft-ietf-ccamp-lsp-stitching-06.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 1, 2007.

Ayyangar, et al.                                                [Page 1]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

Abstract

   In certain scenarios, there may be a need to combine together several
   Generalized Multi-Protocol Label Switching (GMPLS) Label Switched
   Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and
   all traffic from one constituent LSP is switched onto the next LSP.
   We will refer to this as "LSP stitching", the key requirement being
   that a constituent LSP not be allocated to more than one e2e LSP.
   The constituent LSPs will be referred to as "LSP segments" (S-LSPs).

   This document describes extensions to the existing GMPLS signaling
   protocol (RSVP-TE) to establish e2e LSPs created from from S-LSPs,
   and describes how the LSPs can be managed using the GMPLS signaling
   and routing protocols.

   It may be possible to configure a GMPLS node to switch the traffic
   from an LSP for which it is the egress, to another LSP for which it
   is the ingress, without requiring any signaling or routing extensions
   whatsoever, completely transparent to other nodes.  This will also
   result in LSP stitching in the data plane.  However, this document
   does not cover this scenario of LSP stitching.

Ayyangar, et al.                                                [Page 2]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  4
   2.  Comparison with LSP Hierarchy  . . . . . . . . . . . . . . . .  4
   3.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Triggers for LSP Segment Setup . . . . . . . . . . . . . .  6
     3.2.  Applications . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Routing Aspects  . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Signaling Aspects  . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  RSVP-TE Signaling Extensions . . . . . . . . . . . . . . .  8
       5.1.1.  Creating and Preparing an LSP Segment for Stitching  .  8
       5.1.2.  Stitching the e2e LSP to the LSP Segment . . . . . . . 10
       5.1.3.  RRO Processing for e2e LSPs  . . . . . . . . . . . . . 11
       5.1.4.  Teardown of LSP Segments . . . . . . . . . . . . . . . 12
       5.1.5.  Teardown of e2e LSPs . . . . . . . . . . . . . . . . . 12
     5.2.  Summary of LSP Stitching Procedures  . . . . . . . . . . . 13
       5.2.1.  Example Topology . . . . . . . . . . . . . . . . . . . 13
       5.2.2.  LSP Segment Setup  . . . . . . . . . . . . . . . . . . 13
       5.2.3.  Setup of an e2e LSP  . . . . . . . . . . . . . . . . . 14
       5.2.4.  Stitching of an e2e LSP into an LSP Segment  . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  Attribute Flags for LSP_ATTRIBUTES Object  . . . . . . . . 15
     7.2.  New Error Code . . . . . . . . . . . . . . . . . . . . . . 16
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   10.  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . 18
   11.  Full Copyright Statement  . . . . . . . . . . . . . . . . . . 19
   12.  Intellectual Property   . . . . . . . . . . . . . . . . . . . 19

Ayyangar, et al.                                                [Page 3]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

1.  Introduction

   A stitched Generalized Multiprotocol Label Switching (GMPLS) Traffic
   Engineering (TE) Label Switched Path (LSP) is built from a set of
   different LSP segments (S-LSPs) that are connected together in the
   data plane in such a way that a single end-to-end LSP is realized in
   the data plane.  In this document, we define the concept of LSP
   stitching and detail the control plane mechanisms and procedures
   (routing and signaling) to accomplish this.  Where applicable,
   similarities and differences between LSP hierarchy [RFC4206] and LSP
   stitching are highlighted.  Signaling extensions required for LSP
   stitching are also described here.

   It may be possible to configure a GMPLS node to switch the traffic
   from an LSP for which it is the egress, to another LSP for which it
   is the ingress, without requiring any signaling or routing extensions
   whatsoever, and such that the operation is completely transparent to
   other nodes.  This results in LSP stitching in the data plane, but
   requires management intervention at the node where the stitching is
   performed.  With the mechanism described in this document, the node
   performing the stitching does not require configuration of the pair
   of S-LSPs to be stitched together.  Also, LSP stitching as defined
   here results in an end-to-end LSP both in the control and data
   planes.

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

2.  Comparison with LSP Hierarchy

   LSP hierarchy ([RFC4206]) provides signaling and routing procedures
   so that:

   a.  A Hierarchical LSP (H-LSP) can be created.  Such an LSP created
       in one layer can appear as a data link to LSPs in higher layers.
       As such, one or more LSPs in a higher layer can traverse this
       H-LSP as a single hop; we call this "nesting".

   b.  An H-LSP may be managed and advertised (although this is not a
       requirement) as a Traffic Engineering (TE) link.  Advertising an
       H-LSP as a TE link allows other nodes in the TE domain in which
       it is advertised to use this H-LSP in path computation.  If the
       H-LSP TE link is advertised in the same instance of control plane
       (TE domain) in which the H-LSP was provisioned, it is then
       defined as a forwarding adjacency LSP (FA-LSP) and GMPLS nodes
       can form a forwarding adjacency (FA) over this FA-LSP.  There is
       usually no routing adjacency between end points of an FA.  An

Ayyangar, et al.                                                [Page 4]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

       H-LSP may also be advertised as a TE link in a different TE
       domain.  In this case, the end points of the H-LSP are required
       have a routing adjacency between them.

   c.  RSVP signaling ([RFC3473], [RFC3209]) for LSP setup can occur
       between nodes that do not have a routing adjacency.

   In case of LSP stitching, instead of an H-LSP, an "LSP segment"
   (S-LSP) is created between two GMPLS nodes.  An S-LSP for stitching
   is considered to be the moral equivalent of an H-LSP for nesting.  An
   S-LSP created in one layer, unlike an H-LSP, provides a data link to
   other LSPs in the same layer.  Similar to an H-LSP, an S-LSP could be
   managed and advertised, although it is not required, as a TE link,
   either in the same TE domain as it was provisioned or a different
   one.  If so advertised, other Generalized Multiprotocol Label
   Switching (GMPLS) nodes can use the corresponding S-LSP TE link in
   path computation.  While there is a forwarding adjacency between end
   points of an H-LSP TE link, there is no forwarding adjacency between
   end points of an S-LSP TE link.  In this aspect, an H-LSP TE link
   more closely resembles a 'basic' TE link as compared to an S-LSP TE
   link.

   While LSP hierarchy allows more than one LSP to be mapped to an
   H-LSP, in case of LSP stitching, at most one LSP may be associated
   with an S-LSP.  Thus, if LSP-AB is an H-LSP between nodes A and B,
   then multiple LSPs, say LSP1, LSP2, and LSP3 can potentially be
   'nested into' LSP-AB.  This is achieved by exchanging a unique label
   for each of LSP1..3 over the LSP-AB hop, thereby separating the data
   corresponding to each of LSP1..3 while traversing the H-LSP LSP-AB.
   Each of LSP1..3 may reserve some bandwidth on LSP-AB.  On the other
   hand, if LSP-AB is an S-LSP, then at most one LSP, say LSP1, may be
   stitched to the S-LSP LSP-AB.  LSP-AB is then dedicated to LSP1 and
   no other LSPs can be associated with LSP-AB.  The entire bandwith on
   S-LSP LSP-AB is allocated to LSP1.  However, similar to H-LSPs,
   several S-LSPs may be bundled into a TE link ([RFC4201]).

   The LSPs LSP1..3 which are either nested or stitched into another LSP
   are termed as e2e LSPs in the rest of this document. Routing
   procedures specific to LSP stitching are detailed in Section 4.

   Targetted (non-adjacent) RSVP signaling defined in [RFC4206] is
   required for LSP stitching of an e2e LSP to an S-LSP.  Specific
   extensions for LSP stitching are described later in Section 5.1.
   Therefore, in the control plane, there is one RSVP session
   corresponding to the e2e LSP as well as one for each S-LSP.  The
   creation and termination of an S-LSP may be dictated by
   administrative control (statically provisioned) or due to another
   incoming LSP request (dynamic).  Triggers for dynamic creation of an
   S-LSP may be different from that of an H-LSP and will be described in
   detail later.

Ayyangar, et al.                                                [Page 5]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

3.  Usage

3.1.  Triggers for LSP Segment Setup

   An S-LSP may be created either by administrative control
   (configuration trigger) or dynamically due to an incoming LSP
   request.  LSP Hierarchy ([RFC4206]) defines one possible trigger for
   dynamic creation of FA-LSP by introducing the notion of LSP regions
   based on Interface Switching Capabilities.  As per [RFC4206], dynamic
   FA-LSP creation may be triggered on a node when an incoming LSP
   request crosses region boundaries.  However, this trigger MUST NOT be
   used for creation of S-LSP for LSP stitching as described in this
   document.  In case of LSP stitching, the switching capabilities of
   the previous hop and the next hop TE links MUST be the same.
   Therefore, local policies configured on the node SHOULD be used for
   dynamic creation of LSP segments.

   Other possible triggers for dynamic creation of both H-LSPs and
   S-LSPs include cases where an e2e LSP may cross domain boundaries or
   satisfy locally configured policies on the node as described in
   [RSVP-INTER].

3.2.  Applications

   LSP stitching procedures described in this document are applicable to
   GMPLS nodes that need to associate an e2e LSP with another S-LSP of
   the same switching type and LSP hierarchy procedures do not apply.
   E.g., if an e2e lambda LSP traverses an LSP segment TE link which is
   also lambda switch capable, then LSP hierarchy is not possible; in
   this case, LSP switching may be an option.

   LSP stitching procedures can be used for inter-domain TE LSP
   signaling to stitch an inter-domain e2e LSP to a local intra-domain
   TE S-LSP ([RFC4726] and [RSVP-INTER]).

   LSP stitching may also be useful in networks to bypass legacy nodes
   which may not have certain new capabilities in the control plane
   and/or data plane.  E.g., one suggested usage in the case of
   point-to-multipoint (P2MP) RSVP LSPs ([RSVP-P2MP]) is the use of LSP
   stitching to stitch a P2MP RSVP LSP to an LSP segment between P2MP
   capable Label Switching Routers (LSRs) in the network.  The LSP
   segment would traverse legacy LSRs that may be incapable of acting as
   P2MP branch points, thereby shielding them from the P2MP control and
   data path.  Note, however, that such configuration may limit the
   attractiveness of RSVP P2MP and should carefully be examined before
   deployment.

Ayyangar, et al.                                                [Page 6]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

4.  Routing Aspects

   An S-LSP is created between two GMPLS nodes and it may traverse zero
   or more intermediate GMPLS nodes.  There is no forwarding adjacency
   between the end points of an S-LSP TE link.  So, although in the TE
   topology, the end points of an S-LSP TE link are adjacent, in the
   data plane, these nodes do not have an adjacency.  Hence any data
   plane resource identifier between these nodes is also meaningless.
   The traffic that arrives at the head end of the S-LSP is switched
   into the S-LSP contiguously with a label swap and no label is
   associated directly between the end nodes of the S-LSP itself.

   An S-LSP MAY be treated and managed as a TE link.  This TE link MAY
   be numbered or unnumbered.  For an unnumbered S-LSP TE link, the
   schemes for assignment and handling of the local and remote link
   identifiers as specified in [RFC3477] SHOULD be used.  When
   appropriate, the TE information associated with an S-LSP TE link MAY
   be flooded via ISIS-TE [RFC4205] or OSPF-TE [RFC4203].  Mechanisms
   similar to that for regular (basic) TE links SHOULD be used to flood
   S-LSP TE links.  Advertising or flooding the S-LSP TE link is not a
   requirement for LSP stitching.  If advertised, this TE information
   will exist in the TE database (TED) and can then be used for path
   computation by other GMPLS nodes in the TE domain in which it is
   advertised.  When so advertising S-LSPs, one should keep in mind that
   these add to the size and complexity of the link-state database.

   If an S-LSP is advertised as a TE link in the same TE domain in which
   it was provisioned, there is no need for a routing adjacency between
   end points of this S-LSP TE link.  If an S-LSP TE link is advertised
   in a different TE domain, the end points of that TE link SHOULD have
   a routing adjacency between them.

   The TE parameters defined for an FA in [RFC4206] SHOULD be used for
   an S-LSP TE link as well.  The switching capability of an S-LSP TE
   link MUST be equal to the switching type of the underlying S-LSP;
   i.e. an S-LSP TE link provides a data link to other LSPs in the same
   layer, so no hierarchy is possible.

   An S-LSP MUST NOT admit more than one e2e LSP into it.  If an S-LSP
   is allocated to an e2e LSP, the unreserved bandwidth SHOULD be set to
   zero to prevent further e2e LSPs being admitted into the S-LSP.

   Multiple S-LSPs between the same pair of nodes MAY be bundled using
   the concept of Link Bundling ([RFC4201]) into a single TE link.  In
   this case, each component S-LSP may be allocated to at most one e2e
   LSP.  When any component S-LSP is allocated for an e2e LSP, the
   component's unreserved bandwidth SHOULD be set to zero and the
   Minimum and Maximum LSP bandwidth of the TE link SHOULD be
   recalculated.  This will prevent more than one LSP from being
   computed and admitted over an S-LSP.

Ayyangar, et al.                                                [Page 7]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

5.  Signaling Aspects

   The end nodes of an S-LSP may or may not have a routing adjacency.
   However, they SHOULD have a signaling adjacency (RSVP neighbor
   relationship) and will exchange RSVP messages with each other.  It
   may, in fact, be desirable to exchange RSVP Hellos directly between
   the LSP segment end points to allow support for state recovery during
   Graceful Restart procedures as described in [RFC3473].

   In order to signal an e2e LSP over an LSP segment, signaling
   procedures described in section 8.1.1 of [RFC4206] MUST be used.
   Additional signaling extensions for stitching are described in the
   next section.

5.1.  RSVP-TE Signaling Extensions

   The signaling extensions described here MUST be used for stitching an
   e2e packet or non-packet GMPLS LSP ([RFC3473]), to an S-LSP.

   Stitching an e2e LSP to an LSP segment involves the following two
   step process:

   1.  Creating and preparing the S-LSP for stitching by signaling the
       desire to stitch between end points of the S-LSP; and

   2.  stitching the e2e LSP to the S-LSP.

5.1.1.  Creating and Preparing an LSP Segment for Stitching

   If a GMPLS node desires to create an S-LSP, i.e., one to be used for
   stitching, then it MUST indicate this in the Path message for the
   S-LSP.  This signaling explicitly informs the S-LSP egress node that
   the ingress node is planning to perform stitching over the S-LSP.
   Since an S-LSP is not conceptually different from any other LSP,
   explicitly signaling 'LSP stitching desired' helps clarify the data
   plane actions to be carried out when the S-LSP is used by some other
   e2e LSP.  Also, in case of packet LSPs, this is what allows the
   egress of the S-LSP to carry out label allocation as explained below.
   Also, so that the head-end node can ensure that correct stitching
   actions will be carried out at the egress node, the egress node MUST
   signal this information back to the head-end node in the Resv, as
   explained below.

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

   LSP stitching desired bit - This bit SHOULD be set in the Attributes
   Flags TLV of the LSP_ATTRIBUTES object in the Path message for the
   S-LSP by the head-end of the S-LSP, that desires LSP stitching.  This

Ayyangar, et al.                                                [Page 8]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

   bit MUST NOT be modified by any other nodes in the network.  Nodes
   other than the egress of the S-LSP SHOULD ignore this bit.  The bit
   number for this flag is defined in Section 7.1.

   An LSP segment can be used for stitching only if the egress node of
   the S-LSP is also ready to participate in stitching.  In order to
   indicate this to the head-end node of the S-LSP, the following new
   bit is defined in the Flags field of the Record Route object (RRO)
   Attributes subobject: "LSP segment stitching ready".  The bit number
   for this flag is defined in Section 7.1.

   If an egress node of the S-LSP receiving the Path message, supports
   the LSP_ATTRIBUTES object and the Attributes Flags TLV, and also
   recognizes the "LSP stitching desired" 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 value
   of "Stitching unsupported" to the head-end node of the S-LSP. The
   new error value is defined in Section 7.2.

   If an egress node receiving a Path message with the "LSP stitching
   desired" bit set in the Flags field of received LSP_ATTRIBUTES,
   recognizes the object, the TLV and the bit and also supports the
   desired stitching behavior, then it MUST allocate a non-NULL label
   for that S-LSP in the corresponding Resv message.  Also, so that the
   head-end node can ensure that the correct label (forwarding) actions
   will be carried out by the egress node and that the S-LSP can be used
   for stitching, the egress node MUST set the "LSP segment stitching
   ready" bit defined in the Flags field of the RRO Attribute sub-
   object.

   Finally, if the egress node for the S-LSP 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 bit, then it
   SHOULD simply ignore the above request.

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

5.1.1.1.  Steps to Support Penultimate Hop Popping

   Note that this section is only applicable to packet LSPs that use
   Penultimate Hop Popping (PHP) at the last hop, where the egress node
   distributes the Implicit NULL Label ([RFC3032]) in the Resv Label.
   These steps MUST NOT be used for a non-packet LSP and for packet LSPs
   where PHP is not desired.

Ayyangar, et al.                                                [Page 9]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

   When the egress node of an S-LSP receives a Path message for an e2e
   LSP using this S-LSP and this is a packet LSP, it SHOULD first check
   if it is also the egress for the e2e LSP.  If the egress node is the
   egress for both the S-LSP as well as the e2e TE LSP, and this is a
   packet LSP which requires PHP, then the node MUST send back a Resv
   trigger message for the S-LSP with a new label corresponding to the
   Implicit or Explicit NULL label.  Note that this operation does not
   cause any traffic disruption since the S-LSP is not carrying any
   traffic at this time, since the e2e LSP has not yet been established.

   If the e2e LSP and the S-LSP are bidirectional, the ingress of the
   e2e LSP SHOULD first check whether it is also the ingress of the
   S-LSP.  If so, it SHOULD re-issue the Path message for the S-LSP with
   an implicit or explicit NULL upstream label; and only then proceed
   with the signaling of the e2e LSP.

5.1.2.  Stitching the e2e LSP to the LSP segment

   When a GMPLS node receives an e2e LSP request, depending on the
   applicable trigger, it may either dynamically create an S-LSP based
   on procedures described above or it may map an e2e LSP to an existing
   S-LSP.  The switching type in the Generalized Label Request of the
   e2e LSP MUST be equal to the switching type of the S-LSP.  Other
   constraints like the explicit path encoded in the Explicit Route
   object (ERO), bandwidth, local TE policies MUST also be used for
   S-LSP selection or signaling.  In either case, once an S-LSP has been
   selected for an e2e LSP, the following procedures MUST be followed in
   order to stitch an e2e LSP to an S-LSP.

   The GMPLS node receiving the e2e LSP setup Path message MUST use the
   signaling procedures described in [RFC4206] to send the Path message
   to the end point of the S-LSP.  In this Path message, the node MUST
   identify the S-LSP in the RSVP_HOP.  An egress node receiving this
   RSVP_HOP should also be able to identify the S-LSP TE link based on
   the information signaled in the RSVP_HOP.  If the S-LSP TE link is
   numbered, then the addressing scheme as proposed in [RFC4206] SHOULD
   be used to number the S-LSP TE link.  If the S-LSP TE link is
   unnumbered, then any of the schemes proposed in [RFC3477] SHOULD be
   used to exchange S-LSP TE link identifiers between the S-LSP end
   points.  If the TE link is bundled, the RSVP_HOP SHOULD identify the
   component link as defined in [RFC4201].

   In case of a bidirectional e2e TE LSP, an Upstream Label MUST be
   signaled in the Path message for the e2e LSP over the S-LSP hop.
   However, since there is no forwarding adjacency between the S-LSP end
   points, any label exchanged between them has no significance.  So the
   node MAY chose any label value for the Upstream Label.  The label
   value chosen and signaled by the node in the Upstream Label is out of
   the scope of this document and is specific to the implementation on
   that node.  The egress node receiving this Path message MUST ignore

Ayyangar, et al.                                               [Page 10]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

   the Upstream Label in the Path message over the S-LSP hop.

   The egress node receiving this Path message MUST signal a Label in
   the Resv message for the e2e TE LSP over the S-LSP hop.  Again, since
   there is no forwarding adjacency between the egress and ingress S-LSP
   nodes, any label exchanged between them is meaningless.  So, the
   egress node MAY choose any label value for the Label.  The label
   value chosen and signaled by the egress node is out of the scope of
   this document and is specific to the implementation on the egress
   node.  The egress S-LSP node SHOULD also carry out data plane
   operations so that traffic coming in on the S-LSP is switched over to
   the e2e LSP downstream, if the egress of the e2e LSP is some other
   node downstream.  If the e2e LSP is bidirectional, this means setting
   up label switching in both directions.  The Resv message from the
   egress S-LSP node is IP routed back to the previous hop (ingress of
   the S-LSP).  The ingress node stitching an e2e TE LSP to an S-LSP
   MUST ignore the Label object received in the Resv for the e2e TE LSP
   over the S-LSP hop.  The S-LSP ingress node SHOULD also carry out
   data plane operations so that traffic coming in on the e2e LSP is
   switched into the S-LSP.  It should also carry out actions to handle
   traffic in the opposite direction if the e2e LSP is bidirectional.

   Note that the label exchange procedure for LSP stitching on the S-LSP
   hop, is similar to that for LSP hierarchy over the H-LSP hop.  The
   difference is the lack of the significance of this label between the
   S-LSP end points in case of stitching.  Therefore, in case of
   stitching the recepients of the Label/Upstream Label MUST NOT process
   these labels.  Also, at most one e2e LSP is associated with one
   S-LSP.  If a node at the head-end of an S-LSP receives a Path Msg for
   an e2e LSP that identifies the S-LSP in the ERO and the S-LSP
   bandwidth has already been allocated to some other LSP, then regular
   rules of RSVP-TE pre-emption apply to resolve contention for S-LSP
   bandwidth.  If the LSP request over the S-LSP cannot be satisfied,
   then the node SHOULD send back a PathErr with the error codes as
   described in [RFC3209].

5.1.3.  RRO Processing for e2e LSPs

   RRO procedures for the S-LSP specific to LSP stitching are already
   described in Section 5.1.1.  In this section we will look at the RRO
   processing for the e2e LSP over the S-LSP hop.

   An e2e LSP traversing an S-LSP, SHOULD record in the RRO for that
   hop, an identifier corresponding to the S-LSP TE link.  This is
   applicable to both Path and Resv messages over the S-LSP hop.  If the
   S-LSP is numbered, then the IPv4 or IPv6 address subobject
   ([RFC3209]) SHOULD be used to record the S-LSP TE link address.  If
   the S-LSP is unnumbered, then the Unnumbered Interface ID subobject
   as described in [RFC3477] SHOULD be used to record the node's Router
   ID and Interface ID of the S-LSP TE link.  In either case, the RRO

Ayyangar, et al.                                               [Page 11]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

   subobject SHOULD identify the S-LSP TE link end point.  Intermediate
   links or nodes traversed by the S-LSP itself SHOULD NOT be recorded
   in the RRO for the e2e LSP over the S-LSP hop.

5.1.4.  Teardown of LSP Segments

   S-LSP teardown follows the standard procedures defined in [RFC3209]
   and [RFC3473].  This includes procedures without and with setting the
   administrative status.  Teardown of S-LSP may be initiated by either
   the ingress, egress or any other node along the S-LSP path.
   Deletion/teardown of the S-LSP SHOULD be treated as a failure event
   for the e2e LSP associated with it and corresponding teardown or
   recovery procedures SHOULD be triggered for the e2e LSP.  In case of
   S-LSP teardown for maintenance purpose, the S-LSP ingress node MAY
   treat this to be equivalent to administratively shutting down a TE
   link along the e2e LSP path and take corresponding actions to notify
   the ingress of this event.  The actual signaling procedures to handle
   this event is out of the scope of this document.

5.1.5.  Teardown of e2e LSPs

   e2e LSP teardown also follows standard procedures defined in
   [RFC3209] and [RFC3473] either without or with the administrative
   status.  Note, however, that teardown procedures of e2e LSP and of
   S-LSP are independent of each other.  So, it is possible that while
   one LSP follows graceful teardown with adminstrative status, the
   other LSP is torn down without administrative status (using
   PathTear/ResvTear/PathErr with state removal).

   When an e2e LSP teardown is initiated from the head-end, and a
   PathTear arrives at the GMPLS stitching node, the PathTear message
   like the Path message MUST be IP routed to the LSP segment egress
   node with the destination IP address of the Path message set to the
   address of the S-LSP end node.  Router Alert MUST be off and RSVP TTL
   check MUST be disabled on the receiving node.  PathTear will result
   in deletion of RSVP states corresponding to the e2e LSP and freeing
   of label allocations and bandwidth reservations on the S-LSP.  The
   unreserved bandwidth on the S-LSP TE link SHOULD be re-adjusted.

   Similarly, a teardown of the e2e LSP may be initiated from the tail-
   end either using a ResvTear or a PathErr with state removal.  The
   egress of the S-LSP MUST propagate the ResvTear/PathErr upstream, IP
   routed to the ingress of the LSP segment.

   Graceful LSP teardown using ADMIN_STATUS as described in [RFC3473] is
   also applicable to stitched LSPs.

   If the S-LSP was statically provisioned, tearing down of an e2e LSP
   MAY not result in tearing down of the S-LSP.  If, however, the S-LSP
   was dynamically setup due to the e2e LSP setup request, then

Ayyangar, et al.                                               [Page 12]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

   depending on local policy, the S-LSP MAY be torn down if no e2e LSP
   is utilizing the S-LSP.  Although the S-LSP may be torn down while
   the e2e LSP is being torn down, it is RECOMMENDED that a delay be
   introduced in tearing down the S-LSP once the e2e LSP teardown is
   complete, in order to reduce the simultaneous generation of RSVP
   errors and teardown messages due to multiple events.  The delay
   interval may be set based on local implementation.  The RECOMMENDED
   interval is 30 seconds.

5.2.  Summary of LSP Stitching Procedures

5.2.1.  Example Topology

   The following topology will be used for the purpose of examples
   quoted in the following sections.

                     e2e LSP
      +++++++++++++++++++++++++++++++++++> (LSP1-2)

               LSP segment (S-LSP)
              ====================> (LSP-AB)
                  C --- E --- G
                 /|\    |   / |\
                / | \   |  /  | \
      R1 ---- A \ |  \  | /   | / B --- R2
                 \|   \ |/    |/
                  D --- F --- H

                      PATH
              ====================> (LSP stitching desired)
                      RESV
              <==================== (LSP segment stitching ready)

                      PATH (Upstream Label)
              +++++++++++++++++++++
       +++++++                     ++++++>
       <++++++                     +++++++
              +++++++++++++++++++++
                      RESV (Label)

5.2.2.  LSP Segment Setup

   Let us consider an S-LSP LSP-AB being setup between two nodes A and B
   which are more than one hop away.  Node A sends a Path message for
   the LSP-AB with "LSP stitching desired" set in Flags field of
   LSP_ATTRIBUTES object.  If the egress node B is ready to carry out
   stitching procedures, then B will respond with "LSP segment stitching
   ready" set in the Flags field of the RRO Attributes subobject, in the
   RRO sent in the Resv for the S-LSP.  Once A receives the Resv for

Ayyangar, et al.                                               [Page 13]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

   LSP-AB and sees this bit set in the RRO, it can then use LSP-AB for
   stitching.  A cannot use LSP-AB for stitching if the bit is cleared
   in the RRO.

5.2.3.  Setup of an e2e LSP

   Let us consider an e2e LSP LSP1-2 starting one hop before A on R1 and
   ending on node R2, as shown above.  If the S-LSP has been advertised
   as a TE link in the TE domain, and R1 and A are in the same domain,
   then R1 may compute a path for LSP1-2 over the S-LSP LSP-AB and
   identify the LSP-AB hop in the ERO.  If not, R1 may compute hops
   between A and B and A may use these ERO hops for S-LSP selection or
   signaling a new S-LSP.  If R1 and A are in different domains, then
   LSP1-2 is an inter-domain LSP.  In this case, S-LSP LSP-AB, similar
   to any other basic TE link in the domain will not be advertised
   outside the domain.  R1 would use either per-domain path computation
   ([PD-PATH]) or PCE based computation ([RFC4655]) for LSP1-2.

5.2.4.  Stitching of an e2e LSP into an LSP Segment

   When the Path message for the e2e LSP LSP1-2 arrives at node A, A
   matches the switching type of LSP1-2 with the S-LSP LSP-AB.  If the
   switching types are not equal, then LSP-AB cannot be used to stitch
   LSP1-2.  Once the S-LSP LSP-AB to which LSP1-2 will be stitched has
   been determined, the Path message for LSP1-2 is sent (via IP routing,
   if needed) to node B with the IF_ID RSVP_HOP identifying the S-LSP
   LSP-AB.  When B receives this Path message for LSP1-2, if B is also
   the egress for LSP1-2, and if this is a packet LSP requiring PHP,
   then B will send a Resv refresh for LSP-AB with the NULL Label.  In
   this case, since B is not the egress, the Path message for LSP1-2 is
   propagated to R2.  The Resv for LSP1-2 from B is sent back to A with
   a Label value chosen by B. B also sets up its data plane to swap the
   Label sent to either G or H on the S-LSP with the Label received from
   R2.  Node A ignores the Label on receipt of the Resv message and then
   propagates the Resv to R1.  A also sets up its data plane to swap the
   Label sent to R1 with the Label received on the S-LSP from C or D.
   This stitches the e2e LSP LSP1-2 to an S-LSP LSP-AB between nodes A
   and B. In the data plane, this yields a series of label swaps from R1
   to R2 along e2e LSP LSP1-2.

6.  Security Considerations

   From a security point of view, the changes introduced in this
   document model the changes introduced by [RFC4206].  That is, the
   control interface over which RSVP messages are sent or received need
   not be the same as the data interface which the message identifies
   for switching traffic.  But the capability for this function was
   introduced in [RFC3473] to support the concept of out-of-fiber
   control channels, so there is nothing new in this concept for
   signaling or security.

Ayyangar, et al.                                               [Page 14]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

   The application of this facility means that the "sending interface"
   or "receiving interface" may change as routing changes.  So, these
   interfaces cannot be used to establish security association between
   neighbors, and security associations MUST be bound to the
   communicating neighbors themselves.

   [RFC2747] provides a solution to this issue: in Section 2.1, under
   "Key Identifier", an IP address is a valid identifier for the sending
   (and by analogy, receiving) interface.  Since RSVP messages for a
   given LSP are sent to an IP address that identifies the next/previous
   hop for the LSP, one can replace all occurrences of 'sending
   [receiving] interface' with 'receiver's [sender's] IP address'
   (respectively). For example, in Section 4, third paragraph, instead
   of:

      "Each sender SHOULD have distinct security associations (and keys)
       per secured sending interface (or LIH).  ...  At the sender,
       security association selection is based on the interface through
       which the message is sent."

   it should read:

      "Each sender SHOULD have distinct security associations (and keys)
       per secured receiver's IP address. ...  At the sender, security
       association selection is based on the IP address to which the
       message is sent."

   Thus the mechanisms of [RFC2747] can be used unchanged to establish
   security associations between control plane neighbors.

   This document allows the IP destination address of Path and PathTear
   messages to be the IP address of a nexthop node (receiver's address)
   instead of the RSVP session destination address.  This means that the
   use of the IPsec Authentication Header (AH) (ruled out in [RFC2747]
   because RSVP messages were encapsulated in IP packets addressed to
   the ultimate destination of the Path or PathTear messages) is now
   perfectly applicable, and standard IPsec procedures can be used to
   secure the message exchanges.

   An analysis of GMPLS security issues can be found in [MPLS-SEC].

7.  IANA Considerations

   IANA is requested to make the following codepoint allocations for
   this document.

7.1.  Attribute Flags for LSP_ATTRIBUTES Object

   The "RSVP TE Parameters" registry includes the "Attributes Flags"
   sub-registry.

Ayyangar, et al.                                               [Page 15]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

   IANA is requested to make an allocation for the following new bit
   defined for the Attributes Flags TLV in the LSP_ATTRIBUTES object.
   The numeric value should be assigned by IANA. The value 5 is
   suggested.

   LSP stitching desired bit - Bit Number 5 (Suggested value)

   This bit is 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 (Bit Number 5) to be used in the RRO Attributes
   sub-object.

   The following text is suggested for inclusion in the registry:

                               Path      Resv     RRO
   Bit  Name                   message   message  sub-object  Reference
   ---  ---------------------  -------   -------  ----------  ----------
   5    LSP stitching desired  Yes       No       Yes         [This doc]

7.2.  New Error Codes

   The "Resource ReSerVation Protocol (RSVP) Parameters" registry
   includes the "Error Codes and Globally-Defined Error Value Sub-Codes"
   sub-registry.

   IANA is requested to assign a new error sub-code under the RSVP
   error-code "Routing Problem" (24).  The numeric error sub-code value
   should be assigned by IANA. A value of 23 is suggested.

   This error code is to be used only in an RSVP PathErr.

   The following text is suggested for inclusion in the registry:

   24  Routing Problem                             [RFC3209]

        23 = Stitching unsupported  [This doc]

8.  Acknowledgments

    The authors would like to thank Dimitri Papadimitriou and Igor
    Bryskin for their thorough review of the document and discussions
    regarding the same.

Ayyangar, et al.                                               [Page 16]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

9.  References

9.1.  Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
             and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
             Tunnels", RFC 3209, December 2001.

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

   [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
             Hierarchy with Generalized Multi-Protocol Label Switching
             (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

   [RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and
             A. Ayyangar, "Encoding of Attributes for Multiprotocol
             Label Switching (MPLS) Label Switched Path (LSP)
             Establishment Using Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE)", RFC 4420, February 2006.

9.2.  Informative References

   [RFC3032]    Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
                Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
                Encoding", RFC 3032, January 2001.

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

   [RFC4201]    Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
                in MPLS Traffic Engineering (TE)", RFC 4201, October
                2005.

   [RFC4203]    Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
                of Generalized Multi-Protocol Label Switching (GMPLS)",
                RFC 4203, October 2005.

   [RFC4205]    Kompella, K. and Y. Rekhter, "Intermediate System to
                Intermediate System (IS-IS) Extensions in Support of
                Generalized Multi-Protocol Label Switching (GMPLS)",
                RFC 4205, October 2005.

Ayyangar, et al.                                               [Page 17]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

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

   [RFC4726]    Farrel, A., Vasseur, J.P., and Ayyangar, Arthi, "A
                Framework for Inter-Domain Multiprotocol Label Switching
                Traffic Engineering", RFC 4726, November 2006.

   [RSVP-P2MP]  Aggarwal, R., "Extensions to RSVP-TE for Point-to-
                Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp, work
                in progress.

   [RSVP-INTER] Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic
                Engineering - RSVP-TE extensions", draft-ietf-ccamp-
                inter-domain-rsvp-te, work in progress.

   [PD-PATH]    Vasseur, J., "A Per-domain path computation method for
                establishing Inter-domain Traffic  Engineering (TE)
                Label Switched Paths (LSPs)", draft-ietf-ccamp-inter-
                domain-pd-path-comp, work in progress.

   [MPLS-SEC]   Fang, L., et al., "Security Framework for MPLS and GMPLS
                Networks", draft-fang-mpls-gmpls-security-framework,
                work in progress.

10.  Authors' Addresses

   Arthi Ayyangar
   Nuova Systems
   2600 San Tomas Expressway
   Santa Clara, CA  95051
   Email: arthi@nuovasystems.com

   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   Email: kireeti@juniper.net

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

   Adrian Farrel
   Old Dog Consulting
   Email: adrian@olddog.co.uk

Ayyangar, et al.                                               [Page 18]
Internet-Draft         LSP Stitching with GMPLS TE            April 2007

11.  Full Copyright Statement

   Copyright (C) The 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.

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

12.  Intellectual Property

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

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

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

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Ayyangar, et al.                                               [Page 19]