⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc975.txt

📁 RFC 的详细文档!
💻 TXT
📖 第 1 页 / 共 2 页
字号:


Network Working Group                                        D. L. Mills
Request for Comments: 975                               M/A-COM Linkabit
                                                           February 1986

                       Autonomous Confederations


Status of This Memo

   This RFC proposes certain enhancements of the Exterior Gateway
   Protocol (EGP) to support a simple, multiple-level routing capability
   while preserving the robustness features of the current EGP model.
   It requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

Overview

   The enhancements, which do not require retrofits in existing
   implementations in order to interoperate with enhanced
   implementations, in effect generalize the concept of core system to
   include multiple communities of autonomous systems, called autonomous
   confederations. Autonomous confederations maintain a higher degree of
   mutual trust than that assumed between autonomous systems in general,
   including reasonable protection against routing loops between the
   member systems, but allow the routing restrictions of the current EGP
   model to be relaxed.

   The enhancements involve the "hop count" or distance field of the EGP
   Update message, the interpretation of which is not covered by the
   current EGP model.  This field is given a special interpretation
   within each autonomous confederation to support up to three levels of
   routing, one within the autonomous system, a second within the
   autonomous confederation and an optional third within the universe of
   confederations.

1.  Introduction and Background

   The historical development of Internet exterior-gateway routing
   algorithms began with a rather rigid and restricted topological model
   which emphasized robustness and stability at the expense of routing
   dynamics and flexibility.  Evolution of robust and dynamic routing
   algorithms has since proved extraordinarily difficult, probably due
   more to varying perceptions of service requirements than to
   engineering problems.

   The original exterior-gateway model suggested in RFC-827 [1] and
   subsequently refined in RFC-888 [2] severely restricted the Internet
   topology essentially to a tree structure with root represented by the
   BBN-developed "core" gateway system.  The most important
   characteristic of the model was that debilitating resource-consuming
   routing loops between clusters of gateways (called autonomous


Mills                                                           [Page 1]



RFC 975                                                    February 1986
Autonomous Confederations


   systems) could not occur in a tree-structured topology.  However, the
   administrative and enforcement difficulties involved, not to mention
   the performance liabilities, made widespread implementation
   impractical.

   1.1.  The Exterior Gateway Protocol

      Requirements for near-term interoperability between the BBN core
      gateways and the remainder of the gateway population implemented
      by other organizations required that an interim protocol be
      developed with the capability of exchanging reachability
      information, but not necessarily the capability to function as a
      true routing algorithm. This protocol is called the Exterior
      Gateway Protocol (EGP) and is documented in RFC-904 [3].

      EGP was not designed as a routing algorithm, since no agreement
      could be reached on a trusted, common metric.  However, EGP was
      designed to provide high-quality reachability information, both
      about neighbor gateways and about routes to non-neighbor gateways.
      At the present state of development, dynamic routes are computed
      only by the core system and provided to non-core gateways using
      EGP only as an interface mechanism.  Non-core gateways can provide
      routes to the core system and even to other non-core gateways, but
      cannot pass on "third-party" routes computed using data received
      from other gateways.

      As operational experience with EGP has accumulated, it has become
      clear that a more decentralized dynamic routing capability is
      needed in order to avoid resource-consuming suboptimal routes.  In
      addition, there has long been resistance to the a-priori
      assumption of a single core system, with implications of
      suboptimal performance, administrative problems, impossible
      enforcement and possible subversion.  Whether or not this
      resistance is real or justified, the important technical question
      remains whether a more dynamic, distributed approach is possible
      without significantly diluting stability and robustness.

      This document proposes certain enhancements of EGP which
      generalize the concept of core system to include multiple
      communities of autonomous systems, called autonomous
      confederations.  Autonomous confederations maintain a higher
      degree of mutual trust than that assumed between autonomous
      systems in general, including reasonable protection against
      routing loops between the member systems.  The enhancements
      involve the "hop count" or distance field of the EGP Update




Mills                                                           [Page 2]



RFC 975                                                    February 1986
Autonomous Confederations


      message, which is given a special interpretation as described
      later.  Note that the interpretation of this field is not
      specified in RFC-904, but is left as a matter for further study.

      The interpretation of the distance field involves three levels of
      metrics, in which the lowest level is available to the interior
      gateway protocol (IGP) of the autonomous system itself to extend
      the interior routes to the autonomous system boundary.  The next
      higher level selects preferred routes within the autonomous system
      to those outside, while the third and highest selects preferred
      routes within the autonomous confederation to those outside.

      The proposed model is believed compatible with the current
      specifications and practices used in the Internet.  In fact, the
      entire present conglomeration of autonomous systems, including the
      core system, can be represented as a single autonomous
      confederation, with new confederations being formed from existing
      and new systems as necessary.

   1.2.  Routing Restrictions

      It was the intent in RFC-904 that the stipulated routing
      restrictions superceded all previous documents, including RFC-827
      and RFC-888.  The notion that a non-core gateway must not pass on
      third-party information was suggested in planning meetings that
      occured after the previous documents had been published and before
      RFC-904 was finalized.  This effectively obsoletes prior notions
      of "stub" or any other asymmetry other than the third-party rule.

      Thus, the only restrictions placed on a non-core gateway is that
      in its EGP messages (a) a gateway can be listed only if it belongs
      to the same autonomous system (internal neighbor) and (b) a net
      can be listed only if it is reachable via gateways belonging to
      that system.  There are no other restrictions, overt or implied.
      The specification does not address the design of the core system
      or its gateways.

      The restrictions imply that, to insure full connectivity, every
      non-core gateway must run EGP with a core gateway.  Since the
      present core-gateway implementation disallows other gateways on
      EGP-neighbor paths, this further implies that every non-core
      gateway must share a net in common with at least one core gateway.

      Note that there is no a-priori prohibition on using EGP as an IGP,
      or even on using EGP with a gateway of another non-core system,




Mills                                                           [Page 3]



RFC 975                                                    February 1986
Autonomous Confederations


      providing that the third-party rule is observed.  If a gateway in
      each system ran EGP with a gateway in every other system, the
      notion of core system would be unneccessary and superflous.

      At one time during the evolution of the EGP model a strict
      hierarchical topology (tree structure) of autonomous systems was
      required, but this is not the case now.  At one time it was
      forbidden for two nets to be connected by gateways of two or more
      systems, but this is not the case now.  Autonomous systems are
      sets of gateways, not nets or hosts, so that a given net or host
      can be reachable via more than one system;  however, every gateway
      belongs to exactly one system.

   1.3.  Examples and Problems

      Consider the common case of two local-area nets A and B connected
      to the ARPANET by gateways of different systems.  Now assume A and
      B are connected to each other by a gateway A-B belonging to the
      same system as the A-ARPANET gateway, which could then list itself
      and both the A and B nets in EGP messages sent to any other
      gateway, since both are now reachable in its system.  However, the
      B-ARPANET gateway could list itself and only the B net, since the
      A-B gateway is not in its system.

      In principle, we could assume the existence of a second gateway
      B-A belonging to the same system as the B-ARPANET gateway, which
      would entitle it to list the A net as well;  however, it may be
      easier for both systems to sign a treaty and consider the A-B
      gateway under joint administration.  The implementation of the
      treaty may not be trivial, however, since the joint gateway must
      appear to other gateways as two distinct gateways, each with its
      own autonomous-system number.

      Another case occurs when for some reason or other a system has no
      path to a core gateway other than via another non-core system.
      Consider a third local-are net C, together with gateway C-A
      belonging to a system other than the A-ARPANET and B-ARPANET
      gateways.  According to the restrictions above, gateway C-A could
      list net C in EGP messages sent to A-ARPANET, while A-ARPANET
      could list ARPANET in messages sent to C-A, but not other nets
      which it may learn about from the core.  Thus, gateway C-A cannot
      acquire full routing information unless it runs EGP directly with
      a core gateway.






Mills                                                           [Page 4]



RFC 975                                                    February 1986
Autonomous Confederations


2.  Autonomous Systems and Confederations

   The second example above illustrates the need for a mechanism in
   which arbitrary routing information can be exchanged between non-core
   gateways without degrading the degree of robustness relative to a
   mutually agreed security model.  One way of doing this is is to
   extend the existing single-core autonomous-system model to include
   multiple core systems.  This requires both a topological model which
   can be used to define the scope of these systems together with a
   global, trusted metric that can be used to drive the routing
   computations.  An appropriate topological model is described in the
   next section, while an appropriate metric is suggested in the
   following section.

   2.1.  Topological Models

      An "autonomous system" consists of a set of gateways, each of
      which can reach any other gateway in the same system using paths
      via gateways only in that system.  The gateways of a system
      cooperatively maintain a routing data base using an interior
      gateway protocol (IGP) and a intra-system trusted routing
      mechanism of no further concern here.  The IGP is expected to
      include security mechanisms to insure that only gateways of the
      same system can acquire each other as neighbors.

      One or more gateways in an autonomous system can run EGP with one
      or more gateways in a neighboring system.  There is no restriction
      on the number or configuration of EGP neighbor paths, other than
      the requirement that each path involve only gateways of one system
      or the other and not intrude on a third system.  It is
      specifically not required that EGP neighbors share a common
      network, although most probably will.

      An "autonomous confederation" consists of a set of autonomous
      systems sharing a common security model;  that is, they trust each
      other to compute routes to other systems in the same
      confederation.  Each gateway in a confederation can reach any
      other gateway in the same confederation using paths only in that
      confederation.  Although there is no restriction on the number or
      configuration of EGP paths other than the above, it is expected
      that some mechanism be available so that potential EGP neighbors
      can discover whether they are in the same confederation.  This
      could be done by access-control lists, for example, or by
      partitioning the set of system numbers.

      A network is "directly reachable" from an autonomous system if a
      gateway in that system has an interface to it.  Every gateway in


Mills                                                           [Page 5]


⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -