idnits 2.17.1 draft-ietf-pwe3-vccv-bfd-03.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 (February 18, 2009) is 5544 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-08 -- 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: August 22, 2009 Cisco Systems, Inc. 6 February 18, 2009 8 Bidirectional Forwarding Detection (BFD) for 9 the Pseudowire Virtual Circuit Connectivity Verification (VCCV) 10 draft-ietf-pwe3-vccv-bfd-03 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. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 22, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 This document may contain material from IETF Documents or IETF 47 Contributions published or made publicly available before November 48 10, 2008. The person(s) controlling the copyright in some of this 49 material may not have granted the IETF Trust the right to allow 50 modifications of such material outside the IETF Standards Process. 51 Without obtaining an adequate license from the person(s) controlling 52 the copyright in such materials, this document may not be modified 53 outside the IETF Standards Process, and derivative works of it may 54 not be created outside the IETF Standards Process, except to format 55 it for publication as an RFC or to translate it into languages other 56 than English. 58 Abstract 60 This document describes new Connectivity Verification (CV) types 61 using Bidirectional Forwarding Detection (BFD) with Virtual Circuit 62 Connectivity Verification (VCCV). VCCV provides a control channel 63 that is associated with a Pseudowire (PW), as well as the 64 corresponding operations and management functions such as 65 connectivity verification to be used over that control channel. 67 Table of Contents 69 1. Specification of Requirements . . . . . . . . . . . . . . . . 4 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Bidirectional Forwarding Detection Connectivity 74 Verification . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3.1. BFD CV Type Operation . . . . . . . . . . . . . . . . . . 5 76 3.2. BFD Encapsulation . . . . . . . . . . . . . . . . . . . . 6 77 3.3. CV Types for BFD . . . . . . . . . . . . . . . . . . . . . 8 79 4. Capability Selection . . . . . . . . . . . . . . . . . . . . . 9 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV . 10 83 5.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 10 84 5.3. L2TPv3 CV Types for the VCCV Capability AVP . . . . . . . 11 86 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 11 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 98 1. Specification of Requirements 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 The reader is expected to be familiar with the terminology and 105 abbreviations defined in [RFC5085]. 107 2. Introduction 109 This document describes new Connectivity Verification (CV) types 110 using Bidirectional Forwarding Detection (BFD) with Virtual Circuit 111 Connectivity Verification (VCCV). VCCV [RFC5085] provides a control 112 channel that is associated with a Pseudowire (PW), as well as the 113 corresponding operations and management functions such as 114 connectivity/fault verification to be used over that control channel. 116 BFD [I-D.ietf-bfd-base] is used over the VCCV control channel 117 primarily as a pseudowire fault detection mechanism, for detecting 118 dataplane failures. Some BFD CV Types can additionally carry fault 119 status between the endpoints of the pseudowire. Furthermore, this 120 information can then be translated into the native OAM status codes 121 used by the native access technologies, such as ATM, Frame-Relay or 122 Ethernet. The specific details of such status interworking are out 123 of the scope of this document, and are only noted here to illustrate 124 the utility of BFD over VCCV for such purposes. Those details can be 125 found in [I-D.ietf-pwe3-oam-msg-map]. 127 The new BFD CV Types are PW Demultiplexer-agnostic, and hence 128 applicable for both MPLS and L2TPv3 Pseudowire Demultiplexers. This 129 document concerns itself with the BFD VCCV operation over Single- 130 Segment Pseudowires (SS-PW). This specification describes procedures 131 only for BFD asynchronous mode. 133 3. Bidirectional Forwarding Detection Connectivity Verification 135 VCCV can support several Connectivity Verification (CV) types. This 136 section defines new CV Types for use when BFD is used as the VCCV 137 payload. 139 The CV Type is defined as a bitmask field used to indicate the 140 specific CV Type or Types (i.e., none, one or more) of VCCV packets 141 that may be sent on the VCCV control channel. The values shown below 142 augment those already defined in [RFC5085]. They represent the 143 numerical value corresponding to the actual bit being set in the CV 144 Type bitfield. 146 BFD CV Types: 148 The defined values for the different BFD CV Types for MPLS and 149 L2TPv3 PWs are: 151 Bit (Value) Description 152 ============ ==================================================== 153 Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only 154 Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and 155 AC/PW Fault Status Signaling 156 Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only 157 Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and 158 AC/PW Fault Status Signaling 160 It should be noted that four BFD CV Types have been defined by 161 permutation of their encapsulation and functionality, see 162 Section 3.3. 164 3.1. BFD CV Type Operation 166 When heart-beat indication is necessary for one or more PWs, the 167 Bidirectional Forwarding Detection (BFD) [I-D.ietf-bfd-base] provides 168 a means of continuous monitoring of the PW data path and, in some 169 operational modes, propagation of forward and reverse defect 170 indications. 172 In order to use BFD, both ends of the PW connection need to agree on 173 the BFD CV Type to use: 175 For statically provisioned pseudowires, both ends need to be 176 statically configured to use the same BFD CV Type (in addition to 177 be statically configured for VCCV with the same CC Type). 179 For dynamically established pseudowires, both ends of the PW must 180 have signaled the existence of a control channel and the ability 181 to run BFD on it (see Section 3.3 and Section 4). 183 Once a node has selected a valid BFD CV Type to use (either 184 statically provisioned or selected dynamically after the node has 185 both signaled and received signaling from its peer of these 186 capabilities), it begins sending BFD control packets. 188 The BFD control packets are sent on the VCCV control channel. The 189 use of the VCCV control channel provides the context required to bind 190 and bootstrap the BFD session, since discriminator values are not 191 exchanged; the pseudowire demultiplexer field (e.g., MPLS PW Label or 192 L2TPv3 Session ID) provides the context to demultiplex the first BFD 193 control packet, and thus single-hop BFD initialization procedures are 194 followed (see Section 3 of [I-D.ietf-bfd-v4v6-1hop] and Section 6 of 195 [I-D.ietf-bfd-generic]). A single BFD session exists per-pseudowire. 196 Both PW endpoints take the Active role sending initial BFD Control 197 packets with a "Your Discriminator" field of zero, and BFD Control 198 packets received with a "Your Discriminator" field of zero are 199 associated to the BFD session bound to the PW. BFD MUST be run in 200 asynchronous mode (see [I-D.ietf-bfd-base]). 202 The operation of BFD VCCV for PWs is therefore symmetrical. Both 203 endpoints of the bidirectional pseudowire MUST send BFD messages on 204 the VCCV control channel. 206 When the downstream PE (D-PE) does not receive BFD control messages 207 from its upstream peer PE (U-PE) during a certain number of 208 transmission intervals (a number provisioned by the operator as 209 Detect Mult), D-PE declares that the PW in its receive direction is 210 down. In other words, D-PE enters the "forward defect" state for 211 this PW. After this calculated Detection Time, D-PE declares the 212 session Down, and signals this to the remote end via the State (Sta) 213 with Diagnostic code 1 (Control Detection Time Expired). In turn, 214 U-PE declares the PW is down in its transmit direction setting the 215 State to Down, and it using Diagnostic code 3 (Neighbor signaled 216 session down) in its control messages to D-PE. U-PE enters the 217 "reverse defect" state for this PW. If needed, how it further 218 processes this error condition, and conveys this status to the 219 attachment circuits is out of the scope of this specification, and is 220 instead defined in [I-D.ietf-pwe3-oam-msg-map]. 222 The VCCV message comprises a BFD Control packet [I-D.ietf-bfd-base] 223 encapsulated as specified by the CV Type (see Section 3.2). 225 3.2. BFD Encapsulation 227 There are two ways in which a BFD connectivity verification packet 228 may be encapsulated over the VCCV control channel. This document 229 defines four BFD CV Types (see Section 3), which can be grouped into 230 two pairs of BFD CV Types from an encapsulation point of view. 231 Table 1 in Section 3.3 summarizes the BFD CV Types. 233 o IP/UDP BFD Encapsulation (BFD with IP/UDP Headers) 235 In the first method, the VCCV encapsulation of BFD includes the 236 IP/UDP headers as defined in Section 4 of 237 [I-D.ietf-bfd-v4v6-1hop]. BFD Control packets are therefore 238 transmitted in UDP with destination port 3784 and source port 239 within the rage 49152 through 65535. The IP Protocol Number and 240 UDP Port numbers discriminate among the possible VCCV payloads 241 (i.e., differentiate among ICMP Ping and LSP Ping defined in 242 [RFC5085] and BFD). 244 The IP version (IPv4 or IPv6) matches the IP version used for 245 signaling for dynamically established pseudowires, or is 246 configured for statically provisioned pseudowires. The source IP 247 address is an address of the sender. The destination IP address 248 is a (randomly chosen) IPv4 address from the range 127/8 or IPv6 249 address from the range 0:0:0:0:0:FFFF:127.0.0.0/104. The 250 rationale is explained in Section 2.1 of [RFC4379]. The Time to 251 Live/Hop Limit procedures from Section 5 of 252 [I-D.ietf-bfd-v4v6-1hop] apply to this encapsulation, and hence 253 the TTL/Hop Limit is set to 255. In this encapsulation, the BFD 254 CV Type used in signaling (if used) 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 for its Control Word (CW) or L2-Specific 265 Sublayer (L2SS, used in L2TPv3). 267 In this encapsulation, a "raw" BFD Control packet follows directly 268 the PW-ACH, and the PW-ACH Channel Type identifies "raw" BFD. The 269 PW Associated Channel (PWAC) is defined in Section 5 of [RFC4385], 270 and its Channel Type field is used as a payload type identifier to 271 discriminate the VCCV payload types. 273 The usage of the PW-ACH on different VCCV CC Types is specified 274 for CC Type 1, Type 2 and Type 3 respectively in Sections 5.1.1, 275 5.1.2 and 5.1.3 of [RFC5085], in all cases depending on the use of 276 a CW. When VCCV carries 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), to allow the identification of the encased BFD 280 payload when demultiplexing the VCCV control channel. In this 281 case, the BFD CV Type employed in signaling (if used) is either 282 0x10 or 0x20. 284 In summary, for the IP/UDP encapsulation of BFD (BFD with IP/UDP 285 headers), if a PW Associated Channel Header is used, the Channel Type 286 can indicate IPv4 (0x0021) or IPv6 (0x0057). For the PW-ACH 287 encapsulation of BFD (BFD without IP/UDP headers), the PW Associated 288 Channel Header MUST be used and indicates BFD Control packet 289 (0x0007). 291 3.3. CV Types for BFD 293 Four CV Types are defined for BFD. Table 1 summarizes the BFD CV 294 Types, grouping them by encapsulation (i.e., with and without IP/UDP 295 headers) and by functionality (i.e., fault detection only, or fault 296 detection and status signaling). 298 +----------------------------+--------------+-----------------------+ 299 | | Fault | Fault Detection and | 300 | | Detection | Status Signaling | 301 | | Only | | 302 +----------------------------+--------------+-----------------------+ 303 | BFD, IP/UDP encapsulation | 0x04 | 0x08 | 304 | (with IP/UDP Headers) | | | 305 | | | | 306 | BFD, PW-ACH encapsulation | 0x10 | 0x20 | 307 | (without IP/UDP Headers) | | | 308 +----------------------------+--------------+-----------------------+ 310 Table 1: Bitmask Values for BFD CV Types 312 Given the bidirectional nature of BFD, before selecting a given BFD 313 CV Type capability to be used in dynamically established pseudowires, 314 there MUST be common CV Types in the VCCV capability advertised and 315 received. That is, only BFD CV Types that were both advertised and 316 received are available to be selected. Additionally, only one BFD CV 317 Type can be used (selecting a BFD CV Type excludes all the remaining 318 BFD CV Types). 320 The following list enumerates rules, restrictions and clarifications 321 on the usage of BFD CV Types: 323 1. BFD CV Types used for fault detection and status signaling (i.e., 324 CV Types 0x08 and 0x20) SHOULD NOT be used when a control 325 protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available 326 that can signal the AC/PW status to the remote endpoint of the 327 PW. More details can be found in [I-D.ietf-pwe3-oam-msg-map]. 329 2. BFD CV Types used for fault detection only (i.e., CV Types 0x04 330 and 0x10) can be used whether a protocol that can signal AC/PW 331 status is available or not. This includes both statically 332 provisioned and dynamically signaled pseudowires. 334 A. In this case, BFD is used exclusively to detect faults on the 335 PW; if it is desired to convey AC/PW fault status, some means 336 other than BFD are to be used. Examples include using LDP 337 status messages when using MPLS as a transport (see Section 338 5.4 of [RFC4447]), and the Circuit Status AVP in an L2TPv3 339 SLI message for L2TPv3 (see Section 5.4.5 of [RFC3931]). 341 3. Pseudowires that do not use a CW or L2SS using the PW Associated 342 Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., 343 PW-ACH encapsulation of BFD, without IP/UDP headers). 345 A. PWs that use a PW-ACH include CC Type 1 (for both MPLS and 346 L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]), 347 and MPLS CC Types 2 and 3 when using a Control Word (as 348 specified in Sections 5.1.2 and 5.1.3 of [RFC5085]). This 349 restriction stems from the fact that the PW-ACH contains a 350 Protocol Identification (PID) field, the Channel Type. 352 B. PWs that do not use a PW-ACH can use the VCCV BFD 353 encapsulation with IP/UDP headers, including its concurrent 354 use along with another CV Type that uses an encapsulation 355 with IP headers (e.g., ICMP Ping or LSP Ping). For example, 356 as specified in Section 7 of [RFC4385], a Pseudowire 357 operating without CW MUST NOT use the PW-ACH. 359 4. Only a single BFD CV Type can be selected and used. All BFD CV 360 Types are mutually exclusive with the rest, after selecting a BFD 361 CV Type, a node MUST NOT use any of the other three BFD CV Types. 363 4. Capability Selection 365 The precedence rules for selection of various CC and CV Types is 366 clearly outlined in Section 7 of [RFC5085]. This section augments 367 these rules when the BFD CV Types defined herein are supported. The 368 selection of a specific BFD CV Type to use out of the four available 369 CV Types defined is tied to multiple factors, as hinted in 370 Section 3.3. Given that BFD is bidirectional in nature, only CV 371 Types that are both received and sent in VCCV capability signaling 372 advertisement can be selected. 374 There may be more than one CV Type available for selection after 375 considering the intersection of advertised and received BFD CV Types, 376 and applying the rules in Section 3.3. For these cases were multiple 377 BFD CV Types are available for selection, the following precedence 378 order applies when choosing the single BFD CV Type to use. The 379 lowest numbered item (where both ends have set the indicated flag and 380 such flag is allowed by the rules above) is used: 382 1. 0x20 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW 383 Fault Detection and AC/PW Fault Status Signaling 385 2. 0x10 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW 386 Fault Detection only 388 3. 0x08 - BFD IP/UDP-encapsulated, for PW Fault Detection and AC/PW 389 Fault Status Signaling 391 4. 0x04 - BFD IP/UDP-encapsulated, for PW Fault Detection only 393 This precedence order prioritizes superset of functionality and 394 simplicity of encapsulation. 396 5. IANA Considerations 398 5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV 400 The VCCV Interface Parameters Sub-TLV codepoint is defined in 401 [RFC4446], and the VCCV CV Types registry is defined in [RFC5085]. 402 This section lists the new BFD CV Types. 404 IANA is requested to augment the "VCCV Connectivity Verification 405 Types" registry in the Pseudo Wires Name Spaces, reachable from 406 [IANA.pwe3-parameters]. These are bitfield values. CV Type values 407 0x04 0x08, 0x10 and 0x20 are specified in Section 3. 409 MPLS Connectivity Verification (CV) Types: 411 Bit (Value) Description 412 ============ ==================================================== 413 Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only 414 Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and 415 AC/PW Fault Status Signaling 416 Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only 417 Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and 418 AC/PW Fault Status Signaling 420 5.2. PW Associated Channel Type 422 The PW Associated Channel Types used by VCCV rely on previously 423 allocated numbers from the Pseudowire Associated Channel Types 424 Registry [RFC4385] in the Pseudo Wires Name Spaces reachable from 425 [IANA.pwe3-parameters]. In particular, 0x21 (Internet Protocol 426 version 4) is used whenever an IPv4 payload follows the Pseudowire 427 Associated Channel Header, or 0x57 is used when an IPv6 payload 428 follows the Pseudowire Associated Channel Header. 430 In cases where a raw BFD Control packet follows the Pseudowire 431 Associated Channel as specified in Section 3.2 (i.e., when using the 432 PW-ACH-encapsulated BFD without IP/UDP headers), a new "Pseudowire 433 Associated Channel Types" Registry [RFC4385] entry of 0x07 is used. 434 IANA is requested to reserve a new Pseudowire Associated Channel Type 435 value as follows: 437 Value (in hex) Protocol Name Reference 438 -------------- --------------------------------- --------- 440 0x0007 BFD Control, PW-ACH encapsulation [This document] 441 (without IP/UDP Headers) 443 5.3. L2TPv3 CV Types for the VCCV Capability AVP 445 This section lists the new BFD CV Types to be added to the existing 446 "VCCV Capability AVP" registry in the L2TP name spaces. The Layer 447 Two Tunneling Protocol "L2TP" Name Spaces are reachable from 448 [IANA.l2tp-parameters]. 450 IANA is requested to reserve the following L2TPv3 Connectivity 451 Verification (CV) Types in the VCCV Capability AVP Values registry. 453 VCCV Capability AVP (Attribute Type AVP-TBD) Values 454 --------------------------------------------------- 456 L2TPv3 Connectivity Verification (CV) Types: 458 Bit (Value) Description 459 ============ ==================================================== 460 Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only 461 Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and 462 AC/PW Fault Status Signaling 463 Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only 464 Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and 465 AC/PW Fault Status Signaling 467 6. Congestion Considerations 469 The congestion considerations that apply to [RFC5085] apply to this 470 mode of operation as well. 472 7. Security Considerations 474 Routers that implement the additional CV Types defined herein are 475 subject to the same security considerations as defined in [RFC5085], 476 [I-D.ietf-bfd-base], and [I-D.ietf-bfd-v4v6-1hop]. This 477 specification does not raise any additional security issues beyond 478 these. The IP/UDP-encapsulated BFD makes use of the TTL/Hop Limit 479 procedures described in Section 5 of [I-D.ietf-bfd-v4v6-1hop], 480 including the use of the Generalized TTL Security Mechanism (GTSM) as 481 a security mechanism. 483 8. Acknowledgements 485 This work forks from a previous revision of the PWE3 WG document that 486 resulted in [RFC5085], to which a number of people contributed, 487 including Rahul Aggarwal, Peter B. Busschbach, Yuichi Ikejiri, Kenji 488 Kumaki, Luca Martini, Monique Morrow, George Swallow, and others. 490 Sam Aldrin, Stewart Bryant, Vishwas Manral, Luca Martini, Dave 491 McDysan, Pankil Shah, and George Swallow provided useful feedback and 492 valuable comments and suggestions on the newer versions of this 493 document. 495 9. References 497 9.1. Normative References 499 [I-D.ietf-bfd-base] 500 Katz, D. and D. Ward, "Bidirectional Forwarding 501 Detection", draft-ietf-bfd-base-09 (work in progress), 502 February 2009. 504 [I-D.ietf-bfd-generic] 505 Katz, D. and D. Ward, "Generic Application of BFD", 506 draft-ietf-bfd-generic-05 (work in progress), 507 February 2009. 509 [I-D.ietf-bfd-v4v6-1hop] 510 Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single 511 Hop)", draft-ietf-bfd-v4v6-1hop-09 (work in progress), 512 February 2009. 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 517 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 518 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 519 Use over an MPLS PSN", RFC 4385, February 2006. 521 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 522 Connectivity Verification (VCCV): A Control Channel for 523 Pseudowires", RFC 5085, December 2007. 525 9.2. Informative References 527 [I-D.ietf-pwe3-oam-msg-map] 528 Nadeau, T., "Pseudo Wire (PW) OAM Message Mapping", 529 draft-ietf-pwe3-oam-msg-map-08 (work in progress), 530 November 2008. 532 [IANA.l2tp-parameters] 533 Internet Assigned Numbers Authority, "Layer Two Tunneling 534 Protocol "L2TP"", December 2008, 535 . 537 [IANA.pwe3-parameters] 538 Internet Assigned Numbers Authority, "Pseudowire Name 539 Spaces (PWE3)", August 2008, 540 . 542 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 543 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 545 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 546 Label Switched (MPLS) Data Plane Failures", RFC 4379, 547 February 2006. 549 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 550 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 552 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 553 Heron, "Pseudowire Setup and Maintenance Using the Label 554 Distribution Protocol (LDP)", RFC 4447, April 2006. 556 Authors' Addresses 558 Thomas D. Nadeau (editor) 559 BT 560 BT Centre 561 81 Newgate Street 562 London, EC1A 7AJ 563 United Kingdom 565 Email: tom.nadeau@bt.com 567 Carlos Pignataro (editor) 568 Cisco Systems, Inc. 569 7200 Kit Creek Road 570 PO Box 14987 571 Research Triangle Park, NC 27709 572 USA 574 Email: cpignata@cisco.com