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

Versions: 00 01

Network Working Group                        Thomas D. Nadeau
Internet Draft                               Monique Morrow
Expires: October 2003                         George Swallow
                                          Cisco Systems, Inc.

                                                April  2003

    Pseudo Wire (PW) Virtual Circuit Connection Verification

Status of this Memo
   This document is an Internet-Draft and is in full
   conformance with all provisions of Section 10 of RFC 2026
   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
   The list of Internet-Draft Shadow Directories can be
   accessed at http://www.ietf.org/shadow.html.

   This document describes the Virtual Circuit Connection
   Verification Protocol (VCCV).  VCCV supports connection
   verification applications for pseudowire VCs regardless of
   the underlying MPLS or IP tunnel technology. A network
   operator may use the VCCV protocol to test the network's
   forwarding plane liveliness.

1. Specification of Requirements                            2
2. Acronyms                                                 2
3. Introduction                                             2
4. Scope                                                    4
5. L2TPv3/IP as PSN                                         4
6. MPLS as PSN                                              4
7. OAM Capability Negotiation                               6
8. Security Considerations                                  7
9. Acknowledgments                                          7
10. References                                              8
11. Authors' Addresses                                      9
12. Intellectual Property Rights Notices                    9
13. Full Copyright Statement                               10

Nadeau et al.              Expires October 2003              [Page 1]

Internet Draft                 PWE3 VCCV                April 1, 2003

1. Specification of Requirements
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   and "OPTIONAL" in this document are to be interpreted
   as described in RFC 2119.

2. Acronyms
   CE      Customer Edge
   CV      Connection Verification
   FEC     Forward Equivalency Class
   PE      Provider Edge
   PSN     Packet Service Network
   TLV     Type Length Value
   VC      Virtual Circuit
   VCCV    Virtual Circuit Connection Verification

3. Introduction
   As network operators deploy pseudowire services, fault
   detection and diagnostic mechanisms particularly for the PSN
   portion of the network are pivotal. Specifically, the ability
   to provide end-to-end fault detection and diagnostics for an
   emulated pseudowire service is critical for the network
   operator. Operators have indicated in [MPLSOAMREQS] that such
   a tool is required for pseudowire deployments. This document
   describes a protocol for PSN-agnostic fault detection and
   diagnostics called virtual circuit connection verification

                 |<------- pseudowire ------>|
                 |    |<-- PSN Tunnel -->|    |
          PW     V    V                  V    V     PW
     End Service +----+                  +----+ End Service
+-----+     |    | PE1|==================| PE2|       |    +-----+
|     |----------|............PW1.............|------------|     |
| CE1 |     |    |    |                  |    |       |    | CE2 |
|     |----------|............PW2.............|------------|     |
+-----+     |    |    |==================|    |       |    +-----+
Customer    |    +----+                  +----+       |    Customer
 Edge 1     |  Provider Edge 1        Provider Edge 2 |     Edge 2
            |<----------- Emulated Service ---------->|
                 |<---------- VCCV ---------->|

            Figure 1: PWE3 VCCV Operation Reference Model

Nadeau et al.              Expires October 2003              [Page 2]

Internet Draft                 PWE3 VCCV                April 1, 2003

Figure 1 depicts the basic functionality of VCCV. The protocol
runs between PEs that attaches the VC under test. The protocol
encapsulates packets using the same encapsulation as is used
for data.

   +-------------+                                +-------------+
   |  Layer2     |                                |  Layer2     |
   |  Emulated   |                                |  Emulated   |
   |  Services   |         Emulated Service       |  Services   |
   |             |<==============================>|             |
   +-------------+       VCCV/pseudowire         +-------------+
   +-------------+                                +-------------+
   |    PSN      |            PSN Tunnel          |    PSN      |
   |   MPLS      |<==============================>|   MPLS      |
   +-------------+                                +-------------+
   |  Physical   |                                |  Physical   |
   +-----+-------+                                +-----+-------+
         |                                              |
         |             ____     ___       ____          |
         |           _/    \___/   \    _/    \__       |
         |          /               \__/         \_     |
         |         /                               \    |
         +========/      MPLS or IP Network         |===+
                  \                                /
                   \   ___      ___     __      _/
                    \_/   \____/   \___/  \____/

      Figure 2: PWE3 Protocol Stack Reference Model
                including VCCV.

   Figure 2 depicts how VCCV is run over the pseudowire to
   verify specific VCs. VCCV messages are encapsulated using the
   PWE3 encapsulation as described below in sections 5 and 6.
   These messages are exchanged only after the desire to exchange
   such traffic has been negotiated between the PEs (see section
   8).  The figure also illustrates how VCCV traffic should be
   routed and handled using the same data plane path as normal
   data traffic until it reaches the PE de-multiplextor point.
   When VCCV messages are intercepted at the de-multiplextor
   point, they are processed specially. Normal data traffic would
   be de-capsulated and forwarded to the emulated service at this
   point.  This provides a true test of the data plane integrity
   of the pseudowire data traffic.

Nadeau et al.              Expires October 2003              [Page 3]

Internet Draft                 PWE3 VCCV                April 1, 2003

4. Scope

   VCCV is intended to provide connectivity verification of a
   psuedowire.  As shown in figure 1, a pseudowire rides over a
   PSN and is used to provide an Emulated Serivce.  Verification
   of the underlying PSN is specific to the PSN technology
   employed, and is therefore beyond the scope of this document.
   In all cases, connection verification of the Emulated Service
   between two CEs should be performed using the CV mechanism(s)
   provided by the emulated services running between the CEs.
   It may be necessary to inject indications of errors discovered
   by VCCV into the attachment circuits that are affected by
   those errors. In these cases an OAM message mapping mechanism
   is required. OAM mapping is beyond the scope of this document;
   it is discussed in [OAMMsgMap].

5. L2TPv3/IP as PSN

   When IP is used as the underlying PSN, T.B.D. is used to
   perform connectivity verification and tracing functions
   between PEs.

6. MPLS as PSN

   In order to apply IP monitoring tools to PWE3 circuits, VCCV
   creates a control channel between PWE3 PEs[].  Packets sent
   across this channel are IP packets, allowing maximum
   Ideally such a control channel would be completely in band.
   When a control word is present on virtual circuit, it is
   possible to indicate the control channel by setting a bit in
   the control header.  This method is described in section 6.1
   and is referred to as inband MPLS VCCV.
   However in order to address the case when the control header
   is not in use as well as to deal with a number of existent
   hardware devices, use of the MPLS Router Alert Label to indicate
   the IP control channel is also proposed.  This is described in
   section 6.2.
   The actual channel type is agreed through signaling as
   described in section 8.

6.1.  Inband MPLS VCCV

   The PWE control word [PWE-ENCAP] is defined as follows:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Nadeau et al.              Expires October 2003              [Page 4]

Internet Draft                 PWE3 VCCV                April 1, 2003

   | Rsvd  | Flags |Res|   Length  |     Sequence Number           |
   We propose that bit 7 of the control word (low order bit in
   the Flagsfield) of each PWE3 header type be allocated for the
   purpose of indicating control channel messages.

6.2.  Router Alert Label Approach

   When the control word is not used, or the receiving hardware
   cannot divert control traffic, an IP control channel can be
   created by including the MPLS router alert label immediately
   above the VC label.  If the control word is in use on this VC
   it is also included in the IP control flow.
   0x1  OAM Flag in PWE header
   0x2  Include the control channel label in stack above VC

7. IP Probe Traffic

   For connectivity verification, both ICMP Ping and LSP-Ping
   packets may be used on the control channel.  The type of
   packets used is agreed in signaling as described in section 8.

7.1.  ICMP Ping

   When ICMP packets are used, the source address should be set
   to the source address of the LDP session and the destination
   address to the destination of the LDP session.  The Identifier
   and Sequence Number fields of the ICMP Echo Request / Echo
   Reply messages are used to track what VCs are being tested.
   These fields are only interpreted by the sending PE.  Specific
   use of these fields is an implementation matter.

7.2.  MPLS Ping Packet

   The LSP Ping header must be used as described [LSP-PING] and
   must also contain the sub-TLV of 8 for PW circuits. This sub-
   TLV must be sent containing the circuit to be verified as the
   "VC ID" field:

    7.2.1 L2 Circuit ID TLV for MPLS LSP Ping
   The value field consists of a remote PE address (the address
   of the targeted LDP session), the source address of the PE
   that originated this request, a VC ID and an encapsulation
   type, as follows.

Nadeau et al.              Expires October 2003              [Page 5]

Internet Draft                 PWE3 VCCV                April 1, 2003

  0                   1                 2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  |                      Remote PE Address                        |
  |                      Source PE Address|
  |PWID Type      |PWID Length  | PWID                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                 +
  |                                                               |
  |                          Parameters                           |
  |                              "                                |
  |                              "                                |

   Two PWID types are defined:

   1. A FEC 128 VCID as defined in [MARTINISIG].
   2. A FEC 129 Attachment Identifier, as defined [L2SIG].
   The PWID length field contains the length of the
   PWID field in bytes. Zero to three bytes of padding will follow
   the PWID field, so that the parameters field starts on a 64-bit

   Parameters are:
   - Interface parameters, as defined in [MARTINISIG].

   ***Note that we propose that this field be removed from the
      LSP Ping draft [LSPPING] and defined here instead.

8. LDP OAM Capability Negotiation

   To permit negotiation of the use and type of OAM for
   Connectivity Verification, a VCCV parameter is defined below.
   When a PE signals a PWE VC and desires OAM, it must indicate
   this during VC establishment.  Specifically for LDP it MUST
   include the VCCV parameter in the VC setup message.
   The requesting PE indicates its desire for the remote PE to
   support OAM capability by including the VCCV parameter with
   appropriate options set to indicate which methods of OAM are
   desired.  The remote PE indicates it will support returning
   the VCCV parameter.  The requesting PE MAY indicate multiple
   IP control channel options.  The remote PE MUST respond with a
   single IP control channel selected. If it does not wish to
   support OAM functions, it MUST zero all bits of the control
   channel type field.  The absence of the VCCV FEC TLV also
   indicates that no OAM functions are supported or desired by
   the requesting PE.  This last method MUST be supported by all

Nadeau et al.              Expires October 2003              [Page 6]

Internet Draft                 PWE3 VCCV                April 1, 2003

   PEs in order to handle backward-compatibility with older PEs.
   The requesting PE MAY indicate multiple IP control channel
   probe packets.  The remote PE MAY respond with any or all of
   IP control channel probe packets selected.

8.1.  Optional VCCV Parameter

   [PWE3CONTROL] defines a VC FEC TLV for LDP.  Parameters can be
   carried within that TLV to signal different capabilities for
   specific PWs. We propose an optional parameter to be used to
   indicate the desire to use a control channel for VCCV as
   follows.  As the overall method of PWE3 signaling is
   downstream, unsolicited, this leaves the decision of the type
   of IP control channel completely to the receiving control
   entity.  OAM capability MUST be signaled BEFORE a PE may send
   OAM messages. If a PE receives OAM messages prior to reception
   of a VCCV parameter, it MUST discard these messages. In this
   case, the LSR SHOULD increment an error counter and optionally
   issues a system and/or SNMP notification to indicate to the
   system administrator that a mis-configuration exists.
   When included, this optional parameter MUST be used to
   validate that the LSRs, and the ingress and egress ports at
   the edges of the circuit, have the necessary capabilities to
   support VCCV.

   The TLV field structure is defined in [PWE3CONTROL] as
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |  Parameter ID |    Length     |    Variable Length Value      |
   |                         Variable Length Value                 |
   |                             "                                 |
   The VCCV parameter ID is defined as follows:
     Parameter ID   Length     Description
       0x06           4           VCCV
   The format of the VCCV parameter TLV is as follows:
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |      0x06     |       0x04    |   CC Type     |   CV Types    |
   The CC type field defines the type of IP control channel.
   The defined values are:
    0x1  OAM Flag set in PWE header
    0x2  MPLS Router Alert Label
   The CV Types field defines the types of IP control packets

Nadeau et al.              Expires October 2003              [Page 7]

Internet Draft                 PWE3 VCCV                April 1, 2003

   that may be sent on the control channel.  The defined values
    0x1  ICMP Ping
    0x2  LSP Ping

9.     Security Considerations

10.   Acknowledgments
   The authors would like to thank Hari Rakotoranto, Michel
   Khouderchah, Bertrand Duvivier, Vanson Lim, Chris Metz, W.
   Mark Townsley, Eric Rosen, Dan Tappan, Rahul Aggarwal, and
   Danny McPherson for their valuable comments and suggestions.

11.   References

[PWREQ]    Xiao, X., McPherson, D., Pate, P., Gill, V.,
           Kompella, K., Nadeau, T., White, C., "Requirements
           for Pseudo Wire Emulation Edge-to-Edge (PWE3)",
           <draft-ietf-pwe3-requirements-02.txt>, November 2001.
[PWE3FW]   Prayson Pate, et al., Internet draft, Framework for
           Pseudo Wire Emulation Edge-to-Edge (PWE3), draft-
           ietf-pwe3-framework-01.txt, work in progress.
[PWEARCH]  Bryant, S., Pate, P., Johnson, T., Kompella, K.,
           Malis, A., McPherson, D., Nadeau, T., So, T., Townsley,
           W., Systems, White., C., Wood, L., Xiao, X., Internet
           draft, Framework for Pseudo Wire Emulation Edge-to-Edge
           (PWE3), draft-ietf-pwe3-framework-01.txt, work in
[L2SIG]    Rosen, E., LDP-based Signaling for L2VPNs,
           Internet Draft <draft-rosen-ppvpn-l2-signaling-02.txt>,
           September 2002.
[LSPPING]  Kompella, K., Pan, P., Sheth, N., Cooper, D.,
           Swallow, G., Wadhwa, S., Bonica, R., " Detecting
           Data Plane Liveliness in MPLS", Internet Draft
           <draft-ietf-mpls-lsp-ping-01.txt>, April 2003.
[MARTINISIG] "Transport of Layer 2 Frames Over MPLS", Martini et.
             al., draft-martini-l2circuit-trans-mpls-10.txt,
             August 2002
[GTTP]     Bonica, R., Kompella, K., Meyer, D., "Generic
           Tunnel Tracing Protocol (GTTP) Specification", Internet
           Draft <draft-bonica-tunproto-01.txt>, April, 2003
[FRF 8.1]  Frame Relay Forum, Frame Relay / ATM PVC Service
           Interworking Implementation Agreement, February 2000
[ITU-T]    "Draft Recommendation Y.17fw" (MPLS Management
           Framework), July 2002.
[ITU-T]    "Frame Relay Bearer Service Interworking," I.555,
           September 2997.

Nadeau et al.              Expires October 2003              [Page 8]

Internet Draft                 PWE3 VCCV                April 1, 2003

[ITU-T],   "Frame Relay Operations Principles and Functions",
           I.620, October, 1996.
[ITU-T]    Q.933, ISDN Digital Subscriber Signalling System
           No. 1 (DSS 1) - Signalling specification for frame
           mode basic call control, November 1995.
 [ICMP]    Postel, J. "Internet Control Message Protocol, "
           RFC 792
[PWEATM]   Martini, L., et al., "Encapsulation Methods for
           Transport of ATM Cells/Frame Over IP and MPLS
           Networks", Internet Draft <draft-ietf-pwe3-atm-
           encap-00.txt>, October 2002
[MPLSOAMREQS] Nadeau, T., et al,"OAM Requirements for MPLS
              Networks, Internet Draft <draft-nadeau-ietf-oam-
              requirements-00.txt>, January 2003.
[OAMMsgMap] Nadeau, T., et al, " Pseudo Wire (PW) OAM Message
            Mapping, Internet Draft < draft-nadeau-pwe3-OAMMap.txt>,
            December, 2002.
[PWE3CONTROL] L.Martini et al., "Transport of Layer 2 Frames
              over MPLS, Internet Draft, <draft-ietf-pwe3-control-
              protocol-01.txt>, May 2003
[PPVPNFW]     Callon, R., Suzuki, M., Gleeson, B., Malis, A.,
              Muthukrishnan, K., Rosen, E., Sargor, C., and J. Yu,
              "A Framework for Provider Provisioned Virtual
              Private Networks", Internet Draft <draft-ietf-
              ppvpn-framework-01.txt>, July 2001.
[SAJASSI]  A.Sajassi et al., "L2VPN Interworking," Internet
           Draft <draft-sajassi-l2vpn-interworking-00.txt>,
           November 2002.
[RFC3031]  Rosen, E., Viswanathan, A., and R. Callon,
           "Multiprotocol Label Switching Architecture", RFC
           3031, January 2001.

12.     Authors' Addresses

  Thomas D. Nadeau
  Cisco Systems, Inc.
  250 Apollo Drive
  Chelmsford, MA 01824
  Email: tnadeau@cisco.com

  George Swallow
  Cisco Systems, Inc.
  250 Apollo Drive
  Chelmsford, MA 01824
  Email: swallow@cisco.com

  Monique Morrow
  Cisco Systems, Inc.

Nadeau et al.              Expires October 2003              [Page 9]

Internet Draft                 PWE3 VCCV                April 1, 2003

  CH-8301 Glattzentrum
  Email: mmorrow@cisco.com

13.   Intellectual Property Rights Notices

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on
   the IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances
   of licenses to be made available, or the result of an attempt made
   to obtain a general license or permission for the use of such
   proprietary rights by implementers or users of this specification
   can be obtained from the IETF Secretariat.
   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF
   Executive Director.

14.   Full Copyright Statement

   Copyright (C) The Internet Society (2001). All Rights
   This document and translations of it may be copied and
   furnished to others, and derivative works that comment on
   or otherwise explain it or assist in its implementation may
   be prepared, copied, published and distributed, in whole or
   in part, without restriction of any kind, provided that the
   above copyright notice and this paragraph are included on
   all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by
   removing the copyright notice or references to the Internet
   Society or other Internet organizations, except as needed
   for the purpose of developing Internet standards in which
   case the procedures for copyrights defined in the Internet
   Standards process must be followed, or as required to
   translate it into languages other than English.
   The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its
   successors or assigns. This document and the information
   contained herein is provided on an "AS IS" basis and THE

Nadeau et al.              Expires October 2003             [Page 10]

Internet Draft                 PWE3 VCCV                April 1, 2003


Nadeau et al.              Expires October 2003             [Page 11]

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