Re: [Fwd: Re: [RPRWG] A topology discovery algorithm for RPR]
Jim, thanks for your comments. As an expert in Token Ring design, you may
want to provide us with some input on the functions provided by the Token
Ring protocol, and which of those you believe are important ones for RPR to
replicate.
As a separate issue, your comments on whether the way Token Ring executed
each of those functions is attractive for RPR would also provide us with
valuable input.
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: "Jim Ervin" <jervin@xxxxxxxxx>
To: <Brian_Holden@xxxxxxxxxxxxxx>; <rdlove@xxxxxxxxx>
Cc: <stds-802-17@xxxxxxxx>; <Heng_Liao@xxxxxxxxxxxxxx>;
<Tom_Alexander@xxxxxxxxxxxxxx>; <Stuart_Robinson@xxxxxxxxxxxxxx>
Sent: Thursday, May 31, 2001 6:11 PM
Subject: 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
> > > >
> > > >
> > > >
>