[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                                Thomas D. Nadeau
Internet Draft                                       Cisco Systems, Inc.
Expires: February 2006
                                                     Rahul Aggarwal
                                                     Juniper Networks
                                                     Editors

                                                     August 2005




           Pseudo Wire Virtual Circuit Connectivity
                     Verification (VCCV)
                draft-ietf-pwe3-vccv-05.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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Please send comments to the Pseudowire Emulation Edge to
   Edge (PWE3) working group at pwe3@ietf.org.

Abstract

   This document describes Virtual Circuit Connection Verification
   (VCCV) procedures for use with pseudo wire connections. VCCV
   supports connection verification applications for pseudo wire
   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 pseudo wire. A network



IETF PWE3 Working Group         Expires February 2006        [Page 1]

Internet Draft                   VCCV                   July 17, 2005



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

Contents
     Abstract........................................................1
  1. Authors' Addresses..............................................1
  2. Introduction....................................................2
  3. Overview of VCCV Modes of Operation.............................3
  4. VCCV Control Channel Types for MPLS PSN.........................3
  4.1 Inband VCCV ...................................................3
  4.2 Out-of-band VCCV ..............................................4
  4.3 TTL Expiry VCCV ...............................................4
  5. VCCV Types .....................................................5
  5.1.  MPLS LSP Ping Packet ........................................5
  5.2   Bidirectional Forwarding Detection ..........................5
  6. OAM Capability Indication ......................................6
  6.1.  Optional VCCV Parameter .....................................6
  7. VCCV Control Channel for L2TPv3/IP PSN..........................8
  7.1. L2TPv3 VCCV Message..........................................11
  7.2. L2TPv3 VCCV Capability Indication............................11
  7.3. L2TPv3 VCCV Operation........................................11
  8. Acknowledgments................................................11
  9. References.....................................................11
  9.2 Normative References..........................................11
  9.2 Informative References........................................11
  10. Security Considerations.......................................12
  11. Intellectual Property Statement...............................12
  12. Full Copyright Statement......................................13
  13. IANA Considerations...........................................13

1. Authors' Addresses

  Thomas D. Nadeau                   Rahul Aggarwal
  Cisco Systems, Inc.                Juniper Networks
  300 Beaver Brook Road              1194 North Mathilda Ave.
  Boxborough, MA 01719               Sunnyvale, CA 94089
  Email: tnadeau@cisco.com           Email: rahul@juniper.net

  George Swallow                     Monique Morrow
  Cisco Systems, Inc.                Cisco Systems, Inc.
  300 Beaver Brook Road              Glatt-com
  Boxborough, MA 01719               CH-8301 Glattzentrum
  Email: swallow@cisco.com           Switzerland
                                     Email: mmorrow@cisco.com

  Yuichi Ikejiri                     Kenji Kumaki
  NTT Communication Corporation      KDDI Corporation
  1-1-6, Uchisaiwai-cho, Chiyoda-ku  KDDI Bldg. 2-3-2,



IETF PWE3 Working Group         Expires February 2006        [Page 2]

Internet Draft                   VCCV                   July 17, 2005



  Tokyo 100-8019                     Nishishinjuku,
  Shinjuku-ku, JAPAN                 Tokyo 163-8003,
  Email: y.ikejiri@ntt.com           JAPAN
                                     E-mail: ke-kumaki@kddi.com

  Peter B. Busschbach                Vasile Radoaca
  Lucent Technologies                Nortel Networks
  67 Whippany Road                   Billerica, MA, 01803
  Whippany, NJ, 07981                Email: vasile@nortelnetworks.com
  E-mail: busschbach@lucent.com


2. Introduction

   As network operators deploy pseudo wire services, fault
   detection and diagnostic mechanisms particularly for the PSN
   portion of the network are pivotal. Specifically, the ability
   to provide end-to-end fault detection and diagnostics for an
   emulated pseudo wire service is critical for the network
   operator. Operators have indicated in [MPLSOAMREQS][PWREQ] that
   such a tool is required for pseudo wire 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
   several means of creating a control channel between PEs that



IETF PWE3 Working Group         Expires February 2006        [Page 3]

Internet Draft                   VCCV                   July 17, 2005



   attaches the PW under test.


















   +-------------+                                +-------------+
   |  Layer2     |                                |  Layer2     |
   |  Emulated   |         Emulated Service       |  Emulated   |
   |  Services   |                                |  Services   |
   +-------------+                                +-------------+
   |             |         VCCV/pseudo wire        |             |
   |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 messages, referred to as VCCV messages, are exchanged



IETF PWE3 Working Group         Expires February 2006        [Page 4]

Internet Draft                   VCCV                   July 17, 2005



   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
   verify connectivity of the pseudo wire. To make sure that pseudo wire
   packets follow the same path as the data flow, they are encapsulated
   with the same labels. 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
   pseudo wire is bi-directional, it makes sense to require that the
   reply is send over the PSN tunnel that makes up the other half
   of the PW under test. For example, if the PSN is an MPLS LSP,
   the reply should be sent on the LSP representing the reverse
   path. If this fails, the operator can use other reply modes to
   determine what is wrong. The specific type of reply mode is
   indicated during PW circuit set-up (see section 6).

   The fault detection mode provides a way to emulate fault
   detection mechanisms in other technologies, such as ATM for
   example. For example, in the fault detection mode, the BFD
   (Bidirectional Forward mechanism) 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 indications 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 the PSN is MPLS, the LSP Ping header is used as described
   in [LSP-PING] as a connectivity verification and diagnostic
   tool for pseudo wires.

3.2 L2TPV3

   When IP is used as the PSN, various protocols can be deployed for PW
   Demultiplexing (see [PWEARCH]). If L2TP or UDP is used, ICMP ECHO



IETF PWE3 Working Group         Expires February 2006        [Page 5]

Internet Draft                   VCCV                   July 17, 2005



   packets [ICMP] can be used as the means by which connectivity
   verification is achieved. If MPLS is used for PW Demultiplexing, the
   LSP Ping header is used as described in [LSP-PING] for verifying the
   connectivity status of pseudo wires.

3.4 Bidirectional Forwarding Detection

   When fault detection indication is necessary for one or more
   pseudo wires, 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 underlying
   PSN technology.


4. VCCV Control Channel Types for MPLS PSN

   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 indicate 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 PWE3 payload type identifier for VCCV control channel
   traffic is defined as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|          Control Word-specific Information            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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



IETF PWE3 Working Group         Expires February 2006        [Page 6]

Internet Draft                   VCCV                   July 17, 2005




     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| reserved = 0  |  PA=0 |PPP DLL Proto Number=0021/0057 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The first nibble is set to 0x0001, the protocol of the frame is
   indicated by the Protocol Number. IP OAM flows are identified by
   either an IPv4 (0021) or IPv6 (0057) codepoint [IANAPPP].

   It should be noted that pseudo-wires are not required to
   carry the control word, and that this method can only be
   used for those pseudo-wires 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), MPLS is utilized as the PSN,
   a VCCV control channel can be created alternatively by including
   the MPLS router alert label [RFC3032] immediately above the PW label.
   If the control word is in use on this VC 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
   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 inner 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.

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

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.



IETF PWE3 Working Group         Expires February 2006        [Page 7]

Internet Draft                   VCCV                   July 17, 2005



   The specific type or types of VCCV accepted by a router
   are indicated during signaling as described in section 6.
   With the exception of the BFD protocol which applies to
   all PSN types, all other VCCV types supported SHOULD be
   used only when they apply to the PSN in use. For example,
   the LSP Ping type should only be used when MPLS is utilized
   as the PSN.

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 indicate the the
   circuit to be verified.

5.2   Bidirectional Forwarding Detection

   When heart-beat indication is necessary for one or more
   pseudo wires, 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 pseudo wire connection must
   have signaled 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 pseudo wire (FEC).  Thus normal BFD
   initialization procedures are followed.  BFD MUST be run in
   asynchronous mode.

   It may be desirable to use LSP-Ping additionally for periodic
   diagnostics in addition to BFD for fault detection on the same
   PW [BFDMPLS].

   When one of the PEs (PE2) doesn't receive control messages
   from PE1 during the specified amount of time, or if it
   determines that reachability to PE1 is no longer available, it
   declares that the PW in the direction from PE2 to PE1 is down.
   It stores the cause (e.g. control detection time expired) and
   sends a message to PE1 with H (i.e. "I don't hear you"). In
   turn, PE1 declares the PW in the direction from PE1 to PE2
   down and 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
   indication on its attachment circuits.



IETF PWE3 Working Group         Expires February 2006        [Page 8]

Internet Draft                   VCCV                   July 17, 2005




   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

    Of these, 0 is used when the PW is up and 2 is not applicable
    to asynchronous mode.


