rfc1478.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,339 行 · 第 1/5 页

         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
   to execute the IDPR protocols.

3.2.1.  Path Agents

   Any Internet host can reap the benefits of IDPR, as long as there
   exists a path agent configured to act on its behalf and a means by
   which the host's messages can reach that path agent.  Path agents
   select and set up policy routes for hosts, accounting for service
   requirements.  To obtain a host's service requirements, a path agent
   may either consult its configured IDPR source policy information or
   extract service requirements directly from the host's data messages,
   provided such information is available in these data messages.




Steenstrup                                                     [Page 15]

RFC 1478                   IDPR Architecture                   June 1993


   Separating the path agent functions from the hosts means that host
   software need not be modified to support IDPR.  Moreover, it means
   that a path agent can aggregate onto a single policy route traffic
   from several different hosts, as long as the source domains,
   destination domains, and service requirements are the same for all of
   these host traffic flows.  Policy gateways are the natural choice for
   the entities that perform the path agent functions on behalf of
   hosts, as policy gateways are the only inter-domain connecting points
   recognized by IDPR.

   Each domain administrator determines the set of hosts that its
   domain's path agents will handle.  We expect that a domain
   administrator will normally configure path agents in its domain to
   act on behalf of its domain's hosts only.  However, a path agent can
   be configured to act on behalf of any Internet host.  This
   flexibility permits one domain to act as an IDPR "proxy" for another
   domain.  For example, a small stub domain may wish to have policy
   routing available to a few of its hosts but may not want to set up
   its domain to support all of the IDPR functionality.  The
   administrator of the stub domain can negotiate the proxy function
   with the administrator of another domain, who agrees that its domain
   will provide policy routes on behalf of the stub domain's hosts.

   If a source domain supports IDPR and limits all domain egress points
   to policy gateways, then each message generated by a host in that
   source domain and destined for a host in another domain must pass
   through at least one policy gateway, and hence path agent, in the
   source domain.  A host need not know how to reach any policy gateways
   in its domain; it need only know how to reach a gateway on its own
   local network.  Gateways within the source domain direct inter-domain
   host traffic toward policy gateways, using default routes or routes
   derived from other inter-domain routing procedures.

   If a source domain does not support IDPR and requires an IDPR proxy
   domain to provide its hosts with policy routing, the administrator of
   that source domain must carefully choose the proxy domain.  All
   intervening gateways between hosts in the source domain and path
   agents in the proxy domain forward traffic according to default
   routes or routes derived from other inter-domain routing procedures.
   In order for traffic from hosts in the source domain to reach the
   proxy domain with no special intervention, the proxy domain must lie
   on an existing non-IDPR inter-domain route from the source to the
   destination domain.  Hence, to minimize the knowledge a domain
   administrator must have about inter-domain routes when selecting a
   proxy domain, we recommend that a domain administrator select its
   proxy domain from the set of adjacent domains.





Steenstrup                                                     [Page 16]

RFC 1478                   IDPR Architecture                   June 1993


   In either case, the first policy gateway to receive messages from an
   inter-domain traffic flow originating at the source domain acts as
   the path agent for the host generating that flow.

3.2.2.  IDPR Servers

   IDPR servers are the entities that manage the IDPR databases and that
   respond to queries for information from policy gateways or other
   servers.  Each IDPR server may be a dedicated device, physically
   separate from the policy gateway, or it may be part of the
   functionality of the policy gateway itself.  Separating the server
   functions from the policy gateways reduces the processing and memory
   requirements for and increases the data traffic carrying capacity of
   the policy gateways.

   The following IDPR databases: routing information, route, mapping,
   and configuration, may be distributed hierarchically, with partial
   redundancy throughout the Internet.  This arrangement implies a
   hierarchy of the associated servers, where a server's position in the
   hierarchy determines the extent of its database.  At the bottom of
   the hierarchy are the "local servers" that maintain information
   pertinent to a single domain; at the top of the hierarchy are the
   "global servers" that maintain information pertinent to all domains
   in the Internet.  There may be zero or more levels in between the
   local and global levels.

   Hierarchical database organization relieves most IDPR servers of the
   burden of maintaining information about large portions of the
   Internet, most of which their clients will never request.
   Distributed database organization, with redundancy, allows clients to
   spread queries among IDPR servers, thus reducing the load on any one
   server.  Furthermore, failure to communicate with a given IDPR server
   does not mean the loss of the entire service, as a client may obtain
   the information from another server.  We note that some IDPR
   databases, such as the mapping database, may grow so large that it is
   not feasible to store the entire database at any single server.

   IDPR routing information databases need not be completely consistent
   for proper policy route generation and use, because message
   forwarding along policy routes is completely specified by the source
   path agent.  The absence of a requirement for consistency among IDPR
   routing information databases implies that there is no requirement
   for strict synchronization of these databases.  Such synchronization
   is costly in terms of the message processing and transmission
   bandwidth required.  Nevertheless, each IDPR route server should have
   a query/response mechanism for making its routing information
   database consistent with that of another route server, if necessary.
   A route server uses this mechanism to update its routing information



