GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7324

Internet Engineering Task Force (IETF) E. Osborne Request for Comments: 7324 July 2014 Updates: 6378 Category: Standards Track ISSN: 2070-1721

        Updates to MPLS Transport Profile Linear Protection

Abstract

 This document contains a number of updates to the Protection State
 Coordination (PSC) logic defined in RFC 6378, "MPLS Transport Profile
 (MPLS-TP) Linear Protection".  These updates provide some rules and
 recommendations around the use of TLVs in PSC, address some issues
 raised in an ITU-T liaison statement, and clarify PSC's behavior in a
 case not well explained in RFC 6378.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7324.

Copyright Notice

 Copyright (c) 2014 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Osborne Standards Track [Page 1] RFC 7324 PSC Updates July 2014

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

 This document contains a number of updates to PSC [RFC6378].  One
 provides some rules and recommendations around the use of TLVs in
 PSC.  Three of the updates address issues #2, #7, and #8 as
 identified in the ITU's liaison statement "Recommendation ITU-T
 G.8131/Y.1382 revision - Linear protection switching for MPLS-TP
 networks" [LIAISON].  Another clears up a behavior that was not well
 explained in RFC 6378.  These updates are not changes to the
 protocol's packet format or to PSC's design; they are corrections and
 clarifications to specific aspects of the protocol's procedures.
 This document does not introduce backward compatibility issues with
 implementations of RFC 6378.
 It should be noted that [RFC7271] contains protocol mechanisms for an
 alternate mode of operating MPLS-TP PSC.  Those modes are built on
 the message structures and procedures of [RFC6378], and so, while
 this document does not update [RFC7271], it has an impact on that
 work through its update to [RFC6378].
 This document assumes familiarity with RFC 6378 and its terms,
 conventions, and acronyms.  Any term used in this document but not
 defined herein can be found in RFC 6378.  In particular, this
 document shares the acronyms defined in Section 2.1 of RFC 6378.

Osborne Standards Track [Page 2] RFC 7324 PSC Updates July 2014

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 covers message formatting as well as some recommended
 error checking.

2.1. PSC TLV Format

 [RFC6378] provides the capability to carry TLVs in the PSC messages.
 All fields are encoded in network byte order.  Each TLV contains
 three fields, as follows:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             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, and 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 contains
 the total length of all TLVs in octets.

Osborne Standards Track [Page 3] RFC 7324 PSC Updates July 2014

2.2. Error Handling

 It is recommended to implement error and bounds checking to ensure
 that received messages, if improperly formatted, are handled in such
 a way to minimize the impact of this formatting on the behavior of
 the network and its devices.  This section covers two such areas --
 malformed messages and well-formed but unexpected TLVs.
 This text is not intended to limit the error or bounds checking a
 device performs.  The recommendations herein should be taken as a
 starting point.

2.2.1. Malformed Messages

 An implementation SHOULD:
 o  Ensure any fields prior to TLV Length are consistent with RFC
    6378, particularly Section 4.2 of that document.
 o  Ensure the overall length of the message matches the value in the
    TLV Length + 12.
 o  Check that the sum of the lengths of all TLVs matches the value in
    the TLV Length.
 If an implementation receives a message that fails any malformed
 message checks, it MUST drop the message and SHOULD alert the
 operator to the malformed message.  The method(s) used to alert the
 operator are outside the scope of this document but may include
 things like syslog or console messages.

2.2.2. Well-Formed but Unknown or Unexpected TLV

 If a message is deemed to be properly formed, an implementation
 SHOULD check all TLVs to ensure that 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 processed as if the ignored TLV did not
 exist.  An implementation detecting a malformed TLV SHOULD alert the
 operator as described in Section 2.2.1.

Osborne Standards Track [Page 4] RFC 7324 PSC Updates July 2014

3. Incorrect Local Status after Failure

 Issue #2 in the liaison statement identifies a case where a strict
 reading of RFC 6378 leaves a node reporting an 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
 address this issue, the fourth bullet in Section 4.3.3.3 of RFC 6378
 is replaced with the following three bullets:
 o  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.
 o  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.
 o  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 does, however, have the ability to signal two
 properties of that domain, via the Protection Type (PT) and Revertive
 (R) bits.  RFC 6378 specifies that if these bits do not match an
 operator "SHALL [be notified]" (PT, Section 4.2.3) or "SHOULD be
 notified" (R, Section 4.2.4).  However, there is no text that
 specifies the behavior of the end nodes of a protection domain in
 case of a mismatch.  This section provides that text, 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 specifies three
 protection types -- bidirectional switching using a permanent bridge,
 bidirectional switching using a selector bridge, and unidirectional
 switching using a permanent bridge.  They are abbreviated here as BP,
 BS, and UP.

