Network Working Group N. Del Regno, Ed.
Internet-Draft Verizon
Intended status: Informational V. Manral, Ed.
Expires: October 27, 2010 IPInfusion Inc.
April 25, 2010
Mandatory Features of Virtual Circuit Connectivity Verification
Implementations
draft-delregno-pwe3-vccv-mandatory-features-01
Abstract
Pseudowire Virtual Circuit Connectivity Verification (VCCV) [RFC5085]
defines several Control Channel (CC) Types for MPLS PW's 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. In the RFC5085 the CV type of LSP Ping is made the
default for MPLS PW's and ICMP Ping is made optional. This however,
is a reccomendation and not a requirement for implementations which
can lead to 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. This document also states requirements for
the CV type too.
This draft is specific to MPLS PW's and not L2TPv3 PW. For the
L2TPv3 PW only one CC and CV type are specified and the issues raised
in this draft do not arise.
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 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-
Del Regno & Manral Expires October 27, 2010 [Page 1]
Internet-Draft VCCV Mandatory Control Channel April 2010
Drafts is at http://datatracker.ietf.org/drafts/current/.
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 October 27, 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 Simplified BSD License.
Del Regno & Manral Expires October 27, 2010 [Page 2]
Internet-Draft VCCV Mandatory Control Channel April 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Comparison of Alternative Control Channel Types . . . . . . . . 4
2.1. Control Channel Type 1: Control Word . . . . . . . . . . . 4
2.2. Control Channel Type 2: MPLS Router Alert Label . . . . . 5
2.3. Control Channel Type 3: MPLS PW Label with TTL == 1 . . . 6
3. Mandatory Control Channels . . . . . . . . . . . . . . . . . . 6
4. Mandatory CV Types . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Del Regno & Manral Expires October 27, 2010 [Page 3]
Internet-Draft VCCV Mandatory Control Channel April 2010
1. Introduction
[RFC5085] defines three Control Channel types for MPLS PW's: 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.
This document also puts an explicit reqirement on the CV type to be
supported for MPLS PW.
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
Del Regno & Manral Expires October 27, 2010 [Page 4]
Internet-Draft VCCV Mandatory Control Channel April 2010
"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.
The use of the control word is not mandatory on all PWE3
encapsulations. However based on the current hardware support the
draft strongly suggest that all implementations SHOULD generically
support the use of VCCV Control Channel Type 1.
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 MAY support VCCV Control Channel Type 2 so that
operators who choose to use this approach can do so in mixed-
implementation environments. Further Router Alert Label MUST use a
TTL value, so that the TTL value does not cause the CPU exception in
any intermediate device in case of PHP.
Del Regno & Manral Expires October 27, 2010 [Page 5]
Internet-Draft VCCV Mandatory Control Channel April 2010
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], 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.
Implementations MUST support the use of this option.
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.
Del Regno & Manral Expires October 27, 2010 [Page 6]
Internet-Draft VCCV Mandatory Control Channel April 2010
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 SHOULD 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. Mandatory CV Types
For MPLS PWs, the CV Type of LSP Ping (0x02) MUST be supported, and
the CV Type of ICMP Ping (0x01) MAY be supported.
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. 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
Del Regno & Manral Expires October 27, 2010 [Page 7]
Internet-Draft VCCV Mandatory Control Channel April 2010
associated with VCCV. As a result, no additional security issues are
raised by this document over those already identified in [RFC5085].
7. Acknowledgements
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.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.
Authors' Addresses
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 & Manral Expires October 27, 2010 [Page 8]
Internet-Draft VCCV Mandatory Control Channel April 2010
Vishwas Manral (editor)
IPInfusion Inc.
1188 E. Arques Ave.
Sunnyvale, CA 94085
US
Phone: 408-400-1900
Fax:
Email: vishwas@ipinfusion.com
URI:
Del Regno & Manral Expires October 27, 2010 [Page 9]