6. OAM Capability Indication

   To permit the indication of the type or types of pseudo wire control
   channel(s), and connectivity verification mode or modes
   over a particular pseudo wire, a VCCV parameter is defined below
   that is used as part of the pseudo wire establishment signaling.
   When a PE signals a pseudo wire and desires pseudo wire OAM for that
   pseudo wire, 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.

   As the overall method of PWE3 signaling is downstream,
   unsolicited, 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 pseudo wire. 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. Further
   action should be taken to prevent the remote PE from continuing
   to send the unwanted messages.

   The requesting PE indicates its configured VCCV capability or



IETF PWE3 Working Group         Expires February 2006        [Page 9]

Internet Draft                   VCCV                   July 17, 2005



   capabilities to the remote PE by including the VCCV parameter with
   appropriate options indicating which methods of OAM it supports in
   the interface parameter sub-TLV portion of the FEC TLV.
   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 interface parameter sub-TLV in the FEC TLV 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 sub-TLV 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 different options and
   try to signal the PW again.

6.1.  Optional VCCV Parameter

   [PWE3CONTROL] defines a PW FEC Interface TLV Parameters for LDP.
   Parameters can be carried within that TLV to signal different
   capabilities for specific PWs. We propose an optional parameter
   to be used to indicate the desire to use a control channel for
   VCCV as follows.

   The TLV field structure is defined in [PWE3CONTROL].
   The VCCV parameter ID is defined as follows in [PWE3IANA]:

     Parameter ID   Length     Description
       0x0c           4           VCCV


   The format of the VCCV parameter TLV is as follows:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x0c     |       0x04    |   CC Types    |   CV Types    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Control Channel (CC) 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 is specified, the router agrees to accept control
   traffic at any time over either control channel. If none of the



IETF PWE3 Working Group        Expires February 2006        [Page 10]

Internet Draft                   VCCV                   July 17, 2005



   types are supported, a CC 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 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 inner label TTL = 1

   The CV Type Indicators field defines a bitmask used to indicate the
   specific 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

    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 status 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 troubleshoot potential
    problems deeper within the dataplane of L2TP endpoints themselves,
    or to provide additional connection status of individual pseudo
    wires.

    In order to carry VCCV messages within an L2TPv3 session data
    packet, the default L2-Specific Sublayer MUST be present. 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.




IETF PWE3 Working Group        Expires February 2006        [Page 11]

Internet Draft                   VCCV                   July 17, 2005



    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.

7.1. L2TPv3 VCCV Message

   The VCCV message MUST contain a VCCV AVP. It does not contain a
   messageheader. 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
   pseudo wire 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
   pseudo wires, 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 pseudo wire 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.



IETF PWE3 Working Group        Expires February 2006        [Page 12]

Internet Draft                   VCCV                   July 17, 2005




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

   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
   packets 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 pseudo wire 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 pseudo wire, 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 pseudo wire 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
   signaled 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



IETF PWE3 Working Group        Expires February 2006        [Page 13]

Internet Draft                   VCCV                   July 17, 2005



   counter. In this case the PE can optionally issue a system and/or
   SNMP notification.


8.   Acknowledgments

   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.


9.   References

9.1 Normative References

[BFD]      Katz, D., Ward, D., Bidirectional Forwarding
           Indication, draft-katz-ward-bfd-01.txt, August
           2003.

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

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

[LSPPING]  Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow,
           G., Wadhwa, S., Bonica, R., " Detecting MPLS Data Plane
           Failures", Internet Draft draft-ietf-mpls-lsp-ping-05.txt,
           February 2004.

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

[ENETENCAP] Martini, L., et. al., "Encapsulation Methods for Transport
            of Ethernet Frames Over IP/MPLS Networks",
            draft-ietf-pwe3-ethernet-encap-06.txt, April 2004.

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



IETF PWE3 Working Group        Expires February 2006        [Page 14]

Internet Draft                   VCCV                   July 17, 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.


9.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", Internet
              Draft, draft-ietf-pwe3-arch-07.txt, March 2004

[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-raggarwa-mpls-bfd-00.txt>, October 2003.

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

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



IETF PWE3 Working Group        Expires February 2006        [Page 15]

Internet Draft                   VCCV                   July 17, 2005



      possible for the UDP stream between L2TPv3 peers. In doing
      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
   considerations as specified in [RFC3031] apply. If the PSN is a
   MPLS tunnel, PSN tunnel label spoofing is also required.

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



IETF PWE3 Working Group        Expires February 2006        [Page 16]

Internet Draft                   VCCV                   July 17, 2005



   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.


12. 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 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
    ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
    PARTICULAR PURPOSE.


13.  IANA Considerations

   TBD.














IETF PWE3 Working Group        Expires February 2006        [Page 17]


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