A Unified Approach to Inter-Domain Routing
RFC 1322

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

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