rfc1126.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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]

RFC 1126            Inter-Autonomous System Routing         October 1989


   determines the boundary gateway which will serve as the exit gateway.
   This may require that the entrance boundary gateway add a source
   route to the packet, or encapsulate the packet in another level of IP
   or gateway-to-gateway header.  This allows boundary gateways to
   forward data traffic using the appropriate tunnelling technique.

   Finally, with solution (3), the interior gateways have some knowledge
   of Inter-AS Routing.  At a minimum, the interior gateways would need
   to know the identity of each boundary gateway, the address(es) that
   can be reached by that gateway, and the Inter-AS metric associated
   with the route to that address(es).  If the IARP allows for separate
   routing for multiple TOS classes, then the information that the
   interior gateways need to know includes a separate Inter-AS metric
   for each TOS class.  The Inter-AS metrics are necessary to allow
   gateways to choose among multiple possible exit boundary gateways.
   In general, it is not necessary for the Inter-AS metrics to have any
   relationship with the metric used within an AS for interior routing.
   The interior gateways do not need to know how to interpret the
   exterior metrics, except to know that each metric is to be
   interpreted as an unsigned integer and a lesser value is preferable
   to a greater value.  It would be possible, but not necessary, for the
   interior gateways to have full knowledge of the IARP.

   It is not necessary for the Inter-AS Routing architecture to specify
   which of these solutions are to be used for any particular AS.
   Rather, it is possible for individual AS's to choose which scheme or
   combination of schemes to use.  Independence of the IARP from the
   internal operation of each AS implies that this decision be left up
   to the internal protocols used in each AS.  The IARP must be able to
   operate as if the boundary gateways were directly connected.

A.2.6.2  Forwarding of Data from the AS

   The scheme used for forwarding transit traffic across an AS also has
   implications for the forwarding of traffic which originates within an
   AS, but whose destination is reachable only from other AS's.  If
   either of solutions (1) or (2) in Section A.2.6.1 is followed, then
   it will be sufficient for an interior gateway to forward such traffic
   to any boundary gateway.  Greater efficiency may optionally be
   achieved in some cases by providing interior gateways with additional
   information which will allow them to choose the "best" boundary
   gateway in some sense.  If solution (3) is followed, then the
   information passed to interior gateways to allow them to forward
   transit traffic will also be sufficient to forward traffic
   originating within that AS.






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


A.2.6.3  Forwarding of Data to a Destination in the AS

   If a packet whose destination is reachable from an AS arrives at that
   AS, then it is desired that the interior routing protocol used in
   that AS be able to successfully deliver the packet without reliance
   on Inter-AS Routing.  This does not preclude that the Inter-AS
   Routing protocol will deal with partitioned AS's.

   An AS may have access control, security, and policy restrictions that
   restrict which data packets may enter or leave the AS. However, for
   any data packet which is allowed access to the AS, the AS is expected
   to deliver the packet to its destination without further restrictions
   between parts of the AS.  In this sense, the internal structure of
   the AS should not be visible to the IARP.

