idnits 2.17.1 draft-ietf-pwe3-vccv-bfd-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 586. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2008) is 5783 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-08 == Outdated reference: A later version (-05) exists of draft-ietf-bfd-generic-04 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-v4v6-1hop-08 == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-06 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 T. Nadeau, Ed. 3 Internet-Draft BT 4 Intended status: Standards Track C. Pignataro, Ed. 5 Expires: December 27, 2008 Cisco Systems, Inc. 6 June 25, 2008 8 Bidirectional Forwarding Detection (BFD) for 9 the Pseudowire Virtual Circuit Connectivity Verification (VCCV) 10 draft-ietf-pwe3-vccv-bfd-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 27, 2008. 37 Abstract 39 This document describes new Connectivity Verification (CV) types 40 using Bidirectional Forwarding Detection (BFD) with Virtual Circuit 41 Connectivity Verification (VCCV). VCCV provides a control channel 42 that is associated with a Pseudowire (PW), as well as the 43 corresponding operations and management functions such as 44 connectivity verification to be used over that control channel. 46 Table of Contents 48 1. Specification of Requirements . . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Bidirectional Forwarding Detection Connectivity 53 Verification . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. BFD CV Type Operation . . . . . . . . . . . . . . . . . . 4 55 3.2. BFD Encapsulation . . . . . . . . . . . . . . . . . . . . 5 56 3.3. CV Types for BFD . . . . . . . . . . . . . . . . . . . . . 6 58 4. Capability Selection . . . . . . . . . . . . . . . . . . . . . 8 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV . 9 62 5.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 9 63 5.3. L2TPv3 CV Types for the VCCV Capability AVP . . . . . . . 10 65 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 10 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 76 Intellectual Property and Copyright Statements . . . . . . . . . . 14 78 1. Specification of Requirements 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 The reader is expected to be familiar with the terminology and 85 abbreviations defined in [RFC5085]. 87 2. Introduction 89 This document describes new Connectivity Verification (CV) types 90 using Bidirectional Forwarding Detection (BFD) with Virtual Circuit 91 Connectivity Verification (VCCV). VCCV [RFC5085] provides a control 92 channel that is associated with a Pseudowire (PW), as well as the 93 corresponding operations and management functions such as 94 connectivity/fault verification to be used over that control channel. 96 BFD [I-D.ietf-bfd-base] is used over the VCCV control channel 97 primarily as a pseudowire fault detection mechanism, for detecting 98 dataplane failures. Some BFD CV Types can additionally carry fault 99 status between the endpoints of the pseudowire. Furthermore, this 100 information can then be translated into the native OAM status codes 101 used by the native access technologies, such as ATM, Frame-Relay or 102 Ethernet. The specific details of such status interworking are out 103 of the scope of this document, and are only noted here to illustrate 104 the utility of BFD over VCCV for such purposes. Those details can be 105 found in [I-D.ietf-pwe3-oam-msg-map]. 107 The new BFD CV Types are PW Demultiplexer-agnostic, and hence 108 applicable for both MPLS and L2TPv3 Pseudowire Demultiplexers. This 109 document concerns itself with the BFD VCCV operation over Single- 110 Segment Pseudowires (SS-PW). This specification describes procedures 111 only for BFD asynchronous mode. 113 3. Bidirectional Forwarding Detection Connectivity Verification 115 VCCV can support several Connectivity Verification (CV) types. This 116 section defines new CV Types for use when BFD is used as the VCCV 117 payload. 119 The CV Type is defined as a bitmask field used to indicate the 120 specific CV Type or Types (i.e., none, one or more) of VCCV packets 121 that may be sent on the VCCV control channel. The values shown below 122 augment those already defined in [RFC5085]. They represent the 123 numerical value corresponding to the actual bit being set in the CV 124 Type bitfield. 126 BFD CV Types: 128 The defined values for the different BFD CV Types for MPLS and 129 L2TPv3 PWs are: 131 Bit (Value) Description 132 ============ ==================================================== 133 Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only 134 Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and 135 AC/PW Fault Status Signaling 136 Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only 137 Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and 138 AC/PW Fault Status Signaling 140 It should be noted that four BFD CV Types have been defined by 141 permutation of their encapsulation and functionality, see 142 Section 3.3. 144 3.1. BFD CV Type Operation 146 When heart-beat indication is necessary for one or more PWs, the 147 Bidirectional Forwarding Detection (BFD) [I-D.ietf-bfd-base] provides 148 a means of continuous monitoring of the PW data path and, in some 149 operational modes, propagation of forward and reverse defect 150 indications. 152 In order to use BFD, both ends of the PW connection need to agree on 153 the BFD CV Type to use: 155 For statically provisioned pseudowires, both ends need to be 156 statically configured to use the same BFD CV Type (in addition to 157 be statically configured for VCCV with the same CC Type). 159 For dynamically established pseudowires, both ends of the PW must 160 have signaled the existence of a control channel and the ability 161 to run BFD on it (see Section 3.3 and Section 4). 163 Once a node has selected a valid BFD CV Type to use (either 164 statically provisioned or selected dynamically after the node has 165 both signaled and received signaling from its peer of these 166 capabilities), it begins sending BFD control packets. 168 The BFD control packets are sent on the VCCV control channel. The 169 use of the VCCV control channel provides the context required to bind 170 and bootstrap the BFD session, since discriminator values are not 171 exchanged; the pseudowire demultiplexer field (e.g., MPLS PW Label or 172 L2TPv3 Session ID) provides the context to demultiplex the first BFD 173 control packet, and thus single-hop BFD initialization procedures are 174 followed (see Section 3 of [I-D.ietf-bfd-v4v6-1hop] and Section 6 of 175 [I-D.ietf-bfd-generic]). A single BFD session exists per-pseudowire. 176 Both PW endpoints take the Active role sending initial BFD Control 177 packets with a "Your Discriminator" field of zero, and BFD Control 178 packets received with a "Your Discriminator" field of zero are 179 associated to the BFD session bound to the PW. BFD MUST be run in 180 asynchronous mode (see [I-D.ietf-bfd-base]). 182 When the downstream PE (D-PE) does not receive BFD control messages 183 from its upstream peer PE (U-PE) during a certain number of 184 transmission intervals (a number provisioned by the operator as 185 Detect Mult), D-PE declares that the PW in its receive direction is 186 down. In other words, D-PE enters the "forward defect" state for 187 this PW. After this calculated Detection Time, D-PE declares the 188 session Down, and signals this to the remote end via the State (Sta) 189 with Diagnostic code 1 (Control Detection Time Expired). In turn, 190 U-PE declares the PW is down in its transmit direction setting the 191 State to Down, and it using Diagnostic code 3 (Neighbor signaled 192 session down) in its control messages to D-PE. U-PE enters the 193 "reverse defect" state for this PW. If needed, how it further 194 processes this error condition, and conveys this status to the 195 attachment circuits is out of the scope of this specification, and is 196 instead defined in [I-D.ietf-pwe3-oam-msg-map]. 198 The VCCV message comprises a BFD Control packet [I-D.ietf-bfd-base] 199 encapsulated as specified by the CV Type (see Section 3.2). 201 3.2. BFD Encapsulation 203 There are two ways in which a BFD connectivity verification packet 204 may be encapsulated over the VCCV control channel. This document 205 defines four BFD CV Types (see Section 3), which can be grouped into 206 two pairs of BFD CV Types from an encapsulation point of view. 207 Table 1 in Section 3.3 summarizes the BFD CV Types. 209 o IP/UDP BFD Encapsulation (BFD with IP/UDP Headers) 211 In the first method, the VCCV encapsulation of BFD includes the 212 IP/UDP headers as defined in Section 4 of 213 [I-D.ietf-bfd-v4v6-1hop]. BFD Control packets are therefore 214 transmitted in UDP with destination port 3784 and source port 215 within the rage 49152 through 65535. The IP Protocol Number and 216 UDP Port numbers discriminate among the possible VCCV payloads 217 (i.e., differentiate among ICMP Ping and LSP Ping defined in 218 [RFC5085] and BFD). 220 The source IP address is a routable address of the sender. The 221 destination IP address is a (randomly chosen) IPv4 address from 222 the range 127/8 or IPv6 address from the range 0:0:0:0:0:FFFF:127/ 223 104. The rationale is explained in Section 2.1 of [RFC4379]. The 224 Time to Live/Hop Limit procedures from Section 5 of 225 [I-D.ietf-bfd-v4v6-1hop] apply to this encapsulation, and hence 226 the TTL/Hop Limit is set to 255. In this encapsulation, the BFD 227 CV Type used in signaling (if used) is either 0x04 or 0x08. 229 o PW-ACH BFD Encapsulation (BFD without IP/UDP Headers) 231 In the second method, a BFD Control packet (format defined in 232 Section 4 of [I-D.ietf-bfd-base]) is encapsulated directly in the 233 VCCV control channel (see Sections 6 and 8 of 234 [I-D.ietf-bfd-generic]) and the IP/UDP headers are omitted from 235 the BFD encapsulation. Therefore, to utilize this encapsulation, 236 a pseudowire MUST use a Control Word (CW) or Layer-2 Specific 237 Sublayer (L2SS) that can take the PW Associated Channel Header 238 (PW-ACH) Control Word format. 240 In this encapsulation, a "raw" BFD Control packet follows directly 241 the PW-ACH, and the PW-ACH Channel Type identifies "raw" BFD. The 242 PW Associated Channel (PWAC) is defined in Section 5 of [RFC4385], 243 and its Channel Type field is used as a payload type identifier to 244 discriminate the VCCV payload types. 246 The usage of the PW-ACH on different VCCV CC Types is specified 247 for CC Type 1, Type 2 and Type 3 respectively in Sections 5.1.1, 248 5.1.2 and 5.1.3 of [RFC5085], in all cases depending on the use of 249 a CW. When VCCV carries raw BFD, the PW-ACH (Pseudowire CW's or 250 L2SS') Channel Type MUST be set to 0x0007 to indicate "BFD 251 Control, PW-ACH-encapsulated" (i.e., BFD Without IP/UDP Headers, 252 see Section 5.2), to allow the identification of the encased BFD 253 payload when demultiplexing the VCCV control channel. In this 254 case, the BFD CV Type employed in signaling (if used) is either 255 0x10 or 0x20. 257 In summary, for the IP/UDP encapsulation of BFD (BFD with IP/UDP 258 headers), if a PW Associated Channel Header is used, the Channel Type 259 can indicate IPv4 (0x0021) or IPv6 (0x0057). For the PW-ACH 260 encapsulation of BFD (BFD without IP/UDP headers), the PW Associated 261 Channel Header MUST be used and indicates BFD Control packet 262 (0x0007). 264 3.3. CV Types for BFD 266 Four CV Types are defined for BFD. Table 1 summarizes the BFD CV 267 Types, grouping them by encapsulation (i.e., with and without IP/UDP 268 headers) and by functionality (i.e., fault detection only, or fault 269 detection and status signaling). 271 +----------------------------+--------------+-----------------------+ 272 | | Fault | Fault Detection and | 273 | | Detection | Status Signaling | 274 | | Only | | 275 +----------------------------+--------------+-----------------------+ 276 | BFD, IP/UDP encapsulation | 0x04 | 0x08 | 277 | (with IP/UDP Headers) | | | 278 | | | | 279 | BFD, PW-ACH encapsulation | 0x10 | 0x20 | 280 | (without IP/UDP Headers) | | | 281 +----------------------------+--------------+-----------------------+ 283 Table 1: Bitmask Values for BFD CV Types 285 Given the bidirectional nature of BFD, before selecting a given BFD 286 CV Type capability to be used in dynamically established pseudowires, 287 there MUST be common CV Types in the VCCV capability advertised and 288 received. That is, only BFD CV Types that were both advertised and 289 received are available to be selected. Additionally, only one BFD CV 290 Type can be used (selecting a BFD CV Type excludes all the remaining 291 BFD CV Types). 293 The following list enumerates rules, restrictions and clarifications 294 on the usage of BFD CV Types: 296 1. BFD CV Types used for fault detection and status signaling (i.e., 297 CV Types 0x08 and 0x20) SHOULD NOT be used when a control 298 protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available 299 that can signal the AC/PW status to the remote endpoint of the 300 PW. More details can be found in [I-D.ietf-pwe3-oam-msg-map]. 302 2. BFD CV Types used for fault detection only (i.e., CV Types 0x04 303 and 0x10) can be used whether a protocol that can signal AC/PW 304 status is available or not. This includes both statically 305 provisioned and dynamically signaled pseudowires. 307 A. In this case, BFD is used exclusively to detect faults on the 308 PW; if it is desired to convey AC/PW fault status, some means 309 other than BFD are to be used. Examples include using LDP 310 status messages when using MPLS as a transport (see Section 311 5.4 of [RFC4447]), and the Circuit Status AVP in an L2TPv3 312 SLI message for L2TPv3 (see Section 5.4.5 of [RFC3931]). 314 3. Pseudowires that do not use a CW or L2SS using the PW Associated 315 Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., 316 PW-ACH encapsulation of BFD, without IP/UDP headers). 318 A. PWs that use a PW-ACH include CC Type 1 (for both MPLS and 319 L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]), 320 and MPLS CC Types 2 and 3 when using a Control Word (as 321 specified in Sections 5.1.2 and 5.1.3 of [RFC5085]). This 322 restriction stems from the fact that the PW-ACH contains a 323 Protocol Identification (PID) field, the Channel Type. 325 B. PWs that do not use a PW-ACH can use the VCCV BFD 326 encapsulation with IP/UDP headers, including its concurrent 327 use along with another CV Type that uses an encapsulation 328 with IP headers (e.g., ICMP Ping or LSP Ping). For example, 329 as specified in Section 7 of [RFC4385], a Pseudowire 330 operating without CW MUST NOT use the PW-ACH. 332 4. Only a single BFD CV Type can be selected and used. All BFD CV 333 Types are mutually exclusive with the rest, after selecting a BFD 334 CV Type, a node MUST NOT use any of the other three BFD CV Types. 336 4. Capability Selection 338 The precedence rules for selection of various CC and CV Types is 339 clearly outlined in Section 7 of [RFC5085]. This section augments 340 these rules when the BFD CV Types defined herein are supported. The 341 selection of a specific BFD CV Type to use out of the four available 342 CV Types defined is tied to multiple factors, as hinted in 343 Section 3.3. Given that BFD is bidirectional in nature, only CV 344 Types that are both received and sent in VCCV capability signaling 345 advertisement can be selected. 347 There may be more than one CV Type available for selection after 348 considering the intersection of advertised and received BFD CV Types, 349 and applying the rules in Section 3.3. For these cases were multiple 350 BFD CV Types are available for selection, the following precedence 351 order applies when choosing the single BFD CV Type to use. The 352 lowest numbered item (where both ends have set the indicated flag and 353 such flag is allowed by the rules above) is used: 355 1. 0x20 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW 356 Fault Detection and AC/PW Fault Status Signaling 358 2. 0x10 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW 359 Fault Detection only 361 3. 0x08 - BFD IP/UDP-encapsulated, for PW Fault Detection and AC/PW 362 Fault Status Signaling 364 4. 0x04 - BFD IP/UDP-encapsulated, for PW Fault Detection only 366 This precedence order prioritizes superset of functionality and 367 simplicity of encapsulation. 369 5. IANA Considerations 371 5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV 373 The VCCV Interface Parameters Sub-TLV codepoint is defined in 374 [RFC4446], and the VCCV CV Types registry is defined in [RFC5085]. 375 This section lists the new BFD CV Types. 377 IANA is requested to augment the "VCCV Connectivity Verification 378 Types" registry in the Pseudo Wires Name Spaces, reachable from 379 [IANA.pwe3-parameters]. These are bitfield values. CV Type values 380 0x04 0x08, 0x10 and 0x20 are specified in Section 3. 382 MPLS Connectivity Verification (CV) Types: 384 Bit (Value) Description 385 ============ ==================================================== 386 Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only 387 Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and 388 AC/PW Fault Status Signaling 389 Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only 390 Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and 391 AC/PW Fault Status Signaling 393 5.2. PW Associated Channel Type 395 The PW Associated Channel Types used by VCCV rely on previously 396 allocated numbers from the Pseudowire Associated Channel Types 397 Registry [RFC4385] in the Pseudo Wires Name Spaces reachable from 398 [IANA.pwe3-parameters]. In particular, 0x21 (Internet Protocol 399 version 4) is used whenever an IPv4 payload follows the Pseudowire 400 Associated Channel Header, or 0x57 is used when an IPv6 payload 401 follows the Pseudowire Associated Channel Header. 403 In cases where a raw BFD Control packet follows the Pseudowire 404 Associated Channel as specified in Section 3.2 (i.e., when using the 405 PW-ACH-encapsulated BFD without IP/UDP headers), a new "Pseudowire 406 Associated Channel Types" Registry [RFC4385] entry of 0x07 is used. 408 IANA is requested to reserve a new Pseudowire Associated Channel Type 409 value as follows: 411 Value (in hex) Protocol Name Reference 412 -------------- --------------------------------- --------- 414 0x0007 BFD Control, PW-ACH encapsulation [This document] 415 (without IP/UDP Headers) 417 5.3. L2TPv3 CV Types for the VCCV Capability AVP 419 This section lists the new BFD CV Types to be added to the existing 420 "VCCV Capability AVP" registry in the L2TP name spaces. The Layer 421 Two Tunneling Protocol "L2TP" Name Spaces are reachable from 422 [IANA.l2tp-parameters]. 424 IANA is requested to reserve the following L2TPv3 Connectivity 425 Verification (CV) Types in the VCCV Capability AVP Values registry. 427 VCCV Capability AVP (Attribute Type AVP-TBD) Values 428 --------------------------------------------------- 430 L2TPv3 Connectivity Verification (CV) Types: 432 Bit (Value) Description 433 ============ ==================================================== 434 Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only 435 Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and 436 AC/PW Fault Status Signaling 437 Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only 438 Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and 439 AC/PW Fault Status Signaling 441 6. Congestion Considerations 443 The congestion considerations that apply to [RFC5085] apply to this 444 mode of operation as well. 446 7. Security Considerations 448 Routers that implement the additional CV Types defined herein are 449 subject to the same security considerations as defined in [RFC5085], 450 [I-D.ietf-bfd-base], and [I-D.ietf-bfd-v4v6-1hop]. This 451 specification does not raise any additional security issues beyond 452 these. The IP/UDP-encapsulated BFD makes use of the TTL/Hop Limit 453 procedures described in Section 5 of [I-D.ietf-bfd-v4v6-1hop], 454 including the use of the Generalized TTL Security Mechanism (GTSM) as 455 a security mechanism. 457 8. Acknowledgements 459 This work forks from a previous revision of the PWE3 WG document that 460 resulted in [RFC5085], to which a number of people contributed, 461 including Rahul Aggarwal, Peter B. Busschbach, Yuichi Ikejiri, Kenji 462 Kumaki, Luca Martini, Monique Morrow, George Swallow, and others. 464 Stewart Bryant, Luca Martini, Pankil Shah, and George Swallow 465 provided useful feedback and valuable comments and suggestions on the 466 newer versions of this document. 468 9. References 470 9.1. Normative References 472 [I-D.ietf-bfd-base] 473 Katz, D. and D. Ward, "Bidirectional Forwarding 474 Detection", draft-ietf-bfd-base-08 (work in progress), 475 March 2008. 477 [I-D.ietf-bfd-generic] 478 Katz, D. and D. Ward, "Generic Application of BFD", 479 draft-ietf-bfd-generic-04 (work in progress), 480 January 2008. 482 [I-D.ietf-bfd-v4v6-1hop] 483 Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single 484 Hop)", draft-ietf-bfd-v4v6-1hop-08 (work in progress), 485 March 2008. 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, March 1997. 490 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 491 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 492 Use over an MPLS PSN", RFC 4385, February 2006. 494 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 495 Connectivity Verification (VCCV): A Control Channel for 496 Pseudowires", RFC 5085, December 2007. 498 9.2. Informative References 500 [I-D.ietf-pwe3-oam-msg-map] 501 Nadeau, T., "Pseudo Wire (PW) OAM Message Mapping", 502 draft-ietf-pwe3-oam-msg-map-06 (work in progress), 503 February 2008. 505 [IANA.l2tp-parameters] 506 Internet Assigned Numbers Authority, "Layer Two Tunneling 507 Protocol "L2TP"", April 2007, 508 . 510 [IANA.pwe3-parameters] 511 Internet Assigned Numbers Authority, "Pseudo Wires Name 512 Spaces", June 2007, 513 . 515 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 516 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 518 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 519 Label Switched (MPLS) Data Plane Failures", RFC 4379, 520 February 2006. 522 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 523 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 525 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 526 Heron, "Pseudowire Setup and Maintenance Using the Label 527 Distribution Protocol (LDP)", RFC 4447, April 2006. 529 Authors' Addresses 531 Thomas D. Nadeau (editor) 532 BT 533 BT Centre 534 81 Newgate Street 535 London, EC1A 7AJ 536 United Kingdom 538 Email: tom.nadeau@bt.com 539 Carlos Pignataro (editor) 540 Cisco Systems, Inc. 541 7200 Kit Creek Road 542 PO Box 14987 543 Research Triangle Park, NC 27709 544 USA 546 Email: cpignata@cisco.com 548 Full Copyright Statement 550 Copyright (C) The IETF Trust (2008). 552 This document is subject to the rights, licenses and restrictions 553 contained in BCP 78, and except as set forth therein, the authors 554 retain all their rights. 556 This document and the information contained herein are provided on an 557 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 558 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 559 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 560 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 561 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 562 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 564 Intellectual Property 566 The IETF takes no position regarding the validity or scope of any 567 Intellectual Property Rights or other rights that might be claimed to 568 pertain to the implementation or use of the technology described in 569 this document or the extent to which any license under such rights 570 might or might not be available; nor does it represent that it has 571 made any independent effort to identify any such rights. Information 572 on the procedures with respect to rights in RFC documents can be 573 found in BCP 78 and BCP 79. 575 Copies of IPR disclosures made to the IETF Secretariat and any 576 assurances of licenses to be made available, or the result of an 577 attempt made to obtain a general license or permission for the use of 578 such proprietary rights by implementers or users of this 579 specification can be obtained from the IETF on-line IPR repository at 580 http://www.ietf.org/ipr. 582 The IETF invites any interested party to bring to its attention any 583 copyrights, patents or patent applications, or other proprietary 584 rights that may cover technology that may be required to implement 585 this standard. Please address the information to the IETF at 586 ietf-ipr@ietf.org.