[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
Hi Juergen,
1) thank you for your thorough explanation
2) however the question is how we can stretch your FCS/BIP processing
model to cover
the PW case: should the PW be considered as an "Ethernet network link" that
has
to be protected by FCS or as a "packet service" ? IMHO the PW is closer to
the "link"...
Regards,
Akiva Sadovski
-----Original Message-----
From: Heiles Juergen
To: Heiles Juergen; 'Scott Kotrla'; mick_seaman@ieee.org;
stds-802-1@ieee.org
Cc: pwe3@ietf.org
Sent: 20/11/2003 12:22
Subject: AW: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
I had some further thoughts on the FCS issue and noted a major
difference between FCS processing in circuit an packet switched
networks.
In a circuit switched network like SONET/SDH the FCS is bound to the
trail while in a packet switched network like Ethernet it is bound to
the link.
In a circuit switched network a client frame is not dropped in case of
bit errors detected by the server layer or link. It is still forwarded
downstream and its payload can still be useful. In a packet network a
frame is dropped in case of a server layer/link FCS error. One reason
for this is in my view that packet networks have the forwarding
information (address, label) as part of the frame itself. In case of a
FCS error this information might be corrupted and correct forwarding is
not guaranteed. In a circuit switched network the forwarding information
is the timeslot which is a implicit information which can not be
corrupted by bit errors (except for the case of excessive bit errors
that result in loss of frame synchronization in which case the frame is
also dropped = all-ONEs/AIS insertion). In addition circuit switched
networks use in-frame multiplexing which means that frames from several
clients are multiplexed into a single server layer frame. A server layer
FCS err!
or may only effect some, but not all of the client layer frames. Packet
networks have often a one-to-one frame mapping between client and server
layers or a 1 to n mapping where a client frame is split over several
server frames. So server frame FCS errors are directly related to client
frame FCS error.
Circuit switched networks use a FCS often at all layers (SONET/SDH, OTN)
while packet networks use it often only at a single layer, the link
layer.
In SDH the VC-4 BIP-8 is generated at the termination source and checked
at the termination sink. The check at the termination sink provides the
information about the error performance of the VC-4 trail. In addition
we have BIPs at the multiplex section and regenerator section layer.
These are mainly for error localization and protection switching trigger
at these layers.
In an Ethernet network the frame is dropped in case the link detects an
error. One cannot get the error performance of the connection by just
checking the FCS at the termination (end station, or egress UNI) as only
good frames are passed to it and only information about the dropped
frames of the last link are available. For the error performance the
number of dropped frames of each link has to be added or one makes a
comparison between the number of ingress and egress frames. The
difference gives the number of dropped frames = error performance. This
can be used for point-to-point connections (line), but gets difficult
for multi-point-to-multi-point connections (LAN).
The different behavior means also that a end-to-end FCS is not required
for a packet service, what is required is a full coverage of error
checks which for example could consists of link FCS and internal error
supervision of the network elements. If any of the two detects errors
the frame is dropped. This leads to the same frame dropped as an
end-to-end FCS. This approach however is problematic as it is difficult
to standardize internal error supervision of network elements and very
difficult for operators to test the internal supervision. SO they have
problems to trust this functionality. A end-to-end FCS is easier to
handle.
Regards
Juergen
> -----Ursprungliche Nachricht-----
> Von: Heiles Juergen [mailto:juergen.heiles@siemens.com]
> Gesendet: Mittwoch, 19. November 2003 11:51
> An: 'Scott Kotrla'; mick_seaman@ieee.org; stds-802-1@ieee.org
> Cc: pwe3@ietf.org
> Betreff: 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
>
_______________________________________________
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