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.
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.
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.
Author's Address
Mike Little
Science Applications International Corporation (SAIC)
8619 Westwood Center Drive
Vienna, Virginia 22182
Phone: 703-734-9000
EMail: little@SAIC.COM