GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc5150

Network Working Group A. Ayyangar Request for Comments: 5150 K. Kompella Category: Standards Track Juniper Networks

                                                           JP. Vasseur
                                                   Cisco Systems, Inc.
                                                             A. Farrel
                                                    Old Dog Consulting
                                                         February 2008
                Label Switched Path Stitching with

Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Abstract

 In certain scenarios, there may be a need to combine several
 Generalized Multiprotocol Label Switching (GMPLS) Label Switched
 Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and
 all traffic from one constituent LSP is switched onto the next LSP.
 We will refer to this as "LSP stitching", the key requirement being
 that a constituent LSP not be allocated to more than one e2e LSP.
 The constituent LSPs will be referred to as "LSP segments" (S-LSPs).
 This document describes extensions to the existing GMPLS signaling
 protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-
 TE)) to establish e2e LSPs created from S-LSPs, and describes how the
 LSPs can be managed using the GMPLS signaling and routing protocols.
 It may be possible to configure a GMPLS node to switch the traffic
 from an LSP for which it is the egress, to another LSP for which it
 is the ingress, without requiring any signaling or routing extensions
 whatsoever and such that the operation is 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. Standards Track [Page 1] RFC 5150 LSP Stitching with GMPLS TE February 2008

Table of Contents

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

1. Introduction

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

Ayyangar, et al. Standards Track [Page 2] RFC 5150 LSP Stitching with GMPLS TE February 2008

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

1.1. Conventions Used in This Document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].

2. Comparison with LSP Hierarchy

 LSP hierarchy ([RFC4206]) provides signaling and routing procedures
 so that:
 a. A Hierarchical LSP (H-LSP) can be created.  Such an LSP created in
    one layer can appear as a data link to LSPs in higher layers.  As
    such, one or more LSPs in a higher layer can traverse this H-LSP
    as a single hop; we call this "nesting".
 b. An H-LSP may be managed and advertised (although this is not a
    requirement) as a Traffic Engineering (TE) link.  Advertising an
    H-LSP as a TE link allows other nodes in the TE domain in which it
    is advertised to use this H-LSP in path computation.  If the H-LSP
    TE link is advertised in the same instance of control plane (TE
    domain) in which the H-LSP was provisioned, it is then defined as
    a forwarding adjacency LSP (FA-LSP) and GMPLS nodes can form a
    forwarding adjacency (FA) over this FA-LSP.  There is usually no
    routing adjacency between end points of an FA.  An 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 to have a routing
    adjacency between them.
 c. RSVP signaling ([RFC3473], [RFC3209]) for LSP setup can occur
    between nodes that do not have a routing adjacency.
 In case of LSP stitching, instead of an H-LSP, an LSP segment (S-LSP)
 is created between two GMPLS nodes.  An S-LSP for stitching is
 considered to be the moral equivalent of an H-LSP for nesting.  An
 S-LSP created in one layer, unlike an H-LSP, provides a data link to

Ayyangar, et al. Standards Track [Page 3] RFC 5150 LSP Stitching with GMPLS TE February 2008

 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 bandwidth on
 S-LSP LSP-AB is allocated to LSP1.  However, similar to H-LSPs,
 several S-LSPs may be bundled into a TE link ([RFC4201]).
 The LSPs LSP1..3 that are either nested or stitched into another LSP
 are termed as e2e LSPs in the rest of this document.  Routing
 procedures specific to LSP stitching are detailed in Section 4.
 Targeted (non-adjacent) RSVP signaling defined in [RFC4206] is
 required for LSP stitching of an e2e LSP to an S-LSP.  Specific
 extensions for LSP stitching are described 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 in Section 3.1.

3. Usage

3.1. Triggers for LSP Segment Setup

 An S-LSP may be created either by administrative control
 (configuration trigger) or dynamically due to an incoming LSP
 request.  LSP hierarchy ([RFC4206]) defines one possible trigger for
 dynamic creation of an FA-LSP by introducing the notion of LSP
 regions based on Interface Switching Capabilities.  As per [RFC4206],

Ayyangar, et al. Standards Track [Page 4] RFC 5150 LSP Stitching with GMPLS TE February 2008

 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 an 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
 [RFC5151].

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.
 For example, if an e2e lambda LSP traverses an LSP segment TE link
 that is also lambda-switch capable, then LSP hierarchy is not
 possible; in this case, LSP switching may be an option.
 LSP stitching procedures can be used for inter-domain TE LSP
 signaling to stitch an inter-domain e2e LSP to a local intra-domain
 TE S-LSP ([RFC4726] and [RFC5151]).
 LSP stitching may also be useful in networks to bypass legacy nodes
 that may not have certain new capabilities in the control plane
 and/or data plane.  For example, one suggested usage in the case of
 point-to-multipoint (P2MP) RSVP LSPs ([RFC4875]) is the use of LSP
 stitching to stitch a P2MP RSVP LSP to an LSP segment between P2MP-
 capable Label Switching Routers (LSRs) in the network.  The LSP
 segment would traverse legacy LSRs that may be incapable of acting as
 P2MP branch points, thereby shielding them from the P2MP control and
 data path.  Note, however, that such configuration may limit the
 attractiveness of RSVP P2MP and should carefully be examined before
 deployment.

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.

Ayyangar, et al. Standards Track [Page 5] RFC 5150 LSP Stitching with GMPLS TE February 2008

 The traffic that arrives at the head end of the S-LSP is switched
 into the S-LSP contiguously with a label swap, and no label is
 associated directly between the end nodes of the S-LSP itself.
 An S-LSP MAY be treated and managed as a TE link.  This TE link MAY
 be numbered or unnumbered.  For an unnumbered S-LSP TE link, the
 schemes for assignment and handling of the local and remote link
 identifiers as specified in [RFC3477] SHOULD be used.  When
 appropriate, the TE information associated with an S-LSP TE link MAY
 be flooded via ISIS-TE [RFC4205] or OSPF-TE [RFC4203].  Mechanisms
 similar to that for regular (basic) TE links SHOULD be used to flood
 S-LSP TE links.  Advertising or flooding the S-LSP TE link is not a
 requirement for LSP stitching.  If advertised, this TE information
 will exist in the TE database (TED) and can then be used for path
 computation by other GMPLS nodes in the TE domain in which it is
 advertised.  When so advertising S-LSPs, one should keep in mind that
 these add to the size and complexity of the link-state database.
 If an S-LSP is advertised as a TE link in the same TE domain in which
 it was provisioned, there is no need for a routing adjacency between
 end points of this S-LSP TE link.  If an S-LSP TE link is advertised
 in a different TE domain, the end points of that TE link SHOULD have
 a routing adjacency between them.
 The TE parameters defined for an FA in [RFC4206] SHOULD be used for
 an S-LSP TE link as well.  The switching capability of an S-LSP TE
 link MUST be equal to the switching type of the underlying S-LSP;
 i.e., an S-LSP TE link provides a data link to other LSPs in the same
 layer, so no hierarchy is possible.
 An S-LSP MUST NOT admit more than one e2e LSP into it.  If an S-LSP
 is allocated to an e2e LSP, the unreserved bandwidth SHOULD be set to
 zero to prevent further e2e LSPs from being admitted into the S-LSP.
 Multiple S-LSPs between the same pair of nodes MAY be bundled using
 the concept of Link Bundling ([RFC4201]) into a single TE link.  In
 this case, each component S-LSP may be allocated to at most one e2e
 LSP.  When any component S-LSP is allocated for an e2e LSP, the
 component's unreserved bandwidth SHOULD be set to zero and the
 Minimum and Maximum LSP bandwidth of the TE link SHOULD be
 recalculated.  This will prevent more than one LSP from being
 computed and admitted over an S-LSP.

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

Ayyangar, et al. Standards Track [Page 6] RFC 5150 LSP Stitching with GMPLS TE February 2008

 may, in fact, be desirable to exchange RSVP Hellos directly between
 the LSP segment end points to allow support for state recovery during
 Graceful Restart procedures as described in [RFC3473].
 In order to signal an e2e LSP over an LSP segment, signaling
 procedures described in Section 8.1.1 of [RFC4206] MUST be used.
 Additional signaling extensions for stitching are described in the
 next section.

5.1. RSVP-TE Signaling Extensions

 The signaling extensions described here MUST be used for stitching an
 e2e packet or non-packet GMPLS LSP ([RFC3473]) to an S-LSP.
 Stitching an e2e LSP to an LSP segment involves the following two-
 step process:
 1. Creating and preparing the S-LSP for stitching by signaling the
    desire to stitch between end points of the S-LSP; and
 2. Stitching the e2e LSP to the S-LSP.

5.1.1. Creating and Preparing an LSP Segment for Stitching

 If a GMPLS node desires to create an S-LSP, i.e., one to be used for
 stitching, then it MUST indicate this in the Path message for the S-
 LSP.  This signaling explicitly informs the S-LSP egress node that
 the ingress node is planning to perform stitching over the S-LSP.
 Since an S-LSP is not conceptually different from any other LSP,
 explicitly signaling 'LSP stitching desired' helps clarify the data
 plane actions to be carried out when the S-LSP is used by some other
 e2e LSP.  Also, in the case of packet LSPs, this is what allows the
 egress of the S-LSP to carry out label allocation as explained below.
 Also, so that the head-end node can ensure that correct stitching
 actions will be carried out at the egress node, the egress node MUST
 signal this information back to the head-end node in the Resv, as
 explained below.
 In order to request LSP stitching on the S-LSP, we define a new bit
 in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in
 [RFC4420]:
 LSP stitching desired bit - This bit SHOULD be set in the Attributes
 Flags TLV of the LSP_ATTRIBUTES object in the Path message for the
 S-LSP by the head end of the S-LSP that desires LSP stitching.  This
 bit MUST NOT be modified by any other nodes in the network.  Nodes
 other than the egress of the S-LSP SHOULD ignore this bit.  The bit
 number for this flag is defined in Section 7.1.

Ayyangar, et al. Standards Track [Page 7] RFC 5150 LSP Stitching with GMPLS TE February 2008

 An LSP segment can be used for stitching only if the egress node of
 the S-LSP is also ready to participate in stitching.  In order to
 indicate this to the head-end node of the S-LSP, the following new
 bit is defined in the Flags field of the Record Route object (RRO)
 Attributes subobject: "LSP segment stitching ready".  The bit number
 for this flag is defined in Section 7.1.
 If an egress node of the S-LSP receiving the Path message supports
 the LSP_ATTRIBUTES object and the Attributes Flags TLV, and also
 recognizes the "LSP stitching desired" bit, but cannot support the
 requested stitching behavior, then it MUST send back a PathErr
 message with an error code of "Routing Problem" and an error value of
 "Stitching unsupported" to the head-end node of the S-LSP.  The new
 error value is defined in Section 7.2.
 If an egress node receiving a Path message with the "LSP stitching
 desired" bit set in the Flags field of received LSP_ATTRIBUTES object
 recognizes the object, the TLV 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 subobject.
 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 subobject Flags corresponding to the egress node for the
 S-LSP, to make sure that stitching actions are carried out at the
 egress node.  It MUST NOT use the S-LSP for stitching if the "LSP
 segment stitching ready" bit is cleared.

5.1.1.1. Steps to Support Penultimate Hop Popping

 Note that this section is only applicable to packet LSPs that use
 Penultimate Hop Popping (PHP) at the last hop, where the egress node
 distributes the Implicit NULL Label ([RFC3032]) in the Resv Label.
 These steps MUST NOT be used for a non-packet LSP and for packet LSPs
 where PHP is not desired.
 When the egress node of a packet S-LSP receives a Path message for an
 e2e LSP that uses the S-LSP, the egress of the S-LSP SHOULD first
 check to see if it is also the egress of the e2e LSP.  If the egress
 node is the egress for both the S-LSP and the e2e TE LSP, and this is

Ayyangar, et al. Standards Track [Page 8] RFC 5150 LSP Stitching with GMPLS TE February 2008

 a packet LSP that 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 because 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 map an e2e LSP to an existing S-LSP.
 The switching type in the Generalized Label Request of the e2e LSP
 MUST be equal to the switching type of the S-LSP.  Other constraints
 like the explicit path encoded in the Explicit Route object (ERO),
 bandwidth, and local TE policies MUST also be used for S-LSP
 selection or signaling.  In either case, once an S-LSP has been
 selected for an e2e LSP, the following procedures MUST be followed in
 order to stitch an e2e LSP to an S-LSP.
 The GMPLS node receiving the e2e LSP setup Path message MUST use the
 signaling procedures described in [RFC4206] to send the Path message
 to the end point of the S-LSP.  In this Path message, the node MUST
 identify the S-LSP in the RSVP_HOP.  An egress node receiving this
 RSVP_HOP should also be able to identify the S-LSP TE link based on
 the information signaled in the RSVP_HOP.  If the S-LSP TE link is
 numbered, then the addressing scheme as proposed in [RFC4206] SHOULD
 be used to number the S-LSP TE link.  If the S-LSP TE link is
 unnumbered, then any of the schemes proposed in [RFC3477] SHOULD be
 used to exchange S-LSP TE link identifiers between the S-LSP end
 points.  If the TE link is bundled, the RSVP_HOP SHOULD identify the
 component link as defined in [RFC4201].
 In case of a bidirectional e2e TE LSP, an Upstream Label MUST be
 signaled in the Path message for the e2e LSP over the S-LSP hop.
 However, since there is no forwarding adjacency between the S-LSP end
 points, any label exchanged between them has no significance.  So the
 node MAY chose any label value for the Upstream Label.  The label
 value chosen and signaled by the node in the Upstream Label is out of
 the scope of this document and is specific to the implementation on
 that node.  The egress node receiving this Path message MUST ignore
 the Upstream Label in the Path message over the S-LSP hop.

Ayyangar, et al. Standards Track [Page 9] RFC 5150 LSP Stitching with GMPLS TE February 2008

 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 recipients 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
 message for an e2e LSP that identifies the S-LSP in the ERO and the
 S-LSP bandwidth has already been allocated to some other LSP, then
 regular rules of RSVP-TE pre-emption apply to resolve contention for
 S-LSP bandwidth.  If the LSP request over the S-LSP cannot be
 satisfied, then the node SHOULD send back a PathErr with the error
 codes as described in [RFC3209].

5.1.3. RRO Processing for e2e LSPs

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

Ayyangar, et al. Standards Track [Page 10] RFC 5150 LSP Stitching with GMPLS TE February 2008

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

5.1.4. Teardown of LSP Segments

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

