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

RE: [RPRWG] A topology discovery algorithm for RPR - interpretati on of Motion #15




While the Motion #15 on master-less topology is a passed objective and the
following may have been discussed before, I think both cases (1) and (2)
outlined by Brian are important in Cable 
head-end, PON, and metro-access network (traffic model is hub & spoke). In
service provider networks explicit control & monitoring by service provider
node (master node in CO?), and SLA enforcement is more important than
fairness & distributed control.  While I may be repeating earlier
discussions, I would like to re-iterate difference between LAN and service
provider -- LANs are predominantly single organizational and administrative
domains; thus distributed control and fairness are more important. In LANs,
the network attempts to adapt itself by re-allocating resources based on
traffic -- thus the achieved throughput for flows may be highly traffic
dependent.  Service provider networks span multiple organizations, and
traffic isolation of multiple customer flows, and explicit control by
service provider node is more important (Master & Standby Master).
Provisioned model is more appropriate in a service provider network. I think
a central controlling device (with redundancy) in a service provider
location is more appropriate.  In LANs all nodes are equally accessible
(within the building with same ease of access) and
maintenance/service/upgrade costs of all nodes are similar unlike in
MAN/WAN.  Thus I would argue for Master centric topology.

  Some of the carrier presentations (as summarized in Lantern & PMC's
presentation) highlight the needs of SLAs, TDM, etc. that are more transport
centric. One of the goals of RPR as I understand is to get into
SONET/Transport markets with Ethernet costs and flexibility -- to this goal
I think .17 should fit into service, O&M, and topology models of current
transmission infrastructure.  

However the .17 currently has more LAN centric vendors (& LAN groups in
LAN-WAN vendors) than 
transport service providers; I am not sure how the process could weigh
carrier needs more than
what early implementations and LAN centric vendors are pushing to
standardize.  

 -Kumar    

-----Original Message-----
From: Brian Holden [mailto:Brian_Holden@xxxxxxxxxxxxxx]
Sent: Thursday, May 31, 2001 4:51 PM
To: stds-802-17@xxxxxxxx
Cc: Heng Liao; Tom Alexander; Stuart Robinson
Subject: RE: [RPRWG] A topology discovery algorithm for RPR -
interpretati on of Motion #15



Bob,

Thanks - I agree that Token Ring is a great place to 
start because its problem space was much the same as ours.


I was just trying to get a sense from the group
as to the interpretation of our motion #15.  Motion
#15's term "Master node" can have at least two meanings.
That motion was:  "The 802.17 RPR standard shall support a 
fully distributed access method without a master node within
the same ring." 


Meaning #1 - "master node" for bandwidth allocation.
Cable modems typically use request-acknowledge or polling
protocols.  This is where the master station explicitly
divides out the available bandwidth to the end stations.

Meaning #2 - "master node" for ring administration.
Token Rings dynamically select an "Active Monitor"
station that is in charge of various ring administration
functions.  These include watching for lost tokens and
initiating the neighbor discovery protocol.

Our meaning could mean one or the other or both of
these meanings.  To me, meaning #1 was definitely in
mind by the group when the motion was accepted.  Meaning
#2 might have been in mind.  If we are to reuse many of the 
administration mechanisms of Token Ring unchanged, we
would have to reject that meaning #2 was what motion #15 
was talking about.


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




> >