RFC 7324

Updates to MPLS Transport Profile Linear Protection

📅 published July 2014, from ietf

RFC 7324: Updates to MPLS Transport Profile Linear Protection 🦋✨

Who wrote it: E. Osborne 💅 When: July 2014 📅 Category: Standards Track 🎀 Updates: RFC 6378 🔥 (it doesn't obsolete anything) ISSN: 2070-1721 🌸

This is a Standards Track document from the IETF, so it's officially part of the Internet's rulebook, not just a suggestion. 👑

Abstract

okay so this doc is a bunch of updates to the Protection State Coordination (PSC) logic in RFC 6378, which is "MPLS Transport Profile (MPLS-TP) Linear Protection" 💖. The updates add some rules and recommendations for using TLVs in PSC, deal with a few problems that came up in an ITU-T liaison statement, and clear up how PSC behaves in one case that RFC 6378 didn't explain super well 🧚.

Status of This Memo

this is an Internet Standards Track document 🔥.

it's a product of the Internet Engineering Task Force (IETF) 🌈. it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication ✨. if you want more about Internet Standards, check Section 2 of RFC 5741 📚.

info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc7324 🦋.

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date 🫶. read them carefully, because they explain your rights and restrictions. code components pulled from this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says 💅.

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
2.  Message Formatting and Error Handling . . . . . . . . . . . .   3
  2.1.  PSC TLV Format  . . . . . . . . . . . . . . . . . . . . .   3
  2.2.  Error Handling  . . . . . . . . . . . . . . . . . . . . .   4
    2.2.1.  Malformed Messages  . . . . . . . . . . . . . . . . .   4
    2.2.2.  Well-Formed but Unknown or Unexpected TLV . . . . . .   4
3.  Incorrect Local Status after Failure  . . . . . . . . . . . .   5
4.  Handling a Capabilities Mismatch  . . . . . . . . . . . . . .   5
  4.1.  Protection Type Mismatch  . . . . . . . . . . . . . . . .   5
  4.2.  R Mismatch  . . . . . . . . . . . . . . . . . . . . . . .   6
  4.3.  Unsupported Modes . . . . . . . . . . . . . . . . . . . .   6
5.  Reversion Deadlock Due to a Race Condition  . . . . . . . . .   7
6.  Clarifying PSC's Behavior in the Face of Multiple Inputs  . .   8
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
  10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
  10.2.  Informative References . . . . . . . . . . . . . . . . .  10

1. Introduction ✨

okay so this doc has a bunch of updates to PSC [RFC6378] 💖. one of them adds rules and recommendations for using TLVs in PSC. three of them fix issues #2, #7, and #8 from the ITU's liaison statement "Recommendation ITU-T G.8131/Y.1382 revision - Linear protection switching for MPLS-TP networks" [LIAISON] 🔥. the last one clears up a behavior that RFC 6378 didn't explain well 🙈.

none of these change the packet format or PSC's design. they're corrections and clarifications to how the protocol's procedures work, so it's giving "tidy-up" energy 🧹. this doc also doesn't create backward compatibility issues for implementations of RFC 6378 🫶.

it's worth knowing that [RFC7271] has protocol mechanisms for an alternate mode of operating MPLS-TP PSC 🦋. those modes are built on the message structures and procedures of [RFC6378]. so even though this doc doesn't update [RFC7271], it still affects that work because it updates [RFC6378] 💅.

this doc assumes you already know RFC 6378 and its terms, conventions, and acronyms 📚. anything used here but not defined is defined in RFC 6378. specifically, this doc shares the acronyms from Section 2.1 of RFC 6378 🌈.

1.1. Requirements Language

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

2. Message Formatting and Error Handling 💜

this section is about message formatting and some recommended error checking 🧚.

2.1. PSC TLV Format

[RFC6378] lets you carry TLVs in PSC messages 🍓. all fields are encoded in network byte order. each TLV has three fields, shown below 👑:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Value                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type field (T):

a two-octet field that encodes a type value 🌸. the type values are recorded in the IANA registry "MPLS PSC TLV Registry" 📚.

Length field (L):

a two-octet field that encodes the length in octets of the Value field. the value of this field MUST be a multiple of 4 💖.

Value field (V):

the payload of the TLV 🎁. the length of this field (which is the value of the Length field) MUST be a multiple of 4 octets, so this field may contain explicit padding 🫶. the length of each single TLV is the sum of the lengths of its three fields: the length of the value field + 4 ✨. the overall TLV Length field in the PSC message holds the total length of all TLVs in octets 💅.

2.2. Error Handling

it is recommended to implement error and bounds checking, so that received messages that are improperly formatted get handled in a way that keeps their impact on the network and its devices as small as possible 🛡️. this section covers two areas: malformed messages, and well-formed but unexpected TLVs 🦋.

this text doesn't limit the error or bounds checking a device does 🙈. treat the recommendations here as a starting point, not the finish line ✨.

2.2.1. Malformed Messages

An implementation SHOULD:

  • Ensure any fields prior to TLV Length are consistent with RFC 6378, particularly Section 4.2 of that document 🔍.
  • Ensure the overall length of the message matches the value in the TLV Length + 12 📏.
  • Check that the sum of the lengths of all TLVs matches the value in the TLV Length 🧮.

If an implementation gets a message that fails any malformed message checks, it MUST drop the message and SHOULD alert the operator to the malformed message 🚨. the methods for alerting the operator are outside the scope of this document, but they might include things like syslog or console messages 💀.

2.2.2. Well-Formed but Unknown or Unexpected TLV

if a message is deemed properly formed, an implementation SHOULD check all TLVs to make sure it knows what to do with them 👀. a well-formed but unknown or unexpected TLV value MUST be ignored, and the rest of the message gets processed as if the ignored TLV didn't exist 🫧. an implementation that detects a malformed TLV SHOULD alert the operator as described in Section 2.2.1 🔥.

3. Incorrect Local Status after Failure 🙈

issue #2 in the liaison statement points out a case where a strict reading of RFC 6378 leaves a node reporting inaccurate status 😭:

A node can end up sending incorrect status -- NR(0,1) -- despite the failure of the protection LSP (P-LSP). This is clearly not correct, as a node should not be sending NR if it has a local failure.

to fix this, the fourth bullet in Section 4.3.3.3 of RFC 6378 gets replaced with the following three bullets 🔧:

  • If the current state is due to a local or remote Manual Switch, a local Signal Fail indication on the protection path SHALL cause the LER to enter local Unavailable state and begin transmission of an SF(0,0) message 🧯.
  • If the LER is in local Protecting Administrative state due to a local Forced Switch, a local Signal Fail indication on the protection path SHALL be ignored 🙅‍♀️.
  • If the LER is in remote Protecting Administrative state due to a remote Forced Switch, a local Signal Fail indication on the protection path SHALL cause the LER to remain in remote Protecting administrative state and transmit an SF(0,1) message 🫶.

4. Handling a Capabilities Mismatch 🎀

PSC has no explicit facility to negotiate any properties of the protection domain 🙃. it can, however, signal two properties of that domain using the Protection Type (PT) and Revertive (R) bits 💖. RFC 6378 says that if these bits don't match, an operator "SHALL [be notified]" (PT, Section 4.2.3) or "SHOULD be notified" (R, Section 4.2.4) 📣. the problem is that there's no text saying how the end nodes of a protection domain should behave when there's a mismatch 😬. this section fixes that, as requested by issue #7 in the liaison statement ✨.

4.1. Protection Type Mismatch

the behavior of the protection domain depends on the exact Protection Type (PT) mismatch 🧩. Section 4.2.3 of RFC 6378 defines three protection types: bidirectional switching using a permanent bridge, bidirectional switching using a selector bridge, and unidirectional switching using a permanent bridge 🌉. here they're abbreviated as BP, BS, and UP 🏷️.

there are three possible mismatches: {BP, UP}, {BP, BS}, and {UP, BS} 🔢. the priority is:

UP > BS > BP

in other words:

  • If the PT mismatch is {BP, UP}, the node transmitting BP MUST switch to UP mode if it is supported 🔁.
  • If the PT mismatch is {BP, BS}, the node transmitting BP MUST switch to BS mode if it is supported 🔁.
  • If the PT mismatch is {UP, BS}, the node transmitting BS MUST switch to UP mode if it is supported 🔁.

if a node doesn't support a mode it's required to switch to, then that node MUST behave as in Section 4.3 💀.

4.2. R Mismatch

the R bit tells you whether the protection domain is revertive or non-revertive 🔄. if the R bits don't match, the node indicating non-revertive MUST switch to Revertive if it's supported 🫶. if it isn't supported, a node must behave as in Section 4.3 🙈.

to be continued... ✨🦋 part 2 is coming, bestie 💖

4.3. Unsupported Modes 🌸

okay so not every implementation supports all three PT modes or both R modes 😬 which means two nodes might literally never find a mode they both like. that's a permanent mismatch, and only a human operator can fix it 🙈 an implementation SHOULD alert the operator when that happens, bestie 🚨

it's still good to let the protection domain keep working when there's a mismatch, because PT and R are about how nodes recover from a failure ✨ so an implementation SHOULD still send traffic on the Working LSP whenever there's no failure (like NR state), even if PT or R don't match 💖

the one hard rule: if something is triggering protection (like SF or MS), a node MUST NOT use the protection LSP to carry traffic. no exceptions, periodt 💅

5. Reversion Deadlock Due to a Race Condition 💀

this one is giving main character drama 😭 issue #8 in the liaison statement describes a deadlock where each node keeps sending NR(0,1) when it should actually be recovering from the failure (entering WTR or DNR, depending on the protection domain) 🔁

here's how it happens: both nodes enter WTR at the same time, then each gets an out-of-date SF-W, flips into a remotely triggered WTR, and just sits there waiting for the other end to change its status. nobody moves, lol 🫠

so in issue #8, each node sends NR(0,1), which means "I have no local failure, I'm just reacting to the remote SF-W." if a node gets NR(0,1) and it's not actually reporting a local error, the right move is to treat that NR(0,1) as "there's no error in the protection domain" and start recovery (WTR or DNR) ✨

the fix is a new bullet added as the penultimate bullet in Section 4.3.3.4 of RFC 6378. here's the exact text:

o  If a node is in Protecting Failure state due to a remote SF-W and
   receives NR(0,1), this SHALL cause the node to begin recovery
   procedures.  If the LER is configured for revertive behavior, it
   enters into Wait-to-Restore state, starts the WTR timer, and
   begins transmitting WTR(0,1).  If the LER is configured for non-
   revertive behavior, it enters into Do-Not-Revert state and begins
   transmitting a DNR(0,1) message.

there's also a little tweak to the penultimate bullet in Section 4.3.3.3, going from this:

o  A remote NR(0,0) message SHALL be ignored if in local Protecting
   administrative state.

to this:

o  A remote No Request message SHALL be ignored if in local
   Protecting administrative state.
this means a remote NR now does the same thing no matter what FPath and Path are set to 👀 the change doesn't directly fix issue #8, but it kills a similar bug. if a node gets NR while in Remote administrative state, FPath and Path shouldn't change how it reacts, and now they don't 🎀

6. Clarifying PSC's Behavior in the Face of Multiple Inputs ✨🦋

okay so RFC 6378 explains the PSC state machine, right? Figure 1 in Section 3 of RFC 6378 shows two inputs going into the PSC Control logic: Local Request logic and Remote PSC Request 🧠 when there's only one input (just a local request OR just a remote request), the PSC Control logic figures out what it means and takes whatever actions are needed. that's the PSC State Machine in Section 4.3 of RFC 6378, and it's clear enough 💖

the problem is multiple inputs (one Local Request AND one Remote Request). RFC 6378 doesn't really explain that, so this section fills in the gaps 🫶

there are two cases to think about. case one is when the same request shows up from both ends, like a Forced Switch (FS) configured on both ends of an LSP. the PSC Control logic gets a local FS and a remote FS, which we write as [L(FS), R(FS)] (Local(Forced Switch) and Remote(Forced Switch)) 🔥

case two is handled exactly the same way, but the two inputs describe different events. for example, a Lockout of Protection from the local side plus a Signal Fail on the Working path from the remote side. shortened: [L(LO), R(SF-W)] ⭐

in both cases, the question isn't how PSC picks which input to act on. Section 4.3.2 of RFC 6378 has the priority order, and if two inputs have the same priority, the local one wins 🏆 so in the first example the local SF drives things, and in the second example the local Lockout drives things.

the real question is what happens when the highest-priority input disappears 😳

take case one. PSC starts with [L(FS), R(FS)], and L(FS) is running the show. then L(FS) goes away but R(FS) is still there. what does PSC do? a strict reading of the FSM would send it from PA:F:L into N, and then later (maybe after the remote request refreshes) from N into PA:F:R. that's unreasonable 🙃 why would a node act like everything is normal when it's obviously not?

case two is the same vibe. starting with [L(LO), R(SF-W)], if the local lockout gets removed, a strict reading would move the node from UA:LO:L to N, then eventually notice R(SF-W) and go from N to PF:W:R. again, not useful at all 💀

so in both cases the request that was driving PSC got removed. what should happen is that when an input is removed, PSC immediately re-checks all the other inputs and decides what to do next. to do this, an implementation has to store the most recent local and remote inputs, even the ones that aren't currently triggering anything 🧚

there's also a third case. say a node has [L(FS), R(LO)], and then the remote node swaps its Lockout for a Signal Fail on Working, so the inputs become [L(FS), R(SF-W)]. same deal as before: the node should immediately re-check both local and remote inputs, find the highest priority, and act on it. and that's actually what Section 4.3.3 of RFC 6378 already says:

When a LER is in a remote state, i.e., state transition in
reaction to a PSC message received from the far-end LER, and
receives a new PSC message from the far-end LER that indicates a
contradictory state, e.g., in remote Unavailable state receiving a
remote FS(1,1) message, then the PSC Control logic SHALL
reevaluate all inputs (both the local input and the remote
message) as if the LER is in the Normal state.

this section extends that paragraph to cover the first two cases too. the big idea is that with multiple inputs, PSC has to re-evaluate things as if it were in Normal state. so the quoted paragraph gets replaced with this text:

The PSC Control logic may simultaneously have Local and Remote
requests, and the highest priority of these requests ultimately
drives the behavior of the PSC Control logic.  When this highest-
priority request is removed or is replaced with another input,
then the PSC Control logic SHALL immediately reevaluate all inputs
(both the local input and the remote message), transitioning into
a new state only upon reevaluation of all inputs.

7. Security Considerations 🔐

these changes and clarifications don't add any new security concerns, no cap 🙌 RFC 6941 [RFC6941] is the baseline security discussion for MPLS-TP, and PSC (both as described in RFC 6378 and in this document) lives under that umbrella. also, Section 2.2 explains how to react to malformed or unexpected messages, so go read that one, it's important 🛡️

8. IANA Considerations 📋

IANA marked the value 0 in the "MPLS PSC TLV Registry" as "Reserved, not to be allocated" and updated the references to point to [RFC6378] and this document (RFC 7324) 🎀 this document just writes down an action IANA already took, which RFC 6378 never recorded, so now it's on the record ✨

9. Acknowledgements 🫶

the author thanks Taesik Cheung, Alessandro D'Alessandro, Annamaria Fulignoli, Sagar Soni, George Swallow, and Yaacov Weingarten for their contributions and review 💜 and Adrian Farrel for the text of Section 2 🌷

10. References 📚

10.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011.

10.2. Informative References

  • [LIAISON] ITU-T SG15, "Liaison Statement: Recommendation ITU-T G.8131/Y.1382 revision - Linear protection switching for MPLS-TP networks", <https://datatracker.ietf.org/liaison/1205/>.
  • [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. Graveman, "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, April 2013.
  • [RFC7271] Ryoo, J., Gray, E., van Helvoort, H., D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators", RFC 7271, June 2014.

Author's Address 💌

Eric Osborne

EMail: eric.osborne@notcom.com 🦋

📦 where this page comes from