Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [RPRWG] CRC check in each node?




Robin, All,

I have no issue with people not deleting the packet on finding
an FCS error. It is a trivial optimization if store and forward
is the transit path design. I do not believe it should be 
a requirement, nor has it every been pushed as one (i.e. not a 
sneaky way to force store and forward into the standard). 

What my last email tried to show, was that there is no concept today
of forwarding a packet in an 802 network for the purpose of 
statistics as had been suggested. Therefore there is nothing in 
802 standards that forces a bad packet to continue to be forwarded.

What carrier's absolutely want to do is determine if links are going 
bad. So the advantage of deleting the packets is an easy method to 
insure that the CRC error is not counted all the way around the
ring. For cut-through nodes, there has to be some method of not
counting the CRC error at subsequent nodes.

I do not believe that customers or carriers actually want to
get per flow error statistics. I have never heard such a requirement
from a customer of mine. That being said, there are simpler ways to do it
that work better and that line up with the sorts of statistics that customer have
asked me to put in our products. 

I believe that each node can easily count (should people choose
to put in the HW): 
how many packets it has sent to each destination
how many packets have arrived from each source

This can be done outside of the MAC (or inside if 
you have a handle on the number of nodes per ring/network)
and software can co-ordinate the collection of data. This method's
complexity grows as N rather than N^2. Even if an address crc is 
available, this method is required because there are some additional 
errors to consider I.E. there are at least 3 components of loss
and possibly more. 

1) packets lost due to payload crc error
2) packets lost due to "address" crc error (assuming it exists)
3) packets lost due to queueing limitations at intermediate 
switches/ bridges. 

Therefore, it is a waste of time, energy and silicon to put a 
separate address error check if customer's want to know how
many packets are lost from an end to end perspective. This is 
the sort of thing that allows people to differentiate based on
their customer requirements.

I fully support the idea that TTL and some other fields should be
outside of the main packet in an RPR header and it should be protected
in some way. We will go into some of the reasons in Portland as 
part of a presentation.

mike