doc: Add RFC documents

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