The Routing Over Large Clouds Mailing List Archive by date[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Maybe RSVP and Q.2931, but not NHRP
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
|
|