idnits 2.17.1 draft-ietf-pwe3-vccv-bfd-07.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 (July 27, 2009) is 5379 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-11 -- 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: January 28, 2010 Cisco Systems, Inc. 6 July 27, 2009 8 Bidirectional Forwarding Detection (BFD) for 9 the Pseudowire Virtual Circuit Connectivity Verification (VCCV) 10 draft-ietf-pwe3-vccv-bfd-07 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 January 28, 2010. 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 Connectivity Verification (CV) types using 59 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 . . . . . . . . . . . . . . . . . . . 12 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 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 Connectivity Verification (CV) types using 108 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 o The BFD control packets are sent on the VCCV control channel. The 181 use of the VCCV control channel provides the context required to 182 bind and bootstrap the BFD session, since discriminator values are 183 not exchanged; the pseudowire demultiplexer field (e.g., MPLS PW 184 Label or L2TPv3 Session ID) provides the context to demultiplex 185 the first BFD control packet, and thus single-hop BFD 186 initialization procedures are followed (see Section 3 of 187 [I-D.ietf-bfd-v4v6-1hop] and Section 6 of [I-D.ietf-bfd-generic]). 189 o A single BFD session exists per-pseudowire. Both PW endpoints 190 take the Active role sending initial BFD Control packets with a 191 "Your Discriminator" field of zero, and BFD Control packets 192 received with a "Your Discriminator" field of zero are associated 193 to the BFD session bound to the PW. 195 o BFD MUST be run in asynchronous mode (see [I-D.ietf-bfd-base]). 197 The operation of BFD VCCV for PWs is therefore symmetrical. Both 198 endpoints of the bidirectional pseudowire MUST send BFD messages on 199 the VCCV control channel. 201 The details of the BFD state machine are as per Section 6.2 of 202 [I-D.ietf-bfd-base]. The following scenario exemplifies the 203 operation: When the downstream PE (D-PE) does not receive BFD control 204 messages from its upstream peer PE (U-PE) during a certain number of 205 transmission intervals (a number provisioned by the operator as 206 "Detect Mult" or detection time multiplier [I-D.ietf-bfd-base]), D-PE 207 declares that the PW in its receive direction is down. In other 208 words, D-PE enters the "PW receive defect" state for this PW. After 209 this calculated Detection Time (see Section 6.8.4 of 210 [I-D.ietf-bfd-base]), D-PE declares the session Down, and signals 211 this to the remote end via the State (Sta) with Diagnostic code 1 212 (Control Detection Time Expired). In turn, U-PE declares the PW is 213 down in its transmit direction, setting the State to Down with 214 Diagnostic code 3 (Neighbor signaled session down) in its control 215 messages to D-PE. U-PE enters the "PW transmit defect" state for 216 this PW. How it further processes this error condition, and 217 potentially conveys this status to the attachment circuits is out of 218 the scope of this specification, and is defined in 219 [I-D.ietf-pwe3-oam-msg-map]. 221 3.2. BFD Encapsulation 223 The VCCV message comprises a BFD Control packet [I-D.ietf-bfd-base] 224 encapsulated as specified by the CV Type. There are two ways in 225 which a BFD connectivity verification packet may be encapsulated over 226 the VCCV control channel. This document defines four BFD CV Types 227 (see Section 3), which can be grouped into two pairs of BFD CV Types 228 from an encapsulation point of view. See Table 1 in Section 3 that 229 summarizes the BFD CV Types. 231 o IP/UDP BFD Encapsulation (BFD with IP/UDP Headers) 233 In the first method, the VCCV encapsulation of BFD includes the 234 IP/UDP headers as defined in Section 4 of 235 [I-D.ietf-bfd-v4v6-1hop]. BFD Control packets are therefore 236 transmitted in UDP with destination port 3784 and source port 237 within the range 49152 through 65535. The IP Protocol Number and 238 UDP Port numbers discriminate among the possible VCCV payloads 239 (i.e., differentiate among ICMP Ping and LSP Ping defined in 240 [RFC5085] and BFD). 242 The IP version (IPv4 or IPv6) MUST match the IP version used for 243 signaling for dynamically established pseudowires, or MUST be 244 configured for statically provisioned pseudowires. The source IP 245 address is an address of the sender. The destination IP address 246 is a (randomly chosen) IPv4 address from the range 127/8 or IPv6 247 address from the range 0:0:0:0:0:FFFF:127.0.0.0/104. The 248 rationale is explained in Section 2.1 of [RFC4379]. The Time to 249 Live/Hop Limit and Generalized TTL Security Mechanism (GTSM) 250 procedures from Section 5 of [I-D.ietf-bfd-v4v6-1hop] apply to 251 this encapsulation, and hence the TTL/Hop Limit is set to 255. 253 If the PW is establised by signaling, then the BFD CV Type used 254 for this encapsulation is either 0x04 or 0x08. 256 o PW-ACH BFD Encapsulation (BFD without IP/UDP Headers) 258 In the second method, a BFD Control packet (format defined in 259 Section 4 of [I-D.ietf-bfd-base]) is encapsulated directly in the 260 VCCV control channel (see Sections 6 and 8 of 261 [I-D.ietf-bfd-generic]) and the IP/UDP headers are omitted from 262 the BFD encapsulation. Therefore, to utilize this encapsulation, 263 a pseudowire MUST use the PW Associated Channel Header (PW-ACH) 264 Control Word format (see [RFC5586]) for its Control Word (CW) or 265 L2-Specific Sublayer (L2SS, used in L2TPv3). 267 In this encapsulation, a "raw" BFD Control packet (i.e., a BFD 268 Control packet as defined in Section 4.1 of [I-D.ietf-bfd-base] 269 without IP/UDP Headers) follows directly the PW-ACH. The PW-ACH 270 Channel Type indicates that the Associated Channel carries "raw" 271 BFD. The PW Associated Channel (PWAC) is defined in Section 5 of 272 [RFC4385], and its Channel Type field is used to discriminate the 273 VCCV payload types. 275 The usage of the PW-ACH on different VCCV CC Types is specified 276 for CC Type 1, Type 2 and Type 3 respectively in Sections 5.1.1, 277 5.1.2 and 5.1.3 of [RFC5085], and in all cases requires the use of 278 a CW (see Section 7 of [RFC4385]). When VCCV carries PW-ACH- 279 encapsulated BFD (i.e., "raw" BFD), the PW-ACH (Pseudowire CW's or 280 L2SS') Channel Type MUST be set to 0x0007 to indicate "BFD 281 Control, PW-ACH-encapsulated" (i.e., BFD Without IP/UDP Headers, 282 see Section 5.2). This is to allow the identification of the 283 encased BFD payload when demultiplexing the VCCV control channel. 285 If the PW is establised by signaling, then the BFD CV Type used 286 for this encapsulation is either 0x10 or 0x20. 288 In summary, for the IP/UDP encapsulation of BFD (BFD with IP/UDP 289 headers), if a PW Associated Channel Header is used, the Channel Type 290 MUST indicate either IPv4 (0x0021) or IPv6 (0x0057). For the PW-ACH 291 encapsulation of BFD (BFD without IP/UDP headers), the PW Associated 292 Channel Header MUST be used and the Channel Type MUST indicate BFD 293 Control packet (0x0007). 295 3.3. CV Types for BFD 297 The CV Type is defined as a bitmask field used to indicate the 298 specific CV Type or Types (i.e., none, one or more) of VCCV packets 299 that may be sent on the VCCV control channel. The CV Types shown in 300 the table below augment those already defined in [RFC5085]. Their 301 values shown in parenthesis represent the numerical value 302 corresponding to the actual bit being set in the CV Type bitfield. 304 BFD CV Types: 306 The defined values for the different BFD CV Types for MPLS and 307 L2TPv3 PWs are: 309 Bit (Value) Description 310 ============ ==================================================== 311 Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only 312 Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and 313 AC/PW Fault Status Signaling 314 Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only 315 Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and 316 AC/PW Fault Status Signaling 318 It should be noted that four BFD CV Types have been defined by 319 combining two types of encapsulation with two types of functionality, 320 see Table 1 in Section 3. 322 Given the bidirectional nature of BFD, before selecting a given BFD 323 CV Type capability to be used in dynamically established pseudowires, 324 there MUST be common CV Types in the VCCV capability advertised and 325 received. That is, only BFD CV Types that were both advertised and 326 received are available to be selected. Additionally, only one BFD CV 327 Type can be used (selecting a BFD CV Type excludes all the remaining 328 BFD CV Types). 330 The following list enumerates rules, restrictions and clarifications 331 on the usage of BFD CV Types: 333 1. BFD CV Types used for fault detection and status signaling (i.e., 334 CV Types 0x08 and 0x20) SHOULD NOT be used when a control 335 protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available 336 that can signal the AC/PW status to the remote endpoint of the 337 PW. More details can be found in [I-D.ietf-pwe3-oam-msg-map]. 339 2. BFD CV Types used for fault detection only (i.e., CV Types 0x04 340 and 0x10) can be used whether a protocol that can signal AC/PW 341 status is available or not. This includes both statically 342 provisioned and dynamically signaled pseudowires. 344 2.1. In this case, BFD is used exclusively to detect faults on 345 the PW; if it is desired to convey AC/PW fault status, some 346 means other than BFD are to be used. Examples include 347 using LDP status messages when using MPLS as a transport 348 (see Section 5.4 of [RFC4447]), and the Circuit Status AVP 349 in an L2TPv3 SLI message for L2TPv3 (see Section 5.4.5 of 350 [RFC3931]). 352 3. Pseudowires that do not use a CW or L2SS using the PW Associated 353 Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., 354 PW-ACH encapsulation of BFD, without IP/UDP headers). 356 3.1. PWs that use a PW-ACH include CC Type 1 (for both MPLS and 357 L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]), 358 and MPLS CC Types 2 and 3 when using a Control Word (as 359 specified in Sections 5.1.2 and 5.1.3 of [RFC5085]). This 360 restriction stems from the fact that the encapsulation uses 361 the Channel Type in the PW-ACH. 363 3.2. PWs that do not use a PW-ACH can use the VCCV BFD 364 encapsulation with IP/UDP headers, as the only VCCV BFD 365 encapsulation supported. Using the IP/UDP encapsulated BFD 366 CV Types allows for the concurrent use of other VCCV CV 367 Types that uses an encapsulation with IP headers (e.g., 368 ICMP Ping or LSP Ping defined in [RFC5085]). 370 4. Only a single BFD CV Type can be selected and used. All BFD CV 371 Types are mutually exclusive. After selecting a BFD CV Type, a 372 node MUST NOT use any of the other three BFD CV Types. 374 5. Once a PE has chosen a single BFD CV Type to use, it MUST 375 continue using it until when the PW is re-signaled. In order to 376 change the negotiated and selected BFD CV Type, the PW must be 377 torn-down and re-established. 379 4. Capability Selection 381 The precedence rules for selection of various CC and CV Types is 382 clearly outlined in Section 7 of [RFC5085]. This section augments 383 these rules when the BFD CV Types defined herein are supported. The 384 selection of a specific BFD CV Type to use out of the four available 385 CV Types defined is tied to multiple factors, as described in 386 Section 3.3. Given that BFD is bidirectional in nature, only CV 387 Types that are both received and sent in VCCV capability signaling 388 advertisement can be selected. 390 When multiple BFD CV Types are advertised, and after applying the 391 rules in Section 3.3, the set that both ends of the pseudowire have 392 in common is determined. If the two ends have more than one BFD CV 393 Type in common, the following list of BFD CV Types is considered in 394 the order of the lowest list number CV Type to the highest list 395 number CV Type, and the CV Type with the lowest list number is used: 397 1. 0x20 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW 398 Fault Detection and AC/PW Fault Status Signaling 400 2. 0x10 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW 401 Fault Detection only 403 3. 0x08 - BFD IP/UDP-encapsulated, for PW Fault Detection and AC/PW 404 Fault Status Signaling 406 4. 0x04 - BFD IP/UDP-encapsulated, for PW Fault Detection only 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 Registry: 443 TLV 444 Value Description Follows Reference 445 ------ ---------------------------------- ------- --------------- 446 0x0007 BFD Control, PW-ACH encapsulation No [This document] 447 (without IP/UDP Headers) 449 5.3. L2TPv3 CV Types for the VCCV Capability AVP 451 This section lists the new BFD CV Types to be added to the existing 452 "VCCV Capability AVP" registry in the L2TP name spaces. The Layer 453 Two Tunneling Protocol "L2TP" Name Spaces are reachable from 454 [IANA.l2tp-parameters]. 456 IANA is requested to reserve the following L2TPv3 Connectivity 457 Verification (CV) Types in the VCCV Capability AVP Values registry. 459 VCCV Capability AVP (Attribute Type AVP-TBD) Values 460 --------------------------------------------------- 462 L2TPv3 Connectivity Verification (CV) Types: 464 Bit (Value) Description 465 ============ ==================================================== 466 Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only 467 Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and 468 AC/PW Fault Status Signaling 469 Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only 470 Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and 471 AC/PW Fault Status Signaling 473 6. Congestion Considerations 475 The congestion considerations that apply to [RFC5085] apply to this 476 mode of operation as well. This section describes explicitly how 477 they apply. 479 BFD as a VCCV application is required to provide details on 480 congestion and bandwidth considerations. BFD provides with a desired 481 minimum transmit interval, a required minimum receive interval, 482 negotiates the transmission interval using these configurable fields, 483 and has a packet of fixed size (setting the transmission rate). 484 Therefore, it results in a configuration limited bandwidth 485 utilization. As stated in [RFC5085], this is sufficient protection 486 against congestion as long as BFD's configured maximum bit-rate is 487 minimal compared to the bit-rate of the pseudowire the VCCV channel 488 is associated with. If the pseudowire bit-rate can't be guaranteed 489 to be minimal, like potentially for highly variable bit-rate and/or 490 congestion responsive pseudowires, BFD will be required to operate 491 using an adaptive congestion control mechanism (for example including 492 a throttled transmission rate on "congestion detected" situations, 493 and a slow-start after shutdown due to congestion and until basic 494 connectivity is verified). 496 Since the bandwidth utilized by BFD is configuration-limited, the 497 VCCV channel MUST NOT be rate limited below this maximum configurable 498 bandwidth or BFD will not operate correctly. The VCCV channel could 499 provide rate-limiting above the maximum BFD rate, to protect from a 500 mis-behaving BFD application, so that it does not conflict and can 501 coexist. Additionally, the VCCV channel SHOULD NOT use any 502 additional congestion control loop that would interfere or negatively 503 interact with that of BFD. There are no additional congestion 504 considerations. 506 7. Security Considerations 508 Routers that implement the additional CV Types defined herein are 509 subject to the same security considerations as defined in [RFC5085], 510 [I-D.ietf-bfd-base], and [I-D.ietf-bfd-v4v6-1hop]. This 511 specification does not raise any additional security issues beyond 512 these. The IP/UDP-encapsulated BFD makes use of the TTL/Hop Limit 513 procedures described in Section 5 of [I-D.ietf-bfd-v4v6-1hop], 514 including the use of the Generalized TTL Security Mechanism (GTSM) as 515 a security mechanism. 517 8. Acknowledgements 519 This work forks from a previous revision of the PWE3 WG document that 520 resulted in [RFC5085], to which a number of people contributed, 521 including Rahul Aggarwal, Peter B. Busschbach, Yuichi Ikejiri, Kenji 522 Kumaki, Luca Martini, Monique Morrow, George Swallow, and others. 524 Mustapha Aissaoui, Sam Aldrin, Stewart Bryant, Peter B. Busschbach, 525 Annamaria Fulignoli, Vishwas Manral, Luca Martini, Dave McDysan, Ben 526 Niven-Jenkins, Pankil Shah, Yaakov Stein, and George Swallow provided 527 useful feedback and valuable comments and suggestions improving newer 528 versions of this document. 530 9. References 532 9.1. Normative References 534 [I-D.ietf-bfd-base] 535 Katz, D. and D. Ward, "Bidirectional Forwarding 536 Detection", draft-ietf-bfd-base-09 (work in progress), 537 February 2009. 539 [I-D.ietf-bfd-generic] 540 Katz, D. and D. Ward, "Generic Application of BFD", 541 draft-ietf-bfd-generic-05 (work in progress), 542 February 2009. 544 [I-D.ietf-bfd-v4v6-1hop] 545 Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single 546 Hop)", draft-ietf-bfd-v4v6-1hop-09 (work in progress), 547 February 2009. 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, March 1997. 552 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 553 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 554 Use over an MPLS PSN", RFC 4385, February 2006. 556 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 557 Connectivity Verification (VCCV): A Control Channel for 558 Pseudowires", RFC 5085, December 2007. 560 9.2. Informative References 562 [I-D.ietf-pwe3-oam-msg-map] 563 Martini, L., Nadeau, T., Aissaoui, M., Allan, D., and Y. 564 Stein, "Pseudo Wire (PW) OAM Message Mapping", 565 draft-ietf-pwe3-oam-msg-map-11 (work in progress), 566 June 2009. 568 [IANA.l2tp-parameters] 569 Internet Assigned Numbers Authority, "Layer Two Tunneling 570 Protocol "L2TP"", July 2009, 571 . 573 [IANA.pwe3-parameters] 574 Internet Assigned Numbers Authority, "Pseudowire Name 575 Spaces (PWE3)", June 2009, 576 . 578 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 579 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 581 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 582 Label Switched (MPLS) Data Plane Failures", RFC 4379, 583 February 2006. 585 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 586 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 588 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 589 Heron, "Pseudowire Setup and Maintenance Using the Label 590 Distribution Protocol (LDP)", RFC 4447, April 2006. 592 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 593 Associated Channel", RFC 5586, June 2009. 595 Authors' Addresses 597 Thomas D. Nadeau (editor) 598 BT 599 BT Centre 600 81 Newgate Street 601 London, EC1A 7AJ 602 United Kingdom 604 Email: tom.nadeau@bt.com 606 Carlos Pignataro (editor) 607 Cisco Systems, Inc. 608 7200 Kit Creek Road 609 PO Box 14987 610 Research Triangle Park, NC 27709 611 USA 613 Email: cpignata@cisco.com