MPLS-TP VCCV: Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP)
How two pseudowire edge routers agree to use MPLS-TP connectivity checks, without confusing older equipment.
Mirsky, G., "Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP)", RFC 7189, DOI 10.17487/RFC7189, March 2014, <https://www.rfc-editor.org/info/rfc7189>.
@misc{rfc7189,
series = {Request for Comments},
number = 7189,
howpublished = {RFC 7189},
publisher = {RFC Editor},
doi = {10.17487/RFC7189},
url = {https://www.rfc-editor.org/info/rfc7189},
author = {G. Mirsky},
title = {{Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP)}},
pagetotal = 7,
year = 2014,
month = mar,
} RFC text
Contents
Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 7189 Ericsson
Category: Standards Track March 2014
ISSN: 2070-1721
Virtual Circuit Connectivity Verification (VCCV)
Capability Advertisement for 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 of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 2
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 2
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3
2. MPLS-TP CC-CV on Pseudowires . . . . . . . . . . . . . . . . 3
2.1. VCCV Extended CV Advertisement Sub-TLV . . . . . . . . . 3
2.2. MPLS-TP CC-CV Types . . . . . . . . . . . . . . . . . . . 3
2.3. MPLS-TP CC-CV Type Operation . . . . . . . . . . . . . . 4
2.4. CV Type Selection . . . . . . . . . . . . . . . . . . . . 4
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
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. Conventions Used in This 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] [RFC4447]. Currently, 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 Advertisement Sub-TLV
The format of the VCCV Extended CV Advertisement is a TLV 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 CV Parameter 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 in 4-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 capable of supporting. The VCCV Extended CV parameter sub-
TLV MUST appear in combination with the VCCV parameter sub-TLV. If
the VCCV parameter sub-TLV is missing, 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-point bidirectional connection that can be applied to
monitoring PWs. At the same time, [RFC6310] defines how BFD-based
Operations, Administration, and Maintenance (OAM) can map to the
status of an Attachment Circuit. Thus, there could be four MPLS-TP
CV types for each combination of mode 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 Operation
According to [RFC6428], connectivity verification is part of MPLS-TP
CC/CV operation that can be used with VCCV Control Channel Type 1
[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 list
(ordered by descending priority) is used:
1. 0x08 - Coordinated mode for PW Fault Detection and AC/PW Fault
Status Signaling
2. 0x04 - Coordinated mode for PW Fault Detection only
3. 0x02 - Independent mode for PW Fault Detection and AC/PW Fault
Status Signaling
4. 0x01 - Independent mode for PW Fault Detection only
3. IANA Considerations
The PW Interface Parameters Sub-TLV registry is defined in [RFC4446].
IANA has 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
IANA has set up a registry of VCCV Extended CV Types. These are
8-bit values. Extended CV Type values 0x01, 0x02, 0x04, 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 beyond those.
5. Acknowledgements
The author gratefully acknowledges the thoughtful review, comments,
and explanations provided by Dave Allan and Carlos 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
Ericsson
EMail: gregory.mirsky@ericsson.com
AI ELI5
On this page
§1Why VCCV Needs an Update
Proactive Connectivity Verification (CV), Continuity Check (CC) and Remote Defect Indication (RDI) for the MPLS Transport Profile are defined in RFC 6428. They apply to every construct of MPLS-TP, including pseudowires (PWs).
When a control plane sets up and manages PWs, the procedures of RFC 5085 and RFC 5885 pick the type of control channel and the matching type of connectivity verification. This document changes the signaling and selection steps so that proactive CV-CC-RDI can be used over MPLS-TP PWs and older implementations keep working.
Some network lines already have a way to check they are alive. This RFC teaches the two ends a new, better way to check, and makes sure old equipment is not confused.
§2.1The VCCV Extended CV Sub-TLV
PW VCCV can support several CV types, advertised in the CV Types field of the VCCV Interface Parameter sub-TLV. Six types had been defined. This document adds four more and defines a new VCCV Extended CV parameter for the PW Interface Parameters Sub-TLV to carry them.
The sub-TLV has a Type of 0x19, a Length, a CV Type bitmask and a Reserved field. Length covers the whole sub-TLV, including the type and length fields, and the minimum is 4. Extensions should be made in 4-byte increments. Reserved MUST be set to zeroes on transmit and ignored on receive.
The CV Type bitmask lists the kinds of CV monitoring a provider edge router (PE) can support. The sub-TLV MUST appear together with the VCCV parameter sub-TLV. If the VCCV parameter sub-TLV is missing, the extended sub-TLV SHOULD be ignored.
It is a small form with tick boxes. Each tick box says one kind of check the router can do, and a blank part is left for the future.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
TYPE | Type | 1 byte | 0x19 | Sub-TLV type. |
LENGTH | Length | 1 byte | Length of the sub-TLV including type and length; minimum 4. | |
CV-TYPE | CV Type | 1 byte | Bitmask of the CV monitoring types the PE supports. | |
RESERVED | Reserved | 1 byte | Zeroes on transmit, ignored on receive. |
§2.2The Four MPLS-TP CC-CV Types
RFC 6428 defines coordinated and independent modes for monitoring a point-to-point bidirectional connection, and RFC 6310 defines how BFD-based OAM maps to the status of an Attachment Circuit. Combining the two modes with two kinds of functionality gives four CV types.
0x01: independent mode, fault detection only.0x02: independent mode, fault detection and status signaling.0x04: coordinated mode, fault detection only.0x08: coordinated mode, fault detection and status signaling.
There are two styles of checking and two jobs a check can do. Two styles times two jobs makes four kinds of check, each with its own tick box.
§2.4Operation and CV Type Selection
MPLS-TP connectivity verification can be used with VCCV Control Channel Type 1. If that channel type is selected, PEs MAY select one of the MPLS-TP CC-CV types as the CV mechanism for the PW.
The selection rules of Section 7 of RFC 5085, updated by Section 4 of RFC 5885, are extended. If the common set of proactive CV types advertised by both PEs includes MPLS-TP CC-CV types and some BFD CV types, MPLS-TP CC-CV takes precedence over any BFD CV type. If several MPLS-TP types are common to both PEs, the highest priority is chosen from this list: 0x08, then 0x04, then 0x02, then 0x01.
If both sides know several kinds of check, they use the fanciest one they share. The new kinds beat the older kinds.
- 0x08Coordinated, with status signaling — Coordinated mode for PW Fault Detection and AC/PW Fault Status Signaling.
- 0x04Coordinated, detection only — Coordinated mode for PW Fault Detection only.
- 0x02Independent, with status signaling — Independent mode for PW Fault Detection and AC/PW Fault Status Signaling.
- 0x01Independent, detection only — Independent mode for PW Fault Detection only.
§3IANA Registrations
IANA reserved a new PW Interface Parameters Sub-TLV type, 0x19, with variable length, named VCCV Extended CV Parameter.
IANA also set up a registry of VCCV Extended CV Types. The values are 8 bits. Values 0x01, 0x02, 0x04 and 0x08 are those above. The remaining values, 0x10 through 0x80, are assigned under the IETF Review policy, which requires a description and a reference to an RFC approved by the IESG.
A librarian keeps the official list of tick boxes. Four are taken and four are saved for later, to be handed out only after careful review.
§4Security Considerations
Routers that implement the additional CV types are subject to the same security considerations as RFC 5085, RFC 5880, RFC 5881 and RFC 6428. The document says it raises no additional security issues beyond those.
Nothing new to worry about here. The same safety rules as before still apply.