doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc1222.txt b/doc/rfc/rfc1222.txt
new file mode 100644
index 0000000..639cd8d
--- /dev/null
+++ b/doc/rfc/rfc1222.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                         H-W. Braun
+Request for Comments: 1222                San Diego Supercomputer Center
+                                                              Y. Rekhter
+                                         IBM T.J. Watson Research Center
+                                                                May 1991
+
+
+               Advancing the NSFNET Routing Architecture
+
+Status of this Memo
+
+   This RFC suggests improvements in the NSFNET routing architecture to
+   accommodate a more flexible interface to the Backbone clients.  This
+   memo provides information for the Internet community.  It does not
+   specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Introduction
+
+   This memo describes the history of NSFNET Backbone routing and
+   outlines two suggested phases for further evolution of the Backbone's
+   routing interface.  The intent is to provide a more flexible
+   interface for NSFNET Backbone service subscribers, by providing an
+   attachment option that is simpler and lower-cost than the current
+   one.
+
+Acknowledgements
+
+   The authors would like to thank Scott Brim (Cornell University),
+   Bilal Chinoy (Merit), Elise Gerich (Merit), Paul Love (SDSC), Steve
+   Wolff (NSF), Bob Braden (ISI), and Joyce K. Reynolds (ISI) for their
+   review and constructive comments.
+
+1. NSFNET Phase 1 Routing Architecture
+
+   In the first phase of the NSFNET Backbone, a 56Kbps infrastructure
+   utilized routers based on Fuzzball software [2].  The Phase 1
+   Backbone used the Hello Protocol for interior routing.  At the
+   periphery of the Backbone, the client networks were typically
+   connected by using a gatedaemon ("gated") interface to translate
+   between the Backbone's Hello Protocol and the interior gateway
+   protocol (IGP) of the mid-level network.
+
+   Mid-level networks primarily used the Routing Information Protocol
+   (RIP) [3] for their IGP.  The gatedaemon system acted as an interface
+   between the Hello and RIP environments.  The overall appearance was
+   that the Backbone, mid-level networks, and the campus networks formed
+   a single routing system in which information was freely exchanged.
+
+
+
+Braun & Rekhter                                                 [Page 1]
+
+RFC 1222       Advancing the NSFNET Routing Architecture        May 1991
+
+
+   Network metrics were translated among the three network levels
+   (backbone, mid-level networks, and campuses).
+
+   With the development of the gatedaemon, sites were able to introduce
+   filtering based on IP network numbers.  This process was controlled
+   by the staff at each individual site.
+
+   Once specific network routes were learned, the infrastructure
+   forwarded metric changes throughout the interconnected network. The
+   end-result was that a metric fluctuation on one end of the
+   interconnected network could permeate all the way to the other end,
+   crossing multiple network administrations.  The frequency of metric
+   fluctuations within the Backbone itself was further increased when
+   event-driven updates (e.g., metric changes) were introduced.  Later,
+   damping of the event driven updates lessened their frequency, but the
+   overall routing environment still appeared to be quite unstable.
+
+   Given that only limited tools and protocols were available to
+   engineer the flow of dynamic routing information, it was fairly easy
+   for routing loops to form.  This was amplified as the topology became
+   more fully connected without insulation of routing components from
+   each other.
+
+   All six nodes of the Phase 1 Backbone were located at client sites,
+   specifically NSF funded supercomputer centers.
+
+
+2. NSFNET Phase 2 Routing Architecture
+
+   The routing architecture for the second phase of the NSFNET Backbone,
+   implemented on T1 (1.5Mbps) lines, focused on the lessons learned in
+   the first NSFNET phase.  This resulted in a strong decoupling of the
+   IGP environments of the backbone network and its attached clients
+   [5].  Specifically, each of the administrative entities was able to
+   use its own IGP in any way appropriate for the specific network.  The
+   interface between the backbone network and its attached client was
+   built by means of exterior routing, initially via the Exterior
+   Gateway Protocol (EGP) [1,4].
+
+   EGP improved provided routing isolation in two ways.  First, EGP
+   signals only up/down transitions for individual network numbers, not
+   the fluctuations of metrics (with the exception of metric acceptance
+   of local relevance to a single Nodal Switching System (NSS) only for
+   inbound routing information, in the case of multiple EGP peers at a
+   NSS).  Second, it allowed engineering of the dynamic distribution of
+   routing information.  That is, primary, secondary, etc., paths can be
+   determined, as long as dynamic externally learned routing information
+   is available.  This allows creation of a spanning tree routing
+
+
+
+Braun & Rekhter                                                 [Page 2]
+
+RFC 1222       Advancing the NSFNET Routing Architecture        May 1991
+
+
+   topology, satisfying the constraints of EGP.
+
+   The pre-engineering of routes is accomplished by means of a routing
+   configuration database that is centrally controlled and created, with
+   a subsequent distribution of individual configuration information to
+   all the NSFNET Backbone nodes.  A computer controlled central system
+   ensures the correctness of the database prior to its distribution to
+   the nodes.
+
+   All nodes of the 1.5Mbps NSFNET Backbone (currently fourteen) are
+   located at client sites, such as NSF funded supercomputer centers and
+   mid-level network attachment points.
+
+3. T3 Phase of the NSFNET Backbone
+
+   The T3 (45Mbps) phase of the NSFNET Backbone is implemented by means
+   of a new architectural model, in which the principal communication
+   nodes (core nodes) are co-located with major phone company switching
+   facilities.  Those co-located nodes then form a two-dimensional
+   networking infrastructure "cloud".  Individual sites are connected
+   via exterior nodes (E-NSS) and typically have a single T3 access line
+   to a core node (C-NSS).  That is, an exterior node is physically at
+   the service subscriber site.
+
+   With respect to routing, this structure is invisible to client sites,
+   as the routing interface uses the same techniques as the T1 NSFNET
+   Backbone.  The two backbones will remain independent infrastructures,
+   overlaying each other and interconnected by exterior routing, and the
+   T1 Backbone will eventually be phased out as a separate network.
+
+4. A Near-term Routing Alternative
+
+   The experience with the T1/T3 NSFNET routing demonstrated clear
+   advantages of this routing architecture in which the whole
+   infrastructure is strongly compartmentalized.  Previous experience
+   also showed that the architecture imposes certain obligations upon
+   the attached client networks.  Among them is the requirement that a
+   service subscriber must deploy its own routing protocol peer,
+   participating in the IGP of the service subscriber and connected via
+   a common subnet to the subscriber-site NSFNET node.  The router and
+   the NSFNET Backbone exchange routing information via an EGP or BGP
+   [7] session.
+
+   The drawbacks imposed by this requirement will become more obvious
+   with the transition to the new architecture that is employed by the
+   T3 phase of the NSFNET Backbone.  This will allow rapid expansion to
+   many and smaller sites for which a very simple routing interface may
+   be needed.
+
+
+
+Braun & Rekhter                                                 [Page 3]
+
+RFC 1222       Advancing the NSFNET Routing Architecture        May 1991
+
+
+   We strongly believe that separating the routing of the service
+   subscriber from the NSFNET Backbone routing via some kind of EGP is
+   the correct routing architecture.  However, it should not be
+   necessary to translate this architecture into a requirement for each
+   service subscriber to install and maintain additional equipment, or
+   for the subscriber to deal with more complicated routing
+   environments.  In other words, while maintaining that the concept of
+   routing isolation is correct, we view the present implementation of
+   the concept as more restrictive than necessary.
+
+   An alternative implementation of this concept may be realized by
+   separating the requirement for an EGP/BGP session, as the mechanism
+   for exchanging routing information between the service subscriber
+   network and the backbone, from the actual equipment that has to be
+   deployed and maintained to support such a requirement.  The only
+   essential requirement for routing isolation is the presence of two
+   logical routing entities.  The first logical entity participates in
+   the service subscriber's IGP, the second logical entity participates
+   in the NSFNET Backbone IGP, and the two logical entities exchange
+   information with each other by means of inter-domain mechanisms.  We
+   suggest that these two logical entities could exist within a single
+   physical entity.
+
+   In terms of implementation, this would be no different from a
+   gatedaemon system interfacing with the previous 56Kbps NSFNET
+   Backbone from the regional clients, except that we want to continue
+   the strong routing and administrative control that decouple the two
+   IGP domains.  Retaining an inter-domain mechanism (e.g., BGP) to
+   connect the two IGP domains within the single physical entity allows
+   the use of a well defined and understood interface.  At the same
+   time, care must be taken in the implementation that the two daemons
+   will not simultaneously interact with the system kernel in unwanted
+   ways.
+
+   The possibility of interfacing two IGP domains within a single router
+   has also been noted in [8].  For the NSFNET Backbone case, we propose
+   in addition to retain strong firewalls between the IGP domains.  The
+   IGP information would need to be tagged with exterior domain
+   information at its entry into the other IGP.  It would also be
+   important to allow distributed control of the configuration.  The
+   NSFNET Backbone organization and the provider of the attached client
+   network are each responsible for the integrity of their own routing
+   information.
+
+   An example implementation might be a single routing engine that
+   executed two instances of routing daemons.  In the NSFNET Backbone
+   case, one of the daemons would participate in the service
+   subscriber's IGP, and the other would participate in the NSFNET
+
+
+
+Braun & Rekhter                                                 [Page 4]
+
+RFC 1222       Advancing the NSFNET Routing Architecture        May 1991
+
+
+   Backbone IGP.  These two instances could converse with each other by
+   running EGP/BGP via a local loopback mechanism or internal IPC.  In
+   the NSFNET Backbone implementation, the NSFNET T1 E-PSP or T3 E-NSS
+   are UNIX machines, so the local loopback interface (lo0) of the UNIX
+   operating system may be used.
+
+   Putting both entities into the same physical machine means that the
+   E-PSP/E-NSS would participate in the regional IGP on its exterior
+   interface.  We would still envision the Ethernet attachment to be the
+   demarcation point for the administrative control and operational
+   responsibility.  However, the regional client could provide the
+   configuration information for the routing daemon that interfaced to
+   the regional IGP, allowing the regional to continue to exercise
+   control over the introduction of routing information into its IGP.
+
+5. Long-Term Alternatives
+
+   As technology employed by the NSFNET Backbone evolves, one may
+   envision the demarcation line between the Backbone and the service
+   subscribers moving in the direction of the "C-NSS cloud", so that the
+   NSFNET IGP will be confined to the C-NSS, while the E-NSS will be a
+   full participant in the IGP of the service subscriber.
+
+   Clearly, one of the major prerequisites for such an evolution is the
+   ability for operational management of the physical medium connecting
+   a C-NSS with an E-NSS by two different administrative entities (i.e.,
+   the NSFNET Backbone provider as well as the service subscriber).  It
+   will also have to be manageable enough to be comparable in ease of
+   use to an Ethernet interface, as a well-defined demarcation point.
+
+   The evolution of the Point-to-Point Protocol, as well as a
+   significantly enhanced capability for managing serial lines via
+   standard network management protocols, will clearly help.  This may
+   not be the complete answer, as a variety of equipment is used on
+   serial lines, making it difficult to isolate a hardware problem.
+   Similar issues may arise for future demarcation interfaces to
+   Internet infrastructure (e.g., SMDS interfaces).
+
+   In summary, there is an opportunity to simplify the management,
+   administration, and exchange of routing information by collapsing the
+   number of physical entities involved.
+
+6. References
+
+   [1] Mills, D., "Exterior Gateway Protocol Formal Specification", RFC
+       904, BBN, April 1984.
+
+   [2] Mills, D., and H-W. Braun, "The NSFNET Backbone Network", SIGCOMM
+
+
+
+Braun & Rekhter                                                 [Page 5]
+
+RFC 1222       Advancing the NSFNET Routing Architecture        May 1991
+
+
+       1987, August 1987.
+
+   [3] Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers
+       University, June 1988.
+
+   [4] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
+       Backbone", RFC 1092, IBM T.J. Watson Research Center, February
+       1989.
+
+   [5] Braun, H-W., "The NSFNET Routing Architecture", RFC 1093,
+       Merit/NSFNET, February 1989.
+
+   [6] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
+       Merit/NSFNET, June 1989.
+
+   [7] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol (BGP)",
+       RFC 1163, cisco Systems, IBM T.J. Watson Research Center, June
+       1990.
+
+   [8] Almquist, P., "Requirements for Internet IP Routers", to be
+       published as a RFC.
+
+7.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+8. Authors' Addresses
+
+   Hans-Werner Braun
+   San Diego Supercomputer Center
+   P.O. Box 85608
+   La Jolla, CA 92186-9784
+
+   Phone: (619) 534-5035
+   Fax:   (619) 534-5113
+
+   EMail: HWB@SDSC.EDU
+
+   Yakov Rekhter
+   T.J. Watson Research Center
+   IBM Corporation
+   P.O. Box 218
+   Yorktown Heights, NY  10598
+
+   Phone: (914) 945-3896
+
+   EMail: Yakov@Watson.IBM.COM
+
+
+
+
+Braun & Rekhter                                                 [Page 6]
+
\ No newline at end of file