The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1996-May> msg00190



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Maybe RSVP and Q.2931, but not NHRP

  • From: Sam Wilson <ercm20@tattoo.ed.ac.uk>
  • Date: 31 May 96 11:06:28 BST
  • cc: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>, mohta@necom830.hpcl.titech.ac.jp, ion@nexen.com

Scott,

> I don't want to get embroiled in your overall argument, but I think I might
> take Masataka's claim a step further:  there is really no inherent reason
> why routers have to be significantly slower than switches in general in the
> WAN environment.  It's merely the way that the market evolved to date.

I wouldn't want to get into an argument about the potential performance
of future cell switches vs future packet switches.  On our network, at
the moment, with the kit we have, each router hop adds considerable
latency and may introduce capacity bottlenecks.  To avoid it requires
either NHRP (non-scaling according to Ohta-san) or some mangling of the
routing model.

> >> or the administrative complexity of
> >> overlaying a mesh of IP connections over a simple ATM star topology.
> >
> >If the mesh of IP connections are necessary only within a subnet,
> >a small cloud between the cell-switching IP routers, it's administration
> >is only as complex as the current configuration.
> >
> >And, are you aware that if you have a large cloud with N nodes and
> >a mesh of IP connections over a simple ATM star topology, most
> >links will have O(N^2) VCs? That is, if you use CBR, each VC can't
> >have high bandwidth. ...

I'm certainly aware of all that.  Let me provide a little more info for
clarification but not, please, comment - I could not guarantee to reply,
even impolitely. 

We have 4 MANs centred on Edinburgh, Glasgow, Aberdeen and Dundee. 
These are to be interconnected in a star based on Edinburgh.  Each MAN
comprises its own core of arbitrary topology, some pure ATM, some mixed
ATM and FDDI technology.  Attached to each MAN are a number of campus
LANs, of the order of a dozen on each MAN, using various technologies
including ATM.  The Scottish MAN Interconnect in Edinburgh will also
connect to the SuperJANET ATM network. 

For IP there are routers between each LAN and their respective MAN and
there will be routers between the MANs across the Interconnect.  At the
ATM level we expect to provide a single signalled fabric from LAN to
LAN, and there will be native ATM applications using it.  NHRP could be
used to take advantage of the ATM infrastructure to provide high
throughput IP traffic between the attached LANs.

Actually, it's all very obvious... :-)

You could also look at http://hel.cee.hw.ac.uk/index.html

Now, Ohta-san - is that large? It is not large in the sense of number of
connected entities (I'd guess 30-40K attached hosts in the catenet) nor
in complexity of routing.  It is large in the sense that there is a
connected NBMA infrastructure which could be exploited to avoid
router-router hops, the sort of scenario both NHRP and CSR are designed
to handle.  Anyway the WG title no longer contains the word 'large'... 
:-)

> I think you folks just talked past each other.  Sam said, "over a simple
> ATM star topology".  He was, if I understand him correctly, assuming that
> the VCs converge at a single point in the "logical center" of the network.

That is indeed the simplest way to build the IP structure of the
Interconnect but is almost certainly the least efficient. 

> This is the simplest way to structure and configure an internetwork over an
> NBMA, and avoids the need for (n * (n-1))/2 VCs to which Masataka
> implicitly refers.  In doing so, it also avoids the fragmentation
> associated with having large numbers of distinct PVCs over each link (as
> Masataka says, "each VC can't have high bandwidth"), but at the cost of an
> extra hop for most if not all of the traffic.

One of our informal aims for our local LAN and MAN and also for the
Scottish MAN Interconnect which we will be managing is never to have to
configure an ATM PVC.  This is partly to avoid the b/w fragmentation
issue (which hits us hard on SuperJANET which uses PVCs and has only(!!)
34Mbps to play with on each link) and partly just because of the
management hassle, though as software matures this is getting easier (in
the worst case having to manually set up a PVC in each direction on each
switch was rather labour intensive). 

> [ frame relay discussion deleted ]
> I'm not trying to argue that meshes are better than stars, or vice versa --
> like most things, it depends. I'm just trying to help you get your arms
> around one aspect of your disagreement.

Thanks for your contribution.  One of the difficulties with switched
link layers (with attitude or not) is that the you can end up building
logical meshes on top of physical stars or vice versa.  Design decisions
interact between the layers.  But you all know that, anyway...


Sam Wilson
Network Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK