From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5885.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc5885.txt (limited to 'doc/rfc/rfc5885.txt') 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", . + + [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] + -- cgit v1.2.3