5.1.5. Teardown of e2e LSPs

 e2e LSP teardown also follows standard procedures defined in
 [RFC3209] and [RFC3473] either without or with the administrative
 status.  Note, however, that teardown procedures of e2e LSP and of
 S-LSP are independent of each other.  So it is possible that while
 one LSP follows graceful teardown with administrative 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
 Time to Live (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 readjusted.
 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, and
 MUST use IP addressing to target the ingress of the LSP segment.
 Graceful LSP teardown using ADMIN_STATUS as described in [RFC3473] is
 also applicable to stitched LSPs.

Ayyangar, et al. Standards Track [Page 11] RFC 5150 LSP Stitching with GMPLS TE February 2008

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

5.2.2. LSP Segment Setup

 Let us consider an S-LSP LSP-AB being set up between two nodes A and
 B that are more than one hop away.  Node A sends a Path message for
 the LSP-AB with "LSP stitching desired" set in the Flags field of the

Ayyangar, et al. Standards Track [Page 12] RFC 5150 LSP Stitching with GMPLS TE February 2008

 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.  Node A cannot use LSP-AB for stitching if the bit is
 cleared in the RRO.

5.2.3. Setup of an e2e LSP

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

5.2.4. Stitching of an e2e LSP into an LSP Segment

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

Ayyangar, et al. Standards Track [Page 13] RFC 5150 LSP Stitching with GMPLS TE February 2008

6. Security Considerations

 From a security point of view, the changes introduced in this
 document model the changes introduced by [RFC4206].  That is, the
 control interface over which RSVP messages are sent or received need
 not be the same as the data interface that the message identifies for
 switching traffic.  But the capability for this function was
 introduced in [RFC3473] to support the concept of out-of-fiber
 control channels, so there is nothing new in this concept for
 signaling or security.
 The application of this facility means that the "sending interface"
 or "receiving interface" may change as routing changes.  So these
 interfaces cannot be used to establish security associations between
 neighbors, and security associations MUST be bound to the
 communicating neighbors themselves.
 [RFC2747] provides a solution to this issue: in Section 2.1, under
 "Key Identifier", an IP address is a valid identifier for the sending
 (and by analogy, receiving) interface.  Since RSVP messages for a
 given LSP are sent to an IP address that identifies the next/previous
 hop for the LSP, one can replace all occurrences of 'sending
 [receiving] interface' with 'receiver's [sender's] IP address'
 (respectively).  For example, in Section 4, third paragraph, instead
 of:
    "Each sender SHOULD have distinct security associations (and keys)
     per secured sending interface (or LIH).  ...  At the sender,
     security association selection is based on the interface through
     which the message is sent."
 it should read:
    "Each sender SHOULD have distinct security associations (and keys)
     per secured receiver's IP address. ...  At the sender, security
     association selection is based on the IP address to which the
     message is sent."
 Thus, the mechanisms of [RFC2747] can be used unchanged to establish
 security associations between control plane neighbors.
 This document allows the IP destination address of Path and PathTear
 messages to be the IP address of a next hop node (receiver's address)
 instead of the RSVP session destination address.  This means that the
 use of the IPsec Authentication Header (AH) (ruled out in [RFC2747]

Ayyangar, et al. Standards Track [Page 14] RFC 5150 LSP Stitching with GMPLS TE February 2008

 because RSVP messages were encapsulated in IP packets addressed to
 the ultimate destination of the Path or PathTear messages) is now
 perfectly applicable, and standard IPsec procedures can be used to
 secure the message exchanges.
 An analysis of GMPLS security issues can be found in [MPLS-SEC].

7. IANA Considerations

 IANA has made the following codepoint allocations for this document.

7.1. Attribute Flags for LSP_ATTRIBUTES Object

 The "RSVP TE Parameters" registry includes the "Attributes Flags"
 sub-registry.
 IANA has allocated the following new bit (5) defined for the
 Attributes Flags TLV in the LSP_ATTRIBUTES object.
 LSP stitching bit - Bit Number 5
 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
 subobject.
 The following text has been includuded in the registry:
 Bit | Name                 | Attribute  | Path       | RRO | Reference
 No  |                      | Flags Path | Flags Resv |     |
 ----+----------------------+------------+------------+-----+----------
 5    LSP stitching desired   Yes          No           Yes   [RFC5150]

7.2. New Error Codes

 The "Resource ReSerVation Protocol (RSVP) Parameters" registry
 includes the "Error Codes and Globally-Defined Error Value Sub-Codes"
 sub-registry.
 IANA has assigned a new error sub-code (30) under the RSVP error-code
 "Routing Problem" (24).
 This error code (30) is to be used only in an RSVP PathErr.

Ayyangar, et al. Standards Track [Page 15] RFC 5150 LSP Stitching with GMPLS TE February 2008

 The following text has been included in the registry:
 24  Routing Problem                             [RFC3209]
     30 = Stitching unsupported  [RFC5150]

8. Acknowledgments

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

9. References

9.1. Normative References

 [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2747]    Baker, F., Lindell, B., and M. Talwar, "RSVP
              Cryptographic Authentication", RFC 2747, January 2000.
 [RFC3209]    Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
              V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.
 [RFC3473]    Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Resource ReserVation
              Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
              3473, January 2003.
 [RFC4206]    Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
              Hierarchy with Generalized Multi-Protocol Label
              Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
              October 2005.
 [RFC4420]    Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., 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.

Ayyangar, et al. Standards Track [Page 16] RFC 5150 LSP Stitching with GMPLS TE February 2008

9.2. Informative References

 [RFC3032]    Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.
 [RFC3477]    Kompella, K. and Y. Rekhter, "Signalling Unnumbered
              Links in Resource ReSerVation Protocol - Traffic
              Engineering (RSVP-TE)", RFC 3477, January 2003.
 [RFC4201]    Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
              in MPLS Traffic Engineering (TE)", RFC 4201, October
              2005.
 [RFC4203]    Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
              in Support of Generalized Multi-Protocol Label Switching
              (GMPLS)", RFC 4203, October 2005.
 [RFC4205]    Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate
              System to Intermediate System (IS-IS) Extensions in
              Support of Generalized Multi-Protocol Label Switching
              (GMPLS)", RFC 4205, October 2005.
 [RFC4655]    Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
              Computation Element (PCE)-Based Architecture", RFC 4655,
              August 2006.
 [RFC4726]    Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
              Framework for Inter-Domain Multiprotocol Label Switching
              Traffic Engineering", RFC 4726, November 2006.
 [RFC4875]    Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
              Yasukawa, Ed., "Extensions to Resource Reservation
              Protocol - Traffic Engineering (RSVP-TE) for Point-to-
              Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
              May 2007.
 [RFC5151]    Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
              Domain MPLS and GMPLS Traffic Engineering -- Resource
              Reservation Protocol-Traffic Engineering (RSVP-TE)
              Extensions", RFC 5151, February 2008.
 [RFC5152]    Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
              Per-Domain Path Computation Method for Establishing
              Inter-Domain Traffic Engineering (TE) Label Switched
              Paths (LSPs)", RFC 5152, February 2008.

Ayyangar, et al. Standards Track [Page 17] RFC 5150 LSP Stitching with GMPLS TE February 2008

 [MPLS-SEC]   Fang, L., Ed., Behringer, M., Callon, R., Le Roux, J.
              L., Zhang, R., Knight, P., Stein, Y., Bitar, N., and R.
              Graveman., "Security Framework for MPLS and GMPLS
              Networks", Work in Progress, July 2007.

Authors' Addresses

 Arthi Ayyangar
 Juniper Networks
 1194 N. Mathilda Avenue
 Sunnyvale, CA 94089
 EMail: arthi@juniper.net
 Kireeti Kompella
 Juniper Networks
 1194 N. Mathilda Avenue
 Sunnyvale, CA 94089
 EMail: kireeti@juniper.net
 JP Vasseur
 Cisco Systems, Inc.
 300 Beaver Brook Road
 Boxborough, MA 01719
 EMail: jpv@cisco.com
 Adrian Farrel
 Old Dog Consulting
 EMail: adrian@olddog.co.uk

Ayyangar, et al. Standards Track [Page 18] RFC 5150 LSP Stitching with GMPLS TE February 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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.

Ayyangar, et al. Standards Track [Page 19]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5150.txt · Last modified: 2008/02/27 23:15 (external edit)