rfc1479.txt

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

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

1.3.1.  IDPR 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, forward data messages along established
   paths, and maintain forwarding information databases.

   "Path agents", resident within policy gateways and within "route
   servers" (see below), 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 configured to act on its behalf and a
   means by which the host's messages can reach the path agent.
   Specifically, a path agent in one domain may be configured to act on
   behalf of hosts in another domain.  In this case, the path agent's
   domain is an IDPR "proxy" for the hosts' domain.

   Route servers maintain both the routing information database and the
   route database, and they generate policy routes using the routing
   information collected and the source policies requested by 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 database (routing information and route)
   maintenance and the computationally intensive task of route
   generation.  Route servers, like policy gateways, each have a unique
   numeric identifier within their domain, assigned by the domain
   administrator.

   Given the size of the current Internet, each policy gateway can
   perform the route server functions, in addition to its message
   forwarding functions, with little or no degradation in message
   forwarding performance.  Aggregating the routing functions into
   policy gateways simplifies implementation; one need only install IDPR
   protocols in policy gateways.  Moreover, it simplifies communication
   between routing functions, as all functions reside within each policy
   gateway.  As the Internet grows, the memory and processing required
   to perform the route server functions may become a burden for the
   policy gateways.  When this happens, each domain administrator should



Steenstrup                                                      [Page 6]

RFC 1479                     IDPR Protocol                     July 1993


   separate the route server functions from the policy gateways in its
   domain.

   "Mapping servers" maintain the database of mappings that resolve
   Internet names and addresses to domain identifiers.  Each host is
   contained within a domain and is associated with a proxy domain which
   may be identical with the host's domain.  The mapping server function
   will be integrated into the existing DNS name service (see [6]) and
   will provide mappings between a host and its local and proxy domains.

   "Configuration servers" maintain the databases of configured
   information that apply to IDPR entities within their domains.
   Configuration information for a given domain includes transit
   policies (i.e., service offerings and restrictions), source policies
   (i.e., service requirements), and mappings between local IDPR
   entities and their names and addresses.  The configuration server
   function will be integrated into a domain's existing network
   management system (see [7]-[8]).

1.4.  Policy Semantics

   The source and transit policies supported by IDPR are intended to
   accommodate a wide range of services available throughout the
   Internet.  We describe the semantics of these policies, concentrating
   on the access restriction aspects.  To express these policies in this
   document, we have chosen to use a syntactic variant of Clark's policy
   term notation [1].  However, we provide a more succinct syntax (see
   [7]) for actually configuring source and transit policies.

1.4.1.  Source Policies

   Each source policy takes the form of a collection of sets as follows:

   Applicable Sources and Destinations:
      {((H(1,1),s(1,1)),...,(H(1,f1),s(1,f1))),...,((H(n,1),s(n,1)),...,
      (H(n,fn),s(n,fn)))}: The set of groups of source/destination
      traffic flows to which the source policy applies.  Each traffic
      flow group ((H(i,1),s(i,1)),...,(H(i,fi),s(i,fi))) contains a set
      of source hosts and corresponding destination hosts.  Here, H(i,j)
      represents a host, and s(i,j), an element of {SOURCE,
      DESTINATION}, represents an indicator of whether H(i,j) is to be
      considered as a source or as a destination.

   Domain Preferences: {(AD(1),x(1)),...,(AD(m),x(m))}: The set of
      transit domains that the traffic flows should favor, avoid, or
      exclude.  Here, AD(i) represents a domain, and x(i), an element of
      {FAVOR, AVOID, EXCLUDE}, represents an indicator of whether routes
      including AD(i) are to be favored, avoided if possible, or



Steenstrup                                                      [Page 7]

RFC 1479                     IDPR Protocol                     July 1993


      unconditionally excluded.

   UCI: The source user class for the traffic flows listed.

   RequestedServices: The set of requested services not related to
      access restrictions, i.e., service quality and monetary cost.

   When selecting a route for a traffic flow from a source host H(i,j)
   to a destination host H(i,k), where 1 < or = i < or = n and 1 < or =
   j, k < or = fi, the path agent (see section 1.3.1) must honor the
   source policy such that:

   - For each domain, AD(p), contained in the route, AD(p) is not equal
     to any AD(k), such that 1 < or = k < or = m and x(k) = EXCLUDE.

   - The route provides the services listed in the set Requested
     Services.

1.4.2.  Transit Policies

   Each transit policy takes the form of a collection of sets as
   follows:

   Source/Destination Access Restrictions:
      {((H(1,1),AD(1,1),s(1,1)),...,(H(1,f1),AD(1,f1),s(1,f1))),...,
      ((H(n,1),AD(n,1),s(n,1)),...,(H(n,fn),AD(n,fn),s(n,fn)))}: The set
      of groups of source and destination hosts and domains to which the
      transit policy applies.  Each domain group
      ((H(i,1),AD(i,1),s(i,1)),...,(H(i,fi),AD(i,fi),s(i,fi))) contains
      a set of source and destination hosts and domains such that this
      transit domain will carry traffic from each source listed to each
      destination listed.  Here, H(i,j) represents a set of hosts,
      AD(i,j) represents a domain containing H(i,j), and s(i,j), a
      subset of {SOURCE, DESTINATION}, represents an indicator of
      whether (H(i,j),AD(i,j)) is to be considered as a set of sources,
      destinations, or both.

   Temporal Access Restrictions: The set of time intervals during which
      the transit policy applies.

   User Class Access Restrictions: The set of user classes to which the
      transit policy applies.

   Offered Services: The set of offered services not related to access
      restrictions, i.e., service quality and monetary cost.






Steenstrup                                                      [Page 8]

RFC 1479                     IDPR Protocol                     July 1993


   Virtual Gateway Access Restrictions:
      {((VG(1,1),e(1,1)),...,(VG(1,g1),e(1,g1))),...,((VG(m,1),e(m,1)),
      gateways to which the transit policy applies.  Each virtual
      gateway group ((VG(i,1),e(i,1)),...,(VG(i,gi),e(i,gi))) contains a
      set of domain entry and exit points such that each entry virtual
      gateway can reach (barring an intra-domain routing failure) each
      exit virtual gateway via an intra-domain route supporting the
      transit policy.  Here, VG(i,j) represents a virtual gateway, and
      e(i,j), a subset of {ENTRY, EXIT}, represents an indicator of
      whether VG(i,j) is to be considered as a domain entry point, exit
      point, or both.

   The domain advertising such a transit policy will carry traffic from
   any host in the set H(i,j) in AD(i,j) to any host in the set H(i,k)
   in AD(i,k), where 1 < or = i < or = n and 1 < or = j, k < or = fi,
   provided that:

   - SOURCE is an element of s(i,j).

   - DESTINATION is an element of s(i,k).

   - Traffic from H(i,j) enters the domain during one of the intervals
     in the set Temporal Access Restrictions.

   - Traffic from H(i,j) carries one of the user class identifiers in
     the set User Class Access Restrictions.

   - Traffic from H(i,j) enters via any VG(u,v) such that ENTRY is an
     element of e(u,v), where 1 < or = u < or = m and 1 < or = v < or =
     gu.

   - Traffic to H(i,k) leaves via any VG(u,w) such that EXIT is an
     element of e(u,w), where 1 < or = w < or = gu.

1.5.  IDPR Message Encapsulation

   There are two kinds of IDPR messages:

   - "Data messages" containing user data generated by hosts.

   - "Control messages" containing IDPR protocol-related control
     information generated by policy gateways and route servers.

   Within an internetwork, only policy gateways and route servers are
   able to generate, recognize, and process IDPR messages.  The
   existence of IDPR is invisible to all other gateways and hosts,
   including mapping servers and configuration servers.  Mapping servers
   and configuration servers perform necessary but ancillary functions



Steenstrup                                                      [Page 9]

RFC 1479                     IDPR Protocol                     July 1993


   for IDPR, and thus they are not required to handle IDPR messages.

   An IDPR entity places IDPR-specific information in each IDPR control
   message it originates; this information is significant only to
   recipient IDPR entities.  Using "encapsulation" across each domain,
   an IDPR message tunnels from source to destination across an
   internetwork through domains that may employ disparate intra-domain
   addressing schemes and routing procedures.

   As an alternative to encapsulation, we had considered embedding IDPR
   in IP, as a set of IP options.  However, this approach has the
   following disadvantages:

   - Only domains that support IP would be able to participate in IDPR;
     domains that do not support IP would be excluded.

   - Each gateway, policy or other, in a participating domain would at
     least have to recognize the IDPR option, even if it did not execute
     the IDPR protocols.  However, most commercial routers are not
     optimized for IP options processing, and so IDPR message handling
     might require significant processing at each gateway.

   - For some IDPR protocols, in particular path control, the size
     restrictions on IP options would preclude inclusion of all of the
     necessary protocol-related information.

   For these reasons, we decided against the IP option approach and in
   favor of encapsulation.

   An IDPR message travels from source to destination between
   consecutive policy gateways.  Each policy gateway encapsulates the
   IDPR message with information, for example an IP header, that will
   enable the message to reach the next policy gateway.  Note that the
   encapsulating header and the IDPR-specific information may increase
   the message size beyond the MTU of the given domain.  However,
   message fragmentation and reassembly is the responsibility of the
   protocol, for example IP, that encapsulates IDPR messages for
   transport between successive policy gateways; it is not currently the
   responsibility of IDPR itself.

   A policy gateway, when forwarding an IDPR message to a peer or a
   neighbor policy gateway, encapsulates the message in accordance with
   the addressing scheme and routing procedure of the given domain and
   indicates in the protocol field of the encapsulating header that the
   message is indeed an IDPR message.  Intermediate gateways between the
   two policy gateways forward the IDPR message as they would any other
   message, using the information in the encapsulating header.  Only the
   recipient policy gateway interprets the protocol field, strips off



Steenstrup                                                     [Page 10]

RFC 1479                     IDPR Protocol                     July 1993


   the encapsulating header, and processes the IDPR message.

   A policy gateway, when forwarding an IDPR message to a directly-
   connected adjacent policy gateway, encapsulates the message in
   accordance with the addressing scheme of the entities within the
   virtual gateway and indicates in the protocol field of the
   encapsulating header that the message is indeed an IDPR message.  The
   recipient policy gateway strips off the encapsulating header and
   processes the IDPR message.  We recommend that the recipient policy
   gateway perform the following validation check of the encapsulating