RFC 4872

RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery

📅 published May 2007, from ietf

RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery 🎀

okay bestie, this is the title block tea ☕✨

Number and title: RFC 4872, RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery
Stream: Network Working Group
Category: Standards Track
Date: May 2007
Updates: RFC 3471
Authors (all Editors, Ed.): J.P. Lang (Sonos), Y. Rekhter (Juniper), and D. Papadimitriou (Alcatel) 👑

Status of This Memo 📋

this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions to make it better 🫶 for the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited, so share away 💅

Copyright Notice ©️

Copyright (C) The IETF Trust (2007).

Abstract 🦋

this doc describes the protocol-specific procedures and extensions for GMPLS Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling so it can support end-to-end Label Switched Path (LSP) recovery, which covers both protection and restoration 🔥 the generic functional description of GMPLS recovery lives in a companion doc, RFC 4426 📚

Table of Contents 🗂️

  1. Introduction .....................................................3
   2. Conventions Used in This Document ...............................5
   3. Relationship to Fast Reroute (FRR) ..............................5
   4. Definitions .....................................................6
      4.1. LSP Identification .........................................6
      4.2. Recovery Attributes ........................................7
           4.2.1. LSP Status ..........................................7
           4.2.2. LSP Recovery ........................................8
      4.3. LSP Association ............................................9
   5. 1+1 Unidirectional Protection ...................................9
      5.1. Identifiers ...............................................10

   6. 1+1 Bidirectional Protection ...................................10
      6.1. Identifiers ...............................................11
      6.2. End-to-End Switchover Request/Response ....................11
   7. 1:1 Protection with Extra-Traffic ..............................13
      7.1. Identifiers ...............................................14
      7.2. End-to-End Switchover Request/Response ....................15
      7.3. 1:N (N > 1) Protection with Extra-Traffic .................16
   8. Rerouting without Extra-Traffic ................................17
      8.1. Identifiers ...............................................19
      8.2. Signaling Primary LSPs ....................................19
      8.3. Signaling Secondary LSPs ..................................19
   9. Shared-Mesh Restoration ........................................20
      9.1. Identifiers ...............................................22
      9.2. Signaling Primary LSPs ....................................22
      9.3. Signaling Secondary LSPs ..................................23
   10. LSP Preemption ................................................23
   11. (Full) LSP Rerouting ..........................................25
      11.1. Identifiers ..............................................25
      11.2. Signaling Reroutable LSPs ................................26
   12. Reversion .....................................................26
   13. Recovery Commands .............................................29
   14. PROTECTION Object .............................................31
      14.1. Format ...................................................31
      14.2. Processing ...............................................33
   15. PRIMARY_PATH_ROUTE Object .....................................33
      15.1. Format ...................................................34
      15.2. Subobjects ...............................................34
      15.3. Applicability ............................................35
      15.4. Processing ...............................................36
   16. ASSOCIATION Object ............................................37
      16.1. Format ...................................................37
      16.2. Processing ...............................................38
   17. Updated RSVP Message Formats ..................................39
   18. Security Considerations .......................................40
   19. IANA Considerations ...........................................41
   20. Acknowledgments ...............................................43
   21. References ....................................................43
      21.1. Normative References .....................................43
      21.2. Informative References ...................................44
   22. Contributors ..................................................45

1. Introduction 🌸

okay so GMPLS takes MPLS and extends it to cover Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM), Lambda Switch Capable (LSC), and Fiber Switch Capable (FSC) interfaces 🧚 GMPLS recovery uses control plane mechanisms (that's signaling, routing, and link management) to support data plane fault recovery 💖 the analogous data plane fault detection mechanisms are required to be present so the control plane mechanisms can actually do their job, so don't skip them 🙈

in this doc, "recovery" is the catch-all word for both protection and restoration. "protection" and "restoration" only come out when you need to tell them apart 💅 the subtle difference between them is based on the resource allocation that happens during the recovery phase (see [RFC4427]) ✨

a functional description of GMPLS recovery is in [RFC4426], and you should treat it as a companion doc 📚 this doc focuses on the protocol-specific procedures for GMPLS RSVP-TE (Resource ReSerVation Protocol - Traffic Engineering) signaling (see [RFC3473]) to support end-to-end recovery. end-to-end recovery means recovering an entire LSP, from its head-end (the ingress node endpoint) to its tail-end (the egress node endpoint) 🦋

with end-to-end recovery, working LSPs are assumed to be resource-disjoint (a resource being a link, a node, or a Shared Risk Link Group (SRLG)) so they don't share failure probability. but this is not mandatory, bestie 🫣 for a given set of network resources, a working/protecting LSP pair SHOULD be resource disjoint for the dedicated recovery type (more on that below). for shared recovery, a group of working LSPs SHOULD be mutually resource-disjoint so they can all share one protecting LSP, and that protecting LSP has to be resource-disjoint from each of the working LSPs too 🔥 resource disjointness is a necessary (but not sufficient) condition for LSP recoverability, so it's not the whole story ngl 💀

this doc covers four types of end-to-end LSP recovery:

1+1 protection, in unidirectional or bidirectional flavors
1:N protection with extra-traffic, where N >= 1
pre-planned LSP rerouting without extra-traffic, including shared mesh
full LSP rerouting 👑

1) 1+1 unidirectional protection is the simplest notion of end-to-end LSP protection 🌈 a protecting LSP is signaled over a dedicated resource-disjoint alternate path to protect an associated working LSP. normal traffic is sent on both LSPs at the same time, and a selector at the egress node picks up traffic from one of them. if a failure hits one of the LSPs, the egress node just selects traffic from the valid LSP. no coordination between the end nodes is required when a failure or switchover happens, which is so iconic 😭

1+1 bidirectional protection works like this: a protecting LSP is signaled over a dedicated resource-disjoint alternate path to protect the working LSP. normal traffic goes on both LSPs at once (in both directions), and a selector is used at both the ingress and egress nodes to receive traffic from the same LSP. this one does require coordination between the end nodes when switching over to the protecting LSP 🤝

2) 1:N (N >= 1) protection with extra-traffic has a protecting LSP that's fully provisioned and resource-disjoint from the N working LSPs, and it lets you carry extra-traffic 🧁 the N working LSPs MAY be mutually resource-disjoint. coordination between end nodes is required when switching from one of the working LSPs to the protecting LSP. since the protecting LSP is fully provisioned, default operations during protection switching are specified for a protecting LSP carrying extra-traffic, but this is not mandatory 💅 also, M:N protection is out of scope for this doc, though the mechanisms it defines may be extended to cover it 🙌

3) Pre-planned LSP rerouting (or restoration) relies on setting up, between the same pair of end-nodes, a working LSP and a protecting LSP that's link/node/SRLG disjoint from the working one 🦋 the recovery resources for the protecting LSP are pre-reserved, but you need explicit action to activate it. that means committing the resource allocation at the data plane for one specific protecting LSP that was set up during the (pre-)provisioning phase. since the protecting LSP isn't "active" (aka fully instantiated), it can't carry any extra-traffic. that doesn't mean the resources can't be used by other LSPs though 👀 so this protects against working LSP failures, but the protecting LSP has to be activated after the working LSP fails, and that needs restoration signaling along the protecting path.

"shared-mesh" restoration is a special case of pre-planned LSP rerouting. it cuts down on recovery resource requirements by letting multiple protecting LSPs share common link and node resources 🧠 same deal as before: the recovery resources are pre-reserved, explicit action is required to activate one specific protecting LSP set up during the (pre-)provisioning phase, and this procedure needs restoration signaling along the protecting path.

heads up: in both of these cases, bandwidth that's pre-reserved for a protecting (but not activated) LSP can be made available for carrying extra traffic ⚠️ LSPs for extra-traffic (with lower holding priority than the protecting LSP) can then be established using the bandwidth pre-reserved for the protecting LSP. also, any lower priority LSP that uses the pre-reserved resources for the protecting LSP(s) must be preempted during the activation of the protecting LSP 💀

4) Full LSP rerouting (or restoration) switches normal traffic to an alternate LSP that isn't even partially established until after the working LSP fails 😤 the new alternate route is selected at the LSP head-end node. it may reuse resources of the failed LSP at intermediate nodes, and it may include additional intermediate nodes and/or links 🌟

crankback signaling (see [CRANK]) and LSP segment recovery (see [RFC4873]) are covered in detail in their own dedicated companion docs, so we'll leave them there for now 🫶

2. Conventions Used in This Document ✨

okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read the way [RFC2119] says 🎀

also, the reader is assumed to already know the terminology from [RFC3945], [RFC3471], [RFC3473] and the ones referenced in [RFC4427] and [RFC4426]. no cap, bring your homework 📚💅

3. Relationship to Fast Reroute (FRR) 🦋

okay so end-to-end GMPLS recovery does not hurt RSVP-TE Fast Reroute (FRR) [RFC4090] at all 🫶 you can totally use either method defined in FRR together with end-to-end GMPLS recovery. iconic. 👑

the objects used and/or newly introduced by end-to-end recovery just get ignored by [RFC4090] conformant implementations 🙈 and FRR can still work on a per LSP basis, like [RFC4090] describes. main character energy for both of them 💖

4. Definitions 🌸

4.1. LSP Identification 🧚

this section is a quick recap of terms already defined in [RFC2205], [RFC3209], and [RFC3473]. LSP tunnels are identified by a combo of the SESSION and SENDER_TEMPLATE objects (see also [RFC3209]). the relevant fields are:

IPv4 (or IPv6) tunnel endpoint address : the IPv4 (or IPv6) address of the egress node for the tunnel.

Tunnel ID : a 16-bit identifier used in the SESSION that stays constant over the whole life of the tunnel.

Extended Tunnel ID : a 32-bit (or 16-byte) identifier used in the SESSION that stays constant over the life of the tunnel. it's normally set to all zeros 🫠 ingress nodes that want to narrow the scope of a SESSION down to the ingress-egress pair MAY put their IPv4 (or IPv6) address here as a globally unique identifier. ✨

IPv4 (or IPv6) tunnel sender address : the IPv4 (or IPv6) address for a sender node.

LSP ID : a 16-bit identifier used in the SENDER_TEMPLATE and FILTER_SPEC that can be changed so a sender can share resources with itself. lowkey genius 🧠

okay so the first three fields live in the SESSION object (Path and Resv message) and make up the basic identification of the LSP tunnel 🎀 the last two fields are carried in the SENDER_TEMPLATE (Path message) and FILTER_SPEC objects (Resv message). the LSP ID is how we tell apart LSPs that belong to the same LSP Tunnel (the one identified by its Tunnel ID) 💜

4.2. Recovery Attributes 💅

the recovery attributes are all the parameters that decide the status of an LSP inside the recovery scheme it's attached to. these attributes are part of the PROTECTION object introduced in Section 14. 🫶

4.2.1. LSP Status 🌈

these bits help decide resource allocation and the status of the LSP within the group of LSPs that form the protected entity:

S (Secondary) bit: this one tells primary and secondary LSPs apart. a primary LSP is fully established, meaning its resource allocation has been committed at the data plane (so full cross-connection has been performed). both working and protecting LSPs can be primary LSPs. a secondary LSP is only provisioned in the control plane. resource selection MAY have been done for it, but its resource allocation hasn't been committed at the data plane (for example, no cross-connection has been performed). so a secondary LSP is not immediately ready to carry any traffic, and it needs extra signaling before it's available 🙈 a secondary LSP can only ever be a protecting LSP. the (data plane) resources allocated for a secondary LSP MAY be used by other LSPs until the primary LSP fails over to the secondary LSP. 🦋
P (Protecting) bit: this one tells working and protecting LSPs apart. a working LSP MUST be a primary LSP, whilst a protecting LSP can be either a primary or a secondary LSP. when protecting LSP(s) are associated with working LSP(s), the working ones are also called protected LSPs. 🛡️

Note: the combo "secondary working" is not valid (only protecting LSPs can be secondary LSPs). working LSPs are always primary LSPs (fully established), whilst primary LSPs can be either working or protecting LSPs. 💀

O (Operational) bit: this bit gets set when a protecting LSP is carrying the normal traffic after protection switching. it only applies to dedicated LSP protection or LSP protection with extra-traffic (see Section 4.2.2). 🍓

in this doc, the PROTECTION object uses the PROTECTION object from [RFC3471] and [RFC3473] as a base and adds some extra fields inside it. the fields defined in [RFC3471] and [RFC3473] are unchanged by this document. ✨

4.2.2. LSP Recovery 🦋

this is the classification used to tell apart the LSP Protection Types that LSPs can be associated with at end-nodes. each Protection Type gets its own distinct value in the PROTECTION object (see Section 14). 💖

Full LSP Rerouting: set if a primary working LSP can be dynamically recovered using (non pre-planned) head-end rerouting. 🔥
Pre-planned LSP Rerouting without Extra-traffic: set if a protecting LSP is a secondary LSP that lets the pre-reserved recovery resources be shared between one or more than one <sender;receiver> pair. when the secondary LSP's resources are not pre-reserved for a single <sender;receiver> pair, this type is called "shared mesh" recovery. 🌸
LSP Protection with Extra-traffic: set if a protecting LSP is a dedicated primary LSP that allows extra-traffic transport, and so it rules out any sharing of the recovery resources between more than one <sender;receiver> pair. this type includes 1:N LSP protection with extra-traffic. 🧚
Dedicated LSP Protection: set if a protecting LSP doesn't allow sharing of the recovery resources or the transport of extra-traffic (which in this context means the signal is duplicated over both working and protecting LSPs, like 1+1 dedicated protection). also, this doc makes a distinction between 1+1 unidirectional and bidirectional dedicated LSP protection. 💜

for LSP protection, especially when the data plane has automated protection-switching capability (see for instance the ITU-T [G.841] Recommendation), a Notification (N) bit is defined in the PROTECTION object. it lets you tell whether protection switching signaling goes via the control plane or the data plane. 🎀

Note: this doc assumes that Protection Type values have end-to-end significance and that the same value is sent over the protected and the protecting path. from the end-nodes' point of view, shared-mesh (for instance) just looks like an LSP rerouting without extra-traffic services. the net result is that the S bit alone can't tell whether resource allocation should happen based on the status of the LSP within the protected entity. the P bit fixes this problem unambiguously. these bits MUST be processed on a hop-by-hop basis (independently of the LSP Protection Type context). this makes reversion signaling easier to implement (see Section 12), and it also helps with the transparent delivery of protected services, since no intermediate node has to know what the incoming LSP Protection Type value means. 🫶

4.3. LSP Association 🌷

the ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs. 💅

when it's used for signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. when it's used for signaling the protecting LSP, this field identifies the LSP that the protecting LSP protects. 🧚

5. 1+1 Unidirectional Protection 💖

okay so one of the simplest ideas of end-to-end LSP protection is 1+1 unidirectional protection 🌈

picture this network topology:

                              A---B---C---D
                               \         /
                                E---F---G

the paths [A,B,C,D] and [A,E,F,G,D] are node and link disjoint, ignoring the ingress/egress nodes A and D. a 1+1 protected path is set up from A to D over [A,B,C,D] and [A,E,F,G,D], and traffic is sent simultaneously over both component paths (i.e., LSPs). 🔥

during the provisioning phase, both LSPs are fully instantiated (and so activated), which means no resource sharing can happen along the protecting LSP (and no extra-traffic can be carried either). 🙈 it's also RECOMMENDED to set the N bit, since no protection-switching signaling is assumed in this case. ✨

when a failure happens (say, at node B) and gets detected at end-node D, the receiver at D selects the normal traffic from the other LSP. so from this angle, 1+1 unidirectional protection is basically an uncoordinated protection-switching mechanism that acts independently at both endpoints 💜 also, for the LSP under failure, it's RECOMMENDED to NOT set the Path_State_Removed Flag of the ERROR_SPEC object (see [RFC3473]) when generating the PathErr message. 🫠

Note: it's necessary that both paths are SRLG disjoint to make sure they're recoverable. otherwise, a single failure could hit both the working and protecting LSPs. 💀

5.1. Identifiers 🎀

to keep association operations simple, both LSPs belong to the same session. so the SESSION object MUST be the same for both LSPs. the LSP ID, however, MUST be different so you can tell the two LSPs apart. 🧚

a new PROTECTION object (see Section 14) is included in the Path message. this object carries the desired end-to-end LSP Protection Type, which in this case is "1+1 Unidirectional". this LSP Protection Type value applies to both uni- and bidirectional LSPs. 🌸

to tell the working LSP (the one the signal is taken from) apart from the protecting LSP, the working LSP is signaled by setting the S bit to 0 and the P bit to 0 in the PROTECTION object, and by setting the Association ID in the ASSOCIATION object to the protecting LSP_ID. the protecting LSP is signaled by setting the S bit to 0 and the P bit to 1 in the PROTECTION object, and by setting the Association ID in the ASSOCIATION object to the associated protected LSP_ID. 🦋

after protection switching completes, and after the PathErr message is received, the protecting LSP SHOULD be signaled with the O bit set, so you can keep track of which LSP the signal is taken from. 🫶 the formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]). this whole process assumes the tail-end node has told the head-end node that traffic selection switchover has happened. 👑

6. 1+1 Bidirectional Protection ✨

okay so 1+1 bidirectional protection is giving end-to-end protection for bidirectional LSPs 🦋 it's the whole "two paths, one bestie" energy 💖

picture this network 👇

                              A---B---C---D
                               \         /
                                E---F---G

The LSPs [A,B,C,D] and [A,E,F,G,D] are node and link disjoint, ignoring the ingress/egress nodes A and D 🌸 A bidirectional LSP gets set up from A to D over each path, and traffic is sent over both LSPs at the same time 👑 In this scheme, both endpoints must receive traffic over the same LSP. Also, both LSPs are fully instantiated (so they're both activated), which means no resource sharing can happen along the protection path, and no extra-traffic can ride it either 🙈

When one or both endpoints of the LSP detect a failure, both endpoints must select traffic from the other LSP. This action must be coordinated between node A and node D. So honestly? 1+1 bidirectional protection is just a coordinated protection-switching mechanism between both endpoints 💅

Note: it is necessary that both paths are SRLG disjoint to ensure recoverability; otherwise, a single failure may impact both working and protecting LSPs. 💀

6.1. Identifiers

okay so to make association operations easier, both LSPs belong to the same session 🎀 That means the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different so you can tell the two LSPs apart 🧚

There's also a new PROTECTION object (see Section 14) that gets included in the Path message. This object carries the desired end-to-end LSP Protection Type, which here is "1+1 Bidirectional" 💜 This LSP Protection Type value only applies to bidirectional LSPs, so no sneaking it onto the unidirectional ones 🙅‍♀️

It's also super useful to tell the working LSP (the one the signal is taken from) apart from the protecting LSP 🦋 For the working LSP, you set the S bit to 0 and the P bit to 0 in the PROTECTION object, and in the ASSOCIATION object you set the Association ID to the protecting LSP_ID. The protecting LSP gets signaled by setting the S bit to 0 and the P bit to 1 in the PROTECTION object, and setting the Association ID in the ASSOCIATION object to the associated protected LSP_ID ✨

6.2. End-to-End Switchover Request/Response

okay this part is the switchover handshake and it's kind of iconic 👑 To coordinate the switchover between endpoints, you need an end-to-end switchover request/response exchange. Why? Because a failure on one of the LSPs makes both endpoints switch to the other LSP, so they each start receiving traffic from the other LSP in their own direction 🌈

Here's how it goes:

If an end-node (A or D) detects the failure of the working LSP (or a degradation of signal quality over the working LSP), or receives a Notify message that includes its SESSION object within the <upstream/downstream session list> (see [RFC3473]) and the new error code/sub-code "Notify Error/ LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object, it MUST begin receiving on the protecting LSP 😭 Also, the <sender descriptor> or <flow descriptor> is present in the Notify message too, which clears up any ambiguity and race condition by identifying (together with the SESSION object) the LSP that's under the failure condition 🔍

Note: (IF_ID)_ERROR_SPEC indicates that either the ERROR_SPEC (C-Type 1/2) or the ERROR_SPEC (C-Type 3/4, defined in [RFC3473]) can be used.

This node MUST reliably send a Notify message, including the MESSAGE_ID object, to the other end-node (D or A, respectively) with the new error code/sub-code "Notify Error/LSP Failure" (Switchover Request) indicating the failure of the working LSP 🔥 This Notify message MUST be sent with the ACK_Desired flag set in the MESSAGE_ID object, which asks the receiver to send back an acknowledgment for the message (see [RFC2961]) 🫶

This (switchover request) Notify message MAY indicate the identity of the failed link or any other relevant information using the IF_ID ERROR_SPEC object (see [RFC3473]). In that case, the IF_ID ERROR_SPEC object replaces the ERROR_SPEC object in the Notify message. Otherwise, the corresponding (data plane) information SHOULD be received in the PathErr/ResvErr message 🍓

When the (switchover request) Notify message comes in, the end-node (D or A, respectively) MUST begin receiving from the protecting LSP 🦋

This node MUST reliably send a Notify message, including the MESSAGE_ID object, to the other end-node (A or D, respectively). This (switchover response) Notify message MUST also include a MESSAGE_ID_ACK object to acknowledge reception of the (switchover request) Notify message 💖

This (switchover response) Notify message MAY indicate the identity of the failed link or any other relevant information using the IF_ID ERROR_SPEC object (see [RFC3473]).

Note: when the (switchover response) Notify message is received, the end-node (A or D, respectively) MUST send an Ack message to the other end-node to acknowledge its reception 🌸

Since the intermediate nodes (B, C, E, F, and G) are assumed to be GMPLS RSVP-TE signaling capable, each node adjacent to the failure MAY generate a Notify message directed to the LSP head-end (upstream direction), the LSP tail-end (downstream direction), or even both 🧚 So it's expected that these LSP terminating nodes (which MAY also detect the failure of the LSP from the data plane) either have the right correlation mechanism to avoid repeating the procedure above, or just discard subsequent Notify messages for the same Session 🙈 Also, for the LSP under failure condition, it is RECOMMENDED to not set the Path_State_Removed Flag of the ERROR_SPEC object (see [RFC3473]) when generating the PathErr message 💜

After the protection switching completes (step 2), and after the PathErr message is received, the protecting LSP SHOULD be signaled with the O bit set, so everyone can keep track of which LSP the signal is being taken from 👑 The formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]) ✨

Note: when the N bit is set, the end-to-end switchover request/response exchange described above only provides control plane coordination. No actions are triggered at the data plane level. 🫶

7. 1:1 Protection with Extra-Traffic 🌈

okay so the most common case of end-to-end 1:N protection is setting up, between the same endpoints, an end-to-end working LSP (so N = 1) and a dedicated end-to-end protecting LSP. These two are mutually link, node, and SRLG disjoint, and together they protect against working LSP failures 🦋

The protecting LSP is used for switchover when the working LSP fails. GMPLS RSVP-TE signaling lets you pre-provision protecting LSPs by indicating in the Path message (in the PROTECTION object; see Section 14) that the LSPs are of type protecting 🎀 Here, the working and protecting LSPs are both signaled as primary LSPs, and both are fully instantiated during the provisioning phase 💅

Even though the resources for the protecting LSP are pre-allocated, preemptable traffic may be carried end-to-end using this LSP. So the protecting LSP can carry extra-traffic, with the caveat that this traffic gets preempted if the working LSP fails 🙈

The setup of the working LSP SHOULD indicate that the LSP head-end and tail-end nodes wish to receive Notify messages, using the NOTIFY REQUEST object 🔍 The node upstream of the failure (upstream in terms of the direction a Path message travels) SHOULD send a Notify message to the LSP head-end node, and the node downstream of the failure SHOULD send a Notify message to the LSP tail-end node 🍓 When the Notify messages arrive, both end-nodes MUST switch the (normal) traffic from the working LSP to the pre-configured protecting LSP (see Section 7.2) 😭 Some coordination is also required if extra-traffic is carried over the end-to-end protecting LSP. And if the working and the protecting LSP are established between the same end-nodes, no further notification is needed to indicate that the working LSPs are no longer protected 🌸

Consider this topology 👇

                              A---B---C---D
                               \         /
                                E---F---G

The working LSP [A,B,C,D] could be protected by the protecting LSP [A,E,F,G,D]. Both LSPs are fully instantiated (resources are allocated for both the working and protecting LSPs), and no resource sharing can be done along the protection path, since the primary protecting LSP can carry extra-traffic 🧚

Note: it is necessary that both paths are SRLG disjoint to ensure recoverability; otherwise, a single failure may impact both working and protecting LSPs. 💀

7.1. Identifiers

okay so to simplify association operations, both LSPs belong to the same session 🎀 That means the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different, so you can tell apart the protected LSP carrying working traffic from the protecting LSP that can carry extra-traffic 💜

A new PROTECTION object (see Section 14) is included in the Path message used to set up the two LSPs. This object carries the desired end-to-end LSP Protection Type, which in this case is "1:N Protection with Extra-Traffic". This LSP Protection Type value applies to both uni- and bidirectional LSPs 🌈

The working LSP is signaled by setting the S bit to 0 and the P bit to 0 in the new PROTECTION object, and setting the Association ID in the ASSOCIATION object to the protecting LSP_ID 🦋

The protecting LSP is signaled by setting the S bit to 0 and the P bit to 1 in the new PROTECTION object, and setting the Association ID in the ASSOCIATION object to the associated protected LSP_ID 🫶

7.2. End-to-End Switchover Request/Response ✨

okay so, to coordinate the switchover between the endpoints, we need an end-to-end switchover request/response so the affected LSP gets moved over to the protecting LSP 🦋 Switching from the working LSP to the protecting LSP (which means bumping any extra-traffic off the protecting LSP 🙈) must be initiated by one of the end-nodes (A or D) 💅

Here's how the dance goes:

If an end-node (A or D) spots the working LSP failing (or the signal quality over it getting sus), or gets a Notify message with its SESSION object in the <upstream/downstream session list> (see [RFC3473]) plus the new error code/sub-code "Notify Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object, it disconnects the extra-traffic from the protecting LSP 😭 Also, the <sender descriptor> or <flow descriptor> shows up in that Notify message too, which clears up any mixups and race conditions, because together with the SESSION object it pins down exactly which LSP is under failure 🎀

This node MUST reliably send a Notify message, including the MESSAGE_ID object, to the other end-node (D or A, respectively) with the new error code/sub-code "Notify Error/LSP Failure" (Switchover Request) saying the working LSP has failed 🔥 This Notify message MUST be sent with the ACK_Desired flag set in the MESSAGE_ID object so the receiver knows to send back an acknowledgment for it (see [RFC2961]) 🫶

This (switchover request) Notify message MAY indicate the identity of the failed link or any other relevant info using the IF_ID ERROR_SPEC object (see [RFC3473]). If it does, the IF_ID ERROR_SPEC object replaces the ERROR_SPEC object in the Notify message 💜 If it doesn't, the matching data plane info SHOULD be received in the PathErr/ResvErr message 🌸

When the (switchover request) Notify message shows up, the end-node (D or A, respectively) MUST disconnect the extra-traffic from the protecting LSP and start sending/receiving normal traffic out of/from the protecting LSP 👑

This node MUST reliably send a Notify message, including the MESSAGE_ID object, to the other end-node (A or D, respectively). This (switchover response) Notify message MUST also include a MESSAGE_ID_ACK object to acknowledge that it got the (switchover request) Notify message 🍓

This (switchover response) Notify message MAY indicate the identity of the failed link or any other relevant info using the IF_ID ERROR_SPEC object (see [RFC3473]) 🧚

Note: since the Notify message from the other end-node (A or D, respectively) is easy to tell apart from one sent by an intermediate node, there's no way the extra-traffic can get hooked back onto the working LSP just because a Notify came from an intermediate node 🙈

When the (switchover response) Notify message arrives, the end-node (A or D, respectively) MUST start receiving normal traffic from, or sending normal traffic out on, the protecting LSP 🌈

This node MUST also send an Ack message to the other end-node (D or A, respectively) to acknowledge the (switchover response) Notify message 💖

Note 1: a 2-phase protection-switching signaling is what we're using here 🦋 A 3-phase signaling (see [RFC4426]), which would involve a notification message, a switchover request message, and a switchover response message, isn't considered in this part. Also, when the protecting LSPs don't carry extra-traffic, the protection-switching signaling (as defined in Section 6.2) MAY be used instead of the procedure in this section ✨

Note 2: when the N bit is set, this end-to-end switchover request/response exchange only gives you control plane coordination, so no actions get triggered at the data plane level 🫶

After protection switching completes (step 3) and after the PathErr message is received, the protecting LSP SHOULD be signaled with the O bit set so everyone can keep track of which LSP the normal traffic is coming from 💅 On top of that, the formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]) 🎀

7.3. 1:N (N > 1) Protection with Extra-Traffic ✨

1:N (N > 1) protection with extra-traffic assumes the fully provisioned protecting LSP is resource-disjoint from the N working LSPs 🌸 That's what lets the protecting LSP carry extra-traffic 🦋 Just so we're clear, the N working LSPs and the protecting LSP are all between the same pair of endpoints 💜 The N working LSPs (treated as identical when it comes to traffic parameters) MAY be mutually resource-disjoint 🧚 Coordination between the end-nodes is required when switching from one of the working LSPs to the protecting LSP 🔥

Each working LSP is signaled with both the S bit and the P bit set to 0. The LSP Protection Type is set to 0x04 (1:N Protection with Extra-Traffic) during LSP setup. Each Association ID points to the protecting LSP ID 🍓

The protecting LSP (the one carrying extra-traffic) is signaled with the S bit set to 0 and the P bit set to 1. The LSP Protection Type is set to 0x04 (1:N Protection with Extra-Traffic) during LSP setup. The Association ID MUST be set by default to the LSP ID of the protected LSP corresponding to N = 1 👑

Any signaling procedure that applies to 1:1 protection with extra-traffic also applies equally to 1:N protection with extra-traffic 💖

8. Rerouting without Extra-Traffic 🦋

End-to-end (pre-planned) rerouting without extra-traffic depends on setting up, between the same pair of end-nodes, a working LSP and a protecting LSP that is link/node/SRLG disjoint from the working LSP 🌈 The catch is that the protecting LSP isn't fully instantiated, so it can't carry any extra-traffic (and no, that doesn't mean the resources can't be used by other LSPs 🙈). So this mechanism protects against working LSP failure(s), but the protecting LSP has to be activated after the failure happens 😭

Signaling works by indicating in the Path message (in the PROTECTION object; see Section 14) that the LSPs are of type working and protecting, respectively. Protecting LSPs get used for fast switchover when working LSPs fail 🔥 In this case, the working and protecting LSPs are signaled as primary LSP and secondary LSP, respectively. So only the working LSP is fully instantiated during provisioning, and no resources are committed at the data plane level for the protecting LSPs (they're pre-reserved at the control plane level only) 🫶 Setting up the working LSP SHOULD indicate (using the NOTIFY REQUEST object as specified in Section 4 of [RFC3473]) that the LSP head-end node (and possibly the tail-end node) wants to receive a Notify message when the LSP fails 💅 When that Notify message arrives, the head-end node MUST switch the (normal) traffic from the working LSP over to the protecting LSP after it's activated 🎀 And since the working and protecting LSPs are between the same end-nodes, no extra notification is needed to say the working LSPs are without protection 🧚

To make the bandwidth pre-reserved for a protecting (but not activated) LSP available for extra-traffic, that bandwidth could be included in the advertised Unreserved Bandwidth at a priority lower (meaning numerically higher) than the Holding Priority of the protecting LSP 💜 Also, the Max LSP Bandwidth field in the Interface Switching Capability Descriptor sub-TLV should reflect the fact that the bandwidth pre-reserved for the protecting LSP is available for extra traffic 🌸 LSPs for extra-traffic can then be established using that pre-reserved bandwidth by setting, in the Path message, the Setup Priority field of the SESSION_ATTRIBUTE object to X (where X is the Setup Priority of the protecting LSP), and the Holding Priority field to at least X+1 🍓 And if the resources pre-reserved for the protecting LSP are being used by lower-priority LSPs, those LSPs MUST be preempted when the protecting LSP is activated (see Section 10) ⭐

Consider the following topology 🌈

                              A---B---C---D
                               \         /
                                E---F---G

The working LSP [A,B,C,D] could be protected by the protecting LSP [A,E,F,G,D]. Only the protected LSP is fully instantiated (resources are only allocated for the working LSP), so the protecting LSP can't carry any extra-traffic 🙈 When a failure gets detected on the working LSP (say, at B), the error is propagated and/or notified to the ingress node (A) using a Notify message with the new error code/sub-code "Notify Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object 😭 Once the ingress node gets that, it activates the secondary protecting LSP that was set up during the (pre-)provisioning phase 🔥 This needs:

(1) the ability to identify a "secondary protecting LSP" (hereby called the "secondary LSP") used to recover another primary working LSP (hereby called the "protected LSP")
(2) the ability to associate the secondary LSP with the protected LSP
(3) the capability to activate a secondary LSP after failure occurrence

In the following subsections, these features get described in more detail 🦋

8.1. Identifiers 🫶

To keep association operations simple, both LSPs (the protected and the secondary LSPs) belong to the same session. So the SESSION object MUST be the same for both LSPs 💖 The LSP ID, however, MUST be different, so you can tell apart the protected LSP carrying working traffic from the secondary LSP that can't carry extra-traffic 🌈

A new PROTECTION object (see Section 14) is used to set up the two LSPs. This object carries the desired end-to-end LSP Protection Type (in this case, "Rerouting without Extra-Traffic"). This LSP Protection Type value applies to both unidirectional and bidirectional LSPs 🍓

8.2. Signaling Primary LSPs 💅

The new PROTECTION object is included in the Path message while signaling the primary working LSP, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic" 🎀

Primary working LSPs are signaled by setting the S bit to 0 and the P bit to 0 in the new PROTECTION object, and setting the Association ID in the ASSOCIATION object to the associated secondary protecting LSP_ID 🧚

8.3. Signaling Secondary LSPs 🧚

okay so the new PROTECTION object gets slotted into the Path message when you're signaling secondary protecting LSPs 💅, and the end-to-end LSP Protection Type gets set to "Rerouting without Extra-Traffic" 🦋

to mark a secondary protecting LSP, you set the S bit and the P bit to 1 in the new PROTECTION object 🫶. then in the ASSOCIATION object, the Association ID gets set to the associated primary working LSP_ID. that LSP_ID MUST be known before the secondary LSP gets signaled, so plan ahead bestie 🙈

with that setup, the resources for the secondary LSP SHOULD be pre-reserved 🌸, but not committed at the data plane level. so the switch internals don't need to be set up yet, and that only happens once someone takes explicit action to activate this secondary LSP ✨. activation is done with a modified Path message that has the S bit set to 0 in the PROTECTION object. at that point, the link and node resources must be allocated for this LSP, which becomes a primary LSP and is ready to carry normal traffic 🔥

from [RFC3945], the secondary LSP is set up with resource pre-reservation, but with or without label pre-selection (both of which allow sharing of the recovery resources) 🎀. with label pre-selection off (the default), label allocation during secondary LSP signaling doesn't need any special procedure compared to [RFC3473] 💖. but with label pre-selection on, label (and thus resource) re-allocation MAY occur during the secondary LSP activation 👑. that means labels MAY be reassigned during the LSP activation phase, with higher precedence over the existing label assignment. see also [RFC3471] 🧠

Note: under certain circumstances (e.g., when pre-reserved protecting resources are used by lower-priority LSPs), it MAY be desirable to perform the activation of the secondary LSP in the upstream direction (Resv trigger message) instead of using the default downstream activation. in this case, any mis-ordering and any mis-interpretation between a refresh Resv (along the lower-priority LSP) and a trigger Resv message (along the secondary LSP) MUST be avoided at any intermediate node 😭 for this purpose, upon reception of the Path message, the egress node MAY include the PROTECTION object in the Resv message. the Resv message is then processed on a hop-by-hop basis to activate the secondary LSP until it reaches the ingress node 🦋 the PROTECTION object included in the Path message MUST be set as specified in this section. in this case, the PROTECTION object with the S bit MUST be set to 0 and included in the Resv message sent in the upstream direction. the upstream activation behavior SHOULD be configurable on a local basis 💅 details about lower-priority LSP preemption upon secondary LSP activation are provided in Section 10 🌈

9. Shared-Mesh Restoration ✨

okay this is the one that makes my brain go brrr 🧠✨ an approach to reduce recovery resource requirements is to have protection LSPs share network resources when the working LSPs they protect are physically (i.e., link, node, SRLG, etc.) disjoint 💜. this mechanism is called shared mesh restoration and it's described in [RFC4426] 🦋. shared-mesh restoration is basically a particular case of pre-planned LSP rerouting (see Section 8) that cuts down on recovery resource requirements by letting multiple protecting LSPs share common link and node resources 🫶. again, the recovery resources for the protecting LSPs are pre-reserved during the provisioning phase, so an explicit signaling action is required to activate (i.e., commit resource allocation at the data plane) a specific protecting LSP that was instantiated during the (pre-)provisioning phase. this requires restoration signaling along the protecting LSP 🔥

to make bandwidth pre-reserved for a protecting (but not activated) LSP available for extra-traffic, that bandwidth could be included in the advertised Unreserved Bandwidth at a priority lower (numerically higher) than the Holding Priority of the protecting LSP 🌸. also, the Max LSP Bandwidth field in the Interface Switching Capability Descriptor sub-TLV should reflect the fact that the bandwidth pre-reserved for the protecting LSP is available for extra traffic 🎀. LSPs for extra-traffic can then be established using the bandwidth pre-reserved for the protecting LSP. to do that, you set the Setup Priority field of the SESSION_ATTRIBUTE object (in the Path message) to X (where X is the Setup Priority of the protecting LSP) and the Holding Priority field to at least X+1 🧚 and if the resources pre-reserved for the protecting LSP are used by lower-priority LSPs, these LSPs MUST be preempted when the protecting LSP is activated (see Section 10) 😭 further, if the recovery resources are shared between multiple protecting LSPs, the corresponding working LSPs' head-end nodes must be informed that they are no longer protected when the protecting LSP is activated to recover the normal traffic for the working LSP under failure 💀

here's the topology, it's giving diagram energy 🍓

                                  A---B---C---D
                                   \         /
                                    E---F---G
                                   /         \
                                  H---I---J---K

the working LSPs [A,B,C,D] and [H,I,J,K] could be protected by [A,E,F,G,D] and [H,E,F,G,K], respectively. per [RFC3209], in order to achieve resource sharing during the signaling of these protecting LSPs, they must have the same Tunnel Endpoint Address (as part of their SESSION object) 🙈. however, these addresses are not the same in this example. resource sharing along E, F, and G can only be achieved if the nodes E, F, and G recognize that the LSP Protection Type of the secondary LSP is set to "Rerouting without Extra-Traffic" (see PROTECTION object, Section 14) and act accordingly 👑. in this case, the protecting LSPs are not merged (which is useful since the paths diverge at G), but the resources along E, F, G can be shared 🌈

when a failure is detected on one of the working LSPs (say, at B), the error is propagated and/or notified to the ingress node (A) 🚨. this uses a Notify message with the new error code/sub-code "Notify Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object. upon reception, the ingress node activates the secondary protecting LSP (see Section 8) 🔥. at this point, it's super important that a failure on the other LSP (say, at J) does not cause the other ingress (H) to send data down the protecting LSP, since the resources are already in use 😭. this can be achieved by node E using the following procedure. when the capacity is first reserved for the protecting LSP, E should verify that the LSPs being protected ([A,B,C,D] and [H,I,J,K], respectively) do not share any common resources 🫶. then, when a failure occurs (say, at B) and the protecting LSP [A,E,F,G,D] is activated, E should notify H that the resources for the protecting LSP [H,E,F,G,K] are no longer available 💅

the following subsections detail how shared mesh restoration can be implemented in an interoperable fashion using GMPLS RSVP-TE extensions (see [RFC3473]). this includes:

the ability to identify a "secondary protecting LSP" (hereby called the "secondary LSP") used to recover another primary working LSP (hereby called the "protected LSP")
the ability to associate the secondary LSP with the protected LSP
the capability to include information about the resources used by the protected LSP while instantiating the secondary LSP
the capability to instantiate several secondary LSPs during the provisioning phase in an efficient manner
the capability to activate a secondary LSP after failure occurrence

in the following subsections, these features get the full breakdown 🦋

9.1. Identifiers 🪪

to simplify association operations, both LSPs (i.e., the protected and the secondary LSPs) belong to the same session. so the SESSION object MUST be the same for both LSPs 💖. the LSP ID, however, MUST be different, so the protected LSP carrying working traffic can be told apart from the secondary LSP that cannot carry extra-traffic 🙈

a new PROTECTION object (see Section 14) is used to set up the two LSPs 🎀. this object carries the desired end-to-end LSP Protection Type, which in this case is "Rerouting without Extra-Traffic". this LSP Protection Type value applies to both unidirectional and bidirectional LSPs 🌸

9.2. Signaling Primary LSPs 🚀

the new PROTECTION object gets included in the Path message during signaling of the primary working LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic" 🧚

primary working LSPs are signaled by setting the S bit to 0 and the P bit to 0 in the new PROTECTION object. then in the ASSOCIATION object, the Association ID gets set to the associated secondary protecting LSP_ID 💅

9.3. Signaling Secondary LSPs 🧚

the new PROTECTION object gets included in the Path message during signaling of the secondary protecting LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic" 🦋

secondary protecting LSPs are signaled by setting the S bit and the P bit to 1 in the new PROTECTION object, and in the ASSOCIATION object, the Association ID gets set to the associated primary working LSP_ID. that LSP_ID MUST be known before the secondary LSP gets signaled 🙈. also, the Path message used to instantiate the secondary LSP SHOULD include at least one PRIMARY_PATH_ROUTE object (see Section 15), which further allows recovery resource sharing at each intermediate node along the secondary path 🫶

with that setting, the resources for the secondary LSP SHOULD be pre-reserved, but not committed at the data plane level 🌸. so the switch internals don't need to be established until someone takes explicit action to activate this LSP ✨. activation is done with a modified Path message that has the S bit set to 0 in the PROTECTION object. at that point, the link and node resources must be allocated for this LSP, which becomes a primary LSP and is ready to carry normal traffic 🔥

from [RFC3945], the secondary LSP is set up with resource pre-reservation, but with or without label pre-selection (both allowing sharing of the recovery resources) 🎀. with label pre-selection off (the default), label allocation during secondary LSP signaling doesn't need any special procedure compared to [RFC3473] 💖. but with label pre-selection on, label (and thus resource) re-allocation MAY occur during the secondary LSP activation 👑. that means that during the LSP activation phase, labels MAY be reassigned, with higher precedence over the existing label assignment. see also [RFC3471] 🧠

10. LSP Preemption 👑

okay so when protecting resources are only pre-reserved for the secondary LSPs, they MAY be used to set up lower-priority LSPs 💅. BUT here's the tea: those resources MUST be preempted when the protecting LSP gets activated 🔥. There's also a sneaky extra condition, misconnection avoidance 😭, between the secondary protecting LSP being activated and the low-priority LSP(s) being preempted. Here's what happens when the secondary protecting LSP (aka the preempting LSP) Path message reaches a node that's using resources for lower-priority LSP(s) (aka preempted LSP(s)) 🦋:

De-allocate resources to be used by the preempting LSP and release the cross-connection. Also, if the preempting LSP is bidirectional, these resources may come from one or two lower-priority LSPs, and if they come from two LSPs, they may be uni- or bi-directional 🧚. The preempting node SHOULD NOT send the Path message before the de-allocation of resources has completed, since this may lead to the downstream path becoming misconnected if the downstream node is able to reassign the resources more quickly 💀.
Send PathTear and PathErr messages with the new error code/sub-code Policy Control failure/Hard preempted and the Path_State_Removed flag set for the preempted LSP(s) 🌸.
Reserve the preempted resources for the protecting LSP. The preempting node MUST NOT cross-connect the upstream resources of a bidirectional preempting LSP 🙈.
Send the Path message ✨.
Upon reception of a trigger Resv message from the downstream node, cross-connect the downstream path resources, and if the preempting LSP is bidirectional, perform cross-connection for the upstream path resources 🎀.

Heads up, step 1 may cause alarms to be raised for the preempted LSP 🚨. If alarm suppression is desired, the preempting node MAY insert the following steps before step 1.

1a. Before de-allocating resources, send a Resv message, including an ADMIN_STATUS object, to disable alarms for the preempted LSP.

1b. Receive a Path message indicating that alarms are disabled.

At the downstream node (with respect to the preempting LSP), the processing is RECOMMENDED to go like this 🍓:

Receive PathTear (and/or PathErr) message for the preempted LSP(s).

2a. Release the resources associated with the LSP on the interface to the preempting LSP, remove any cross-connection, and release all other resources associated with the preempted LSP 🧹.

2b. Forward the PathTear (and/or PathErr) message per [RFC3473].

Receive the Path message for the preempting LSP and process it as normal, forwarding it to the downstream node 💜.
Receive the Resv message for the preempting LSP and process it as normal, forwarding it to the upstream node 🫶.

11. (Full) LSP Rerouting 🌈

LSP rerouting, on the other hand, switches normal traffic to an alternate LSP that is fully established only after a failure occurs 🦋. The new (alternate) route is selected at the LSP head-end and may reuse intermediate nodes from the original route; it may also include additional intermediate nodes ✨. For strict-hop routing, TE requirements can be applied directly to the route computation, and the failed node or link can be avoided 🎯. However, if the failure occurred within a loose-routed hop, the head-end node may not have enough information to reroute the LSP around the failure 😩. Crankback signaling (see [CRANK]) and route exclusion techniques (see [RFC4874]) MAY be used in this case 🔧.

The alternate route MAY be either computed on demand (that is, when the failure occurs; this is referred to as full LSP rerouting) or pre-computed and stored for use when the failure is reported 🧠. The latter offers faster restoration time ⚡. There is, however, a risk that the alternate route will become out of date through other changes in the network 🫠; this can be mitigated to some extent by periodic recalculation of idle alternate routes 🔁.

(Full) LSP rerouting will be initiated by the head-end node that has either detected the LSP failure or received a Notify message and/or a PathErr message with the new error code/sub-code Notify Error/LSP Locally Failed for this LSP 🚨. The new LSP resources can be established using the make-before-break mechanism, where the new LSP is set up before the old LSP is torn down 🧁. This is done by using the mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit (SE) reservation style (see [RFC3209]) 💅. Both the new and old LSPs can share resources at common nodes 🫂.

Note that the make-before-break mechanism is not used to avoid disruption to the normal traffic flow (that flow has already been broken by the failure being repaired) 💔. However, it is valuable to retain the resources allocated on the original LSP that will be reused by the new alternate LSP 💎.

11.1. Identifiers 🪪

The Tunnel Endpoint Address, Tunnel ID, Extended Tunnel ID, and Tunnel Sender Address uniquely identify both the old and new LSPs 👯. Only the LSP_ID value differentiates the old from the new alternate LSP 🔑. The new alternate LSP is set up before the old LSP is torn down using the Shared-Explicit (SE) reservation style. This ensures that the new (alternate) LSP is established without double-counting resource requirements along common segments 🧮.

The alternate LSP MAY be set up before any failure occurs with SE-style resource reservation; the latter shares the same Tunnel End Point Address, Tunnel ID, Extended Tunnel ID, and Tunnel Sender Address with the original LSP (i.e., only the LSP ID value MUST be different) 🦋.

In both cases, the Association ID of the ASSOCIATION object MUST be set to the LSP ID value of the signaled LSP 🎀.

11.2. Signaling Reroutable LSPs 📡

A new PROTECTION object is included in the Path message during signaling of dynamically reroutable LSPs, with the end-to-end LSP Protection Type value set to "Full Rerouting" 🌟. These LSPs, which can be either uni- or bidirectional, are signaled by setting the S bit to 0, the P bit to 0, and the Association ID value to the LSP_ID value of the signaled LSP in the PROTECTION object 💖. Any specific action to be taken during the provisioning phase is up to the end-node local policy 🧑‍💻.

Note: when the end-to-end LSP Protection Type is set to "Unprotected", both the S and P bits MUST be set to 0, and the LSP SHOULD NOT be rerouted at the head-end node after a failure occurs 🙅‍♀️. The Association_ID value MUST be set to the LSP_ID value of the signaled LSP. This does not mean that the Unprotected LSP cannot be re-established for other reasons, such as path re-optimization and bandwidth adjustment driven by policy conditions 🔄.

12. Reversion ✨

okay so reversion is when the normal traffic goes back home to the working LSP after it's recovered from a failure 🦋 it basically means the resources stay reserved for the LSP that was originally using them, even after everything went sideways. so it's super important to have ways to do this with minimal service disruption and reconfiguration 💅

For "1+1 bidirectional Protection", reversion to the recovered LSP happens in this order 🎀

Clear the A bit of the ADMIN_STATUS object if set for the recovered LSP.
Then, use the method below to switch normal traffic back from the protecting LSP to the recovered LSP. This uses the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request) 🌸

The steps go like this:

The initiating (source) node sends the normal traffic onto both the working and the protecting LSPs. Once that's done, the source node sends a Notify message to the destination, reliably, with the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request). This Notify message includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to ask the receiver to send back an acknowledgment for the message (see [RFC2961]).
When the destination gets that message, it selects the traffic from the working LSP. At the same time, it transmits the traffic onto both the working and protecting LSP.

Then the destination sends a Notify message to the source, reliably, confirming the operation is complete. This message includes the MESSAGE_ID_ACK object to acknowledge that it received the Notify message. It also includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to ask the receiver to send back an acknowledgment for the message (see [RFC2961]).

When the source node gets this Notify message, it switches to receiving traffic from the working LSP.

Then the source node sends an Ack message to the destination node, confirming that the LSP has been reverted 🧚

Finally, clear the O bit of the PROTECTION object sent over the protecting LSP ✨

For "1:N Protection with Extra-traffic", reversion to the recovered LSP happens like this 👑

Clear the A bit of the ADMIN_STATUS object if set for the recovered LSP.
Then, use the method below to switch normal traffic back from the protecting LSP to the recovered LSP. This uses the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request) 🌸

The steps go like this:

The initiating (source) node sends the normal traffic onto both the working and the protecting LSPs. Once that's done, the source node sends a Notify message to the destination, reliably, with the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request). This Notify message includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to ask the receiver to send back an acknowledgment for the message (see [RFC2961]).
When the destination gets that message, it selects the traffic from the working LSP. At the same time, it transmits the traffic onto both the working and protecting LSP.

When the source node gets this Notify message, it switches to receiving traffic from the working LSP, and stops transmitting traffic on the protecting LSP.

Then the source node sends an Ack message to the destination node, confirming that the LSP has been reverted.

When the destination node gets this message, it stops transmitting traffic along the protecting LSP 🫶

Finally, clear the O bit of the PROTECTION object sent over the protecting LSP ✨

For "Rerouting without Extra-traffic" (including the shared recovery case), reversion means the formerly working LSP was never torn down by the head-end node when it got the PathErr message. In other words, the head-end kept refreshing the working LSP even while it was failing 🔥 That's what makes sure the exact same resources come back after reversion switching, unless the working LSP needed to be re-signaled. Re-activation goes like this 💖

Clear the A bit of the ADMIN_STATUS object if set for the recovered LSP.
Then, use the method below to switch normal traffic back from the protecting LSP to the recovered LSP. This uses the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request) 🌸

The steps go like this:

The initiating (source) node sends the normal traffic onto both the working and the protecting LSPs. Once that's done, the source node sends a Notify message to the destination, reliably, with the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request). This Notify message includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to ask the receiver to send back an acknowledgment for the message (see [RFC2961]).
When the destination gets that message, it selects the traffic from the working LSP. At the same time, it transmits the traffic onto both the working and protecting LSP.

When the source node gets this Notify message, it switches to receiving traffic from the working LSP, and stops transmitting traffic on the protecting LSP.

Then the source node sends an Ack message to the destination node, confirming that the LSP has been reverted.

When the destination node gets this message, it stops transmitting traffic along the protecting LSP 🫶

Finally, de-activate the protecting LSP by setting the S bit to 1 in the PROTECTION object sent over the protecting LSP 🦋

13. Recovery Commands 🎀

this section is all about the control plane behavior when you use several commands (see [RFC4427]) that can influence recovery operations. these are basically the knobs you can turn 🎛️

A. Lockout of recovery LSP:

the Lockout (L) bit of the ADMIN_STATUS object is used by following the rules in Section 8 of [RFC3471] and Section 7 of [RFC3473]. the L bit must be set together with the Reflect (R) bit in the ADMIN_STATUS object sent in the Path message. when the Resv message comes back with the L bit set, the recovery LSP is forced to be temporarily unavailable to carry traffic (normal or extra-traffic) 🧊 Unlock happens by clearing the L bit, following the rules in Section 7 of [RFC3473]. this procedure only applies when the LSP Protection Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 Bidirectional Protection) 💜

the updated format of the ADMIN_STATUS object, with the L bit included, looks like this:

  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(196)|   C-Type (1)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |R|                        Reserved                 |L|I|C|T|A|D|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Lockout (L): 1 bit

When set, forces the recovery LSP to be temporarily unavailable to transport traffic (either normal or extra traffic).

the R (Reflect), T (Testing), A (Administratively down), and D (Deletion in progress) bits are defined in [RFC3471]. the C (Call control) bit is defined in [GMPLS-CALL], and the I (Inhibit alarm communication) bit in [RFC4783] 🌈

B. Lockout of normal traffic:

the O bit of the PROTECTION object is set to 1 to force the recovery LSP to be temporarily unavailable to transport normal traffic. > This operation MUST NOT occur unless the working LSP is carrying the normal traffic. Unlock is performed by clearing the O bit over the protecting LSP. this procedure only applies when the LSP Protection Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 Bidirectional Protection) 🔒

C. Forced switch for normal traffic:

recovery signaling is initiated to switch normal traffic to the recovery LSP, following the procedures defined in Section 6, 7, 8, and 9 🚀

D. Requested switch for normal traffic:

recovery signaling is initiated to switch normal traffic to the recovery LSP, following the procedures defined in Section 6, 7, 8, and 9. this happens unless a fault condition exists on other LSPs or spans (including the recovery LSP), or a switch command of equal or higher priority is in effect 🙈

E. Requested switch for recovery LSP:

recovery signaling is initiated to switch normal traffic back to the working LSP, following the procedure defined in Section 12. this request is executed except if a fault condition exists on the working LSP or an equal or higher priority switch command is in effect 🧚

14. PROTECTION Object 💅

this section describes the extensions to the PROTECTION object so it can cover end-to-end LSP recovery, which is a much bigger playground than before 🌸

14.1. Format

okay so the PROTECTION Object is Class-Num = 37, C-Type = 2, and it's giving bit-level drama 💅✨

      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|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Secondary (S): 1 bit 🦋 When set to 1, this bit means the requested LSP is a secondary LSP. When it's set to 0 (the default), the requested LSP is a primary LSP. Simple, but it matters!

Protecting (P): 1 bit 🛡️ When set to 1, the requested LSP is a protecting LSP. When set to 0 (the default), it's a working LSP. Heads up: the combo of S set to 1 with P set to 0 is not valid 🙅

Notification (N): 1 bit 🔔 When set to 1, the control plane message exchange is only used for notification during protection switching. When set to 0 (the default), the control plane message exchanges are used for protection-switching purposes. The N bit is only applicable when the LSP Protection Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 Bidirectional Protection). The N bit MUST be set to 0 in any other case. 🙈

Operational (O): 1 bit 🌸 When set to 1, the protecting LSP is carrying the normal traffic after protection switching. The O bit only applies when the P bit is set to 1 and the LSP Protection Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 Bidirectional Protection). The O bit MUST be set to 0 in any other case.

Reserved: 5 bits 🫧 This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be passed through unmodified by transit nodes.

LSP (Protection Type) Flags: 6 bits 👑 This is the desired end-to-end LSP recovery type. A value of 0 means the LSP is "Unprotected". Only one value SHOULD be set at a time. These are the defined values, and everything else is reserved:

       0x00    Unprotected
       0x01    (Full) Rerouting
       0x02    Rerouting without Extra-Traffic
       0x04    1:N Protection with Extra-Traffic
       0x08    1+1 Unidirectional Protection
       0x10    1+1 Bidirectional Protection

Reserved: 10 bits 🌈 Same deal as before: it's reserved, it MUST be set to zero on transmission, it MUST be ignored on receipt, and it SHOULD be passed through unmodified by transit nodes.

Link Flags: 6 bits 🔗 This is the desired link protection type (see [RFC3471]).

Reserved field: 32 bits 🧚 The encoding of this field is detailed in [RFC4873].

14.2. Processing

okay this part is all about checking your work ✅ Intermediate and egress nodes that process a Path message with a PROTECTION object MUST verify that the requested LSP Protection Type can be satisfied by the incoming interface. If it can't, the node MUST generate a PathErr message with the new error code/sub-code "Routing problem/Unsupported LSP Protection". No cap, that's the rule. 🚫

Intermediate nodes that process a Path message containing a PROTECTION object with the LSP Protection Type 0x02 (Rerouting without Extra-Traffic) value set, plus a PRIMARY_PATH_ROUTE object (see Section 15), MUST verify that the requested LSP Protection Type can be supported by the outgoing interface. If it can't, the node MUST generate a PathErr message with the new error code/sub-code "Routing problem/Unsupported LSP Protection". Lowkey the same energy, just checking the outgoing side this time 💖

15. PRIMARY_PATH_ROUTE Object ✨

The PRIMARY_PATH_ROUTE object (PPRO) is how we tell the nodes on a secondary protecting LSP's path which resources (links or nodes) the associated primary protected LSP is already using. That's identified by the Association ID field. If the LSP Protection Type value is 0x02 (Rerouting without Extra-Traffic), this object SHOULD be present in the Path message. That lets you pre-provision the secondary protecting LSP so it can share recovery resources with one or more other secondary protecting LSPs (see Section 9). This document doesn't assume or rule out any other usage for this object. 🦋

PRIMARY_PATH_ROUTE objects carry information pulled from the EXPLICIT ROUTE object and/or the RECORD ROUTE object of the primary working LSPs they protect. The head-end node that starts the request gets to decide what goes in the PPRO content, based on its local policy. That means the info can be used as policy-based admission control, so recovery resources only get shared between secondary protecting LSPs whose primary LSPs have link/node/SRLG disjoint paths. Main character admission control 👑

15.1. Format

The primary path route is specified via the PRIMARY_PATH_ROUTE object (PPRO). Its Primary Path Route Class Number (Class-Num) is of the form 0bbbbbbb 38. 💅

Right now there's one C-Type (Class-Type) defined: Type 1, Primary Path Route. The PRIMARY_PATH_ROUTE object looks like this:

Class-Num = 38 (of the form 0bbbbbbb), C-Type = 1

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                        (Subobjects)                         //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The contents of a PRIMARY_PATH_ROUTE object are a series of variable-length data items called subobjects (see Section 15.3). 🧩

To signal a secondary protecting LSP, the Path message MAY include one or multiple PRIMARY_PATH_ROUTE objects, and each one has to be meaningful. Multiple objects are useful when a secondary protecting LSP needs to be link/node/SRLG disjoint from more than one primary LSP, aka it's protecting more than one primary LSP. Protecting multiple things at once? Iconic. ✨

15.2. Subobjects

The PRIMARY_PATH_ROUTE object is a list of variable-length data items called subobjects. These are derived from the subobjects of the EXPLICIT ROUTE and/or RECORD ROUTE object of the primary working LSP(s). 🌸

Each subobject has its own length field. The length is the total length of the subobject in bytes, including the Type and Length fields. The length MUST always be a multiple of 4, and at least 4. 📏

These are the subobjects currently defined for the PRIMARY_PATH_ROUTE object:

Sub-Type 1: IPv4 Address (see [RFC3209])
Sub-Type 2: IPv6 Address (see [RFC3209])
Sub-Type 3: Label (see [RFC3473])
Sub-Type 4: Unnumbered Interface (see [RFC3477])

An empty PPRO with no subobjects is illegal, so no empty ones, bestie 🙅 If there's no first subobject, the Path message is also in error, and the receiving node SHOULD return a PathErr message with the new error code/sub-code "Routing Problem/Bad PRIMARY_PATH_ROUTE object".

Note: an intermediate node processing a PPRO can derive SRLG identifiers from the local IGP-TE database. It does this by using its Type 1, 2, or 4 subobject values as pointers to the corresponding TE Links, assuming each of them has an associated SRLG TE attribute. 🔍

15.3. Applicability

The PRIMARY_PATH_ROUTE object MAY only be used when all GMPLS nodes along the path support it and a secondary protecting LSP is being requested. It's assigned a class value of the form 0bbbbbbb. If a receiving GMPLS node along the path doesn't support this object, that node MUST return a PathErr message with the "Unknown Object Class" error code (see [RFC2205]). 🚨

There are also some restrictions on PPRO usage that MUST be applied:

PPROs MAY only be included in Path messages when signaling secondary protecting LSPs (S bit = 1 and P bit = 1) and when the LSP Protection Type value is 0x02 (without Rerouting Extra-Traffic) in the PROTECTION object (see Section 14). 💜
PRROs SHOULD be present in the Path message for the pre-provisioning of the secondary protecting LSP, so recovery resources can be shared between one or more secondary protecting LSPs (see Section 15.4).
PPROs MUST NOT be used in any other conditions. In particular, if a PPRO is received when the S bit is set to 0 in the PROTECTION object, the receiving node MUST return a PathErr message with the new error code/sub-code "Routing Problem/PRIMARY_PATH_ROUTE object not applicable". Nope, not allowed 🙅‍♀️
Crossed exchanges of PPROs over primary LSPs are forbidden. Their usage is restricted to a single set of protected LSPs. 🚫
The PPRO's content MUST NOT include subobjects coming from other PPROs. In particular, received PPROs MUST NOT be reused to establish other working or protecting LSPs. Don't recycle other people's PPROs, periodt 💀

15.4. Processing 🧚

okay so the PPRO is what lets secondary protecting LSPs share recovery resources 🫶, as long as their primary working LSPs have mutually (link/node/SRLG) disjoint paths 💅. picture a node N where n secondary protecting LSPs (let's say P[1],...,P[n]) are already set up and protecting n primary working LSPs (P'[1],...,P'[n]). say these n secondary working LSPs all share one outgoing link resource (call it r) 🦋

now the plot twist: node N gets a Path message for another secondary protecting LSP (Q, protecting Q') ✨. the PPRO in that message gets processed like this:

N checks whether the primary working LSPs P'[1],...,P'[n], which go with P[1],...,P[n] respectively, have any link, node, and SLRG in common with the primary working Q' (the one tied to Q). it does this by comparing the stored PPRO subobjects for P'[1],...,P'[n] with the PPRO subobjects for Q' that came in the Path message 🔍
if they DO overlap, N SHOULD NOT attempt to share the outgoing link resource r between P[1],...,P[n] and Q 🙅‍♀️. however, if local policy allows it, N MAY allocate another available (shared) link other than r for Q 🔀. if that's not the case (local policy says no other link can be allocated for Q) or if no other link is available for Q, N SHOULD return a PathErr message with the new error code/sub-code "Admission Control Failure/LSP Admission Failure" 😭
otherwise, if P'[1],...,P'[n] and Q' are fully disjoint 🌈, the link r that N picks for LSP Q MAY be exactly the same one picked for P[1],...,P[n]. this happens after N checks (from its local policy) that link r can be shared between these LSPs ✅. if that's not the case (say the sharing ratio has already hit its max for that link) and local policy says no other link can be allocated for Q, N SHOULD return a PathErr message with the error code/sub-code "Admission Control Failure/Requested Bandwidth Unavailable" (see [RFC2205]) 💀. otherwise (if no other link is available), N SHOULD return a PathErr message with the new error code/sub-code "Admission Control Failure/LSP Admission Failure" 🥲

⚠️ bestie, note that which m out of the n (m =< n) secondary protecting LSPs' PPROs get picked for that comparison and link selection is decided locally. that process is out of scope of this document 🙈

16. ASSOCIATION Object 💜

the ASSOCIATION object is how LSPs get linked up with each other 🔗. for end-to-end LSP recovery, the association MUST only identify LSPs that support the same Tunnel ID, the same tunnel sender address, and the same tunnel endpoint address 👑. the Association Type, Association Source, and Association ID fields together uniquely identify an association 🎀. this object uses an object class number of the form 11bbbbbb so that non-supporting nodes don't freak out 🫧

the ASSOCIATION object is how LSPs get associated with each other.

16.1. Format 📐

the IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 1) looks like this:

  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(199)|  C-Type (1)   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       Association Type        |       Association ID          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  IPv4 Association Source                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

the IPv6 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 2) looks like this:

  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(199)|  C-Type (2)   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       Association Type        |       Association ID          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                  IPv6 Association Source                      |
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Association Type: 16 bits 🏷️

Indicates the type of association being identified. this value is considered when determining the association. the following are values defined in this document:

    Value       Type
    -----       ----
      0         Reserved
      1         Recovery (R)

Association ID: 16 bits 🆔

a value assigned by the LSP head-end. combined with the Association Type and Association Source, this value uniquely identifies an association 💖

Association Source: 4 or 16 bytes 📍

an IPv4 or IPv6 address (depending on which one you're using), associated with the node that originated the association 🌸

16.2. Processing 🧠

in the end-to-end LSP recovery context, the ASSOCIATION object is used to associate a recovery LSP with the LSP(s) it's protecting, or a protected LSP(s) with its recovery LSP 🔁. the object is carried in Path messages. more than one object MAY be carried in a single Path message ✨

Transit nodes MUST transmit, without modification, any received ASSOCIATION object in the corresponding outgoing Path message 🚚

an ASSOCIATION object with an Association Type set to the value "Recovery" is used to identify an LSP-Recovery-related association 🩷. any node associating a recovery LSP MUST insert an ASSOCIATION object with the following settings:

the Association Type MUST be set to the value "Recovery" in the Path message of the recovery LSP 💜
the (IPv4/IPv6) Association Source MUST be set to the tunnel sender address of the LSP being protected 📮
the Association ID MUST be set to the LSP ID of the LSP being protected by this LSP, or the LSP protecting this LSP. if it's unknown, this value is set to its own signaled LSP_ID value (default). also, the value of the Association ID MAY change during the lifetime of the LSP 🦋

terminating nodes use received ASSOCIATION object(s) with the Association Type set to "Recovery" to associate a recovery LSP with its matching working LSP 🎯. this info is used to bind the right working and recovery LSPs together 🫶. such nodes MUST ensure that the received Path messages, including the ASSOCIATION object(s), are processed with the appropriate PROTECTION object settings, if present (see Section 14 for PROTECTION object processing) 🛡️. otherwise, this node MUST return a PathErr message with the new error code/sub-code "LSP Admission Failure/Bad Association Type" 😤

similarly, terminating nodes receiving a Path message with a PROTECTION object that requires association between working and recovery LSPs MUST include an ASSOCIATION object 🙌. otherwise, such nodes MUST return a PathErr message with the new error code/sub-code "Routing Problem/PROTECTION object not Applicable" 💀

17. Updated RSVP Message Formats 🎀

this section shows the RSVP message formats as modified by this document 💅. unmodified RSVP message formats aren't listed 🙈

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> ... ]
                   [ <PRIMARY_PATH_ROUTE> ... ]
                   [ <POLICY_DATA> ... ]
                   <sender descriptor>

the format of the <sender descriptor> for unidirectional and bidirectional LSPs is not modified by the present document 🧡

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> ]
                   [ <PROTECTION> ]
                   [ <NOTIFY_REQUEST> ]
                   [ <ADMIN_STATUS> ]
                   [ <POLICY_DATA> ... ]
                   <STYLE> <flow descriptor list>

<flow descriptor list> is not modified by this document 🌷

18. Security Considerations 🔐

okay bestie, this one is SERIOUS 😭🔥. the security threats identified in [RFC4426] may show up because of the RSVP messages and info exchanged as detailed in this document. the following security mechanisms apply 🛡️

RSVP signaling MUST be able to provide authentication and integrity 🚨. authentication is required so we can be sure the signaling messages are coming from the right place and haven't been changed in transit 👀

for this purpose, [RFC2747] provides the required RSVP message authentication and integrity for hop-by-hop RSVP message exchanges 🔒. for non hop-by-hop RSVP message exchanges, the standard IPsec-based integrity and authentication can be used, as explained in [RFC3473] 🧩

this document also uses the Notify message exchange 📬. this rules out RSVP's hop-by-hop integrity and authentication model 🙃. when the same level of security that [RFC2747] provides is wanted, the standard IPsec-based integrity and authentication can be used, as explained in [RFC3473] 💜

to prevent the consequences of poorly applied protection and the increased risk of misconnection (especially when extra-traffic is involved, since that could deliver the wrong traffic to the wrong destination) 😱, specific mechanisms are in place as described in Section 7.2, 8.3, and 10 🫶✨

19. IANA Considerations ✨

okay bestie, IANA is the one handing out the official number tags for RSVP stuff 🎀 This part is where the new PROTECTION, PRIMARY_PATH_ROUTE, and ASSOCIATION objects get their registry slots, plus some new error codes and some ADMIN_STATUS bits that need tracking 💅

IANA assigns values to RSVP protocol parameters. Within the current document, a PROTECTION object (new C-Type), a PRIMARY_PATH_ROUTE object, and an ASSOCIATION object are defined. In addition, new Error code/sub-code values are defined in this document. Finally, registration of the ADMIN_STATUS object bits is requested.

Two RSVP Class Numbers (Class-Num) and three Class Types (C-Types) values have to be defined by IANA in registry:

http://www.iana.org/assignments/rsvp-parameters

PROTECTION object (defined in Section 14.1) 🛡️
- PROTECTION object: Class-Num = 37
  - Type 2: C-Type = 2
PRIMARY_PATH_ROUTE object (defined in Section 15.1) 🛣️
- PRIMARY_PATH_ROUTE object: Class-Num = 38 (of the form 0bbbbbbb),
  - Primary Path Route: C-Type = 1
ASSOCIATION object (defined in Section 16.1) 🔗
- ASSOCIATION object: Class-Num = 199 (of the form 11bbbbbb)
  - IPv4 Association: C-Type = 1
  - IPv6 Association: C-Type = 2
- Association Type

The following values defined for the Association Type (16 bits) field of the ASSOCIATION object. 🌸

         Value       Type
         -----       ----
           0         Reserved
           1         Recovery (R)

Assignment of values (from 2 to 65535) by IANA are subject to IETF expert review process, i.e., IETF Standards Track RFC Action. 🦋

Error Code/Sub-code values ⚠️

The following Error code/sub-code values are defined in this document:

Error Code = 01: "Admission Control Failure" (see [RFC2205])
- "Admission Control Failure/LSP Admission Failure" (4)
- "Admission Control Failure/Bad Association Type" (5)
Error Code = 02: "Policy Control Failure" (see [RFC2205])
- "Policy Control failure/Hard Pre-empted" (20)
Error Code = 24: "Routing Problem" (see [RFC3209])
- "Routing Problem/Unsupported LSP Protection" (17)
- "Routing Problem/PROTECTION object not applicable" (18)
- "Routing Problem/Bad PRIMARY_PATH_ROUTE object" (19)
- "Routing Problem/PRIMARY_PATH_ROUTE object not applicable" (20)
Error Code = 25: "Notify Error" (see [RFC3209])
- "Notify Error/LSP Failure" (9)
- "Notify Error/LSP Recovered" (10)
- "Notify Error/LSP Locally Failed" (11)

Registration of the ADMIN_STATUS object bits 🎈

The ADMIN_STATUS object (Class-Num = 196, C-Type = 1) is defined in [RFC3473].

IANA is also requested to track the ADMIN_STATUS bits extended by this document. For this purpose, the following new registry entries have been created:

http://www.iana.org/assignments/gmpls-sig-parameters

ADMIN_STATUS bits:

     Name: ADMIN_STATUS bits
     Format: 32-bit vector of bits
     Position:
        [0]          Reflect (R) bit defined in [RFC3471]
        [1..25]      To be assigned by IANA via IETF Standards
                     Track RFC Action.
        [26]         Lockout (L) bit is defined in Section 13
        [27]         Inhibit alarm communication (I) in [RFC4783]
        [28]         Call control (C) bit is defined in
                     [GMPLS-CALL]
        [29]         Testing (T) bit is defined in [RFC3471]
        [30]         Administratively down (A) bit is defined in
                     [RFC3471]
        [31]         Deletion in progress (D) bit is defined in
                     [RFC3471]

20. Acknowledgments 🫶

The authors would like to thank John Drake for his active collaboration, Adrian Farrel for his contribution to this document (in particular, to the Section 10 and 11) and his thorough review of the document, Bart Rousseau (for editorial review), Dominique Verchere, and Stefaan De Cnodder. Thanks also to Ichiro Inoue for his valuable comments.

The authors would also like to thank Lou Berger for the time and effort he spent together with the design team, in contributing to the present document. 💜

21. References 📚

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

[RFC2747]    Baker, F., Lindell, B., and M. Talwar, "RSVP
             Cryptographic Authentication", RFC 2747, January 2000.

[RFC2961]    Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
             and S. Molendini, "RSVP Refresh Overhead Reduction
             Extensions", RFC 2961, April 2001.

[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., "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Functional Description", RFC 3471,
             January 2003.

[RFC3473]    Berger, L., "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE) Extensions", RFC 3473, January
             2003.

[RFC3477]    Kompella, K. and Y. Rekhter, "Signalling Unnumbered
             Links in Resource ReSerVation Protocol - Traffic
             Engineering (RSVP-TE)", RFC 3477, January 2003.

[RFC3945]    Mannie, E., "Generalized Multi-Protocol Label Switching
             (GMPLS) Architecture", RFC 3945, October 2004.

[RFC4426]    Lang, J., Rajagopalan, B., and D. Papadimitriou,
             "Generalized Multi-Protocol Label Switching (GMPLS)
             Recovery Functional Specification", RFC 4426, March
             2006.

[RFC4873]    Berger, L., Bryskin, I., Papdimitriou, D., and A.
             Farrel, "GMPLS Segment Recovery," RFC 4873, May 2007.

21.2. Informative References

[RFC4783]    Berger, L., "GMPLS - Communication of Alarm
             Information", RFC 4783, December 2006.

[CRANK]      Farrel, A., Ed., "Crankback Signaling Extensions for
             MPLS and GMPLS RSVP-TE",  Work in Progress, January
             2007.

[GMPLS-CALL] Papadimitriou, D., Ed., and A. Farrel, Ed., "Generalized
             MPLS (GMPLS) RSVP-TE Signaling Extensions in support of
             Calls",  Work in Progress, January 2007.

[RFC4090]    Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
             Reroute Extensions to RSVP-TE for LSP Tunnels", RFC
             4090, May 2005.

[RFC4427]    Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
             (Protection and Restoration) Terminology for Generalized
             Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
             2006.

[RFC4874]    Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes
             - Extension to Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE)", RFC 4874, April 2007.

[G.841]      ITU-T, "Types and Characteristics of SDH Network
             Protection Architectures," Recommendation G.841, October
             1998, available from http://www.itu.int.

22. Contributors 🌈

This document is the result of the CCAMP Working Group Protection and Restoration design team joint effort. The following are the authors that contributed to the present document:

Deborah Brungard (AT&T)
Rm. D1-3C22 - 200, S. Laurel Ave.
Middletown, NJ 07748, USA
EMail: dbrungard@att.com

Sudheer Dharanikota
EMail: sudheer@ieee.org

Guangzhi Li (AT&T)
180 Park Avenue
Florham Park, NJ 07932, USA
EMail: gli@research.att.com

Eric Mannie (Perceval)
Rue Tenbosch, 9
1000 Brussels, Belgium
Phone: +32-2-6409194
EMail: eric.mannie@perceval.net

Bala Rajagopalan (Intel Broadband Wireless Division)
2111 NE 25th Ave.
Hillsboro, OR 97124, USA
EMail: bala.rajagopalan@intel.com

Editors' Addresses ✍️

Jonathan P. Lang
Sonos
506 Chapala Street
Santa Barbara, CA 93101, USA

EMail: jplang@ieee.org


Yakov Rekhter
Juniper
1194 N. Mathilda Avenue
Sunnyvale, CA 94089, USA

EMail: yakov@juniper.net


Dimitri Papadimitriou
Alcatel
Copernicuslaan 50
B-2018, Antwerpen, Belgium

EMail: dimitri.papadimitriou@alcatel-lucent.be

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

📦 where this page comes from

ietf: rfc4872 2007-05
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms

RFC 4872

RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery 🎀

Status of This Memo 📋

Copyright Notice ©️

Abstract 🦋

Table of Contents 🗂️

1. Introduction 🌸

2. Conventions Used in This Document ✨

3. Relationship to Fast Reroute (FRR) 🦋

4. Definitions 🌸

4.1. LSP Identification 🧚

4.2. Recovery Attributes 💅

4.2.1. LSP Status 🌈

4.2.2. LSP Recovery 🦋

4.3. LSP Association 🌷

5. 1+1 Unidirectional Protection 💖

5.1. Identifiers 🎀

6. 1+1 Bidirectional Protection ✨

6.1. Identifiers

6.2. End-to-End Switchover Request/Response

7. 1:1 Protection with Extra-Traffic 🌈

7.1. Identifiers

7.2. End-to-End Switchover Request/Response ✨

7.3. 1:N (N > 1) Protection with Extra-Traffic ✨

8. Rerouting without Extra-Traffic 🦋

8.1. Identifiers 🫶

8.2. Signaling Primary LSPs 💅

8.3. Signaling Secondary LSPs 🧚

9. Shared-Mesh Restoration ✨

9.1. Identifiers 🪪

9.2. Signaling Primary LSPs 🚀

9.3. Signaling Secondary LSPs 🧚

10. LSP Preemption 👑

11. (Full) LSP Rerouting 🌈

11.1. Identifiers 🪪

11.2. Signaling Reroutable LSPs 📡

12. Reversion ✨

13. Recovery Commands 🎀

14. PROTECTION Object 💅

14.1. Format

14.2. Processing

15. PRIMARY_PATH_ROUTE Object ✨

15.1. Format

15.2. Subobjects

15.3. Applicability

15.4. Processing 🧚

16. ASSOCIATION Object 💜

16.1. Format 📐

16.2. Processing 🧠

17. Updated RSVP Message Formats 🎀

18. Security Considerations 🔐

19. IANA Considerations ✨

20. Acknowledgments 🫶

21. References 📚

21.1. Normative References

21.2. Informative References

22. Contributors 🌈

Editors' Addresses ✍️

Full Copyright Statement ©️

Intellectual Property 🔐

Acknowledgement 💖