Mandatory Features of Virtual Circuit Connectivity Verification Implementations
draft-delregno-pwe3-vccv-mandatory-features-00

Abstract

RFC 5085 defines several Control Channel (CC) Types for Virtual Circuit Connectivity Verification, none of which are preferred or mandatory. As a result, independent implementations of different subsets of the three options have resulted in interoperability challenges. To enable interoperability between implementations, this document defines a subset of control channels that is considered mandatory for VCCV implementation. This will ensure that VCCV remains the valuable tool it was designed to be in multi-vendor, multi-implementation and multi-carrier networks.

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Status of this Memo

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

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 23, 2010.

Copyright Notice

Copyright (c) 2010 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 BSD License.

Table of Contents

1.  Introduction
2.  Comparison of Alternative Control Channel Types
    2.1.  Control Channel Type 1: Control Word
    2.2.  Control Channel Type 2: MPLS Router Alert Label
    2.3.  Control Channel Type 3: MPLS PW Label with TTL == 1
3.  Mandatory Control Channels
4.  IANA Considerations
5.  Security Considerations
6.  Acknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Author's Address

1.  Introduction

[RFC5085] (Nadeau, T., “Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires,” December 2007.) defines three Control Channel types for MPLS: Type 1, using the Pseudowire Control Word, Type 2, using the Router Alert Label, and Type 3, using TTL Expiration (e.g. MPLS PW Label with TTL == 1). While Type 2 (RA Label) is indicated as being "the preferred mode of VCCV operation when the Control Word is not present," RFC 5085 does not indicate a mandatory Control Channel to ensure interoperable implementations. The closest it comes to mandating a control channel is the requirement to support Type 1 (Control Word) whenever the control word is present. As such, the three options yield seven implementation permutations (assuming you have to support at least one Control Channel type to provide VCCV). Many equipment manufacturers have gravitated to two common implementation camps: 1) Control Word and Router Alert Label support, or 2) TTL Expiration support only.

As a result, service providers are faced with diametrically opposed support for VCCV Control Channel types when deploying mixed vendor networks. As long as operators select vendors from within a camp, VCCV can be used as the valuable fault-detection and diagnostic mechanism it was created to be. However, due to myriad other unrelated requirements associated with large router requirement specifications and related acquisitions, practice has shown it to be impractical to deploy equipment from only one camp or the other. As a result, this mismatch of support between camps often leads to a service provider's inability to use an important operational tool in networks supporting Layer 2 VPN services.

This document discusses the three Control Channel options, presents pros and cons of each approach and concludes with which Control Channel an implementation is required to implement.

2.  Comparison of Alternative Control Channel Types

The following section presents a review of each control channel type and the pros and cons of implementing each.

2.1.  Control Channel Type 1: Control Word

As noted in [RFC5085] (Nadeau, T., “Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires,” December 2007.), an in-band control channel is ideal, since this ensures that the connectivity verification messages follow the same path as the PWE3 traffic. VCCV Control Channel Type 1, also known as "PWE3 Control Word with 0001b as first nibble," is the only "in-band" control channel specified. It uses the control word as opposed to using the label to indicate the presence of the Connectivity Verification message (CV). This ensures that the control channel follows the forwarding path of the associated traffic in all cases, including in the case of ECMP hashing.

However, in the RFC, use of the control word is not mandatory on all PWE3 encapsulations. Further, in network deployments to date, use of the control word, where optional, is in fact rare. As such, while the author strongly suggest that all implementations should generically support the use of VCCV Control Channel Type 1, it cannot be mandated.

2.2.  Control Channel Type 2: MPLS Router Alert Label

VCCV Control Channel Type 2 is also referred to as "MPLS Router Alert Label." In this approach, the VCCV control channel is created by using the MPLS router alert label [RFC3032] (Rosen, E., “MPLS Label Stack Encoding,” January 2001.) (e.g. Label Value = 1) immediately above the pseudowire label. As this label is inserted above the pseudowire label and below the PSN tunnel label, intermediate label switch routers do not act on the label. However, at the egress router, when the PSN tunnel label is popped and the next label is examined, the label value of 1 will cause the packet to be delivered to a local software module for further processing (e.g. processing of the VCCV Connectivity Verification (CV) message). Similarly, in the case of penultimate hop-popping, the labeled packet arrives with it's top-most label having a label value = 1, causing it to be delivered to a local software module for further processing.

As the processing behavior associated with Router Alert labels is germane to all MPLS implementations, VCCV Control Channel Type 2 should be supported by all implementations. However, there are issues with using Router Alert labels in operational networks. First, there are known issues related to the use of the Router Alert label and possible security risks associated with DoS attacks. While this is less of a risk in closed networks, this becomes a larger potential issue in inter-provider networks. Second, unlike use of the Control Word, inserting a label between the PSN tunnel label and the pseudowire label has ECMP implications, resulting in the very real possibility of the VCCV Control Channel diverging from the path of the associated traffic. While ECMP issues arise from both non-control-word control channels, given the security risks of using the Router Alert label, the VCCV Control Channel Type 2 cannot be mandatory for VCCV implementations. All implementations SHOULD support VCCV Control Channel Type 2 so that operators who choose to use this approach can do so in mixed-implementation environments.

2.3.  Control Channel Type 3: MPLS PW Label with TTL == 1

VCCV Control Channel Type 3 is also known as "MPLS PW Label with TTL == 1." Unlike VCCV Control Channel Type 2, this approach uses the existing pseudowire label to indicate the need for further processing. Upon receiving the labeled packet, whether accompanied by a PSN tunnel label or alone (in the case of penultimate hop popping), the egress router makes a forwarding decision based on the Label Value, assuming the TTL is greater than or equal to 2. However, as part of this process and prior to forwarding the contents of the labeled packet to the attachment circuit (AC), the TTL is decremented. If the TTL value of the received packet was equal to 1, the TTL is decremented to 0, causing the packet to be sent to the control plane for processing.

Unlike the Router Alert Label (Label Value == 1), there has been no standardization of the pseudowire label TTL to this point. For example, [RFC3985] (Bryant, S., “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.), one of the only PWE3 RFCs to address TTL at all, states that "when a MPLS label is used as a PW Demultiplexer, setting of the TTL value in the PW label is application specific." However, no subsequent RFCs have defined the default value of the TTL field within the PW demultiplexer. With the advent of VCCV, it became clear that a TTL value greater than 1 was needed. Many implementations have settled on a default value of 2 for single-segment pseudowires, as evidenced by subsequent MIB drafts in which the default value of 2 is alluded to, if not explicitly defined. Consequently, implementations vary widely with regard to the default value of the TTL field and the subsequent behavior when the TTL is decremented to 0, if it is decremented at all.

Similar to VCCV CC Type 2, changing the value of the TTL in the existing PW demultiplexer label to something different from the value of the labels accompanying the associated traffic, can result in the VCCV Control Channel messages diverging from the path of the associated traffic when ECMP is employed.

3.  Mandatory Control Channels

Implementations of VCCV, at a minimum, MUST support VCCV Control Channel Type 3: MPLS PW Label with TTL == 1. Implementations of VCCV MUST also set the default TTL value of the PW demultiplexer label to 2 for single-segment pseudowires. Further, implementations of VCCV MUST decrement the TTL of the PW demultiplexer label in the egress PE, and upon reaching a TTL==0, MUST pass the packet to the control plane for further processing of the VCCV message contained therein. This provides a basic level of interoperability across all implementations of VCCV without mandating the use of the control word for all VCCV-enabled pseudowire applications. Further, as VCCV is applied to multi-segment pseudowires, using Control Channel Type 3 enables PW traceroute to be implemented in a manner similar to that of MPLS and IP traceroute, through the incrementing of the TTL value in subsequent probes.

As noted previously, this baseline level of VCCV support does not address the aforementioned ECMP issues. Consequently, implementations of VCCV SHOULD support VCCV Control Channel Type 1 for pseudowire encapsulations for which a control word is not mandatory.

Implementations of VCCV MUST support VCCV Control Channel Type 1: Control Word for all implemented pseudowire encapsulations where use of the Control Word is mandatory. Implementations SHOULD support VCCV Control Channel Type 1 for implemented pseudowire encapsulations where, although optional, use of the control word is elected, on a pseudowire-by-pseudowire basis.

Implementations of VCCV MUST support the appropriate signaling of VCCV Control Channel Type support in the pseudowire setup signaling. In order to avoid interoperability issues, implementations should negotiate VCCV Control Channel Type, in decreasing priority: Type 1 (Control Word), Type 3 (TTL Expiration) and Type 2 (Router Alert), when all, or any permutation of the three CC Types are supported.

4.  IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

5.  Security Considerations

This document describes the VCCV Control Channels which MUST be implemented to ensure interoperability in a mixed-implementation environment. This document does not change the basic functionality associated with VCCV. As a result, no additional security issues are raised by this document over those already identified in [RFC5085] (Nadeau, T., “Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires,” December 2007.).

6.  Acknowledgements

7.  References

7.1. Normative References

7.2. Informative References

Author's Address