VCCV GAL Indicator: Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator
A new way to tag pseudowire health-check packets with a reserved label, for pseudowires that run without a control word.
Nadeau, T., Martini, L., and S. Bryant, "Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator", RFC 7708, DOI 10.17487/RFC7708, November 2015, <https://www.rfc-editor.org/info/rfc7708>.
@misc{rfc7708,
series = {Request for Comments},
number = 7708,
howpublished = {RFC 7708},
publisher = {RFC Editor},
doi = {10.17487/RFC7708},
url = {https://www.rfc-editor.org/info/rfc7708},
author = {T. Nadeau and L. Martini and S. Bryant},
title = {{Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator}},
pagetotal = 9,
year = 2015,
month = nov,
} RFC text
Contents
Internet Engineering Task Force (IETF) T. Nadeau
Request for Comments: 7708 Brocade
Category: Standards Track L. Martini
ISSN: 2070-1721 S. Bryant
Cisco Systems
November 2015
Using a Generic Associated Channel Label
as a Virtual Circuit Connectivity Verification Channel Indicator
Abstract
The Virtual Circuit Connectivity Verification (VCCV) protocol
specified in RFC 5085 provides a control channel (CC) that is
associated with a pseudowire (PW). This document specifies an
additional VCCV control channel type to be used with pseudowires that
do not use the PW Control Word and that are carried over an MPLS
network. This new VCCV CC type uses the Generic Associated Channel
Label defined in RFC 5586 to distinguish VCCV packets from packets
carrying user data. This new VCCV CC type introduces compatibility
with the method of MPLS Label Switched Path Operations,
Administration, and Maintenance (OAM) identification, particularly in
MPLS Transport Profile (MPLS-TP) networks (RFC 5921).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
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) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided 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 . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The Virtual Circuit Connectivity Verification (VCCV) protocol is
specified in RFC 5085 [RFC5085]. This document specifies a new VCCV
control channel (VCCV CC) type to be used with pseudowires (PWs)
carried over an MPLS network that do not use the PW Control Word (CW)
[RFC4385]. This new VCCV CC type uses the Generic Associated Channel
Label (GAL) [RFC5586] to distinguish VCCV packets from packets
carrying user data. This new VCCV CC type provides compatibility
with the method of MPLS Label Switched Path (LSP) Operations,
Administration, and Maintenance (OAM) message identification, as used
in MPLS Transport Profile (MPLS-TP) networks [RFC5921].
VCCV currently specifies three CC types. VCCV CC Type 1 uses the PW
Control Word (CW) to distinguish VCCV packets from packets carrying
user data. VCCV CC Types 2 and 3 require IP encapsulation for OAM
packets. This was not an issue when [RFC5085] was designed, but it
is in conflict with the design goals of MPLS-TP [RFC5921], which do
not otherwise require the availability of IP. VCCV CC Type 2 is not
applicable to Multi-Segment PWs (MS-PWs) [RFC6073]. A MS-PW
operating without the CW therefore has to use VCCV CC Type 3, which
identifies VCCV packets on the basis of Time to Live (TTL) expiry.
Whilst less of an issue with a single segment PW (SS-PW), on an MS-PW
this requires accurately setting the TTL for expiry at the egress
Terminating Provider Edge (T-PE) [RFC6073]. In the event of an error
in the setting of the PW Label Stack Entry (LSE) TTL, VCCV packets
will not be received by the Terminating Provider Edge (T-PE) and may
leak into the attachment circuit [RFC6073]. The new VCCV CC type
defined in this specification addresses these problems for PWs that
do not use the CW.
Note that mandating that PWs use the PW CW is not a viable way to
address this issue. This is because:
o PWs without the CW are already widely deployed.
o There is a significant deployment of existing hardware that does
not support usage of the PW CW for some PW types.
o Some operators are concerned that the inclusion of the PW CW will
increase the PW packet size.
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 is not used, the Type 4 MPLS VCCV Control Channel (CC)
type defined in this section MAY be used. This is referred to as
VCCV CC Type 4 throughout the rest of this of this document. VCCV CC
Type 4 uses the encapsulation shown in Figure 1 in which the presence
of a GAL at the end of the MPLS label stack indicates that 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 1
The VCCV message body is preceded by a Generic Associated Channel
Header, as defined in [RFC5586], in which the Channel Type identifies
the type and format of the OAM message carried in the VCCV message
body.
The GAL LSE MUST contain the GAL reserved label as defined in
[RFC5586].
The PW LSE is constructed according to the existing procedures that
apply to the type of pseudowire that is in use.
Where the LSP used by the PW is subject to Equal-Cost Multipath
(ECMP) load balancing, a problem arises if any LSR on that LSP treats
special-purpose labels as ordinary labels in its ECMP selection
method. In these circumstances, the inclusion of a GAL following the
PW LSE can cause the OAM packet to take a different path through the
network than the corresponding PW data packets. If the LSP traverses
such equipment and this behaviour is not acceptable, then an
alternative VCCV type needs to be used. The requirement to not
include special-purpose labels in the load-balancing decision is
described in "MPLS Forwarding Compliance and Performance
Requirements" [RFC7325]. For equipment that conforms to this, the
VCCV type 4 traffic will follow the corresponding PW data packets.
4. FAT PWs
[RFC6391] specifies that when the flow-aware transport (FAT) of
pseudowires over an MPLS packet switched network has been signalled
or configured, the Flow LSE MUST be present. It further specifies
that "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 specifies that if the flow-aware transport of
pseudowires over an MPLS packet switched network has been signalled
or configured, then the presence of VCCV message is indicated by the
use of a GAL in place of the flow LSE.
This is consistent with [RFC6391], and the packet structure is
identical to that shown in Figure 1.
Flow LSEs are inserted into a PW label stack in order to enable the
distribution of the PW traffic among multiple equal-cost MPLS paths.
The use of GAL in place of the flow label will cause all OAM packets
to take exactly one of the possible paths through the network. As
noted in Section 3, the ECMP selection method may result in the path
taken by the OAM packets being different from the path taken by any
of the actual traffic flows. If this is not acceptable, then an
alternative VCCV type needs be used.
5. Multi-Segment Pseudowires
When using VCCV CC Type 4 for MS-PWs, a PE transmitting the VCCV
packet to a Switching PE (S-PE) MUST set the TTL to the appropriate
value to expire at that S-PE. An S-PE that supports this
specification MUST inspect PW packets that are received as a result
of TTL expiry, and determine whether a GAL follows the PW LSE. If a
GAL is present, the S-PE then processes the VCCV packet.
An S-PE that does not support this specification would be expected to
reject as malformed a VCCV CC Type 4 packet that was received. This
is because the S-PE would expect the PW LSE to be the bottom of stack
(the non-FAT case) and for the LSE at the bottom of stack not to be a
reserved label (both the FAT and the non-FAT cases). An S-PE that
did not make this reserved label check would then find that the first
nibble following the label stack was 0x1 and not the expected start
of an IP packet. Thus, it would be expected to also reject the
packet. This update to the behaviour of S-PEs is therefore backwards
compatible.
6. VCCV Capability Advertisement
The VCCV capability advertisement MUST match the C-bit setting that
is advertised in the PW FEC element [RFC4447]. If the C-bit is set,
indicating the use of the PW CW, then VCCV CC Type 4 MUST NOT be
advertised. If the C-bit is not set, indicating that the PW CW is
not in use, then equipment supporting this specification MUST
advertise VCCV CC Type 4. Advertisement of VCCV CC Type 1 and
advertisement of VCCV CC Type 4 are therefore mutually exclusive.
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 for cases where multiple CC Types are advertised, the
following precedence rules apply when choosing which CC Type to use:
1. Type 4: GAL VCCV Control Channel.
2. Type 2: MPLS Router Alert Label.
3. 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 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".
7. Manageability Considerations
Whilst the introduction of this additional VCCV CC type increases the
number of VCCV CC types that the operator needs to manage, it
addresses the issues with VCCV CC Types 2 and 3 described in
Section 1.
In the event of a misconfiguration of this VCCV CC type, the PW is
taken out of service and the operator advised as described in
Section 6.
Attention is drawn to the possible absence of fate sharing between PW
data packets and VCCV CC Type 4 packets described in Section 3 and
Section 4.
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.
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 in
order to identify VCCV type 4.
MPLS VCCV Control Channel (CC) Types
Bit (Value) Description Reference
============ =========== ==================
Bit 3 (0x08) Type 4: GAL RFC 7708
9.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 7708
10. 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. 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
AI ELI5
On this page
§1Why Another VCCV Channel Type
The Virtual Circuit Connectivity Verification (VCCV) protocol from RFC 5085 gives a pseudowire (PW) a control channel for checking that it works. Three channel types existed. Type 1 uses the PW Control Word (CW) to tell VCCV packets from user data. Types 2 and 3 need IP encapsulation for the OAM packets.
That IP requirement conflicts with the goals of MPLS-TP (RFC 5921), which do not otherwise need IP. Type 2 does not apply to multi-segment PWs (RFC 6073), so a multi-segment PW without the CW has to use Type 3, which relies on TTL expiry. If the TTL in the PW label stack entry is set wrongly, VCCV packets will not reach the terminating provider edge and may leak into the attachment circuit.
The RFC says that simply requiring the CW is not viable. PWs without the CW are already widely deployed, some existing hardware cannot use the CW for some PW types, and some operators worry that the CW makes packets bigger.
The old ways of marking check notes were either awkward or easy to get wrong. And you cannot just force everyone to use the old tag, because many trucks do not have the right holder for it.
§3The Type 4 Packet Format
When the PW CW is not used, VCCV CC Type 4 MAY be used. The presence of a GAL at the end of the MPLS label stack tells the receiver the packet carries a VCCV message. The GAL label stack entry (LSE) MUST contain the GAL reserved label from RFC 5586, and the PW LSE is built by the usual procedures for the PW type in use.
After the GAL comes a Generic Associated Channel Header. Its first nibble is 0001, followed by a version, a reserved byte and a Channel Type, which says what kind of OAM message the VCCV message body holds.
The packet gets a special label near the end that shouts 'I am a check note', and right after it a small header says what kind of check note it is.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
PW-LSE | PW LSE | 4 bytes | Pseudowire label stack entry, built as usual for the PW type. | |
GAL-LSE | GAL LSE | 4 bytes | Contains the GAL reserved label. | |
FIRST-NIBBLE | 0001 | 4 bits | First nibble of the Generic Associated Channel Header. | |
VERSION | Version | 4 bits | Version of the header. | |
RESERVED | Reserved | 1 byte | Reserved. | |
CHANNEL-TYPE | Channel Type | 2 bytes | Type and format of the OAM message in the body. |
§3Load Balancing, FAT PWs and Multi-Segment PWs
If the LSP uses equal-cost multipath (ECMP) and some router treats special-purpose labels like ordinary labels when choosing a path, the GAL can send OAM packets down a different path from the PW data. If that is not acceptable, another VCCV type has to be used. Equipment that follows RFC 7325 leaves special-purpose labels out of the load-balancing decision, so Type 4 traffic follows the data.
For flow-aware transport (FAT) PWs (RFC 6391), a flow LSE must be present, so the GAL takes the place of the flow LSE. The packet structure is the same as the basic one, and all OAM packets then take exactly one of the possible paths.
On a multi-segment PW, the sending PE MUST set the TTL so the packet expires at the target switching PE. A switching PE that supports this MUST inspect PW packets received through TTL expiry and check whether a GAL follows the PW LSE. One that does not support it would be expected to reject the packet as malformed, so the change is backwards compatible.
If the roads split into several lanes, the check note might take a different lane from the parcels. The RFC says to pick another method if that matters. On a long route with many stops, the sender sets a countdown so the note gets opened at the right stop.
§6Advertising and Choosing the Channel Type
The VCCV capability advertisement MUST match the C-bit in the PW FEC element (RFC 4447). If the C-bit is set, meaning the CW is used, Type 4 MUST NOT be advertised. If it is not set, equipment supporting this RFC MUST advertise Type 4. So advertising Type 1 and Type 4 together is mutually exclusive. A PE MAY also advertise other types.
When the remote PE supports Type 4 and the CW is not in use, the order of preference is Type 4 (GAL), then Type 2 (Router Alert Label), then Type 3 (PW label with TTL equal to 1).
If the remote PE sees Types 1 and 4 both advertised, or the C-bit set together with Type 4, it should report the error to the operator and send a Label Release Message with the status code VCCV Type Error.
Both ends say which kinds of check notes they understand and agree on the best one. If one end says something that makes no sense, the other tells the operator and refuses.
- 1stType 4 — GAL VCCV Control Channel.
- 2ndType 2 — MPLS Router Alert Label.
- 3rdType 3 — MPLS PW Label with TTL == 1.
§8Manageability and Security
Adding a fourth type means operators have one more VCCV type to manage, but it addresses the problems of Types 2 and 3. If this type is misconfigured, the PW is taken out of service and the operator is told, as described in the negotiation rules. The RFC also points out that PW data and Type 4 packets may not share fate, because of the ECMP and FAT behaviour above.
On security, the document raises nothing new beyond RFC 5085 and RFC 6073. It adds that the procedure removes the packet leaking that can occur with VCCV Type 3.
Having one more kind of note to keep track of is a small cost. The new kind is safer because notes no longer slip out where they should not.
§9IANA Assignments
IANA assigned a new bit in the MPLS VCCV Control Channel (CC) Types registry: Bit 3 (0x08), described as Type 4: GAL. It also assigned a new LDP status code, 0x00000035, named VCCV Type Error.
The official list of codes got two new entries: one number for the new note type and one for the 'wrong combination' error.