A.3  Policy Issues

   The interconnection of multiple heterogeneous networks and multiple
   heterogeneous autonomous systems owned and operated by multiple
   administrations into a single combined internet is a very complex
   task.  It is expected that the administrations associated with such
   an internet will wish to impose a variety of constraints on the
   operation of the internet.  Specifically, externally imposed routing
   constraints may include a variety of transit access control,
   administrative policy, and security constraints.

   Transit access control refers to those access control restrictions
   which an AS may impose to restrict which traffic the AS is willing to
   forward.  There are a large number of access control restrictions
   which one could envision being used.  For example, some AS's may wish
   to operate only as "non-transit" AS's, that is, they will only
   forward data traffic which either originates or terminates within
   that AS.  Other AS's may restrict transit traffic to datagrams which
   originate within a specified set of source hosts. Restrictions may
   require that datagrams be associated with specific applications (such
   as electronic mail traffic only), or that datagrams be associated
   with specific classes of users.

   Policy restrictions may allow either the source of datagrams, or the
   organization that is paying for transmission of a datagram, to limit
   which AS's the datagrams may transit.  For example, an organization
   may wish to specify that certain traffic originating within their AS
   should not transit any AS administered by its main competitor.

   Security restrictions on traffic relates to the official security
   classification level of traffic.  As an example, an AS may specify
   that all classified traffic is not allowed to leave its AS.




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


   The main problem with producing a routing scheme which is sensitive
   to transit access control, administrative policy, and security
   constraints is the associated potential for exponential growth of
   routes.  For example, suppose that there are 20 packets arriving at a
   particular gateway, each for the same destination, but subject to a
   different combination of access control, policy, and security
   constraints.  It is possible that all 20 packets would need to follow
   different routes to the destination.

   This explosive growth of routes leads to the question: "Is it
   practically feasible to deal with complete general external routing
   constraints?" One approach would allow only a smaller subset of
   constraints, chosen to provide some useful level of control while
   allowing minimal impact on the routing protocol.  Further work is
   needed to determine the feasibility of this approach.

   There is another problem with dealing with transit access control,
   policy, and security restrictions in a fully general way.
   Specifically, it is not clear just what the total set of possible
   restrictions should be.  Efforts to study this issue are currently
   underway, but are not expected to produce definitive results within a
   short to medium time frame.  It is therefore not practical to wait
   for this effort to be finished before defining the next generation of
   Inter-AS Routing.

A.4  Service Features

   The following paragraphs discuss issues concerning the services an
   Inter-AS Routing Protocol may provide.  This is not a complete list
   of service issues but does address many of those services which are
   of concern to a significant portion of the community.

A.4.1  Cost on Toll Networks

   Consideration must be given to the use of routing protocols with toll
   (i.e., charge) networks.  Although uncommon in the Internet at the
   moment, they will become more common in the future, and thought needs
   to be given to allowing their inclusion in an efficient and effective
   manner.

   There are two areas in which concerns of cost intrude.  First,
   provision must be made to include in the routing information
   distributed throughout the system the information that certain links
   cost money, so that traffic patterns may account for the cost.
   Second, the actual operation of the algorithm, in terms of the
   messages that must be exchanged to operate the algorithm, must
   recognize that fact that on certain links, the exchange may have an
   associated cost which must be taken into account.  These areas often



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


   involve policy questions on the part of the user.  It is a
   requirement of the algorithm that facilities be available to allow
   different groups to answer these questions in different ways.  The
   first area is related to type-of-service routing, and is discussed in
   Section A.4.2.  The second area is discussed below.

   Previous attempts at providing these sorts of controls were
   incomplete because they were not thought through fully; a new effort
   must avoid these pitfalls.  For instance, even though the Hello rate
   in EGP may be adjusted, turning the rate down too low (to control the
   costs) could cause the route to be dropped from databases through
   timeout.

   In a large internet, changes will be occurring constantly; a
   simplistic mechanism might mean that a site which is only connected
   by toll networks has to either accept having an old picture of the
   network, or spend more to keep a more current picture of things.
   However, that is not necessarily the case if incomplete knowledge and
   cache-based techniques are used more. For instance, if a site
   connected only by toll links keeps an incomplete or less up-to-date
   map of the situation, an agreement with a neighbor which does not
   labor under these restrictions might allow it to get up-to-date
   information only when needed.

A.4.2  Type-of-Service Routing

   The need for type-of-service (TOS) has been increasing as networks
   become more heterogeneous in physical channel components, high-level
   applications, and administrative management.  For instance, some
   recently installed fiber cables provide abundant communication
   bandwidths, while old narrow-band channels will still be with us for
   a long time period.  Electronic mail traffic tolerates delivery
   delays and low throughput.  New image transmissions are coming up;
   these require high bandwidths but are not effected by a few bit
   errors.  Furthermore, some networks may soon install accounting
   functions to charge users, while others may still provide free
   services.

   Considering the long life span of a new routing architecture, it is