wdiff rfc8237.original rfc8237.txt

Internet Engineering Task Force Luca (IETF) L. Martini
Internet Draft
Request for Comments: 8237 Monoski LLC
Intended status:
Category: Standards Track George G. Swallow
Expires: November 2017 Cisco
Elisa
ISSN: 2070-1721 SETC
E. Bellagamba
Ericsson

May
October 2017

MPLS LSP PW status refresh reduction for Static Pseudowires

draft-ietf-pals-status-reduction-05.txt Label Switched Path (LSP) Pseudowire (PW)
Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid Refresh Reduction for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 10, 2010 Static PWs

Abstract

This document describes a method for generating an aggregated
pseudowire (PW) status message transmitted for a statically
configured
pseudowire PW on a Multi-Protocol Multiprotocol Label Switching (MPLS) Label
Switched Path (LSP) to indicate the status of one or more pseudowires PWs carried
on the LSP.

The method for transmitting the pseudowire (PW) PW status information is not new, however 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.

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.

Table of Contents

1. Introduction ......................................... 3
1.1 ....................................................3
1.1. Requirements Language ................................ 3
1.2 ......................................4
1.2. Terminology .......................................... 3
1.3 ................................................4
1.3. Notational Conventions in Backus-Naur Form ........... 4
2 .....................................5
2. PW status refresh reduction protocol ................. 4
2.1 Status Refresh Reduction Protocol states ...................................... 4
2.1.1 ............................5
2.1. Protocol States ............................................5
2.1.1. INACTIVE ............................................. 5
2.1.2 ............................................5
2.1.2. STARTUP .............................................. 5
2.1.3 .............................................6
2.1.3. ACTIVE ............................................... 5
2.2 ..............................................6
2.2. Timer value change transition procedure .............. 5
3 Value Change Transition Procedure ....................6
3. PW status refresh reduction procedure ................ 6
4 Status Refresh Reduction Procedure ...........................7
4. PW status refresh reduction Status Refresh Reduction Message Encoding ......... 6
5 ....................8
5. PW status refresh reduction Status Refresh Reduction Control Messages ......... 10
5.1 ...................11
5.1. Notification message ................................. 10
5.2 Message ......................................12
5.2. PW Configuration Message ............................. 11
5.2.1 ..................................12
5.2.1. MPLS-TP Tunnel ID .................................... 12
5.2.2 ..................................13
5.2.2. PW ID configured Configured List ................................ 13
5.2.3 ..............................14
5.2.3. PW ID unconfigured Unconfigured List .............................. 13
6 ............................15
6. PW provisioning verification procedure ............... 14
6.0.4 Provisioning Verification Procedure .........................15
6.1. PW ID List advertising Advertising and processing ................ 15
7 Processing .....................16
7. Security Considerations .............................. 15
8 ........................................16
8. IANA Considerations .................................. 15
8.1 ............................................17
8.1. PW Status Refresh Reduction Message Types ............ 15
8.2 .................17
8.2. PW Configuration Message Sub-TLVs .................... 16
8.3 .........................17
8.3. PW Status Refresh Reduction Notification Codes ....... 16
8.4 ............18
8.4. PW status refresh reduction Status Refresh Reduction Message Flags ............ 17
8.5 G-ACH .................18
8.5. G-ACh Registry Allocation ............................ 17
8.6 .................................19
8.6. Guidance for Designated Experts ...................... 17
9 ...........................19
9. References ........................................... 18
9.1 .....................................................19
9.1. Normative References ................................. 18
9.2 ......................................19
9.2. Informative References ............................... 18
10 ....................................20
Authors' Addresses ................................... 18 ................................................20

1. Introduction

When PWs use a Multi Protocol Multiprotocol Label Switched Switching (MPLS) network as the
Packet Switched Network (PSN), they are setup according to [RFC8077] set up using static configuration mode label
assignment per Section 4 of [RFC8077], and the PW status information
is propagated using the method described in [RFC6478]. There are 2 two
basic modes of operation described in [RFC6478] section [RFC6478], Section 5.3: Periodic
(1) periodic retransmission of non-zero status messages, messages and (2) a
simple acknowledgement acknowledgment of PW status (sec (Section 5.3.1 of [RFC6478]). The LSP level
LSP-level protocol described below applies to the case when
PW status is acknowledged immediately with a requested refresh value
of zero (no refresh). In this case case, the PW status refresh reduction
protocol is necessary for several reasons, such as:

-i. Greatly increase 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 PE Provider Edge (PE) needs to periodically send to it's
its neighbors.
-ii. Detect

ii. The PW status refresh reduction protocol will detect a remote PE
restart.
-iii.

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. Optionally 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 [RFC2119].
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 Switching Switched Path

MS-PW: Multi-Segment Pseudowire

PE: Provider Edge

PW: Pseudowire

SS-PW: Single-Segment Pseudowire

S-PE: Switching Provider Edge Node of MS-PW

SS-PW: Single-Segment Pseudowire

T-PE: Terminating Provider Edge Node of MS-PW

1.3. Notational Conventions in Backus-Naur Form

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
Backus-Naur Form (using
double-colon - "::" - notation). ("::") 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 example, Src-Node_ID is the Node_ID
of a node referred to as Src (where "Src" ("Src" is short for "source" in this
example). "source").

The notation does not define an implicit ordering of the information
elements involved in a concatenated identifier.

2. PW status refresh reduction protocol Status Refresh Reduction Protocol

The PW status refresh reduction protocol consists of a simple message
that is sent at the LSP level level, using the MPLS Generic Associated
Channel.[RFC5586]

A PE using
Channel (G-ACh) [RFC5586].

For a particular LSP where the PW status refresh reduction protocol, for a particular
LSP where this 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 re-transmitted retransmitted at a locally configured interval
indicated in the refresh timer Refresh Timer field. If no acknowledgment is
received, the protocol does not reach active state, the ACTIVE state
(Section 2.1.3), and the PE SHOULD NOT send any PW status messages
with a refresh timer Refresh Timer of zero as described in [RFC6478] section [RFC6478],
Section 5.3.1.

It is worth noting that no relationship is existing exists between the locally
configured timer for the PW status refresh reduction protocol and the
PW
individual PW status refresh timers. Refresh Timers.

2.1. Protocol states States

The protocol can be in 3 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 PW PWs on a specific LSP are deprovisioned, or the
feature is deprovisioned.

2.1.2. STARTUP

In this state state, the PE transmits periodic PW status refresh reduction
messages,
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 Session ID in the Ack Session ID Field. This state field. State
can be
exited 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 Message with the correct local session Session ID in the Ack
Session ID Field field within 3.5 times the refresh timer Refresh Timer field value of
the last PW status refresh reduction message Message transmitted. This state
is immediately exited as follows:

-i. in the following scenarios:

i. A valid PW status refresh reduction message Message is not received
within 3.5 times the current refresh timer Refresh Timer field value. value (assuming
that a timer transition procedure is not in progress) progress).
New state: STARTUP
-ii. STARTUP.

ii. A PW status refresh reduction message Message is received with the
wrong, wrong
Ack Session ID field value or a zero, zero Ack Session ID field value.
New state:
STARTUP
-iii. STARTUP.

iii. All PWs using the particular LSP are deprovisioned, or the
protocol is disabled.
New state: INACTIVE INACTIVE.

2.2. Timer value change transition procedure Value Change Transition Procedure

If a PE needs to change the refresh timer 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.

i. A PW status refresh reduction message Message is transmitted with the
new timer value.
-ii.

ii. If the new value is greater then than the original one one, the PE will
operate on according to the new timer value immediately.
-iii.

iii. If the new value is smaller then than the original one, the PE will
operate according to the original timer value for a period
3.5 times the original timer value, value or until the first valid PW
status refresh reduction message Message is received.

A PE receiving a PW status refresh reduction message Message with a new
timer value, value will immediately transmit an acknowledge the new value via a PW
status refresh reduction message, Message and will start operating
according to the new timer value.

3. PW status refresh reduction procedure Status Refresh Reduction Procedure

When the PW status refresh reduction protocol, protocol on a particular LSP, LSP is
in the ACTIVE state, the PE can send all PW status messages, for PWs
on that LSP, with a refresh timer 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 mitigate 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 Refresh Timer expires. This can be
achieved by using a PW status refresh reduction Message refresh timer Refresh Timer
value that is much smaller then than the PW status message refresh timer Refresh Timer
value in use. (sec use (Section 5.3.1 of [RFC6478]) [RFC6478]).

If the PW status refresh reduction protocol session is terminated by
entering the INACTIVE state or the STARTUP states, state, the PE MUST
immediately re-send resend all the previously sent PW status messages for
that particular LSP for which the session was terminated. In this case
case, the refresh timer Refresh Timer value MUST NOT be set to zero, 0 and MUST be set
according to the local policy of the PE router. Care Implementations MUST be considered by implementations
take care to avoid flooding the remote PE with a large number of PW
status messages at once. if If the PW status refresh reduction protocol
session is terminated for administrative reasons, 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.

4. PW status refresh reduction Status Refresh Reduction Message Encoding

The packet containing the PW status refresh reduction message Message is
encoded as
follows: follows (omitting link layer information) 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 | 0xZZ 0x29 PW OAM Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | Ack Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Timer | Total Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Received Seq Sequence Number | Message Type |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Control Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This message contains the following fields:

* MPLS LSP (tunnel) Label Stack Entry

This

The label stack is explained in [RFC3031].

* GAL

The GAL 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. Message

This field indicates the Generic Associated Channel type Type in the
GACH header G-ACh header, as defined
described in Section 2.1 of [RFC5586].

Note: Channel type 0xZZ pending IANA allocation.

* Session ID

A non-zero, non-zero locally selected session number that is not
preserved if the local PE restarts.

In order to get a locally unique session Session ID, the recommended
choice is to perform a CRC-16 ("CRC" stands for "Cyclic
Redundancy Check"), giving as input the following data data:

|YY|MM|DD|HHMMSSLLL|

Where: YY: are
YY = the decimal two last digit two decimal digits of the current year
MM: are
MM = the decimal two digit decimal digits of the current month DD: are
DD = the
decimal two digit decimal digits of the current day HHMMSSLLL: are
HHMMSSLLL = the decimal digits of the current time time,
expressed in (hour, minutes, seconds,
milliseconds) hours (HH), minutes (MM), seconds (SS), and
milliseconds (LLL)

If the calculation results in an already existing 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 Session ID is also acceptable.

* Ack Session ID

The Acknowledgment Session ID received from the remote PE.

* Refresh Timer. Timer

A non zero non-zero unsigned 16 bit 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. Control Message Body. A value of
zero means that no control message is present, and therefore present and, therefore,
that no Checksum, and following Checksum or subsequent fields are present either.

* Checksum

A 16 bit 16-bit field containing the one's complement of the one's
complement sum of the entire message (including the GACH G-ACh
header), with the checksum 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 16-bit integer number that is started from 1 when the
protocol enters the ACTIVE state. The sequence numbers number wraps
back to 1 when the maximum value is reached. The value of zero 0 is
reserved and MUST NOT be used.

* Last Received Message Sequence Number

The sequence number of the last message received. In If no
message has yet been received during this session, this field
is set to
zero. 0.

* Message Type

The Type type of the control message that follows. Control message
types are allocated in this document, document and by IANA.

* (U) Unknown flag bit. bit

Upon receipt of an unknown message or TLV, if U is clear (=0), (0),
a notification message of with code "Unknown TLV (U-bit=0)" code 0x4 (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), (1), the unknown message, or message contining a containing an
unknown TLV, MUST be acknowledged and silently ignored ignored, and the
following messages, or TLVs, if any, processed as if the
unknown message, message or TLV did not exist. In this case case, the PE MAY
send back a single notification message per keepalive session
with code "Unknown TLV (U-bit=1)". (U-Bit=1)". This last Step step is OPTIONAL.

* (C) Configuration flag bit. bit

The C Bit C-Bit is used to signal the end of PW configuration
transmission. If it is set, the sending PE has finished
sending all it's of its current configuration information.

* 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, transmission and ignored on reception.

* Control Message Body

The Control Message body Body is defined in a section below, 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 Control
Message Body are OPTIONAL. The length Total Message Length field is used to
parse how many optional fields are included. Hence 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 a code "PW configuration not
supported.",
supported", and the message is ignored.

5. PW status refresh reduction Status Refresh Reduction Control Messages

PW status refresh reduction Control messages Messages consist of the Checksum,
Message Sequence Number, Last Received Message Sequence Number,
Message Type, Flags, and control message body. Control Message Body.

When there is the need to send a PW status refresh reduction Control
Messages, 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 case, PW status refresh
reduction Control Messages always piggy back piggyback on normal messages.

A PW status refresh reduction message 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 U-Bit is set, 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 However, the
message sequence number
Message Sequence Number MUST still be acknowledged by sending a null Null
Notification message back with the appropriate value in the Last
Message Received
Field. field. If a control message is not acknowledged, acknowledged
after 3.5 times the value of the Refresh Timer, a fatal notification "unacknowledged
-- "Unacknowledged control message" -- MUST be sent, and the PW
status refresh reduction session MUST be terminated.

If a PE does not want or need to send a control message, the
Checksum, Checksum
and all following subsequent fields MUST NOT be sent, and the Total Message
Length field is then set to zero. 0.

5.1. Notification message Message

The most common use of the Notification Message notification message is to acknowledge the
reception of a message by indicating the received message sequence
number Message Sequence
Number in the "Last Last Received Sequence Number" 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 Seq Sequence Number | Type=0x01 |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Notification Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The message type is set to 0x01, and the U bit U-Bit is treated as
described in the above section. Section 4. The Notification Codes are a 32 bit
quantity 32-bit quantities
assigned by IANA. IANA (see the IANA consideration section) Considerations section). Notification
codes are either considered either "Error codes" or simple notifications.
If the Notification code 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
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,
transmission and ignored on reception.

