[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-nadeau-pwe3-vccv) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 RFC 5085

Network Working Group                              T. D. Nadeau (Editor)
Internet Draft                                       Cisco Systems, Inc.
Expiration Date: April 2006
                                                    R. Aggarwal (Editor)
                                                        Juniper Networks




                                                            March 2006


      Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)


                      draft-ietf-pwe3-vccv-08.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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.

Abstract

   This document describes Virtual Circuit Connection Verification
   (VCCV) procedures for use with pseudo wire (PW) connections. VCCV
   supports connection verification applications for PWs regardless of
   the underlying public service network technology. VCCV makes use of
   IP-based protocols to perform operations and maintenance functions.
   This is accomplished by providing a control channel associated with
   each PW. A network operator may use the VCCV procedures to test the
   network's forwarding plane liveliness.

Table of Contents



PWE3 Working Group           Expires November 2006           [Page 1]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006




 1     Specification of requirements  ..........................   4
 2     Introduction  ...........................................   4
 3     Overview of VCCV  .......................................   5
 3.1   LSP Ping  ...............................................   6
 3.2   L2TPV3  .................................................   6
 3.3   Bidirectional Forwarding Detection  .....................   6
 4     VCCV Control Channels for PWs Demultiplexed using MPLS ..   7
 4.1   Inband VCCV (Type 1) ....................................   7
 4.2   Out-of-Band VCCV (Type 2) ...............................   8
 4.3   TTL Expiry VCCV (Type 3) ................................   8
 5     VCCV Types  .............................................   8
 5.1   MPLS LSP Ping Packet  ...................................   9
 5.2   Bidirectional Forwarding Detection  .....................   9
 6     OAM Capability Indication for PWs Demultiplexed using MPLS 10
 6.1   Optional VCCV Parameter  ................................  11
 7     VCCV Control Channel for L2TPv3/IP PSN  .................  12
 7.1   L2TPv3 VCCV Message  ....................................  13
 7.1.1 L2TPv3 VCCV ICMP Ping AVP  ..............................  13
 7.1.2 L2TPv3 VCCV BFD AVP  ....................................  13
 7.2   L2TPv3 VCCV Capability Indication  ......................  13
 7.2.1 L2TPv3 VCCV Capability AVP  .............................  13
 7.3   L2TPv3 VCCV Operation  ..................................  14
 8     IANA Considerations  ....................................  14
 8.1   VCCV Parameter ID  ......................................  14
 8.1.1 CC Types  ...............................................  15
 8.1.2 CV Types  ...............................................  15
 8.2   L2TPv3 Assignments  .....................................  15
 8.2.1 CV Types  ...............................................  15
 9     Security Considerations  ................................  15
10     Acknowledgements  .......................................  17
11     References  .............................................  17
11.1   Normative References  ...................................  17
11.2   Informative References  .................................  18
12     Editor Information ......................................  18
13     Contributor Information  ................................  19
14     Intellectual Property Statement  ........................  20
15     Full Copyright Statement  ...............................  20


1. Specification of requirements

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


2. Introduction



PWE3 Working Group           Expires November 2006           [Page 2]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006




   As network operators deploy pseudo wire (PW) services, fault detec-
   tion 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 PW service is
   critical for the network operator. Operators have indicated in
   [MPLSOAMREQS][PWREQ] that such a tool is required for PW deployments.
   This document describes procedures for PSN-agnostic fault detection
   and diagnostics called Virtual Circuit Connection Verification
   (VCCV).


                            |<----- Pseudo Wire ---->|
                            |                        |
                Attachment  |  |<-- PSN Tunnel -->|  |   Attachment
                 Circuit    V  V                  V  V    Circuit
                    |     +----+                  +----+     |
          +----+    |     | PE1|==================| PE2|     |    +----+
          |    |----------|............PW1.............|----------|    |
          | CE1|    |     |    |                  |    |     |    |CE2 |
          |    |----------|............PW2.............|----------|    |
          +----+    |     |    |==================|    |     |    +----+
               ^          +----+                  +----+     |    ^
               |      Provider Edge 1         Provider Edge 2     |
               |                                                  |
               |<--------------- Emulated Service --------------->|
                            |<---------- VCCV ------>|
          Customer                                             Customer
          Edge 1                                                Edge 2

               Figure 1: PWE3 VCCV Operation Reference Model


   Figure 1 depicts the basic functionality of VCCV. VCCV provides sev-
   eral means of creating a control channel between PEs that attaches
   the PW under test.

      +-------------+                                +-------------+
      |  Layer2     |                                |  Layer2     |
      |  Emulated   |       < Emulated Service >     |  Emulated   |
      |  Services   |                                |  Services   |
      +-------------+                                +-------------+
      |             |            VCCV/PW             |             |
      |Demultiplexer|       < Control Channel >      |Demultiplexer|
      +-------------+                                +-------------+
      |    PSN      |          < PSN Tunnel >        |    PSN      |
      +-------------+                                +-------------+
      |  Physical   |                                |  Physical   |



PWE3 Working Group           Expires November 2006           [Page 3]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



      +-----+-------+                                +-----+-------+
            |                                              |
            |             ____     ___        ____         |
            |           _/    ___/    \    _/     __       |
            |          /               \__/        _       |
            |         /                              \     |
            ---------|      MPLS or IP Network        |-----
                     |                               /
                     |    ___      ___     __   ___/
                      \_/   ____/   ___/  ____/

         Figure 2: PWE3 Protocol Stack Reference Model
                   including the VCCV control channel.

   Figure 2 depicts how the VCCV control channel is associated with the
   pseudo wire. Ping and other IP messages are encapsulated using the
   PWE3 encapsulation as described below in sections 5 and 6. These mes-
   sages, referred to as VCCV messages, are exchanged only after the
   desire to exchange such traffic has been negotiated between the PEs
   (see section 8).


3. Overview of VCCV

   VCCV defines a set of messages that are exchanged between PEs to ver-
   ify connectivity of the pseudo wire. To make sure that VCCV packets
   follow the same path as the PW data flow, they are encapsulated in
   the PW demultiplexer and trasported over the PSN tunnel.  VCCV can
   operate in two modes:

    1) as a diagnostic tool
    2) as a fault detection tool

   In the diagnostic mode, the operator triggers LSP-Ping, L2TPV3, or
   ICMP Ping [ICMP] modes depending on the underlying PSN. Since a PW
   service is bi-directional, the reply MAY be sent over the PW in
   the reverse direction, that makes up the other half of the PW service
   under test. For example, if the PSN is MPLS, the reply should be sent
   over the reverse PW, which is transported over the PSN LSP in the
   reverse direction. If this fails, the operator MAY use other reply
   modes such as Reply Mode 4 from [LSP-PING] (Reply via application
   level control channel) to determine the fault.

   The fault detection mode provides a way to emulate fault detection
   mechanisms in other technologies, such as ATM for example. For exam-
   ple, in the fault detection mode, the BFD Bidirectional Forwarding
   Detection (BFD) mechanism can be used as following: the upstream PE
   sends BFD control messages periodically. When the downstream PE



PWE3 Working Group           Expires November 2006           [Page 4]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



   doesn't receive these message for a defined period of time, it
   declares that direction of the PW down and it notifies the upstream
   PE. Based on the emulated service, the PEs may send native indica-
   tions over the related attachment circuits to notify the end points
   of the fault condition. The specific details of the handling of
   these conditions is out of the scope of this document, and are
   only noted here to illustrate the utility of VCCV for these
   purposes. More complete details can be found in [OAM-MAP].

3.1. LSP Ping

   When PWs are demultiplexed using MPLS, LSP Ping is used as described
   in [LSP-PING] as a connectivity verification and diagnostic tool for
   PWs. The PSN may be MPLS or IP.


3.2. L2TPV3

   When IP is used as the PSN, various protocols can be deployed for PW
   Demultiplexing [PWEARCH]. If L2TP or UDP is used, ICMP ECHO packets
   [ICMP] can be used as the means by which connectivity verification is
   achieved.


3.3. Bidirectional Forwarding Detection

   When fault detection indication is necessary for one or more PWs, the
   Bidirectional Forwarding Detection (BFD) [BFD] provides a light-
   weight means of continuous monitoring and propagation of forward and
   reverse defect indications.  BFD can be used regardless of the under-
   lying PSN technology.

4. VCCV Control Channels for PWs Demultiplexed using MPLS

   In order to apply IP monitoring tools to PWE3 circuits, VCCV creates
   a control channel between PWE3 PEs [PWEARCH].  Packets sent across
   this channel are IP packets, allowing maximum flexibility.

   Ideally such a control channel would be completely in band.  When a
   control word is present on virtual circuit, it is possible to indi-
   cate the control channel by setting a bit in the control header.
   This method is described in section 4.1 and is referred to as PWE3
   inband VCCV.


4.1. Inband VCCV (Type 1)

   The PW set-up protocol [PWSIG] determines whether a PW uses a control



PWE3 Working Group           Expires November 2006           [Page 5]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



   word. When a control word is used, it SHOULD have the following form
   for the purpose of indicating VCCV control channel messages. (Note
   that for data, one uses the control word defined just above the MPLS
   payload [PWEARCH].)

   The PW Associated Channel for VCCV control channel traffic is defined
   as follows in [PW-CW]:

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|Version|   Reserved    |         Channel Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3: PW Associated Channel Header

   The first nibble is set to 0x0001 to indicate a channel associated
   with a pseudowire [PW-CW, PWE3IANA]. The Format ID and the reserved
   fields are set to 0, the Version is 0, and the Channel Type is set
   to 0.

   For example, the following is an example of how the ethernet control
   word would be received [ENETENCAP]:

          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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 1|  0                   |            0                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 4: PW Associated Channel Header for VCCV


   It should be noted that although some PW types are not required
   to carry the control word, this type of VCCV MUST only be used
   for those PW types that do employ the control word.


4.2. Out-of-Band VCCV (Type 2)

   When the control word is not used, or the receiving hardware cannot
   divert control traffic based on information in the control word
   (i.e.: older hardware), a VCCV control channel can alternatively
   be created by including the MPLS router alert label [RFC3032]
   immediately above the PW label. If the control word is in use on
   this PW it is also included in the VCCV control flow. It should be
   noted that this approach MAY alter equal cost multi-path (ECMP)
   hashing behavior, and thus result in the VCCV control channel



