A Unified Approach to Inter-Domain Routing
RFC 1322
Network Working Group D. Estrin
Request for Comments: 1322 USC
Y. Rekhter
IBM
S. Hotz
USC
May 1992
A Unified Approach to Inter-Domain Routing
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
Abstract
This memo is an informational RFC which outlines one potential
approach for inter-domain routing in future global internets. The
focus is on scalability to very large networks and functionality, as
well as scalability, to support routing in an environment of
heterogeneous services, requirements, and route selection criteria.
Note: The work of D. Estrin and S. Hotz was supported by the National
Science Foundation under contract number NCR-9011279, with matching
funds from GTE Laboratories. The work of Y. Rekhter was supported by
the Defense Advanced Research Projects Agency, under contract
DABT63-91-C-0019. Views and conclusions expressed in this paper are
not necessarily those of the Defense Advanced Research Projects
Agency and National Science Foundation.
1.0 Motivation
The global internet can be modeled as a collection of hosts
interconnected via transmission and switching facilities. Control
over the collection of hosts and the transmission and switching
facilities that compose the networking resources of the global
internet is not homogeneous, but is distributed among multiple
administrative authorities. Resources under control of a single
administration form a domain. In order to support each domain's
autonomy and heterogeneity, routing consists of two distinct
components: intra-domain (interior) routing, and inter-domain
(exterior) routing. Intra-domain routing provides support for data
communication between hosts where data traverses transmission and
switching facilities within a single domain. Inter-domain routing
provides support for data communication between hosts where data
Estrin, Rekhter & Hotz [Page 1]
RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
traverses transmission and switching facilities spanning multiple
domains. The entities that forward packets across domain boundaries
are called border routers (BRs). The entities responsible for
exchanging inter-domain routing information are called route servers
(RSs). RSs and BRs may be colocated.
As the global internet grows, both in size and in the diversity of
routing requirements, providing inter-domain routing that can
accommodate both of these factors becomes more and more crucial. The
number and diversity of routing requirements is increasing due to:
(a) transit restrictions imposed by source, destination, and transit
networks, (b) different types of services offered and required, and
(c) the presence of multiple carriers with different charging
schemes. The combinatorial explosion of mixing and matching these
different criteria weighs heavily on the mechanisms provided by
conventional hop-by-hop routing architectures ([ISIS10589, OSPF,
Hedrick88, EGP]).
Current work on inter-domain routing within the Internet community
has diverged in two directions: one is best represented by the Border
Gateway Protocol (BGP)/Inter-Domain Routeing Protocol (IDRP)
architectures ([BGP91, Honig90, IDRP91]), and another is best
represented by the Inter-Domain Policy Routing (IDPR) architecture
([IDPR90, Clark90]). In this paper we suggest that the two
architectures are quite complementary and should not be considered
mutually exclusive.
We expect that over the next 5 to 10 years, the types of services
available will continue to evolve and that specialized facilities
will be employed to provide new services. While the number and
variety of routes provided by hop-by-hop routing architectures with
type of service (TOS) support (i.e., multiple, tagged routes) may be
sufficient for a large percentage of traffic, it is important that
mechanisms be in place to support efficient routing of specialized
traffic types via special routes. Examples of special routes are:
(1) a route that travels through one or more transit domains that
discriminate according to the source domain, (2) a route that travels
through transit domains that support a service that is not widely or
regularly used. We refer to all other routes as generic.
Our desire to support special routes efficiently led us to
Show full document text