RFC 1322 (rfc1322) - Page 2 of 38
A Unified Approach to Inter-Domain Routing
Alternative Format: Original Text Document
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
investigate the dynamic installation of routes ([Breslau-Estrin91,
Clark90, IDPR90]). In a previous paper ([Breslau-Estrin91]), we
evaluated the algorithmic design choices for inter-domain policy
routing with specific attention to accommodating source-specific and
other "special" routes. The conclusion was that special routes are
best supported with source-routing and extended link-state
algorithms; we refer to this approach as source-demand routing
Estrin, Rekhter & Hotz