rfc1478.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                     M. Steenstrup
Request for Comments: 1478                 BBN Systems and Technologies
                                                              June 1993


            An Architecture for Inter-Domain Policy Routing

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   We present an architecture for inter-domain policy routing (IDPR).
   The objective of IDPR is to construct and maintain routes, between
   source and destination administrative domains, that provide user
   traffic with the requested services within the constraints stipulated
   for the domains transited.  The IDPR architecture is designed to
   accommodate an internetwork containing tens of thousands of
   administrative domains with heterogeneous service requirements and
   restrictions.

Contributors

   The following people have contributed to the IDPR architecture: Bob
   Braden, Lee Breslau, Ross Callon, Noel Chiappa, Dave Clark, Pat
   Clark, Deborah Estrin, Marianne Lepp, Mike Little, Martha Steenstrup,
   Zaw-Sing Su, Paul Tsuchiya, and Gene Tsudik.  Yakov Rekhter supplied
   many useful comments on a previous draft of this document.


















Steenstrup                                                      [Page 1]

RFC 1478                   IDPR Architecture                   June 1993


Table of Contents

   1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3
   1.1. The Internet Environment. . . . . . . . . . . . . . . . . . . 4
   2. Approaches to Policy Routing. . . . . . . . . . . . . . . . . . 5
   2.1. Policy Route Generation . . . . . . . . . . . . . . . . . . . 5
   2.1.1. Distance Vector Approach. . . . . . . . . . . . . . . . . . 5
   2.1.2. Link State Approach . . . . . . . . . . . . . . . . . . . . 7
   2.2. Routing Information Distribution. . . . . . . . . . . . . . . 8
   2.2.1. Distance Vector Approach. . . . . . . . . . . . . . . . . . 8
   2.2.2. Link State Approach . . . . . . . . . . . . . . . . . . . .10
   2.3. Message Forwarding along Policy Routes. . . . . . . . . . . .10
   2.3.1. Hop-by-Hop Approach . . . . . . . . . . . . . . . . . . . .11
   2.3.1.1. A Clarification . . . . . . . . . . . . . . . . . . . . .11
   2.3.2. Source Specified Approach . . . . . . . . . . . . . . . . .12
   3. The IDPR Architecture . . . . . . . . . . . . . . . . . . . . .13
   3.1. IDPR Functions. . . . . . . . . . . . . . . . . . . . . . . .13
   3.2. IDPR Entities . . . . . . . . . . . . . . . . . . . . . . . .13
   3.2.1. Path Agents . . . . . . . . . . . . . . . . . . . . . . . .16
   3.2.2. IDPR Servers. . . . . . . . . . . . . . . . . . . . . . . .17
   3.2.3. Entity Identifiers. . . . . . . . . . . . . . . . . . . . .19
   3.3. Security and Reliability. . . . . . . . . . . . . . . . . . .20
   3.3.1. Retransmissions and Acknowledgements. . . . . . . . . . . .20
   3.3.2. Integrity Checks. . . . . . . . . . . . . . . . . . . . . .21
   3.3.3. Source Authentication . . . . . . . . . . . . . . . . . . .21
   3.3.4. Timestamps. . . . . . . . . . . . . . . . . . . . . . . . .21
   3.4. An Example of IDPR Operation. . . . . . . . . . . . . . . . .22
   4. Accommodating a Large, Heterogeneous Internet . . . . . . . . .25
   4.1. Domain Level Routing. . . . . . . . . . . . . . . . . . . . .25
   4.2. Route Generation. . . . . . . . . . . . . . . . . . . . . . .27
   4.3. Super Domains . . . . . . . . . . . . . . . . . . . . . . . .29
   4.4. Domain Communities. . . . . . . . . . . . . . . . . . . . . .30
   4.5. Robustness in the Presence of Failures. . . . . . . . . . . .31
   4.5.1. Path Repair . . . . . . . . . . . . . . . . . . . . . . . .31
   4.5.2. Partitions. . . . . . . . . . . . . . . . . . . . . . . . .33
   5. References. . . . . . . . . . . . . . . . . . . . . . . . . . .XX
   5. Security Considerations . . . . . . . . . . . . . . . . . . . .34
   6. Author's Address  . . . . . . . . . . . . . . . . . . . . . . .34













Steenstrup                                                      [Page 2]

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                                                      [Page 3]

RFC 1478                   IDPR Architecture                   June 1993


   In this document, we describe an architecture for inter-domain policy
   routing (IDPR), and we provide a set of functions which can form the
   basis for a suite of IDPR protocols and procedures.

1.1.  The Internet Environment

   The Internet currently comprises over 7000 operational networks and
   over 10,000 registered networks.  In fact, for the last several
   years, the number of constituent networks has approximately doubled
   annually.  Although we do not expect the Internet to sustain this
   growth rate, we must provide an architecture for IDPR that can
   accommodate the Internet five to ten years in the future.  According
   to the functional requirements for inter-autonomous system (i.e.,
   inter-domain) routing set forth in [6], the IDPR architecture and
   protocols must be able to handle O(100,000) networks distributed over
   O(10,000) domains.

   Internet connectivity has increased along with the number of
   component networks.  In the early 1980s, the Internet was purely
   hierarchical, with the ARPANET as the single backbone.  The current
   Internet possesses a semblance of a hierarchy in the collection of
   backbone, regional, metropolitan, and campus domains that compose it.
   However, technological, economical, and political incentives have
   prompted the introduction of inter-domain links outside of those in
   the strict hierarchy.  Hence, the Internet has the properties of both
   hierarchical and mesh connectivity.

   We expect that the Internet will evolve in the following way.  Over
   the next five years, the Internet will grow to contain O(10) backbone
   domains, most providing connectivity between many source and
   destination domains and offering a wide range of qualities of
   service, for a fee.  Most domains will connect directly or indirectly
   to at least one Internet backbone domain, in order to communicate
   with other domains.  In addition, some domains may install direct
   links to their most favored destinations.  Domains at the lower
   levels of the hierarchy will provide some transit service, limited to
   traffic between selected sources and destinations.  However, the
   majority of Internet domains will be "stubs", that is, domains that
   do not provide any transit service for other domains.

   The bulk of Internet traffic will be generated by hosts in these stub
   domains, and thus, the applications running in these hosts will
   determine the traffic service requirements.  We expect application
   diversity encompassing electronic mail, desktop videoconferencing,
   scientific visualization, and distributed simulation, to list a few.
   Many of these applications have strict requirements on loss, delay,
   and throughput.




Steenstrup                                                      [Page 4]

RFC 1478                   IDPR Architecture                   June 1993


   Ensuring that Internet traffic traverses routes that provide the
   required services without violating domain usage restrictions will be
   the task of policy routing in the Internet in the next several years.
   Refer to [1]-[10] for more information on the role of policy routing
   in the Internet.

2.  Approaches to Policy Routing

   In this section, we provide an assessment of candidate approaches to
   policy routing, concentrating on the "distance vector" and "link
   state" alternatives for routing information distribution and route
   generation and on the "hop-by-hop" and "source specified"
   alternatives for data message forwarding.  The IDPR architecture
   supports link state routing information distribution and route
   generation in conjunction with source specified message forwarding.
   We justify these choices for IDPR below.

2.1.  Policy Route Generation

   We present policy route generation from the distance vector
   perspective and from the link state perspective.

2.1.1.  Distance Vector Approach

   Distance vector route generation distributes the computation of a
   single route among multiple routing entities along the route.  Hence,
   distance vector route generation is potentially susceptible to the
   problems of routing loop formation and slow adaptation to changes in
   an internetwork.  However, there exist several techniques that can be
   applied during distance vector route generation to reduce the
   severity of, or even eliminate, these problems.  For information on a
   loop-free, quickly adapting distance vector routing procedure,
   consult [13] and [14].

   During policy route generation, each recipient of a distance vector
   message assesses the acceptability of the associated route and
   determines the set of neighboring domains to which the message should
   be propagated.  In the context of policy routing, both of the
   following conditions are necessary for route acceptability:

   - The route is consistent with at least one transit policy for each
     domain, not including the current routing entity's domain, contained
     in the route.  To enable each recipient of a distance vector message
     to verify consistency of the associated route with the transit
     policies of all constituent domains, each routing entity should