PWE3 Working Group           Expires November 2006           [Page 6]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



   traffic taking a path which differs from that of the data
   traffic under test.

4.3. TTL Expiry VCCV (Type 3)

   The TTL of the PW demultiplexor label can be set to 1 to force the
   packet to be processed within the destination router's control plane.
   This is an inband control channel identification mechanism that is an
   alternate to section 4.1.

   When the PSN is MPLS it should be noted that this mode may not work
   in cases where the penultimate hop overwrites the TTL values of
   labels underneath the top-most label. Some older implementations do
   this, and the result would be a false positive. Therefore, we recom-
   mend that operators investigate the TTL handling behavior of the
   routers in their networks to determine if this situation can occur.
   If it is discovered that it can, than this mode should not be used
   for the reasons explained above.

   It should be noted that although some PW types are not required
   to carry the control word, this type of VCCV MUST only be used
   for those PW types that do employ the control word.

5. VCCV Types

   VCCV can support several types of connectivity verification
   protocols within its control channel, but only one MUST be used.
   The specific one chosen is based on the preferred order
   specified below. If another is desired to be used once one has begun
   to be transmitted, the pseudowire MUST be re-signaled.  The specific
   type or types of VCCV packets accepted by a router are indicated
   during capability advertisement as described in section 6.  The
   various VCCV types supported SHOULD be used only when they apply
   to the PW demultiplexor in use. For example, the LSP Ping type
   should only be used when MPLS is utilized as the PW demultiplexor.

5.1. MPLS LSP Ping

   The LSP Ping header must be used as described [LSP-PING] and MUST
   also contain the target FEC Stack in turn containing the
   sub-TLV of 8 for the L2 VPN endpoint or 9 or 10
   for "FEC 128 Pseudowire" or 11 for the FEC 128 Pseudowire".
   The sub-TLV indicates the PW to be verified.

5.2. Bidirectional Forwarding Detection

   When heart-beat indication is necessary for one or more PWs, the
   Bidirectional Forwarding Detection (BFD) [BFD] provides a



PWE3 Working Group           Expires November 2006           [Page 7]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



   means of continuous monitoring of the PW data path and
   propagation of forward and reverse defect indications.

   In order to use BFD, both ends of the PW connection must have sig-
   naled the existence of a control channel and the ability to run BFD.
   Once a node has both signaled and received signaling from its peer of
   these capabilities, it MUST begin sending BFD control packets. The
   packets MUST be sent on the control channel. The use of the control
   channel provides the context required to bind the BFD session to a
   particular PW (FEC). Thus normal single-hop BFD initialization
   procedures are followed. BFD MUST be run in asynchronous mode.
   In addition, it may also be desirable to use LSP-Ping for periodic
   diagnostics, in addition to BFD, for fault detection on the same
   PW. The procedures for this are described in [BFDMPLS].

   When one of the PEs (PE2) doesn't receive control messages from PE1
   during the specified amount of time it declares that the PW in the
   direction from PE2 to PE1 is down.  It stores the cause
   (e.g., Diagnostic code 1 - control detection time expired) and
   sends a message to PE1 containing this diagnostic code.
   This causes PE1 to declare the PW in the direction from PE1 to PE2
   is down and it stores as cause: neighbor signaled session down.
   Depending on the emulated services, PE2 may send a
   forward direction indication (FDI) on its attachment
   circuits and PE1 may send an RDI indication on its attachment
   circuits [OAM-MAP].

   BFD defines the following diagnostics:

       0 - No Diagnostic
       1 - Control Detection Time Expired
       2 - Echo Function Failed
       3 - Neighbor Signaled Session Down
       4 - Forwarding Plane Reset (Local equipment failure)
       5 - Path Down (Alarm Suppression)
       6 - Concatenated Path Down (Propagating access link alarm)
       7 - Administratively Down
       8 - Reverse Concatenated Path Down

   Note that the value, 0 is used when the PW is up and 2 is not appli-
   cable to asynchronous mode.

6. OAM Capability Indication for PWs Demultiplexed using MPLS

   To permit the indication of the type or types of PW control chan-
   nel(s), and connectivity verification mode or modes over a particular
   PW, a VCCV parameter is defined below that is used as part of the PW
   establishment signaling.  When a PE signals a PW and desires PW OAM



PWE3 Working Group           Expires November 2006           [Page 8]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



   for that PW, it MUST indicate this during PW establishment using the
   messages defined below. Specifically, for LDP the PE MUST include the
   VCCV parameter in the PW setup message.

   The decision of the type of VCCV control channel is left completely
   to the receiving control entity, although the set of choices is
   given by the sender in that it indicates the type or types of
   control channels that it can understand.  The receiver SHOULD
   chose a single control channel type from the choices indicated
   based on the order of preference rules specified below in
   the section entitled, "Preferred Capability Order" and it
   MUST continue to use this type for the duration of the life
   of the control channel. Changing control channel types after
   one has been established to be in use could potentially cause
   problems at the receiving end, and could also lead to
   interoperability issues, thus it is strongly discouraged.

   When a PE sends a label for a PW, it uses the VCCV parameter to
   indicate the type of OAM control channels and connectivity
   verification type or types it is willing to receive on that PW.
   The capablity of supporting a control channel or channels,
   and connectivity type or types used over that control channel
   or channels MUST be signaled before the remote PE may send VCCV
   messages, and then only on the control channel or channels, and
   using the connectivity verification type or types indicated.

   If a PE receives VCCV messages prior to advertising capability for
   this message, it MUST discard these messages and not reply to them.
   In this case, the PE SHOULD increment an error counter and optionally
   issue a system and/or SNMP notification to indicate to the system
   administrator that this condition exists.

   When LDP is used as the PW signaling protocol the requesting PE
   indicates its configured VCCV capability or capabilities to the
   remote PE by including the VCCV parameter with appropriate options
   indicating which control channel types it supports in the
   interface parameter field of the PW ID FEC TLV (FEC 128) or in
   the sub-TLV interface parameter of the Genralized PW ID FEC TLV
   (FEC 129). The requesting PE MAY indicate that it supports
   multiple control channel options, and in doing so agrees to support
   any and all indicated types if transmitted to it.

   Local policy may direct the PE to support certain OAM capability and
   to indicate it. The absence of the VCCV parameter indicates that no
   OAM functions are supported by the requesting PE, and thus the
   receiving PE MUST NOT send any VCCV control channel traffic to it.
   The reception of a VCCV parameter with no options set MUST be
   ignored as if one is not transmitted at all.



PWE3 Working Group           Expires November 2006           [Page 9]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006




   The receiving PE similarly indicates its supported control channel
   types in the response.  These may or may not be the same as the
   ones that were sent to it.  The sender should examine the set that
   is returned to understand which control channels it may establish
   with the remote peer. Similarly, it MUST NOT send control channel
   traffic to the remove PE for which the remote PE has not indicated
   it supports.

   The exception to the rules given in the last two paragraphs above
   is when one side of the PW indicates no support for VCCV while the
   other indicates support for at least one control channel type. In
   this case, it is possible for one side of the PW to send VCCV
   messages (either requests or replies to requests).

6.1. Optional VCCV Parameter

   [PWE3CONTROL] defines an Interface Parameter field in the LDP PW ID
   FEC (FEC 128) and an Interface Parameters TLV in the LDP Generalized
   PW ID FEC (FEC 129) 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. This is the VCCV parameter
   field. If FEC 128 is used the VCCV parameter field is carried in the
   Interface Parameters field. If FEC 129 is used it is carried as an
   Interface Parameter sub-TLV in the Interface Parameters TLV.

   The VCCV parameter ID is defined as follows in [PWE3IANA]:

        Parameter ID   Length     Description
          0x0c           4           VCCV

   The format of the VCCV parameter field 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 0
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      0x0c     |       0x04    |   CC Types    |   CV Types    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Control Channel (CC Types) type field defines a bitmask used to
   indicate the type of control channel(s) (i.e.: none, one or more)
   that may be used to receive OAM control channel traffic on. If more
   than one control channel is specified, the router agrees to accept
   control traffic at any time over either control channel. If none of
   the types are supported, a CC Type Indicator of 0x00 SHOULD be trans-
   mitted to indicate this to the peer. However, if no capability is
   signaled, then the peer MUST assume that the peer is incapable of
   receiving VCCV and MUST NOT send any OAM control channel traffic to



PWE3 Working Group           Expires November 2006          [Page 10]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



   it.

       0x00 None.
       0x01 PWE3 control word with 0x0001 as first nibble
       0x02 MPLS Router Alert Label
       0x04 MPLS PW Demultiplexor Label TTL = 1

   The CV Type Indicators field is a bitmask used to indicate the spe-
   cific type or types (i.e.: none, one or more) of control channel
   packets that may be sent on the specified control channel.  The
   defined values are:

       0x00  None.
       0x01  ICMP Ping
       0x02  LSP Ping
       0x04  BFD for PW Fault Detection only
       0x08  BFD for PW Fault Detection and AC/PW Fault
             Status Signaling

   It should be noted that two different CV Types have been defined
   when BFD is used. In the first case, type 0x04 indicates that
   BFD is used exclusively to detect faults on the PW and the
   status of those faults should be conveyed using some means other
   than BFD.  In the case of type 0x08, the AC and PW status SHOULD
   be conveyed via BFD status codes as specified in [OAM-MAP].
   Implementations SHOULD NOT include both type 0x04 and 0x08
   in a capability advertisement due to the complexity of supporting
   both simultaneously to avoid ambiguity and confusion about how
   to process and transmit pseudowire status.

   If none of the types above are supported, a CV Type Indicator of 0x00
   SHOULD be transmitted to indicate this to the peer. However, if no
   capability is signaled, then the peer MUST assume that the peer has
   no VCCV capability.


7. VCCV Control Channel for L2TPv3/IP PSN

   When L2TPv3 is used to setup a PW over an IP PSN, VCCV packets are
   carried over the L2TPv3 session as defined in this section.  L2TPv3
   provides a "Hello" keepalive mechanism for the L2TPv3 control plane
   that operates in-band over IP or UDP (see Section 4.4 of [L2TPv3]).
   This built-in Hello facility provides dead peer and path detection
   only for the group of sessions associated with the L2TP Control
   Connection. VCCV, however, allows individual L2TP sessions to be
   tested. This provides a more granular mechanism which can be used to
   troubleshoot potential problems within the dataplane of L2TP
   endpoints themselves, or to provide additional connection status of



