idnits 2.17.1 draft-ietf-pwe3-vccv-bfd-05.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 (June 2, 2009) is 5442 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: December 4, 2009 Cisco Systems, Inc. 6 June 2, 2009 8 Bidirectional Forwarding Detection (BFD) for 9 the Pseudowire Virtual Circuit Connectivity Verification (VCCV) 10 draft-ietf-pwe3-vccv-bfd-05 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 December 4, 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 . . . . . . . . . . . . . . . . . . . . . 9 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]. The term CV (Connectivity 104 Verification) is used in the same context as [RFC5085]. Note that 105 ongoing work in MPLS-TP is addressing requirements for CV in 106 transport applications of MPLS (see the PDF format version of 107 [RFC5317]). 109 2. Introduction 111 This document describes new Connectivity Verification (CV) types 112 using Bidirectional Forwarding Detection (BFD) with Virtual Circuit 113 Connectivity Verification (VCCV). VCCV [RFC5085] provides a control 114 channel that is associated with a Pseudowire (PW), as well as the 115 corresponding operations and management functions such as 116 connectivity/fault verification to be used over that control channel. 118 BFD [I-D.ietf-bfd-base] is used over the VCCV control channel 119 primarily as a pseudowire fault detection mechanism, for detecting 120 dataplane failures. Some BFD CV Types can additionally carry fault 121 status between the endpoints of the pseudowire. Furthermore, this 122 information can then be translated into the native OAM status codes 123 used by the native access technologies, such as ATM, Frame-Relay or 124 Ethernet. The specific details of such status interworking are out 125 of the scope of this document, and are only noted here to illustrate 126 the utility of BFD over VCCV for such purposes. Those details can be 127 found in [I-D.ietf-pwe3-oam-msg-map]. 129 The new BFD CV Types are PW Demultiplexer-agnostic, and hence 130 applicable for both MPLS and L2TPv3 Pseudowire Demultiplexers. This 131 document concerns itself with the BFD VCCV operation over Single- 132 Segment Pseudowires (SS-PW). This specification describes procedures 133 only for BFD asynchronous mode. 135 3. Bidirectional Forwarding Detection Connectivity Verification 137 VCCV can support several Connectivity Verification (CV) types. This 138 section defines new CV Types for use when BFD is used as the VCCV 139 payload. 141 Four CV Types are defined for BFD. Table 1 summarizes the BFD CV 142 Types, grouping them by encapsulation (i.e., with vs. without IP/UDP 143 headers) and by functionality (i.e., fault detection only vs. fault 144 detection and status signaling). 146 +----------------------------+--------------+-----------------------+ 147 | | Fault | Fault Detection and | 148 | | Detection | Status Signaling | 149 | | Only | | 150 +----------------------------+--------------+-----------------------+ 151 | BFD, IP/UDP encapsulation | 0x04 | 0x08 | 152 | (with IP/UDP Headers) | | | 153 | | | | 154 | BFD, PW-ACH encapsulation | 0x10 | 0x20 | 155 | (without IP/UDP Headers) | | | 156 +----------------------------+--------------+-----------------------+ 158 Table 1: Bitmask Values for BFD CV Types 160 3.1. BFD CV Type Operation 162 When heart-beat indication is necessary for one or more PWs, the 163 Bidirectional Forwarding Detection (BFD) [I-D.ietf-bfd-base] provides 164 a means of continuous monitoring of the PW data path and, in some 165 operational modes, propagation of PW receive and transmit defect 166 state indications. 168 In order to use BFD, both ends of the PW connection need to agree on 169 the BFD CV Type to use: 171 For statically provisioned pseudowires, both ends need to be 172 statically configured to use the same BFD CV Type (in addition to 173 be statically configured for VCCV with the same CC Type). 175 For dynamically established pseudowires, both ends of the PW must 176 have signaled the existence of a control channel and the ability 177 to run BFD on it (see Section 3.3 and Section 4). 179 Once a node has selected a valid BFD CV Type to use (either 180 statically provisioned or selected dynamically after the node has 181 both signaled and received signaling from its peer of these 182 capabilities), it begins sending BFD control packets: 184 o The BFD control packets are sent on the VCCV control channel. The 185 use of the VCCV control channel provides the context required to 186 bind and bootstrap the BFD session, since discriminator values are 187 not exchanged; the pseudowire demultiplexer field (e.g., MPLS PW 188 Label or L2TPv3 Session ID) provides the context to demultiplex 189 the first BFD control packet, and thus single-hop BFD 190 initialization procedures are followed (see Section 3 of 191 [I-D.ietf-bfd-v4v6-1hop] and Section 6 of [I-D.ietf-bfd-generic]). 193 o A single BFD session exists per-pseudowire. Both PW endpoints 194 take the Active role sending initial BFD Control packets with a 195 "Your Discriminator" field of zero, and BFD Control packets 196 received with a "Your Discriminator" field of zero are associated 197 to the BFD session bound to the PW. 199 o BFD MUST be run in asynchronous mode (see [I-D.ietf-bfd-base]). 201 The operation of BFD VCCV for PWs is therefore symmetrical. Both 202 endpoints of the bidirectional pseudowire MUST send BFD messages on 203 the VCCV control channel. 205 The details of the BFD state machine are as per Section 6.2 of 206 [I-D.ietf-bfd-base]. The following scenario exemplifies the 207 operation: When the downstream PE (D-PE) does not receive BFD control 208 messages from its upstream peer PE (U-PE) during a certain number of 209 transmission intervals (a number provisioned by the operator as 210 "Detect Mult" or detection time multiplier [I-D.ietf-bfd-base]), D-PE 211 declares that the PW in its receive direction is down. In other 212 words, D-PE enters the "PW receive defect" state for this PW. After 213 this calculated Detection Time (see Section 6.8.4 of 214 [I-D.ietf-bfd-base]), D-PE declares the session Down, and signals 215 this to the remote end via the State (Sta) with Diagnostic code 1 216 (Control Detection Time Expired). In turn, U-PE declares the PW is 217 down in its transmit direction, setting the State to Down with 218 Diagnostic code 3 (Neighbor signaled session down) in its control 219 messages to D-PE. U-PE enters the "PW transmit defect" state for 220 this PW. How it further processes this error condition, and 221 potentially conveys this status to the attachment circuits is out of 222 the scope of this specification, and is instead defined in 223 [I-D.ietf-pwe3-oam-msg-map]. 225 3.2. BFD Encapsulation 227 The VCCV message comprises a BFD Control packet [I-D.ietf-bfd-base] 228 encapsulated as specified by the CV Type. There are two ways in 229 which a BFD connectivity verification packet may be encapsulated over 230 the VCCV control channel. This document defines four BFD CV Types 231 (see Section 3), which can be grouped into two pairs of BFD CV Types 232 from an encapsulation point of view. See Table 1 in Section 3 that 233 summarizes the BFD CV Types. 235 o IP/UDP BFD Encapsulation (BFD with IP/UDP Headers) 236 In the first method, the VCCV encapsulation of BFD includes the 237 IP/UDP headers as defined in Section 4 of 238 [I-D.ietf-bfd-v4v6-1hop]. BFD Control packets are therefore 239 transmitted in UDP with destination port 3784 and source port 240 within the rage 49152 through 65535. The IP Protocol Number and 241 UDP Port numbers discriminate among the possible VCCV payloads 242 (i.e., differentiate among ICMP Ping and LSP Ping defined in 243 [RFC5085] and BFD). 245 The IP version (IPv4 or IPv6) MUST match the IP version used for 246 signaling for dynamically established pseudowires, or MUST be 247 configured for statically provisioned pseudowires. The source IP 248 address is an address of the sender. The destination IP address 249 is a (randomly chosen) IPv4 address from the range 127/8 or IPv6 250 address from the range 0:0:0:0:0:FFFF:127.0.0.0/104. The 251 rationale is explained in Section 2.1 of [RFC4379]. The Time to 252 Live/Hop Limit and Generalized TTL Security Mechanism (GTSM) 253 procedures from Section 5 of [I-D.ietf-bfd-v4v6-1hop] apply to 254 this encapsulation, and hence the TTL/Hop Limit is set to 255. 256 If the PW is establised by signaling, then the BFD CV Type used 257 for this encapsulation is either 0x04 or 0x08. 259 o PW-ACH BFD Encapsulation (BFD without IP/UDP Headers) 261 In the second method, a BFD Control packet (format defined in 262 Section 4 of [I-D.ietf-bfd-base]) is encapsulated directly in the 263 VCCV control channel (see Sections 6 and 8 of 264 [I-D.ietf-bfd-generic]) and the IP/UDP headers are omitted from 265 the BFD encapsulation. Therefore, to utilize this encapsulation, 266 a pseudowire MUST use the PW Associated Channel Header (PW-ACH) 267 Control Word format (see [I-D.ietf-mpls-tp-gach-gal]) for its 268 Control Word (CW) or L2-Specific Sublayer (L2SS, used in L2TPv3). 270 In this encapsulation, a "raw" BFD Control packet (i.e., a BFD 271 Control packet as defined in Section 4.1 of [I-D.ietf-bfd-base] 272 without IP/UDP Headers) follows directly the PW-ACH. The PW-ACH 273 Channel Type indicates that the Associated Channel carries "raw" 274 BFD. The PW Associated Channel (PWAC) is defined in Section 5 of 275 [RFC4385], and its Channel Type field is used to discriminate the 276 VCCV payload types. 278 The usage of the PW-ACH on different VCCV CC Types is specified 279 for CC Type 1, Type 2 and Type 3 respectively in Sections 5.1.1, 280 5.1.2 and 5.1.3 of [RFC5085], and in all cases requires the use of 281 a CW (see Section 7 of [RFC4385]). When VCCV carries PW-ACH- 282 encapsulated BFD (i.e., "raw" BFD), the PW-ACH (Pseudowire CW's or 283 L2SS') Channel Type MUST be set to 0x0007 to indicate "BFD 284 Control, PW-ACH-encapsulated" (i.e., BFD Without IP/UDP Headers, 285 see Section 5.2). This is to allow the identification of the 286 encased BFD payload when demultiplexing the VCCV control channel. 288 If the PW is establised by signaling, then the BFD CV Type used 289 for this encapsulation is either 0x10 or 0x20. 291 In summary, for the IP/UDP encapsulation of BFD (BFD with IP/UDP 292 headers), if a PW Associated Channel Header is used, the Channel Type 293 MUST indicate either IPv4 (0x0021) or IPv6 (0x0057). For the PW-ACH 294 encapsulation of BFD (BFD without IP/UDP headers), the PW Associated 295 Channel Header MUST be used and the Channel Type MUST indicate BFD 296 Control packet (0x0007). 298 3.3. CV Types for BFD 300 The CV Type is defined as a bitmask field used to indicate the 301 specific CV Type or Types (i.e., none, one or more) of VCCV packets 302 that may be sent on the VCCV control channel. The CV Types shown in 303 the table below augment those already defined in [RFC5085]. Their 304 values shown in parenthesis represent the numerical value 305 corresponding to the actual bit being set in the CV Type bitfield. 307 BFD CV Types: 309 The defined values for the different BFD CV Types for MPLS and 310 L2TPv3 PWs are: 312 Bit (Value) Description 313 ============ ==================================================== 314 Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only 315 Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and 316 AC/PW Fault Status Signaling 317 Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only 318 Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and 319 AC/PW Fault Status Signaling 321 It should be noted that four BFD CV Types have been defined by 322 combining two types of encapsulation with two types of functionality, 323 see Table 1 in in Section 3. 325 Given the bidirectional nature of BFD, before selecting a given BFD 326 CV Type capability to be used in dynamically established pseudowires, 327 there MUST be common CV Types in the VCCV capability advertised and 328 received. That is, only BFD CV Types that were both advertised and 329 received are available to be selected. Additionally, only one BFD CV 330 Type can be used (selecting a BFD CV Type excludes all the remaining 331 BFD CV Types). 333 The following list enumerates rules, restrictions and clarifications 334 on the usage of BFD CV Types: 336 1. BFD CV Types used for fault detection and status signaling (i.e., 337 CV Types 0x08 and 0x20) SHOULD NOT be used when a control 338 protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available 339 that can signal the AC/PW status to the remote endpoint of the 340 PW. More details can be found in [I-D.ietf-pwe3-oam-msg-map]. 342 2. BFD CV Types used for fault detection only (i.e., CV Types 0x04 343 and 0x10) can be used whether a protocol that can signal AC/PW 344 status is available or not. This includes both statically 345 provisioned and dynamically signaled pseudowires. 347 2.1. In this case, BFD is used exclusively to detect faults on 348 the PW; if it is desired to convey AC/PW fault status, some 349 means other than BFD are to be used. Examples include 350 using LDP status messages when using MPLS as a transport 351 (see Section 5.4 of [RFC4447]), and the Circuit Status AVP 352 in an L2TPv3 SLI message for L2TPv3 (see Section 5.4.5 of 353 [RFC3931]). 355 3. Pseudowires that do not use a CW or L2SS using the PW Associated 356 Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., 357 PW-ACH encapsulation of BFD, without IP/UDP headers). 359 3.1. PWs that use a PW-ACH include CC Type 1 (for both MPLS and 360 L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]), 361 and MPLS CC Types 2 and 3 when using a Control Word (as 362 specified in Sections 5.1.2 and 5.1.3 of [RFC5085]). This 363 restriction stems from the fact that the encapsulation uses 364 the Channel Type in the PW-ACH. 366 3.2. PWs that do not use a PW-ACH can use the VCCV BFD 367 encapsulation with IP/UDP headers, as the only VCCV BFD 368 encapsulation supported. Using the IP/UDP encapsulated BFD 369 CV Types allows for the concurrent use of other VCCV CV 370 Types that uses an encapsulation with IP headers (e.g., 371 ICMP Ping or LSP Ping defined in [RFC5085]). 373 4. Only a single BFD CV Type can be selected and used. All BFD CV 374 Types are mutually exclusive. After selecting a BFD CV Type, a 375 node MUST NOT use any of the other three BFD CV Types. 377 5. Once a PE has chosen a single BFD CV Type to use, it MUST 378 continue using it until such time as the PW is re-signaled. In 379 order to change the negotiated and selected BFD CV Type, the PW 380 must be torn-down and re-established. 382 4. Capability Selection 384 The precedence rules for selection of various CC and CV Types is 385 clearly outlined in Section 7 of [RFC5085]. This section augments 386 these rules when the BFD CV Types defined herein are supported. The 387 selection of a specific BFD CV Type to use out of the four available 388 CV Types defined is tied to multiple factors, as described in 389 Section 3.3. Given that BFD is bidirectional in nature, only CV 390 Types that are both received and sent in VCCV capability signaling 391 advertisement can be selected. 393 When multiple BFD CV Types are advertised, and after applying the 394 rules in Section 3.3, the set that both ends of the pseudowire have 395 in common is determined. If the two ends have more than one BFD CV 396 Type in common, the following list of BFD CV Types is considered in 397 the order lowest list number CV Type to highest list number CV Type, 398 and the CV Type with the lowest list number is used: 400 1. 0x20 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW 401 Fault Detection and AC/PW Fault Status Signaling 403 2. 0x10 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW 404 Fault Detection only 406 3. 0x08 - BFD IP/UDP-encapsulated, for PW Fault Detection and AC/PW 407 Fault Status Signaling 409 4. 0x04 - BFD IP/UDP-encapsulated, for PW Fault Detection only 411 This precedence order prioritizes superset of functionality and 412 simplicity of encapsulation. 414 5. IANA Considerations 416 5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV 418 The VCCV Interface Parameters Sub-TLV codepoint is defined in 419 [RFC4446], and the VCCV CV Types registry is defined in [RFC5085]. 420 This section lists the new BFD CV Types. 422 IANA is requested to augment the "VCCV Connectivity Verification 423 Types" registry in the Pseudo Wires Name Spaces, reachable from 424 [IANA.pwe3-parameters]. These are bitfield values. CV Type values 425 0x04 0x08, 0x10 and 0x20 are specified in Section 3 of this document. 427 MPLS Connectivity Verification (CV) Types: 429 Bit (Value) Description 430 ============ ==================================================== 431 Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only 432 Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and 433 AC/PW Fault Status Signaling 434 Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only 435 Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and 436 AC/PW Fault Status Signaling 438 5.2. PW Associated Channel Type 440 The PW Associated Channel Types used by VCCV rely on previously 441 allocated numbers from the Pseudowire Associated Channel Types 442 Registry [RFC4385] in the Pseudo Wires Name Spaces reachable from 443 [IANA.pwe3-parameters]. 445 IANA is requested to reserve a new Pseudowire Associated Channel Type 446 value as follows: 448 Registry: 449 TLV 450 Value Description Follows Reference 451 ------ ---------------------------------- ------- --------------- 452 0x0007 BFD Control, PW-ACH encapsulation No [This document] 453 (without IP/UDP Headers) 455 5.3. L2TPv3 CV Types for the VCCV Capability AVP 457 This section lists the new BFD CV Types to be added to the existing 458 "VCCV Capability AVP" registry in the L2TP name spaces. The Layer 459 Two Tunneling Protocol "L2TP" Name Spaces are reachable from 460 [IANA.l2tp-parameters]. 462 IANA is requested to reserve the following L2TPv3 Connectivity 463 Verification (CV) Types in the VCCV Capability AVP Values registry. 465 VCCV Capability AVP (Attribute Type AVP-TBD) Values 466 --------------------------------------------------- 468 L2TPv3 Connectivity Verification (CV) Types: 470 Bit (Value) Description 471 ============ ==================================================== 472 Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only 473 Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and 474 AC/PW Fault Status Signaling 475 Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only 476 Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and 477 AC/PW Fault Status Signaling 479 6. Congestion Considerations 481 The congestion considerations that apply to [RFC5085] apply to this 482 mode of operation as well. There are no additional congestion 483 considerations. 485 7. Security Considerations 487 Routers that implement the additional CV Types defined herein are 488 subject to the same security considerations as defined in [RFC5085], 489 [I-D.ietf-bfd-base], and [I-D.ietf-bfd-v4v6-1hop]. This 490 specification does not raise any additional security issues beyond 491 these. The IP/UDP-encapsulated BFD makes use of the TTL/Hop Limit 492 procedures described in Section 5 of [I-D.ietf-bfd-v4v6-1hop], 493 including the use of the Generalized TTL Security Mechanism (GTSM) as 494 a security mechanism. 496 8. Acknowledgements 498 This work forks from a previous revision of the PWE3 WG document that 499 resulted in [RFC5085], to which a number of people contributed, 500 including Rahul Aggarwal, Peter B. Busschbach, Yuichi Ikejiri, Kenji 501 Kumaki, Luca Martini, Monique Morrow, George Swallow, and others. 503 Mustapha Aissaoui, Sam Aldrin, Stewart Bryant, Peter B. Busschbach, 504 Annamaria Fulignoli, Vishwas Manral, Luca Martini, Dave McDysan, Ben 505 Niven-Jenkins, Pankil Shah, Yaakov Stein, and George Swallow provided 506 useful feedback and valuable comments and suggestions improving newer 507 versions of this document. 509 9. References 511 9.1. Normative References 513 [I-D.ietf-bfd-base] 514 Katz, D. and D. Ward, "Bidirectional Forwarding 515 Detection", draft-ietf-bfd-base-09 (work in progress), 516 February 2009. 518 [I-D.ietf-bfd-generic] 519 Katz, D. and D. Ward, "Generic Application of BFD", 520 draft-ietf-bfd-generic-05 (work in progress), 521 February 2009. 523 [I-D.ietf-bfd-v4v6-1hop] 524 Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single 525 Hop)", draft-ietf-bfd-v4v6-1hop-09 (work in progress), 526 February 2009. 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997. 531 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 532 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 533 Use over an MPLS PSN", RFC 4385, February 2006. 535 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 536 Connectivity Verification (VCCV): A Control Channel for 537 Pseudowires", RFC 5085, December 2007. 539 9.2. Informative References 541 [I-D.ietf-mpls-tp-gach-gal] 542 Bocci, M., Vigoureux, M., Bryant, S., Swallow, G., Ward, 543 D., and R. Aggarwal, "MPLS Generic Associated Channel", 544 draft-ietf-mpls-tp-gach-gal-06 (work in progress), 545 May 2009. 547 [I-D.ietf-pwe3-oam-msg-map] 548 Martini, L. and M. Morrow, "Pseudo Wire (PW) OAM Message 549 Mapping", draft-ietf-pwe3-oam-msg-map-10 (work in 550 progress), April 2009. 552 [IANA.l2tp-parameters] 553 Internet Assigned Numbers Authority, "Layer Two Tunneling 554 Protocol "L2TP"", June 2009, 555 . 557 [IANA.pwe3-parameters] 558 Internet Assigned Numbers Authority, "Pseudowire Name 559 Spaces (PWE3)", May 2009, 560 . 562 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 563 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 565 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 566 Label Switched (MPLS) Data Plane Failures", RFC 4379, 567 February 2006. 569 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 570 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 572 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 573 Heron, "Pseudowire Setup and Maintenance Using the Label 574 Distribution Protocol (LDP)", RFC 4447, April 2006. 576 [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) 577 Report on MPLS Architectural Considerations for a 578 Transport Profile", RFC 5317, February 2009. 580 Authors' Addresses 582 Thomas D. Nadeau (editor) 583 BT 584 BT Centre 585 81 Newgate Street 586 London, EC1A 7AJ 587 United Kingdom 589 Email: tom.nadeau@bt.com 591 Carlos Pignataro (editor) 592 Cisco Systems, Inc. 593 7200 Kit Creek Road 594 PO Box 14987 595 Research Triangle Park, NC 27709 596 USA 598 Email: cpignata@cisco.com