Re: Sprint NAP Status

[tjs () msc edu (Tim Salo)]

> From: Pushpendra Mohta <pushp () 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.

-tjs
- - - - - - - - - - - - - - - - -