|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Comments
Here's a couple of other things we thought about. FDDI NAP - good short term prospects, tried and true technology. Capacity even more of a problem than SMDS, won't even support a 155 Mb/s vBNS connection. Switched FDDI over ATM helps the bandwidth problem a bit, but I don't really understand how that will extend to a large-scale network. The LAN-emulation folks in the Forum have lots of work yet to do with large LAN emulation networks. The equipment for LAN emulation over ATM is in the same stage of "immaturity" as the IP/ATM equipment. Multimedia NAP - My best reply to this is Peter Ford's statement, "NAPs Don't Route". They're a layer two service. Some layer 2 interworking may be possible in the future, and we're looking at FR<->ATM interworking boxes right now. Cheap, low speed connections to the NAP - We got squeezed by product availability here. We know that there is a bigger market in selling T1 speed connections to the NAPs than T3 and above. However, we had a requirement to support multiple T3's initially (remember that the minimum purpose of the NAPs is to support the existing NSFNET backbone for transition purposes, the NSPs who are providing access to RNP's and who have a requirement to connect to all of the priority NAPs, and the vBNS). FDDI and SMDS weren't going to survive for long under this type of load, but ATM doesn't yet have T1 capability (although it's coming). So, we proposed ATM, starting at 45 and 155 Mb/s initially, and extending to 1.5 Mb/s and 622 Mb/s as switching equipment becomes available. Believe me, we'll be offering T1 speed connections to the SF and Chicago NAPs just as soon as we can make it work. ATM immaturity - ATM itself isn't immature, it's the router and ADSU technology that's immature. We've been running ATM in our lab since (believe it or not) 1986, and switch vendors have been shipping equipment for about 3 years now. We're beginning to see second generation products on the market right now. Since the Toronto IETF, we've been running tests on the SF NAP configuration, and the problems we've found (and fixed) have all been with the ADSU's or routers. We do have a working configuration for the 1490/AAL5 protocol stack, and are running load tests on it now. Bi-lateral/multi-lateral NAP traffic agreements - There's no rules here at all. The agreements are completely up to the NSPs who connect to the NAP. A CIX-like arrangement where all parties agree to exchange traffic w/o settlements is just as possible as N**2 bi-lateral agreements with traffic sensitive settlements. The NAP managers and NSF have nothing to say here. As far as taking a long-range view on the Internet, I'll plead guilty. We're already seeing congestion problems on the Internet today, and that's even before we turn the video and audio applications completely loose. My concern is that if we don't get enough capacity into the Internet, and really soon, the growth rate is going to drop badly. I've lived on badly congested Internets (remember the 56 Kb/s NSFNET?), and it's not an experience I wish to repeat. Dave - - - - - - - - - - - - - - - - -
|