[PWE3] 802.1 specification of a bridge - FCS being an example

["Mick Seaman" <mick_seaman@ieee.org>]

For anyone new to the style of, and self-imposed limits upon, 802.1
specifications, the following may be useful (and not just as it applies to
the FCS discussion - see email extract below (which by the way I think is an
entirely sensible question).

802.1 contains a fairly detailed model of a bridge, necessary to express its
observed external behavior. However it contains (in clause 7.3) the
following text:

"The model of operation is simply a basis for describing the functionality
of the MAC Bridge. It is in no way intended to constrain real
implementations of a MAC Bridge; these may adopt any internal model of
operation compatible with the externally visible behavior that this standard
specifies. Conformance of equipment to this standard is purely in respect of
observable protocol."

This principle - that a specification only describes external behavior and
not how a particular item of equipment is built - was a very strongly held
belief amongst the members of the committee at the time 802.1D was first
developed, and I would note that some of them are still round the committee,
most are still around the industry, and many are IEEE SA members fully
entitled to vote on sponsor ballots. I would therefore rate the chance of
successfully amending this clause (or the similar one in 802.1Q) whether
directly or by stealth (by mandating implementation internals elsewhere in
the spec) in any future 802.1 amendment or revision as negligible.

[It took me (personally) a very considerable effort to get the treatment of
FCS as far as it is. Considerable opposition came from those who were using
MAC chips that could not take the FCS as a transmission parameter and there
was much argument as to the plausibility of conformance verification by
testing, but it was established that the requirement could be verified. We
didn't at the time go as far as I would have liked, but I accepted the
limits of the outcome, and in common with some other arguments which I have
somewhat lost, I do feel honor bound to respect and use my energies to
preserve this outcome (not least because if all outcomes are up for grabs
all the time the spec would flap around like a fish, which is bad for all
outcomes not just ones I would personally like to tweak).]

The consequence of the "may adopt any internal model of operation compatible
with the externally visible behavior" might not be readily apparent to all
in the context of this FCS discussion, so let me spell it out.

It means that if the chance/frequency of undetected errors being introduced
in frame stored within a particular bridge implementation is no more likely
than such errors arising in the transmission medium, that any spec to carry
the received FCS through the bridge and append an additional FCS to the
transmitted frame could be validly achieved on transmission by calculating
both those FCSes at transmission time, i.e. calculating both the "original"
and the "new complete frame".

Given that 802.1ad allows a number of different interfaces to a provider
bridge network for any service instance (for example a provider router might
service multiplex by "customer VLAN" a number of service instances that are
to be delivered at individual ports to specific customers without the
tagging) there is some doubt as to what the "original frame" comprises when
it is final delivered. The obvious way out of that bind would be to decide
on some definition of the "essential frame" for the inner FCS, whether that
is the frame once the provider stuff has been removed at any point in the
net or not. This becomes easier if you spec the "inner" FCS over some
specific data fields and calculate both "inner" and "outer" at transmission
time on or near the final hop to the customer. Of course you could always
try to tell the originating interface what the final form of the frame was
going to be :-) so the input interface could calculate the right one (if the
destination doesn't move).  The two FCSes look pretty much in specification
terms like a new MAC to the bridge. It is not so trivial to cover services
that are not just point to point wires with new "end to end" requirements.
Given that, it is sure tempting just to fix the newly invented substandard
parts of the network. Then the frame errors can be localized because the
frame will get dropped by the bridge receiving from the new inferior media.

To answer the question in the attached email as best I can.

As per the above, the .1ad spec cannot mandate where in the implementation
values are calculated. Obviously frames with bad FCS on receipt are
discarded, and the chance of incorrectly changed data being sent with a
valid FCS should be verifiably low (given enough test systems and time).

Early bridges spanned the range of permissiveness and paranoia. Some bridges
used chips which would not accept the FCS on transmission, and had average
cheap memories. The early DEC Ethernet-FDDI bridges were very cautious and
paranoid. While not calculating FCS differences as per Annex G, they
overlapped FCS coverage as the frames passed through the format conversion
chips i.e. the FCS received (call it FCS-R) was recalculated over the fields
that should contribute to FCS-R after the frame modifications were made and
the FCS to be used for transmission (call it FCS-T) has been calculated and
associated with the frame. The circuit design takes some care and
verification, but the method can be very good.

Nowadays I believe most bridges from reputable suppliers use memories whose
characteristics are such that the frame data is just as likely  to have been
corrupted in the originating end-stations transmission queue before the very
first FCS  has been added or the receiving destinations receive queue after
the FCS has been verified for the very last time.

Mick

-----Original Message-----

Extract from a message sent by Heiles Juergen

.......

802.1q says the following:
NOTE-There are two possibilities for recreating a valid FCS. The first is to
generate a new FCS by algorithmically
modifying the received FCS, based on knowledge of the FCS algorithm and the
transformations that the frame has
undergone between reception and transmission. The second is to rely on the
normal MAC procedures to recalculate the
FCS for the outgoing frame. The former approach may be preferable in terms
of its ability to protect against increased
levels of undetected frame errors. ISO/IEC 15802-3, Annex G, discusses these
possibilities in more detail. The
frame_check_sequence parameter of the Enhanced Internal Sublayer Service
(7.1) is able to signal the validity, or otherwise,
of the FCS; an unspecified value in this parameter in a data request
indicates to the transmitting MAC that the
received FCS is no longer valid, and the FCS must therefore be recalculated.

For a end-to-end supervision the first approach has to be used. It means
that for the outgoing FCS the incoming FCS is used and it is modified
according to the frame modifications. This means that errors that occur
within the bridge are covered and will be detected. 802.1d Annex G provides
examples on how this can be achieved.

One question to the Ethernet community: What is the usual FCS procedure for
.1q bridges modification or new calculation? What would it be for .1ad
bridges?







_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3