rfc1126.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,403 行 · 第 1/5 页


RFC 1126            Inter-Autonomous System Routing         October 1989


5.  Considerations

   Although neither a specific goal nor a functional requirement,
   consideration must be given to the transition which will occur from
   the current operational routing environment to a new routing
   environment.  A coordinated effort among all participants of the
   Internet would be impractical considering the magnitude of such an
   undertaking.  Particularly, the issues of transitional coexistence,
   as opposed to phased upgrading between disjoint systems, should be
   addressed as a means to minimize the disruption of service.  Careful
   consideration should also be given to any required changes to hosts.
   It is very unlikely that all hosts could be changed, given historical
   precedence, their diversity and their large numbers.

Appendix - Issues in Inter-Autonomous Systems Routing

A.0  Acknowledgement

   This appendix is an edited version of the now defunct document
   entitled "Requirements for Inter-Autonomous Systems Routing", written
   by Ross Callon in conjunction with the members of the Open Routing
   Working Group.

A.1  Introduction

   The information and discussion contained here historically precedes
   that of the main document body and was a major influence on its
   content.  It is included here as a matter of reference and to provide
   insight into some of the many issues involved in inter-autonomous
   systems routing.

   The following definitions are utilized:

      Boundary Gateway

            A boundary gateway is any autonomous system gateway which
            has a network interface directly reachable from another
            autonomous system.  As a member of an autonomous system, a
            boundary gateway participates in the Interior Gateway
            Protocol and other protocols used for routing (and other
            purposes) between other gateways of this same autonomous
            system and between those networks directly reachable by this
            autonomous system.  A boundary gateway may also
            participate in an Inter-Autonomous System Routing Protocol.
            As a participant in the inter-autonomous system routing
            protocol, a boundary gateway interacts with other boundary
            gateways in other autonomous systems, either directly or
            indirectly, in support of the operation of the



Little                                                         [Page 11]

RFC 1126            Inter-Autonomous System Routing         October 1989


            Inter-Autonomous System Routing Protocol.

      Interior Gateway

            An interior gateway is any autonomous system gateway which
            is not a boundary gateway.  As such, an interior gateway
            does not have any network interfaces which are directly
            reachable by any other autonomous system.  An interior
            gateway is part of an autonomous system and, as such,
            takes part in the Interior Gateway Protocol and other
            protocols used in that autonomous system. However, an
            interior gateway does not directly exchange routing
            information with gateways in other autonomous systems via
            the Inter-Autonomous System Routing Protocol.

   The following acronyms are used:

      AS -- Autonomous System

            This document uses the current definition of "Autonomous
            System": a collection of cooperating gateways running a
            common interior routing protocol. This implies that networks
            and hosts may be reachable through one or more Autonomous
            Systems.

            NOTE: The current notion of "Autonomous System" implicitly
            assumes that each gateway will belong to exactly one AS.
            Extensions to allow gateways which belong to no AS's
            and/or gateways which belong to multiple AS's, are beyond
            the scope of this discussion. However, we do not preclude
            the possibility of considering such extensions in the
            future.

      IARP -- Inter-Autonomous System Routing Protocol

            This is the protocol used between boundary gateways for
            the purpose of routing between autonomous systems.

      IGP -- Interior Gateway Protocol

            This is the protocol used within an autonomous system for
            routing within that autonomous system.

A.2  Architectural Issues

   The architecture of an inter-autonomous system routing environment is
   mutually dependent with the notion of an Autonomous System. In
   general, the architecture should maximize independence of the



Little                                                         [Page 12]

RFC 1126            Inter-Autonomous System Routing         October 1989


   internals of an AS from the internals of other AS's, as well as from
   the inter-autonomous system routing protocols (IARP). This
   independence should allow technological and administrative
   differences among AS's as well as protection against propagation of
   misbehavior.  The following issues address ways to achieve
   interoperation and protection, and to meet certain performance
   criteria. We also put forth a set of minimal constraints to be
   imposed among Autonomous Systems, and between inter- and intra-AS
   functions.

A.2.1  IGP Behavior

   The IARP should be capable of tolerating an Autonomous System in
   which its IGP is unable to route packets, provides incorrect
   information, and exhibits unstable behavior.  Interfacing to such an
   ill-behaved AS should not produce global instabilities within the
   IARP and the IARP should localize any effects.  On the other hand,
   the IGP should provide a routing environment where the information
   and connectivity provided to the IARP from the IGP does not exhibit
   rapid and continual changes.  An Autonomous System therefore should
   appear as a relatively stable environment.