PWE3 Working Group           Expires November 2006          [Page 11]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



   individual Pseudowires.

   In order to carry VCCV messages within an L2TPv3 session data packet,
   the PW MUST be established such that an L2-Specific Sublayer (L2SS)
   that defines the V-bit is present.  This document defines the V-bit
   for the Default L2-Specific Sublayer [L2TPv3] and the ATM-Specific
   Sublayer [L2TPv3-ATM] using the Bit 0 position (see Section 8.2.2 and
   Section 8.2.3).  The L2-Specific Sublayer presence and type (either
   the Default or a PW-Specific L2SS) is signaled via the L2-Specific
   Sublayer AVP, Attribute Type 69, as defined in [L2TPv3].  The V-bit
   within the L2-Specific Sublayer is used to identify that a VCCV
   message follows, and when the V-bit is set the L2SS has the following
   format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0 0 0|Version|   Reserved    |         Channel Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          L2-Specific Sublayer Format when the V-bit (bit 0) is set

   The VCCV messages are distinguished from user data by the V-bit.  The
   V-bit is set to 1, indicating that a VCCV session message follows.
   The next three bits MUST be set to 0 when sending and ignored upon
   receipt. The remaining fields comprising 28 bits (i.e., Version,
   Reserved and Channel Type) follow the same definition, format and
   values from Section 5 of [RFC4385].


7.1. L2TPv3 VCCV Message

   The VCCV message over L2TPv3 directly follows the L2-Specific
   Sublayer with the V-bit set.  It could either contain an ICMP Echo
   packet as described in Section 7.1.1, or a BFD packet as described in
   Section 7.1.2.


7.1.1. L2TPv3 VCCV using ICMP Ping

   When this connectivity verification mode is used, an ICMP Echo packet
   [ICMP] achieves connectivity verification.  The ICMP Ping packet
   directly follows the L2SS with the V-bit set.  In the ICMP Echo
   request, the IP Header fields MUST have the following values: the
   destination IP address is set to the remote LCCE's IP address for the
   tunnel endpoint, the source IP address is set to the local LCCE's IP
   address for the tunnel endpoint, and the TTL is set to 1.




PWE3 Working Group           Expires November 2006          [Page 12]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006




7.1.2. L2TPv3 VCCV using BFD

   When BFD is used as the connectivity verification mode for L2TPv3
   Pseudowires, a BFD packet is used to verify the session.  The BFD
   packet is encapsulated in IP/UDP as specified in [BFDV4V61HOP] and
   directly follows the L2SS with the V-bit set.  When heart-beat
   indication is necessary for one or more PWs, the Bidirectional
   Forwarding Detection (BFD) [BFD] provides a means of continuous
   monitoring of the PW data path and propagation of forward and reverse
   defect indications.

   To use BFD, both ends of the Pseudowire MUST have signaled a VCCV
   control channel capability and the ability to run BFD.  Once an LCCE
   has both signaled and received signaling from its peer of a VCCV
   control channel and BFD connectivity verification capabilities, it
   MUST begin sending BFD control packets.  The packets MUST be sent on
   the VCCV control channel.  The use of the VCCV control channel
   provides the context required to bind the BFD session to a particular
   L2TPv3 session (PW).  Thus normal single-hop BFD initialization
   procedures SHOULD be followed [BFD].  BFD MUST be run in asynchronous
   mode.  The VCCV message comprises a BFD control packet [BFD]
   encapsulated in IP/UDP as specified in Section 4 of [BFDV4V61HOP].
   The L2TPv3 Session ID provides the context to demultiplex the first
   BFD control packet.


7.2. L2TPv3 VCCV Capability Indication

   An new optional AVP is defined in Section 7.2.1 to indicate the the
   VCCV capabilities during session establishment.  An LCCE MUST signal
   its desire to use connectivity verification for a particular L2TPv3
   session and its VCCV capabilities using the VCCV Capability AVP.


7.2.1. L2TPv3 VCCV Capability AVP

   The "VCCV Capability AVP", Attribute type AVP-TBD, specifies the VCCV
   capabilities as a pair of bitflags for the Control Channel (CC) and
   Connectifity Verification (CV) Types.  This AVP is exchanged during
   session establishment (in ICRQ, ICRP, OCRQ or OCRP messages). The
   value field has the following format:

   VCCV Capability AVP (ICRQ, ICRP, OCRQ, OCRP)

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