Steenstrup                                                     [Page 17]

RFC 1478                   IDPR Architecture                   June 1993


   database following detection of a gap or potential error in database
   contents, for example, when the route server returns to service after
   disconnection from the Internet.

   A route server in one domain wishing to communicate with a route
   server in another domain must establish a policy route to the other
   route server's domain.  To generate and establish a policy route, the
   route server must know the other route server's domain, and it must
   have sufficient routing information to construct a route to that
   domain.  As route servers may often intercommunicate in order to
   obtain routing information, one might assume an ensuing deadlock in
   which a route server requires routing information from another route
   server but does not have sufficient mapping and routing information
   to establish a policy route to that route server.  However, such a
   deadlock should seldom persist, if the following IDPR functionality
   is in place:

   - A mechanism that allows a route server to gain access, during route
     server initialization, to the identities of the other route servers
     within its domain.  Using this information, the route server need not
     establish policy routes in order to query these route servers for
     routing information.

   - A mechanism that allows a route server to gain access, during route
     server initialization, to its domain's adjacencies.  Using this
     information, the route server may establish policy routes to the
     adjacent domains in order to query their route servers for routing
     information when none is available within its own domain.

   - Once operational, a route server should collect (memory capacity
     permitting) all the routing information to which it has access.  A
     domain usually does not restrict distribution of its routing
     information but instead distributes its routing information to all
     other Internet domains.  Hence, a route server in a given domain is
     likely to receive routing information from most Internet domains.

   - A mechanism that allows an operational route server to obtain the
     identities of external route servers from which it can obtain routing
     information and of the domains containing these route servers.
     Furthermore, this mechanism should not require mapping server queries.
     Rather, each domain should distribute in its routing information
     messages the identities of all route servers, within its domain, that
     may be queried by clients outside of its domain.

   When a host in one domain wishes to communicate with a host in
   another domain, the path agent in the source domain must establish a
   policy route to a path agent in the destination domain.  However, the
   source path agent must first query a mapping server, to determine the



Steenstrup                                                     [Page 18]

RFC 1478                   IDPR Architecture                   June 1993


   identity of the destination domain.  The queried mapping server may
   in turn contact other mapping servers to obtain a reply.  As with
   route server communication, one might assume an ensuing deadlock in
   which a mapping server requires mapping information from an external
   mapping server but the path agent handling the traffic does not have
   sufficient mapping information to determine the domain of, and hence
   establish a policy route to, that mapping server.

   We have previously described how to minimize the potential for
   deadlock in obtaining routing information.  To minimize the potential
   for deadlock in obtaining mapping information, there should be a
   mechanism that allows a mapping server to gain access, during mapping
   server initialization, to the identities of other mapping servers and
   the domains in which they reside.  Thus, when a mapping server needs
   to query an external mapping server, it knows the identity of that
   mapping server and sends a message.  The path agent handling this
   traffic queries a local mapping server to resolve the identity of the
   external mapping server to the proper domain and then proceeds to
   establish a policy route to that domain.

3.2.3.  Entity Identifiers

   Each domain has a unique identifier within the Internet, specifically
   an ordinal number in the enumeration of Internet domains, determined
   by the Internet Assigned Numbers Authority (IANA) who is responsible
   for maintaining such information.

   Each virtual gateway has a unique local identifier within a domain,
   derived from the adjacent domain's identifier together with the
   virtual gateway's ordinal number within an enumeration of the virtual
   gateways connecting the two domains.  The administrators of both
   domains mutually agree upon the enumeration of the virtual gateways
   within their shared set of virtual gateways; selecting a single
   virtual gateway enumeration that applies in both domains eliminates
   the need to maintain a mapping between separate virtual gateway
   ordinal numbers in each domain.

   Each policy gateway and route server has a unique local identifier
   within its domain, specifically an ordinal number in the domain
   administrator's enumeration of IDPR entities within its domain.  This
   local identifier, when combined with the domain identifier, produces
   a unique identifier within the Internet for the policy gateway or
   route server.

3.3.  Security and Reliability

   The correctness of control information, and in particular routing-
   related information, distributed throughout the Internet is a



Steenstrup                                                     [Page 19]

RFC 1478                   IDPR Architecture                   June 1993


   critical factor affecting the Internet's ability to transport data.
   As the number and heterogeneity of Internet domains increases, so too