idnits 2.17.1 draft-ietf-pwe3-vccv-15.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1364. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (September 21, 2007) is 6052 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) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-05 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 T. Nadeau, Ed. 3 Internet-Draft C. Pignataro, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: March 24, 2008 September 21, 2007 7 Pseudowire Virtual Circuit Connectivity Verification (VCCV) A Control 8 Channel for Pseudowires 9 draft-ietf-pwe3-vccv-15 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 24, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes Virtual Circuit Connection Verification 43 (VCCV) which provides a control channel that is associated with a 44 Pseudowire (PW), as well as the corresponding operations and 45 management functions such as connectivity verification to be used 46 over that control channel. VCCV applies to all supported access 47 circuit and transport types currently defined for PWs. 49 Table of Contents 51 1. Specification of Requirements . . . . . . . . . . . . . . . . 4 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 56 3. Overview of VCCV . . . . . . . . . . . . . . . . . . . . . . . 7 58 4. CC Types and CV Types . . . . . . . . . . . . . . . . . . . . 8 60 5. VCCV Control Channel for MPLS PSN . . . . . . . . . . . . . . 11 61 5.1. VCCV Control Channel Types for MPLS . . . . . . . . . . . 12 62 5.1.1. Inband VCCV (Type 1) . . . . . . . . . . . . . . . . . 12 63 5.1.2. Out-of-Band VCCV (Type 2) . . . . . . . . . . . . . . 13 64 5.1.3. TTL Expiry VCCV (Type 3) . . . . . . . . . . . . . . . 14 65 5.2. VCCV Connectivity Verification Types for MPLS . . . . . . 14 66 5.2.1. ICMP Ping . . . . . . . . . . . . . . . . . . . . . . 14 67 5.2.2. MPLS LSP Ping . . . . . . . . . . . . . . . . . . . . 14 68 5.3. VCCV Capability Advertisement for MPLS PSN . . . . . . . . 14 69 5.3.1. VCCV Capability Advertisement LDP Sub-TLV . . . . . . 16 71 6. VCCV Control Channel for L2TPv3/IP PSN . . . . . . . . . . . . 17 72 6.1. VCCV Control Channel Type for L2TPv3 . . . . . . . . . . . 17 73 6.2. VCCV Connectivity Verification Type for L2TPv3 . . . . . . 18 74 6.2.1. L2TPv3 VCCV using ICMP Ping . . . . . . . . . . . . . 18 75 6.3. L2TPv3 VCCV Capability Advertisement for L2TPv3 . . . . . 18 76 6.3.1. L2TPv3 VCCV Capability AVP . . . . . . . . . . . . . . 19 78 7. Capability Advertisement Selection . . . . . . . . . . . . . . 20 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 81 8.1. VCCV Interface Parameters Sub-TLV . . . . . . . . . . . . 20 82 8.1.1. Control Channel Types (CC Types) . . . . . . . . . . . 21 83 8.1.2. Connectivity Verification Types (CV Types) . . . . . . 21 84 8.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 22 85 8.3. L2TPv3 Assignments . . . . . . . . . . . . . . . . . . . . 22 86 8.3.1. Control Message Attribute Value Pairs (AVPs) . . . . . 22 87 8.3.2. Default L2-Specific Sublayer bits . . . . . . . . . . 23 88 8.3.3. ATM-Specific Sublayer bits . . . . . . . . . . . . . . 23 89 8.3.4. VCCV Capability AVP Values . . . . . . . . . . . . . . 23 91 9. Congestion Considerations . . . . . . . . . . . . . . . . . . 24 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 95 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 98 12.2. Informative References . . . . . . . . . . . . . . . . . . 28 100 Appendix A. Contributors' Addresses . . . . . . . . . . . . . . . 29 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 103 Intellectual Property and Copyright Statements . . . . . . . . . . 32 105 1. Specification of Requirements 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 2. Introduction 113 Fault detection and diagnostic mechanisms that can be used for end- 114 to-end fault detection and diagnostics for a PW as a means of 115 determining its true operational state are needed. Operators have 116 indicated in [RFC4377] and [RFC3916] that such a tool is required for 117 PW operation and maintenance. This document defines a protocol 118 called Virtual Circuit Connection Verification (VCCV) that satisfies 119 these requirements. VCCV is in its simplest description, a control 120 channel between a pseudowire's ingress and egress points over which 121 connectivity verification messages can be sent. 123 The Pseudowire Edge-to-Edge Emulation (PWE3) Working Group defines a 124 mechanism that emulates the essential attributes of a 125 telecommunications service (such as a T1 leased line or Frame Relay) 126 over a variety of Public Switched Network (PSN) types [RFC3985]. 127 PWE3 is intended to provide only the minimum necessary functionality 128 to emulate the service with the required degree of faithfulness for 129 the given service definition. The required functions of PWs include 130 encapsulating service-specific bit streams, cells, or PDUs arriving 131 at an ingress port and carrying them across an IP path or MPLS 132 tunnel. In some cases it is necessary to perform other operations 133 such as managing their timing and order, to emulate the behavior and 134 characteristics of the service to the required degree of 135 faithfulness. 137 From the perspective of Customer Edge (CE) devices, the PW is 138 characterized as an unshared link or circuit of the chosen service. 139 In some cases, there may be deficiencies in the PW emulation that 140 impact the traffic carried over a PW and therefore limit the 141 applicability of this technology. These limitations must be fully 142 described in the appropriate service-specific documentation. 144 For each service type, there will be one default mode of operation 145 that all PEs offering that service type must support. However, 146 optional modes have been defined to improve the faithfulness of the 147 emulated service, as well as to offer a means by which older 148 implementations may support these services. 150 Figure 1 depicts the architecture of a Pseudowire as defined in 151 [RFC3985]. It further depicts where the VCCV control channel resides 152 within this architecture, which will be discussed in detail shortly. 154 |<-------------- Emulated Service ---------------->| 155 | |<---------- VCCV ----------> | 156 | |<------- Pseudowire ------->| | 157 | | | | 158 | | |<-- PSN Tunnel -->| | | 159 | V V V V | 160 V AC +----+ +----+ AC V 161 +-----+ | | PE1|==================| PE2| | +-----+ 162 | |----------|............PW1.............|----------| | 163 | CE1 | | | | | | | | CE2 | 164 | |----------|............PW2.............|----------| | 165 +-----+ ^ | | |==================| | | ^ +-----+ 166 ^ | +----+ +----+ | | ^ 167 | | Provider Edge 1 Provider Edge 2 | | 168 | | | | 169 Customer | | Customer 170 Edge 1 | | Edge 2 171 | | 172 | | 173 Native service Native service 175 Figure 1: PWE3 VCCV Operation Reference Model 177 From Figure 1, Customer Edge (CE) routers CE1 and CE2 are attached to 178 the emulated service via Attachment Circuits (ACs), and to each of 179 the Provider Edge (PE) routers (PE1 and PE2 respectively). An AC can 180 be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, etc. The PE 181 devices provide Pseudowire emulation, enabling the CEs to communicate 182 over the PSN. A Pseudowire exists between these PEs traversing the 183 provider network. VCCV provides several means of creating a control 184 channel over the PW, between PE routers that attach the PW. 186 Figure 2 depicts how the VCCV control channel is associated with the 187 Pseudowire protocol stack. 189 +-------------+ +-------------+ 190 | Layer2 | | Layer2 | 191 | Emulated | < Emulated Service > | Emulated | 192 | Services | | Services | 193 +-------------+ +-------------+ 194 | | VCCV/PW | | 195 |Demultiplexer| < Control Channel > |Demultiplexer| 196 +-------------+ +-------------+ 197 | PSN | < PSN Tunnel > | PSN | 198 +-------------+ +-------------+ 199 | Physical | | Physical | 200 +-----+-------+ +-----+-------+ 201 | | 202 | ____ ___ ____ | 203 | _/ \___/ \ _/ \__ | 204 | / \__/ \_ | 205 | / \ | 206 +--------| MPLS or IP Network |---+ 207 \ / 208 \ ___ ___ __ _/ 209 \_/ \____/ \___/ \____/ 211 Figure 2: PWE3 Protocol Stack Reference Model including the VCCV 212 control channel 214 VCCV messages are encapsulated using the PWE3 encapsulation as 215 described in Section 5 and Section 6, in a manner that causes these 216 messages to be handled and processed in the same manner as, or in 217 some cases similar to, the PW PDUs for which it provides a control 218 channel. These VCCV messages are exchanged only after the capability 219 (expressed as two VCCV type spaces, namely the VCCV control channel 220 and connectivity verification types) and desire to exchange such 221 traffic has been advertised between the PEs (see Section 5.3 and 222 Section 6.3), and VCCV types chosen. 224 2.1. Abbreviations 226 AC Attachment Circuit [RFC3985]. 228 AVP Attribute Value Pair [RFC3931]. 230 CC Control Channel (used as CC Type). 232 CE Customer Edge. 234 CV Connectivity Verification (used as CV Type). 236 CW Control Word [RFC3985]. 238 L2SS L2-Specific Sublayer [RFC3931]. 240 LCCE L2TP Control Connection Endpoint [RFC3931]. 242 OAM Operation and Maintenance. 244 PE Provider Edge. 246 PSN Packet Switched Network [RFC3985]. 248 PW Pseudowire [RFC3985]. 250 PW-ACH PW Associated Channel Header [RFC4385]. 252 VCCV Virtual Circuit Connectivity Verification. 254 3. Overview of VCCV 256 The goal of VCCV is to verify and further diagnose the Pseudowire 257 forwarding path. To this end, VCCV is comprised of different 258 components: a means of signaling VCCV capabilities to a peer PE, an 259 encapsulation for the VCCV control channel messages that allows the 260 receiving PE to intercept, interpret and process them locally as OAM 261 messages, and specifications for the operation of the various VCCV 262 operational modes transmitted within the VCCV messages. 264 When a Pseudowire is first signaled using the Label Distribution 265 Protocol [RFC4447] or the Layer Two Tunneling Protocol version 3 266 [RFC3931], a message is sent from the initiating PE to a receiving PE 267 requesting that a Pseudowire be setup. This message has been 268 extended to include VCCV capability information (see Section 4). The 269 VCCV capability information indicates to the receiving PE which 270 combinations of Control Channel (CC) and Connectivity Verification 271 (CV) types it is capable of receiving. If the receiving PE agrees to 272 establish the PW, it will return its capabilities in the subsequent 273 signaling message to indicate which CC and CV types it is capable of 274 processing. Precedence rules for which CC and CV type to choose in 275 cases where more than one is specified in this message are defined in 276 Section 7 in this document. 278 Once the PW is signaled, data for the PW will flow between the PEs 279 terminating the PW. At this time, the PEs can begin transmitting 280 VCCV messages based on the CC and CV type combinations just 281 discussed. To this end, VCCV defines an encapsulation for these 282 messages that identifies them as belonging to the control channel for 283 the PW. This encapsulation is designed to both allow the control 284 channel to be processed functionally in the same manner as the data 285 traffic for the PW in order to faithfully test the data plane for the 286 PE, and allow the PE to intercept and process these VCCV messages 287 instead of forwarding them out of the AC towards the CE as if they 288 were data traffic. In this way, the most basic function of the VCCV 289 control channel is to verify connectivity of the Pseudowire and the 290 data plane used to transport the data path for the pseudowire. It 291 should be noted that because of the number of combinations of 292 optional and mandatory data plane encapsulations for PW data traffic, 293 VCCV defines a number of control channel (CC) and connectivity 294 verification (CV) types in order to support as many of these as 295 possible. While designed to support most of the existing 296 combinations both mandatory and optional, VCCV does define a default 297 CC and CV type combination for each PSN type, as will be described in 298 detail later in this document. 300 VCCV can be used both as a fault detection and/or a diagnostic tool 301 for Pseudowires. For example, an operator can periodically invoke 302 VCCV on a timed, on-going basis for proactive connectivity 303 verification on an active Pseudowire, or on an ad hoc or as-needed 304 basis as a means of manual connectivity verification. When invoking 305 VCCV, the operator triggers a combination of one of its various 306 Control Channel types and one of its various Connectivity 307 Verification types. The CV types include LSP Ping [RFC4379] for MPLS 308 PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs. 309 We define a matrix of acceptable CC and CV type combinations further 310 in this specification. 312 The control channel maintained by VCCV can additionally carry fault 313 detection status between the endpoints of the Pseudowire. 314 Furthermore, this information can then be translated into the native 315 OAM status codes used by the native access technologies, such as ATM, 316 Frame-Relay or Ethernet. The specific details of such status 317 interworking is out of the scope of this document, and is only noted 318 here to illustrate the utility of VCCV for such purposes. More 319 complete details can be found in [I-D.ietf-pwe3-oam-msg-map] and 320 [RFC4447]. 322 4. CC Types and CV Types 324 The VCCV Control Channel type (CC type) defines several possible 325 types of control channel that VCCV can support. These control 326 channels can in turn carry several types of protocols defined by the 327 Connectivity Verification type (CV type). VCCV potentially supports 328 multiple CV Types concurrently, but it only supports the use of a 329 single CC Type. The specific type or types of VCCV packets that can 330 be accepted and sent by a router are indicated during capability 331 advertisement as described in Section 5.3 and Section 6.3. The 332 various VCCV CV types supported are used only when they apply to the 333 context of the PW demultiplexer in use. For example, LSP Ping type 334 should only be used when MPLS is utilized as the PSN. 336 Once a set of VCCV capabilities is received and advertised, a CC Type 337 and CV Type(s) that match both the received and transmitted 338 capabilities can be selected. That is, a PE router needs to only 339 allow Types that are both received and advertised to be selected, 340 performing a logical AND between the received and transmitted bitflag 341 fields. The specific CC Type and CV Type(s) are then chosen within 342 the constraints and rules specified in Section 7. Once a specific CC 343 Type has been chosen (i.e., it matches both the transmitted and 344 received VCCV CC capability), transmitted and replied to, this CC 345 Type MUST be the only one used until such time as the Pseudowire is 346 re-signaled. In addition, based on these rules and the procedures 347 defined in Section 5.2 of [RFC4447], the Pseudowire MUST be re- 348 signaled if a different set of capabilities types is desired. The 349 relevant portion of Section 5.2 of [RFC4447] is: 351 Interface Parameter Sub-TLV 353 Note that as the "interface parameter sub-TLV" is part of the 354 FEC, the rules of LDP make it impossible to change the 355 interface parameters once the pseudowire has been set up. 357 The CC and CV type indicator fields are defined as 8-bit bitmasks 358 used to indicate the specific CC or CV type or types (i.e.: none, one 359 or more) of control channel packets that may be sent on the VCCV 360 control channel. These values represent the numerical value 361 corresponding to the actual bit being set in the bitfield. The 362 definition of each CC and CV Type is dependent on the PW type 363 context, either MPLS or L2TPv3, within which it is defined. 365 Control Channel (CC) Types: 367 The defined values for CC Types are for MPLS PWs are: 369 MPLS Control Channel (CC) Types: 371 Bit (Value) Description 372 ============ ========================================== 373 Bit 0 (0x01) - Type 1: PWE3 Control Word with 0001b as 374 first nibble (PW-ACH, see [RFC4385]) 375 Bit 1 (0x02) - Type 2: MPLS Router Alert Label 376 Bit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1 377 Bit 3 (0x08) - Reserved 378 Bit 4 (0x10) - Reserved 379 Bit 5 (0x20) - Reserved 380 Bit 6 (0x40) - Reserved 381 Bit 7 (0x80) - Reserved 383 The defined values for CC Types are for L2TPv3 PWs are: 385 L2TPv3 Control Channel (CC) Types: 387 Bit (Value) Description 388 ============ ========================================== 389 Bit 0 (0x01) - L2-Specific Sublayer with V-bit set 390 Bit 1 (0x02) - Reserved 391 Bit 2 (0x04) - Reserved 392 Bit 3 (0x08) - Reserved 393 Bit 4 (0x10) - Reserved 394 Bit 5 (0x20) - Reserved 395 Bit 6 (0x40) - Reserved 396 Bit 7 (0x80) - Reserved 398 Connectivity Verification (CV) Types: 400 The defined values for CV Types are for MPLS PWs are: 402 MPLS Connectivity Verification (CV) Types: 404 Bit (Value) Description 405 ============ ========================================== 406 Bit 0 (0x01) - ICMP Ping 407 Bit 1 (0x02) - LSP Ping 408 Bit 2 (0x04) - Reserved 409 Bit 3 (0x08) - Reserved 410 Bit 4 (0x10) - Reserved 411 Bit 5 (0x20) - Reserved 412 Bit 6 (0x40) - Reserved 413 Bit 7 (0x80) - Reserved 415 The defined values for CV Types are for L2TPv3 PWs are: 417 L2TPv3 Connectivity Verification (CV) Types: 419 Bit (Value) Description 420 ============ ========================================== 421 Bit 0 (0x01) - ICMP Ping 422 Bit 1 (0x02) - Reserved 423 Bit 2 (0x04) - Reserved 424 Bit 3 (0x08) - Reserved 425 Bit 4 (0x10) - Reserved 426 Bit 5 (0x20) - Reserved 427 Bit 6 (0x40) - Reserved 428 Bit 7 (0x80) - Reserved 430 If none of the types above are supported, the entire CC and CV Type 431 Indicator fields SHOULD be transmitted as 0x00 (i.e., all bits in the 432 bitfield set to 0) to indicate this to the peer. 434 If no capability is signaled, then the peer MUST assume that the peer 435 has no VCCV capability and follow the procedures specified in this 436 document for this case. 438 5. VCCV Control Channel for MPLS PSN 440 When MPLS is used to transport PW packets, VCCV packets are carried 441 over the MPLS LSP as defined in this section. In order to apply IP 442 monitoring tools to a PW, an operator may configure VCCV as a control 443 channel for the PW between the PEs endpoints [RFC3985]. Packets sent 444 across this channel from the source PE towards the destination PE 445 either as in-band traffic with the PW's data, or out-of-band. In all 446 cases, the control channel traffic is not forwarded past the PE 447 endpoints towards the Customer Edge (CE) devices; instead, VCCV 448 messages are intercepted at the PE endpoints for exception 449 processing. 451 5.1. VCCV Control Channel Types for MPLS 453 As already described in Section 4, the capability of which control 454 channel types (CC Type) are supported is advertised by a PE. Once 455 the receiving PE has chosen a CC Type mode to use, it MUST continue 456 using this mode until such time as the PW is re-signaled. Thus, if a 457 new CC type is desired, the PW must be torn-down and re-established. 459 Ideally such a control channel would be completely inband (i.e., 460 following the same dataplane faith as PW data). When a control word 461 is present on the PW, it is possible to indicate the control channel 462 by setting a bit in the control word header (see Section 5.1.1). 464 Section 5.1.1 through Section 5.1.3 describe each of the currently 465 defined VCCV Control Channel Types (CC Types). 467 5.1.1. Inband VCCV (Type 1) 469 CC Type 1 is also referred to as "PWE3 Control Word with 0001b as 470 first nibble". It uses the PW Associated Channel Header (PW-ACH), 471 see Section 5 of [RFC4385]. 473 The PW set-up protocol [RFC4447] determines whether a PW uses a 474 control word. When a control word is used, and that CW uses the 475 "Generic PW MPLS Control Word" format (see Section 3 of [RFC4385]), a 476 Control Channel for use of VCCV messages can be created by using the 477 PW Associated Channel CW format (see Section 5 of [RFC4385]). 479 The PW Associated Channel for VCCV control channel traffic is defined 480 in [RFC4385] as shown in Figure 3: 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 |0 0 0 1|Version| Reserved | Channel Type | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 3: PW Associated Channel Header 490 The first nibble is set to 0001b to indicate a channel associated 491 with a Pseudowire (see Section 5 of [RFC4385] and Section 3.6 of 492 [RFC4446]). The Version and the Reserved fields are set to 0, and 493 the Channel Type is set to 0x0021 for IPv4 and 0x0057 for IPv6 494 payloads. 496 For example, Figure 4 shows how the Ethernet [RFC4448] PW-ACH would 497 be received containing an LSP Ping payload corresponding to a choice 498 of CC Type of 0x01 and a CV Type of 0x02: 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| 0x21 (IPv4) or 0x57 (IPv6) | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 4: PW Associated Channel Header for VCCV 508 It should be noted that although some PW types are not required to 509 carry the control word, this type of VCCV can only be used for those 510 PW types that do employ the control word when it is in use. Further, 511 this CC Type can only be used if the PW CW follows the "Generic PW 512 MPLS Control Word" format. This is the mode of VCCV operation MUST 513 be supported when the control word is present. 515 5.1.2. Out-of-Band VCCV (Type 2) 517 CC Type 2 is also referred to as "MPLS Router Alert Label". 519 A VCCV control channel can alternatively be created by using the MPLS 520 router alert label [RFC3032] immediately above the PW label. It 521 should be noted that this approach could result in a different Equal 522 Cost Multi-Path (ECMP) hashing behavior than Pseudowire PDUs, and 523 thus result in the VCCV control channel traffic taking a path which 524 differs from that of the actual data traffic under test. Please see 525 Section 2 of [RFC4928]. 527 CC Type 2 can be used whether the PW is set-up with a Control Word 528 present or not. 530 This is the preferred mode of VCCV operation when the Control Word is 531 not present. 533 If the Control Word is in use on this PW, it MUST also be included 534 before the VCCV message. This is done to avoid the different ECMP 535 hashing behavior. In this case, the CW uses the PW-ACH format 536 described in Section 5.1.1 (see Figure 3 and Figure 4). If the 537 Control Word is not in use on this PW, the VCCV message follows 538 directly the PW Label. 540 5.1.3. TTL Expiry VCCV (Type 3) 542 CC Type 3 is also referred to as "MPLS PW Label with TTL == 1". 544 The TTL of the PW label can be set to 1 to force the packet to be 545 processed within the destination router's control plane. This 546 approach could also result in a different ECMP hashing behavior and 547 VCCV messages taking a different path than the PW data traffic. 549 CC Type 3 can be used whether the PW is set-up with a Control Word 550 present or not. 552 If the Control Word is in use on this PW, it MUST also be included 553 before the VCCV message. This is done to avoid the different ECMP 554 hashing behavior. In this case, the CW uses the PW-ACH format 555 described in Section 5.1.1 (see Figure 3 and Figure 4). If the 556 Control Word is not in use on this PW, the VCCV message follows 557 directly the PW Label. 559 5.2. VCCV Connectivity Verification Types for MPLS 561 5.2.1. ICMP Ping 563 When this optional connectivity verification mode is used, an ICMP 564 Echo packet using the encoding specified in [RFC0792] (ICMPv4) or 565 [RFC4443] (ICMPv6) achieves connectivity verification. 566 Implementations MUST use ICMPv4 [RFC0792] if the signaling for VCCV 567 used IPv4 addresses, or ICMPv6 [RFC4443] if IPv6 addresses were used. 568 If the pseudowire is setup statically, then the encoding MUST use 569 that which was used for the pseudowire in the configuration. 571 5.2.2. MPLS LSP Ping 573 The LSP Ping header MUST be used in accordance with [RFC4379] and 574 MUST also contain the target FEC Stack containing the sub-TLV of 8 575 for the "L2 VPN endpoint", 9 (deprecated) or 10 for "FEC 128 576 Pseudowire" or 11 for the "FEC 129 Pseudowire". The sub-TLV 577 indicates the PW to be verified. 579 5.3. VCCV Capability Advertisement for MPLS PSN 581 To permit the indication of the type or types of PW control 582 channel(s) and connectivity verification mode or modes over a 583 particular PW, a VCCV parameter is defined in Section 5.3.1 that is 584 used as part of the PW establishment signaling. When a PE signals a 585 PW and desires PW OAM for that PW, it MUST indicate this during PW 586 establishment using the messages defined in Section 5.3.1. 587 Specifically, the PE MUST include the VCCV interface parameter sub- 588 TLV (0x0C) assigned in [RFC4446] in the PW setup message [RFC4447]. 590 The decision of the type of VCCV control channel is left completely 591 to the receiving control entity, although the set of choices is given 592 by the sender in that it indicates the type or types of control 593 channels and connectivity verification types that it can understand. 594 The receiver SHOULD choose a single Control Channel type from the 595 match between the choices sent and received, based on the capability 596 advertisement selection specified in Section 7, and it MUST continue 597 to use this type for the duration of the life of the control channel. 598 Changing Control Channel types after one has been established to be 599 in use could potentially cause problems at the receiving end, and 600 could also lead to interoperability issues, thus it is NOT 601 RECOMMENDED. 603 When a PE sends a label mapping message for a PW, it uses the VCCV 604 parameter to indicate the type of OAM control channels and 605 connectivity verification type or types it is willing to receive and 606 can send on that PW. A remote PE MUST NOT send VCCV messages before 607 the capability of supporting a control channel or channels, and 608 connectivity type or types to be used over that control channel or 609 channels is signaled, and then it can do so only on a control 610 channel, and using connectivity verification type or types from the 611 ones indicated. 613 If a PE receives VCCV messages prior to advertising capability for 614 this message, it MUST discard these messages and not reply to them. 615 In this case, the PE SHOULD increment an error counter and optionally 616 issue a system and/or SNMP notification to indicate to the system 617 administrator that this condition exists. 619 When LDP is used as the PW signaling protocol, the requesting PE 620 indicates its configured VCCV capability or capabilities to the 621 remote PE by including the VCCV parameter with appropriate options in 622 the VCCV interface parameter sub-TLV field of the PW ID FEC TLV (FEC 623 128) or in the interface parameter sub-TLV of the Generalized PW ID 624 FEC TLV (FEC 129). These options indicate which control channel and 625 connectivity verification types it supports. The requesting PE MAY 626 indicate that it supports multiple control channel options, and in 627 doing so agrees to support any and all indicated types if transmitted 628 to it, but MUST do so in accordance with the rules stipulated in 629 Section 5.3.1 (VCCV Capability Advertisement Sub-TLV.) 631 Local policy may direct the PE to support certain OAM capability and 632 to indicate it. The absence of the VCCV parameter indicates that no 633 OAM functions are supported by the requesting PE, and thus the 634 receiving PE MUST NOT send any VCCV control channel traffic to it. 635 The reception of a VCCV parameter with no options set MUST be ignored 636 as if one is not transmitted at all. 638 The receiving PE similarly indicates its supported control channel 639 types in the label mapping message. These may or may not be the same 640 as the ones that were sent to it. The sender should examine the set 641 that is returned to understand which control channels it may 642 establish with the remote peer, as specified in Section 4 and 643 Section 7. Similarly, it MUST NOT send control channel traffic to 644 the remote PE for which the remote PE has not indicated it supports. 646 5.3.1. VCCV Capability Advertisement LDP Sub-TLV 648 [RFC4447] defines an Interface Parameter Sub-TLV in the LDP PW ID FEC 649 (FEC 128) and an Interface Parameters TLV in the LDP Generalized PW 650 ID FEC (FEC 129) to signal different capabilities for specific PWs. 651 An optional sub-TLV parameter is defined to indicate the capability 652 of supporting none, one or more control channel and connectivity 653 verification types for VCCV. This is the VCCV parameter field. If 654 FEC 128 is used, the VCCV parameter field is carried in the Interface 655 Parameter sub-TLV field. If FEC 129 is used, it is carried as an 656 Interface Parameter sub-TLV in the Interface Parameters TLV. 658 The VCCV parameter ID is defined as follows in [RFC4446]: 660 Parameter ID Length Description 661 0x0c 4 VCCV 663 The format of the VCCV parameter field is as follows: 665 0 1 2 3 666 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 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | 0x0c | 0x04 | CC Types | CV Types | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 The Control Channel type field (CC Types) defines a bitmask used to 672 indicate the type of control channel(s) (i.e., none, one or more) 673 that a router is capable of receiving control channel traffic on. If 674 more than one control channel is specified, the router agrees to 675 accept control traffic over either control channel; however, see the 676 rules specified in Section 4 and Section 7 for more details. If none 677 of the types are supported, a CC Type Indicator of 0x00 SHOULD be 678 transmitted to indicate this to the peer. However, if no capability 679 is signaled, then the PE MUST assume that its peer is incapable of 680 receiving any of the VCCV CC Types and MUST NOT send any OAM control 681 channel traffic to it. Note that the CC and CV types definitions are 682 consistent regardless of the PW's transport or access circuit type. 683 The CC and CV type values are defined in Section 4. 685 6. VCCV Control Channel for L2TPv3/IP PSN 687 When L2TPv3 is used to setup a PW over an IP PSN, VCCV packets are 688 carried over the L2TPv3 session as defined in this section. L2TPv3 689 provides a "Hello" keepalive mechanism for the L2TPv3 control plane 690 that operates in-band over IP or UDP (see Section 4.4 of [RFC3931]). 691 This built-in Hello facility provides dead peer and path detection 692 only for the group of sessions associated with the L2TP Control 693 Connection. VCCV, however, allows individual L2TP sessions to be 694 tested. This provides a more granular mechanism which can be used to 695 troubleshoot potential problems within the dataplane of L2TP 696 endpoints themselves, or to provide additional connection status of 697 individual Pseudowires. 699 The capability of which control channel type (CC Type) to use is 700 advertised by a PE to indicate which of the potentially various 701 control channel types are supported. Once the receiving PE has 702 chosen a mode to use, it MUST continue using this mode until such 703 time as the PW is re-signaled. Thus, if a new CC type is desired, 704 the PW must be torn-down and re-established. 706 An LCCE sends VCCV messages on an L2TPv3 signaled Pseudowire for 707 fault detection and diagnostic of the L2TPv3 session. The VCCV 708 message travels inband with the Session and follows the exact same 709 path as the user data for the session, because the IP header and 710 L2TPv3 Session header are identical. The egress LCCE of the L2TPv3 711 session intercepts and processes the VCCV message, and verifies the 712 signaling and forwarding state of the Pseudowire on reception of the 713 VCCV message. It is to be noted that the VCCV mechanism for L2TPv3 714 is primarily targeted at verifying the Pseudowire forwarding and 715 signaling state at the egress LCCE. It also helps when L2TPv3 716 Control Connection and Session paths are not identical. 718 6.1. VCCV Control Channel Type for L2TPv3 720 In order to carry VCCV messages within an L2TPv3 session data packet, 721 the PW MUST be established such that an L2-Specific Sublayer (L2SS) 722 that defines the V-bit is present. This document defines the V-bit 723 for the Default L2-Specific Sublayer [RFC3931] and the ATM-Specific 724 Sublayer [RFC4454] using the Bit 0 position (see Section 8.3.2 and 725 Section 8.3.3). The L2-Specific Sublayer presence and type (either 726 the Default or a PW-Specific L2SS) is signaled via the L2-Specific 727 Sublayer AVP, Attribute Type 69, as defined in [RFC3931]. The V-bit 728 within the L2-Specific Sublayer is used to identify that a VCCV 729 message follows, and when the V-bit is set the L2SS has the format 730 shown in Figure 5: 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 |1|0 0 0|Version| Reserved | Channel Type | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 Figure 5: L2-Specific Sublayer Format when the V-bit (bit 0) is set 740 The VCCV messages are distinguished from user data by the V-bit. The 741 V-bit is set to 1, indicating that a VCCV session message follows. 742 The next three bits MUST be set to 0 when sending and ignored upon 743 receipt. The remaining fields comprising 28 bits (i.e., Version, 744 Reserved and Channel Type) follow the same definition, format and 745 number registry from Section 5 of [RFC4385]. 747 The Version and Reserved fields are set to zero. For the CV Type 748 currently defined of ICMP Ping (0x01), the Channel Type can indicate 749 IPv4 (0x0021) or IPv6 (0x0057) (see [RFC4385]) as the VCCV payload 750 directly following the L2SS. 752 6.2. VCCV Connectivity Verification Type for L2TPv3 754 The VCCV message over L2TPv3 directly follows the L2-Specific 755 Sublayer with the V-bit set. It MUST contain an ICMP Echo packet as 756 described in Section 6.2.1. 758 6.2.1. L2TPv3 VCCV using ICMP Ping 760 When this connectivity verification mode is used, an ICMP Echo packet 761 using the encoding specified in [RFC0792] for (ICMPv4) or [RFC4443] 762 (for ICMPv6) achieves connectivity verification. Implementations 763 MUST use ICMPv4 [RFC0792] if the signaling for the L2TPv3 PW used 764 IPv4 addresses, or ICMPv6 [RFC4443] if IPv6 addresses were used. If 765 the Pseudowire is setup statically, then the encoding MUST use that 766 which was used for the pseudowire in the configuration. 768 The ICMP Ping packet directly follows the L2SS with the V-bit set. 769 In the ICMP Echo request, the IP Header fields MUST have the 770 following values: the destination IP address is set to the remote 771 LCCE's IP address for the tunnel endpoint, the source IP address is 772 set to the local LCCE's IP address for the tunnel endpoint, and the 773 TTL or Hop Limit is set to 1. 775 6.3. L2TPv3 VCCV Capability Advertisement for L2TPv3 777 A new optional AVP is defined in Section 6.3.1 to indicate the VCCV 778 capabilities during session establishment. An LCCE MUST signal its 779 desire to use connectivity verification for a particular L2TPv3 780 session and its VCCV capabilities using the VCCV Capability AVP. 782 An LCCE MUST NOT send VCCV packets on an L2TPv3 session unless it has 783 received VCCV capability by means of the VCCV Capability AVP from the 784 remote end. If an LCCE receives VCCV packets and its not VCCV 785 capable or it has not sent VCCV capability indication to the remote 786 end, it MUST discard these messages. It should also increment an 787 error counter. In this case the LCCE MAY optionally issue a system 788 and/or SNMP notification. 790 6.3.1. L2TPv3 VCCV Capability AVP 792 The "VCCV Capability AVP", Attribute type AVP-TBD, specifies the VCCV 793 capabilities as a pair of bitflags for the Control Channel (CC) and 794 Connectivity Verification (CV) Types. This AVP is exchanged during 795 session establishment (in ICRQ, ICRP, OCRQ or OCRP messages). The 796 value field has the following format: 798 VCCV Capability AVP (ICRQ, ICRP, OCRQ, OCRP) 800 0 1 801 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | CC Types | CV Types | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 CC Types: 808 The Control Channel (CC) Types field defines a bitmask used to 809 indicate the type of control channel(s) that may be used to 810 receive OAM traffic on for the given Session. The router agrees 811 to accept VCCV traffic at any time over any of the signaled VCCV 812 control channel types. CC Type values are defined in Section 4. 813 Although there is only one value defined in this document, the CC 814 Types field is included for forward compatibility should further 815 CC Types need to be defined in the future. 817 A CC Type of 0x01 may only be requested when there is an L2- 818 Specific Sublayer that defines the V-bit present. If a CC Type of 819 0x01 is requested without requesting an L2-Specific Sublayer AVP 820 with an L2SS type that defines the V-bit, the session MUST be 821 disconnected with a CDN message. 823 If no CC Type is supported, a CC Type Indicator of 0x00 SHOULD be 824 sent. 826 CV Types: 828 The Connectivity Verification (CV) Types field defines a bitmask 829 used to indicate the specific type or types (i.e., none, one or 830 more) of control packets that may be sent on the specified VCCV 831 control channel. CV Type values are defined in Section 4. 833 If no VCCV Capability AVP is signaled, then the LCCE MUST assume that 834 the peer is incapable of receiving VCCV and MUST NOT send any OAM 835 control channel traffic to it. 837 All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, and 838 Vendor ID. The Vendor ID for the VCCV Capability AVP MUST be 0, 839 indicating that this is an IETF-defined AVP. This AVP MAY be hidden 840 (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 841 0. The Length (before hiding) of this AVP is 8. 843 7. Capability Advertisement Selection 845 When a PE receives a VCCV capability advertisement, the advertisement 846 may potentially contain more than one CC or CV Type. Only matching 847 capabilities can be selected. When multiple capabilities match, only 848 one CC Type MUST be used. 850 In particular, as already specified, once a valid CC Type is used by 851 a PE (traffic sent using that encapsulation), the PE MUST NOT send 852 any traffic down another CC Type control channel. 854 For cases were multiple CC Types are advertised, the following 855 precedence rules apply when choosing the single CC Type to use: 857 1. Type 1: PWE3 Control Word with 0001b as first nibble 859 2. Type 2: MPLS Router Alert Label 861 3. Type 3: MPLS PW Label with TTL == 1 863 For MPLS PWs, the CV Type of LSP Ping (0x02) is the default, and the 864 CV Type of ICMP Ping (0x01) is optional. 866 8. IANA Considerations 868 8.1. VCCV Interface Parameters Sub-TLV 870 The VCCV Interface Parameters Sub-TLV codepoint is defined in 871 [RFC4446]. IANA is requested to create and maintain registries for 872 the CC Types and CV Types (bitmasks in the VCCV Parameter ID). The 873 CC Type and CV Type new registries (see Section 8.1.1 and 874 Section 8.1.2 respectively) are to be created in the Pseudo Wires 875 Name Spaces, reachable from [IANA.pwe3-parameters]. The allocations 876 must be done using the "IETF Consensus" policy defined in RFC2434. 878 8.1.1. Control Channel Types (CC Types) 880 IANA is requested to set up a registry of "VCCV Control Channel 881 Types". These are 8 bitfield values. CC Type values 0x01, 0x02, and 882 0x04 are specified in Section 4 of this document. The remaining 883 bitfield values (0x08, 0x10, 0x20, 0x40 and 0x80) are to be assigned 884 by IANA using the "IETF Consensus" policy defined in [RFC2434]. A 885 VCCV Control Channel Type description and a reference to an RFC 886 approved by the IESG are required for any assignment from this 887 registry. 889 MPLS Control Channel (CC) Types: 891 Bit (Value) Description 892 ============ ========================================== 893 Bit 0 (0x01) - Type 1: PWE3 Control Word with 0001b as 894 first nibble (PW-ACH, see [RFC4385]) 895 Bit 1 (0x02) - Type 2: MPLS Router Alert Label 896 Bit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1 897 Bit 3 (0x08) - Reserved 898 Bit 4 (0x10) - Reserved 899 Bit 5 (0x20) - Reserved 900 Bit 6 (0x40) - Reserved 901 Bit 7 (0x80) - Reserved 903 8.1.2. Connectivity Verification Types (CV Types) 905 IANA is requested to set up a registry of "VCCV Control Verification 906 Types". These are 8 bitfield values. CV Type values 0x01 and 0x02 907 are specified in Section 4 of this document. The remaining bitfield 908 values (0x04, 0x08, 0x10, 0x20, 0x40 and 0x80) are to be assigned by 909 IANA using the "IETF Consensus" policy defined in [RFC2434]. A VCCV 910 using the "IETF Consensus" policy defined in [RFC2434]. A VCCV 911 Control Verification Type description and a reference to an RFC 912 approved by the IESG are required for any assignment from this 913 registry. 915 MPLS Connectivity Verification (CV) Types: 917 Bit (Value) Description 918 ============ ========================================== 919 Bit 0 (0x01) - ICMP Ping 920 Bit 1 (0x02) - LSP Ping 921 Bit 2 (0x04) - Reserved 922 Bit 3 (0x08) - Reserved 923 Bit 4 (0x10) - Reserved 924 Bit 5 (0x20) - Reserved 925 Bit 6 (0x40) - Reserved 926 Bit 7 (0x80) - Reserved 928 8.2. PW Associated Channel Type 930 The PW Associated Channel Types used by VCCV as defined in 931 Section 5.1.1 and Section 6.1 rely on previously allocated numbers 932 from the Pseudowire Associated Channel Types Registry [RFC4385] in 933 the Pseudo Wires Name Spaces reachable from [IANA.pwe3-parameters]. 934 In particular, 0x21 (Internet Protocol version 4) MUST be used 935 whenever an IPv4 payload follows the Pseudowire Associated Channel 936 Header, or 0x57 MUST be used when an IPv6 payload follows the 937 Pseudowire Associated Channel Header. 939 8.3. L2TPv3 Assignments 941 Section 8.3.1 through Section 8.3.3 are registrations of new L2TP 942 values for registries already managed by IANA. Section 8.3.4 943 requests a new registry to be added to the existing L2TP name spaces, 944 and be maintained by IANA accordingly. The Layer Two Tunneling 945 Protocol "L2TP" Name Spaces are reachable from 946 [IANA.l2tp-parameters]. 948 8.3.1. Control Message Attribute Value Pairs (AVPs) 950 An additional AVP Attribute is specified in Section 6.3.1. It is 951 required to be defined by IANA as described in Section 2.2 of 952 [RFC3438]. 954 Attribute 955 Type Description 956 --------- ---------------------------------- 957 AVP-TBD VCCV Capability AVP 959 8.3.2. Default L2-Specific Sublayer bits 961 The Default L2-Specific Sublayer contains 8 bits in the low-order 962 portion of the header. This document defines one reserved bits in 963 the Default L2-Specific Sublayer in Section 6.1, which may be 964 assigned by IETF Consensus [RFC2434]. It is required to be assigned 965 by IANA. 967 Default L2-Specific Sublayer bits - per [RFC3931] 968 --------------------------------- 969 Bit 0 - V (VCCV) bit 971 8.3.3. ATM-Specific Sublayer bits 973 The ATM-Specific Sublayer contains 8 bits in the low-order portion of 974 the header. This document defines one reserved bits in the ATM- 975 Specific Sublayer in Section 6.1, which may be assigned by IETF 976 Consensus [RFC2434]. It is required to be assigned by IANA. 978 ATM-Specific Sublayer bits - per [RFC4454] 979 -------------------------- 980 Bit 0 - V (VCCV) bit 982 8.3.4. VCCV Capability AVP Values 984 This is a new registry for IANA to maintain in the L2TP Name Spaces. 986 IANA is requested to maintain a registry for the CC Types and CV 987 Types bitmasks in the VCCV Capability AVP, defined in Section 6.3.1. 988 The allocations must be done using the "IETF Consensus" policy 989 defined in [RFC2434]. A VCCV CC or CV Type description and a 990 reference to an RFC approved by the IESG are required for any 991 assignment from this registry. 993 IANA is requested to reserve the following bits in this registry: 995 VCCV Capability AVP (Attribute Type AVP-TBD) Values 996 --------------------------------------------------- 998 L2TPv3 Control Channel (CC) Types: 1000 Bit (Value) Description 1001 ============ ========================================== 1002 Bit 0 (0x01) - L2-Specific Sublayer with V-bit set 1003 Bit 1 (0x02) - Reserved 1004 Bit 2 (0x04) - Reserved 1005 Bit 3 (0x08) - Reserved 1006 Bit 4 (0x10) - Reserved 1007 Bit 5 (0x20) - Reserved 1008 Bit 6 (0x40) - Reserved 1009 Bit 7 (0x80) - Reserved 1011 L2TPv3 Connectivity Verification (CV) Types: 1013 Bit (Value) Description 1014 ============ ========================================== 1015 Bit 0 (0x01) - ICMP Ping 1016 Bit 1 (0x02) - Reserved 1017 Bit 2 (0x04) - Reserved 1018 Bit 3 (0x08) - Reserved 1019 Bit 4 (0x10) - Reserved 1020 Bit 5 (0x20) - Reserved 1021 Bit 6 (0x40) - Reserved 1022 Bit 7 (0x80) - Reserved 1024 9. Congestion Considerations 1026 The bandwidth resources used by VCCV are recommended to be minimal 1027 compared to those of the associated PW. The bandwidth required for 1028 the VCCV channel is taken outside any allocation for PW data-traffic, 1029 and can be configurable. When doing resource reservation or network 1030 planning, the bandwidth requirements for both PW data and VCCV 1031 traffic need to be taken into account. 1033 VCCV applications (i.e., Connectivity Verification (CV) Types) MUST 1034 consider congestion and bandwidth usage implications and provide 1035 details on bandwidth or packet frequency management. VCCV 1036 applications can have built-in bandwidth management in their 1037 protocols. Other VCCV applications can have their bandwidth 1038 configuration-limited, and rate-limiting them can be harmful as it 1039 could translate to incorrectly declaring connectivity failures. For 1040 all other VCCV applications, outgoing VCCV messages SHOULD be rate- 1041 limited to prevent aggressive connectivity verification consuming 1042 excessive bandwidth, causing congestion, becoming Denial-of-Service 1043 attacks, or generating an excessive packet rate at the CE-bound PE. 1045 If these conditions cannot be followed, an adaptive loss-based scheme 1046 SHOULD be applied to congestion-control outgoing VCCV traffic, so 1047 that it competes fairly with TCP within an order of magnitude. One 1048 method of determining an acceptable bandwidth for VCCV is described 1049 in [RFC3448] (TFRC), other methods exist. For example, bandwidth or 1050 packet frequency management can include any of the following: a 1051 negotiation of transmission interval/rate, a throttled transmission 1052 rate on "congestion detected" situations, a slow-start after shutdown 1053 due to congestion and until basic connectivity is verified, and other 1054 mechanisms. 1056 The ICMP and MPLS LSP PING applications SHOULD be rate-limited to 1057 below 5% of the bit-rate of the associated PW. For this purpose, the 1058 considered bit-rate of a Pseudowire is dependent on the PW Type. For 1059 Pseudowires that carry constant bit-rate traffic (e.g., TDM PWs) the 1060 full bit-rate of the PW is used. For Pseudowires that carry variable 1061 bit-rate traffic (e.g., Ethernet PWs), the mean or sustained bit-rate 1062 of the PW is used. 1064 As described in Section 10, incoming VCCV messages can be rate- 1065 limited as a protection against Denial-of-Service attacks. This 1066 throttling or policing of incoming VCCV messages should not be more 1067 stringent than the bandwidth allocated to the VCCV channel to prevent 1068 false indications of connectivity failure. 1070 10. Security Considerations 1072 Routers that implement VCCV create a Control Channel (CC) associated 1073 with a Pseudowire. This control channel can be signaled (e.g., using 1074 LDP or L2TPv3 depending on the PSN) or statically configured. Over 1075 this control channel, VCCV Connectivity Verification (CV) messages 1076 are sent. Therefore, three different areas are of concern from a 1077 security standpoint. 1079 The first area of concern relates to control plane parameter and 1080 status message attacks, that is, attacks that concern the signaling 1081 of VCCV capabilities. MPLS PW Control Plane security is discussed in 1082 Section 8.2 of [RFC4447]. L2TPv3 PW Control Plane security is 1083 discussed in Section 8.1 of [RFC3931]. The addition of the 1084 connection verification negotiation extensions does not change the 1085 security aspects of Section 8.2 of RFC4447, or Section 8.1 of 1086 RFC3931. Implementation of IP source address filters may also aid in 1087 deterring these types of attacks. 1089 A second area of concern centers on dataplane attacks, that is, 1090 attacks on the associated channel itself. Routers that implement the 1091 VCCV mechanisms are subject to additional data plane denial-of- 1092 service attacks as follows: 1094 An intruder could intercept or inject VCCV packets effectively 1095 providing false positives or false negatives. 1097 An intruder could deliberately flood a peer router with VCCV 1098 messages to deny services to others. 1100 A misconfigured or misbehaving device could inadvertently flood a 1101 peer router with VCCV messages which could result in a denial of 1102 services. In particular, if a router is either implicitly or 1103 explicitly indicated that it cannot support one or all of the 1104 types of VCCV, but is sent those messages in sufficient quantity, 1105 could result in a denial of service. 1107 To protect against these potential (deliberate or unintentional) 1108 attacks, multiple mitigation techniques can be employed: 1110 VCCV message throttling mechanisms can be used, especially in 1111 distributed implementations which have a centralized control plane 1112 processor with various line cards attached by some control plane 1113 data path. In these architectures VCCV messages may be processed 1114 on the central processor after being forwarded there by the 1115 receiving line card. In this case, the path between the line card 1116 and the control processor may become saturated if appropriate VCCV 1117 traffic throttling is not employed, which could lead to a complete 1118 denial of service to users of the particular line card. Such 1119 filtering is also useful for preventing the processing of unwanted 1120 VCCV messages, such as those which are sent on unwanted (and 1121 perhaps unadvertised) control channel types or VCCV types. 1123 Section 8.1 of [RFC4447] discusses methods to protect the data 1124 plane of MPLS PWs from data plane attacks. However the 1125 implementation of the connection verification protocol expands the 1126 range of possible data plane attacks. For this reason 1127 implementations MUST provide a method to secure the data plane. 1128 This can be in the form of encryption of the data by running IPsec 1129 on MPLS packets encapsulated according to [RFC4023], or by 1130 providing the ability to architect the MPLS network in such a way 1131 that no external MPLS packets can be injected (private MPLS 1132 network). 1134 For L2TPv3, data packet spoofing considerations are outlined in 1135 Section 8.2 of [RFC3931]. While the L2TPv3 Session ID provides 1136 traffic separation, the optional Cookie provides additional 1137 protection to thwarts spoofing attacks. To maximize protection 1138 against a variety of dataplane attacks, a 64-bit cookie can be 1139 used. L2TPv3 can also be run over IPsec as detailed in Section 1140 4.1.3 of [RFC3931]. 1142 A third and last area of concern relates to the processing of the 1143 actual contents of VCCV messages, i.e., LSP Ping and ICMP messages. 1144 Therefore, the corresponding security considerations for these 1145 protocols (LSP Ping [RFC4379], ICMPv4 Ping [RFC0792] and ICMPv6 Ping 1146 [RFC4443]) apply as well. 1148 11. Acknowledgements 1150 The authors would like to thank Hari Rakotoranto, Michel Khouderchah, 1151 Bertrand Duvivier, Vanson Lim, Chris Metz, W. Mark Townsley, Eric 1152 Rosen, Dan Tappan, Danny McPherson, Luca Martini, Don O'Connor, Neil 1153 Harrison, Danny Prairie, Mustapha Aissaoui and Vasile Radoaca for 1154 their valuable comments and suggestions. 1156 12. References 1158 12.1. Normative References 1160 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1161 RFC 792, September 1981. 1163 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1164 Requirement Levels", BCP 14, RFC 2119, March 1997. 1166 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1167 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1168 Encoding", RFC 3032, January 2001. 1170 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 1171 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1173 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1174 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1175 February 2006. 1177 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1178 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1179 Use over an MPLS PSN", RFC 4385, February 2006. 1181 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1182 Message Protocol (ICMPv6) for the Internet Protocol 1183 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1185 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1186 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 1188 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1189 Heron, "Pseudowire Setup and Maintenance Using the Label 1190 Distribution Protocol (LDP)", RFC 4447, April 2006. 1192 12.2. Informative References 1194 [I-D.ietf-pwe3-oam-msg-map] 1195 Nadeau, T., "Pseudo Wire (PW) OAM Message Mapping", 1196 draft-ietf-pwe3-oam-msg-map-05 (work in progress), 1197 March 2007. 1199 [IANA.l2tp-parameters] 1200 Internet Assigned Numbers Authority, "Layer Two Tunneling 1201 Protocol "L2TP"", April 2007, 1202 . 1204 [IANA.pwe3-parameters] 1205 Internet Assigned Numbers Authority, "Pseudo Wires Name 1206 Spaces", June 2007, 1207 . 1209 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1210 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1211 October 1998. 1213 [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) 1214 Internet Assigned Numbers Authority (IANA) Considerations 1215 Update", BCP 68, RFC 3438, December 2002. 1217 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 1218 Friendly Rate Control (TFRC): Protocol Specification", 1219 RFC 3448, January 2003. 1221 [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for 1222 Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, 1223 September 2004. 1225 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1226 Edge (PWE3) Architecture", RFC 3985, March 2005. 1228 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 1229 MPLS in IP or Generic Routing Encapsulation (GRE)", 1230 RFC 4023, March 2005. 1232 [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 1233 Matsushima, "Operations and Management (OAM) Requirements 1234 for Multi-Protocol Label Switched (MPLS) Networks", 1235 RFC 4377, February 2006. 1237 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 1238 "Encapsulation Methods for Transport of Ethernet over MPLS 1239 Networks", RFC 4448, April 2006. 1241 [RFC4454] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous 1242 Transfer Mode (ATM) over Layer 2 Tunneling Protocol 1243 Version 3 (L2TPv3)", RFC 4454, May 2006. 1245 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 1246 Cost Multipath Treatment in MPLS Networks", BCP 128, 1247 RFC 4928, June 2007. 1249 Appendix A. Contributors' Addresses 1251 George Swallow 1252 Cisco Systems, Inc. 1253 300 Beaver Brook Road 1254 Boxborough, MA 01719 1255 USA 1257 Email: swallow@cisco.com 1259 Monique Morrow 1260 Cisco Systems, Inc. 1261 Glatt-com 1262 CH-8301 Glattzentrum 1263 Switzerland 1265 Email: mmorrow@cisco.com 1267 Yuichi Ikejiri 1268 NTT Communication Corporation 1269 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1270 Tokyo 100-8019 1271 Shinjuku-ku 1272 JAPAN 1274 Email: y.ikejiri@ntt.com 1275 Kenji Kumaki 1276 KDDI Corporation 1277 KDDI Bldg. 2-3-2 1278 Nishishinjuku 1279 Tokyo 163-8003 1280 JAPAN 1282 Email: ke-kumaki@kddi.com 1284 Peter B. Busschbach 1285 Alcatel-Lucent 1286 67 Whippany Road 1287 Whippany, NJ, 07981 1288 USA 1290 Email: busschbach@alcatel-lucent.com 1292 Rahul Aggarwal 1293 Juniper Networks 1294 1194 North Mathilda Ave. 1295 Sunnyvale, CA 94089 1296 USA 1298 Email: rahul@juniper.net 1300 Luca Martini 1301 Cisco Systems, Inc. 1302 9155 East Nichols Avenue, Suite 400 1303 Englewood, CO, 80112 1304 USA 1306 Email: lmartini@cisco.com 1308 Authors' Addresses 1310 Thomas D. Nadeau (editor) 1311 Cisco Systems, Inc. 1312 300 Beaver Brook Road 1313 Boxborough, MA 01719 1314 USA 1316 Email: tnadeau@cisco.com 1317 Carlos Pignataro (editor) 1318 Cisco Systems, Inc. 1319 7200 Kit Creek Road 1320 PO Box 14987 1321 Research Triangle Park, NC 27709 1322 USA 1324 Email: cpignata@cisco.com 1326 Full Copyright Statement 1328 Copyright (C) The IETF Trust (2007). 1330 This document is subject to the rights, licenses and restrictions 1331 contained in BCP 78, and except as set forth therein, the authors 1332 retain all their rights. 1334 This document and the information contained herein are provided on an 1335 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1336 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1337 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1338 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1339 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1340 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1342 Intellectual Property 1344 The IETF takes no position regarding the validity or scope of any 1345 Intellectual Property Rights or other rights that might be claimed to 1346 pertain to the implementation or use of the technology described in 1347 this document or the extent to which any license under such rights 1348 might or might not be available; nor does it represent that it has 1349 made any independent effort to identify any such rights. Information 1350 on the procedures with respect to rights in RFC documents can be 1351 found in BCP 78 and BCP 79. 1353 Copies of IPR disclosures made to the IETF Secretariat and any 1354 assurances of licenses to be made available, or the result of an 1355 attempt made to obtain a general license or permission for the use of 1356 such proprietary rights by implementers or users of this 1357 specification can be obtained from the IETF on-line IPR repository at 1358 http://www.ietf.org/ipr. 1360 The IETF invites any interested party to bring to its attention any 1361 copyrights, patents or patent applications, or other proprietary 1362 rights that may cover technology that may be required to implement 1363 this standard. Please address the information to the IETF at 1364 ietf-ipr@ietf.org. 1366 Acknowledgment 1368 Funding for the RFC Editor function is provided by the IETF 1369 Administrative Support Activity (IASA).