idnits 2.17.1 draft-ietf-pwe3-vccv-bfd-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 13, 2009) is 5459 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-09 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-v4v6-1hop-09 == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-10 -- 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 (~~), 4 warnings (==), 4 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: November 14, 2009 Cisco Systems, Inc. 6 May 13, 2009 8 Bidirectional Forwarding Detection (BFD) for 9 the Pseudowire Virtual Circuit Connectivity Verification (VCCV) 10 draft-ietf-pwe3-vccv-bfd-04 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on November 14, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document describes new Connectivity Verification (CV) types 59 using Bidirectional Forwarding Detection (BFD) with Virtual Circuit 60 Connectivity Verification (VCCV). VCCV provides a control channel 61 that is associated with a Pseudowire (PW), as well as the 62 corresponding operations and management functions such as 63 connectivity verification to be used over that control channel. 65 Table of Contents 67 1. Specification of Requirements . . . . . . . . . . . . . . . . 3 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Bidirectional Forwarding Detection Connectivity 72 Verification . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3.1. BFD CV Type Operation . . . . . . . . . . . . . . . . . . 4 74 3.2. BFD Encapsulation . . . . . . . . . . . . . . . . . . . . 5 75 3.3. CV Types for BFD . . . . . . . . . . . . . . . . . . . . . 7 77 4. Capability Selection . . . . . . . . . . . . . . . . . . . . . 8 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV . 9 81 5.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 10 82 5.3. L2TPv3 CV Types for the VCCV Capability AVP . . . . . . . 10 84 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 11 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 96 1. Specification of Requirements 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 The reader is expected to be familiar with the terminology and 103 abbreviations defined in [RFC5085]. 105 2. Introduction 107 This document describes new Connectivity Verification (CV) types 108 using Bidirectional Forwarding Detection (BFD) with Virtual Circuit 109 Connectivity Verification (VCCV). VCCV [RFC5085] provides a control 110 channel that is associated with a Pseudowire (PW), as well as the 111 corresponding operations and management functions such as 112 connectivity/fault verification to be used over that control channel. 114 BFD [I-D.ietf-bfd-base] is used over the VCCV control channel 115 primarily as a pseudowire fault detection mechanism, for detecting 116 dataplane failures. Some BFD CV Types can additionally carry fault 117 status between the endpoints of the pseudowire. Furthermore, this 118 information can then be translated into the native OAM status codes 119 used by the native access technologies, such as ATM, Frame-Relay or 120 Ethernet. The specific details of such status interworking are out 121 of the scope of this document, and are only noted here to illustrate 122 the utility of BFD over VCCV for such purposes. Those details can be 123 found in [I-D.ietf-pwe3-oam-msg-map]. 125 The new BFD CV Types are PW Demultiplexer-agnostic, and hence 126 applicable for both MPLS and L2TPv3 Pseudowire Demultiplexers. This 127 document concerns itself with the BFD VCCV operation over Single- 128 Segment Pseudowires (SS-PW). This specification describes procedures 129 only for BFD asynchronous mode. 131 3. Bidirectional Forwarding Detection Connectivity Verification 133 VCCV can support several Connectivity Verification (CV) types. This 134 section defines new CV Types for use when BFD is used as the VCCV 135 payload. 137 Four CV Types are defined for BFD. Table 1 summarizes the BFD CV 138 Types, grouping them by encapsulation (i.e., with vs. without IP/UDP 139 headers) and by functionality (i.e., fault detection only vs. fault 140 detection and status signaling). 142 +----------------------------+--------------+-----------------------+ 143 | | Fault | Fault Detection and | 144 | | Detection | Status Signaling | 145 | | Only | | 146 +----------------------------+--------------+-----------------------+ 147 | BFD, IP/UDP encapsulation | 0x04 | 0x08 | 148 | (with IP/UDP Headers) | | | 149 | | | | 150 | BFD, PW-ACH encapsulation | 0x10 | 0x20 | 151 | (without IP/UDP Headers) | | | 152 +----------------------------+--------------+-----------------------+ 154 Table 1: Bitmask Values for BFD CV Types 156 3.1. BFD CV Type Operation 158 When heart-beat indication is necessary for one or more PWs, the 159 Bidirectional Forwarding Detection (BFD) [I-D.ietf-bfd-base] provides 160 a means of continuous monitoring of the PW data path and, in some 161 operational modes, propagation of PW receive and transmit defect 162 state indications. 164 In order to use BFD, both ends of the PW connection need to agree on 165 the BFD CV Type to use: 167 For statically provisioned pseudowires, both ends need to be 168 statically configured to use the same BFD CV Type (in addition to 169 be statically configured for VCCV with the same CC Type). 171 For dynamically established pseudowires, both ends of the PW must 172 have signaled the existence of a control channel and the ability 173 to run BFD on it (see Section 3.3 and Section 4). 175 Once a node has selected a valid BFD CV Type to use (either 176 statically provisioned or selected dynamically after the node has 177 both signaled and received signaling from its peer of these 178 capabilities), it begins sending BFD control packets. 180 The BFD control packets are sent on the VCCV control channel. The 181 use of the VCCV control channel provides the context required to bind 182 and bootstrap the BFD session, since discriminator values are not 183 exchanged; the pseudowire demultiplexer field (e.g., MPLS PW Label or 184 L2TPv3 Session ID) provides the context to demultiplex the first BFD 185 control packet, and thus single-hop BFD initialization procedures are 186 followed (see Section 3 of [I-D.ietf-bfd-v4v6-1hop] and Section 6 of 187 [I-D.ietf-bfd-generic]). A single BFD session exists per-pseudowire. 188 Both PW endpoints take the Active role sending initial BFD Control 189 packets with a "Your Discriminator" field of zero, and BFD Control 190 packets received with a "Your Discriminator" field of zero are 191 associated to the BFD session bound to the PW. BFD MUST be run in 192 asynchronous mode (see [I-D.ietf-bfd-base]). 194 The operation of BFD VCCV for PWs is therefore symmetrical. Both 195 endpoints of the bidirectional pseudowire MUST send BFD messages on 196 the VCCV control channel. 198 The details of the BFD state machine are as per Section 6.2 of 199 [I-D.ietf-bfd-base]. The following scenario exemplifies the 200 operation: When the downstream PE (D-PE) does not receive BFD control 201 messages from its upstream peer PE (U-PE) during a certain number of 202 transmission intervals (a number provisioned by the operator as 203 "Detect Mult" or detection time multiplier [I-D.ietf-bfd-base]), D-PE 204 declares that the PW in its receive direction is down. In other 205 words, D-PE enters the "PW receive defect" state for this PW. After 206 this calculated Detection Time (see Section 6.8.4 of 207 [I-D.ietf-bfd-base]), D-PE declares the session Down, and signals 208 this to the remote end via the State (Sta) with Diagnostic code 1 209 (Control Detection Time Expired). In turn, U-PE declares the PW is 210 down in its transmit direction, setting the State to Down with 211 Diagnostic code 3 (Neighbor signaled session down) in its control 212 messages to D-PE. U-PE enters the "PW transmit defect" state for 213 this PW. How it further processes this error condition, and 214 potentially conveys this status to the attachment circuits is out of 215 the scope of this specification, and is instead defined in 216 [I-D.ietf-pwe3-oam-msg-map]. 218 3.2. BFD Encapsulation 220 The VCCV message comprises a BFD Control packet [I-D.ietf-bfd-base] 221 encapsulated as specified by the CV Type. There are two ways in 222 which a BFD connectivity verification packet may be encapsulated over 223 the VCCV control channel. This document defines four BFD CV Types 224 (see Section 3), which can be grouped into two pairs of BFD CV Types 225 from an encapsulation point of view. See Table 1 in Section 3 that 226 summarizes the BFD CV Types. 228 o IP/UDP BFD Encapsulation (BFD with IP/UDP Headers) 230 In the first method, the VCCV encapsulation of BFD includes the 231 IP/UDP headers as defined in Section 4 of 232 [I-D.ietf-bfd-v4v6-1hop]. BFD Control packets are therefore 233 transmitted in UDP with destination port 3784 and source port 234 within the rage 49152 through 65535. The IP Protocol Number and 235 UDP Port numbers discriminate among the possible VCCV payloads 236 (i.e., differentiate among ICMP Ping and LSP Ping defined in 237 [RFC5085] and BFD). 239 The IP version (IPv4 or IPv6) MUST match the IP version used for 240 signaling for dynamically established pseudowires, or MUST be 241 configured for statically provisioned pseudowires. The source IP 242 address is an address of the sender. The destination IP address 243 is a (randomly chosen) IPv4 address from the range 127/8 or IPv6 244 address from the range 0:0:0:0:0:FFFF:127.0.0.0/104. The 245 rationale is explained in Section 2.1 of [RFC4379]. The Time to 246 Live/Hop Limit and Generalized TTL Security Mechanism (GTSM) 247 procedures from Section 5 of [I-D.ietf-bfd-v4v6-1hop] apply to 248 this encapsulation, and hence the TTL/Hop Limit is set to 255. 250 In this encapsulation, the BFD CV Type used in signaling (if used) 251 is either 0x04 or 0x08. 253 o PW-ACH BFD Encapsulation (BFD without IP/UDP Headers) 255 In the second method, a BFD Control packet (format defined in 256 Section 4 of [I-D.ietf-bfd-base]) is encapsulated directly in the 257 VCCV control channel (see Sections 6 and 8 of 258 [I-D.ietf-bfd-generic]) and the IP/UDP headers are omitted from 259 the BFD encapsulation. Therefore, to utilize this encapsulation, 260 a pseudowire MUST use the PW Associated Channel Header (PW-ACH) 261 Control Word format for its Control Word (CW) or L2-Specific 262 Sublayer (L2SS, used in L2TPv3). 264 In this encapsulation, a "raw" BFD Control packet (i.e., a BFD 265 Control packet as defined in Section 4.1 of [I-D.ietf-bfd-base] 266 without IP/UDP Headers) follows directly the PW-ACH. The PW-ACH 267 Channel Type indicates that the Associated Channel carries "raw" 268 BFD. The PW Associated Channel (PWAC) is defined in Section 5 of 269 [RFC4385], and its Channel Type field is used to discriminate the 270 VCCV payload types. 272 The usage of the PW-ACH on different VCCV CC Types is specified 273 for CC Type 1, Type 2 and Type 3 respectively in Sections 5.1.1, 274 5.1.2 and 5.1.3 of [RFC5085], and in all cases requires the use of 275 a CW (see Section 7 of [RFC4385]). When VCCV carries PW-ACH- 276 encapsulated BFD (i.e., "raw" BFD), the PW-ACH (Pseudowire CW's or 277 L2SS') Channel Type MUST be set to 0x0007 to indicate "BFD 278 Control, PW-ACH-encapsulated" (i.e., BFD Without IP/UDP Headers, 279 see Section 5.2). This is to allow the identification of the 280 encased BFD payload when demultiplexing the VCCV control channel. 282 In this encapsulation, the BFD CV Type employed in signaling (if 283 used) is either 0x10 or 0x20. 285 In summary, for the IP/UDP encapsulation of BFD (BFD with IP/UDP 286 headers), if a PW Associated Channel Header is used, the Channel Type 287 MUST indicate either IPv4 (0x0021) or IPv6 (0x0057). For the PW-ACH 288 encapsulation of BFD (BFD without IP/UDP headers), the PW Associated 289 Channel Header MUST be used and the Channel Type MUST indicate BFD 290 Control packet (0x0007). 292 3.3. CV Types for BFD 294 The CV Type is defined as a bitmask field used to indicate the 295 specific CV Type or Types (i.e., none, one or more) of VCCV packets 296 that may be sent on the VCCV control channel. The CV Types shown in 297 the table below augment those already defined in [RFC5085]. Their 298 values shown in parenthesis represent the numerical value 299 corresponding to the actual bit being set in the CV Type bitfield. 301 BFD CV Types: 303 The defined values for the different BFD CV Types for MPLS and 304 L2TPv3 PWs are: 306 Bit (Value) Description 307 ============ ==================================================== 308 Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only 309 Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and 310 AC/PW Fault Status Signaling 311 Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only 312 Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and 313 AC/PW Fault Status Signaling 315 It should be noted that four BFD CV Types have been defined by 316 combining two types of encapsulation with two types of functionality, 317 see Table 1 in in Section 3. 319 Given the bidirectional nature of BFD, before selecting a given BFD 320 CV Type capability to be used in dynamically established pseudowires, 321 there MUST be common CV Types in the VCCV capability advertised and 322 received. That is, only BFD CV Types that were both advertised and 323 received are available to be selected. Additionally, only one BFD CV 324 Type can be used (selecting a BFD CV Type excludes all the remaining 325 BFD CV Types). 327 The following list enumerates rules, restrictions and clarifications 328 on the usage of BFD CV Types: 330 1. BFD CV Types used for fault detection and status signaling (i.e., 331 CV Types 0x08 and 0x20) SHOULD NOT be used when a control 332 protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available 333 that can signal the AC/PW status to the remote endpoint of the 334 PW. More details can be found in [I-D.ietf-pwe3-oam-msg-map]. 336 2. BFD CV Types used for fault detection only (i.e., CV Types 0x04 337 and 0x10) can be used whether a protocol that can signal AC/PW 338 status is available or not. This includes both statically 339 provisioned and dynamically signaled pseudowires. 341 2.1. In this case, BFD is used exclusively to detect faults on 342 the PW; if it is desired to convey AC/PW fault status, some 343 means other than BFD are to be used. Examples include 344 using LDP status messages when using MPLS as a transport 345 (see Section 5.4 of [RFC4447]), and the Circuit Status AVP 346 in an L2TPv3 SLI message for L2TPv3 (see Section 5.4.5 of 347 [RFC3931]). 349 3. Pseudowires that do not use a CW or L2SS using the PW Associated 350 Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., 351 PW-ACH encapsulation of BFD, without IP/UDP headers). 353 3.1. PWs that use a PW-ACH include CC Type 1 (for both MPLS and 354 L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]), 355 and MPLS CC Types 2 and 3 when using a Control Word (as 356 specified in Sections 5.1.2 and 5.1.3 of [RFC5085]). This 357 restriction stems from the fact that the encapsulation uses 358 the Channel Type in the PW-ACH. 360 3.2. PWs that do not use a PW-ACH can use the VCCV BFD 361 encapsulation with IP/UDP headers, as the only VCCV BFD 362 encapsulation supported. Using the IP/UDP encapsulated BFD 363 CV Types allows for the concurrent use of other VCCV CV 364 Types that uses an encapsulation with IP headers (e.g., 365 ICMP Ping or LSP Ping defined in [RFC5085]). 367 4. Only a single BFD CV Type can be selected and used. All BFD CV 368 Types are mutually exclusive. After selecting a BFD CV Type, a 369 node MUST NOT use any of the other three BFD CV Types. 371 5. Once a PE has chosen a single BFD CV Type to use, it MUST 372 continue using it until such time as the PW is re-signaled. In 373 order to change the negotiated and selected BFD CV Type, the PW 374 must be torn-down and re-established. 376 4. Capability Selection 378 The precedence rules for selection of various CC and CV Types is 379 clearly outlined in Section 7 of [RFC5085]. This section augments 380 these rules when the BFD CV Types defined herein are supported. The 381 selection of a specific BFD CV Type to use out of the four available 382 CV Types defined is tied to multiple factors, as described in 383 Section 3.3. Given that BFD is bidirectional in nature, only CV 384 Types that are both received and sent in VCCV capability signaling 385 advertisement can be selected. 387 When multiple BFD CV Types are advertised, and after applying the 388 rules in Section 3.3, the set that both ends of the pseudowire have 389 in common is determined. If the two ends have more than one BFD CV 390 Type in common, the following list of BFD CV Types is considered in 391 the order lowest list number CV Type to highest list number CV Type, 392 and the CV Type with the lowest list number is used: 394 1. 0x20 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW 395 Fault Detection and AC/PW Fault Status Signaling 397 2. 0x10 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW 398 Fault Detection only 400 3. 0x08 - BFD IP/UDP-encapsulated, for PW Fault Detection and AC/PW 401 Fault Status Signaling 403 4. 0x04 - BFD IP/UDP-encapsulated, for PW Fault Detection only 405 This precedence order prioritizes superset of functionality and 406 simplicity of encapsulation. 408 5. IANA Considerations 410 5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV 412 The VCCV Interface Parameters Sub-TLV codepoint is defined in 413 [RFC4446], and the VCCV CV Types registry is defined in [RFC5085]. 414 This section lists the new BFD CV Types. 416 IANA is requested to augment the "VCCV Connectivity Verification 417 Types" registry in the Pseudo Wires Name Spaces, reachable from 418 [IANA.pwe3-parameters]. These are bitfield values. CV Type values 419 0x04 0x08, 0x10 and 0x20 are specified in Section 3 of this document. 421 MPLS Connectivity Verification (CV) Types: 423 Bit (Value) Description 424 ============ ==================================================== 425 Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only 426 Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and 427 AC/PW Fault Status Signaling 428 Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only 429 Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and 430 AC/PW Fault Status Signaling 432 5.2. PW Associated Channel Type 434 The PW Associated Channel Types used by VCCV rely on previously 435 allocated numbers from the Pseudowire Associated Channel Types 436 Registry [RFC4385] in the Pseudo Wires Name Spaces reachable from 437 [IANA.pwe3-parameters]. 439 IANA is requested to reserve a new Pseudowire Associated Channel Type 440 value as follows: 442 Value (in hex) Protocol Name Reference 443 -------------- --------------------------------- --------- 445 0x0007 BFD Control, PW-ACH encapsulation [This document] 446 (without IP/UDP Headers) 448 5.3. L2TPv3 CV Types for the VCCV Capability AVP 450 This section lists the new BFD CV Types to be added to the existing 451 "VCCV Capability AVP" registry in the L2TP name spaces. The Layer 452 Two Tunneling Protocol "L2TP" Name Spaces are reachable from 453 [IANA.l2tp-parameters]. 455 IANA is requested to reserve the following L2TPv3 Connectivity 456 Verification (CV) Types in the VCCV Capability AVP Values registry. 458 VCCV Capability AVP (Attribute Type AVP-TBD) Values 459 --------------------------------------------------- 461 L2TPv3 Connectivity Verification (CV) Types: 463 Bit (Value) Description 464 ============ ==================================================== 465 Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only 466 Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and 467 AC/PW Fault Status Signaling 468 Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only 469 Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and 470 AC/PW Fault Status Signaling 472 6. Congestion Considerations 474 The congestion considerations that apply to [RFC5085] apply to this 475 mode of operation as well. There are no additional congestion 476 considerations. 478 7. Security Considerations 480 Routers that implement the additional CV Types defined herein are 481 subject to the same security considerations as defined in [RFC5085], 482 [I-D.ietf-bfd-base], and [I-D.ietf-bfd-v4v6-1hop]. This 483 specification does not raise any additional security issues beyond 484 these. The IP/UDP-encapsulated BFD makes use of the TTL/Hop Limit 485 procedures described in Section 5 of [I-D.ietf-bfd-v4v6-1hop], 486 including the use of the Generalized TTL Security Mechanism (GTSM) as 487 a security mechanism. 489 8. Acknowledgements 491 This work forks from a previous revision of the PWE3 WG document that 492 resulted in [RFC5085], to which a number of people contributed, 493 including Rahul Aggarwal, Peter B. Busschbach, Yuichi Ikejiri, Kenji 494 Kumaki, Luca Martini, Monique Morrow, George Swallow, and others. 496 Mustapha Aissaoui, Sam Aldrin, Stewart Bryant, Peter B. Busschbach, 497 Annamaria Fulignoli, Vishwas Manral, Luca Martini, Dave McDysan, Ben 498 Niven-Jenkins, Pankil Shah, Yaakov Stein, and George Swallow provided 499 useful feedback and valuable comments and suggestions improving newer 500 versions of this document. 502 9. References 504 9.1. Normative References 506 [I-D.ietf-bfd-base] 507 Katz, D. and D. Ward, "Bidirectional Forwarding 508 Detection", draft-ietf-bfd-base-09 (work in progress), 509 February 2009. 511 [I-D.ietf-bfd-generic] 512 Katz, D. and D. Ward, "Generic Application of BFD", 513 draft-ietf-bfd-generic-05 (work in progress), 514 February 2009. 516 [I-D.ietf-bfd-v4v6-1hop] 517 Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single 518 Hop)", draft-ietf-bfd-v4v6-1hop-09 (work in progress), 519 February 2009. 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 525 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 526 Use over an MPLS PSN", RFC 4385, February 2006. 528 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 529 Connectivity Verification (VCCV): A Control Channel for 530 Pseudowires", RFC 5085, December 2007. 532 9.2. Informative References 534 [I-D.ietf-pwe3-oam-msg-map] 535 Martini, L. and M. Morrow, "Pseudo Wire (PW) OAM Message 536 Mapping", draft-ietf-pwe3-oam-msg-map-10 (work in 537 progress), April 2009. 539 [IANA.l2tp-parameters] 540 Internet Assigned Numbers Authority, "Layer Two Tunneling 541 Protocol "L2TP"", May 2009, 542 . 544 [IANA.pwe3-parameters] 545 Internet Assigned Numbers Authority, "Pseudowire Name 546 Spaces (PWE3)", April 2009, 547 . 549 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 550 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 552 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 553 Label Switched (MPLS) Data Plane Failures", RFC 4379, 554 February 2006. 556 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 557 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 559 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 560 Heron, "Pseudowire Setup and Maintenance Using the Label 561 Distribution Protocol (LDP)", RFC 4447, April 2006. 563 Authors' Addresses 565 Thomas D. Nadeau (editor) 566 BT 567 BT Centre 568 81 Newgate Street 569 London, EC1A 7AJ 570 United Kingdom 572 Email: tom.nadeau@bt.com 574 Carlos Pignataro (editor) 575 Cisco Systems, Inc. 576 7200 Kit Creek Road 577 PO Box 14987 578 Research Triangle Park, NC 27709 579 USA 581 Email: cpignata@cisco.com