doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc1133.txt b/doc/rfc/rfc1133.txt
new file mode 100644
index 0000000..6d5dbe2
--- /dev/null
+++ b/doc/rfc/rfc1133.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                            J. Yu
+Request for Comments: 1133                                  H-W. Braun
+                                                Merit Computer Network
+                                                         November 1989
+
+
+                 Routing between the NSFNET and the DDN
+
+Status of this Memo
+
+   This document is a case study of the implementation of routing
+   between the NSFNET and the DDN components (the MILNET and the
+   ARPANET).  We hope that it can be used to expand towards
+   interconnection of other Administrative Domains.  We would welcome
+   discussion and suggestions about the methods employed for the
+   interconnections.  No standards are specified in this memo.
+   Distribution of this memo is unlimited.
+
+1.  Definitions for this document
+
+   The NSFNET is the backbone network of the National Science
+   Foundation's computer network infrastructure.  It interconnects
+   multiple autonomously administered mid-level networks, which in turn
+   connect autonomously administered networks of campuses and research
+   centers.  The NSFNET connects to multiple peer networks consisting of
+   national network infrastructures of other federal agencies.  One of
+   these peer networks is the Defense Data Network (DDN) which, for the
+   sake of this discussion, should be viewed as the combination of the
+   DoD's MILNET and ARPANET component networks, both of which are
+   national in scope.
+
+   It should be pointed out that network announcements in one direction
+   result in traffic the other direction, e.g., a network announcement
+   via a specific interconnection between the NSFNET to the DDN results
+   in packet traffic via the same interconnection between the DDN to the
+   NSFNET.
+
+2.  NSFNET/DDN routing until mid '89
+
+   Until mid-1989, the NSFNET and the DDN were connected via a few
+   intermediate routers which in turn were connected to the ARPANET.
+   These routers exchanged network reachability information via the
+   Exterior Gateway Protocol (EGP) with the NSFNET nodes as well as with
+   the DDN Mailbridges.  In the context of network routing these
+   Mailbridges can be viewed as route servers, which exchange external
+   network reachability information via EGP while using a proprietary
+   protocol to exchange routing information among themselves.
+   Currently, there are three Mailbridges at east coast locations and
+
+
+
+Yu & Braun                                                      [Page 1]
+
+RFC 1133         Routing between the NSFNET and the DDN    November 1989
+
+
+   three Mailbridges at west coast locations.  Besides functioning as
+   route servers the Mailbridges also provide for connectivity, i.e,
+   packet switching, between the ARPANET and the MILNET.
+
+   The intermediate systems between the NSFNET and the ARPANET were
+   under separate administrative control, typically by a NSFNET mid-
+   level network.
+
+   For a period of time, the traffic between the NSFNET and the DDN was
+   carried by three ARPANET gateways.  These ARPANET gateways were under
+   the administrative control of a NSFNET mid-level network or local
+   site and had direct connections to both a NSFNET NSS and an ARPANET
+   PSN.  These routers had simultaneous EGP sessions with a NSFNET NSS
+   as well as a DDN Mailbridge.  This resulted in making them function
+   as packet switches between the two peer networks.  As network routes
+   were established packets were switched between the NSFNET and the
+   DDN.
+
+   The NSFNET used three NSFNET/ARPANET gateways which had been provided
+   by three different sites for redundancy purposes.  Those three sites
+   were initially at Cornell University, the University of Illinois
+   (UC), and Merit.  When the ARPANET connections at Cornell University
+   and the University of Illinois (UC) were terminated, a similar setup
+   was introduced at the Pittsburgh Supercomputer Center and at the John
+   von Neumann Supercomputer Center which, together with the Merit
+   connection, allowed for continued redundancy.
+
+   As described in RFC1092 and RFC1093, NSFNET routing is controlled by
+   a distributed policy routing database that controls the acceptance
+   and distribution of routing information.  This control also extends
+   to the NSFNET/ARPANET gateways.
+
+2.1  Inbound announcement -- Routes announced from the DDN to the
+     NSFNET
+
+   In the case of the three NSFNET/ARPANET gateways, each of the
+   associated NSSs accepted the DDN routes at a different metric.  The
+   route with the lowest metric then was favored for the traffic towards
+   the specific DDN network, but had that specific gateway to the DDN
+   experienced problems with loss of routing information, one of the
+   redundant gateways would take over and carry the load as a fallback
+   path.  Assuming consistent DDN routing information at any of the
+   three gateways, as received from the Mailbridges, only a single
+   NSFNET/ARPANET gateway was used at a given time for traffic from the
+   NSFNET towards the DDN, with two further gateways standing by as hot
+   backups.  The metric for network announcements from the DDN to the
+   NSFNET was coordinated by the Merit/NSFNET project.
+
+
+
+
+Yu & Braun                                                      [Page 2]
+
+RFC 1133         Routing between the NSFNET and the DDN    November 1989
+
+
+2.2  Outbound announcement -- Routes announced from the NSFNET to the
+     DDN
+
+   Each NSS involved with NSFNET/DDN routing had an EGP peer relation
+   with the NSFNET/ARPANET gateway.  Via EGP it announced a certain set
+   of NSFNET connected networks, again, as controlled by the distributed
+   policy routing database, to its peer.  The NSFNET/ARPANET gateway
+   then redistributed the networks it had learned from the NSS to the
+   DDN via a separate EGP session.  Each of the NSFNET/ARPANET gateways
+   used a separate Autonomous System number to communicate EGP
+   information with the DDN.  Also these Autonomous System numbers were
+   not the same as the NSFNET backbone uses to communicate with directly
+   attached client networks.  The NSFNET/ARPANET gateways used the
+   Autonomous System number of the local network.  The metrics for
+   announcing network numbers to the DDN Mailbridges were set according
+   to the requests of the mid-level network of which the specific
+   individual network was a client.  Mid-level network also influenced
+   the specific NSFNET/ARPANET gateway used, including primary/secondary
+   selection.  These primary/secondary selections among the
+   NSFNET/ARPANET gateways allowed for redundancy, while the preference
+   of network announcements was modulated by the metric used for the
+   announcements to the DDN from the NSFNET/ARPANET gateways.  Some of
+   the selection decisions were based on reliability of a specific
+   gateway or congestion expected in a specific PSN that connected to
+   the NSFNET/ARPANET gateway.
+
+2.3  Administrative aspects
+
+   From an administrative point of view, the NSFNET/ARPANET gateways
+   were administered by the institution to which the gateway belonged.
+   This has never been a real problem due to the excellent cooperation
+   received from all the involved sites.
+
+3.  NSFNET/DDN routing via attached Mailbridges
+
+   During the first half of 1989 a new means of interconnectivity
+   between the NSFNET and the DDN was designed and implemented.
+   Ethernet adapters were installed in two of the Mailbridges, which
+   previously just connected the MILNET and the ARPANET, allowing a
+   direct interface to NSFNET nodes.  Of these two Mailbridges one is
+   located on the west coast at NASA-Ames located at Moffett Field, CA,
+   and the other one is located on the east coast at Mitre in Reston,
+   VA.  With this direct interconnection it became possible for the
+   NSFNET to exchange routing information directly with the DDN route
+   servers, without a gateway operated by a mid-level network in the
+   middle.  This also eliminated the need to traverse the ARPANET in
+   order to reach MILNET sites.  It furthermore allows the Defense
+   Communication Agency as well as the National Science Foundation to
+
+
+
+Yu & Braun                                                      [Page 3]
+
+RFC 1133         Routing between the NSFNET and the DDN    November 1989
+
+
+   exercise control over the interconnection on a need basis, e.g., the
+   connectivity can now be easily disabled from either site at times of
+   tighter network security concerns.
+
+3.1  Inbound announcement -- Routes announced from the DDN to the
+     NSFNET
+
+   The routing setup for the direct Mailbridge connections is somewhat
+   different, as compared to the previously used NSFNET/ARPANET
+   gateways.  Instead of a single NSFNET/ARPANET gateway carrying all
+   the traffic from the DDN to the NSFNET at any moment, the
+   distribution of network numbers is now split between the two
+   Mailbridges.  This results in a distributed load, with specific
+   network numbers always preferring a particular Mailbridge under
+   normal operating circumstances.  In the case of an outage at one of
+   the Mailbridge connections, the other one fully takes over the load
+   for all the involved network numbers.  For this setup, the two DDN
+   links are known as two different Autonomous System numbers by the
+   NSFNET.  The routes learned via the NASA-Ames Mailbridges are part of
+   the Autonomous System 164 which is also the Autonomous System number
+   which the Mailbridges are using by themselves during the EGP session.
+   In the case of the EGP sessions with the Mitre Mailbridge, the DDN-
+   internal Autonomous System number of 164 is overwritten with a
+   different Autonomous System number (in this case 184) and the routes
+   learned via the Mitre Mailbridge will therefore become part of
+   Autonomous System 184 within the NSFNET.
+
+   The NSFNET-inbound routing is controlled by the distributed policy
+   routing database.  In particular, the network number is verified
+   against a list of legitimate networks, and a metric is associated
+   with an authorized network number for a particular site.  For
+   example, both NSSs in Palo Alto and College Park learn net 10 (the
+   ARPANET network number) from the Mailbridges they are connected to
+   and have EGP sessions.  The Palo Alto NSS will accept Net 10 with a
+   metric of 10, while the College Park NSS will accept the same network
+   number with a metric of 12.  Therefore, traffic destinated to net 10
+   will prefer the path via the Palo Alto NSS and the NASA-Ames
+   Mailbridge.  If the connection via the NASA-Ames Mailbridge is not
+   functioning, the traffic will be re-routed via the Mailbridge link at
+   Mitre.  Each of the two NSS accepts half of the network routes via
+   EGP from its co- located Mailbridge at a lower metric and the other
+   half at a higher metric.  The half with the lower metric at the Palo
+   Alto NSS will be the same set which uses a higher metric at the
+   College Park NSS and vice versa.
+
+   There are at least three different possibilities about how the NSFNET
+   could select a path to a DDN network via a specific Mailbridge, i.e.,
+   the one at NASA-Ames versus the one at Mitre:
+
+
+
+Yu & Braun                                                      [Page 4]
+
+RFC 1133         Routing between the NSFNET and the DDN    November 1989
+
+
+      1.  Assign a primary path for all DDN networks to a single
+          Mailbridge and use the other purely as a backup path.
+
+      2.  Distribute the DDN networks randomly across the two
+          Mailbridges.
+
+      3.  Let the DDN administration inform the NSFNET which networks
+          on the DDN are closer to a specific Mailbridge so that the
+          particular Mailbridge would accept these networks at a lower
+          metric.  The second Mailbridge would then function as a backup
+          path.  From a NSFNET point of view, this would mean treating the
+          DDN like other NSFNET peer networks such as the NASA Science
+          network (NSN) or DOE's Energy Science Network (ESNET).
+
+   We are currently using alternative (2) as an interim solution.  At
+   this time, the DDN administration is having discussions with NSFNET
+   about moving to alternative (3), which would allow them control over
+   how the DDN networks would be treated in the NSFNET.
+
+3.2  Outbound announcement -- Routes announced from the NSFNET to the
+     DDN
+
+   The selection of metrics for announcements of NSFNET networks to the
+   DDN is controlled by the NSFNET.  The criteria for the metric
+   decisions is based on distances between the NSS, which introduces a
+   specific network into the NSFNET, and either one of the NSSs that has
+   a co-located Mailbridge.  In this context, the distance translates
+   into the hop count between NSSs in the NSFNET backbone.  For example,
+   the Princeton NSS is currently one hop away from the NSS co-located
+   with the Mitre Mailbridge, but is three hops away from the NSS with
+   the NASA-Ames Mailbridge.  Therefore, in the case of networks with
+   primary paths via the Princeton NSS, the Mitre Mailbridge will
+   receive the announcements for those networks at a lower metric than
+   the NASA-Ames Mailbridge.  This means that the traffic from the DDN
+   to networks connected to the Princeton NSS will be routed through the
+   Mailbridge at Mitre to the College Park NSS and then through the
+   Princeton NSS to its final destination.  This will guarantee that
+   traffic entering the NSFNET from the DDN will take the shortest path
+   to its NSFNET destination under normal operating conditions.
+
+3.3  Administrative aspects
+
+   Any of the networks connected via the NSFNET can be provided with the
+   connectivity to the DDN via the NSFNET upon request from the mid-
+   level network through which the specific network is connected.
+
+   For networks that do not have a DDN connection other than via NSFNET,
+   the NSFNET will announce the nets via one of the Mailbridges with a
+
+
+
+Yu & Braun                                                      [Page 5]
+
+RFC 1133         Routing between the NSFNET and the DDN    November 1989
+
+
+   low metric to create a primary path (e.g., metric "1") and via the
+   second Mailbridge as a secondary path (e.g., metric "3").  For
+   networks that have their own DDN connection and wish to use the
+   NSFNET as a backup connection to DDN, the NSFNET will announce those
+   networks via the two Mailbridges at higher metrics.
+
+   The mid-level networks need to make a specific request if they want
+   client networks to be announced to the DDN via the NSFNET. Those
+   requests need to state whether this would be a primary connection for
+   the specific networks.  If the request is for a fallback connection,
+   it needs to state the existing metrics in use for announcements of
+   the network to the DDN.
+
+4.  Shortcomings of the current NSFNET/DDN interconnection routing
+
+   The current setup makes full use of the two Mailbridges that connect
+   to the NSFNET directly, with regard to redundancy and load sharing.
+   However, with regard to performance optimization, such as packet
+   propagation delay between source/destination pairs located on
+   disjoint peer networks, there are some shortcomings.  These
+   shortcomings are not easy to overcome because of the limitations of
+   the current architecture.  However, it is a worthwhile topic for
+   discussion to aid future improvements.
+
+   To make the discussion easier, the following assumptions and
+   terminology will be used:
+
+      The NSFNET is viewed as a cloud and so is the DDN.  The two have
+      two connections, one at east coast and one at west coast.
+
+      mb-east -- the Mailbridge at Mitre
+
+      mb-west -- the Mailbridge at Ames
+
+      NSS-east -- the NSS egp peer with mb-east
+
+      NSS-west -- the NSS egp peer with mb-west
+
+      DDN.east-net -- networks connected to DDN and physically closer to
+                      mb-east
+
+      DDN.west-net -- networks connected to DDN and physically closer to
+                      mb-west
+
+      NSF.east-net -- networks connected to NSFNET and physically closer
+                      to NSS-east
+
+      NSF.west-net -- networks connected to NSFNET and physically closer
+
+
+
+Yu & Braun                                                      [Page 6]
+
+RFC 1133         Routing between the NSFNET and the DDN    November 1989
+
+
+                      to NSS-west
+
+   The traffic between NSFNET<->DDN will fall into the following
+   patterns:
+
+      a) NSF.east-net <-> DDN.east-net or
+         NSF.west-net <-> DDN.west-net
+
+      b) NSF.east-net <-> DDN.west-net or
+         NSF.west-net <-> DDN.east-net
+
+   The ideal traffic path for a) and b) should be as follows:
+
+   For traffic pattern a)
+
+        NSF.east-net<-->NSS.east<-->mb-east<-->DDN.east-net
+
+   or
+
+        NSF.west-net<-->NSS.west<-->mb-west<-->DDN.west-net
+
+   For traffic pattern b)
+
+        NSF.east-net-*->NSS.west-->mb-west-->DDN.west-net-**->mb-east
+                                                                    |
+                                              NSF.east-net<--NSS-east
+
+   or
+
+        NSF.west-net-*->NSS.east-->mb-east-->DDN.east-net-**->mb-west
+                                                                    |
+                                              NSF.west-net<--NSS-west
+
+
+   Note:
+
+        -*-> is used to indicate traffic transcontinentally traversing
+        the NSFNET backbone
+
+        -**-> is used to indicate traffic transcontinentally traversing
+        the DDN backbone
+
+        The traffic for a) will transcontinentally traverse NEITHER the
+        NSFNET backbone, NOR the DDN backbone.
+
+        The traffic for b) will transcontinentally traverse NSFNET once
+        and DDN once and only once for each.
+
+
+
+
+Yu & Braun                                                      [Page 7]
+
+RFC 1133         Routing between the NSFNET and the DDN    November 1989
+
+
+   For the current set up,
+
+   The traffic path for pattern a) would have chances to
+   transcontinentally traverse both NSFNET and DDN.
+
+   The traffic path for pattern b) would have chances to
+   transcontinentally traverse the DDN in both directions.
+
+   To achieve the ideal traffic path it requires the NSFNET to implement
+   (3) as stated above, i.e., to treat the DDN like other NSFNET peer or
+   mid-level networks.  As mentioned before, discussions between NSFNET
+   and DDN people are underway and the DDN is considering providing the
+   NSFNET with the required information to accomplish the outlined goals
+   in the near future.
+
+   At such time as this is accomplished, it will reduce the likelihood
+   of packet traffic unnecessarily traversing national backbones.
+
+   One of the best ways to optimize the traffic between two peer
+   networks, not necessary limited to the NSFNET and the DDN, is to try
+   to avoid letting traffic traverse a backbone with a comparatively
+   slower speed and/or a backbone with a significantly larger diameter
+   network.  For example, in the case of traffic between the NSFNET and
+   the DDN, the NSFNET has a T1 backbone and a maximum diameter of three
+   hops, while the DDN is a relatively slow network running largely at
+   56Kbps.  In this case the overall performance would be better if
+   traffic would traverse the DDN as little as possible, i.e., whenever
+   the traffic has to reach a destination network outside of the DDN, it
+   should find the closest Mailbridge to exit the DDN.
+
+   The current architecture employed for DDN routing is not able to
+   accomplish this.  Firstly, the technology is designed based on a core
+   model.  It does not expect a single network to be announced by
+   multiple places.  An example for multiple announcements could be two
+   NSSs announcing a single network number to the two Mailbridges at
+   their different locations.  Secondly, the way all the existing
+   Mailbridges exchange routing information among themselves is done via
+   a protocol similar to EGP, and the information is then distributed
+   via EGP to the DDN-external networks.  In this case the physical
+   distance information and locations of network numbers is lost and
+   neither the Mailbridges nor the external gateways will be able to do
+   path optimization based on physical distance and/or propagation
+   delay.  This is not easy to change, as in the DDN the link level
+   routing information is decoupled from the IP level routing, i.e., the
+   IP level routing has no information about topology of the physical
+   infrastructure.  Thus, even if an external gateway to a DDN network
+   were to learn a particular network route from two Mailbridges, it
+   would not be able to favor one over the other DDN exit point based on
+
+
+
+Yu & Braun                                                      [Page 8]
+
+RFC 1133         Routing between the NSFNET and the DDN    November 1989
+
+
+   the distance to the respective Mailbridge.
+
+5.  Conclusions
+
+   While recent changes in the interconnection architecture between the
+   NSFNET and DDN peer networks have resulted in significant performance
+   and reliability improvements, there are still possibilities for
+   further improvements and rationalization of this inter-peer network
+   routing.  However, to accomplish this it would most likely require
+   significant architectural changes within the DDN.
+
+6.  References
+
+  [1]  Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
+       Backbone", RFC 1092, IBM Research, February 1989.
+
+  [2]  Braun, H-W., "The NSFNET Routing Architecture", RFC 1093,
+       Merit/NSFNET Project, February 1989.
+
+  [3]  Collins, M., and R. Nitzan, "ESNET Routing", DRAFT Version 1.0,
+       LLNL, May 1989.
+
+  [4]  Braun, H-W., "Models of Policy Based Routing," RFC 1104,
+       Merit/NSFNET Project, February 1989.
+
+Security Considerations
+
+   Security issues are not addressed in this memo.
+
+Authors' Addresses
+
+   Jessica (Jie Yun) Yu
+   Merit Computer Network
+   1075 Beal Avenue
+   Ann Arbor, Michigan 48109
+
+   Telephone:      313 936-2655
+   Fax:            313 747-3745
+   EMail:          jyy@merit.edu
+
+   Hans-Werner Braun
+   Merit Computer Network
+   1075 Beal Avenue
+   Ann Arbor, Michigan 48109
+
+   Telephone:      313 763-4897
+   Fax:            313 747-3745
+   EMail:          hwb@merit.edu
+
+
+
+Yu & Braun                                                      [Page 9]
+
+RFC 1133         Routing between the NSFNET and the DDN    November 1989
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu & Braun                                                     [Page 10]
+
\ No newline at end of file