5.2. PW Configuration Message

The PW status refresh reduction TLVs are informational TLVs, TLVs that
allow the remote PE to verify certain provisioning information. This
message contain contains a series of sub-TLVs sub-TLVs, in no particular order, that
contain PW and LSP configuration information. The message has no
preset length limit, however limit; however, its total length will be limited by the
transport network network's Maximum Transmit Transmission Unit (MTU). PW status
refresh reduction
messages Messages MUST NOT be fragmented. If a sender has
more configuration information to send than will fit into one PW
Configuration Message Message, it may send further additional messages carrying further
additional TLVs.

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 Seq Sequence Number | Type=0x02 |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| PW Configuration Message Sub-TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The PW Configuration Message type is set to 0x02. For this message message,
the U-bit U-Bit is set to 1 1, as processing of these messages is OPTIONAL.

The C Bit 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 C-Bit on the last PW configuration message Configuration Message when all
current PW configuration information has been sent.

PW Configuration Message Sub-TLVs 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 (Continued) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.1. MPLS-TP Tunnel ID

This TLV contains the MPLS-TP tunnel ID. Tunnel ID ("MPLS-TP" stands for "MPLS
Transport Profile"). When the configuration message is used for a
particular keepalive session session, the MPLS-TP Tunnel ID sub-TLV MUST be
sent at least once.

The MPLS 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) octets) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The MPLS point to point point-to-point tunnel ID is defined in [RFC6370] as follows:

Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::Dst-
Tunnel_Num [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 tunnel ID is enough to identify the tunnel, tunnel and the
source end of the message.

5.2.2. PW ID configured Configured List

This OPTIONAL TLV 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) |
~ ~
| Continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The PW Path ID is a 32 octet pseudowire 32-octet PW path identifier specified in
[RFC6370] as follows: [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 TLV, up to a maximum of 8. The procedure for processing this
TLV will be described in a section below. Section 6.

5.2.3. PW ID unconfigured Unconfigured List

This OPTIONAL TLV sub-TLV contains a list of the PWs that have been
deprovisioned on the LSP. Note that it is a fatal session error to
send sending the same PW address in
both the configured list TLV , PW ID Configured List sub-TLV and the
unconfigured list TLV PW ID Unconfigured
List sub-TLV in the same configuration message. message constitutes a fatal
session error. If the this error occurs, an error notification message
is returned with the
error Error code of "PW Configuration TLV conflict" 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) |
~ ~
| Continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The PW Path ID is a 32 octet pseudowire 32-octet PW path identifier specified in
[RFC6370] as follows: AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID::
Dst-Global_ID::Dst-Node_ID::Dst-AC_ID defined in
Section 5.2.2.

The number of PW Path IDs in the TLV will be inferred by the length
of the TLV TLV, up to a maximum of 8.

6. PW provisioning verification procedure Provisioning Verification Procedure

The advertisement of the PW configuration message Configuration Message is OPTIONAL.

A PE that desires to use the PW configuration message Configuration Message to verify the
configuration of PWs on a particular LSP, 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 is does not supporting support processing the information or is not
willing to use the
information, process it, it MUST acknowledge all the PW configuration messages Configuration
Messages with a the notification of code "PW configuration not supported".
In this case, the information in the control messages PW Configuration Message is
silently ignored. If a PE receives such a notification notification, it SHOULD
stop sending PW
configuration control messages Configuration Messages for the duration of the PW
status refresh reduction keepalive session.

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 action actions SHOULD be taken:

-i.

i. The local PW MUST be considered in "Not Forwarding" State.

-ii. state
(Section 6.3.2 of [RFC8077]).

ii. The PW Attachment Circuit status is set to reflect the PW fault.

-iii.

iii. An Alarm alarm SHOULD be raised to a network management system.

-iv.

iv. A Notification notification message with the notification code of "PW
configuration mismatch." 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
restriction message-size restrictions on a
particular link. Upon receipt of such a
message message, the receiving
PE MAY raise an alarm to a network management system. This
alarm MAY be cleared when the configuration is updated.

6.0.4.

6.1. PW ID List advertising Advertising and processing Processing

When configuration messages are advertised along on a particular LSP, the
PE sending the messages needs to check point checkpoint the configuration
information sent by setting the C bit 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 false-positive
events of mis-configuration misconfiguration due to the ends of the PW being slightly
out of sync.

7. Security Considerations

The security considerations of discussed in [RFC6478] are adequate for
the
proposed 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. All these situations are covered in the
security considerations of [RFC6478].

8. IANA Considerations

All the

The registries in this section are to be have been created or updated as
appropriate in the Pseudowire "Pseudowire Name Spaces (PWE3). (PWE3)" registry or the
"Generic Associated Channel (G-ACh) Parameters" registry. For the
allocation ranges designated as "vendor proprietary "vendor-proprietary extensions", the
respective IANA registry, will contain registry contains the vendor name in brackets at the
end of the description Description field.

8.1. PW Status Refresh Reduction Message Types

IANA needs to has set up a registry of the "PW status refresh reduction Status Refresh Reduction Control Messages". These are Messages"
registry. This registry contains 8-bit values. Type value values 1 through and 2
are defined in this document. Type values 3 through 64, 64 and 128
through 254 are to be assigned by IANA using the "Expert Review"
policy defined in RFC5226. [RFC8126]. Type values 65 through 127, 0 0, and 255
are to be allocated using the IETF review "IETF Review" policy defined in [RFC5226].
[RFC8126].

The Type Values values are assigned as follows:

Type Message Description
---- ------------------- ------------------------
0x01 Notification message
0x02 PW Configuration Message

8.2. PW Configuration Message Sub-TLVs

IANA needs to has set up a registry of the "PW status refresh reduction Status Refresh Reduction Configuration
Message Sub-TLVs". These are Sub-TLVs" registry. This registry contains 8-bit values.
Type value values 1 through 3 are defined in this document. Type values 3 4
through 64, 64 and 128 through 254 are to be assigned by IANA using the
"Expert Review" policy defined in RFC5226. [RFC8126]. Type values 65 through
127, 0 0, and 255 are to be allocated using the IETF review "IETF Review" policy
defined in [RFC5226]. [RFC8126].

The Type Values values are assigned as follows:
sub-TLV type

Sub-TLV Type Description
------------ ----------- -----------------------
0x01 MPLS-TP Tunnel ID. ID
0x02 PW ID configured List. Configured List
0x03 PW ID unconfigured List. Unconfigured List

8.3. PW Status Refresh Reduction Notification Codes

