diff options
Diffstat (limited to 'doc/rfc/rfc5085.txt')
| -rw-r--r-- | doc/rfc/rfc5085.txt | 1683 |
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc5085.txt b/doc/rfc/rfc5085.txt new file mode 100644 index 0000000..bc0b656 --- /dev/null +++ b/doc/rfc/rfc5085.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group T. Nadeau, Ed. +Request for Comments: 5085 C. Pignataro, Ed. +Category: Standards Track Cisco Systems, Inc. + December 2007 + + + Pseudowire Virtual Circuit Connectivity Verification (VCCV): + A Control Channel for Pseudowires + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes Virtual Circuit Connectivity Verification + (VCCV), which provides a control channel that is associated with a + pseudowire (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. + + + + + + + + + + + + + + + + + + + + + + + + + + +Nadeau & Pignataro Standards Track [Page 1] + +RFC 5085 PW VCCV December 2007 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Specification of Requirements . . . . . . . . . . . . . . 5 + 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Overview of VCCV . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. CC Types and CV Types . . . . . . . . . . . . . . . . . . . . 8 + 5. VCCV Control Channel for MPLS PWs . . . . . . . . . . . . . . 10 + 5.1. VCCV Control Channel Types for MPLS . . . . . . . . . . . 10 + 5.1.1. In-Band VCCV (Type 1) . . . . . . . . . . . . . . . . 11 + 5.1.2. Out-of-Band VCCV (Type 2) . . . . . . . . . . . . . . 12 + 5.1.3. TTL Expiry VCCV (Type 3) . . . . . . . . . . . . . . . 12 + 5.2. VCCV Connectivity Verification Types for MPLS . . . . . . 13 + 5.2.1. ICMP Ping . . . . . . . . . . . . . . . . . . . . . . 13 + 5.2.2. MPLS LSP Ping . . . . . . . . . . . . . . . . . . . . 13 + 5.3. VCCV Capability Advertisement for MPLS PWs . . . . . . . . 13 + 5.3.1. VCCV Capability Advertisement LDP Sub-TLV . . . . . . 14 + 6. VCCV Control Channel for L2TPv3/IP PWs . . . . . . . . . . . . 15 + 6.1. VCCV Control Channel Type for L2TPv3 . . . . . . . . . . . 16 + 6.2. VCCV Connectivity Verification Type for L2TPv3 . . . . . . 17 + 6.2.1. L2TPv3 VCCV using ICMP Ping . . . . . . . . . . . . . 17 + 6.3. L2TPv3 VCCV Capability Advertisement for L2TPv3 . . . . . 17 + 6.3.1. L2TPv3 VCCV Capability AVP . . . . . . . . . . . . . . 17 + 7. Capability Advertisement Selection . . . . . . . . . . . . . . 19 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 8.1. VCCV Interface Parameters Sub-TLV . . . . . . . . . . . . 19 + 8.1.1. MPLS VCCV Control Channel (CC) Types . . . . . . . . . 19 + 8.1.2. MPLS VCCV Connectivity Verification (CV) Types . . . . 20 + 8.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 21 + 8.3. L2TPv3 Assignments . . . . . . . . . . . . . . . . . . . . 21 + 8.3.1. Control Message Attribute Value Pairs (AVPs) . . . . . 21 + 8.3.2. Default L2-Specific Sublayer Bits . . . . . . . . . . 21 + 8.3.3. ATM-Specific Sublayer Bits . . . . . . . . . . . . . . 21 + 8.3.4. VCCV Capability AVP Values . . . . . . . . . . . . . . 22 + 9. Congestion Considerations . . . . . . . . . . . . . . . . . . 23 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 + + + + + + + + + + + +Nadeau & Pignataro Standards Track [Page 2] + +RFC 5085 PW VCCV December 2007 + + +1. Introduction + + There is a need for fault detection and diagnostic mechanisms that + can be used for end-to-end fault detection and diagnostics for a + Pseudowire, as a means of determining the PW's true operational + state. Operators have indicated in [RFC4377] and [RFC3916] that such + a tool is required for PW operation and maintenance. This document + defines a protocol called Virtual Circuit Connectivity Verification + (VCCV) that satisfies these requirements. VCCV is, in its simplest + description, a control channel between a pseudowire's ingress and + egress points over which connectivity verification messages can be + sent. + + The Pseudowire Edge-to-Edge Emulation (PWE3) Working Group defines a + mechanism that emulates the essential attributes of a + telecommunications service (such as a T1 leased line or Frame Relay) + over a variety of Packet Switched Network (PSN) types [RFC3985]. + PWE3 is intended to provide only the minimum necessary functionality + to emulate the service with the required degree of faithfulness for + the given service definition. The required functions of PWs include + encapsulating service-specific bit streams, cells, or PDUs arriving + at an ingress port and carrying them across an IP path or MPLS + tunnel. In some cases, it is necessary to perform other operations, + such as managing their timing and order, to emulate the behavior and + characteristics of the service to the required degree of + faithfulness. + + From the perspective of Customer Edge (CE) devices, the PW is + characterized as an unshared link or circuit of the chosen service. + In some cases, there may be deficiencies in the PW emulation that + impact the traffic carried over a PW and therefore limit the + applicability of this technology. These limitations must be fully + described in the appropriate service-specific documentation. + + For each service type, there will be one default mode of operation + that all PEs offering that service type must support. However, + optional modes have been defined to improve the faithfulness of the + emulated service, as well as to offer a means by which older + implementations may support these services. + + Figure 1 depicts the architecture of a pseudowire as defined in + [RFC3985]. It further depicts where the VCCV control channel resides + within this architecture, which will be discussed in detail shortly. + + + + + + + + +Nadeau & Pignataro Standards Track [Page 3] + +RFC 5085 PW VCCV December 2007 + + + |<-------------- Emulated Service ---------------->| + | |<---------- VCCV ---------->| | + | |<------- Pseudowire ------->| | + | | | | + | | |<-- PSN Tunnel -->| | | + | V V V V | + V AC +----+ +----+ AC V + +-----+ | | PE1|==================| PE2| | +-----+ + | |----------|............PW1.............|----------| | + | CE1 | | | | | | | | CE2 | + | |----------|............PW2.............|----------| | + +-----+ ^ | | |==================| | | ^ +-----+ + ^ | +----+ +----+ | | ^ + | | Provider Edge 1 Provider Edge 2 | | + | | | | + Customer | | Customer + Edge 1 | | Edge 2 + | | + | | + Native service Native service + + Figure 1: PWE3 VCCV Operation Reference Model + + From Figure 1, Customer Edge (CE) routers CE1 and CE2 are attached to + the emulated service via Attachment Circuits (ACs), and to each of + the Provider Edge (PE) routers (PE1 and PE2, respectively). An AC + can be a Frame Relay Data Link Connection Identifier (DLCI), an ATM + Virtual Path Identifier / Virtual Channel Identifier (VPI/VCI), an + Ethernet port, etc. The PE devices provide pseudowire emulation, + enabling the CEs to communicate over the PSN. A pseudowire exists + between these PEs traversing the provider network. VCCV provides + several means of creating a control channel over the PW, between the + PE routers that attach the PW. + + Figure 2 depicts how the VCCV control channel is associated with the + pseudowire protocol stack. + + + + + + + + + + + + + + + +Nadeau & Pignataro Standards Track [Page 4] + +RFC 5085 PW VCCV December 2007 + + + +-------------+ +-------------+ + | Layer2 | | Layer2 | + | Emulated | < Emulated Service > | Emulated | + | Services | | Services | + +-------------+ +-------------+ + | | VCCV/PW | | + |Demultiplexer| < Control Channel > |Demultiplexer| + +-------------+ +-------------+ + | PSN | < PSN Tunnel > | PSN | + +-------------+ +-------------+ + | Physical | | Physical | + +-----+-------+ +-----+-------+ + | | + | ____ ___ ____ | + | _/ \___/ \ _/ \__ | + | / \__/ \_ | + | / \ | + +--------| MPLS or IP Network |---+ + \ / + \ ___ ___ __ _/ + \_/ \____/ \___/ \____/ + + Figure 2: PWE3 Protocol Stack Reference Model including the VCCV + Control Channel + + VCCV messages are encapsulated using the PWE3 encapsulation as + described in Sections 5 and 6, so that they are handled and processed + in the same manner (or in some cases, a similar manner) as the PW + PDUs for which they provide a control channel. These VCCV messages + are exchanged only after the capability (expressed as two VCCV type + spaces, namely the VCCV Control Channel and Connectivity Verification + Types) and desire to exchange such traffic has been advertised + between the PEs (see Sections 5.3 and 6.3), and VCCV types chosen. + +1.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]. + +2. Abbreviations + + AC Attachment Circuit [RFC3985]. + + AVP Attribute Value Pair [RFC3931]. + + CC Control Channel (used as CC Type). + + + + +Nadeau & Pignataro Standards Track [Page 5] + +RFC 5085 PW VCCV December 2007 + + + CE Customer Edge. + + CV Connectivity Verification (used as CV Type). + + CW Control Word [RFC3985]. + + L2SS L2-Specific Sublayer [RFC3931]. + + LCCE L2TP Control Connection Endpoint [RFC3931]. + + OAM Operation and Maintenance. + + PE Provider Edge. + + PSN Packet Switched Network [RFC3985]. + + PW Pseudowire [RFC3985]. + + PW-ACH PW Associated Channel Header [RFC4385]. + + VCCV Virtual Circuit Connectivity Verification. + +3. Overview of VCCV + + The goal of VCCV is to verify and further diagnose the pseudowire + forwarding path. To this end, VCCV is comprised of different + components: + + o a means of signaling VCCV capabilities to a peer PE, + + o an encapsulation for the VCCV control channel messages that allows + the receiving PE to intercept, interpret, and process them locally + as OAM messages, and + + o specifications for the operation of the various VCCV operational + modes transmitted within the VCCV messages. + + When a pseudowire is first signaled using the Label Distribution + Protocol (LDP) [RFC4447] or the Layer Two Tunneling Protocol version + 3 (L2TPv3) [RFC3931], a message is sent from the initiating PE to the + receiving PE requesting that a pseudowire be set up. This message + has been extended to include VCCV capability information (see + Section 4). The VCCV capability information indicates to the + receiving PE which combinations of Control Channel (CC) and + Connectivity Verification (CV) Types it is capable of receiving. If + the receiving PE agrees to establish the PW, it will return its + capabilities in the subsequent signaling message to indicate which CC + + + + +Nadeau & Pignataro Standards Track [Page 6] + +RFC 5085 PW VCCV December 2007 + + + and CV Types it is capable of processing. Precedence rules for which + CC and CV Type to choose in cases where more than one is specified in + this message are defined in Section 7 of this document. + + Once the PW is signaled, data for the PW will flow between the PEs + terminating the PW. At this time, the PEs can begin transmitting + VCCV messages based on the CC and CV Type combinations just + discussed. To this end, VCCV defines an encapsulation for these + messages that identifies them as belonging to the control channel for + the PW. This encapsulation is designed to both allow the control + channel to be processed functionally in the same manner as the data + traffic for the PW in order to faithfully test the data plane for the + PE, and allow the PE to intercept and process these VCCV messages + instead of forwarding them out of the AC towards the CE as if they + were data traffic. In this way, the most basic function of the VCCV + control channel is to verify connectivity of the pseudowire and the + data plane used to transport the data path for the pseudowire. It + should be noted that because of the number of combinations of + optional and mandatory data-plane encapsulations for PW data traffic, + VCCV defines a number of Control Channel (CC) and Connectivity + Verification (CV) types in order to support as many of these as + possible. While designed to support most of the existing + combinations (both mandatory and optional), VCCV does define a + default CC and CV Type combination for each PW Demultiplexer type, as + will be described in detail later in this document. + + VCCV can be used both as a fault detection and/or a diagnostic tool + for pseudowires. For example, an operator can periodically invoke + VCCV on a timed, on-going basis for proactive connectivity + verification on an active pseudowire, or on an ad hoc or as-needed + basis as a means of manual connectivity verification. When invoking + VCCV, the operator triggers a combination of one of its various CC + Types and one of its various CV Types. The CV Types include LSP Ping + [RFC4379] for MPLS PWs, and ICMP Ping [RFC0792] [RFC4443] for both + MPLS and L2TPv3 PWs. We define a matrix of acceptable CC and CV Type + combinations further in this specification. + + The control channel maintained by VCCV can additionally carry fault + detection status 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, + Frame-Relay 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. Complete + details can be found in [MSG-MAP] and [RFC4447]. + + + + + + +Nadeau & Pignataro Standards Track [Page 7] + +RFC 5085 PW VCCV December 2007 + + +4. CC Types and CV Types + + The VCCV Control Channel (CC) Type defines several possible types of + control channel that VCCV can support. These control channels can in + turn carry several types of protocols defined by the Connectivity + Verification (CV) Type. VCCV potentially supports multiple CV Types + concurrently, but it only supports the use of a single CC Type. The + specific type or types of VCCV packets that can be accepted and sent + by a router are indicated during capability advertisement as + described in Sections 5.3 and 6.3. The various VCCV CV Types + supported are used only when they apply to the context of the PW + demultiplexer in use. For example, the LSP Ping CV Type should only + be used when MPLS Labels are utilized as PW Demultiplexer. + + Once a set of VCCV capabilities is received and advertised, a CC Type + and CV Type(s) that match both the received and transmitted + capabilities can be selected. That is, a PE router needs to only + allow Types that are both received and advertised to be selected, + performing a logical AND between the received and transmitted bitflag + fields. The specific CC Type and CV Type(s) are then chosen within + the constraints and rules specified in Section 7. Once a specific CC + Type has been chosen (i.e., it matches both the transmitted and + received VCCV CC capability), transmitted and replied to, this CC + Type MUST be the only one used until such time as the pseudowire is + re-signaled. In addition, based on these rules and the procedures + defined in Section 5.2 of [RFC4447], the pseudowire MUST be re- + signaled if a different set of capabilities types is desired. The + relevant portion of Section 5.2 of [RFC4447] is: + + Interface Parameter Sub-TLV + + Note that as the "interface parameter sub-TLV" is part of the + FEC, the rules of LDP make it impossible to change the + interface parameters once the pseudowire has been set up. + + The CC and CV Type indicator fields are defined as 8-bit bitmasks + used to indicate the specific CC or CV Type or Types (i.e., none, + one, or more) of control channel packets that may be sent on the VCCV + control channel. These values represent the numerical value + corresponding to the actual bit being set in the bitfield. The + definition of each CC and CV Type is dependent on the PW type + context, either MPLS or L2TPv3, within which it is defined. + + + + + + + + + +Nadeau & Pignataro Standards Track [Page 8] + +RFC 5085 PW VCCV December 2007 + + + Control Channel (CC) Types: + + The defined values for CC Types for MPLS PWs are: + + MPLS Control Channel (CC) Types: + + Bit (Value) Description + ============ ========================================== + Bit 0 (0x01) - Type 1: PWE3 Control Word with 0001b as + first nibble (PW-ACH, see [RFC4385]) + Bit 1 (0x02) - Type 2: MPLS Router Alert Label + Bit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1 + Bit 3 (0x08) - Reserved + Bit 4 (0x10) - Reserved + Bit 5 (0x20) - Reserved + Bit 6 (0x40) - Reserved + Bit 7 (0x80) - Reserved + + The defined values for CC Types for L2TPv3 PWs are: + + L2TPv3 Control Channel (CC) Types: + + Bit (Value) Description + ============ ========================================== + 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 + Bit 7 (0x80) - Reserved + + Connectivity Verification (CV) Types: + + The defined values for CV Types for MPLS PWs are: + + MPLS Connectivity Verification (CV) Types: + + Bit (Value) Description + ============ ========================================== + Bit 0 (0x01) - ICMP Ping + Bit 1 (0x02) - LSP Ping + Bit 2 (0x04) - Reserved + Bit 3 (0x08) - Reserved + Bit 4 (0x10) - Reserved + Bit 5 (0x20) - Reserved + + + + +Nadeau & Pignataro Standards Track [Page 9] + +RFC 5085 PW VCCV December 2007 + + + Bit 6 (0x40) - Reserved + Bit 7 (0x80) - Reserved + + The defined values for CV Types for L2TPv3 PWs are: + + L2TPv3 Connectivity Verification (CV) Types: + + Bit (Value) Description + ============ ========================================== + Bit 0 (0x01) - ICMP Ping + Bit 1 (0x02) - Reserved + Bit 2 (0x04) - Reserved + Bit 3 (0x08) - Reserved + Bit 4 (0x10) - Reserved + Bit 5 (0x20) - Reserved + Bit 6 (0x40) - Reserved + Bit 7 (0x80) - Reserved + + If none of the types above are supported, the entire CC and CV Type + Indicator fields SHOULD be transmitted as 0x00 (i.e., all bits in the + bitfield set to 0) to indicate this to the peer. + + If no capability is signaled, then the peer MUST assume that the peer + has no VCCV capability and follow the procedures specified in this + document for this case. + +5. VCCV Control Channel for MPLS PWs + + 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 to a PW, an operator may configure VCCV as a control + channel for the PW between the PE's 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 is not forwarded past the PE + endpoints towards the Customer Edge (CE) devices; instead, VCCV + messages are intercepted at the PE endpoints for exception + processing. + +5.1. VCCV Control Channel Types for MPLS + + As already described in Section 4, the capability of which control + channel types (CC Type) are supported is advertised by a PE. Once + the receiving PE has chosen a CC Type 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. + + + + + +Nadeau & Pignataro Standards Track [Page 10] + +RFC 5085 PW VCCV December 2007 + + + Ideally, such a control channel would be completely in-band (i.e., + following the same data-plane faith as PW data). When a control word + is present on the PW, it is possible to indicate the control channel + by setting a bit in the control word header (see Section 5.1.1). + + Section 5.1.1 through Section 5.1.3 describe each of the currently + defined VCCV Control Channel Types (CC Types). + +5.1.1. In-Band VCCV (Type 1) + + CC Type 1 is also referred to as "PWE3 Control Word with 0001b as + first nibble". It uses the PW Associated Channel Header (PW-ACH); + see Section 5 of [RFC4385]. + + The PW set-up protocol [RFC4447] determines whether a PW uses a + control word. When a control word is used, and that CW uses the + "Generic PW MPLS Control Word" format (see Section 3 of [RFC4385]), a + Control Channel for use of VCCV messages can be created by using the + PW Associated Channel CW format (see Section 5 of [RFC4385]). + + The PW Associated Channel for VCCV control channel traffic is defined + in [RFC4385] as shown in Figure 3: + + 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 0001b to indicate a channel associated + with a pseudowire (see Section 5 of [RFC4385] and Section 3.6 of + [RFC4446]). The Version and the Reserved fields are set to 0, and + the Channel Type is set to 0x0021 for IPv4 and 0x0057 for IPv6 + payloads. + + For example, Figure 4 shows how the Ethernet [RFC4448] PW-ACH would + be received containing an LSP Ping payload corresponding to a choice + of CC Type of 0x01 and a CV Type of 0x02: + + 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 0 0|0 0 0 0 0 0 0 0| 0x21 (IPv4) or 0x57 (IPv6) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: PW Associated Channel Header for VCCV + + + +Nadeau & Pignataro Standards Track [Page 11] + +RFC 5085 PW VCCV December 2007 + + + It should be noted that although some PW types are not required to + carry the control word, this type of VCCV can only be used for those + PW types that do employ the control word when it is in use. Further, + this CC Type can only be used if the PW CW follows the "Generic PW + MPLS Control Word" format. This mode of VCCV operation MUST be + supported when the control word is present. + +5.1.2. Out-of-Band VCCV (Type 2) + + CC Type 2 is also referred to as "MPLS Router Alert Label". + + A VCCV control channel can alternatively be created by using the MPLS + router alert label [RFC3032] immediately above the PW label. It + should be noted that this approach could result in a different 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. Please see + Section 2 of [RFC4928]. + + CC Type 2 can be used whether the PW is set-up with a Control Word + present or not. + + This is the preferred mode of VCCV operation when the Control Word is + not present. + + If the Control Word is in use on this PW, it MUST also be included + before the VCCV message. This is done to avoid the different ECMP + hashing behavior. In this case, the CW uses the PW-ACH format + described in Section 5.1.1 (see Figures 3 and 4). If the Control + Word is not in use on this PW, the VCCV message follows the PW Label + directly. + +5.1.3. TTL Expiry VCCV (Type 3) + + CC Type 3 is also referred to as "MPLS PW Label with TTL == 1". + + 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 + approach could also result in a different ECMP hashing behavior and + VCCV messages taking a different path than the PW data traffic. + + CC Type 3 can be used whether the PW is set-up with a Control Word + present or not. + + If the Control Word is in use on this PW, it MUST also be included + before the VCCV message. This is done to avoid the different ECMP + hashing behavior. In this case, the CW uses the PW-ACH format + + + + +Nadeau & Pignataro Standards Track [Page 12] + +RFC 5085 PW VCCV December 2007 + + + described in Section 5.1.1 (see Figures 3 and 4). If the Control + Word is not in use on this PW, the VCCV message follows the PW Label + directly. + +5.2. VCCV Connectivity Verification Types for MPLS + +5.2.1. ICMP Ping + + When this optional connectivity verification mode is used, an ICMP + Echo packet using the encoding specified in [RFC0792] (ICMPv4) or + [RFC4443] (ICMPv6) achieves connectivity verification. + Implementations MUST use ICMPv4 [RFC0792] if the signaling for VCCV + used IPv4 addresses, or ICMPv6 [RFC4443] if IPv6 addresses were used. + If the pseudowire is set up statically, then the encoding MUST use + that which was used for the pseudowire in the configuration. + +5.2.2. 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 sub- + Type 8 for the "L2 VPN endpoint", 9 for "FEC 128 Pseudowire + (deprecated)", 10 for "FEC 128 Pseudowire", or 11 for the "FEC 129 + Pseudowire". The sub-TLV value indicates the PW to be verified. + +5.3. VCCV Capability Advertisement for MPLS PWs + + To permit the indication of the type or types of PW control + channel(s) and connectivity verification mode or modes over a + particular PW, a VCCV parameter is defined in Section 5.3.1 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 in Section 5.3.1. + Specifically, the PE MUST include the VCCV interface parameter sub- + TLV (0x0C) assigned in [RFC4446] in the PW set-up 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 control channels and + connectivity verification type or types that it can understand. The + receiver SHOULD choose a single Control Channel Type from the match + between the choices sent and received, based on the capability + advertisement selection specified in Section 7, 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 NOT + RECOMMENDED. + + + + +Nadeau & Pignataro Standards Track [Page 13] + +RFC 5085 PW VCCV December 2007 + + + 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 and + can send on that PW. A remote PE MUST NOT send VCCV messages before + the capability of supporting the control channel(s) (and connectivity + verification type(s) to be used over them) is signaled. Then, it can + do so only on a control channel and using the connectivity + verification type(s) from the ones 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 in + the VCCV interface parameter sub-TLV field of the PW ID FEC TLV (FEC + 128) or in the interface parameter sub-TLV of the Generalized PW ID + FEC TLV (FEC 129). These options indicate which control channel and + connectivity verification types it supports. The requesting PE MAY + indicate that it supports multiple control channel options, and in + doing so, it agrees to support any and all indicated types if + transmitted to it. However, it MUST do so in accordance with the + rules stipulated in Section 5.3.1 (VCCV Capability Advertisement Sub- + TLV.) + + 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. + + The receiving PE similarly indicates its supported control channel + types in the label mapping message. 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, as specified in Sections 4 and 7. + Similarly, it MUST NOT send control channel traffic to the remote PE + for which the remote PE has not indicated it supports. + +5.3.1. VCCV Capability Advertisement LDP Sub-TLV + + [RFC4447] defines an Interface Parameter Sub-TLV 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 + + + +Nadeau & Pignataro Standards Track [Page 14] + +RFC 5085 PW VCCV December 2007 + + + specific PWs. An optional sub-TLV parameter is defined to indicate + the capability of supporting none, one, or more control channel and + connectivity verification types for VCCV. This is the VCCV parameter + field. If FEC 128 is used, the VCCV parameter field is carried in + the Interface Parameter sub-TLV 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 Type field (CC Type) 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 Sections 4 and 7 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 peer is incapable of + receiving any of the VCCV CC Types and MUST NOT send any OAM control + channel traffic to it. Note that the CC and CV Types definitions are + consistent regardless of the PW's transport or access circuit type. + The CC and CV Type values are defined in Section 4. + +6. VCCV Control Channel for L2TPv3/IP PWs + + When L2TPv3 is used to set up 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 data plane of L2TP + endpoints themselves, or to provide additional connection status of + individual pseudowires. + + + +Nadeau & Pignataro Standards Track [Page 15] + +RFC 5085 PW VCCV December 2007 + + + The capability of which Control Channel Type (CC Type) to use is + advertised by a PE to indicate which of the potentially 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. + + An LCCE sends VCCV messages on an L2TPv3-signaled pseudowire for + fault detection and diagnostic of the L2TPv3 session. The VCCV + message travels in-band 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. 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. + +6.1. VCCV Control Channel Type for L2TPv3 + + 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 Sections 8.3.2 and + 8.3.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 format + shown in Figure 5: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: 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, + Reserved, and Channel Type) follow the same definition, format, and + number registry from Section 5 of [RFC4385]. + + + + +Nadeau & Pignataro Standards Track [Page 16] + +RFC 5085 PW VCCV December 2007 + + + The Version and Reserved fields are set to 0. For the CV Type + currently defined of ICMP Ping (0x01), the Channel Type can indicate + IPv4 (0x0021) or IPv6 (0x0057) (see [RFC4385]) as the VCCV payload + directly following the L2SS. + +6.2. VCCV Connectivity Verification Type for L2TPv3 + + The VCCV message over L2TPv3 directly follows the L2-Specific + Sublayer with the V-bit set. It MUST contain an ICMP Echo packet as + described in Section 6.2.1. + +6.2.1. L2TPv3 VCCV using ICMP Ping + + When this connectivity verification mode is used, an ICMP Echo packet + using the encoding specified in [RFC0792] for (ICMPv4) or [RFC4443] + (for ICMPv6) achieves connectivity verification. Implementations + MUST use ICMPv4 [RFC0792] if the signaling for the L2TPv3 PW used + IPv4 addresses, or ICMPv6 [RFC4443] if IPv6 addresses were used. If + the pseudowire is set-up statically, then the encoding MUST use that + which was used for the pseudowire in the configuration. + + 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 or Hop Limit is set to 1. + +6.3. L2TPv3 VCCV Capability Advertisement for L2TPv3 + + A new optional AVP is defined in Section 6.3.1 to indicate 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. + + An LCCE MUST NOT send VCCV packets on an 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 it is 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. + +6.3.1. L2TPv3 VCCV Capability AVP + + The "VCCV Capability AVP", Attribute Type 96, specifies the VCCV + capabilities as a pair of bitflags for the Control Channel (CC) and + Connectivity Verification (CV) Types. This AVP is exchanged during + + + +Nadeau & Pignataro Standards Track [Page 17] + +RFC 5085 PW VCCV December 2007 + + + session establishment (in ICRQ (Incoming-Call-Request), ICRP + (Incoming-Call-Reply), OCRQ (Outgoing-Call-Request), or OCRP + (Outgoing-Call-Reply) 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. CC Type values are defined in Section 4. + 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. + + 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 Call-Disconnect-Notify (CDN) message. + + If no CC Type is supported, a CC Type Indicator of 0x00 SHOULD be + sent. + + CV Types: + + The Connectivity Verification (CV) Types field defines a bitmask + used to indicate the specific type or types (i.e., none, one, or + more) of control packets that may be sent on the specified VCCV + control channel. CV Type values are defined in Section 4. + + 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. + + + + + + + + +Nadeau & Pignataro Standards Track [Page 18] + +RFC 5085 PW VCCV December 2007 + + + 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. + +7. Capability Advertisement Selection + + When a PE receives a VCCV capability advertisement, the advertisement + may potentially contain more than one CC or CV Type. Only matching + capabilities can be selected. When multiple capabilities match, only + one CC Type MUST be used. + + In particular, as already specified, 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 control channel. + + For cases where multiple CC Types are advertised, the following + precedence rules apply when choosing the single CC Type to use: + + 1. Type 1: PWE3 Control Word with 0001b as first nibble + + 2. Type 2: MPLS Router Alert Label + + 3. Type 3: MPLS PW Label with TTL == 1 + + For MPLS PWs, the CV Type of LSP Ping (0x02) is the default, and the + CV Type of ICMP Ping (0x01) is optional. + +8. IANA Considerations + +8.1. VCCV Interface Parameters Sub-TLV + + The VCCV Interface Parameters Sub-TLV codepoint is defined in + [RFC4446]. IANA has created and will maintain registries for the CC + Types and CV Types (bitmasks in the VCCV Parameter ID). The CC Type + and CV Type new registries (see Sections 8.1.1 and 8.1.2, + respectively) have been created in the Pseudo Wires Name Spaces, + reachable from [IANA.pwe3-parameters]. The allocations must be done + using the "IETF Consensus" policy defined in [RFC2434]. + +8.1.1. MPLS VCCV Control Channel (CC) Types + + IANA has set up a registry of "MPLS VCCV Control Channel Types". + These are 8 bitfields. CC Type values 0x01, 0x02, and 0x04 are + specified in Section 4 of this document. The remaining bitfield + values (0x08, 0x10, 0x20, 0x40, and 0x80) are to be assigned by IANA + using the "IETF Consensus" policy defined in [RFC2434]. A VCCV + + + +Nadeau & Pignataro Standards Track [Page 19] + +RFC 5085 PW VCCV December 2007 + + + Control Channel Type description and a reference to an RFC approved + by the IESG are required for any assignment from this registry. + + MPLS Control Channel (CC) Types: + + Bit (Value) Description + ============ ========================================== + Bit 0 (0x01) - Type 1: PWE3 Control Word with 0001b as + first nibble (PW-ACH, see [RFC4385]) + Bit 1 (0x02) - Type 2: MPLS Router Alert Label + Bit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1 + Bit 3 (0x08) - Reserved + Bit 4 (0x10) - Reserved + Bit 5 (0x20) - Reserved + Bit 6 (0x40) - Reserved + Bit 7 (0x80) - Reserved + + The most significant (high order) bit is labeled Bit 7, and the least + significant (low order) bit is labeled Bit 0, see parenthetical + "Value". + +8.1.2. MPLS VCCV Connectivity Verification (CV) Types + + IANA has set up a registry of "MPLS VCCV Control Verification Types". + These are 8 bitfields. CV Type values 0x01 and 0x02 are specified in + Section 4 of this document. The remaining bitfield values (0x04, + 0x08, 0x10, 0x20, 0x40, and 0x80) are to be assigned by IANA using + the "IETF Consensus" policy defined in [RFC2434]. A VCCV Control + Verification Type description and a reference to an RFC approved by + the IESG are required for any assignment from this registry. + + MPLS Connectivity Verification (CV) Types: + + Bit (Value) Description + ============ ========================================== + Bit 0 (0x01) - ICMP Ping + Bit 1 (0x02) - LSP Ping + Bit 2 (0x04) - Reserved + Bit 3 (0x08) - Reserved + Bit 4 (0x10) - Reserved + Bit 5 (0x20) - Reserved + Bit 6 (0x40) - Reserved + Bit 7 (0x80) - Reserved + + The most significant (high order) bit is labeled Bit 7, and the least + significant (low order) bit is labeled Bit 0, see parenthetical + "Value". + + + + +Nadeau & Pignataro Standards Track [Page 20] + +RFC 5085 PW VCCV December 2007 + + +8.2. PW Associated Channel Type + + The PW Associated Channel Types used by VCCV as defined in Sections + 5.1.1 and 6.1 rely on previously allocated numbers from the + Pseudowire Associated Channel Types Registry [RFC4385] in the Pseudo + Wires Name Spaces reachable from [IANA.pwe3-parameters]. In + particular, 0x21 (Internet Protocol version 4) MUST be used whenever + an IPv4 payload follows the Pseudowire Associated Channel Header, or + 0x57 MUST be used when an IPv6 payload follows the Pseudowire + Associated Channel Header. + +8.3. L2TPv3 Assignments + + Section 8.3.1 through Section 8.3.3 are registrations of new L2TP + values for registries already managed by IANA. Section 8.3.4 is a + new registry that has been added to the existing L2TP name spaces, + and will be maintained by IANA accordingly. The Layer Two Tunneling + Protocol "L2TP" Name Spaces are reachable from + [IANA.l2tp-parameters]. + +8.3.1. Control Message Attribute Value Pairs (AVPs) + + An additional AVP Attribute is specified in Section 6.3.1. It was + defined by IANA as described in Section 2.2 of [RFC3438]. + + Attribute + Type Description + --------- ---------------------------------- + 96 VCCV Capability AVP + +8.3.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 bit in the + Default L2-Specific Sublayer in Section 6.1, which was assigned by + IANA following IETF Consensus [RFC2434]. + + Default L2-Specific Sublayer bits - per [RFC3931] + --------------------------------- + Bit 0 - V (VCCV) bit + +8.3.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 bit in the ATM- + Specific Sublayer in Section 6.1, which was assigned by IANA + following IETF Consensus [RFC2434]. + + + + +Nadeau & Pignataro Standards Track [Page 21] + +RFC 5085 PW VCCV December 2007 + + + ATM-Specific Sublayer bits - per [RFC4454] + -------------------------- + Bit 0 - V (VCCV) bit + +8.3.4. VCCV Capability AVP Values + + This is a new registry that IANA maintains in the L2TP Name Spaces. + + IANA created and maintains a registry for the CC Types and CV Types + bitmasks in the VCCV Capability AVP, defined in Section 6.3.1. The + allocations must be done using the "IETF Consensus" policy defined in + [RFC2434]. A VCCV CC or CV Type description and a reference to an + RFC approved by the IESG are required for any assignment from this + registry. + + IANA has reserved the following bits in this registry: + + VCCV Capability AVP (Attribute Type 96) Values + --------------------------------------------------- + + L2TPv3 Control Channel (CC) Types: + + Bit (Value) Description + ============ ========================================== + 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 + Bit 7 (0x80) - Reserved + + L2TPv3 Connectivity Verification (CV) Types: + + Bit (Value) Description + ============ ========================================== + Bit 0 (0x01) - ICMP Ping + Bit 1 (0x02) - Reserved + Bit 2 (0x04) - Reserved + Bit 3 (0x08) - Reserved + Bit 4 (0x10) - Reserved + Bit 5 (0x20) - Reserved + Bit 6 (0x40) - Reserved + Bit 7 (0x80) - Reserved + + + + + + +Nadeau & Pignataro Standards Track [Page 22] + +RFC 5085 PW VCCV December 2007 + + + The most significant (high order) bit is labeled Bit 7, and the least + significant (low order) bit is labeled Bit 0, see parenthetical + "Value". + +9. Congestion Considerations + + The bandwidth resources used by VCCV are recommended to be minimal + compared to those of the associated PW. The bandwidth required for + the VCCV channel is taken outside any allocation for PW data traffic, + and can be configurable. When doing resource reservation or network + planning, the bandwidth requirements for both PW data and VCCV + traffic need to be taken into account. + + VCCV applications (i.e., Connectivity Verification (CV) Types) MUST + consider congestion and bandwidth usage implications and provide + details on bandwidth or packet frequency management. VCCV + applications can have built-in bandwidth management in their + protocols. Other VCCV applications can have their bandwidth + configuration-limited, and rate-limiting them can be harmful as it + could translate to incorrectly declaring connectivity failures. For + all other VCCV applications, outgoing VCCV messages SHOULD be rate- + limited to prevent aggressive connectivity verification consuming + excessive bandwidth, causing congestion, becoming denial-of-service + attacks, or generating an excessive packet rate at the CE-bound PE. + + If these conditions cannot be followed, an adaptive loss-based scheme + SHOULD be applied to congestion-control outgoing VCCV traffic, so + that it competes fairly with TCP within an order of magnitude. One + method of determining an acceptable bandwidth for VCCV is described + in [RFC3448] (TFRC); other methods exist. For example, bandwidth or + packet frequency management can include any of the following: a + negotiation of transmission interval/rate, a throttled transmission + rate on "congestion detected" situations, a slow-start after shutdown + due to congestion and until basic connectivity is verified, and other + mechanisms. + + The ICMP and MPLS LSP PING applications SHOULD be rate-limited to + below 5% of the bit-rate of the associated PW. For this purpose, the + considered bit-rate of a pseudowire is dependent on the PW type. For + pseudowires that carry constant bit-rate traffic (e.g., TDM PWs) the + full bit-rate of the PW is used. For pseudowires that carry variable + bit-rate traffic (e.g., Ethernet PWs), the mean or sustained bit-rate + of the PW is used. + + + + + + + + +Nadeau & Pignataro Standards Track [Page 23] + +RFC 5085 PW VCCV December 2007 + + + As described in Section 10, incoming VCCV messages can be rate- + limited as a protection against denial-of-service attacks. This + throttling or policing of incoming VCCV messages should not be more + stringent than the bandwidth allocated to the VCCV channel to prevent + false indications of connectivity failure. + +10. Security Considerations + + Routers that implement VCCV create a Control Channel (CC) associated + with a pseudowire. This control channel can be signaled (e.g., using + LDP or L2TPv3 depending on the PWE3) or statically configured. Over + this control channel, VCCV Connectivity Verification (CV) messages + are sent. Therefore, three different areas are of concern from a + security standpoint. + + The first area of concern relates to control plane parameter and + status message attacks, that is, attacks that concern the signaling + of VCCV capabilities. MPLS PW Control Plane security is discussed in + Section 8.2 of [RFC4447]. L2TPv3 PW Control Plane security is + discussed in Section 8.1 of [RFC3931]. The addition of the + connectivity verification negotiation extensions does not change the + security aspects of Section 8.2 of [RFC4447], or Section 8.1 of + [RFC3931]. Implementation of IP source address filters may also aid + in deterring these types of attacks. + + A second area of concern centers on data-plane attacks, that is, + attacks on the associated channel itself. Routers that implement the + VCCV mechanisms are subject to additional data-plane denial-of- + service attacks as follows: + + 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 deny services to others. + + A misconfigured or misbehaving device could inadvertently flood a + peer router with VCCV messages which could result in denial of + services. In particular, if a router has 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, + it could result in a denial of service. + + To protect against these potential (deliberate or unintentional) + attacks, multiple mitigation techniques can be employed: + + VCCV message throttling mechanisms can be used, especially in + distributed implementations which have a centralized control-plane + + + +Nadeau & Pignataro Standards Track [Page 24] + +RFC 5085 PW VCCV December 2007 + + + processor with various line cards attached by some control-plane + data path. In 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 complete + denial of service to users of the particular line card. 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. + + Section 8.1 of [RFC4447] discusses methods to protect the data + plane of MPLS PWs from data-plane attacks. However the + implementation of the connectivity verification protocol expands + the range of possible data-plane attacks. For this reason + implementations MUST provide a method to secure the data plane. + This can be in the form of encryption of the data by running IPsec + on MPLS packets encapsulated according to [RFC4023], or by + providing the ability to architect the MPLS network in such a way + that no external MPLS packets can be injected (private MPLS + network). + + For L2TPv3, data packet spoofing considerations are outlined in + Section 8.2 of [RFC3931]. While the L2TPv3 Session ID provides + traffic separation, the optional Cookie field provides additional + protection to thwart spoofing attacks. To maximize protection + against a variety of data-plane attacks, a 64-bit Cookie can be + used. L2TPv3 can also be run over IPsec as detailed in Section + 4.1.3 of [RFC3931]. + + A third and last area of concern relates to the processing of the + actual contents of VCCV messages, i.e., LSP Ping and ICMP messages. + Therefore, the corresponding security considerations for these + protocols (LSP Ping [RFC4379], ICMPv4 Ping [RFC0792], and ICMPv6 Ping + [RFC4443]) apply as well. + +11. 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, Luca Martini, Don O'Connor, Neil + Harrison, Danny Prairie, Mustapha Aissaoui, and Vasile Radoaca for + their valuable comments and suggestions. + + + + + + + + +Nadeau & Pignataro Standards Track [Page 25] + +RFC 5085 PW VCCV December 2007 + + +12. References + +12.1. Normative References + + [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, + RFC 792, September 1981. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., + Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack + Encoding", RFC 3032, January 2001. + + [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling + Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. + + [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol + Label Switched (MPLS) Data Plane Failures", RFC 4379, + February 2006. + + [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, + "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for + Use over an MPLS PSN", RFC 4385, February 2006. + + [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control + Message Protocol (ICMPv6) for the Internet Protocol + Version 6 (IPv6) Specification", RFC 4443, March 2006. + + [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge + Emulation (PWE3)", BCP 116, RFC 4446, April 2006. + + [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. + Heron, "Pseudowire Setup and Maintenance Using the Label + Distribution Protocol (LDP)", RFC 4447, April 2006. + +12.2. Informative References + + [IANA.l2tp-parameters] + Internet Assigned Numbers Authority, "Layer Two Tunneling + Protocol "L2TP"", April 2007, + <http://www.iana.org/assignments/l2tp-parameters>. + + [IANA.pwe3-parameters] + Internet Assigned Numbers Authority, "Pseudo Wires Name + Spaces", June 2007, + <http://www.iana.org/assignments/pwe3-parameters>. + + + + +Nadeau & Pignataro Standards Track [Page 26] + +RFC 5085 PW VCCV December 2007 + + + [MSG-MAP] Nadeau, T., "Pseudo Wire (PW) OAM Message Mapping", + Work in Progress, March 2007. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) + Internet Assigned Numbers Authority (IANA) Considerations + Update", BCP 68, RFC 3438, December 2002. + + [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP + Friendly Rate Control (TFRC): Protocol Specification", + RFC 3448, January 2003. + + [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for + Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, + September 2004. + + [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- + Edge (PWE3) Architecture", RFC 3985, March 2005. + + [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating + MPLS in IP or Generic Routing Encapsulation (GRE)", + RFC 4023, March 2005. + + [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. + Matsushima, "Operations and Management (OAM) Requirements + for Multi-Protocol Label Switched (MPLS) Networks", + RFC 4377, February 2006. + + [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, + "Encapsulation Methods for Transport of Ethernet over MPLS + Networks", RFC 4448, April 2006. + + [RFC4454] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous + Transfer Mode (ATM) over Layer 2 Tunneling Protocol + Version 3 (L2TPv3)", RFC 4454, May 2006. + + [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal + Cost Multipath Treatment in MPLS Networks", BCP 128, + RFC 4928, June 2007. + + + + + + + + + +Nadeau & Pignataro Standards Track [Page 27] + +RFC 5085 PW VCCV December 2007 + + +Appendix A. Contributors' Addresses + + George Swallow + Cisco Systems, Inc. + 300 Beaver Brook Road + Boxborough, MA 01719 + USA + + 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 + + EMail: ke-kumaki@kddi.com + + + Peter B. Busschbach + Alcatel-Lucent + 67 Whippany Road + Whippany, NJ, 07981 + USA + + EMail: busschbach@alcatel-lucent.com + + + + +Nadeau & Pignataro Standards Track [Page 28] + +RFC 5085 PW VCCV December 2007 + + + Rahul Aggarwal + Juniper Networks + 1194 North Mathilda Ave. + Sunnyvale, CA 94089 + USA + + EMail: rahul@juniper.net + + + Luca Martini + Cisco Systems, Inc. + 9155 East Nichols Avenue, Suite 400 + Englewood, CO, 80112 + USA + + EMail: lmartini@cisco.com + +Authors' Addresses + + Thomas D. Nadeau (editor) + Cisco Systems, Inc. + 300 Beaver Brook Road + Boxborough, MA 01719 + USA + + EMail: tnadeau@lucidvision.com + + + Carlos Pignataro (editor) + Cisco Systems, Inc. + 7200 Kit Creek Road + PO Box 14987 + Research Triangle Park, NC 27709 + USA + + EMail: cpignata@cisco.com + + + + + + + + + + + + + + + +Nadeau & Pignataro Standards Track [Page 29] + +RFC 5085 PW VCCV December 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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. + +Intellectual Property + + 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. + + + + + + + + + + + + +Nadeau & Pignataro Standards Track [Page 30] + |