Internet DRAFT - draft-ietf-pwe3-mpls-tp-oam-config
draft-ietf-pwe3-mpls-tp-oam-config
PWE3 Working Group F. Zhang
Internet-Draft Huawei
Intended status: Standards Track B. Wu
Expires: December 29, 2014 ZTE Corporation
E. Bellagamba
Ericsson
M. Chen
Huawei
June 27, 2014
Label Distribution Protocol Extensions for Proactive Operations,
Administration and Maintenance Configuration of Dynamic MPLS Transport
Profile PseudoWire
draft-ietf-pwe3-mpls-tp-oam-config-01
Abstract
This document specifies extensions to the Label Distribution Protocol
(LDP) to configure and control proactive Operations, Administration
and Maintenance (OAM) functions, which are suitable for dynamic
Single-Segment PseudoWire (SS-PW) and Multi-Segment PseudoWire (MS-
PW).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid 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."
This Internet-Draft will expire on December 29, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Zhang, et al. Expires December 29, 2014 [Page 1]
Internet-Draft LDP Extensions for TP PW OAM June 2014
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MPLS-TP PW OAM Configuration Overview . . . . . . . . . . . . 5
3.1. OAM Configuration for MS-PW . . . . . . . . . . . . . . . 5
3.1.1. Establishment of OAM Entities and Functions . . . . . 5
3.1.2. Adjustment of OAM Parameters . . . . . . . . . . . . 6
3.1.3. Deleting OAM Entities . . . . . . . . . . . . . . . . 7
3.2. OAM Configuration for SS-PW . . . . . . . . . . . . . . . 8
4. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. MPLS-TP PW OAM Capability TLV . . . . . . . . . . . . . . 8
4.1.1. Backward Compatibility . . . . . . . . . . . . . . . 9
4.2. MPLS-TP PW OAM Administration TLV . . . . . . . . . . . . 9
4.3. MPLS-TP PW OAM Configuration TLV . . . . . . . . . . . . 10
4.3.1. BFD Configuration sub-TLV . . . . . . . . . . . . . . 11
4.3.1.1. Local Discriminator sub-TLV . . . . . . . . . . . 13
4.3.1.2. Negotiation Timer Parameters sub-TLV . . . . . . 13
4.3.1.3. BFD Authentication sub-TLV . . . . . . . . . . . 15
4.3.2. Performance Monitoring sub-TLV . . . . . . . . . . . 15
4.3.2.1. MPLS-TP PW PM Loss TLV . . . . . . . . . . . . . 16
4.3.2.2. MPLS-TP PW PM Delay TLV . . . . . . . . . . . . . 18
4.3.3. MPLS-TP PW FMS TLV . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
5.1. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.1. MPLS-TP PW OAM Configuration Sub-TLV . . . . . . . . 20
5.2. OAM Configuration Error Code . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative references . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
MultiProtocol Label Switching (MPLS) Pseudowire (PW) is defined in
[RFC3985] and [RFC5659], which provides emulated services over an
MPLS Packet Switched Network (PSN). MPLS Transport Profile (MPLS-TP)
Zhang, et al. Expires December 29, 2014 [Page 2]
Internet-Draft LDP Extensions for TP PW OAM June 2014
describes a profile of MPLS that enables operational models typical
in transport networks, while providing additional Operations,
Administration and Maintenance (OAM), survivability and other
maintenance functions not previously supported by IP/MPLS. The
corresponding requirements are defined in [RFC5860].
The MPLS-TP OAM mechanisms are described in [RFC6371], which can be
categorized into proactive and on-demand OAM. Proactive OAM refers
to OAM operations that are either configured to be carried out
periodically and continuously or preconfigured to act on certain
events such as alarm signals. In contrast, on-demand OAM is
initiated manually and for a limited amount of time, usually for
operations such as diagnostics to investigate into a defect
condition.
Normally, the Network Management System (NMS) is used to configure
these OAM functionalities when a control plane is not instantiated.
If the control plane is used, it MUST support the configuration and
modification of OAM maintenance points as well as the activation/
deactivation of OAM when the transport path or transport service is
established or modified (Requirement 51)[RFC5654].
This document defines extensions to the LDP protocol to negotiate PW
OAM capabilities, configure and bootstrap proactive PW OAM functions,
which are suitable for Point to Point (P2P) SS-PW and MS-PW. The
extensions to Point to Multi-Point (P2MP) PW will be studied in the
future.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.1. Acronyms
AC: Attachment Circuit
AIS: Alarm indication signal
BFD: Bidirectional Forwarding Detection
CC: Continuity Check
CV: Connectivity Verification
DM: Delay Measurement
Zhang, et al. Expires December 29, 2014 [Page 3]
Internet-Draft LDP Extensions for TP PW OAM June 2014
FEC: Forwarding Equivalence Class
FMS: Fault Management Signal
ICMP: Internet Control Message Protocol
G-ACh: Generic Associated Channel
LDI: Link Down Indication
LDP: Label Distribution Protocol
LKR: Lock Reporting
LM: Loss Measurement
LSP: Label Switched Path
ME: Maintenance Entity
MEG: Maintenance Entity Group
MEP: Maintenance Entity Group End Point
MIP: Maintenance Entity Group Intermediate Point
MPLS-TP: MPLS Transport Profile
MS-PW: Multi-Segment PseudoWire
NMS: Network Management System
OAM: Operations, Administration and Maintenance
P2MP: Point to Multi-Point
PE: Provider Edge
PHB: Per-Hop Behavior
PM: Performance Monitoring
PSN: Packet Switched Network
PW: Pseudowire
S-PE: Switching Provider Edge
Zhang, et al. Expires December 29, 2014 [Page 4]
Internet-Draft LDP Extensions for TP PW OAM June 2014
SPME: Sub-Path Maintenance Entity
SS-PW: Single-Segment Pseudo Wire
T-PE: Terminating Provider Edge
TLV: Type Length Value
VCCV: Virtual Circuit Connectivity Verification
3. MPLS-TP PW OAM Configuration Overview
When OAM functions are required for PWs, before starting to configure
and enable the OAM functions, the PEs SHOULD negotiate the OAM
capability when the PWs are first set up, hence to know what OAM
functions the PEs can support. To achieve this, a new LDP TLV,
MPLS-TP PW OAM Capability TLV is defined (Section 4.1), it is included
in the LDP Initialization message and used to carry the MPLS-TP PW OAM
capabilities that a PE support. So, if a PE does not receive any
MPLS-TP PW OAM Capability TLV from the remote PE, it SHOULD NOT send
the MPLS-TP PW OAM configuration information to the PE and try to
configure and enable related OAM functions.
Section 3.1 describes the general OAM configuration procedures. For
SS-PW and MS-PW, the OAM configuration procedures are mostly
identical. One exception is that SS-PW does not need to configure
the MIP function. Section 3.2 highlights the differences between the
two.
3.1. OAM Configuration for MS-PW
3.1.1. Establishment of OAM Entities and Functions
Assuming there is one PW that needs to be setup between T-PE1 and
T-PE2, across S-PE1 and S-PE2. OAM functions must be setup and
enabled in the appropriate order so that spurious alarms can be
avoided.
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| A|--------|B C|--------|D E|--------|F |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
T-PE1 S-PE1 S-PE2 T-PE2
Figure 1: MS-PW OAM Configuration Scheme
Zhang, et al. Expires December 29, 2014 [Page 5]
Internet-Draft LDP Extensions for TP PW OAM June 2014
Fist of all, T-PE1 MUST setup the OAM sink function to be prepared to
receive OAM messages but MUST suppress any OAM alarms (e.g., due to
missing or unidentified OAM messages). The Mapping message MUST be
sent with the "OAM Alarms Enabled" cleared and "OAM MIP Entities
desired" set in the MPLS-TP PW OAM Administration TLV.
When the Mapping message arrives at the downstream S-PEs, such as
S-PE1 and S-PE2, they MUST establish and configure MIP entities
according to the set "I"flag in the MPLS-TP PW OAM Administration
TLV. If failure, a Notification message SHOULD be sent, with a
Status Code set to "MIP Configuration Failure". If OAM entities are
established successfully, the middle points (S-PE1 and S-PE2) MUST
forward the Mapping message downstream, the endpoint (T-PE2) MUST set
the OAM Source function and MUST be prepared to Send OAM messages.
The same rules are applied to the reverse direction (from T-PE2 to
T-PE1), that is to say, T-PE2 needs to setup the OAM sink function to
be prepared to receive OAM messages but MUST suppress any OAM alarms
(e.g., due to missing or unidentified OAM messages). The Mapping
message MUST be sent with the "OAM Alarms Enabled" cleared, "OAM MIP
Entities desired" set in the MPLS-TP PW OAM Administration TLV. When
T-PE1 receives the Mapping message, it completes any pending OAM
configuration and enables the OAM source function to send OAM
messages.
After this, OAM entities are established and configured for the PW
and OAM messages MAY already be exchanged, and OAM alarms can now be
enabled. The T-PE nodes (T-PE1 and T-PE2), while still keeping OAM
alarms disabled send a Notification message with "OAM Alarms Enabled"
PW status flag set, and enable the OAM alarms after processing the
Notification message. At this point, data-plane OAM is fully
functional, and the MPLS-TP OAM PW configuration TLV MAY be omitted
in subsequent Notification messages
The PW MAY be setup with OAM entities right away with the first
signalling, as described above, but a PW MAY be signalled and
established without OAM configuration first, and OAM entities may be
added later. This can be done by sending a Notification message with
the related configuration parameters subsequently.
3.1.2. Adjustment of OAM Parameters
There may be a need to change the parameters of an already
established and configured OAM function during the lifetime of the
PW. To do so the T-PE nodes need to send a Notification message with
the updated parameters. OAM parameters that influence the content
and timing of OAM messages and identify the way OAM defects and
alarms are derived and generated. Hence, to avoid spurious alarms,
Zhang, et al. Expires December 29, 2014 [Page 6]
Internet-Draft LDP Extensions for TP PW OAM June 2014
it is important that both sides, OAM sink and source, are updated in
a synchronized way. Firstly, the alarms of the OAM sink function
should be suppressed and only then should expected OAM parameters be
adjusted. Subsequently, the parameters of the OAM source function
can be updated. Finally, the alarms of the OAM sink side can be
enabled again.
In accordance with the above operation, T-PE1 MUST send a
Notification message with "OAM Alarms Enabled" cleared and including
the updated MPLS-TP PW OAM Configuration TLV corresponding to the new
parameter settings. The initiator (T-PE1) MUST keep its OAM sink and
source functions running unmodified, but it MUST suppress OAM alarms
after the updated Notification message is sent. The receiver (T-PE2)
MUST firstly disable all OAM alarms, then update the OAM parameters
according to the information in the Notification message and reply
with a Notification message acknowledging the changes by including
the MPLS-TP PW OAM Configuration TLV. Note that the receiving side
has the possibility to adjust the requested OAM configuration
parameters and reply with and updated MPLS-TP PW OAM Configuration
TLV in the Notification message, reflecting the actually configured
values. However, in order to avoid an extensive negotiation phase,
in the case of adjusting already configured OAM functions, the
receiving side SHOULD NOT update the parameters requested in the
Notification message to an extent that would provide lower
performance than what has been configured previously.
The initiator (T-PE1) MUST only update its OAM sink and source
functions when it has received the Notification message from the
peer. After the OAM parameters are updated and OAM is running
according the new parameter settings, OAM alarms are still disabled,
so a subsequent Notification messages exchanges with "OAM Alarms
Enabled" flag set are needed to enable OAM alarms again.
3.1.3. Deleting OAM Entities
In some cases it may be useful to remove some or all OAM entities and
functions from one PW without actually tearing down the connection.
To avoid any spurious alarm, the following procedure should be
followed:
The T-PE nodes disable OAM alarms and SHOULD send Notification
message to each other with "OAM Alarms Enabled" cleared but unchanged
OAM configuration and without the MPLS-TP PW OAM Configuration TLV.
After that, T-PE1 (T-PE2) SHOULD delete OAM source functions, then
send a Notification message with "OAM MIP Entities desired" cleared.
While T-PE2 (T-PE1) deletes OAM sink function, S-PE1 and S-PE2 delete
MIP configuration when they receive the Notification message with
"OAM MIP Entities desired" cleared.
Zhang, et al. Expires December 29, 2014 [Page 7]
Internet-Draft LDP Extensions for TP PW OAM June 2014
Alternatively, if only some OAM functions need to be removed, the
T-PE node sends the Notification message with the updated OAM
Configuration TLV. Changes between the contents of the previously
signalled OAM Configuration TLV and the currently received TLV
represent which functions SHOULD be removed/added.
3.2. OAM Configuration for SS-PW
Assuming there is one PW that needs to be setup between T-PE1 and
T-PE2.
If the receiving PE (T-PE2) have initiated the MPLS-TP PW OAM
configuration request to the other PE (T-PE1), it MUST compare its
AII against T-PE1's. If it is numerically lower, will reply a
Notification message with the updated "MPLS-TP PW OAM Configuration
TLV", and the Status Code set to "Wrong MPLS-TP PW OAM Configuration
TLV".
On the other hand, if the T-PE2's AII is numerically higher than
T-PE1's, it MUST reply a Notification message with Status Code set to
"Rejected MPLS-TP PW OAM Configuration TLV".
4. LDP Extensions
Below, LDP extensions to configure proactive MPLS-TP PW OAM functions
are defined.
4.1. MPLS-TP PW OAM Capability TLV
A new Capability Parameter TLV called the MPLS-TP PW OAM Capability
TLV is defined, and the format is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Type (TBD) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Capability Data |F|D|L|V|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPLS-TP PW OAM Capability TLV
The value of the U-bit for the MPLS-TP PW OAM Capability TLV MUST be
set to 1 so that a receiver MUST silently ignore this TLV if unknown
to it, and continue processing the rest of the message[RFC5036].
Currently defined specific OAM Capability Flags in the "Capability
Data" field from right to left are:
Zhang, et al. Expires December 29, 2014 [Page 8]
Internet-Draft LDP Extensions for TP PW OAM June 2014
One bit "C" (31, IANA to assign) CC mode supported
One bit "V" (30, IANA to assign) CV mode supported
One bit "L" (29, IANA to assign) PM Loss supported
One bit "D" (28, IANA to assign) PM Delay supported
One bit "F" (27, IANA to assign) FMS supported
Bits 8-26: This field MUST be set to zero
on transmission and MUST be ignored on receipt.
The above bits can be set individually to indicate more than one kind
of OAM capabilities at once, and the other reserved bits MUST be set
to zero on transmission and MUST be ignored on receipt. Moreover, if
CV flag is set, the CC flag MUST be set at the same time.
The MPLS-TP PW OAM Capability TLV MAY be included by a PE in an
Initialization message to signal its peer that it supports the MPLS-
TP PW OAM Capability. If the remote peer does not support the MPLS-
TP PW OAM Capability TLV or the Initialization message sent by the
remote peer does not include the MPLS-TP PW OAM Capability TLV, the
resulting negotiation does not support MPLS-TP PW OAM capability. If
instead the negotiation supports the MPLS-TP PW OAM capability, then
the subsequent LDP Mapping message will carry the information of the
MPLS-TP PW OAM configuration.
4.1.1. Backward Compatibility
If both the two T-PEs can recognize the MPLS-TP PW OAM Capability
TLV,and CC or CV mode is supported, the BFD configuration procedure
described in this document is adopted. Otherwise, if at least one of
the two T-PEs do not support the CC or CV mode, the old VCCV BFD
[RFC5885] will be performed. In this situation, the procedure
described in [RFC5885] MUST be followed: the C and V flags of MPLS-TP
PW OAM Configuration TLV MUST NOT be set and the BFD Configuration
sub-TLV MUST NOT be carried as a sub-TLV of MPLS-TP PW OAM
Configuration TLV also.
The described behavior ensures full compatibility with the existing
implementations.
4.2. MPLS-TP PW OAM Administration TLV
The format of the MPLS-TP PW OAM Administration TLV is as follows:
Zhang, et al. Expires December 29, 2014 [Page 9]
Internet-Draft LDP Extensions for TP PW OAM June 2014
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|0| Type (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPLS-TP PW OAM Administration TLV
One bit "I" (0, IANA to assign): "OAM MIP Entities Desired" is
allocated. If the "OAM MIP entities desired" bit is set, it is
indicating that the establishment of OAM MIP entities is required at
every transit node of the signalled PW. If the establishment of a
MIP is not supported, a Notification message MUST be sent with Status
Code set to "MIP Configuration Failure".
One bit "A" (1, IANA to assign): "OAM Alarms Enabled" is allocated.
If the "OAM Alarms Enabled" bit is set, it is indicating that the
T-PE needs to enable OAM alarms.
Reserved (2-31 bits): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
4.3. MPLS-TP PW OAM Configuration TLV
The "MPLS-TP PW OAM Configuration TLV" is depicted in the following
figure. It may be carried in the Mapping and Notification messages,
just following the PW Status TLV.
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|0| Type (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|V|L|D|F| OAM Function Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPLS-TP PW OAM Configuration TLV
The "MPLS-TP PW OAM Configuration TLV" contains a number of flags
indicating which OAM functions should be activated as well as OAM
function specific sub-TLVs with configuration parameters for the
particular functions.
Zhang, et al. Expires December 29, 2014 [Page 10]
Internet-Draft LDP Extensions for TP PW OAM June 2014
Type: indicates a new type: the MPLS-TP PW OAM Configuration TLV
(IANA to assign).
Length: the length of the OAM Function Flags field including the
total length of the sub-TLVs in octets.
OAM Function Flags: a bitmap numbered from left to right as shown in
the figure.
These flags are defined in this document:
OAM Function Flag bit# Description
--------------------- ---------------------------
0 (C) Continuity Check (CC)
1 (V) Connectivity Verification (CV)
2 (L) Performance Monitoring/Loss (PM/Loss)
3 (D) Performance Monitoring/Delay (PM/Delay)
4 (F) Fault Management Signals (FMS)
5-31 Reserved (set all to 0s)
Sub-TLVs corresponding to the different flags are as follows.
o "BFD Configuration sub-TLV", which MUST be included if the CC and/
or the CV OAM Function flag is set. Furthermore, if the CV flag
is set, the CC flag MUST be set at the same time.
o "Performance Monitoring sub-TLV", which MUST be included if the
PM/Loss OAM Function flag is set.
o "MPLS-TP PW FMS sub-TLV", which MAY be included if the FMS OAM
Function flag is set. If the "MPLS-TP PW FMS sub-TLV" is not
included, default configuration values are used.
4.3.1. BFD Configuration sub-TLV
The "BFD Configuration sub-TLV is defined for BFD specific
configuration parameters, which accommodates generic BFD OAM
information and carries sub-TLVs.
Zhang, et al. Expires December 29, 2014 [Page 11]
Internet-Draft LDP Extensions for TP PW OAM June 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFD Conf. Type (1) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| PHB |N|S|I|G|U|A| Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BFD Configuration sub-TLV
Type: indicates a new type, the "BFD Configuration sub-TLV" (IANA to
define, suggested value 1).
Length: indicates the length of the TLV including sub-TLVs but
excluding the Type and Length field, in octets.
Version: identifies the BFD protocol version. If a node does not
support a specific BFD version, a Notification message MUST be
generated with Status Code set to "Unsupported OAM Version".
PHB: Identifies the Per-Hop Behavior (PHB) to be used for periodic
continuity monitoring messages.
BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD
Control Messages is enabled, when cleared it is disabled.
Symmetric session (S): If set the BFD session MUST use symmetric
timing values.
Integrity (I): If set BFD Authentication MUST be enabled. If the
"BFD Configuration sub-TLV" does not include a "BFD Authentication
sub-TLV" the authentication MUST use Keyed SHA1 with an empty pre-
shared key (all 0s).
Encapsulation Capability (G): if set, it shows the capability of
encapsulating BFD messages into G-ACh channel without IP/UDP headers.
If both the G bit and U bit are set, configuration gives precedence
to the G bit.
Encapsulation Capability (U): if set, it shows the capability of
encapsulating BFD messages into G-ACh channel with IP/UDP headers.
If both the G bit and U bit are set, configuration gives precedence
to the G bit.
Zhang, et al. Expires December 29, 2014 [Page 12]
Internet-Draft LDP Extensions for TP PW OAM June 2014
Operation mode (A): if set, it configures BFD in the associated mode.
If it is not set it configures BFD in independent mode.
Reserved: Reserved for future specification and set to 0.
The "BFD Configuration sub-TLV" MUST include the following sub-TLVs
in the Mapping message:
o "Local Discriminator sub-TLV".
o "Negotiation Timer Parameters sub-TLV" if the N flag is cleared.
4.3.1.1. Local Discriminator sub-TLV
The "Local Discriminator sub-TLV" is carried as a sub-TLV of the "BFD
Configuration sub-TLV" and is depicted below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lcl. Discr. Type (1) (IANA) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local Discriminator sub-TLV
Type: indicates a new type, the "Local Discriminator sub-TLV" (IANA
to define, suggested value 1).
Length: indicates the TLV total length in octets (4).
Local Discriminator: A unique, nonzero discriminator value generated
by the transmitting system and referring to itself, used to
demultiplex multiple BFD sessions between the same pair of systems.
4.3.1.2. Negotiation Timer Parameters sub-TLV
The "Negotiation Timer Parameters sub-TLV" is carried as a sub-TLV of
the "BFD Configuration sub-TLV" and is depicted below.
Zhang, et al. Expires December 29, 2014 [Page 13]
Internet-Draft LDP Extensions for TP PW OAM June 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timer Neg. Type (2) (IANA) | Length (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acceptable Min. Asynchronous TX interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acceptable Min. Asynchronous RX interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Echo TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Negotiation Timer Parameters sub-TLV
Type: indicates a new type, the "Negotiation Timer Parameters sub-
TLV" (IANA to define, suggested value 2).
Length: indicates the TLV total length in octets (16).
Acceptable Min. Asynchronous TX interval: in case of S (symmetric)
flag set in the "BFD Configuration" TLV, it expresses the desired
time interval (in microseconds) at which the T-PE initiating the
signalling intends to both transmit and receive BFD periodic control
packets. If the receiving T-PE can not support such value, it is
allowed to reply back with an interval greater than the one proposed.
In case of S (symmetric) flag cleared in the "BFD Configuration sub-
TLV", this field expresses the desired time interval (in
microseconds) at which T-PE intends to transmit BFD periodic control
packets in its transmitting direction.
Acceptable Min. Asynchronous RX interval: in case of S (symmetric)
flag set in the "BFD Configuration sub-TLV", this field MUST be equal
to "Acceptable Min. Asynchronous TX interval" and has no additional
meaning respect to the one described for "Acceptable Min.Asynchronous
TX interval".
In case of S (symmetric) flag cleared in the "BFD Configuration sub-
TLV", it expresses the minimum time interval (in microseconds) at
which T-PE can receive BFD periodic control packets. In case this
value is greater than the "Acceptable Min. Asynchronous TX interval"
received from the other T-PE, such T-PE MUST adopt the interval
expressed in this "Acceptable Min. Asynchronous RX interval".
Required Echo TX Interval: the minimum interval (in microseconds)
between received BFD Echo packets that this system is capable of
supporting, less any jitter applied by the sender as described in
[RFC5880] sect. 6.8.9. This value is also an indication for the
Zhang, et al. Expires December 29, 2014 [Page 14]
Internet-Draft LDP Extensions for TP PW OAM June 2014
receiving system of the minimum interval between transmitted BFD Echo
packets. If this value is zero, the transmitting system does not
support the receipt of BFD Echo packets. If the receiving system can
not support this value a Notification MUST be generated with Status
Code set to "Unsupported BFD TX Echo rate interval". By default the
value is set to 0.
4.3.1.3. BFD Authentication sub-TLV
The "BFD Authentication sub-TLV" is carried as a sub-TLV of the "BFD
Configuration sub-TLV" and is depicted below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFD Auth. Type (3) (IANA) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Key ID | Reserved (0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BFD Authentication sub-TLV
Type: indicates a new type, the "BFD Authentication sub-TLV" (IANA to
define, suggested value 3).
Length: indicates the TLV total length in octets (8).
Auth Type: indicates which type of authentication to use. The same
values as are defined in section 4.1 of [RFC5880] are used.
Auth Key ID: indicates which authentication key or password
(depending on Auth Type) should be used. How the key exchange is
performed is out of scope of this document.
Reserved: Reserved for future specification and set to 0.
4.3.2. Performance Monitoring sub-TLV
If the "MPLS-TP PW OAM Configuration TLV" has either the L (Loss), D
(Delay) flag set, the "Performance Monitoring sub-TLV" MUST be
present.
In case the values need to be different than the default ones the
"MPLS-TP PW PM Loss sub-TLV, "MPLS-TP PW PM Delay sub-TLV" MAY be
included:
o "MPLS-PW PM Loss sub-TLV" if the L flag is set in the "MPLS-TP PW
OAM Configuration TLV";
Zhang, et al. Expires December 29, 2014 [Page 15]
Internet-Draft LDP Extensions for TP PW OAM June 2014
o "MPLS-PW PM Delay sub-TLV" if the D flag is set in the "MPLS-TP PW
OAM Configuration TLV ".
The "Performance Monitoring sub-TLV" depicted below is carried as a
sub-TLV of the "MPLS-TP PW OAM Configuration TLV"
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Perf Monitoring Type (IANA)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|L|J|Y|K|C| Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Performance Monitoring sub-TLV
o D: Delay inferred/direct (0=INFERRED, 1=DIRECT)
o L: Loss inferred/direct (0=INFERRED, 1=DIRECT)
o J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE)
o Y: Dyadic (1=ACTIVE, 0=NOT ACTIVE)
o K: Loopback (1=ACTIVE, 0=NOT ACTIVE)
o C: Combined (1=ACTIVE, 0=NOT ACTIVE)
4.3.2.1. MPLS-TP PW PM Loss TLV
The "MPLS-TP PW PM Loss sub-TLV" depicted below is carried as a sub-
TLV of the "Performance Monitoring sub-TLV".
Zhang, et al. Expires December 29, 2014 [Page 16]
Internet-Draft LDP Extensions for TP PW OAM June 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PM Loss Type (1) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OTF |T|B| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measurement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPLS-TP PW PM Loss sub-TLV
Type: indicates a new type, the "MPLS-TP PW PM Loss sub-TLV" (IANA to
define, suggested value 1).
Length: indicates the length of the parameters in octets.
OTF: Origin Timestamp Format of the Origin Timestamp field described
in [RFC6374]. By default it is set to IEEE 1588 version 1.
Configuration Flags, please refer to [RFC6374] for further details:
o T: Traffic-class-specific measurement indicator. Set to 1 when
the measurement operation is scoped to packets of a particular
traffic class (DSCP value), and 0 otherwise. When set to 1, the
DS field of the message indicates the measured traffic class. By
default it is set to 1.
o B: Octet (byte) count. When set to 1, indicates that the Counter
1-4 fields represent octet counts. When set to 0, indicates that
the Counter 1-4 fields represent packet counts. By default it is
set to 0.
Measurement Interval: the time interval (in microseconds) at which LM
query messages MUST be sent on both directions. If the T-PE
receiving the Mapping message can not support such value, it can
reply back with a higher interval. By default it is set to (TBD).
Test Interval: test messages interval as described in [RFC6374]. By
default it is set to (TBD).
Loss Threshold: the threshold value of lost packets over which
protections MUST be triggered. By default it is set to (TBD).
Zhang, et al. Expires December 29, 2014 [Page 17]
Internet-Draft LDP Extensions for TP PW OAM June 2014
4.3.2.2. MPLS-TP PW PM Delay TLV
The "MPLS-TP PW PM Delay sub-TLV" depicted below is carried as a sub-
TLV of the "MPLS-TP PW OAM Configuration TLV"
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PM Delay Type (2) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OTF |T|B| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measurement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPLS-TP PW PM Delay sub-TLV
Type: indicates a new type, the "MPLS-TP PW PM Delay sub-TLV" (IANA
to define, suggested value 2).
Length: indicates the length of the parameters in octets.
OTF: Origin Timestamp Format of the Origin Timestamp field described
in [RFC6374]. By default it is set to IEEE 1588 version 1.
Configuration Flags, please refer to [RFC6374] for further details:
o T: Traffic-class-specific measurement indicator. Set to 1 when
the measurement operation is scoped to packets of a particular
traffic class (DSCP value), and 0 otherwise. When set to 1, the
DS field of the message indicates the measured traffic class. By
default it is set to 1.
o B: Octet (byte) count. When set to 1, indicates that the Counter
1-4 fields represent octet counts. When set to 0, indicates that
the Counter 1-4 fields represent packet counts. By default it is
set to 0.
Measurement Interval: the time interval (in microseconds) at which LM
query messages MUST be sent on both directions. If the T-PE
receiving the Mapping message can not support such value, it can
reply back with a higher interval. By default it is set to (TBD).
Zhang, et al. Expires December 29, 2014 [Page 18]
Internet-Draft LDP Extensions for TP PW OAM June 2014
Test Interval: test messages interval as described in [RFC6374]. By
default it is set to (TBD).
Delay Threshold: the threshold value of packet delay time over which
protections MUST be triggered. By default it is set to (TBD).
4.3.3. MPLS-TP PW FMS TLV
The "MPLS-TP PW FMS sub-TLV" depicted below is carried as a sub-TLV
of the "MPLS-TP PW OAM Configuration TLV".
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fault mgmt Type (4) (IANA) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D|L| Reserved (set to all 0s) |E| PHB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPLS-TP PW FMS sub-TLV
Type: indicates a new type, the "MPLS-TP PW FMS sub-TLV" (IANA to
define, suggested value 4).
Length: indicates the length of the parameters in octets (8).
Signal Flags: are used to enable the following signals:
o A: Alarm Indication Signal (AIS) as described in [RFC6427]
o D: Link Down Indication (LDI) as described in [RFC6427]
o L: Locked Report (LKR) as described in [RFC6427]
o Remaining bits: Reserved for future specification and set to 0.
Configuration Flags:
o E: used to enable/disable explicitly clearing faults
o PHB: identifies the per-hop behavior of packets with fault
management information
Refresh Timer: indicates the refresh timer (in microseconds) of fault
indication messages. If the T-PE receiving the Path message can not
support such value, it can reply back with a higher interval.
Zhang, et al. Expires December 29, 2014 [Page 19]
Internet-Draft LDP Extensions for TP PW OAM June 2014
5. IANA Considerations
5.1. TLV
IANA is requested to assign three new TLV types from the registry
"TLV Type Name Space" in the "Label Distribution Protocol (LDP)
Parameters" registry.
Value TLV References
----- -------- ----------
TBD1 MPLS-TP PW OAM Capability TLV this document
TBD2 MPLS-TP PW OAM Administration TLV this document
TBD3 MPLS-TP PW OAM Configuration TLV this document
5.1.1. MPLS-TP PW OAM Configuration Sub-TLV
IANA is requested to create a registry of "MPLS-TP Pseudowire OAM
Configuration Sub-TLV types". These are 16 bit values. Sub-TLV
types 1 through 8 are specified in this document. Sub-TLV types 0
and 65535 are reserved. Sub-TLV 9 through 65534 are to be assigned
by IANA, using the "Expert Review" policy defined in RFC2434.
Value Sub-TLV References
----- -------- ----------
1 BFD Configuration sub-TLV this document
2 Performance Monitoring sub-TLV this document
3 MPLS-TP PW FMS sub-TLV this document
4 Local Discriminator sub-TLV this document
5 Negotiation Timer Parameters sub-TLV this document
6 BFD Authentication sub-TLV this document
7 MPLS-TP PW PM Loss sub-TLV this document
8 MPLS-TP PW PM Loss sub-TLV this document
5.2. OAM Configuration Error Code
IANA is requested to assign the following LDP status codes from the
registry "STATUS CODE NAME SPACE" in the "Label Distribution Protocol
(LDP) Parameters" registry.
Range/Value E Description
TBD4 0 "MIP Configuration Failure"
TBD5 0 "Rejected MPLS-TP PW OAM Configuration TLV"
TBD6 0 "Wrong MPLS-TP PW OAM Configuration TLV"
TBD7 0 "Unsupported OAM Version"
TBD8 0 "Unsupported BFD TX Echo rate interval"
Zhang, et al. Expires December 29, 2014 [Page 20]
Internet-Draft LDP Extensions for TP PW OAM June 2014
6. Security Considerations
Security considerations relating to LDP are described in section 5 of
[RFC5036] and section 11 of [RFC5561]. Security considerations
relating to use of LDP in setting up PWs is described in section 8 of
[RFC4447].
This document defines new TLV/sub-TLV types, and OAM configuration
procedures intended for use with MPLS-TP, which do not raise any
additional security issues.
7. Acknowledgement
The authors would like to thank Andrew Malis, Greg Mirsky, Luca
Martini, Matthew Bocci, Thomas Nadeau for their valuable comments and
discussions, especially would like to thank Eric Gray for his review
of this document.
8. References
8.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
8.2. Informative References
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
Zhang, et al. Expires December 29, 2014 [Page 21]
Internet-Draft LDP Extensions for TP PW OAM June 2014
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
October 2009.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)", RFC 5885, June 2010.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S.,
and D. Ward, "MPLS Fault Management Operations,
Administration, and Maintenance (OAM)", RFC 6427, November
2011.
[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci,
"Pseudowire Status for Static Pseudowires", RFC 6478, May
2012.
Authors' Addresses
Fei Zhang
Huawei
Email: zhangfei7@huawei.com
Bo Wu
ZTE Corporation
Email: wu.bo@zte.com.cn
Zhang, et al. Expires December 29, 2014 [Page 22]
Internet-Draft LDP Extensions for TP PW OAM June 2014
Elisa Bellagamba
Ericsson
Farogatan 6
Kista, 164 40
Sweden
Phone: +46 761440785
Email: elisa.bellagamba@ericsson.com
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com
Attila Takacs
Ericsson
Laborc u. 1.
Budapest, 1037
Hungary
Email: attila.takacs@ericsson.com
Xuehui Dai
ZTE Corporation
Email: dai.xuehui@zte.com.cn
Min Xiao
ZTE Corporation
Email: xiao.min2@zte.com.cn
Zhang, et al. Expires December 29, 2014 [Page 23]
