|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Sprint NAP Status
> From: Pushpendra Mohta <[email protected]> > 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. -tjs - - - - - - - - - - - - - - - - -
|