RFC 7708
Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator
RFC 7708: Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator 💖
Okay bestie, this is RFC 7708, and it's giving main character energy ✨ It's a Standards Track document from the IETF, dated November 2015, with ISSN 2070-1721. The authors are T. Nadeau (Brocade), L. Martini, and S. Bryant (both Cisco Systems). The title block doesn't list anything this document obsoletes or updates, so there's no drama there 🫶
Abstract
Okay so, VCCV (the Virtual Circuit Connectivity Verification protocol, from RFC 5085) gives you a control channel (CC) attached to a pseudowire (PW) 🦋 This document adds a new VCCV control channel type for PWs that don't use the PW Control Word and that ride over an MPLS network. The new type uses the Generic Associated Channel Label from RFC 5586 to tell VCCV packets apart from user data packets. It also plays nicely with the way MPLS Label Switched Path OAM identification works, especially in MPLS Transport Profile (MPLS-TP) networks (RFC 5921) 💅
Status of This Memo
This is an Internet Standards Track document. 🌸
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.
For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7708.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Type 4 MPLS VCCV Control Channel Type . . . . . . . . . . . . 3
4. FAT PWs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Multi-Segment Pseudowires . . . . . . . . . . . . . . . . . . 5
6. VCCV Capability Advertisement . . . . . . . . . . . . . . . . 5
7. Manageability Considerations . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9.1. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . . 7
9.2. LDP Status Code . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91. Introduction ✨
So VCCV is specified in RFC 5085 [RFC5085]. This document adds a new VCCV control channel (VCCV CC) type for pseudowires (PWs) that ride over an MPLS network and don't use the PW Control Word (CW) [RFC4385]. The new type uses the Generic Associated Channel Label (GAL) [RFC5586] to tell VCCV packets apart from packets carrying user data. It's also compatible with how MPLS Label Switched Path (LSP) Operations, Administration, and Maintenance (OAM) message identification works in MPLS Transport Profile (MPLS-TP) networks [RFC5921] 🦋
Now, VCCV has three CC types right now. 🧚 CC Type 1 uses the PW Control Word (CW) to tell VCCV packets apart from user data. CC Types 2 and 3 need IP encapsulation for OAM packets. That wasn't a problem when [RFC5085] was designed, but it clashes with the MPLS-TP design goals [RFC5921], which don't otherwise need IP to be available. CC Type 2 doesn't work for Multi-Segment PWs (MS-PWs) [RFC6073]. So an MS-PW running without the CW has to use CC Type 3, which figures out VCCV packets by Time to Live (TTL) expiry. That's less of a problem on a single segment PW (SS-PW), but on an MS-PW it means you have to set the TTL super accurately so it expires at the egress Terminating Provider Edge (T-PE) [RFC6073]. If the PW Label Stack Entry (LSE) TTL is set wrong, VCCV packets won't reach the T-PE and may leak into the attachment circuit [RFC6073]. The new VCCV CC type in this spec fixes these problems for PWs that don't use the CW. 💅
Mandating that PWs use the PW CW is not a viable fix, though, and here's why:
- PWs without the CW are already widely deployed.
- There's a big install base of existing hardware that doesn't support the PW CW for some PW types.
- Some operators are worried that adding the PW CW will make PW packets bigger.
2. Requirements Language 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
3. Type 4 MPLS VCCV Control Channel Type 🦋
When the PW CW isn't used, the Type 4 MPLS VCCV Control Channel (CC) type defined in this section MAY be used. From here on, this is called VCCV CC Type 4. VCCV CC Type 4 uses the encapsulation in Figure 1, where a GAL at the end of the MPLS label stack tells you the packet carries a VCCV message. 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW LSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL LSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ VCCV Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1So the VCCV message body comes right after a Generic Associated Channel Header (defined in [RFC5586]), and the Channel Type in that header tells you the type and format of the OAM message inside the body. 🍓
The GAL LSE MUST contain the GAL reserved label as defined in [RFC5586]. 💖
The PW LSE gets built using the existing rules for whatever type of pseudowire is in use. ✨
Now the tricky bit 👀 When the LSP carrying the PW is doing Equal-Cost Multipath (ECMP) load balancing, things can go sideways if any LSR on that LSP treats special-purpose labels as ordinary labels when it picks an ECMP path. In that case, putting a GAL right after the PW LSE can send the OAM packet down a different path than the matching PW data packets. If your LSP goes through gear like that and this behaviour isn't acceptable, you'll need to use a different VCCV type. The rule about not including special-purpose labels in the load-balancing decision is described in "MPLS Forwarding Compliance and Performance Requirements" [RFC7325]. For equipment that follows it, VCCV type 4 traffic will follow the same path as the corresponding PW data packets. 🫶
4. FAT PWs 🌸
[RFC6391] says that when flow-aware transport (FAT) of pseudowires over an MPLS packet switched network has been signalled or configured, the Flow LSE MUST be present. It also says "the flow label MUST NOT be an MPLS reserved label (values in the range 0..15) [RFC3032]", and that "If a flow LSE is present, it MUST be checked to determine whether it carries a reserved label. If it is a reserved label, the packet is processed according to the rules associated with that reserved label; otherwise, the LSE is discarded."
This document says that if FAT of pseudowires over an MPLS packet switched network has been signalled or configured, then a VCCV message is indicated by using a GAL in place of the flow LSE. 🦋
That matches [RFC6391], and the packet structure is exactly the same as Figure 1.
Flow LSEs get stuck into a PW label stack so PW traffic can be spread across several equal-cost MPLS paths. Using a GAL in place of the flow label means all OAM packets will take exactly one of the possible paths through the network. As noted in Section 3, the ECMP selection method might mean the OAM packets take a different path from the actual traffic flows. If that's not acceptable, you'll need to use a different VCCV type. 💅
5. Multi-Segment Pseudowires 💜
When VCCV CC Type 4 is used for MS-PWs, a PE sending the VCCV packet to a Switching PE (S-PE) MUST set the TTL to the appropriate value so it expires at that S-PE. An S-PE that supports this specification MUST inspect PW packets received as a result of TTL expiry, and figure out whether a GAL follows the PW LSE. If a GAL is there, the S-PE goes ahead and processes the VCCV packet. 🧚
An S-PE that doesn't support this specification would be expected to reject a received VCCV CC Type 4 packet as malformed. That's because the S-PE would expect the PW LSE to be the bottom of the stack (the non-FAT case), and it would expect the LSE at the bottom of the stack not to be a reserved label (in both the FAT and non-FAT cases). An S-PE that skipped this reserved label check would then find that the first nibble after the label stack was 0x1, not the expected start of an IP packet. So it would be expected to reject the packet too. Basically, this update to S-PE behaviour is backwards compatible, and that's iconic 👑
6. VCCV Capability Advertisement ✨
okay so the VCCV capability advertisement MUST match the C-bit setting that's advertised in the PW FEC element [RFC4447] 🎀 If the C-bit is set, which means the PW CW is in use, then VCCV CC Type 4 MUST NOT be advertised 🙅♀️ If the C-bit is not set, which means the PW CW is not in use, then equipment supporting this specification MUST advertise VCCV CC Type 4 💖 So advertising VCCV CC Type 1 and VCCV CC Type 4 is mutually exclusive, bestie. They literally can't be in the same group chat 💅
A PE supporting VCCV CC Type 4 MAY advertise other VCCV CC types as defined in [RFC5085] .
If the remote PE supports VCCV CC Type 4, and the PW CW is not in use, then when multiple CC Types are advertised, these precedence rules decide which CC Type gets picked 👑
- Type 4: GAL VCCV Control Channel.
- Type 2: MPLS Router Alert Label.
- Type 3: MPLS PW Label with TTL == 1.
If the remote PE finds that VCCV CC Types 1 and 4 are both advertised, or that the C-bit is set and VCCV CC Type 4 is advertised, then it should report the error to the operator through the management interface in use, and send a Label Release Message with a status code "VCCV Type Error" 😭 that's a whole mess, so the operator needs to know asap 🚨
7. Manageability Considerations 🧚
Whilst the introduction of this additional VCCV CC type means the operator has a few more VCCV CC types to manage 📋 it also fixes the issues with VCCV CC Types 2 and 3 described in Section 1. Lowkey a glow-up 🌸
If this VCCV CC type gets misconfigured, the PW is taken out of service and the operator gets advised as described in Section 6 🙈
Heads up, bestie: attention is drawn to the possible absence of fate sharing between PW data packets and VCCV CC Type 4 packets, as described in Section 3 and Section 4. The data packets and the VCCV CC Type 4 packets might not share a fate, so keep an eye on that 👀
8. Security Considerations 🔐
This document does not by itself raise any new security considerations beyond those described in [RFC5085] and [RFC6073] 🛡️ [RFC6073] provides detailed operational procedures that can be used to verify the MS-PW connectivity ✅ In addition, the procedure specified in this document eliminates the possibility of packet leaking that can occur with VCCV Type 3. Iconic, no cap 💜
9. IANA Considerations 📚
9.1. MPLS VCCV Control Channel (CC) Type 4
IANA has assigned a new bit from the MPLS VCCV Control Channel (CC) Types registry in the "Pseudowire Name Spaces (PWE3)" registry, so that VCCV type 4 can be identified 🦋
MPLS VCCV Control Channel (CC) Types
Bit (Value) Description Reference
============ =========== ==================
Bit 3 (0x08) Type 4: GAL RFC 77089.2. LDP Status Code
IANA has assigned a new Status Code from the "Label Distribution Protocol (LDP) Parameters" registry 🌈
Status Code Name Space
Range/Value E Description Reference
=========== = =============== =========
0x00000035 0 VCCV Type Error RFC 770810. References 📖
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC4385,
February 2006, <http://www.rfc-editor.org/info/rfc4385>.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447,
DOI 10.17487/RFC4447, April 2006,
<http://www.rfc-editor.org/info/rfc4447>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<http://www.rfc-editor.org/info/rfc5586>.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073,
DOI 10.17487/RFC6073, January 2011,
<http://www.rfc-editor.org/info/rfc6073>.
[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
Regan, J., and S. Amante, "Flow-Aware Transport of
Pseudowires over an MPLS Packet Switched Network",
RFC 6391, DOI 10.17487/RFC6391, November 2011,
<http://www.rfc-editor.org/info/rfc6391>.10.2. Informative References
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<http://www.rfc-editor.org/info/rfc5921>.
[RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
and C. Pignataro, "MPLS Forwarding Compliance and
Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
August 2014, <http://www.rfc-editor.org/info/rfc7325>.Acknowledgments 🫶
The authors wish to thank Alexander (Sasha) Vainshtein for his proposal to make the GAL and Flow labels mutually exclusive. This proposal led to a significant simplification of this design, which is so iconic 🙌 The authors also thank Sasha, Matthew Bocci, Loa Andersson, and Deborah Brungard for their review comments 💕
Authors' Addresses 💌
Thomas D. Nadeau
Brocade
Email: tnadeau@lucidvision.com
Luca Martini
Cisco Systems
Email: lmartini@cisco.com
Stewart Bryant
Cisco Systems
Email: stewart.bryant@gmail.com📦 where this page comes from
- ietf: rfc7708 2015-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms