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

Versions: 00 01 02 03 04 05 06 07 RFC 5885

PWE3                                                      T. Nadeau, Ed.
Internet-Draft                                                        BT
Intended status: Standards Track                       C. Pignataro, Ed.
Expires: May 12, 2008                                Cisco Systems, Inc.
                                                        November 9, 2007


  Bi-directional Forwarding Detection (BFD) for the Pseudowire Virtual
                Circuit Connectivity Verification (VCCV)
                      draft-ietf-pwe3-vccv-bfd-00

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.

   This Internet-Draft will expire on May 12, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes new Connectivity Verification (CV) types for
   using Bi-directional Forwarding Detection (BFD) with Virtual Circuit
   Connectivity Verification (VCCV).  VCCV provides a control channel
   that is associated with a Pseudowire (PW), as well as the
   corresponding operations and management functions such as
   connectivity verification to be used over that control channel.



Nadeau & Pignataro        Expires May 12, 2008                  [Page 1]


Internet-Draft                  BFD VCCV                   November 2007


Table of Contents

   1.  Specification of Requirements  . . . . . . . . . . . . . . . .  3

   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   3.  Bidirectional Forwarding Detection Connectivity
       Verification . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  BFD CV Type Operation  . . . . . . . . . . . . . . . . . .  4
     3.2.  BFD Encapsulation  . . . . . . . . . . . . . . . . . . . .  5
     3.3.  CV Types for BFD . . . . . . . . . . . . . . . . . . . . .  5

   4.  Capability Selection . . . . . . . . . . . . . . . . . . . . .  7

   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  MPLS CV Types for the VCCV Interface Parameters Sub-TLV  .  7
     5.2.  PW Associated Channel Type . . . . . . . . . . . . . . . .  8
     5.3.  L2TPv3 CV Types for the VCCV Capability AVP  . . . . . . .  8

   6.  Congestion Considerations  . . . . . . . . . . . . . . . . . .  9

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9

   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 12




















Nadeau & Pignataro        Expires May 12, 2008                  [Page 2]


Internet-Draft                  BFD VCCV                   November 2007


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

   This document describes new Connectivity Verification (CV) types for
   using Bi-directional Forwarding Detection (BFD) with Virtual Circuit
   Connectivity Verification (VCCV).  VCCV [I-D.ietf-pwe3-vccv] provides
   a control channel that is associated with a Pseudowire (PW), as well
   as the corresponding operations and management functions such as
   connectivity/fault verification to be used over that control channel.

   Some BFD CV Types can additionally carry fault status between the
   endpoints of the Pseudowire.  Furthermore, this information can then
   be translated into the native OAM status codes used by the native
   access technologies, such as ATM, Frame-Relay or Ethernet.  The
   specific details of such status interworking are out of the scope of
   this document, and are only noted here to illustrate the utility of
   BFD over VCCV for such purposes.  Those details can be found in
   [I-D.ietf-pwe3-oam-msg-map].

   The new BFD CV Types are PSN-agnostic, and hence applicable for both
   MPLS and L2TPv3 PSNs.  This document concerns itself with the BFD
   VCCV operation over Single-Segment Pseudowires (SS-PW).


3.  Bidirectional Forwarding Detection Connectivity Verification

   VCCV can support several Connectivity Verification types (CV types)
   or protocols.  This section defines new CV types for use when BFD is
   used as the VCCV payload.  These types apply to both MPLS and L2TPv3
   Pseudowire demultiplexors.

   The CV Type indicator field is defined as a bitmask used to indicate
   the specific CV type or types (i.e., none, one or more) of VCCV
   packets that may be sent on the VCCV control channel.  The values
   shown below augment those already defined in [I-D.ietf-pwe3-vccv].
   They represent the numerical value corresponding to the actual bit
   being set in the CV Type bitfield.

   BFD CV Types:

      The defined values for the different BFD CV Types for MPLS and
      L2TPv3 PWs are:



Nadeau & Pignataro        Expires May 12, 2008                  [Page 3]


Internet-Draft                  BFD VCCV                   November 2007


         Bit (Value)    Description
         ============   ==========================================
         Bit 2 (0x04) - BFD for PW Fault Detection Only.
         Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault
                        Status Signaling.
         Bit 4 (0x10) - BFD for PW Fault Detection Only, carrying BFD
                        payload without IP/UDP headers.
         Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault
                        Status Signaling, carrying BFD payload without
                        IP/UDP headers.

   It should be noted that two pairs of BFD CV Types have been defined,
   see Section 3.3.

3.1.  BFD CV Type Operation

   When heart-beat indication is necessary for one or more PWs, the
   Bidirectional Forwarding Detection (BFD) [I-D.ietf-bfd-base] provides
   a 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
   signaled the existence of a control channel and the ability to run
   BFD on it (see Section 3.3 and Section 4).  Once a node has both
   signaled and received signaling from its peer of these capabilities,
   it begins sending BFD control packets.  The packets are sent on the
   VCCV control channel.  The use of the control channel provides the
   context required to bind and bootstrap the BFD session; the
   Pseudowire demultiplexer field (e.g., MPLS PW Label or L2TPv3 Session
   ID) provides the context to demultiplex the first BFD control packet,
   and thus single-hop BFD initialization procedures are followed (see
   Section 3 of [I-D.ietf-bfd-v4v6-1hop]).  BFD MUST be run in
   asynchronous mode (see [I-D.ietf-bfd-base]).

   When the downstream PE (D-PE) does not receive control messages from
   its upstream peer PE (U-PE) during a certain number of transmission
   intervals (a number provisioned by the operator), D-PE declares that
   the PW in its receive direction is down.  In other words, D-PE enters
   the "forward defect" state for this PW.  D-PE then sends a message to
   U-PE with H=0 (i.e., "I do not hear you") and with Diagnostic code 1.
   In turn, U-PE declares the PW is down in its transmit direction and
   it uses Diagnostic code 3 in its control messages to D-PE.  U-PE
   enters the "reverse defect" state for this PW.  How it further
   processes this error condition, and conveys this status the
   attachment circuits is out of the scope of this specification, and is
   instead defined in [I-D.ietf-pwe3-oam-msg-map].

   The VCCV message comprises a BFD packet [I-D.ietf-bfd-base]



Nadeau & Pignataro        Expires May 12, 2008                  [Page 4]


Internet-Draft                  BFD VCCV                   November 2007


   encapsulated as specified by the CV Type (see Section 3.2).

3.2.  BFD Encapsulation

   This document defines two pairs of BFD CV Types (see Section 3) which
   specify two ways in which a BFD connectivity verification packet may
   be encapsulated over the VCCV control channel.  Table 1 in
   Section 3.3 summarizes the BFD CV Types.

   When the BFD CV Type used is either 0x04 or 0x08, the VCCV
   encapsulation of BFD includes the IP/UDP headers as defined in
   Section 4 of [I-D.ietf-bfd-v4v6-1hop].  The IP Protocol Number and
   UDP Port numbers discriminate among the possible VCCV payloads (i.e.,
   differentiate among ICMP Ping and LSP Ping defined in
   [I-D.ietf-pwe3-vccv] and BFD).

   However, when BFD CV Types of 0x10 or 0x20 are employed, the IP/UDP
   headers are omitted from the BFD encapsulation.  Therefore, these BFD
   CV Types can only be used when the Pseudowire utilizes a Control Word
   (CW) or Layer-2 Specific Sublayer (L2SS) that can take the PW
   Associated Channel Header (PW-ACH) Control Word format.  The PW
   Associated Channel (PW-AC) is defined in Section 5 of [RFC4385], and
   its Channel Type field is used as a payload type identifier to
   discriminate the VCCV payload types.  The usage of the PW-AC for VCCV
   is specified in Sections 5.1.1, 5.1.2 and 5.1.3 of
   [I-D.ietf-pwe3-vccv].  When VCCV carries raw BFD, the Pseudowire CW's
   or L2SS' Channel Type MUST be set to 0x0007 to indicate "BFD Without
   IP/UDP Headers" (see Section 5.2), to allow the identification of the
   encased BFD payload when demultiplexing the control channel.

   In summary, if a PW Associated Channel Header is used, the Channel
   Type can indicate IPv4 (0x0021) or IPv6 (0x0057) for CV Types 0x04
   and 0x08, or BFD without IP/UDP headers (0x0007) for CV Types 0x10
   and 0x20.

3.3.  CV Types for BFD

   Two distinctive pairs of CV Types are defined for BFD.  Table 1
   summarizes the BFD CV Types, grouping them by encapsulation (i.e.,
   with and without IP/UDP headers) and by functionality (i.e., fault
   detection only, or fault detection and status signaling).










Nadeau & Pignataro        Expires May 12, 2008                  [Page 5]


