The PW Associated Channel

In the beginning of the development of pseudowire technology, it was obvious to many of us that PWs would require some sort of OAM support. As always with OAM the question was how to make OAM packets fate-share with user data packets. The original RAD proposition was to define a special "OAM PW" that would be placed alongside the monitored PWs. In the MPLS case this meant a special PW label for OAM (RAD's proposal was to use the "all-ones" label), but to ensure that this OAM PW was placed in the same MPLS tunnel. This proposal still exists in Appendix D of RFC 5087.

The alternative proposal ("VCCV") placed special OAM packets in every PW. This meant much more OAM traffic for the prevalent case of many PWs in a single PSN tunnel, but simplified the assurance of fate-sharing. In order to enable interworking with other vendors, RAD abandoned its own proposal and adopted the VCCV approach, including advocating conformance with the newly standardized PWE3 control word and upgrading its equipment base accordingly.

Digression: VCCV stands for Virtual Channel Connectivity Verification, and is a complete misnomer. VC was an old (ATM-style) name for what is now called a PW. It was used in the early days of the PWE3 WG before the introduction of the term pseudowire, and should have been completely replaced. CV is a well-defined OAM term for detection of misconnections, that is, detecting that a packet arrives at the wrong destination. It should never be confused with Continuity Check (CC), which means checking that packets sent are actually received. Of course that is precisely the meaning in the term VCCV. Unfortunately by the time of the RFC it was too late to rename this function PWCC.

Three mechanisms were proposed for distinguishing between VCCV packets and user data packets, and all three became part of the standard. In the language of RFC 5085, there are three Control Channel types.

• CC TYPE 1 When the PWE3 control word (CW) is used, the first nibble is set to 0001, instead of 0000.



• CC TYPE 2 Router Alert Label (AKA out-of-band VCCV) - placing the reserved MPLS RA label above the PW label.



• CC TYPE 3 TTL expiry - i.e., ensuring that the TTL in the PW label equals 1 at the PW endpoint.

Having three options sounds a bit confusing, but there were good reasons for all three. First, not all PWs use the CW; in fact, in some cases it would be wasteful to add 4 bytes to a small payload. Second, it has been argued that types 2 and 3 must be supported, as they are integral parts of the MPLS architecture. If a PW gateway receives a packet with the RA label, or with an expired TTL, it can not be expected to process it as a regular user packet!

It was realized early on that the CC types defined a PW associated channel could be used for functions other than VCCV, and that realization is captured in RFC 4385. However, this channel is limited to PWs, and could not be used for adding OAM functionality to non-PW MPLS traffic. So when the MPLS-TP effort required such functionality, the idea of an associated channel was generalized to a Generic Associated Channel (GACh) in RFC 5586. The generalization is obtained by defining what is essentially a fourth CC type - the GACh Label (GAL). This reserved MPLS label, unlike CC TYPE 2, sits at the bottom of the stack (there being no PW label), and is followed by what is essentially the PWE control word.

Those involved in the MPLS-TP effort want MPLS-TP mechanisms to work for PWs as well. This has led to a proposal to enable the use of the GAL for PW packets as well as for MPLS packets. For the PW case the idea is to put the GAL under the PW label. This proposal breaks an underlying characteristic of all PWs (explicitly stated in numerous RFCs), namely that the PW label sits at the bottom of the stack.

In my opinion three methods of indicating an associated channel packet is quite enough, and we don't need a fourth method. Yet, another proposal goes even further. This proposal suggests eliminating CC types 2 and 2, and leaving only type 1 (using the CW) and the new GAL approach. Were this proposed ten years ago I would probably have been in favor, although it is still not clear to me what a receiving PW gateway does when it receives a type 2 or type 3 packet. (Losing type 3 also excludes traceroute mechanisms.) However, at the present time this proposal would require upgrading ten years of live PW deployments, and I can not see how it can be implemented.

Y(J)S