Network Working Group                                   A. Ayyangar, Ed.
Internet-Draft                                          Juniper Networks
Expires: January 16, March 26, 2006                                      JP. Vasseur
                                                     Cisco Systems, Inc.
                                                           July 15,
                                                      September 22, 2005

Label Switched Path Stitching with Generalized MPLS Traffic Engineering
                 draft-ietf-ccamp-lsp-stitching-01.txt
                 draft-ietf-ccamp-lsp-stitching-02.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 January 16, March 26, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   In certain scenarios, there may be a need to combine together two
   different Generalized Multi-Protocol Label Switching (GMPLS) Label
   Switched Paths (LSPs) such that in the data plane, a single end-to-
   end (e2e) LSP is achieved realized and all traffic from one LSP is switched
   onto the other LSP.  We will refer to this as "LSP stitching".  This
   document covers cases where: a) the node performing the stitching
   does not require configuration of every LSP pair to be stitched
   together b) the node performing the stitching is not the egress of
   any of the LSPs c) LSP stitching not only results in an end-to-end
   LSP in the data plane, but there is also a corresponding end-to-end
   LSP (RSVP session) in the control plane.

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

Table of Contents

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

1.  Introduction

   This document describes the mechanisms to accomplish LSP stitching in
   the scenarios described above.

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

   a.  a GMPLS node  A Hierarchical LSP (H-LSP) can form a forwarding adjacency (FA) over the FA be created.  Such an LSP

   b.  other Label Switching Routers (LSRs) created
       in one layer can provide a data link to LSPs in higher layers.
       Also one or more LSPs can see be nested into this FA LSP H-LSP.

   b.  An H-LSP may be managed and advertised (although this is not a
       requirement) as a Traffic Engineering (TE) link, when needed.

   c. link.  Advertising an
       H-LSP as a TE link allows other nodes in the GMPLS node can nest one or more LSPs over TE domain in which
       it is advertised to use this H-LSP in path computation.  If the FA LSP.  This
       only covers LSPs
       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 single domain.

   d.  RSVP 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 stitching is comprises of different LSP segments (S-LSPs) that
   are connected together in the data plane in such a special case way that a single
   end-to-end LSP is realized in the data plane.  In this document, we
   define the concept of LSP hierarchy. 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].

2.  Comparison with LSP Hierarchy

   In case of LSP stitching, instead of an FA LSP, H-LSP, an "LSP segment"
   (S-LSP) is created between two GMPLS nodes.  So an LSP segment  An S-LSP for stitching
   is considered to be the moral equivalent of an FA LSP H-LSP for nesting and nesting.  An
   S-LSP created in one layer, unlike an LSP segment TE
   link is H-LSP, provides a moral equivalent of FA (FA-LSP TE link).  While LSP
   hierarchy allows more that one LSP to be mapped data link to an FA-LSP,
   other LSPs in case
   of LSP stitching, at most one LSP may be mapped the same layer.  Similar to an LSP segment.
   E.g. if LSP-AB is H-LSP, an FA-LSP between nodes A and B, then multiple
   LSPs, say LSP1, LSP2, LSP3 S-LSP could potentially be 'nested into' LSP-AB.
   This
   managed and advertised, although it is achieved by exchanging not required, as a unique label for each of TE link,
   either in the same TE domain as it was provisioned or a different
   one.  If advertised, other GMPLS nodes could used 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.  E.g. if LSP-AB is an H-LSP between nodes A and B,
   then multiple LSPs, say LSP1, LSP2, LSP3 could 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 permitting LSP1..3 to share
   the FA-LSP H-LSP LSP-AB.  Each of LSP1..3 may reserve some bandwidth on
   LSP-AB.  On the other hand, if LSP-AB is an LSP segment, S-LSP, then at most one
   LSP, say LSP1 may be 'stitched to' stitched to the LSP segment S-LSP LSP-AB.  No labels are
   exchanged for LSP1 over the LSP-AB hop directly between nodes A and
   B. Therefore  LSP-AB is
   dedicated to LSP1 and no other LSPs can be associated with LSP-AB.
   The entire bandwith on LSP segment S-LSP LSP-AB is allocated to LSP1.  However,
   several S-LSPs MAY be bundled into a TE link ([11]), similar to
   H-LSPs.

   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.

   Signaling and routing
   Routing procedures for specific to LSP stitching are basically
   similar to that described detailed in [2].  The LSP segment, like an FA-LSP is
   treated as a TE link.  Also, non-adjacent
   Section 4.

   Targetted (non-adjacent nodes) RSVP signaling defined in
   [2]) [2] is
   required to stitch for LSP stitching of an e2e LSP to an S-LSP.  Specific
   extensions for LSP segment.  So, 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 LSP segment that the e2e LSP is being
   stitched to. S-LSP.  The creation/termination
   creation and termination of an LSP segment S-LSP may be dictated by
   administrative control (statically provisioned) or due to another
   incoming LSP request (dynamic).  Triggers for dynamic creation of an LSP segment are
   S-LSP may be different from that of an FA-LSP H-LSP and will be described in
   detail later.  In this document, where
   applicable, similarities and differences in the routing and signaling
   procedures between LSP hierarchy and LSP stitching are highlighted.
   Additional signaling extensions required

3.  Usage

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

2.  Routing aspects

   An LSP segment is created and treated like a TE link between two
   GMPLS nodes whose path transits zero or more GMPLS nodes in the same
   instance of the GMPLS control plane.  These TE links setup

   An S-LSP may be numbered created either by administrative control
   (configuration trigger) or unnumbered.  For an unnumbered LSP segment, the assignment and
   handling of the local and remote link identifiers is specified in
   [9].  Unlike dynamically due to an FA-LSP, a GMPLS node does not have a data plane
   adjacency with the end point of the incoming LSP segment.  This implies that
   the traffic that arrives at the GMPLS node will be switched into the
   request.  LSP segment contiguously with a label swap and no label is exchanged
   directly between the end nodes Hierarchy ([2]) defines one possible trigger for
   dynamic creation of FA-LSP by introducing the notion of LSP segment itself.  A routing
   adjacency will not be established over an LSP segment.  ISIS/OSPF
   may, however, flood the TE information associated with an regions
   based on Interface Switching Capabilities.  As per [2], dynamic FA-
   LSP segment
   TE link, when appropriate.  Mechanisms similar to that for regular TE
   links creation may be used to flood LSP segment TE links.  Advertising or
   flooding the LSP segment TE link is not triggered on a requirement for node when an incoming LSP
   stitching.  Discretion should request
   crosses region boundaries.  However, this trigger MUST NOT be used when advertising an
   for creation of S-LSP for LSP segment
   TE link stitching as described in IGP.  If advertised, this TE information will exist in
   document.  In case of LSP stitching, the
   TE database (TED) switching capabilities of
   the previous hop and can then the next hop TE links MUST be the same.
   Therefore, local policies configured on the node SHOULD be used for path computation by other
   GMPLS nodes in the network.

   The TE parameters defined
   dynamic creation of LSP segments.

   Other possible triggers for dynamic creation of both H-LSPs and
   S-LSPs include cases where an FA 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 [2]) this document are exactly applicable to
   an LSP segment TE link as well.  Note
   GMPLS nodes that need to associate an e2e LSP with another S-LSP of
   the same switching capability
   of type and LSP hierarchy procedures do not apply.
   E.g. if an e2e lambda LSP traverses an LSP segment TE link MUST be equal to the switching type of the
   underlying which is
   also lambda switch capable, then in this case LSP segment; i.e. no hierarchy (nesting) is not
   possible.

   An

   LSP segment stitching procedures could be used for inter-domain TE link SHOULD NOT admit more than one e2e LSP into
   it.  So, once
   signaling to stitch an inter-domain LSP to a local intra-domain TE
   S-LSP ([8]).

   LSP stitching could 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 stitched into the use of LSP stitching to stitch a P2MP RSVP LSP to
   an LSP segment, the unreserved
   bandwidth on segment between P2MP capable LSRs in the network.  The LSP
   segment SHOULD would traverse legacy LSRs that may be set to zero.  This will
   prevent any more LSPs incapable of acting as
   P2MP branch points, thereby shielding them from being computed the P2MP control and admitted over
   data path.  Note, however, that such configuration may limit the LSP
   segment
   attractiveness of RSVP P2MP and should carefully be examined before
   deployment.

4.  Routing aspects

   An S-LSP is created between two GMPLS nodes and it may traverse zero
   or more GMPLS nodes.  There is no forwarding adjacency between the
   end points of an S-LSP TE link.  Multiple LSP segments  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 the same pair of these nodes may be bundled using is also meaningless.  The traffic that
   arrives at the concept head end of Link Bundling ([10]) into a
   single TE link.  When any component LSP segment the S-LSP is allocated for an
   LSP, switched into the component's unreserved bandwidth SHOULD be set to zero S-LSP
   contiguously with a label swap and no label is associated directly
   between the Minimum and Maximum LSP bandwidth end nodes of the TE link SHOULD S-LSP itself.

   An S-LSP MAY be
   recalculated.

3.  Usage

3.1  LSP regions treated and LSP stitching

   An LSP segment may managed as a TE link.  This TE link MAY
   be created either by administrative control
   (configuration trigger) numbered or dynamically due to unnumbered.  For an incoming LSP
   request.  LSP Hierarchy ([2]) defines one possible trigger for
   dynamic creation of FA-LSP by introducing unnumbered S-LSP TE link, 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 LSP segment
   schemes for LSP stitching as described in this
   document.  In case of LSP stitching, the switching capabilities of
   the previous hop assignment and handling of the next hop TE links MUST be the same.
   Therefore, local policies configured on the node and remote link
   identifiers as specified in [10] SHOULD be used for
   dynamic creation of LSP segments.

   Other possible triggers for dynamic creation of both FA-LSPs and LSP
   segments include cases where an e2e LSP used.  ISIS/OSPF may cross domain boundaries flood
   the TE information associated with an S-LSP TE link, when
   appropriate.  Mechanisms similar to that for regular (basic) TE links
   SHOULD be used to flood S-LSP TE links.  Advertising or satisfy locally configured policies on flooding the node as described in
   [8].

3.2  Applications
   S-LSP TE link is not a requirement for LSP stitching procedures described stitching.  Discretion
   should be used when advertising an S-LSP TE link in an IGP.  If
   advertised, this document are applicable to TE information will exist in the TE database (TED)
   and can then be used for path computation by other GMPLS nodes that need to associate an e2e LSP with another LSP
   segment of in the same switching type and LSP hierarchy procedures do
   not apply.  E.g. if an e2e lambda LSP traverses
   TE domain in which it is advertised.

   If an LSP segment S-LSP is advertised as a TE link in the same TE domain in which
   it was provisioned, there is also lambda switch capable, then in no need for a routing adjacency between
   end points of this case LSP
   hierarchy S-LSP TE link.  If an S-LSP TE link is not possible.

   LSP stitching procedures could 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 inter-domain an
   S-LSP TE LSP
   signaling to stitch link as well.  The switching capability of an inter-domain LSP to a local intra-domain S-LSP TE
   LSP segment ([8]).

   LSP stitching could also link
   MUST be useful in networks equal to bypass legacy nodes
   which may not have certain new capabilities in the control plane
   and/or switching type of the underlying S-LSP; i.e. an
   S-LSP TE link provides a data plane.  E.g. link to other LSPs in the same layer,
   so no hierarchy is possible.

   An S-LSP MUST NOT admit more than one suggested usage in case e2e LSP into it.  However,
   multiple S-LSPs between the same pair of P2MP RSVP
   LSPs ([7]) is nodes MAY be bundled using
   the use concept of LSP stitching to stitch Link Bundling ([11]) into a P2MP RSVP LSP to single TE link.  So, while
   an S-LSP can have exactly one e2e LSP segment between P2MP capable LSRs in associated with it, a bundled
   TE link comprising of multiple S-LSPs, MAY admit more than one e2e
   LSP.  When any component S-LSP is allocated for an e2e LSP, the network.  The LSP
   segment would traverse legacy LSRs that may
   component's unreserved bandwidth SHOULD be incapable of acting as
   P2MP branch points, thereby shielding them from set to zero and the P2MP control
   Minimum and
   data path.  Note, however, that such configuration may Maximum LSP bandwidth of course
   limit the attractiveness of RSVP P2MP and should carefully TE link SHOULD be
   examined before deployment.

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

5.  Signaling aspects

   The end nodes of the LSP segment do an S-LSP may or may not have a routing adjacency.
   However, they will SHOULD have a signaling adjacency (RSVP neighbor
   relationship) and will exchange RSVP messages directly between 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.

4.1

5.1  RSVP-TE signaling extensions

   The signaling extensions described here MUST be used if the LSP
   segment is a packet LSP and an e2e packet LSP needs to be stitched to
   it.  These extensions are optional for non-packet LSPs and SHOULD be
   used if no other local mechanisms exist to automatically detect a
   requirement for stitching at both the ingress and egress GMPLS nodes
   of the LSP segment.  In cases where such mechanisms exist on these
   nodes and there is no need to signal "stitching" explicitly, the
   nodes MAY simply follow LSP hierarchy signaling procedures, but
   instead of nesting, they will stitch the LSPs in the data plane. 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 : process:

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

   b.  Stitching the e2e LSP to the LSP segment

4.1.1 S-LSP

5.1.1  Creating and preparing LSP segment for stitching

   If a GMPLS node desires to perform LSP stitching, then it MUST
   indicate this in the Path message for the LSP segment S-LSP that it plans to use
   for stitching.  This signaling explicitly informs the S-LSP egress
   node for the LSP segment that the ingress node is planning to perform stitching over the LSP segment.  This will allow
   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
   LSP segment S-LSP to allocate the correct label(s) carry out label allocation as explained below.
   Also, so that the head-end node can ensure that correct stitching
   actions were will be carried out at the egress node, a new flag is defined
   below in the Record Route Object (RRO) Attributes subobject egress node MUST
   signal this information back to
   indicate that the LSP segment can be used for stitching. head-end node in the Resv, as
   explained below.

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

   0x02

   Bit Number 5 (TBD): LSP stitching desired bit - This flag will bit SHOULD be
   set in the Attributes Flags TLV of the LSP_ATTRIBUTES object in the
   Path message for the LSP segment S-LSP by the head-end of the LSP segment, S-LSP, that desires
   LSP stitching.  This flag 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 only be used for stitching only if appropriate label
   actions were carried out at the egress node of
   the LSP segment. S-LSP is also ready to participate in stitching.  In order to
   indicate this to the head-end node of the LSP segment, S-LSP, the following new flag
   bit is defined in the Flags field of the RRO Attributes sub-object:
   0x02 subobject:
   Bit Number 5 (TBD): LSP segment stitching ready.

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

   If an egress node receiving a Path message with the "LSP stitching
   desired" flag set, bit set in the Flags field of received LSP_ATTRIBUTES,
   recognizes the object, the TLV and the flag bit and also supports the
   desired stitching behavior, then it MUST allocate a non-NULL label
   for that LSP segment S-LSP in the corresponding Resv message.  Now,  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 LSP
   segment S-LSP can be used
   for stitching, the egress node MUST set the "LSP segment stitching
   ready" bit defined in the RRO Attribute sub-object.
   Also, when the egress node for the LSP segment receives a Path
   message for an e2e LSP using this LSP segment, it SHOULD first check
   if it is also the egress for the e2e LSP.  If the egress node is the
   egress for both the LSP segment as well as the e2e TE LSP, and this
   is a packet LSP which requires Penultimate Hop Popping (PHP), then
   the node MUST send back a Resv refresh for the LSP segment with a new
   label corresponding to the NULL label. Flags field of the RRO Attribute sub-
   object.

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

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