Osborne Standards Track [Page 5] RFC 7324 PSC Updates July 2014

 There are three possible mismatches: {BP, UP}, {BP, BS}, and
 {UP, BS}.  The priority is:
 UP > BS > BP
 In other words:
 o  If the PT mismatch is {BP, UP}, the node transmitting BP MUST
    switch to UP mode if it is supported.
 o  If the PT mismatch is {BP, BS}, the node transmitting BP MUST
    switch to BS mode if it is supported.
 o  If the PT mismatch is {UP, BS}, the node transmitting BS MUST
    switch to UP mode if it is supported.
 If a node does not support a mode to which it is required to switch,
 then that node MUST behave as in Section 4.3.

4.2. R Mismatch

 The R bit indicates whether the protection domain is in revertive or
 non-revertive behavior.  If the R bits do not match, the node
 indicating non-revertive MUST switch to Revertive if it is supported.
 If it is not supported, a node must behave as in Section 4.3.

4.3. Unsupported Modes

 An implementation may not support all three PT modes and/or both R
 modes, and thus a pair of nodes may be unable to converge on a common
 mode.  This creates a permanent mismatch, resolvable only by operator
 intervention.  An implementation SHOULD alert the operator to an
 irreconcilable mismatch.
 It is desirable to allow the protection domain to function in a non-
 failure mode even if there is a mismatch, as the mismatches of PT or
 R have to do with how nodes recover from a failure.  An
 implementation SHOULD allow traffic to be sent on the Working LSP as
 long as there is no failure (e.g., NR state) regardless of any PT or
 R mismatch.
 If there is a trigger that would cause the protection LSP to be used,
 such as SF or MS, a node MUST NOT use the protection LSP to carry
 traffic.

Osborne Standards Track [Page 6] RFC 7324 PSC Updates July 2014

5. Reversion Deadlock Due to a Race Condition

 Issue #8 in the liaison statement identifies a deadlock case where
 each node can end up sending NR(0,1) when it should instead be in the
 process of recovering from the failure (i.e., entering into WTR or
 DNR, as appropriate for the protection domain).  The root of the
 issue is that a pair of nodes can simultaneously enter WTR state,
 receive an out-of-date SF-W indication, transition into a remotely
 triggered WTR, and remain in remotely triggered WTR waiting for the
 other end to trigger a change in status.
 In the case identified in issue #8, each node can end up sending
 NR(0,1), which is an indication that the transmitting node has no
 local failure, but is instead reacting to the remote SF-W.  If a node
 that receives NR(0,1) is in fact not indicating a local error, the
 correct behavior for the receiving node is to take the received
 NR(0,1) as an indication that there is no error in the protection
 domain, and recovery procedures (WTR or DNR) should begin.
 This is addressed by adding the following text as the penultimate
 bullet in Section 4.3.3.4 of RFC 6378:
 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.
 Additionally, the penultimate bullet in Section 4.3.3.3 is changed
 from
 o  A remote NR(0,0) message SHALL be ignored if in local Protecting
    administrative state.
 to
 o  A remote No Request message SHALL be ignored if in local
    Protecting administrative state.
 This indicates that a remote NR triggers the same behavior regardless
 of the value of FPath and Path.  This change does not directly
 address issue #8, but it fixes a similar issue -- if a node receives
 NR while in Remote administrative state, the value of FPath and Path
 have no bearing on the node's reaction to this NR.

Osborne Standards Track [Page 7] RFC 7324 PSC Updates July 2014

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

 RFC 6378 describes the PSC state machine.  Figure 1 in Section 3 of
 RFC 6378 shows two inputs into the PSC Control logic -- Local Request
 logic and Remote PSC Request.  When there is only one input into the
 PSC Control logic -- a local request or a remote request but not both
 -- the PSC Control logic decides what that input signifies and then
 takes one or more actions, as necessary.  This is what the PSC State
 Machine in Section 4.3 of RFC 6378 describes.
 RFC 6378 does not sufficiently describe the behavior in the face of
 multiple inputs into the PSC Control Logic (one Local Request and one
 Remote Request).  This section clarifies the expected behavior.
 There are two cases to think about when considering dual inputs into
 the PSC Control logic.  The first is when the same request is
 presented from both local and remote sources.  One example of this
 case is a Forced Switch (FS) configured on both ends of an LSP.  This
 will result in the PSC Control logic receiving both a local FS and
 remove FS.  For convenience, this scenario is written as [L(FS),
 R(FS)] -- that is, Local(Forced Switch) and Remote(Forced Switch).
 The second case, which is handled in exactly the same way as the
 first, is when the two inputs into the PSC Control logic describe
 different events.  There are a number of variations on this case.
 One example is when there is a Lockout of Protection from the Local
 request logic and a Signal Fail on the Working path from the Remote
 PSC Request.  This is shortened to [L(LO), R(SF-W)].
 In both cases, the question is not how the PSC Control logic decides
 which of these is the one it acts upon.  Section 4.3.2 of RFC 6378
 lists the priority order and prioritizes the local input over the
 remote input in case both inputs are of the same priority.  So, in
 the first example it is the local SF that drives the PSC Control
 logic, and in the second example it is the local Lockout that drives
 the PSC Control logic.
 The point that this section clears up is around what happens when the
 highest-priority input goes away.  Consider the first case.
 Initially, the PSC Control logic has [L(FS), R(FS)], and L(FS) is
 driving PSC's behavior.  When L(FS) is removed, but R(FS) remains,
 what does PSC do?  A strict reading of the Finite State Machine (FSM)
 would suggest that PSC transition from PA:F:L into N, and at some
 future time (perhaps after the remote request refreshes), PSC would
 transition from N to PA:F:R.  This is an unreasonable behavior, as
 there is no sensible justification for a node behaving as if things
 were normal (i.e., N state) when it is clear that they are not.

Osborne Standards Track [Page 8] RFC 7324 PSC Updates July 2014

 The second case is similar.  If a node starts with [L(LO), R(SF-W)]
 and the local lockout is removed, a strict reading of the state
 machine would suggest that the node transition from UA:LO:L to N, and
 then at some future time presumably notice the R(SF-W) and transition
 from N to PF:W:R.  As with the first case, this is clearly not a
 useful behavior.
 In both cases, the request that was driving PSC's behavior was
 removed.  What should happen is that the PSC Control logic should,
 upon removal of an input, immediately reevaluate all other inputs to
 decide on the next course of action.  This requires an implementation
 to store the most recent local and remote inputs regardless of their
 eventual use as triggers for the PSC Control Logic.
 There is also a third case.  Consider a node with [L(FS), R(LO)].  At
 some point in time, the remote node replaces its Lockout request with
 a Signal Fail on Working, so that the inputs into the PSC Control
 logic on the receiving node go to [L(FS), R(SF-W)].  Similar to the
 first two cases, the node should immediately reevaluate both its
 local and remote inputs to determine the highest priority among them
 and act on that input accordingly.  That is in fact what happens, as
 defined in Section 4.3.3 of RFC 6378:
    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 handle the first two cases.
 The essence of the quoted paragraph is that when faced with multiple
 inputs, PSC must reevaluate any changes as if it were in Normal
 state.  So, the quoted paragraph is replaced with the following 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.

Osborne Standards Track [Page 9] RFC 7324 PSC Updates July 2014

7. Security Considerations

 These changes and clarifications raise no new security concerns.  RFC
 6941 [RFC6941] provides the baseline security discussion for MPLS-TP,
 and PSC (as described in both RFC 6378 and this document) falls under
 that umbrella.  Additionally, Section 2.2 clarifies how to react to
 malformed or unexpected messages.

8. IANA Considerations

 IANA has marked the value 0 in the "MPLS PSC TLV Registry" as
 "Reserved, not to be allocated" and updated the references to show
 [RFC6378] and this document (RFC 7324).  Note that this document
 provides documentation of an action already taken by IANA but not
 recorded in RFC 6378.

9. Acknowledgements

 The author of this document 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.

Osborne Standards Track [Page 10] RFC 7324 PSC Updates July 2014

 [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

Osborne Standards Track [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7324.txt · Last modified: 2014/07/29 22:11 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki