Network Working Group N. Del Regno, Ed.
Internet-Draft Verizon
Intended status: Informational March 22, 2010
Expires: September 23, 2010
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 [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.
Del Regno Expires September 23, 2010 [Page 1]
Internet-Draft VCCV Mandatory Control Channel March 2010
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.
Del Regno Expires September 23, 2010 [Page 2]
Internet-Draft VCCV Mandatory Control Channel March 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Comparison of Alternative Control Channel Types . . . . . . . . 3
2.1. Control Channel Type 1: Control Word . . . . . . . . . . . 3
2.2. Control Channel Type 2: MPLS Router Alert Label . . . . . 4
2.3. Control Channel Type 3: MPLS PW Label with TTL == 1 . . . 4
3. Mandatory Control Channels . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Del Regno Expires September 23, 2010 [Page 3]
Internet-Draft VCCV Mandatory Control Channel March 2010
1. Introduction
[RFC5085] 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], 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
Del Regno Expires September 23, 2010 [Page 4]
Internet-Draft VCCV Mandatory Control Channel March 2010
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] (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
Del Regno Expires September 23, 2010 [Page 5]
Internet-Draft VCCV Mandatory Control Channel March 2010
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], 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
Del Regno Expires September 23, 2010 [Page 6]
Internet-Draft VCCV Mandatory Control Channel March 2010
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].
6. Acknowledgements
7. References
Del Regno Expires September 23, 2010 [Page 7]
Internet-Draft VCCV Mandatory Control Channel March 2010
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[RFC3032] Rosen, E., "MPLS Label Stack Encoding", January 2001.
[RFC3985] Bryant, S., "Pseudo Wire Emulation Edge-to-Edge (PWE3)
Architecture", March 2005.
[RFC5085] Nadeau, T., "Pseudowire Virtual Circuit Connectivity
Verification (VCCV): A Control Channel for Pseudowires",
December 2007.
Author's Address
Nick Del Regno (editor)
Verizon
400 International Pkwy
Richardson, TX 75081
US
Phone: 972-729-3411
Fax:
Email: nick.delregno@verizon.com
URI:
Del Regno Expires September 23, 2010 [Page 8]