Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection
draft-ietf-pals-mpls-tp-dual-homing-coordination-04
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8185.
|
|
---|---|---|---|
Authors | Weiqiang Cheng , Lei Wang , Han Li , Kai Liu , Shahram Davari , Jie Dong , Alessandro D'Alessandro | ||
Last updated | 2017-01-06 (Latest revision 2016-08-01) | ||
Replaces | draft-cheng-pwe3-mpls-tp-dual-homing-coordination | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-05)
by Jouni Korhonen
Ready w/nits
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Stewart Bryant | ||
Shepherd write-up | Show Last changed 2016-08-23 | ||
IESG | IESG state | Became RFC 8185 (Proposed Standard) | |
Consensus boilerplate | Yes | ||
Telechat date | (None) | ||
Responsible AD | Deborah Brungard | ||
Send notices to | "Stewart Bryant" <stewart.bryant@gmail.com> |
draft-ietf-pals-mpls-tp-dual-homing-coordination-04
Network Working Group W. Cheng Internet-Draft L. Wang Intended status: Standards Track H. Li Expires: February 2, 2017 China Mobile K. Liu Huawei Technologies S. Davari Broadcom Corporation J. Dong Huawei Technologies A. D'Alessandro Telecom Italia August 1, 2016 Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection draft-ietf-pals-mpls-tp-dual-homing-coordination-04 Abstract In some scenarios, the MPLS Transport Profile (MPLS-TP) Pseudowires (PWs) are provisioned through either static configuration or management plane, where a dynamic control plane is not available. A fast protection mechanism for MPLS-TP PWs is needed to protect against the failure of Attachment Circuit (AC), the failure of Provider Edge (PE) and also the failure in the Packet Switched Network (PSN). The framework and typical scenarios of dual-homing PW local protection are described in [draft-ietf-pals-mpls-tp-dual- homing-protection]. This document proposes a dual-homing coordination mechanism for MPLS-TP PWs, which is used for state exchange and switchover coordination between the dual-homing PEs for dual-homing PW local protection. Requirements Language 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 RFC 2119 [RFC2119]. 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 Cheng, et al. Expires February 2, 2017 [Page 1] Internet-Draft Dual-Homing Coordination for MPLS-TP PWs August 2016 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 February 2, 2017. Copyright Notice Copyright (c) 2016 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 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. Overview of the Proposed Solution . . . . . . . . . . . . . . 3 3. Protocol Extensions for Dual-Homing MPLS-TP PW Protection . . 4 3.1. Information Exchange Between Dual-Homing PEs . . . . . . 4 3.2. Protection Procedures . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction [RFC6372], [RFC6378] and [RFC7771] describe the framework and mechanism of MPLS-TP Linear protection, which can provide protection for the MPLS LSP and PW between the edge nodes. These mechanisms cannot protect the failure of the Attachment Circuit (AC) or the edge nodes. [RFC6718] and [RFC6870] specifies the PW redundancy framework and mechanism for protecting the AC or edge node failure by adding one or more edge nodes, but it requires PW switchover in case of a AC Cheng, et al. Expires February 2, 2017 [Page 2] Internet-Draft Dual-Homing Coordination for MPLS-TP PWs August 2016 failure, also PW redundancy relies on PSN protection mechanisms to protect the failure of PW. In some scenarios such as mobile backhauling, the MPLS PWs are provisioned with dual-homing topology, in which at least the CE node on one side is dual-homed to two PEs. If a failure occurs in the primary AC, operators usually prefer to perform local switchover in the dual-homing PE side and keep the working pseudowire unchanged if possible. This is to avoid massive PW switchover in the mobile backhaul network due to the AC failure in the mobile core site, which may in turn lead to congestion due to the migration of traffic from the paths preferred by the network planners. Similarly, as muliple PWs share the physical AC in the mobile core site, it is preferable to keep using the working AC when one working PW fails in the PSN network, which could avoid unnecessary AC switchover for other PWs. A fast dual-homing PW protection mechanism is needed to protect the failure in AC, the PE node and the PSN network to meet the above requirements. [I-D.ietf-pals-mpls-tp-dual-homing-protection] describes a framework and several scenarios of dual-homing pseudowire (PW) local protection. This document proposes a dual-homing coordination mechanism for static MPLS-TP PWs, which is used for information exchange and switchover coordination between the dual-homing PEs for the dual-homing PW local protection. The proposed mechanism has been implemented and deployed in several mobile backhaul networks which use static MPLS-TP PWs for the backhauling of mobile traffic from the radio access sites to the core site. 2. Overview of the Proposed Solution Linear protection mechanisms for MPLS-TP network are defined in [RFC6378], [RFC7271] and [RFC7324]. When such mechanisms are applied to PW linear protection [RFC7771], both the working PW and the protection PW are terminated on the same PE node. In order to provide dual-homing protection for MPLS-TP PWs, some additional mechanisms are needed. In MPLS-TP PW dual-homing protection, the linear protection mechanism as defined in [RFC6378] [RFC7271] and [RFC7324] on the single-homing PE (e.g. PE3 in figure 1) is not changed, while on the dual-homing side, the working PW and protection PW are terminated on two dual- homing PEs (e.g. PE1 and PE2 in figure 1) respectively to protect the failure occurs in the dual-homing PEs and the connected ACs. As specified in [I-D.ietf-pals-mpls-tp-dual-homing-protection], a dedicated Dual-Node Interconnection (DNI) PW is provisioned between the two dual-homing PE nodes, which is used to bridge the traffic between the dual-homing PEs when a failure happens in the working PW Cheng, et al. Expires February 2, 2017 [Page 3] Internet-Draft Dual-Homing Coordination for MPLS-TP PWs August 2016 or the primary AC. In order to make the linear protection mechanism work in the dual-homing PEs scenario, coordination between the dual- homing PE nodes is needed, so that the dual-homing PEs can set the connection between the AC, the service PW and the DNI-PW properly in a coordinated fashion. +----------------+ / | +--------+ AC1 /| PE1 | Working PW | | / | X----------------X | / | | Service PW1 | | +---/+ +--------X-------+ | | +----+ | | | DNI PW | PE3 | | | | CE1| | | |---| CE2| +---\+ +--------X-------+ | | +----+ \ | | Protection PW | | \ | X----------------X | AC2 \| | Service PW2 | | \ PE2 | +--------+ +----------------+ Figure 1. Dual-homing Protection with DNI-PW 3. Protocol Extensions for Dual-Homing MPLS-TP PW Protection In dual-homing MPLS-TP PW local protection, the forwarding state of the dual-homing PEs are determined by the forwarding state machine as defined in [I-D.ietf-pals-mpls-tp-dual-homing-protection]. In order to achieve the dual-homing MPLS-TP PW protection, coordination between the dual-homing PE nodes is needed to exchange the PW status and protection coordination requests. 3.1. Information Exchange Between Dual-Homing PEs The coordination information will be sent on the DNI PW over the G-ACh as described in [RFC5586]. A new G-ACh channel type is defined for the dual-homing coordination between the dual-homing PEs of MPLS- TP PWs. This channel type can be used for the exchange of different kinds of information between the dual-homing PEs. This document uses this channel type for the exchange of PW status and switchover coordination between the dual-homing PEs. Other potential usages of this channel type are for further study and are out of the scope of this document. The MPLS-TP Dual-Homing Coordination (DHC) message is sent on the DNI PW between the dual-homing PEs. The format of MPLS-TP DHC message is shown below: Cheng, et al. Expires February 2, 2017 [Page 4] Internet-Draft Dual-Homing Coordination for MPLS-TP PWs August 2016 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 0 1|Version| Flags | DHC Code Point | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dual-Homing PEs Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. MPLS-TP Dual-Homing Coordination Message The Dual-Homing Group ID is a 4-octet unsigned integer to identify the dual-homing group which the dual-homing PEs belong to. It MUST be the same at both PEs in the same group. The TLV Length field specifies the total length in octets of the subsequent TLVs. In this document, two TLVs are defined in MPLS-TP Dual-Homing Coordination message for dual-homing MPLS-TP PW protection: Type Description Length 1 PW Status 20 Bytes 2 Dual-Node Switching 16 Bytes The PW Status TLV is used by a dual-homing PE to report its service PW status to the other dual-homing PE in the same dual-homing group. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1 (PW Status) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Dual-homing PE Node_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Dual-homing PE Node_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DNI PW-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service PW Status |D|F| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. PW Status TLV Cheng, et al. Expires February 2, 2017 [Page 5] Internet-Draft Dual-Homing Coordination for MPLS-TP PWs August 2016 - The Length field specifies the length in octets of the value field of the TLV. - The Destination Dual-homing PE Node_ID is the 32-bit identifier of the receiver PE. Usually it is the same as the LSR-ID of the receiver PE. - The Source Dual-homing PE Node_ID is the 32-bit identifier of the sending PE. Usually it is the same as the LSR-ID of the sending PE. - The DNI PW-ID field contains the 32-bit PW ID of the DNI PW. - The Flags field contains 32 bit flags, in which: o The P (Protection) bit indicates whether the Source Dual-homing PE is the working PE (P=0) or the protection PE (P=1). o Other bits are reserved for future use, which MUST be set to 0 on transmission and MUST be ignored upon receipt. - The Service PW Status field indicates the status of the Service PW between the sending PE and the remote PE. Currently two bits are defined in the Service PW Status field: o F bit: If set, it indicates Signal Fail (SF) [RFC6378] is generated on the service PW. It can be either a local request or a remote request received from the remote PE. o D bit: If set, it indicates Signal Degrade (SD) [RFC6378] generated on the service PW. It can be either a local request or a remote request received from the remote PE. o Other bits are reserved for future use, which MUST be set to 0 on transmission and MUST be ignored upon receipt. The Dual-Node Switching TLV is used by one dual-homing PE to send protection state coordination to the other PE in the same dual-homing group. Cheng, et al. Expires February 2, 2017 [Page 6] Internet-Draft Dual-Homing Coordination for MPLS-TP PWs August 2016quot;OAM MIP entities desired" bit is set in the Attribute Flags TLV in the LSP_REQUIRED_ATTRIBUTES object, it indicates that the establishment of OAM MIP entities is required at every transit node of the signaled LSP. 3.1. Establishment of OAM Entities and Functions In order to avoid spurious alarms, OAM functions should be set up and enabled in the appropriate order. When using the GMPLS control plane for both LSP establishment and enabling OAM functions on the LSPs, the control of both processes is bound to RSVP-TE message exchanges. An LSP may be signaled and established without OAM configuration first, and OAM entities may be added later with a subsequent re-signaling of the LSP. Alternatively, the LSP may be set up with OAM entities with the first signaling of the LSP. The procedures below apply to both cases. Before initiating a Path message with OAM configuration information, an initiating node MUST establish and configure the corresponding OAM entities locally. But until the LSP is established, OAM source functions MUST NOT start sending any OAM messages. In the case of bidirectional connections, in addition to the OAM source function, the initiator node MUST set up the OAM sink function and prepare it to receive OAM messages. During this time the OAM alarms MUST be suppressed (e.g., due to missing or unidentified OAM messages). To achieve OAM alarm suppression, Path messages MUST be sent with the "OAM Alarms Enabled" Admin_Status flag cleared. When the Path message arrives at the receiver, the remote end MUST establish and configure OAM entities according to the OAM information provided in the Path message. If this is not possible, a PathErr message SHOULD be sent, and neither the OAM entities nor the LSP SHOULD be established. If OAM entities are established successfully, the OAM sink function MUST be prepared to receive OAM messages but Takacs, et al. Standards Track [Page 8] RFC 7260 RSVP-TE-Based OAM Configuration June 2014 MUST NOT generate any OAM alarms (e.g., due to missing or unidentified OAM messages). In the case of bidirectional connections, in addition to the OAM sink function, an OAM source function MUST be set up and, according to the requested configuration, the OAM source function MUST start sending OAM messages. A Resv message MUST then be sent back, including the Attribute Flags TLV, with the appropriate setting of the "OAM MEP entities desired" and "OAM MIP entities desired" flags, and the OAM Configuration TLV that corresponds to the established and configured OAM entities and functions. Depending on the OAM technology, some elements of the OAM Configuration TLV MAY be updated/changed, i.e., if the remote end does not support a certain OAM configuration it may suggest an alternative setting, which may or may not be accepted by the initiator of the Path message. If it is accepted, the initiator will reconfigure its OAM functions according to the information received in the Resv message. If the alternate setting is not acceptable, a ResvErr message MAY be sent, tearing down the LSP. Details of this operation are technology specific and should be described in accompanying technology-specific documents. When the initiating side receives the Resv message, it completes any pending OAM configuration and enables the OAM source function to send OAM messages. After this exchange, OAM entities are established and configured for the LSP, and OAM messages are exchanged. OAM alarms can now be enabled. During the period when OAM alarms are disabled, the initiator sends a Path message with the "OAM Alarms Enabled" Admin_Status flag set. The receiving node enables OAM alarms after processing the Path message. The initiator enables OAM alarms after it receives the Resv message. Data-plane OAM is now fully functional. If an egress LSR does not support the extensions defined in this document, according to [RFC5420], it will silently ignore the new LSP attribute flags as well as the TLVs carrying additional OAM configuration information, and therefore no error will be raised that would notify the ingress LSR about the missing OAM configuration actions on the egress side. However, as described above, an egress LSR conformant to the specification of this document will set the LSP attribute flags and include the OAM Configuration TLV in the Resv message indicating the configuration of the OAM mechanisms; therefore, by detecting the missing information in the Resv message, an ingress LSR will be able to recognize that the remote end does not support the OAM configuration functionality, and therefore it SHOULD tear down the LSP and, if appropriate, signal the LSP without any OAM configuration information. Takacs, et al. Standards Track [Page 9] RFC 7260 RSVP-TE-Based OAM Configuration June 2014 3.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 LSP. To do so, the LSP needs to be re-signaled with the updated parameters. OAM parameters influence the content and timing of OAM messages and also identify the way that 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, the LSP MUST first be re-signaled with the "OAM Alarms Enabled" Admin_Status flag cleared, including the updated OAM Configuration TLV corresponding to the new parameter settings. The initiator MUST keep its OAM sink and source functions running unmodified, but it MUST suppress OAM alarms after the updated Path message is sent. The receiver MUST first disable all OAM alarms and then update the OAM parameters according to the information in the Path message and reply with a Resv message acknowledging the changes by including the OAM Configuration TLV. Note that the receiving side can adjust the requested OAM configuration parameters and reply with an updated OAM Configuration TLV in the Resv message, reflecting the values that are actually configured. 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 Path message to an extent that would provide lower performance (e.g., lower frequency of monitoring packets) than what had previously been in place. The initiator MUST only update its OAM sink and source functions after it receives the Resv message. After this Path/Resv message exchange (in both unidirectional and bidirectional LSP cases), the OAM parameters are updated, and OAM is running according to the new parameter settings. However, OAM alarms are still disabled. A subsequent Path/Resv message exchange with the "OAM Alarms Enabled" Admin_Status flag set is needed to enable OAM alarms again. Takacs, et al. Standards Track [Page 10] RFC 7260 RSVP-TE-Based OAM Configuration June 2014 3.3. Deleting OAM Entities In some cases, it may be useful to remove some or all OAM entities and functions from an LSP without actually tearing down the connection. To avoid any spurious alarms, first the LSP MUST be re-signaled with the "OAM Alarms Enabled" Admin_Status flag cleared but with OAM configuration unchanged. Subsequently, the LSP is re-signaled with "OAM MEP entities desired" and "OAM MIP entities desired" LSP attribute flags cleared, and without the OAM Configuration TLV, this MUST result in the deletion of all OAM entities associated with the LSP. All control-plane and data-plane resources in use by the OAM entities and functions SHOULD be freed up. Alternatively, if only some OAM functions need to be removed, the LSP is re-signaled 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 MUST be removed/added. OAM source functions MUST be deleted first, and only after the "OAM Alarms Disabled" can the associated OAM sink functions be removed; this will ensure that OAM messages do not leak outside the LSP. To this end, the initiator, before sending the Path message, MUST remove the OAM source, hence terminating the OAM message flow associated to the downstream direction. In the case of a bidirectional connection, it MUST leave in place the OAM sink functions associated to the upstream direction. The remote end, after receiving the Path message, MUST remove all associated OAM entities and functions and reply with a Resv message without an OAM Configuration TLV. The initiator completely removes OAM entities and functions after the Resv message arrives. 4. RSVP-TE Extensions 4.1. LSP Attribute Flags In RSVP-TE, the Flags field of the SESSION_ATTRIBUTE object is used to indicate options and attributes of the LSP. The Flags field has 8 bits and hence is limited to differentiate only 8 options. [RFC5420] defines new objects for RSVP-TE messages to allow the signaling of arbitrary attribute parameters, making RSVP-TE easily extensible to support new applications. Furthermore, [RFC5420] allows options and attributes that do not need to be acted on by all Label Switching Routers (LSRs) along the path of the LSP. In particular, these options and attributes may apply only to key LSRs on the path, such as the ingress LSR and egress LSR. Options and attributes can be signaled transparently and only examined at those points that need to act on them. The LSP_ATTRIBUTES and Takacs, et al. Standards Track [Page 11] RFC 7260 RSVP-TE-Based OAM Configuration June 2014 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=2 (Dual-Node Switching) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Dual-homing PE Node_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Dual-homing PE Node_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DNI PW-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |S|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. Dual-Node Switching TLV - The Length field specifies the length in octets of the value field of the TLV. - The Destination Dual-homing PE Node_ID is the 32-bit identifier of the receiver PE. Usually it is the same as the LSR-ID of the receiver PE. - The Source Dual-homing PE Node_ID is the 32-bit identifier of the sending PE. Usually it is the same as the LSR-ID of the sending PE. - The DNI PW-ID field contains the 32-bit PW-ID of the DNI PW. - The Flags field contains 32 bit flags, in which: o The P (Protection) bit indicates whether the Source Dual-homing PE is the working PE or the protection PE. It is set to 1 when the Source PE of the dual-node switching request is the protection PE. o The S (PW Switching) bit indicates which service PW is used for forwarding traffic. It is set to 0 when traffic will be transported on the working PW, and is set to 1 if traffic will be transported on the protection PW. The value of the S bit is determined by the protection coordination mechanism between the dual-homing PEs and the remote PE. o Other bits are reserved for future use, which MUST be set to 0 on transmission and MUST be ignored upon receipt. When a change of the service PW status is detected by one of the dual-homing PEs, it MUST be reflected in the PW Status TLV and sent to the other dual-homing PE immediately using 3 consecutive rapid DHC messages. After the transmission of the three rapid messages, the dual-homing PE MUST send the most recently transmitted service PW Cheng, et al. Expires February 2, 2017 [Page 7] Internet-Draft Dual-Homing Coordination for MPLS-TP PWs August 2016 status periodically to the other dual-homing PE using the continual DHC message. When one dual-homing PE determines that the active service PW needs to be switched from the working PW to the protection PW, It MUST send the Dual-Node Switching TLV to the other dual-homing PE immediately using 3 consecutive rapid DHC messages. After the transmission of the three rapid messages, the dual-homing PE MUST send the most recently transmitted Dual-Node Switching TLV periodically to the other dual-homing PE using the continual DHC messages. It is RECOMMENDED that the default interval of the first three rapid DHC messages is 3.3 ms, and the default interval of the subsequent messages is 1 second. Both the default frequency of the three rapid messages as well as the default frequency of the continual message transmission SHALL be configurable by the operator. 3.2. Protection Procedures The dual-homing MPLS-TP PW protection mechanism can be deployed with the existing AC redundancy mechanisms. On the PSN network side, PSN tunnel protection mechanism is not required, as the dual-homing PW protection can also protect the failure occurred in the PSN network. This section takes one-side dual-homing scenario as an example to describe the dual-homing PW protection procedures, the procedures for two-side dual-homing scenario would be similar. On dual-homing PE side, the role of working and protection PE are set by NMS or local configuration. The service PW connecting to the working PE is the working PW, and the service PW connecting to the protection PE is called the protection PW. On single-homing PE side, it just treats the working PW and protection PW as if they terminate on the same remote PE node, thus normal MPLS-TP protection coordination procedures still apply on the single-homing PE. The forwarding behavior of the dual-homing PEs is determined by the components shown in the figure below: Cheng, et al. Expires February 2, 2017 [Page 8] Internet-Draft Dual-Homing Coordination for MPLS-TP PWs August 2016 +---------------------------------+ +-----+ | PE1 (Working PE) | | | +---------------------------------+ | | | | | PW1 | | + Forwarder + Service X<-------->X | /| | PW | Working | | / +--------+--------+ | PW | | AC1 / | DNI PW | | | | / +--------X--------+---------------+ | | +-----+/ ^ | | | CE1 | | DNI PW | PE3 | +---+ +-----+ | | ---|CE3| \ V | | +---+ AC2 \ +--------X--------+---------------+ | | \ | DNI PW | | | | \ +--------+--------+ | | | \| | Service | PW2 | | + Forwarder + PW X<-------->X | | | |Protection| | +---------------------------------+ PW | | | PE2 (Protection PE) | | | +---------------------------------+ +-----+ Figure 5. Components of one-side dual-homing PW protection In figure 5, for each dual-homing PE, service PW is the PW used to carry service between the dual-homing PE and the remote PE. The state of the service PW is determined by the OAM mechanisms between the dual-homing PEs and the remote PE. DNI PW is provisioned between the two dual-homing PE nodes. It is used to bridge traffic when failure occurs in the PSN network or in the ACs. The state of DNI PW is determined by the OAM mechanism between the dual-homing PEs. Since DNI PW is used to carry both the coordination messages and the service traffic during protection switching, it is important to ensure the robustness of the DNI PW. In order to avoid the DNI PW failure due to the failure of a particular link, it is RECOMMENDED that multiple diverse links be deployed between the dual-homing PEs and the underlay LSP protection mechanism SHOULD be enabled. AC is the link which connects a dual-homing PE to the dual-homed CE. The status of AC is determined by some existing AC redundancy mechanisms, which is out of the scope of this document. In order to perform dual-homing PW local protection, the service PW status and Dual-node switching coordination requests are exchanged between the dual-homing PEs using the DHC message defined above. Cheng, et al. Expires February 2, 2017 [Page 9] Internet-Draft Dual-Homing Coordination for MPLS-TP PWs August 2016 Whenever a change of service PW status is detected by a dual-homing PE, it MUST be reflected in the PW Status TLV and sent to the other dual-homing PE immediately using using 3 consecutive rapid DHC messages. This way, both dual-homing PEs have the status of the working and protection PW consistently. When there is a switchover request either generated locally or received on the protection PW from the remote PE, based on the status of the working and protection service PW, along with the local and remote request of the protection coordination between the dual-homing PEs and the remote PE, the active/standby state of the service PW can be determined by the dual-homing PEs. As the remote protection coordination request is transmitted over the protection path, in this case the active/standby status of the service PW is determined by the protection PE in the dual-homing group. If it is determined on one dual-homing PE that switchover of service PW is needed, this dual-homing PE MUST set the S bit in the Dual-Node Switching TLV and send it to the other dual-homing PE immediately using 3 consecutive rapid DHC messages. With the exchange of service PW status and the switching request, both dual-homing PEs are consistent on the Active/Standby forwarding status of the working and protection service PWs. The status of DNI PW is determined by OAM mechanism, and the status of ACs are determined by existing AC redundancy mechanism, which is out of the scope of this document. The forwarding behavior on the dual-homing PE nodes is determined by the forwarding state machine as shown in table 1 of [I-D.ietf-pals-mpls-tp-dual-homing-protection]. Take the topology in figure 5 as an example, in normal state, the working PW (PW1) is in active state, the protection PW (PW2) is in standby state, the DNI PW is up, and AC1 is in active state according to the AC redundancy mechanism. According to the forwarding state machine in table 1 of [I-D.ietf-pals-mpls-tp-dual-homing-protection], traffic will be forwarded through the working PW (PW1) and the primary AC (AC1). No traffic will go through the protection PE (PE2) or the DNI PW, as both the protection PW (PW2) and the AC connecting to PE2 are in standby state. If a failure occurs in AC1, the state of AC2 changes to active according to the AC redundancy mechanism, while there is no change in the state of the working and protection PWs. According to the forwarding state machine in table 1 of [I-D.ietf-pals-mpls-tp-dual-homing-protection], PE1 starts to forward traffic between the working PW and the DNI PW, and PE2 starts to forward traffic between AC2 and the DNI PW. It should be noted that in this case only AC switchover takes place, in the PSN network traffic is still forwarded using the working PW. Cheng, et al. Expires February 2, 2017 [Page 10] Internet-Draft Dual-Homing Coordination for MPLS-TP PWs August 2016 If a failure in the PSN network brings PW1 to down, the failure can be detected by PE1 or PE3 using some OAM mechanism. If PE1 detects the failure of PW1, it MUST inform PE2 the state of working PW using the PW Status TLV in the DHC messages and change the forwarding status of PW1 to standby. On receipt of the DHC message, PE2 SHOULD change the forwarding status of PW2 to active. Then according to the forwarding state machine in table 1 of [I-D.ietf-pals-mpls-tp-dual-homing-protection], PE1 SHOULD set up the connection between the DNI PW and AC1, and PE2 SHOULD set up the connection between PW2 and the DNI PW. According to the linear protection mechanism [RFC6378], PE2 also sends an appropriate protection coordination message over the protection PW (PW2) to PE3, so that PE3 changes the forwarding status of PW2 to active, thus switchover from PW1 to PW2. If PE3 detects the failure of PW1, according to linear protection mechanism [RFC6378], it sends a protection coordination message on the protection PW (PW2) to inform PE2 of the failure on the working PW. Upon receipt of the message, PE2 SHOULD change the forwarding status of PW2 to active and set up the connection according to the forwarding state machine in table 1 of [I-D.ietf-pals-mpls-tp-dual-homing-protection]. PE2 SHOULD send a DHC message to PE1 with the S bit set in the Dual-Node Switching TLV to coordinate the switchover on PE1 and PE2. This could be useful for a unidirectional failure which cannot be detected by PE1. If a failure brings the working PE (PE1) to down, the failure can be detected by both PE2 and PE3 using some OAM mechanisms. Both PE2 and PE3 SHOULD change the forwarding status of PW2 to active, and send a protection coordination message on the protection PW (PW2) to inform the remote side to switchover. According to AC redundancy mechanism, the status of AC1 changes to standby, and the state of AC2 changes to active. According to the forwarding state machine in table 1 of [I-D.ietf-pals-mpls-tp-dual-homing-protection], PE2 starts to forward traffic between the PW2 and AC2. 4. IANA Considerations This documnet requests that IANA assigns one new channel type for "MPLS-TP Dual-Homing Coordination message" from the "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)" registry of the "Generic Associated Channel (G-ACh) Parameters" registry. Value Description Reference TBD MPLS-TP Dual-Homing Coordination message [This document] This documnet requests that IANA creates a new sub-registry called "MPLS-TP DHC TLVs" in the "Generic Associated Channel (G-ACh) Parameters" registry, with fields and initial allocations as follows: Cheng, et al. Expires February 2, 2017 [Page 11] Internet-Draft Dual-Homing Coordination for MPLS-TP PWs August 2016 LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC5420] to provide means to signal LSP attributes and options in the form of TLVs. Options and attributes signaled in the LSP_ATTRIBUTES object can be passed transparently through LSRs not supporting a particular option or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES object MUST be examined and processed by each LSR. One TLV is defined in [RFC5420]: the Attribute Flags TLV. One bit (bit number 10): "OAM MEP entities desired" is allocated in the Attribute Flags TLV to be used in the LSP_ATTRIBUTES object. If the "OAM MEP entities desired" bit is set, it indicates that the establishment of OAM MEP entities is required at the endpoints of the signaled LSP. If the establishment of MEPs is not supported, an error MUST be generated: "OAM Problem/MEP establishment not supported". If the "OAM MEP entities desired" bit is set and additional parameters need to be configured, an OAM Configuration TLV MAY be included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object. One bit (bit number 11): "OAM MIP entities desired" is allocated in the Attribute Flags TLV to be used in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects. If the "OAM MEP entities desired" bit is not set, then this bit MUST NOT be set. If the "OAM MIP entities desired" bit is set in the Attribute Flags TLV in the LSP_REQUIRED_ATTRIBUTES object, it indicates that the establishment of OAM MIP entities is required at every transit node of the signaled LSP. If the establishment of a MIP is not supported, an error MUST be generated: "OAM Problem/MIP establishment not supported". If an intermediate LSR does not support the extensions defined in this document, it will not recognize the "OAM MIP entities desired" flag and, although the LSP_REQUIRED_ATTRIBUTES object was used, it will not configure MIP entities and will not raise any errors. If LSRs that do not support the extensions defined in this document are to be assumed as present in the network, the ingress LSR SHOULD collect per-hop information about the LSP attributes utilizing the LSP Attributes sub-object of the Record Route object (RRO) as defined in [RFC5420]. When the Record Route object is received, the ingress SHOULD check whether all intermediate LSRs set the "OAM MIP entities desired" flag indicating support of the function; if not, depending on operator policy, the LSP MAY need to be torn down. Takacs, et al. Standards Track [Page 12] RFC 7260 RSVP-TE-Based OAM Configuration June 2014 4.2. OAM Configuration TLV This TLV provides information about which OAM technology/method should be used and carries sub-TLVs for any additional OAM configuration information. One OAM Configuration TLV MAY be carried in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object, it indicates that intermediate nodes MUST recognize and react on the OAM configuration information. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (3) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OAM Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ sub-TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: indicates a new type: the OAM Configuration TLV (3). OAM Type: specifies the technology-specific OAM method. When carried in the LSP_REQUIRED_ATTRIBUTES object, if the requested OAM method is not supported at any given node an error MUST be generated: "OAM Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES object, intermediate nodes not supporting the OAM Type pass the object forward unchanged as specified in [RFC5420]. Ingress and egress nodes that support the OAM Configuration TLV but that do not support a specific OAM Type MUST respond with an error indicating "OAM Problem/Unsupported OAM Type". OAM Type Description ------------ -------------------- 0-255 Reserved This document defines no types. IANA maintains the values in a new "RSVP-TE OAM Configuration Registry". Length: indicates the total length of the TLV in octets. The TLV MUST be zero-padded so that the TLV is 4-octet aligned. Two groups of TLVs are defined: generic sub-TLVs and technology- specific sub-TLVs. Generic sub-TLVs carry information that is applicable independent of the actual OAM technology, while technology-specific sub-TLVs are providing configuration parameters Takacs, et al. Standards Track [Page 13] RFC 7260 RSVP-TE-Based OAM Configuration June 2014 for specific OAM technologies. This document defines one generic sub-TLV (see Section 4.2.1), while it is foreseen that technology- specific sub-TLVs will be defined by separate documents. The receiving node, based on the OAM Type, will check to see if a corresponding technology-specific OAM configuration sub-TLV is included in the OAM Configuration TLV. If the included technology- specific OAM configuration sub-TLV is different from what is specified in the OAM Type, an error MUST be generated: "OAM Problem/ OAM Type Mismatch". IANA maintains the sub-TLV space in the new "RSVP-TE OAM Configuration Registry". Note that there is a hierarchical dependency between the OAM configuration elements. First, the "OAM MEP entities desired" flag needs to be set. Only when that flag is set MAY an OAM Configuration TLV be included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object. When this TLV is present, based on the "OAM Type" field, it MAY carry a technology-specific OAM configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP entities desired" flag is not set but an OAM Configuration TLV is present), an error MUST be generated: "OAM Problem/Configuration Error". 4.2.1. OAM Function Flags Sub-TLV The OAM Configuration TLV MUST always include a single instance of the OAM Function Flags Sub-TLV, and it MUST always be the first sub-TLV. "OAM Function Flags" specifies which proactive OAM functions (e.g., connectivity monitoring, loss and delay measurement) and which fault management signals MUST be established and configured. If the selected OAM Function or Functions are not supported, an error MUST be generated: "OAM Problem/Unsupported OAM Function". 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (1) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ OAM Function Flags ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Takacs, et al. Standards Track [Page 14] RFC 7260 RSVP-TE-Based OAM Configuration June 2014 OAM Function Flags is a bitmap with extensible length based on the Length field of the TLV. Bits are numbered from left to right. The TLV is padded to 4-octet alignment. The Length field indicates the size of the padded TLV in octets. IANA maintains the OAM Function Flags in the new "RSVP-TE OAM Configuration Registry". This document defines the following flags: OAM Function Flag bit # Description ----------------------- --------------------------------------------- 0 Continuity Check (CC) 1 Connectivity Verification (CV) 2 Fault Management Signal (FMS) 3 Performance Monitoring/Loss (PM/Loss) 4 Performance Monitoring/Delay (PM/Delay) 5 Performance Monitoring/Throughput Measurement (PM/Throughput) 4.2.2. Technology-Specific Sub-TLVs If technology-specific configuration information is needed for a specific "OAM Type", then this information is carried in a technology-specific sub-TLV. Such sub-TLVs are OPTIONAL, and an OAM Configuration TLV MUST NOT contain more than one technology-specific sub-TLV. IANA maintains the OAM technology-specific sub-TLV space in the new "RSVP-TE OAM Configuration Registry". 4.3. Administrative Status Information Administrative Status Information is carried in the Admin_Status object, which is specified for RSVP-TE in [RFC3473]. Administrative Status Information is described in [RFC3471]. Two bits (bit numbers 23 and 24) are allocated by this document for the administrative control of OAM monitoring: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms MUST be enabled; if it is cleared, OAM mechanisms MUST be disabled. When the "OAM Alarms Enabled" bit is set, OAM-triggered alarms are enabled and associated consequent actions MUST be executed, including the notification to the management system. When this bit is cleared, alarms are suppressed, and no action SHOULD be executed; additionally, the management system SHOULD NOT be notified. For a detailed description of the use of these flags, see Section 3. Takacs, et al. Standards Track [Page 15] RFC 7260 RSVP-TE-Based OAM Configuration June 2014 4.4. Handling OAM Configuration Errors To handle OAM configuration errors, a new Error Code "OAM Problem" (40) is introduced. To refer to specific problems, a set of Error Values are defined under the "OAM Problem" error code. If a node does not support the establishment of OAM MEP or MIP entities it MUST use the error value "MEP establishment not supported" or "MIP establishment not supported", respectively, in the PathErr message. If a node does not support a specific OAM technology/solution, it MUST use the error value "Unsupported OAM Type" in the PathErr message. If a different technology-specific OAM Configuration TLV is included than what was specified in the OAM Type, an error MUST be generated with error value "OAM Type Mismatch" in the PathErr message. There is a hierarchy between the OAM configuration elements. If this hierarchy is broken, the error value "Configuration Error" MUST be used in the PathErr message. If a node does not support a specific OAM Function, it MUST use the error value "Unsupported OAM Function" in the PathErr message. 4.5. Considerations on Point-to-Multipoint OAM Configuration RSVP-TE extensions for the establishment of point-to-multipoint (P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between the ingress and egress LSRs and are appropriately combined by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. One Path message may signal one or multiple S2L sub-LSPs for a single P2MP LSP. Hence, the S2L sub-LSPs belonging to a P2MP LSP can be signaled using one Path message or split across multiple Path messages. P2MP OAM mechanisms are very specific to the data-plane technology; therefore, in this document we only highlight the basic principles of P2MP OAM configuration. We consider only the root-to-leaf OAM flows, and as such, aspects of the configuration of return paths are outside the scope of our discussions. We also limit our consideration to the case where all leaves must successfully establish OAM entities with identical configuration in order for the P2MP OAM to be successfully established. In any case, the discussion set forth below provides Takacs, et al. Standards Track [Page 16] RFC 7260 RSVP-TE-Based OAM Configuration June 2014 only guidelines for P2MP OAM configuration. However, at a minimum, the procedures below SHOULD be specified for P2MP OAM configuration in a technology-specific document. The root node may use a single Path message or multiple Path messages to set up the whole P2MP tree. In the case when multiple Path messages are used, the root node is responsible for keeping the OAM configuration information consistent in each of the sent Path messages, i.e., the same information MUST be included in all Path messages used to construct the multicast tree. Each branching node will propagate the Path message downstream on each of the branches; when constructing a Path message, the OAM configuration information MUST be copied unchanged from the received Path message, including the related Admin_Status bits, LSP attribute flags, and OAM Configuration TLV. The latter two also imply that the LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects MUST be copied for the upstream Path message to the subsequent downstream Path messages. Leaves MUST create and configure OAM sink functions according to the parameters received in the Path message; for P2MP OAM configuration, there is no possibility for parameter negotiation on a per-leaf basis. This is due to the fact that the OAM source function, residing in the root of the tree, will operate with a single configuration, which then must be obeyed by all leaves. If a leaf cannot accept the OAM parameters, it MUST use the RRO Attributes sub-object [RFC5420] to notify the root about the problem. In particular, if the OAM configuration was successful, the leaf would set the "OAM MEP entities desired" flag in the RRO Attributes sub-object in the Resv message. On the other hand, if OAM entities could not be established, the Resv message should be sent with the "OAM MEP entities desired" bit cleared in the RRO Attributes sub-object. Branching nodes should collect and merge the received RROs according to the procedures described in [RFC4875]. This way, the root, when receiving the Resv message (or messages if multiple Path messages were used to set up the tree), will have clear information about which of the leaves could establish the OAM functions. If all leaves established OAM entities successfully, the root can enable the OAM message flow. On the other hand, if at some leaves the establishment was unsuccessful, additional actions will be needed before the OAM message flow can be enabled. Such action could be to set up two independent P2MP LSPs: o One LSP with OAM configuration information towards leaves that can support the OAM function. This can be done by pruning from the previously signaled P2MP LSP the leaves that failed to set up OAM. o The other P2MP LSP could be constructed for leaves without OAM entities. Takacs, et al. Standards Track [Page 17] RFC 7260 RSVP-TE-Based OAM Configuration June 2014 The exact procedures will be described in technology-specific documents. 5. IANA Considerations 5.1. Admin_Status Object Bit Flags IANA maintains a registry called "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" with a sub-registry called "Administrative Status Information Flags". IANA has allocated two new flags as follows: Bit Number | Hex Value | Name | Reference -----------+------------+--------------------------+----------- 23 | 0x00000100 | OAM Flows Enabled (M) | [RFC7260] 24 | 0x00000080 | OAM Alarms Enabled (O) | [RFC7260] 5.2. LSP Attribute Flags IANA maintains a registry called "Resource Reservation Protocol- Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called "Attribute Flags". IANA has allocated two new flags as follows: Bit | | Attribute | Attribute | | No. | Name | Flags Path | Flags Resv | RRO | Reference ----+------------------+------------+------------+-----+---------- 10 | OAM MEP | | | | | entities desired | Yes | Yes | Yes | [RFC7260] | | | | | 11 | OAM MIP | | | | | entities desired | Yes | Yes | Yes | [RFC7260] Takacs, et al. Standards Track [Page 18] RFC 7260 RSVP-TE-Based OAM Configuration June 2014 5.3. New LSP Attributes IANA maintains a registry called "Resource Reservation Protocol- Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called "Attributes TLV Space". IANA has allocated one new TLV type as follows: | | |Allowed on | | |Allowed on |LSP_REQUIRED_| Type| Name |LSP_ATTRIBUTES|ATTRIBUTES |Reference ----+----------------------+--------------+-------------+--------- 3 | OAM Configuration TLV| Yes | Yes |[RFC7260] 5.4. RSVP Error Code IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a sub-registry called "Error Codes and Globally-Defined Error Value Sub-Codes". IANA has allocated one new Error Code as follows: Error Code | Meaning | Reference -----------+-------------+------------- 40 | OAM Problem | [RFC7260] The following Error Value sub-codes are defined for this new Error Code: Value | Description | Reference -----------+---------------------------------+-------------- 0 | Reserved | [RFC7260] 1 | MEP establishment not supported | [RFC7260] 2 | MIP establishment not supported | [RFC7260] 3 | Unsupported OAM Type | [RFC7260] 4 | Configuration Error | [RFC7260] 5 | OAM Type Mismatch | [RFC7260] 6 | Unsupported OAM Function | [RFC7260] 7-32767 | Unassigned | 32768-65535| Reserved for Private Use | [RFC7260] Takacs, et al. Standards Track [Page 19] Type Description Length Reference 0x00 Reserved 0x01 PW Status 20 Bytes [this document] 0x02 Dual-Node Switching 16 Bytes [this document] The allocation policy for this registry is IETF Review or IESG Approval. 5. Security Considerations Procedures and protocol extensions defined in this document do not affect the security model of MPLS-TP linear protection as defined in [RFC6378]. Please refer to [RFC5920] for MPLS security issues and generic methods for securing traffic privacy and integrity. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <http://www.rfc-editor.org/info/rfc5586>. [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, October 2011, <http://www.rfc-editor.org/info/rfc6378>. [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, <http://www.rfc-editor.org/info/rfc7271>. [RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear Protection", RFC 7324, DOI 10.17487/RFC7324, July 2014, <http://www.rfc-editor.org/info/rfc7324>. Cheng, et al. Expires February 2, 2017 [Page 12] Internet-Draft Dual-Homing Coordination for MPLS-TP PWs August 2016 6.2. Informative References [I-D.ietf-pals-mpls-tp-dual-homing-protection] Cheng, W., Wang, L., Li, H., Liu, K., Davari, S., Dong, J., and A. D'Alessandro, "Dual-Homing Protection for MPLS and MPLS-TP Pseudowires", draft-ietf-pals-mpls-tp-dual- homing-protection-03 (work in progress), June 2016. [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>. [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, DOI 10.17487/RFC6372, September 2011, <http://www.rfc-editor.org/info/rfc6372>. [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire Redundancy", RFC 6718, DOI 10.17487/RFC6718, August 2012, <http://www.rfc-editor.org/info/rfc6718>. [RFC6870] Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire Preferential Forwarding Status Bit", RFC 6870, DOI 10.17487/RFC6870, February 2013, <http://www.rfc-editor.org/info/rfc6870>. [RFC7771] Malis, A., Ed., Andersson, L., van Helvoort, H., Shin, J., Wang, L., and A. D'Alessandro, "Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires", RFC 7771, DOI 10.17487/RFC7771, January 2016, <http://www.rfc-editor.org/info/rfc7771>. Authors' Addresses Weiqiang Cheng China Mobile No.32 Xuanwumen West Street Beijing 100053 China Email: chengweiqiang@chinamobile.com Cheng, et al. Expires February 2, 2017 [Page 13] Internet-Draft Dual-Homing Coordination for MPLS-TP PWs August 2016 Lei Wang China Mobile No.32 Xuanwumen West Street Beijing 100053 China Email: Wangleiyj@chinamobile.com Han Li China Mobile No.32 Xuanwumen West Street Beijing 100053 China Email: Lihan@chinamobile.com Kai Liu Huawei Technologies Huawei Base, Bantian, Longgang District Shenzhen 518129 China Email: alex.liukai@huawei.com Shahram Davari Broadcom Corporation 3151 Zanker Road San Jose 95134-1933 United States Email: davari@broadcom.com Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Cheng, et al. Expires February 2, 2017 [Page 14] Internet-Draft Dual-Homing Coordination for MPLS-TP PWs August 2016 Alessandro D'Alessandro Telecom Italia via Reiss Romoli, 274 Torino 10148 Italy Email: alessandro.dalessandro@telecomitalia.it Cheng, et al. Expires February 2, 2017 [Page 15] RFC 7260 RSVP-TE-Based OAM Configuration June 2014