[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Network Working Group                                          T. Nadeau
Internet-Draft                                                    Huawei
Intended status: Informational                                L. Martini
Expires: September 6, 2011                           Cisco Systems, Inc.
                                                           March 5, 2011


              A Unified Control Channel for Pseudowires
                     draft-nadeau-pwe3-vccv-2-00

Abstract

   This document describes a unified mode for Virtual Circuit
   Connectivity Verification (VCCV), which provides a control channel
   that is associated with a pseudowire (PW). VCCV applies to all
   supported access circuit and transport types currently defined for
   PWs, as well as those being transported by The MPLS Transport
   Profile. This new mode is intended to augment those described in
   RFC5085, but this document describes new rules requiring this mode
   to be used as the default/mandatory mode of operation for
   VCCV. The older types will remain optional.


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-
   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 September 6, 2011.




Copyright Notice




Nadeau & Martini              Expires March 2011             [Page 1]


                         VCCV 2                         March 5, 2011



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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.




Table of Contents
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  VCCV Control Channel When The Control Word is Used . . . . . .  6
   3.  VCCV Control Channel When The Control Word is Not Used . . . .  6
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
     4.1.  VCCV Interface Parameters Sub-TLV  . . . . . . . . . . . . 19
       4.1.1.  MPLS VCCV Control Channel (CC) Type 4  . . . . . . . . 19
   5. Security Considerations   . . . . . . . . . . . . . . . . . . . 24
   6. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 25
   7. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     7.1. Normative References  . . . . . . . . . . . . . . . . . . . 26
     7.2. Informative References  . . . . . . . . . . . . . . . . . . 26




1.  Introduction

   There is a need for fault detection and diagnostic mechanisms that



Nadeau & Martini              Expires March 2011             [Page 2]


                         VCCV 2                         March 5, 2011



   can be used for end-to-end fault detection and diagnostics for a
   Pseudowire, as a means of determining the PW's true operational
   state.  Operators have indicated in [RFC4377], [RFC3916].
   that such a tool is required for PW operation and maintenance. To
   this end, the IETF's PWE3 Working Group defined The Virtual
   Circuit Connectivity Verification Protocol (VCCV) in [RFC5085].
   Since then a number of interoperability issues have arisen with the
   protocol as it is defined.

   The variety of VCCV options or "modes" have been created to support
   legacy hardware, the use of the control word in some cases, while in
   others not, among others. The difficulty of operating these different
   combinations of "modes" have been detailed in an implementation
   survey the PWE3 Working Group conducted. Many of the motivations of
   this survey are detailed in [MAN-CW]. This document and the
   implementation survey concluded that operators have had difficulty
   deploying the protocol given the number of combinations and options
   for its use.

   In addition to the implementation issues just described, the ITU-T
   and IETF have set out to enhance MPLS to make it suitable as an
   optical transport protocol. The requirements for this protocol are
   defined as the MPLS Transport Profile (MPLS-TP). The requirements
   for this protocol can be found in [RFC5654]. In order to support
   VCCV when an MPLS-TP PSN is in use, the GAL-ACH had to be created;
   this effectively resulted in another mode of operation.

   This document seeks to simplify the modes of operation of VCCV
   down to a single mode of operation we refer to as type 4 for
   the moment. This mode simply defines two ways to run VCCV:
   1) with a control word or 2) without a control word, but with a
   ACH encapsulation making it easy to handle all of the other
   cases handled by the other modes of VCCV. In either case, it will
   be mandatory to implement and use that mode, thus simplifying
   the implementation and operation of the protocol.

   Figure 1 depicts the architecture of a pseudowire as defined in
   [RFC3985].  It further depicts where the VCCV control channel resides
   within this architecture, which will be discussed in detail shortly.


            |<-------------- Emulated Service ---------------->|
            |          |<---------- VCCV ---------->|          |
            |          |<------- Pseudowire ------->|          |
            |          |                            |          |
            |          |    |<-- PSN Tunnel -->|    |          |
            |          V    V                  V    V          |
            V    AC    +----+                  +----+     AC   V



Nadeau & Martini              Expires March 2011             [Page 3]


                         VCCV 2                         March 5, 2011



      +-----+    |     | PE1|==================| PE2|     |    +-----+
      |     |----------|............PW1.............|----------|     |
      | CE1 |    |     |    |                  |    |     |    | CE2 |
      |     |----------|............PW2.............|----------|     |
      +-----+  ^ |     |    |==================|    |     | ^  +-----+
            ^  |       +----+                  +----+     | |  ^
            |  |   Provider Edge 1         Provider Edge 2  |  |
            |  |                                            |  |
      Customer |                                            | Customer
      Edge 1   |                                            | Edge 2
               |                                            |
               |                                            |
         Native service                               Native service

               Figure 1: PWE3 VCCV Operation Reference Model

   From Figure 1, Customer Edge (CE) routers CE1 and CE2 are attached to
   the emulated service via Attachment Circuits (ACs), and to each of
   the Provider Edge (PE) routers (PE1 and PE2, respectively).  An AC
   can be a Frame Relay Data Link Connection Identifier (DLCI), an ATM
   Virtual Path Identifier / Virtual Channel Identifier (VPI/VCI), an
   Ethernet port, etc.  The PE devices provide pseudowire emulation,
   enabling the CEs to communicate over the PSN.  A pseudowire exists
   between these PEs traversing the provider network.  VCCV provides
   several means of creating a control channel over the PW, between the
   PE routers that attach the PW.

   Figure 2 depicts how the VCCV control channel is associated with the
   pseudowire protocol stack.

       +-------------+                                +-------------+
       |  Layer2     |                                |  Layer2     |
       |  Emulated   |       < Emulated Service >     |  Emulated   |
       |  Services   |                                |  Services   |
       +-------------+                                +-------------+
       |             |            VCCV/PW             |             |
       |Demultiplexer|       < Control Channel >      |Demultiplexer|
       +-------------+                                +-------------+
       |    PSN      |          < PSN Tunnel >        |    PSN      |
       +-------------+                                +-------------+
       |  Physical   |                                |  Physical   |
       +-----+-------+                                +-----+-------+
             |                                              |
             |             ____     ___       ____          |
             |           _/    \___/   \    _/    \__       |
             |          /               \__/         \_     |
             |         /                               \    |
             +--------|     MPLS/MPLS-TP or IP Network  |---+



Nadeau & Martini              Expires March 2011             [Page 4]


                         VCCV 2                         March 5, 2011



                       \                               /
                        \   ___      ___     __      _/
                         \_/   \____/   \___/  \____/

     Figure 2: PWE3 Protocol Stack Reference Model including the VCCV
                              Control Channel

   VCCV messages are encapsulated using the PWE3 encapsulation as
   described in Sections 2 and 3, so that they are handled and processed
   in the same manner (or in some cases, a similar manner) as the PW
   PDUs for which they provide a control channel.  These VCCV messages
   are exchanged only after the capability (expressed as two VCCV type
   spaces, namely the VCCV Control Channel and Connectivity Verification
   Types) and desire to exchange such traffic has been advertised
   between the PEs (see Sections 5.3 and 6.3), and VCCV types chosen.



1.2.  Acronyms

   AC      Attachment Circuit [RFC3985].

   AVP     Attribute Value Pair [RFC3931].

   CC      Control Channel (used as CC Type).

   CE      Customer Edge.

   CV      Connectivity Verification (used as CV Type).

   CW      Control Word [RFC3985].

   L2SS    L2-Specific Sublayer [RFC3931].

   LCCE    L2TP Control Connection Endpoint [RFC3931].

   OAM     Operation and Maintenance.

   PE      Provider Edge.

   PSN     Packet Switched Network [RFC3985].

   PW      Pseudowire [RFC3985].

   PW-ACH  PW Associated Channel Header [RFC4385].

   VCCV    Virtual Circuit Connectivity Verification [RFC5085].




Nadeau & Martini              Expires March 2011             [Page 5]


                         VCCV 2                         March 5, 2011



2. VCCV Control Channel When The Control Word is Used

   When the PWE3 Control Word is used to encapsulate pseudowire traffic,
the rules described for encapsulating VCCV CC Type 1 as specified in
section 5.1.1 of [RFC5085] MUST be used.  The capability advertisement
MUST be set to indicate this capability. All other capabilities SHOULD
NOT be set indicating a preference to use this and only this type.

3. VCCV Control Channel When The Control Word is Not Used

   When the PWE3 Control Word is not used, as is the case with
many encapsulations as well as with MPLS-TP, a new CC Type 4 is
defined and MUST be used. The capability advertisement MUST be set to
indicate this capability. All other capabilities SHOULD NOT be set
indicating a preference to use this and only this type.
Packets using this control channel MUST be encapsulated using
a new ACH subtype.


4.  IANA Considerations

4.1.  VCCV Interface Parameters Sub-TLV

   The VCCV Interface Parameters Sub-TLV codepoint is defined in
   [RFC4446].  IANA has created and will maintain registries for the CC
   Types and CV Types (bitmasks in the VCCV Parameter ID).  The CC Type
   and CV Type new registries (see Sections 8.1.1 and 8.1.2,
   respectively) have been created in the Pseudo Wires Name Spaces,
   reachable from [IANA.pwe3-parameters].  The allocations must be done
   using the "IETF Consensus" policy defined in [RFC2434].

4.1.1.  MPLS VCCV Control Channel (CC) Type 4

   IANA is requested to augment the registry of "MPLS VCCV Control
   Channel Types" with the new type defined below. As defined in
   RFC5058, this new bitfield is to be assigned by IANA using
   the "IETF Consensus" policy defined in [RFC2434].  A VCCV
   Control Channel Type description and a reference to an RFC approved
   by the IESG are required for any assignment from this registry.

      MPLS Control Channel (CC) Types:

      Bit (Value)    Description
      ============   ==========================================
      Bit 3 (0x08) - Type 4


   The most significant (high order) bit is labeled Bit 7, and the least



Nadeau & Martini              Expires March 2011             [Page 6]


                         VCCV 2                         March 5, 2011



   significant (low order) bit is labeled Bit 0, see parenthetical
   "Value".

5.  Security Considerations

   This document does not by itself raise any particular security
   considerations that differ from those described in RFC5085.


6.  Acknowledgements

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3931]  Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
              Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.

   [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, February 2006.

   [RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
              Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

   [RFC5085]   Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
               Connectivity Verification (VCCV): A Control Channel for
               Pseudowires", RFC 5085, December 2007.

   [RFC5654]  Niven-Jenkins, B., Brungard, D., and M. Betts,
              "Requirements of an MPLS Transport Profile", RFC 5654,
              September 2009

12.2.  Informative References

   [IANA.l2tp-parameters]
              Internet Assigned Numbers Authority, "Layer Two Tunneling
              Protocol "L2TP"", April 2007,
              <http://www.iana.org/assignments/l2tp-parameters>.

   [IANA.pwe3-parameters]
              Internet Assigned Numbers Authority, "Pseudo Wires Name
              Spaces", June 2007,
              <http://www.iana.org/assignments/pwe3-parameters>.




Nadeau & Martini              Expires March 2011             [Page 7]


                         VCCV 2                         March 5, 2011



   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC3916]  Xiao, X., McPherson, D., and P. Pate, "Requirements for
              Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
              September 2004.

   [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
              Edge (PWE3) Architecture", RFC 3985, March 2005.

   [RFC4377]  Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
              Matsushima, "Operations and Management (OAM) Requirements
              for Multi-Protocol Label Switched (MPLS) Networks",
              RFC 4377, February 2006.

   [MAN-CW]   Del Regno, N., Nadeau, T., Manral, V., Ward, D.,
              "Mandatory Use of Control Word for PWE3 Encapsulations",
              "Work in progress", October 2010.


8.  Authors' Addresses


Authors' Addresses

   Thomas D. Nadeau
   Huawei
   Email: tnadeau@lucidvision.com

   Luca Martini
   Cisco Systems, Inc.
   Email: lmartini@cisco.com


















Nadeau & Martini              Expires March 2011             [Page 8]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/