Re: [RPRWG] CRC check in each node?
Bob,
My apologies if I was not being clear.
I was talking about forwarding through a bridge.
It had been suggested that one would forward packets with
good address CRC but bad Payload CRC through a
bridge to get end to end error statistics. As I pointed
out, if people are really serious about end to end
statistics there are other issues at play and IMHO
this should be outside of the scope of the
MAC.
I agreed that one could clearly indicate that a
CRC check has failed at an intermediate node on the
ring and signal it to the next node(s). I regret that
I did not known the token ring method for same and
referred instead to ideas other people floated
on the reflector.
mike
RDLove wrote:
>
> Mike, I seem to be missing where you are coming from when you say that there
> is no concept today of forwarding a packet in an 802 network for the purpose
> of statistics. In 802.5, there is exactly this concept. Token Ring has a
> single byte ending delimiter which is generated as jk1jk10e where j and k
> are special non-0 or 1 characters", and the final bit E is the error bit,
> always transmitted as a zero by the station inserting the frame onto the
> ring. If a station receives a frame that is in error, it unconditionally
> sets the e bit to a one as it transmits it. However, that station reads
> that bit before it sets it. If it was already a one, it takes no action.
> If it was a zero, then information is stored in the station. The
> information is that the error was created within the domain that starts with
> the immediate upstream station, and ends with that station. After a certain
> threshold of those types of errors are stored, the station sends a message
> that can be received by any station recording the rings statistics, stating
> the MAC addresses of the upstream and downstream stations that define the
> domain of where the errors are being created. Note that in Token ring,
> packets with a bad CRC continue to circulate until the transmitting station
> strips them from the ring.
>
> Mike, I'm not suggesting that 802.17 should or should not have similar
> capabilities, but the concept is both fully fleshed out and implemented in
> the MAC of 802 rings today.
>
> Best regards,
>
> Robert D. Love
> Chair, Resilient Packet Ring Alliance
> President, LAN Connect Consultants
> 7105 Leveret Circle Raleigh, NC 27615
> Phone: 919 848-6773 Mobile: 919 810-7816
> email: rdlove@xxxxxxxx Fax: 208 978-1187
> ----- Original Message -----
> From: "Mike Takefman" <tak@xxxxxxxxx>
> To: "ieee 802.17 list" <stds-802-17@xxxxxxxx>
> Sent: Tuesday, June 26, 2001 1:06 PM
> Subject: 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
--
Michael Takefman tak@xxxxxxxxx
Manager HW Engineering, Cisco Systems
Chair IEEE 802.17 Stds WG
2000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-271-3399 fax: 613-271-4867