[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
Scott,
the pseudo wire and stacked VLAN case are different in my view.
Lets start with the Ethernet pseudo wire case:
The client is the Ethernet MAC signal. This could be a untagged frame, a .1Q tagged frame, a .1ad provider tagged frame or even a proprietary .1Q in .1Q tagged frame. The pseudo wire should not care about it. It is mapped into MPLS or IP using the pwe3 mapping. If the pseudo wire is a layer of its own or only a mapping is not relevant for this discussion. So we have the following basic network layering:
Ethernet MAC ETH client
| |
MPLS LSP server client
| |
xyz server
MPLS is a server layer for ETH and MPLS itself is again supported by server layers. MPLS switching, supervision and OAM is independent of the ETH client layer. MPLS can not touch or modify the MAC frame. It is a real tunnel case.
With the original pwe3 definitions the MAC FCS would be stripped when the frame was mapped and a end-to-end FCS check of the ETH link over the pseudo wire was not possible. With the optional inclusion of the FCS it is possible. This is the issue Norm is talking about I think. The ETH link over a pseudo wire should provide the same functionality as over a physical Ethernet or as for example over SONET/SDH (using GFP or LAPS).
Note that even with the inclusion of the FCS it doesn't always mean that this is the original customer FCS. This is only the case when the Ethernet UNI is directly forwarded to the pseudo wire without any Ethernet bridging in between. In case of a multiplexed access link (service services on the access link separated by VLAN tags) or in the VPLS case (MAC switching) a Ethernet bridge function is located between the UNI and the pseudo wire which does the normal Ethernet FCS processing.
Stacked VLAN:
With the stacked VLAN we do not introduce new layer. The VLAN provides a method to fragment/part ion an ETH network in several smaller ETH networks (see ITU G.8010 Ethernet Network Architecture which is in the approval process). Connectivity is only possible within the specific VLAN. Forwarding decisions are still based on the MAC addresses. Switching, supervision and OAM is/will be based on the MAC frame and the MAC frame can/will be modified including the FCS. So it is not a real tunnel.
Even in this case preserving the customer FCS is useful when errored customer frames would be forwarded through the network and not dropped at the ingress. This is for example the case in SONET/SDH Tandem Connection Monitoring as we do not drop frames with wrong FCS in circuit switched networks.
As stated in my earlier mail Ethernet drops frames with wrong FCS. So we have only customer frames with correct FCS forwarded at the ingress UNI. If the normal MAC FCS is not recalculated at each bridge but instead is modified according to the changes to the frame it provides the UNI-to-UNI coverage for the customer frames Scott is looking for without the need to tunnel the customer FCS.
Regards
Juergen
> -----Ursprungliche Nachricht-----
> Von: Scott Kotrla [mailto:scott.kotrla@mci.com]
> Gesendet: Mittwoch, 19. November 2003 00:09
> 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
>
>
> Let me attempt to clarify why I brought up Pseudowires in the first
> place.
>
> Pseudowire/Ethernet transport of Ethernet services(protocol stack is
> Customer Tagged Ethernet/Pseudowire/Carrier Untagged
> Ethernet, note the
> Carrier Ethernet could be GFP, HDLC, X.86, etc.) looks a lot like
> Stacked VLAN transport of Ethernet services (protocol stack
> is Customer
> Tagged Ethernet/Carrier VLAN). In the Pseudowire model, the customer
> FCS (originally tossed in the PWE3 specs but now optionally
> maintained)
> is an end-to-end Path FCS, while the carrier FCS (always present for
> Ethernet over Dark Fiber implementations as part of the underlying L2
> transport of the L2.5 PW frame) is a Link/Line FCS. In the
> stacked VLAN
> transport, the customer FCS is tossed/overwritten, just like it was in
> the PWE3 spec originally. The newly calculated FCS is a
> Link/Line FCS.
>
>
> Keeping the customer FCS in PWE3 (when there is already an underlying
> Link/Line FCS) is exactly the same as keeping the customer FCS in a
> Stacked VLAN model and appending a new Link/Line FCS (instead of
> overwriting the customer's FCS). If we can get consensus on
> this, then
> we should also be able to get consensus that the same functionality
> should optionally be available in either architecture. This consensus
> has already been reached in PWE3, and my goal is to reach the same
> consensus in 802.1.
>
> As Norm stated, router guys take the underlying error correcting
> capabilities that bridges provide for granted, so it should take less
> work to convince bridge guys (who understand the importance of error
> detection) than it did to convince router guys, which by the way was a
> very long and grueling process.
>
> I plan to put some drawing together showing the protocol stack
> similarities as well as the functions required at each point in each
> switch for these various scenarios when time permits.
>
> Hope this textual explanation provides some clarification.
>
> Thanks,
>
> Scott
>
> -----Original Message-----
> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On
> Behalf Of Mick
> Seaman
> Sent: Tuesday, November 18, 2003 4: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
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3