Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator
Extracted elements (19)
Mandating that PWs use the PW Control Word is not viable because PWs without the CW are already widely deployed, significant existing hardware does not support the CW for some PW types, and some operators are concerned about increased packet size from the CW.
Using GAL in place of the flow label for FAT PWs ensures a consistent OAM encapsulation structure (identical to Figure 1) and is proposed by Alexander Vainshtein to make GAL and Flow labels mutually exclusive, significantly simplifying the design.
VCCV CC Types 2 and 3 require IP encapsulation for OAM packets, conflicting with MPLS-TP design goals that do not otherwise require IP availability. Type 2 is not applicable to MS-PWs, and Type 3 (TTL-based) risks VCCV packets failing to reach the T-PE or leaking into the attachment circuit if the PW LSE TTL is set incorrectly. Type 4 using GAL addresses these problems for PWs that do not use the Control Word.
An S-PE that does not support VCCV CC Type 4 will reject a Type 4 packet as malformed because it expects either the PW LSE to be the bottom of stack (non-FAT) or the bottom-of-stack LSE not to be a reserved label. This behavior makes the update backwards compatible with non-supporting S-PEs.
The use of GAL in place of the flow label causes all OAM packets to take exactly one of the possible equal-cost paths, which may differ from the paths taken by actual traffic flows. If fate sharing between OAM and data packets is required, an alternative VCCV type must be used.
Where the LSP is subject to ECMP load balancing, some LSRs may treat special-purpose labels as ordinary labels, causing GAL-carrying OAM packets to take a different path than the corresponding PW data packets. If this path divergence is not acceptable, an alternative VCCV CC type must be used.
An S-PE that supports this specification MUST inspect PW packets received as a result of TTL expiry and determine whether a GAL follows the PW LSE; if a GAL is present, the S-PE processes the VCCV packet.
If the C-bit is not set (PW CW not in use), then equipment supporting this specification MUST advertise VCCV CC Type 4. Advertisement of VCCV CC Type 1 and Type 4 are therefore mutually exclusive.
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, it should report the error to the operator through the management interface and send a Label Release Message with status code 'VCCV Type Error'.
The GAL LSE MUST contain the GAL reserved label as defined in RFC 5586.
The VCCV capability advertisement MUST match the C-bit setting advertised in the PW FEC element (RFC 4447). If the C-bit is set (CW in use), VCCV CC Type 4 MUST NOT be advertised.
When flow-aware transport (FAT) of pseudowires has been signalled or configured, the presence of a VCCV message MUST be indicated by the use of a GAL in place of the flow LSE, consistent with RFC 6391.
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.
VCCV CC Type 4 is a new MPLS VCCV control channel type that uses the Generic Associated Channel Label (GAL) at the end of the MPLS label stack to indicate that a packet carries a VCCV message, used when the PW Control Word is not in use.
When the PW CW is not in use and multiple CC types are advertised, the following precedence applies for CC type selection: (1) Type 4: GAL VCCV Control Channel, (2) Type 2: MPLS Router Alert Label, (3) Type 3: MPLS PW Label with TTL == 1.
IANA assigned Bit 3 (value 0x08) in the MPLS VCCV Control Channel (CC) Types registry (Pseudowire Name Spaces / PWE3) to identify VCCV CC Type 4: GAL.
IANA assigned Status Code 0x00000035 (E-bit = 0, description 'VCCV Type Error') in the Label Distribution Protocol (LDP) Parameters Status Code Name Space registry.
This document does not introduce new security considerations beyond those in RFC 5085 and RFC 6073. Additionally, the procedure specified in this document eliminates the possibility of packet leaking that can occur with VCCV Type 3 (TTL-based identification).
The Type 4 VCCV packet encapsulation consists of a PW LSE, followed by a GAL LSE, followed by a Generic Associated Channel Header (4 bytes: 0x1 nibble, Version, Reserved, Channel Type), followed by the VCCV Message Body. The structure is identical whether or not FAT is in use.