RFC 1093 (rfc1093) - Page 2 of 9

NSFNET routing architecture

RFC 1093              NSFNET Routing Architecture          February 1989


   Milford, CT.  The adaptation of EGP to the NSS routing code and the
   new requirements was done jointly by Jeff Honig (who spent about a
   week to work on this at IBM Research) and Jacob Rekhter.  Jeff is
   integrating the changes done for the new EGP requirements into the
   "gated" distributions.

   The IGP derives routing tables from Internet address information.
   This information is flooded throughout the NSFNET core, and the
   individual NSS nodes create or update their routing information after
   running the SPF algorithm over the flooded information.  A detailed
   description of the NSFNET backbone IGP will be documented in a future
   document.

   The routing interface between the NSFNET core and regional backbones
   as well as peer networks utilizes the Exterior Gateway Protocol
   (EGP).  The EGP/IGP consistency and integrity at the interface points
   is ensured by filtering mechanisms according to individual nodal
   routing policy data bases [1].  EGP is selected as the routing
   interface of choice between the NSFNET backbone and its regional
   attachments due to its widespread implementation as well its ability
   to utilize autonomous system designators and to allow for effective
   firewalls between systems.  In the longer run the hope is to replace
   the EGP interface with a new inter Autonomous System protocol. Such a
   new protocol should also allow to move the filtering of network
   numbers or Autonomous Network number groups to the regional gateways
   in order for the regional gateways to decide as to what routing
   information they wish to receive.

   A general model is to ensure consistent routing information between
   peer networks.  This means that, e.g., the NSFNET core will have the
   same sets of Internet network numbers in its routing tables as are
   present in the ARPANET core.  However, the redistribution of this
   routing information is tightly controlled and based on Autonomous
   System numbers.  For example, ARPANET routes with the ARPANET
   Autonomous System number will not be redistributed into regional or
   other peer networks.  If an NSFNET internal path exists to such a
   network known to the ARPANET it may be redistributed into regional
   networks, subject to further policy verification. Generally it may be
   necessary to have different trust models for peer and subordinate
   networks, while giving a greater level of trust to peer networks.

   The described use of EGP, which is further elaborated on in [1]
   requires bidirectional translation of network information between the
   IGP in use and EGP.

2. Conclusions reached during the discussions

   The following conclusions were reached during the meeting and in



Braun