As per Relevance of the word environment, we have this rfc below:
Network Working Group M.
Request for Comments: 1126
October 1989
Goals and Functional Requirements
Inter-Autonomous System
Status of this
This document describes the functional requirements for a
protocol to be used between autonomous systems. This document
intended as a necessary precursor to the design of a new inter
autonomous system routing protocol and specifies requirements for
Internet applicable for use with the current DoD IP, the ISO IP,
future Internet Protocols. It is intended that these
will form the basis for the future development of a new inter
autonomous systems routing architecture and protocol. This
is being circulated to the IETF and Internet community for comment
Comments should be sent to: "open-rout-editor@bbn.com". This
does not specify a standard. Distribution of this memo is unlimited
1.
The development of an inter-autonomous systems routing
proceeds from those goals and functions seen as both desirable
obtainable for the Internet environment. This document
these goals and functional requirements. The goals and
requirements addressed by this document are intended to provide
context within which an inter-autonomous system routing
can be developed which will meet both current and future
routing needs. The goals presented indicate properties and
capabilities desired of the Internet routing environment and what
inter-autonomous system routing architecture is to accomplish as
whole
The goals are followed by functional requirements, which
either detailed objectives or specific functionality to be
by the architecture and resulting protocol(s). These
requirements are enumerated for clarity and grouped so as to
directly to areas of architectural consideration. This is
by a listing and description of general objectives, such
robustness, which are applicable in a broad sense.
functions which are not reasonably attainable or best left to
efforts are identified as non-requirements
The intent of this document is to provide both the goals
functional requirements in a concise fashion. Supporting arguments
Little [Page 1]
RFC 1126 Inter-Autonomous System Routing October 1989
tradeoff considerations and the like have been purposefully
in support of this. An appendix has been included which
this omission to a limited extent and the reader is directed
for a more detailed discussion of the issues involved
The goals and functional requirements contained in this document
the result of work done by the members of the Open Routing
Group. It is our intention that these goals and requirements
not only those foreseen in the Internet community but are
similar to those encountered in environments proposed by ANSI,
and ISO. It is expected that there will be some interaction
relationship between this work and the product of these groups
2. Overall
In order to derive a set functional requirements there must be one
more principals or overall goals for the routing environment
satisfy. These high level goals provide the basis for each of
functional requirements we have derived and will guide the
philosophy for achieving an inter-autonomous system routing solution
The overall goals we are utilizing are described in the
sections
2.1 Route to
The routing architecture will provide for the routing of
from a single source to one or more destinations in a timely manner
The larger goal is to provide datagram delivery to an
destination, one which is not necessarily immediately reachable
the source. In particular, routing is to address the needs of
single source requiring datagram delivery to one or
destinations. The concepts of multi-homed hosts and
routing services are encompassed by this goal. Datagram delivery
to be provided to all interconnected systems when not
constrained by autonomous considerations
2.2 Routing is
Routing services are to be provided with assurance, where
inability to provide a service is communicated under best effort
the requester within an acceptable level of error. This assurance
not to be misconstrued to mean guaranteed datagram delivery nor
it imply error notification for every lost datagram. Instead
attempts to utilize network routing services when such service
be provided will result in requester notification within a
period given persistent attempts
Little [Page 2]
RFC 1126 Inter-Autonomous System Routing October 1989
2.3 Large
The design of the architecture, and the protocols within
architecture, should accommodate a large number of routing entities
The exact order of magnitude is a relative guess and the best
would provide for a practical level of unbounded growth
Nevertheless, the routing architecture is expected to accommodate
growth of the Internet environment for the next 10 years
2.4 Autonomous
The routing architecture is to allow for stable operation
significant portions of the internetworking environment
controlled by disjoint entities. The future Internet environment
envisioned as consisting of a large number of
facilities owned and operated by a variety of funding sources
administrative concerns. Although cooperation between
facilities is necessary to provide interconnectivity, it is
that both the degree and type of cooperation will vary widely
Additionally, each of these internetworking facilities desires
operate as independently as possible from the concerns and
of other facilities individually and the interconnection
as a whole. Those resources used by (and available for) routing
to be allowed autonomous control by those administrative
which own or operate them. Specifically, each
administration should be allowed to establish and maintain
regarding the use of a given routing resource
2.5 Distributed
The routing environment developed should not depend upon a
repository or topological entity which is either centralized
ubiquitous. The growth pattern of the Internet, coupled with
need for autonomous operation, dictates an independence from
topological and administrative centralization of both data
control flows. Past experience with a centralized topology has
that it is both impractical for the needs of the community
restrictive of administrative freedoms. A distributed
environment should not be restrictive of either redundancy
diversity. Any new routing environment must allow for
interconnection between internetworks
2.6 Provide A Credible
The routing environment and services should be based upon
and information that exhibit both integrity and security.
routing mechanisms should operate in a sound and reliable
while the routing information base should provide credible data
Little [Page 3]
RFC 1126 Inter-Autonomous System Routing October 1989
which to base routing decisions. The environment can be
to the extent that the resulting effect on routing services
negligible. The architecture and protocol designs should be
that the routing environment is reasonably secure from
modification or influence
2.7 Be A Managed
Provide a manger insight into the operation of the inter-
system routing environment to support resource management,
solving, and fault isolation. Allow for management control of
routing system and collect useful information for the
management environment. Datagram events as well as the content
distribution characteristics of relevant databases are of
importance
2.8 Minimize Required
Any feasible design should restrain the demand for resources
to provide inter-autonomous systems routing. Of particular
are those resources required for data storage, transmission,
processing. The design must be practical in terms of today'
technology. Specifically, do not assume significant upgrades to
existing level of technology in use today for data
systems
3. Functional
The functional requirements we have identified have been derived
the overall goals and describe the critical features expected
inter-autonomous system routing. To an extent, these functions
vague in terms of detail. We do not, for instance, specify
quantity or types for quality-of-service parameters. This
purposeful, as the functional requirements specified here
intended to define the features required of the inter-
system routing environment rather than the exact nature of
environment. The functional requirements identified have
loosely grouped according to areas of architectural impact
3.1 Route Synthesis
Route synthesis is that functional area concerned with both
selection and path determination (identification of a sequence
intermediate systems) from a source to a destination. The
requirements identified here provide for path determination which
adaptive to topology changes, responsive to administrative policy
cognizant of quality-of-service concerns, and sensitive to
interconnected environment of autonomously managed systems
Little [Page 4]
RFC 1126 Inter-Autonomous System Routing October 1989
a) Route around failures
Route synthesis will provide a best effort attempt to
failures in those routing resources which are currently
utilized. Upon detection of a failed resource, route
will provide a best effort to utilize other available
resources in an attempt to provide the necessary
service
b) Provide loop free
The path provided for a datagram, from source to destination
will be free of circuits or loops most of the time. At
times a circuit or loop exists, it occurs with both
probability and duration
c) Know when a path or destination is
Route synthesis will be capable of determining when a
cannot be constructed to reach a known destination
Additionally, route synthesis will be capable of
when a given destination cannot be determined because
requested destination is unknown (or this knowledge
unavailable).
d) Provide paths sensitive to administrative
Route synthesis will accommodate the resource
policies of those administrative entities which manage
resources identified by the resulting path. However, it
inconceivable to accommodate all policies which can be
by a managing administrative entity. Specifically,
dependent upon volatile events of great celerity or those
are non-deterministic in nature cannot be accommodated
e) Provide paths sensitive to user
Paths produced by route synthesis must be sensitive to
expressed by the user. These user policies are expressed
terms relevant to known characteristics of the topology.
path achieved will meet the requirements stated by the
policy
f) Provide paths which characterize user quality-of-
The characteristics of the path provided should match
indicated by the quality-of-service requested.
Little [Page 5]
RFC 1126 Inter-Autonomous System Routing October 1989
appropriate, utilize only those resources which can support
desired quality-of-service (e.g., bandwidth).
g) Provide autonomy between inter- and intra-autonomous
route
The inter- and intra-autonomous system routing
should operate independent of one another. The
and design should be such that route synthesis of
routing environment does not depend upon information from
other for successful functioning. Specifically, the inter
autonomous system route synthesis design should minimize
constraints on the intra-autonomous system route
decisions when transiting (or delivering to) the
system
3.2 Forwarding
The following requirements specifically address the functionality
the datagram forwarding process. The forwarding process
datagrams to intermediate or final destinations based upon
characteristics, environmental characteristics, and route
decisions
a) Decouple inter- and intra-autonomous system
The requirement is to provide a degree of independence
the inter-autonomous system forwarding decision and the intra
autonomous system forwarding decision within the
process. Though the forwarding decisions are to be
of each other, the inter-autonomous system delivery process
necessarily be dependent upon intra-autonomous system
synthesis and forwarding
b) Do not forward datagrams deemed administratively
Forward datagrams according to the route synthesis decision
it does not conflict with known policy. Policy sensitive
synthesis will prevent normally routed datagrams from
inappropriate resources. However, a datagram routed
due to unknown events or actions can always occur and the
way to prohibit unwanted traffic from entering or leaving
autonomous system is to provide policy enforcement within
forwarding function
Little [Page 6]
RFC 1126 Inter-Autonomous System Routing October 1989
c) Do not forward datagrams to failed
A datagram is not to be forwarded to a resource known to
unavailable, notably an intermediate system such as a gateway
This implies some ability to detect and react to
failures
d) Forward datagram according to its
The datagram forwarding function is to be sensitive to
characteristics of the datagram in order to execute
appropriate route synthesis decision. Characteristics
consider are the destination, quality-of-service, precedence
datagram (or user) policy, and security. Note that
characteristics, precedence for example, affect the
service provided whereas others affect the path chosen
3.3 Information
This functional area addresses the general information
of the routing environment. This encompasses both the nature
disbursal of routing information. The characteristics of the
information and its disbursal are given by the following
requirements
a) Provide a distributed and descriptive information
The information base must not depend upon either
or exact replication. The content of the information base
be sufficient to support all provided routing functionality
specifically that of route synthesis and forwarding
Information of particular importance includes
characteristics and resource utilization policies
b) Determine resource
Provide a means of determining the availability of any
resource in a timely manner. The timeliness of
determination is dependent upon the routing service(s) to
supported
c) Restrain transmission
The dynamics of routing information flow should be such that
significant portion of transmission resources are not consumed
Routing information flow should adjust to the demands of
environment, the capacities of the distribution
utilized, and the desires of the resource manager
Little [Page 7]
RFC 1126 Inter-Autonomous System Routing October 1989
d) Allow limited information
Information distribution is to be sensitive to
policies. An administrative policy may affect the content
completeness of the information distributed. Additionally
administrative policy may determine the extent of
distributed
3.4 Environmental
The following items identify those requirements directly related
the nature of the environment within which routing is to occur
a) Support a packet-switching
The routing environment should be capable of
datagram transfer within a packet-switched oriented
environment
b) Accommodate a connection-less oriented user transport
The routing environment should be designed such that
accommodates the model for connection-less oriented
transport service
c) Accommodate 10K autonomous systems and 100K
This requirement identifies the scale of the
environment we view as appearing in the future. A
design which does not accommodate this order of magnitude
viewed as being inappropriate
d) Allow for arbitrary interconnection of autonomous
The routing environment should accommodate
between autonomous systems which may occur in an
manner. It is recognized that a practical solution is
to favor a given structure of interconnectivity for reasons
efficiency. However, a design which does not allow for
utilize interconnectivity of an arbitrary nature would not
considered a feasible design
3.5 General
The following are overall objectives to be achieved by the inter
autonomous routing architecture and its protocols
a) Provide routing services in a timely
Little [Page 8]
RFC 1126 Inter-Autonomous System Routing October 1989
Those routing services provided, encapsulated by
requirements stated herein, are to be provided in a
manner. The time scale for this provision must be
to support those services provided by the
environment as a whole
b) Minimize constraints on systems with limited
Allow autonomous systems, or gateways, of limited resources
participate in the inter-autonomous system
architecture. This limited participation is not
without cost, either in terms of responsiveness,
optimization, or other factor(s).
c) Minimize impact of dissimilarities between autonomous
Attempt to achieve a design in which the
between autonomous systems do not impinge upon the
services provided to any autonomous system
d) Accommodate the addressing schemes and protocol mechanisms
the autonomous
The routing environment should accommodate the
schemes and protocol mechanisms of autonomous systems,
these schemes and mechanisms may differ among
systems
e) Must be implementable by network
This is to say that the algorithms and complexities of
design must be such that they can be understood outside of
research community and implementable by people other than
designers themselves. Any feasible design must be capable
being put into practice
4. Non-
In view of the conflicting nature of many of the stated goals and
careful considerations and tradeoffs necessary to achieve
successful design, it is important to also identify those goals
functions which we are not attempting to achieve. The
items are not considered to be reasonable goals or
requirements at this time and are best left to future efforts.
are non-goals, or non-requirements, within the context of the
and requirements previously stated by this document as well as
interpretation of what can be practically achieved
Little [Page 9]
RFC 1126 Inter-Autonomous System Routing October 1989
a)
It is not a goal to design a routing environment in which
participating autonomous system can obtain a routing service
any other participating autonomous system in a
fashion. Within a policy sensitive routing environment,
cooperation of intermediate resources will be necessary
cannot be guaranteed to all participants. The concept
ubiquitous connectivity will not be a valid one
b) Congestion
The ability for inter-autonomous system routing to
congestion control is a non-requirement. Additional study
necessary to determine what mechanisms are most appropriate
if congestion control is best realized within the inter-
and/or intra-AS environments, and if both, what the dynamics
the interactions between the two are
c) Load
The functional capability to distribute the flow of datagrams
from a source to a destination, across two or more
paths through route synthesis and/or forwarding is a non
requirement
d) Maximizing the utilization of
There is no goal or requirement for the inter-autonomous
routing environment to be designed such that it attempts
maximize the utilization of available resources
e) Schedule to deadline
The ability to support a schedule to deadline routing
is a non-requirement for the inter-autonomous
environment at this point in time
f) Non-interference policies of resource
The ability to support routing policies based upon the
of non-interference is a not a requirement. An example of
a policy is one where an autonomous system allows
utilization of excess bandwidth by external users as long
this does not interfere with local usage of the link
Little [Page 10]
RFC 1126 Inter-Autonomous System Routing October 1989
5.
Although neither a specific goal nor a functional requirement
consideration must be given to the transition which will occur
the current operational routing environment to a new
environment. A coordinated effort among all participants of
Internet would be impractical considering the magnitude of such
undertaking. Particularly, the issues of transitional coexistence
as opposed to phased upgrading between disjoint systems, should
addressed as a means to minimize the disruption of service.
consideration should also be given to any required changes to hosts
It is very unlikely that all hosts could be changed, given
precedence, their diversity and their large numbers
Appendix - Issues in Inter-Autonomous Systems
A.0
This appendix is an edited version of the now defunct
entitled "Requirements for Inter-Autonomous Systems Routing",
by Ross Callon in conjunction with the members of the Open
Working Group
A.1
The information and discussion contained here historically
that of the main document body and was a major influence on
content. It is included here as a matter of reference and to
insight into some of the many issues involved in inter-
systems routing
The following definitions are utilized
Boundary
A boundary gateway is any autonomous system gateway
has a network interface directly reachable from
autonomous system. As a member of an autonomous system,
boundary gateway participates in the Interior
Protocol and other protocols used for routing (and
purposes) between other gateways of this same
system and between those networks directly reachable by
autonomous system. A boundary gateway may
participate in an Inter-Autonomous System Routing Protocol
As a participant in the inter-autonomous system
protocol, a boundary gateway interacts with other
gateways in other autonomous systems, either directly
indirectly, in support of the operation of
Little [Page 11]
RFC 1126 Inter-Autonomous System Routing October 1989
Inter-Autonomous System Routing Protocol
Interior
An interior gateway is any autonomous system gateway
is not a boundary gateway. As such, an interior
does not have any network interfaces which are
reachable by any other autonomous system. An
gateway is part of an autonomous system and, as such
takes part in the Interior Gateway Protocol and
protocols used in that autonomous system. However,
interior gateway does not directly exchange
information with gateways in other autonomous systems
the Inter-Autonomous System Routing Protocol
The following acronyms are used
AS -- Autonomous
This document uses the current definition of "
System": a collection of cooperating gateways running
common interior routing protocol. This implies that
and hosts may be reachable through one or more
Systems
NOTE: The current notion of "Autonomous System"
assumes that each gateway will belong to exactly one AS
Extensions to allow gateways which belong to no AS'
and/or gateways which belong to multiple AS's, are
the scope of this discussion. However, we do not
the possibility of considering such extensions in
future
IARP -- Inter-Autonomous System Routing
This is the protocol used between boundary gateways
the purpose of routing between autonomous systems
IGP -- Interior Gateway
This is the protocol used within an autonomous system
routing within that autonomous system
A.2 Architectural
The architecture of an inter-autonomous system routing environment
mutually dependent with the notion of an Autonomous System.
general, the architecture should maximize independence of
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
the inter-autonomous system routing protocols (IARP).
independence should allow technological and
differences among AS's as well as protection against propagation
misbehavior. The following issues address ways to
interoperation and protection, and to meet certain
criteria. We also put forth a set of minimal constraints to
imposed among Autonomous Systems, and between inter- and intra-
functions
A.2.1 IGP
The IARP should be capable of tolerating an Autonomous System
which its IGP is unable to route packets, provides
information, and exhibits unstable behavior. Interfacing to such
ill-behaved AS should not produce global instabilities within
IARP and the IARP should localize any effects. On the other hand
the IGP should provide a routing environment where the
and connectivity provided to the IARP from the IGP does not
rapid and continual changes. An Autonomous System therefore
appear as a relatively stable environment
A.2.2 Independence of Autonomous
The IARP should not constrain any AS to require the use any
specific IGP. This applies both to IGPs and potentially to any
internal protocols. The architecture should also allow intra-
routing and organizational structures to be hidden from inter-AS use
An Autonomous System should not be required to use any one
type of linkage between boundary gateways within the AS. However
there are some minimal constraints that gateways and the
interior routing protocol within an AS must meet in order to be
to route Inter-AS traffic, as discussed in Section A.2.6.
A.2.3 General
The routing architecture should provide significant
regarding the interconnection of AS's. The specification of
should impose no inherent restriction on either
configuration or information passing among autonomous systems.
may be administrative and policy limitations on the
of AS's, and on the extent to which routing information and
traffic may be passed between AS's. However, there should be
inherent restrictions imposed by limitations in the design of
routing architecture. The architecture should allow
topological interconnection of Autonomous Systems. Propagation
routing information should not be restricted by the specification
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
We expect AS's to have a certain amount of insulation from
AS's. This protection should apply to both the adequacy
stability of routes produced by the routing scheme, and also to
amount of overhead traffic and other costs necessary to run
routing scheme. There are several forms which these "
firewalls" may take
- An AS must be able to successfully route its own
traffic in the face of arbitrary failures of other IGPs and
IARP. In other words, the AS should be able to
shutout the rest of the world
- The IARP should be able to operate correctly in the face of
failures. In this case, correct operation is defined
recognizing that an AS has failed, and routing around it
possible (traffic to or from that AS may of course fail).
- In addition, problems in Inter-AS Routing should, as much
possible, be limited in the extent of their effect
Routing firewalls may be explicit, or may be inherent in the
of the algorithms. We expect that both explicit and
firewalls will be utilized. Examples of firewalls include
- Separating Intra- and Inter-AS Routing to some
isolates each of these from problems with the other.
defined interfaces between different modules/protocols
some degree of protection
- Access control restrictions may provide some degree
firewalls. For example, some AS's may be non-transit (won'
forward transit traffic). Failures within such AS's may
prevented from affecting traffic not associated with that AS
- Protocol design can help. For example, with link state
you can require that both ends must report a link before is
be regarded as up, thereby eliminating the possibility of
single node causing fictitious links
- Finally, explicit firewalls may be employed using
configuration information
Little [Page 14]
RFC 1126 Inter-Autonomous System Routing October 1989
A.2.5 Boundary
Boundary gateways will exchange Inter-AS Routing information
other boundary gateways using the IARP. Each AS which is to
part in Inter-AS Routing will have one or more boundary gateways,
which one or more of these boundary gateways exchanges
with peer boundary gateways in other AS's
Information related to Inter-AS Routing may be passed
connected boundary gateways in different AS's. Specific
boundary gateways will therefore be required to understand the IARP
The external link between the boundary gateways may be
by any kind of connectivity that can be modeled as a direct
between two gateways -- a LAN, an ARPANET, a satellite link,
dedicated line, and so on
A.2.6 Minimal Constraints on the Autonomous
The architectural issues discussed here for inter-AS routing
certain minimal functional constraints that an AS must satisfy
order to take part in the Inter-AS Routing scheme. These
requirements are described in greater detail in this section.
list of functional constraints is not necessarily complete
A.2.6.1 Internal Links between Boundary
In those cases where an AS may act as a transit AS (i.e., may
traffic for which neither the source nor the destination is in
AS), the gateways internal to that AS will need to know
boundary gateway is to serve as the exit gateway from that AS.
are several ways in which this may be accomplished
1. Boundary gateways are directly
2. "Tunneling" (i) using source routing (ii) using
3. Interior gateways participate (i) limited participation (ii
fully general
With solution (1), the boundary gateways in an AS are
connected. This eliminates the need for other gateways in the AS
have any knowledge of Inter-AS Routing. Transit traffic is
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
knowledge about Inter-AS routes by means such as source routing
encapsulation. The boundary gateway by which the packet enters an
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
route to the packet, or encapsulate the packet in another level of
or gateway-to-gateway header. This allows boundary gateways
forward data traffic using the appropriate tunnelling technique
Finally, with solution (3), the interior gateways have some
of Inter-AS Routing. At a minimum, the interior gateways would
to know the identity of each boundary gateway, the address(es)
can be reached by that gateway, and the Inter-AS metric
with the route to that address(es). If the IARP allows for
routing for multiple TOS classes, then the information that
interior gateways need to know includes a separate Inter-AS
for each TOS class. The Inter-AS metrics are necessary to
gateways to choose among multiple possible exit boundary gateways
In general, it is not necessary for the Inter-AS metrics to have
relationship with the metric used within an AS for interior routing
The interior gateways do not need to know how to interpret
exterior metrics, except to know that each metric is to
interpreted as an unsigned integer and a lesser value is
to a greater value. It would be possible, but not necessary, for
interior gateways to have full knowledge of the IARP
It is not necessary for the Inter-AS Routing architecture to
which of these solutions are to be used for any particular AS
Rather, it is possible for individual AS's to choose which scheme
combination of schemes to use. Independence of the IARP from
internal operation of each AS implies that this decision be left
to the internal protocols used in each AS. The IARP must be able
operate as if the boundary gateways were directly connected
A.2.6.2 Forwarding of Data from the
The scheme used for forwarding transit traffic across an AS also
implications for the forwarding of traffic which originates within
AS, but whose destination is reachable only from other AS's.
either of solutions (1) or (2) in Section A.2.6.1 is followed,
it will be sufficient for an interior gateway to forward such
to any boundary gateway. Greater efficiency may optionally
achieved in some cases by providing interior gateways with
information which will allow them to choose the "best"
gateway in some sense. If solution (3) is followed, then
information passed to interior gateways to allow them to
transit traffic will also be sufficient to forward
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
If a packet whose destination is reachable from an AS arrives at
AS, then it is desired that the interior routing protocol used
that AS be able to successfully deliver the packet without
on Inter-AS Routing. This does not preclude that the Inter-
Routing protocol will deal with partitioned AS's
An AS may have access control, security, and policy restrictions
restrict which data packets may enter or leave the AS. However,
any data packet which is allowed access to the AS, the AS is
to deliver the packet to its destination without further
between parts of the AS. In this sense, the internal structure
the AS should not be visible to the IARP
A.3 Policy
The interconnection of multiple heterogeneous networks and
heterogeneous autonomous systems owned and operated by
administrations into a single combined internet is a very
task. It is expected that the administrations associated with
an internet will wish to impose a variety of constraints on
operation of the internet. Specifically, externally imposed
constraints may include a variety of transit access control
administrative policy, and security constraints
Transit access control refers to those access control
which an AS may impose to restrict which traffic the AS is willing
forward. There are a large number of access control
which one could envision being used. For example, some AS's may
to operate only as "non-transit" AS's, that is, they will
forward data traffic which either originates or terminates
that AS. Other AS's may restrict transit traffic to datagrams
originate within a specified set of source hosts. Restrictions
require that datagrams be associated with specific applications (
as electronic mail traffic only), or that datagrams be
with specific classes of users
Policy restrictions may allow either the source of datagrams, or
organization that is paying for transmission of a datagram, to
which AS's the datagrams may transit. For example, an
may wish to specify that certain traffic originating within their
should not transit any AS administered by its main competitor
Security restrictions on traffic relates to the official
classification level of traffic. As an example, an AS may
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
to transit access control, administrative policy, and
constraints is the associated potential for exponential growth
routes. For example, suppose that there are 20 packets arriving at
particular gateway, each for the same destination, but subject to
different combination of access control, policy, and
constraints. It is possible that all 20 packets would need to
different routes to the destination
This explosive growth of routes leads to the question: "Is
practically feasible to deal with complete general external
constraints?" One approach would allow only a smaller subset
constraints, chosen to provide some useful level of control
allowing minimal impact on the routing protocol. Further work
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
restrictions should be. Efforts to study this issue are
underway, but are not expected to produce definitive results within
short to medium time frame. It is therefore not practical to
for this effort to be finished before defining the next generation
Inter-AS Routing
A.4 Service
The following paragraphs discuss issues concerning the services
Inter-AS Routing Protocol may provide. This is not a complete
of service issues but does address many of those services which
of concern to a significant portion of the community
A.4.1 Cost on Toll
Consideration must be given to the use of routing protocols with
(i.e., charge) networks. Although uncommon in the Internet at
moment, they will become more common in the future, and thought
to be given to allowing their inclusion in an efficient and
manner
There are two areas in which concerns of cost intrude. First
provision must be made to include in the routing
distributed throughout the system the information that certain
cost money, so that traffic patterns may account for the cost
Second, the actual operation of the algorithm, in terms of
messages that must be exchanged to operate the algorithm,
recognize that fact that on certain links, the exchange may have
associated cost which must be taken into account. These areas
Little [Page 18]
RFC 1126 Inter-Autonomous System Routing October 1989
involve policy questions on the part of the user. It is
requirement of the algorithm that facilities be available to
different groups to answer these questions in different ways.
first area is related to type-of-service routing, and is discussed
Section A.4.2. The second area is discussed below
Previous attempts at providing these sorts of controls
incomplete because they were not thought through fully; a new
must avoid these pitfalls. For instance, even though the Hello
in EGP may be adjusted, turning the rate down too low (to control
costs) could cause the route to be dropped from databases
timeout
In a large internet, changes will be occurring constantly;
simplistic mechanism might mean that a site which is only
by toll networks has to either accept having an old picture of
network, or spend more to keep a more current picture of things
However, that is not necessarily the case if incomplete knowledge
cache-based techniques are used more. For instance, if a
connected only by toll links keeps an incomplete or less up-to-
map of the situation, an agreement with a neighbor which does
labor under these restrictions might allow it to get up-to-
information only when needed
A.4.2 Type-of-Service
The need for type-of-service (TOS) has been increasing as
become more heterogeneous in physical channel components, high-
applications, and administrative management. For instance,
recently installed fiber cables provide abundant
bandwidths, while old narrow-band channels will still be with us
a long time period. Electronic mail traffic tolerates
delays and low throughput. New image transmissions are coming up
these require high bandwidths but are not effected by a few
errors. Furthermore, some networks may soon install
functions to charge users, while others may still provide
services
Considering the long life span of a new routing architecture, it
mandatory that it be built with mechanisms to provide TOS routing
Unfortunately, we have had very little experience with TOS routing
even with a single network. No TOS routing system has ever
field-tested on a large-scale basis
We foresee the need for TOS routing and recognize the
complexities and difficulties in design and implementation. We
consider that new applications coming along may require
services that are unforeseeable today. We feel a practical
Little [Page 19]
RFC 1126 Inter-Autonomous System Routing October 1989
is to provide a small set of TOS routing functions as a first
while the design of the architecture should be such that new
of TOS can be easily added later and incrementally deployed.
Inter-AS Routing Architecture should allow both globally and
defined TOS classes
We intend to address TOS routing based on the following metrics
-
-
-
Delay and throughput are the main network performance concerns
Considering that some networks may soon start charging users for
transmission services provided, the cost should also be added as
factor in route selection
Reliability is not included in the above list.
applications with different reliability requirements will differ
terms of what Transport Protocol they use. However, IP offers only
"moderate" level of reliability, suitable to applications such
voice, or possibly even less than that required by voice. The
of reliability offered by IP will not differ substantially based
the application. Thus the requested level of reliability will
affect Inter-AS Routing
Delay and throughput will be measured from the
characteristics of communication channels, without
instantaneous load. This is necessary in order to provide
routes, and to minimize the overhead caused by the Inter-AS
scheme
A number of TOS service classes may be defined according to
metrics. Each class will present defined requirements for each
the TOS metrics. For example, one class may require low delay
require only low throughput, and require low cost
A.4.3 Multipath
There are two types of multipath routing which are useful for Inter
AS Routing: (1) there may be multiple gateways between any
neighboring AS's; (2) there may be multiple AS-to-AS paths
any pair of source and destination AS's. Both forms of multipath
useful in order to allow for loadsplitting. Provision for
routing in the IARP is desirable, but not an absolute requirement
Little [Page 20]
RFC 1126 Inter-Autonomous System Routing October 1989
A.5 Performance
The following paragraphs discuss issues related to the performance
an Inter-AS Routing Protocol. This discussion addresses size as
as efficiency considerations
A.5.1 Adaptive
It is necessary that the Inter-AS Routing scheme respond in a
fashion to major network problems, such as the failure of
network resources. In this sense, Inter-AS Routing needs to
adaptive routing mechanisms similar to those commonly used
individual networks and AS's. It is important that the
routing mechanism chosen for Inter-AS Routing achieve
convergence following internet topological changes, with little
none of the serious convergence problems (such as "counting
infinity") that have been experienced in some existing
routing protocols
The Inter-AS Routing scheme must provide stability of routes. It
totally unacceptable for routes to vary on a frequent basis.
requirement is not meant to limit the ability of the
algorithm to react rapidly to major topological changes, such as
loss of connectivity between two AS's. The need for adaptive
does not imply any desire for load-based routing
A.5.2 Large
One key question in terms of the targets is the maximum size of
Internet this algorithm is supposed to support. To some degree,
is tied to the timeline for which this protocol is expected to
active. However, it is necessary to have some size targets
Techniques that work at one order of size may be impractical in
system ten or twenty times larger
Over the past five years there has been an approximate doubling
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
difficult to predict accurately. However, if this doubling
continues, we would reach 10,000 nets sometime near January 1993.
Taking a projection purely on the number of networks (the top
routing entity) may be overly conservative since the introduction
wide use of subnets has absorbed some growth, but will not
to be able to do so. In addition, there are plans being
that will continue or accelerate the current rate of growth
Nonetheless, the number of networks is very important
Little [Page 21]
RFC 1126 Inter-Autonomous System Routing October 1989
networks constitute the "top level entities" in the
addressing structure
The implications of the size parameter are fairly serious.
current system has only one level of addressing above subnets.
it is possible to adjust certain parameters (for example,
unsolicited or unnecessary retransmission rate) to produce a
but less robust system, other parameters (for example, the rate
change in the system) cannot be so adjusted. This will
eventual limits on the size of a system that can be dealt with in
flat address space
The exact size that necessitates moving from the current single
level system to a multi-level system is not clear. Among
parameters which affect it are the assumed minimum speed of links
the system (faster links can allocate more bandwidth to
traffic before it becomes obtrusive), speed and memory capacity
routing nodes (needed to store and process routing data), rate
which topology changes, etc. The maximum size which can be
in a single layer is generally thought to be somewhere on the
of 10 thousand objects. The IARP must be designed to deal
internets bigger than this
A.5.3 Addressing
Given the current rate of growth of the Internet, we can expect
the current addressing structure will become unworkable early
the lifetime of the new IARP. It is therefore essential that any
IARP be able to use a new addressing format which allows
addressing hierarchies beyond the network level. Any new IARP
allow for graceful migration from the current routing protocols,
should also allow for graceful migration from a routing scheme
on the current addressing, to a scheme based on a new multi-
addressing format such as that described by OSI 8473.
A.5.4 Memory, CPU, and Bandwidth
Routing costs can be measured in terms of the memory needed to
routing information, the CPU costs of calculating routes
forwarding packets, and the bandwidth costs of exchanging
information and of forwarding packets. These significant
should provide the basis for comparison between competing
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
Internet, the expected memory capacity of the gateways, capacity
the Inter-AS links, and the computing speed of the gateways.
our experience with the current Internet, it is clearly necessary
the scheme to function adequately even if the Internet grows
quickly than we predict and its capacity grows more slowly. Memory
CPU, and bandwidth costs should be in line with what is
practical at any point in time given the size of the Internet at
time
A.6 Other
The following are issues of a general nature and includes
of items which have been considered to be best left for
efforts
A.6.1
The specification of IARP should allow interoperation among multi
vendor implementations. This requires that multiple vendors be
to implement the same protocol, and that equipment from
vendors be able to interoperate successfully
There are potential practical difficulties of realizing multi-
interoperation. Any such difficulty should not be inherent to
protocol specifications. Towards this end, we should produce
protocol specification that is precise and unambiguous. This
that the specification should include a detailed specification
Pseudo-Code or a Formal Description Technique
A.6.2
It is expected that any IARP will require a certain amount
configuration information to be maintained by gateways. However,
practice it is often difficult to maintain configuration
in a fully correct and up-to-date form. Problems in
have been known to cause significant problems in existing
networks and internets. The design of an Inter-AS
architecture must therefore simplify the maintenance of
information, consistent with other requirements. Simplification
configuration information may require minimizing the amount
configuration information, and using automated or semi-
configuration mechanisms
A.6.3
In any event, whether the address format changes or not, a
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,
coordinated change is not possible. Where possible, changes
not affect the hosts, since deploying such a change is
several orders of magnitude more difficult than changing only
gateways, due to the larger number of host implementations as well
hosts. There are two important questions that need to be addressed
(1) migration from the existing EGP to a new IARP; (2) migration
the current DD IP to future protocols (including the ISO IP,
other future protocols).
A.6.4 Load-Based
Some existing networks are able to route packets based on
load in the network. For example, one approach to
involves adjusting the routes in real time to send as much traffic
possible on lightly loaded network links
This sort of load-based routing is a relatively delicate
which is prone to instability. It is particularly difficult
achieve stability in multi-vendor environments, in large internets
and in environments characterized by a large variation in
characteristics. For these reasons, we believe that it would be
mistake to attempt to achieve effective load-based routing in
Inter-AS Routing scheme
A.6.5 Non-Interference
There are policies which are in effect, or desired to be in effect
which are based upon the concept of non-interference. These
state that the utilization of a given resource is permissible by
party as long as that utilization does not disrupt the current
future utilization of another party. These policies are often of
kind "you may use the excess capacity of my link"
guaranteeing any capacity will be available. The expectation is
be able to utilize the link as needed, perhaps to the exclusion
the other party. The problem with supporting such a policy is
need to be cognizant of highly dynamic state information and
implicit requirement to adapt to these changes. Rapid, persistent
and non-deterministic state changes would lead to
oscillations and looping. We do not believe it is feasible
support policies based on these considerations in a
internetworking environment based on the current design of IP
Security
Security issues are not addressed in this memo
Little [Page 24]
RFC 1126 Inter-Autonomous System Routing October 1989
Author's
Mike
Science Applications International Corporation (SAIC
8619 Westwood Center
Vienna, Virginia 22182
Phone: 703-734-9000
EMail: little@SAIC.
Little [Page 25]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
