RFC 1478 (rfc1478) - Page 3 of 35

An Architecture for Inter-Domain Policy Routing

RFC 1478                   IDPR Architecture                   June 1993


1.  Introduction

   As data communications technologies evolve and user populations grow,
   the demand for internetworking increases.  Internetworks usually
   proliferate through interconnection of autonomous, heterogeneous
   networks administered by separate authorities.  We use the term
   "administrative domain" (AD) to refer to any collection of contiguous
   networks, gateways, links, and hosts governed by a single
   administrative authority who selects the intra-domain routing
   procedures and addressing schemes, specifies service restrictions for
   transit traffic, and defines service requirements for locally-
   generated traffic.

   Interconnection of administrative domains can broaden the range of
   services available in an internetwork.  Hence, traffic with special
   service requirements is more likely to receive the service requested.
   However, administrators of domains offering special transit services
   are more likely to establish stringent access restrictions, in order
   to maintain control over the use of their domains' resources.

   An internetwork composed of many domains with diverse service
   requirements and restrictions requires "policy routing" to transport
   traffic between source and destination.  Policy routing constitutes
   route generation and message forwarding procedures for producing and
   using routes that simultaneously satisfy user service requirements
   and respect transit domain service restrictions.

   With policy routing, each domain administrator sets "transit
   policies" that dictate how and by whom the resources within its
   domain should be used.  Transit policies are usually public, and they
   specify offered services comprising:

   - Access restrictions: e.g., applied to traffic to or from certain
     domains or classes of users.

   - Quality: e.g., delay, throughput, or error characteristics.

   - Monetary cost: e.g., charge per byte, message, or unit time.

   Each domain administrator also sets "source policies" for traffic
   originating within its domain.  Source policies are usually private,
   and they specify requested services comprising:

   - Access restrictions: e.g., domains to favor or avoid in routes.

   - Quality: e.g., acceptable delay, throughput, or reliability.

   - Monetary cost: e.g., acceptable session cost.



Steenstrup