RFC 1322 (rfc1322) - Page 2 of 38

A Unified Approach to Inter-Domain Routing

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