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

Versions: 00 01 02                                                      
Network Working Group                                  N. Del Regno, Ed.
Internet-Draft                                                   Verizon
Intended status: BCP                                      V. Manral, Ed.
Expires: April 18, 2011                                  IPInfusion Inc.
                                                                R. Kunze
                                                                 M. Paul
                                                        Deutsche Telekom
                                                               T. Nadeau
                                                                  Huawei
                                                        October 15, 2010


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

Abstract

   Pseudowire Virtual Circuit Connectivity Verification (VCCV) [RFC5085]
   defines several Control Channel (CC) Types for MPLS PW's , 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 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 recommendation and not a requirement
   for implementations which can also 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



Del Regno, et al.        Expires April 18, 2011                 [Page 1]


Internet-Draft       VCCV Mandatory Control Channel         October 2010


   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 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 April 18, 2011.

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, et al.        Expires April 18, 2011                 [Page 2]


Internet-Draft       VCCV Mandatory Control Channel         October 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, et al.        Expires April 18, 2011                 [Page 3]


Internet-Draft       VCCV Mandatory Control Channel         October 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 often 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, et al.        Expires April 18, 2011                 [Page 4]


Internet-Draft       VCCV Mandatory Control Channel         October 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 for all PWE3
   encapsulations.

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
   contain an appropriate TTL value, such that the TTL value does not



Del Regno, et al.        Expires April 18, 2011                 [Page 5]


Internet-Draft       VCCV Mandatory Control Channel         October 2010


   cause the CPU exception in any intermediate device in case of PHP.

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



Del Regno, et al.        Expires April 18, 2011                 [Page 6]


Internet-Draft       VCCV Mandatory Control Channel         October 2010


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



Del Regno, et al.        Expires April 18, 2011                 [Page 7]


Internet-Draft       VCCV Mandatory Control Channel         October 2010


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


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, et al.        Expires April 18, 2011                 [Page 8]


Internet-Draft       VCCV Mandatory Control Channel         October 2010


   Vishwas Manral (editor)
   IPInfusion Inc.
   1188 E. Arques Ave.
   Sunnyvale, CA  94085
   US

   Phone: 408-400-1900
   Fax:
   Email: vishwas@ipinfusion.com
   URI:


   Ruediger Kunze
   Deutsche Telekom


   Phone:
   Fax:
   Email: Ruediger.Kunze@telekom.de
   URI:


   Manuel Paul
   Deutsche Telekom


   Phone:
   Fax:
   Email: Manuel.Paul@telekom.de
   URI:


   Thomas Nadeau
   Huawei


   Phone:
   Fax:
   Email: tnadeau@lucidvision.com
   URI:











Del Regno, et al.        Expires April 18, 2011                 [Page 9]