Label Distribution Protocol Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire
draft-ietf-pals-mpls-tp-oam-config-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Fei Zhang , Bo Wu , Elisa Bellagamba , Mach Chen | ||
| Last updated | 2015-06-24 | ||
| Replaces | draft-ietf-pwe3-mpls-tp-oam-config | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-pals-mpls-tp-oam-config-01
Network Working Group F. Zhang, Ed.
Internet-Draft Huawei
Intended status: Standards Track B. Wu, Ed.
Expires: December 26, 2015 ZTE Corporation
E. Bellagamba, Ed.
Ericsson
M. Chen, Ed.
Huawei
June 24, 2015
Label Distribution Protocol Extensions for Proactive Operations,
Administration and Maintenance Configuration of Dynamic MPLS Transport
Profile PseudoWire
draft-ietf-pals-mpls-tp-oam-config-01
Abstract
This document defines extensions to LDP to configure proactive OAM
functions for both dynamic SS-PW and 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 26, 2015.
Copyright Notice
Copyright (c) 2015 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
Zhang, et al. Expires December 26, 2015 [Page 1]
Internet-Draft LDP Extensions for TP PW OAM June 2015
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 . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 7
3.1.3. Deleting OAM Entities . . . . . . . . . . . . . . . . 8
3.2. OAM Configuration for SS-PW . . . . . . . . . . . . . . . 8
4. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. MPLS-TP PW OAM Administration TLV . . . . . . . . . . . . 9
4.2. MPLS-TP PW OAM Configuration TLV . . . . . . . . . . . . 10
4.2.1. BFD Configuration sub-TLV . . . . . . . . . . . . . . 11
4.2.1.1. Local Discriminator sub-TLV . . . . . . . . . . . 12
4.2.1.2. Negotiation Timer Parameters sub-TLV . . . . . . 13
4.2.1.3. BFD Authentication sub-TLV . . . . . . . . . . . 14
4.2.2. Performance Monitoring sub-TLV . . . . . . . . . . . 14
4.2.2.1. MPLS-TP PW PM Loss TLV . . . . . . . . . . . . . 16
4.2.2.2. MPLS-TP PW PM Delay TLV . . . . . . . . . . . . . 17
4.2.3. MPLS-TP PW FMS sub-TLV . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5.1. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.1. MPLS-TP PW OAM Configuration Sub-TLV . . . . . . . . 19
5.1.1.1. BFD Configuration sub-TLVs . . . . . . . . . . . 19
5.1.1.2. Performance Monitoring sub-TLVs . . . . . . . . . 19
5.2. OAM Configuration Error Code . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative references . . . . . . . . . . . . . . . . . . 20
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)
describes a profile of MPLS that introduces the operational models
typically used in transport networks, while providing additional
Operations, Administration and Maintenance (OAM), survivability and
Zhang, et al. Expires December 26, 2015 [Page 2]
Internet-Draft LDP Extensions for TP PW OAM June 2015
other maintenance functions that are not previously supported by IP/
MPLS network. 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 (e.g., 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, as required in [RFC5654] (Requirement
51), 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.
This document defines extensions to the Label Distribution Protocol
(LDP) protocol to configure and bootstrap proactive PW OAM functions,
which are suitable for both Point to Point (P2P) Single-Segment
PseudoWire (SS-PW) and Multi-Segment PseudoWire (MS-PW). The
extensions to Point to Multi-Point (P2MP) PW is left for future study
and out of scope.
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
FEC: Forwarding Equivalence Class
Zhang, et al. Expires December 26, 2015 [Page 3]
Internet-Draft LDP Extensions for TP PW OAM June 2015
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
SPME: Sub-Path Maintenance Entity
Zhang, et al. Expires December 26, 2015 [Page 4]
Internet-Draft LDP Extensions for TP PW OAM June 2015
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
For SS-PW and MS-PW, the OAM configuration procedures are almost
identical. Section 3.1 describes the OAM configuration procedures
for MS-PW. Section 3.2 highlights the differences between SS-PW and
MS-PW.
3.1. OAM Configuration for MS-PW
3.1.1. Establishment of OAM Entities and Functions
Given that there is a PW that needs to be setup between T-PE1 and
T-PE2, across S-PE1 and S-PE2 (as shown below in Figure 1) . 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 Scenario
Figure 1: MS-PW OAM Configuration Scheme
Fist of all, T-PE1 MUST setup the OAM sink function and prepare to
receive OAM messages. Before the PW established, any OAM alarms MUST
be suppressed. To achieve this, a Label Mapping message MUST be sent
with the "OAM Alarms Enabled" flag cleared. If the S-PEs are
expected to establish and enable the MIP entities, the "OAM MIP
Entities desired" of the MPLS-TP PW OAM Administration TLV MUST be
set. In addition, the "OAM MEP Entities Desired" flag MUST be set,
the MPLS-TP PW OAM Configuration TLV and related sub-TLVs MUST be
included to configure and enable particular OAM functions.
On receipt of the Label Mapping message, S-PE(e.g., S-PE1) SHOULD
establish and configure MIP functions according to the "OAM MIP
Entities desired" flag in the MPLS-TP PW OAM Administration TLV. If
Zhang, et al. Expires December 26, 2015 [Page 5]
Internet-Draft LDP Extensions for TP PW OAM June 2015
the MIP functions are established and configured successfully, S-PE1
will relay the Label Mapping message downstream to the next S-PE.
Otherwise, a Label Release message MUST be replied to its upstream
adjacent PE, with a Status Code set to "MIP Configuration Failure",
and the PW will not be established. All the subsequent S-PEs along
the PW will perform the same operations as S-PE1 does until the Label
Mapping message reaches to the remote T-PE (T-PE2).
When the Mapping message arrives at the remote T-PE (T-PE2), T-PE2
MUST establish and configure OAM entities according to the
information carried in the MPLS-TP PW OAM Administration TLV and
MPLS-TP PW OAM Configuration TLV. If T-PE2 fails to establish and
configure the OAM entities, a Label Release message MUST be replied
to its upstream PE, with a Status Code set to "Fail to Establish and
Configure OAM Entities". If the OAM entities established and
configured successfully, the OAM sink and source functions MUST be
setup and the OAM sink function MUST be prepared to receive OAM
messages. Since the OAM alarm is disabled, no alarms will be
generated. The OAM source function can start to send OAM messages.
The same rules are applied to the reverse direction (from T-PE2 to
T-PE1). Specifically, T-PE2 needs to setup the OAM sink function and
prepare to receive OAM messages. OAM alarms MUST be suppressed by
sending a Label Mapping message carrying an MPLS-TP PW OAM
Administration TLV with the "OAM Alarms Enabled" cleared. When MIP
entities are desired, the "OAM MIP Entities desired" flag of the
MPLS-TP PW OAM Administration TLV MUST be set. Then S-PEs MUST
establish and configure MIP functions according to the "OAM MIP
Entities desired" flag of the MPLS-TP PW OAM Administration TLV.
When T-PE1 receives the Label Mapping message, it completes any
pending OAM configuration and enables the OAM source function to send
OAM messages.
Till now, OAM entities are established and configured for the PW and
OAM messages may already be exchanged. The OAM alarms can be safely
enabled now. The initiator PE (T-PE1) will then send another Label
Mapping message with "OAM Alarms Enabled" flag set to enable the OAM
alarm function. When T-PE2 received the Label Mapping message, it
will enable the OAM alarm and send a Label Mapping message with the
"OAM Alarms Enabled" flag set along the reverse direction to T-PE1.
Once the Label Mapping message received, T-PE1 enables the OAM alarm
function. At this point, data-plane OAM is fully functional.
The above shows how the OAM entities are established and configured
with the establishment of a PW. It's possible that a PW is
established without any OAM entities establishments and
configurations when the PW was signalled, and then the OAM entities
can be established and configured later. This can be done by sending
Zhang, et al. Expires December 26, 2015 [Page 6]
Internet-Draft LDP Extensions for TP PW OAM June 2015
another Label Mapping message with the updated configuration
parameters. The procedure is identical to the adjustment of OAM
parameters, more detail is described in Section 3.1.2.
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 achieve this, the T-PEs need to send a Label Mapping message
with the updated OAM parameters to update and adjust relevant
parameters. OAM parameters that influence the content and timing of
OAM messages and identify the way OAM defects and alarms are derived
and generated. To avoid spurious alarms, it is important that both
sides, OAM sink and source, are updated in a synchronized way. So,
firstly, the alarms of the OAM sink function should be suppressed and
only then expected OAM parameters should 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 Label
Mapping message with the "OAM Alarms Enabled" flag 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 before the updated Label Mapping message is sent.
The receiver (T-PE2) MUST firstly disable all OAM alarms, then update
the OAM parameters according to the information in the Label Mapping
message and reply with a Label Mapping 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 Label Mapping 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 Label Mapping 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 Label Mapping 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 Label Mapping messages exchanges with "OAM Alarms
Enabled" flag set are needed to enable OAM alarms again.
Zhang, et al. Expires December 26, 2015 [Page 7]
Internet-Draft LDP Extensions for TP PW OAM June 2015
3.1.3. Deleting OAM Entities
In some cases it may be useful to remove some or all OAM entities and
functions from a PW without actually tearing down the connection.
The deleting procedures are defined as below:
Firstly, the initiator PE (e.g., T-PE1) disables the OAM alarms and
sends a Label Mapping message to the remote PE (e.g., T-PE2) with the
"OAM Alarms Enabled" flag cleared but with all other OAM
configuration unchanged. Ofter receiving the acknowledgement of the
OAM alarms disable, T-PE1 will send a Label Mapping message with the
"OAM MEP Entities desired" and "OAM MIP Entities desired" flags
cleared to its adjacent PE to delete all OAM entities associated with
the PW. When the Label Mapping message finally reaches the T-PE2,
all the OAM entities associated with the PW are deleted and all
relevant data-plane and control plane resources in use by the OAM
entities and functions should be freed up.
3.2. OAM Configuration for SS-PW
For SS-PW, there is no need to establish and enable MIP entities.
This is different from the MS-PW OAM configuration mechanisms as
described above. In addition, for SS-PW, another difference is that
both ends of the PW may be the OAM configuration initiator. It is
possible that both ends will try to establish and configure the OAM
entities and functions at the same time.
If the OAM parameters and functions configured by both ends are the
same, then the configuration has converged on a mutually way and the
configuration and PW signalling are completed.
Otherwise, the configurations from both sides are different. To
resolve the confliction, the Label Switching Router (LSR) identifiers
(LSR Id) of the PEs are used as the tie breaker. That is, when the
configurations conflict, the receiving PE (e.g., T-PE2) MUST compare
its LSR Id against the initiator's (T-PE1's). If it is numerically
lower, means T-PE1's configuration has the higher priority, T-PE2
will obey the configuration requests from T-PE1 and reply a Label
Mapping message with the updated "MPLS-TP PW OAM Configuration TLV"
according to the received configuration to acknowledge the
configuration. On the other hand, if the T-PE2's LSR Id is
numerically higher than T-PE1's, it MUST reply a Label Release
message with Status Code set to "Rejected MPLS-TP PW OAM
Configuration TLV", and the PW will not be established.
Zhang, et al. Expires December 26, 2015 [Page 8]
Internet-Draft LDP Extensions for TP PW OAM June 2015
4. LDP Extensions
4.1. MPLS-TP PW OAM Administration TLV
The MPLS-TP PW OAM Administration TLV is used to configure and enable
the MEP, MIP and Alarm functions. It can be sent with the Label
Mapping message. The format of the TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type | Length(=4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Administration Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPLS-TP PW OAM Administration TLV
The MPLS-TP PW OAM Administration TLV type is TBD1.
The Length field is 2 octets in length. It defines the length in
octets of OAM Administration Flags filed, it's value is 4.
The OAM Administration Flags is a bitmap with the length of 4 octets.
This document defines the following flags:
OAM Administration Flags bit# Description
----------------------------- --------------------------------
0 OAM MIP Entities Desired
1 OAM MEP Entities Desired
2 OAM Alarms Enabled
3-31 Reserved
The "OAM MIP Entities Desired" flag is used to direct each S-PE along
the PW to establish (when set) or delete (when cleared and the OAM
MIP entity exists) the OAM MIP entity.
The "OAM MEP Entities Desired" flag is used to request the remote
T-PE to establish (when set) or delete (when cleared) the OAM
entities.
The "OAM Alarms Enabled" flag is used to request the remote T-PE to
enable (when set) or disable (when cleared) OAM alarms function.
Reserved (3-31 bits): MUST be set to zero on transmission and SHOULD
be ignored on receipt.
Zhang, et al. Expires December 26, 2015 [Page 9]
Internet-Draft LDP Extensions for TP PW OAM June 2015
4.2. MPLS-TP PW OAM Configuration TLV
The MPLS-TP PW OAM Configuration TLV is defined to configure and
enable specific OAM functions, it is carried in Label Mapping message
when used. The format of the TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 and OAM function
specific sub-TLVs with configuration parameters for particular
functions.
The MPLS-TP PW OAM Configuration TLV type is TBD2.
The Length field is 2 octets in length. It defines the length in
octets of OAM Function Flags and sub-TLVs fields.
The OAM Function Flags is a bitmap with the length of 4 octets.
This document defines the following flags:
OAM Function Flags bit# Description
--------------------- ---------------------------
0 Continuity Check (CC)
1 Connectivity Verification (CV)
2 Fault Management Signals (FMS)
3 Performance Monitoring (PM) Loss
4 Performance Monitoring (PM) Delay
5 Performance Monitoring (PM) Throughput
6-31 Reserved
The sub-TLVs corresponding to the different OAM function flags are as
follows.
o BFD Configuration sub-TLV 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.
Zhang, et al. Expires December 26, 2015 [Page 10]
Internet-Draft LDP Extensions for TP PW OAM June 2015
o Performance Monitoring sub-TLV MUST be included if the PM Loss/
Delay OAM Function flag is set.
o MPLS-TP PW FMS sub-TLV MAY be included if the FMS OAM Function
flag is set. If the MPLS-TP PW FMS sub-TLV is not included, the
default configuration values are used.
4.2.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.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| PHB |N|S|I|G|U|A| Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BFD Configuration sub-TLV
Type: The "BFD Configuration sub-TLV" type is 1.
Length: It defines the length in octets of the value field.
Version: It 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).
Zhang, et al. Expires December 26, 2015 [Page 11]
Internet-Draft LDP Extensions for TP PW OAM June 2015
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.
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.2.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) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local Discriminator sub-TLV
Type: The "Local Discriminator sub-TLV" type is 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.
Zhang, et al. Expires December 26, 2015 [Page 12]
Internet-Draft LDP Extensions for TP PW OAM June 2015
4.2.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.
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) | Length (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acceptable Min. Asynchronous TX interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acceptable Min. Asynchronous RX interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Echo TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Negotiation Timer Parameters sub-TLV
Type: The "Negotiation Timer Parameters sub-TLV" type is 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".
Zhang, et al. Expires December 26, 2015 [Page 13]
Internet-Draft LDP Extensions for TP PW OAM June 2015
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
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.2.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) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Key ID | Reserved (0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BFD Authentication sub-TLV
Type: The "BFD Authentication sub-TLV" type is 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.2.2. Performance Monitoring sub-TLV
If the "MPLS-TP PW OAM Configuration TLV" has either the PM Loss or
PM 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" and "MPLS-TP PW PM Delay sub-TLV" MUST
be included:
Zhang, et al. Expires December 26, 2015 [Page 14]
Internet-Draft LDP Extensions for TP PW OAM June 2015
o "MPLS-PW PM Loss sub-TLV" if the L flag is set in the "MPLS-TP PW
OAM Configuration TLV";
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|L|J|Y|K|C| Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Performance Monitoring sub-TLV
Type: The "Performance Monitoring sub-TLV" type is 2.
Length: indicates the TLV total length in octets.
Performance Monitoring sub-TLV has 32-bit flag field, this document
defines the following flags:
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)
o Other bits are reserved and MUST be set to 0 when sent and should
be ignored when received.
Sub-TLVs: This document defines two sub-TLVs, more detail in
following sub-sections.
Zhang, et al. Expires December 26, 2015 [Page 15]
Internet-Draft LDP Extensions for TP PW OAM June 2015
4.2.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".
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 (2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OTF |T|B| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measurement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPLS-TP PW PM Loss sub-TLV
Type: The "MPLS-TP PW PM Loss sub-TLV" type is 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).
Test Interval: test messages interval as described in [RFC6374]. By
default it is set to (TBD).
Zhang, et al. Expires December 26, 2015 [Page 16]
Internet-Draft LDP Extensions for TP PW OAM June 2015
Loss Threshold: the threshold value of lost packets over which
protections MUST be triggered. By default it is set to (TBD).
4.2.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 (3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OTF |T|B| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measurement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPLS-TP PW PM Delay sub-TLV
Type: The "MPLS-TP PW PM Delay sub-TLV" type is 3.
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 26, 2015 [Page 17]
Internet-Draft LDP Extensions for TP PW OAM June 2015
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.2.3. MPLS-TP PW FMS sub-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) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D|L| Reserved (set to all 0s) |E| PHB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPLS-TP PW FMS sub-TLV
Type: The "MPLS-TP PW FMS sub-TLV" type is 3.
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 26, 2015 [Page 18]
Internet-Draft LDP Extensions for TP PW OAM June 2015
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 Administration TLV this document
TBD2 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 [RFC5226].
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
5.1.1.1. BFD Configuration sub-TLVs
IANA is requested to create a registry of "MPLS-TP Pseudowire OAM BFD
Configuration Sub-TLV types". These are 16 bit values. Sub-TLV
types 1 through 3 are specified in this document. Sub-TLV types 0
and 65535 are reserved. Sub-TLV 4 through 65534 are to be assigned
by IANA, using the "Expert Review" policy defined in [RFC5226].
Value Sub-TLV References
----- -------- ----------
1 Local Discriminator sub-TLV this document
2 Negotiation Timer Parameters sub-TLV this document
3 BFD Authentication sub-TLV this document
5.1.1.2. Performance Monitoring sub-TLVs
IANA is requested to create a registry of "MPLS-TP Pseudowire OAM
Performance Monitoring Sub-TLV types". These are 16 bit values.
Sub-TLV types 1 through 2 are specified in this document. Sub-TLV
types 0 and 65535 are reserved. Sub-TLV 3 through 65534 are to be
Zhang, et al. Expires December 26, 2015 [Page 19]
Internet-Draft LDP Extensions for TP PW OAM June 2015
assigned by IANA, using the "Expert Review" policy defined in
[RFC5226].
Value Sub-TLV References
----- -------- ----------
1 MPLS-TP PW PM Loss TLV this document
2 MPLS-TP PW PM Delay 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
----------- ----- -------------------
TBD3 0 "MIP Configuration Failure"
TBD4 0 "Rejected MPLS-TP PW OAM Configuration TLV"
TBD5 0 "Fail to Establish and Congfigure OAM Entities"
TBD6 0 "Unsupported OAM Version"
TBD7 0 "Unsupported BFD TX Echo rate interval"
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.
Zhang, et al. Expires December 26, 2015 [Page 20]
Internet-Draft LDP Extensions for TP PW OAM June 2015
[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.
8.2. Informative References
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[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.
[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.
Zhang, et al. Expires December 26, 2015 [Page 21]
Internet-Draft LDP Extensions for TP PW OAM June 2015
Authors' Addresses
Fei Zhang (editor)
Huawei
Email: zhangfei7@huawei.com
Bo Wu (editor)
ZTE Corporation
Email: wu.bo@zte.com.cn
Elisa Bellagamba (editor)
Ericsson
Farogatan 6
Kista, 164 40
Sweden
Phone: +46 761440785
Email: elisa.bellagamba@ericsson.com
Mach(Guoyi) Chen (editor)
Huawei
Email: mach.chen@huawei.com
Zhang, et al. Expires December 26, 2015 [Page 22]