idnits 2.17.1 draft-ietf-pwe3-vccv-11.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1247. ** 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 2006) is 6402 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) == Unused Reference: 'IANAPPP' is defined on line 1116, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) -- No information found for draft-ietf-bfd - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BFD' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANAPPP' -- 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 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-v4v6-1hop-05 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Nadeau (Ed) 2 Internet Draft C. Pignataro (Ed) 3 Expiration Date: April 2007 Cisco Systems, Inc. 5 R. Aggarwal (Ed) 6 Juniper Networks 8 October 2006 10 Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) 12 draft-ietf-pwe3-vccv-11.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document describes Virtual Circuit Connection Verification 40 (VCCV) which provides a control channel that is associated 41 with a pseudo wire (PW), as well as the corresponding 42 operations and management functions such as connectivity 43 verification to be used over that control channel. VCCV 44 applies to all supported access circuit and transport types 45 currently defined for PWs. 47 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 49 Table of Contents 51 1 Specification of requirements .......................... 4 52 2 Introduction ........................................... 4 53 3 Overview of VCCV ....................................... 5 54 4 CC Types and CV Types ................................... 5 55 4.1 Bidirectional Forwarding Detection ...................... 7 56 4.1.1 BFD Encapsulation ....................................... 7 57 5 VCCV Control Channel for MPLS PSN ....................... 7 58 5.1 Inband VCCV (Type 1) .................................... 7 59 5.2 Out-of-Band VCCV (Type 2) ............................... 8 60 5.3 TTL Expiry VCCV (Type 3) ................................ 8 61 5.4 VCCV Connectivity Verification Types .................... 8 62 5.4.1 MPLS LSP Ping ........................................... 9 63 5.5 VCCV Capability Advertisement for MPLS PSN .............. 10 64 5.5.1 VCCV Capability Advertisement LDP Sub-TLV ............... 11 65 6 VCCV Control Channel for L2TPv3/IP PSN ................. 12 66 6.1 L2TPv3 VCCV Message .................................... 13 67 6.1.1 L2TPv3 VCCV using ICMP Ping ............................ 13 68 6.1.2 L2TPv3 VCCV using BFD .................................. 13 69 6.2 L2TPv3 VCCV Capability Indication ...................... 13 70 6.2.1 L2TPv3 VCCV Capability AVP ............................. 13 71 6.3 L2TPv3 VCCV Operation .................................. 14 72 7. Capability Advertisement Preference Order ............... 14 73 8. IANA Considerations .................................... 14 74 8.1 VCCV Parameter ID ...................................... 14 75 8.1.1 Control Channel Types (CC Types) ........................ 15 76 8.1.2 Connectivity Verification Types (CV Types) .............. 15 77 8.1.3 Channel Type ............................ .............. 15 78 8.2 L2TPv3 Assignments ..................................... 15 79 8.2.1 Control Message Attribute Value Pairs (AVPs) ........... 15 80 8.2.2 Default L2-Specific Sublayer bits ...................... 15 81 8.2.3 ATM-Specific Sublayer bits ............................. 15 82 8.2.4 VCCV Capability AVP Values ............................. 15 83 9 Security Considerations ................................ 15 84 10 Acknowledgements ....................................... 17 85 11 References ............................................. 17 86 11.1 Normative References ................................... 17 87 11.2 Informative References ................................. 18 88 12 Editor Information ...................................... 18 89 13 Contributor Information ................................ 19 90 14 Intellectual Property Statement ........................ 20 91 15 Full Copyright Statement ............................... 20 93 1. Specification of requirements 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Introduction 103 As network operators deploy pseudo wire (PW) services, fault detec- 104 tion and diagnostic mechanisms particularly for the PSN portion of 105 the network are pivotal. Specifically, the ability to provide end-to- 106 end fault detection and diagnostics for an emulated PW service is 107 critical for the network operator. Operators have indicated in 108 [RFC4377][RFC3916] that such a tool is required for PW deployments. 109 This document describes procedures for a PSN-agnostic fault 110 detection and diagnostics tool called Virtual Circuit Connection 111 Verification (VCCV). 113 |<----- Pseudo Wire ---->| 114 | | 115 Attachment or | |<-- PSN Tunnel -->| | Attachment or 116 Virtual | | | | Virtual 117 Circuit V V V V Circuit 118 | +----+ +----+ | 119 +----+ | | PE1|==================| PE2| | +----+ 120 | |----------|............PW1.............|----------| | 121 | CE1| | | | | | | |CE2 | 122 | |----------|............PW2.............|----------| | 123 +----+ | | |==================| | | +----+ 124 ^ +----+ +----+ | ^ 125 | Provider Edge 1 Provider Edge 2 | 126 | | 127 |<--------------- Emulated Service --------------->| 129 Customer Customer 130 Edge 1 Edge 2 132 Figure 2 illustrates the network reference model for point-to-point 133 PWs. 135 |<-------------- Emulated Service ---------------->| 136 | | 137 | <---------- VCCV ----------> | 138 | |<------- Pseudo Wire ------>| | 139 | | | | 140 | | |<-- PSN Tunnel -->| | | 141 | V V V V | 142 V AC +----+ +----+ AC V 143 +-----+ | | PE1|==================| PE2| | +-----+ 144 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 146 | |----------|............PW1.............|----------| | 147 | CE1 | | | | | | | | CE2 | 148 | |----------|............PW2.............|----------| | 149 +-----+ ^ | | |==================| | | ^ +-----+ 150 ^ | +----+ +----+ | | ^ 151 | | Provider Edge 1 Provider Edge 2 | | 152 | | | | 153 Customer | | Customer 154 Edge 1 | | Edge 2 155 | | 156 | | 157 Native service Native service 159 Figure 1: PWE3 VCCV Operation Reference Model 161 Figure 1 depicts the basic functionality of VCCV. VCCV provides 162 several means of creating a control channel between PEs that 163 attach the PW under test. 165 +-------------+ +-------------+ 166 | Layer2 | | Layer2 | 167 | Emulated | < Emulated Service > | Emulated | 168 | Services | | Services | 169 +-------------+ +-------------+ 170 | | VCCV/PW | | 171 |Demultiplexer| < Control Channel > |Demultiplexer| 172 +-------------+ +-------------+ 173 | PSN | < PSN Tunnel > | PSN | 174 +-------------+ +-------------+ 175 | Physical | | Physical | 176 +-----+-------+ +-----+-------+ 177 | | 178 | ____ ___ ____ | 179 | _/ ___/ \ _/ __ | 180 | / \__/ _ | 181 | / \ | 182 ---------| MPLS or IP Network |----- 183 | / 184 | ___ ___ __ ___/ 185 \_/ ____/ ___/ ____/ 187 Figure 2: PWE3 Protocol Stack Reference Model 188 including the VCCV control channel. 190 Figure 2 depicts how the VCCV control channel is associated with the 191 pseudo wire. Ping and other IP messages are encapsulated using the 192 PWE3 encapsulation as described below in sections 5 and 6. These mes- 193 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 195 sages, referred to as VCCV messages, are exchanged only after the 196 desire to exchange such traffic has been negotiated between the PEs 197 (see section 8). 199 3. Overview of VCCV 201 VCCV defines a set of messages that are exchanged between PEs to ver- 202 ify connectivity of the pseudo wire. To make sure that VCCV packets 203 follow the same path as the PW data flow, they SHOULD be encapsulated 204 with the same PW demultiplexer and trasported over the same PSN 205 tunnel. For example, if MPLS is the PSN in use, then the same 206 label shim header (and label stack) MUST be incorporated. The only 207 cases where this might not be possible is when out-of-band VCCV modes 208 are used which require this encapsulation to be altered; however, 209 these modes are discouraged. 211 VCCV can be used both as a fault detection and/or a diagnostic 212 tool for pseudowires. An operator can periodically invoke VCCV 213 for proactve connectivity verification on an active pseudowire, 214 or on an ad hoc or as-needed as a means of manual 215 connectivity verification. When invoking VCCV, the operator 216 triggers a combination of one of its various Connectivity Check 217 types (CC Type) and one of its various Connectivity Verification 218 (CV) Types. These include LSP-Ping, L2TPV3, or ICMP Ping [RFC792] 219 modes and are applicable depending on the underlying PSN. 221 Since a pseudowire service is bi-directional, the reply MAY be sent 222 in-band over the PW in the reverse direction. Responses MUST 223 be encapsulated so that they follow the return path of 224 the pseudowire in this case. In-band responses MUST be attempted 225 first. If an in-band test fails, the operator is advised to 226 then use a subsequent test using an out-of-band reply mode such 227 as Reply Mode 4 from [RFC4379], which will return the result 228 to the sender via an application level control channel to 229 determine the fault's direction. 231 The control channel maintained with VCCV can carry fault detection 232 status across a pseudowire and convey this information between 233 the endpoints of the pseudowire. Furthermore, this information 234 can then be translated into the native OAM status codes used by 235 the native access technologies, such as ATM or Ethernet. The 236 specific details of such status interworking is out of the scope 237 of this document, and is only noted here to illustrate the 238 utility of VCCV for such purposes. More complete details can 239 be found in [OAM-MAP]. 241 4. CC Types and CV Types 242 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 244 VCCV can support several types of connectivity verification 245 types (CV types) or protocols within its control channel, 246 but only one MUST be used once a PE has begun transmitting one. 247 The specific one chosen is based on the preferred order 248 specified below in section 7. If another is desired to be 249 used once a PE has begun to use one, the pseudowire MUST 250 be re-signaled. The specific type or types of VCCV packets 251 accepted by a router are indicated during capability 252 advertisement as described in section 4.5. The various VCCV 253 CV types supported MUST be used only when they apply 254 to the context of the PW demultiplexor in use. For example, 255 LSP Ping type should only be used when MPLS is utilized as 256 the PSN. 258 These type indicator fields are defined as a bitmask used 259 to indicate the specific CV or CC type or types (i.e.: none, 260 one or more) of control channel packets that may be sent on 261 the VCCV control channel. These values represent the numerical 262 value corresponding to the actual bit being set in the 263 bitfield. The definintion of each CV and CC Type is dependent 264 on the context within which it is defined; please refer to 265 the specific MPLS or L2TPv3 sections below. 267 The defined values for CC Types are for MPLS PWs are: 269 0x01 Type 1: PWE3 control word with 0001b as first nibble 270 as defined in [RFC4385]. 271 0x02 Type 2: MPLS Router Alert Label. 272 0x04 Type 3: MPLS PW Demultiplexor Label TTL = 1 (Type 3). 274 The defined values for CC Types are for L2TPv3 PWs are: 276 0x01 L2-Specific Sublayer with V-bit set. 277 0x02 Reserved for future use. 278 0x04 Reserved for future use. 280 The defined values for CV Types are for MPLS PWs are: 282 0x01 ICMP Ping. 283 0x02 LSP Ping. 284 0x04 BFD for PW Fault Detection Only. 285 0x08 BFD for PW Fault Detection and AC/PW Fault 286 Status Signaling. 287 0x10 BFD for PW Fault Detection Only. Carrying BFD payload 288 without IP headers. 289 0x20 BFD for PW Fault Detection and AC/PW Fault 290 Status Signaling. Carrying BFD payload without IP headers. 292 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 294 The defined values for CV Types are for L2TPv3 PWs are: 296 0x01 ICMP Ping. 297 0x02 Reserved for future use. 298 0x04 BFD for PW Fault Detection Only. 299 0x08 BFD for PW Fault Detection and AC/PW Fault 300 Status Signaling. 301 0x10 BFD for PW Fault Detection Only. Carrying BFD payload 302 without IP headers. 303 0x20 BFD for PW Fault Detection and AC/PW Fault 304 Status Signaling. Carrying BFD payload without IP headers. 306 It should be noted that two different pairs of CV Types have been 307 defined when BFD is used. If a capability advertisement is received 308 with both 0x04 and 0x08 types indicated, the PE MUST ignore the 0x08 309 bit as if it were set to 0. If a capability advertisement is 310 received with both 0x10 and 0x20 types indicated, the PE MUST ignore 311 the 0x20 bit as if it were set to 0. In the case of type 0x08 or 312 0x20, the AC and PW status SHOULD be conveyed via BFD status codes 313 as specified in [OAM-MAP]. However, this type SHOULD NOT be used 314 when a control protocol such as LDP or L2TPV3 is available that can 315 signal the AC/PW status to the remote endpoint of the PW 316 In the case of type 0x04 or 0x10, BFD is used exclusively to detect 317 faults on the PW and the status of those faults should be conveyed 318 using some means other than BFD, such as using LDP status messages 319 when using MPLS as a transport, or the Circuit Status 320 AVP in an L2TPv3 SLI message for L2TPv3 (see [RFC3931]). 321 If none of the types above are supported, the entire CV Type 322 Indicator field SHOULD be transmitted as 0x00 to indicate this 323 to the peer. 325 If no capability is signaled, then the peer MUST assume that 326 the peer has no VCCV capability and follow the procedures 327 specified in this document for this case. 329 4.1 Bidirectional Forwarding Detection 331 When heart-beat indication is necessary for one or more PWs, the 332 Bidirectional Forwarding Detection (BFD) [BFD] provides a 333 means of continuous monitoring of the PW data path and 334 propagation of forward and reverse defect indications. 336 In order to use BFD, both ends of the PW connection must have 337 signaled the existence of a control channel and the ability to run 338 BFD on it. Once a node has both signaled and received signaling from 339 its peer of these capabilities, it MUST begin sending BFD control 340 packets. The packets MUST be sent on the control channel. The use 341 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 343 of the control channel provides the context required to bind and 344 bootstrap the BFD session, thus single-hop BFD initialization 345 procedures are followed [BFD], and BFD MUST be run in asynchronous 346 mode [BFD]. 348 When one of the PEs (PE2 from Figure 1) doesn't receive control 349 messages from PE1 (from Figure 1) during the specified amount of 350 time it declares that the PW in the direction from PE2 to PE1 351 is down. 353 It stores the cause (e.g., Diagnostic code 1 - control detection time 354 expired) and sends a message to PE1 containing this diagnostic code. 355 This causes PE1 to declare the PW in the direction from PE1 to PE2 356 is down and it stores as cause: neighbor signaled session down. 357 Depending on the emulated services, PE2 may send a 358 forward direction indication (FDI) on its attachment 359 circuits and PE1 may send an RDI indication on its attachment 360 circuits [OAM-MAP]. 362 BFD defines the following diagnostics: 364 0 - No Diagnostic 365 1 - Control Detection Time Expired 366 2 - Echo Function Failed 367 3 - Neighbor Signaled Session Down 368 4 - Forwarding Plane Reset (Local equipment failure) 369 5 - Path Down (Alarm Suppression) 370 6 - Concatenated Path Down (Propagating access link alarm) 371 7 - Administratively Down 372 8 - Reverse Concatenated Path Down 374 Note that the value, 0 is used when the PW is up and 2 is not appli- 375 cable to asynchronous mode. 377 In cases where PW or AC status is received from both the signaling 378 protocol and VCCV via BFD status codes, the following algorithm 379 should be employed when transitioning the PW state based on these 380 values: 382 Transition from any state to "UP" state where the control plane 383 and BFD status both indicate that the PW is functioning correctly: 385 if (control plane == "UP" && BFD Status == "UP") 386 PW status = UP; 388 Transition from any state to "Down" state where either 389 the contorl or BFD status indicate that the PW is malfunctioning: 391 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 393 if (control plane == "UP" || BFD Status == "UP") 394 PW status = DOWN; 396 The VCCV message comprises a BFD packet [BFD] encapsulated 397 as specified by the CV Type (see Section 4.1.1). 399 4.1.1 BFD Encapsulation 401 VCCV defines two pairs of CV Types (see above) which specify 402 two ways in which the VCCV control channel may be encapsualted 403 when carrying a BFD payload. When the CV Type is either 0x04 or 404 0x08, the VCCV encapsulation includes the IP/UDP encapsulation 405 as defined in Section 4 of [BFDV4V61HOP]. However, when CV Type 406 0x10 or 0x20 is employed, the IP/UDP header is omitted. 407 In these cases the the corresponding PW CW's or L2SS' 408 Channel Type field MUST use the value defined in section 409 8.1.3 as a means of allowing the data plane to demultiplex 410 the control channel and identify the encased BFD payload. 412 5. VCCV Control Channel for MPLS PSN 414 When MPLS is used to transport PW packets, VCCV packets are 415 carried over the MPLS LSP as defined in this section. 416 In order to apply IP monitoring tools a PWE3 PW, an operator 417 may configure VCCV as a control channel for the PW between 418 the PEs endpoints [RFC3985]. Packets sent across this channel 419 from the source PE towards the destination PE either as in-band 420 traffic with the PW's data, or out-of-band. In all cases, the 421 control channel traffic MUST NOT be forwarded past the PE 422 endpoints towards the Customer Edge (CE) devices; instead, 423 they must be intercepted at the PE endpoints for exception 424 processing. 426 The capability of which control channel type (CC Type) to 427 use is advertised by a PE to indicate which of the various 428 control channel types are supported. Once the receiving PE 429 has chosen a mode to use, it MUST continue using this mode 430 until such time as the PW is re-signaled. Thus, if a new CC 431 type is desired, the PW must be torn-down and re-established. 433 Ideally such a control channel would be completely inband. When 434 a control word is present on the PW, it is possible to indi- 435 cate the control channel by setting a bit in the control word 436 header. 438 The following subsections define each of 439 the currently defined VCCV Control Channel Types (CC Types). 441 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 443 5.1. Inband VCCV (Type 1) 445 The PW set-up protocol [RFC4447] determines whether a PW uses a 446 control word. When a control word is used, it SHOULD have the 447 following form for the purpose of indicating VCCV control 448 channel messages. Note that for data, one uses the control 449 word defined just above the MPLS payload [RFC4385]. 451 The PW Associated Channel for VCCV control channel traffic is 452 defined as follows in [RFC4385]: 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 |0 0 0 1|Version| Reserved | Channel Type | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Figure 3: PW Associated Channel Header 462 The first nibble is set to 0001b to indicate a channel associated 463 with a pseudowire [RFC4385][RFC4446]. The Version and the Reserved 464 fields are set to 0, the Version is 0, and the Channel Type is set 465 to 0x21 for IPv4 and 0x56 for IPv6 payloads. If the payload contains 466 BFD without IP/UDP headers, it MUST use 0x07 as the Channel Type 467 (see 8.1.3). 469 For example, the following is an example of how the ethernet 470 ACH would be received [RFC4448] containing an LSP Ping payload 471 corresponding to a choice of CC Type of 0x01 and a CV Type of 472 0x02: 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 |0 0 0 1| 0 0 0 0 0 0 0 0 0 0 0 | 0x21 | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 Figure 4: PW Associated Channel Header for VCCV 482 It should be noted that although some PW types are not required 483 to carry the control word, this type of VCCV MUST only be used 484 for those PW types that do employ the control word when it is 485 in use. 487 This is the preferred mode of VCCV operation when the control word 488 is present. 490 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 492 5.2. Out-of-Band VCCV (Type 2) 494 A VCCV control channel can alternatively be created by using the 495 MPLS router alert label [RFC3032] immediately above the PW label. 496 It should be noted that this approach MAY result in a differnt 497 equal cost multi-path (ECMP) hashing behavior than pseudowire 498 PDUs and thus result in the VCCV control channel traffic taking 499 a path which differs from that of the actual data traffic under 500 test. 502 This is the preferred mode of VCCV operation when the control word 503 is not present. 505 5.3. TTL Expiry VCCV (Type 3) 507 The TTL of the PW label can be set to 1 to force the packet to be 508 processed within the destination router's control plane. This is 509 an inband control channel identification mechanism that is an 510 alternate to section 5.1. 512 To use this type, the control word MUST be used. 514 5.4 VCCV Connectivity Verification Types 516 5.4.1 MPLS LSP Ping 518 The LSP Ping header MUST be used in accordance with [RFC4379] 519 and MUST also contain the target FEC Stack containing the 520 sub-TLV of 8 for the L2 VPN endpoint or 9 or 10 for "FEC 128 521 Pseudowire" or 11 for the FEC 129 Pseudowire". The sub-TLV 522 indicates the PW to be verified. 524 5.5 VCCV Capability Advertisement for MPLS PSN 526 To permit the indication of the type or types of PW control chan- 527 nel(s), and connectivity verification mode or modes over a particular 528 PW, a VCCV parameter is defined below that is used as part of the PW 529 establishment signaling. When a PE signals a PW and desires PW OAM 530 for that PW, it MUST indicate this during PW establishment using the 531 messages defined below. Specifically, for PE MUST include the 532 VCCV parameter in the PW setup message [RFC4447]. 534 The decision of the type of VCCV control channel is left completely 535 to the receiving control entity, although the set of choices is 536 given by the sender in that it indicates the type or types of 537 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 539 control channels that it can understand. The receiver SHOULD 540 chose a single control channel type from the choices indicated 541 based on the order of preference rules specified below in 542 the section 7 and it MUST continue to use this type for 543 the duration of the life of the control channel. Changing control 544 channel types after one has been established to be in use 545 could potentially cause problems at the receiving end, and 546 could also lead to interoperability issues, thus it is strongly 547 discouraged. 549 When a PE sends a label mapping message for a PW, it uses 550 the VCCV parameter to indicate the type of OAM control channels 551 and connectivity verification type or types it is willing to 552 receive on that PW. The capablity of supporting a control 553 channel or channels, and connectivity type or types used 554 over that control channel or channels MUST be signaled before 555 the remote PE may send VCCV messages, and then only on the 556 control channel or channels, and using the connectivity 557 verification type or types indicated. 559 If a PE receives VCCV messages prior to advertising capability for 560 this message, it MUST discard these messages and not reply to them. 561 In this case, the PE SHOULD increment an error counter and optionally 562 issue a system and/or SNMP notification to indicate to the system 563 administrator that this condition exists. 565 When LDP is used as the PW signaling protocol the requesting PE 566 indicates its configured VCCV capability or capabilities to the 567 remote PE by including the VCCV parameter with appropriate options 568 indicating which control channel types it supports in the 569 interface parameter field of the PW ID FEC TLV (FEC 128) or in 570 the sub-TLV interface parameter of the Genralized PW ID FEC TLV 571 (FEC 129). The requesting PE MAY indicate that it supports 572 multiple control channel options, and in doing so agrees to support 573 any and all indicated types if transmitted to it, but MUST do so 574 in accordance with the rules stipulated in section 4.5.1 (VCCV 575 Capability Advertisement Sub-TLV). 577 Local policy may direct the PE to support certain OAM capability and 578 to indicate it. The absence of the VCCV parameter indicates that no 579 OAM functions are supported by the requesting PE, and thus the 580 receiving PE MUST NOT send any VCCV control channel traffic to it. 581 The reception of a VCCV parameter with no options set MUST be 582 ignored as if one is not transmitted at all. 584 The receiving PE similarly indicates its supported control channel 585 types in the response. These may or may not be the same as the 586 ones that were sent to it. The sender should examine the set that 587 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 589 is returned to understand which control channels it may establish 590 with the remote peer. Similarly, it MUST NOT send control channel 591 traffic to the remove PE for which the remote PE has not indicated 592 it supports. 594 The exception to the rules given in the last two paragraphs above 595 is when one side of the PW indicates no support for VCCV while the 596 other indicates support for at least one control channel type. In 597 this case, it is possible for one side of the PW to send VCCV 598 messages (either requests or replies to requests). 600 5.5.1 VCCV Capability Advertisement LDP Sub-TLV 602 [RFC4447] defines an Interface Parameter field in the LDP PW ID 603 FEC (FEC 128) and an Interface Parameters TLV in the LDP Generalized 604 PW ID FEC (FEC 129) to signal different capabilities for specific 605 PWs. An optional sub-TLV parameter is defined to indicate the 606 capability of supporting none, one or more control channel types 607 for VCCV. This is the VCCV parameter field. If FEC 128 is used the 608 VCCV parameter field is carried in the Interface Parameters field. 609 If FEC 129 is used it is carried as an Interface Parameter sub-TLV 610 in the Interface Parameters TLV. 612 The VCCV parameter ID is defined as follows in [RFC4446]: 614 Parameter ID Length Description 615 0x0c 4 VCCV 617 The format of the VCCV parameter field is as follows: 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | 0x0c | 0x04 | CC Types | CV Types | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 The Control Channel (CC Types) type field defines a bitmask used to 626 indicate the type of control channel(s) (i.e.: none, one or more) 627 that a router is capable of receiving control channel traffic on. 628 If more than one control channel is specified, the router agrees 629 to accept control traffic over either control channel; however, 630 see the rules specified in section 6 for more details. 631 If none of the types are supported, a CC Type Indicator of 0x00 632 SHOULD be transmitted to indicate this to the peer. However, 633 if no capability is signaled, then the PE MUST assume that its 634 peer is incapable of receiving any of the VCCV CC Types and 635 MUST NOT send any OAM control channel traffic to it. Note that 636 the CC and CV types definitions are consistent regardless of 637 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 639 the PW's transport or access circuit type. The CC and CV values 640 are defined below in Section 4. 642 6. VCCV Control Channel for L2TPv3/IP PSN 644 When L2TPv3 is used to setup a PW over an IP PSN, VCCV packets are 645 carried over the L2TPv3 session as defined in this section. L2TPv3 646 provides a "Hello" keepalive mechanism for the L2TPv3 control plane 647 that operates in-band over IP or UDP (see Section 4.4 of [RFC3931]). 648 This built-in Hello facility provides dead peer and path detection 649 only for the group of sessions associated with the L2TP Control 650 Connection. VCCV, however, allows individual L2TP sessions to be 651 tested. This provides a more granular mechanism which can be used to 652 troubleshoot potential problems within the dataplane of L2TP 653 endpoints themselves, or to provide additional connection status of 654 individual Pseudowires. 656 The capability of which control channel type (CC Type) to 657 use is advertised by a PE to indicate which of the various 658 control channel types are supported. Once the receiving PE 659 has chosen a mode to use, it MUST continue using this mode 660 until such time as the PW is re-signaled. Thus, if a new CC 661 type is desired, the PW must be torn-down and re-established. 663 In order to carry VCCV messages within an L2TPv3 session data packet, 664 the PW MUST be established such that an L2-Specific Sublayer (L2SS) 665 that defines the V-bit is present. This document defines the V-bit 666 for the Default L2-Specific Sublayer [RFC3931] and the ATM-Specific 667 Sublayer [RFC4454] using the Bit 0 position (see Section 8.2.2 and 668 Section 8.2.3). The L2-Specific Sublayer presence and type (either 669 the Default or a PW-Specific L2SS) is signaled via the L2-Specific 670 Sublayer AVP, Attribute Type 69, as defined in [RFC3931]. The V-bit 671 within the L2-Specific Sublayer is used to identify that a VCCV 672 message follows, and when the V-bit is set the L2SS has the following 673 format: 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 |1|0 0 0|Version| Reserved | Channel Type | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 L2-Specific Sublayer Format when the V-bit (bit 0) is set 683 The VCCV messages are distinguished from user data by the V-bit. The 684 V-bit is set to 1, indicating that a VCCV session message follows. 685 The next three bits MUST be set to 0 when sending and ignored upon 686 receipt. The remaining fields comprising 28 bits (i.e., Version, 687 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 689 Reserved and Channel Type) follow the same definition, format and 690 number registry from Section 5 of [RFC4385]. 692 Depending on the CV Type in use, the Channel Type can indicate IPv4, 693 IPv6 (see [RFC4385]) or BFD (see Section 8.1.3) as VCCV payload 694 directly following the L2SS. For CV Types of 0x01, 0x04 and 0x08, 695 the Channel Type can indicate IPv4 or IPv6; for CV Types of 0x10 696 and 0x20, the Channel Type indicates BFD Without IP/UDP Header. 698 6.1. L2TPv3 VCCV Message 700 The VCCV message over L2TPv3 directly follows the L2-Specific 701 Sublayer with the V-bit set. It could either contain an ICMP Echo 702 packet as described in Section 6.1.1, or a BFD packet as described in 703 Section 6.1.2. 705 6.1.1. L2TPv3 VCCV using ICMP Ping 707 When this connectivity verification mode is used, an ICMP Echo packet 708 [RFC792] achieves connectivity verification. The ICMP Ping packet 709 directly follows the L2SS with the V-bit set. In the ICMP Echo 710 request, the IP Header fields MUST have the following values: the 711 destination IP address is set to the remote LCCE's IP address for the 712 tunnel endpoint, the source IP address is set to the local LCCE's IP 713 address for the tunnel endpoint, and the TTL is set to 1. 715 6.1.2. L2TPv3 VCCV using BFD 717 The L2TPv3 Session ID provides the context to demultiplex the first 718 BFD control packet. See Section 4.1 and Section 4.1.1 for additional 719 details on BFD usage and BFD encapsulation. 721 6.2. L2TPv3 VCCV Capability Indication 723 An new optional AVP is defined in Section 6.2.1 to indicate the the 724 VCCV capabilities during session establishment. An LCCE MUST signal 725 its desire to use connectivity verification for a particular L2TPv3 726 session and its VCCV capabilities using the VCCV Capability AVP. 728 6.2.1. L2TPv3 VCCV Capability AVP 730 The "VCCV Capability AVP", Attribute type AVP-TBD, specifies the VCCV 731 capabilities as a pair of bitflags for the Control Channel (CC) and 732 Connectifity Verification (CV) Types. This AVP is exchanged during 733 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 735 session establishment (in ICRQ, ICRP, OCRQ or OCRP messages). The 736 value field has the following format: 738 VCCV Capability AVP (ICRQ, ICRP, OCRQ, OCRP) 740 0 1 741 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | CC Types | CV Types | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 CC Types: 748 The Control Channel (CC) Types field defines a bitmask used to 749 indicate the type of control channel(s) that may be used to 750 receive OAM traffic on for the given Session. The router agrees 751 to accept VCCV traffic at any time over any of the signaled VCCV 752 control channel types. CC Type values are defined in Section 4. 753 Although there is only one value defined in this document, the CC 754 Types field is included for forward compatibility should further 755 CC Types need to be defined in the future. 757 A CC Type of 0x01 may only be requested when there is an 758 L2-Specific Sublayer that defines the V-bit present. If a CC Type 759 of 0x01 is requested without requesting an L2-Specific Sublayer 760 AVP with an L2SS type that defines the V-bit, the session MUST be 761 disconnected with a CDN message. 763 If no CC Type is supported, a CC Type Indicator of 0x00 SHOULD be 764 sent. 766 CV Types: 768 The Connectifity Verification (CV) Types field defines a bitmask 769 used to indicate the specific type or types (i.e.: none, one or 770 more) of control packets that may be sent on the specified VCCV 771 control channel. CV Type values are defined in Section 4. 773 If no VCCV Capability AVP is signaled, then the LCCE MUST assume that 774 the peer is incapable of receiving VCCV and MUST NOT send any OAM 775 control channel traffic to it. 777 All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, and 778 Vendor ID. The Vendor ID for the VCCV Capability AVP MUST be 0, 779 indicating that this is an IETF-defined AVP. This AVP MAY be hidden 780 (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 781 0. The Length (before hiding) of this AVP is 8. 783 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 785 6.3. L2TPv3 VCCV Operation 787 An LCCE sends VCCV messages on an L2TPv3 signaled Pseudowire for 788 fault detection and diagnostic of the L2TPv3 session. The VCCV 789 message travels inband with the Session and follows the exact same 790 path as the user data for the session, because the IP header and 791 L2TPv3 Session header are identical. The egress LCCE of the L2TPv3 792 session intercepts and processes the VCCV message, and verifies the 793 signaling and forwarding state of the Pseudowire on reception of the 794 VCCV message. Any faults detected can be signaled in the VCCV 795 response. It is to be noted that the VCCV mechanism for L2TPv3 is 796 primarily targeted at verifying the Pseudowire forwarding and 797 signaling state at the egress LCCE. It also helps when L2TPv3 Control 798 Connection and Session paths are not identical. 800 An LCCE MUST NOT send VCCV packets on an L2TPv3 session unless it has 801 received VCCV capability by means of the VCCV Capability AVP from the 802 remote end. If an LCCE receives VCCV packets and its not VCCV 803 capable or it has not sent VCCV capability indication to the remote 804 end, it MUST discard these messages. It should also increment an 805 error counter. In this case the LCCE MAY optionally issue a system 806 and/or SNMP notification. 808 Additionally, because BFD is bidirectional in nature, when using BFD 809 as the connectivity verification type, an LCCE must send VCCV packets 810 on an L2TPv3 session only if it has signaled VCCV capability with a 811 BFD CV Type to the remote end and received VCCV capability with a 812 matching BFD CV Type from the remote end. 814 7. Capability Advertisement Preference Order 816 When a PE receives a VCCV capability advertisement, 817 the advertisement may potentially contain more than one CC or 818 CV Type. In this case, it MUST use the following rules when 819 choosing which CC or CV type to use. It may only choose one mode 820 based on the rules stipulated in sections 4 and 5 above. In 821 particular, once a valid CC Type is used by a PE (traffic 822 sent using that encapsulation), the PE MUST NOT send any 823 traffic down another CC Type encapsulation. 825 CC Types: 827 - PWE3 control word with 0001b as first nibble 828 - MPLS Router Alert Label 829 - MPLS PW Demultiplexor Label TTL = 1 830 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 832 For cases were multiple CC Types are advertised, 833 the following precedence rules apply when choosing: 835 - PWE3 control word with 0001b as first nibble 836 - MPLS PW Demultiplexor Label TTL = 1 837 - MPLS Router Alert Label 839 The following precidence rules are used for choosing 840 CV Type to use: 842 - LSP Ping. 843 - BFD for PW Fault Detection only. 844 - ICMP Ping. 845 - BFD for PW Fault Detection and AC/PW Fault. 846 Status Signaling. 847 - BFD for PW Fault Detection Only. Carrying BFD payload 848 without IP headers. 849 - BFD for PW Fault Detection and AC/PW Fault 850 Status Signaling. Carrying BFD payload without IP headers. 852 8. IANA Considerations 854 8.1. VCCV Parameter ID 856 The VCCC parameter ID codepoint is defined in [RFC4446]. IANA 857 is requested to maintain a registry for the CC Types and CV 858 Types, and bitmasks in the VCCV Parameter ID. The allocations 859 must be done using the "First Come First Served" policy 860 defined in RFC2434. IANA is requested to maintain the 861 following registries. 863 8.1.1. Control Channel Types (CC Types) 865 IANA is requested to set up a registry of "VCCV Control Channel 866 Types". These are 8-bit values. CV Type values 0x01, 0x02, and 0x04 867 are specified in this document, PW Type values 0x08, 0x16 868 and 0x24 are to be assigned by IANA using the "Expert Review" 869 policy defined in [RFC2434]. A VCCV Control Channel Type 870 description is required for any assignment from this registry. 871 A document reference should also be provided. 873 0x01 Type 1: PWE3 control word with 0001b as first nibble 874 as defined in [RFC4385]. 875 0x02 Type 2: MPLS Router Alert Label. 876 0x04 Type 3: MPLS PW Demultiplexor Label TTL = 1 (Type 3). 878 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 880 8.1.2. Connectivity Verification Types (CV Types) 882 IANA needs to set up a registry of "VCCV Control Channel Types". 883 These are 8-bit values. CV Type values 0x00, 0x01, 0x02, and 0x04 884 are specified in this document, CV Type values 0x16 885 and 0x24 are to be assigned by IANA using the "Expert Review" 886 policy defined in [RFC2434]. A VCCV CV Type description 887 is required for any assignment from this registry. 888 A document reference should also be provided. 890 0x01 ICMP Ping. 891 0x02 LSP Ping. 892 0x04 BFD for PW Fault Detection Only. 893 0x08 BFD for PW Fault Detection and AC/PW Fault 894 Status Signaling. 895 0x10 BFD for PW Fault Detection Only. Carrying BFD payload 896 without IP headers. 897 0x20 BFD for PW Fault Detection and AC/PW Fault 898 Status Signaling. Carrying BFD payload without IP headers. 900 8.1.3 Channel Type 902 The Channel Types used by VCCV as defined above in section 903 4.1, 4.2 and 4.3 rely on previously allocated numbers 904 from the Pseudowire Associated Channel Types Registry 905 [RFC4385]. In particular, 0x21 (Internet Protocol 906 version 4) MUST be used whenever an IPv4 payload 907 follows the pseudowire control word, or 0x57 MUST be used 908 when an IPv6 payload follows the pseudowire control word. 910 In cases where raw BFD follows the pseudowire control word 911 (i.e.: the IP/UDP encapsulation as specified in [BFD] 912 will not be present), a new Pseudowire Associated Channel 913 Types Registry [RFC4385] entry of 0x07 is used. IANA is 914 requested to reserve a new Channel Types value as follows: 916 Value (in hex) Protocol Name Reference 917 -------------- ------------------------------- --------- 919 0007 BFD Without IP/UDP Header [This document] 921 8.2. L2TPv3 Assignments 923 Sections 8.2.1 through 8.2.3 are registrations of new L2TP values for 924 name spaces already managed by IANA. Section 8.2.4 requests a new 925 registry to be added to the existing L2TP registry, and be maintained 926 by IANA accordingly. 928 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 930 8.2.1. Control Message Attribute Value Pairs (AVPs) 932 An additiona AVP Attribute is specified in Section 6.2.1. It is 933 required to be defined by IANA as described in Section 2.2 of 934 [RFC3438]. 936 Attribute 937 Type Description 938 --------- ---------------------------------- 939 AVP-TBD VCCV Capability AVP 941 8.2.2. Default L2-Specific Sublayer bits 943 The Default L2-Specific Sublayer contains 8 bits in the low-order 944 portion of the header. This document defines one reserved bits in 945 the Default L2-Specific Sublayer in Section 6, which may be assigned 946 by IETF Consensus [RFC2434]. It is required to be assigned by IANA. 948 Default L2-Specific Sublayer bits - per [RFC3931] 949 --------------------------------- 950 Bit 0 - V (VCCV) bit 952 8.2.3. ATM-Specific Sublayer bits 954 The ATM-Specific Sublayer contains 8 bits in the low-order portion of 955 the header. This document defines one reserved bits in the ATM- 956 Specific Sublayer in Section 6, which may be assigned by IETF 957 Consensus [RFC2434]. It is required to be assigned by IANA. 959 ATM-Specific Sublayer bits - per [RFC4454] 960 -------------------------- 961 Bit 0 - V (VCCV) bit 963 8.2.4. VCCV Capability AVP Values 965 This is a new registry for IANA to maintain. 967 IANA is requested to maintain a registry for the CC Types and CV 968 Types bitmasks in the VCCV Capability AVP, defined in Section 6.2.1. 969 The allocations must be done using the "Expert Review" policy defined 970 in [RFC2434]. A VCCV CC or CV Type description is required for any 971 assignment from this registry. A document reference should also be 972 provided. 974 IANA is requested to reserve the following bits in this registry: 976 VCCV Capability AVP (Attribute Type AVP-TBD) Values 977 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 979 --------------------------------------------------- 981 Control Channel (CC) Types 983 Bit 0 (0x01) - L2-Specific Sublayer with V-bit set. 984 Bit 1 (0x02) - Reserved 985 Bit 2 (0x04) - Reserved 986 Bit 3 (0x08) - Reserved 987 Bit 4 (0x10) - Reserved 988 Bit 5 (0x20) - Reserved 989 Bit 6 (0x40) - Reserved 990 Bit 7 (0x80) - Reserved 992 Connectifity Verification (CV) Types 994 Bit 0 (0x01) - ICMP Ping 995 Bit 1 (0x02) - Reserved 996 Bit 2 (0x04) - BFD for PW Fault Detection Only. 997 Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault 998 Status Signaling. 999 Bit 4 (0x10) - BFD for PW Fault Detection Only. Carrying 1000 BFD payload without IP headers. 1001 Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault 1002 Status Signaling. Carrying BFD payload 1003 without IP headers. 1004 Bit 6 (0x40) - Reserved 1005 Bit 7 (0x80) - Reserved 1007 9. Security Considerations 1009 Routers that implement the mechanism described herein are subject to 1010 to additional denial-of-service attacks as follows: 1012 An intruder may impersonate an LDP peer in order to 1013 force a failure and reconnection of the TCP connection. 1014 Please see the Security Considerations section of 1015 [RFC3036] details. 1017 An intruder could intercept or inject VCCV packets effectively 1018 providing false positives or false negatives. 1020 An intruder could deliberately flood a peer router with VCCV 1021 messages to either obtain services without authorization or to 1022 deny services to others. 1024 A misconfigured or misbehaving device could inadvertantly flood 1025 a peer router with VCCV messages which could result in a denial 1026 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 1028 of services. In particular, if a router is either implicitly or 1029 explicitly indicated that it cannot support one or all of the 1030 types of VCCV, but is sent those messages in sufficient quantity, 1031 could result in a denial of service. 1033 All of attacks above which concern the L2TPv3 or LDP control planes 1034 may be countered by use of a control message authentication scheme 1035 between LDP or L2TPv3 peers, such as the MD5-based scheme outlined in 1036 [RFC3036] or [RFC3931]. Implementation of IP address filters may 1037 also aid in deterring these types of attacks. 1039 VCCV message throttling mechanisms should be employed, especially in 1040 distributed implementations which have a centralized control plane 1041 processor with various line cards attached by some data path. In 1042 these architectures VCCV messages may be processed on the central 1043 processor after being forwarded there by the receiving line card. In 1044 this case, the path between the line card and the control processor 1045 may become saturated if appropriate VCCV traffic throttling is not 1046 employed, which could lead to a denial of service. Such filtering is 1047 also useful for preventing the processing of unwanted VCCV messages, 1048 such as those which are sent on unwanted (and perhaps unadvertised) 1049 control channel types or VCCV types. 1051 VCCV spoofing requires MPLS PW label spoofing and spoofing the PSN 1052 tunnel header. As far as the PW label is concerned the same consider- 1053 ations as specified in [RFC3031] apply. If the PSN is a MPLS tunnel, 1054 PSN tunnel label spoofing is also required. 1056 10. Acknowledgements 1058 The authors would like to thank Hari Rakotoranto, Michel Khouderchah, 1059 Bertrand Duvivier, Vanson Lim, Chris Metz, W. Mark Townsley, Eric 1060 Rosen, Dan Tappan, Danny McPherson and Luca Martini for their 1061 valuable comments and suggestions. 1063 11. References 1065 11.1. Normative References 1067 [RFC792] Postel, J. "Internet Control Message Protocol, 1068 RFC792, September 1981. 1070 [RFC2119] "Key words for use in RFCs to Indicate Requirement 1071 Levels.", Bradner, March 1997 1073 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, 1074 "Multiprotocol Label Switching Architecture", RFC 1076 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 1078 3031, January 2001. 1080 [RFC3032] Rosen, E., Rehter, Y., Tappan, D., Farinacci, D., 1081 Fedorkow, G., Li, T. and A. Conta, "MPLS Label 1082 Stack Encoding", RFC3032, January 2001. 1084 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. 1085 and B. Thomas, "Label Distribution Protocol", RFC 1086 3036, January 2001. 1088 [RFC3931] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling 1089 Protocol - Version 3 (L2TPv3)", RFC3931, March 2005. 1091 [RFC4385] Bryant, S., Martini, L., McPherson, D., 1092 "Pseudowire Emulation Edge-to-Edge (PWE3) 1093 Control Word for Use over an MPLS PSN", 1094 RFC4385, February 2006. 1096 [RFC4446] Martini, L., "IANA Allocations for 1097 Pseudo Wire Edge to Edge Emulation (PWE3)", 1098 RFC4446, April 2006. 1100 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., 1101 "Pseudowire Setup and Maintenance 1102 Using the Label Distribution Protocol (LDP)", 1103 RFC4447, April 2006. 1105 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., Heron, G., 1106 "Encapsulation Methods for Transport of Ethernet 1107 over MPLS Networks", RFC4448, April 2006. 1109 [RFC4379] Kompella, K., G. Swallow, " Detecting Multi-Protocol 1110 Label Switched (MPLS) Data Plane Failures", 1111 RFC4379, February 2006. 1113 [BFD] Katz, D., Ward, D., Bidirectional Forwarding 1114 Detection", draft-ietf-bfd-05.txt, June 2006. 1116 [IANAPPP] IANA Point-to-Point Protocol Field Assignments, 1117 April 12, 2004, 1118 http://www.iana.org/assignments/ppp-numbers 1120 11.2. Informative References 1122 [RFC4377] Nadeau, T., Swallow, G., Allan., D., 1123 "Operations and Management (OAM) Requirements 1124 for Multi-Protocol Label Switched (MPLS) Networks" 1125 RFC4377, February 2006. 1127 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 1129 [RFC3985] Bryant, S., Pate, P., "Pseudo Wire Emulation 1130 Edge-to-Edge Architecture", RFC 3985, March 2005. 1132 [RFC3916] Xiao, X., McPherson, D., Pate, P., "Requirements for 1133 Pseudo Wire Emulation Edge to-Edge (PWE3)", 1134 RFC3916, September 2004. 1136 [RFC2434] Narten, T. and H. Alvestrand., "Guidelines for Writing 1137 an IANA Considerations Section in RFCs", BCP 26, RFC 1138 2434, October 1998. 1140 [OAM-MAP] T. Nadeau, et. al, "Pseudo Wire (PW) OAM Message Map- 1141 ping", draft-ietf-pwe3-oam-msg-map-03.txt, 1142 September 2005 1144 [RFC3036] Andersson, L, et al., "LDP Specification", 1145 RFC3036, January 2001. 1147 [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) 1148 Internet Assigned Numbers Authority (IANA) 1149 Considerations Update", BCP 68, RFC 3438, 1150 December 2002. 1152 [RFC4454] Singh, S., Townsley, M., Pignataro, C., 1153 "Asynchronous Transfer Mode (ATM) over 1154 Layer 2 Tunneling Protocol Version 3 (L2TPv3)", 1155 RFC4454, March 2006. 1157 [BFDV4V61HOP] Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single 1158 Hop)", draft-ietf-bfd-v4v6-1hop-05, June 2006. 1160 12. Editor Information 1162 Thomas D. Nadeau 1163 Cisco Systems, Inc. 1164 300 Beaver Brook Road 1165 Boxborough, MA 01719 1166 Email: tnadeau@cisco.com 1168 Carlos Pignataro 1169 Cisco Systems, Inc. 1170 7025 Kit Creek Road 1171 PO Box 14987 1172 Research Triangle Park, NC 27709 1174 EMail: cpignata@cisco.com 1175 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 1177 Rahul Aggarwal 1178 Juniper Networks 1179 1194 North Mathilda Ave. 1180 Sunnyvale, CA 94089 1181 Email: rahul@juniper.net 1183 13. Contributor Information 1185 George Swallow 1186 Cisco Systems, Inc. 1187 300 Beaver Brook Road 1188 Boxborough, MA 01719 1189 Email: swallow@cisco.com 1191 Monique Morrow 1192 Cisco Systems, Inc. 1193 Glatt-com 1194 CH-8301 Glattzentrum 1195 Switzerland 1196 Email: mmorrow@cisco.com 1198 Yuichi Ikejiri 1199 NTT Communication Corporation 1200 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1201 Tokyo 100-8019 1202 Shinjuku-ku, JAPAN 1203 Email: y.ikejiri@ntt.com 1205 Kenji Kumaki 1206 KDDI Corporation 1207 KDDI Bldg. 2-3-2, 1208 Nishishinjuku, 1209 Tokyo 163-8003, 1210 JAPAN 1211 E-mail: ke-kumaki@kddi.com 1213 Peter B. Busschbach 1214 Lucent Technologies 1215 67 Whippany Road 1216 Whippany, NJ, 07981 1217 E-mail: busschbach@lucent.com 1219 Vasile Radoaca 1220 Nortel Networks 1221 Billerica, MA, 01803 1222 Email: vasile@nortelnetworks.com 1223 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006 1225 14. Intellectual Property Statement 1227 The IETF takes no position regarding the validity or scope of any 1228 Intellectual Property Rights or other rights that might be claimed to 1229 pertain to the implementation or use of the technology described in 1230 this document or the extent to which any license under such rights 1231 might or might not be available; nor does it represent that it has 1232 made any independent effort to identify any such rights. Information 1233 on the procedures with respect to rights in RFC documents can be 1234 found in BCP 78 and BCP 79. 1236 Copies of IPR disclosures made to the IETF Secretariat and any 1237 assurances of licenses to be made available, or the result of an 1238 attempt made to obtain a general license or permission for the use of 1239 such proprietary rights by implementers or users of this specification 1240 can be obtained from the IETF on-line IPR repository at 1241 http://www.ietf.org/ipr. 1243 The IETF invites any interested party to bring to its attention any 1244 copyrights, patents or patent applications, or other proprietary 1245 rights that may cover technology that may be required to implement 1246 this standard. Please address the information to the IETF at ietf- 1247 ipr@ietf.org. 1249 15. Full Copyright Statement 1251 Copyright (C) The Internet Society (2006). This document is subject 1252 to the rights, licenses and restrictions contained in BCP 78, and 1253 except as set forth therein, the authors retain all their rights. 1255 This document and the information contained herein are provided on an 1256 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1257 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1258 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1259 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1260 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1261 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1263 draft-ietf-pwe3-vccv-11 VCCV October 1, 2006