Internet DRAFT - draft-ietf-pals-mpls-tp-oam-config
draft-ietf-pals-mpls-tp-oam-config
Network Working Group F. Zhang, Ed.
Internet-Draft Huawei
Intended status: Standards Track B. Wu, Ed.
Expires: January 21, 2016 ZTE Corporation
E. Bellagamba, Ed.
Ericsson
M. Chen, Ed.
Huawei
July 20, 2015
LDP Extensions for Proactive Operations, Administration and Maintenance
Configuration of Dynamic MPLS Transport Profile PseudoWire
draft-ietf-pals-mpls-tp-oam-config-03
Abstract
This document defines extensions to LDP to configure proactive OAM
functions for both SS-PW and MS-PW when the PW control plane is used.
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 January 21, 2016.
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
to this document. Code Components extracted from this document must
Zhang, et al. Expires January 21, 2016 [Page 1]
Internet-Draft LDP Extensions for TP PW OAM July 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
3. PW OAM Configuration . . . . . . . . . . . . . . . . . . . . 5
3.1. OAM Configuration for SS-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 MS-PW . . . . . . . . . . . . . . . 8
3.2.1. Establishment of OAM Entities and Functions . . . . . 9
3.2.2. Adjustment of OAM Parameters . . . . . . . . . . . . 10
3.2.3. Deleting OAM Entities . . . . . . . . . . . . . . . . 12
4. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. PW OAM Administration TLV . . . . . . . . . . . . . . . . 12
4.2. PW OAM Functions TLV . . . . . . . . . . . . . . . . . . 13
4.2.1. BFD Configuration sub-TLV . . . . . . . . . . . . . . 15
4.2.1.1. Local Discriminator sub-TLV . . . . . . . . . . . 16
4.2.1.2. Negotiation Timer Parameters sub-TLV . . . . . . 17
4.2.1.3. BFD Authentication sub-TLV . . . . . . . . . . . 18
4.2.1.4. Traffic Class Sub-TLV . . . . . . . . . . . . . . 19
4.2.2. Performance Monitoring sub-TLV . . . . . . . . . . . 20
4.2.2.1. PM Loss Sub-TLV . . . . . . . . . . . . . . . . . 21
4.2.2.2. PM Delay Sub-TLV . . . . . . . . . . . . . . . . 23
4.2.3. Fault Management Signal Sub-TLV . . . . . . . . . . . 24
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
5.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.1. PW OAM Configuration Sub-TLV . . . . . . . . . . . . 26
5.1.1.1. BFD Configuration sub-TLVs . . . . . . . . . . . 26
5.1.1.2. Performance Monitoring sub-TLVs . . . . . . . . . 26
5.2. OAM Configuration Status Code . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative references . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
There are two documents that define MultiProtocol Label Switching
(MPLS) Pseudowire (PW). [RFC3985] defines Single Segment PW (SS-PW)
and [RFC5659] defines Multi-Segment PW (MS-PW). The two documents
Zhang, et al. Expires January 21, 2016 [Page 2]
Internet-Draft LDP Extensions for TP PW OAM July 2015
explain how to provide emulated services over an MPLS Packet Switched
Network (PSN). The MPLS Transport Profile (MPLS-TP) is described in
[RFC5291], which describes a profile of MPLS that introduces the
operational models that were typically used in transport networks,
while providing additional Operations, Administration and Maintenance
(OAM), survivability and other maintenance functions that were not
previously supported by IP/MPLS network. The MPLS-TP 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.
When a control plane is not used the OAM functions are typically
configured from the Network Management System (NMS). When a control
plane is used, requirement 51 in [RFC5654] requires that it MUST be
able to support configuration of the OAM functions. The control
plane is also required to be able to configure, maintain and modify,
as well as activation/deactivation of maintenance points.
For MPLS-TP OAM configuration, two companion documents exists.
[RFC7260] and [RFC7487] define extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) to support the establishment
and configuration of OAM entities along with Label Switched Path
(LSP) signaling. [I-D.ietf-mpls-lsp-ping-mpls-tp-oam-conf] defines
extensions to LSP Ping [RFC4379] to support the configuration of
proactive MPLS-TP OAM functions.
This document defines extensions to the Label Distribution Protocol
(LDP) to configure proactive MPLS-TP PW OAM functions for both Point
to Point SS-PW and MS-PW when the PW control plane is used. The
extensions defined in this document are aligned with those companion
documents. Extensions to Point to Multi-Point (P2MP) PW are for
future study and outside the scope of this document.
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].
Zhang, et al. Expires January 21, 2016 [Page 3]
Internet-Draft LDP Extensions for TP PW OAM July 2015
2.1. Acronyms
AIS: Alarm indication signal
BFD: Bidirectional Forwarding Detection
CC: Continuity Check
CV: Connectivity Verification
DM: Delay Measurement
FEC: Forwarding Equivalence Class
FMS: Fault Management Signal
G-ACh: Generic Associated Channel
LDI: Link Down Indication
LDP: Label Distribution Protocol
LM: Loss Measurement
LSP: Label Switched Path
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
Zhang, et al. Expires January 21, 2016 [Page 4]
Internet-Draft LDP Extensions for TP PW OAM July 2015
PW: Pseudowire
S-PE: Switching Provider Edge
SS-PW: Single-Segment Pseudo Wire
T-PE: Terminating Provider Edge
TLV: Type Length Value
3. PW OAM Configuration
This document defines two new TLVs, the PW OAM Administration TLV and
the PW OAM Functions TLV.
The PW OAM Administrations TLV is used to setup/remove MIP and MEP
functions and to control whether OAM alarm function should be
suppressed or not.
The PW OAM Functions TLV is used to configure, enable and disable OAM
functions that include Continuity Check (CC), Connectivity
Verification (CV), Packet Loss/Delay/Throught and PM and Fault
Management Signal(FMS). More details about the new TLVs can be found
in Section 4.
3.1. OAM Configuration for SS-PW
3.1.1. Establishment of OAM Entities and Functions
OAM entities and functions can be setup, configured and activated
either when the PW first is signalled or on an already established
PW. This section describes how the OAM entities and functions are
setup and configured with the signalling of a PW.
For the case where OAM entities and functions are setup and
configured after establishment of a PW, the procedures are identical
to the "adjustment of OAM parameters" procedures, more detail can be
found in Section 3.1.2.
Given that a SS-PW needs to be setup between PE1 and PE2 (see
Figure 1) . OAM functions MUST be setup and enabled in the
appropriate order so that spurious alarms can be avoided.
Zhang, et al. Expires January 21, 2016 [Page 5]
Internet-Draft LDP Extensions for TP PW OAM July 2015
+-------+ +-------+
| | | |
| |---------------| |
| | | |
+-------+ +-------+
PE1 PE2
Figure 1 SS-PW OAM Configuration Scheme
Figure 1: SS-PW OAM Configuration Scheme
Fist, the ingress PE (e.g., PE1) must setup the OAM sink function and
prepare to receive OAM messages. Until the PW is fully established,
any OAM alarm SHOULD be suppressed.
To achieve this, a Label Mapping message with the "OAM Alarms
Enabled" flag cleared is sent. In the message, the "OAM MEP Entities
Desired" flag is set. Since there is no MIPs for a SS-PW, the "OAM
MIP Entities desired" flag MUST be cleared. In addition, to
configure and enable particular OAM functions, the PW OAM Functions
TLV and relevant sub-TLVs MUST be included.
When the Label Mapping message is received by PE2, PE2 needs to check
whether it supports the requested OAM configuration. If it does not
support the requested OAM configuration, a Label Release message MUST
be returned to PE1, with a Status Code set to "PW OAM Parameters
Rejected". The PW signalling is complete and the PW will not be
established. If the requested OAM parameters and configuration are
supported, PE2 will establish and configure the requested OAM
entities.
If PE2 fails to establish and configure the OAM entities, a Label
Release message will be returned to PE1, with a Status Code set to
"PW MEP Configuration Failed". The PW signalling is complete and the
PW will not be established.
If the OAM entities are setup and configured successfully, the OAM
sink and source functions is setup and the OAM sink function will be
configured 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. PE2 will then
reply a Label Mapping message to PE1, the PW OAM Administration TLV
and PW OAM Configuration TLV from the received Label Mapping message
MUST be copied and carried in the Label Mapping message.
Zhang, et al. Expires January 21, 2016 [Page 6]
Internet-Draft LDP Extensions for TP PW OAM July 2015
When PE1 receives this Label Mapping message, PE1 completes any
pending OAM configuration and enables the OAM source function to send
OAM messages.
For PE1, the OAM entities and functions are now setup and configured,
and OAM messages may be exchanged. The OAM alarms can be safely
enabled. The initiator PE (PE1) will send another Label Mapping
message with "OAM Alarms Enabled" flag set to PE2, this will allow
PE2 to enable the OAM alarm function.
When the Label Mapping message is received by PE2, the OAM alarm will
be enabled. PE2 then sends a Notification message with the Status
Code set to "PW OAM Alarms enabled" to PE1.
When the Notification message is received by PE1, PE1 enables the OAM
alarm function. At this point, data-plane OAM is fully functional.
3.1.2. Adjustment of OAM Parameters
Existing OAM parameters may be changed during the life time of a PW.
To achieve this, PE1 sends a Label Mapping message with the updated
OAM parameters to PE2.
To avoid spurious alarms, it is important that OAM sink and source
functions on both PEs are updated in a synchronized way. First, the
alarms of the OAM sink function should be suppressed. After that,
new OAM parameters can be adjusted. Subsequently, the parameters of
the OAM source function can be updated. Finally, the alarms can be
enabled again.
Consequently, the ingress PE needs to keep its OAM sink and source
functions running without any changes until the OAM parameters are
updated. However, in order to suppress spurious alarms, it also need
to disable the alarm functions before the Label Mapping message, with
the "OAM Alarms Enabled" flag cleared and the updated PW OAM Function
TLV, is sent. The OAM alarm function needs to be disabled until the
corresponding response message is received.
On receipt of the Label Mapping message, PE2 needs to check whether
the updated parameters can be supported. If they can be supported,
PE2 needs first disable the OAM alarms firstly and then update the
OAM parameters. When the update is done, a Notification message
needs to be sent to PE1, with the Status Code set to "PW MEP
Configuration Succeed", to acknowledge the update. If PE2 can not
support the update, a Notification message with Status Code set to
"PW OAM Parameters Rejected" will be sent to PE1.
Zhang, et al. Expires January 21, 2016 [Page 7]
Internet-Draft LDP Extensions for TP PW OAM July 2015
When PE1 receives the Notification message with the Status Code set
to "PW MEP Configuration Succeed", PE1 will update using the new OAM
parameters. After the OAM parameters are updated and the OAM is
running with the new parameter settings, OAM alarms are still
disabled. A subsequent Label Mapping message with "OAM Alarms
Enabled" flag set will be sent to re-enable OAM alarms. If the
Status Code of the received Notification message is "PW OAM
Parameters Rejected", it will not update the OAM parameters. The OAM
alarms are just enabled again and the OAM will keep running with the
old parameters. PE1 can also re-try changing the OAM parameters
using a different set of parameters.
When PE2 received the Label Mapping message with "OAM Alarms Enabled"
flag set, it will enable the OAM alarms and reply a Notification
message with Status Code set to "PW OAM Alarms Enabled". When
received the Notification message, PE1 will enable the OAM alarms
again.
3.1.3. Deleting OAM Entities
In some cases it may be useful to remove all OAM entities and
functions from a PW without actually tearing down the connection.
The deleting procedures are defined as below:
First, the ingress PE (e.g., PE1) disables its own the OAM alarms and
then sends a Label Mapping message to the remote PE (e.g., PE2) with
the "OAM Alarms Enabled" flag set but with all other OAM
configurations unchanged.
When received the Label Mapping message, PE2 disables the OAM alarm
and then send a Notification message with Status Code set to "PW OAM
Alarms Disabled" to PE1.
When received the confirmation from PE2, it's safe to delete the OAM
entities. PE1 will delete the OAM entities related to the PW and
send another Label Mapping message with the "OAM MEP Entities
desired" flag cleared to PE2.
When PE2 received the Label Mapping message, it will delete all OAM
entities related to the PW and then reply a Notification message with
the Status Code set to "PW MEP Entities Disabled" to PE1.
3.2. OAM Configuration for MS-PW
Zhang, et al. Expires January 21, 2016 [Page 8]
Internet-Draft LDP Extensions for TP PW OAM July 2015
3.2.1. Establishment of OAM Entities and Functions
Given that a MS-PW needs to be setup between T-PE1 and T-PE2, across
S-PE1 and S-PE2 (see Figure 2) . 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 2 MS-PW Scenario
Figure 2: MS-PW OAM Configuration Scheme
Fist, T-PE1 must setup the OAM sink function and prepare to receive
OAM messages. Until the PW is fully established, any OAM alarm
SHOULD be suppressed.
To achieve this, a Label Mapping message with the "OAM Alarms
Enabled" flag cleared is sent. If the S-PEs are expected to setup
and configure the MIP entities, the "OAM MIP Entities desired" flag
MUST be set. In the message, the "OAM MEP Entities Desired" flag is
set. In addition, to configure and enable particular OAM functions,
the PW OAM Functions TLV and relevant sub-TLVs MUST be included.
On receipt of the Label Mapping message, S-PE(e.g., S-PE1) needs to
check whether it supports MIP function. If S-PE1 does not support
MIP function, a Notification message will be sent to T-PE1, with the
Status Code set to "PW MIP Configuration Failed". If S-PE1 supports
MIP function, it will establish and configure the MIP entities
according to the "OAM MIP Entities desired" flag in the PW OAM
Administration TLV. No matter whether S-PE1 supports MIP function,
it will relay the Label Mapping message downstream to the next S-PE.
All the subsequent S-PEs along the PW will perform the same
operations as S-PE1 does until the Label Mapping message reaches the
remote T-PE (T-PE2).
When the Label Mapping message is received by the remote T-PE
(T-PE2), T-PE2 needs to check whether it support the requested OAM
configuration. If it does not support the requested OAM
configuration, a Label Release message MUST be returned to its
upstream PE, with a Status Code set to "PW MEP Configuration Failed".
The signalling is complete and the PW will not be established. If
Zhang, et al. Expires January 21, 2016 [Page 9]
Internet-Draft LDP Extensions for TP PW OAM July 2015
the requested OAM parameters and configuration are supported, T-PE2
will establish and configure requested OAM entities.
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 "PW MEP Configuration Failed". The signalling is
complete and the PW will not be established.
If the OAM entities established and configured successfully, the OAM
sink and source functions are setup and the OAM sink function will be
configured 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. T-PE2 will then reply a Label Mapping message,
the PW OAM Administration TLV and PW OAM Function TLV from the
received Label Mapping message MUST be copied and carried in the
returned Label Mapping message.
S-PEs will relay the Label Mapping message upstream until it reaches
T-PE1. When the Label Mapping message is received by T-PE1, T-PE1
will complete any pending OAM configuration and enables the OAM
source function to send OAM messages.
For T-PE1, the OAM entities and functions are now setup and
configured, and OAM messages may be exchanged. The OAM alarms can be
safely enabled. T-PE1 will send another Label Mapping message with
"OAM Alarms Enabled" flag set to enable the OAM alarm function.
When the Label Mapping message is received by S-PEs, S-PEs will
enable the OAM alarm and relay the Label Mapping message downstream
until it reaches T-PE2.
When the Label Mapping message is received by T-PE2, the OAM alarm
will be enabled. T-PE2 then sends a Notification message to T-PE1,
with the Status Code set to "PW OAM Alarms Enabled". Once the
Notification message is received by T-PE1, T-PE1 enables the OAM
alarm function. At this point, data-plane OAM is fully functional.
3.2.2. Adjustment of OAM Parameters
Existing OAM parameters may be changed during the life time of a PW.
To achieve this, the T-PE1 needs to send a Label Mapping message with
the updated OAM parameters to adjust and update OAM parameters.
To avoid spurious alarms, it is important that OAM sink and source
functions on both sides are updated in a synchronized way. Fist, the
alarms of the OAM sink function should be suppressed. After that,
new OAM parameters can be adjusted. Subsequently, the parameters of
Zhang, et al. Expires January 21, 2016 [Page 10]
Internet-Draft LDP Extensions for TP PW OAM July 2015
the OAM source function can be updated. Finally, the alarms can be
enabled again.
Consequently, T-PE1 needs to keep its OAM sink and source functions
running without any changes until the OAM parameters are updated.
However, in order to suppress spurious alarms, it also need to
disable the alarm functions before the Label Mapping message, with
the "OAM Alarms Enabled" flag cleared and the updated PW OAM Function
TLV, is sent. The OAM alarm function needs to be disabled until the
corresponding response message is received.
When the Label Mapping message is received by S-PEs, each S-PE just
disables the OAM alarm and relay the Label Mapping message downstream
until the Label Mapping message reaches the remote T-PE (T-PE2).
On receipt of the Label Mapping message, T-PE2 needs to check whether
the updated parameters can be supported. If they can be supported,
T-PE2 needs first disable the OAM alarms and then update the OAM
parameters. When the update is done, a Notification message needs to
be sent to T-PE1, with the Status Code set to "PW MEP Configuration
Succeed", to acknowledge the update. If T-PE2 can not support the
update, a Notification message with Status Code set to "PW OAM
Parameters Rejected" will be sent T-PE1.
When T-PE1 receives the Notification message with the Status Code set
to "PW MEP Configuration Succeed", T-PE1 will update using the new
OAM parameters. After the OAM parameters are updated and the OAM is
running with the new parameter settings, OAM alarms are still
disabled. A subsequent Label Mapping message with "OAM Alarms
Enabled" flag set will be sent to re-enable OAM alarms. If the
Status Code of the received Notification message is "PW OAM
Parameters Rejected", it will not update the OAM parameters. The OAM
alarms are just enabled again and the OAM will keep running with the
old parameters. T-PE1 can also re-try changing the OAM parameters
using a different set of parameters.
When S-PEs receives the Label Mapping message, they will enable the
OAM alarms and relay the Label Mapping message downstream.
When T-PE2 receives the Label Mapping message with the "OAM Alarms
Enabled" flag set, it will enable the OAM alarms and reply a
Notification message with Status Code set to "PW OAM Alarms Enabled".
When received the Notification message, T-PE1 will enable the OAM
alarms again.
Zhang, et al. Expires January 21, 2016 [Page 11]
Internet-Draft LDP Extensions for TP PW OAM July 2015
3.2.3. Deleting OAM Entities
In some cases it may be useful to remove all OAM entities and
functions from a PW without actually tearing down the connection.
The deleting procedures are defined as below:
First, T-PE1disables its own the OAM alarms and then 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 configurations
unchanged.
When received the Label Mapping message, S-PEs will disable the OAM
alarm and relay the Mapping message downstream until the Label
Mapping message reaches the remote T-PE (T-PE2).
When received the Label Mapping message, T-PE2 will disable the OAM
alarm and then reply a Notification message with Status Code set to
"PW OAM Alarms Disabled" to T-PE1.
When received the confirmation from T-PE2, it's safe to delete the
OAM entities. T-PE1 will delete the all OAM entities associated with
the PW and send another Label Mapping message with both the "OAM MEP
Entities desired" and "OAM MIP Entities desired" flags cleared to the
remote T-PE.
When received the Label Mapping message, S-PE (e.g., S-PE1) will
delete all the OAM entities associated with the PW and relay the
Label Mapping message downstream. Subsequent S-PEs will do the same
operations until the Label Mapping message reaches the remote T-PE.
When T-PE2 receives the Label Mapping message, it will delete all OAM
entities associated with the PW and then reply a Notification message
with the Status Code set to "PW MEP Entities Disabled" to T-PE1.
4. LDP Extensions
4.1. PW OAM Administration TLV
The 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:
Zhang, et al. Expires January 21, 2016 [Page 12]
Internet-Draft LDP Extensions for TP PW OAM July 2015
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PW OAM Administration TLV
The 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 the S-PE(s)
along a PW to establish (when set) or delete (when cleared ) the OAM
MIP entities. This flag only applies to MS-PW scenario. For SS-PW
case, this flag MUST be cleared when sent, and SHOULD be ignored when
received.
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 received PEs 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.
4.2. PW OAM Functions TLV
The PW OAM Functions 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:
Zhang, et al. Expires January 21, 2016 [Page 13]
Internet-Draft LDP Extensions for TP PW OAM July 2015
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PW OAM Functions TLV
The PW OAM Functions 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 PW OAM Functions 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 as well.
o Performance Monitoring sub-TLV MUST be included if the PM Loss/
Delay OAM Function flag is set.
o Fault Management Signal (FMS) sub-TLV MAY be included if the FMS
OAM Function flag is set. If the Fault Management Signal sub-TLV
is not included, the default configuration values are used.
Zhang, et al. Expires January 21, 2016 [Page 14]
Internet-Draft LDP Extensions for TP PW OAM July 2015
4.2.1. BFD Configuration sub-TLV
The BFD Configuration Sub-TLV (depicted below) is defined for BFD-
OAM-specific configuration parameters. The BFD Configuration Sub-TLV
is carried as a sub-TLV of the PW OAM Functions TLV.
This sub-TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFD Conf. Type (1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.|N|S|I|G|U|B| Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BFD Configuration sub-TLV
Type: indicates a new type, the BFD Configuration Sub-TLV (suggested
value 1).
Length: Indicates the length of the Value field in octets.
Version: Identifies the BFD protocol version. If the egress LSR does
not support the version, a Notification message MUST be generated,
with the Status Code set to "OAM Problem/ Unsupported BFD Version".
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). If the egress LSR does not support BFD Authentication,
an Notification message MUST be generated, with Status Code set to
"OAM Problem/BFD Authentication unsupported".
Encapsulation Capability (G): If set, it shows the capability of
encapsulating BFD messages into The G-Ach channel. If both the G bit
and U bit are set, configuration gives precedence to the G bit. If
Zhang, et al. Expires January 21, 2016 [Page 15]
Internet-Draft LDP Extensions for TP PW OAM July 2015
the egress LSR does not support any of the ingress LSR Encapsulation
Capabilities, an Notification message MUST be generated, with the
Status Code set to "OAM Problem/Unsupported BFD Encapsulation
format".
Encapsulation Capability (U): If set, it shows the capability of
encapsulating BFD messages into UDP packets. If both the G bit and U
bit are set, configuration gives precedence to the G bit. If the
egress LSR does not support any of the ingress LSR Encapsulation
Capabilities, a Notification message MUST be generated, with the
Status Code set to "OAM Problem/Unsupported BFD Encapsulation
Format".
Bidirectional (B): If set, it configures BFD in the Bidirectional
mode. If it is not set, it configures BFD in unidirectional mode.
In the second case, the source node does not expect any Discriminator
values back from the destination node.
Reserved: Reserved for future specifications; set to 0 on
transmission and ignored when received.
The BFD Configuration Sub-TLV MUST include the following sub-TLVs in
the Label Mapping message:
o BFD Identifiers Sub-TLV; and
o Negotiation Timer Parameters Sub-TLV if the N flag is cleared.
The BFD Configuration Sub-TLV MUST include the following sub-TLVs in
the "response" Label Mapping message:
o BFD Identifiers Sub-TLV; and
o Negotiation Timer Parameters Sub-TLV if:
* the N and S flags are cleared; or if
* the N flag is cleared and the S flag is set and the Negotiation
Timer Parameters Sub-TLV received by the egress contains
unsupported values. In this case, an updated Negotiation Timer
Parameters Sub-TLV containing values supported by the egress
LSR MUST be returned to the ingress.
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.
Zhang, et al. Expires January 21, 2016 [Page 16]
Internet-Draft LDP Extensions for TP PW OAM July 2015
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
(suggested value 1).
Length: indicates the length of the Value field 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.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) (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
(suggested value 2).
Length: indicates the length of the Value field in octets (12).
Acceptable Min. Asynchronous TX interval: in case of S (symmetric)
flag set in the BFD Configuration sub-TLV, defined in Section 4.2.1,
it expresses the desired time interval (in microseconds) at which the
ingress PE intends to both transmit and receive BFD periodic control
Zhang, et al. Expires January 21, 2016 [Page 17]
Internet-Draft LDP Extensions for TP PW OAM July 2015
packets. If the receiving PE cannot support such value, it SHOULD
reply 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-PEs can receive BFD periodic control packets. In case this
value is greater than the value of Acceptable Min. Asynchronous TX
interval received from the other edge LSR, 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
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
cannot support this value, a Notification message MUST be generated,
with the 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) (IANA) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Key ID | Reserved (0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BFD Authentication sub-TLV
Zhang, et al. Expires January 21, 2016 [Page 18]
Internet-Draft LDP Extensions for TP PW OAM July 2015
Type: indicates a new type, the BFD Authentication sub-TLV (suggested
value 3).
Length: indicates the length of the Value field in octets (4).
Auth Type: indicates which type of authentication to use. The same
values as are defined in section 4.1 of [RFC5880] are used. If the
egress PE does not support this type, an Notification message MUST be
generated, with the Status Code set to "OAM Problem/Unsupported BFD
Authentication Type".
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. If the egress PE does
not support this Auth Key ID, a Notification message MUST be
generated, with the Status Code set to "OAM Problem/Mismatch of BFD
Authentication Key ID".
Reserved: Reserved for future specification and set to 0 on
transmission and ignored when received.
4.2.1.4. Traffic Class Sub-TLV
The Traffic Class sub-TLV is carried as a sub-TLV of the BFD
Configuration sub-TLV or Fault Management Signal sub-TLV
(Section 4.2.3) and is depicted as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Class sub-Type (104) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TC | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type, the Traffic Class sub-TLV (suggested
value 4).
Length: Indicates the length of the Value field in octets (4).
Traffic Class (TC): Identifies the TC [RFC5462] for periodic
continuity monitoring messages or packets with fault management
information. If the Traffic Class sub-TLV is present, then the value
of the TC field MUST be used as the value of the TC field of an MPLS
label stack entry. If the Traffic Class sub-TLV is absent from BFD
Configuration sub-TLV or Fault Management Signal sub-TLV, then
selection of the TC value is a local decision.
Zhang, et al. Expires January 21, 2016 [Page 19]
Internet-Draft LDP Extensions for TP PW OAM July 2015
4.2.2. Performance Monitoring sub-TLV
If the PW OAM Functions TLV has either the L (Loss), D (Delay) or T
(Throughput) flag set, the Performance Measurement sub-TLV MUST be
present. Failure to include the correct sub-TLVs MUST result in a
Notification message (with the Status Code set to "OAM Problem/
Configuration Error") being generated. The Performance Measurement
sub-TLV provides the configuration information mentioned in Section 7
of [RFC6374]. It includes support for the configuration of quality
thresholds and, as described in [RFC6374], "the crossing of which
will trigger warnings or alarms, and result reporting and exception
notification will be integrated into the system-wide network
management and reporting framework." In case the values need to be
different than the default ones the Performance Measurement sub-TLV
MAY include the following sub-TLVs:
o "MPLS-PW PM Loss sub-TLV" if the L flag is set in the "PW OAM
Functions TLV";
o "MPLS-PW PM Delay sub-TLV" if the D flag is set in the "PW OAM
Functions TLV ".
The "Performance Monitoring sub-TLV" depicted below is carried as a
sub-TLV of the "PW OAM Functions 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
Sub-type: indicates a new sub-type, the Performance Management sub-
TLV (suggested value 2).
Length: indicates the length of the Value field in octets (4).
Configuration Flags, for the specific function description please
refer to [RFC6374]:
o D: Delay inferred/direct (0=INFERRED, 1=DIRECT). If the egress
LSR does not support specified mode, a Notification message MUST
Zhang, et al. Expires January 21, 2016 [Page 20]
Internet-Draft LDP Extensions for TP PW OAM July 2015
be generated, with the Status Code set to "OAM Problem/Unsupported
Delay Mode".
o L: Loss inferred/direct (0=INFERRED, 1=DIRECT). If the egress LSR
does not support specified mode, a Notification message MUST be
generated, with the Status Code set to "OAM Problem/Unsupported
Loss Mode".
o J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE). If the egress
LSR does not support Delay variation measurements and the J flag
is set, a Notification message MUST be generated, with the Status
Code set to "OAM Problem/Delay variation unsupported".
o Y: Dyadic (1=ACTIVE, 0=NOT ACTIVE). If the egress LSR does not
support Dyadic mode and the Y flag is set, a Notification message
MUST be generated, with the Status Code set to "OAM Problem/Dyadic
mode unsupported".
o K: Loopback (1=ACTIVE, 0=NOT ACTIVE). If the egress LSR does not
support Loopback mode and the K flag is set, a Notification
message MUST be generated, with the Status Code set to "OAM
Problem/ Loopback mode unsupported".
o C: Combined (1=ACTIVE, 0=NOT ACTIVE). If the egress LSR does not
support Combined mode and the C flag is set, a Notification
message MUST be generated, with the Status Code set to "OAM
Problem/ Combined mode unsupported".
Reserved: Reserved for future specification and set to 0 on
transmission and ignored when received.
4.2.2.1. PM Loss Sub-TLV
The PM Loss sub-TLV depicted below is carried as a sub-TLV of the
Performance Monitoring sub-TLV.
Zhang, et al. Expires January 21, 2016 [Page 21]
Internet-Draft LDP Extensions for TP PW OAM July 2015
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PM Loss sub-TLV
Type: indicates a new type, the PM Loss sub-TLV (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. If the
egress PE cannot support this value, a Notification message MUST be
generated, with the Status Code set to "OAM Problem/Unsupported
Timestamp Format".
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 (100) as
per [RFC6375]..
Test Interval: test messages interval as described in [RFC6374]. By
default it is set to (10) as per [RFC6375].
Zhang, et al. Expires January 21, 2016 [Page 22]
Internet-Draft LDP Extensions for TP PW OAM July 2015
Loss Threshold: the threshold value of measured lost packets per
measurement over which action(s) SHOULD be triggered.
4.2.2.2. PM Delay Sub-TLV
The PM Delay sub-TLV depicted below is carried as a sub-TLV of the PW
OAM Functions 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PM Delay sub-TLV
Type: indicates a new type, the PM Delay sub-TLV (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. If the
egress LSR cannot support this value, a Notification message MUST be
generated, with the Status Code set to "OAM Problem/Unsupported
Timestamp Format".
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.
Zhang, et al. Expires January 21, 2016 [Page 23]
Internet-Draft LDP Extensions for TP PW OAM July 2015
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 (1000) as
per [RFC6375].
Test Interval: test messages interval as described in [RFC6374]. By
default it is set to (10) as per [RFC6375].
Delay Threshold: the threshold value of measured two-way delay (in
milliseconds) over which action(s) SHOULD be triggered.
4.2.3. Fault Management Signal Sub-TLV
The Fault Management Signal sub-TLV depicted below is carried as a
sub-TLV of the PW OAM Functions TLV. When both working and
protection paths are configured, both PWs SHOULD be configured with
identical settings of the E flag, T flag, and the refresh timer.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FMS sub-type (300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|S|T| Reserved | Refresh Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fault Management Signal sub-TLV
Type: indicates a new type, the Fault Management Signal sub-TLV
(suggested value 4).
Length: indicates the length of the parameters in octets (8).
FMS Signal Flags are used to enable the FMS signals at end point MEPs
and the Server MEPs of the links over which the PW is forwarded. In
this document only the S flag pertains to Server MEPs.
The following flags are defined:
o E: Enable Alarm Indication Signal (AIS) and Lock Report (LKR)
signaling as described in [RFC6427]. Default value is 1
(enabled). If the egress MEP does not support FMS signal
generation, a Notification message MUST be generated, with the
Zhang, et al. Expires January 21, 2016 [Page 24]
Internet-Draft LDP Extensions for TP PW OAM July 2015
Status Code set to "OAM Problem/Fault management signaling
unsupported".
o S: Indicate to a server MEP that it should transmit AIS and LKR
signals on the client PW. Default value is 0 (disabled). If a
Server MEP which is capable of generating FMS messages is for some
reason unable to do so for the PW being signaled, a Notification
message MUST be generated, with the Status Code set to "OAM
Problem/ Unable to create fault management association".
o T: Set timer value, enabled the configuration of a specific timer
value. Default value is 0 (disabled).
o Remaining bits: Reserved for future specification and set to 0.
Refresh Timer: indicates the refresh timer of fault indication
messages, in seconds. The value MUST be between 1 to 20 seconds as
specified for the Refresh Timer field in [RFC6427]. If the egress PE
receiving the Label Mapping message cannot support the value it
SHOULD reply with a higher timer value.
Fault Management Signal sub-TLV MAY include Traffic Class sub-TLV
(Section 4.2.1.4). If TC sub-TLV is present, the value of the TC
field MUST be used as the value of the TC field of a PW label stack
entry for FMS messages. If the TC sub-TLV is absent, then selection
of the TC value is local decision.
5. IANA Considerations
5.1. TLVs
IANA is requested to assign two new TLV types from the registry "TLV
Type Name Space" in the "Label Distribution Protocol (LDP)
Parameters" registry.
Value TLV References
----- -------- ----------
TBD1 PW OAM Administration TLV this document
TBD2 PW OAM Functions TLV this document
The sub-TLV space and assignments for the PW OAM Functions TLV will
be the same as that for the MPLS OAM Functions TLV. Sub-types for
the MPLS OAM Functions TLV and the PW OAM Functions TLV MUST be kept
the same. Any new sub-type added to the MPLS OAM Functions TLV MUST
apply to the PW OAM Functions TLV as well.
Zhang, et al. Expires January 21, 2016 [Page 25]
Internet-Draft LDP Extensions for TP PW OAM July 2015
5.1.1. PW OAM Configuration Sub-TLV
IANA is requested to create a registry of "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 Fault Management Signal sub-TLV this document
5.1.1.1. BFD Configuration sub-TLVs
IANA is requested to create a registry of "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
4 Traffic Class Sub-TLV this document
5.1.1.2. Performance Monitoring sub-TLVs
IANA is requested to create a registry of "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 assigned by IANA,
using the "Expert Review" policy defined in [RFC5226].
Value Sub-TLV References
----- -------- ----------
1 PM Loss TLV this document
2 PM Delay TLV this document
5.2. OAM Configuration Status 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.
Zhang, et al. Expires January 21, 2016 [Page 26]
Internet-Draft LDP Extensions for TP PW OAM July 2015
Range/Value E Description Reference
----------- ----- ------------------------------------- -------------
TBD3 0 "PW OAM Alarms Enabled" This document
TBD4 0 "PW OAM Alarms Disabled" This document
TBD5 0 "PW MEP Configuration Failed" This document
TBD6 0 "PW MEP Configuration Succeed" This document
TBD7 0 "PW MEP Entities Disabled" This document
TBD8 0 "PW MIP Configuration Failed" This document
TBD9 0 "PW OAM Parameters Rejected" This document
TBD10 0 "OAM Problem/Unsupported BFD This document
Version"
TBD11 0 "OAM Problem/Unsupported BFD This document
Encapsulation format"
TBD12 0 "OAM Problem/Unsupported BFD This document
Authentication Type"
TBD13 0 "OAM Problem/Mismatch of BFD This document
Authentication Key ID
TBD14 0 "OAM Problem/Unsupported Timestamp This document
Format"
TBD15 0 "OAM Problem/Unsupported Delay This document
Mode"
TBD16 0 "OAM Problem/Unsupported Loss Mode" This document
TBD17 0 "OAM Problem/Delay variation This document
unsupported"
TBD18 0 "OAM Problem/Dyadic mode This document
unsupported"
TBD19 0 "OAM Problem/Loopback mode This document
unsupported"
TBD20 0 "OAM Problem/Combined mode This document
unsupported"
TBD21 0 "OAM Problem/Fault management This document
signaling unsupported"
TBD22 0 "OAM Problem/Unable to create This document
fault management association"
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.
Zhang, et al. Expires January 21, 2016 [Page 27]
Internet-Draft LDP Extensions for TP PW OAM July 2015
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., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447,
DOI 10.17487/RFC4447, April 2006,
<http://www.rfc-editor.org/info/rfc4447>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561,
DOI 10.17487/RFC5561, July 2009,
<http://www.rfc-editor.org/info/rfc5561>.
8.2. Informative References
[I-D.ietf-mpls-lsp-ping-mpls-tp-oam-conf]
Bellagamba, E., Mirsky, G., Andersson, L., Skoldstrom, P.,
Ward, D., and J. Drake, "Configuration of Proactive
Operations, Administration, and Maintenance (OAM)
Functions for MPLS-based Transport Networks using LSP
Ping", draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-09 (work
in progress), January 2015.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<http://www.rfc-editor.org/info/rfc3985>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc4379>.
Zhang, et al. Expires January 21, 2016 [Page 28]
Internet-Draft LDP Extensions for TP PW OAM July 2015
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering
Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291,
August 2008, <http://www.rfc-editor.org/info/rfc5291>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <http://www.rfc-editor.org/info/rfc5462>.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
September 2009, <http://www.rfc-editor.org/info/rfc5654>.
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
DOI 10.17487/RFC5659, October 2009,
<http://www.rfc-editor.org/info/rfc5659>.
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
"Requirements for Operations, Administration, and
Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
DOI 10.17487/RFC5860, May 2010,
<http://www.rfc-editor.org/info/rfc5860>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>.
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
September 2011, <http://www.rfc-editor.org/info/rfc6371>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011,
<http://www.rfc-editor.org/info/rfc6374>.
[RFC6375] Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and
Delay Measurement Profile for MPLS-Based Transport
Networks", RFC 6375, DOI 10.17487/RFC6375, September 2011,
<http://www.rfc-editor.org/info/rfc6375>.
Zhang, et al. Expires January 21, 2016 [Page 29]
Internet-Draft LDP Extensions for TP PW OAM July 2015
[RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
Boutros, S., and D. Ward, "MPLS Fault Management
Operations, Administration, and Maintenance (OAM)",
RFC 6427, DOI 10.17487/RFC6427, November 2011,
<http://www.rfc-editor.org/info/rfc6427>.
[RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
Extensions for Operations, Administration, and Maintenance
(OAM) Configuration", RFC 7260, DOI 10.17487/RFC7260, June
2014, <http://www.rfc-editor.org/info/rfc7260>.
[RFC7487] Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L.,
Skoldstrom, P., and D. Ward, "Configuration of Proactive
Operations, Administration, and Maintenance (OAM)
Functions for MPLS-Based Transport Networks Using RSVP-
TE", RFC 7487, DOI 10.17487/RFC7487, March 2015,
<http://www.rfc-editor.org/info/rfc7487>.
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 January 21, 2016 [Page 30]