rfc1477.txt

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

Network Working Group                                     M. Steenstrup
Request for Comments: 1477                 BBN Systems and Technologies
                                                              July 1993


                      IDPR as a Proposed Standard

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.

1.  Introduction

   This document contains a discussion of inter-domain policy routing
   (IDPR), including an overview of functionality and a discussion of
   experiments.  The objective of IDPR is to construct and maintain
   routes between source and destination administrative domains, that
   provide user traffic with the services requested within the
   constraints stipulated for the domains transited.

   Four documents describe IDPR in detail:

      M. Steenstrup.  An architecture for inter-domain policy routing.
      RFC 1478.  July 1993.

      M. Steenstrup.  Inter-domain policy routing protocol
      specification: version 1.  RFC 1479.  July 1993.

      H. Bowns and M. Steenstrup.  Inter-domain policy routing
      configuration and usage.  Work in Progress.  July 1991.

      R. Woodburn.  Definitions of managed objects for inter-domain
      policy routing (version 1).  Work in Progress.  March 1993.

   This is a product of the Inter-Domain Policy Routing Working Group of
   the Internet Engineering Task Force (IETF).

2.  The Internet Environment

   As data communications technologies evolve and user populations grow,
   the demand for internetworking increases.  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
   prepare for the Internet of five to ten years in the future.



Steenstrup                                                      [Page 1]

RFC 1477                         IDPR                          July 1993


   Internet connectivity has increased along with the number of
   component networks.  Internetworks 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 that selects
   the intra-domain routing procedures and addressing schemes, specifies
   service restrictions for transit traffic, and defines service
   requirements for locally-generated traffic.

   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, 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 any other domains
   but that connect directly to one or more transit domains.

   The bulk of Internet traffic will be generated by hosts in the 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, for example.
   Many of these applications have strict requirements on loss, delay,
   and throughput.

   In such a large and heterogeneous Internet, the routing procedures
   must be capable of ensuring that traffic is forwarded along routes
   that offer the required services without violating domain usage
   restrictions.  We believe that IDPR meets this goal; it has been
   designed to accommodate an Internet comprising O(10,000)
   administrative domains with diverse service offerings and
   requirements.




Steenstrup                                                      [Page 2]

RFC 1477                         IDPR                          July 1993


3.  An Overview of IDPR

   IDPR generates, establishes, and maintains "policy routes" that
   satisfy the service requirements of the users and respect the service
   restrictions of the transit domains.  Policy routes are constructed
   using information about the services offered by and the connectivity
   between administrative domains and information about the services
   requested by the users.

3.1  Policies

   With IDPR, each domain administrator sets "transit policies" that
   dictate how and by whom the resources in 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 session time.

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

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

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

   - Monetary cost: e.g., acceptable cost per byte, message, or session
     time.

3.2  Functions

   The basic IDPR functions include:

   - Collecting and distributing routing information, i.e., domain
     transit policy and connectivity information.  IDPR uses link state
     routing information distribution, so that each source domain may
     obtain routing information about all other domains.

   - Generating and selecting policy routes based on the routing
     information distributed and on source policy information.  IDPR
     gives each source domain complete control over the routes it
     generates.




Steenstrup                                                      [Page 3]

RFC 1477                         IDPR                          July 1993


   - Setting up paths across the Internet, using the policy routes
     generated.

   - Forwarding messages across and between administrative domains along
     the established paths.  IDPR uses source-specified message
     forwarding, giving each source domain complete control over the
     paths traversed by its hosts' inter-domain traffic.

   - Maintaining databases of routing information, inter-domain policy
     routes, forwarding information, and configuration information.

3.3  Entities

   Several different entities are responsible for performing the IDPR
   functions:

   - "Policy gateways", the only IDPR-recognized connecting points
     between adjacent domains, collect and distribute routing
     information, participate in path setup, maintain forwarding
     information databases, and forward data messages along established
     paths.

   - "Path agents", resident within policy gateways, act on behalf of
     hosts to select policy routes, to set up and manage paths, and to
     maintain forwarding information databases.  Any Internet host can
     reap the benefits of IDPR, as long as there exists a path agent
     willing to act on its behalf and a means by which the host's
     messages can reach that path agent.

   - Special-purpose servers maintain all other IDPR databases as
     follows:

      o  Each "route server" is responsible for both its database of
         routing information, including domain connectivity and transit
         policy information, and its database of policy routes.  Also,
         each route server generates policy routes on behalf of its
         domain, using entries from its routing information database
         and using source policy information supplied through
         configuration or obtained directly from the path agents.  A
         route server may reside within a policy gateway, or it may
         exist as an autonomous entity.  Separating the route server
         functions from the policy gateways frees the policy gateways
         from both the memory intensive task of routing information
         database and route database maintenance and the
         computationally intensive task of route generation.

      o  Each "mapping server" is responsible for its database of
         mappings that resolve Internet names and addresses to



Steenstrup                                                      [Page 4]

RFC 1477                         IDPR                          July 1993


         administrative domains.  The mapping server function can be
         easily integrated into an existing name service such as the
         DNS.

      o  Each "configuration server" is responsible for its database of
         configured information that applies to policy gateways, path
         agents, and route servers in the given administrative domain.
         Configuration information for a given domain includes source
         and transit policies and mappings between local IDPR entities
         and their addresses.  The configuration server function can be
         easily integrated into a domain's existing network management
         system.

3.4  Message Handling