Re: [RPRWG] CRC check in each node?
Devendra, IEEE 802.5 thought of that. Please see my note to Mike Takefman,
and this reflector, June 26th, 9:20pm where I describe how error domains are
determined in 802.5.
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: "RDLove" <rdlove@xxxxxxxxx>
Cc: "ieee 802.17 list" <stds-802-17@xxxxxxxx>
Sent: Thursday, June 28, 2001 9:51 PM
Subject: RE: [RPRWG] CRC check in each node?
> Hi Robert,
>
> As a corrollary, I think only node which drops the packet should count the
> error (otherwise same error will be counted by many nodes and may be many
> times). Unfortunately it may mask off error start point. Any one has
thought
> more on this ?
>
> 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 RDLove
> > Sent: Thursday, June 28, 2001 4:52 AM
> > To: Devendra Tripathi
> > Cc: ieee 802.17 list
> > Subject: 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
> > > > ---------------------------------------
> > > >
> > > >
> > > >
> > >
> >
> >
>