RFC 5885
Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)
RFC 5885: Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) 💖
Okay bestie, the header is giving official paperwork 📄🎀. It's from the IETF (Internet Engineering Task Force), Request for Comments 5885, and it's a Standards Track doc, so it's actual Internet protocol stuff. It came out in June 2010 with ISSN 2070-1721. The editors are T. Nadeau (BT) and C. Pignataro (Cisco Systems, Inc.), both marked "Ed." because they edited it. The header doesn't list anything it obsoletes or updates, so there's nothing to cross-check there ✨.
Abstract ✨
Okay so this doc defines Connectivity Verification (CV) Types for BFD (Bidirectional Forwarding Detection) running over VCCV (Virtual Circuit Connectivity Verification) 🦋. VCCV gives a pseudowire (PW) its own control channel, plus the operations and management stuff like connectivity verification that runs over that channel. Main character energy 💅.
Status of This Memo 📜
This is an Internet Standards Track document 🎀.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 🌸.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5885 🔗.
Copyright Notice ©️
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 🧚.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this doc was published. Read those carefully, because they spell out your rights and restrictions for this doc. Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🧾.
Some of this doc may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get a proper license from those copyright holders, this doc may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈.
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Bidirectional Forwarding Detection Connectivity
Verification . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. BFD CV Type Operation . . . . . . . . . . . . . . . . . . 4
3.2. BFD Encapsulation . . . . . . . . . . . . . . . . . . . . 5
3.3. CV Types for BFD . . . . . . . . . . . . . . . . . . . . . 7
4. Capability Selection . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV . 10
5.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 10
5.3. L2TPv3 CV Types for the VCCV Capability AVP . . . . . . . 11
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 131. Introduction 🦋
Okay so this doc is about Connectivity Verification (CV) Types for BFD over VCCV. VCCV [RFC5085] gives a pseudowire (PW) a control channel, plus the operations and management functions, like connectivity/fault verification, that run over it 💅.
BFD [RFC5880] runs over the VCCV control channel mainly as a pseudowire fault detection mechanism, catching data-plane failures 🔍. Some BFD CV Types can also carry fault status between the endpoints of the pseudowire. That info can then be translated into the native Operations, Administration, and Maintenance (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 doc and are only mentioned to show why BFD over VCCV is useful for this stuff. You'll find those details in [OAM-MSG-MAP] 📖.
The new BFD CV Types don't care which PW demultiplexer is used, so they work for both MPLS and Layer Two Tunneling Protocol version 3 (L2TPv3) pseudowire demultiplexers 🧚. This doc covers BFD VCCV operation over single-segment pseudowires (SS-PWs). It only describes procedures for BFD asynchronous mode ✨.
2. 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] 💜.
The reader is expected to know the terminology and abbreviations defined in [RFC5085] 🤓.
3. Bidirectional Forwarding Detection Connectivity Verification 🎀
VCCV can support several Connectivity Verification (CV) Types. This section defines new CV Types for when BFD is the VCCV payload ✨.
Four CV Types are defined for BFD. Table 1 sums them up, grouped by encapsulation (with or without IP/UDP headers) and by functionality (fault detection only, or fault detection plus status signaling) 🍓.
+----------------------------+--------------+-----------------------+
| | Fault | Fault Detection and |
| | Detection | Status Signaling |
| | Only | |
+----------------------------+--------------+-----------------------+
| BFD, IP/UDP Encapsulation | 0x04 | 0x08 |
| (with IP/UDP Headers) | | |
| | | |
| BFD, PW-ACH Encapsulation | 0x10 | 0x20 |
| (without IP/UDP Headers) | | |
+----------------------------+--------------+-----------------------+
Table 1: Bitmask Values for BFD CV Types3.1. BFD CV Type Operation 🚀
When heart-beat indication is necessary for one or more PWs, BFD [RFC5880] keeps a continuous eye on the PW data path. In some operational modes, it also propagates PW receive and transmit defect state indications 👀.
To use BFD, both ends of the PW connection need to agree on the BFD CV Type 🤝:
- For statically provisioned pseudowires, both ends need to be statically configured to use the same BFD CV Type. They also need to be statically configured for VCCV with the same CC Type.
- For dynamically established pseudowires, both ends of the PW must have signaled that a control channel exists and that they can run BFD on it (see Sections 3.3 and 4).
Once a node has picked a valid BFD CV Type to use, either statically provisioned or selected dynamically after the node has both signaled and received signaling of these capabilities from its peer, it starts sending BFD Control packets 💌:
- The BFD Control packets are sent on the VCCV control channel. The VCCV control channel gives the context needed to bind and bootstrap the BFD session, since discriminator values are not exchanged. The pseudowire demultiplexer field (for example, MPLS PW Label or L2TPv3 Session ID) gives the context needed to demultiplex the first BFD Control packet, so single-hop BFD initialization procedures are followed (see Section 3 of [RFC5881] and Section 6 of [RFC5882]) 🧩.
- A single BFD session exists per pseudowire. Both PW endpoints take the Active role by sending initial BFD Control packets with a
Your Discriminatorfield of zero. BFD Control packets received with aYour Discriminatorfield of zero are associated with the BFD session bound to the PW 🔗. - BFD MUST be run in asynchronous mode (see [RFC5880]) 🫶.
So BFD VCCV operation for PWs is symmetrical, and that's iconic 👑. Both endpoints of the bidirectional pseudowire MUST send BFD messages on the VCCV control channel 💅.
The BFD state machine details are per Section 6.2 of [RFC5880]. Here's a scenario to show how it works 🌈. When the downstream PE (D-PE) doesn't get BFD Control messages from its upstream peer PE (U-PE) for a certain number of transmission intervals, D-PE declares the PW down in its receive direction. That number is provisioned by the operator as Detect Mult (detection time multiplier) [RFC5880]. In other words, D-PE enters the "PW receive defect" state for this PW 😭. After this calculated Detection Time (see Section 6.8.4 of [RFC5880]), D-PE declares the session Down and signals that to the remote end using the State (Sta) with Diagnostic code 1 (Control Detection Time Expired). Then U-PE declares the PW is down in its transmit direction. It sets the State to Down with Diagnostic code 3 (Neighbor signaled session down) in its control messages to D-PE, and U-PE enters the "PW transmit defect" state for this PW 💀. How it processes this error further, and whether it passes this status on to the attachment circuits, is out of scope for this spec and is defined in [OAM-MSG-MAP] 🙈.
3.2. BFD Encapsulation ✨
okay so the VCCV message is basically a BFD Control packet [RFC5880] wrapped up in whatever encapsulation the CV Type says to use 🎀 There are two ways a BFD connectivity verification packet can get wrapped over the VCCV control channel. This doc defines four BFD CV Types (see Section 3) and they split into two pairs based on encapsulation 🦋 Table 1 in Section 3 has the full rundown.
- IP/UDP BFD Encapsulation (BFD with IP/UDP Headers) 💖
Method one is giving full IP/UDP realness. The VCCV encapsulation of BFD includes the IP/UDP headers as defined in Section 4 of [RFC5881]. So BFD Control packets ride in UDP with destination port 3784 and a source port somewhere in 49152 through 65535 🌸 The IP Protocol Number and UDP Port numbers are how the VCCV payloads tell each other apart (ICMP Ping and LSP Ping from [RFC5085], plus BFD).
The IP version (IPv4 or IPv6) MUST match the IP version used for signaling for dynamically established pseudowires, or it MUST be configured for statically provisioned pseudowires. The source IP address is the sender's address. The destination IP address is a randomly chosen IPv4 address from the 127/8 range, or an IPv6 address from the 0:0:0:0:0:FFFF:127.0.0.0/104 range 💅 The reasoning behind that is explained in Section 2.1 of [RFC4379]. The Time to Live/Hop Limit and Generalized TTL Security Mechanism (GTSM) procedures from Section 5 of [RFC5881] apply to this encapsulation, so the TTL/Hop Limit gets set to 255 🔥
If the PW is established by signaling, then the BFD CV Type used for this encapsulation is either 0x04 or 0x08 ✨
- PW-ACH BFD Encapsulation (BFD without IP/UDP Headers) 🧚
Method two skips the IP/UDP headers entirely 🦋 A BFD Control packet (format defined in Section 4 of [RFC5880]) gets encapsulated directly in the VCCV control channel (see Sections 6 and 8 of [RFC5882]). Because of that, a pseudowire MUST use the PW Associated Channel Header (PW-ACH) Control Word format (see [RFC5586]) for its Control Word (CW), or the L2-Specific Sublayer (L2SS, used in L2TPv3) if that's what it's using 🫶
In this encapsulation, a "raw" BFD Control packet (that's a BFD Control packet as defined in Section 4.1 of [RFC5880] without IP/UDP headers) sits right after the PW-ACH 💜 The PW-ACH Channel Type is what tells you the Associated Channel is carrying "raw" BFD. The PW Associated Channel (PWAC) is defined in Section 5 of [RFC4385], and its Channel Type field is what separates the VCCV payload types 🌈
How PW-ACH shows up on different VCCV CC Types: CC Type 1, Type 2, and Type 3 each get their own section, which are Sections 5.1.1, 5.1.2, and 5.1.3 of [RFC5085] respectively. In every case you need a CW (see Section 7 of [RFC4385]) 🍓 When VCCV carries PW-ACH-encapsulated BFD (aka "raw" BFD), the PW-ACH Channel Type (in the pseudowire CW or the L2SS') MUST be set to 0x0007. That value means "BFD Control, PW-ACH-encapsulated," which is BFD without IP/UDP headers (see Section 5.2). This is what lets you figure out the encased BFD payload when you're demultiplexing the VCCV control channel 👑
If the PW is established by signaling, then the BFD CV Type used for this encapsulation is either 0x10 or 0x20 ⭐
Quick recap, bestie 💀 For IP/UDP encapsulation of BFD (BFD with IP/UDP headers), if a PW Associated Channel Header is used, the Channel Type MUST indicate either IPv4 (0x0021) or IPv6 (0x0057). For PW-ACH encapsulation of BFD (BFD without IP/UDP headers), the PW Associated Channel Header MUST be used, and the Channel Type MUST indicate BFD Control packet (0x0007).
3.3. CV Types for BFD 🌸
The CV Type is a bitmask field that says which specific CV Type or Types (none, one, or more) of VCCV packets may be sent on the VCCV control channel 🎀 The CV Types in the table below add to the ones already defined in [RFC5085]. The values in parentheses are the numbers for the actual bit being set in the CV Type bitfield.
BFD CV Types:
The defined values for the different BFD CV Types for MPLS and L2TPv3 PWs are:
Bit (Value) Description
============ ====================================================
Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
AC/PW Fault Status SignalingWorth noting: four BFD CV Types came from mixing two encapsulations with two functions. Table 1 in Section 3 has the breakdown 🦋
Since BFD is bidirectional, before you pick a BFD CV Type to use on dynamically established pseudowires, there MUST be common CV Types between what's advertised and what's received. Only the BFD CV Types that were both advertised and received are up for grabs. Also, only one BFD CV Type can be used at a time, because picking one excludes all the others 💅
Here's the list of rules, restrictions, and clarifications for using BFD CV Types 💖
- BFD CV Types used for fault detection and status signaling (CV Types 0x08 and 0x20) SHOULD NOT be used when a control protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available that can signal the AC/PW status to the remote endpoint of the PW. More details can be found in [OAM-MSG-MAP] 🙈
- BFD CV Types used for fault detection only (CV Types 0x04 and 0x10) can be used whether or not a protocol that can signal AC/PW status is available. This covers both statically provisioned and dynamically signaled pseudowires ✨
- 2.1. In this case, BFD is used exclusively to detect faults on the PW. If you want to convey AC/PW fault status, you'll need some means other than BFD. Examples include LDP status messages when MPLS is the transport (see Section 5.4 of [RFC4447]), and the Circuit Status Attribute Value Pair (AVP) in an L2TPv3 SLI message for L2TPv3 (see Section 5.4.5 of [RFC3931]) 🌈
- Pseudowires that don't use a CW or L2SS using the PW Associated Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (that's PW-ACH encapsulation of BFD, without IP/UDP headers) 🧚
- 3.1. PWs that use a PW-ACH include CC Type 1 (for both MPLS and L2TPv3, as defined in Sections 5.1.1 and 6.1 of [RFC5085]), and MPLS CC Types 2 and 3 when using a Control Word (as specified in Sections 5.1.2 and 5.1.3 of [RFC5085]). This restriction comes from the fact that the encapsulation uses the Channel Type in the PW-ACH 🍓
- 3.2. PWs that don't use a PW-ACH can use the VCCV BFD encapsulation with IP/UDP headers, which is the only VCCV BFD encapsulation supported for them. Using the IP/UDP encapsulated BFD CV Types allows concurrent use of other VCCV CV Types that use an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping defined in [RFC5085]) 💜
- Only a single BFD CV Type can be selected and used. All BFD CV Types are mutually exclusive. After selecting a BFD CV Type, a node MUST NOT use any of the other three BFD CV Types 👑
- Once a PE has chosen a single BFD CV Type to use, it MUST continue using it until the PW is re-signaled. To change the negotiated and selected BFD CV Type, the PW must be torn down and re-established 😭
4. Capability Selection 💅
The precedence rules for choosing CC and CV Types are clearly laid out in Section 7 of [RFC5085] 🎀 This section adds to those rules when the BFD CV Types defined here are supported. Picking a specific BFD CV Type out of the four available depends on several factors, as described in Section 3.3. Since BFD is bidirectional, only CV Types that are both received and sent in VCCV capability signaling advertisements can be selected 🦋
When multiple BFD CV Types are advertised, and after applying the rules in Section 3.3, you figure out which set both ends of the pseudowire have in common. If the two ends share more than one BFD CV Type, you go through the following list from the lowest list number to the highest, and the CV Type with the lowest list number is the one that gets used 🌸
- 0x20 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW Fault Detection and AC/PW Fault Status Signaling ⭐
- 0x10 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW Fault Detection only 🧚
- 0x08 - BFD IP/UDP-encapsulated, for PW Fault Detection and AC/PW Fault Status Signaling 🍓
- 0x04 - BFD IP/UDP-encapsulated, for PW Fault Detection only 🌈
5. IANA Considerations 🌷
5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV 🦋
The VCCV Interface Parameters Sub-TLV codepoint is defined in [RFC4446], and the VCCV CV Types registry is defined in [RFC5085]. This section lists the new BFD CV Types 💖
IANA has augmented the "VCCV Connectivity Verification (CV) Types" registry in the Pseudowire Name Spaces reachable from [IANA]. These are bitfield values. CV Type values 0x04, 0x08, 0x10, and 0x20 are specified in Section 3 of this document ✨
MPLS Connectivity Verification (CV) Types:
Bit (Value) Description
============ ====================================================
Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling5.2. PW Associated Channel Type 🎀
The PW Associated Channel Types used by VCCV rely on numbers that were already allocated from the Pseudowire Associated Channel Types Registry [RFC4385], in the Pseudowire Name Spaces reachable from [IANA] 🫶
IANA has reserved a new Pseudowire Associated Channel Type value, as follows:
Registry:
TLV
Value Description Follows Reference
------ ---------------------------------- ------- ---------------
0x0007 BFD Control, PW-ACH encapsulation No [This document]
(without IP/UDP Headers)5.3. L2TPv3 CV Types for the VCCV Capability AVP 🎀
okay so this bit is the L2TPv3 version of the CV types list 🦋 It says the new BFD CV Types get added to the existing "VCCV Capability AVP" registry over in the L2TP name spaces. You can reach those name spaces from [IANA] 🌸
IANA has already reserved these L2TPv3 CV Types in the VCCV Capability AVP Values registry, and the table is literally the whole thing 💅
VCCV Capability AVP (Attribute Type 96) Values
----------------------------------------------
L2TPv3 Connectivity Verification (CV) Types:
Bit (Value) Description
============ ====================================================
Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling6. Congestion Considerations 🌊
okay this one is a big deal bestie 😭 The congestion considerations that apply to [RFC5085] also apply to this mode of operation. This section just spells out how they show up here 💖
BFD as a VCCV application is required to give details on congestion and bandwidth. BFD gives you a desired minimum transmit interval and a required minimum receive interval, it negotiates the transmission interval using those configurable fields, and it sends a packet of fixed size, which is what sets the transmission rate. So the bandwidth use is limited by configuration, which is honestly so clean 🧚 As [RFC5085] says, that's enough protection against congestion as long as BFD's configured maximum bit-rate is tiny compared to the bit-rate of the pseudowire the VCCV channel is attached to ✨
But here's the tea ☕ If the pseudowire bit-rate can't be guaranteed to be tiny, like with highly variable bit-rate pseudowires or congestion-responsive ones, BFD will be required to run an adaptive congestion control mechanism. For example, that could mean throttling the transmission rate when "congestion detected" shows up, and doing a slow-start after a shutdown caused by congestion, until basic connectivity is verified 🫶
Since BFD's bandwidth is limited by configuration, the VCCV channel MUST NOT be rate-limited below this maximum configurable bandwidth, or BFD just won't work right 💀 The VCCV channel could do rate-limiting above the maximum BFD rate to guard against a misbehaving BFD application, so everything can coexist peacefully 🌈 Also, the VCCV channel SHOULD NOT run any extra congestion control loop that would interfere with or negatively interact with BFD's own. And that's it, there are no additional congestion considerations 🎀
7. Security Considerations 🔐
this section is serious, so we're keeping it complete 🙈 Routers that implement the additional CV Types defined here are subject to the same security considerations as defined in [RFC5085], [RFC5880], and [RFC5881]. This specification doesn't raise any additional security issues beyond those. The IP/UDP-encapsulated BFD uses the TTL/Hop Limit procedures described in Section 5 of [RFC5881], including the Generalized TTL Security Mechanism (GTSM) as a security mechanism 🛡️
8. Acknowledgements 🫶
this work forks from an earlier revision of the PWE3 WG document that became [RFC5085]. A bunch of people contributed to that, including Rahul Aggarwal, Peter B. Busschbach, Yuichi Ikejiri, Kenji Kumaki, Luca Martini, Monique Morrow, George Swallow, and others 💜
Mustapha Aissaoui, Sam Aldrin, Stewart Bryant, Peter B. Busschbach, Annamaria Fulignoli, Vishwas Manral, Luca Martini, Dave McDysan, Ben Niven-Jenkins, Pankil Shah, Yaakov Stein, and George Swallow gave useful feedback and valuable comments and suggestions that improved newer versions of this document. Iconic behaviour from all of them 👑
9. References 📚
9.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [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.
- [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
- [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", RFC 5880, June 2010.
- [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
- [RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010.
9.2. Informative References
- [IANA] Internet Assigned Numbers Authority, "Protocol Registries", <http://www.iana.org>.
- [OAM-MSG-MAP] Aissaoui, M., Busschbach, P., Morrow, M., Martini, L., Stein, Y., Allan, D., and T. Nadeau, "Pseudowire (PW) OAM Message Mapping", Work in Progress, March 2010.
- [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.
- [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.
- [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
Authors' Addresses 💌
Thomas D. Nadeau (editor)
BT
BT Centre
81 Newgate Street
London EC1A 7AJ
United Kingdom
EMail: tom.nadeau@bt.com
Carlos Pignataro (editor)
Cisco Systems, Inc.
7200 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
USA
EMail: cpignata@cisco.com📦 where this page comes from
- ietf: rfc5885 2010-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms