Re: [RPRWG] CRC check in each node?
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