PWE3 | T. Nadeau |
Internet-Draft | lucidvision |
Updates: 4447, 5085 (if approved) | L. Martini |
Intended status: Standards Track | S. Bryant |
Expires: June 20, 2015 | Cisco Systems |
December 17, 2014 |
VCCV Default CC Types
draft-ietf-pals-vccv-for-gal-00
This document specifies the default Virtual Circuit Connectivity Verification (VCCV) (RFC5085) control channel type to be used when the pseudowire control word is present and when it is not present. A new VCCV control channel type using the Generic Associated Channel Label (RFC5586) is specified for use when the control word not present.
This document updates RFC4447 and RFC5085.
Note to be removed at publication: this document started out as draft-ietf-pwe3-vccv-for-gal and got to version -02. When PWE3 was absorbed into PALS the next version published was draft-ietf-pals-vccv-for-gal-00
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 June 20, 2015.
Copyright (c) 2014 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
There is a need for fault detection and diagnostic mechanisms that can be used for end-to-end fault detection and diagnostics for a Pseudowire, as a means of determining the PW's true operational state. Operators have indicated in [RFC4377], and [RFC3916] that such a tool is required for PW operation and maintenance. To this end, the IETF's PWE3 Working Group defined the Virtual Circuit Connectivity Verification Protocol (VCCV) in [RFC5085] . Since then a number of interoperability issues have arisen with the protocol as it is defined.
Over time, a variety of VCCV options or "modes" have been created to support legacy hardware, these modes use of the CW in some cases, while in others the CW is not used. The difficulty of operating these different combinations of "modes" have been detailed in an implementation survey conducted by the PWE3 Working Group and documented in [RFC7079]. The implementation survey and the PWE3 Working Group have concluded that operators have difficulty deploying the VCCV OAM protocol due to the number of combinations and options for its use.
In addition to the implementation issues just described, the ITU-T and IETF have set out to enhance MPLS to make it suitable as an optical transport protocol. The requirements for this protocol are defined as the MPLS Transport Profile (MPLS-TP). The requirements for MPLS-TP can be found in [RFC5654]. In order to support VCCV when an MPLS-TP PSN is in use, the GAL-ACH had to be created [RFC5586]. This resulted in yet another mode of VCCV operation.
This document specifies that there are two default modes of operation of VCCV: 1) with a control word or 2) without a control word, both with a ACH encapsulation [RFC4385] making it possible to handle all of the other cases handled by the other modes of VCCV. The modes of operation defined in this document MUST be implemented.
VCCV messages are encapsulated using the PWE3 encapsulation as described in Section 3 and Section 4, so that they are handled and processed in the same manner (or in some cases, a similar manner) the PW PDUs for which they provide a control channel. These VCCV messages are exchanged only after the capability (the VCCV Control Channel and Connectivity Verification types) and the desire to exchange VCCV traffic has been advertised between the PEs (see Sections 5.3 of [RFC5085]), and VCCV type to use has been chosen.
When the PWE3 Control Word is used to encapsulate pseudowire traffic, the rules described for encapsulating VCCV CC Type 1 as specified in section 9.5.1 of [RFC6073] and section 5.1.1 of [RFC5085] MUST be used. In this case the advertised CC Type is 1, and Associated Channel Types of 21, 07, or 57 are allowed.
When the PWE3 Control Word is not used, the new VCCV CC Type 4 defined in this section MUST be used. VCCV CC Type 4 uses the encapsulation shown in Figure 1.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW LSE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL LSE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Associated Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ VCCV Message Body ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
When the PW is a single segment PW, the TTL field of the PW Label Stack Entry (LSE) MUST be set to 2. TTL=2, rather than the more obvious TTL=1, is used because of legacy hardware considerations. In the case of multi-segment pseudo-wires, the PW LSE TTL MUST be set to the value needed to reach the intended destination PE as described in [RFC6073].
The GAL LSE MUST contain the GAL reserved label as defined in [RFC5586].
As defined in [RFC4385] and [RFC4446] the first nibble of the next field is set to 0001b to indicate an ACH is being carried instead of PW data. The Version and the Reserved fields MUST be set to 0, and the Channel Type is set to 0x0021 for IPv4, 0x0057 for IPv6 payloads [RFC5085] or 0x0007 for BFD payloads [RFC5885].
The Associated Channel Type defines how the "VCCV Message Body" field is to be interpreted by the receiver.
When the flow-aware transport of pseudowires over an MPLS packet switched network [RFC6391] has been signalled or configured, the Flow LSE MUST always be present. When VCCV CC Type 4 is in use the Flow LSE MUST be immediately below the PW LSE in the label stack, and the GAL MUST be at the bottom of the label stack. This is shown in Figure 2.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW LSE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow LSE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL LSE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Associated Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ VCCV Message Body ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
The ELI mechanism [RFC6790] applies to the MPLS LSP that carries the PW and is therefore out of scope of this specification.
The VCCV capability advertisement MUST match the c-bit setting that is advertised in the PW FEC element [RFC4447]. If the c-bit is set, indicating the use of the control word, VCCV CC Type 1 MUST be advertised and VCCV CC Type 4 MUST NOT be advertised. If the c-bit is not set, indicating that the control word is not in use, VCCV CC Type 4 MUST be advertised, and VCCV CC Type 1 MUST NOT be advertised.
A PE supporting VCCV CC Type 4 MAY advertise other CC types as defined in [RFC5085] . If the remote PE also supports VCCV CC Type 4, then VCCV CC Type 4 MUST be used superseding the Capability Advertisement Selection rules of Section 7 from [RFC5085] . If a remote PE does not support VCCV CC Type 4, then the rules from Section 7 of [RFC5085] apply. If a CW is in use, then VCCV CC Type 4 is not applicable, and therefore the normal capability advertisement selection rules of Section 7 from [RFC5085] apply.
By introducing default VCCV CC types, and improving the compatibility with MPLS-TP, the compatibility of implementations is improved and management and configuration of the network becomes simpler.
Network operators should note that the presence of the GAL may cause the PW packet and associated VCCV packets to be subjected to different ECMP choices and thus not fate share. This effect is not present in networks that support [RFC6790] since reserved labels are ignored during ECMP path selection.
This document does not by itself raise any new security considerations beyond those described in [RFC5085].
IANA is requested to assign a new bit from the MPLS VCCV Control Channel (CC) Types registry in the PWE3-parameters name space in order to identify VCCV type 4. It is recommended that Bit 3 be assigned to this purpose which would have a value of 0x08.
MPLS VCCV Control Channel (CC) Types Bit (Value) Description Reference ============ =========== ==================== Bit X (0x0Y) Type 4 [This Specification]
[RFC3916] | Xiao, X., McPherson, D. and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004. |
[RFC3985] | Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. |
[RFC4377] | Nadeau, T., Morrow, M., Swallow, G., Allan, D. and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006. |
[RFC7079] | Del Regno, N. and A. Malis, "The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results", RFC 7079, November 2013. |