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