PWE3 Working Group           Expires November 2006          [Page 13]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



      |   CC Types    |   CV Types    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   CC Types:

      The Control Channel (CC) Types field defines a bitmask used to
      indicate the type of control channel(s) that may be used to
      receive OAM traffic on for the given Session.  The router agrees
      to accept VCCV traffic at any time over any of the signaled VCCV
      control channel types.  Although there is only one value defined
      in this document, the CC Types field is included for forward
      compatibility should further CC Types need to be defined in the
      future.

         0x01  L2-Specific Sublayer with V-bit set.

      A CC Type of 0x01 may only be requested when there is an
      L2-Specific Sublayer that defines the V-bit present. If a CC Type
      of 0x01 is requested without requesting an L2-Specific Sublayer
      AVP with an L2SS type that defines the V-bit, the session MUST be
      disconnected with a CDN message.

      If no CC Type is supported, a CC Type Indicator of 0x00 SHOULD be
      sent.

   CV Types:

      The Connectifity Verification (CV) Types field defines a bitmask
      used to indicate the specific type or types (i.e.: none, one or
      more) of IP control packets that may be sent on the specified VCCV
      control channel. The defined values are:

         0x01  ICMP Ping
         0x02  BFD for PW Fault Detection only
         0x04  BFD for PW Fault Detection and AC/PW Fault Status
               Signaling

      For CV Type of 0x02, BFD is used exclusively to detect faults on
      the Session and the status of those faults should be conveyed
      using some means other than BFD, such as using the Circuit Status
      AVP in an L2TPv3 SLI message.  For CV Type of 0x04, the AC and PW
      status SHOULD be conveyed via BFD status codes.  Implementations
      SHOULD NOT include both CV types of 0x02 and 0x04 simultaneously
      in a capability advertisement due to the complexity of supporting
      both simultaneously to avoid ambiguity and confusion about how to
      process and transmit Pseudowire status.

      If none of the types above are supported, a CV Type Indicator of



PWE3 Working Group           Expires November 2006          [Page 14]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



      0x00 SHOULD be transmitted to indicate this to the peer LCCE.

   If no VCCV Capability AVP is signaled, then the LCCE MUST assume that
   the peer is incapable of receiving VCCV and MUST NOT send any OAM
   control channel traffic to it.

   All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, and
   Vendor ID. The Vendor ID for the VCCV Capability AVP MUST be 0,
   indicating that this is an IETF-defined AVP.  This AVP MAY be hidden
   (the H bit MAY be 0 or 1).  The M bit for this AVP SHOULD be set to
   0.  The Length (before hiding) of this AVP is 8.


7.3. L2TPv3 VCCV Operation

   An LCCE sends VCCV echo requests on an L2TPv3 signaled Pseudowire for
   fault detection and diagnostic of the L2TPv3 session.  The VCCV
   message travels inband with the Session and follows the exact same
   path as the user data for the session, because the IP header and
   L2TPv3 Session header are identical.  The egress LCCE of the L2TPv3
   session intercepts and processes the VCCV message, and verifies the
   signaling and forwarding state of the Pseudowire on reception of the
   VCCV message. Any faults detected can be signaled in the VCCV
   response. It is to be noted that the VCCV mechanism for L2TPv3 is
   primarily targeted at verifying the Pseudowire forwarding and
   signaling state at the egress LCCE. It also helps when L2TPv3 Control
   Connection and Session paths are not identical.

   An LCCE MUST NOT send VCCV packets on a L2TPv3 session unless it has
   received VCCV capability by means of the VCCV Capability AVP from the
   remote end.  If an LCCE receives VCCV packets and its not VCCV
   capable or it has not sent VCCV capability indication to the remote
   end, it MUST discard these messages.  It should also increment an
   error counter. In this case the LCCE MAY optionally issue a system
   and/or SNMP notification.

   Additionally, because BFD is bidirectional in nature, when using BFD
   as the connectivity verification type, an LCCE must send VCCV packets
   on a L2TPv3 session only if it has signaled VCCV capability with BFD
   CV Type to the remote end and received VCCV capability with BFD CV
   Type from the remote end.


8. IANA Considerations

8.1. VCCV Parameter ID

   The VCCC parameter ID codepoint is defined in [PWE3IANA]. IANA



PWE3 Working Group           Expires November 2006          [Page 15]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



   is requested to maintain a registry for the CC Types and CV
   Types, and bitmasks in the VCCV Parameter ID. The allocations
   must be done using the "First Come First Served" policy
   defined in RFC2434. IANA is requested to maintain the
   following registries.

8.1.1. CC Types

   IANA needs to set up a registry of "VCCV Control Channel Types".
   These are 8-bit values. CV Type values 0x01, 0x02, and 0x04
   are specified in this document, PW Type values 0x08, 0x16
   and 0x24 are to be assigned by IANA using the "Expert Review"
   policy defined in [RFC2434]. A VCCV Control Channel Type
   description is required for any assignment from this registry.
   A document reference should also be provided.

       0x00 None
       0x01 PWE3 control word with 0x0001 as first nibble
            as defined in [PW-CW]
       0x02 MPLS Router Alert Label
       0x04 MPLS PW Demultiplexor Label TTL = 1


8.1.2. CV Types

   IANA needs to set up a registry of "VCCV Control Channel Types".
   These are 8-bit values. CV Type values 0x00, 0x01, 0x02, and 0x04
  are specified in this document, CV Type values 0x16
   and 0x24 are to be assigned by IANA using the "Expert Review"
   policy defined in [RFC2434]. A VCCV CV Type description
   is required for any assignment from this registry.
   A document reference should also be provided.

       0x00  None
       0x01  ICMP Ping
       0x02  LSP Ping
       0x04  BFD for PW Fault Detection only
       0x08  BFD for PW Fault Detection and AC/PW Fault
             Status Signaling

8.1.3  Channel Type

   The Channel Type codepoint is defined in [PW-CW]. IANA
   is requested to maintain a registry for the Channel
   Types from that document. The allocations
   must be done using the "First Come First Served" policy
   defined in RFC2434. IANA is requested to maintain the
   following registries.



PWE3 Working Group           Expires November 2006          [Page 16]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006




       0x00  OAM Indication (VCCV)

