doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc1093.txt b/doc/rfc/rfc1093.txt
new file mode 100644
index 0000000..42fa423
--- /dev/null
+++ b/doc/rfc/rfc1093.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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
+         Autonomous System where it originated.  The end effect is that
+         partitions within an Autonomous System will not be healed by
+         using the NSS system.  In addition, if three or more regionals
+         connect to each other via multiple back-door paths, it is
+         imperative that all back-door paths have firewalls that ensure
+         that the above restrictions are imposed.  These actions are
+         necessary to prevent routing loops that involve the NSS system.
+         Furthermore routing information should only be accepted from
+         another regional backbone via backdoor paths for networks which
+         are positively desired to be reached via this same backdoor
+         path.
+
+3. EGP requirements for attached gateways
+
+   The following EGP requirements are necessary for attached gateways;
+   they may require changes in existing vendor products:
+
+      IGP to EGP routing exchanges need to be bidirectional.  This
+      feature should be selectable by the gateway administrator, and by
+      default be configured OFF.
+
+      The metric used when translating from EGP to IGP should be
+      configurable.
+
+
+
+
+Braun                                                           [Page 5]
+
+RFC 1093              NSFNET Routing Architecture          February 1989
+
+
+      It must be possible for IGP information to override EGP
+      information, so that the internal paths are preferred over
+      external paths.  Overriding EGP information on an absolute basis,
+      where an external path would never be used as long as there is an
+      internal one, is acceptable.
+
+      The ability to do route filtering in the regional gateways on a
+      per net basis is highly desirable to allow the regional gateways
+      to do a further selection as to what routes they would want to
+      redistribute into their network.
+
+      The existence of an EGP connection should optionally lead to the
+      generation of a DEFAULT announcement for propagation via the IGP.
+      The DEFAULT metric should be independently configurable.
+
+      EGP routes with a metric of "128" should be acceptable.  In most
+      cases the regional backbone should ignore the EGP metric.
+
+      The regional gateways must only announce networks known to their
+      own Autonomous System.  At the very least they must not
+      redistribute routing information via EGP for routes previously
+      learned via EGP.
+
+      It would be beneficial if the regional IGPs would tag routes as
+      being EGP derived.
+
+      If the EGP peer (e.g., a NSS) terminates the EGP exchange the
+      previously learned routes should expire in a timely fashion.
+
+4. References
+
+   [1]  Rekhter, J., "EGP and Policy Based Routing in the New NSFNET
+        Backbone", T.J. Watson Research Center, IBM Corporation, March
+        1988.  Also as RFC 1092, February 1989.
+
+   [2]  Mills, D., "Autonomous Confederations", RFC 975, M/A-COM
+        Linkabit, February 1986.
+
+   [3]  Mills, D., "Exterior Gateway Formal Specification", RFC 904,
+        M/A-COM Linkabit, April 1984.
+
+   [4] "Exterior Gateway Protocol, Version 3, Revisions and Extensions,"
+        Working Notes of the IETF WG on EGP, Marianne L. Gardner and
+        Mike Karels, February 1988.
+
+   [5]  "Management and Operation of the NSFNET Backbone Network,"
+        proposal to the National Science Foundation, Merit Computer
+        Network, August 1987.
+
+
+
+Braun                                                           [Page 6]
+
+RFC 1093              NSFNET Routing Architecture          February 1989
+
+
+5. Appendix
+
+   The following are extensions implemented for the "gated" EGP
+   implementation, as designed by Jeff Honig of the Cornell University
+   Theory Center.  These extensions are still in the design stage and
+   may be changed over time.  They are included here as an
+   implementation example.
+
+   Changes to egpneighbor clause:
+
+   egpneighbor <address>   metricin <metric>
+                           egpmetricout <egpmetric>
+                           ASin <as>
+                           ASout <as>
+                           nogendefault
+                           acceptdefault
+                           defaultout <egpmetric>
+                           validate
+
+   metricin <metric>
+
+        If specified, the metric of all nets received from this
+        neighbor are set to <metric>.
+
+   egpmetricout <egpmetric>
+
+        If specified, the metric of all nets sent to this neighbor,
+        except default, are set to <egpmetric>.
+
+   ASin <as>
+
+        If specified, EGP packets received from this neighbor must
+        specify this AS number of an EGP error packet is generated.
+        The AS number is only checked at neighbor acquisition time.
+
+   ASout <as>
+
+        If specified, this AS number is used on all EGP packets sent
+        to thiqs neighbor
+
+   nogendefault
+
+        If specified, this neighbor is not considered when
+        generating a gateway default.
+
+   acceptdefault
+
+        If specified, the default will be accepted from this
+
+
+
+Braun                                                           [Page 7]
+
+RFC 1093              NSFNET Routing Architecture          February 1989
+
+
+        neighbor, otherwise it will be explicitly ignored.
+
+   defaultout <egpmetric>
+
+        If specified, the internally generated default is send to
+        this neighbor in EGP updates.  Default learned from other
+        gateways is not propogated.
+
+   validate
+
+        If specifed, all nets learned from this EGP neighbor must
+        have a corresponding 'validAS' clause or they will be
+        ignored.
+
+   Addition of a validAS clause:
+
+   validAS <net> AS <as> metric <metric>
+
+      This clause specifies which AS a network may be learned from and
+      what internal metric to use when the net is learned.  The
+      specifies the 'validate' option.  Note that more than one may be
+      learned from more than one AS.
+
+   Addition of sendAS and donotsendAS clauses:
+
+      These clauses control the announcement of exterior (currently only
+      EGP) routes.  Normally, exterior routes are not considered for
+      announcement.  When the 'sendAS' or 'donotsendAS' clauses are
+      used, the announce/donotannounce, egpnetsreachable and other
+      restrictions still apply.  The 'sendAS' and 'donotsendAS' clauses
+      are mutually exclusive by autonomous system.
+
+   sendAS <as0> ASlist <as1> <as2> ...
+
+      This clause specifies that only nets learned from as1, as2, ...
+      may be propogated to as0.
+
+   donotsendAS <as0> ASlist <as1> <as2> ...
+
+      This clause specifies that nets learned from as1, as2, ...  may
+      not be propogated to <as0>, all other nets are propogated.
+
+   An example of a "/etc/gated.conf" file could include the following:
+
+   #
+   RIP supplier
+   #
+   autonomousystem (regional AS)
+
+
+
+Braun                                                           [Page 8]
+
+RFC 1093              NSFNET Routing Architecture          February 1989
+
+
+   #
+   egpneighbor (NSS address) ASin (NSS AS) nogendefault
+   metricin (metric)
+   #
+   sendAS (NSS AS) ASlist (regional AS)
+   #
+
+   Where:
+
+        Regional AS   Is the AS number of the regional network
+        NSS address   Is the IP address of the local NSS
+        NSS AS        Is the AS number the NSFNET backbone
+        Metric        Is the gated internal (time delay) metric that
+                      EGP learned routes should have.  This is the
+                      metric used on output after conversion to a RIP
+                      metric.  Some values are:
+
+                                   HELLO   RIP
+                                   100     1
+                                   148     2
+                                   219     3
+                                   325     4
+                                   481     5
+
+Author's Address:
+
+   Hans-Werner Braun
+   University of Michigan
+   Computing Center
+   1075 Beal Avenue
+   Ann Arbor, MI 48109
+
+   Phone: (313) 763-4897
+
+   Email: HWB@MCR.UMICH.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Braun                                                           [Page 9]
+
\ No newline at end of file