Internet-Draft                  BFD VCCV                   November 2007


   +---------------------+-----------------+---------------------------+
   |                     | Fault Detection |    Fault Detection and    |
   |                     |       Only      |      Status Signaling     |
   +---------------------+-----------------+---------------------------+
   |     BFD with IP/UDP |       0x04      |            0x08           |
   |             Headers |                 |                           |
   |                     |                 |                           |
   |  BFD without IP/UDP |       0x10      |            0x20           |
   |             Headers |                 |                           |
   +---------------------+-----------------+---------------------------+

                 Table 1: Bitmask Values for BFD CV Types

   Given the bidirectional nature of BFD, before selecting a given BFD
   CV Type capability to be used, there MUST be a match in the given CV
   Type capability advertised and received.  That is, only BFD CV Types
   that were both advertised and received are available to be selected.
   Additionally, only one BFD CV Type can be used (selecting a BFD CV
   Type excludes all the remaining BFD CV Types).

   The following list enumerates restrictions and their corollaries on
   the usage of BFD CV Types:

   1.  CV Types 0x08 and 0x20, SHOULD NOT be used when a control
       protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available
       that can signal the AC/PW status to the remote endpoint of the
       PW.

       A.  In the case of CV Type 0x08 or 0x20, the AC and PW status is
           conveyed via BFD status codes as specified in
           [I-D.ietf-pwe3-oam-msg-map].

   2.  Similarly, CV Types 0x04 and 0x10 SHOULD NOT be used when there
       is no control protocol available to signal the AC/PW status.

       A.  In the case of type 0x04 or 0x10, BFD is used exclusively to
           detect faults on the PW and the status of those faults are to
           be conveyed using some means other than BFD, such as using
           LDP status messages when using MPLS as a transport (see
           Section 5.4 of [RFC4447]), or the Circuit Status AVP in an
           L2TPv3 SLI message for L2TPv3 (see Section 5.4.5 of
           [RFC3931]).

   3.  Only a single BFD CV Type can be seleced and used.







Nadeau & Pignataro        Expires May 12, 2008                  [Page 6]


Internet-Draft                  BFD VCCV                   November 2007


4.  Capability Selection

   The precedence rules for selection of various CC and CV types is
   clearly outlined in Section 7 of [I-D.ietf-pwe3-vccv].  This section
   augments these rules when the BFD CV types defined herein are
   supported.  The selection of a specific BFD CV Type to use out of the
   four available CV Types defined is tied to multiple factors, as
   detained in Section 3.3.  Given that BFD is bidirectional in nature,
   only CV Types that are both received and sent in VCCV capability
   signaling advertisement can be selected.

   As already enumerated, when a control protocol that can signal the
   AC/PW status is not available, CV Types CV Types 0x04 and 0x10 (i.e.,
   for Fault Detection only) SHOULD NOT be used.  When a control
   protocol that can signal the AC/PW status (such as LDP [RFC4447] or
   L2TPv3 [RFC3931]) is available, CV Types 0x08 and 0x20 (i.e., for
   Fault Detection and Status Signaling) SHOULD NOT be used.  All BFD CV
   Types are mutually exclusive with the rest, selecting a BFD CV Type
   prevents the use of any of the other three BFD CV Types.

   Finally, only Pseudowires that use a CW or L2SS using the PW
   Associated Channel Header support the use of BFD CV Types 0x10 or
   0x20 (i.e., encapsulation of BFD without IP/UDP headers), and
   consequently the their concurrent use along with another CV Type that
   uses an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping).
   PWs that use a PW-ACH include CC Type 1 (for both MPLS and L2TPv3 as
   defined in Sections 5.1.1 and 6.1 of [I-D.ietf-pwe3-vccv]), and MPLS
   CC Types 2 and 3 when using a Control Word (as specified in Sections
   5.1.2 and 5.1.3 of [I-D.ietf-pwe3-vccv]).  This restriction stems
   from the fact that the PW-ACH contains a Protocol Identification
   (PID) field, the Channel Type.


5.  IANA Considerations

5.1.  MPLS CV Types for the VCCV Interface Parameters Sub-TLV

   The VCCV Interface Parameters Sub-TLV codepoint is defined in
   [RFC4446], and the VCCV CV Types registry is defined in
   [I-D.ietf-pwe3-vccv].  This section lists the new BFD CV Types.

   IANA is requested to augment the "VCCV Connectivity Verification
   Types" registry in the Pseudo Wires Name Spaces, reachable from
   [IANA.pwe3-parameters].  These are bitfield values.  CV Type values
   0x04 0x08, 0x10 and 0x20 are specified in Section 3.






Nadeau & Pignataro        Expires May 12, 2008                  [Page 7]


Internet-Draft                  BFD VCCV                   November 2007


      MPLS Connectivity Verification (CV) Types:

      Bit (Value)    Description
      ============   ==========================================
      Bit 2 (0x04) - BFD for PW Fault Detection Only.
      Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault Status
                     Signaling.
      Bit 4 (0x10) - BFD for PW Fault Detection Only, carrying BFD
                     payload without IP/UDP headers.
      Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault Status
                     Signaling, carrying BFD payload without IP/UDP
                     headers.

