Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
> > >
> > >
> > >