Network Working Group A. Ayyangar, Ed. Internet-Draft Juniper Networks Expires:
October 3, 2005January 16, 2006 JP. Vasseur Cisco Systems, Inc. AprilJuly 15, 2005 Label Switched Path Stitching with Generalized MPLS Traffic Engineering draft-ietf-ccamp-lsp-stitching-00draft-ietf-ccamp-lsp-stitching-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667.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 becomebecomes aware will be disclosed, in accordance with RFC 3668.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. 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 October 3, 2005.January 16, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In certain scenarios, there may be a need to combine together two different Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that in the data plane, a single end-to-endend-to- end (e2e) LSP is achieved and all traffic from one LSP is switched onto the other LSP. We will refer to this as "LSP stitching". This document covers cases where: a) the node performing the stitching does not require configuration of every LSP pair to be stitched together b) the node performing the stitching is not the egress of any of the LSPs c) LSP stitching not only results in an end-to-end LSP in the data plane, but there is also a corresponding end-to-end LSP (RSVP session) in the control plane. It might 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. This document describes the mechanisms to accomplish LSP stitching in the scenarios described above.Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 43 1.1 Conventions used in this document . . . . . . . . . . . . 54 2. Routing aspects . . . . . . . . . . . . . . . . . . . . . . . 65 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 LSP regions and LSP stitching . . . . . . . . . . . . . . 6 3.2 Applications . . . . . . . . . . . . . . . . . . . . . . . 6 4. Signaling aspects . . . . . . . . . . . . . . . . . . . . . . 7 3.14.1 RSVP-TE signaling extensions . . . . . . . . . . . . . . . 7 18.104.22.168 Creating and preparing LSP segment for stitching . . . 7 4.1.2 Stitching the e2e LSP to the LSP segment . . . . . . . 9 4.1.3 RRO Processing for e2e LSP . . . . . . . . . . . . . . 9 4.2 Summary of LSP Stitching procedures . . . . . . . . . . . 10 4.2.1 Example topology . . . . . . . . . . . . . . . . . . . 10 22.214.171.124 LSP segment setup . . . . . . . . . . . . . . . . . . . . 10 4.211 4.2.3 Setup of e2e LSP . . . . . . . . . . . . . . . . . . . . . 10 4.311 4.2.4 Stitching of e2e LSP into an LSP segment . . . . . . . 11 4.2.5 Teardown of e2e LSP . . . . 10. . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 1214 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 1315 6.1 Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 1315 6.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 1315 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 1416 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 1517 8.1 Normative References . . . . . . . . . . . . . . . . . . . 1517 8.2 Informative References . . . . . . . . . . . . . . . . . . 1517 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 1618 Intellectual Property and Copyright Statements . . . . . . . . 1719 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 node can form a forwarding adjacency (FA) over the FA LSP b. other Label Switching Routers (LSRs) can see this FA LSP as a Traffic Engineering (TE) linklink, when needed. c. the GMPLS node can nest one or more LSPs over the FA LSP. This only covers intra-domainLSPs only.in a single domain. d. RSVP signaling for LSP setup can occur between nodes that do not have routing adjacency. LSP stitching is a special case of LSP hierarchy. In case of LSP stitching, instead of an FA LSP, we will createan "LSP segment" betweenis created between two GMPLS nodes. So an LSP segment for stitching is considered to be the moral equivalent of an FA LSP for nesting.nesting and an LSP segment TE link is a moral equivalent of FA (FA-LSP TE link). While LSP hierarchy allows more that one LSP to be admitted into themapped to an FA-LSP, in case of LSP stitching, the desired switching type of the LSP and the switching capability of the LSP segment are such thatat most one LSP may be admitted intomapped to an LSP segment. E.g. if LSP-AB is an FA-LSP between nodes A and B, then multiple LSPs, say LSP1, LSP2, LSP3 could potentially be 'nested into' LSP-AB. This is achieved by exchanging a unique label for each of LSP1..3 over the LSP-AB hop thereby permitting LSP1..3 to share the FA-LSP LSP-AB. Each of LSP1..3 may reserve some bandwidth on LSP-AB. On the other hand, if LSP-AB is an LSP segment, then at most one LSP, say LSP1 may be 'stitched to' the LSP segment LSP-AB. No labels are exchanged for LSP1 over the LSP-AB hop (i.e.directly between nodes A and B directly). Therefore,B. Therefore LSP-AB is dedicated to LSP1 and no other LSPs can be associated with LSP-AB. The entire bandwith on LSP segment LSP-AB is allocated to LSP1. The LSPs LSP1..3 which are either nested or stitched into another LSP are termed as end-to-end (e2e) LSPs in the rest of this document. Signaling and routing procedures for LSP stitching are basically similar to that described in ).. The LSP segment will be seen seensegment, like an FA-LSP is treated as a TE link by all nodes in the network.link. Also, non-adjacent RSVP signaling defined in ) will still beis required to stitch an LSP to an LSP segment. So, 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. AnThe creation/termination of an LSP segment may be created either via a configuration triggerdictated by administrative control (statically provisioned) or dynamicallydue to ananother incoming LSP request.request (dynamic). Triggers for dynamic creation of an LSP segment are different from that of an FA-LSP and will be described in detail later. In this document we will highlight,document, where applicable, similarities and differences in the routing and signaling procedures between LSP hierarchy and LSP stitching.stitching are highlighted. Additional signaling extensions required for LSP stitching are also described here. LSP stitching SHOULD be1.1 Conventions used when the switching types (capabilities) of the LSPin this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and the LSP segment"OPTIONAL" in this document are such that LSP hierarchyto be interpreted as described in ) is not possible. E.g. if the e2e LSP is a lambda LSP and theRFC 2119 . 2. Routing aspects An LSP segment is alsocreated and treated like a lambda LSP, then in this case LSP hierarchy is not possible. LSP stitching could also be useful in networks to bypass legacyTE link between two GMPLS nodes whose path transits zero or more GMPLS nodes which may not have certain new capabilitiesin the control plane and/or data plane. E.g. one suggested usage in case of P2MP RSVP LSPs () is the use of LSP stitching to stitch a P2MP RSVP LSP to an LSP segment between P2MP capable LSRs in the network. The LSP segment would traverse legacy LSRs that may be incapable of acting as P2MP branch points, thereby shielding them from the P2MP control and data path. LSP stitching procedures could also be used for inter-domain TE LSP signaling to stitch an inter-domain LSP to a local intra-domain TE LSP segment (). 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 LSP segment is similar to an FA-LSP in that, an LSP segment like an FA-LSP is created and treated like a TE link between two GMPLS nodes whose path transits zero or more GMPLS nodes in the same instancesame instance of the GMPLS control plane. These TE links may be numbered or unnumbered. For an unnumbered LSP segment, the assignment and handling of the local and remote link identifiers is specified in . Unlike an FA-LSP, a GMPLS node does not have a data plane adjacency with the end point of the LSP segment. This implies that the traffic that arrives at the GMPLS node will be switched into the LSP segment contiguously with a label swap and no label is exchanged directly between the end nodes of the LSP segment itself. Also, aA routing adjacency will not be established over an LSP segment. ISIS/OSPF may, however, flood the TE information associated with an LSP segment, whichsegment TE link, when appropriate. Mechanisms similar to that for regular TE links may be used to flood LSP segment TE links. Advertising or flooding the LSP segment TE link is not a requirement for LSP stitching. Discretion should be used when advertising an LSP segment TE link in IGP. 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 network. The TE parameters defined for an FA in ) are alsoexactly applicable to an LSP segment TE link.link as well. Note that, whilethat the switching capability of an FA-LSPLSP segment TE link can admit zero or more LSPs over it, anMUST be equal to the switching type of the underlying LSP segment; i.e. no hierarchy (nesting) is possible. An LSP segment canTE link SHOULD NOT admit at mostmore than one e2e LSP overinto it. So, once an LSP is stitched into an LSP segment, the unreserved bandwidth on the LSP segment isSHOULD be set to zero. This preventswill prevent any more LSPs from being computed and admitted over the LSP segment TE link. Multiple LSP segments between the same pair of nodes may be bundled using the concept of Link Bundling () into a single TE link. When any component LSP segment is allocated for an LSP, the component's unreserved bandwidth MUSTSHOULD be set to zero and the Minimum and Maximum LSP bandwidth of the TE link SHOULD be recalculated. 3. Signaling aspects In general, the trigger for the creation or termination of anUsage 3.1 LSP regions and LSP stitching An LSP segment may be created either mechanisms which are outside of GMPLSby administrative control (configuration oftrigger) or dynamically due to an incoming LSP segment onrequest. LSP Hierarchy () defines one possible trigger for dynamic creation of FA-LSP by introducing the stitching node) or mechanisms within GMPLS (arrivalnotion of LSP regions based on Interface Switching Capabilities. As per , dynamic FA- LSP creation may be triggered on a node when an incoming LSP setuprequest with appropriate switching type on the stitching node). Although not adjacent in routing, the end nodescrosses region boundaries. However, this trigger MUST NOT be used for creation of theLSP segment will have a signaling adjacency and will exchange RSVP messages directly between each other. When an RSVP-TEfor LSP is signaled over anstitching as described in this document. In case of LSP segment,stitching, the Path message MUST contain an IF_ID RSVP_HOP object switching capabilities of the previous hop and the data interface identificationnext hop TE links MUST identifybe the LSP segment. Forsame. Therefore, local policies configured on the purposenode SHOULD be used for dynamic creation of ERO and RRO as well, an LSP segment is treated exactly like an FA. The main difference between signaling an LSP over anLSP segment insteadsegments. Other possible triggers for dynamic creation of over an FA-LSP is that no Labels are allocatedboth FA-LSPs and exchanged for theLSP segments include cases where an e2e LSP overmay cross domain boundaries or satisfy locally configured policies on the node as described in . 3.2 Applications LSP segment hop. So, at most onestitching procedures described in this document are applicable to GMPLS nodes that need to associate an e2e LSP is associatedwith oneanother LSP segment. If a node at the head-endsegment of the same switching type and LSP hierarchy procedures do not apply. E.g. if an e2e lambda LSP traverses an LSP segment receives a Path MsgTE link which is also lambda switch capable, then in this case LSP hierarchy is not possible. LSP stitching procedures could be used for inter-domain TE LSP signaling to stitch an inter-domain LSP that identifies theto a local intra-domain TE LSP segment (). LSP stitching could also be useful in networks to bypass legacy nodes which may not have certain new capabilities in the ERO andcontrol plane and/or data plane. E.g. one suggested usage in case of P2MP RSVP LSPs () is the use of LSP segment bandwidth has already been allocatedstitching to some other LSP, then regular rules of RSVP-TE pre-emption apply. If thestitch a P2MP RSVP LSP request overto an LSP segment between P2MP capable LSRs in the network. The LSP segment cannotwould traverse legacy LSRs that may be satisfied, thenincapable of acting as P2MP branch points, thereby shielding them from the node SHOULD send backP2MP control and data path. Note, however, that such configuration may of course limit the attractiveness of RSVP P2MP and should carefully be examined before deployment. 4. Signaling aspects The end nodes of the LSP segment do not have a PathErr withrouting adjacency. However, they will have a signaling adjacency and will exchange RSVP messages directly between each other. It may, in fact, be desirable to exchange RSVP Hellos directly between the error codesLSP 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. 3.14.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 mayneeds 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. If a GMPLS node desiresIn cases where such mechanisms exist on these nodes and there is no need to perform LSPsignal "stitching" explicitly, the nodes MAY simply follow LSP hierarchy signaling procedures, but instead of nesting, they will stitch the LSPs in the data plane. Stitching an e2e LSP to an LSP segment involves the following two step process : a. Creating and preparing the LSP segment for stitching by signaling the desire to stitch between end points of the LSP segment and b. Stitching the e2e LSP to the LSP segment 4.1.1 Creating and preparing LSP segment for stitching If a GMPLS node desires to perform LSP stitching, then it MUST indicate this in the Path message for the LSP segment that it plans to use for stitching. This signaling explicitly informs the egress node for the LSP segment that the ingress node is planning to perform stitching over the LSP segment. This will allow the egress of the LSP segment to allocate the correct label(s) as explained below. Also, so that the head-end node can ensure that correct stitching actions were carried out at the egress node, a new flag is defined below in the RRORecord Route Object (RRO) Attributes subobject to indicate that the LSP segment can be used for stitching. In order to request LSP stitching on the LSP segment, we define a new flag bit in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in : 0x02 (TBD): LSP stitching desired bit - This flag will be set in the Attributes Flags TLV of the LSP_ATTRIBUTES object in the Path message for the LSP segment by the head-end of the LSP segment, that desires LSP stitching. This flag MUST notNOT be modified by any other nodes in the network. An LSP segment can only be used for stitching if appropriate label actions were carried out at the egress node of the LSP segment. In order to indicate this to the head-end node of the LSP segment, the following new flag bit is defined in the RRO Attributes sub-object: 0x02 (TBD): LSP segment stitching ready. If an egress node receiving a Path message, supports the LSP_ATTRIBUTES object and the Attributes Flags TLV, and also recognizes the "LSP stitching desired" flag bit, but cannot support the requested stitching behavior, then it MUST send back a PathErr message with an error code of "Routing Problem" and an error sub-code=16sub- code=16 (TBD) "Stitching unsupported" to the head-end node of the LSP segment. If an egress node receiving a Path message with the "LSP stitching desired" flag set, recognizes the object, the TLV and the flag and also supports the desired stitching behavior, then it MUST allocate a non-NULL label for that LSP segment in the corresponding Resv message. Now, so that the head-end node can ensure that the correct label actions will be carried out by the egress node and that the LSP segment 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. Finally, if the egress node for the LSP segment supports the LSP_ATTRIBUTES object but does not recognize the Attributes Flags TLV, or supports the TLV as well but does not recognize this particular flag bit, then it SHOULD simply ignore the above request. An ingress node requesting LSP stitching MUST examine the RRO Attributes sub-object flag corresponding to the egress node for the LSP segment, to make sure that stitching actions were carried out at the egress node. It MUST NOT use the LSP segment for stitching if the "LSP segment stitching ready" flag is cleared. The egress node MUST not allocate any Label in the Resv message for4.1.2 Stitching the e2e TE LSP. Similarly, in case of bidirectional e2e TE LSP, no Upstream Label is allocated overLSP to the LSP segment in the corresponding Path message. An ingressWhen a GMPLS node stitchingreceives an e2e TELSP torequest, depending on the applicable trigger it may either dynamically create an LSP segment MUST ignore any Label object receivedbased on procedures described above or it may map an e2e LSP to an existing LSP segment. The switching type in the Resv forGeneralized Label Request of the e2e TE LSP. 4. Summary of LSP Stitching procedures 4.1LSP segment setup A GMPLS node that originates anMUST be equal to the switching type of the LSP segmentsegment. Other constraints like ERO, bandwidth, local TE policies may decide to use thisalso be used for LSP segment for stitching. The creation of thisselection or signaling. In either case, once an LSP segment and its usehas been selected for stitching mayan e2e LSP, the following procedures MUST be dictated either by configuration or dynamically on arrival offollowed in order to stitch an e2e LSP setup request at theto an LSP segment. The GMPLS node. Successful completion of signaling procedures fornode receiving the e2e LSP segment assetup Path message MUST use the signaling procedures described in Section 3.1 will allow to send the GMPLS nodePath message directly to : a) advertise thisthe end point of the LSP segment assegment. In case of a bidirectional e2e TE link withLSP, an Upstream Label MUST NOT be allocated and signaled in the bandwidth ofPath message for the e2e LSP asover the unreserved bandwidthLSP segment hop. The egress node receiving this Path message MUST NOT allocate any Label in the IGP and b) carry out stitching proceduresResv message for the e2e TE LSP over the LSP segment hop. This Resv message is IP routed back to actually stitchthe previous hop (ingress of the LSP segment). The ingress node stitching an e2e TE LSP to an LSP segment MUST ignore any Label object received in the Resv for the e2e TE LSP segment. Similar to setup, tearing downover the LSP segment may also be decided either via local configuration or due tohop. So, the fact that theremain difference between signaling an e2e LSP over an LSP segment instead of over an FA-LSP is that no longer anLabels are allocated and exchanged for the e2e LSP stitched toover the LSP segment hop. So, at most one e2e LSP is associated with one LSP segment. E.g. Let us considerIf a node at the head- end of an LSP segment LSP-AB being setup between two nodes A and B. A sendsreceives a Path messageMsg for an LSP that identifies the LSP-AB with "LSP stitching desired". If on the egress node B, stitching procedures are successfully carried out, then B will set the "LSPLSP segment stitching ready"in the RRO sent inERO and the Resv. Once A receivesLSP segment bandwidth has already been allocated to some other LSP, then regular rules of RSVP-TE pre- emption apply. If the ResvLSP request over the LSP segment cannot be satisfied, then the node SHOULD send back a PathErr with the error codes as described in . 4.1.3 RRO Processing for LSP-AB and sees this bit sete2e LSP RRO procedures for the LSP segment specific to LSP stitching are already described in Section 4.1.1. In this section we will look at the RRO, it can then use LSP-ABRRO processing for stitching. 4.2 Setup ofthe e2e LSP Other nodesover the LSP segment hop. An e2e LSP traversing an LSP segment, SHOULD record in the network (inRRO for that hop, an identifier corresponding to the same domain) tryingLSP segment TE link. This is applicable to setup an e2eboth Path and Resv messages over the LSP acrosssegment hop. If the network may seeLSP segment is numbered, then the IPv4 or IPv6 address subobject () SHOULD be used to record the LSP segment as aTE link address. If the LSP segment 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 LSP segment TE link. In case of an inter-domain e2e LSP, however,either case, the RRO subobject SHOULD identify the LSP segment TE link, like any other basic TElink inend point (link or node). Intermediate links or nodes traversed by the domain will probably notLSP segment 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 LSP segment TE link may be identified as an ERO hophop. 4.2 Summary of LSP Stitching procedures 4.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 =====================> (LSP-AB) C --- E --- G /|\ | / |\ / | \ | / | \ R1 ---- A \ | \ | / | / B --- R2 \| \ |/ |/ D --- F --- H PATH ======================> (LSP stitching desired) RESV <====================== (LSP segment stitching ready) PATH (no Upstream Label) +++++++++++++++++++++++ ++++++ +++++> <+++++ ++++++ +++++++++++++++++++++++ RESV (no Label) 4.2.2 LSP segment setup A GMPLS node that originates an LSP segment may decide to use this LSP segment for stitching. The creation of this LSP segment and its use for stitching may be dictated either by configuration or dynamically on arrival of an LSP setup request at the GMPLS node. Successful completion of signaling procedures for the LSP segment as described in Section 4.1 will allow the GMPLS node to : a) advertise this LSP segment as a TE link with the bandwidth of the LSP as the unreserved bandwidth in the IGP and b) carry out stitching procedures to actually stitch an e2e LSP to the LSP segment. Note that it is not, however, required to advertise the LSP segment TE link in the IGP in the first place. Similar to setup, tearing down the LSP segment may also be decided either via local configuration or due to the fact that there is no longer an e2e LSP stitched to the LSP segment. E.g. Let us consider an LSP segment LSP-AB being setup between two nodes A and B which may be one or more hops away. A sends a Path message for the LSP-AB with "LSP stitching desired". If on the egress node B, stitching procedures are successfully carried out, then B will set the "LSP segment stitching ready" in the RRO sent in the Resv. Once A receives the Resv for LSP-AB and sees this bit set in the RRO, it can then use LSP-AB for stitching. 4.2.3 Setup of e2e LSP Other nodes in the network (in the same domain) trying to setup an e2e LSP across the network may see the LSP segment as a TE link in their TE databases and may compute a path over this TE link. In case of an inter-domain e2e LSP, however, the LSP segment TE link, like any other basic TE link in the domain will not be advertised outside the domain. In this case, either per-domain path computation () or PCE based computation () will permit setting up e2e LSPs over LSP segments in other domains. The LSP segment TE link may itself be identified as an ERO hop in the Path message of the e2e LSP message or ERO hops signaled for the e2e LSP may be used as a criterion for LSP segment selection or signaling. E.g. Let us consider an e2e LSP LSP1-2 starting one hop before A on R1 and ending on node R2, as shown above. R1 may compute a path for LSP1-2 over the LSP segment LSP-AB and identify the LSP-AB hop in the ERO or R1 may compute hops between A and B and A may use these ERO hops for LSP segment selection or signaling a new LSP segment. 4.2.4 Stitching of e2e LSP into an LSP segment When the Path message for an e2e LSP arrives at the GMPLS stitching node, the LSP segment to stitch the e2e LSP to is determined. The Path message for the e2e LSP is then sent directly (IP routed) to the LSP segment end node with the destination IP address of the Path message set to the address of the LSP segment end node. The Router Alert option MUST NOT be set in this case. Furthermore, when the message arrives at the end node, RSVP TTL checks MUST be disabled. The LSP segment MUST be identified in the IF_ID RSVP_HOP (PHOP) object of the Path message. It is assumed that the receiver of this Path message can identify the LSP segment based on the data interface identification in the IF_ID RSVP_HOP. Also, if the e2e LSP is bidirectional, an Upstream Label MUST NOT be allocated/signaled in the Path message. When the Resv is sent back for the e2e LSP, a Label MUST NOT be allocated on the LSP segment hop. When the Resv is received and propagated further upstream (when applicable), the e2e LSP has been stitched to the LSP segment. E.g. When the Path message for the e2e LSP LSP1-2 arrives at node A, and the LSP segment LSP-AB to stitch LSP1-2 to has been identified (either based on explicit hop in ERO or due to local decision),then Path message for LSP1-2 is sent directly to node B with the IF_ID RSVP_HOP identifying the LSP segment 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. If B is not the egress, then Path message for LSP1-2 is propagated to R2. The Resv for LSP1-2 is sent back from B directly to A with no Label in it. Node A then propagates the Path message of the e2e LSP message. E.g. Let us considerResv to R1. This stitches an e2e LSP LSP1-2 starting one hop before A on R1 and ending on node R2. R1 may compute a path for LSP1-2 over theto an LSP segment LSP-AB between nodes A and identify the LSP-AB hop inB. In the ERO. 4.3 Stitchingdata plane, this yields a series of e2elabel swaps from R1 to R2 along LSP into anLSP1-2. 4.2.5 Teardown of e2e LSP segmentWhen the Path message foran 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 thenMUST be sent directly to the LSP segment endegress node with the destination IP address of the Path message set to the address of the LSP segment 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 LSP segment. The unreserved bandwidth on the LSP segment MUSTTE link SHOULD be identified in the IF_ID RSVP_HOP (PHOP) objectre-adjusted. Simiarly, a teardown of the Path message. It is assumed thate2e LSP may be initiated from the receivertail- end either using a ResvTear or a PathErr with state removal. The egress of this Path message can identifythe LSP segment based on the data interface identification inMUST propagate the IF_ID RSVP_HOP. WhenResvTear/PathErr upstream directly to the Resv is sent back foringress of the e2e LSP, no LabelLSP segment. Graceful LSP teardown using ADMIN_STATUS as described in  is allocated onalso applicable to stitched LSPs. If the LSP segment hop. E.g. When the Path message for thewas statically provisioned, tearing down of an e2e LSP LSP1-2 arrives at node A, andMAY not result in tearing down of the LSP segment. If, however, the LSP segment LSP-AB to stitch LSP1-2 to has been identified (either based on explicit hop in ERO orwas dynamically setup due to local decision), then Path message for LSP1-2 is sent directly to node B withthe IF_ID RSVP_HOP identifyinge2e LSP setup request, then depending on local policy, the LSP segment LSP-AB. When B receives this Path message for LSP1-2,MAY be torn down if Bno e2e LSP is alsoutilizing the egress for LSP1-2, and if thisLSP segment. Although the LSP segment may be torn down while the e2e LSP is being torn down, it is RECOMMENDED that a packetdelay be introduced in tearing down the LSP requiring PHP, then B will send a Resv refresh for LSP-AB withsegment once the NULL Label. If Be2e LSP teardown is notcomplete, in order to reduce the egress, then Path message for LSP1-2 is propagatedsimultaneous generation of RSVP errors and teardown messages due to R2.multiple events. The Resv for LSP1-2delay interval may be set based on local implementation. The recommended interval is sent back from B directly to A with no Label in it. Node A then propagates30 seconds. Also, deletion/teardown of the Resv to R1. This stitches an e2eLSP LSP1-2segment (due to ansome failure or maintenance) SHOULD be treated as a failure event for the e2e LSP segment LSP-AB between nodes Aassociated with it and B. Incorresponding teardown or recovery procedures SHOULD be triggered for the data plane, this yields a series of label swaps from R1 to R2 along LSP LSP1-2.e2e LSP. 5. 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. IANA Considerations The following values have to be defined by IANA for this document. The registry is http://www.iana.org/assignments/rsvp-parameters. 6.1 Attribute Flags for LSP_ATTRIBUTES object The following new flag bit is being defined for the Attributes Flags TLV in the LSP_ATTRIBUTES object. The numeric value should be assigned by IANA. LSP stitching desired bit - 0x02 (Suggested value) This flag bit is only to be used in the Attributes Flags TLV on a Path message. The 'LSP stitching desired bit' has a corresponding 'LSP segment stitching ready' bit to be used in the RRO Attributes sub-object. 6.2 New Error Codes The following new error sub-code is being defined under the RSVP error-code "Routing Problem" (24). The numeric error sub-code value should be assigned by IANA. Stitching unsupported - sub-code 16 (Suggested value) This error code is to be used only in a RSVP PathErr. 7. 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. References 8.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", Internet-Draft draft-ietf-mpls-lsp-hierarchy-08,draft-ietf-mpls-lsp-hierarchy-08 (work in progress), September 2002.  Farrel, A., Papadimitriou, D. and J. Vasseur,"Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", Internet-Draft draft-ietf-mpls-rsvpte-attributes-04, July 2004.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.V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.  Baker, F., Lindell, B.B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. 8.2 Informative References  Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE LSPs", Internet-Draft draft-ietf-mpls-rsvp-te-p2mp-01,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", Internet-Draft draft-ietf-ccamp-inter-domain-rsvp-te-00,draft-ietf-ccamp-inter-domain-rsvp-te-00 (work in progress), February 2005.  Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.  Kompella, K., Rekhter, Y.Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering", Internet-Draft draft-ietf-mpls-bundle-06,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.