8.2. L2TPv3 Assignments

   Sections 8.2.1 through 8.2.3 are registrations of new L2TP values for
   name spaces already managed by IANA.  Section 8.2.4 requests a new
   registry to be added to the existing L2TP registry, and be maintained
   by IANA accordingly.

8.2.1. Control Message Attribute Value Pairs (AVPs)

   An additiona AVP Attribute is specified in Section 7.2.1.  It is
   required to be defined by IANA as described in Section 2.2 of
   [RFC3438].

      Attribute
      Type        Description
      ---------   ----------------------------------
      AVP-TBD     VCCV Capability AVP

8.2.2. Default L2-Specific Sublayer bits

   The Default L2-Specific Sublayer contains 8 bits in the low-order
   portion of the header.  This document defines one reserved bits in
   the Default L2-Specific Sublayer in Section 7, which may be assigned
   by IETF Consensus [RFC2434]. It is required to be assigned by IANA.

      Default L2-Specific Sublayer bits - per [L2TPv3]
      ---------------------------------
      Bit 0 - V (VCCV) bit

8.2.3. ATM-Specific Sublayer bits

   The ATM-Specific Sublayer contains 8 bits in the low-order portion of
   the header.  This document defines one reserved bits in the ATM-
   Specific Sublayer in Section 7, which may be assigned by IETF
   Consensus [RFC2434]. It is required to be assigned by IANA.

      ATM-Specific Sublayer bits - per [L2TPv3-ATM]
      --------------------------
      Bit 0 - V (VCCV) bit

8.2.4. VCCV Capability AVP Values

   This is a new registry for IANA to maintain.

   IANA is requested to maintain a registry for the CC Types and CV



PWE3 Working Group           Expires November 2006          [Page 17]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



   Types bitmasks in the VCCV Capability AVP, defined in Section 7.2.1.
   The allocations must be done using the "Expert Review" policy defined
   in [RFC2434].  A VCCV CC or CV Type description is required for any
   assignment from this registry.  A document reference should also be
   provided.

   IANA is requested to reserve the following bits in this registry:

      VCCV Capability AVP (Attribute Type AVP-TBD) Values
      ---------------------------------------------------

      Control Channel (CC) Types

         Bit 0 (0x01) - L2-Specific Sublayer with V-bit set.
         Bit 1 (0x02) - Reserved
         Bit 2 (0x04) - Reserved
         Bit 3 (0x08) - Reserved
         Bit 4 (0x10) - Reserved
         Bit 5 (0x20) - Reserved
         Bit 6 (0x40) - Reserved
         Bit 7 (0x80) - Reserved

      Connectifity Verification (CV) Types

         Bit 0 (0x01) - ICMP Ping
         Bit 1 (0x02) - BFD for PW Fault Detection only
         Bit 2 (0x04) - BFD for PW Fault Detection and AC/PW Fault
                        Status Signaling
         Bit 3 (0x08) - Reserved
         Bit 4 (0x10) - Reserved
         Bit 5 (0x20) - Reserved
         Bit 6 (0x40) - Reserved
         Bit 7 (0x80) - Reserved


9. Security Considerations

   Routers that implement the mechanism described herein are subject to
   to additional denial-of-service attacks as follows:

     An intruder may impersonate an LDP peer in order to
     force a failure and reconnection of the TCP connection.
     Please see the Security Considerations section of
     [RFC3036] details.

     An intruder could intercept or inject VCCV packets effectively
     providing false positives or false negatives.




PWE3 Working Group           Expires November 2006          [Page 18]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



     An intruder could deliberately flood a peer router with VCCV
     messages to either obtain services without authorization or to
     deny services to others.

     A misconfigured or misbehaving device could inadvertantly flood
     a peer router with VCCV messages which could result in a denial
     of services. In particular, if a router is either implicitly or
     explicitly indicated that it cannot support one or all of the
     types of VCCV, but is sent those messages in sufficient quantity,
     could result in a denial of service.

   All of attacks above which concern the L2TPv3 or LDP control planes
   may be countered by use of a control message authentication scheme
   between LDP or L2TPv3 peers, such as the MD5-based scheme outlined in
   [LDP] or [L2TPv3]. Implementation of IP address filters may also aid
   in deterring these types of attacks.

   VCCV message throttling mechanisms should be employed, especially in
   distributed implementations which have a centralized control plane
   processor with various line cards attached by some data path. In
   these architectures VCCV messages may be processed on the central
   processor after being forwarded there by the receiving line card. In
   this case, the path between the line card and the control processor
   may become saturated if appropriate VCCV traffic throttling is not
   employed, which could lead to a denial of service.  Such filtering is
   also useful for preventing the processing of unwanted VCCV messages,
   such as those which are sent on unwanted (and perhaps unadvertised)
   control channel types or VCCV types.

   VCCV spoofing requires MPLS PW label spoofing and spoofing the PSN
   tunnel header. As far as the PW label is concerned the same consider-
   ations as specified in [RFC3031] apply. If the PSN is a MPLS tunnel,
   PSN tunnel label spoofing is also required.

10. Acknowledgements

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


11. References

11.1. Normative References

   [RFC2119] "Key words for use in RFCs to Indicate Requirement
             Levels.", Bradner, March 1997



PWE3 Working Group           Expires November 2006          [Page 19]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006




   [BFD]      Katz, D., Ward, D., Bidirectional Forwarding
              Indication, draft-ietf-bfd-03.txt, July 2005

   [PWE3IANA] Martini, L., Townsley, M., "IANA Allocations for
              pseudo Wire Edge to Edge Emulation (PWE3)",
              draft-ietf-pwe3-iana-allocation-11.txt, June
              2005.

   [IANAPPP]  IANA Point-to-Point Protocol Field Assignments,
              April 12, 2004,
              http://www.iana.org/assignments/ppp-numbers

   [LSPPING]  Kompella, K., G. Swallow, " Detecting MPLS Data Plane
              Failures", Internet Draft draft-ietf-mpls-lsp-ping-09.txt,
              May 2005.

   [PWCTRL]   Martini, L., et. al., "Pseudo Wire Setup and Maintenance
              using LDP", draft-ietf-pwe3-control-protocol-17.txt,
              June 2005

   [ENETENCAP] Martini, L., et. al., "Encapsulation Methods for Trans-
   port
               of Ethernet Frames Over IP/MPLS Networks",
               draft-ietf-pwe3-ethernet-encap-10.txt, June 2005.

   [RFC3032]  Rosen, E., Rehter, Y., Tappan, D., Farinacci, D.,
   Fedorkow,
              G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC
              3032, January 2001.

   [L2TPv3]   J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling
              Protocol version 3", draft-ietf-l2tpext-l2tp-base-12.txt,
              March 2004.

   [ICMP]     Postel, J. "Internet Control Message Protocol,  RFC 792

   [LDP]      Andersson, L., Doolan, P., Feldman, N., Fredette, A.
              and B. Thomas, "Label Distribution Protocol", RFC
              3036, January 2001.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon,
              "Multiprotocol Label Switching Architecture", RFC
              3031, January 2001.

   [PW-CW]    S. Bryant et. al., "PWE3 Control Word for use over an
              MPLS PSN", draft-ietf-pwe3-cw-05.txt, June 2005.




PWE3 Working Group           Expires November 2006          [Page 20]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006




11.2. Informative References

   [MPLSOAMREQS] Nadeau, T., et al,"OAM Requirements for MPLS
                 Networks, Internet Draft
                 draft-ietf-oam-requirements-02.txt, June 2003.

   [PWEARCH]     Bryant, S., Pate, P., "PWE3 Architecture", RFC 3985,
                 March 2005

   [PWREQ]       Xiao, X., McPherson, D., Pate, P., "Requirements for
                 Pseudo Wire Emulation Edge to-Edge (PWE3)",
                 draft-ietf-pwe3-requirements-08.txt, December 2003

   [BFDMPLS]     R. Aggarwal, et al, "BFD for MPLS LSPs", Internet
                 Draft <draft-ietf-bfd-mpls-02.txt>, June 2005.

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

   [OAM-MAP]     T. Nadeau, et. al, "Pseudo Wire (PW) OAM Message Map-
                 ping", draft-ietf-pwe3-oam-msg-map-03.txt,
                 September 2005

   [RFC3036]     Andersson, L, et al., "LDP Specification",
                 RFC3036, January 2001.

   [RFC3438]     Townsley, W., "Layer Two Tunneling Protocol (L2TP)
                 Internet Assigned Numbers Authority (IANA)
                 Considerations Update", BCP 68, RFC 3438,
                 December 2002.

   [L2TPv3-ATM]  Singh, S., "ATM over L2TPv3",
                 draft-ietf-l2tpext-pwe3-atm-04 (work in progress),
                 January 2006.

   [BFDV4V61HOP] Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single
                 Hop)", draft-ietf-bfd-v4v6-1hop-04 (work in progress),
                 October 2005.


12. Editor Information

   Thomas D. Nadeau
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough, MA 01719



PWE3 Working Group           Expires November 2006          [Page 21]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



   Email: tnadeau@cisco.com

   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: rahul@juniper.net


13. Contributor Information

   George Swallow
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough, MA 01719
   Email: swallow@cisco.com

   Monique Morrow
   Cisco Systems, Inc.
   Glatt-com
   CH-8301 Glattzentrum
   Switzerland
   Email: mmorrow@cisco.com

   Yuichi Ikejiri
   NTT Communication Corporation
   1-1-6, Uchisaiwai-cho, Chiyoda-ku
   Tokyo 100-8019
   Shinjuku-ku, JAPAN
   Email: y.ikejiri@ntt.com

   Kenji Kumaki
   KDDI Corporation
   KDDI Bldg. 2-3-2,
   Nishishinjuku,
   Tokyo 163-8003,
   JAPAN
   E-mail: ke-kumaki@kddi.com

   Peter B. Busschbach
   Lucent Technologies
   67 Whippany Road
   Whippany, NJ, 07981
   E-mail: busschbach@lucent.com

   Vasile Radoaca
   Nortel Networks
   Billerica, MA, 01803



PWE3 Working Group           Expires November 2006          [Page 22]

           draft-ietf-pwe3-vccv-08         VCCV          May 30, 2006



   Email: vasile@nortelnetworks.com



14. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

15. Full Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.










PWE3 Working Group           Expires November 2006          [Page 23]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/