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.txtdraft-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 twodifferent Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that in the data plane, a single end-to- end (e2e) LSP is achievedrealized 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 mightmay 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 . . . . . . . . . . . . 43 2. Routing aspectsComparison 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.15.1 RSVP-TE signaling extensions . . . . . . . . . . . . . . . 7 188.8.131.52.1 Creating and preparing LSP segment for stitching . . . 7 184.108.40.206.2 Stitching the e2e LSP to the LSP segment . . . . . . . 9 220.127.116.11.3 RRO Processing for e2e LSP . . . . . . . . . . . . . . 9 4.2 Summary10 5.1.4 Teardown of LSP Stitching proceduressegment . . . . . . . . . . . 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 setupStitching 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.17.1 Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 15 6.27.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 15 7.8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8.9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.19.1 Normative References . . . . . . . . . . . . . . . . . . . 17 8.29.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 () provides signaling and routing procedures so that: a. a GMPLS nodeA Hierarchical LSP (H-LSP) can form a forwarding adjacency (FA) over the FAbe 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 seebe nested into this FA LSPH-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 overTE domain in which it is advertised to use this H-LSP in path computation. If the FA LSP. This only covers LSPsH-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. RSVPforwarding 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 iscomprises of different LSP segments (S-LSPs) that are connected together in the data plane in such a special caseway 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 . 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 segmentAn S-LSP for stitching is considered to be the moral equivalent of an FA LSPH-LSP for nesting andnesting. An S-LSP created in one layer, unlike an LSP segment TE link isH-LSP, provides a moral equivalent of FA (FA-LSP TE link). While LSP hierarchy allows more that one LSP to be mappeddata link to an FA-LSP,other LSPs in case of LSP stitching, at most one LSP may be mappedthe same layer. Similar to an LSP segment. E.g. if LSP-AB isH-LSP, an FA-LSP between nodes A and B, then multiple LSPs, say LSP1, LSP2, LSP3S-LSP could potentiallybe 'nested into' LSP-AB. Thismanaged and advertised, although it is achieved by exchangingnot required, as a unique label for each ofTE 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-LSPH-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 segmentS-LSP LSP-AB. No labels are exchanged for LSP1 over the LSP-AB hop directly between nodes A and B. ThereforeLSP-AB is dedicated to LSP1 and no other LSPs can be associated with LSP-AB. The entire bandwith on LSP segmentS-LSP LSP-AB is allocated to LSP1. However, several S-LSPs MAY be bundled into a TE link (), 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 routingRouting procedures forspecific to LSP stitching are basically similar to that describeddetailed in . The LSP segment, like an FA-LSP is treated as a TE link. Also, non-adjacentSection 4. Targetted (non-adjacent nodes) RSVP signaling defined in ) is required to stitchfor 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/terminationcreation and termination of an LSP segmentS-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 areS-LSP may be different from that of an FA-LSPH-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 required3. 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 . 2. Routing aspects An LSPsegment 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 linkssetup An S-LSP may be numberedcreated 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 . Unlikedynamically due to an FA-LSP, a GMPLS node does not have a data plane adjacency with the end point of theincoming LSP segment. This implies that the traffic that arrives at the GMPLS node will be switched into therequest. LSP segment contiguously with a label swap and no label is exchanged directly between the end nodesHierarchy () 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 anregions based on Interface Switching Capabilities. As per , dynamic FA- LSP segment TE link, when appropriate. Mechanisms similar to that for regular TE linkscreation may be used to flood LSP segment TE links. Advertising or flooding the LSP segment TE link is nottriggered on a requirement fornode when an incoming LSP stitching. Discretion shouldrequest crosses region boundaries. However, this trigger MUST NOT be used when advertising anfor creation of S-LSP for LSP segment TE linkstitching as described in IGP. If advertised,this TE information will exist indocument. In case of LSP stitching, the TE database (TED)switching capabilities of the previous hop and can thenthe 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 defineddynamic creation of LSP segments. Other possible triggers for dynamic creation of both H-LSPs and S-LSPs include cases where an FAe2e LSP may cross domain boundaries or satisfy locally configured policies on the node as described in . 3.2 Applications LSP stitching procedures described in )this document are exactlyapplicable to an LSP segment TE link as well. NoteGMPLS nodes that need to associate an e2e LSP with another S-LSP of the same switching capability oftype 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 underlyingwhich is also lambda switch capable, then in this case LSP segment; i.e. nohierarchy (nesting)is not possible. AnLSP segmentstitching procedures could be used for inter-domain TE link SHOULD NOT admit more than one e2eLSP into it. So, oncesignaling to stitch an inter-domain LSP to a local intra-domain TE S-LSP (). 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 () is stitched intothe use of LSP stitching to stitch a P2MP RSVP LSP to an LSP segment, the unreserved bandwidth onsegment between P2MP capable LSRs in the network. The LSP segment SHOULDwould traverse legacy LSRs that may be set to zero. This will prevent any more LSPsincapable of acting as P2MP branch points, thereby shielding them from being computedthe P2MP control and admitted overdata path. Note, however, that such configuration may limit the LSP segmentattractiveness 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 segmentsSo, 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 ofthese nodes may be bundled usingis also meaningless. The traffic that arrives at the concepthead end of Link Bundling () into a single TE link. When any component LSP segmentthe S-LSP is allocated for an LSP,switched into the component's unreserved bandwidth SHOULD be set to zeroS-LSP contiguously with a label swap and no label is associated directly between the Minimum and Maximum LSP bandwidthend nodes of the TE link SHOULDS-LSP itself. An S-LSP MAY be recalculated. 3. Usage 3.1 LSP regionstreated and LSP stitching An LSP segment maymanaged as a TE link. This TE link MAY be created either by administrative control (configuration trigger)numbered or dynamically due tounnumbered. For an incoming LSP request. LSP Hierarchy () defines one possible trigger for dynamic creation of FA-LSP by introducingunnumbered S-LSP TE link, the notion of LSP regions based on Interface Switching Capabilities. As per , 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 segmentschemes for LSP stitching as described in this document. In case of LSP stitching, the switching capabilities of the previous hopassignment and handling of the next hop TE links MUST be the same. Therefore,local policies configured on the nodeand remote link identifiers as specified in  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 LSPused. ISIS/OSPF may cross domain boundariesflood 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 onflooding the node as described in . 3.2 ApplicationsS-LSP TE link is not a requirement for LSP stitching procedures describedstitching. Discretion should be used when advertising an S-LSP TE link in an IGP. If advertised, this document are applicable toTE 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 ofin the same switching type and LSP hierarchy procedures do not apply. E.g. if an e2e lambda LSP traversesTE domain in which it is advertised. If an LSP segmentS-LSP is advertised as a TE link in the same TE domain in which it was provisioned, there is also lambda switch capable, then inno need for a routing adjacency between end points of this case LSP hierarchyS-LSP TE link. If an S-LSP TE link is not possible. LSP stitching procedures couldadvertised 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  SHOULD be used for inter-domainan S-LSP TE LSP signaling to stitchlink as well. The switching capability of an inter-domain LSP to a local intra-domainS-LSP TE LSP segment (). LSP stitching could alsolink MUST be useful in networksequal to bypass legacy nodes which may not have certain new capabilities inthe control plane and/orswitching 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 casee2e LSP into it. However, multiple S-LSPs between the same pair of P2MP RSVP LSPs () isnodes MAY be bundled using the useconcept of LSP stitching to stitchLink Bundling () into a P2MP RSVP LSP tosingle TE link. So, while an S-LSP can have exactly one e2e LSP segment between P2MP capable LSRs inassociated 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 maycomponent's unreserved bandwidth SHOULD be incapable of acting as P2MP branch points, thereby shielding them fromset to zero and the P2MP controlMinimum and data path. Note, however, that such configuration mayMaximum LSP bandwidth of course limitthe attractiveness of RSVP P2MP and should carefullyTE 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 doan S-LSP may or may not have a routing adjacency. However, they willSHOULD have a signaling adjacency (RSVP neighbor relationship) and will exchange RSVP messages directly betweenwith 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 . In order to signal an e2e LSP over an LSP segment, signaling procedures described in section 8.1.1 of  MUST be used. Additional signaling extensions for stitching are described in the next section. 4.15.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 (), 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 segmentS-LSP for stitching by signaling the desire to stitch between end points of the LSP segmentS-LSP and b. Stitching the e2e LSP to the LSP segment 4.1.1S-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 segmentS-LSP that it plans to use for stitching. This signaling explicitly informs the S-LSP egress node for the LSP segmentthat the ingress node is planning to perform stitching over the LSP segment. This will allowS-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 segmentS-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 werewill be carried out at the egress node, a new flag is defined below inthe Record Route Object (RRO) Attributes subobjectegress node MUST signal this information back to indicate thatthe 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 flagbit in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in : 0x02Bit Number 5 (TBD): LSP stitching desired bit - This flag willbit SHOULD be set in the Attributes Flags TLV of the LSP_ATTRIBUTES object in the Path message for the LSP segmentS-LSP by the head-end of the LSP segment,S-LSP, that desires LSP stitching. This flagbit 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 onlybe used for stitching only if appropriate label actions were carried out atthe 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 flagbit is defined in the Flags field of the RRO Attributes sub-object: 0x02subobject: Bit Number 5 (TBD): LSP segment stitching ready. If an egress node of the S-LSP receiving athe Path message, supports the LSP_ATTRIBUTES object and the Attributes Flags TLV, and also recognizes the "LSP stitching desired" flagbit, 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) "Stitchingcode="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 flagbit and also supports the desired stitching behavior, then it MUST allocate a non-NULL label for that LSP segmentS-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 segmentS-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 segmentS-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 flagbit, then it SHOULD simply ignore the above request. An ingress node requesting LSP stitching MUST examine the RRO Attributes sub-object flagFlags corresponding to the egress node for the LSP segment,S-LSP, to make sure that stitching actions wereare carried out at the egress node. It MUST NOT use the LSP segmentS-LSP for stitching if the "LSP segment stitching ready" flagbit is cleared. 18.104.22.168.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 () 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 triggertrigger, it may either dynamically create an LSP segmentS-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 mayMUST also be used for LSP segmentS-LSP selection or signaling. In either case, once an LSP segmentS-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  to send the Path message directlyPath 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  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  SHOULD be used to exchange S-LSP TE link identifiers between the S-LSP end point ofpoints. If the LSP segment.TE link is bundled, the RSVP_HOP SHOULD identify the component link as defined in . In case of a bidirectional e2e TE LSP, an Upstream Label MUST NOTbe allocated andsignaled 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 segmentS-LSP hop. This Resv messageHowever, since there is IP routed back to the previous hop (ingress ofno forwarding adjacency between the LSP segment). The ingress node stitching an e2e TE LSP to an LSP segment MUST ignoreS-LSP end points, any Label object received in the Resv for the e2e TE LSP over the LSP segment hop. So, the main differencelabel exchanged between signaling an e2e LSP over an LSP segment instead of over an FA-LSP is thatthem has no Labels are allocated and exchanged for the e2e LSP oversignificance. So the LSP segment hop. So, at most one e2e LSP is associated with one LSP segment. If anode at the head- end of an LSP segment receives a Path MsgMAY chose any label value for an LSP that identifies the LSP segment inthe EROUpstream 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, thensignaled by the node SHOULD send back a PathErr with the error codes as describedin . 4.1.3 RRO Processing for e2e LSP RRO procedures forthe LSP segmentUpstream Label is out of the scope of this document and is specific to LSP stitching are already describedthe implementation on that node. The egress node receiving this Path message MUST ignore the Upstream Label in Section 4.1.1. Inthe Path message over the S-LSP hop. The egress node receiving this section we will look atPath message MUST signal a Label in the RRO processingResv message for the e2e TE LSP over the LSP segmentS-LSP hop. An e2e LSP traversing an LSP segment, SHOULD record inAgain, since there is no forwarding adjacency between the RROegress 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 tothe LSP segment TE link. This is applicable to both PathLabel. The label value chosen and Resv messages oversignaled by the LSP segment hop. Ifegress node is out of the LSP segmentscope of this document and is numbered, thenspecific to the IPv4 or IPv6 address subobject ()implementation on the egress node. The egress S-LSP node SHOULD be usedalso carry out data plane operations so that traffic coming in on the S-LSP is switched over to recordthe e2e LSP segment TE link address. Ifdownstream, if the egress of the e2e LSP segmentis unnumbered, thensome other node downstream. If the Unnumbered Interface ID subobject as describede2e LSP is bidirectional, this means setting up label switching in  SHOULD be usedboth directions. The Resv message from the egress S-LSP node is IP routed back to recordthe node's Router ID and Interface IDprevious hop (ingress of the LSP segment TE link. In either case, the RRO subobject SHOULD identify the LSP segmentS-LSP). The ingress node stitching an e2e TE link end point (link or node). Intermediate links or nodes traversed by theLSP segment itself SHOULD NOT be recordedto an S-LSP MUST ignore the Label object received in the RROResv for the e2e TE LSP over the LSP segmentS-LSP hop. 4.2 Summary of LSP Stitching procedures 4.2.1 Example topologyThe following topology will be used for the purpose of examples quotedS-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 decideis switched into the S-LSP. It should also carry out actions to use thishandle traffic in the opposite direction if the e2e LSP segmentis bidirectional. Note that the label exchange procedure for stitching. The creation of thisLSP segment and its use forstitching may be dictated either by configuration or dynamicallyon arrival of an LSP setup request atthe GMPLS node. Successful completion of signaling proceduresS-LSP hop, is similar to that for theLSP segment as described in Section 4.1 will allowhierarchy over the GMPLS node to : a) advertise this LSP segment as a TE link withH-LSP hop. The difference is the bandwidthlack of the LSP assignificance of this label between the unreserved bandwidthS-LSP end points in the IGP and b) carry outcase of stitching. Therefore, in case of stitching procedures to actually stitchthe 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. Notethat it is not, however, required to advertiseidentifies the LSP segment TE linkS-LSP in the IGP inERO and the first place. SimilarS-LSP bandwidth has already been allocated to setup, tearing down the LSP segment may also be decided either via local configuration or duesome 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 e2eLSP stitched torequest over the LSP segment. E.g. Let us consider an LSP segment LSP-AB being setup between two nodes A and B which mayS-LSP cannot be one or more hops away. A sends a Path message forsatisfied, then the LSP-ABnode SHOULD send back a PathErr with "LSP stitching desired". If onthe egress node B, stitchingerror codes as described in . 5.1.3 RRO Processing for e2e LSP RRO procedures are successfully carried out, then B will setfor the "LSP segmentS-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 Resvprocessing for LSP-AB and sees this bit set inthe RRO, it can then use LSP-AB for stitching. 4.2.3 Setup ofe2e LSP Other nodesover the S-LSP hop. An e2e LSP traversing an S-LSP, SHOULD record in the network (inRRO for that hop, an identifier corresponding to the same domain) tryingS-LSP TE link. This is applicable to setup an e2e LSP acrossboth Path and Resv messages over the network may seeS-LSP hop. If the LSP segment as aS-LSP is numbered, then the IPv4 or IPv6 address subobject () 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 SHOULD be used to record the node's Router ID and may compute a path over thisInterface 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 basicRRO subobject SHOULD identify the S-LSP TE link inend point. Intermediate links or nodes traversed by the domain will notS-LSP itself SHOULD NOT be advertised outsiderecorded in the RRO for the domain. In this case, either per-domain path computation () or PCE based computation () will permit setting upe2e LSPs overLSP segments in other domains. Theover the S-LSP hop. 5.1.4 Teardown of LSP segment TE link may itself be identified as an ERO hopS-LSP teardown follows the standard procedures defined in  and . This includes procedures without and with setting the Path messageadministrative status. Teardown of S-LSP may be initiated by either the e2e LSP messageingress, egress or ERO hops signaled forany other node along the e2e LSP mayS-LSP path. Deletion/teardown of the S-LSP SHOULD be usedtreated as a criterionfailure event for LSP segment selection or signaling. E.g. Let us consider anthe e2e LSP LSP1-2 starting one hop before A on R1associated with it and ending oncorresponding 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 computeMAY treat this to be equivalent to administratively shutting down a path for LSP1-2 overTE link along the e2e LSP segment LSP-ABpath and identifytake corresponding actions to notify the LSP-AB hop iningress 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 forscope of this document. 5.1.5 Teardown of e2e LSP segment selection or signaling a newe2e LSP segment. 4.2.4 Stitchingteardown also follows standard procedures defined in  and  either without or with the administrative status. Note, however, that teardown procedures of e2e LSP into anand of S-LSP are independent of each other. So, it is possible that while one LSP segment Whenfollows graceful teardown with adminstrative status, the Path message forother 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 stitchPathTear message like the e2e LSP to is determined. ThePath message for the e2e LSP is then sent directly (IP routed)MUST be IP routed to the LSP segment endegress node with the destination IP address of the Path message set to the address of the LSP segmentS-LSP end node. TheRouter Alert optionMUST NOTbe set in this case. Furthermore, when the message arrives at the end node,off and RSVP TTL checkscheck 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 MUSTmay be identified ininitiated from the IF_ID RSVP_HOP (PHOP) objecttail- end either using a ResvTear or a PathErr with state removal. The egress of the Path message. It is assumed thatS-LSP MUST propagate the ResvTear/PathErr upstream, IP routed to the receiveringress of this Path message can identifythe LSP segment based onsegment. Graceful LSP teardown using ADMIN_STATUS as described in  is also applicable to stitched LSPs. If the data interface identificationS-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 theno e2e LSP is bidirectional, an Upstream Label MUST NOT be allocated/signaled inutilizing the Path message. WhenS-LSP. Although the Resv is sent back forS-LSP may be torn down while the e2e LSP,LSP is being torn down, it is RECOMMENDED that a Label MUST NOTdelay be allocated on the LSP segment hop. Whenintroduced in tearing down the Resv is received and propagated further upstream (when applicable),S-LSP once the e2e LSP has been stitchedteardown 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-2teardown messages due to has been identified (eithermultiple events. The delay interval may be set based on explicit hop in ERO or due tolocal decision),then Path message for LSP1-2implementation. The RECOMMENDED interval is sent directly to node B with30 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 identifyingpurpose 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, thensegment setup Let us consider an S-LSP LSP-AB being setup between two nodes A and B will sendwhich are more than one hop away. Node A sends a Resv refreshPath message for the LSP-AB with the NULL Label."LSP stitching desired" set in Flags field of LSP_ATTRIBUTES object. If B is notthe egress, then Path message for LSP1-2egress node B is propagatedready to R2. The Resv for LSP1-2 is sent back fromcarry out stitching procedures, then B directly to Awill respond with no Label"LSP segment stitching ready" set in it. Nodethe Flags field of the RRO Attributes subobject, in the RRO sent in the Resv for the S-LSP. Once A then propagatesreceives the Resv to R1. This stitches an e2e LSP LSP1-2 to an LSP segmentfor LSP-AB between nodes Aand B. In the data plane,sees this yields a series of label swaps from R1 to R2 along LSP LSP1-2. 4.2.5 Teardownbit 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 WhenLet 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 egressending on node withR2, as shown above. If the destination IP address ofS-LSP has been adevrtised as a TE link in the Path message set toTE domain, and R1 and A are in the address ofsame domain, then R1 may compute a path for LSP1-2 over the LSP segment end node. Router Alert MUST be offS-LSP LSP-AB and RSVP TTL check MUST be disabled onidentify the receiving node. PathTear will resultLSP-AB hop in deletion of RSVP states corresponding tothe e2e LSPERO. If not, R1 may compute hops between A and freeing of label allocationsB and bandwidth reservations on the LSP segment. The unreserved bandwidth on the LSP segmentA may use these ERO hops for S-LSP selection or signaling a new S-LSP. Also, an S-LSP TE link SHOULDcannot be re-adjusted. Simiarly, a teardown ofdistinguished 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 maydomain will not be initiated fromadvertised outside the tail- enddomain. R1 would use either using a ResvTearper-domain path computation () or a PathErr with state removal. The egressPCE based computation () for LSP1-2. 5.2.4 Stitching of thee2e LSP into an LSP segment MUST propagateWhen the ResvTear/PathErr upstream directly toPath message for the ingresse2e 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  is also applicable to stitched LSPs.S-LSP LSP-AB. If the LSP segment was statically provisioned, tearing down of an e2e LSP MAYswitching 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 duePath 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 downS-LSP LSP-AB. When B receives this Path message for LSP1-2, if no e2e LSPB is utilizingalso the egress for LSP1-2, and if this is a packet LSP segment. Althoughrequiring PHP, then B will send a Resv refresh for LSP-AB with the LSP segment may be torn down whileNULL Label. In this case, since B is not the e2e LSPegress, the Path message for LSP1-2 is being torn down, itpropagated to R2. The Resv for LSP1-2 from B is RECOMMENDED thatIP routed back to A with a delay be introduced in tearing down the LSP segment onceLabel value chosen by B. B also sets up its data plane to swap the e2e LSP teardown is complete, in orderLabel sent to reduceeither G or H on the simultaneous generationS-LSP with the Label received from R2. Node A ignores the Label on receipt of RSVP errorsthe Resv message and teardown messages duethen 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 ofR1. A also sets up its data plane to swap the LSP segment (dueLabel sent to some failureR1 with the Label received on the S-LSP from C or maintenance) SHOULD be treated as a failure event forD. This stitches the e2e LSP associated with itLSP1-2 to an S-LSP LSP-AB between nodes A and corresponding teardown or recovery procedures SHOULD be triggered forB. 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 , 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  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,  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.17.1 Attribute Flags for LSP_ATTRIBUTES object The following new flagbit 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 - 0x02Bit Number 5 (Suggested value) This flagbit 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.27.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 1623 (Suggested value) This error code is to be used only in aan 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.19.1 Normative References  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08 (work in progress), September 2002.  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.  Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.  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.  Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. 8.29.2 Informative References  Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-01 (work in progress), January 2005.  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.  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.  Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.  Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering", draft-ietf-mpls-bundle-06 (work in progress), December 2004.  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.  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: email@example.com Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 US Email: firstname.lastname@example.org 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 email@example.com. 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.