[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
Pat,
we are talking about Ethernet services which are for example transported over IP. In this case the Ethernet MAC frame is a payload of the IP frame. This IP frame may again be transported over Ethernet so we have the following stack:
Ethernet MAC service
|
IP
|
Ethernet MAC transport
Any changes to the IP header or the transport MAC header have no influence on the Ethernet MAC service frame and its FCS.
Regards
Juergen
> -----Ursprüngliche Nachricht-----
> Von: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
> Gesendet: Mittwoch, 19. November 2003 00:39
> An: mick_seaman@ieee.org; stds-802-1@ieee.org
> Cc: pwe3@ietf.org
> Betreff: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
>
>
>
> I am also confused about the same point. Some people such as
> Norm seem to be concerned about a CRC over the media and some
> seem to be concerned about an end to end CRC to protect
> against errors during CRC regeneration in bridges.
>
> Of course as long as all the media are using the same CRC
> polynomial, the bridges could adjust the original CRC for any
> packet changes rather than regenerate. Personally, I think
> 802.1 Appendix G makes this look more complicated than it is.
>
> Attempting an end-to-end MAC layer CRC isn't worthwhile. As
> soon as one goes through a higher layer device such as a
> router, it will get tossed and regenerated anyway (unless
> they do CRC adjustment for IP and MAC header changes which
> seems unlikely). If real end-to-end protection against
> corruption is desired, then the place to do it is in
> transport or above.
>
> Pat
>
> P.S. the CRC-32 provides Hamming distance of 4 - it detects
> all 3 bit errors up to something larger than 8 K.
>
> -----Original Message-----
> From: Mick Seaman [mailto:mick_seaman@ieee.org]
> Sent: Tuesday, November 18, 2003 2:12 PM
> To: stds-802-1@ieee.org
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
>
>
>
>
> 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: owner-stds-802-1@majordomo.ieee.org
> [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla
> Sent: Tuesday, November 18, 2003 12:22 PM
> To: 'Norman Finn'
> Cc: stds-802-1@ieee.org; pwe3@ietf.org; '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: owner-stds-802-1@majordomo.ieee.org
> [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of mark seery
> Sent: Tuesday, November 18, 2003 10:16 AM
> To: Norman Finn
> Cc: stds-802-1@ieee.org; pwe3@ietf.org
> 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 <nfinn@cisco.com> 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
>
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3