Subject: RE: pwe3-ethernet-encap - FCS...

From: "Christopher N. \"Nick\" DelRegno" <[email-masked]>
Date: Thu, 17 Apr 2003 11:53:02 -0500

Beware, can of worms opening…
 
>From the original “Martini” draft to today, the customer FCS data has
been discarded.  Initially, my interest was in the “tagged” mode more
than the “port” or “raw” mode of encapsulation.  I noted that the FCS
was discarded in order to save 4 bytes as well as the fact that many
deployed implementations discard the FCS today.  Until recently, we were
okay with this since each link has some error checking mechanism in
place.
 
In testing a very widely deployed Ethernet switch, we encountered an
anomaly which, if the FCS is discarded, would be a nightmare to
troubleshoot in a live network.  Briefly, while we weren’t seeing any
packet loss across an Ethernet network and every packet was being
received by the destination host, all higher-layer frames were being
dropped by the host.  After spending an inordinate amount of time using
traditional Ethernet performance metrics to attempt to isolate the
problem, not until we intrusively placed Ethernet test equipment on both
ends did we discover that while the Ethernet FCS of every delivered
packet was good, the customer data was corrupt.
 
Apparently one of the Ethernet switches in the network was internally
corrupting the data between the discarding of the customer FCS and the
calculation of a new FCS.  Mind you, there were no VLAN tag swaps or
stacks or the like.  This was a simple bridged connection, where the
Ethernet packet in theory shouldn’t change, that was consistently
corrupting the data.
 
Now, had the FCS been maintained throughout the data path, the
customer’s network-facing Ethernet switch would have dropped every
corrupted packet due to the FCS error.
 
In the pwe3-ethernet-encap draft as it stands, there is no provision for
keeping the received FCS.  In tagged mode, this is more understandable
since I very well may change the VLAN ID at the far end of the network. 
However, in the Ethernet mode, where I am sending ALL of the customer’s
frames, without looking at the VLAN ID, I need the ability to maintain
the customer’s FCS as well.
 
I realize that A) this is not how the draft is written, B) that if the
FCS is optional, then pwe3-control-protocol will have to be updated as
well to signal the presence or lack of the FCS (possibly via the
Interface Parameters field) and C) that many popular techniques to stack
tags don’t retain the customer FCS.  However, the cost of the additional
4 bytes per packet and extra signaling information is worth it.  When
providing Ethernet private line type services, we have to rely on the
Layer 2 information to determine the performance of the network.
 Maintaining the customer’s FCS, resulting in a “Path FCS”, gives the SP
an end-to-end error check.
 
In the truest sense of the term pseudo-wire, we are using a PSN to
emulate an Ethernet-cable.  It would be unacceptable if an Ethernet
cable somehow corrupted the payload of the MAC frames without the FCS
being able to detect it.  It is just as unacceptable if that Ethernet
cable is composed of packet switched networks instead of twisted pairs.
 
Admittedly, if such internal errors occur in network devices, having a
“Path FCS” will not tell me which switch is errant.  However, it will
tell me a problem exists, hopefully prior to my customer’s contacting
me.  
 
Regards,
Nick DelRegno