PALS T. Nadeau
Internet-Draft lucidvision
Intended status: Standards Track L. Martini
Expires: March 27, 2016 S. Bryant
Cisco Systems
September 24, 2015

Using A Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator


The Virtual Circuit Connectivity Verification (VCCV) protocol specified in RFC 5085 provides a control channel (CC) that is associated with a pseudowire (PW). This document specifies an additional VCCV control channel type to be used with pseudowires (PW) which do not use the PW Control Word and which are carried over an MPLS network. This new VCCV CC type uses the Generic Associated Channel Label defined in RFC5586 to distinguish VCCV packets from packets carrying user data. This new VCCV CC type introduces compatibility with the method of MPLS Label Switched Path Operations, Administration, and Maintenance (OAM) identification, particularly in MPLS Transport Profile (MPLS-TP) networks (RFC5921).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

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 March 27, 2016.

Copyright Notice

Copyright (c) 2015 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 ( 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

The Virtual Circuit Connectivity Verification (VCCV) protocol is specified in RFC 5085 [RFC5085]. This document specifies a new VCCV control channel (VCCV CC) type to be used with pseudowires (PW) carried over an MPLS network that do not use the PW Control Word (CW) [RFC4385]. This new VCCV CC type uses the Generic Associated Channel Label (GAL) [RFC5586] to distinguish VCCV packets from packets carrying user data. This new VCCV CC type provides compatibility with the method of MPLS Label Switched Path (LSP) Operations, Administration, and Maintenance (OAM) message identification, as used in MPLS Transport Profile (MPLS-TP) networks [RFC5921].

VCCV currently specifies three CC types. VCCV CC Type 1 uses the PW Control Word (CW) to distinguish VCCV packets from packets carrying user data. VCCV CC Types 2 and 3 require IP encapsulation for OAM packets. This was not an issue when [RFC5085] was designed, but is in conflict with the design goals of MPLS-TP [RFC5921] which does not otherwise require the availability of IP. VCCV CC Type 2 is not applicable to Multi-Segment PWs (MS-PWs) [RFC6073]. A MS-PW operating without the CW therefore has to use VCCV CC Type 3 which identifies VCCV packets on the basis of Time to Live (TTL) expiry. Whilst less of an issue with a single segment PW (SS-PW), on an MS-PW this requires accurately setting the TTL for expiry at the egress Terminating Provider Edge (T-PE) [RFC6073]. In the event of an error in the setting of the PW Label Stack Entry (LSE) TTL, VCCV packets will not be received by the Terminating Provider Edge (T-PE) and may leak into the attachment circuit [RFC6073]. The new VCCV CC type defined in this specification addresses these problems for PWs that do not use the CW.

Note that mandating PWs use the PW CW is not a viable way to address this issue. This is because:

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].

3. Type 4 MPLS VCCV Control Channel Type

When the PW CW is not used, the Type 4 MPLS VCCV Control Channel (CC) type defined in this section MAY be used. This is referred to as VCCV CC Type 4 throughout the rest of this of this document. VCCV CC Type 4 uses the encapsulation shown in Figure 1 in which the presence of a GAL at the end of the MPLS label stack indicates that the packet carries a VCCV message.

 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    |        Channel Type           |
|                                                               |
~                        VCCV Message Body                      ~
|                                                               |

Figure 1

The VCCV message body is preceded by a Generic Associated Channel Header as defined in [RFC5586], in which the Channel Type identifies the type and format of the OAM message carried in the VCCV message body.

The GAL LSE MUST contain the GAL reserved label as defined in [RFC5586].

The PW LSE is constructed according to the existing procedures that apply to the type of pseudowire that is in use.

Where the LSP used by the PW is subject to Equal-Cost Multi-path (ECMP) load balancing, a problem arises if any LSR on that LSP treats special purpose labels as ordinary labels in its ECMP selection method. In these circumstances the inclusion of a GAL following the PW LSE can cause the OAM packet to take a different path through the network from the corresponding PW data packets. If the LSP traverses such equipment and this behaviour is not acceptable, then an alternative VCCV type needs to be used. The requirement to not include special-purpose labels in the load-balancing decision is described in "MPLS Forwarding Compliance and Performance Requirements" [RFC7325]. For equipment that conforms to this, the VCCV type 4 traffic will follow the corresponding PW data packets.

4. FAT PWs

[RFC6391] specifies that when the flow-aware transport (FAT) of pseudowires over an MPLS packet switched network has been signalled or configured, the Flow LSE MUST be present. It further specifies that "the flow label MUST NOT be an MPLS reserved label (values in the range 0..15) [RFC3032]", and that "If a flow LSE is present, it MUST be checked to determine whether it carries a reserved label. If it is a reserved label, the packet is processed according to the rules associated with that reserved label; otherwise, the LSE is discarded."

This document specifies that if the flow-aware transport of pseudowires over an MPLS packet switched network has been signalled or configured then the presence of VCCV message is indicated by the use of a GAL in place of the flow LSE.

This is consistent with [RFC6391], and the packet structure is identical to that shown in Figure 1.

Flow LSEs are inserted into a PW label stack in order to enable the distribution of the PW traffic among multiple equal cost MPLS paths. The use of GAL in place of the flow label will cause all OAM packets to take exactly one of these paths, and this path may be different from the paths taken by any of traffic flows. If this is not acceptable, then an alternative VCCV type needs be used.

5. Multi-Segment Pseudowires

When using VCCV CC Type 4 for MS-PWs, a PE transmitting the VCCV packet to a Switching PE (S-PE) MUST set the TTL to the appropriate value to expire at that S-PE. An S-PE that supports this specification MUST inspect PW packets that are received as a result of TTL expiry, and determine whether a GAL follows the PW LSE. If a GAL is present the S-PE then processes the VCCV packet.

An S-PE that does not support this specification would be expected to reject as malformed a VCCV CC Type 4 packet that was received. This is because the S-PE would expect the PW LSE to be bottom of stack (the non FAT case) and for the LSE at bottom of stack not to be a reserved label (both the FAT and the non-FAT cases). An S-PE that did not make this reserved label check would then find that the first nibble following the label stack was 0x1 and not the expected start of an IP packet. It would hence be expected to also reject the packet. This update to the behaviour of S-PEs is therefore backwards compatible.

6. VCCV Capability Advertisement

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 PW CW, then VCCV CC Type 4 MUST NOT be advertised. If the c-bit is not set, indicating that the PW CW is not in use, then equipment supporting this specification MUST advertise VCCV CC Type 4. Advertisement of VCCV CC Types 1 and 4 are therefore mutually exclusive.

A PE supporting VCCV CC Type 4 MAY advertise other VCCV CC types as defined in [RFC5085] .

If the remote PE supports VCCV CC Type 4, and the PW CW is not in use, then for cases where multiple CC Types are advertised, the following precedence rules apply when choosing which CC Type to use:

  1. Type 4: GAL VCCV Control Channel.
  2. Type 2: MPLS Router Alert Label.
  3. Type 3: MPLS PW Label with TTL == 1.

If the remote PE finds that VCCV CC Types 1 and 4 are both advertised, or that c-bit is set and VCCV CC Type 4 is advertised, then it should report the error to the operator through the management interface in use, and send a Label Release Message with a status code "VCCV Type Error".

7. Manageability Considerations

Whilst the introduction of this additional VCCV CC type increases the number of VCCV CC types that the operator needs to manage, it addresses the issues with VCCV CC Types 2 and 3 described in Section 1.

In the event of a misconfiguration of this VCCV CC type, the PW is taken out of service and the operator advised as described in Section 6.

Attention is drawn to the possible absence of fate sharing between PW data packets and VCCV CC Type 4 packets described in Section 3 and Section 4.

8. Security Considerations

This document does not by itself raise any new security considerations beyond those described in [RFC5085] and [RFC6073]. [RFC6073] provides detailed operational procedures which can be used to verify the MS-PW connectivity. In addition, the procedure specified in this document eliminates the possibility of packet leaking that can occur with VCCV Type 3.

9. IANA Considerations

9.1. MPLS VCCV Control Channel (CC) Type 4

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 requested 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: GAL   This Specification

9.2. LDP Status Code

IANA is requested to assign a new Status Code from the Label Distribution Protocol (LDP) Parameters name space:

Status Code Name Space

      Range/Value  E  Description      Reference
      ===========  =  ===============  =========
      0x000000xx   0  VCCV Type Error  This Specification

10. Acknowledgments

The authors wish to thank Alexander (Sasha) Vainshtein for his proposal to make the GAL and Flow labels mutually exclusive. This proposal led to a significant simplification of this design. The authors also thank Sasha, Matthew Bocci, Loa Andersson and Deborah Brungard for their review comments.

11. References

11.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.
[RFC4385] Bryant, S., Swallow, G., Martini, L. and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 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, DOI 10.17487/RFC4447, April 2006.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007.
[RFC5586] Bocci, M., Vigoureux, M. and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M. and M. Aissaoui, "Segmented Pseudowire", RFC 6073, DOI 10.17487/RFC6073, January 2011.
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J. and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, DOI 10.17487/RFC6391, November 2011.

11.2. Informative References

[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L. and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010.
[RFC7325] Villamizar, C., Kompella, K., Amante, S., Malis, A. and C. Pignataro, "MPLS Forwarding Compliance and Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, August 2014.

Authors' Addresses

Thomas D. Nadeau lucidvision EMail:
Luca Martini Cisco Systems EMail:
Stewart Bryant Cisco Systems EMail: