rfc1126.txt

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

A.5  Performance Issues

   The following paragraphs discuss issues related to the performance of
   an Inter-AS Routing Protocol.  This discussion addresses size as well
   as efficiency considerations.

A.5.1  Adaptive Routing

   It is necessary that the Inter-AS Routing scheme respond in a timely
   fashion to major network problems, such as the failure of specific
   network resources.  In this sense, Inter-AS Routing needs to use
   adaptive routing mechanisms similar to those commonly used within
   individual networks and AS's.  It is important that the adaptive
   routing mechanism chosen for Inter-AS Routing achieve rapid
   convergence following internet topological changes, with little or
   none of the serious convergence problems (such as "counting to
   infinity") that have been experienced in some existing dynamic
   routing protocols.

   The Inter-AS Routing scheme must provide stability of routes.  It is
   totally unacceptable for routes to vary on a frequent basis.  This
   requirement is not meant to limit the ability of the routing
   algorithm to react rapidly to major topological changes, such as the
   loss of connectivity between two AS's.  The need for adaptive routing
   does not imply any desire for load-based routing.

A.5.2  Large Internets

   One key question in terms of the targets is the maximum size of the
   Internet this algorithm is supposed to support.  To some degree, this
   is tied to the timeline for which this protocol is expected to be
   active.  However, it is necessary to have some size targets.
   Techniques that work at one order of size may be impractical in a
   system ten or twenty times larger.

   Over the past five years there has been an approximate doubling of
   the Internet each year.  In January 1988, there were more than 330
   operational networks and more than 700 network assigned numbers.
   Exact figures for the future growth rate of the Internet are
   difficult to predict accurately.  However, if this doubling trend
   continues, we would reach 10,000 nets sometime near January 1993.

   Taking a projection purely on the number of networks (the top level
   routing entity) may be overly conservative since the introduction and
   wide use of subnets has absorbed some growth, but will not continue
   to be able to do so.  In addition, there are plans being discussed
   that will continue or accelerate the current rate of growth.
   Nonetheless, the number of networks is very important because



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


   networks constitute the "top level entities" in the current
   addressing structure.

   The implications of the size parameter are fairly serious.  The
   current system has only one level of addressing above subnets. While
   it is possible to adjust certain parameters (for example, the
   unsolicited or unnecessary retransmission rate) to produce a larger
   but less robust system, other parameters (for example, the rate of
   change in the system) cannot be so adjusted.  This will provide
   eventual limits on the size of a system that can be dealt with in a
   flat address space.

   The exact size that necessitates moving from the current single-
   level system to a multi-level system is not clear.  Among the
   parameters which affect it are the assumed minimum speed of links in
   the system (faster links can allocate more bandwidth to routing
   traffic before it becomes obtrusive), speed and memory capacity of
   routing nodes (needed to store and process routing data), rate at
   which topology changes, etc.  The maximum size which can be handled
   in a single layer is generally thought to be somewhere on the order
   of 10 thousand objects.  The IARP must be designed to deal with
   internets bigger than this.

A.5.3  Addressing Implications

   Given the current rate of growth of the Internet, we can expect that
   the current addressing structure will become unworkable early within
   the lifetime of the new IARP.  It is therefore essential that any new
   IARP be able to use a new addressing format which allows for
   addressing hierarchies beyond the network level.  Any new IARP should
   allow for graceful migration from the current routing protocols, and
   should also allow for graceful migration from a routing scheme based
   on the current addressing, to a scheme based on a new multi-level
   addressing format such as that described by OSI 8473.

A.5.4  Memory, CPU, and Bandwidth Costs

   Routing costs can be measured in terms of the memory needed to store
   routing information, the CPU costs of calculating routes and
   forwarding packets, and the bandwidth costs of exchanging routing
   information and of forwarding packets.  These significant factors
   should provide the basis for comparison between competing proposals
   in IARP design.








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


   The routing architecture will be driven by the expected size of the
   Internet, the expected memory capacity of the gateways, capacity of
   the Inter-AS links, and the computing speed of the gateways. Given
   our experience with the current Internet, it is clearly necessary for
   the scheme to function adequately even if the Internet grows more
   quickly than we predict and its capacity grows more slowly.  Memory,
   CPU, and bandwidth costs should be in line with what is economically
   practical at any point in time given the size of the Internet at that
   time.

A.6  Other Issues

   The following are issues of a general nature and includes discussion
   of items which have been considered to be best left for future
   efforts.

A.6.1  Implementation

   The specification of IARP should allow interoperation among multi-
   vendor implementations.  This requires that multiple vendors be able
   to implement the same protocol, and that equipment from multiple
   vendors be able to interoperate successfully.

   There are potential practical difficulties of realizing multi-vendor
   interoperation.  Any such difficulty should not be inherent to the
   protocol specifications.  Towards this end, we should produce a
   protocol specification that is precise and unambiguous.  This implies
   that the specification should include a detailed specification using
   Pseudo-Code or a Formal Description Technique.

A.6.2  Configuration

   It is expected that any IARP will require a certain amount of
   configuration information to be maintained by gateways.  However, in
   practice it is often difficult to maintain configuration information
   in a fully correct and up-to-date form.  Problems in configuration
   have been known to cause significant problems in existing operational
   networks and internets.  The design of an Inter-AS Routing
   architecture must therefore simplify the maintenance of configuration
   information, consistent with other requirements. Simplification of
   configuration information may require minimizing the amount of
   configuration information, and using automated or semi-automated
   configuration mechanisms.

A.6.3  Migration

   In any event, whether the address format changes or not, a viable
   transition plan which allows for interoperability must be arranged.



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


   In a system of this magnitude, which is in operational use, a
   coordinated change is not possible.  Where possible, changes should
   not affect the hosts, since deploying such a change is probably
   several orders of magnitude more difficult than changing only the
   gateways, due to the larger number of host implementations as well as
   hosts.  There are two important questions that need to be addressed:
   (1) migration from the existing EGP to a new IARP; (2) migration from
   the current DD IP to future protocols (including the ISO IP, and
   other future protocols).

A.6.4  Load-Based Routing

   Some existing networks are able to route packets based on current
   load in the network.  For example, one approach to congestion
   involves adjusting the routes in real time to send as much traffic as
   possible on lightly loaded network links.

   This sort of load-based routing is a relatively delicate procedure
   which is prone to instability.  It is particularly difficult to
   achieve stability in multi-vendor environments, in large internets,
   and in environments characterized by a large variation in network
   characteristics.  For these reasons, we believe that it would be a
   mistake to attempt to achieve effective load-based routing in an
   Inter-AS Routing scheme.

A.6.5  Non-Interference Policies

   There are policies which are in effect, or desired to be in effect,
   which are based upon the concept of non-interference.  These policies
   state that the utilization of a given resource is permissible by one
   party as long as that utilization does not disrupt the current or
   future utilization of another party.  These policies are often of the
   kind "you may use the excess capacity of my link" without
   guaranteeing any capacity will be available.  The expectation is to
   be able to utilize the link as needed, perhaps to the exclusion of
   the other party.  The problem with supporting such a policy is the
   need to be cognizant of highly dynamic state information and the
   implicit requirement to adapt to these changes. Rapid, persistent,
   and non-deterministic state changes would lead to routing
   oscillations and looping.  We do not believe it is feasible to
   support policies based on these considerations in a large
   internetworking environment based on the current design of IP.

Security Considerations

   Security issues are not addressed in this memo.





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


Author's Address

   Mike Little
   Science Applications International Corporation (SAIC)
   8619 Westwood Center Drive
   Vienna, Virginia  22182

   Phone: [phone]

   EMail: [e-mail]









































Little                                                         [Page 25]