diff options
Diffstat (limited to 'doc/rfc/rfc4873.txt')
| -rw-r--r-- | doc/rfc/rfc4873.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc4873.txt b/doc/rfc/rfc4873.txt new file mode 100644 index 0000000..8ed7b42 --- /dev/null +++ b/doc/rfc/rfc4873.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group L. Berger +Request for Comments: 4873 LabN Consulting +Updates: 3473, 4872 I. Bryskin +Category: Standards Track ADVA Optical + D. Papadimitriou + Alcatel + A. Farrel + Old Dog Consulting + May 2007 + + + GMPLS Segment Recovery + +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. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This document describes protocol specific procedures for GMPLS + (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource + ReserVation Protocol - Traffic Engineering) signaling extensions to + support label switched path (LSP) segment protection and restoration. + These extensions are intended to complement and be consistent with + the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). + Implications and interactions with fast reroute are also addressed. + This document also updates the handling of NOTIFY_REQUEST objects. + + + + + + + + + + + + + + + + +Berger, et al. Standards Track [Page 1] + +RFC 4873 GMPLS Segment Recovery May 2007 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................3 + 2. Segment Recovery ................................................4 + 2.1. Segment Protection .........................................6 + 2.2. Segment Re-routing and Restoration .........................6 + 3. ASSOCIATION Object ..............................................6 + 3.1. Format .....................................................7 + 3.2. Procedures .................................................7 + 3.2.1. Recovery Type Processing ............................7 + 3.2.2. Resource Sharing Association Type Processing ........7 + 4. Explicit Control of LSP Segment Recovery ........................8 + 4.1. Secondary Explicit Route Object Format .....................8 + 4.1.1. Protection Subobject ................................8 + 4.2. Explicit Control Procedures ................................9 + 4.2.1. Branch Failure Handling ............................10 + 4.2.2. Resv Message Processing ............................11 + 4.2.3. Admin Status Change ................................12 + 4.2.4. Recovery LSP Teardown ..............................12 + 4.3. Teardown From Non-Ingress Nodes ...........................12 + 4.3.1. Modified NOTIFY_REQUEST Object Processing ..........13 + 4.3.2. Modified Notify and Error Message Processing .......14 + 5. Secondary Record Route Objects .................................14 + 5.1. Format ....................................................14 + 5.2. Path Processing ...........................................15 + 5.3. Resv Processing ...........................................15 + 6. Dynamic Control of LSP Segment Recovery ........................16 + 6.1. Modified PROTECTION Object Format .........................16 + 6.2. Dynamic Control Procedures ................................17 + 7. Updated RSVP Message Formats ...................................18 + 8. Security Considerations ........................................20 + 9. IANA Considerations ............................................21 + 9.1. New Association Type Assignment ...........................21 + 9.2. Definition of PROTECTION Object Reserved Bits .............21 + 9.3. Secondary Explicit Route Object ...........................21 + 9.4. Secondary Record Route Object .............................21 + 9.5. New Error Code ............................................22 + 9.6. Use of PROTECTION Object C-type ...........................22 + 10. References ....................................................23 + 10.1. Normative References .....................................23 + 10.2. Informative References ...................................23 + + + + + + + + + +Berger, et al. Standards Track [Page 2] + +RFC 4873 GMPLS Segment Recovery May 2007 + + +1. Introduction + + [RFC4427] covers multiple types of protection, including end-to-end + and segment-based approaches. "RSVP-TE Extensions in Support of + End-to-End Generalized Multi-Protocol Label Switching (GMPLS) + Recovery" [RFC4872] defines a set of extensions to support multiple + types of recovery. The supported types include 1+1 unidirectional/ + 1+1 bidirectional protection, LSP protection with extra-traffic + (including 1:N protection with extra-traffic), pre-planned LSP re- + routing without extra-traffic (including shared mesh), and full LSP + re-routing. In all cases, the recovery is provided on an end-to-end + basis, i.e., the ingress and egress nodes of both the protected and + the protecting LSP are the same. + + [RFC4090] provides a form of segment recovery for packet MPLS-TE + networks. Two methods of fast reroute are defined in [RFC4090]. The + one-to-one backup method creates detour LSPs for each protected LSP + at each potential point of local repair. The facility backup method + creates a bypass tunnel to protect a potential failure point that is + shared by multiple LSPs and uses label stacking. Neither approach + supports the full set of recovery types supported by [RFC4872]. + Additionally, the facility backup method is not applicable to most + non-PSC (packet switch capable) switching technologies. + + The extensions defined in this document allow for support of the full + set of recovery types supported by [RFC4872], but on a segment, or + portion of the LSP, basis. The extensions allow (a) the signaling of + desired LSP segment protection type, (b) upstream nodes to optionally + identify where segment protection starts and stops, (c) the optional + identification of hops used on protection segments, and (d) the + reporting of paths used to protect an LSP. The extensions also widen + the topological scope over which protection can be supported. They + allow recovery segments that protect against an arbitrary number of + nodes and links. They enable overlapping protection and nested + protection. These extensions are intended to be compatible with fast + reroute, and in some cases used with fast reroute. + +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 [RFC2119]. + + In addition, the reader is assumed to be familiar with the + terminology used in [RFC3209], [RFC3471], and [RFC3473], as well as + [RFC4427], [RFC4426], [RFC4872], and [RFC4090]. + + + + + +Berger, et al. Standards Track [Page 3] + +RFC 4873 GMPLS Segment Recovery May 2007 + + +2. Segment Recovery + + Segment recovery is used to provide protection and restoration over a + portion of an end-to-end LSP. Such segment protection and + restoration is useful to protect against a span failure, a node + failure, or failure over a particular portion of a network used by an + LSP. + + Consider the following topology: + + A---B---C---D---E---F + \ / + G---I + + In this topology, end-to-end protection and recovery is not possible + for an LSP going between node A and node F, but it is possible to + protect/recover a portion of the LSP. Specifically, if the LSP uses + a working path of [A,B,C,D,E,F], then a protection or restoration LSP + can be established along the path [C,G,I,E]. This LSP protects + against failures on spans {C,D} and {D,E}, as well as a failure of + node D. This form of protection/restoration is referred to as + Segment Protection and Segment Restoration, or as Segment Recovery, + collectively. The LSP providing the protection or restoration is + referred to as a segment protection LSP or a segment restoration LSP. + The term "segment recovery LSP" is used to cover either a segment + protection LSP or a segment restoration LSP. The term "branch node" + is used to refer to a node that initiates a recovery LSP, e.g., node + C in the figure shown above. This is equivalent to the point of + local repair (PLR) used in [RFC4090]. As with [RFC4090], the term + "merge node" is used to refer to a node that terminates a recovery + LSP, e.g., node E in the figure shown above. + + Segment protection or restoration is signaled using a working LSP and + one or more segment recovery LSPs. Each segment recovery LSP is + signaled as an independent LSP. Specifically, the Sender_Template + object uses the IP address of the node originating the recovery path, + e.g., node C in the topology shown above, and the Session object + contains the IP address of the node terminating the recovery path, + e.g., node E shown above. There is no specific requirement on LSP ID + value, Tunnel ID, and Extended Tunnel ID. Values for these fields + are selected normally, including consideration for the make-before- + break concept (as described in [RFC3209]). Intermediate nodes follow + standard signaling procedures when processing segment recovery LSPs. + A segment recovery LSP may be protected itself using segment or end- + to-end protection/restoration. Note, in PSC environments, it may be + desirable to construct the Sender_Template and Session objects per + [RFC4090]. + + + + +Berger, et al. Standards Track [Page 4] + +RFC 4873 GMPLS Segment Recovery May 2007 + + + When [RFC4090] isn't being used, the association between segment + recovery LSPs with other LSPs is indicated using the ASSOCIATION + object defined in [RFC4872]. The ASSOCIATION object is used to + associate recovery LSPs with the LSP they are protecting. Working + and protecting LSPs, as well as primary and secondary LSPs, are + identified using LSP Status as described in [RFC4872]. The O-bit in + the segment flags portion of the PROTECTION object is used to + identify when a recovery LSP is carrying the normal (active) traffic. + + An upstream node can permit downstream nodes to dynamically identify + branch and merge points by setting the desired LSP segment protection + bits in the PROTECTION object. These bits are defined below. + + Optionally, an upstream node, usually the ingress node, can identify + the endpoints of a segment recovery LSP. This is accomplished using + a new object. This object uses the same format as an Explicit Route + Object (ERO) and is referred to as a Secondary Explicit Route object + (SERO); see Section 4.1. SEROs also support a new subobject to + indicate the type of protection or restoration to be provided. At a + minimum, an SERO will indicate a recovery LSP's initiator, + protection/restoration type and terminator. Standard ERO semantics + (see [RFC3209]) can optionally be used within and SERO to explicitly + control the recovery LSP. A Secondary Record Route object (SRRO) is + defined for recording the path of a segment recovery LSP; see Section + 5. + + SEROs are carried between the node creating the SERO, typically the + ingress, and the node initiating a recovery LSP. The node initiating + a recovery LSP uses the SERO to create the ERO for the recovery LSP. + At this (branch) node, all local objects are removed, and the new + protection subobject is used to create the PROTECTION object for the + recovery LSP. It is also possible to control the handling of a + failure to establish a recovery LSP. + + SRROs are carried in Path messages between the node terminating a + recovery LSP, the merge node, and the egress. SRROs are used in Resv + messages between a branch node and the ingress. The merge node of a + recovery LSP creates an SRRO by copying the RRO from the Path message + of the associated recovery LSP into a new SRRO object. Any SRROs + present in the recovery LSP's Path message are also copied. The + branch node of a recovery LSP creates an SRRO by copying the RRO from + the Resv message of associated recovery LSP into a new SRRO object. + Any SRROs present in the recovery LSP's Resv message are also copied. + + Notify request processing is also impacted by LSP segment recovery. + Per [RFC3473], only one NOTIFY_REQUEST object is meaningful and + should be propagated. Additional NOTIFY_REQUEST objects are used to + identify recovery LSP branch nodes. + + + +Berger, et al. Standards Track [Page 5] + +RFC 4873 GMPLS Segment Recovery May 2007 + + +2.1. Segment Protection + + Three approaches for end-to-end protection are defined in [RFC4872]: + 1+1 Unidirectional Protection (Section 5), 1+1 Bidirectional + Protection (Section 6), and 1:1 Protection With Extra-Traffic + (Section 7). The segment protection forms of these protection + approaches all operate much like their end-to-end counterparts. Each + behaves just like its end-to-end counterpart, with the exception that + the protection LSP protects only a portion of the working LSP. The + type of protection to be used on a segment protection LSP is + indicated, to the protection LSP's ingress, using the protection SERO + subobject defined in Section 4.1. + + The switch-over processing for segment 1+1 Bidirectional protection + and 1:1 Protection With Extra-Traffic follows the same procedures as + end-to-end protection forms; see Sections 6.2 and 7.2 of [RFC4872] + for details. + +2.2. Segment Re-routing and Restoration + + Three re-routing and restoration approaches are defined in [RFC4872]: + Re-routing without Extra-Traffic (Section 8), Shared-Mesh Restoration + (Section 9), (Full) LSP Re-routing (Section 11). As with protection, + these approaches are supported on a segment basis. The segment forms + of re-routing and restoration operate exactly like their end-to-end + counterparts, with the exception that the restoration LSP recovers + only a portion of the working LSP. The type of re-routing or + restoration to be used on a segment restoration LSP is indicated, to + the restoration LSP's ingress, using the new protection SERO + subobject. + +3. ASSOCIATION Object + + The ASSOCIATION object is used for the association of segment + protection LSPs when [RFC4090] isn't being used. The ASSOCIATION + object is defined in [RFC4872]. In this document, we define a new + Association Type field value to support make-before-break; the + formats and procedures defined in [RFC4872] are not otherwise + modified. + + + + + + + + + + + + +Berger, et al. Standards Track [Page 6] + +RFC 4873 GMPLS Segment Recovery May 2007 + + +3.1. Format + + Association Type: 16 bits + + Value Type + ----- ---- + 2 Resource Sharing (R) + + See [RFC4872] for the definition of other fields and values. + +3.2. Procedures + + The ASSOCIATION object is used to associate different LSPs with each + other. In the protection and restoration context, the object is used + to associate a recovery LSP with the LSP it is protecting. The + ASSOCIATION object is also used to support resource sharing during + make-before-break. This object MUST NOT be used when association is + made according to the methods defined in [RFC4090]. + +3.2.1. Recovery Type Processing + + Recovery type processing procedures are the same as those defined in + [RFC4872], but processing and identification occur with respect to + segment recovery LSPs. Note that this means that multiple + ASSOCIATION objects of type recovery may be present on an LSP. + +3.2.2. Resource Sharing Association Type Processing + + The ASSOCIATION object with an Association Type with the value + Resource Sharing is used to enable resource sharing during make- + before-break. Resource sharing during make-before-break is defined + in [RFC3209]. The defined support only works with LSPs that share + the same LSP egress. With the introduction of segment recovery LSPs, + it is now possible for an LSP endpoint to change during make-before- + break. + + A node includes an ASSOCIATION object with a Resource Sharing + Association Type in an outgoing Path message when it wishes to + indicate resource sharing across an associated set of LSPs. The + Association Source is set to the originating node's router address. + The Association ID MUST be set to a value that uniquely identifies + the association of LSPs. This MAY be set to the working LSP's LSP + ID. Once included, an ASSOCIATION object with a Resource Sharing + Association Type SHOULD NOT be removed from the Path messages + associated with an LSP. + + + + + + +Berger, et al. Standards Track [Page 7] + +RFC 4873 GMPLS Segment Recovery May 2007 + + + Any node processing a Path message for which the node does not have a + matching state, and which contains an ASSOCIATION object with a + Resource Sharing type, examines existing LSPs for matching + Association Type, Association Source, and Association ID values. If + any match is found, then [RFC3209] style resource sharing SHOULD be + provided between the new and old LSPs. See [RFC3209] for additional + details. + +4. Explicit Control of LSP Segment Recovery + + Secondary Explicit Route objects, or SEROs, are defined in this + document. They may be used to indicate the branch and merge nodes of + recovery LSPs. They may also provide additional information that is + to be carried in a recovery LSP's ERO. When upstream control of + branch and merge nodes is not desired, SEROs are not used. + +4.1. Secondary Explicit Route Object Format + + The format of a SECONDARY_EXPLICIT_ROUTE object is the same as an + EXPLICIT_ROUTE object. This includes the definition of subobjects + defined for EXPLICIT_ROUTE object. The class of the + SECONDARY_EXPLICIT_ROUTE object is 200 (of the form 11bbbbbb). + +4.1.1. Protection Subobject + + A new subobject, called the protection subobject, is defined for use + in the SECONDARY_EXPLICIT_ROUTE object. As mentioned above, the new + protection subobject is used to create the PROTECTION object for the + recovery LSP. Specific procedures related to the protection + subobject are provided in Section 4.2. The protection subobject is + not valid for use with the Explicit and Record Route objects and MUST + NOT be included in those objects. + + The format of the protection subobject is defined as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |L| Type | Length | Reserved | C-Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PROTECTION Object Contents | + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + L-bit + + This is defined in [RFC3209] and MUST be set to zero for + protection subobjects. + + + +Berger, et al. Standards Track [Page 8] + +RFC 4873 GMPLS Segment Recovery May 2007 + + + Type + + 37 Protection + + Length + + As defined in [RFC3209], Section 4.3.3. + + Reserved + + This field is reserved. It MUST be set to zero on transmission + and MUST be ignored on receipt. + + C-Type + + The C-Type of the included PROTECTION object. + + PROTECTION Object Contents + + The contents of the PROTECTION object, with the format matching + the indicated C-Type, excluding the object header. + +4.2. Explicit Control Procedures + + SEROs are carried in Path messages and indicate at which node a + recovery LSP is to be initiated relative to the LSP carrying the + SERO. More than one SERO MAY be present in a Path message. + + To indicate the branch and merge nodes of a recovery LSP, an SERO is + created and added to the Path message of the LSP being recovered. + The decision to create and insert an SERO is a local matter and + outside the scope of this document. + + An SERO SHOULD contain at least three subobjects. The first + subobject MUST indicate the node that is to originate the recovery + LSP, i.e. the segment branch node. The address used SHOULD also be + listed in the ERO or another SERO. This ensures that the branch node + is along the LSP path. The second subobject SHOULD be a protection + subobject and should indicate the protection or restoration to be + provided by the recovery LSP. When the protection subobject is + present, the LSP Segment Recovery Flags in the protection subobject + MUST be ignored. The final subobject in the SERO MUST be the merge + node of the recovery LSP, and MAY have the L-bit set. Standard ERO + subobjects MAY be inserted between the protection subobject and the + final subobject. These subobjects MAY be loose or strict. + + A node receiving a Path message containing one or more SEROs SHOULD + examine each SERO to see if it indicates a local branch point. This + + + +Berger, et al. Standards Track [Page 9] + +RFC 4873 GMPLS Segment Recovery May 2007 + + + determination is made by examining the first object of each SERO and + seeing if the address indicated in the subobject can be associated + with the local node. If any of indicated addresses are associated + with the local node, then the local node is a branch node. If the + local node is not a branch node, all received SEROs MUST be + transmitted, without modification, in the corresponding outgoing Path + message. + + At a branch node, the SERO, together with the Path message of LSP + being recovered, provides the information to create the recovery LSP. + The Path message for the recovery LSP is created at the branch node + by cloning the objects carried in the incoming Path message of the + LSP being protected. Certain objects are replaced or modified in the + recovery LSP's outgoing Path message. The Sender_template object + MUST be updated to use an address (in its Tunnel Sender Address + field) on the local node, and the LSP ID MUST be updated to ensure + uniqueness. The Session object MUST be updated to use the address + indicated in the final subobject of the SERO as the tunnel endpoint + address, the tunnel ID MAY be updated, and the extended tunnel ID + MUST be set to the local node address. The PROTECTION object is + replaced with the contents of the matching SERO protection subobject, + when present. In all cases, the R-bit of a new PROTECTION object is + reset (0). Any RROs and EROs present in the incoming Path message + MUST NOT be included in the recovery LSP. A new ERO MUST be + included, with the contents of the SERO that indicated a local + branch. As with all EROs, no local information (local address and + any protection subobjects) is carried in the ERO carried in the + recovery LSP's outgoing Path message. The SERO that indicated a + local branch MUST be omitted from the recovery LSP's outgoing Path + message. Note, by default, all other received SEROs are passed in + the recovery LSP's outgoing Path message. SEROs MAY be omitted, from + the recovery LSP's outgoing Path message as well as the outgoing Path + message for the LSP being protected, when the SERO does not relate to + the outgoing path message. + + The resulting Path message is used to create the recovery LSP. From + this point on, Standard Path message processing is used in processing + the resulting Path message. + +4.2.1. Branch Failure Handling + + During setup, it is possible that a processing node will be unable to + support a requested branch. Additionally, during setup and normal + operation, PathErr messages may be received at a branch node. The + processing of these events depend on a number of factors. + + When a failure or received PathErr message is associated with the LSP + being protected, the event is first processed per standard processing + + + +Berger, et al. Standards Track [Page 10] + +RFC 4873 GMPLS Segment Recovery May 2007 + + + rules. This includes generation of a standard PathErr message. When + LSP state is removed due to a local failure or a PathErr message with + the Path_State_Removed flag set (1), the node MUST send a PathTear + message downstream on all other branches. + + When a failure or received PathErr message is associated with a + recovery LSP, processing is based on the R-bit in addition to the + Path_State_Removed flag. In all cases, a received PathErr message is + first processed per standard processing rules and the failure or + received PathErr message SHOULD trigger the generation of a PathErr + message upstream for the LSP being protected. The outgoing PathErr + message SHOULD indicate an error of "Routing Problem/LSP Segment + Protection Failed". The outgoing PathErr message MUST include any + SEROs carried in a received PathErr message. If no SERO is present + in a received PathErr message or when the failure is local, then an + SERO that matches the errored LSP or failed branch MUST be added to + the outgoing PathErr message. + + When a PathErr message with the Path_State_Removed flag cleared (0) + is received, the outgoing (upstream) PathErr message SHOULD be sent + with the Path_State_Removed flag cleared (0). + + When a PathErr message for a recovery LSP with the Path_State_Removed + flag set (1) is received, the processing node MUST examine the R-bit + (as defined below) of the LSP being protected. The R-bit is carried + in the PROTECTION object that triggered the initiation of the + recovery LSP. When the R-bit is not set (0), the outgoing (upstream) + PathErr message SHOULD be sent with the Path_State_Removed flag + cleared (0). When the R-bit is set (1), the outgoing (upstream) + PathErr message MUST be sent with the Path_State_Removed flag set + (1). + + In all cases where an outgoing (upstream) PathErr message is sent + with the Path_State_Removed flag set (1), all path state for the LSP + being protected MUST be removed, and the node MUST send a PathTear + message downstream on all active branches. + +4.2.2. Resv Message Processing + + Branch nodes will process Resv messages for both recovery LSPs and + LSPs being protected. Resv messages are propagated upstream of + branch nodes only after a Resv message is received for the protected + LSP. Resv messages on recovery LSPs will typically not trigger + transmission of upstream Resv messages (for the LSP being protected). + Exceptions to this include when RROs/SRROs are being collected and + during certain ADMIN_STATUS object processing. See below for more + information on related processing. + + + + +Berger, et al. Standards Track [Page 11] + +RFC 4873 GMPLS Segment Recovery May 2007 + + +4.2.3. Admin Status Change + + In general, objects in a recovery LSP are created based on the + corresponding objects in the LSP being protected. The ADMIN_STATUS + object is created the same way, but it also requires some special + coordination at branch nodes. Specifically, in addition to normal + processing, a branch node that receives an ADMIN_STATUS object in a + Path message also MUST relay the ADMIN_STATUS object in a Path on + every recovery LSP. All Path messages MAY be concurrently sent + downstream. + + Downstream nodes process the change in the ADMIN_STATUS object per + [RFC3473], including generation of Resv messages. When the most + recently received upstream ADMIN_STATUS object has the R bit set, + branch nodes wait for a Resv message with a matching ADMIN_STATUS + object to be received on all branches before relaying a corresponding + Resv message upstream. + +4.2.4. Recovery LSP Teardown + + Recovery LSP removal follows standard procedures defined in [RFC3209] + and [RFC3473]. This includes with and without setting the + administrative status. + +4.2.4.1. Teardown Without Admin Status Change + + The node initiating the teardown originates a PathTear message. Each + node that receives a PathTear message processes the PathTear message + per standard processing (see [RFC3209] and [RFC2205]), and MUST also + relay a PathTear on every recovery LSP. All PathTear messages + (received from upstream and locally originated) may be concurrently + sent downstream. + +4.2.4.2. Teardown With Admin Status Change + + Per [RFC3473], the ingress node originates a Path message with the D + and R bits set in the ADMIN_STATUS object. The admin status change + procedure defined in Section 4.2.3 MUST then be followed. Once the + ingress receives all expected Resv messages, it MUST follow the + teardown procedure described in Section 4.2.4.1. + +4.3. Teardown From Non-Ingress Nodes + + As with any LSP, any node along a recovery LSP may initiate removal + of the recovery LSP. To do this, the node initiating the teardown + sends a PathErr message with the appropriate Error Code and the + Path_State_Removed flag cleared (0) toward the LSP ingress. As + described above, the recovery LSP ingress will propagate the error to + + + +Berger, et al. Standards Track [Page 12] + +RFC 4873 GMPLS Segment Recovery May 2007 + + + the LSP ingress, which can then signal the removal of the recovery + LSP. + + It is also possible for the node initiating the teardown to remove a + Recovery LSP in a non-graceful manner. In this case, the initiator + sends a PathTear message downstream and a PathErr message with a + "Confirmation" indication (error code and value set to zero), and the + Path_State_Removed flag set (1) toward the LSP ingress node. This + manner of non-ingress node teardown is NOT RECOMMENDED because in + some cases it can result in the removal of the LSP being protected. + +4.3.1. Modified NOTIFY_REQUEST Object Processing + + A parallel set of rules are applied at branch and merge nodes to + enable the branch or merge node to add a NOTIFY_REQUEST object to the + Path and Resv messages of protected and recovery LSPs. Branch nodes + add NOTIFY_REQUEST objects to Path messages, and merge nodes add + NOTIFY_REQUEST objects to Resv messages. + + When a node is branching or merging a recovery LSP, the node SHOULD + include a single NOTIFY_REQUEST object in the Path message of the + recovery LSP, in the case of a branch node, or the Resv message of + the recovery LSP, in the case of a merge node. The notify node + address MUST be set to the router address of the processing node. + + Branch and merge nodes SHOULD also add a NOTIFY_REQUEST object to the + LSP being protected. For branch nodes, the notify node address is + set to the address used in the sender template object of the + associated recovery LSP. For merge nodes, the notify node address is + set to the address used in the session object of the associated + recovery LSP. A locally added NOTIFY_REQUEST object MUST be listed + first in an outgoing message; any received NOTIFY_REQUEST objects + MUST then be listed in the message in the order that they were + received. Note that this can result in a stack (or ordered list) of + objects. + + Normal notification procedures are then followed for the LSP being + protected. That is, the notifying node MUST issue a Notify message + to the recipient indicated by the notify address of the first listed + NOTIFY_REQUEST object. Under local policy control, a node issuing a + Notify message MAY also send a Notify message to the Notify Node + Address indicated in the last, or any other, NOTIFY_REQUEST object + carried in the Path or Resv message. + + Recovery LSP merge and branch nodes remove the object added by the + recovery branch or merge node from outgoing Path and Resv messages + for the LSP being protected. This is done by removing the + NOTIFY_REQUEST object that, in the case of a merge node, matches the + + + +Berger, et al. Standards Track [Page 13] + +RFC 4873 GMPLS Segment Recovery May 2007 + + + source address of the recovery LSP and, in the case of a branch node, + matches the tunnel endpoint address of the recovery LSP. The + matching NOTIFY_REQUEST object will normally be the first of the + listed NOTIFY_REQUEST objects. Note, to cover certain backwards + compatibility scenarios, the NOTIFY_REQUEST object SHOULD NOT be + removed if it is the sole NOTIFY_REQUEST object. + + Note this requires the following change to [RFC3473], Section 4.2.1: + + o old text: + If a message contains multiple NOTIFY_REQUEST objects, only the + first object is meaningful. Subsequent NOTIFY_REQUEST objects MAY + be ignored and SHOULD NOT be propagated. + + o new text: + If a message contains multiple NOTIFY_REQUEST objects, only the + first object used is in notification. Subsequent NOTIFY_REQUEST + objects MUST be propagated in the order received. + +4.3.2. Modified Notify and Error Message Processing + + Branch and merge nodes MUST support the following modification to + Notify message processing. When a branch or merge node receives + notification of an LSP failure and it is unable to recover from that + failure, it MUST notify the node indicated in the first + NOTIFY_REQUEST object received in the Path message (for branch nodes) + or Resv message (for merge nodes) associated with the LSP. + +5. Secondary Record Route Objects + + Secondary Record Route objects, or SRROs, are used to record the path + used by recovery LSPs. + +5.1. Format + + The format of a SECONDARY_RECORD_ROUTE object is the same as a + RECORD_ROUTE object, Class number 21. This includes the definition + of subobjects defined for RECORD_ROUTE object. The class of the + SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb). + + The protection subobject defined above can also be used in + SECONDARY_RECORD_ROUTE objects. + + + + + + + + + +Berger, et al. Standards Track [Page 14] + +RFC 4873 GMPLS Segment Recovery May 2007 + + +5.2. Path Processing + + SRROs may be carried in Path messages and indicate the presence of + upstream recovery LSPs. More than one SRRO MAY be added and present + in a Path message. + + Any received SRRO MUST be transmitted by transit nodes, without + modification, in the corresponding outgoing Path message. + + SRROs are inserted in Path messages by recovery LSP merge nodes. The + SRRO is created by copying the contents of an RRO received by the + recovery LSP into a new SRRO object. This SRRO is added to the + outgoing Path message of the recovered LSP. Note that multiple SRROs + may be present. The collection of SRROs is controlled via the + segment-recording-desired flag in the SESSION_ATTRIBUTE object. This + flag MAY be set even when SEROs are not used. + +5.3. Resv Processing + + SRROs may be carried in Resv messages and indicate the presence of + downstream recovery LSPs. More than one SRRO MAY be added and + present in a Resv message. + + Any received SRRO MUST be transmitted by transit nodes, without + modification, in the corresponding outgoing Resv message. When Resv + messages are merged, the resulting merged Resv SHOULD contain all + SRROs received in downstream Resv messages. + + SRROs are inserted in Resv messages by branch nodes of recovery LSPs. + The SRRO SHOULD be created with the first two objects being the local + node address, followed by a protection subobject with the contents of + the recovery LSP's PROTECTION object. The remainder of the SRRO + SHOULD be created by copying the contents of the RRO received by the + recovery LSP. This SRRO SHOULD be added to the outgoing Resv message + of the recovered LSP. Again, multiple SRROs may be present. + + If the newly added SRRO causes the message to be too big to fit in a + Resv message, SRRO subobjects SHOULD be removed from any present + SRROs. When removing subobjects, the first two subobjects and the + last subobject in an SRRO MUST NOT be removed. Note that the + subobject that followed a removed subobject MUST be updated with the + L-bit set (1). If after removing all but the first and last + subobjects in all SRROs the resulting message is still too large to + fit, then whole SRROs SHOULD be removed until the message does fit. + + + + + + + +Berger, et al. Standards Track [Page 15] + +RFC 4873 GMPLS Segment Recovery May 2007 + + +6. Dynamic Control of LSP Segment Recovery + + Dynamic identification of branch and merge nodes is supported via the + LSP Segment Recovery Flags carried in the PROTECTION object. The LSP + Segment Recovery Flags are carried within one of the Reserved fields + defined in the PROTECTION object defined in [RFC4872]. LSP Segment + Recovery Flags are used to indicate when LSP segment recovery is + desired. When these bits are set, branch and merge nodes are + dynamically identified. + + Note, the procedures defined in this section parallel the explicit + control procedures defined above in Section 4.2. The primary + difference is in the creation of a recovery LSP's ERO. + +6.1. Modified PROTECTION Object Format + + LSP Segment Recovery Flags are carried in the PROTECTION object of + the same C-Type defined in [RFC4872]. The format of the flags are: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | Class-Num(37) | C-Type (2) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I|R| Reserved | Seg.Flags | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + In-Place (I): 1 bit + + When set (1) indicates that the desired segment recovery type + indicated in the LSP Segment Recovery Flag is already in place + for the associated LSP. + + Required (R): 1 bit + + When set (1) indicates that failure to establish the indicated + protection should result in a failure of the LSP being + protected. + + Segment Recovery Flags (Seg.Flags): 6 bits + + This field is used to indicate when an upstream node desires + LSP Segment recovery to be dynamically initiated where + possible. The values used in this field are identical to the + values defined for LSP Flags; see [RFC4872]. + + + + +Berger, et al. Standards Track [Page 16] + +RFC 4873 GMPLS Segment Recovery May 2007 + + + See [RFC4872] for the definition of other fields. + +6.2. Dynamic Control Procedures + + LSP Segment Recovery Flags are set to indicate that LSP segment + recovery is desired for the LSP being signaled. The type of recovery + desired is indicated by the flags. The decision to set the LSP + Segment Recovery Flags is a local matter and outside the scope of + this document. A value of zero (0) means that no dynamic + identification of segment recovery branch nodes are needed for the + associated LSP. When the In-Place bit is set, it means that the + desired type of recovery is already in place for that particular LSP. + + A transit node receiving a Path message containing a PROTECTION + object with a non-zero LSP Segment Recovery Flags value and the In- + Place bit clear (0) SHOULD consider if it can support the indicated + recovery type and if it can identify an appropriate merge node for a + recovery LSP. Dynamic identification MUST NOT be done when the + processing node is identified as a branch node in an SERO. If a node + is unable to provide the indicated recovery type or identify a merge + node, the Path message MUST be processed normally, and the LSP + Segment Recovery Flags MUST NOT be modified. + + When a node dynamically identifies itself as a branch node and + identifies the merge node for the type of recovery indicated in the + LSP Segment Recovery Flags, it attempts to setup a recovery LSP. The + dynamically identified information, together with the Path message of + LSP being recovered, is used to create the recovery LSP. + + The Path message for the recovery LSP is created at the branch node + by cloning the objects carried in the incoming Path message of the + LSP being protected. Certain objects are replaced or modified in the + recovery LSP's outgoing Path message. The Sender_template object + MUST be updated to use an address (in its Tunnel Sender Address + field) on the local node, and the LSP ID MUST be updated to ensure + uniqueness. The Session object MUST be updated to use the address of + the dynamically identified merge node as the tunnel endpoint address, + the tunnel ID MAY be updated, and the extended tunnel ID MUST be set + to the local node address. The PROTECTION object is updated with the + In-Place bit set (1). Any RROs and EROs present in the incoming Path + message MUST NOT be included in the recovery LSP. A new ERO MAY be + created based on any path information dynamically computed by the + local node. + + + + + + + + +Berger, et al. Standards Track [Page 17] + +RFC 4873 GMPLS Segment Recovery May 2007 + + + The resulting Path message is used to create the recovery LSP. While + the recovery LSP exists, the PROTECTION object in the original Path + message (unless overridden by local policy) MUST also be updated + with the In-Place bit set (1). From this point on, Standard Path + message processing is used in processing the resulting and original + Path messages. + + The merge node of a dynamically controlled recovery LSP SHOULD reset + (0) the In-Place bit in the PROTECTION object of the outgoing Path + message associated with the terminated recovery LSP. + + Unlike with explicit control, if the creation of a dynamically + identified recovery LSP fails for any reason, the recovery LSP is + removed, and no error message or indication is sent upstream. With + this exception, all the other procedures for explicitly controlled + recovery LSPs apply to dynamically controlled recovery LSPs. These + other procedures are defined above in Sections 4.2.1 through 4.2.4. + +7. Updated RSVP Message Formats + + This section presents the RSVP message related formats as modified by + this document. Where they differ, formats for unidirectional LSPs + are presented separately from bidirectional LSPs. + + The format of a Path message is as follows: + + <Path Message> ::= <Common Header> [ <INTEGRITY> ] + [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] + [ <MESSAGE_ID> ] + <SESSION> <RSVP_HOP> + <TIME_VALUES> + [ <EXPLICIT_ROUTE> ] + <LABEL_REQUEST> + [ <PROTECTION> ] + [ <LABEL_SET> ... ] + [ <SESSION_ATTRIBUTE> ] + [ <NOTIFY_REQUEST> ... ] + [ <ADMIN_STATUS> ] + [ <ASSOCIATION> ... ] + [ <SECONDARY_EXPLICIT_ROUTE> ... ] + [ <POLICY_DATA> ... ] + <sender descriptor> + + + + + + + + + +Berger, et al. Standards Track [Page 18] + +RFC 4873 GMPLS Segment Recovery May 2007 + + + The format of the sender description for unidirectional LSPs is: + + <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> + [ <ADSPEC> ] + [ <RECORD_ROUTE> ] + [ <SUGGESTED_LABEL> ] + [ <RECOVERY_LABEL> ] + [ <SECONDARY_RECORD_ROUTE> ... ] + + The format of the sender description for bidirectional LSPs is: + + <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> + [ <ADSPEC> ] + [ <RECORD_ROUTE> ] + [ <SUGGESTED_LABEL> ] + [ <RECOVERY_LABEL> ] + <UPSTREAM_LABEL> + [ <SECONDARY_RECORD_ROUTE> ... ] + + The format of a PathErr message is as follows: + + <PathErr Message> ::= <Common Header> [ <INTEGRITY> ] + [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] + [ <MESSAGE_ID> ] + <SESSION> <ERROR_SPEC> + [ <ACCEPTABLE_LABEL_SET> ... ] + [ <SECONDARY_EXPLICIT_ROUTE> ... ] + [ <POLICY_DATA> ... ] + <sender descriptor> + + The format of a Resv message is as follows: + + <Resv Message> ::= <Common Header> [ <INTEGRITY> ] + [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] + [ <MESSAGE_ID> ] + <SESSION> <RSVP_HOP> + <TIME_VALUES> + [ <RESV_CONFIRM> ] [ <SCOPE> ] + [ <NOTIFY_REQUEST> ... ] + [ <ADMIN_STATUS> ] + [ <POLICY_DATA> ... ] + <STYLE> <flow descriptor list> + + <flow descriptor list> ::= <FF flow descriptor list> + | <SE flow descriptor> + + + + + + +Berger, et al. Standards Track [Page 19] + +RFC 4873 GMPLS Segment Recovery May 2007 + + + <FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC> + <LABEL> [ <RECORD_ROUTE> ] + [ <SECONDARY_RECORD_ROUTE> ... ] + | <FF flow descriptor list> + <FF flow descriptor> + + <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL> + [ <RECORD_ROUTE> ] + [ <SECONDARY_RECORD_ROUTE> ... ] + + <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list> + + <SE filter spec list> ::= <SE filter spec> + | <SE filter spec list> <SE filter spec> + + <SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ] + [ <SECONDARY_RECORD_ROUTE> ... ] + +8. Security Considerations + + This document introduces new message objects for use in GMPLS + signaling [RFC3473]. It does not introduce any new signaling + messages, nor change the relationship between LSRs that are adjacent + in the control plane. + + The procedures defined in this document result in an increase in the + amount of topology information carried in signaling messages since + the presence of SEROs and SRROs necessarily means that there is more + information about LSP paths carried than in simple EROs and RROs. + Thus, in the event of the interception of a signaling message, + slightly more could be deduced about the state of the network than + was previously the case, but this is judged to be a very minor + security risk as this information is already available via routing. + + Otherwise, this document introduces no additional security + considerations. See [RFC3473] for relevant security considerations. + + + + + + + + + + + + + + + +Berger, et al. Standards Track [Page 20] + +RFC 4873 GMPLS Segment Recovery May 2007 + + +9. IANA Considerations + + IANA has assigned the following values for the namespaces defined in + this document and reviewed in this section. + +9.1. New Association Type Assignment + + IANA has made the following assignment to the "GMPLS Signaling + Parameters" Registry (see [RFC4872]) located at + http://www.iana.org/assignments/gmpls-sig-parameters. + + Value Type + ----- ---- + 2 Resource Sharing (R) [RFC4873] + +9.2. Definition of PROTECTION Object Reserved Bits + + This document defines bits carried in the Reserved field of the + PROTECTION object defined in [RFC4872]. As no IANA registry for + these bits is requested in [RFC4872], no IANA action is required + related to this definition. + +9.3. Secondary Explicit Route Object + + IANA has made the following assignments in the "Class Names, Class + Numbers, and Class Types" section of the "RSVP PARAMETERS" registry + located at http://www.iana.org/assignments/rsvp-parameters. + + A new class named SECONDARY_EXPLICIT_ROUTE has been created in the + 11bbbbbb range (200) with the following definition: + Class Types or C-types: + + Same values as EXPLICIT_ROUTE object (C-Num 20) + + For Class 1, C-Type 1, the following additional Subobject type is + defined: + + 37 PROTECTION [RFC4873] + +9.4. Secondary Record Route Object + + IANA has made the following assignments in the "Class Names, Class + Numbers, and Class Types" section of the "RSVP PARAMETERS" registry + located at http://www.iana.org/assignments/rsvp-parameters. + + + + + + + +Berger, et al. Standards Track [Page 21] + +RFC 4873 GMPLS Segment Recovery May 2007 + + + A new class named SECONDARY_RECORD_ROUTE has been created in the + 11bbbbbb range (201) with the following definition: + + Class Types or C-types: + + Same values as RECORD_ROUTE object (C-Num 21) + + For Class 1, C-Type 1, the following additional Subobject type is + defined: + + 37 PROTECTION [RFC4873] + +9.5. New Error Code + + IANA has made the following assignments in the "Routing Problem" + subsection of "Error Codes and Values" section of the "RSVP + PARAMETERS" registry located at + http://www.iana.org/assignments/rsvp-parameters. + + 21 = LSP Segment Protection Failed [RFC4873] + +9.6. Use of PROTECTION Object C-type + + This document modifies the PROTECTION object, class number 37, C-Type + 2 (defined in Section 14.1. of [RFC4872]). + + + + + + + + + + + + + + + + + + + + + + + + + + +Berger, et al. Standards Track [Page 22] + +RFC 4873 GMPLS Segment Recovery May 2007 + + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. + Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 + Functional Specification", RFC 2205, September 1997. + + [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. + + [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Functional Description", RFC + 3471, January 2003. + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling - Resource ReserVation + Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC + 3473, January 2003. + + [RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, + Ed., "RSVP-TE Extensions in support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery", RFC 4872, May 2007. + +10.2. Informative References + + [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute + Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May + 2005. + + [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. + Papadimitriou, Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Recovery Functional Specification," RFC + 4426, March 2006. + + [RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery + (Protection and Restoration) Terminology for Generalized + Multi-Protocol Label Switching (GMPLS)", RFC 4427, March + 2006. + + + + + + + +Berger, et al. Standards Track [Page 23] + +RFC 4873 GMPLS Segment Recovery May 2007 + + +Authors' Addresses + + Lou Berger + LabN Consulting, L.L.C. + + Phone: +1 301-468-9228 + EMail: lberger@labn.net + + + Igor Bryskin + ADVA Optical + 7926 Jones Branch Drive + Suite 615 + McLean VA, 22102 + + EMail: IBryskin@advaoptical.com + + + Dimitri Papadimitriou + Alcatel + Francis Wellesplein 1 + B-2018 Antwerpen, Belgium + + Phone: +32 3 240-8491 + EMail: dimitri.papadimitriou@alcatel-lucent.be + + + Adrian Farrel + Old Dog Consulting + + Phone: +44 (0) 1978 860944 + EMail: adrian@olddog.co.uk + + + + + + + + + + + + + + + + + + + +Berger, et al. Standards Track [Page 24] + +RFC 4873 GMPLS Segment Recovery May 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Berger, et al. Standards Track [Page 25] + |