[rbridge] Trivial question about FCS in Figure 3 of currentprotocol draft

[Eastlake III Donald-LDE008]

I agree it is not as simple as I made out.

Another strategy is to keep the FCS on admitting a frame and whenever
you delete, insert, or change anything in the frame during processing to
do a compensating adjustment to the FCS, then transmit this modified FCS
with the frame. This alternative to generating it from scratch when the
frame leaves the bridge/Rbridge would have a reasonable chance of
detecting something like memory corruption within the device.

But I don't think we should say anything about which strategy Rbridge
implementations use other than requiring them to send frames with
correct FCS values and discard received frames with bad FCS values. 

Thanks,
Donald

-----Original Message-----
From: James Carlson [mailto:james.d.carlson at Sun.COM] 
Sent: Monday, October 22, 2007 12:10 PM
To: Eastlake III Donald-LDE008
Cc: Radia Perlman; Developing a hybrid router/bridge.
Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of
currentprotocol draft

Eastlake III Donald-LDE008 writes:
> The FCS is commonly something that's buried in the port hardware and
> gets generated at the time of or just before frame transmission and
> checked at the time of or just after receipt and sometimes doesn't
exist
> in the interior of a bridge/Rbridge.
> 
> Since Figures 3 and 7 say they are a frame as it appears on the wire,
> which is what IETF protocol descriptions are normally interested in,
one
> and only one FCS should be shown.

I'm not sure that the question or the answer are 'trivial' here.

In a regular (non-VLAN) bridge, the FCS is normally preserved
end-to-end, so that it protects the frame in transit from molestation
by intermediate bridges.  This is why RFC 3518 (PPP Bridging) contains
a LAN Frame Checksum Preservation feature.

With VLANs, this is no longer true, and corruption introduced by an
intermediate malfunctioning bridge was in fact the cause of a
significant network outage at Sun several years ago -- so I think it's
not a trivial matter to commit to non-preservation of FCS.

All that said, I agree with the current plan: there's a single
medium-dependent FCS, checked and regenerated at hop, and thus no
protection of the frame contents while resident in system memory of
one of the intermediate bridges.  Adding an option (sigh!) for
end-to-end preservation would be nice, but may well be fighting an
uphill battle in terms of functionality and compexity.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677