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