IANA needs to has set up a registry of the "PW status refresh reduction Status Refresh Reduction Notification Codes". These are Codes"
registry. This registry contains 32-bit values. Type value values 0
through 7 are defined in this document. Type values 8 through 65536, 65536
and 134,217,729 through 4,294,967,294 are to be assigned by IANA
using the "Expert Review" policy defined in RFC5226. [RFC8126]. Type values 65536
65537 through 134,217,728, 0 0, and 4,294,967,295 are to be allocated
using the IETF review "IETF Review" policy defined in [RFC5226]. [RFC8126].

For each value assigned assigned, IANA should also track whether the value
constitutes an error as described in Section 5.1. When values are
assigned by IETF review, Review, the setting of this settings in the "Error?" column must be
documented in the RFC that requests the allocation. For Expert Review
"Expert Review" assignments, the setting of this settings in the "Error?" column must
be made clear by the requester at the time of assignment.

The Type Values values are assigned as follows:

Code Error? Description
----
---------- ------ ----------- ------------------------------
0x00000000 No Null Notification. Notification
0x00000001 No PW configuration mismatch. mismatch
0x00000002 Yes PW Configuration TLV conflict. conflict
0x00000003 No Unknown TLV (U-bit=1) (U-Bit=1)
0x00000004 Yes Unknown TLV (U-bit=0) (U-Bit=0)
0x00000005 No Unknown Message Type
0x00000006 No PW configuration not supported. supported
0x00000007 Yes Unacknowledged control message. message

8.4. PW status refresh reduction Status Refresh Reduction Message Flags

IANA needs to has set up a registry of the "PW status refresh reduction Status Refresh Reduction Message Flags". Flags"
registry. This is a 8 bit registry an 8-bit registry, with the first 2 two most
significant bits allocated by this document as follows:

Bit Position Name Description
------------ ---- ----------- ----------------------
0 U Unknown flag bit. bit
1 C Configuration flag bit. bit

The remaining bits are to be allocated by using the "IETF Review" policy
defined in [RFC5226]. [RFC8126].

8.5. G-ACH G-ACh Registry Allocation

IANA maintains a registry called "MPLS Generalized Associated Channel
(G-ACh) Types". Types (including Pseudowire Associated Channel Types)". IANA needs, to allocate
has allocated a new value as follows:

Value Description Reference
----- ----------- --------------------------- ---------
0xZZ
0x29 PW Status Refresh Reduction RFCXXXX 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 [RFC5226] [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 fits fit the general architecture and intended
purpose of the respective message or TLV. Lastly 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, Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March, 1997.

[RFC8077] "Pseudowire Setup and Maintenance Using the
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label
Distribution Protocol (LDP)", L. Martini, G. Heron, RFC8077,
february 2017. 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] L. Martini, G. L., Swallow, G. G., Heron, G., and M. Bocci Bocci,
"Pseudowire Status for Static Pseudowires", RFC6478, RFC 6478,
DOI 10.17487/RFC6478, May 2012

[RFC6370] M. Bocci, 2012,
<https://www.rfc-editor.org/info/rfc6478>.

[RFC8077] Martini, L., Ed., and G. Swallow, E. Gray "MPLS-TP Identifiers",
RFC6370, September 2011

[RFC5226] Narten, T. Heron, Ed., "Pseudowire Setup and H. Alvestrand,
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 Section in RFCs", BCP 26,
RFC 5226, May 2008

[RFC3031] E. Rosen, et al., 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 3031, MPLS Architecture, January
2001. 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] M. Bocci, M., Ed., M. Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", rfc5586, RFC 5586,
DOI 10.17487/RFC5586, June 2009

10. 2009,
<https://www.rfc-editor.org/info/rfc5586>.

Authors' Addresses

Luca Martini
Monoski LLC.
e-mail: LLC

Email: lmartini@monoski.com

George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, Massachusetts 01719
United States
e-mail: swallow@cisco.com
Southend Technical Center

Email: swallow.ietf@gmail.com

Elisa Bellagamba
Ericsson EAB
Torshamnsgatan 48
16480, Stockholm
Sweden
e-mail:

Email: elisa.bellagamba@gmail.com

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.

Expiration Date: November 2017