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]