Re: [Fwd: Re: [RPRWG] A topology discovery algorithm for RPR]
Brian / Bob,
( NUAN = Nearest Upstream Active Neighbor )
It should also be noted that the process of NUAN that Token-Ring used
only gives a station the MAC address of the upstream station. It does not
give you
the complete ring topology. It is possible in Token-Ring to walk the ring
from a
management station to get the complete topology. This is done by using a
get parameters MAC frame send to each station on the ring. The get parameters
MAC frame returns this stations address and the Upstream address.
In the above I am using some "IBM terms" and not "802.5 terms", but the
actions are the same.
Bottom line, I don't think the Token-Ring process is that good for this case.
Jim Ervin
>-------- Original Message --------
>Subject: Re: [RPRWG] A topology discovery algorithm for RPR
>Date: Thu, 31 May 2001 15:30:15 -0400
>From: "RDLove" <rdlove@xxxxxxxxx>
>To: "Brian Holden" <Brian_Holden@xxxxxxxxxxxxxx>, <stds-802-17@xxxxxxxx>
>CC: "Heng Liao" <Heng_Liao@xxxxxxxxxxxxxx>,"Tom Alexander"
><Tom_Alexander@xxxxxxxxxxxxxx>,"Stuart Robinson"
><Stuart_Robinson@xxxxxxxxxxxxxx>
>References: <9DFF23E1E33391449FDC324526D1F25909D77D@SJC1EXM02>
>
>
>I am not trying to advocate any specific methods of implementing our
>algorithms yet. I believe that one of the greatest benefits of studying
>what Token Ring has done is to understand the problems that it has
>addressed. Certainly we should look at the specific proposals for
>implementing the required features. Some of the proposals may draw on
>solutions developed for Token Ring.
>
>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: "Brian Holden" <Brian_Holden@xxxxxxxxxxxxxx>
>To: "'RDLove'" <rdlove@xxxxxxxxx>; <stds-802-17@xxxxxxxx>
>Cc: "Heng Liao" <Heng_Liao@xxxxxxxxxxxxxx>; "Tom Alexander"
><Tom_Alexander@xxxxxxxxxxxxxx>; "Stuart Robinson"
><Stuart_Robinson@xxxxxxxxxxxxxx>
>Sent: Thursday, May 31, 2001 3:19 PM
>Subject: RE: [RPRWG] A topology discovery algorithm for RPR
>
>
> > Bob,
> >
> > You make a great point about trying to reuse the
> > token ring topology discovery protocols. There are some
> > useful things in 802.5. One example is the Join Ring FSM
> > diagram Fig 23 in section 4.2.2.1.
> >
> > One general issue is that we have passed a motion (#15)
> > which says "The 802.17 RPR standard shall support a fully
> > distributed access method without a master node within
> > the same ring." This seems to rule out the use of those
> > Token Ring methods which rely on the actions of the
> > "Active Monitor" station. It can be argued that
> > 802.5's selection of which station becomes the "Active
> > Monitor" station is dynamic and not determined a priori so
> > it is only marginally a "master node". It can be argued
> > either way.
> >
> > Do others have opinions on whether Token Ring's dynamic
> > selection of an "Active Monitor" station violates our
> > motion?
> >
> > Talk to you soon,
> > Brian Holden
> >
> >
> >
> >
> >
> > _______________________________________________
> > Brian Holden PMC-Sierra, Inc.
> > 3975 Freedom Circle, Santa Clara CA USA
> > +1.408.239.8123 Fax +1.408.492.9862
> > brian_holden@xxxxxxxxxxxxxx http://www.pmc-sierra.com
> >
> >
> >
> >
> > -----Original Message-----
> > From: RDLove [mailto:rdlove@xxxxxxxxx]
> > Sent: Thursday, May 31, 2001 5:00 AM
> > To: Brian Holden; stds-802-17@xxxxxxxx
> > Cc: Heng Liao; Tom Alexander; Stuart Robinson
> > Subject: Re: [RPRWG] A topology discovery algorithm for RPR
> >
> >
> > Brian, thank you for bringing up details that we will need to address
>within
> > the standard. I am not sure what the right solution is yet. However, we
> > would be remiss if we did not fully understand the way this problem has
>been
> > addressed in the past. I refer all that want to understand the background
> > to begin by studying the Token Ring Standard, 4.1.6.2 Neighbor
>Notification
> > process (on page 52 of ISO/IEC8802-5, ANSI/IEEE Std 802.5). I am not
> > suggesting that we copy that process, but just understand its operation,
> > what it accomplishes, and how it accomplishes it. For those that are a
>bit
> > more ambitious, I strongly recommend reading all of the 802.5 Clause 4,
> > Token Ring Protocols, more to understand the functionality it provides,
>than
> > to copy what it does.
> >
> > 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: "Brian Holden" <Brian_Holden@xxxxxxxxxxxxxx>
> > To: <stds-802-17@xxxxxxxx>
> > Cc: "Heng Liao" <Heng_Liao@xxxxxxxxxxxxxx>; "Tom Alexander"
> > <Tom_Alexander@xxxxxxxxxxxxxx>; "Stuart Robinson"
> > <Stuart_Robinson@xxxxxxxxxxxxxx>
> > Sent: Wednesday, May 30, 2001 11:26 PM
> > Subject: [RPRWG] A topology discovery algorithm for RPR
> >
> >
> > >
> > >
> > > All,
> > >
> > > I was kicking around some ideas of how to get a distributed
> > > topology discovery algorithm for RPR that would be:
> > >
> > > 1) robust
> > > 2) not require a separate station numbering scheme
> > > 3) simple
> > >
> > >
> > > Here is one possiblity. There are likely many other ways to
> > > solve this problem - so feel free to shoot holes in this one!
> > >
> > > This algorithm requires:
> > > 1) That each station on the ring must have a separate 48-bit MAC
>address
> > just for control traffic
> > > 2) That we have a ring topology (although it may be extensible to a
>mesh)
> > > 3) That we have a means of sending traffic one and only one hop to each
> > > of a station's neighbors. This can be accomplished by:
> > > a) providing a well-known MAC address for one-hop traffic (my
> > preference)
> > > b) having a bit in the RPR shim which says it is one hop
>traffic
> > > c) some other mechanism
> > >
> > > The algorithm is:
> > > 1) Every T1*ms (forever) each station sends a one-hop MAC-Query message
> > on its East and West
> > > links which requests the MAC address of his immediate neighbors
> > > (along with an authentication field)
> > > 2) Upon receipt of a MAC-Query message, a station responds with its MAC
> > address
> > > (along with an authentication field)
> > > 3) If a MAC-Query is not received in T2*ms, a station records the fact
> > that it has no neighbor
> > > 4) If a MAC-Query response is not received in N attempts, the station
> > records the fact that it
> > > has no neighbor
> > > 5) Every T3*ms (forever) each station sends a broadcast message
> > containing
> > > a) its MAC address
> > > b) its East neighbor's MAC address (or absence)
> > > c) its West neighbor's MAC address (or absence)
> > > d) its capabilities
> > > e) the capabilities of its East Link
> > > f) the capabilities of its West Link
> > > g) (an authentication field)
> > > 6) Upon receipt of one of the broadcast messages, each node updates its
> > topology database.
> > > The MAC addresses in the message payload can be matched up with the
> > current database
> > > entries to find the complete set of neighbors in the ring.
> > >
> > >
> > >
> > > There are several good properties to this algorithm.
> > > 1) The actions of each station are largely stateless
> > > 2) There is no master node
> > > 3) There is no separate numbering system beyond the MAC addresses of
>the
> > station
> > > (numbering systems bring their own set of problems like when partitions
> > occur in
> > > a running system, then nodes are added separately to the partitions,
>then
> > the
> > > partition is healed)
> > > 4) The end result is that each node has a dynamically updated full
> > topology database of
> > > connectivity, control MAC addresses, and capabilities for the stations
> > around the ring
> > >
> > >
> > > Looking for some good feedback.
> > >
> > > Thanks,
> > > Brian Holden
> > >
> > >
> > > _______________________________________________
> > > Brian Holden PMC-Sierra, Inc.
> > > 3975 Freedom Circle, Santa Clara CA USA
> > > +1.408.239.8123 Fax +1.408.492.9862
> > > brian_holden@xxxxxxxxxxxxxx http://www.pmc-sierra.com
> > >
> > >
> > >