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

📄 rfc975.txt

📁 RFC 相关的技术文档
💻 TXT
📖 第 1 页 / 共 2 页
字号:
Network Working Group                                        D. L. MillsRequest for Comments: 975                               M/A-COM Linkabit                                                           February 1986                       Autonomous ConfederationsStatus 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 autonomousMills                                                           [Page 1]RFC 975                                                    February 1986Autonomous 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 UpdateMills                                                           [Page 2]RFC 975                                                    February 1986Autonomous 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 1986Autonomous 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 1986Autonomous Confederations2.  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 inMills                                                           [Page 5]

⌨️ 快捷键说明

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