4.1.2

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.

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

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 trigger, it may either dynamically create an LSP segment S-LSP based
   on procedures described above or it may map an e2e LSP to an existing LSP segment.
   S-LSP.  The switching type in the Generalized Label Request of the
   e2e LSP MUST be equal to the switching type of the LSP
   segment. S-LSP.  Other
   constraints like ERO, bandwidth, local TE policies
   may MUST also be used
   for LSP segment S-LSP selection or signaling.  In either case, once an LSP segment S-LSP has
   been selected for an e2e LSP, the following procedures MUST be
   followed in order to stitch an e2e LSP to an LSP segment. 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
   directly 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 point of points.
   If the LSP segment. 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 NOT be allocated and
   signaled in the Path message for the e2e LSP over the LSP segment
   hop.

   The egress node receiving this Path message MUST NOT allocate any
   Label in the Resv message for the e2e TE LSP over the LSP segment S-LSP hop.  This Resv message
   However, since there is IP routed back to the previous hop
   (ingress of no forwarding adjacency between the LSP segment).

   The ingress node stitching an e2e TE LSP to an LSP segment MUST
   ignore S-LSP end
   points, any Label object received in the Resv for the e2e TE LSP over
   the LSP segment hop.

   So, the main difference label exchanged between signaling an e2e LSP over an LSP
   segment instead of over an FA-LSP is that them has no Labels are allocated and
   exchanged for the e2e LSP over significance.  So the LSP segment hop.  So, at most one
   e2e LSP is associated with one LSP segment.  If a
   node at the head-
   end of an LSP segment receives a Path Msg MAY chose any label value for an LSP that identifies
   the LSP segment in the ERO Upstream Label.  The label
   value chosen and the LSP segment bandwidth has already
   been allocated to some other LSP, then regular rules of RSVP-TE pre-
   emption apply.  If the LSP request over the LSP segment cannot be
   satisfied, then signaled by the node SHOULD send back a PathErr with the error
   codes as described in [5].

4.1.3  RRO Processing for e2e LSP

   RRO procedures for the LSP segment Upstream Label is out of
   the scope of this document and is specific to LSP stitching are
   already described the implementation on
   that node.  The egress node receiving this Path message MUST ignore
   the Upstream Label in Section 4.1.1.  In the Path message over the S-LSP hop.

   The egress node receiving this section we will look at Path message MUST signal a Label in
   the RRO processing Resv message for the e2e TE LSP over the LSP segment S-LSP hop.

   An e2e LSP traversing an LSP segment, SHOULD record in  Again, since
   there is no forwarding adjacency between the RRO egress and ingress S-LSP
   nodes, any label exchanged between them is meaningless.  So, the
   egress node MAY choose any label value for
   that hop, an identifier corresponding to the LSP segment TE link.
   This is applicable to both Path Label.  The label
   value chosen and Resv messages over signaled by the LSP
   segment hop.  If egress node is out of the LSP segment scope of
   this document and is numbered, then specific to the IPv4 or IPv6
   address subobject ([5]) implementation on the egress
   node.  The egress S-LSP node SHOULD be used also carry out data plane
   operations so that traffic coming in on the S-LSP is switched over to record
   the e2e LSP segment TE
   link address.  If downstream, if the egress of the e2e LSP segment is unnumbered, then some other
   node downstream.  If the Unnumbered
   Interface ID subobject as described e2e LSP is bidirectional, this means setting
   up label switching in [9] SHOULD be used both directions.  The Resv message from the
   egress S-LSP node is IP routed back to record the node's Router ID and Interface ID previous hop (ingress of
   the LSP segment TE link.  In
   either case, the RRO subobject SHOULD identify the LSP segment S-LSP).  The ingress node stitching an e2e TE
   link end point (link or node).  Intermediate links or nodes traversed
   by the LSP segment itself SHOULD NOT be recorded to an S-LSP
   MUST ignore the Label object received in the RRO Resv for the e2e TE LSP
   over the LSP segment S-LSP hop.

4.2  Summary of LSP Stitching procedures

4.2.1  Example topology  The following topology will be used for the purpose of examples
   quoted S-LSP ingress node SHOULD also carry out
   data plane operations so that traffic coming in on the following sections. e2e LSP
      ++++++++++++++++++++++++++++++++++> (LSP1-2)

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

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

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

