idnits 2.17.1 draft-ietf-pwe3-vccv-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 39 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 247: '...ntrol word is used, it SHOULD have the...' RFC 2119 keyword, line 314: '...l other VCCV types supported SHOULD be...' RFC 2119 keyword, line 336: '...capabilities, it MUST begin sending BF...' RFC 2119 keyword, line 337: '...ts. The packets MUST be sent on the c...' RFC 2119 keyword, line 340: '...ures are followed. BFD MUST be run in...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The receiving PE agrees to accept any of the indicated OAM types and options by virtue of establishing the PW. If it does not or cannot support at least one of the options specified, it MUST not establish the PW. If the requesting PE wishes to continue, it may choose different options and try to signal the PW again. -- 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 (June 2004) is 7253 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 321, but not defined == Missing Reference: 'PWSIG' is mentioned on line 246, but not defined == Missing Reference: 'PWE3CONTROL' is mentioned on line 433, but not defined == Unused Reference: 'LSPPING' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'PWCTRL' is defined on line 618, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-katz-ward-bfd-01 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANAPPP' == Outdated reference: A later version (-13) exists of draft-ietf-mpls-lsp-ping-05 == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-07 == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-06 == 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) -- No information found for draft-ietf-oam-requirements - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Thomas D. Nadeau 2 Internet Draft Cisco Systems, Inc. 3 Expires: December 2004 4 Rahul Aggarwal 5 Juniper Networks 6 Editors 8 June 2004 10 Pseudo Wire Virtual Circuit Connectivity 11 Verification (VCCV) 12 draft-ietf-pwe3-vccv-03.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Distribution of this document is unlimited. Please send comments to 34 the Multiprotocol Label Switching (mpls) Working Group, mpls@uu.net. 36 Abstract 38 This document describes Virtual Circuit Connection Verification 39 (VCCV) procedures for use with pseudo wire connections. VCCV 40 supports connection verification applications for pseudo wire 41 PWs regardless of the underlying public service network technology. 42 VCCV makes use of IP-based protocols to perform operations 43 and maintenance functions. This is accomplished by providing 44 a control channel associated with each pseudo wire. A network 45 operator may use the VCCV procedures to test the network's 46 forwarding plane liveliness. 48 Contents 49 Abstract.............................................................1 51 1. Contributors.........................................................1 52 2. Introduction.........................................................2 53 3. Overview of VCCV Modes of Operation..................................3 54 4. VCCV Control Channel Types for MPLS PSN..............................3 55 4.1 Inband VCCV ........................................................3 56 4.2 Out-of-band VCCV ...................................................4 57 4.3 TTL Expiry VCCV ....................................................4 58 5. VCCV Types ..........................................................5 59 5.1. MPLS LSP Ping Packet .............................................5 60 5.2 Bidirectional Forwarding Detection ...............................5 61 6. OAM Capability Indication ...........................................6 62 6.1. Optional VCCV Parameter ..........................................6 63 7. VCCV Control Channel for L2TPv3/IP PSN...............................8 64 7.1. L2TPv3 VCCV Message...............................................11 65 7.2. L2TPv3 VCCV Capability Indication.................................11 66 7.3. L2TPv3 VCCV Operation.............................................11 67 8. Acknowledgments.....................................................11 68 9. References..........................................................11 69 9.2 Normative References...............................................11 70 9.2 Informative References.............................................11 71 10. Security Considerations............................................12 72 11. Intellectual Property Rights Notices...............................12 73 12. Full Copyright Statement...........................................13 75 1. Contributors 77 Thomas D. Nadeau Rahul Aggarwal 78 Cisco Systems, Inc. Juniper Networks 79 300 Beaver Brook Road 1194 North Mathilda Ave. 80 Boxborough, MA 01719 Sunnyvale, CA 94089 81 Email: tnadeau@cisco.com Email: rahul@juniper.net 83 George Swallow Monique Morrow 84 Cisco Systems, Inc. Cisco Systems, Inc. 85 300 Beaver Brook Road Glatt-com 86 Boxborough, MA 01719 CH-8301 Glattzentrum 87 Email: swallow@cisco.com Switzerland 88 Email: mmorrow@cisco.com 90 Yuichi Ikejiri Kenji Kumaki 91 NTT Communication Corporation KDDI Corporation 92 1-1-6, Uchisaiwai-cho, Chiyoda-ku KDDI Bldg. 2-3-2, 93 Tokyo 100-8019 Nishishinjuku, 94 Shinjuku-ku, JAPAN Tokyo 163-8003, 95 Email: y.ikejiri@ntt.com JAPAN 96 E-mail: ke-kumaki@kddi.com 98 Peter B. Busschbach Vasile Radoaca 99 Lucent Technologies Nortel Networks 100 67 Whippany Road Billerica, MA, 01803 101 Whippany, NJ, 07981 Email: vasile@nortelnetworks.com 102 E-mail: busschbach@lucent.com 104 2. Introduction 106 As network operators deploy pseudo wire services, fault 107 detection and diagnostic mechanisms particularly for the PSN 108 portion of the network are pivotal. Specifically, the ability 109 to provide end-to-end fault detection and diagnostics for an 110 emulated pseudo wire service is critical for the network 111 operator. Operators have indicated in [MPLSOAMREQS][PWREQ] that 112 such a tool is required for pseudo wire deployments. This document 113 describes procedures for PSN-agnostic fault detection and 114 diagnostics called virtual circuit connection verification 115 (VCCV). 117 |<----- Pseudo Wire ---->| 118 | | 119 Attachment | |<-- PSN Tunnel -->| | Attachment 120 Circuit V V V V Circuit 121 | +----+ +----+ | 122 +----+ | | PE1|==================| PE2| | +----+ 123 | |----------|............PW1.............|----------| | 124 | CE1| | | | | | | |CE2 | 125 | |----------|............PW2.............|----------| | 126 +----+ | | |==================| | | +----+ 127 ^ +----+ +----+ | ^ 128 | Provider Edge 1 Provider Edge 2 | 129 | | 130 |<--------------- Emulated Service --------------->| 131 |<---------- VCCV ------>| 132 Customer Customer 133 Edge 1 Edge 2 135 Figure 1: PWE3 VCCV Operation Reference Model 137 Figure 1 depicts the basic functionality of VCCV. VCCV provides 138 several means of creating a control channel between PEs that 139 attaches the PW under test. 141 +-------------+ +-------------+ 142 | Layer2 | | Layer2 | 143 | Emulated | Emulated Service | Emulated | 144 | Services | | Services | 145 +-------------+ +-------------+ 146 | | VCCV/pseudo wire | | 147 |Demultiplexer| Control Channel |Demultiplexer| 148 +-------------+ +-------------+ 149 | PSN | PSN Tunnel | PSN | 150 +-------------+ +-------------+ 151 | Physical | | Physical | 152 +-----+-------+ +-----+-------+ 153 | | 154 | ____ ___ ____ | 155 | _/ \___/ \ _/ \__ | 156 | / \__/ \_ | 157 | / \ | 158 ---------| MPLS or IP Network |----- 159 \ / 160 \ ___ ___ __ _/ 161 \_/ \____/ \___/ \____/ 163 Figure 2: PWE3 Protocol Stack Reference Model 164 including the VCCV control channel. 166 Figure 2 depicts how the VCCV control channel is associated 167 with the pseudo wire. Ping and other IP messages are encapsulated 168 using the PWE3 encapsulation as described below in sections 5 and 169 6. These messages, referred to as VCCV messages, are exchanged 170 only after the desire to exchange such traffic has been 171 negotiated between the PEs (see section 8). 173 3. Overview of VCCV 175 VCCV defines a set of messages that are exchanged between PEs to 176 verify connectivity of the pseudo wire. To make sure that pseudo wire 177 packets follow the same path as the data flow, they are encapsulated 178 with the same labels. VCCV can operate in two modes: 180 1) as a diagnostic tool 181 2) as a fault detection tool 183 In the diagnostic mode, the operator triggers LSP-Ping, L2TPV3, 184 or ICMP Ping [ICMP] modes depending on the underlying PSN. Since a 185 pseudo wire is bi-directional, it makes sense to require that the 186 reply is send over the PSN tunnel that makes up the other half 187 of the PW under test. For example, if the PSN is an MPLS LSP, 188 the reply should be sent on the LSP representing the reverse 189 path. If this fails, the operator can use other reply modes to 190 determine what is wrong. The specific type of reply mode is 191 indicated during PW circuit set-up (see section 6). 193 The fault detection mode provides a way to emulate fault 194 detection mechanisms in other technologies, such as ATM for 195 example. For example, in the fault detection mode, the BFD 196 (Bidirectional Forward mechanism) mechanism can be used as following: 197 the upstream PE sends BFD control messages periodically. When 198 the downstream PE doesn't receive these message for a defined 199 period of time, it declares that direction of the PW down and 200 it notifies the upstream PE. Based on the emulated service, the 201 PEs may send native indications over the related attachment 202 circuits to notify the end points of the fault condition. The 203 specific details of the handling of these conditions is out of 204 the scope of this document, and are only noted here to illustrate 205 the utility of VCCV for these purposes. 207 3.1 LSP Ping 209 When the PSN is MPLS, the LSP Ping header is used as described 210 in [LSP-PING] as a connectivity verification and diagnostic 211 tool for pseudo wires. 213 3.2 L2TPV3 215 When IP is used as the PSN, various protocols can be deployed for PW 216 Demultiplexing (see [PWEARCH]). If L2TP or UDP is used, ICMP ECHO 217 packets [ICMP] can be used as the means by which connectivity 218 verification is achieved. If MPLS is used for PW Demultiplexing, the 219 LSP Ping header is used as described in [LSP-PING] for verifying the 220 connectivity status of pseudo wires. 222 3.4 Bidirectional Forwarding Detection 224 When fault detection indication is necessary for one or more 225 pseudo wires, the Bidirectional Forwarding Detection (BFD) 226 [BFD] provides a light-weight means of continuous 227 monitoring and propagation of forward and reverse defect 228 indications. BFD can be used regardless of the underlying 229 PSN technology. 231 4. VCCV Control Channel Types for MPLS PSN 233 In order to apply IP monitoring tools to PWE3 circuits, VCCV 234 creates a control channel between PWE3 PEs[PWEARCH]. Packets 235 sent across this channel are IP packets, allowing maximum 236 flexibility. 238 Ideally such a control channel would be completely in band. 239 When a control word is present on virtual circuit, it is 240 possible to indicate the control channel by setting a bit in 241 the control header. This method is described in section 4.1 242 and is referred to as PWE3 inband VCCV. 244 4.1. Inband VCCV 246 The PW set-up protocol [PWSIG] determines whether a PW uses 247 a control word. When a control word is used, it SHOULD have the 248 following form for the purpose of indicating VCCV 249 control channel messages. Note that for data, one uses the 250 control word defined just above the MPLS payload [PWEARCH]. 252 The PWE3 payload type identifier for VCCV control channel 253 traffic is defined as follows: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 |0 0 0 1| Control Word-specific Information | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 For example, the following is an example of how the ethernet 262 control 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| reserved = 0 | PA=0 |PPP DLL Proto Number=0021/0057 | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 The first nibble is set to 0x0001, the protocol of the frame is 271 indicated by the Protocol Number. IP OAM flows are identified by 272 either an IPv4 (0021) or IPv6 (0057) codepoint [IANAPPP]. 274 It should be noted that pseudo-wires are not required to 275 carry the control word, and that this method can only be 276 used for those pseudo-wires that do. 278 4.2. Out-of-Band VCCV 280 When the control word is not used, or the receiving hardware 281 cannot divert control traffic based on information in the control 282 word (i.e.: older hardware), MPLS is utilized as the PSN, 283 a VCCV control channel can be created alternatively by including 284 the MPLS router alert label [RFC3032] immediately above the PW label. 285 If the control word is in use on this VC it is also included in the 286 VCCV control flow. It should be noted that this approach may 287 alter equal cost multi-path (ECMP) hashing behavior, and thus 288 the VCCV traffic may take a path which differs from that of the 289 data traffic under test. 291 4.3 TTL Expiry VCCV 293 The TTL of the inner label can be set to 1 to force the packet 294 to be processed within the destination router's control plane. 295 This is an inband control channel identification mechanism that 296 is an alternate to section 4.1. 298 It should be noted that this mode may not work in cases 299 where the penultimate hop overwrites the TTL values of 300 labels underneith the top-most label. Some older implementations 301 do this, and the result would be a false positive. Therefore, 302 we recommend that operators investigate the TTL behavior 303 of the routers in their networks to determine if this 304 situation can occur, and if it is discovered that it can, 305 that this mode should not be used for the reasons explained. 307 5. VCCV Types 309 VCCV can carry several types of protocols that can be used 310 on the control channel either at the same time, or serially. 311 The specific type or types of VCCV accepted by a router 312 are indicated during signaling as described in section 6. 313 With the exception of the BFD protocol which applies to 314 all PSN types, all other VCCV types supported SHOULD be 315 used only when they apply to the PSN in use. For example, 316 the LSP Ping type should only be used when MPLS is utilized 317 as the PSN. 319 5.1. MPLS LSP Ping Packet 321 The LSP Ping header must be used as described [LSP-PING] and 322 must also contain the sub-TLV of 8 for the L2 VPN endpoint or 323 9 for the L2 circuit ID. The sub-TLV indicate the the 324 circuit to be verified. 326 5.2 Bidirectional Forwarding Detection 327 When heart-beat indication is necessary for one or more 328 pseudo wires, the Bidirectional Forwarding Detection (BFD) 329 [BFD] provides a light-weight means of continuous 330 monitoring and propagation of forward and reverse defect 331 indications. 333 In order to use BFD, both ends of the pseudo wire connection must 334 have signaled the existence of a control channel and the ability to 335 run BFD. Once a node has both signaled and received signaling from 336 its peer of these capabilities, it MUST begin sending BFD control 337 packets. The packets MUST be sent on the control channel. The use 338 of the control channel provides the context required to bind the 339 BFD session to a particular pseudo wire (FEC). Thus normal BFD 340 initialization procedures are followed. BFD MUST be run in 341 asynchronous mode. 343 It may be desirable to use LSP-Ping additionally for periodic 344 diagnostics in addition to BFD for fault detection on the same 345 PW [BFDMPLS]. 347 When one of the PEs (PE2) doesn't receive control messages 348 from PE1 during the specified amount of time, or if it 349 determines that reachability to PE1 is no longer available, it 350 declares that the PW in the direction from PE2 to PE1 is down. 351 It stores the cause (e.g. control detection time expired) and 352 sends a message to PE1 with H (i.e. "I don't hear you"). In 353 turn, PE1 declares the PW in the direction from PE1 to PE2 354 down and stores as cause: neighbor signaled session down. 355 Depending on the emulated services, PE2 may send a FDI 356 indication on its attachment circuits and PE1 may send an RDI 357 indication on its attachment circuits. 359 BFD defines the following diagnostics: 361 0 -- No Diagnostic 362 1 -- Control Detection Time Expired 363 2 -- Echo Function Failed 364 3 -- Neighbor Signaled Session Down 365 4 -- Forwarding Plane Reset (Local equipment failure) 366 5 -- Path Down (Alarm Suppression) 367 6 -- Concatenated Path Down (Propagating access link alarm) 368 7 -- Administratively Down 370 Of these, 0 is used when the PW is up and 2 is not applicable 371 to asynchronous mode. 373 6. OAM Capability Indication 375 To permit the advertisement of the type of pseudo wire control 376 channel or channels, and connectivity verification mode or modes 377 over a particular pseudo wire, a VCCV parameter is defined below 378 that is used as part of the pseudo wire establishment signaling. 379 When a PE signals a pseudo wire and desires pseudo wire OAM for that 380 pseudo wire, it MUST indicate this during PW establishment using the 381 messages defined below. Specifically for LDP the PE MUST include the 382 VCCV parameter in the PW setup message. 384 As the overall method of PWE3 signaling is downstream, 385 unsolicited, the decision of the type of VCCV control channel is 386 left completely to the receiving control entity. When a PE sends 387 a label for a PW, it uses the VCCV parameter to indicate the type 388 of OAM control channels and connectivity verification type or types 389 it is willing to receive on that pseudo wire. The capablity of 390 supporting a control channel or channels, and connectivity type or 391 types used over that control channel or channels MUST be signaled 392 BEFORE the remote PE may send VCCV messages, and then only on the 393 control channel or channels, and using the connectivity verification 394 type or types indicated. 396 If a PE receives VCCV messages prior to advertising capability for 397 this message, it MUST discard these messages and not reply 398 to them. In this case, the PE SHOULD increment an error counter 399 and optionally issue a system and/or SNMP notification to indicate 400 to the system administrator that this condition exists. Further 401 action should be taken to prevent the remote PE from continuing 402 to send the unwanted messages. 404 The requesting PE indicates its configured VCCV capability or 405 capabilities to the remote PE by including the VCCV parameter with 406 appropriate options indicating which methods of OAM it supports in 407 the interface parameter sub-TLV portion of the FEC TLV. 408 The requesting PE MAY indicate that it supports multiple control 409 channel options, and in doing so agrees to support any and all 410 advertised types if transmitted to it. Local policy may direct the 411 PE to support certain OAM capability and to advertise it. The absence 412 of the VCCV interface parameter sub-TLV in the FEC TLV indicates that 413 no OAM functions are supported by the requesting PE, and thus the 414 receiving PE MUST NOT send any VCCV control channel traffic to it. 415 The reception of a VCCV sub-TLV with no options set MUST be ignored as 416 if one is not transmitted at all. 418 The receiving PE agrees to accept any of the indicated 419 OAM types and options by virtue of establishing the PW. If 420 it does not or cannot support at least one of the options 421 specified, it MUST not establish the PW. If the requesting 422 PE wishes to continue, it may choose different options and 423 try to signal the PW again. 425 6.1. Optional VCCV Parameter 427 [PWE3CONTROL] defines a PW FEC Interface TLV Parameters for LDP. 428 Parameters can be carried within that TLV to signal different 429 capabilities for specific PWs. We propose an optional parameter 430 to be used to indicate the desire to use a control channel for 431 VCCV as follows. 433 The TLV field structure is defined in [PWE3CONTROL]. 434 The VCCV parameter ID is defined as follows in [PWE3IANA]: 436 Parameter ID Length Description 437 0x0c 4 VCCV 439 The format of the VCCV parameter TLV is as follows: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | 0x0c | 0x04 | CC Types | CV Types | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 The Control Channel (CC) type field defines a bitmask used to indicate 448 the type of control channel(s) (i.e.: none, one or both) that 449 may be used to receive OAM control channel traffic on. If more than 450 one is specified, the router agrees to accept control traffic at any 451 time over either control channel. If none of the types are supported, 452 a CC Type Indicator of 0x00 SHOULD be transmitted to indicate this to 453 the peer. However, if no capability is signaled, then the peer MUST 454 assume that the peer is incapable of receiving VCCV and MUST NOT 455 send any OAM control channel traffic to it. 457 0x01 PWE3 control word with 0x0001 as first nibble 458 0x02 MPLS Router Alert Label 459 0x04 MPLS inner label TTL = 1 461 The CV Type Indicators field defines a bitmask used to indicate the 462 specific type or types (i.e.: none, one or more) of control 463 channel packets that may be sent on the specified control channel. 464 The defined values are: 466 0x01 ICMP Ping 467 0x02 LSP Ping 468 0x04 BFD 470 If none of the types above are supported, a CV Type Indicator 471 of 0x00 SHOULD be transmitted to indicate this to the peer. However, 472 if no capability is signaled, then the peer MUST assume that 473 the peer has no VCCV capability. 475 7. VCCV Control Channel for L2TPv3/IP PSN 477 When L2TPv3 is used to setup a PW over an IP PSN, VCCV packets are 478 carried over the L2TPv3 session as defined in this section. It should 479 be noted that L2TPv3 has a built-in "Hello" keepalive mechanism for 480 its control plane that operates "in-band" over IP with respect to 481 the IP protocol number, port (when UDP is used), source and destination 482 IP addresses. This built-in Hello mechanism provides connection status 483 only for the group of sessions associated with the L2TP Control 484 Channel. VCCV, however, allows individual L2TP sessions to be tested. 485 This provides a more granular mechanism which can be used to 486 troubleshoot potential problems deeper within the dataplane of L2TP 487 endpoints themselves, or to provide additional connection status of 488 individual pseudo wires. 490 In order to carry VCCV messages within an L2TPv3 session data packet, 491 the default L2-Specific Sublayer MUST be present. The presence of this 492 field is signaled via the L2-Specific Sublayer AVP as defined in 493 [L2TPv3]. The 'V' bit within the Default L2-Specific Sublayer is used 494 to identify that a VCCV message follows. 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 |V|S|x|x|x|x|x|x| Sequence Number | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Default L2-Specific Sublayer Format with V bit. 504 The 'V' bit indicates that a VCCV session message follows. 505 If the PW has not been signaled to include a L2-specific sublayer 506 format, other mechanisms are needed to indicate the VCCV message. 507 Such mechanisms are for further study. 509 7.1. L2TPv3 VCCV Message 511 The VCCV message MUST contain a VCCV AVP. It does not contain a 512 messageheader. This could either be a new VCCV ICMP Ping AVP or VCCV 513 BFD AVP. The usage of the L2TPv3 AVP format leaves room for adding 514 further AVPs to this message in the future as needed. 516 7.1.1. L2TPv3 VCCV ICMP Ping AVP 518 This AVP encodes the ICMP Ping Echo Packet [ICMP]. This AVP may be 519 followed by the L2TPv3 Remote End Identifier AVP to identify the 520 pseudo wire associated with the session. 522 7.1.2. L2TPv3 VCCV BFD AVP 523 This AVP encodes a BFD packet that is used to verify the session. 524 When heart-beat indication is necessary for one or more 525 pseudo wires, the Bidirectional Forwarding Detection (BFD) 526 [BFD] provides a light-weight means of continuous 527 monitoring and propagation of forward and reverse defect 528 indications. 530 BFD MUST be run in asynchronous mode. BFD control packets [BFD] are 531 encapsulated in the AVP. The L2TPv3 session provides the context to 532 demultiplex the first BFD control packet. 534 The L2TPv3 VCCV BFD AVP may be followed by the L2TPv3 Remote End 535 Identifier AVP to identify the pseudo wire associated with the session. 537 7.2. L2TPv3 VCCV Capability Negotiation 539 A LCCE or a LAC should be able to indicate whether the session is 540 capable of processing VCCV packets. This is done by including the 541 optional VCCV capability AVP in an ICRQ, ICRP, OCRQ or OCRP. 543 7.2.1. L2TPv3 VCCV Capability AVP 545 This AVP specifies the VCCV capability. Its attribute type 546 is TBD. The value field has the following format: 548 0 1 549 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Reserved | CV Type | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 The CV Type Indicators field defines a bitmask used to indicate the 555 specific type or types (i.e.: none, one or more) of IP control 556 packets that may be sent on the specified control channel. The 557 defined values are: 559 0x01 ICMP Ping 560 0x02 BFD 562 If none of the types above are supported, a CV Type Indicator 563 of 0x00 SHOULD be transmitted to indicate this to the session peer. 564 However, if no capability is signaled, then the peer MUST assume that 565 the other peer has no VCCV capability. 567 7.3. L2TPv3 VCCV Operation 569 A PE sends VCCV echo requests on a L2TPv3 signaled pseudo wire for 570 fault detection and diagnostic of the L2TPv3 session. The destination 571 IP address in the echo request is set to the remote PE's IP address, 572 while the source IP address is set to the local PE's IP address. The 573 egress of the L2TPv3 session verifies the signaling and forwarding 574 state of the pseudo wire, on reception of the VCCV message. Any faults 575 detected can be signaled in the VCCV echo response. Its to be noted 576 that the VCCV mechanism for L2TPv3 is primarily targeted at verifying 577 the pseudo wire forwarding and signaling state at the egress PE. It 578 also helps when L2TPv3 control and session paths are not identical. 580 A PE must send VCCV packets on a L2TPv3 session only if it has 581 signaled VCCV capability to the remote end and received VCCV capability 582 from the remote end. If a PE receives VCCV packets and its not VCCV 583 capable or it has not received VCCV capability indication from the 584 remote end, it must discard these messages. In addition if a PE receives 585 VCCV messages and it has not received VCCV capability from the remote 586 end, it should increment an error counter. In this case the PE can 587 optionally issue a system and/or SNMP notification. 589 8. Acknowledgments 591 The authors would like to thank Hari Rakotoranto, Michel 592 Khouderchah, Bertrand Duvivier, Vanson Lim, Chris Metz, W. Mark 593 Townsley, Eric Rosen, Dan Tappan,Danny McPherson and Luca Martini 594 for their valuable comments and suggestions. 596 9. References 598 9.1 Normative References 600 [BFD] Katz, D., Ward, D., Bidirectional Forwarding 601 Indication, draft-katz-ward-bfd-01.txt, August 602 2003. 604 [PWE3IANA] Martini, L., Townsley, M., "IANA Allocations for 605 pseudo Wire Edge to Edge Emulation (PWE3)", 606 draft-ietf-pwe3-iana-allocation-04.txt, April 607 2004. 609 [IANAPPP] IANA Point-to-Point Protocol Field Assignments, 610 April 12, 2004, 611 http://www.iana.org/assignments/ppp-numbers 613 [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow, 614 G., Wadhwa, S., Bonica, R., " Detecting MPLS Data Plane 615 Failures", Internet Draft draft-ietf-mpls-lsp-ping-05.txt, 616 February 2004. 618 [PWCTRL] Martini, L., et. al., "Pseudo Wire Setup and Maintenance 619 using LDP", draft-ietf-pwe3-control-protocol-07.txt, 620 June 2004 622 [ENETENCAP] Martini, L., et. al., "Encapsulation Methods for Transport 623 of Ethernet Frames Over IP/MPLS Networks", 624 draft-ietf-pwe3-ethernet-encap-06.txt, April 2004. 626 [RFC3032] Rosen, E., Rehter, Y., Tappan, D., Farinacci, D., Fedorkow, 627 G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 628 3032, January 2001. 629 [L2TPv3] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling 630 Protocol version 3", draft-ietf-l2tpext-l2tp-base-12.txt, 631 March 2004. 633 [ICMP] Postel, J. "Internet Control Message Protocol, RFC 792 635 [LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. 636 and B. Thomas, "Label Distribution Protocol", RFC 637 3036, January 2001. 639 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, 640 "Multiprotocol Label Switching Architecture", RFC 641 3031, January 2001. 643 9.2 Informative References 645 [MPLSOAMREQS] Nadeau, T., et al,"OAM Requirements for MPLS 646 Networks, Internet Draft 647 draft-ietf-oam-requirements-02.txt, June 2003. 649 [PWEARCH] Bryant, S., Pate, P., "PWE3 Architecture", Internet 650 Draft, draft-ietf-pwe3-arch-07.txt, March 2004 652 [PWREQ] Xiao, X., McPherson, D., Pate, P., "Requirements for 653 Pseudo Wire Emulation Edge to-Edge (PWE3)", 654 draft-ietf-pwe3-requirements-08.txt, December 2003 656 [BFDMPLS] R. Aggarwal, et al, "BFD for MPLS LSPs", Internet 657 Draft , October 2003. 659 10. Security Considerations 661 Routers that implement the mechanism described herein are 662 subject to to additional denial-of-service attacks as follows: 664 An intruder may impersonate an LDP peer in order to 665 force a failure and reconnection of the TCP connection, but 666 where the intruder sets the Recovery Time to 0 on 667 reconnection. 669 An intruder could intercept the traffic between LDP or 670 peers and override the setting of the TCP Recovery Time to 671 be set to 0. 673 An intruder could inject traffic into the TCP connection 674 and effectively masquerade as an LDP peer. The same is 675 possible for the UDP stream between L2TPv3 peers. In doing 676 so could falsely advertise VCCV capabilities to a peer. 678 An intruder could intercept or inject VCCV packets effectively 679 providing false positives or false negatives. 681 An intruder could deliberately flood a peer router with VCCV 682 messages to either obtain services without authorization or to 683 deny services to others. 685 A misconfigured or misbehaving device could inadvertantly flood 686 a peer router with VCCV messages which could result in a denial 687 of services. In particular, if a router is either implicitly or 688 explicitly indicated that it cannot support one or all of the 689 types of VCCV, but is sent those messages in sufficient quantity, 690 could result in a denial of service. 692 All of attacks above which concern the L2TPv3 or LDP control planes 693 may be countered by use of a control message authentication scheme 694 between LDP or L2TPv3 peers, such as the MD5-based scheme outlined 695 in [LDP] or [L2TPv3]. Implementation of IP address filters may also 696 aid in deterring these types of attacks. 698 VCCV message throttling mechanisms should be employed, 699 especially in distributed implementations which have a centralized 700 control plane processor with various line cards attached by some 701 data path. In these architectures VCCV messages may be processed 702 on the central processor after being forwarded there by the receiving 703 line card. In this case, the path between the line card and the 704 control processor may become saturated if appropriate VCCV traffic 705 throttling is not employed, which could lead to a denial of service. 706 Such filtering is also useful for preventing the processing 707 of unwanted VCCV messages, such as those which are sent on unwanted 708 (and perhaps unadvertised) control channel types or VCCV types. 710 VCCV spoofing requires MPLS PW label spoofing and spoofing the PSN 711 tunnel header. As far as the PW label is concerned the same 712 considerations as specified in [RFC3031] apply. If the PSN is a 713 MPLS tunnel, PSN tunnel label spoofing is also required. 715 11. Intellectual Property Rights Notices 716 The IETF takes no position regarding the validity or scope of any 717 intellectual property or other rights that might be claimed to 718 pertain to the implementation or use of the technology described in 719 this document or the extent to which any license under such rights 720 might or might not be available; neither does it represent that it 721 has made any effort to identify any such rights. Information on 722 the IETF's procedures with respect to rights in standards-track and 723 standards-related documentation can be found in BCP-11. Copies of 724 claims of rights made available for publication and any assurances 725 of licenses to be made available, or the result of an attempt made 726 to obtain a general license or permission for the use of such 727 proprietary rights by implementers or users of this specification 728 can be obtained from the IETF Secretariat. 729 The IETF invites any interested party to bring to its attention any 730 copyrights, patents or patent applications, or other proprietary 731 rights which may cover technology that may be required to practice 732 this standard. Please address the information to the IETF 733 Executive Director. 735 11. Full Copyright Statement 737 Copyright (C) The Internet Society (2003). All Rights 738 Reserved. 739 This document and translations of it may be copied and 740 furnished to others, and derivative works that comment on 741 or otherwise explain it or assist in its implementation may 742 be prepared, copied, published and distributed, in whole or 743 in part, without restriction of any kind, provided that the 744 above copyright notice and this paragraph are included on 745 all such copies and derivative works. However, this 746 document itself may not be modified in any way, such as by 747 removing the copyright notice or references to the Internet 748 Society or other Internet organizations, except as needed 749 for the purpose of developing Internet standards in which 750 case the procedures for copyrights defined in the Internet 751 Standards process must be followed, or as required to 752 translate it into languages other than English. 753 The limited permissions granted above are perpetual and 754 will not be revoked by the Internet Society or its 755 successors or assigns. This document and the information 756 contained herein is provided on an "AS IS" basis and THE 757 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 758 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 759 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 760 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 761 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 762 PURPOSE.