draft-ietf-pals-status-reduction-05.original   draft-ietf-pals-status-reduction-05v3.txt 
Internet Engineering Task Force Luca Martini Internet Engineering Task Force L. Martini
Internet Draft Monoski LLC Internet-Draft Monoski LLC
Intended status: Standards Track George Swallow Intended status: Standards Track G. Swallow
Expires: November 2017 Cisco Expires: November 2, 2017 Cisco
Elisa Bellagamba E. Bellagamba
Ericsson Ericsson
May 2017 May 2017
MPLS LSP PW status refresh reduction for Static Pseudowires MPLS LSP PW status refresh reduction for Static Pseudowires
draft-ietf-pals-status-reduction-05.txt draft-ietf-pals-status-reduction-05.txt
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with the This document describes a method for generating an aggregated
pseudowire status message transmitted for a statically configured
pseudowire on a Multi-Protocol Label Switching (MPLS) Label Switched
Path (LSP) to indicate the status of one or more pseudowires carried
on the LSP.
The method for transmitting the pseudowire (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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 2, 2017.
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
Abstract Copyright Notice
This document describes a method for generating an aggregated Copyright (c) 2017 IETF Trust and the persons identified as the
pseudowire status message transmitted for a statically configured document authors. All rights reserved.
pseudowire on a Multi-Protocol Label Switching (MPLS) Label Switched
Path (LSP) to indicate the status of one or more pseudowires carried
on the LSP.
The method for transmitting the pseudowire (PW) status information is This document is subject to BCP 78 and the IETF Trust's Legal
not new, however this protocol extension allows a Service Provider Provisions Relating to IETF Documents
(SP) to reliably monitor the individual PW status while not (http://trustee.ietf.org/license-info) in effect on the date of
overwhelming the network with multiple periodic status messages. This publication of this document. Please review these documents
is achieved by sending a single cumulative summary status carefully, as they describe your rights and restrictions with respect
verification message for all the PWs grouped in the same LSP. 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 Table of Contents
1 Introduction ......................................... 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Requirements Language ................................ 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2 Terminology .......................................... 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Notational Conventions in Backus-Naur Form ........... 4 1.3. Notational Conventions in Backus-Naur Form . . . . . . . 4
2 PW status refresh reduction protocol ................. 4 2. PW status refresh reduction protocol . . . . . . . . . . . . 4
2.1 Protocol states ...................................... 4 2.1. Protocol states . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 INACTIVE ............................................. 5 2.1.1. INACTIVE . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 STARTUP .............................................. 5 2.1.2. STARTUP . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 ACTIVE ............................................... 5 2.1.3. ACTIVE . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Timer value change transition procedure .............. 5 2.2. Timer value change transition procedure . . . . . . . . . 5
3 PW status refresh reduction procedure ................ 6 3. PW status refresh reduction procedure . . . . . . . . . . . . 6
4 PW status refresh reduction Message Encoding ......... 6 4. PW status refresh reduction Message Encoding . . . . . . . . 6
5 PW status refresh reduction Control Messages ......... 10 5. PW status refresh reduction Control Messages . . . . . . . . 10
5.1 Notification message ................................. 10 5.1. Notification message . . . . . . . . . . . . . . . . . . 10
5.2 PW Configuration Message ............................. 11 5.2. PW Configuration Message . . . . . . . . . . . . . . . . 11
5.2.1 MPLS-TP Tunnel ID .................................... 12 5.2.1. MPLS-TP Tunnel ID . . . . . . . . . . . . . . . . . . 12
5.2.2 PW ID configured List ................................ 13 5.2.2. PW ID configured List . . . . . . . . . . . . . . . . 13
5.2.3 PW ID unconfigured List .............................. 13 5.2.3. PW ID unconfigured List . . . . . . . . . . . . . . . 13
6 PW provisioning verification procedure ............... 14 6. PW provisioning verification procedure . . . . . . . . . . . 14
6.0.4 PW ID List advertising and processing ................ 15 6.1. PW ID List advertising and processing . . . . . . . . . . 15
7 Security Considerations .............................. 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8 IANA Considerations .................................. 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1 PW Status Refresh Reduction Message Types ............ 15 8.1. PW Status Refresh Reduction Message Types . . . . . . . . 15
8.2 PW Configuration Message Sub-TLVs .................... 16 8.2. PW Configuration Message Sub-TLVs . . . . . . . . . . . . 16
8.3 PW Status Refresh Reduction Notification Codes ....... 16 8.3. PW Status Refresh Reduction Notification Codes . . . . . 16
8.4 PW status refresh reduction Message Flags ............ 17 8.4. PW status refresh reduction Message Flags . . . . . . . . 17
8.5 G-ACH Registry Allocation ............................ 17 8.5. G-ACH Registry Allocation . . . . . . . . . . . . . . . . 17
8.6 Guidance for Designated Experts ...................... 17 8.6. Guidance for Designated Experts . . . . . . . . . . . . . 17
9 References ........................................... 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1 Normative References ................................. 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2 Informative References ............................... 18 9.2. Informative References . . . . . . . . . . . . . . . . . 18
10 Authors' Addresses ................................... 18
1. Introduction Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
When PWs use a Multi Protocol Label Switched (MPLS) network as the When PWs use a Multi Protocol Label Switched (MPLS) network as the
Packet Switched Network (PSN), they are setup according to [RFC8077] Packet Switched Network (PSN), they are setup according to [RFC8077]
static configuration mode and the PW status information is propagated static configuration mode and the PW status information is propagated
using the method described in [RFC6478]. There are 2 basic modes of using the method described in [RFC6478]. There are 2 basic modes of
operation described in [RFC6478] section 5.3: Periodic retransmission operation described in [RFC6478] section 5.3: Periodic retransmission
of non-zero status messages, and a simple acknowledgement of PW of non-zero status messages, and a simple acknowledgement of PW
status (sec 5.3.1 of [RFC6478]). The LSP level protocol described status (sec 5.3.1 of [RFC6478]). The LSP level protocol described
below applies to the case when PW status is acknowledged immediately below applies to the case when PW status is acknowledged immediately
with a requested refresh value of zero (no refresh). In this case with a requested refresh value of zero (no refresh). In this case
the PW status refresh reduction protocol is necessary for several the PW status refresh reduction protocol is necessary for several
reasons, such as: reasons, such as:
-i. Greatly increase the scalability of the PW status protocol -i. Greatly increase the scalability of the PW status
by reducing the amount of messages that a PE needs to protocol by reducing the amount of messages that a PE needs to
periodically send to it's neighbors. periodically send to it's neighbors.
-ii. 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. Optionally detect a remote PE provisioning change.
1.1. Requirements Language -ii. 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. Optionally detect a remote PE provisioning change.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
FEC: Forwarding Equivalence Class FEC: Forwarding Equivalence Class
LDP: Label Distribution Protocol LDP: Label Distribution Protocol
LSP: Label Switching Path LSP: Label Switching Path
MS-PW: Multi-Segment Pseudowire MS-PW: Multi-Segment Pseudowire
PE: Provider Edge PE: Provider Edge
skipping to change at page 3, line 45 skipping to change at page 4, line 4
FEC: Forwarding Equivalence Class FEC: Forwarding Equivalence Class
LDP: Label Distribution Protocol LDP: Label Distribution Protocol
LSP: Label Switching Path LSP: Label Switching Path
MS-PW: Multi-Segment Pseudowire MS-PW: Multi-Segment Pseudowire
PE: Provider Edge PE: Provider Edge
PW: Pseudowire PW: Pseudowire
SS-PW: Single-Segment Pseudowire SS-PW: Single-Segment Pseudowire
S-PE: Switching Provider Edge Node of MS-PW S-PE: Switching Provider Edge Node of MS-PW
T-PE: Terminating Provider Edge Node of MS-PW T-PE: Terminating Provider Edge Node of MS-PW
1.3. Notational Conventions in Backus-Naur Form 1.3. Notational Conventions in Backus-Naur Form
All multiple-word atomic identifiers use underscores (_) between the All multiple-word atomic identifiers use underscores (_) between the
words to join the words. Many of the identifiers are composed of a words to join the words. Many of the identifiers are composed of a
concatenation of other identifiers. These are expressed using concatenation of other identifiers. These are expressed using
Backus-Naur Form (using double-colon - "::" - notation). Backus-Naur Form (using double-colon - "::" - notation).
Where the same identifier type is used multiple times in a Where the same identifier type is used multiple times in a
concatenation, they are qualified by a prefix joined to the concatenation, they are qualified by a prefix joined to the
identifier by a dash (-). For example Src-Node_ID is the Node_ID of identifier by a dash (-). For example Src-Node_ID is the Node_ID of
a node referred to as Src (where "Src" is short for "source" in this a node referred to as Src (where "Src" is short for "source" in this
example). example).
The notation does not define an implicit ordering of the information The notation does not define an implicit ordering of the information
elements involved in a concatenated identifier. elements involved in a concatenated identifier.
2. PW status refresh reduction protocol 2. PW status refresh reduction protocol
PW status refresh reduction protocol consists of a simple message PW status refresh reduction protocol consists of a simple message
that is sent at the LSP level using the MPLS Generic Associated that is sent at the LSP level using the MPLS Generic Associated
Channel.[RFC5586] Channel.[RFC5586]
A PE using the PW status refresh reduction protocol, for a particular A PE using the PW status refresh reduction protocol, for a particular
LSP where this protocol is enabled, MUST send the PW status refresh LSP where this protocol is enabled, MUST send the PW status refresh
reduction Message as soon as a PW is configured on that LSP. The reduction Message as soon as a PW is configured on that LSP. The
message is then re-transmitted at a locally configured interval message is then re-transmitted at a locally configured interval
indicated in the refresh timer field. If no acknowledgment is indicated in the refresh timer field. If no acknowledgment is
received, the protocol does not reach active state, and the PE SHOULD received, the protocol does not reach active state, and the PE SHOULD
NOT send any PW status messages with a refresh timer of zero as NOT send any PW status messages with a refresh timer of zero as
described in [RFC6478] section 5.3.1. described in [RFC6478] section 5.3.1.
It is worth noting that no relationship is existing between the It is worth noting that no relationship is existing between the
locally configured timer for the refresh reduction protocol and the locally configured timer for the refresh reduction protocol and the
PW individual status refresh timers. PW individual status refresh timers.
2.1. Protocol states 2.1. Protocol states
The protocol can be in 3 possible states: INACTIVE, STARTUP, and The protocol can be in 3 possible states: INACTIVE, STARTUP, and
ACTIVE. ACTIVE.
2.1.1. INACTIVE 2.1.1. INACTIVE
This state is entered when the protocol is turned off. This state is This state is entered when the protocol is turned off. This state is
also entered if all PW on a specific LSP are deprovisioned, or the also entered if all PW on a specific LSP are deprovisioned, or the
feature is deprovisioned. feature is deprovisioned.
2.1.2. STARTUP 2.1.2. STARTUP
In this state the PE transmits periodic PW status refresh reduction In this state the PE transmits periodic PW status refresh reduction
messages, with the Ack Session ID set to 0. The PE remains in this messages, with the Ack Session ID set to 0. The PE remains in this
state until a PW status refresh message is received with the correct state until a PW status refresh message is received with the correct
local session ID in the Ack Session ID Field. This state can be local session ID in the Ack Session ID Field. This state can be
exited to the ACTIVE or INACTIVE state. exited to the ACTIVE or INACTIVE state.
2.1.3. ACTIVE 2.1.3. ACTIVE
This state is entered once the PE receives a PW status refresh This state is entered once the PE receives a PW status refresh
reduction message with the correct local session ID in the Ack reduction message with the correct local session ID in the Ack
Session ID Field within 3.5 times the refresh timer field value of Session ID Field within 3.5 times the refresh timer field value of
the last PW status refresh reduction message transmitted. This state the last PW status refresh reduction message transmitted. This state
is immediately exited as follows: is immediately exited as follows:
-i. A valid PW status refresh reduction message is not received -i. A valid PW status refresh reduction message is not
within 3.5 times the current refresh timer field value. received within 3.5 times the current refresh timer field
(assuming a timer transition procedure is not in progress) value. (assuming a timer transition procedure is not in
New state: STARTUP progress) New state: STARTUP
-ii. A PW status refresh reduction message is received with the
wrong, 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 -ii. A PW status refresh reduction message is received
with the wrong, 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 refresh timer value field while the PW If a PE needs to change the refresh timer value field while the PW
refresh reduction protocol is in the ACTIVE state, the following refresh reduction protocol is in the ACTIVE state, the following
procedure must be followed: procedure must be followed: -i. A PW status refresh reduction
-i. A PW status refresh reduction message is transmitted with message is transmitted with the new timer value.
the new timer value.
-ii. If the new value is greater then the original one the PE
will operate on the new timer value immediately.
-iii. If the new value is smaller then 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 -ii. If the new value is greater then the original one the
new timer value, will immediately transmit an acknowledge PW PE will operate on the new timer value immediately.
status refresh reduction message, and start operating
according to the new timer value.
3. PW status refresh reduction procedure -iii. If the new value is smaller then 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 transmit an
acknowledge PW status refresh reduction message, and
start operating according to the new timer value.
3. PW status refresh reduction procedure
When the refresh reduction protocol, on a particular LSP, is in the When the refresh reduction protocol, on a particular LSP, is in the
ACTIVE state, the PE can send all PW status messages, for PWs on that 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 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 amount of messages that the PE needs to transmit to the remote PE
because once the PW status message for a particular PW is because once the PW status message for a particular PW is
acknowledged, further repetitions of that message are no longer acknowledged, further repetitions of that message are no longer
necessary. necessary.
To further mitigate the amount of possible messages when an LSP To further mitigate the amount of possible messages when an LSP
starts forwarding traffic, care should be taken to permit the PW starts forwarding traffic, care should be taken to permit the PW
refresh reduction protocol to reach the ACTIVE state quickly, and refresh reduction protocol to reach the ACTIVE state quickly, and
before the first PW status refresh timer expires. This can be before the first PW status refresh timer expires. This can be
achieved by using a PW status refresh reduction Message refresh timer achieved by using a PW status refresh reduction Message refresh timer
value that is much smaller then the PW status message refresh timer value that is much smaller then the PW status message refresh timer
value in use. (sec 5.3.1 of [RFC6478]) value in use. (sec 5.3.1 of [RFC6478])
If the refresh reduction protocol session is terminated by entering If the refresh reduction protocol session is terminated by entering
the INACTIVE or STARTUP states, the PE MUST immediately re-send all the INACTIVE or STARTUP states, the PE MUST immediately re-send all
the previously sent PW status messages for that particular LSP for the previously sent PW status messages for that particular LSP for
which the session terminated. In this case the refresh timer value which the session terminated. In this case the refresh timer value
MUST NOT be set to zero, and MUST be set according to the local MUST NOT be set to zero, and MUST be set according to the local
policy of the PE router. Care MUST be considered by implementations policy of the PE router. Care MUST be considered by implementations
to avoid flooding the remote PE with a large number of PW status to avoid flooding the remote PE with a large number of PW status
messages at once. if the refresh reduction protocol session is messages at once. if the refresh reduction protocol session is
terminated for administrative reasons, and the local PE can still terminated for administrative reasons, and the local PE can still
communicate with the remote PE, the local PE SHOULD pace the communicate with the remote PE, the local PE SHOULD pace the
transmission of PW status messages to the remote PE. transmission of PW status messages to the remote PE.
4. PW status refresh reduction Message Encoding 4. PW status refresh reduction Message Encoding
The packet containing the refresh reduction message is encoded as The packet containing the refresh reduction message is encoded as
follows: (omitting link layer information) follows: (omitting link layer information)
0 1 2 3 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 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 | | MPLS LSP (tunnel) Label Stack Entry |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | | GAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 34 skipping to change at page 7, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message contains the following fields: This message contains the following fields:
* MPLS LSP (tunnel) Label Stack Entry * MPLS LSP (tunnel) Label Stack Entry
This is explained in [RFC3031]. This is explained in [RFC3031].
* GAL * GAL
The GAL and the next 4 octets are explained in [RFC5586]. The GAL and the next 4 octets are explained in [RFC5586].
* PW OAM Message.
* PW OAM Message.
This field indicates the Generic Associated Channel type in the This field indicates the Generic Associated Channel type in the
GACH header as defined in [RFC5586]. GACH header as defined in [RFC5586].
Note: Channel type 0xZZ pending IANA allocation. Note: Channel type 0xZZ pending IANA allocation.
* Session ID * Session ID
A non-zero, locally selected session number that is not preserved A non-zero, locally selected session number that is not
if the local PE restarts. preserved if the local PE restarts.
In order to get a locally unique session ID, the recommended In order to get a locally unique session ID, the recommended
choice is to perform a CRC-16 giving as input the following data choice is to perform a CRC-16 giving as input the following
data
|YY|MM|DD|HHMMSSLLL| |YY|MM|DD|HHMMSSLLL|
Where: YY: are the decimal two last digit of the current year
MM: are the decimal two digit of the current month DD: are the
decimal two digit of the current day HHMMSSLLL: are the decimal
digits of the current time expressed in (hour, minutes, seconds,
milliseconds) 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 Where: YY: are the decimal two last digit of the current
year
MM: are the decimal two digit of the current month
DD: are the decimal two digit of the current day
HHMMSSLLL: are the decimal digits of the current
time expressed in (hour, minutes, seconds,
milliseconds) 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.
The Acknowledgment Session ID received from the remote PE. * Ack Session ID
* Refresh Timer. The Acknowledgment Session ID received from the remote PE.
A non zero unsigned 16 bit integer value greater or equal to 10, * Refresh Timer.
in milliseconds, that indicates the desired refresh interval. The
default value of 30000 is RECOMMENDED.
* Total Message Length A non zero unsigned 16 bit integer value greater or equal to
10, in milliseconds, that indicates the desired refresh
interval. The default value of 30000 is RECOMMENDED.
Total length in octets of the Checksum, Message Type, Flags, * Total Message Length
Message Sequence Number, and control message body. A value of
zero means that no control message is present, and therefore that
no Checksum, and following fields are present either.
* Checksum 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, and following fields are present either.
A 16 bit field containing the one's complement of the one's * Checksum
complement sum of the entire message (including the GACH 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 A 16 bit field containing the one's complement of the one's
complement sum of the entire message (including the GACH
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.
An unsigned 16 bit integer number that is started from 1 when the * Message Sequence Number
protocol enters ACTIVE state. The sequence numbers wraps back to An unsigned 16 bit integer number that is started from 1 when
1 when the maximum value is reached. The value of zero is the protocol enters ACTIVE state. The sequence numbers wraps
reserved and MUST NOT be used. back to 1 when the maximum value is reached. The value of zero
is reserved and MUST NOT be used.
* Last Received Message Sequence Number * Last Received Message Sequence Number
The sequence number of the last message received. In no message The sequence number of the last message received. In no
has yet been received during this session, this field is set to message has yet been received during this session, this field
zero. is set to zero.
* Message Type * Message Type
The Type of the control message that follows. Control message The Type of the control message that follows. Control message
types are allocated in this document, and by IANA. types are allocated in this document, and by IANA.
* (U) Unknown flag bit. * (U) Unknown flag bit.
Upon receipt of an unknown message or TLV, if U is clear (=0), a Upon receipt of an unknown message or TLV, if U is clear (=0),
notification message of "Unknown TLV (U-bit=0)" code 0x4 MUST be a notification message of "Unknown TLV (U-bit=0)" code 0x4 MUST
sent to the remote PE, and the keepalive session MUST be be sent to the remote PE, and the keepalive session MUST be
terminated by entering STARTUP state; if U is set (=1), the terminated by entering STARTUP state; if U is set (=1), the
unknown message, or message contining a unknown TLV, MUST be unknown message, or message contining a unknown TLV, MUST be
acknowledged and silently ignored and the following messages, or acknowledged and silently ignored and the following messages,
TLVs, if any, processed as if the unknown message, or TLV did not or TLVs, if any, processed as if the unknown message, or TLV
exist. In this case the PE MAY send back a single notification did not exist. In this case the PE MAY send back a single
message per keepalive session with code "Unknown TLV (U-bit=1)". notification message per keepalive session with code "Unknown
This last Step is OPTIONAL. TLV (U-bit=1)". This last Step is OPTIONAL.
* (C) Configuration flag bit. * (C) Configuration flag bit.
The C Bit is used to signal the end of PW configuration The C Bit is used to signal the end of PW configuration
transmission. If it is set, the sending PE has finished sending transmission. If it is set, the sending PE has finished
all it's current configuration information. sending all it's current configuration information.
* Flags * Flags
The remaining 6 bits of PW status refresh reduction Message Flags The remaining 6 bits of PW status refresh reduction Message
to be allocated by IANA. These unallocated bits MUST be set to 0 Flags to be allocated by IANA. These unallocated bits MUST be
on transmission, and ignored on reception. set to 0 on transmission, and ignored on reception.
* Control Message Body * Control Message Body
The Control Message body is defined in a section below, and is The Control Message body is defined in a section below, and is
specific to the type of message. specific to the type of message.
It should be noted that the Checksum, Message Sequence Number, Last It should be noted that the Checksum, Message Sequence Number, Last
Received Message Sequence Number, Message Type, Flags, and control Received Message Sequence Number, Message Type, Flags, and control
message body are OPTIONAL. The length field is used to parse how many message body are OPTIONAL. The length field is used to parse how
optional fields are included. Hence all optional fields that precede many optional fields are included. Hence all optional fields that
a specific field that needs to be included in a specific precede a specific field that needs to be included in a specific
implementation MUST be included if that optional field is also implementation MUST be included if that optional field is also
included. included.
If any of the above values are outside the specified range, a If any of the above values are outside the specified range, a
notification message is returned with a code "PW configuration not notification message is returned with a code "PW configuration not
supported.", and the message is ignored. supported.", and the message is ignored.
5. PW status refresh reduction Control Messages 5. PW status refresh reduction Control Messages
PW status refresh reduction Control messages consist of the Checksum, PW status refresh reduction Control messages consist of the Checksum,
Message Sequence Number, Last Received Message Sequence Number, Message Sequence Number, Last Received Message Sequence Number,
Message Type, Flags, and control message body. Message Type, Flags, and control message body.
When there is the need to send a PW status refresh reduction Control When there is the need to send a PW status refresh reduction Control
Messages, the system can attach it to a scheduled PW status refresh Messages, the system can attach it to a scheduled PW status refresh
reduction or send one ahead of time. In any case PW status refresh reduction or send one ahead of time. In any case PW status refresh
reduction Control Messages always piggy back on normal messages. reduction Control Messages always piggy back on normal messages.
A PW refresh reduction message is also called a PW status refresh A PW refresh reduction message is also called a PW status refresh
reduction Control Message if it contains a control message reduction Control Message if it contains a control message construct.
construct.
There can only be one control message construct per PW status refresh 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 reduction Message. If the U bit is set, and a PE receiving the PW
status refresh reduction Message does not understand the control status refresh reduction Message does not understand the control
message, the control message MUST be silently ignored. However the message, the control message MUST be silently ignored. However the
message sequence number MUST still be acknowledged by sending a null message sequence number MUST still be acknowledged by sending a null
message back with the appropriate value in the Last Message Received message back with the appropriate value in the Last Message Received
Field. If a control message is not acknowledged, after 3.5 times the Field. If a control message is not acknowledged, after 3.5 times the
value of the Refresh Timer, a fatal notification "unacknowledged value of the Refresh Timer, a fatal notification "unacknowledged
control message" MUST be sent, and the PW refresh reduction session control message" MUST be sent, and the PW refresh reduction session
MUST be terminated. MUST be terminated.
If a PE does not want or need to send a control message, the If a PE does not want or need to send a control message, the
Checksum, and all following fields MUST NOT be sent, and the Total Checksum, and all following fields MUST NOT be sent, and the Total
Message Length field is then set to zero. Message Length field is then set to zero.
5.1. Notification message 5.1. Notification message
The most common use of the Notification Message is to acknowledge the The most common use of the Notification Message is to acknowledge the
reception of a message by indicating the received message sequence reception of a message by indicating the received message sequence
number in the "Last Received Sequence Number" field. The notification number in the "Last Received Sequence Number" field. The
message is encoded as follows: notification message is encoded as follows:
0 1 2 3 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 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 | | Checksum | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Received Seq Number | Type=0x01 |U|C| Flags | | Last Received Seq Number | Type=0x01 |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Notification Code | | Notification Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 4 skipping to change at page 11, line 14
0 1 2 3 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 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 | | Checksum | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Received Seq Number | Type=0x01 |U|C| Flags | | Last Received Seq Number | Type=0x01 |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Notification Code | | Notification Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message type is set to 0x01, and the U bit is treated as The message type is set to 0x01, and the U bit is treated as
described in the above section. The Notification Codes are a 32 bit described in the above section. The Notification Codes are a 32 bit
quantity assigned by IANA. (see IANA consideration section) quantity assigned by IANA. (see IANA consideration section)
Notification codes are either considered "Error codes" or simple Notification codes are either considered "Error codes" or simple
notifications. If the Notification code is an Error code as indicated notifications. If the Notification code is an Error code as
in the IANA allocation registry, the keepalive session MUST be indicated in the IANA allocation registry, the keepalive session MUST
terminated by entering STARTUP state. be terminated by entering STARTUP state.
When there is no notification information to be sent, the When there is no notification information to be sent, the
notification code is set to 0 to indicate a "Null Notification". 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 C Bit MUST always be set to 0 in this type of message. The remaining
remaining 6 bits of PW status refresh reduction Message Flags to be 6 bits of PW status refresh reduction Message Flags to be allocated
allocated by IANA. These unallocated bits MUST be set to 0 on by IANA. These unallocated bits MUST be set to 0 on transmission,
transmission, and ignored on reception. and ignored on reception.
5.2. PW Configuration Message 5.2. PW Configuration Message
The PW status refresh reduction TLVs are informational TLVs, that The PW status refresh reduction TLVs are informational TLVs, that
allow the remote PE to verify certain provisioning information. This allow the remote PE to verify certain provisioning information. This
message contain a series of sub-TLVs in no particular order, that message contain a series of sub-TLVs in no particular order, that
contain PW and LSP configuration information. The message has no contain PW and LSP configuration information. The message has no
preset length limit, however its total length will be limited by the preset length limit, however its total length will be limited by the
transport network Maximum Transmit Unit (MTU). PW refresh reduction transport network Maximum Transmit Unit (MTU). PW refresh reduction
messages MUST NOT be fragmented. If a sender has more configuration messages MUST NOT be fragmented. If a sender has more configuration
information to send than will fit into one PW Configuration Message information to send than will fit into one PW Configuration Message
it may send further messages carrying further TLVs. it may send further messages carrying further TLVs.
0 1 2 3 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 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 | | Checksum | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Received Seq Number | Type=0x02 |U|C| Flags | | Last Received Seq Number | Type=0x02 |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
| PW Configuration Message Sub-TLVs | | PW Configuration Message Sub-TLVs |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PW Configuration Message type is set to 0x02. For this message
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 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. The C Bit is used to signal the end of PW configuration transmission.
If it is set, the sending PE has finished sending all its current If it is set, the sending PE has finished sending all its current
configuration information. The PE transmitting the configuration MUST configuration information. The PE transmitting the configuration
set the C bit on the last PW configuration message when all current MUST set the C bit on the last PW configuration message when all
PW configuration has been sent. current PW configuration has been sent.
PW Configuration Message Sub-TLVs have the following generic format: PW Configuration Message Sub-TLVs have the following generic format:
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value | | Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
| Value Continued | | Value Continued |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.1. MPLS-TP Tunnel ID 5.2.1. MPLS-TP Tunnel ID
This TLV contains the MPLS-TP tunnel ID. When the configuration This TLV contains the MPLS-TP tunnel ID. When the configuration
message is used for a particular keepalive session the MPLS-TP Tunnel message is used for a particular keepalive session the MPLS-TP Tunnel
ID sub-TLV MUST be sent at least once. ID sub-TLV MUST be sent at least once.
The MPLS Tunnel ID is encoded as follows: The MPLS Tunnel ID is encoded as follows:
0 1 2 3 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 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 | | Type=0x01 | Length=20 | MPLS-TP Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 5 skipping to change at page 13, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MPLS point to point tunnel ID is defined in [RFC6370] as follows: The MPLS point to point tunnel ID is defined in [RFC6370] as follows:
Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::Dst- Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::Dst-
Tunnel_Num Tunnel_Num
Note that a single Tunnel ID is enough to identify the tunnel, and Note that a single Tunnel ID is enough to identify the tunnel, and
the source end of the message. the source end of the message.
5.2.2. PW ID configured List 5.2.2. PW ID configured List
This OPTIONAL TLV contains a list of the provisioned PWs on the LSP. This OPTIONAL TLV contains a list of the provisioned PWs on the LSP.
0 1 2 3 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 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 | | Type=0x02 | Length | PW Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| PW Path ID | | PW Path ID |
skipping to change at page 13, line 28 skipping to change at page 13, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PW Path ID is a 32 octet pseudowire path identifier specified in The PW Path ID is a 32 octet pseudowire path identifier specified in
[RFC6370] as follows: AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID:: [RFC6370] as follows: AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID::
Dst-Global_ID::Dst-Node_ID::Dst-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 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 of the TLV up to a maximum of 8. The procedure for processing this
TLV will be described in a section below. TLV will be described in a section below.
5.2.3. PW ID unconfigured List 5.2.3. PW ID unconfigured List
This OPTIONAL TLV contains a list of the PWs that have been This OPTIONAL TLV contains a list of the PWs that have been
deprovisioned on the LSP. Note that it is a fatal session error to deprovisioned on the LSP. Note that it is a fatal session error to
send the same PW address in both the configured list TLV , and the send the same PW address in both the configured list TLV , and the
unconfigured list TLV in the same configuration message. If the this unconfigured list TLV in the same configuration message. If the this
error occurs, an error notification message is returned with the error occurs, an error notification message is returned with the
error code of "PW Configuration TLV conflict" and the session is error code of "PW Configuration TLV conflict" and the session is
terminated by entering STARTUP state. terminated by entering STARTUP state.
0 1 2 3 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 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 | | Type=0x03 | Length | PW Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 14, line 4 skipping to change at page 13, line 50
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x03 | Length | PW Path ID | | Type=0x03 | Length | PW Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| PW Path ID | | PW Path ID |
~ ~ ~ ~
| Continued | | Continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PW Path ID is a 32 octet pseudowire path identifier specified in The PW Path ID is a 32 octet pseudowire path identifier specified in
[RFC6370] as follows: AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID:: [RFC6370] as follows: AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID::
Dst-Global_ID::Dst-Node_ID::Dst-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 The number of PW Path IDs in the TLV will be inferred by the length
of the TLV up to a maximum of 8. of the TLV up to a maximum of 8.
6. PW provisioning verification procedure 6. PW provisioning verification procedure
The advertisement of the PW configuration message is OPTIONAL. The advertisement of the PW configuration message is OPTIONAL.
A PE that desires to use the PW configuration message to verify the 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 of PWs on a particular LSP, should advertise its PW
configuration to the remote PE on LSPs that have active keepalive configuration to the remote PE on LSPs that have active keepalive
sessions. When a PE receives PW configuration information using this sessions. When a PE receives PW configuration information using this
protocol and it is not supporting or is not willing to use the protocol and it is not supporting or is not willing to use the
information, it MUST acknowledge all the PW configuration messages information, it MUST acknowledge all the PW configuration messages
with a notification of "PW configuration not supported". In this with a notification of "PW configuration not supported". In this
case, the information in the control messages is silently ignored. If case, the information in the control messages is silently ignored.
a PE receives such a notification it SHOULD stop sending PW If a PE receives such a notification it SHOULD stop sending PW
configuration control messages for the duration of the PW refresh configuration control messages for the duration of the PW refresh
reduction keepalive session. reduction keepalive session.
If PW configuration information is received, it is used to verify the If PW configuration information is received, it is used to verify the
accuracy of the local configuration information against the remote accuracy of the local configuration information against the remote
PE's configuration information. If a configuration mismatch is PE's configuration information. If a configuration mismatch is
detected, where a particular PW is configured locally but not on the detected, where a particular PW is configured locally but not on the
remote PE, the following action SHOULD be taken: remote PE, the following action SHOULD be taken:
-i. The local PW MUST be considered in "Not Forwarding" State. -i. The local PW MUST be considered in "Not Forwarding" State.
-ii. The PW Attachment Circuit status is set to reflect the PW -ii. The PW Attachment Circuit status is set to reflect the
fault. PW fault.
-iii. An Alarm SHOULD be raised to a network management system. -iii. An Alarm SHOULD be raised to a network management
system.
-iv. A Notification message with notification code of "PW -iv. A Notification message with notification code of "PW
configuration mismatch." MUST be sent to the remote PE. Only configuration mismatch." MUST be sent to the remote PE.
one such message is REQUIRED per configuration message even Only one such message is REQUIRED per configuration message
if the configuration message is split into multiple even if the configuration message is split into multiple
configuration messages due to individual message size configuration messages due to individual message size
restriction on a particular link. Upon receipt of such a restriction on a particular link. Upon receipt of such a
message the receiving PE MAY raise an alarm to a network message the receiving PE MAY raise an alarm to a network
management system. This alarm MAY be cleared when the management system. This alarm MAY be cleared when the
configuration is updated. configuration is updated.
6.0.4. PW ID List advertising and processing 6.1. PW ID List advertising and processing
When configuration messages are advertised along a particular LSP, When configuration messages are advertised along a particular LSP,
the PE sending the messages needs to check point the configuration the PE sending the messages needs to check point the configuration
information sent by setting the C bit when all currently known information sent by setting the C bit when all currently known
configuration information has been sent. This process allows the configuration information has been sent. This process allows the
receiving PE to immediately proceed to verify all the currently receiving PE to immediately proceed to verify all the currently
configured PWs on that LSP, eliminating the need for a long waiting configured PWs on that LSP, eliminating the need for a long waiting
period. period.
If a new PW is added to a particular LSP, the PE MUST place the 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 configuration verification of this PW on hold for a period of at
least 30 seconds. This is necessary to minimize false positive events least 30 seconds. This is necessary to minimize false positive
of mis-configuration due to the ends of the PW being slightly out of events of mis-configuration due to the ends of the PW being slightly
sync. out of sync.
7. Security Considerations 7. Security Considerations
The security considerations of [RFC6478] are adequate for the The security considerations of [RFC6478] are adequate for the
proposed mechanism since the operating environment is almost proposed mechanism since the operating environment is almost
identical to the one where this protocol would be deployed. It should identical to the one where this protocol would be deployed. It
also be noted that since this protocol is designed to be deployed should also be noted that since this protocol is designed to be
between two adjacent PEs connected by a physical link, it is not deployed between two adjacent PEs connected by a physical link, it is
possible to misdirect or inject traffic without compromising the PW not possible to misdirect or inject traffic without compromising the
transport link itself. All these situations are covered in the PW transport link itself. All these situations are covered in the
security considerations of [RFC6478]. security considerations of [RFC6478].
8. IANA Considerations 8. IANA Considerations
All the registries in this section are to be created or updated as All the registries in this section are to be created or updated as
appropriate in the Pseudowire Name Spaces (PWE3). For the allocation appropriate in the Pseudowire Name Spaces (PWE3). For the allocation
ranges designated as "vendor proprietary extensions", the respective ranges designated as "vendor proprietary extensions", the respective
IANA registry, will contain the vendor name in brackets at the end of IANA registry, will contain the vendor name in brackets at the end of
the description field. the description field.
8.1. PW Status Refresh Reduction Message Types 8.1. PW Status Refresh Reduction Message Types
IANA needs to set up a registry of "PW status refresh reduction IANA needs to set up a registry of "PW status refresh reduction
Control Messages". These are 8-bit values. Type value 1 through 2 are Control Messages". These are 8-bit values. Type value 1 through 2
defined in this document. Type values 3 through 64, and 128 through are defined in this document. Type values 3 through 64, and 128
254 are to be assigned by IANA using the "Expert Review" policy through 254 are to be assigned by IANA using the "Expert Review"
defined in RFC5226. Type values 65 through 127, 0 and 255 are to be policy defined in RFC5226. Type values 65 through 127, 0 and 255 are
allocated using the IETF review policy defined in [RFC5226]. to be allocated using the IETF review policy defined in [RFC5226].
The Type Values are assigned as follows: The Type Values are assigned as follows:
Type Message Description Type Message Description
---- ------------------- ---- -------------------
0x01 Notification message 0x01 Notification message
0x02 PW Configuration Message 0x02 PW Configuration Message
8.2. PW Configuration Message Sub-TLVs 8.2. PW Configuration Message Sub-TLVs
IANA needs to set up a registry of "PW status refresh reduction IANA needs to set up a registry of "PW status refresh reduction
Configuration Message Sub-TLVs". These are 8-bit values. Type value 1 Configuration Message Sub-TLVs". These are 8-bit values. Type value
through 3 are defined in this document. Type values 3 through 64, and 1 through 3 are defined in this document. Type values 3 through 64,
128 through 254 are to be assigned by IANA using the "Expert Review" and 128 through 254 are to be assigned by IANA using the "Expert
policy defined in RFC5226. Type values 65 through 127, 0 and 255 are Review" policy defined in RFC5226. Type values 65 through 127, 0 and
to be allocated using the IETF review policy defined in [RFC5226]. 255 are to be allocated using the IETF review policy defined in
[RFC5226].
The Type Values are assigned as follows: The Type Values are assigned as follows:
sub-TLV type Description sub-TLV type Description
------------ ----------- ------------ -----------
0x01 MPLS-TP Tunnel ID. 0x01 MPLS-TP Tunnel ID.
0x02 PW ID configured List. 0x02 PW ID configured List.
0x03 PW ID unconfigured List. 0x03 PW ID unconfigured List.
8.3. PW Status Refresh Reduction Notification Codes 8.3. PW Status Refresh Reduction Notification Codes
IANA needs to set up a registry of "PW status refresh reduction IANA needs to set up a registry of "PW status refresh reduction
Notification Codes". These are 32-bit values. Type value 0 through 7 Notification Codes". These are 32-bit values. Type value 0 through
are defined in this document. Type values 8 through 65536, and 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 134,217,729 through 4,294,967,294 are to be assigned by IANA using
the "Expert Review" policy defined in RFC5226. Type values 65536 the "Expert Review" policy defined in RFC5226. Type values 65536
through 134,217,728, 0 and 4,294,967,295 are to be allocated using through 134,217,728, 0 and 4,294,967,295 are to be allocated using
the IETF review policy defined in [RFC5226]. the IETF review policy defined in [RFC5226].
For each value assigned IANA should also track whether the value For each value assigned IANA should also track whether the value
constitutes an error as described in Section 5.1. When values are constitutes an error as described in Section 5.1. When values are
assigned by IETF review, the setting of this column must be assigned by IETF review, the setting of this column must be
documented in the RFC that requests the allocation. For Expert Review documented in the RFC that requests the allocation. For Expert
assignments, the setting of this column must be made clear by the Review assignments, the setting of this column must be made clear by
requester at the time of assignment. the requester at the time of assignment.
The Type Values are assigned as follows: The Type Values are assigned as follows:
Code Error? Description Code Error? Description
---- ------ ----------- ---- ------ -----------
0x00000000 No Null Notification. 0x00000000 No Null Notification.
0x00000001 No PW configuration mismatch. 0x00000001 No PW configuration mismatch.
0x00000002 Yes PW Configuration TLV conflict. 0x00000002 Yes PW Configuration TLV conflict.
0x00000003 No Unknown TLV (U-bit=1) 0x00000003 No Unknown TLV (U-bit=1)
0x00000004 Yes Unknown TLV (U-bit=0) 0x00000004 Yes Unknown TLV (U-bit=0)
0x00000005 No Unknown Message Type 0x00000005 No Unknown Message Type
0x00000006 No PW configuration not supported. 0x00000006 No PW configuration not supported.
0x00000007 Yes Unacknowledged control message. 0x00000007 Yes Unacknowledged control message.
8.4. PW status refresh reduction Message Flags 8.4. PW status refresh reduction Message Flags
IANA needs to set up a registry of "PW status refresh reduction IANA needs to set up a registry of "PW status refresh reduction
Message Flags". This is a 8 bit registry with the first 2 most Message Flags". This is a 8 bit registry with the first 2 most
significant bits allocated by this document as follows: significant bits allocated by this document as follows:
Bit Position Name Description Bit Position Name Description
------------ ---- ----------- ------------ ---- -----------
0 U Unknown flag bit. 0 U Unknown flag bit.
1 C Configuration flag bit. 1 C Configuration flag bit.
The remaining bits are to be allocated by "IETF Review" policy The remaining bits are to be allocated by "IETF Review" policy
defined in [RFC5226]. defined in [RFC5226].
8.5. G-ACH Registry Allocation 8.5. G-ACH Registry Allocation
IANA maintains a registry called "MPLS Generalized Associated Channel IANA maintains a registry called "MPLS Generalized Associated Channel
(G-ACh) Types". IANA needs, to allocate a new value as follows: (G-ACh) Types". IANA needs, to allocate a new value as follows:
Value Description Reference Value Description Reference
----- ----------- --------- ----- ----------- ---------
0xZZ PW Status Refresh Reduction RFCXXXX 0xZZ PW Status Refresh Reduction RFCXXXX
8.6. Guidance for Designated Experts 8.6. Guidance for Designated Experts
In all cases of review by the Designated Expert (DE) described here, In all cases of review by the Designated Expert (DE) described here,
the DE is expected to ascertain the existence of suitable the DE is expected to ascertain the existence of suitable
documentation (a specification) as described in [RFC5226] and to documentation (a specification) as described in [RFC5226] and to
verify that the document is permanently and publicly available. The verify that the document is permanently and publicly available. The
DE is also expected to check the clarity of purpose and use of the DE is also expected to check the clarity of purpose and use of the
requested code points fits the general architecture and intended requested code points fits the general architecture and intended
purpose of the respective message or TLV. Lastly the DE should check purpose of the respective message or TLV. Lastly the DE should check
that any assignment does not duplicate or conflict with work that is that any assignment does not duplicate or conflict with work that is
active or already published within the IETF. active or already published within the IETF.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner. S, "Key words for use in RFCs to [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Indicate Requirement Levels", RFC 2119, March, 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC8077] "Pseudowire Setup and Maintenance Using the Label [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
Distribution Protocol (LDP)", L. Martini, G. Heron, RFC8077, Maintenance Using the Label Distribution Protocol (LDP)",
february 2017. STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
<http://www.rfc-editor.org/info/rfc8077>.
[RFC6478] L. Martini, G. Swallow, G. Heron, M. Bocci "Pseudowire [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci,
Status for Static Pseudowires", RFC6478, May 2012 "Pseudowire Status for Static Pseudowires", RFC 6478,
DOI 10.17487/RFC6478, May 2012,
<http://www.rfc-editor.org/info/rfc6478>.
[RFC6370] M. Bocci, G. Swallow, E. Gray "MPLS-TP Identifiers", [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
RFC6370, September 2011 Profile (MPLS-TP) Identifiers", RFC 6370,
DOI 10.17487/RFC6370, September 2011,
<http://www.rfc-editor.org/info/rfc6370>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations section in RFCs", BCP 26, RFC 5226, May 2008 IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC3031] E. Rosen, et al., RFC 3031, MPLS Architecture, January [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
2001. Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.
9.2. Informative References 9.2. Informative References
[RFC5586] M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed., [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", rfc5586, June 2009 "MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<http://www.rfc-editor.org/info/rfc5586>.
10. Authors' Addresses Authors' Addresses
Luca Martini Luca Martini
Monoski LLC. Monoski LLC.
e-mail: lmartini@monoski.com e-mail: lmartini@monoski.com
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, Massachusetts 01719 Boxborough, Massachusetts 01719
United States United States
e-mail: swallow@cisco.com e-mail: swallow@cisco.com
Elisa Bellagamba Elisa Bellagamba
Ericsson EAB Ericsson EAB
Torshamnsgatan 48 Torshamnsgatan 48
16480, Stockholm 16480, Stockholm
Sweden Sweden
e-mail: elisa.bellagamba@gmail.com e-mail: elisa.bellagamba@gmail.com
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
(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
 End of changes. 139 change blocks. 
298 lines changed or deleted 335 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/