summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8237.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8237.txt')
-rw-r--r--doc/rfc/rfc8237.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc8237.txt b/doc/rfc/rfc8237.txt
new file mode 100644
index 0000000..d7f3e31
--- /dev/null
+++ b/doc/rfc/rfc8237.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) L. Martini
+Request for Comments: 8237 Monoski LLC
+Category: Standards Track G. Swallow
+ISSN: 2070-1721 SETC
+ E. Bellagamba
+ Ericsson
+ October 2017
+
+
+ MPLS Label Switched Path (LSP) Pseudowire (PW)
+ Status Refresh Reduction for Static PWs
+
+Abstract
+
+ This document describes a method for generating an aggregated
+ pseudowire (PW) status message transmitted for a statically
+ configured PW on a Multiprotocol Label Switching (MPLS) Label
+ Switched Path (LSP) to indicate the status of one or more PWs carried
+ on the LSP.
+
+ The method for transmitting the PW status information is not new;
+ however, this protocol extension allows a Service Provider (SP) to
+ reliably monitor the individual PW status while not overwhelming the
+ network with multiple periodic status messages. This is achieved by
+ sending a single cumulative summary status verification message for
+ all the PWs grouped in the same LSP.
+
+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 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8237.
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 1]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+Copyright Notice
+
+ Copyright (c) 2017 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
+ (https://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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 2]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Requirements Language ......................................4
+ 1.2. Terminology ................................................4
+ 1.3. Notational Conventions .....................................5
+ 2. PW Status Refresh Reduction Protocol ............................5
+ 2.1. Protocol States ............................................5
+ 2.1.1. INACTIVE ............................................5
+ 2.1.2. STARTUP .............................................6
+ 2.1.3. ACTIVE ..............................................6
+ 2.2. Timer Value Change Transition Procedure ....................6
+ 3. PW Status Refresh Reduction Procedure ...........................7
+ 4. PW Status Refresh Reduction Message Encoding ....................8
+ 5. PW Status Refresh Reduction Control Messages ...................11
+ 5.1. Notification Message ......................................12
+ 5.2. PW Configuration Message ..................................12
+ 5.2.1. MPLS-TP Tunnel ID ..................................13
+ 5.2.2. PW ID Configured List ..............................14
+ 5.2.3. PW ID Unconfigured List ............................15
+ 6. PW Provisioning Verification Procedure .........................15
+ 6.1. PW ID List Advertising and Processing .....................16
+ 7. Security Considerations ........................................16
+ 8. IANA Considerations ............................................17
+ 8.1. PW Status Refresh Reduction Message Types .................17
+ 8.2. PW Configuration Message Sub-TLVs .........................17
+ 8.3. PW Status Refresh Reduction Notification Codes ............18
+ 8.4. PW Status Refresh Reduction Message Flags .................18
+ 8.5. G-ACh Registry Allocation .................................19
+ 8.6. Guidance for Designated Experts ...........................19
+ 9. References .....................................................19
+ 9.1. Normative References ......................................19
+ 9.2. Informative References ....................................20
+ Authors' Addresses ................................................20
+
+1. Introduction
+
+ When PWs use a Multiprotocol Label Switching (MPLS) network as the
+ Packet Switched Network (PSN), they are set up using static label
+ assignment per Section 4 of [RFC8077], and the PW status information
+ is propagated using the method described in [RFC6478]. There are two
+ basic modes of operation described in [RFC6478], Section 5.3:
+ (1) periodic retransmission of non-zero status messages and (2) a
+ simple acknowledgment of PW status (Section 5.3.1 of [RFC6478]). The
+ LSP-level protocol described below applies to the case when
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 3]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+ PW status is acknowledged immediately with a requested refresh value
+ of zero (no refresh). In this case, the PW status refresh reduction
+ protocol is necessary for several reasons, such as the following:
+
+ i. The PW status refresh reduction protocol greatly increases the
+ scalability of the PW status protocol by reducing the amount of
+ messages that a Provider Edge (PE) needs to periodically send to
+ its neighbors.
+
+ ii. The PW status refresh reduction protocol will detect a remote PE
+ restart.
+
+ iii. If the local state is lost for some reason, the PE needs to be
+ able to request a status refresh reduction from the remote PE.
+
+ iv. The PW status refresh reduction protocol can optionally detect a
+ remote PE provisioning change.
+
+1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+1.2. Terminology
+
+ FEC: Forwarding Equivalence Class
+
+ LDP: Label Distribution Protocol
+
+ LSP: Label Switched Path
+
+ MS-PW: Multi-Segment Pseudowire
+
+ PE: Provider Edge
+
+ PW: Pseudowire
+
+ S-PE: Switching Provider Edge Node of MS-PW
+
+ SS-PW: Single-Segment Pseudowire
+
+ T-PE: Terminating Provider Edge Node of MS-PW
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 4]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+1.3. Notational Conventions
+
+ All multiple-word atomic identifiers use underscores ("_") between
+ the words to join the words. Many of the identifiers are composed of
+ a concatenation of other identifiers. These are expressed using
+ double-colon ("::") notation.
+
+ Where the same identifier type is used multiple times in a
+ concatenation, they are qualified by a prefix joined to the
+ identifier by a dash ("-"). For example, Src-Node_ID is the Node_ID
+ of a node referred to as "Src" ("Src" is short for "source").
+
+ The notation does not define an implicit ordering of the information
+ elements involved in a concatenated identifier.
+
+2. PW Status Refresh Reduction Protocol
+
+ The PW status refresh reduction protocol consists of a simple message
+ that is sent at the LSP level, using the MPLS Generic Associated
+ Channel (G-ACh) [RFC5586].
+
+ For a particular LSP where the PW status refresh reduction protocol
+ is enabled, a PE using this protocol MUST send the PW status refresh
+ reduction Message as soon as a PW is configured on that LSP. The
+ message is then retransmitted at a locally configured interval
+ indicated in the Refresh Timer field. If no acknowledgment is
+ received, the protocol does not reach the ACTIVE state
+ (Section 2.1.3), and the PE SHOULD NOT send any PW status messages
+ with a Refresh Timer of zero as described in [RFC6478],
+ Section 5.3.1.
+
+ It is worth noting that no relationship exists between the locally
+ configured timer for the PW status refresh reduction protocol and the
+ individual PW status Refresh Timers.
+
+2.1. Protocol States
+
+ The protocol can be in three possible states: INACTIVE, STARTUP, and
+ ACTIVE.
+
+2.1.1. INACTIVE
+
+ This state is entered when the protocol is turned off. This state is
+ also entered if all PWs on a specific LSP are deprovisioned.
+
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 5]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+2.1.2. STARTUP
+
+ In this state, the PE transmits periodic PW status refresh reduction
+ Messages with the Ack Session ID (Section 4) set to 0. The PE
+ remains in this state until a PW status refresh message is received
+ with the correct local Session ID in the Ack Session ID field. State
+ can transition from the STARTUP state to the ACTIVE or INACTIVE
+ state.
+
+2.1.3. ACTIVE
+
+ This state is entered once the PE receives a PW status refresh
+ reduction Message with the correct local Session ID in the Ack
+ Session ID field within 3.5 times the Refresh Timer field value of
+ the last PW status refresh reduction Message transmitted. This state
+ is immediately exited in the following scenarios:
+
+ i. A valid PW status refresh reduction Message is not received
+ within 3.5 times the current Refresh Timer field value (assuming
+ that a timer transition procedure is not in progress).
+ New state: STARTUP.
+
+ ii. A PW status refresh reduction Message is received with the wrong
+ Ack Session ID field value or a zero Ack Session ID field value.
+ New state: STARTUP.
+
+ iii. All PWs using the particular LSP are deprovisioned, or the
+ protocol is disabled.
+ New state: INACTIVE.
+
+2.2. Timer Value Change Transition Procedure
+
+ If a PE needs to change the value of the Refresh Timer field while
+ the PW status refresh reduction protocol is in the ACTIVE state, the
+ following procedure must be followed:
+
+ i. A PW status refresh reduction Message is transmitted with the
+ new timer value.
+
+ ii. If the new value is greater than the original one, the PE will
+ operate according to the new timer value immediately.
+
+
+
+
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 6]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+ iii. If the new value is smaller than the original one, the PE will
+ operate according to the original timer value for a period
+ 3.5 times the original timer value or until the first valid PW
+ status refresh reduction Message is received.
+
+ A PE receiving a PW status refresh reduction Message with a new
+ timer value will immediately acknowledge the new value via a PW
+ status refresh reduction Message and will start operating
+ according to the new timer value.
+
+3. PW Status Refresh Reduction Procedure
+
+ When the PW status refresh reduction protocol on a particular LSP is
+ in the ACTIVE state, the PE can send all PW status messages, for PWs
+ on that LSP, with a Refresh Timer value of zero. This greatly
+ decreases the amount of messages that the PE needs to transmit to the
+ remote PE because once the PW status message for a particular PW is
+ acknowledged, further repetitions of that message are no longer
+ necessary.
+
+ To further reduce the amount of possible messages when an LSP starts
+ forwarding traffic, care should be taken to permit the PW status
+ refresh reduction protocol to reach the ACTIVE state quickly, and
+ before the first PW status Refresh Timer expires. This can be
+ achieved by using a PW status refresh reduction Message Refresh Timer
+ value that is much smaller than the PW status message Refresh Timer
+ value in use (Section 5.3.1 of [RFC6478]).
+
+ If the PW status refresh reduction protocol session is terminated by
+ entering the INACTIVE state or the STARTUP state, the PE MUST
+ immediately resend all the previously sent PW status messages for
+ that particular LSP for which the session was terminated. In this
+ case, the Refresh Timer value MUST NOT be set to 0 and MUST be set
+ according to the local policy of the PE router. Implementations MUST
+ take care to avoid flooding the remote PE with a large number of PW
+ status messages at once. If the PW status refresh reduction protocol
+ session is terminated for administrative reasons and the local PE can
+ still communicate with the remote PE, the local PE SHOULD pace the
+ transmission of PW status messages to the remote PE.
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 7]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+4. PW Status Refresh Reduction Message Encoding
+
+ The packet containing the PW status refresh reduction Message is
+ encoded as follows (omitting link-layer information):
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MPLS LSP (tunnel) Label Stack Entry |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | GAL |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 1|Version| Reserved | 0x29 PW OAM Message |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Session ID | Ack Session ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Refresh Timer | Total Message Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Checksum | Message Sequence Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Last Received Sequence Number | Message Type |U|C| Flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ ~ Control Message Body ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ This message contains the following fields:
+
+ * MPLS LSP (tunnel) Label Stack Entry
+
+ The label stack is explained in [RFC3031].
+
+ * GAL
+
+ The G-ACh Label (GAL) and the next 4 octets (including the PW
+ OAM Message field as the Channel Type) are explained in
+ Section 2.1 of [RFC5586].
+
+ * PW OAM Message
+
+ This field indicates the Channel Type in the G-ACh header, as
+ described in Section 2.1 of [RFC5586].
+
+
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 8]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+ * Session ID
+
+ A non-zero locally selected session number that is not
+ preserved if the local PE restarts.
+
+ In order to get a locally unique Session ID, the recommended
+ choice is to perform a CRC-16 ("CRC" stands for "Cyclic
+ Redundancy Check"), giving as input the following data:
+
+ |YY|MM|DD|HHMMSSLLL|
+
+ Where:
+ YY = the last two decimal digits of the current year
+ MM = the two decimal digits of the current month
+ DD = the two decimal digits of the current day
+ HHMMSSLLL = the decimal digits of the current time,
+ expressed in hours (HH), minutes (MM), seconds (SS), and
+ milliseconds (LLL)
+
+ If the calculation results in an already-existing Session ID, a
+ unique Session ID can be generated by adding 1 to the result
+ until the Session ID is unique. Any other method to generate a
+ locally unique Session ID is also acceptable.
+
+ * Ack Session ID
+
+ The Acknowledgment Session ID received from the remote PE.
+
+ * Refresh Timer
+
+ A non-zero unsigned 16-bit integer value greater than or equal
+ to 10, expressed in milliseconds, that indicates the desired
+ refresh interval. The default value of 30000 is RECOMMENDED.
+
+ * Total Message Length
+
+ Total length in octets of the Checksum, Message Type, Flags,
+ Message Sequence Number, and Control Message Body. A value of
+ zero means that no control message is present and, therefore,
+ that no Checksum or subsequent fields are present either.
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 9]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+ * Checksum
+
+ A 16-bit field containing the one's complement of the one's
+ complement sum of the entire message (including the G-ACh
+ header), with the Checksum field replaced by zero for the
+ purpose of computing the checksum. An all-zero value means
+ that no checksum was transmitted. Note that when the checksum
+ is not computed, the header of the bundle message will not be
+ covered by any checksum.
+
+ * Message Sequence Number
+
+ An unsigned 16-bit integer that is started from 1 when the
+ protocol enters the ACTIVE state. The sequence number wraps
+ back to 1 when the maximum value is reached. The value 0 is
+ reserved and MUST NOT be used.
+
+ * Last Received Message Sequence Number
+
+ The sequence number of the last message received. If no
+ message has yet been received during this session, this field
+ is set to 0.
+
+ * Message Type
+
+ The type of control message that follows. Control message
+ types are allocated in this document and by IANA.
+
+ * (U) Unknown flag bit
+
+ Upon receipt of an unknown message or TLV, if U is clear (0),
+ a notification message with code "Unknown TLV (U-Bit=0)"
+ (code 0x4) MUST be sent to the remote PE, and the keepalive
+ session MUST be terminated by entering the STARTUP state; if
+ U is set (1), the unknown message, or message containing an
+ unknown TLV, MUST be acknowledged and silently ignored, and the
+ following messages, or TLVs, if any, processed as if the
+ unknown message or TLV did not exist. In this case, the PE MAY
+ send back a single notification message per keepalive session
+ with code "Unknown TLV (U-Bit=1)". This last step is OPTIONAL.
+
+ * (C) Configuration flag bit
+
+ The C-Bit is used to signal the end of PW configuration
+ transmission. If it is set, the sending PE has finished
+ sending all of its current configuration information.
+
+
+
+
+
+Martini, et al. Standards Track [Page 10]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+ * Flags
+
+ The remaining 6 bits of PW status refresh reduction Message
+ Flags to be allocated by IANA. These unallocated bits MUST be
+ set to 0 on transmission and ignored on reception.
+
+ * Control Message Body
+
+ The Control Message Body is defined in Section 5 and is
+ specific to the type of message.
+
+ It should be noted that the Checksum, Message Sequence Number, Last
+ Received Message Sequence Number, Message Type, Flags, and Control
+ Message Body are OPTIONAL. The Total Message Length field is used to
+ parse how many optional fields are included. Hence, all optional
+ fields that precede a specific field that needs to be included in a
+ specific implementation MUST be included if that optional field is
+ also included.
+
+ If any of the above values are outside the specified range, a
+ notification message is returned with code "PW configuration not
+ supported", and the message is ignored.
+
+5. PW Status Refresh Reduction Control Messages
+
+ PW status refresh reduction Control Messages consist of the Checksum,
+ Message Sequence Number, Last Received Message Sequence Number,
+ Message Type, Flags, and Control Message Body.
+
+ When a PW status refresh reduction Control Message needs to be sent,
+ the system can attach it to a scheduled PW status refresh reduction
+ Message or send one ahead of time. In any case, PW status refresh
+ reduction Control Messages always piggyback on normal messages.
+
+ A PW status refresh reduction Message is also called a PW status
+ refresh reduction Control Message if it contains a control message
+ construct.
+
+ There can only be one control message construct per PW status refresh
+ reduction Message. If the U-Bit is set and a PE receiving the PW
+ status refresh reduction Message does not understand the control
+ message, the control message MUST be silently ignored. However, the
+ Message Sequence Number MUST still be acknowledged by sending a Null
+ Notification message back with the appropriate value in the Last
+ Message Received field. If a control message is not acknowledged
+ after 3.5 times the value of the Refresh Timer, a fatal notification
+ -- "Unacknowledged control message" -- MUST be sent, and the PW
+ status refresh reduction session MUST be terminated.
+
+
+
+Martini, et al. Standards Track [Page 11]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+ If a PE does not want or need to send a control message, the Checksum
+ and all subsequent fields MUST NOT be sent, and the Total Message
+ Length field is then set to 0.
+
+5.1. Notification Message
+
+ The most common use of the notification message is to acknowledge the
+ reception of a message by indicating the received Message Sequence
+ Number in the Last Received Sequence Number field. The notification
+ message is encoded 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Checksum | Message Sequence Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Last Received Sequence Number | Type=0x01 |U|C| Flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Notification Code |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The message type is set to 0x01, and the U-Bit is treated as
+ described in Section 4. The Notification Codes are 32-bit quantities
+ assigned by IANA (see the IANA Considerations section). Notification
+ codes are considered either "Error codes" or simple notifications.
+ If the Notification Code is an Error code as indicated in the IANA
+ allocation registry, the keepalive session MUST be terminated by
+ entering the STARTUP state.
+
+ When there is no notification information to be sent, the
+ notification code is set to 0 to indicate a "Null Notification". The
+ C-Bit MUST always be set to 0 in this type of message. The remaining
+ 6 bits of PW status refresh reduction Message Flags are to be
+ allocated by IANA. These unallocated bits MUST be set to 0 on
+ transmission and ignored on reception.
+
+5.2. PW Configuration Message
+
+ The PW status refresh reduction TLVs are informational TLVs that
+ allow the remote PE to verify certain provisioning information. This
+ message contains a series of sub-TLVs, in no particular order, that
+ contain PW and LSP configuration information. The message has no
+ preset length limit; however, its total length will be limited by the
+ transport network's Maximum Transmission Unit (MTU). PW status
+ refresh reduction Messages MUST NOT be fragmented. If a sender has
+ more configuration information to send than will fit into one PW
+ Configuration Message, it may send additional messages carrying
+ additional TLVs.
+
+
+
+Martini, et al. Standards Track [Page 12]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Checksum | Message Sequence Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Last Received Sequence Number | Type=0x02 |U|C| Flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ | PW Configuration Message Sub-TLVs |
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The PW Configuration Message type is set to 0x02. For this message,
+ the U-Bit is set to 1, as processing of these messages is OPTIONAL.
+
+ The C-Bit is used to signal the end of PW configuration transmission.
+ If it is set, the sending PE has finished sending all of its current
+ configuration information. The PE transmitting the configuration
+ MUST set the C-Bit on the last PW Configuration Message when all
+ current PW configuration information has been sent.
+
+ PW Configuration Message sub-TLVs have the following generic format:
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ | Value (Continued) |
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+5.2.1. MPLS-TP Tunnel ID
+
+ This TLV contains the MPLS-TP Tunnel ID ("MPLS-TP" stands for "MPLS
+ Transport Profile"). When the configuration message is used for a
+ particular keepalive session, the MPLS-TP Tunnel ID sub-TLV MUST be
+ sent at least once.
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 13]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+ The MPLS-TP Tunnel ID is encoded 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=0x01 | Length=20 | MPLS-TP Tunnel ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ | MPLS-TP Tunnel ID (Continued) (20 octets) |
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The MPLS point-to-point tunnel ID is defined in [RFC6370]. The
+ coding used by the node that is the source of a message is:
+
+ Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::
+ Dst-Tunnel_Num
+
+ Note that a single tunnel ID is enough to identify the tunnel and the
+ source end of the message.
+
+5.2.2. PW ID Configured List
+
+ This OPTIONAL sub-TLV contains a list of the provisioned PWs on
+ the LSP.
+
+ 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=0x02 | Length | PW Path ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | PW Path ID (Continued) |
+ ~ ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The PW Path ID is a 32-octet PW path identifier [RFC6370]. The
+ coding used by the node that is the source of a message is:
+
+ AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID::
+ Dst-Global_ID::Dst-Node_ID::Dst-AC_ID
+
+ The number of PW Path IDs in the TLV will be inferred by the length
+ of the TLV, up to a maximum of 8. The procedure for processing this
+ TLV will be described in Section 6.
+
+
+
+
+
+Martini, et al. Standards Track [Page 14]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+5.2.3. PW ID Unconfigured List
+
+ This OPTIONAL sub-TLV contains a list of the PWs that have been
+ deprovisioned on the LSP. Note that sending the same PW address in
+ both the PW ID Configured List sub-TLV and the PW ID Unconfigured
+ List sub-TLV in the same configuration message constitutes a fatal
+ session error. If this error occurs, an error notification message
+ is returned with the Error code "PW Configuration TLV conflict", and
+ the session is terminated by entering the STARTUP state.
+
+ 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=0x03 | Length | PW Path ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | PW Path ID (Continued) |
+ ~ ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The PW Path ID is a 32-octet PW path identifier as defined in
+ Section 5.2.2.
+
+ The number of PW Path IDs in the TLV will be inferred by the length
+ of the TLV, up to a maximum of 8.
+
+6. PW Provisioning Verification Procedure
+
+ The advertisement of the PW Configuration Message is OPTIONAL.
+
+ A PE that desires to use the PW Configuration Message to verify the
+ configuration of PWs on a particular LSP should advertise its PW
+ configuration to the remote PE on LSPs that have active keepalive
+ sessions. When a PE receives PW configuration information using this
+ protocol and it does not support processing the information or is not
+ willing to process it, it MUST acknowledge all the PW Configuration
+ Messages with the notification code "PW configuration not supported".
+ In this case, the information in the PW Configuration Message is
+ silently ignored. If a PE receives such a notification, it SHOULD
+ stop sending PW Configuration Messages for the duration of the PW
+ status refresh reduction keepalive session.
+
+
+
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 15]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+ If PW configuration information is received, it is used to verify the
+ accuracy of the local configuration information against the remote
+ PE's configuration information. If a configuration mismatch is
+ detected, where a particular PW is configured locally but not on the
+ remote PE, the following actions SHOULD be taken:
+
+ i. The local PW MUST be considered in "Not Forwarding" state
+ (Section 6.3.2 of [RFC8077]).
+
+ ii. The PW Attachment Circuit status is set to reflect the PW fault.
+
+ iii. An alarm SHOULD be raised to a network management system.
+
+ iv. A notification message with the notification code "PW
+ configuration mismatch" MUST be sent to the remote PE. Only one
+ such message is REQUIRED per configuration message even if the
+ configuration message is split into multiple configuration
+ messages due to individual message-size restrictions on a
+ particular link. Upon receipt of such a message, the receiving
+ PE MAY raise an alarm to a network management system. This
+ alarm MAY be cleared when the configuration is updated.
+
+6.1. PW ID List Advertising and Processing
+
+ When configuration messages are advertised on a particular LSP, the
+ PE sending the messages needs to checkpoint the configuration
+ information sent by setting the C-Bit when all currently known
+ configuration information has been sent. This process allows the
+ receiving PE to immediately proceed to verify all the currently
+ configured PWs on that LSP, eliminating the need for a long waiting
+ period.
+
+ If a new PW is added to a particular LSP, the PE MUST place the
+ configuration verification of this PW on hold for a period of at
+ least 30 seconds. This is necessary to minimize false-positive
+ events of misconfiguration due to the ends of the PW being slightly
+ out of sync.
+
+7. Security Considerations
+
+ The security considerations discussed in [RFC6478] are adequate for
+ the mechanism described in this document, since the operating
+ environment is almost identical to the one where this protocol would
+ be deployed. It should also be noted that since this protocol is
+ designed to be deployed between two adjacent PEs connected by a
+ physical link, it is not possible to misdirect or inject traffic
+ without compromising the PW transport link itself.
+
+
+
+
+Martini, et al. Standards Track [Page 16]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+8. IANA Considerations
+
+ The registries in this section have been created or updated as
+ appropriate in the "Pseudowire Name Spaces (PWE3)" registry or the
+ "Generic Associated Channel (G-ACh) Parameters" registry. For the
+ allocation ranges designated as "vendor-proprietary extensions", the
+ respective IANA registry contains the vendor name in brackets at the
+ end of the Description field.
+
+8.1. PW Status Refresh Reduction Message Types
+
+ IANA has set up the "PW Status Refresh Reduction Control Messages"
+ registry. This registry contains 8-bit values. Type values 1 and 2
+ are defined in this document. Type values 3 through 64 and 128
+ through 254 are to be assigned by IANA using the "Expert Review"
+ policy defined in [RFC8126]. Type values 65 through 127, 0, and 255
+ are to be allocated using the "IETF Review" policy defined in
+ [RFC8126].
+
+ The Type values are assigned as follows:
+
+ Type Message Description
+ ---- ------------------------
+ 0x01 Notification message
+ 0x02 PW Configuration Message
+
+8.2. PW Configuration Message Sub-TLVs
+
+ IANA has set up the "PW Status Refresh Reduction Configuration
+ Message Sub-TLVs" registry. This registry contains 8-bit values.
+ Type values 1 through 3 are defined in this document. Type values 4
+ through 64 and 128 through 254 are to be assigned by IANA using the
+ "Expert Review" policy defined in [RFC8126]. Type values 65 through
+ 127, 0, and 255 are to be allocated using the "IETF Review" policy
+ defined in [RFC8126].
+
+ The Type values are assigned as follows:
+
+ Sub-TLV Type Description
+ ------------ -----------------------
+ 0x01 MPLS-TP Tunnel ID
+ 0x02 PW ID Configured List
+ 0x03 PW ID Unconfigured List
+
+
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 17]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+8.3. PW Status Refresh Reduction Notification Codes
+
+ IANA has set up the "PW Status Refresh Reduction Notification Codes"
+ registry. This registry contains 32-bit values. Type values 0
+ through 7 are defined in this document. Type values 8 through 65536
+ and 134,217,729 through 4,294,967,294 are to be assigned by IANA
+ using the "Expert Review" policy defined in [RFC8126]. Type values
+ 65537 through 134,217,728, 0, and 4,294,967,295 are to be allocated
+ using the "IETF Review" policy defined in [RFC8126].
+
+ For each value assigned, IANA should also track whether the value
+ constitutes an error as described in Section 5.1. When values are
+ assigned by IETF Review, the settings in the "Error?" column must be
+ documented in the RFC that requests the allocation. For
+ "Expert Review" assignments, the settings in the "Error?" column must
+ be made clear by the requester at the time of assignment.
+
+ The Type values are assigned as follows:
+
+ Code Error? Description
+ ---------- ------ ------------------------------
+ 0x00000000 No Null Notification
+ 0x00000001 No PW configuration mismatch
+ 0x00000002 Yes PW Configuration TLV conflict
+ 0x00000003 No Unknown TLV (U-Bit=1)
+ 0x00000004 Yes Unknown TLV (U-Bit=0)
+ 0x00000005 No Unknown Message Type
+ 0x00000006 No PW configuration not supported
+ 0x00000007 Yes Unacknowledged control message
+
+8.4. PW Status Refresh Reduction Message Flags
+
+ IANA has set up the "PW Status Refresh Reduction Message Flags"
+ registry. This is an 8-bit registry, with the first two most
+ significant bits allocated by this document as follows:
+
+ Bit Position Name Description
+ ------------ ---- ----------------------
+ 0 U Unknown flag bit
+ 1 C Configuration flag bit
+
+ The remaining bits are to be allocated using the "IETF Review" policy
+ defined in [RFC8126].
+
+
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 18]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+8.5. G-ACh Registry Allocation
+
+ IANA maintains a registry called "MPLS Generalized Associated Channel
+ (G-ACh) Types (including Pseudowire Associated Channel Types)". IANA
+ has allocated a new value as follows:
+
+ Value Description Reference
+ ----- --------------------------- ---------
+ 0x29 PW Status Refresh Reduction RFC 8237
+
+8.6. Guidance for Designated Experts
+
+ In all cases of review by the Designated Expert (DE) described here,
+ the DE is expected to ascertain the existence of suitable
+ documentation (a specification) as described in [RFC8126] and to
+ verify that the document is permanently and publicly available. The
+ DE is also expected to check that the clarity of purpose and use of
+ the requested code points fit the general architecture and intended
+ purpose of the respective message or TLV. Lastly, the DE should
+ check that any assignment does not duplicate or conflict with work
+ that is active or already published within the IETF.
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+ Label Switching Architecture", RFC 3031,
+ DOI 10.17487/RFC3031, January 2001,
+ <https://www.rfc-editor.org/info/rfc3031>.
+
+ [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
+ Profile (MPLS-TP) Identifiers", RFC 6370,
+ DOI 10.17487/RFC6370, September 2011,
+ <https://www.rfc-editor.org/info/rfc6370>.
+
+ [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci,
+ "Pseudowire Status for Static Pseudowires", RFC 6478,
+ DOI 10.17487/RFC6478, May 2012,
+ <https://www.rfc-editor.org/info/rfc6478>.
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 19]
+
+RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017
+
+
+ [RFC8077] Martini, L., Ed., and G. Heron, Ed., "Pseudowire Setup and
+ Maintenance Using the Label Distribution Protocol (LDP)",
+ STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
+ <https://www.rfc-editor.org/info/rfc8077>.
+
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+ RFC 2119 Key Words", BCP 14, RFC 8174,
+ DOI 10.17487/RFC8174, May 2017,
+ <https://www.rfc-editor.org/info/rfc8174>.
+
+9.2. Informative References
+
+ [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
+ "MPLS Generic Associated Channel", RFC 5586,
+ DOI 10.17487/RFC5586, June 2009,
+ <https://www.rfc-editor.org/info/rfc5586>.
+
+Authors' Addresses
+
+ Luca Martini
+ Monoski LLC
+
+ Email: lmartini@monoski.com
+
+
+ George Swallow
+ Southend Technical Center
+
+ Email: swallow.ietf@gmail.com
+
+
+ Elisa Bellagamba
+ Ericsson EAB
+ Torshamnsgatan 48
+ 16480, Stockholm
+ Sweden
+
+ Email: elisa.bellagamba@gmail.com
+
+
+
+
+
+
+
+
+Martini, et al. Standards Track [Page 20]
+