[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AW: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Neil I have to correct you here.

In the ITU Ethernet Network Architecture (G.8010 which is currently out for approval) the FCS is not part of the CI. It is a link property. This is the difference in FCS for circuit and packet switched networks I mentioned in my previous email.

G.8010 refers however to the undetected errors of a bridge. This doesn't mean that a bridge should be error free. An error introduced by a bridge which is detected by the FCS is ok. For a bridge as a single network element designed by a single manufacturer such a requirement on undetected errors seems to be achievable. For a pseudo wire which is a link connection through a network  which consists of network elements and connections between them such a requirement is very difficult to achieve.

Regards

Juergen




> -----Ursprüngliche Nachricht-----
> Von: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Gesendet: Sonntag, 23. November 2003 10:20
> An: kgk@igs.net; jmessenger@advaoptical.com; nfinn@cisco.com
> Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org;
> Maarten.Vissers@alcatel.de; alan.mcguire@bt.com
> Betreff: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
> 
> 
> Keith,
> 
> Maarten....you may want to note this mail given you are 
> defining the functional models for ethernet.  I'd be grateful 
> if you would please check the accuracy of my remarks below.  
> Ditto Alan for MPLS.  Thanks, Neil
> 
> Keith Knightson wrote 22 November 2003 17:44
> 
> > Well, this is what 802.1D has to say on the subject:
> > 
> > "...for frames relayed between LANS of the same MAC type, 
> the bridge 
> > shall not introduce an undetected frame error rate greater 
> than that 
> > which would be achieved by *preserving* the FCS.
> > 
> > I take this to mean that there is no requirement to preserve the 
> > (originally received) FCS, even on a pure native LAN system with 
> > bridges. Quite the contrary, Bridges are expected to not introduce 
> > errors.
> > 
> > If you assume a PW to be a sort of bridge,
> NH=> A PW is for sure not a bridge!  A PW is an adaptation 
> funtion that lies between a client layer network and a server 
> layer network of MPLS or IP.  A PW is *not* a layer network 
> itself since PWs are not 'networked'.  CF GPF which has a 
> similar role in adapting an ethernet client layer network to 
> an SDH VC4 layer network.  Now whether a PW adaptation 
> function is required or is properly constructed is a 
> different question, and some things are not right here 
> IMO....but this is not relevant to this topic.  A bridge is a 
> node in the ethernet layer network.....and from the 
> perspective of recursive partitioning of the ethernet layer 
> network, it is the smallest flow domain subnetwork.  I 
> believe that if you were more au fait with G.805 and G.809 
> func arch concepts then this would help you see these things 
> more clearly.
> 
> > this is certainly the case 
> > for a VPLS with multiple PWs, then a PW is no worse with or 
> without a 
> > preserved FCS, if and only if, the undetected frame error 
> rate is no 
> > greater than that which would be achieved by *preserving* the FCS.
> > 
> > Why would one expect a PW to be better than a bridge?  (Since a 
> > remote bridge would have been would been the alternative anyway!)
> NH=> This is not a valid comparison, ie apples with oranges.
> > 
> > I do not think that client/server has anything to do with this 
> > argument.
> NH=> On the contrary it has everything to do with the issue 
> at question.  But I can see that you are having problems with this.
> 
> > In any case it is clear the client is the frame without its 
> > FCS.
> NH=> This is not correct.  The FCS is an intrinsic component 
> of the ethernet CI (characteristic information).....you
> simply cannot go around arbitrarily changing/removing it.    
> 
> > If anything, I would submit that the client is the LLC layer, ie 
> > the MAC Service User, and not the MAC Sublayer,  i.e.  the frames, 
> > yes,  but not the mechanisms associated with the actual 
> transmission 
> > of the frames.
> NH=> I can see your confusion given the way the LLC and MAC 
> sublayers were orginally specified (for example, see Radia 
> Perlman's book 'Interconnections' section 2.7).
> > 
> > Otherwise, one could carry the argument to absurdum. For example, 
> > why not include the flags or manchester encodings or whatever else 
> > defines the frame?
> NH=> This is wrong...and if you understood G.805/809 you 
> would immediately know why.  Specific line codings belong to 
> the section media level.  They occur *below* a given link 
> connection on the *lowest* layer network.  Line codings are 
> *not* networked entities.  For example, consider a VC4 layer 
> network.  The SDH STM-N nodes can be connected together (so 
> these would be link connections in the VC4 layer network) 
> using radio, electrical or optical media sections.  The line 
> codes used on each section are different, however the VC4 
> entity is consistent across all of them.  Note that a VC4 
> traffic unit carries a BIP check of degree 8 (x^8 +1), which 
> is its FCS if you like....and these do not get 
> changed/removed in some ad hoc fashion by the section layers.
> 
> >  In a bridge the relaying is taking place at the 
> > frame level, not the MAC level. For example one can different MAC 
> > sublayers on each side of a bridge, forcing a recalculation of the 
> > FCS.
> NH=> I assume you mean 802.3 and 802.5 interworking for 
> example?  If you looked at what is happening here from a func 
> arch perspective, you would note that we have to terminate 
> the MAC trails either side.  Why?  Because the CI is 
> different on each side, eg the bit ordering of DA/SA fields 
> is different.  So it is a requirement to have different FCSs.
> > 
> > MHO.
> > 
> > Regards
> > 
> > Keith
> > 
> >   8:31 PM +0100 21/11/03, John Messenger wrote:
> > >Neil Harrison said:
> > >>   IMO the ethernet FCS is part of the ethernet's CI and 
> > should not be
> > >>   removed by *any* server layer technology.
> > >
> > >Absolutely.  Amen to that.
> > >	-- John
> > >--
> > >John Messenger (JMessenger@advaoptical.com)
> > >R&D Manager, Software
> > >ADVA Optical Networking Ltd.
> > >+44-1904-699309
> > >www.advaoptical.com
> > >
> > >_______________________________________________
> > >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