Dave Sincoskie sincos at
Thu Sep 1 14:11:37 UTC 1994

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.

More information about the NANOG mailing list