idnits 2.17.1 draft-ietf-pwe3-vccv-08.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1112. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1085. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1092. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1098. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (March 2006) is 6618 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) == Missing Reference: 'LSP-PING' is mentioned on line 326, but not defined == Missing Reference: 'PWSIG' is mentioned on line 237, but not defined == Missing Reference: 'PWE3CONTROL' is mentioned on line 455, but not defined == Missing Reference: 'RFC4385' is mentioned on line 564, but not defined == Unused Reference: 'IANAPPP' is defined on line 936, but no explicit reference was found in the text == Unused Reference: 'LSPPING' is defined on line 940, but no explicit reference was found in the text == Unused Reference: 'PWCTRL' is defined on line 944, but no explicit reference was found in the text -- No information found for draft-ietf-bfd - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BFD' == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-11 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANAPPP' == Outdated reference: A later version (-13) exists of draft-ietf-mpls-lsp-ping-09 == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-10 == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-12 ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) == Outdated reference: A later version (-06) exists of draft-ietf-pwe3-cw-05 -- No information found for draft-ietf-oam-requirements - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-03 -- Duplicate reference: RFC3036, mentioned in 'RFC3036', was also mentioned in 'LDP'. -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-11) exists of draft-ietf-bfd-v4v6-1hop-04 Summary: 6 errors (**), 0 flaws (~~), 16 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. D. Nadeau (Editor) 2 Internet Draft Cisco Systems, Inc. 3 Expiration Date: April 2006 4 R. Aggarwal (Editor) 5 Juniper Networks 7 March 2006 9 Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) 11 draft-ietf-pwe3-vccv-08.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document describes Virtual Circuit Connection Verification 39 (VCCV) procedures for use with pseudo wire (PW) connections. VCCV 40 supports connection verification applications for PWs regardless of 41 the underlying public service network technology. VCCV makes use of 42 IP-based protocols to perform operations and maintenance functions. 43 This is accomplished by providing a control channel associated with 44 each PW. A network operator may use the VCCV procedures to test the 45 network's forwarding plane liveliness. 47 Table of Contents 48 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 50 1 Specification of requirements .......................... 4 51 2 Introduction ........................................... 4 52 3 Overview of VCCV ....................................... 5 53 3.1 LSP Ping ............................................... 6 54 3.2 L2TPV3 ................................................. 6 55 3.3 Bidirectional Forwarding Detection ..................... 6 56 4 VCCV Control Channels for PWs Demultiplexed using MPLS .. 7 57 4.1 Inband VCCV (Type 1) .................................... 7 58 4.2 Out-of-Band VCCV (Type 2) ............................... 8 59 4.3 TTL Expiry VCCV (Type 3) ................................ 8 60 5 VCCV Types ............................................. 8 61 5.1 MPLS LSP Ping Packet ................................... 9 62 5.2 Bidirectional Forwarding Detection ..................... 9 63 6 OAM Capability Indication for PWs Demultiplexed using MPLS 10 64 6.1 Optional VCCV Parameter ................................ 11 65 7 VCCV Control Channel for L2TPv3/IP PSN ................. 12 66 7.1 L2TPv3 VCCV Message .................................... 13 67 7.1.1 L2TPv3 VCCV ICMP Ping AVP .............................. 13 68 7.1.2 L2TPv3 VCCV BFD AVP .................................... 13 69 7.2 L2TPv3 VCCV Capability Indication ...................... 13 70 7.2.1 L2TPv3 VCCV Capability AVP ............................. 13 71 7.3 L2TPv3 VCCV Operation .................................. 14 72 8 IANA Considerations .................................... 14 73 8.1 VCCV Parameter ID ...................................... 14 74 8.1.1 CC Types ............................................... 15 75 8.1.2 CV Types ............................................... 15 76 8.2 L2TPv3 Assignments ..................................... 15 77 8.2.1 CV Types ............................................... 15 78 9 Security Considerations ................................ 15 79 10 Acknowledgements ....................................... 17 80 11 References ............................................. 17 81 11.1 Normative References ................................... 17 82 11.2 Informative References ................................. 18 83 12 Editor Information ...................................... 18 84 13 Contributor Information ................................ 19 85 14 Intellectual Property Statement ........................ 20 86 15 Full Copyright Statement ............................... 20 88 1. Specification of requirements 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Introduction 95 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 97 As network operators deploy pseudo wire (PW) services, fault detec- 98 tion and diagnostic mechanisms particularly for the PSN portion of 99 the network are pivotal. Specifically, the ability to provide end-to- 100 end fault detection and diagnostics for an emulated PW service is 101 critical for the network operator. Operators have indicated in 102 [MPLSOAMREQS][PWREQ] that such a tool is required for PW deployments. 103 This document describes procedures for PSN-agnostic fault detection 104 and diagnostics called Virtual Circuit Connection Verification 105 (VCCV). 107 |<----- Pseudo Wire ---->| 108 | | 109 Attachment | |<-- PSN Tunnel -->| | Attachment 110 Circuit V V V V Circuit 111 | +----+ +----+ | 112 +----+ | | PE1|==================| PE2| | +----+ 113 | |----------|............PW1.............|----------| | 114 | CE1| | | | | | | |CE2 | 115 | |----------|............PW2.............|----------| | 116 +----+ | | |==================| | | +----+ 117 ^ +----+ +----+ | ^ 118 | Provider Edge 1 Provider Edge 2 | 119 | | 120 |<--------------- Emulated Service --------------->| 121 |<---------- VCCV ------>| 122 Customer Customer 123 Edge 1 Edge 2 125 Figure 1: PWE3 VCCV Operation Reference Model 127 Figure 1 depicts the basic functionality of VCCV. VCCV provides sev- 128 eral means of creating a control channel between PEs that attaches 129 the PW under test. 131 +-------------+ +-------------+ 132 | Layer2 | | Layer2 | 133 | Emulated | < Emulated Service > | Emulated | 134 | Services | | Services | 135 +-------------+ +-------------+ 136 | | VCCV/PW | | 137 |Demultiplexer| < Control Channel > |Demultiplexer| 138 +-------------+ +-------------+ 139 | PSN | < PSN Tunnel > | PSN | 140 +-------------+ +-------------+ 141 | Physical | | Physical | 142 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 144 +-----+-------+ +-----+-------+ 145 | | 146 | ____ ___ ____ | 147 | _/ ___/ \ _/ __ | 148 | / \__/ _ | 149 | / \ | 150 ---------| MPLS or IP Network |----- 151 | / 152 | ___ ___ __ ___/ 153 \_/ ____/ ___/ ____/ 155 Figure 2: PWE3 Protocol Stack Reference Model 156 including the VCCV control channel. 158 Figure 2 depicts how the VCCV control channel is associated with the 159 pseudo wire. Ping and other IP messages are encapsulated using the 160 PWE3 encapsulation as described below in sections 5 and 6. These mes- 161 sages, referred to as VCCV messages, are exchanged only after the 162 desire to exchange such traffic has been negotiated between the PEs 163 (see section 8). 165 3. Overview of VCCV 167 VCCV defines a set of messages that are exchanged between PEs to ver- 168 ify connectivity of the pseudo wire. To make sure that VCCV packets 169 follow the same path as the PW data flow, they are encapsulated in 170 the PW demultiplexer and trasported over the PSN tunnel. VCCV can 171 operate in two modes: 173 1) as a diagnostic tool 174 2) as a fault detection tool 176 In the diagnostic mode, the operator triggers LSP-Ping, L2TPV3, or 177 ICMP Ping [ICMP] modes depending on the underlying PSN. Since a PW 178 service is bi-directional, the reply MAY be sent over the PW in 179 the reverse direction, that makes up the other half of the PW service 180 under test. For example, if the PSN is MPLS, the reply should be sent 181 over the reverse PW, which is transported over the PSN LSP in the 182 reverse direction. If this fails, the operator MAY use other reply 183 modes such as Reply Mode 4 from [LSP-PING] (Reply via application 184 level control channel) to determine the fault. 186 The fault detection mode provides a way to emulate fault detection 187 mechanisms in other technologies, such as ATM for example. For exam- 188 ple, in the fault detection mode, the BFD Bidirectional Forwarding 189 Detection (BFD) mechanism can be used as following: the upstream PE 190 sends BFD control messages periodically. When the downstream PE 191 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 193 doesn't receive these message for a defined period of time, it 194 declares that direction of the PW down and it notifies the upstream 195 PE. Based on the emulated service, the PEs may send native indica- 196 tions over the related attachment circuits to notify the end points 197 of the fault condition. The specific details of the handling of 198 these conditions is out of the scope of this document, and are 199 only noted here to illustrate the utility of VCCV for these 200 purposes. More complete details can be found in [OAM-MAP]. 202 3.1. LSP Ping 204 When PWs are demultiplexed using MPLS, LSP Ping is used as described 205 in [LSP-PING] as a connectivity verification and diagnostic tool for 206 PWs. The PSN may be MPLS or IP. 208 3.2. L2TPV3 210 When IP is used as the PSN, various protocols can be deployed for PW 211 Demultiplexing [PWEARCH]. If L2TP or UDP is used, ICMP ECHO packets 212 [ICMP] can be used as the means by which connectivity verification is 213 achieved. 215 3.3. Bidirectional Forwarding Detection 217 When fault detection indication is necessary for one or more PWs, the 218 Bidirectional Forwarding Detection (BFD) [BFD] provides a light- 219 weight means of continuous monitoring and propagation of forward and 220 reverse defect indications. BFD can be used regardless of the under- 221 lying PSN technology. 223 4. VCCV Control Channels for PWs Demultiplexed using MPLS 225 In order to apply IP monitoring tools to PWE3 circuits, VCCV creates 226 a control channel between PWE3 PEs [PWEARCH]. Packets sent across 227 this channel are IP packets, allowing maximum flexibility. 229 Ideally such a control channel would be completely in band. When a 230 control word is present on virtual circuit, it is possible to indi- 231 cate the control channel by setting a bit in the control header. 232 This method is described in section 4.1 and is referred to as PWE3 233 inband VCCV. 235 4.1. Inband VCCV (Type 1) 237 The PW set-up protocol [PWSIG] determines whether a PW uses a control 238 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 240 word. When a control word is used, it SHOULD have the following form 241 for the purpose of indicating VCCV control channel messages. (Note 242 that for data, one uses the control word defined just above the MPLS 243 payload [PWEARCH].) 245 The PW Associated Channel for VCCV control channel traffic is defined 246 as follows in [PW-CW]: 248 0 1 2 3 249 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 |0 0 0 1|Version| Reserved | Channel Type | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 3: PW Associated Channel Header 256 The first nibble is set to 0x0001 to indicate a channel associated 257 with a pseudowire [PW-CW, PWE3IANA]. The Format ID and the reserved 258 fields are set to 0, the Version is 0, and the Channel Type is set 259 to 0. 261 For example, the following is an example of how the ethernet control 262 word would be received [ENETENCAP]: 264 0 1 2 3 265 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 |0 0 0 1| 0 | 0 | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 4: PW Associated Channel Header for VCCV 272 It should be noted that although some PW types are not required 273 to carry the control word, this type of VCCV MUST only be used 274 for those PW types that do employ the control word. 276 4.2. Out-of-Band VCCV (Type 2) 278 When the control word is not used, or the receiving hardware cannot 279 divert control traffic based on information in the control word 280 (i.e.: older hardware), a VCCV control channel can alternatively 281 be created by including the MPLS router alert label [RFC3032] 282 immediately above the PW label. If the control word is in use on 283 this PW it is also included in the VCCV control flow. It should be 284 noted that this approach MAY alter equal cost multi-path (ECMP) 285 hashing behavior, and thus result in the VCCV control channel 286 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 288 traffic taking a path which differs from that of the data 289 traffic under test. 291 4.3. TTL Expiry VCCV (Type 3) 293 The TTL of the PW demultiplexor label can be set to 1 to force the 294 packet to be processed within the destination router's control plane. 295 This is an inband control channel identification mechanism that is an 296 alternate to section 4.1. 298 When the PSN is MPLS it should be noted that this mode may not work 299 in cases where the penultimate hop overwrites the TTL values of 300 labels underneath the top-most label. Some older implementations do 301 this, and the result would be a false positive. Therefore, we recom- 302 mend that operators investigate the TTL handling behavior of the 303 routers in their networks to determine if this situation can occur. 304 If it is discovered that it can, than this mode should not be used 305 for the reasons explained above. 307 It should be noted that although some PW types are not required 308 to carry the control word, this type of VCCV MUST only be used 309 for those PW types that do employ the control word. 311 5. VCCV Types 313 VCCV can support several types of connectivity verification 314 protocols within its control channel, but only one MUST be used. 315 The specific one chosen is based on the preferred order 316 specified below. If another is desired to be used once one has begun 317 to be transmitted, the pseudowire MUST be re-signaled. The specific 318 type or types of VCCV packets accepted by a router are indicated 319 during capability advertisement as described in section 6. The 320 various VCCV types supported SHOULD be used only when they apply 321 to the PW demultiplexor in use. For example, the LSP Ping type 322 should only be used when MPLS is utilized as the PW demultiplexor. 324 5.1. MPLS LSP Ping 326 The LSP Ping header must be used as described [LSP-PING] and MUST 327 also contain the target FEC Stack in turn containing the 328 sub-TLV of 8 for the L2 VPN endpoint or 9 or 10 329 for "FEC 128 Pseudowire" or 11 for the FEC 128 Pseudowire". 330 The sub-TLV indicates the PW to be verified. 332 5.2. Bidirectional Forwarding Detection 334 When heart-beat indication is necessary for one or more PWs, the 335 Bidirectional Forwarding Detection (BFD) [BFD] provides a 336 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 338 means of continuous monitoring of the PW data path and 339 propagation of forward and reverse defect indications. 341 In order to use BFD, both ends of the PW connection must have sig- 342 naled the existence of a control channel and the ability to run BFD. 343 Once a node has both signaled and received signaling from its peer of 344 these capabilities, it MUST begin sending BFD control packets. The 345 packets MUST be sent on the control channel. The use of the control 346 channel provides the context required to bind the BFD session to a 347 particular PW (FEC). Thus normal single-hop BFD initialization 348 procedures are followed. BFD MUST be run in asynchronous mode. 349 In addition, it may also be desirable to use LSP-Ping for periodic 350 diagnostics, in addition to BFD, for fault detection on the same 351 PW. The procedures for this are described in [BFDMPLS]. 353 When one of the PEs (PE2) doesn't receive control messages from PE1 354 during the specified amount of time it declares that the PW in the 355 direction from PE2 to PE1 is down. It stores the cause 356 (e.g., Diagnostic code 1 - control detection time expired) and 357 sends a message to PE1 containing this diagnostic code. 358 This causes PE1 to declare the PW in the direction from PE1 to PE2 359 is down and it stores as cause: neighbor signaled session down. 360 Depending on the emulated services, PE2 may send a 361 forward direction indication (FDI) on its attachment 362 circuits and PE1 may send an RDI indication on its attachment 363 circuits [OAM-MAP]. 365 BFD defines the following diagnostics: 367 0 - No Diagnostic 368 1 - Control Detection Time Expired 369 2 - Echo Function Failed 370 3 - Neighbor Signaled Session Down 371 4 - Forwarding Plane Reset (Local equipment failure) 372 5 - Path Down (Alarm Suppression) 373 6 - Concatenated Path Down (Propagating access link alarm) 374 7 - Administratively Down 375 8 - Reverse Concatenated Path Down 377 Note that the value, 0 is used when the PW is up and 2 is not appli- 378 cable to asynchronous mode. 380 6. OAM Capability Indication for PWs Demultiplexed using MPLS 382 To permit the indication of the type or types of PW control chan- 383 nel(s), and connectivity verification mode or modes over a particular 384 PW, a VCCV parameter is defined below that is used as part of the PW 385 establishment signaling. When a PE signals a PW and desires PW OAM 386 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 388 for that PW, it MUST indicate this during PW establishment using the 389 messages defined below. Specifically, for LDP the PE MUST include the 390 VCCV parameter in the PW setup message. 392 The decision of the type of VCCV control channel is left completely 393 to the receiving control entity, although the set of choices is 394 given by the sender in that it indicates the type or types of 395 control channels that it can understand. The receiver SHOULD 396 chose a single control channel type from the choices indicated 397 based on the order of preference rules specified below in 398 the section entitled, "Preferred Capability Order" and it 399 MUST continue to use this type for the duration of the life 400 of the control channel. Changing control channel types after 401 one has been established to be in use could potentially cause 402 problems at the receiving end, and could also lead to 403 interoperability issues, thus it is strongly discouraged. 405 When a PE sends a label for a PW, it uses the VCCV parameter to 406 indicate the type of OAM control channels and connectivity 407 verification type or types it is willing to receive on that PW. 408 The capablity of supporting a control channel or channels, 409 and connectivity type or types used over that control channel 410 or channels MUST be signaled before the remote PE may send VCCV 411 messages, and then only on the control channel or channels, and 412 using the connectivity verification type or types indicated. 414 If a PE receives VCCV messages prior to advertising capability for 415 this message, it MUST discard these messages and not reply to them. 416 In this case, the PE SHOULD increment an error counter and optionally 417 issue a system and/or SNMP notification to indicate to the system 418 administrator that this condition exists. 420 When LDP is used as the PW signaling protocol the requesting PE 421 indicates its configured VCCV capability or capabilities to the 422 remote PE by including the VCCV parameter with appropriate options 423 indicating which control channel types it supports in the 424 interface parameter field of the PW ID FEC TLV (FEC 128) or in 425 the sub-TLV interface parameter of the Genralized PW ID FEC TLV 426 (FEC 129). The requesting PE MAY indicate that it supports 427 multiple control channel options, and in doing so agrees to support 428 any and all indicated types if transmitted to it. 430 Local policy may direct the PE to support certain OAM capability and 431 to indicate it. The absence of the VCCV parameter indicates that no 432 OAM functions are supported by the requesting PE, and thus the 433 receiving PE MUST NOT send any VCCV control channel traffic to it. 434 The reception of a VCCV parameter with no options set MUST be 435 ignored as if one is not transmitted at all. 437 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 439 The receiving PE similarly indicates its supported control channel 440 types in the response. These may or may not be the same as the 441 ones that were sent to it. The sender should examine the set that 442 is returned to understand which control channels it may establish 443 with the remote peer. Similarly, it MUST NOT send control channel 444 traffic to the remove PE for which the remote PE has not indicated 445 it supports. 447 The exception to the rules given in the last two paragraphs above 448 is when one side of the PW indicates no support for VCCV while the 449 other indicates support for at least one control channel type. In 450 this case, it is possible for one side of the PW to send VCCV 451 messages (either requests or replies to requests). 453 6.1. Optional VCCV Parameter 455 [PWE3CONTROL] defines an Interface Parameter field in the LDP PW ID 456 FEC (FEC 128) and an Interface Parameters TLV in the LDP Generalized 457 PW ID FEC (FEC 129) to signal different capabilities for specific 458 PWs. We propose an optional parameter to be used to indicate the 459 desire to use a control channel for VCCV. This is the VCCV parameter 460 field. If FEC 128 is used the VCCV parameter field is carried in the 461 Interface Parameters field. If FEC 129 is used it is carried as an 462 Interface Parameter sub-TLV in the Interface Parameters TLV. 464 The VCCV parameter ID is defined as follows in [PWE3IANA]: 466 Parameter ID Length Description 467 0x0c 4 VCCV 469 The format of the VCCV parameter field is as follows: 471 0 1 2 3 472 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | 0x0c | 0x04 | CC Types | CV Types | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 The Control Channel (CC Types) type field defines a bitmask used to 478 indicate the type of control channel(s) (i.e.: none, one or more) 479 that may be used to receive OAM control channel traffic on. If more 480 than one control channel is specified, the router agrees to accept 481 control traffic at any time over either control channel. If none of 482 the types are supported, a CC Type Indicator of 0x00 SHOULD be trans- 483 mitted to indicate this to the peer. However, if no capability is 484 signaled, then the peer MUST assume that the peer is incapable of 485 receiving VCCV and MUST NOT send any OAM control channel traffic to 486 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 488 it. 490 0x00 None. 491 0x01 PWE3 control word with 0x0001 as first nibble 492 0x02 MPLS Router Alert Label 493 0x04 MPLS PW Demultiplexor Label TTL = 1 495 The CV Type Indicators field is a bitmask used to indicate the spe- 496 cific type or types (i.e.: none, one or more) of control channel 497 packets that may be sent on the specified control channel. The 498 defined values are: 500 0x00 None. 501 0x01 ICMP Ping 502 0x02 LSP Ping 503 0x04 BFD for PW Fault Detection only 504 0x08 BFD for PW Fault Detection and AC/PW Fault 505 Status Signaling 507 It should be noted that two different CV Types have been defined 508 when BFD is used. In the first case, type 0x04 indicates that 509 BFD is used exclusively to detect faults on the PW and the 510 status of those faults should be conveyed using some means other 511 than BFD. In the case of type 0x08, the AC and PW status SHOULD 512 be conveyed via BFD status codes as specified in [OAM-MAP]. 513 Implementations SHOULD NOT include both type 0x04 and 0x08 514 in a capability advertisement due to the complexity of supporting 515 both simultaneously to avoid ambiguity and confusion about how 516 to process and transmit pseudowire status. 518 If none of the types above are supported, a CV Type Indicator of 0x00 519 SHOULD be transmitted to indicate this to the peer. However, if no 520 capability is signaled, then the peer MUST assume that the peer has 521 no VCCV capability. 523 7. VCCV Control Channel for L2TPv3/IP PSN 525 When L2TPv3 is used to setup a PW over an IP PSN, VCCV packets are 526 carried over the L2TPv3 session as defined in this section. L2TPv3 527 provides a "Hello" keepalive mechanism for the L2TPv3 control plane 528 that operates in-band over IP or UDP (see Section 4.4 of [L2TPv3]). 529 This built-in Hello facility provides dead peer and path detection 530 only for the group of sessions associated with the L2TP Control 531 Connection. VCCV, however, allows individual L2TP sessions to be 532 tested. This provides a more granular mechanism which can be used to 533 troubleshoot potential problems within the dataplane of L2TP 534 endpoints themselves, or to provide additional connection status of 535 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 537 individual Pseudowires. 539 In order to carry VCCV messages within an L2TPv3 session data packet, 540 the PW MUST be established such that an L2-Specific Sublayer (L2SS) 541 that defines the V-bit is present. This document defines the V-bit 542 for the Default L2-Specific Sublayer [L2TPv3] and the ATM-Specific 543 Sublayer [L2TPv3-ATM] using the Bit 0 position (see Section 8.2.2 and 544 Section 8.2.3). The L2-Specific Sublayer presence and type (either 545 the Default or a PW-Specific L2SS) is signaled via the L2-Specific 546 Sublayer AVP, Attribute Type 69, as defined in [L2TPv3]. The V-bit 547 within the L2-Specific Sublayer is used to identify that a VCCV 548 message follows, and when the V-bit is set the L2SS has the following 549 format: 551 0 1 2 3 552 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 |1|0 0 0|Version| Reserved | Channel Type | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 L2-Specific Sublayer Format when the V-bit (bit 0) is set 559 The VCCV messages are distinguished from user data by the V-bit. The 560 V-bit is set to 1, indicating that a VCCV session message follows. 561 The next three bits MUST be set to 0 when sending and ignored upon 562 receipt. The remaining fields comprising 28 bits (i.e., Version, 563 Reserved and Channel Type) follow the same definition, format and 564 values from Section 5 of [RFC4385]. 566 7.1. L2TPv3 VCCV Message 568 The VCCV message over L2TPv3 directly follows the L2-Specific 569 Sublayer with the V-bit set. It could either contain an ICMP Echo 570 packet as described in Section 7.1.1, or a BFD packet as described in 571 Section 7.1.2. 573 7.1.1. L2TPv3 VCCV using ICMP Ping 575 When this connectivity verification mode is used, an ICMP Echo packet 576 [ICMP] achieves connectivity verification. The ICMP Ping packet 577 directly follows the L2SS with the V-bit set. In the ICMP Echo 578 request, the IP Header fields MUST have the following values: the 579 destination IP address is set to the remote LCCE's IP address for the 580 tunnel endpoint, the source IP address is set to the local LCCE's IP 581 address for the tunnel endpoint, and the TTL is set to 1. 583 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 585 7.1.2. L2TPv3 VCCV using BFD 587 When BFD is used as the connectivity verification mode for L2TPv3 588 Pseudowires, a BFD packet is used to verify the session. The BFD 589 packet is encapsulated in IP/UDP as specified in [BFDV4V61HOP] and 590 directly follows the L2SS with the V-bit set. When heart-beat 591 indication is necessary for one or more PWs, the Bidirectional 592 Forwarding Detection (BFD) [BFD] provides a means of continuous 593 monitoring of the PW data path and propagation of forward and reverse 594 defect indications. 596 To use BFD, both ends of the Pseudowire MUST have signaled a VCCV 597 control channel capability and the ability to run BFD. Once an LCCE 598 has both signaled and received signaling from its peer of a VCCV 599 control channel and BFD connectivity verification capabilities, it 600 MUST begin sending BFD control packets. The packets MUST be sent on 601 the VCCV control channel. The use of the VCCV control channel 602 provides the context required to bind the BFD session to a particular 603 L2TPv3 session (PW). Thus normal single-hop BFD initialization 604 procedures SHOULD be followed [BFD]. BFD MUST be run in asynchronous 605 mode. The VCCV message comprises a BFD control packet [BFD] 606 encapsulated in IP/UDP as specified in Section 4 of [BFDV4V61HOP]. 607 The L2TPv3 Session ID provides the context to demultiplex the first 608 BFD control packet. 610 7.2. L2TPv3 VCCV Capability Indication 612 An new optional AVP is defined in Section 7.2.1 to indicate the the 613 VCCV capabilities during session establishment. An LCCE MUST signal 614 its desire to use connectivity verification for a particular L2TPv3 615 session and its VCCV capabilities using the VCCV Capability AVP. 617 7.2.1. L2TPv3 VCCV Capability AVP 619 The "VCCV Capability AVP", Attribute type AVP-TBD, specifies the VCCV 620 capabilities as a pair of bitflags for the Control Channel (CC) and 621 Connectifity Verification (CV) Types. This AVP is exchanged during 622 session establishment (in ICRQ, ICRP, OCRQ or OCRP messages). The 623 value field has the following format: 625 VCCV Capability AVP (ICRQ, ICRP, OCRQ, OCRP) 627 0 1 628 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 632 | CC Types | CV Types | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 CC Types: 637 The Control Channel (CC) Types field defines a bitmask used to 638 indicate the type of control channel(s) that may be used to 639 receive OAM traffic on for the given Session. The router agrees 640 to accept VCCV traffic at any time over any of the signaled VCCV 641 control channel types. Although there is only one value defined 642 in this document, the CC Types field is included for forward 643 compatibility should further CC Types need to be defined in the 644 future. 646 0x01 L2-Specific Sublayer with V-bit set. 648 A CC Type of 0x01 may only be requested when there is an 649 L2-Specific Sublayer that defines the V-bit present. If a CC Type 650 of 0x01 is requested without requesting an L2-Specific Sublayer 651 AVP with an L2SS type that defines the V-bit, the session MUST be 652 disconnected with a CDN message. 654 If no CC Type is supported, a CC Type Indicator of 0x00 SHOULD be 655 sent. 657 CV Types: 659 The Connectifity Verification (CV) Types field defines a bitmask 660 used to indicate the specific type or types (i.e.: none, one or 661 more) of IP control packets that may be sent on the specified VCCV 662 control channel. The defined values are: 664 0x01 ICMP Ping 665 0x02 BFD for PW Fault Detection only 666 0x04 BFD for PW Fault Detection and AC/PW Fault Status 667 Signaling 669 For CV Type of 0x02, BFD is used exclusively to detect faults on 670 the Session and the status of those faults should be conveyed 671 using some means other than BFD, such as using the Circuit Status 672 AVP in an L2TPv3 SLI message. For CV Type of 0x04, the AC and PW 673 status SHOULD be conveyed via BFD status codes. Implementations 674 SHOULD NOT include both CV types of 0x02 and 0x04 simultaneously 675 in a capability advertisement due to the complexity of supporting 676 both simultaneously to avoid ambiguity and confusion about how to 677 process and transmit Pseudowire status. 679 If none of the types above are supported, a CV Type Indicator of 680 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 682 0x00 SHOULD be transmitted to indicate this to the peer LCCE. 684 If no VCCV Capability AVP is signaled, then the LCCE MUST assume that 685 the peer is incapable of receiving VCCV and MUST NOT send any OAM 686 control channel traffic to it. 688 All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, and 689 Vendor ID. The Vendor ID for the VCCV Capability AVP MUST be 0, 690 indicating that this is an IETF-defined AVP. This AVP MAY be hidden 691 (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 692 0. The Length (before hiding) of this AVP is 8. 694 7.3. L2TPv3 VCCV Operation 696 An LCCE sends VCCV echo requests on an L2TPv3 signaled Pseudowire for 697 fault detection and diagnostic of the L2TPv3 session. The VCCV 698 message travels inband with the Session and follows the exact same 699 path as the user data for the session, because the IP header and 700 L2TPv3 Session header are identical. The egress LCCE of the L2TPv3 701 session intercepts and processes the VCCV message, and verifies the 702 signaling and forwarding state of the Pseudowire on reception of the 703 VCCV message. Any faults detected can be signaled in the VCCV 704 response. It is to be noted that the VCCV mechanism for L2TPv3 is 705 primarily targeted at verifying the Pseudowire forwarding and 706 signaling state at the egress LCCE. It also helps when L2TPv3 Control 707 Connection and Session paths are not identical. 709 An LCCE MUST NOT send VCCV packets on a L2TPv3 session unless it has 710 received VCCV capability by means of the VCCV Capability AVP from the 711 remote end. If an LCCE receives VCCV packets and its not VCCV 712 capable or it has not sent VCCV capability indication to the remote 713 end, it MUST discard these messages. It should also increment an 714 error counter. In this case the LCCE MAY optionally issue a system 715 and/or SNMP notification. 717 Additionally, because BFD is bidirectional in nature, when using BFD 718 as the connectivity verification type, an LCCE must send VCCV packets 719 on a L2TPv3 session only if it has signaled VCCV capability with BFD 720 CV Type to the remote end and received VCCV capability with BFD CV 721 Type from the remote end. 723 8. IANA Considerations 725 8.1. VCCV Parameter ID 727 The VCCC parameter ID codepoint is defined in [PWE3IANA]. IANA 728 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 730 is requested to maintain a registry for the CC Types and CV 731 Types, and bitmasks in the VCCV Parameter ID. The allocations 732 must be done using the "First Come First Served" policy 733 defined in RFC2434. IANA is requested to maintain the 734 following registries. 736 8.1.1. CC Types 738 IANA needs to set up a registry of "VCCV Control Channel Types". 739 These are 8-bit values. CV Type values 0x01, 0x02, and 0x04 740 are specified in this document, PW Type values 0x08, 0x16 741 and 0x24 are to be assigned by IANA using the "Expert Review" 742 policy defined in [RFC2434]. A VCCV Control Channel Type 743 description is required for any assignment from this registry. 744 A document reference should also be provided. 746 0x00 None 747 0x01 PWE3 control word with 0x0001 as first nibble 748 as defined in [PW-CW] 749 0x02 MPLS Router Alert Label 750 0x04 MPLS PW Demultiplexor Label TTL = 1 752 8.1.2. CV Types 754 IANA needs to set up a registry of "VCCV Control Channel Types". 755 These are 8-bit values. CV Type values 0x00, 0x01, 0x02, and 0x04 756 are specified in this document, CV Type values 0x16 757 and 0x24 are to be assigned by IANA using the "Expert Review" 758 policy defined in [RFC2434]. A VCCV CV Type description 759 is required for any assignment from this registry. 760 A document reference should also be provided. 762 0x00 None 763 0x01 ICMP Ping 764 0x02 LSP Ping 765 0x04 BFD for PW Fault Detection only 766 0x08 BFD for PW Fault Detection and AC/PW Fault 767 Status Signaling 769 8.1.3 Channel Type 771 The Channel Type codepoint is defined in [PW-CW]. IANA 772 is requested to maintain a registry for the Channel 773 Types from that document. The allocations 774 must be done using the "First Come First Served" policy 775 defined in RFC2434. IANA is requested to maintain the 776 following registries. 778 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 780 0x00 OAM Indication (VCCV) 782 8.2. L2TPv3 Assignments 784 Sections 8.2.1 through 8.2.3 are registrations of new L2TP values for 785 name spaces already managed by IANA. Section 8.2.4 requests a new 786 registry to be added to the existing L2TP registry, and be maintained 787 by IANA accordingly. 789 8.2.1. Control Message Attribute Value Pairs (AVPs) 791 An additiona AVP Attribute is specified in Section 7.2.1. It is 792 required to be defined by IANA as described in Section 2.2 of 793 [RFC3438]. 795 Attribute 796 Type Description 797 --------- ---------------------------------- 798 AVP-TBD VCCV Capability AVP 800 8.2.2. Default L2-Specific Sublayer bits 802 The Default L2-Specific Sublayer contains 8 bits in the low-order 803 portion of the header. This document defines one reserved bits in 804 the Default L2-Specific Sublayer in Section 7, which may be assigned 805 by IETF Consensus [RFC2434]. It is required to be assigned by IANA. 807 Default L2-Specific Sublayer bits - per [L2TPv3] 808 --------------------------------- 809 Bit 0 - V (VCCV) bit 811 8.2.3. ATM-Specific Sublayer bits 813 The ATM-Specific Sublayer contains 8 bits in the low-order portion of 814 the header. This document defines one reserved bits in the ATM- 815 Specific Sublayer in Section 7, which may be assigned by IETF 816 Consensus [RFC2434]. It is required to be assigned by IANA. 818 ATM-Specific Sublayer bits - per [L2TPv3-ATM] 819 -------------------------- 820 Bit 0 - V (VCCV) bit 822 8.2.4. VCCV Capability AVP Values 824 This is a new registry for IANA to maintain. 826 IANA is requested to maintain a registry for the CC Types and CV 827 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 829 Types bitmasks in the VCCV Capability AVP, defined in Section 7.2.1. 830 The allocations must be done using the "Expert Review" policy defined 831 in [RFC2434]. A VCCV CC or CV Type description is required for any 832 assignment from this registry. A document reference should also be 833 provided. 835 IANA is requested to reserve the following bits in this registry: 837 VCCV Capability AVP (Attribute Type AVP-TBD) Values 838 --------------------------------------------------- 840 Control Channel (CC) Types 842 Bit 0 (0x01) - L2-Specific Sublayer with V-bit set. 843 Bit 1 (0x02) - Reserved 844 Bit 2 (0x04) - Reserved 845 Bit 3 (0x08) - Reserved 846 Bit 4 (0x10) - Reserved 847 Bit 5 (0x20) - Reserved 848 Bit 6 (0x40) - Reserved 849 Bit 7 (0x80) - Reserved 851 Connectifity Verification (CV) Types 853 Bit 0 (0x01) - ICMP Ping 854 Bit 1 (0x02) - BFD for PW Fault Detection only 855 Bit 2 (0x04) - BFD for PW Fault Detection and AC/PW Fault 856 Status Signaling 857 Bit 3 (0x08) - Reserved 858 Bit 4 (0x10) - Reserved 859 Bit 5 (0x20) - Reserved 860 Bit 6 (0x40) - Reserved 861 Bit 7 (0x80) - Reserved 863 9. Security Considerations 865 Routers that implement the mechanism described herein are subject to 866 to additional denial-of-service attacks as follows: 868 An intruder may impersonate an LDP peer in order to 869 force a failure and reconnection of the TCP connection. 870 Please see the Security Considerations section of 871 [RFC3036] details. 873 An intruder could intercept or inject VCCV packets effectively 874 providing false positives or false negatives. 876 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 878 An intruder could deliberately flood a peer router with VCCV 879 messages to either obtain services without authorization or to 880 deny services to others. 882 A misconfigured or misbehaving device could inadvertantly flood 883 a peer router with VCCV messages which could result in a denial 884 of services. In particular, if a router is either implicitly or 885 explicitly indicated that it cannot support one or all of the 886 types of VCCV, but is sent those messages in sufficient quantity, 887 could result in a denial of service. 889 All of attacks above which concern the L2TPv3 or LDP control planes 890 may be countered by use of a control message authentication scheme 891 between LDP or L2TPv3 peers, such as the MD5-based scheme outlined in 892 [LDP] or [L2TPv3]. Implementation of IP address filters may also aid 893 in deterring these types of attacks. 895 VCCV message throttling mechanisms should be employed, especially in 896 distributed implementations which have a centralized control plane 897 processor with various line cards attached by some data path. In 898 these architectures VCCV messages may be processed on the central 899 processor after being forwarded there by the receiving line card. In 900 this case, the path between the line card and the control processor 901 may become saturated if appropriate VCCV traffic throttling is not 902 employed, which could lead to a denial of service. Such filtering is 903 also useful for preventing the processing of unwanted VCCV messages, 904 such as those which are sent on unwanted (and perhaps unadvertised) 905 control channel types or VCCV types. 907 VCCV spoofing requires MPLS PW label spoofing and spoofing the PSN 908 tunnel header. As far as the PW label is concerned the same consider- 909 ations as specified in [RFC3031] apply. If the PSN is a MPLS tunnel, 910 PSN tunnel label spoofing is also required. 912 10. Acknowledgements 914 The authors would like to thank Hari Rakotoranto, Michel Khouderchah, 915 Bertrand Duvivier, Vanson Lim, Chris Metz, W. Mark Townsley, Eric 916 Rosen, Dan Tappan,Danny McPherson and Luca Martini for their valuable 917 comments and suggestions. 919 11. References 921 11.1. Normative References 923 [RFC2119] "Key words for use in RFCs to Indicate Requirement 924 Levels.", Bradner, March 1997 926 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 928 [BFD] Katz, D., Ward, D., Bidirectional Forwarding 929 Indication, draft-ietf-bfd-03.txt, July 2005 931 [PWE3IANA] Martini, L., Townsley, M., "IANA Allocations for 932 pseudo Wire Edge to Edge Emulation (PWE3)", 933 draft-ietf-pwe3-iana-allocation-11.txt, June 934 2005. 936 [IANAPPP] IANA Point-to-Point Protocol Field Assignments, 937 April 12, 2004, 938 http://www.iana.org/assignments/ppp-numbers 940 [LSPPING] Kompella, K., G. Swallow, " Detecting MPLS Data Plane 941 Failures", Internet Draft draft-ietf-mpls-lsp-ping-09.txt, 942 May 2005. 944 [PWCTRL] Martini, L., et. al., "Pseudo Wire Setup and Maintenance 945 using LDP", draft-ietf-pwe3-control-protocol-17.txt, 946 June 2005 948 [ENETENCAP] Martini, L., et. al., "Encapsulation Methods for Trans- 949 port 950 of Ethernet Frames Over IP/MPLS Networks", 951 draft-ietf-pwe3-ethernet-encap-10.txt, June 2005. 953 [RFC3032] Rosen, E., Rehter, Y., Tappan, D., Farinacci, D., 954 Fedorkow, 955 G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 956 3032, January 2001. 958 [L2TPv3] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling 959 Protocol version 3", draft-ietf-l2tpext-l2tp-base-12.txt, 960 March 2004. 962 [ICMP] Postel, J. "Internet Control Message Protocol, RFC 792 964 [LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. 965 and B. Thomas, "Label Distribution Protocol", RFC 966 3036, January 2001. 968 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, 969 "Multiprotocol Label Switching Architecture", RFC 970 3031, January 2001. 972 [PW-CW] S. Bryant et. al., "PWE3 Control Word for use over an 973 MPLS PSN", draft-ietf-pwe3-cw-05.txt, June 2005. 975 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 977 11.2. Informative References 979 [MPLSOAMREQS] Nadeau, T., et al,"OAM Requirements for MPLS 980 Networks, Internet Draft 981 draft-ietf-oam-requirements-02.txt, June 2003. 983 [PWEARCH] Bryant, S., Pate, P., "PWE3 Architecture", RFC 3985, 984 March 2005 986 [PWREQ] Xiao, X., McPherson, D., Pate, P., "Requirements for 987 Pseudo Wire Emulation Edge to-Edge (PWE3)", 988 draft-ietf-pwe3-requirements-08.txt, December 2003 990 [BFDMPLS] R. Aggarwal, et al, "BFD for MPLS LSPs", Internet 991 Draft , June 2005. 993 [RFC2434] Narten, T. and H. Alvestrand., "Guidelines for Writing 994 an IANA Considerations Section in RFCs", BCP 26, RFC 995 2434, October 1998. 997 [OAM-MAP] T. Nadeau, et. al, "Pseudo Wire (PW) OAM Message Map- 998 ping", draft-ietf-pwe3-oam-msg-map-03.txt, 999 September 2005 1001 [RFC3036] Andersson, L, et al., "LDP Specification", 1002 RFC3036, January 2001. 1004 [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) 1005 Internet Assigned Numbers Authority (IANA) 1006 Considerations Update", BCP 68, RFC 3438, 1007 December 2002. 1009 [L2TPv3-ATM] Singh, S., "ATM over L2TPv3", 1010 draft-ietf-l2tpext-pwe3-atm-04 (work in progress), 1011 January 2006. 1013 [BFDV4V61HOP] Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single 1014 Hop)", draft-ietf-bfd-v4v6-1hop-04 (work in progress), 1015 October 2005. 1017 12. Editor Information 1019 Thomas D. Nadeau 1020 Cisco Systems, Inc. 1021 300 Beaver Brook Road 1022 Boxborough, MA 01719 1023 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 1025 Email: tnadeau@cisco.com 1027 Rahul Aggarwal 1028 Juniper Networks 1029 1194 North Mathilda Ave. 1030 Sunnyvale, CA 94089 1031 Email: rahul@juniper.net 1033 13. Contributor Information 1035 George Swallow 1036 Cisco Systems, Inc. 1037 300 Beaver Brook Road 1038 Boxborough, MA 01719 1039 Email: swallow@cisco.com 1041 Monique Morrow 1042 Cisco Systems, Inc. 1043 Glatt-com 1044 CH-8301 Glattzentrum 1045 Switzerland 1046 Email: mmorrow@cisco.com 1048 Yuichi Ikejiri 1049 NTT Communication Corporation 1050 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1051 Tokyo 100-8019 1052 Shinjuku-ku, JAPAN 1053 Email: y.ikejiri@ntt.com 1055 Kenji Kumaki 1056 KDDI Corporation 1057 KDDI Bldg. 2-3-2, 1058 Nishishinjuku, 1059 Tokyo 163-8003, 1060 JAPAN 1061 E-mail: ke-kumaki@kddi.com 1063 Peter B. Busschbach 1064 Lucent Technologies 1065 67 Whippany Road 1066 Whippany, NJ, 07981 1067 E-mail: busschbach@lucent.com 1069 Vasile Radoaca 1070 Nortel Networks 1071 Billerica, MA, 01803 1072 draft-ietf-pwe3-vccv-08 VCCV May 30, 2006 1074 Email: vasile@nortelnetworks.com 1076 14. Intellectual Property Statement 1078 The IETF takes no position regarding the validity or scope of any 1079 Intellectual Property Rights or other rights that might be claimed to 1080 pertain to the implementation or use of the technology described in 1081 this document or the extent to which any license under such rights 1082 might or might not be available; nor does it represent that it has 1083 made any independent effort to identify any such rights. Information 1084 on the procedures with respect to rights in RFC documents can be 1085 found in BCP 78 and BCP 79. 1087 Copies of IPR disclosures made to the IETF Secretariat and any 1088 assurances of licenses to be made available, or the result of an 1089 attempt made to obtain a general license or permission for the use of 1090 such proprietary rights by implementers or users of this specification 1091 can be obtained from the IETF on-line IPR repository at 1092 http://www.ietf.org/ipr. 1094 The IETF invites any interested party to bring to its attention any 1095 copyrights, patents or patent applications, or other proprietary 1096 rights that may cover technology that may be required to implement 1097 this standard. Please address the information to the IETF at ietf- 1098 ipr@ietf.org. 1100 15. Full Copyright Statement 1102 Copyright (C) The Internet Society (2006). This document is subject 1103 to the rights, licenses and restrictions contained in BCP 78, and 1104 except as set forth therein, the authors retain all their rights. 1106 This document and the information contained herein are provided on an 1107 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1108 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1109 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1110 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1111 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1112 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.