doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc5885.txt b/doc/rfc/rfc5885.txt
new file mode 100644
index 0000000..1d4a816
--- /dev/null
+++ b/doc/rfc/rfc5885.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    T. Nadeau, Ed.
+Request for Comments: 5885                                            BT
+Category: Standards Track                              C. Pignataro, Ed.
+ISSN: 2070-1721                                      Cisco Systems, Inc.
+                                                               June 2010
+
+
+              Bidirectional Forwarding Detection (BFD) for
+    the Pseudowire Virtual Circuit Connectivity Verification (VCCV)
+
+Abstract
+
+   This document describes Connectivity Verification (CV) Types using
+   Bidirectional 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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5885.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Nadeau & Pignataro           Standards Track                    [Page 1]
+
+RFC 5885                        BFD VCCV                       June 2010
+
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Specification of Requirements  . . . . . . . . . . . . . . . .  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 . . . . . . . . . . . . . . . . . . . . .  7
+   4.  Capability Selection . . . . . . . . . . . . . . . . . . . . .  9
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+     5.1.  MPLS CV Types for the VCCV Interface Parameters Sub-TLV  . 10
+     5.2.  PW Associated Channel Type . . . . . . . . . . . . . . . . 10
+     5.3.  L2TPv3 CV Types for the VCCV Capability AVP  . . . . . . . 11
+   6.  Congestion Considerations  . . . . . . . . . . . . . . . . . . 11
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau & Pignataro           Standards Track                    [Page 2]
+
+RFC 5885                        BFD VCCV                       June 2010
+
+
+1.  Introduction
+
+   This document describes Connectivity Verification (CV) Types using
+   Bidirectional Forwarding Detection (BFD) with Virtual Circuit
+   Connectivity Verification (VCCV).  VCCV [RFC5085] 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.
+
+   BFD [RFC5880] is used over the VCCV control channel primarily as a
+   pseudowire fault detection mechanism, for detecting data-plane
+   failures.  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 Operations,
+   Administration, and Maintenance (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
+   [OAM-MSG-MAP].
+
+   The new BFD CV Types are PW demultiplexer-agnostic, and hence
+   applicable for both MPLS and Layer Two Tunneling Protocol version 3
+   (L2TPv3) pseudowire demultiplexers.  This document concerns itself
+   with the BFD VCCV operation over single-segment pseudowires (SS-PWs).
+   This specification describes procedures only for BFD asynchronous
+   mode.
+
+2.  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].
+
+   The reader is expected to be familiar with the terminology and
+   abbreviations defined in [RFC5085].
+
+3.  Bidirectional Forwarding Detection Connectivity Verification
+
+   VCCV can support several Connectivity Verification (CV) Types.  This
+   section defines new CV Types for use when BFD is used as the VCCV
+   payload.
+
+   Four CV Types are defined for BFD.  Table 1 summarizes the BFD CV
+   Types, grouping them by encapsulation (i.e., with versus without IP/
+   UDP headers) and by functionality (i.e., fault detection only versus
+   fault detection and status signaling).
+
+
+
+
+Nadeau & Pignataro           Standards Track                    [Page 3]
+
+RFC 5885                        BFD VCCV                       June 2010
+
+
+   +----------------------------+--------------+-----------------------+
+   |                            |     Fault    |  Fault Detection and  |
+   |                            |   Detection  |    Status Signaling   |
+   |                            |     Only     |                       |
+   +----------------------------+--------------+-----------------------+
+   |  BFD, IP/UDP Encapsulation |     0x04     |          0x08         |
+   |      (with IP/UDP Headers) |              |                       |
+   |                            |              |                       |
+   |  BFD, PW-ACH Encapsulation |     0x10     |          0x20         |
+   |   (without IP/UDP Headers) |              |                       |
+   +----------------------------+--------------+-----------------------+
+
+                 Table 1: Bitmask Values for BFD CV Types
+
+3.1.  BFD CV Type Operation
+
+   When heart-beat indication is necessary for one or more PWs, the
+   Bidirectional Forwarding Detection (BFD) [RFC5880] provides a means
+   of continuous monitoring of the PW data path and, in some operational
+   modes, propagation of PW receive and transmit defect state
+   indications.
+
+   In order to use BFD, both ends of the PW connection need to agree on
+   the BFD CV Type to use:
+
+      For statically provisioned pseudowires, both ends need to be
+      statically configured to use the same BFD CV Type (in addition to
+      being statically configured for VCCV with the same CC Type).
+
+      For dynamically established pseudowires, both ends of the PW must
+      have signaled the existence of a control channel and the ability
+      to run BFD on it (see Sections 3.3 and 4).
+
+   Once a node has selected a valid BFD CV Type to use (either
+   statically provisioned or selected dynamically after the node has
+   both signaled and received signaling from its peer of these
+   capabilities), it begins sending BFD Control packets:
+
+   o  The BFD Control packets are sent on the VCCV control channel.  The
+      use of the VCCV control channel provides the context required to
+      bind and bootstrap the BFD session, since discriminator values are
+      not exchanged; 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 [RFC5881]
+      and Section 6 of [RFC5882]).
+
+
+
+
+
+Nadeau & Pignataro           Standards Track                    [Page 4]
+
+RFC 5885                        BFD VCCV                       June 2010
+
+
+   o  A single BFD session exists per pseudowire.  Both PW endpoints
+      take the Active role sending initial BFD Control packets with a
+      Your Discriminator field of zero, and BFD Control packets received
+      with a Your Discriminator field of zero are associated to the BFD
+      session bound to the PW.
+
+   o  BFD MUST be run in asynchronous mode (see [RFC5880]).
+
+   The operation of BFD VCCV for PWs is therefore symmetrical.  Both
+   endpoints of the bidirectional pseudowire MUST send BFD messages on
+   the VCCV control channel.
+
+   The details of the BFD state machine are as per Section 6.2 of
+   [RFC5880].  The following scenario exemplifies the operation: when
+   the downstream PE (D-PE) does not receive BFD Control messages from
+   its upstream peer PE (U-PE) during a certain number of transmission
+   intervals (a number provisioned by the operator as "Detect Mult" or
+   detection time multiplier [RFC5880]), D-PE declares that the PW in
+   its receive direction is down.  In other words, D-PE enters the "PW
+   receive defect" state for this PW.  After this calculated Detection
+   Time (see Section 6.8.4 of [RFC5880]), D-PE declares the session
+   Down, and signals this to the remote end via the State (Sta) with
+   Diagnostic code 1 (Control Detection Time Expired).  In turn, U-PE
+   declares the PW is down in its transmit direction, setting the State
+   to Down with Diagnostic code 3 (Neighbor signaled session down) in
+   its control messages to D-PE.  U-PE enters the "PW transmit defect"
+   state for this PW.  How it further processes this error condition,
+   and potentially conveys this status to the attachment circuits, is
+   out of the scope of this specification, and is defined in
+   [OAM-MSG-MAP].
+
+3.2.  BFD Encapsulation
+
+   The VCCV message comprises a BFD Control packet [RFC5880]
+   encapsulated as specified by the CV Type.  There are two ways in
+   which a BFD connectivity verification packet may be encapsulated over
+   the VCCV control channel.  This document defines four BFD CV Types
+   (see Section 3), which can be grouped into two pairs of BFD CV Types
+   from an encapsulation point of view.  See Table 1 in Section 3, which
+   summarizes the BFD CV Types.
+
+   o  IP/UDP BFD Encapsulation (BFD with IP/UDP Headers)
+
+      In the first method, the VCCV encapsulation of BFD includes the
+      IP/UDP headers as defined in Section 4 of [RFC5881].  BFD Control
+      packets are therefore transmitted in UDP with destination port
+      3784 and source port within the range 49152 through 65535.  The IP
+
+
+
+
+Nadeau & Pignataro           Standards Track                    [Page 5]
+
+RFC 5885                        BFD VCCV                       June 2010
+
+
+      Protocol Number and UDP Port numbers discriminate among the
+      possible VCCV payloads (i.e., differentiate among ICMP Ping and
+      LSP Ping defined in [RFC5085] and BFD).
+
+      The IP version (IPv4 or IPv6) MUST match the IP version used for
+      signaling for dynamically established pseudowires or MUST be
+      configured for statically provisioned pseudowires.  The source IP
+      address is an address of the sender.  The destination IP address
+      is a (randomly chosen) IPv4 address from the range 127/8 or IPv6
+      address from the range 0:0:0:0:0:FFFF:127.0.0.0/104.  The
+      rationale is explained in Section 2.1 of [RFC4379].  The Time to
+      Live/Hop Limit and Generalized TTL Security Mechanism (GTSM)
+      procedures from Section 5 of [RFC5881] apply to this
+      encapsulation, and hence the TTL/Hop Limit is set to 255.
+
+      If the PW is established by signaling, then the BFD CV Type used
+      for this encapsulation is either 0x04 or 0x08.
+
+   o  PW-ACH BFD Encapsulation (BFD without IP/UDP Headers)
+
+      In the second method, a BFD Control packet (format defined in
+      Section 4 of [RFC5880]) is encapsulated directly in the VCCV
+      control channel (see Sections 6 and 8 of [RFC5882]) and the IP/UDP
+      headers are omitted from the BFD encapsulation.  Therefore, to
+      utilize this encapsulation, a pseudowire MUST use the PW
+      Associated Channel Header (PW-ACH) Control Word format (see
+      [RFC5586]) for its Control Word (CW) or L2-Specific Sublayer
+      (L2SS, used in L2TPv3).
+
+      In this encapsulation, a "raw" BFD Control packet (i.e., a BFD
+      Control packet as defined in Section 4.1 of [RFC5880] without IP/
+      UDP headers) follows directly the PW-ACH.  The PW-ACH Channel Type
+      indicates that the Associated Channel carries "raw" BFD.  The PW
+      Associated Channel (PWAC) is defined in Section 5 of [RFC4385],
+      and its Channel Type field is used to discriminate the VCCV
+      payload types.
+
+      The usage of the PW-ACH on different VCCV CC Types is specified
+      for CC Type 1, Type 2, and Type 3 respectively in Sections 5.1.1,
+      5.1.2, and 5.1.3 of [RFC5085], and in all cases requires the use
+      of a CW (see Section 7 of [RFC4385]).  When VCCV carries PW-ACH-
+      encapsulated BFD (i.e., "raw" BFD), the PW-ACH (pseudowire CW's or
+      L2SS') Channel Type MUST be set to 0x0007 to indicate "BFD
+      Control, PW-ACH-encapsulated" (i.e., BFD without IP/UDP headers;
+      see Section 5.2).  This is to allow the identification of the
+      encased BFD payload when demultiplexing the VCCV control channel.
+
+
+
+
+
+Nadeau & Pignataro           Standards Track                    [Page 6]
+
+RFC 5885                        BFD VCCV                       June 2010
+
+
+      If the PW is established by signaling, then the BFD CV Type used
+      for this encapsulation is either 0x10 or 0x20.
+
+   In summary, for the IP/UDP encapsulation of BFD (BFD with IP/UDP
+   headers), if a PW Associated Channel Header is used, the Channel Type
+   MUST indicate either IPv4 (0x0021) or IPv6 (0x0057).  For the PW-ACH
+   encapsulation of BFD (BFD without IP/UDP headers), the PW Associated
+   Channel Header MUST be used and the Channel Type MUST indicate BFD
+   Control packet (0x0007).
+
+3.3.  CV Types for BFD
+
+   The CV Type is defined as a bitmask field 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 CV Types shown in
+   the table below augment those already defined in [RFC5085].  Their
+   values shown in parentheses 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:
+
+      Bit (Value)   Description
+      ============  ====================================================
+      Bit 2 (0x04)  BFD IP/UDP-encapsulated, for PW Fault Detection only
+      Bit 3 (0x08)  BFD IP/UDP-encapsulated, for PW Fault Detection and
+                    AC/PW Fault Status Signaling
+      Bit 4 (0x10)  BFD PW-ACH-encapsulated, for PW Fault Detection only
+      Bit 5 (0x20)  BFD PW-ACH-encapsulated, for PW Fault Detection and
+                    AC/PW Fault Status Signaling
+
+   It should be noted that four BFD CV Types have been defined by
+   combining two types of encapsulation with two types of functionality;
+   see Table 1 in Section 3.
+
+   Given the bidirectional nature of BFD, before selecting a given BFD
+   CV Type capability to be used in dynamically established pseudowires,
+   there MUST be common CV Types in the VCCV 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).
+
+
+
+
+
+
+
+Nadeau & Pignataro           Standards Track                    [Page 7]
+
+RFC 5885                        BFD VCCV                       June 2010
+
+
+   The following list enumerates rules, restrictions, and clarifications
+   on the usage of BFD CV Types:
+
+   1.  BFD CV Types used for fault detection and status signaling (i.e.,
+       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.  More details can be found in [OAM-MSG-MAP].
+
+   2.  BFD CV Types used for fault detection only (i.e., CV Types 0x04
+       and 0x10) can be used whether or not a protocol that can signal
+       AC/PW status is available.  This includes both statically
+       provisioned and dynamically signaled pseudowires.
+
+       2.1.  In this case, BFD is used exclusively to detect faults on
+             the PW; if it is desired to convey AC/PW fault status, some
+             means other than BFD are to be used.  Examples include
+             using LDP status messages when using MPLS as a transport
+             (see Section 5.4 of [RFC4447]), and the Circuit Status
+             Attribute Value Pair (AVP) in an L2TPv3 SLI message for
+             L2TPv3 (see Section 5.4.5 of [RFC3931]).
+
+   3.  Pseudowires that do not use a CW or L2SS using the PW Associated
+       Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e.,
+       PW-ACH encapsulation of BFD, without IP/UDP headers).
+
+       3.1.  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 [RFC5085]),
+             and MPLS CC Types 2 and 3 when using a Control Word (as
+             specified in Sections 5.1.2 and 5.1.3 of [RFC5085]).  This
+             restriction stems from the fact that the encapsulation uses
+             the Channel Type in the PW-ACH.
+
+       3.2.  PWs that do not use a PW-ACH can use the VCCV BFD
+             encapsulation with IP/UDP headers, as the only VCCV BFD
+             encapsulation supported.  Using the IP/UDP encapsulated BFD
+             CV Types allows for the concurrent use of other VCCV CV
+             Types that use an encapsulation with IP headers (e.g., ICMP
+             Ping or LSP Ping defined in [RFC5085]).
+
+   4.  Only a single BFD CV Type can be selected and used.  All BFD CV
+       Types are mutually exclusive.  After selecting a BFD CV Type, a
+       node MUST NOT use any of the other three BFD CV Types.
+
+   5.  Once a PE has chosen a single BFD CV Type to use, it MUST
+       continue using it until when the PW is re-signaled.  In order to
+       change the negotiated and selected BFD CV Type, the PW must be
+       torn down and re-established.
+
+
+
+Nadeau & Pignataro           Standards Track                    [Page 8]
+
+RFC 5885                        BFD VCCV                       June 2010
+
+
+4.  Capability Selection
+
+   The precedence rules for selection of various CC and CV Types is
+   clearly outlined in Section 7 of [RFC5085].  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 described 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.
+
+   When multiple BFD CV Types are advertised, and after applying the
+   rules in Section 3.3, the set that both ends of the pseudowire have
+   in common is determined.  If the two ends have more than one BFD CV
+   Type in common, the following list of BFD CV Types is considered in
+   the order of the lowest list number CV Type to the highest list
+   number CV Type, and the CV Type with the lowest list number is used:
+
+   1.  0x20 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW
+       Fault Detection and AC/PW Fault Status Signaling
+
+   2.  0x10 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW
+       Fault Detection only
+
+   3.  0x08 - BFD IP/UDP-encapsulated, for PW Fault Detection and AC/PW
+       Fault Status Signaling
+
+   4.  0x04 - BFD IP/UDP-encapsulated, for PW Fault Detection only
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau & Pignataro           Standards Track                    [Page 9]
+
+RFC 5885                        BFD VCCV                       June 2010
+
+
+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 [RFC5085].
+   This section lists the new BFD CV Types.
+
+   IANA has augmented the "VCCV Connectivity Verification (CV) Types"
+   registry in the Pseudowire Name Spaces reachable from [IANA].  These
+   are bitfield values.  CV Type values 0x04, 0x08, 0x10, and 0x20 are
+   specified in Section 3 of this document.
+
+      MPLS Connectivity Verification (CV) Types:
+
+      Bit (Value)   Description
+      ============  ====================================================
+      Bit 2 (0x04)  BFD IP/UDP-encapsulated, for PW Fault Detection only
+      Bit 3 (0x08)  BFD IP/UDP-encapsulated, for PW Fault Detection and
+                    AC/PW Fault Status Signaling
+      Bit 4 (0x10)  BFD PW-ACH-encapsulated, for PW Fault Detection only
+      Bit 5 (0x20)  BFD PW-ACH-encapsulated, for PW Fault Detection and
+                    AC/PW Fault Status Signaling
+
+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 Pseudowire Name Spaces reachable from
+   [IANA].
+
+   IANA has reserved a new Pseudowire Associated Channel Type value as
+   follows:
+
+   Registry:
+                                                TLV
+    Value   Description                         Follows  Reference
+    ------  ----------------------------------  -------  ---------------
+    0x0007  BFD Control, PW-ACH encapsulation   No       [This document]
+            (without IP/UDP Headers)
+
+
+
+
+
+
+
+
+
+
+
+Nadeau & Pignataro           Standards Track                   [Page 10]
+
+RFC 5885                        BFD VCCV                       June 2010
+
+
+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].
+
+   IANA has reserved the following L2TPv3 Connectivity Verification (CV)
+   Types in the VCCV Capability AVP Values registry.
+
+      VCCV Capability AVP (Attribute Type 96) Values
+      ----------------------------------------------
+
+      L2TPv3 Connectivity Verification (CV) Types:
+
+      Bit (Value)   Description
+      ============  ====================================================
+      Bit 2 (0x04)  BFD IP/UDP-encapsulated, for PW Fault Detection only
+      Bit 3 (0x08)  BFD IP/UDP-encapsulated, for PW Fault Detection and
+                    AC/PW Fault Status Signaling
+      Bit 4 (0x10)  BFD PW-ACH-encapsulated, for PW Fault Detection only
+      Bit 5 (0x20)  BFD PW-ACH-encapsulated, for PW Fault Detection and
+                    AC/PW Fault Status Signaling
+
+6.  Congestion Considerations
+
+   The congestion considerations that apply to [RFC5085] apply to this
+   mode of operation as well.  This section describes explicitly how
+   they apply.
+
+   BFD as a VCCV application is required to provide details on
+   congestion and bandwidth considerations.  BFD provides with a desired
+   minimum transmit interval and a required minimum receive interval,
+   negotiates the transmission interval using these configurable fields,
+   and has a packet of fixed size (setting the transmission rate).
+   Therefore, it results in a configuration limited bandwidth
+   utilization.  As stated in [RFC5085], this is sufficient protection
+   against congestion as long as BFD's configured maximum bit-rate is
+   minimal compared to the bit-rate of the pseudowire the VCCV channel
+   is associated with.  If the pseudowire bit-rate can't be guaranteed
+   to be minimal, like potentially for highly variable bit-rate and/or
+   congestion responsive pseudowires, BFD will be required to operate
+   using an adaptive congestion control mechanism (for example,
+   including a throttled transmission rate on "congestion detected"
+   situations, and a slow-start after shutdown due to congestion and
+   until basic connectivity is verified).
+
+
+
+
+
+
+Nadeau & Pignataro           Standards Track                   [Page 11]
+
+RFC 5885                        BFD VCCV                       June 2010
+
+
+   Since the bandwidth utilized by BFD is configuration-limited, the
+   VCCV channel MUST NOT be rate-limited below this maximum configurable
+   bandwidth or BFD will not operate correctly.  The VCCV channel could
+   provide rate-limiting above the maximum BFD rate, to protect from a
+   misbehaving BFD application, so that it does not conflict and can
+   coexist.  Additionally, the VCCV channel SHOULD NOT use any
+   additional congestion control loop that would interfere or negatively
+   interact with that of BFD.  There are no additional congestion
+   considerations.
+
+7.  Security Considerations
+
+   Routers that implement the additional CV Types defined herein are
+   subject to the same security considerations as defined in [RFC5085],
+   [RFC5880], and [RFC5881].  This specification does not raise any
+   additional security issues beyond these.  The IP/UDP-encapsulated BFD
+   makes use of the TTL/Hop Limit procedures described in Section 5 of
+   [RFC5881], including the use of the Generalized TTL Security
+   Mechanism (GTSM) as a security mechanism.
+
+8.  Acknowledgements
+
+   This work forks from a previous revision of the PWE3 WG document that
+   resulted in [RFC5085], 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.
+
+   Mustapha Aissaoui, Sam Aldrin, Stewart Bryant, Peter B. Busschbach,
+   Annamaria Fulignoli, Vishwas Manral, Luca Martini, Dave McDysan, Ben
+   Niven-Jenkins, Pankil Shah, Yaakov Stein, and George Swallow provided
+   useful feedback and valuable comments and suggestions improving newer
+   versions of this document.
+
+9.  References
+
+9.1.  Normative References
+
+   [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.
+
+   [RFC5085]      Nadeau, T. and C. Pignataro, "Pseudowire Virtual
+                  Circuit Connectivity Verification (VCCV): A Control
+                  Channel for Pseudowires", RFC 5085, December 2007.
+
+
+
+Nadeau & Pignataro           Standards Track                   [Page 12]
+
+RFC 5885                        BFD VCCV                       June 2010
+
+
+   [RFC5880]      Katz, D. and D. Ward, "Bidirectional Forwarding
+                  Detection", RFC 5880, June 2010.
+
+   [RFC5881]      Katz, D. and D. Ward, "Bidirectional Forwarding
+                  Detection (BFD) for IPv4 and IPv6 (Single Hop)",
+                  RFC 5881, June 2010.
+
+   [RFC5882]      Katz, D. and D. Ward, "Generic Application of
+                  Bidirectional Forwarding Detection (BFD)", RFC 5882,
+                  June 2010.
+
+9.2.  Informative References
+
+   [IANA]         Internet Assigned Numbers Authority, "Protocol
+                  Registries", <http://www.iana.org>.
+
+   [OAM-MSG-MAP]  Aissaoui, M., Busschbach, P., Morrow, M., Martini, L.,
+                  Stein, Y., Allan, D., and T. Nadeau, "Pseudowire (PW)
+                  OAM Message Mapping", Work in Progress, March 2010.
+
+   [RFC3931]      Lau, J., Townsley, M., and I. Goyret, "Layer Two
+                  Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
+                  March 2005.
+
+   [RFC4379]      Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+                  Label Switched (MPLS) Data Plane Failures", RFC 4379,
+                  February 2006.
+
+   [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.
+
+   [RFC5586]      Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
+                  Associated Channel", RFC 5586, June 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau & Pignataro           Standards Track                   [Page 13]
+
+RFC 5885                        BFD VCCV                       June 2010
+
+
+Authors' Addresses
+
+   Thomas D. Nadeau (editor)
+   BT
+   BT Centre
+   81 Newgate Street
+   London  EC1A 7AJ
+   United Kingdom
+
+   EMail: tom.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           Standards Track                   [Page 14]
+