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

Versions: (draft-ayyangar-ccamp-lsp-stitching) 00 01 02 03 04 05 06 RFC 5150

Network Working Group                                   A. Ayyangar, Ed.
Internet-Draft                                             Nuova Systems
Intended status: Standards Track                        K. Kompella, Ed.
Expires: June 5, 2007                                   Juniper Networks
                                                              JP. Vasseur
                                                      Cisco Systems, Inc.
                                                         December 2, 2006


Label Switched Path Stitching with Generalized MPLS Traffic Engineering
                  draft-ietf-ccamp-lsp-stitching-04.txt

Status of this Memo

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

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

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

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

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

    This Internet-Draft will expire on June 5, 2007.

Copyright Notice

    Copyright (C) The Internet Society (2006).











Ayyangar, et al.          Expires June 5, 2007                  [Page 1]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


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

    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.          Expires June 5, 2007                  [Page 2]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


Table of Contents

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
      1.1.  Conventions used in this document  . . . . . . . . . . . .  4
    2.  Comparison with LSP Hierarchy  . . . . . . . . . . . . . . . .  5
    3.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
      3.1.  Triggers for LSP segment setup . . . . . . . . . . . . . .  6
      3.2.  Applications . . . . . . . . . . . . . . . . . . . . . . .  6
    4.  Routing aspects  . . . . . . . . . . . . . . . . . . . . . . .  7
    5.  Signaling aspects  . . . . . . . . . . . . . . . . . . . . . .  9
      5.1.  RSVP-TE signaling extensions . . . . . . . . . . . . . . .  9
        5.1.1.  Creating and preparing LSP segment for stitching . . .  9
        5.1.2.  Stitching the e2e LSP to the LSP segment . . . . . . . 11
        5.1.3.  RRO Processing for e2e LSP . . . . . . . . . . . . . . 12
        5.1.4.  Teardown of LSP segment  . . . . . . . . . . . . . . . 13
        5.1.5.  Teardown of e2e LSP  . . . . . . . . . . . . . . . . . 13
      5.2.  Summary of LSP Stitching procedures  . . . . . . . . . . . 14
        5.2.1.  Example topology . . . . . . . . . . . . . . . . . . . 14
        5.2.2.  LSP segment setup  . . . . . . . . . . . . . . . . . . 15
        5.2.3.  Setup of e2e LSP . . . . . . . . . . . . . . . . . . . 15
        5.2.4.  Stitching of e2e LSP into an LSP segment . . . . . . . 15
    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
      7.1.  Attribute Flags for LSP_ATTRIBUTES object  . . . . . . . . 17
      7.2.  New Error Codes  . . . . . . . . . . . . . . . . . . . . . 17
    8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
      9.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
      9.2.  Informative References . . . . . . . . . . . . . . . . . . 19
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
    Intellectual Property and Copyright Statements . . . . . . . . . . 22




















Ayyangar, et al.          Expires June 5, 2007                  [Page 3]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


1.  Introduction

    This document describes the mechanisms to accomplish LSP stitching in
    the control (routing and signaling) and data planes, contrasting
    stitching with LSP hierarchy ([2]) as is meaningful.  With the
    mechanism described here, the node performing the stitching does not
    require configuration of the pair of 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.

    LSP hierarchy ([2]) 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
        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 for LSP setup can occur between nodes that do not
        have a routing adjacency.

    A stitched TE LSP comprises 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 to accomplish this.  Where applicable,
    similarities and differences between LSP hierarchy and LSP stitching
    are highlighted.  Signaling extensions required for LSP stitching are
    also described here.

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



Ayyangar, et al.          Expires June 5, 2007                  [Page 4]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


2.  Comparison with LSP Hierarchy

    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 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 ([11]).

    The LSPs LSP1..3 which are either nested or stitched into another LSP
    are termed as end-to-end (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 [2] 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.          Expires June 5, 2007                  [Page 5]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


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 ([2]) defines one possible trigger for
    dynamic creation of FA-LSP by introducing the notion of LSP regions
    based on Interface Switching Capabilities.  As per [2], 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 [8].

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 ([8]).

    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 case of P2MP RSVP
    LSPs ([7]) is the use of LSP stitching to stitch a P2MP RSVP LSP to
    an LSP segment between P2MP capable 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.          Expires June 5, 2007                  [Page 6]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


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 [10] SHOULD be used.  When appropriate,
    the TE information associated with an S-LSP TE link MAY be flooded
    via ISIS-TE [13] or OSPF-TE [12].  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 [2] 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 ([11]) 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



Ayyangar, et al.          Expires June 5, 2007                  [Page 7]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


    will prevent more than one LSP from being computed and admitted over
    an S-LSP.

















































Ayyangar, et al.          Expires June 5, 2007                  [Page 8]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


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

    In order to signal an e2e LSP over an LSP segment, signaling
    procedures described in section 8.1.1 of [2] 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 ([4]), 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 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
    [3]:

    Bit Number 5 (TBD): LSP stitching desired bit - This bit SHOULD be



Ayyangar, et al.          Expires June 5, 2007                  [Page 9]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


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

    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 RRO Attributes subobject:
    Bit Number 5 (TBD): LSP segment stitching ready.

    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 sub-
    code="Stitching unsupported" (TBD) to the head-end node of the S-LSP.

    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 ([9]) 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.          Expires June 5, 2007                 [Page 10]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


    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 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 [2] 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 [2] 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 [10] 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 [11].

    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



Ayyangar, et al.          Expires June 5, 2007                 [Page 11]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


    that node.  The egress node receiving this Path message MUST ignore
    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 [5].

5.1.3.  RRO Processing for e2e LSP

    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 ([5])
    SHOULD be used to record the S-LSP TE link address.  If the S-LSP is



Ayyangar, et al.          Expires June 5, 2007                 [Page 12]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


    unnumbered, then the Unnumbered Interface ID subobject as described
    in [10] SHOULD be used to record the node's Router ID and Interface
    ID of the S-LSP TE link.  In either case, the RRO 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 segment

    S-LSP teardown follows the standard procedures defined in [5] and
    [4].  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 LSP

    e2e LSP teardown also follows standard procedures defined in [5] and
    [4] 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 [4] is also



Ayyangar, et al.          Expires June 5, 2007                 [Page 13]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


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






Ayyangar, et al.          Expires June 5, 2007                 [Page 14]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


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
    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 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
    ([14]) or PCE based computation ([15]) for LSP1-2.

5.2.4.  Stitching of 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.



Ayyangar, et al.          Expires June 5, 2007                 [Page 15]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


6.  Security Considerations

    Similar to [2], this document permits that 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.
    Also, the 'sending interface' and 'receiving interface' may change as
    routing changes.  So, these cannot be used to establish security
    association between neighbors.  Mechanisms described in [6] should be
    re-examined and may need to be altered to define new security
    associations based on receiver's IP address instead of the sending
    and receiving interfaces.  Also, 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.  So, [6] should be revisited to check if
    IPSec AH is now a viable means of securing RSVP-TE messages.




































Ayyangar, et al.          Expires June 5, 2007                 [Page 16]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


7.  IANA Considerations

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

7.1.  Attribute Flags for LSP_ATTRIBUTES object

    The following new bit is being defined for the Attributes Flags TLV
    in the LSP_ATTRIBUTES object.  The numeric value should be assigned
    by IANA.

    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.

7.2.  New Error Codes

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

    Stitching unsupported - sub-code 23 (Suggested value)

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






















Ayyangar, et al.          Expires June 5, 2007                 [Page 17]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


8.  Acknowledgments

    The authors would like to thank Adrian Farrel for his comments and
    suggestions.  The authors would also like to thank Dimitri
    Papadimitriou and Igor Bryskin for their thorough review of the
    document and discussions regarding the same.













































Ayyangar, et al.          Expires June 5, 2007                 [Page 18]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


9.  References

9.1.  Normative References

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

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

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

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

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

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

9.2.  Informative References

    [7]   Aggarwal, R., "Extensions to RSVP-TE for Point-to-Multipoint TE
          LSPs", draft-ietf-mpls-rsvp-te-p2mp-06 (work in progress),
          August 2006.

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

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

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

    [11]  Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in



Ayyangar, et al.          Expires June 5, 2007                 [Page 19]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


          MPLS Traffic Engineering (TE)", RFC 4201, October 2005.

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

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

    [14]  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-03 (work in
          progress), August 2006.

    [15]  Farrel, A., "A Path Computation Element (PCE) Based
          Architecture", draft-ietf-pce-architecture-05 (work in
          progress), April 2006.































Ayyangar, et al.          Expires June 5, 2007                 [Page 20]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


Authors' Addresses

    Arthi Ayyangar (editor)
    Nuova Systems
    2600 San Tomas Expressway
    Santa Clara, CA  95051
    US

    Email: arthi@nuovasystems.com


    Kireeti Kompella (editor)
    Juniper Networks
    1194 N. Mathilda Ave.
    Sunnyvale, CA  94089
    US

    Email: kireeti@juniper.net


    Jean Philippe Vasseur
    Cisco Systems, Inc.
    300 Beaver Brook Road
    Boxborough, MA  01719
    US

    Email: jpv@cisco.com
























Ayyangar, et al.          Expires June 5, 2007                 [Page 21]

Internet-Draft         LSP Stitching with GMPLS TE         December 2006


Full Copyright Statement

    Copyright (C) The Internet Society (2006).

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

    This document and the information contained herein are provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    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.


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.          Expires June 5, 2007                 [Page 22]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/