Draft CSNET Routing Topology

[Daniel Long <[e-mail]>]

    As promised, here's the draft routing policy for the impending CSNET
connection to the NSS at SDSC.  Please let me know if you have any comments.

Thanks,
Dan

---------------------------------------------------------------------------


   		     Draft CSNET Routing Topology Design
     		     -----------------------------------

		                    4/2/90   

			       Dan Long, BBN STC
 		             Bill Nugent, BBN STC


1. Introduction--What is CSNET?

2. Current Physical Topology

3. Current Routing Topology

4. Planned Changes in Physical Topology

5. Planned Changes in Routing Topology

6. Conclusion--Where do we go from here?

--------------------------------------------------------------------------


1. Introduction--What is CSNET?

     CSNET is a nationwide NSFNET mid-level network.  CSNET has historically
targeted small organizations with PhoneNet, a UUCP-like dialup email service.
Many of these organizations have, over time, "grown up" to use TCP/IP and have
either joined their geographically local NSFNET mid-level network or have
requested TCP/IP connectivity from CSNET.  Several of those who have TCP/IP
connections to CSNET are loyal CSNET members and want to continue to improve
their Internet connectivity within the CSNET framework.

     CSNET has also historically offered some connection methods not supported
by other mid-level networks.  Specifically, it support TCP/IP over X.25 which
is particularly popular with its International affiliates and members.  And it
supports PhoneNet over XXX over X.25, also popular with the International
community.  Finally, it has continued its "low-end" focus by offering Dialup-IP
services for sites who cannot afford leased-line connections to the Internet.

2. Current Physical Topology

     CSNET is currently a pair of hubs, one at BBN in Cambridge, MA and the
other at Olivetti in Menlo Park, CA.  These two hubs form the East Coast
Cluster or ECC and the West Coast Cluster or WCC.

     All the X.25-based, PhoneNet, and Dialup-IP services are based at the ECC.
The pure TCP/IP members are divided equally between the two.  The two clusters
are connected by a 256KB Fractional T1 circuit.  The ECC is co-located with a
NEARnet POP which is connected by redundant Microwave Ethernet links to the
JVNCNet and thence by redundant T1 circuits to the NSFNET NSS in Princeton, NJ.

             |	|  |           |  |  |
             |	|  |           |  |  |
          +--+--+--+--+     +--+--+--+--+    +-------+    +-------+    +-----+
          |           |     |           |    |       |    |       |    |     |
          |   CSNET   |     |   CSNET   |    |       |    |       |    |     |
          |    WCC    +-----+    ECC    +----+NEARnet+----+JVNCnet+----+NSS 8|
          |           |256KB|           |10MB|       |10MB|       | T1 |     |
          |           |     |           |    |       |    |       |    |     |
          +--+--+--+--+     +--+--+--+--+    +-------+    +-------+    +-----+
             |	|  |	       |  |  |			   
             |	|  |           |  |  |


3. Current Routing Topology

     Currently, all Internet-bound traffic from WCC and ECC is passed to the
right in the above diagram.  WCC and ECC share routes via several IGRP
processes:

    IGRP 510  contains ECC & NEARnet routes
    IGRP 511  contains WCC routes
    IGRP 560  contains routes learned from JVNCNet [& NSFnet]
 	   ("NSFnet" today is just 129.140.0.0, because of JVNCNet limitations)

The ECC and WCC routes are fed into NEARnet's IGP, IGRP 281, which is fed to
JVNCnet's IGP, IGRP 97, which is advertised to the NSS.

     Some WCC members are also members of BARRNet.  They make their own
decisions about where to send their traffic.  They decide how to rank their
advertisements into NSFNet.  There is no ranking, however, within
CSNET/NEARnet/JVNCnet--all traffic goes via CSNET rather than NSFNET.

4. Planned Changes in Physical Topology

     CSNET plans to establish a T1 line between the WCC and the NSS at San
Diego.  This connection will allow traffic generated at the WCC that is
destined for the West Coast to stay on the West Coast.  This will
also provide some redundancy for the cross-country 256KB link:

              |	 |  |           |  |  |
              |	 |  |           |  |  |
+-----+    +--+--+--+--+     +--+--+--+--+    +-------+    +-------+    +-----+
|     |    |           |     |           |    |       |    |       |    |     |
|     |    |   CSNET   |     |   CSNET   |    |       |    |       |    |     |
+NSS 6+----+    WCC    +-----+    ECC    +----+NEARnet+----+JVNCnet+----+NSS 8|
|     | T1 |           |256KB|           |10MB|       |10MB|       | T1 |     |
|     |    |           |     |           |    |       |    |       |    |     |
+--+--+    +--+--+--+--+     +--+--+--+--+    +-------+    +-------+    +--+--+
   |          |	 |  |	        |  |  |			                   |
   |          |	 |  |           |  |  |                                    |
   |                                                                       |
   |                                                                       |
   +-----------------------------------------------------------------------+
                                    NSFNET
				      
     
5. Planned Changes in Routing Topology

     In this new topology, several decisions have to be made about where
traffic should go and then a routing plan has to be designed to implement that
policy.  In designing that routing plan, care must be taken to avoid routing
loops and black holes.

Proposed traffic flow:

   Traffic between WCC and ECC/NEARnet/JVCnet should use the 256KB link.
	-- If the 256KB link is down, traffic should use the NSFNET backbone.

   Traffic between WCC and NSFNET should use NSS 6.
   Traffic between ECC and NSFNET should use NEARnet.
	-- If either NSFNET connection is down, traffic should use the other.

   Traffic between NEARnet and NSFNET should use JVNCnet.
	-- If JVNCnet or NSS-8 are down, traffic should go to the bit bucket.

Proposed implementation:

   Defer use of BGP; EGP+IGRP should suffice for now.

   Add a routing process within WCC & ECC:
       IGRP 10   contains routes learned from [SDSC &] NSFnet
	    (limit NSFnet input to the default "129.140.0.0" as long as JVNC
	     doesn't provide all NSFNet routes)

   On the model of NSFNET's routing relationship with the DDN (per RFC 1133):
       Advertise WCC routes at level N to NSS 6.
       Advertise WCC routes at level N+1 to NSS 8.
    
       Advertise ECC routes at level N to NSS 8.
       Advertise ECC routes at level N+1 to NSS 6.

   Advertise NEARnet/JVNCnet routes at level N to NSS 8.

      (For the most part, N=1 (a primary route).  Some networks that have
       other preferred connections (e.g. to Barrnet) will have N=2 or 3.)

   Configure WCC and ECC to prefer routes learned via their internal IGP's
   (510 & 511) over routes learned externally (560 & 10).

   
6. Conclusion -- Where do we go from here?

     The proposed traffic plan and routing implementation should be reviewed by
the CSNET folks[done], the TEWG group, MERIT, and SDSC[done] to insure that it
will all fly.  If all looks good, we'll push to get the line in and the bits
flowing as fast as possible.