5.2.  PW Associated Channel Type

   The PW Associated Channel Types used by VCCV rely on previously
   allocated numbers from the Pseudowire Associated Channel Types
   Registry [RFC4385] in the Pseudo Wires Name Spaces reachable from
   [IANA.pwe3-parameters].  In particular, 0x21 (Internet Protocol
   version 4) is used whenever an IPv4 payload follows the Pseudowire
   Associated Channel Header, or 0x57 is used when an IPv6 payload
   follows the Pseudowire Associated Channel Header.

   In cases where raw BFD follows the Pseudowire Associated Channel as
   specified in Section 3.2 (i.e., when the IP/UDP encapsulation as
   specified in [I-D.ietf-bfd-v4v6-1hop] is be present), a new
   Pseudowire Associated Channel Types Registry [RFC4385] entry of 0x07
   is used.  IANA is requested to reserve a new Pseudowire Associated
   Channel Type value as follows:


     Value (in hex)  Protocol Name                    Reference
     --------------  -------------------------------  ---------

     0x0007          BFD Without IP/UDP Headers       [This document]

5.3.  L2TPv3 CV Types for the VCCV Capability AVP

   This section lists the new BFD CV Types to be added to the existing
   "VCCV Capability AVP" registry in the L2TP name spaces.  The Layer
   Two Tunneling Protocol "L2TP" Name Spaces are reachable from
   [IANA.l2tp-parameters].

   IANA is requested to reserve the following L2TPv3 Connectivity
   Verification (CV) Types in the VCCV Capability AVP Values registry.






Nadeau & Pignataro        Expires May 12, 2008                  [Page 8]


Internet-Draft                  BFD VCCV                   November 2007


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

      L2TPv3 Connectivity Verification (CV) Types:

         Bit (Value)    Description
         ============   ==========================================
         Bit 2 (0x04) - BFD for PW Fault Detection Only.
         Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault
                        Status Signaling.
         Bit 4 (0x10) - BFD for PW Fault Detection Only, carrying BFD
                        payload without IP/UDP headers.
         Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault
                        Status Signaling, carrying BFD payload without
                        IP/UDP headers.


6.  Congestion Considerations

   The congestion considerations that apply to [I-D.ietf-pwe3-vccv]
   apply to this mode of operation as well.


7.  Security Considerations

   Routers that implement the additional CV Types defined herein are
   subject to the same security considerations as defined in
   [I-D.ietf-pwe3-vccv], [I-D.ietf-bfd-base], and
   [I-D.ietf-bfd-v4v6-1hop].


8.  Acknowledgements

   This work forks from a previous revision of the PWE3 WG document
   [I-D.ietf-pwe3-vccv], to which a number of people contributed,
   including Rahul Aggarwal, Peter B. Busschbach, Yuichi Ikejiri, Kenji
   Kumaki, Luca Martini, Monique Morrow, George Swallow, and others.


9.  References

9.1.  Normative References

   [I-D.ietf-bfd-base]
              Katz, D. and D. Ward, "Bidirectional Forwarding
              Detection", draft-ietf-bfd-base-06 (work in progress),
              March 2007.




Nadeau & Pignataro        Expires May 12, 2008                  [Page 9]


Internet-Draft                  BFD VCCV                   November 2007


   [I-D.ietf-bfd-v4v6-1hop]
              Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single
              Hop)", draft-ietf-bfd-v4v6-1hop-06 (work in progress),
              March 2007.

   [I-D.ietf-pwe3-vccv]
              Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
              Connectivity Verification (VCCV) A Control  Channel for
              Pseudowires", draft-ietf-pwe3-vccv-15 (work in progress),
              September 2007.

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

   [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
              Use over an MPLS PSN", RFC 4385, February 2006.

9.2.  Informative References

   [I-D.ietf-pwe3-oam-msg-map]
              Nadeau, T., "Pseudo Wire (PW) OAM Message Mapping",
              draft-ietf-pwe3-oam-msg-map-05 (work in progress),
              March 2007.

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

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

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

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

   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", RFC 4447, April 2006.







Nadeau & Pignataro        Expires May 12, 2008                 [Page 10]


Internet-Draft                  BFD VCCV                   November 2007


Authors' Addresses

   Thomas D. Nadeau (editor)
   BT
   BT Centre
   81 Newgate Street
   London,   EC1A 7AJ
   United Kingdom

   Email: thomas.nadeau@bt.com


   Carlos Pignataro (editor)
   Cisco Systems, Inc.
   7200 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC  27709
   USA

   Email: cpignata@cisco.com































Nadeau & Pignataro        Expires May 12, 2008                 [Page 11]


Internet-Draft                  BFD VCCV                   November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Nadeau & Pignataro        Expires May 12, 2008                 [Page 12]


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