Network Working Group T. Nadeau (Ed) Internet Draft C. Pignataro (Ed) Expiration Date: December 2006 Cisco Systems, Inc. R. Aggarwal (Ed) Juniper Networks June 2006 Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) draft-ietf-pwe3-vccv-10.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes Virtual Circuit Connection Verification (VCCV) which provides a control channel that is associated with a pseudo wire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. PWE3 Working Group Expires December 2006 [Page 1] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 Table of Contents 1 Specification of requirements .......................... 4 2 Introduction ........................................... 4 3 Overview of VCCV ....................................... 5 4 VCCV Control Channel for MPLS PSN ....................... 7 4.1 Inband VCCV (Type 1) .................................... 7 4.2 Out-of-Band VCCV (Type 2) ............................... 8 4.3 TTL Expiry VCCV (Type 3) ................................ 8 4.4 VCCV In-band Connectivity Verification Types ............ 8 4.4.1 MPLS LSP Ping Packet ................................... 9 4.4.2 Bidirectional Forwarding Detection ..................... 9 4.5 VCCV Capability Advertisement for MPLS PSN .............. 10 4.5.1 VCCV Capability Advertisement Sub-TLV ................... 11 5 VCCV Control Channel for L2TPv3/IP PSN ................. 12 5.1 L2TPv3 VCCV Message .................................... 13 5.1.1 L2TPv3 VCCV ICMP Ping AVP .............................. 13 5.1.2 L2TPv3 VCCV BFD AVP .................................... 13 5.2 L2TPv3 VCCV Capability Indication ...................... 13 5.2.1 L2TPv3 VCCV Capability AVP ............................. 13 5.3 L2TPv3 VCCV Operation .................................. 14 6. Capability Advertisement Preference Order .................. 14 7 IANA Considerations .................................... 14 7.1 VCCV Parameter ID ...................................... 14 7.1.1 Control Channel Types (CC Types) ........................ 15 7.1.2 Connectivity Verification Types (CV Types) .............. 15 7.2 L2TPv3 Assignments ..................................... 15 7.2.1 CV Types ............................................... 15 8 Security Considerations ................................ 15 9 Acknowledgements ....................................... 17 10 References ............................................. 17 10.1 Normative References ................................... 17 10.2 Informative References ................................. 18 11 Editor Information ...................................... 18 12 Contributor Information ................................ 19 13 Intellectual Property Statement ........................ 20 14 Full Copyright Statement ............................... 20 1. Specification of requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. PWE3 Working Group Expires December 2006 [Page 2] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 2. Introduction As network operators deploy pseudo wire (PW) services, fault detec- tion and diagnostic mechanisms particularly for the PSN portion of the network are pivotal. Specifically, the ability to provide end-to- end fault detection and diagnostics for an emulated PW service is critical for the network operator. Operators have indicated in [RFC4377][RFC3916] that such a tool is required for PW deployments. This document describes procedures for a PSN-agnostic fault detection and diagnostics tool called Virtual Circuit Connection Verification (VCCV). |<----- Pseudo Wire ---->| | | Attachment or | |<-- PSN Tunnel -->| | Attachment or Virtual | | | | Virtual Circuit V V V V Circuit | +----+ +----+ | +----+ | | PE1|==================| PE2| | +----+ | |----------|............PW1.............|----------| | | CE1| | | | | | | |CE2 | | |----------|............PW2.............|----------| | +----+ | | |==================| | | +----+ ^ +----+ +----+ | ^ | Provider Edge 1 Provider Edge 2 | | | |<--------------- Emulated Service --------------->| |<---------- VCCV ------>| Customer Customer Edge 1 Edge 2 Figure 1: PWE3 VCCV Operation Reference Model Figure 1 depicts the basic functionality of VCCV. VCCV provides sev- eral means of creating a control channel between PEs that attaches the PW under test. +-------------+ +-------------+ | Layer2 | | Layer2 | | Emulated | < Emulated Service > | Emulated | | Services | | Services | +-------------+ +-------------+ | | VCCV/PW | | |Demultiplexer| < Control Channel > |Demultiplexer| +-------------+ +-------------+ PWE3 Working Group Expires December 2006 [Page 3] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 | PSN | < PSN Tunnel > | PSN | +-------------+ +-------------+ | Physical | | Physical | +-----+-------+ +-----+-------+ | | | ____ ___ ____ | | _/ ___/ \ _/ __ | | / \__/ _ | | / \ | ---------| MPLS or IP Network |----- | / | ___ ___ __ ___/ \_/ ____/ ___/ ____/ Figure 2: PWE3 Protocol Stack Reference Model including the VCCV control channel. Figure 2 depicts how the VCCV control channel is associated with the pseudo wire. Ping and other IP messages are encapsulated using the PWE3 encapsulation as described below in sections 5 and 6. These mes- sages, referred to as VCCV messages, are exchanged only after the desire to exchange such traffic has been negotiated between the PEs (see section 8). 3. Overview of VCCV VCCV defines a set of messages that are exchanged between PEs to ver- ify connectivity of the pseudo wire. To make sure that VCCV packets follow the same path as the PW data flow, they SHOULD be encapsulated with the same PW demultiplexer and trasported over the same PSN tunnel. For example, if MPLS is the PSN in use, then the same label shim header (and label stack) MUST be incorporated. The only cases where this might not be possible is when out-of-band VCCV modes are used which require this encapsulation to be altered; however, these modes are discouraged. VCCV can be used both as a fault detection and/or a diagnostic tool for pseudowires. An operator can periodically invoke VCCV for proactve connectivity verification on an active pseudowire, or on an ad hoc or as-needed as a means of manual connectivity verification. When invoking VCCV, the operator triggers a combination of one of its various Connectivity Check types (CC Type) and one of its various Connectivity Verification (CV) Types. These include LSP-Ping, L2TPV3, or ICMP Ping [RFC792] modes and are applicable depending on the underlying PSN. Since a pseudowire service is bi-directional, the reply MAY be sent PWE3 Working Group Expires December 2006 [Page 4] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 in-band over the PW in the reverse direction. Responses MUST be encapsulated so that they follow the return path of the pseudowire in this case. In-band responses MUST be attempted first. If an in-band test fails, the operator is advised to then use a subsequent test using an out-of-band reply mode such as Reply Mode 4 from [RFC4379], which will return the result to the sender via an application level control channel to determine the fault's direction. The control channel maintained with VCCV can carry fault detection status across a pseudowire and convey this information between the endpoints of the pseudowire. Furthermore, this information can then be translated into the native OAM status codes used by the native access technologies, such as ATM or Ethernet. The specific details of such status interworking is out of the scope of this document, and is only noted here to illustrate the utility of VCCV for such purposes. More complete details can be found in [OAM-MAP]. 4. VCCV Control Channel for MPLS PSN When MPLS is used to transport PW packets, VCCV packets are carried over the MPLS LSP as defined in this section. In order to apply IP monitoring tools a PWE3 PW, an operator may configure VCCV as a control channel for the PW between the PEs endpoints [RFC3985]. Packets sent across this channel from the source PE towards the destination PE either as in-band traffic with the PW's data, or out-of-band. In all cases, the control channel traffic MUST NOT be forwarded past the PE endpoints towards the Customer Edge (CE) devices; instead, they must be intercepted at the PE endpoints for exception processing. The capability of which control channel type (CC Type) to use is advertised by a PE to indicate which of the various control channel types are supported. Once the receiving PE has chosen a mode to use, it MUST continue using this mode until such time as the PW is re-signaled. Thus, if a new CC type is desired, the PW must be torn-down and re-established. Ideally such a control channel would be completely inband. When a control word is present on the PW, it is possible to indi- cate the control channel by setting a bit in the control word header. The following subsections define each of the currently defined VCCV Control Channel Types (CC Types). PWE3 Working Group Expires December 2006 [Page 5] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 4.1. Inband VCCV (Type 1) The PW set-up protocol [RFC4447] determines whether a PW uses a control word. When a control word is used, it SHOULD have the following form for the purpose of indicating VCCV control channel messages. Note that for data, one uses the control word defined just above the MPLS payload [RFC4385]. The PW Associated Channel for VCCV control channel traffic is defined as follows in [RFC4385]: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: PW Associated Channel Header The first nibble is set to 0x0001 to indicate a channel associated with a pseudowire [RFC4385][RFC4446]. The Format ID and the reserved fields are set to 0, the Version is 0, and the Channel Type is set to 0. For example, the following is an example of how the ethernet control word would be received [RFC4448]: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: PW Associated Channel Header for VCCV It should be noted that although some PW types are not required to carry the control word, this type of VCCV MUST only be used for those PW types that do employ the control word. This is the preferred mode of VCCV operation when the control word is present. 4.2. Out-of-Band VCCV (Type 2) A VCCV control channel can alternatively be created by using the MPLS router alert label [RFC3032] immediately above the PW label. PWE3 Working Group Expires December 2006 [Page 6] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 It should be noted that this approach MAY result in a differnt equal cost multi-path (ECMP) hashing behavior than pseudowire PDUs and thus result in the VCCV control channel traffic taking a path which differs from that of the actual data traffic under test. This is the preferred mode of VCCV operation when the control word is not present. 4.3. TTL Expiry VCCV (Type 3) The TTL of the PW label can be set to 1 to force the packet to be processed within the destination router's control plane. This is an inband control channel identification mechanism that is an alternate to section 4.1. To use this type, the control word MUST be used. 4.4 VCCV In-band Connectivity Verification Types VCCV can support several types of connectivity verification types (CV types) or protocols within its control channel, but only one MUST be used once a PE has begun transmitting one. The specific one chosen is based on the preferred order specified below in section 4.5.1. If another is desired to be used once a PE has begun to use one, the pseudowire MUST be re-signaled. The specific type or types of VCCV packets accepted by a router are indicated during capability advertisement as described in section 4.5. The various VCCV CV types supported MUST be used only when they apply to the context of the PW demultiplexor in use. For example, LSP Ping type should only be used when MPLS is utilized as the PSN. 4.4.1 MPLS LSP Ping The LSP Ping header MUST be used in accordance with [RFC4379] and MUST also contain the target FEC Stack containing the sub-TLV of 8 for the L2 VPN endpoint or 9 or 10 for "FEC 128 Pseudowire" or 11 for the FEC 128 Pseudowire". The sub-TLV indicates the PW to be verified. 4.4.2 Bidirectional Forwarding Detection When heart-beat indication is necessary for one or more PWs, the Bidirectional Forwarding Detection (BFD) [BFD] provides a means of continuous monitoring of the PW data path and propagation of forward and reverse defect indications. PWE3 Working Group Expires December 2006 [Page 7] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 In order to use BFD, both ends of the PW connection must have sig- naled the existence of a control channel and the ability to run BFD on it. Once a node has both signaled and received signaling from its peer of these capabilities, it MUST begin sending BFD control packets. The packets MUST be sent on the control channel. The use of the control channel provides the context required to bind and bootstrap the BFD session to a particular PW FEC [BFDMPLS]. Thus normal single-hop BFD initialization procedures are followed, and BFD MUST be run in asynchronous mode. When one of the PEs (PE2 from Figure 1) doesn't receive control messages from PE1 (from Figure 1) during the specified amount of time it declares that the PW in the direction from PE2 to PE1 is down. It stores the cause (e.g., Diagnostic code 1 - control detection time expired) and sends a message to PE1 containing this diagnostic code. This causes PE1 to declare the PW in the direction from PE1 to PE2 is down and it stores as cause: neighbor signaled session down. Depending on the emulated services, PE2 may send a forward direction indication (FDI) on its attachment circuits and PE1 may send an RDI indication on its attachment circuits [OAM-MAP]. BFD defines the following diagnostics: 0 - No Diagnostic 1 - Control Detection Time Expired 2 - Echo Function Failed 3 - Neighbor Signaled Session Down 4 - Forwarding Plane Reset (Local equipment failure) 5 - Path Down (Alarm Suppression) 6 - Concatenated Path Down (Propagating access link alarm) 7 - Administratively Down 8 - Reverse Concatenated Path Down Note that the value, 0 is used when the PW is up and 2 is not appli- cable to asynchronous mode. 4.5 VCCV Capability Advertisement for MPLS PSN To permit the indication of the type or types of PW control chan- nel(s), and connectivity verification mode or modes over a particular PW, a VCCV parameter is defined below that is used as part of the PW establishment signaling. When a PE signals a PW and desires PW OAM for that PW, it MUST indicate this during PW establishment using the messages defined below. Specifically, for PE MUST include the PWE3 Working Group Expires December 2006 [Page 8] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 VCCV parameter in the PW setup message [RFC4447]. The decision of the type of VCCV control channel is left completely to the receiving control entity, although the set of choices is given by the sender in that it indicates the type or types of control channels that it can understand. The receiver SHOULD chose a single control channel type from the choices indicated based on the order of preference rules specified below in the section 4.5.2 and it MUST continue to use this type for the duration of the life of the control channel. Changing control channel types after one has been established to be in use could potentially cause problems at the receiving end, and could also lead to interoperability issues, thus it is strongly discouraged. When a PE sends a label mapping message for a PW, it uses the VCCV parameter to indicate the type of OAM control channels and connectivity verification type or types it is willing to receive on that PW. The capablity of supporting a control channel or channels, and connectivity type or types used over that control channel or channels MUST be signaled before the remote PE may send VCCV messages, and then only on the control channel or channels, and using the connectivity verification type or types indicated. If a PE receives VCCV messages prior to advertising capability for this message, it MUST discard these messages and not reply to them. In this case, the PE SHOULD increment an error counter and optionally issue a system and/or SNMP notification to indicate to the system administrator that this condition exists. When LDP is used as the PW signaling protocol the requesting PE indicates its configured VCCV capability or capabilities to the remote PE by including the VCCV parameter with appropriate options indicating which control channel types it supports in the interface parameter field of the PW ID FEC TLV (FEC 128) or in the sub-TLV interface parameter of the Genralized PW ID FEC TLV (FEC 129). The requesting PE MAY indicate that it supports multiple control channel options, and in doing so agrees to support any and all indicated types if transmitted to it. Local policy may direct the PE to support certain OAM capability and to indicate it. The absence of the VCCV parameter indicates that no OAM functions are supported by the requesting PE, and thus the receiving PE MUST NOT send any VCCV control channel traffic to it. The reception of a VCCV parameter with no options set MUST be ignored as if one is not transmitted at all. PWE3 Working Group Expires December 2006 [Page 9] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 The receiving PE similarly indicates its supported control channel types in the response. These may or may not be the same as the ones that were sent to it. The sender should examine the set that is returned to understand which control channels it may establish with the remote peer. Similarly, it MUST NOT send control channel traffic to the remove PE for which the remote PE has not indicated it supports. The exception to the rules given in the last two paragraphs above is when one side of the PW indicates no support for VCCV while the other indicates support for at least one control channel type. In this case, it is possible for one side of the PW to send VCCV messages (either requests or replies to requests). 4.5.1 VCCV Capability Advertisement Sub-TLV [RFC4447] defines an Interface Parameter field in the LDP PW ID FEC (FEC 128) and an Interface Parameters TLV in the LDP Generalized PW ID FEC (FEC 129) to signal different capabilities for specific PWs. An optional sub-TLV parameter is defined to indicate the capability of supporting none, one or more control channel types for VCCV. This is the VCCV parameter field. If FEC 128 is used the VCCV parameter field is carried in the Interface Parameters field. If FEC 129 is used it is carried as an Interface Parameter sub-TLV in the Interface Parameters TLV. The VCCV parameter ID is defined as follows in [RFC4446]: Parameter ID Length Description 0x0c 4 VCCV The format of the VCCV parameter field is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0c | 0x04 | CC Types | CV Types | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Control Channel (CC Types) type field defines a bitmask used to indicate the type of control channel(s) (i.e.: none, one or more) that a router is capable of receiving control channel traffic on. If more than one control channel is specified, the router agrees to accept control traffic over either control channel; however, see the rules specified in section 6 for more details. If none of the types are supported, a CC Type Indicator of 0x00 SHOULD be transmitted to indicate this to the peer. However, if no capability is signaled, then the PE MUST assume that its PWE3 Working Group Expires December 2006 [Page 10] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 peer is incapable of receiving any of the VCCV CC Types and MUST NOT send any OAM control channel traffic to it. The defined values for CC Types are: 0x00 None. 0x01 PWE3 control word with 0x0001 as first nibble 0x02 MPLS Router Alert Label 0x04 MPLS PW Demultiplexor Label TTL = 1 The CV Type Indicators field is a bitmask used to indicate the specific type or types (i.e.: none, one or more) of control channel packets that may be sent on the specified control channel. The defined values for CV Types are: 0x00 None. 0x01 ICMP Ping 0x02 LSP Ping 0x04 BFD for PW Fault Detection only 0x08 BFD for PW Fault Detection and AC/PW Fault Status Signaling It should be noted that two different CV Types have been defined when BFD is used. In the first case, type 0x04 indicates that BFD is used exclusively to detect faults on the PW and the status of those faults should be conveyed using some means other than BFD. In the case of type 0x08, the AC and PW status SHOULD be conveyed via BFD status codes as specified in [OAM-MAP]. This type SHOULD not be used when a control protocl such as LDP is available that can signal the AC/PW status to the remote endpoint of the PW due to complications that can arise from synchronization issues between the control protocol's status signaling messags and the BFD messages containing fault status information. Implementations MUST NOT include both CV types of 0x02 and 0x04 simultaneously in a capability advertisement due to the complexity of supporting both simultaneously to avoid ambiguity and confusion about how to process and transmit Pseudowire status. If a capability advertisement is received with both 0x02 and 0x04 types indicated, the PE MUST ignore the 0x04 bit. If none of the types above are supported, a CV Type Indicator of 0x00 SHOULD be transmitted to indicate this to the peer. However, if no capability is signaled, then the peer MUST assume that the peer has no VCCV capability. This bit MUST NOT be set if any of the others are set. A PE receiving such a conflict MUST ignore the 0x00 bit and consider the remaining bits that are set as if the 0x00 bit were not set. If the CC Type is specified as 0x00 above, then the PWE3 Working Group Expires December 2006 [Page 11] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 CV Type field MUST be ignored, and assumed to be 0x00 (None) as well. 5. VCCV Control Channel for L2TPv3/IP PSN When L2TPv3 is used to setup a PW over an IP PSN, VCCV packets are carried over the L2TPv3 session as defined in this section. L2TPv3 provides a "Hello" keepalive mechanism for the L2TPv3 control plane that operates in-band over IP or UDP (see Section 4.4 of [RFC3931]). This built-in Hello facility provides dead peer and path detection only for the group of sessions associated with the L2TP Control Connection. VCCV, however, allows individual L2TP sessions to be tested. This provides a more granular mechanism which can be used to troubleshoot potential problems within the dataplane of L2TP endpoints themselves, or to provide additional connection status of individual Pseudowires. The capability of which control channel type (CC Type) to use is advertised by a PE to indicate which of the various control channel types are supported. Once the receiving PE has chosen a mode to use, it MUST continue using this mode until such time as the PW is re-signaled. Thus, if a new CC type is desired, the PW must be torn-down and re-established. In order to carry VCCV messages within an L2TPv3 session data packet, the PW MUST be established such that an L2-Specific Sublayer (L2SS) that defines the V-bit is present. This document defines the V-bit for the Default L2-Specific Sublayer [RFC3931] and the ATM-Specific Sublayer [RFC4454] using the Bit 0 position (see Section 8.2.2 and Section 8.2.3). The L2-Specific Sublayer presence and type (either the Default or a PW-Specific L2SS) is signaled via the L2-Specific Sublayer AVP, Attribute Type 69, as defined in [RFC3931]. The V-bit within the L2-Specific Sublayer is used to identify that a VCCV message follows, and when the V-bit is set the L2SS has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0 0 0|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L2-Specific Sublayer Format when the V-bit (bit 0) is set The VCCV messages are distinguished from user data by the V-bit. The V-bit is set to 1, indicating that a VCCV session message follows. The next three bits MUST be set to 0 when sending and ignored upon receipt. The remaining fields comprising 28 bits (i.e., Version, PWE3 Working Group Expires December 2006 [Page 12] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 Reserved and Channel Type) follow the same definition, format and values from Section 5 of [RFC4385]. 5.1. L2TPv3 VCCV Message The VCCV message over L2TPv3 directly follows the L2-Specific Sublayer with the V-bit set. It could either contain an ICMP Echo packet as described in Section 5.1.1, or a BFD packet as described in Section 5.1.2. 5.1.1. L2TPv3 VCCV using ICMP Ping When this connectivity verification mode is used, an ICMP Echo packet [RFC792] achieves connectivity verification. The ICMP Ping packet directly follows the L2SS with the V-bit set. In the ICMP Echo request, the IP Header fields MUST have the following values: the destination IP address is set to the remote LCCE's IP address for the tunnel endpoint, the source IP address is set to the local LCCE's IP address for the tunnel endpoint, and the TTL is set to 1. 5.1.2. L2TPv3 VCCV using BFD When BFD is used as the connectivity verification mode for L2TPv3 Pseudowires, a BFD packet is used to verify the session. The BFD packet is encapsulated in IP/UDP as specified in [BFDV4V61HOP] and directly follows the L2SS with the V-bit set. When heart-beat indication is necessary for one or more PWs, the Bidirectional Forwarding Detection (BFD) [BFD] provides a means of continuous monitoring of the PW data path and propagation of forward and reverse defect indications. To use BFD, both ends of the Pseudowire MUST have signaled a VCCV control channel capability and the ability to run BFD. Once an LCCE has both signaled and received signaling from its peer of a VCCV control channel and BFD connectivity verification capabilities, it MUST begin sending BFD control packets. The packets MUST be sent on the VCCV control channel. The use of the VCCV control channel provides the context required to bind the BFD session to a particular L2TPv3 session (PW). Thus normal single-hop BFD initialization procedures SHOULD be followed [BFD]. BFD MUST be run in asynchronous mode. The VCCV message comprises a BFD control packet [BFD] encapsulated in IP/UDP as specified in Section 4 of [BFDV4V61HOP]. The L2TPv3 Session ID provides the context to demultiplex the first BFD control packet. PWE3 Working Group Expires December 2006 [Page 13] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 5.2. L2TPv3 VCCV Capability Indication An new optional AVP is defined in Section 5.2.1 to indicate the the VCCV capabilities during session establishment. An LCCE MUST signal its desire to use connectivity verification for a particular L2TPv3 session and its VCCV capabilities using the VCCV Capability AVP. 5.2.1. L2TPv3 VCCV Capability AVP The "VCCV Capability AVP", Attribute type AVP-TBD, specifies the VCCV capabilities as a pair of bitflags for the Control Channel (CC) and Connectifity Verification (CV) Types. This AVP is exchanged during session establishment (in ICRQ, ICRP, OCRQ or OCRP messages). The value field has the following format: VCCV Capability AVP (ICRQ, ICRP, OCRQ, OCRP) 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC Types | CV Types | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CC Types: The Control Channel (CC) Types field defines a bitmask used to indicate the type of control channel(s) that may be used to receive OAM traffic on for the given Session. The router agrees to accept VCCV traffic at any time over any of the signaled VCCV control channel types. Although there is only one value defined in this document, the CC Types field is included for forward compatibility should further CC Types need to be defined in the future. 0x08 L2-Specific Sublayer with V-bit set. A CC Type of 0x01 may only be requested when there is an L2-Specific Sublayer that defines the V-bit present. If a CC Type of 0x01 is requested without requesting an L2-Specific Sublayer AVP with an L2SS type that defines the V-bit, the session MUST be disconnected with a CDN message. If no CC Type is supported, a CC Type Indicator of 0x00 SHOULD be sent. CV Types: PWE3 Working Group Expires December 2006 [Page 14] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 The Connectifity Verification (CV) Types field defines a bitmask used to indicate the specific type or types (i.e.: none, one or more) of IP control packets that may be sent on the specified VCCV control channel. The defined values are: 0x00 None. 0x01 ICMP Ping 0x02 BFD for PW Fault Detection only 0x04 BFD for PW Fault Detection and AC/PW Fault Status Signaling For CV Type of 0x02, BFD is used exclusively to detect faults on the Session and the status of those faults should be conveyed using some means other than BFD, such as using the Circuit Status AVP in an L2TPv3 SLI message. For CV Type of 0x04, the AC and PW status SHOULD be conveyed via BFD status codes. This type SHOULD not be used when a control protocl such as LDP is available that can signal the AC/PW status to the remote endpoint of the PW due to complications that can arise from synchronization issues between the control protocol's status signaling messags and the BFD messages containing fault status information. Implementations MUST NOT include both CV types of 0x02 and 0x04 simultaneously in a capability advertisement due to the complexity of supporting both simultaneously to avoid ambiguity and confusion about how to process and transmit Pseudowire status. If a capability advertisement is received with both 0x02 and 0x04 types indicated, the PE MUST ignore the 0x04 bit. If none of the types above are supported, a CV Type Indicator of 0x00 SHOULD be transmitted to indicate this to the peer LCCE. If an advertisement is received in which bit 0x00 is set with at least one other bit, the 0x00 field MUST be ignored and treated as if it were not set. If the CC Type is specified as 0x00 above, then the CV Type field MUST be ignored, and assumed to be 0x00 (None) as well. If no VCCV Capability AVP is signaled, then the LCCE MUST assume that the peer is incapable of receiving VCCV and MUST NOT send any OAM control channel traffic to it. All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, and Vendor ID. The Vendor ID for the VCCV Capability AVP MUST be 0, indicating that this is an IETF-defined AVP. This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 8. PWE3 Working Group Expires December 2006 [Page 15] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 5.3. L2TPv3 VCCV Operation An LCCE sends VCCV echo requests on an L2TPv3 signaled Pseudowire for fault detection and diagnostic of the L2TPv3 session. The VCCV message travels inband with the Session and follows the exact same path as the user data for the session, because the IP header and L2TPv3 Session header are identical. The egress LCCE of the L2TPv3 session intercepts and processes the VCCV message, and verifies the signaling and forwarding state of the Pseudowire on reception of the VCCV message. Any faults detected can be signaled in the VCCV response. It is to be noted that the VCCV mechanism for L2TPv3 is primarily targeted at verifying the Pseudowire forwarding and signaling state at the egress LCCE. It also helps when L2TPv3 Control Connection and Session paths are not identical. An LCCE MUST NOT send VCCV packets on a L2TPv3 session unless it has received VCCV capability by means of the VCCV Capability AVP from the remote end. If an LCCE receives VCCV packets and its not VCCV capable or it has not sent VCCV capability indication to the remote end, it MUST discard these messages. It should also increment an error counter. In this case the LCCE MAY optionally issue a system and/or SNMP notification. Additionally, because BFD is bidirectional in nature, when using BFD as the connectivity verification type, an LCCE must send VCCV packets on a L2TPv3 session only if it has signaled VCCV capability with BFD CV Type to the remote end and received VCCV capability with BFD CV Type from the remote end. 6. Capability Advertisement Preference Order When a PE receives a VCCV capability advertisement, the advertisement may potentially contain more than one CV Type. In this case, it MUST use the following rules when choosing which CV type to use. It may only choose one mode based on the rules stipulated in sections 4 and 5 above. In particular, once a valid CC Type is used by a PE (traffic sent using that encapsulation), the PE MUST NOT send any traffic down another CC Type encapsulation. CC Types: 1. PWE3 control word with 0x0001 as first nibble 2. L2-Specific Sublayer with V-bit set. 3. MPLS Router Alert Label 4. MPLS PW Demultiplexor Label TTL = 1 PWE3 Working Group Expires December 2006 [Page 16] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 For cases where choice 1, 3 or 4 are chosen, use the following precidence rules, use the following precidence rules for choosing which CV Type to use: 1. LSP Ping 2. BFD for PW Fault Detection only 3. ICMP Ping 4. BFD for PW Fault Detection and AC/PW Fault Status Signaling For cases where choice 2 is made, use the following precidence rules for choosing which one CV Type mode to use based on the rules stipulated in section 5.2.1 above: 1. ICMP Ping 2. BFD for PW Fault Detection only 3. BFD for PW Fault Detection and AC/PW Fault Status Signaling 7. IANA Considerations 7.1. VCCV Parameter ID The VCCC parameter ID codepoint is defined in [RFC4446]. IANA is requested to maintain a registry for the CC Types and CV Types, and bitmasks in the VCCV Parameter ID. The allocations must be done using the "First Come First Served" policy defined in RFC2434. IANA is requested to maintain the following registries. 7.1.1. Control Channel Types (CC Types) IANA is requested to set up a registry of "VCCV Control Channel Types". These are 8-bit values. CV Type values 0x01, 0x02, and 0x04 are specified in this document, PW Type values 0x08, 0x16 and 0x24 are to be assigned by IANA using the "Expert Review" policy defined in [RFC2434]. A VCCV Control Channel Type description is required for any assignment from this registry. A document reference should also be provided. 0x00 None 0x01 PWE3 control word with 0x0001 as first nibble as defined in [RFC4385] 0x02 MPLS Router Alert Label PWE3 Working Group Expires December 2006 [Page 17] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 0x04 MPLS PW Demultiplexor Label TTL = 1 7.1.2. Connectivity Verification Types (CV Types) IANA needs to set up a registry of "VCCV Control Channel Types". These are 8-bit values. CV Type values 0x00, 0x01, 0x02, and 0x04 are specified in this document, CV Type values 0x16 and 0x24 are to be assigned by IANA using the "Expert Review" policy defined in [RFC2434]. A VCCV CV Type description is required for any assignment from this registry. A document reference should also be provided. 0x00 None 0x01 ICMP Ping 0x02 LSP Ping 0x04 BFD for PW Fault Detection only 0x08 BFD for PW Fault Detection and AC/PW Fault Status Signaling 7.1.3 Channel Type The Channel Type codepoint is defined in [RFC4385]. IANA is requested to maintain a registry for the Channel Types from that document. The allocations must be done using the "First Come First Served" policy defined in RFC2434. IANA is requested to maintain the following registries. 0x00 OAM Indication (VCCV) 7.1.2. L2TPv3 Assignments Sections 6.2.1 through 6.2.3 are registrations of new L2TP values for name spaces already managed by IANA. Section 6.2.4 requests a new registry to be added to the existing L2TP registry, and be maintained by IANA accordingly. 7.2.1. Control Message Attribute Value Pairs (AVPs) An additiona AVP Attribute is specified in Section 6.2.1. It is required to be defined by IANA as described in Section 2.2 of [RFC3438]. Attribute Type Description --------- ---------------------------------- AVP-TBD VCCV Capability AVP PWE3 Working Group Expires December 2006 [Page 18] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 7.2.2. Default L2-Specific Sublayer bits The Default L2-Specific Sublayer contains 8 bits in the low-order portion of the header. This document defines one reserved bits in the Default L2-Specific Sublayer in Section 6, which may be assigned by IETF Consensus [RFC2434]. It is required to be assigned by IANA. Default L2-Specific Sublayer bits - per [RFC3931] --------------------------------- Bit 0 - V (VCCV) bit 7.2.3. ATM-Specific Sublayer bits The ATM-Specific Sublayer contains 8 bits in the low-order portion of the header. This document defines one reserved bits in the ATM- Specific Sublayer in Section 6, which may be assigned by IETF Consensus [RFC2434]. It is required to be assigned by IANA. ATM-Specific Sublayer bits - per [RFC4454] -------------------------- Bit 0 - V (VCCV) bit 7.2.4. VCCV Capability AVP Values This is a new registry for IANA to maintain. IANA is requested to maintain a registry for the CC Types and CV Types bitmasks in the VCCV Capability AVP, defined in Section 6.2.1. The allocations must be done using the "Expert Review" policy defined in [RFC2434]. A VCCV CC or CV Type description is required for any assignment from this registry. A document reference should also be provided. IANA is requested to reserve the following bits in this registry: VCCV Capability AVP (Attribute Type AVP-TBD) Values --------------------------------------------------- Control Channel (CC) Types Bit 0 (0x01) - L2-Specific Sublayer with V-bit set. Bit 1 (0x02) - Reserved Bit 2 (0x04) - Reserved Bit 3 (0x08) - Reserved Bit 4 (0x10) - Reserved Bit 5 (0x20) - Reserved Bit 6 (0x40) - Reserved PWE3 Working Group Expires December 2006 [Page 19] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 Bit 7 (0x80) - Reserved Connectifity Verification (CV) Types Bit 0 (0x01) - ICMP Ping Bit 1 (0x02) - BFD for PW Fault Detection only Bit 2 (0x04) - BFD for PW Fault Detection and AC/PW Fault Status Signaling Bit 3 (0x08) - Reserved Bit 4 (0x10) - Reserved Bit 5 (0x20) - Reserved Bit 6 (0x40) - Reserved Bit 7 (0x80) - Reserved 8. Security Considerations Routers that implement the mechanism described herein are subject to to additional denial-of-service attacks as follows: An intruder may impersonate an LDP peer in order to force a failure and reconnection of the TCP connection. Please see the Security Considerations section of [RFC3036] details. An intruder could intercept or inject VCCV packets effectively providing false positives or false negatives. An intruder could deliberately flood a peer router with VCCV messages to either obtain services without authorization or to deny services to others. A misconfigured or misbehaving device could inadvertantly flood a peer router with VCCV messages which could result in a denial of services. In particular, if a router is either implicitly or explicitly indicated that it cannot support one or all of the types of VCCV, but is sent those messages in sufficient quantity, could result in a denial of service. All of attacks above which concern the L2TPv3 or LDP control planes may be countered by use of a control message authentication scheme between LDP or L2TPv3 peers, such as the MD5-based scheme outlined in [RFC3036] or [RFC3931]. Implementation of IP address filters may also aid in deterring these types of attacks. VCCV message throttling mechanisms should be employed, especially in distributed implementations which have a centralized control plane processor with various line cards attached by some data path. In PWE3 Working Group Expires December 2006 [Page 20] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 these architectures VCCV messages may be processed on the central processor after being forwarded there by the receiving line card. In this case, the path between the line card and the control processor may become saturated if appropriate VCCV traffic throttling is not employed, which could lead to a denial of service. Such filtering is also useful for preventing the processing of unwanted VCCV messages, such as those which are sent on unwanted (and perhaps unadvertised) control channel types or VCCV types. VCCV spoofing requires MPLS PW label spoofing and spoofing the PSN tunnel header. As far as the PW label is concerned the same consider- ations as specified in [RFC3031] apply. If the PSN is a MPLS tunnel, PSN tunnel label spoofing is also required. 9. Acknowledgements The authors would like to thank Hari Rakotoranto, Michel Khouderchah, Bertrand Duvivier, Vanson Lim, Chris Metz, W. Mark Townsley, Eric Rosen, Dan Tappan, Danny McPherson and Luca Martini for their valuable comments and suggestions. 10. References 10.1. Normative References [RFC792] Postel, J. "Internet Control Message Protocol, RFC792, September 1981. [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels.", Bradner, March 1997 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Rehter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC3032, January 2001. [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "Label Distribution Protocol", RFC 3036, January 2001. [RFC3931] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC3931, March 2005. [RFC4385] Bryant, S., Martini, L., McPherson, D., PWE3 Working Group Expires December 2006 [Page 21] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC4385, February 2006. [RFC4446] Martini, L., "IANA Allocations for Pseudo Wire Edge to Edge Emulation (PWE3)", RFC4446, April 2006. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC4447, April 2006. [RFC4448] Martini, L., Rosen, E., El-Aawar, N., Heron, G., "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC4448, April 2006. [RFC4379] Kompella, K., G. Swallow, " Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC4379, February 2006. [BFD] Katz, D., Ward, D., Bidirectional Forwarding Detection", draft-ietf-bfd-05.txt, June 2006. [IANAPPP] IANA Point-to-Point Protocol Field Assignments, April 12, 2004, http://www.iana.org/assignments/ppp-numbers 10.2. Informative References [RFC4377] Nadeau, T., Swallow, G., Allan., D., "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks" RFC4377, February 2006. [RFC3985] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge Architecture", RFC 3985, March 2005. [RFC3916] Xiao, X., McPherson, D., Pate, P., "Requirements for Pseudo Wire Emulation Edge to-Edge (PWE3)", RFC3916, September 2004. [BFDMPLS] R. Aggarwal, et al, "BFD for MPLS LSPs", Internet Draft , June 2005. [RFC2434] Narten, T. and H. Alvestrand., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. PWE3 Working Group Expires December 2006 [Page 22] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 [OAM-MAP] T. Nadeau, et. al, "Pseudo Wire (PW) OAM Message Map- ping", draft-ietf-pwe3-oam-msg-map-03.txt, September 2005 [RFC3036] Andersson, L, et al., "LDP Specification", RFC3036, January 2001. [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002. [RFC4454] Singh, S., Townsley, M., Pignataro, C., "Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC4454, March 2006. [BFDV4V61HOP] Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single Hop)", draft-ietf-bfd-v4v6-1hop-05, June 2006. 11. Editor Information Thomas D. Nadeau Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 Email: tnadeau@cisco.com Carlos Pignataro Cisco Systems, Inc. 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 EMail: cpignata@cisco.com Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net 12. Contributor Information George Swallow PWE3 Working Group Expires December 2006 [Page 23] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 Email: swallow@cisco.com Monique Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland Email: mmorrow@cisco.com Yuichi Ikejiri NTT Communication Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 Shinjuku-ku, JAPAN Email: y.ikejiri@ntt.com Kenji Kumaki KDDI Corporation KDDI Bldg. 2-3-2, Nishishinjuku, Tokyo 163-8003, JAPAN E-mail: ke-kumaki@kddi.com Peter B. Busschbach Lucent Technologies 67 Whippany Road Whippany, NJ, 07981 E-mail: busschbach@lucent.com Vasile Radoaca Nortel Networks Billerica, MA, 01803 Email: vasile@nortelnetworks.com PWE3 Working Group Expires December 2006 [Page 24] draft-ietf-pwe3-vccv-10 VCCV June 25, 2006 13. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 14. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. PWE3 Working Group Expires December 2006 [Page 25]