Re: [RPRWG] A topology discovery algorithm for RPR
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
> >
> >
> >