4.2.2  LSP segment setup

   A GMPLS node that originates an LSP segment may decide is
   switched into the S-LSP.  It should also carry out actions to use this handle
   traffic in the opposite direction if the e2e LSP segment is bidirectional.

   Note that the label exchange procedure for stitching.  The creation of this LSP segment and its
   use for stitching may be dictated either by configuration or
   dynamically on arrival of an LSP setup request at the GMPLS node.
   Successful completion of signaling procedures S-LSP
   hop, is similar to that for the LSP segment as
   described in Section 4.1 will allow hierarchy over the GMPLS node to : a) advertise
   this LSP segment as a TE link with H-LSP hop.  The
   difference is the bandwidth lack of the LSP as significance of this label between the
   unreserved bandwidth
   S-LSP end points in the IGP and b) carry out case of stitching.  Therefore, in case of
   stitching procedures
   to actually stitch 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 to the LSP segment.  Note that it is
   not, however, required to advertise identifies the LSP segment TE link S-LSP in the
   IGP in ERO and the first place.  Similar S-LSP
   bandwidth has already been allocated to setup, tearing down the LSP
   segment may also be decided either via local configuration or due some other LSP, then regular
   rules of RSVP-TE pre-emption apply to resolve contention for S-LSP
   bandwidth.  If the fact that there is no longer an e2e LSP stitched to request over the LSP
   segment.  E.g.  Let us consider an LSP segment LSP-AB being setup
   between two nodes A and B which may S-LSP cannot be one or more hops away.  A
   sends a Path message for satisfied,
   then the LSP-AB node SHOULD send back a PathErr with "LSP stitching desired".  If
   on the egress node B, stitching error codes as
   described in [5].

5.1.3  RRO Processing for e2e LSP

   RRO procedures are successfully carried
   out, then B will set for the "LSP segment S-LSP specific to LSP stitching ready" are already
   described in Section 5.1.1.  In this section we will look at the RRO
   sent in the Resv.  Once A receives the Resv
   processing for LSP-AB and sees this
   bit set in the RRO, it can then use LSP-AB for stitching.

4.2.3  Setup of e2e LSP

   Other nodes over the S-LSP hop.

   An e2e LSP traversing an S-LSP, SHOULD record in the network (in RRO for that
   hop, an identifier corresponding to the same domain) trying S-LSP TE link.  This is
   applicable to setup an
   e2e LSP across both Path and Resv messages over the network may see S-LSP hop.  If the LSP segment as a
   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
   unnumbered, then the Unnumbered Interface ID subobject as described
   in
   their TE databases [10] SHOULD be used to record the node's Router ID and may compute a path over this Interface
   ID of the S-LSP TE link.  In case
   of an inter-domain e2e LSP, however, either case, the LSP segment TE link, like
   any other basic RRO subobject SHOULD
   identify the S-LSP TE link in end point.  Intermediate links or nodes
   traversed by the domain will not S-LSP itself SHOULD NOT be advertised outside recorded in the RRO for
   the domain.  In this case, either per-domain path computation ([11])
   or PCE based computation ([12]) will permit setting up e2e LSPs over LSP segments in other domains.  The over the S-LSP hop.

5.1.4  Teardown of LSP segment TE link may itself be
   identified as an ERO hop

   S-LSP teardown follows the standard procedures defined in [5] and
   [4].  This includes procedures without and with setting the Path message
   administrative status.  Teardown of S-LSP may be initiated by either
   the e2e LSP message ingress, egress or ERO hops signaled for any other node along the e2e LSP may S-LSP path.
   Deletion/teardown of the S-LSP SHOULD be used treated as a criterion failure event
   for
   LSP segment selection or signaling.  E.g.  Let us consider an the e2e LSP
   LSP1-2 starting one hop before A on R1 associated with it and ending on 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 R2, as
   shown above.  R1 may compute MAY
   treat this to be equivalent to administratively shutting down a path for LSP1-2 over TE
   link along the e2e LSP segment
   LSP-AB path and identify take corresponding actions to notify
   the LSP-AB hop in ingress of this event.  The actual signaling procedures to handle
   this event is out of the ERO or R1 may compute hops
   between A and B and A may use these ERO hops for scope of this document.

5.1.5  Teardown of e2e LSP segment
   selection or signaling a new

   e2e LSP segment.

4.2.4  Stitching 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 into an and of S-LSP are independent of
   each other.  So, it is possible that while one LSP segment

   When follows graceful
   teardown with adminstrative status, the Path message for 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 LSP segment to stitch PathTear message
   like the e2e LSP to is determined.  The Path message for the e2e LSP is then sent directly (IP routed) MUST be IP routed to the LSP segment end egress
   node with the destination IP address of the Path message set to the
   address of the LSP segment S-LSP end node.  The  Router Alert option MUST NOT be set in this case.  Furthermore, when the
   message arrives at the end node, off and RSVP TTL checks
   check MUST be disabled. 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 segment MUST may be identified in initiated from the IF_ID RSVP_HOP (PHOP)
   object tail-
   end either using a ResvTear or a PathErr with state removal.  The
   egress of the Path message.  It is assumed that S-LSP MUST propagate the ResvTear/PathErr upstream, IP
   routed to the receiver ingress of this
   Path message can identify the LSP segment based on segment.

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

   If the data interface
   identification 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 IF_ID RSVP_HOP.  Also, S-LSP MAY be torn down if the no e2e LSP
   is
   bidirectional, an Upstream Label MUST NOT be allocated/signaled in utilizing the Path message.  When S-LSP.  Although the Resv is sent back for S-LSP may be torn down while
   the e2e LSP, LSP is being torn down, it is RECOMMENDED that a
   Label MUST NOT delay be allocated on the LSP segment hop.  When
   introduced in tearing down the Resv is
   received and propagated further upstream (when applicable), S-LSP once the e2e LSP has been stitched teardown is
   complete, in order to reduce the LSP segment.  E.g.  When the Path
   message for the e2e LSP LSP1-2 arrives at node A, simultaneous generation of RSVP
   errors and the LSP segment
   LSP-AB to stitch LSP1-2 teardown messages due to has been identified (either multiple events.  The delay
   interval may be set based on
   explicit hop in ERO or due to local decision),then Path message for
   LSP1-2 implementation.  The RECOMMENDED
   interval is sent directly to node B with 30 seconds.

5.2  Summary of LSP Stitching procedures

5.2.1  Example topology

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

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

                LSP segment LSP-AB.  When B receives this Path message for
   LSP1-2, if (S-LSP)
             =====================> (LSP-AB)
                  C --- E --- G
                 /|\    |   / |\
                / | \   |  /  | \
      R1 ---- A \ |  \  | /   | / B is also the egress for LSP1-2, and if this is a packet --- R2
                 \|   \ |/    |/
                  D --- F --- H

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

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

5.2.2  LSP requiring PHP, then segment setup

   Let us consider an S-LSP LSP-AB being setup between two nodes A and B will send
   which are more than one hop away.  Node A sends a Resv refresh Path message for
   the LSP-AB with
   the NULL Label. "LSP stitching desired" set in Flags field of
   LSP_ATTRIBUTES object.  If B is not the egress, then Path message for LSP1-2 egress node B is propagated ready to R2.  The Resv for LSP1-2 is sent back from carry out
   stitching procedures, then B
   directly to A will respond with no Label "LSP segment stitching
   ready" set in it.  Node the Flags field of the RRO Attributes subobject, in the
   RRO sent in the Resv for the S-LSP.  Once A then propagates receives the Resv
   to R1.  This stitches an e2e LSP LSP1-2 to an LSP segment for
   LSP-AB
   between nodes A and B. In the data plane, sees this yields a series of
   label swaps from R1 to R2 along LSP LSP1-2.

4.2.5  Teardown 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

   When

   Let us consider an e2e LSP teardown is initiated from the head-end, LSP1-2 starting one hop before A on R1 and a
   PathTear arrives at the GMPLS stitching node, the PathTear message
   like the Path message MUST be sent directly to the LSP segment egress
   ending on node with R2, as shown above.  If the destination IP address of S-LSP has been adevrtised
   as a TE link in the Path message set to TE domain, and R1 and A are in the
   address of same domain,
   then R1 may compute a path for LSP1-2 over the LSP segment end node.  Router Alert MUST be off S-LSP LSP-AB and
   RSVP TTL check MUST be disabled on
   identify the receiving node.  PathTear will
   result LSP-AB hop in deletion of RSVP states corresponding to the e2e LSP ERO.  If not, R1 may compute hops
   between A and
   freeing of label allocations B and bandwidth reservations on the LSP
   segment.  The unreserved bandwidth on the LSP segment A may use these ERO hops for S-LSP selection or
   signaling a new S-LSP.  Also, an S-LSP TE link SHOULD cannot be re-adjusted.

   Simiarly, a teardown of
   distinguished from any basic TE link on R1.  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 e2e LSP may domain will
   not be initiated from advertised outside the tail-
   end domain.  R1 would use either using a ResvTear per-domain
   path computation ([12]) or a PathErr with state removal.  The
   egress PCE based computation ([13]) for LSP1-2.