A.2.2  Independence of Autonomous Systems

   The IARP should not constrain any AS to require the use any one
   specific IGP.  This applies both to IGPs and potentially to any other
   internal protocols.  The architecture should also allow intra-AS
   routing and organizational structures to be hidden from inter-AS use.
   An Autonomous System should not be required to use any one specific
   type of linkage between boundary gateways within the AS.  However,
   there are some minimal constraints that gateways and the associated
   interior routing protocol within an AS must meet in order to be able
   to route Inter-AS traffic, as discussed in Section A.2.6.

A.2.3  General Topology

   The routing architecture should provide significant flexibility
   regarding the interconnection of AS's.  The specification of IARP
   should impose no inherent restriction on either interconnection
   configuration or information passing among autonomous systems. There
   may be administrative and policy limitations on the interconnection
   of AS's, and on the extent to which routing information and data
   traffic may be passed between AS's. However, there should be no
   inherent restrictions imposed by limitations in the design of the
   routing architecture.  The architecture should allow arbitrary
   topological interconnection of Autonomous Systems.  Propagation of
   routing information should not be restricted by the specification of
   the IARP.  For example, the restrictions imposed by the "core model"



Little                                                         [Page 13]

RFC 1126            Inter-Autonomous System Routing         October 1989


   used by EGP are not acceptable.

A.2.4  Routing Firewalls

   We expect AS's to have a certain amount of insulation from other
   AS's.  This protection should apply to both the adequacy and
   stability of routes produced by the routing scheme, and also to the
   amount of overhead traffic and other costs necessary to run the
   routing scheme.  There are several forms which these "routing
   firewalls" may take:

      -  An AS must be able to successfully route its own internal
         traffic in the face of arbitrary failures of other IGPs and the
         IARP.  In other words, the AS should be able to effectively
         shutout the rest of the world.

      -  The IARP should be able to operate correctly in the face of IGP
         failures.  In this case, correct operation is defined as
         recognizing that an AS has failed, and routing around it if
         possible (traffic to or from that AS may of course fail).

      -  In addition, problems in Inter-AS Routing should, as much as
         possible, be limited in the extent of their effect.

   Routing firewalls may be explicit, or may be inherent in the design
   of the algorithms.  We expect that both explicit and inherent
   firewalls will be utilized.  Examples of firewalls include:

      -  Separating Intra- and Inter-AS Routing to some extent
         isolates each of these from problems with the other.  Clearly
         defined interfaces between different modules/protocols provides
         some degree of protection.

      -  Access control restrictions may provide some degree of
         firewalls.  For example, some AS's may be non-transit (won't
         forward transit traffic).  Failures within such AS's may be
         prevented from affecting traffic not associated with that AS.

      -  Protocol design can help.  For example, with link state routing
         you can require that both ends must report a link before is may
         be regarded as up, thereby eliminating the possibility of a
         single node causing fictitious links.

      -  Finally, explicit firewalls may be employed using explicit
         configuration information.






Little                                                         [Page 14]

RFC 1126            Inter-Autonomous System Routing         October 1989


A.2.5  Boundary Gateways

   Boundary gateways will exchange Inter-AS Routing information with
   other boundary gateways using the IARP.  Each AS which is to take
   part in Inter-AS Routing will have one or more boundary gateways, of
   which one or more of these boundary gateways exchanges information
   with peer boundary gateways in other AS's.

   Information related to Inter-AS Routing may be passed between
   connected boundary gateways in different AS's.  Specific designated
   boundary gateways will therefore be required to understand the IARP.
   The external link between the boundary gateways may be accomplished
   by any kind of connectivity that can be modeled as a direct link
   between two gateways -- a LAN, an ARPANET, a satellite link, a
   dedicated line, and so on.

A.2.6  Minimal Constraints on the Autonomous System

   The architectural issues discussed here for inter-AS routing imply
   certain minimal functional constraints that an AS must satisfy in
   order to take part in the Inter-AS Routing scheme.  These minimal
   requirements are described in greater detail in this section. This
   list of functional constraints is not necessarily complete.

A.2.6.1  Internal Links between Boundary Gateways

   In those cases where an AS may act as a transit AS (i.e., may pass
   traffic for which neither the source nor the destination is in that
   AS), the gateways internal to that AS will need to know which
   boundary gateway is to serve as the exit gateway from that AS. There
   are several ways in which this may be accomplished:

      1. Boundary gateways are directly connected

      2. "Tunneling" (i) using source routing (ii) using encapsulation

      3. Interior gateways participate (i) limited participation (ii)
         fully general participation

   With solution (1), the boundary gateways in an AS are directly
   connected.  This eliminates the need for other gateways in the AS to
   have any knowledge of Inter-AS Routing.  Transit traffic is passed
   directly among the boundary gateways of the AS.

   With solution (2), transit traffic may traverse interior gateways,
   but these interior gateways are protected from any need to have
   knowledge about Inter-AS routes by means such as source routing or
   encapsulation.  The boundary gateway by which the packet enters an AS



Little                                                         [Page 15]