RFC 5085
Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires
Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires 🦋
Okay bestie, this one's the RFC that defines VCCV, a control channel for pseudowires 💖 It's a Standards Track spec from December 2007, written by T. Nadeau (Ed.) and C. Pignataro (Ed.) at Cisco Systems, Inc. It's from the Network Working Group, and the header doesn't list any RFCs it obsoletes or updates. Lowkey iconic that it's been around this long 🌸
Status of This Memo
Ok so this part is the official paperwork 📝 It says the doc is an Internet standards track protocol for the Internet community, and it wants feedback and suggestions for making things better. If you want the current state of the protocol, you check the "Internet Official Protocol Standards" (STD 1) page. The memo can be distributed freely, no cap 🫶
Abstract
So the big idea is VCCV, which gives a pseudowire (PW) its own control channel 🎀 On top of that channel you can run operations and management stuff, like connectivity verification. It works with every access circuit and transport type that's currently defined for PWs ✨
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 . . . . . . . . . . . . . . . . . . 261. Introduction 🌈
Okay so the need is pretty clear: you want fault detection and diagnostics that work end to end across a pseudowire 🔥 The whole point is finding out the PW's true operational state, not just what it looks like from the outside. Operators said in [RFC4377] and [RFC3916] that they need this kind of tool to run and maintain PWs. This doc defines VCCV to deliver exactly that. In the simplest terms, VCCV is a control channel between the ingress and egress points of a pseudowire, and you can send connectivity verification messages over it 💅
The Pseudowire Edge-to-Edge Emulation (PWE3) Working Group made a mechanism that copies the important stuff about a telecom service (like a T1 leased line or Frame Relay) and runs it over different Packet Switched Network (PSN) types [RFC3985]. It's minimal on purpose 🧚 It only does what's needed to emulate the service faithfully enough for that service's definition. The core jobs are wrapping service-specific bit streams, cells, or PDUs that come in at an ingress port and carrying them across an IP path or MPLS tunnel. Sometimes it also has to handle things like timing and ordering so the service acts and feels the way it should 🎀
From the Customer Edge (CE) point of view, the PW looks like an unshared link or circuit of the chosen service ✨ Sometimes the PW emulation has flaws that affect the traffic on it, and that can limit where the tech actually makes sense. Those limitations must be fully described in the service-specific docs 🙈
Hold up, the key word here is MUST. The limitations must be fully described in the appropriate service-specific documentation, so don't skip that part.
For each service type, there's one default mode that every PE offering that service type must support 👑 There are also optional modes that make the emulated service more faithful, and they give older implementations a way to support these services too 🫶
Figure 1 shows the architecture of a pseudowire as defined in [RFC3985]. It also shows where the VCCV control channel sits in that architecture, and we'll get into the details shortly 🦋
|<-------------- 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 ModelSo from Figure 1, CE1 and CE2 are the Customer Edge routers, and they hook up to the emulated service through Attachment Circuits (ACs). Each one connects to its own Provider Edge (PE) router, which is PE1 or 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, and so on. The PEs do the pseudowire emulation so the CEs can talk over the PSN. The PW lives between those PEs and goes across the provider network 🌸 VCCV gives you a few ways to build a control channel over the PW, between the PE routers at each end of it.
Figure 2 shows how the VCCV control channel fits into the pseudowire protocol stack 🧚
+-------------+ +-------------+
| 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 ChannelVCCV messages get encapsulated with the PWE3 encapsulation, as described in Sections 5 and 6 🎀 That means they get handled and processed the same way the PW PDUs they support are (or in some cases, a similar way). The thing to remember is that VCCV messages only get exchanged after the capability and the desire to exchange that traffic have been advertised between the PEs, and the VCCV types have been chosen. The two VCCV type spaces are the VCCV Control Channel types and the Connectivity Verification types. The advertising happens in Sections 5.3 and 6.3 💅
1.1. Specification of Requirements
Here's the BCP 14 part: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document should be read as described in [RFC2119] 🫶
2. Abbreviations 📚
Here's the glossary of all the acronyms you'll see:
AC Attachment Circuit [RFC3985].
AVP Attribute Value Pair [RFC3931].
CC Control Channel (used as CC Type).
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 ✨
okay bestie, VCCV's whole job is to verify and further diagnose the pseudowire forwarding path 🔍💖 It's made of three pieces:
- a way to signal VCCV capabilities to a peer PE 📣
- an encapsulation for VCCV control channel messages, so the receiving PE can intercept, interpret, and process them locally as OAM messages 🎀
- specs for how each VCCV operational mode works inside those VCCV messages 🧚
So when a pseudowire is first signaled using the Label Distribution Protocol (LDP) [RFC4447] or the Layer Two Tunneling Protocol version 3 (L2TPv3) [RFC3931], the initiating PE sends a message to the receiving PE asking it to set up the pseudowire 💌 That message got an upgrade and now includes VCCV capability information (see Section 4) ✨ That info tells the receiving PE which combinations of Control Channel (CC) and Connectivity Verification (CV) Types it can receive. If the receiving PE agrees to set up the PW, it sends its capabilities back in the next signaling message, so you know which CC and CV Types it can process 🫶 If more than one is listed in that message, the precedence rules for picking one are in Section 7 of this document 👑
Once the PW is signaled, data flows between the PEs at each end 🌊 That's when the PEs can start sending VCCV messages using the CC and CV Type combos we just talked about. VCCV defines an encapsulation that marks these messages as belonging to the control channel for the PW 🦋 The big idea is that the control channel gets processed the same way as PW data traffic, so it tests the PE's data plane for real. The PE also grabs these VCCV messages and processes them instead of forwarding them out of the AC toward the CE like they were regular data 🙈 So the most basic job of the VCCV control channel is checking connectivity of the pseudowire and the data plane that carries the PW's data path 💅 It's worth knowing that PW data traffic can have lots of combos of optional and mandatory data-plane encapsulations, so VCCV defines a bunch of CC and CV types to cover as many as possible 🌈 VCCV is built to support most of the existing combos, both mandatory and optional, and it also defines a default CC and CV Type combination for each PW Demultiplexer type, which we'll get into later in this document ⭐
VCCV can be used as a fault detection tool, a diagnostic tool, or both for pseudowires 🩺 An operator can run VCCV on a timed, ongoing schedule for proactive connectivity verification on an active pseudowire, or run it ad hoc or as needed as a manual connectivity check 🍓 When an operator invokes VCCV, they trigger one of the CC Types and one of the CV Types together 💜 The CV Types include LSP Ping [RFC4379] for MPLS PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs. The specification defines a matrix of acceptable CC and CV Type combinations further on 📋
The control channel maintained by VCCV can also carry fault detection status between the endpoints of the pseudowire 🚨 That status can then be translated into the native OAM status codes used by native access technologies, like ATM, Frame-Relay, or Ethernet 🔁 The details of that status interworking are out of scope for this document. It's only mentioned here to show how useful VCCV is for that kind of thing. The full details are in [MSG-MAP] and [RFC4447] 📚
4. CC Types and CV Types
okay this section is the menu of control channel types and what rides on them 🍽️ The VCCV Control Channel (CC) Type defines several possible types of control channel that VCCV can support. Those control channels can carry several types of protocols, which are defined by the Connectivity Verification (CV) Type 🎀 VCCV can support multiple CV Types at once, but it only uses a single CC Type. The specific types of VCCV packets a router can accept and send are indicated during capability advertisement, as described in Sections 5.3 and 6.3 💌 The VCCV CV Types are only used when they fit the PW demultiplexer in use. For example, the LSP Ping CV Type should only be used when MPLS Labels are used as the PW Demultiplexer 🧚
Once a set of VCCV capabilities has been received and advertised, a CC Type and CV Type(s) that match both the received and transmitted capabilities can be selected 🫶 In other words, a PE router only lets through Types that were both received and advertised, by doing a logical AND between the received and transmitted bitflag fields 🔥 The specific CC Type and CV Type(s) are then picked within the constraints and rules in Section 7. Once a specific CC Type has been chosen (meaning it matches both the transmitted and received VCCV CC capability), and it's been transmitted and replied to, this CC Type MUST be the only one used until the pseudowire is re-signaled 👑 Also, based on these rules and the procedures in Section 5.2 of [RFC4447], the pseudowire MUST be re-signaled if a different set of capabilities types is desired 💀 The relevant part of Section 5.2 of [RFC4447] says:
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 8-bit bitmasks. They show which specific CC or CV Type(s) (none, one, or more) of control channel packets may be sent on the VCCV control channel 🌸 The values are the numbers matching the actual bit set in the bitfield. What each CC and CV Type means depends on the PW type context it's defined in, either MPLS or L2TPv3 🦋
Control Channel (CC) Types:
For MPLS PWs, the defined CC Type values 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) - ReservedFor L2TPv3 PWs, the defined CC Type values 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) - ReservedConnectivity Verification (CV) Types:
For MPLS PWs, the defined CV Type values 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
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - ReservedFor L2TPv3 PWs, the defined CV Type values 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) - ReservedIf none of the types above are supported, the whole CC and CV Type Indicator fields SHOULD be sent as 0x00 (every bit in the bitfield set to 0) to tell the peer 🙈
If no capability is signaled, the peer MUST assume it has no VCCV capability and follow the procedures in this document for that case 🥺
5. VCCV Control Channel for MPLS PWs
When MPLS carries PW packets, VCCV packets ride over the MPLS LSP as described in this section 🚂 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 toward the destination PE can travel in-band with the PW's data, or out-of-band 🌈 In every case, the control channel traffic is not forwarded past the PE endpoints toward the Customer Edge (CE) devices. The VCCV messages get intercepted at the PE endpoints for exception processing instead 🛑
5.1. VCCV Control Channel Types for MPLS
Like we already covered in Section 4, a PE advertises which control channel types (CC Type) it supports 📢 Once the receiving PE picks a CC Type mode, it MUST continue using that mode until the PW is re-signaled 🔒 So if a new CC Type is wanted, the PW has to be torn down and re-established 😭
Ideally, the control channel would be completely in-band, following the same data-plane faith as PW data 🫧 When a control word is present on the PW, the control channel can be indicated 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) ✨
Okay so CC Type 1 is also called "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] decides whether a PW uses a control word 🌸 When a control word is in use, and that CW follows the "Generic PW MPLS Control Word" format (see Section 3 of [RFC4385]), you can create a Control Channel for VCCV messages 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] like this, 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 HeaderThe first nibble is set to 0001b to show 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 VCCVIt 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 called "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 so the VCCV control channel traffic could take a path that differs from 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 called "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 could take 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 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 😭
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 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 VCCVThe 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 ✨
okay so when L2TPv3 sets up a PW over an IP PSN 🌐, VCCV packets get carried over the L2TPv3 session, and this section is all about how that works 💖. L2TPv3 already has a built-in "Hello" keepalive for its control plane that runs in-band over IP or UDP (see Section 4.4 of [RFC3931]) 🫶. But here's the tea: that Hello only checks dead peers and paths for the whole group of sessions tied to the L2TP Control Connection. VCCV is the one that lets you test individual L2TP sessions 🦋. That's way more granular, which is iconic for troubleshooting problems inside the data plane of the L2TP endpoints themselves, or for getting extra connection status on each individual pseudowire 👑.
A PE advertises which Control Channel Type (CC Type) it can use, so everyone knows which of the possible control channel types are supported 🎀. Once the receiving PE picks a mode, it MUST keep using that mode until the PW gets re-signaled 🔒. So if you suddenly want a new CC Type, the PW must be torn down and re-established 💀.
An LCCE sends VCCV messages on an L2TPv3-signaled pseudowire for fault detection and diagnostics of the L2TPv3 session 🔍. The VCCV message travels in-band with the Session and follows the exact same path as the user data, because the IP header and L2TPv3 Session header are identical 🧚. The egress LCCE intercepts and processes the VCCV message, and it verifies the signaling and forwarding state of the pseudowire when the VCCV message arrives 🌸. Just so we're clear: the VCCV mechanism for L2TPv3 is mainly aimed at checking the pseudowire forwarding and signaling state at the egress LCCE 💅. It also helps when the L2TPv3 Control Connection and Session paths are not identical 🌈.
6.1. VCCV Control Channel Type for L2TPv3
To carry VCCV messages inside an L2TPv3 session data packet, the PW MUST be established so 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) gets signaled through the L2-Specific Sublayer AVP, Attribute Type 69, as defined in [RFC3931] 💖. The V-bit inside the L2-Specific Sublayer tells you 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
VCCV messages are told apart from user data by the V-bit 🦋. The V-bit is set to 1, which means a VCCV session message follows 🫶. The next three bits MUST be set to 0 when sending and ignored upon receipt 🙈. The remaining 28 bits (that's Version, Reserved, and Channel Type) follow the same definition, format, and number registry from Section 5 of [RFC4385] 🌸.
The Version and Reserved fields are set to 0 🍓. For the CV Type currently defined, ICMP Ping (0x01), the Channel Type can indicate IPv4 (0x0021) or IPv6 (0x0057) (see [RFC4385]) as the VCCV payload that comes right after the L2SS 🧚.
6.2. VCCV Connectivity Verification Type for L2TPv3
The VCCV message over L2TPv3 comes right after 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 in use, an ICMP Echo packet does the job of checking connectivity, using the encoding specified in [RFC0792] for ICMPv4 or [RFC4443] for ICMPv6 🔥. 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 whatever was used for the pseudowire in the configuration ⭐.
The ICMP Ping packet comes right after 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, along with 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 gets exchanged during 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 is a bitmask that shows the type of control channel(s) that may be used to receive OAM traffic 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 🍓. There's only one value defined in this document, but the CC Types field is included for forward compatibility, in case more CC Types need to be defined later 🔮.
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 also 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 is a bitmask that shows the specific type or types (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 it 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, which means it's 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 might 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 👑:
- Type 1: PWE3 Control Word with 0001b as first nibble
- Type 2: MPLS Router Alert Label
- 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 registries (see Sections 8.1.1 and 8.1.2, respectively) have been created in the Pseudo Wires Name Spaces, which you can reach 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 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) - ReservedThe 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) - ReservedThe most significant (high order) bit is labeled Bit 7, and the least significant (low order) bit is labeled Bit 0, see parenthetical "Value" 🔢.
8.2. PW Associated Channel Type ✨
Okay bestie, so the PW Associated Channel Types that VCCV uses (the ones from Sections 5.1.1 and 6.1) aren't brand-new numbers. They come from numbers that were already allocated in the Pseudowire Associated Channel Types Registry [RFC4385] 🗂️. You'll find that registry in the Pseudo Wires Name Spaces, reachable from [IANA.pwe3-parameters]. The main rules: 0x21 (Internet Protocol version 4) MUST be used whenever an IPv4 payload follows the Pseudowire Associated Channel Header, and 0x57 MUST be used when an IPv6 payload follows the Pseudowire Associated Channel Header. Iconic behaviour, honestly 💅
8.3. L2TPv3 Assignments 📋
Okay so Sections 8.3.1 through 8.3.3 are where new L2TP values get registered into registries IANA already runs. Section 8.3.4 is a whole new registry that got added to the existing L2TP name spaces, and IANA is going to keep it maintained. You can find the Layer Two Tunneling Protocol "L2TP" Name Spaces at [IANA.l2tp-parameters] 🌸
8.3.1. Control Message Attribute Value Pairs (AVPs)
This one's giving new AVP vibes 🎀. An additional AVP Attribute is specified in Section 6.3.1, and IANA defined it the way Section 2.2 of [RFC3438] describes.
Attribute
Type Description
--------- ----------------------------------
96 VCCV Capability AVP8.3.2. Default L2-Specific Sublayer Bits
The Default L2-Specific Sublayer has 8 bits in the low-order part of its header 🦋. This document defines one reserved bit in the Default L2-Specific Sublayer in Section 6.1, and IANA assigned it following IETF Consensus [RFC2434]. Slay 💖
Default L2-Specific Sublayer bits - per [RFC3931]
---------------------------------
Bit 0 - V (VCCV) bit8.3.3. ATM-Specific Sublayer Bits
The ATM-Specific Sublayer also has 8 bits in the low-order part of its header 🧚. Same energy here: this document defines one reserved bit in the ATM-Specific Sublayer in Section 6.1, and IANA assigned it following IETF Consensus [RFC2434].
ATM-Specific Sublayer bits - per [RFC4454]
--------------------------
Bit 0 - V (VCCV) bit8.3.4. VCCV Capability AVP Values
This is the brand-new registry, and IANA keeps it in the L2TP Name Spaces 🫶 It holds the CC Types and CV Types bitmasks for the VCCV Capability AVP defined in Section 6.3.1. Allocations have to go through the "IETF Consensus" policy defined in [RFC2434]. Any VCCV CC or CV Type assignment needs a description of that type and a reference to an RFC approved by the IESG.
IANA 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) - ReservedQuick bit-order check 👀: the most significant (high order) bit is labeled Bit 7, and the least significant (low order) bit is labeled Bit 0, which is the one shown in the parenthetical "Value".
9. Congestion Considerations 🌊
Okay so the bandwidth VCCV uses is recommended to be minimal compared to what the associated PW uses 💅 The VCCV channel's bandwidth is taken outside any allocation for PW data traffic, and it can be configurable. When you're doing resource reservation or network planning, you need to count both PW data and VCCV traffic.
VCCV applications (aka Connectivity Verification (CV) Types) MUST consider congestion and bandwidth usage implications, and they MUST provide details on bandwidth or packet frequency management 🔥. Some VCCV applications have bandwidth management built right into their protocols. Others can have their bandwidth configuration-limited, and rate-limiting those can be harmful because it could lead to wrongly declaring connectivity failures 😭. For all other VCCV applications, outgoing VCCV messages SHOULD be rate-limited so that aggressive connectivity verification doesn't eat up excessive bandwidth, cause congestion, turn into a denial-of-service attack, or generate an excessive packet rate at the CE-bound PE.
If those conditions can't be followed, an adaptive loss-based scheme SHOULD be applied to congestion-control outgoing VCCV traffic, so it competes fairly with TCP within an order of magnitude. One way to figure out an acceptable bandwidth for VCCV is described in [RFC3448] (TFRC), and other methods exist too 🦋 For example, bandwidth or packet frequency management can include any of these: negotiating a transmission interval or rate, throttling the transmission rate on "congestion detected" situations, a slow-start after a 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 🍓 The bit-rate you consider for a pseudowire depends on the PW type. For pseudowires that carry constant bit-rate traffic (for example, TDM PWs), the full bit-rate of the PW is used. For pseudowires that carry variable bit-rate traffic (for example, Ethernet PWs), the mean or sustained bit-rate of the PW is used.
As described in Section 10, incoming VCCV messages can be rate-limited as protection against denial-of-service attacks. That throttling or policing of incoming VCCV messages should not be more stringent than the bandwidth allocated to the VCCV channel, or you'll get false indications of connectivity failure 🙈
10. Security Considerations 🔐
Okay, this section is serious but I'm going to keep it fun 💀 Routers that implement VCCV create a Control Channel (CC) associated with a pseudowire. That control channel can be signaled (for example, using LDP or L2TPv3, depending on the PWE3) or statically configured. VCCV Connectivity Verification (CV) messages are sent over this control channel. So there are three different areas of concern from a security standpoint.
The first area is control plane parameter and status message attacks, meaning attacks on 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 connectivity verification negotiation extensions don't change the security aspects of Section 8.2 of [RFC4447] or Section 8.1 of [RFC3931]. Implementing IP source address filters may also help deter these types of attacks 🛡️
The second area is data-plane attacks, meaning attacks on the associated channel itself. Routers that implement the VCCV mechanisms are exposed to extra data-plane denial-of-service attacks, like these:
- An intruder could intercept or inject VCCV packets, which gives you 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 accidentally flood a peer router with VCCV messages, which could result in a denial of service. In particular, if a router has either implicitly or explicitly indicated that it can't support one or all of the VCCV types, but it's sent those messages in large enough quantity, that could cause a denial of service.
To protect against these potential attacks (whether deliberate or unintentional), a few mitigation techniques can be used:
- VCCV message throttling mechanisms can be used, especially in distributed implementations with a centralized control-plane processor and various line cards attached through some control-plane data path. In these setups, VCCV messages may get processed on the central processor after the receiving line card forwards them there. In that case, the path between the line card and the control processor can become saturated if VCCV traffic throttling isn't in place, which could lead to a complete denial of service for users of that line card. This kind of filtering is also useful for stopping unwanted VCCV messages, like ones sent on unwanted (and perhaps unadvertised) control channel types or VCCV types.
- Section 8.1 of [RFC4447] discusses ways to protect the data plane of MPLS PWs from data-plane attacks. However, running the connectivity verification protocol expands the range of possible data-plane attacks, so implementations MUST provide a method to secure the data plane 😤 That can be done by encrypting the data with IPsec running on MPLS packets encapsulated according to [RFC4023], or by architecting the MPLS network so that no external MPLS packets can be injected (a private MPLS network).
- For L2TPv3, data packet spoofing considerations are outlined in Section 8.2 of [RFC3931]. The L2TPv3 Session ID provides traffic separation, and the optional Cookie field adds extra protection against spoofing attacks. To get the most 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] ✨
The third and last area of concern is processing the actual contents of VCCV messages, meaning LSP Ping and ICMP messages. So the corresponding security considerations for those protocols also apply: LSP Ping [RFC4379], ICMPv4 Ping [RFC0792], and ICMPv6 Ping [RFC4443] 🧠
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 💜
12. References 📚
12.1. Normative References ✨
Okay bestie, these are the ones you NEED to have read first 💅 Every single one of these is a must-have foundation for the whole spec.
[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. 📖 This is the one that explains what all those capital words mean![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 🌸
These ones are extra juicy background reading. Totally optional, but so worth it 🫶
[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>.[MSG-MAP]Nadeau, T., "Pseudo Wire (PW) OAM Message Mapping", Work in Progress, March 2007. 🚧 Still a draft, so keep an eye out![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. ⚖️
Appendix A. Contributors' Addresses 💜
These are the lovely people who helped build this spec, so give them some love! 🫶
George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
EMail: swallow@cisco.comMonique Morrow
Cisco Systems, Inc.
Glatt-com
CH-8301 Glattzentrum
Switzerland
EMail: mmorrow@cisco.comYuichi Ikejiri
NTT Communication Corporation
1-1-6, Uchisaiwai-cho, Chiyoda-ku
Tokyo 100-8019
Shinjuku-ku
JAPAN
EMail: y.ikejiri@ntt.comKenji Kumaki
KDDI Corporation
KDDI Bldg. 2-3-2
Nishishinjuku
Tokyo 163-8003
JAPAN
EMail: ke-kumaki@kddi.comPeter B. Busschbach
Alcatel-Lucent
67 Whippany Road
Whippany, NJ, 07981
USA
EMail: busschbach@alcatel-lucent.com
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
USA
EMail: rahul@juniper.netLuca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
USA
EMail: lmartini@cisco.comAuthors' Addresses 🦋
Thomas D. Nadeau (editor)
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
EMail: tnadeau@lucidvision.comCarlos Pignataro (editor)
Cisco Systems, Inc.
7200 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
USA
EMail: cpignata@cisco.comFull 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. 💌
📦 where this page comes from
- ietf: rfc5085 2007-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms