idnits 2.17.1 draft-nadeau-pwe3-vccv-01.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 == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 1) being 79 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 4 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 178: '...word is used, it SHOULD have the follo...' RFC 2119 keyword, line 295: '... MUST indicate this during VC establ...' RFC 2119 keyword, line 296: '...cally for LDP it MUST include the VCCV...' RFC 2119 keyword, line 302: '... OAM capability MUST be signaled BEFO...' RFC 2119 keyword, line 304: '...CV parameter, it MUST discard these me...' (5 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 requesting PE indicates its desire for the remote PE to support OAM capability by including the VCCV parameter with appropriate options set to indicate which methods of OAM are acceptable. The requesting PE MAY indicate multiple IP control IP control channel options. The absence of the VCCV FEC TLV indicates that no OAM functions are supported or desired by the requesting PE. This last method MUST be supported by all PEs in order to handle backward-compatibility with older PEs. The receiving PE agrees to accept any of the indicated OAM types and options by virtue of establishing the VC. If it does not or cannot support at least one of the options specified, it MUST not establish the VC. If the requesting PE wishes to continue, it may choose different options and try to signal the PE 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'PWEARCH' is mentioned on line 534, but not defined == Missing Reference: 'LSP-PING' is mentioned on line 456, but not defined == Missing Reference: 'MARTINISIG' is mentioned on line 547, but not defined == Unused Reference: 'PWREQ' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'PWE3FW' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'GTTP' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'ITU-T' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'ICMP' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'PWEATM' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'OAMMsgMap' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'PPVPNFW' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'SAJASSI' is defined on line 585, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 588, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PWREQ' -- No information found for - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PWE3FW' -- Possible downref: Non-RFC (?) normative reference: ref. 'L2SIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'LSPPING' -- Possible downref: Non-RFC (?) normative reference: ref. 'GTTP' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T' -- Possible downref: Non-RFC (?) normative reference: ref. 'PWEATM' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLSOAMREQS' -- No information found for draft-nadeau-pwe3-OAMMap - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'OAMMsgMap' -- Possible downref: Non-RFC (?) normative reference: ref. 'PWE3CONTROL' -- Possible downref: Non-RFC (?) normative reference: ref. 'PPVPNFW' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAJASSI' Summary: 7 errors (**), 0 flaws (~~), 17 warnings (==), 16 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:November 2003 4 Rahul Aggarwal 5 Juniper Networks 6 Editors 8 June 2003 10 Pseudo Wire (PW) Virtual Circuit Connection Verification 11 (VCCV) 12 draft-nadeau-pwe3-vccv-01.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 psuedowire connections. VCCV 40 supports connection verification applications for pseudowire 41 VCs regardless of the underlying MPLS or IP tunnel technology. 42 VCCV makes use of IP based protocols such as Ping and MPLS-Ping 43 to perform operations and maintenance functions. A network 44 operator may use the VCCV procedures to test the network's 45 forwarding plane liveliness. 47 Contents 49 Abstract.................................................1 50 1. Contributors.............................................1 51 2. Introduction.............................................2 52 3 MPLS as PSN..............................................3 53 4. IP Probe Traffic.........................................5 54 5. OAM Capability Indication................................6 55 6. L2TPv3/IP as PSN.........................................8 56 7. Acknowledgments.........................................11 57 8. References..............................................11 58 9. Security Considerations.................................12 59 10. Intellectual Property Rights Notices...................12 60 11. Full Copyright Statement...............................13 62 1. Contributors 64 Thomas D. Nadeau Rahul Aggarwal 65 Cisco Systems, Inc. Juniper Networks 66 250 Apollo Drive 1194 North Mathilda Ave. 68 Chelmsford, MA 01824 Sunnyvale, CA 94089 69 Email: tnadeau@cisco.com Email: rahul@juniper.net 71 George Swallow Monique Morrow 72 Cisco Systems, Inc. Cisco Systems, Inc. 73 250 Apollo Drive Glatt-com 74 Chelmsford, MA 01824 CH-8301 Glattzentrum 75 Email: swallow@cisco.com Switzerland 76 Email: mmorrow@cisco.com 78 Yuichi Ikejiri Kenji Kumaki 79 NTT Communications Corporation KDDI Corporation 80 1-1-6, Uchisaiwai-cho, Chiyoda-ku KDDI Bldg. 2-3-2, 81 Tokyo 100-8019 Nishishinjuku, Shinjuku-ku, 82 JAPAN Tokyo 163-8003, 83 Email: y.ikejiri@ntt.com JAPAN 84 E-mail : ke-kumaki@kddi.com 86 2. Introduction 88 As network operators deploy pseudowire services, fault 89 detection and diagnostic mechanisms particularly for the PSN 90 portion of the network are pivotal. Specifically, the ability 91 to provide end-to-end fault detection and diagnostics for an 92 emulated pseudowire service is critical for the network 93 operator. Operators have indicated in [MPLSOAMREQS] that such 94 a tool is required for pseudowire deployments. This document 95 describes procedures for PSN-agnostic fault detection and 96 diagnostics called virtual circuit connection verification 97 (VCCV). 99 |<------- pseudowire ------>| 100 | |<-- PSN Tunnel -->| | 101 PW V V V V PW 102 End Service +----+ +----+ End Service 103 +-----+ | | PE1|==================| PE2| | +-----+ 104 | |----------|............PW1.............|------------| | 105 | CE1 | | | | | | | | CE2 | 106 | |----------|............PW2.............|------------| | 107 +-----+ | | |==================| | | +-----+ 108 Customer | +----+ +----+ | Customer 109 Edge 1 | Provider Edge 1 Provider Edge 2 | Edge 2 110 |<----------- Emulated Service ---------->| 111 |<---------- VCCV ---------->| 113 Figure 1: PWE3 VCCV Operation Reference Model 115 Figure 1 depicts the basic functionality of VCCV. VCCV provides 116 several means of creating a control channel between PEs that 117 attaches the VC under test. 119 +-------------+ +-------------+ 120 | Layer2 | | Layer2 | 121 | Emulated | | Emulated | 122 | Services | Emulated Service | Services | 123 | |<==============================>| | 124 +-------------+ VCCV/pseudowire +-------------+ 125 |Demultiplexer|<==============================>|Demultiplexor| 126 +-------------+ +-------------+ 127 | PSN | PSN Tunnel | PSN | 128 | MPLS |<==============================>| MPLS | 129 +-------------+ +-------------+ 130 | Physical | | Physical | 131 +-----+-------+ +-----+-------+ 132 | | 133 | ____ ___ ____ | 134 | _/ \___/ \ _/ \__ | 135 | / \__/ \_ | 136 | / \ | 137 +========/ MPLS or IP Network |===+ 138 \ / 139 \ ___ ___ __ _/ 140 \_/ \____/ \___/ \____/ 142 Figure 2: PWE3 Protocol Stack Reference Model 143 including the VCCV control channel. 145 Figure 2 depicts how the VCCV control channel is run along 146 with the pseudowire to verify specific VCs. Ping and other 147 IP messages are encapsulated using the PWE3 encapsulation 148 as described below in sections 5 and 6. These messages, referred 149 to as VCCV messages, are exchanged only after the desire to 150 exchange such traffic has been negotiated between the PEs 151 (see section 8). 153 3. MPLS as PSN 155 In order to apply IP monitoring tools to PWE3 circuits, VCCV 156 creates a control channel between PWE3 PEs[PWEARCH]. Packets 157 sent across this channel are IP packets, allowing maximum 158 flexibility. 160 Ideally such a control channel would be completely in band. 161 When a control word is present on virtual circuit, it is 162 possible to indicate the control channel by setting a bit in 163 the control header. This method is described in section 7.1 164 and is referred to as inband MPLS VCCV. 166 However in order to address the case when the control header 167 is not in use as well as to deal with a number of existent 168 hardware devices, use of the MPLS Router Alert Label to indicate 169 the IP control channel is also proposed. This is described in 170 section 7.2. 172 The actual channel type is agreed through signaling as 173 described in section 8. 175 3.1. Inband MPLS VCCV 177 The PW set-up protocol determines whether a PW uses a control word. 178 When a control word is used, it SHOULD have the following preferred 179 form: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 |0 0 0 0| Flags |FRG| Length | Sequence Number | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 for the purpose of indicating VCCV control channel messages. 189 Note that for data, one uses the control word defined just 190 above the MPLS payload [PWEARCH] . 192 The MPLS payload type is defined as follows: 194 0 1 2 3 195 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |0 0 0 1| reserved | PPP DLL Protocol Number 199 | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | As defined by PPP DLL protocol definition 203 | 204 | 205 | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 The first nibble 0000 indicates data. When the first nibble is 210 0001, the protocol of the frame is indicated by the Protocol 211 Number. IP OAM flows are identified by either an IPv4 or IPv6 212 codepoint. 214 3.2. Router Alert Label Approach 216 When the control word is not used, or the receiving hardware 217 cannot divert control traffic, an IP control channel can be 218 created by including the MPLS router alert label immediately 219 above the VC label. If the control word is in use on this VC 220 it is also included in the IP control flow. 222 0x1 OAM Flag in PWE header 223 0x2 Include the control channel label in stack above VC 224 label 226 4. IP Probe Traffic 228 For connectivity verification, both ICMP Ping and LSP-Ping 229 packets may be used on the control channel. The type of 230 packets used is agreed in signaling as described in section 9. 232 4.1. ICMP Ping 234 When ICMP packets are used, the source address should be set 235 to the source address of the LDP session and the destination 236 address to the destination of the LDP session. The Identifier 237 and Sequence Number fields of the ICMP Echo Request / Echo 238 Reply messages are used to track what VCs are being tested. 240 These fields are only interpreted by the sending PE. Specific 241 use of these fields is an implementation matter. 243 4.2. MPLS Ping Packet 245 The LSP Ping header must be used as described [LSP-PING] and 246 must also contain the sub-TLV of 8 for PW circuits. This 247 sub-TLV must be sent containing the circuit to be verified as 248 the "VC ID" field: 250 4.2.1 L2 Circuit ID TLV for MPLS LSP Ping 252 The value field consists of a remote PE address (the address 253 of the targeted LDP session), the source address of the PE 254 that originated this request, a VC ID and an encapsulation 255 type, as follows. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Remote PE Address | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Source PE Address | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 |PWID Type |PWID Length | PWID | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Parameters | 269 | " | 270 | " | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Two PWID types are defined: 275 1. A FEC 128 VCID as defined in [MARTINISIG]. 276 2. A FEC 129 Attachment Identifier, as defined [L2SIG]. 278 The PWID length field contains the length of the 279 PWID field in bytes. Zero to three bytes of padding will follow 280 the PWID field, so that the parameters field starts on a 64-bit 281 boundary. 283 Parameters are: 285 - Interface parameters, as defined in [MARTINISIG]. 287 ***Note that we propose that this field be removed from the 288 LSP Ping draft [LSPPING] and defined here instead. 290 5. OAM Capability Indication 292 To permit negotiation of the use and type of OAM for 293 Connectivity Verification, a VCCV parameter is defined below. 294 When a PE signals a PWE3 VC and desires OAM for that VC, it 295 MUST indicate this during VC establishment using the messages 296 defined below. Specifically for LDP it MUST include the VCCV 297 parameter in the VC setup message. 299 As the overall method of PWE3 signaling is 300 downstream, unsolicited, this leaves the decision of the type 301 of IP control channel completely to the receiving control 302 entity. OAM capability MUST be signaled BEFORE a PE may send 303 OAM messages. If a PE receives OAM messages prior to sending 304 a VCCV parameter, it MUST discard these messages and not reply 305 to them. In this case, the LSR SHOULD increment an error counter 306 and optionally issues a system and/or SNMP notification to indicate 307 to the system administrator that a mis-configuration exists. 309 The requesting PE indicates its desire for the remote PE to 310 support OAM capability by including the VCCV parameter with 311 appropriate options set to indicate which methods of OAM are 312 acceptable. The requesting PE MAY indicate multiple IP control 313 IP control channel options. The absence of the VCCV FEC TLV 314 indicates that no OAM functions are supported or desired by 315 the requesting PE. This last method MUST be supported by all 316 PEs in order to handle backward-compatibility with older PEs. 317 The receiving PE agrees to accept any of the indicated 318 OAM types and options by virtue of establishing the VC. If 319 it does not or cannot support at least one of the options 320 specified, it MUST not establish the VC. If the requesting 321 PE wishes to continue, it may choose different options and 322 try to signal the PE again. 324 5.1. Optional VCCV Parameter 326 [PWE3CONTROL] defines a VC FEC TLV for LDP. Parameters can be 327 carried within that TLV to signal different capabilities for 328 specific PWs. We propose an optional parameter to be used to 329 indicate the desire to use a control channel for VCCV as 330 follows. 332 The TLV field structure is defined in [PWE3CONTROL] as 333 follows: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Parameter ID | Length | Variable Length Value | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Variable Length Value | 341 | " | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 The VCCV parameter ID is defined as follows: 346 Parameter ID Length Description 347 0x06 4 VCCV 349 The format of the VCCV parameter TLV is as follows: 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | 0x06 | 0x04 | CC Type | CV Types | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 The CC type field defines the type of IP control channel. 358 The defined values are: 360 0x1 OAM Flag set in PWE header 361 0x2 MPLS Router Alert Label 363 The CV Types field defines the types of IP control packets 364 that may be sent on the control channel. The defined values 365 are: 367 0x1 ICMP Ping 368 0x2 LSP Ping 370 6. L2TPV3 as PSN 372 When L2TPv3 is used as the underlying PSN, a VCCV mechanism is 373 needed for the L2TPv3 session. The L2TPv3 control connection does 374 employ a keepalive mechanism. However this mechanism isn't 375 sufficent for fault detection and diagnostic of the L2TPv3 session 376 i.e. data plane. In L2TPv3 a session is analogous to a PW. A L2TPv3 377 VCCV mechanism is needed in particular for verifying the session 378 forwarding state at the egress router. 380 When a PE verifies the connection status of a L2TPv3 session it must 381 transmit a L2TPv3 VCCV message encoded in the L2TPv3 session packet. 383 The presence of a VCCV message in a L2TPv3 session packet can be 384 indicated by reserving a bit in the default L2-specific sublayer 385 format. 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 |P|S|V|x|x|x|x|x| Sequence Number | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Default L2-Specific Sublayer Format with V bit. 395 The 'V' bit indicates that this is a VCCV session packet. If the PW 396 has not been signaled to include a L2-specific sublayer format, other 398 mechanisms are needed to indicate the VCCV message. Such mechanisms are 399 for further study. 401 6.1. L2TPv3 VCCV Message 403 The VCCV message MUST contain a VCCV AVP. It does not contain a message 404 header. A new AVP, called the VCCV AVP is defined. The usage of the 405 L2TPv3 AVP format leaves room for adding further AVPs to this message 407 in the future as needed. 409 6.1.1. L2TPv3 VCCV AVP 411 This AVP encodes the LSP Ping header as defined in [LSP-PING]. M and H 412 bits must not be set. The attribute type is TBD. The LSP Ping header is 413 not encapsulated in UDP. The modifications to the semantics of the 414 fields of this header are specified here. Unless otherwise specified 415 the semantics of the fields as explained in [LSP-PING] are to be 416 followed. For reference the format of the LSP Ping header is shown 417 below. 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Version Number | Must Be Zero | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Message Type | Reply mode | Return Code | Return Subcode| 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Sender's Handle | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Sequence Number | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | TimeStamp Sent (seconds) | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | TimeStamp Sent (microseconds) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | TimeStamp Received (seconds) | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | TimeStamp Received (microseconds) | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | TLVs ... | 439 . . 440 . . 441 . . 442 | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 The version number is currently 1. The message type is one of the 446 following: 448 1 - L2TPv3 VCCV Echo Request 449 2 - L2TPv3 VCCV Echo Reply 451 The Reply Mode is: 453 1 - Do not reply 454 2 - Reply using the L2TPv3 session 456 As explained in [LSP-PING] a reply mode of "do not reply" can be used 458 for one way connectivity tests. The VCCV message will normally contain 459 a reply mode of "reply using the L2TPv3 session". 461 The return code can be set to the following by the receiver: 463 1 - Malformed echo request received 464 2 - One or more of the TLVs was not understood 465 3 - Replying router has a session mapping for the verified pseudo wire 466 4 - Replying router does not have a mapping for the verified pseudo 467 wire 469 The LSP Ping header must contain the L2 Circuit ID TLV as defined in 470 section 8.2. This TLV identifies the pseudo wire associated with the 471 session, that is being verified. For L2TPv3 the remote PE address is 472 the address of the session's remote end. A new PWID type is defined 473 for L2TPv3, in addition to the ones defined in section 8.2: 475 3. L2TPv3 Remote End Identifier AVP 477 6.2. L2TPv3 VCCV Capability Negotiation 479 A LCCE or a LAC should be able to indicate whether the session is 480 capable of processing VCCV packets. This is done by including the 481 optional VCCV capability AVP in an ICRQ, ICRP, OCRQ or OCRP. 483 6.2.1. L2TPv3 VCCV Capability AVP 485 This AVP specifies the VCCV capability. Its attribute type 486 is TBD. The value field has the following format: 488 0 1 489 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 491 | Reserved | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 494 6.3. L2TPv3 VCCV Operation 496 A PE sends VCCV echo requests on a L2TPv3 signaled pseudo wire for 497 fault detection and diagnostic of the L2TPv3 session. The destination 499 IP address in the echo request is set to the remote PE's IP address, 500 while the source IP address is set to the local PE's IP address. The 501 egress of the L2TPv3 session verifies the signaling and forwarding state 502 of the pseudo wire, on reception of the VCCV message. Any faults 503 detected can be signaled in the VCCV echo response. Its to be noted 504 that the VCCV mechanism for L2TPv3 is primarily targeted at verifying 506 the pseudo wire forwarding and signaling state at the egress PE. It 507 also helps when L2TPv3 control and session paths are not identical. 509 A PE must send VCCV packets on a L2TPv3 session only if it has signaled 510 VCCV capability to the remote end and received VCCV capability from the 511 remote end. If a PE receives VCCV packets and its not VCCV capable or 513 it has not received VCCV capability indication from the remote end, it 514 must discard these messages. In addition if a PE receives VCCV messages 515 and it has not received VCCV capability from the remote end, it should 516 increment an error counter. In this case the PE can optionally issue a 517 system and/or SNMP notification. 519 7. Acknowledgments 521 The authors would like to thank Hari Rakotoranto, Michel 522 Khouderchah, Bertrand Duvivier, Vanson Lim, Chris Metz, W. 523 Mark Townsley, Eric Rosen, Dan Tappan, and 524 Danny McPherson for their valuable comments and suggestions. 526 8. References 528 [PWREQ] Xiao, X., McPherson, D., Pate, P., Gill, V., 529 Kompella, K., Nadeau, T., White, C., "Requirements 530 for Pseudo Wire Emulation Edge-to-Edge (PWE3)", 531 , November 2001. 532 [PWE3FW] Prayson Pate, et al., Internet draft, Framework for 533 Pseudo Wire Emulation Edge-to-Edge (PWE3), draft- 534 ietf-pwe3-framework-01.txt, work in progress. [PWEARCH] Bryant, 535 S., Pate, P., Johnson, T., Kompella, K., 536 Malis, A., McPherson, D., Nadeau, T., So, T., Townsley, 537 W., Systems, White., C., Wood, L., Xiao, X., Internet 538 draft, Framework for Pseudo Wire Emulation Edge-to-Edge 539 (PWE3), draft-ietf-pwe3-framework-01.txt, work in 540 progress. 541 [L2SIG] Rosen, E., LDP-based Signaling for L2VPNs, 542 Internet Draft , 543 September 2002. 544 [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D., 545 Swallow, G., Wadhwa, S., Bonica, R., " Detecting 546 Data Plane Liveliness in MPLS", Internet Draft 547 , April 2003. [MARTINISIG] 548 "Transport of Layer 2 Frames Over MPLS", Martini et. 549 al., draft-martini-l2circuit-trans-mpls-10.txt, 550 August 2002 551 [GTTP] Bonica, R., Kompella, K., Meyer, D., "Generic 552 Tunnel Tracing Protocol (GTTP) Specification", Internet 553 Draft , April, 2003 [FRF 8.1] 554 Frame Relay Forum, Frame Relay / ATM PVC Service 555 Interworking Implementation Agreement, February 2000 556 [ITU-T] "Draft Recommendation Y.17fw" (MPLS Management 557 Framework), July 2002. 558 [ITU-T] "Frame Relay Bearer Service Interworking," I.555, 559 September 2997. 560 [ITU-T], "Frame Relay Operations Principles and Functions", 561 I.620, October, 1996. 562 [ITU-T] Q.933, ISDN Digital Subscriber Signalling System 563 No. 1 (DSS 1) - Signalling specification for frame 564 mode basic call control, November 1995. 565 [ICMP] Postel, J. "Internet Control Message Protocol, " 566 RFC 792 567 [PWEATM] Martini, L., et al., "Encapsulation Methods for 568 Transport of ATM Cells/Frame Over IP and MPLS 569 Networks", Internet Draft , October 2002 571 [MPLSOAMREQS] Nadeau, T., et al,"OAM Requirements for MPLS 572 Networks, Internet Draft , January 2003. 574 [OAMMsgMap] Nadeau, T., et al, " Pseudo Wire (PW) OAM Message 575 Mapping, Internet Draft < draft-nadeau-pwe3-OAMMap.txt>, 576 December, 2002. 577 [PWE3CONTROL] L.Martini et al., "Transport of Layer 2 Frames 578 over MPLS, Internet Draft, , May 2003 580 [PPVPNFW] Callon, R., Suzuki, M., Gleeson, B., Malis, A., 581 Muthukrishnan, K., Rosen, E., Sargor, C., and J. Yu, 582 "A Framework for Provider Provisioned Virtual 583 Private Networks", Internet Draft , July 2001. 585 [SAJASSI] A.Sajassi et al., "L2VPN Interworking," Internet 586 Draft , 587 November 2002. 588 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, 589 "Multiprotocol Label Switching Architecture", RFC 590 3031, January 2001. 592 9. Security Considerations 594 TBD. 596 10. Intellectual Property Rights Notices 598 The IETF takes no position regarding the validity or scope of any 599 intellectual property or other rights that might be claimed to 600 pertain to the implementation or use of the technology described in 601 this document or the extent to which any license under such rights 602 might or might not be available; neither does it represent that it 603 has made any effort to identify any such rights. Information on 604 the IETF's procedures with respect to rights in standards-track and 605 standards-related documentation can be found in BCP-11. Copies of 606 claims of rights made available for publication and any assurances 607 of licenses to be made available, or the result of an attempt made 608 to obtain a general license or permission for the use of such 609 proprietary rights by implementers or users of this specification 610 can be obtained from the IETF Secretariat. 611 The IETF invites any interested party to bring to its attention any 612 copyrights, patents or patent applications, or other proprietary 613 rights which may cover technology that may be required to practice 614 this standard. Please address the information to the IETF 615 Executive Director. 617 11. Full Copyright Statement 619 Copyright (C) The Internet Society (2001). All Rights 620 Reserved. 621 This document and translations of it may be copied and 622 furnished to others, and derivative works that comment on 623 or otherwise explain it or assist in its implementation may 624 be prepared, copied, published and distributed, in whole or 625 in part, without restriction of any kind, provided that the 626 above copyright notice and this paragraph are included on 627 all such copies and derivative works. However, this 628 document itself may not be modified in any way, such as by 629 removing the copyright notice or references to the Internet 630 Society or other Internet organizations, except as needed 631 for the purpose of developing Internet standards in which 632 case the procedures for copyrights defined in the Internet 633 Standards process must be followed, or as required to 634 translate it into languages other than English. 635 The limited permissions granted above are perpetual and 636 will not be revoked by the Internet Society or its 637 successors or assigns. This document and the information 638 contained herein is provided on an "AS IS" basis and THE 639 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 640 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 641 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 642 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 643 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 644 PURPOSE.