rfc1478.txt

中、英文RFC文档大全打包下载完全版 .

   With hop-by-hop message forwarding, each routing entity makes an
   independent forwarding decision based on a message's source,
   destination, and requested services and on information contained in
   the entity's forwarding information database.  Hop-by-hop message
   forwarding follows a source-selected policy route only if all routing
   entities along the route have consistent routing information and make
   consistent use of this information when generating and selecting



Steenstrup                                                     [Page 10]

RFC 1478                   IDPR Architecture                   June 1993


   policy routes and when establishing forwarding information.  In
   particular, all domains along the route must have consistent
   information about the source domain's source policies and consistent,
   but not necessarily complete, information about transit policies and
   domain adjacencies within the Internet.  In general, this implies
   that each domain should have knowledge of all other domains' source
   policies, transit policies, and domain adjacencies.

   When hop-by-hop message forwarding is applied in the presence of
   inconsistent routing information, the actual route traversed by data
   messages not only may differ from the route selected by the source
   but also may contain loops.  In the policy routing context, private
   source policies and restricted distribution of routing information
   are two potential causes of routing information inconsistencies among
   domains.  Moreover, we expect routing information inconsistencies
   among domains in a large Internet, independent of whether the
   Internet supports policy routing, as some domains may not want or may
   not be able to store routing information from the entire Internet.

2.3.1.1.  A Clarification

   In a previous draft, we presented the following example which results
   in persistent routing loops, when hop-by-hop message forwarding is
   used in conjunction with distance vector routing information
   distribution and route selection.  Consider the sequence of events:

   - AD X receives a distance vector message containing a route to AD Z,
     which does not include AD Y.  AD X selects and distributes this route
     as its primary route to AD Z.

   - AD Y receives a distance vector message containing a route to AD Z,
     which does not include AD X.  AD Y selects and distributes this route
     as its primary route to AD Z.

   - AD X eventually receives the distance vector message containing the
     route to AD Z, which includes AD Y but not AD X.  AD X prefers this
     route over its previous route to AD Z and selects this new route as
     its primary route to AD Z.

   - AD Y eventually receives the distance vector message containing the
     route to AD Z, which includes AD X but not AD Y.  AD Y prefers this
     route over its previous route to AD Z and selects this new route as
     its primary route to AD Z.

   Thus, AD X selects a route to AD Z that includes AD Y, and AD Y
   selects a route to AD Z that includes AD X.





Steenstrup                                                     [Page 11]

RFC 1478                   IDPR Architecture                   June 1993


   Suppose that all domains along the route selected by AD X, except for
   AD Y, make forwarding decisions consistent with AD X's route, and
   that all domains along the route selected by AD Y, except for AD X,
   make forwarding decisions consistent with AD Y's route.  Neither AD
   X's selected route nor AD Y's selected route contains a loop.
   Nevertheless, data messages destined for AD Z and forwarded to either
   AD X or AD Y will continue to circulate between AD X and AD Y, until
   there is a route change.  The reason is that AD X and AD Y have
   conflicting notions of the route to AD Z, with each domain existing
   as a hop on the other's route.

   We note that while BGP-3 [8] is susceptible to such routing loops,
   BGP-4 [9] is not.  We thank Tony Li and Yakov Rekhter for their help
   in clarifying this difference between BGP-3 and BGP-4.

2.3.2.  Source Specified Approach

   With source specified message forwarding, the source domain dictates
   the data message forwarding decisions to the routing entities in each
   intermediate domain, which then forward data messages according to
   the source specification.  Thus, the source domain ensures that any
   data message originating within it follows its selected routes.

   For source specified message forwarding, each data message must carry
   either an entire source specified route or a path identifier.
   Including the complete route in each data message incurs a per
   message transmission and processing cost for transporting and
   interpreting the source route.  Using path identifiers does not incur
   these costs.  However, to use path identifiers, the source domain
   must initiate, prior to data message forwarding, a path setup
   procedure that forms an association between the path identifier and
   the next hop in the routing entities in each domain along the path.
   Thus, path setup may impose an initial delay before data message
   forwarding can begin.

   We have selected source specified message forwarding for IDPR data
   messages for the following reasons:

   - Source specified message forwarding respects the source policies of
     the source domain, regardless of whether intermediate domains along
     the route have knowledge of these source policies.

   - Source specified message forwarding is loop-free, regardless of
     whether the all domains along the route maintain consistent routing
     information.

   Also, we have chosen path identifiers over complete routes, to affect
   source specified message forwarding, because of the reduced



Steenstrup                                                     [Page 12]

RFC 1478                   IDPR Architecture                   June 1993


   transmission and processing cost per data message.

3.  The IDPR Architecture

   We now present the architecture for IDPR, including a description of
   the IDPR functions, the entities that perform these functions, and
   the features of IDPR that aid in accommodating Internet growth.

3.1.  IDPR Functions

   Inter-domain policy routing comprises the following functions:

   - Collecting and distributing routing information including domain
     transit policies and inter-domain connectivity.

   - Generating and selecting policy routes based on the routing
     information distributed and on the source policies configured or
     requested.

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

   - Forwarding messages across and between domains along the established
     paths.

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

3.2.  IDPR Entities

   From the perspective of IDPR, the Internet comprises administrative
   domains connected by "virtual gateways" (see below), which are in
   turn connected by intra-domain routes supporting the transit policies
   configured by the domain administrators.  Each domain administrator
   defines the set of transit policies that apply across its domain and
   the virtual gateways between which each transit policy applies.
   Several different transit policies may be configured for the intra-
   domain routes connecting a pair of virtual gateways.  Moreover, a
   transit policy between two virtual gateways may be directional.  That
   is, the transit policy may apply to traffic flowing in one direction,
   between the virtual gateways, but not in the other direction.

   Virtual gateways (VGs) are the only connecting points recognized by
   IDPR between adjacent administrative domains.  Each virtual gateway
   is actually a collection of directly-connected "policy gateways" (see
   below) in two adjacent domains, whose existence has been sanctioned
   by the administrators of both domains.  Domain administrators may
   agree to establish more than one virtual gateway between their



Steenstrup                                                     [Page 13]

RFC 1478                   IDPR Architecture                   June 1993


   domains.  For example, if two domains are to be connected at two
   geographically distant locations, the domain administrators may wish
   to preserve these connecting points as distinct at the inter-domain
   level, by establishing two distinct virtual gateways.

   Policy gateways (PGs) are the physical gateways within a virtual
   gateway.  Each policy gateway forwards transit traffic according to
   the service restrictions stipulated by its domain's transit policies
   applicable to its virtual gateway.  A single policy gateway may
   belong to multiple virtual gateways.  Within a domain, two policy
   gateways are "neighbors" if they are in different virtual gateways.
   Within a virtual gateway, two policy gateways are "peers" if they are
   in the same domain and are "adjacent" if they are in different
   domains.  Peer policy gateways must be able to communicate over
   intra-domain routes that support the transit policies that apply to
   their virtual gateways.  Adjacent policy gateways are "directly
   connected" if they are the only Internet addressable entities
   attached to the connecting medium.  Note that this definition implies
   that not only point-to-point links but also multiaccess networks may
   serve as direct connections between adjacent policy gateways.

   Combining multiple policy gateways into a single virtual gateway
   affords three advantages:

   - A reduction in the amount of IDPR routing information that must be
     distributed and maintained throughout the Internet.

   - An increase in the reliability of IDPR routes through redundancy of
     physical connections between domains.

   - An opportunity for load sharing of IDPR traffic among policy
     gateways.

   Several different entities are responsible for performing the IDPR
   functions:

   - Policy gateways collect and distribute routing information,
     participate in path setup, forward data messages along established
     paths, and maintain forwarding information databases.

   - "Path agents" act on behalf of hosts to select policy routes, to set
     up and manage paths, and to maintain forwarding information
     databases.

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





Steenstrup                                                     [Page 14]

RFC 1478                   IDPR Architecture                   June 1993


      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 source policy information supplied through configuration
        or obtained directly from the path agents.

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

      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.
         The configuration information for a given domain includes
         source and transit policies and mappings between local IDPR
         entities and their Internet addresses.

   To maximize IDPR's manageability, one should embed all of IDPR's
   required functionality within the IDPR protocols and procedures.
   However, to minimize duplication of implementation effort, one should
   take advantage of required functionality already provided by
   mechanisms external to IDPR.  Two such cases are the mapping server
   functionality and the configuration server functionality.  The
   functions of the mapping server can be integrated into an existing
   name service such as the DNS, and the functions of the configuration
   server can be integrated into the domain's existing network
   management system.

   Within the Internet, only policy gateways, path agents, and route
   servers must be able to generate, recognize, and process IDPR
   messages.  The existence of IDPR is invisible to all other gateways
   and hosts.  Mapping servers and configuration servers perform
   necessary but ancillary functions for IDPR, and they are not required