5.2.4  Stitching of the e2e LSP into an LSP segment MUST propagate

   When the ResvTear/PathErr
   upstream directly to Path message for the ingress e2e LSP LSP1-2 arrives at node A, A
   matches the switching type of LSP1-2 with the LSP segment.

   Graceful LSP teardown using ADMIN_STATUS as described in [4] is also
   applicable to stitched LSPs. S-LSP LSP-AB.  If the LSP segment was statically provisioned, tearing down of an e2e
   LSP MAY
   switching types are not result in tearing down of the LSP segment.  If, however, equal, then LSP-AB cannot be used to stitch
   LSP1-2.  Once S-LSP LSP-AB to stitch LSP1-2 to has been determined
   successfully, the LSP segment was dynamically setup due Path message for LSP1-2 is IP routed to node B with
   the e2e LSP setup
   request, then depending on local policy, IF_ID RSVP_HOP identifying the LSP segment MAY be torn
   down S-LSP LSP-AB.  When B receives
   this Path message for LSP1-2, if no e2e LSP B is utilizing also the egress for LSP1-2, and
   if this is a packet LSP segment.  Although requiring PHP, then B will send a Resv
   refresh for LSP-AB with the LSP
   segment may be torn down while NULL Label.  In this case, since B is not
   the e2e LSP egress, the Path message for LSP1-2 is being torn down, it propagated to R2.  The
   Resv for LSP1-2 from B is
   RECOMMENDED that IP routed back to A with a delay be introduced in tearing down the LSP
   segment once Label value
   chosen by B. B also sets up its data plane to swap the e2e LSP teardown is complete, in order Label sent to reduce
   either G or H on the
   simultaneous generation S-LSP with the Label received from R2.  Node A
   ignores the Label on receipt of RSVP errors the  Resv message and teardown messages due then propagates
   the Resv to
   multiple events.  The delay interval may be set based on local
   implementation.  The recommended interval is 30 seconds.

   Also, deletion/teardown of R1.  A also sets up its data plane to swap the LSP segment (due Label sent
   to some failure R1 with the Label received on the S-LSP from C or
   maintenance) SHOULD be treated as a failure event for D. This stitches
   the e2e LSP
   associated with it LSP1-2 to an S-LSP LSP-AB between nodes A and corresponding teardown or recovery procedures
   SHOULD be triggered for B. In the
   data plane, this yields a series of label swaps from R1 to R2 along
   e2e LSP.

5. LSP LSP1-2.

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.

6.

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.

6.1

7.1  Attribute Flags for LSP_ATTRIBUTES object

   The following new flag 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 - 0x02 Bit Number 5 (Suggested value)

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

6.2

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 16 23 (Suggested value)

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

7.

8.  Acknowledgments

   The authors would like to thank Adrian Farrel and Kireeti Kompella
   for their 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.

8.

9.  References

8.1

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, "LSP Hierarchy with Generalized
        MPLS TE", draft-ietf-mpls-lsp-hierarchy-08 (work in progress),
        September 2002.

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

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

8.2

9.2  Informative References

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

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

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

   [10]

   [11]  Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in
         MPLS Traffic Engineering", draft-ietf-mpls-bundle-06 (work in
         progress), December 2004.

   [11]

   [12]  Vasseur, J., "A Per-domain path computation method for
         computing Inter-domain Traffic  Engineering (TE) Label Switched
         Path (LSP)", draft-vasseur-ccamp-inter-domain-pd-path-comp-00
         (work in progress), February 2005.

   [12]

   [13]  Farrel, A., "Path Computation Element (PCE) Architecture",
         draft-ietf-pce-architecture-00 (work in progress), March 2005.

Authors' Addresses

   Arthi Ayyangar (editor)
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: arthi@juniper.net

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

   Email: jpv@cisco.com

Intellectual Property Statement

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

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

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

Disclaimer of Validity

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

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

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