Re: [RPRWG] CRC check in each node?
Devendra, the alternative to a master node is to let the TTL timer expire,
at which time it would be stripped by the next node it reached.
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: "Devendra Tripathi" <tripathi@xxxxxxxxxxxx>
To: "Robin Olsson" <robino@xxxxxxxxxxx>; <tak@xxxxxxxxx>
Cc: "ieee 802.17 list" <stds-802-17@xxxxxxxx>
Sent: Thursday, June 28, 2001 3:39 PM
Subject: RE: [RPRWG] CRC check in each node?
>
> I think Robin has good point. After all, as Mike pointed out,
> we anyway can not enforce it (removing CRC error packets) as it would
amount
> to enforcing store - forward through back door. I guess, the only thing
> which comes out as requirement is that there got to be one "master" node
> which must drop it as otherwise it may remain circulating (if header got
> corrupted by chance).
>
> Regards,
> Devendra Tripathi
> CoVisible Solutions Inc.
> (formerly VidyaWeb, Inc)
> Pune, India
> Tel: +91-20-433-1362
>
> > -----Original Message-----
> > From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> > [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Robin Olsson
> > Sent: Wednesday, June 27, 2001 12:02 PM
> > To: tak@xxxxxxxxx
> > Cc: ieee 802.17 list
> > Subject: Re: [RPRWG] CRC check in each node?
> >
> >
> >
> > Hi Mike and all
> >
> > So I do not compare it bridges today. I compare it to carrier
> > networks today. What makes SONET good? The cabaility to monitor
> > each link and path. Where a customer corresponds to a path. The
> > mnitor and statistics are collected in intermediate nodes to
> > provide for fault location and collected at the end point (i.e.,
> > at the customers interface) to provide as proof for the quality
> > of the network. Some nodes just monitors links, i.e. aggregate
> > traffic, some nodes monitors every path, i.e. customer, but all
> > nodes have the opportunity to monitor due to the fact that error
> > information on path (customer) level is preserved.
> >
> > I am not saying that we want to have SONET. I am saying that if
> > we want to give an packet based alternative to SONET in the
> > carrier world, we should provide sufficient OAM. I see keep the
> > errored packets in the ring as ONE way of doing some of that. And
> > a very easy way as well.
> >
> > But to get back to my question I posted earlier: What is the
> > benefit of removing errored packets in intermediate nodes?
> >
> > Robin
> >
> > Mike Takefman wrote:
> >
> > > 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
> >
> > --
> > ---------------------------------------
> > Robin Olsson
> > Vitesse Semiconductors, Denmark
> > Phone: +45 4596 9659
> > fax: +45 4596 9699
> > ---------------------------------------
> >
> >
> >
>