[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: February 2006
                                                    R. Aggarwal (Editor)
                                                        Juniper Networks




                                                             August 2005


      Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)


                      draft-ietf-pwe3-vccv-06.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



Nadeau & Raggarwa                                               [Page 1]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


   each PW. A network operator may use the VCCV procedures to test the
   network's forwarding plane liveliness.

















































Nadeau & Raggarwa                                               [Page 2]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


Table of Contents

 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  ...........................................   7
 4.2        Out-of-Band VCCV  ......................................   8
 4.3        TTL Expiry VCCV  .......................................   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          Author Information  ....................................  19
13          Intellectual Property Statement  .......................  20
14          Full Copyright Statement  ..............................  20








Nadeau & Raggarwa                                               [Page 3]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


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

   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.







Nadeau & Raggarwa                                               [Page 4]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


      +-------------+                                +-------------+
      |  Layer2     |                                |  Layer2     |
      |  Emulated   |         Emulated Service       |  Emulated   |
      |  Services   |                                |  Services   |
      +-------------+                                +-------------+
      |             |         VCCV/PW                |             |
      |Demultiplexer|         Control Channel        |Demultiplexer|
      +-------------+                                +-------------+
      |    PSN      |            PSN Tunnel          |    PSN      |
      +-------------+                                +-------------+
      |  Physical   |                                |  Physical   |
      +-----+-------+                                +-----+-------+
            |                                              |
            |             ____     ___       ____          |
            |           _/    ___/       _/    __       |
            |          /               __/         _     |
            |         /                                   |
            ---------|      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 SHOULD be sent over the PW in
   the reverse direction, that makes up the other half of the PW service



Nadeau & Raggarwa                                               [Page 5]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


   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 to determine the fault [LSP-PING].

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


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.










Nadeau & Raggarwa                                               [Page 6]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


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

   The PW set-up protocol [PWSIG] determines whether a PW uses a control
   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| FmtID |   Reserved    |         Channel Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 3: PW Associated Channel Header

   The first nibble is set to 0x0001. The Format ID and the reserved
   fields are set to 0 and the channel type is used as defined in [PW-
   CW, PWE3IANA].

   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                   | Channel Type                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 4: PW Associated Channel Header for VCCV




Nadeau & Raggarwa                                               [Page 7]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


   It should be noted that PWs are not required to carry the control
   word, and that this method can only be used for those PWs that do.


4.2. Out-of-Band VCCV

   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 be created alter-
   natively by including the MPLS router alert label [RFC3032] immedi-
   ately 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 behav-
   ior, and thus the VCCV traffic may take a path which differs from
   that of the data traffic under test.


4.3. TTL Expiry VCCV

   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.


5. VCCV Types

   VCCV can carry several types of protocols that can be used on the
   control channel either at the same time, or serially.  The specific
   type or types of VCCV packets accepted by a router are indicated dur-
   ing signaling as described in section 6.  The various VCCV types sup-
   ported 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.








Nadeau & Raggarwa                                               [Page 8]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


5.1. MPLS LSP Ping Packet

   The LSP Ping header must be used as described [LSP-PING] and must
   also contain the sub-TLV of 8 for the L2 VPN endpoint or 9 for the L2
   circuit ID. 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 light-
   weight means of continuous monitoring 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 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 addi-
   tion 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., con-
   trol detection time expired) and sends a message to PE1 with H (i.e.,
   "I don't hear you"). This causes PE1 to declare the PW in the direc-
   tion from PE1 to PE2 down and it stores as cause: neighbor signaled
   session down.  Depending on the emulated services, PE2 may send a FDI
   indication on its attachment circuits and PE1 may send an RDI indica-
   tion 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
   Note that the value, 0 is used when the PW is up and 2 is not appli-
   cable to asynchronous mode.



Nadeau & Raggarwa                                               [Page 9]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


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
   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. 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 chan-
   nels, and connectivity type or types used over that control channel
   or channels MUST be signaled before the remote PE may send VCCV mes-
   sages, 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 indi-
   cates its configured VCCV capability or capabilities to the remote PE
   by including the VCCV parameter with appropriate options indicating
   which methods of OAM it supports in the interface parameter field of
   the PW ID FEC TLV (FEC 128) or in the interface parameter TLV 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.

   The receiving PE agrees to accept any of the indicated OAM types and
   options by virtue of establishing the PW. If it does not or cannot
   support at least one of the options specified, it MUST not establish
   the PW. If the requesting PE wishes to continue, it may choose dif-
   ferent options and try to signal the PW again.





Nadeau & Raggarwa                                              [Page 10]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


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 a
   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 both)
   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
   it.

       0x01 PWE3 control word with 0x0001 as first nibble
       0x02 MPLS Router Alert Label
       0x04 MPLS PW Demultiplexor Label TL = 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:

       0x01  ICMP Ping
       0x02  LSP Ping
       0x04  BFD




Nadeau & Raggarwa                                              [Page 11]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


   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. It should
   be noted that L2TPv3 has a built-in "Hello" keepalive mechanism for
   its control plane that operates "in-band" over IP with respect to the
   IP protocol number, port (when UDP is used), source and destination
   IP addresses. This built-in Hello mechanism provides connection sta-
   tus only for the group of sessions associated with the L2TP Control
   Channel. VCCV, however, allows individual L2TP sessions to be tested.
   This provides a more granular mechanism which can be used to trou-
   bleshoot potential problems deeper within the dataplane of L2TP end-
   points themselves, or to provide additional connection status of
   individual pseudo wires.

   In order to carry VCCV messages within an L2TPv3 session data packet,
   this draft relies on the presence of the L2-Specific Sublayer. The
   presence of this field is signaled via the L2-Specific Sublayer AVP
   as defined in [L2TPv3]. The 'V' bit within the Default L2-Specific
   Sublayer is used to identify that a VCCV message 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |V|S|x|x|x|x|x|x|              Sequence Number                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Default L2-Specific Sublayer Format with V bit.


   The 'V' bit indicates that a VCCV session message follows.  If the PW
   has not been signaled to include a L2-specific sublayer format, other
   mechanisms are needed to indicate the VCCV message.  Such mechanisms
   are for further study.











Nadeau & Raggarwa                                              [Page 12]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


7.1. L2TPv3 VCCV Message

   The VCCV message MUST contain a VCCV AVP. It does not contain a mes-
   sage header. This could either be a new VCCV ICMP Ping AVP or VCCV
   BFD AVP. The usage of the L2TPv3 AVP format leaves room for adding
   further AVPs to this message in the future as needed.


7.1.1. L2TPv3 VCCV ICMP Ping AVP

   This AVP encodes the ICMP Ping Echo Packet [ICMP]. This AVP may be
   followed by the L2TPv3 Remote End Identifier AVP to identify the PW
   associated with the session.


7.1.2. L2TPv3 VCCV BFD AVP

   This AVP encodes a BFD packet that is used to verify the session.
   When heart-beat 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 MUST be run in asynchronous mode. BFD control packets [BFD] are
   encapsulated in the AVP. The L2TPv3 session provides the context to
   demultiplex the first BFD control packet.

   The L2TPv3 VCCV BFD AVP may be followed by the L2TPv3 Remote End
   Identifier AVP to identify the PW associated with the session.


7.2. L2TPv3 VCCV Capability Indication

   A LCCE or a LAC should be able to indicate whether the session is
   capable of processing VCCV packets. This is done by including the
   optional VCCV capability AVP in an ICRQ, ICRP, OCRQ or OCRP.


7.2.1. L2TPv3 VCCV Capability AVP

   This AVP specifies the VCCV capability. Its attribute type is TBD.
   The value field has the following format:

          0                   1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | Reserved     | CV Type        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Nadeau & Raggarwa                                              [Page 13]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


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


       0x01  ICMP Ping
       0x02  BFD

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


7.3. L2TPv3 VCCV Operation

   A PE sends VCCV echo requests on a L2TPv3 signaled PW for fault
   detection and diagnostic of the L2TPv3 session. The destination IP
   address in the echo request is set to the remote PE's IP address,
   while the source IP address is set to the local PE's IP address. The
   egress of the L2TPv3 session verifies the signaling and forwarding
   state of the PW, on reception of the VCCV message. Any faults
   detected can be signaled in the VCCV echo response. Its to be noted
   that the VCCV mechanism for L2TPv3 is primarily targeted at verifying
   the PW forwarding and signaling state at the egress PE. It also helps
   when L2TPv3 control and session paths are not identical.

   A PE must send VCCV packets on a L2TPv3 session only if it has sig-
   naled VCCV capability to the remote end and received VCCV capability
   from the remote end. If a PE receives VCCV packets and its not VCCV
   capable or it has not received VCCV capability indication from the
   remote end, it must discard these messages. In addition if a PE
   receives VCCV messages and it has not received VCCV capability from
   the remote end, it should increment an error counter. In this case
   the PE can optionally issue a system and/or SNMP notification.


8. IANA Considerations

8.1. VCCV Parameter ID

   VCCC parameter ID codepoint is defined in [PWE3IANA]. IANA is
   requested to maintain a registry for the CC Types and CV Types, bit-
   masks in the VCCV parameter ID. The allocations must be done using
   the "First Come First Served" policy defined in RFC2434. IANA is
   requested to reserve the following bits in this registry:




Nadeau & Raggarwa                                              [Page 14]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


8.1.1. CC Types

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


8.1.2. CV Types

       0x01  ICMP Ping
       0x02  LSP Ping
       0x04  BFD


8.2. L2TPv3 Assignments

   The 'V' bit within the L2TPv3 Default L2-Specific Sublayer has to
   assigned by IANA. L2TPv3 VCCV ICMP Ping AVP, BFD AVP, VCCV Capability
   AVP must also be assigned by IANA. IANA is requested to maintain a
   registry for the CV Types, bit-mask in the VCCV Capability AVP. The
   allocations must be done using the "First Come First Served" policy
   defined in RFC2434. IANA is requested to reserve the following bits
   in this registry:


8.2.1. CV Types

       0x01  ICMP Ping
       0x02  BFD


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, but
     where the intruder sets the Recovery Time to 0 on
     reconnection.

     An intruder could intercept the traffic between LDP or
     peers and override the setting of the TCP Recovery Time to
     be set to 0.

     An intruder could inject traffic into the TCP connection
     and effectively masquerade as an LDP peer. The same is
     possible for the UDP stream between L2TPv3 peers. In doing



Nadeau & Raggarwa                                              [Page 15]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


     so could falsely indicate VCCV capabilities to a peer.

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

     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.













Nadeau & Raggarwa                                              [Page 16]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


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

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



Nadeau & Raggarwa                                              [Page 17]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


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


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-02.txt, February 2005













Nadeau & Raggarwa                                              [Page 18]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


12. Author Information

   Thomas D. Nadeau
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough, MA 01719
   Email: tnadeau@cisco.com

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

   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




Nadeau & Raggarwa                                              [Page 19]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005


   Vasile Radoaca
   Nortel Networks
   Billerica, MA, 01803
   Email: vasile@nortelnetworks.com



13. 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 assur-
   ances 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.



14. Full Copyright Statement

   Copyright (C) The Internet Society (2005).  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 INFOR-
   MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
   OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.





Nadeau & Raggarwa                                              [Page 20]

Internet Draft         draft-ietf-pwe3-vccv-06.txt           August 2005





















































Nadeau & Raggarwa                                              [Page 21]


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