Sprint NAP Status
tjs at msc.edu
Sat Sep 24 20:20:11 UTC 1994
> From: Pushpendra Mohta <pushp at CERF.NET>
> Date: Sat, 24 Sep 1994 11:16:10 -0700 (PDT)
> Ittai Hershman writes:
> > CERFnet will be directly connected to the Sprint NAP via Sprint's
> > ATM in the same timeframe.
> > The NAP is a L2 facility. Will the CERFnet router connected to the
> > NAP appear to the other NSP routers to be on the same "wire"?
> The router has one ATM and one FDDI interface. You will
> see us on the FDDI like all other peers.
There are [at least] two architectures for using ATM wide-area networks
to connect to NAPs.
o The ATM WAN could be used as a "wire replacement" to connect
two routers, one at the remote location (e.g., CERFnet in San
Diego) and the other at the NAP (e.g., the Sprint FDDI NAP in
Pennsauken). These routers could either:
- Act as routers, in which case the router local to the NAP
communicates directly with other routers on the NAP; or
- The routers could act as FDDI-FDDI bridges between
an FDDI ring at the remote site and the NAP FDDI ring,
in which case the remote router appears to be on the
NAP FDDI ring, (plus or minus propagation delay).
o The ATM WAN could be used as a more richly connected "cloud,"
which is connected [via ATM; not a router] to an ATM NAP.
In this case, there would be a remote router, but no
associated router at the ATM NAP. In this case, the remote
router will appear to be on the ATM NAP, (i.e., appear to be
on the same layer two medium). The remote router will
then be able to peer directly with the NSP routers located
on the ATM NAP.
Push will have to speak for CERFnet as to their plans; I don't know
for certain which of these architectures CERFnet plans to implement.
The use of ATM WANs to connect remote routers to ATM NAPs sounds like a
good topic for another ATM NAP Workshop at the next IETF.
More information about the NANOG