MPLS Working Group F. Zhang, Ed.
Internet-Draft B. Wu, Ed.
Intended status: Standards Track ZTE Corporation
Expires: April 28, 2011 E. Bellagamba, Ed.
A. Takacs
Ericsson
X. Dai
M. Xiao
ZTE Corporation
October 25, 2010
LDP Extensions for Proactive OAM Configuration of Dynamic MPLS-TP PW
draft-zhang-mpls-tp-pw-oam-config-03
Abstract
This document specifies extensions to the LDP protocol to configure
and control proactive OAM functions, suitable for 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 April 28, 2011.
Copyright Notice
Copyright (c) 2010 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 April 28, 2011 [Page 1]
Internet-Draft LDP extensions for TP PW OAM October 2010
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Analysis of existing PW OAM Configuration . . . . . . . . 3
1.1.1. MPLS PW OAM Functions . . . . . . . . . . . . . . . . 3
1.1.2. VCCV . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3. VCCV BFD . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.4. PW Status . . . . . . . . . . . . . . . . . . . . . . 4
1.1.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Analysis of PW OAM Configuration Extended by MPLS-TP . . . 5
1.2.1. CC-CV-RDI . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2. PM Loss/Delay . . . . . . . . . . . . . . . . . . . . 6
1.2.3. FMS . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.4. On-demand OAM functions . . . . . . . . . . . . . . . 6
1.2.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . 7
2. Conventions Used in This Document . . . . . . . . . . . . . . 8
3. MPLS-TP PW OAM Capability Advertisement . . . . . . . . . . . 8
4. PW OAM Configuration Procedures . . . . . . . . . . . . . . . 8
4.1. Establishment of OAM Entities and Functions . . . . . . . 8
4.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 10
4.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 11
5. LDP extensions . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. MPLS-TP PW OAM capability TLV . . . . . . . . . . . . . . 11
5.2. MPLS-TP PW OAM Configuration TLV . . . . . . . . . . . . . 12
5.2.1. BFD Configuration TLV . . . . . . . . . . . . . . . . 13
5.2.2. MPLS-TP PW PM Loss TLV . . . . . . . . . . . . . . . . 14
5.2.3. MPLS-TP PW PM Delay TLV . . . . . . . . . . . . . . . 14
5.2.4. MPLS-TP PW FMS TLV . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. LDP TLV Types . . . . . . . . . . . . . . . . . . . . . . 15
6.2. LDP Status Code . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
9. Normative references . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Zhang, et al. Expires April 28, 2011 [Page 2]
Internet-Draft LDP extensions for TP PW OAM October 2010
1. Introduction
MPLS PWs are defined in [RFC3985] and [RFC5659], which provide for
emulated services over an MPLS Packet Switched Network (PSN). MPLS
Transport Profile (MPLS-TP) describes a profile of MPLS that enables
operational models typical in transport networks, while providing
additional OAM, survivability and other maintenance functions not
previously supported by IP/MPLS, including PW. The corresponding
requirements are defined in [I-D.ietf-mpls-tp-oam-requirements].
[I-D.ietf-mpls-tp-oam-framework] describes how MPLS-TP OAM mechanisms
are operated to meet transport requirements, categorized into
proactive and on-demand monitoring. Proactive monitoring is
typically configured at transport path creation time, either be
carried out periodically and continuously or act on certain events
such as alarm signals. In contract on-demand monitoring is initiated
manually and for a limited amount of time, usually for operations
such as diagnostics to investigate into a defect condition.
NMS or LSP Ping [I-D.absw-mpls-lsp-ping-mpls-tp-oam-conf] are used to
configure these OAM functionalities if a control plane is not
instantiated. But if the control plane is used, it must support to
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 [RFC5654].
This document specifies extensions to the LDP protocol to negotiate
PW OAM capabilities, configure and bootstrap proactive PW OAM
functions, suitable for SS-PW and MS-PW. Configuration of OAM
entities for MS-PW SPME will be added in the future, and P2MP PW is
out of the scope of this document.
1.1. Analysis of existing PW OAM Configuration
1.1.1. MPLS PW OAM Functions
Before MPLS-TP standards, PW OAM functions are implemented by
[RFC5085], [RFC5885], [RFC4447] and [I-D.ietf-pwe3-static-pw-status].
[RFC5085] defines CV(connectivity verification),which belongs to on-
demand PW monitoring. [RFC5885] defines proactive connectivity
connection and PW/AC status notification. [RFC4447] and
[I-D.ietf-pwe3-static-pw-status] give some other ways of PW/AC status
notification.
1.1.2. VCCV
The goal of VCCV is to verify and further diagnose PW forwarding
path. The extension to LDP is signaling VCCV capabilities to a peer
Zhang, et al. Expires April 28, 2011 [Page 3]
Internet-Draft LDP extensions for TP PW OAM October 2010
PE.
The extension to LDP is signaling VCCV LSP ping/ICMP ping
capabilities to a peer PE.
1.1.3. VCCV BFD
[RFC5885] specifies four CV types for BFD by combining two types of
encapsulation with two types of functionality. When multiple BFD CV
Types are advertised, it also describes how to select one to use.
The extension to LDP is to signal VCCV BFD capabilities to a peer PE,
and activate BFD protocol after PW is established. If the BFD
parameters(such as sending interval) need to be modified, BFD itself
will handle it.
1.1.4. PW Status
PW status codes provides a mechanism to signal the status of PW, or
AC failure between the two PEs at each end of the PW. When PW
control plane exists, the PW status TLV is carried in the initial
Label Mapping message or Notification message to signal all PW status
messages.
The extension to LDP is to signal PW status capabilities to a peer
PE, and activate PW status notification function after PW is
established. So when a event occurs, an update PW status will be
sent.
1.1.5. Conclusion
In summary, IP/MPLS PW OAM functions and relation with control plane/
NMS is described in the table. This document will not replace or
deprecate this; e.g.,VCCV capability advertisement and PW status
negotiation for MPLS networks.
Zhang, et al. Expires April 28, 2011 [Page 4]
Internet-Draft LDP extensions for TP PW OAM October 2010
|----------------------------------------------------------------------|
| | | LDP | LSP Ping | NMS |
|----------------------------------------------------------------------|
| | VCCV | Capability | | Capability |
| | LSP ping | negotiation | |configuration&|
| On-demand | | | | Bootstrapping|
| MPLS PW |-------------------------------------------------------|
| OAM | VCCV | Capability | | Capability |
| | ICMP ping | negotiation | |configuration&|
| | | | | Bootstrapping|
|----------------------------------------------------------------------|
| | VCCV BFD | Capability | | Capability |
| | | negotiation& | |configuration&|
| | | Bootstrapping| | Bootstrapping|
| Proactive |-------------------------------------------------------|
| OAM | PW status | Capability | | Capability |
| | | negotiation& | |configuration&|
| | | Bootstrapping| | Bootstrapping|
|----------------------------------------------------------------------|
Figure 1: IP/MPLS PW OAM functions
1.2. Analysis of PW OAM Configuration Extended by MPLS-TP
1.2.1. CC-CV-RDI
[I-D.ietf-mpls-tp-cc-cv-rdi] has been chosen to be the basis of pro-
active MPLS-TP OAM functions. Because VCCV BFD currently has no CV
function, it SHOULD evolve with [I-D.ietf-mpls-tp-cc-cv-rdi] to
provide this function in TP environment. The use of the VCCV control
channel provides the context, based on the MPLS-PW label, required to
bind and bootstrap the BFD session to a particular PW (FEC) so local
discriminator values are not exchanged; please refer to the analysis
in [I-D.ietf-mpls-tp-oam-analysis] and [RFC5885]. However, in order
to identify certain extreme cases of mis-connectivity and fulfill the
requirements that the BFD mechanism MUST be the same for LSP, (MS-)PW
and Section as well as for SPME, BFD MAY still need to use
Discriminator values to identify the connection being verified at
both ends of the PW. The discriminator values can be statically
configured, or signaled via LSP Ping or LDP extensions defined in
this document.
Timer negotiation, such as TX/RX interval is performed in subsequent
BFD control messages [RFC5880], but it also can be gotten by control
plane signaling [I-D.ietf-mpls-tp-oam-framework].
The source MEP-ID does not need to be carried, for they can be
Zhang, et al. Expires April 28, 2011 [Page 5]
Internet-Draft LDP extensions for TP PW OAM October 2010
deduced from the advertised FEC (129) TLV, as described in
[I-D.ietf-mpls-tp-identifiers].
PHB, which identifies the per-hop behavior of BFD packet, SHOULD be
configured as well. This permits the verification of correct
operation of QoS queuing as well as connectivity.
In conclusion, the configuration of VCCV BFD by control plane is not
necessary, but for consistent operation of transport path and
section, it SHOULD be an option.
1.2.2. PM Loss/Delay
[I-D.frost-mpls-tp-loss-delay]specifies mechanisms for performance
monitoring of PWs, in particular it specifies loss and delay
measurements.
For proactive LM, the transmission rate and PHB associated with the
LM OAM packets originating from a MEP need be negotiated with the
other MEP. LM OAM packets should be transmitted with the same PHB
class that the LM is intended to measure.
Just like LM, Both one way and two way mode of proactive DM need the
two MEPs nodes of PW to negotiate the measure interval and PHB value
of OAM packets.
1.2.3. FMS
[I-D.ietf-mpls-tp-fault]specifies fault management signals with which
a server PW can notify client PWs about various fault conditions to
suppress alarms or to be used as triggers for actions in the client
PWs. The following signals are defined: Alarm Indication Signal
(AIS), Link Down Indication (LDI) and Lock Reporting (LKR).
For each MEP of each MEG, enabling/disabling the generation of FMS
packets, the transmitted period and PHB SHOULD be configured. This
can be done independently, and the values of configured parameters
can be different, but for easy maintenance, these setting SHOULD be
consistent.
In conclusion, the configuration of FMS by control plane is not
necessary, but for easy maintenance, it SHOULD be an option also.
1.2.4. On-demand OAM functions
The extended on-demand OAM functions MAY need capability negotiation
in the initialized LDP mapping message. However, On-demand PW OAM
functions are expected to be carried out by directly accessing
Zhang, et al. Expires April 28, 2011 [Page 6]
Internet-Draft LDP extensions for TP PW OAM October 2010
network nodes via a management interface; hence configuration and
control of on-demand PW OAM functions are out-of-scope for this
document.
1.2.5. Conclusion
According to the analysis above, LDP extensions to the LDP protocol
to negotiate PW OAM capabilities, configure and bootstrap proactive
PW OAM functions, such as, CC-CV-RDI, PM Loss/Delay, FMS. In this
way OAM setup is bound to connection establishment signaling,
avoiding two separate management/configuration steps (connection
setup followed by OAM configuration) which would increases delay,
processing and more importantly may be prune to mis-configuration
errors.
Furthermore, LSP ping can be used to configure the proactive PW OAM
function extended by MPLS-TP also, suitable for dynamic and static
PW. For reference, the following table describes the different scope
of different proactive OAM bootstrapping schemes of dynamic PW.
|-------------------------------------------------------------------------|
| | | LDP | LSP Ping | NMS |
|-------------------------------------------------------------------------|
| | |Capability | | Capability |
| | |negotiation& | |configuration&|
| | CC/CV/RDI |Function | Function | Function |
| | |configuration&|configuration&|configuration&|
| | |Bootstrapping |Bootstrapping | Bootstrapping|
| |------------------------------------------------------------|
| Proactive | |Capability | | Capability |
| OAM | |negotiation& | |configuration&|
| | FMS |Function | Function | Function |
| | |configuration&|configuration&|configuration&|
| | |Bootstrapping |Bootstrapping | Bootstrapping|
| |------------------------------------------------------------|
| | |Capability | | Capability |
| | |negotiation& | |configuration&|
| | PM Loss/Delay |Function | Function | Function |
| | |configuration&|configuration&|configuration&|
| | |Bootstrapping |Bootstrapping | Bootstrapping|
|------------|------------------------------------------------------------|
Figure 2: MPLS-TP PW OAM functions
Zhang, et al. Expires April 28, 2011 [Page 7]
Internet-Draft LDP extensions for TP PW OAM October 2010
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.
3. MPLS-TP PW OAM Capability Advertisement
When a PW is first set up, the PEs MUST attempt to negotiate the
usage of what kind of OAM functions. Up to now, there are PW status
negotiation and VCCV capability advertisement. For the newly
extended OAM function by MPLS-TP, such as PM loss/delay and FMS, the
capability negotiation is accomplished as follows: A PE that supports
the MPLS-TP PW OAM capability MUST include MPLS-TP PW OAM capability
TLV in the initial Label Mapping message, following the PW Status TLV
or VCCV parameter field in Interface Parameters TLV. If the extended
on-demand OAM functions also need capability negotiation, just follow
the same rules.
4. PW OAM Configuration Procedures
A PE may play active or passive role in the signaling of the PW.
There exist two situations:
a) Active/active "C Both PEs of a PW are active (SS-PW), they select
PW OAM configuration parameters and send with the Label Mapping
message to each other independently.
b) Active/passive "C One PE is active and the others are passive
(MS-PW). The active/passive role election is defined in Section
7.2.1 of [I-D.ietf-pwe3-segmented-pw] and applies here, this document
does not define any new role election procedures.
The general rules of OAM configuration procedures are mostly
identical between MS-PW and SS-PW, except that SS-PW does not need to
configure MIP function and the Mapping message are sent out
independently. This section takes MS-PW as an example to describe
the general OAM configuration procedures. As for SS-PW, there may be
some collisions of PW OAM configuration parameters, and these
specific differences would be addressed in section 6.
4.1. Establishment of OAM Entities and Functions
Assuming there is one PW needs to be setup between T-PE1 and T-PE2,
across S-PE1 and S-PE2. OAM functions must be setup and enabled in
the appropriate order so that spurious alarms can be avoided.
Zhang, et al. Expires April 28, 2011 [Page 8]
Internet-Draft LDP extensions for TP PW OAM October 2010
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| A|--------|B C|--------|D E|--------|F |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
T-PE1 S-PE1 S-PE2 T-PE2
Figure 3: MS-PW OAM configuration scheme
Fist of all, T-PE1 MUST setup the OAM sink function to be prepared to
receive OAM messages but MUST suppress any OAM alarms (e.g., due to
missing or unidentified OAM messages). The Mapping message MUST be
sent with the "OAM Alarms Enabled" cleared, "OAM MEP Entities
desired" set and "OAM MIP Entities desired" set in the MPLS-TP PW OAM
capability TLV.
When the Mapping message arrives at the down receivers, such as
S-PE1, S-PE2 and T-PE2, they MUST establish and configure OAM
entities according to the OAM information provided in mapping
message. If this is not possible, a Label Release message SHOULD be
sent and neither the OAM entities nor the PW SHOULD be established.
If OAM entities are established successfully, the middle points
(S-PE1 and S-PE2) MUST forward the Mapping message downstream, the
endpoint (T-PE2) MUST set the OAM Source function and MUST be
prepared to Send OAM messages.
The same rules are applied to the reverse direction (from T-PE2 to
T-PE1), that is to say, T-PE2 needs to setup the OAM sink function to
be prepared to receive OAM messages but MUST suppress any OAM alarms
(e.g., due to missing or unidentified OAM messages). The Mapping
message MUST be sent with the "OAM Alarms Enabled" cleared, "OAM MEP
Entities desired" set, "OAM MIP Entities desired" set in the MPLS-TP
PW OAM capability TLV. When T-PE1 receives the Mapping message, it
completes any pending OAM configuration and enables the OAM source
function to send OAM messages.
After this round, OAM entities are established and configured for the
PW and OAM messages MAY already be exchanged, and OAM alarms can now
be enabled. The T-PE nodes(T-PE1 and T-PE2), while still keeping OAM
alarms disabled send a Notification message with "OAM Alarms Enabled"
PW status flag set, and enable the OAM alarms after processing the
Notification message. Data plane OAM is now fully functional, by the
way, the MPLS-TP PW OAM Configuration TLV is not needed to be carried
in the Notification message.
The PW may be setup with OAM entities right away with the first
signaling, as described above, but a PW may be signaled and
Zhang, et al. Expires April 28, 2011 [Page 9]
Internet-Draft LDP extensions for TP PW OAM October 2010
established without OAM configuration first, and OAM entities may be
added later. This can be done by sending Notification message with
the related configuration parameters subsequently.
4.2. Adjustment of OAM Parameters
There may be a need to change the parameters of an already
established and configured OAM function during the lifetime of the
PW. To do so the T-PE nodes need to send Notification message with
the updated parameters. OAM parameters that influence the content
and timing of OAM messages and identify the way OAM defects and
alarms are derived and generated. Hence, to avoid spurious alarms,
it is important that both sides, OAM sink and source, are updated in
a synchronized way. First, the alarms of the OAM sink function
should be suppressed and only then should expected OAM parameters be
adjusted. Subsequently, the parameters of the OAM source function
can be updated. Finally, the alarms of the OAM sink side can be
enabled again.
In accordance with the above operation, T-PE1 MUST send Notification
message with "OAM Alarms Enabled" cleared and including the updated
MPLS-TP PW OAM Configuration TLV corresponding to the new parameter
settings. The initiator (T-PE1) MUST keep its OAM sink and source
functions running unmodified, but it MUST suppress OAM alarms after
the updated Notification message is sent. The receiver (T-PE2) MUST
first disable all OAM alarms, then update the OAM parameters
according to the information in the Notification message and reply
with a Notification message acknowledging the changes by including
the MPLS-TP PW OAM Configuration TLV. Note that the receiving side
has the possibility to adjust the requested OAM configuration
parameters and reply with and updated MPLS-TP PW OAM Configuration
TLV in the Notification message, reflecting the actually configured
values. However, in order to avoid an extensive negotiation phase,
in the case of adjusting already configured OAM functions, the
receiving side SHOULD NOT update the parameters requested in the
Notification message to an extent that would provide lower
performance than what has been configured previously.
The initiator (T-PE1) MUST only update its OAM sink and source
functions after it received the Notification message. After this
Notification messages that exchange (in both directions) the OAM
parameters are updated and OAM is running according the new parameter
settings. However OAM alarms are still disabled, a subsequent
Notification messages exchanges with "OAM Alarms Enabled" flag set
are needed to enable OAM alarms again.
Zhang, et al. Expires April 28, 2011 [Page 10]
Internet-Draft LDP extensions for TP PW OAM October 2010
4.3. Deleting OAM Entities
In some cases it may be useful to remove some or all OAM entities and
functions from one PW without actually tearing down the connection.
To avoid any spurious alarm, the following procedure should be
followed:
The T-PE nodes disable OAM alarms and SHOULD send Notification
message each other with "OAM Alarms Enabled" cleared but unchanged
OAM configuration and without the MPLS-TP PW OAM Configuration TLV.
After that, T-PE1 (T-PE2) SHOULD delete OAM source functions, then
send Notification message with "OAM MEP Entities desired" and "OAM
MIP Entities desired" cleared. While T-PE2 (T-PE1) deletes OAM sink
function when it receives the Notification message with "OAM MEP
Entities desired" cleared, S-PE1 and S-PE2 delete MIP configuration
when they receive the Notification message with "OAM MIP Entities
desired" cleared.
Alternatively, if only some OAM functions need to be removed, the
T-PE node sends the Notification message with the updated OAM
Configuration TLV. Changes between the contents of the previously
signaled OAM Configuration TLV and the currently received TLV
represent which functions SHOULD be removed/added.
5. LDP extensions
Below, extensions to LDP are defined in order to configure MPLS-TP PW
OAM functionalities during the PW setup.
5.1. MPLS-TP PW OAM capability TLV
The format of the MPLS-TP PW OAM Capability 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| MPLS-TP PW OAM Capability | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|I|A| MPLS-TP PW OAM Capability Flags |F|D|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: MPLS-TP PW OAM Capability TLV
Currently defined OAM Capability Flags are:
Zhang, et al. Expires April 28, 2011 [Page 11]
Internet-Draft LDP extensions for TP PW OAM October 2010
0 PM Loss supported
1 PM Delay supported
2 FMS supported
29 OAM Alarms Enabled
30 OAM MIP entities desired
31 OAM MEP entities desired
One bit (0, IANA to assign): "PM Loss supported" is allocated.
One bit (1, IANA to assign): "PM delay supported" is allocated.
One bit (2, IANA to assign): "FMS supported" is allocated.
One bit (31, IANA to assign): "OAM MEP entities desired" is
allocated. If the "OAM MEP entities desired" bit is set it is
indicating that the establishment of OAM MEP entities are required at
the endpoints of the signaled PW. If the establishment of MEPs is
not supported, a Label Release message MUST be sent. If the "OAM MEP
entities desired" bit is set and additional parameters are needed to
be configured on the OAM entities, an "MPLS-TP PW OAM Configuration
TLV" may be included in the Mapping or Notification message.
One bit (30, IANA to assign): "OAM MIP entities desired" is
allocated. This bit can only be set if the "OAM MEP entities
desired" bit is set. If the "OAM MIP entities desired" bit is set,
it is indicating that the establishment of OAM MIP entities is
required at every transit node of the signaled PW. If the
establishment of a MIP is not supported, a Label Release message MUST
be sent.
One bit (29, IANA to assign): "OAM Alarms Enabled" is allocated.
This bit can only be set if the "OAM MEP entities desired" bit is
set. If the "OAM Alarms Enabled" bit is set, it is indicating that
the T-PE needs to enable OAM alarms. If the establishment of a MIP
is not supported, a Label Release message MUST be sent.
[Editor notes]: If the MPLS-TP equipments support all the PW OAM
functions defined and the OAM capability negotiation is not needed,
this MPLS-TP PW OAM capability TLV just use to configure MEP/MIP
entities and enable/disable OAM alarms.
5.2. MPLS-TP PW OAM Configuration TLV
The "OAM Configuration TLV", defined in
[I-D.ietf-ccamp-oam-configuration-fwk], is depicted in the following
figure. It may be carried in the Mapping and Notification messages,
Zhang, et al. Expires April 28, 2011 [Page 12]
Internet-Draft LDP extensions for TP PW OAM October 2010
just following the PW Status TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (2) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: MPLS-TP PW OAM Configuration TLV
OAM type: indicates a new type: the MPLS-TP PW OAM Configuration TLV
(IANA to assign). If this type is not supported, a Label Release
message MUST be sent. The specific OAM functions are specified in
the "Function Flags" sub-TLV as depicted in
[I-D.ietf-ccamp-oam-configuration-fwk], and the additional
corresponding sub-TLVs are defined in section 3.2 of
[I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext].
For active/active signaling, if the flags in the "MPLS-TP PW OAM
Function Flags sub-TLV" are different in the two Mapping message, the
two PEs nodes can compare the node IDs. Label Withdraw message MUST
be sent by the PE with lower ID, then it sends the Label Mapping
message again with the same flags carried in the received Label
Mapping message.
5.2.1. BFD Configuration TLV
BFD Configuration TLV follows the same TLV structure defined for
RSVP-TE in section 3.3 of [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext].
For active/active signaling, if the flags of "BFD Configuration TLV"
are different in the two Mapping message, similarly Label Withdraw
message MUST be sent by the PE with lower ID. Then it sends the
Label Mapping message again with the same flags carried in the "BFD
configuration TLV" of the received Label Mapping message. If the
flags of "BFD Configuration TLV" are the same, but the values of
"Negotiation Timer parameters sub-TLV" are different, both the PE
nodes MUST adopt the bigger interval and detection time multiplier.
Zhang, et al. Expires April 28, 2011 [Page 13]
Internet-Draft LDP extensions for TP PW OAM October 2010
5.2.2. MPLS-TP PW PM Loss TLV
MPLS-TP PW PM Loss TLV follows the same TLV structure defined for
RSVP-TE in section 3.4 of [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext].
For active/active signaling, if the flags of "MPLS-TP PW OAM PM Loss
TLV" are different in the two Mapping message, similarly Label
Withdraw message MUST be sent by the PE with lower ID. Then it sends
the Label Mapping message again with the same flags carried in the
"MPLS-TP PW OAM PM Loss TLV" of the received Label Mapping message.
If the flags of "MPLS-TP PW OAM PM Loss TLV" are the same, but the
Measurement Interval and Loss Threshold are different, both the PE
nodes MUST adopt the bigger values.
5.2.3. MPLS-TP PW PM Delay TLV
MPLS-TP PW PM Delay TLV follows the same TLV structure defined for
RSVP-TE in section 3.5 of [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext].
For active/active signaling, if the flags of "MPLS-TP PW OAM PM Delay
TLV" are different in the two Mapping message, similarly Label
Withdraw message MUST be sent by the PE with lower ID. Then it sends
the Label Mapping message again with the same flags carried in the
"MPLS-TP PW OAM PM Delay TLV" of the received Label Mapping message.
If the flags of "MPLS-TP PW OAM PM Delay TLV" are the same, but the
Measurement Interval and Delay Threshold are different, both the PE
nodes MUST adopt the bigger values.
5.2.4. MPLS-TP PW FMS TLV
MPLS-TP PW FMS TLV follows the same TLV structure defined for RSVP-TE
in section 3.6 of [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext].
For active/active signaling, if the flags of "MPLS-TP PW OAM FMS TLV"
are different in the two Mapping message, similarly Label Withdraw
message MUST be sent by the PE with lower ID. Then it sends the
Label Mapping message again with the same flags carried in the
"MPLS-TP PW OAM FMS TLV" of the received Label Mapping message.
Notes: CSF are overlapped with PW Status TLV, and the field of
Refresh Timer is not needed.
6. IANA Considerations
Zhang, et al. Expires April 28, 2011 [Page 14]
Internet-Draft LDP extensions for TP PW OAM October 2010
6.1. LDP TLV Types
This document specifies the following new LDP TLV types:
o MPLS-TP PW OAM Capability TLV;
o MPLS-TP PW OAM Configuration TLV;
Sub-TLV types to be carried in the "MPLS-TP PW OAM Configuration
TLV":
o MPLS-TP PW OAM Function Flags sub-TLV;
o BFD Configuration sub-TLV;
o MPLS-TP PW PM Loss sub-TLV;
o MPLS-TP PW PM Delay sub-TLV;
o MPLS-TP PW FMS sub-TLV;
Sub-TLV types to be carried in the "BFD Configuration sub-TLV":
o Local Discriminator sub-TLV;
o Negotiation Timer Parameters sub-TLV.
6.2. LDP Status Code
TBD.
7. Security Considerations
TBD.
8. Acknowledgement
The authors would like to thank Thomas Nadeau for his valuable
comments.
9. Normative references
[I-D.absw-mpls-lsp-ping-mpls-tp-oam-conf]
Bellagamba, E., Andersson, L., Skoldstrom, P., and D.
Ward, "Configuration of pro-active MPLS-TP Operations,
Administration, and Maintenance (OAM) Functions Using LSP
Ping", draft-absw-mpls-lsp-ping-mpls-tp-oam-conf-00 (work
in progress), July 2010.
[I-D.frost-mpls-tp-loss-delay]
Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for the MPLS Transport Profile",
draft-frost-mpls-tp-loss-delay-02 (work in progress),
June 2010.
Zhang, et al. Expires April 28, 2011 [Page 15]
Internet-Draft LDP extensions for TP PW OAM October 2010
[I-D.ietf-ccamp-oam-configuration-fwk]
Takacs, A., Fedyk, D., and H. Jia, "OAM Configuration
Framework and Requirements for GMPLS RSVP-TE",
draft-ietf-ccamp-oam-configuration-fwk-03 (work in
progress), January 2010.
[I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext]
Bellagamba, E., Andersson, L., Skoldstrom, P., Ward, D.,
and A. Takacs, "Configuration of pro-active MPLS-TP
Operations, Administration, and Maintenance (OAM)
Functions Using RSVP-TE",
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-03 (work in
progress), July 2010.
[I-D.ietf-mpls-tp-cc-cv-rdi]
Allan, D., Drake, J., Swallow, G., Boutros, S., Sivabalan,
S., and D. Ward, "Proactive Connectivity Verification,
Continuity Check and Remote Defect indication for MPLS
Transport Profile", draft-ietf-mpls-tp-cc-cv-rdi-02 (work
in progress), October 2010.
[I-D.ietf-mpls-tp-fault]
Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S.,
Ward, D., Bryant, S., and S. Sivabalan, "MPLS Fault
Management OAM", draft-ietf-mpls-tp-fault-02 (work in
progress), July 2010.
[I-D.ietf-mpls-tp-identifiers]
Bocci, M. and G. Swallow, "MPLS-TP Identifiers",
draft-ietf-mpls-tp-identifiers-02 (work in progress),
July 2010.
[I-D.ietf-mpls-tp-lsp-ping-bfd-procedures]
Bahadur, N., Aggarwal, R., Ward, D., Nadeau, T., Sprecher,
N., and Y. Weingarten, "LSP-Ping and BFD encapsulation
over ACH", draft-ietf-mpls-tp-lsp-ping-bfd-procedures-01
(work in progress), August 2010.
[I-D.ietf-mpls-tp-oam-analysis]
Sprecher, N., Bellagamba, E., and Y. Weingarten, "MPLS-TP
OAM Analysis", draft-ietf-mpls-tp-oam-analysis-02 (work in
progress), July 2010.
[I-D.ietf-mpls-tp-oam-framework]
Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A.,
Hernandez-Valencia, E., Levrau, L., Sestito, V., Sprecher,
N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R.
Winter, "Operations, Administration and Maintenance
Zhang, et al. Expires April 28, 2011 [Page 16]
Internet-Draft LDP extensions for TP PW OAM October 2010
Framework for MPLS- based Transport Networks",
draft-ietf-mpls-tp-oam-framework-09 (work in progress),
October 2010.
[I-D.ietf-mpls-tp-oam-requirements]
Vigoureux, M. and D. Ward, "Requirements for OAM in MPLS
Transport Networks",
draft-ietf-mpls-tp-oam-requirements-06 (work in progress),
March 2010.
[I-D.ietf-pwe3-dynamic-ms-pw]
Martini, L., Bocci, M., Balus, F., Bitar, N., Shah, H.,
Aissaoui, M., Rusmisel, J., Serbest, Y., Malis, A., Metz,
C., McDysan, D., Sugimoto, J., Duckett, M., Loomis, M.,
Doolan, P., Pan, P., Pate, P., Radoaca, V., Wada, Y., and
Y. Seo, "Dynamic Placement of Multi Segment Pseudo Wires",
draft-ietf-pwe3-dynamic-ms-pw-13 (work in progress),
October 2010.
[I-D.ietf-pwe3-redundancy]
Muley, P., "Pseudowire (PW) Redundancy",
draft-ietf-pwe3-redundancy-03 (work in progress),
May 2010.
[I-D.ietf-pwe3-segmented-pw]
Martini, L., Nadeau, T., Metz, C., Bocci, M., Aissaoui,
M., Balus, F., and M. Duckett, "Segmented Pseudowire",
draft-ietf-pwe3-segmented-pw-18 (work in progress),
September 2010.
[I-D.ietf-pwe3-static-pw-status]
Martini, L., Swallow, G., and M. Bocci, "Pseudowire Status
for Static Pseudowires",
draft-ietf-pwe3-static-pw-status-00 (work in progress),
February 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Zhang, et al. Expires April 28, 2011 [Page 17]
Internet-Draft LDP extensions for TP PW OAM October 2010
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto,
"Attachment Individual Identifier (AII) Types for
Aggregation", RFC 5003, September 2007.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[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.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)", RFC 5885, June 2010.
Authors' Addresses
Fei Zhang (editor)
ZTE Corporation
4F,RD Building 2,Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52877612
Email: zhang.fei3@zte.com.cn
Zhang, et al. Expires April 28, 2011 [Page 18]
Internet-Draft LDP extensions for TP PW OAM October 2010
Bo Wu (editor)
ZTE Corporation
4F,RD Building 2,Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52877276
Email: wu.bo@zte.com.cn
Elisa Bellagamba (editor)
Ericsson
Farogatan 6
Kista, 164 40
Sweden
Phone: +46 761440785
Email: elisa.bellagamba@ericsson.com
Attila Takacs
Ericsson
Laborc u. 1.
Budapest, 1037
Hungary
Email: attila.takacs@ericsson.com
Xuehui Dai
ZTE Corporation
4F,RD Building 2,Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52877612
Email: dai.xuehui@zte.com.cn
Min Xiao
ZTE Corporation
4F,RD Building 2,Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52877612
Email: xiao.min2@zte.com.cn
Zhang, et al. Expires April 28, 2011 [Page 19]
