Network Working GroupInternet Engineering Task Force (IETF) G. MirskyInternet-DraftRequest for Comments: 7189 EricssonIntended status:Category: Standards TrackJanuary 23, 2014 Expires: July 27,March 2014VCCV MPLS-TPISSN: 2070-1721 Virtual Circuit Connectivity Verification(CV)(VCCV) Capability Advertisementdraft-ietf-pwe3-mpls-tp-cv-adv-06for MPLS Transport Profile (MPLS-TP) Abstract This document specifies how signaling and selection processes for Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) are modified to ensure backward compatibility and allow use of proactive Connectivity Verification (CV), Continuity Check (CC), and Remote Defect Indication (RDI) over MPLS Transport Profile (MPLS-TP) PWs. This document introduces four new CV types and, to accommodate them, a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV is defined. Status ofthisThis Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany 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 July 27, 2014.http://www.rfc-editor.org/info/rfc7189. Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .. 32 1.1. ConventionsusedUsed inthis document .This Document . . . . . . . . . . . .32 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . .. 32 1.1.2. Requirements Language . . . . . . . . . . . . . . . ..3 2. MPLS-TP CC-CV on Pseudowires . . . . . . . . . . . . . . . ..3 2.1. VCCV Extended CV Advertisementsub-TLV .Sub-TLV . . . . . . . . . 3 2.2. MPLS-TP CC-CV Types . . . . . . . . . . . . . . . . . . .. 43 2.3. MPLS-TP CC-CV Type Operation . . . . . . . . . . . . . ..4 2.4. CV Type Selection . . . . . . . . . . . . . . . . . . . .. 54 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . ..5 3.1. VCCV Extended CV Types . . . . . . . . . . . . . . . . ..5 4. Security Considerations . . . . . . . . . . . . . . . . . . ..6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . ..6 6. References . . . . . . . . . . . . . . . . . . . . . . . . ..6 6.1. Normative References . . . . . . . . . . . . . . . . . ..6 6.2. Informative References . . . . . . . . . . . . . . . . .. 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .7 1. Introduction Proactive Connectivity Verification (CV), Continuity Check (CC), and Remote Defect Indication (RDI) for the MPLS Transport Profile [RFC6428] are applicable to all constructs of the MPLS-TP, including pseudowires (PWs). If the control plane is used to operate and manage PWs then the procedures defined in [RFC5085] and [RFC5885] should be used to select the proper type of Control Channel and the corresponding type of Connectivity Verification. This document specifies how signaling and selection processes are modified to ensure backward compatibility and allow use of proactive CV-CC-RDI over MPLS-TP PWs. 1.1. ConventionsusedUsed inthis documentThis Document 1.1.1. Terminology BFD: Bidirectional Forwarding Detection CC: Continuity Check CV: Connectivity Verification PE: Provider Edge VCCV: Virtual Circuit Connectivity Verification 1.1.2. Requirements Language 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]. 2. MPLS-TP CC-CV on Pseudowires PW VCCV can support several CV Types, and it can support an arbitrary combination of CV modes advertised in the CV Types field of the VCCV Interface Parameter sub-TLV[RFC4446],[RFC4446] [RFC4447].CurrentlyCurrently, six types of CV have been defined for PW VCCV. This document introduces four new CV types and, to accommodate them, a new VCCV Extended CV parameter for the PW Interface Parameters Sub-TLV is defined. 2.1. VCCV Extended CV Advertisementsub-TLVSub-TLV The format of the VCCV Extended CV Advertisement is a TLVwhere:where the format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x19 | Length | CV Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: VCCV Extended CVparameter formatParameter Format The Length field is the length of the sub-TLV, including type and the Length field itself. The minimum length is 4. It is recommended that extensions to the sub-TLV be done in4 bytes4-byte increments. The Reserved field MUST be set to zeroes on transmit and ignored on receive. The CV Type field is a bitmask that lists types of CV monitoring that a PE is capableto support.of supporting. The VCCV Extended CV parametersub-TLVsub- TLV MUST appear in combination with the VCCV parameter sub-TLV. If the VCCV parameter sub-TLV ismissingmissing, then the VCCV Extended CV parameter sub-TLV SHOULD be ignored. 2.2. MPLS-TP CC-CV Types [RFC6428] defines coordinated and independent modes of monitoring point-to-pointbi-directionalbidirectional connection that can be applied to monitoring PWs. At the sametimetime, [RFC6310] defines how BFD-basedOAMOperations, Administration, and Maintenance (OAM) can mapand be mappedto the status of an Attachment Circuit.ThusThus, there could be four MPLS-TP CV typesasfor each combination ofmodesmode and functionality: +----------------+-------------------+------------------------------+ | Modes | Fault Detection | Fault Detection and Status | | | Only | Signaling | +----------------+-------------------+------------------------------+ | Independent | 0x01 | 0x02 | | Mode | | | | Coordinated | 0x04 | 0x08 | | Mode | | | +----------------+-------------------+------------------------------+ Table 1: Bitmask Values for MPLS-TP CV Types 2.3. MPLS-TP CC-CV Type OperationConnectivity verification accordingAccording to[RFC6428][RFC6428], connectivity verification is part of MPLS-TP CC/CV operation that can be used with VCCV Control Channel Type 1[RFC5085] .[RFC5085]. If VCCV Control Channel Type 1 is selected, then PEs MAY select one of the MPLS-TP CC-CV types as the VCCV CV mechanism to be used for this PW. 2.4. CV Type Selection CV selection rules that have been defined in Section 7 of [RFC5085] and updated in Section 4 of [RFC5885] are augmented in this document. If VCCV Control Channel Type 1 is chosen according to Section 7 of [RFC5085] and a common set of proactive CV types that are advertised by both PEs includes MPLS-TP CC-CV types and some BFD CV types, then MPLS-TP CC-CV takes precedence over any type of BFD CV. If multiple MPLS-TP CV types are advertised by both PEs, then the following listsorted in(ordered by descendingpriority orderpriority) is used: 1. 0x08 -coordinatedCoordinated mode for PW Fault Detection and AC/PW Fault Status Signaling 2. 0x04 -coordinatedCoordinated mode for PW Fault Detection only 3. 0x02 -independentIndependent mode for PW Fault Detection and AC/PW Fault Status Signaling 4. 0x01 -independentIndependent mode for PW Fault Detection only 3. IANA Considerations The PW Interface Parameters Sub-TLV registry is defined in [RFC4446]. IANAis requested to reservehas reserved a new PW Interface Parameters Sub-TLV type as follows: +-----------+----------+----------------------------+---------------+ | Parameter | Length | Description | Reference | | ID | | | | +-----------+----------+----------------------------+---------------+ | 0x19 | variable | VCCV Extended CV Parameter | This document | +-----------+----------+----------------------------+---------------+ Table 2: New PW Interface Parameters Sub-TLV 3.1. VCCV Extended CV Types IANAis requested tohas set up a registry of VCCV Extended CV Types. These are8 bit8-bit values. Extended CV Type values 0x01, 0x02,0x040x04, and 0x08 are specified in Section 2.2 of this document. The remaining values (0x10 through 0x80) are to be assigned by IANA using the "IETF Review" policy defined in [RFC5226]. A VCCV Extended Connectivity Verification Type description and a reference to an RFC approved by the IESG are required for any assignment from this registry. +--------------+----------------------------------------------------+ | Bit(Value) | Description | +--------------+----------------------------------------------------+ | Bit 0 (0x01) | Independent mode for PW Fault Detection only | | Bit 1 (0x02) | Independent mode for PW Fault Detection and AC/PW | | | Fault Status Signaling | | Bit 2 (0x04) | Coordinated mode for PW Fault Detection only | | Bit 3 (0x08) | Coordinated mode for PW Fault Detection and AC/PW | | | Fault Status Signaling | | Bit 4 (0x10) | Unassigned | | Bit 5 (0x20) | Unassigned | | Bit 6 (0x40) | Unassigned | | Bit 7 (0x80) | Unassigned | +--------------+----------------------------------------------------+ Table 3: VCCV Extended Connectivity Verification (CV) Types 4. Security Considerations Routers that implement the additional CV Type defined herein are subject to the same security considerations as defined in [RFC5085], [RFC5880], [RFC5881], and [RFC6428]. This specification does not raise any additional security issues beyondthese.those. 5. Acknowledgements The author gratefully acknowledges the thoughtful review, comments, and explanations provided by DaveAllan,Allan andbyCarlos Pignataro. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010. [RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping", RFC 6310, July 2011. [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, November 2011. 6.2. Informative References [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Author's Address Greg Mirsky EricssonEmail:EMail: gregory.mirsky@ericsson.com