rfc1093.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                         H.W. Braun
Request for Comments: 1093                                         Merit
                                                           February 1989


                    The NSFNET Routing Architecture

Status of this Memo

   This document describes the routing architecture for the NSFNET
   centered around the new NSFNET Backbone, with specific emphasis on
   the interface between the backbone and its attached networks.
   Distribution of this memo is unlimited.

Introduction

   This document describes the routing architecture for the NSFNET
   centered around the new NSFNET Backbone, with specific emphasis on
   the interface between the backbone and its attached networks.  It
   reflects and augments thoughts described in [1], discussions during
   the Internet Engineering Task Force meeting at the San Diego
   Supercomputing Center in March 1988, discussions on mailing lists,
   especially on a backbone/regional network working group mailing list,
   and a final discussion held at the IBM T.J. Watson Research Center in
   Yorktown, NY, on the 21st of March 1988.  The Yorktown meeting was
   attended by Hans-Werner Braun (Merit), Scott Brim (Cornell
   University), Mark Fedor (NYSERNet), Jeff Honig (Cornell University),
   and Jacob Rekhter (IBM).  Thanks also to: Milo Medin (NASA), John Moy
   (Proteon) and Greg Satz (Cisco) for discussing this document by email
   and/or phone.

   Understanding of [1] is highly recommended prior to reading this
   document.

1. Routing Overview

   The new NSFNET backbone forms the core of the overall NSFNET, which
   connects to regional networks (or regional backbones) as well as to
   peer networks (other backbones like the NASA Science Network or the
   ARPANET).  The NSFNET core uses a SPF based internal routing
   protocol, adapted from the IS-IS protocol submitted by ANSI for
   standardization to the ISO.  The ANSI IS-IS protocol is based upon
   work done at Digital Equipment Corporation.  Its adaptation to the
   Internet environment requires additional definitions, most notably to
   the addressing structure, which will be described in a later
   document.  This adaptation was largely done by Jacob Rekhter of IBM
   Research in Yorktown, NY. The RCP/PSP routing architecture was
   largely implemented by Rick Boivie and his colleagues at IBM TCS in



Braun                                                           [Page 1]

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                                                           [Page 2]

RFC 1093              NSFNET Routing Architecture          February 1989


   subsequent discussions:

      No DDN-only routes (ARPANET/MILNET) shall be announced into the
      regional backbones.  This is a specific case of the ability to
      suppress information from specific Autonomous Systems, as
      described later.

      Regional backbones are required to use an unique Autonomous System
      number.  Announcements from non-sanctioned autonomous systems,
      relative to a particular site, will not be believed and will
      instead trigger an alarm to the Network Operations Center.

      Regional backbone attachments must not require routes to local
      subnets.  This means that the locally attached network needs to
      use a flat space, without subnet bits, at least from the NSS point
      of view.  The reason for this is that the EGP information
      exchanged between the regional gateway and the NSS cannot include
      subnet information. Therefore the NSS has no knowledge of remote
      subnets.  The safest way to get around this limitation is to use a
      non-subnetted network (like a separate Class-C network) at the
      interface between a regional backbone and the NSFNET backbone.
      The other way is to use Proxy-ARP while having just the NSS think
      that the network is not subnetted. In the latter case care must be
      taken so that the E-PSP uses the proper local IP broadcast
      address.

      Routing information received by the NSS from regional gateways
      will be verified on both network number and autonomous system
      number.

      Metric reconstitution is done on a per-network basis.  The NSS
      will construct the fixed metric it will use for a given network
      number from its internal data base.  Network metrics given to the
      NSS via EGP will be ignored.  The metrics used are a result of an
      ordered list of preferred paths as supplied by the regional
      backbones and the attached campuses.  This metric is of relevance
      only to the NSFNET core itself.  The mechanisms are further
      explained in [1].

      Global metric reconstitution by Autonomous System numbers is
      necessary in specific cases, such as peer networks.  An example is
      that ARPANET routes will be reconstituted to a global metric, as
      determined by the NSS.

      EGP announcements into regional networks will use a fixed metric.
      The metric used shall be "128."  The 128-metric is somewhat
      arbitrarily chosen to be high enough so that a regional backbone
      will get a metric high enough from the NSFNET Core AS to allow a



Braun                                                           [Page 3]

RFC 1093              NSFNET Routing Architecture          February 1989


      comparison against other (most likely internal) routes. "128" is
      also consistent with [2].

      Peer network routes (e.g., ARPANET routes) are propagated through
      the NSS structure.

      No DEFAULT routing information is distributed within the NSFNET
      backbone, as the NSFNET core has the combined routing knowledge of
      the attached regional and peer networks.

      We do not expect the requirement for damping of routing update
      frequencies, at least initially.  The frequency of net up/down
      changes combined with the available bandwidth and CPU capacity do
      not let the frequency of SPF floodings appear as being a major
      problem.  Simple metric changes as heard by a NSS via EGP will not
      trigger updates.

      An allowed list of Source Autonomous System information will be
      used to convert from the IGP to EGP, on a Destination Autonomous
      System number basis, to allow for specific exclusion of definable
      remote Autonomous System information.

      EGP must only announce networks for which the preferred path is
      via the IGP.  This means in particular that the EGP peer will
      never announce via EGP what it learned via EGP on the same
      interface, not even if the information was received from a third
      EGP peer.  This will avoid the back-distribution of information
      learned via that same interface.  The EGP peers of regional
      gateways must only announce information belonging to their own
      Autonomous System.

      EGP will be used in interior mode only.

      The regional backbones are responsible for generating DEFAULT
      routing information at their option.  One possibility is to
      generate an IGP default on a peer base as long as the NSS EGP
      connection is working.  The EGP information will not include a
      special indication for DEFAULT.

      It is highly desirable to have direct peer-peer connections, to
      ease the implementation of a consistent routing data base.

      A single Autonomous System number may not be used with two E-PSPs
      at the same time as long as the two E-PSP's belong to the same
      NSS.  Otherwise the same Autonomous System number can be used from
      multiple points of attachment to the backbone and therefore can
      talk to more than one E-PSP.  However, this may result in
      suboptimal routing unless multiple announcements are properly



Braun                                                           [Page 4]

RFC 1093              NSFNET Routing Architecture          February 1989


      engineered according to [1].

      The administrator of the regional networks should be warned that
      improper routing implementations within the region may create
      suboptimal regional routing by using this restriction if no care
      is taken in that:

         Only networks belonging to their own Autonomous System get
         preferred over NSFNET backbone paths; this may extend to a
         larger virtual Autonomous System if backdoor paths are
         effectively implemented.

         IGP implementations should not echo back routing information
         heard via the same path.

         If two regional networks decide to implement a backdoor
         connection between themselves, then the backdoor must have a
         firewall in so that information about their own Autonomous
         System cannot flow in from the other Autonomous System.  That
         is, a regional network must not allow information about
         networks that are interior to its Autonomous System to enter
         via exterior routes.  Likewise, if a regional network is
         connected to the NSFNET via two NSS connections, the NSS cannot
         send back information about the Autonomous System into the