Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention

From: "Mick Seaman" <[email-masked]>
Date: Tue, 18 Nov 2003 14:12:00 -0800

Let's be clear here. I believe Norm is saying that the service provided to a
bridge by whatever media needs to provide the same integrity as is provided
by Ethernet today. This may be accomplished by a CRC-32/integrity check with
Hamming distance of 5/whatever is needed to cover the particular faults of
the media. In this sense bridges may need a CRC option on some PW. This is
not a CRC transported through the bridge, and whatever the media in question
is or locally appears to the bridge to be, if it requires a CRC additional
to the Ethernet CRC it is *not* Ethernet but a *new MAC type*.

This is true even if the new MAC is partially constructed out of
802.3/Ethernet technology, and is documented in the 802.1 July 2003 minutes
(documenting discussion with the 802.3 leadership), and in the liaison to
the ITU agreed at last week's 802.1 meeting. Any packet buffering/relay
function required 'inside' such a new media is not an 802.1 bridge.

For an 802.1 Bridge to use new media/MAC it requires a mapping of the
procedures etc. provided by the media to the Internal Sublayer Service (ISS)
used by the bridge. See 802.1D Clause 6.5 for mappings for 802.3, 802.5,
FDDI, and 802.11. These mappings are developed in close cooperation with the
group responsible for the MAC, and are usually written by that group, so it
is not in 802.1's gift to arbitrarily add to any existing mapping. There is
no restriction on such mappings being exclusively developed by IEEE 802, the
FDDI mapping was developed with the ANSI committee responsible for FDDI
(I've forgotten its name).

I am currently confused by the different answers I am getting on the CRC
question that Scott is posing. In discussion at the meeting Scott told me
that the proposed PW was using a perfectly adequate CRC, but hinted at some
other source of faults (badly implemented bridge? thing that looks like a
bridge to those not familiar with the bridging standards and what they
require?).

Mick

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Scott Kotrla
Sent: Tuesday, November 18, 2003 12:22 PM
To: 'Norman Finn'
Cc: [email-masked]; [email-masked]; 'mark seery'
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Norman,

What media are bridges going to be running PW over that does not have a
CRC?  Are you talking about a CRC of the PW payload or a CRC of the PW
packet including both payload and header?

Thanks,

Scott

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of mark seery
Sent: Tuesday, November 18, 2003 10:16 AM
To: Norman Finn
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Hi Norman,

This is a good formulation of the problem.

thanks,
mark

---- Norman Finn <[email-masked]> wrote:
> Mark,
>
> You say below,
>
>  > but a PW will be running over a physical media itself already,
possibly
>  > even SONET.............
>
> Exactly!  Here, the trail gets a bit murky.  If I'm in total control,
and the PW
> is running over known Ethernet links, then I can get away without the
CRC in the
> PW.  I have no problem whatsoever with the current definition of PWs
without CRC.
>
> But, if I don't have tight control over the physical media over which
the PW runs,
> then I really need a CRC on the PW for the bridge to be able to trust
the "wire"
> and thus provide the same level of data integrity that bridges offer
over physical
> Ethernets.  So, I claim that bridges need a CRC option on PWs.
>
> -- Norm

---

From: Norman Finn <[email-masked]>
Date: Fri, 21 Nov 2003 12:28:43 +0100

Scott,

Over what media can routers run?  Wet string?  There are media in use
that have, in effect, only a 16-bit checksum.

If the endpoints of the PW have knowledge of the underlying media on which
the PW runs, and if those media have satisfactory data integrity protection,
and if the methods of encapsulation and decapsulation have a suitable
mathematical and/or implementation basis to suppose that they won't introduce
significant errors, then you're done.

On the other hand, one of the purposes of layering is precisely to insulate
the upper layers from knowledge of the lower.  If the ends of the PW do not
know that the data is as safe as an Ethernet frame, then the Ether-over-
whatever (i.e. PW) application needs its own checksum over its own data.  This
checksum certainly covers every bit of the Ethernet frame payload.  If the
checksum chosen is a polynomial CRC, presumably the IEEE 802 one, then it has
the property of being extendable to cover some PW header information without
compromise, just as it is used to cover added 802.1Q tags.  I'm not expert
enough on the various PW techniques to tell you for sure whether that's needed
or not, but I doubt that it's necessary.

-- Norm