rfc1479.txt

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

       o    maximum bandwidth path;

       o    upper bound on monetary cost;

       o    minimum monetary cost path.

   In an internetwork-wide implementation of IDPR, the set of global
   configuration parameters and their syntax and semantics must be
   consistent across all participating domains.  The IANA, responsible
   for establishing the full set of global configuration parameters in
   the Internet, relies on the cooperation of the administrators of all
   participating domains to ensure that the global parameters are
   consistent with the desired transit policies and user service
   requirements of each domain.  Moreover, as the syntax and semantics
   of the global parameters affects the syntax and semantics of the
   corresponding IDPR software, the IANA must carefully define each
   global parameter so that it is unlikely to require future
   modification.

   The IANA provides configured global information to configuration
   servers in all domains participating in IDPR.  Each domain
   administrator uses the configured global information maintained by
   its configuration servers to develop configurations for each IDPR
   entity within its domain.  Each configuration server retains a copy
   of the configuration for each local IDPR entity and also distributes
   the configuration to that entity using, for example, SNMP.






Steenstrup                                                     [Page 16]

RFC 1479                     IDPR Protocol                     July 1993


1.8.1.  Policy Gateway Configuration

   Each policy gateway must contain sufficient configuration information
   to perform its IDPR functions, which subsume those of the path agent.
   These include: validating IDPR control messages; generating and
   distributing virtual gateway connectivity and routing information
   messages to peer, neighbor, and adjacent policy gateways;
   distributing routing information messages to route servers in its
   domain; resolving destination addresses; requesting policy routes
   from route servers; selecting policy routes and initiating path
   setup; ensuring consistency of a path with its domain's transit
   policies; establishing path forwarding information; and forwarding
   IDPR data messages along existing paths.  The necessary configuration
   information includes the following:

   - For each integrity/authentication type, the numeric identifier,
     syntax, and semantics.

   - For each policy gateway and route server in the given domain, the
     numeric identifier and set of addresses or names.

   - For each virtual gateway connected to the given domain, the numeric
     identifier, the numeric identifiers for the constituent peer policy
     gateways, and the numeric identifier for the adjacent domain.

   - For each virtual gateway of which the given policy gateway is a
     member, the numeric identifiers and set of addresses for the
     constituent adjacent policy gateways.

   - For each policy gateway directly-connected and adjacent to the
     given policy gateway, the local connecting interface.

   - For each local route server to which the given policy gateway
     distributes routing information, the numeric identifier.

   - For each source policy applicable to hosts within the given domain,
     the syntax and semantics.

   - For each transit policy applicable to the domain, the numeric
     identifier, syntax, and semantics.

   - For each requested service that may appear within a path setup
     message, the numeric identifier, syntax, and semantics.

   - For each source user class, the numeric identifier, syntax, and
     semantics.





Steenstrup                                                     [Page 17]

RFC 1479                     IDPR Protocol                     July 1993


1.8.2.  Route Server Configuration

   Each route server must contain sufficient configuration information
   to perform its IDPR functions, which subsume those of the path agent.
   These include: validating IDPR control messages; deciphering and
   storing the contents of routing information messages; exchanging
   routing information with other route servers and policy gateways;
   generating policy routes that respect transit policy restrictions and
   source service requirements; distributing policy routes to path
   agents in policy gateways; resolving destination addresses; selecting
   policy routes and initiating path setup; establishing path forwarding
   information; and forwarding IDPR data messages along existing paths.
   The necessary configuration information includes the following:

   - For each integrity/authentication type, the numeric identifier,
     syntax, and semantics.

   - For each policy gateway and route server in the given domain, the
     numeric identifier and set of addresses or names.

   - For each source policy applicable to hosts within the given domain,
     the syntax and semantics.

   - For access restriction that may be advertised in transit
     policies, the numeric identifier, syntax, and semantics.

   - For each offered service that may be advertised in transit policies,
     the numeric identifier, syntax, and semantics.

   - For each requested service that may appear within a path setup
     message, the numeric identifier, syntax, and semantics.

   - For each source user class, the numeric identifier, syntax, and
     semantics.

2.  Control Message Transport Protocol

   IDPR control messages convey routing-related information that
   directly affects the policy routes generated and the paths set up
   across the Internet.  Errors in IDPR control messages can have
   widespread, deleterious effects on inter-domain policy routing, and
   so the IDPR protocols have been designed to minimize loss and
   corruption of control messages.  For every control message it
   transmits, each IDPR protocol expects to receive notification as to
   whether the control message successfully reached the intended IDPR
   recipient.  Moreover, the IDPR recipient of a control message first
   verifies that the message appears to be well-formed, before acting on
   its contents.



Steenstrup                                                     [Page 18]

RFC 1479                     IDPR Protocol                     July 1993


   All IDPR protocols use the Control Message Transport Protocol (CMTP),
   a connectionless, transaction-based transport layer protocol, for
   communication with intended recipients of control messages.  CMTP
   retransmits unacknowledged control messages and applies integrity and
   authenticity checks to received control messages.

   There are three types of CMTP messages:

   DATAGRAM:
        Contains IDPR control messages.

   ACK: Positive acknowledgement in response to a DATAGRAM message.

   NAK: Negative acknowledgement in response to a DATAGRAM message.

   Each CMTP message contains several pieces of information supplied by
   the sender that allow the recipient to test the integrity and
   authenticity of the message.  The set of integrity and authenticity
   checks performed after CMTP message reception are collectively
   referred to as "validation checks" and are described in section 2.3.

   When we first designed the IDPR protocols, CMTP as a distinct
   protocol did not exist.  Instead, CMTP-equivalent functionality was
   embedded in each IDPR protocol.  To provide a cleaner implementation,
   we later decided to provide a single transport protocol that could be
   used by all IDPR protocols.  We originally considered using an
   existing transport protocol, but rejected this approach for the
   following reasons:

   - The existing reliable transport protocols do not provide all of the
     validation checks, in particular the timestamp and authenticity
     checks, required by the IDPR protocols.  Hence, if we were to use
     one of these protocols, we would still have to provide a separate
     protocol on top of the transport protocol to force retransmission of
     IDPR messages that failed to pass the required validation checks.

   - Many of the existing reliable transport protocols are window-based
     and hence can result in increased message delay and resource use
     when, as is the case with IDPR, multiple independent messages use
     the same transport connection.  A single message experiencing
     transmission problems and requiring retransmission can prevent the
     window from advancing, forcing all subsequent messages to queue
     behind it.  Moreover, many of the window-based protocols do not
     support selective retransmission of failed messages but instead
     require retransmission of not only the failed message but also all
     preceding messages within the window.

   For these reasons, we decided against using an existing transport



Steenstrup                                                     [Page 19]

RFC 1479                     IDPR Protocol                     July 1993


   protocol and in favor of developing CMTP.

2.1.  Message Transmission

   At the transmitting entity, when an IDPR protocol is ready to issue a
   control message, it passes a copy of the message to CMTP; it also
   passes a set of parameters to CMTP for inclusion in the CMTP header
   and for proper CMTP message handling.  In turn, CMTP converts the
   control message and associated parameters into a DATAGRAM by
   prepending the appropriate header to the control message.  The CMTP
   header contains several pieces of information to aid the message
   recipient in detecting errors (see section 2.4).  Each IDPR protocol
   can specify all of the following CMTP parameters applicable to its
   control message:

   -   IDPR protocol and message type.

   -   Destination.

   -   Integrity/authentication scheme.

   -   Timestamp.

   -   Maximum number of transmissions allotted.

   -   Retransmission interval in microseconds.

   One of these parameters, the timestamp, can be specified directly by
   CMTP as the internal clock time at which the message is transmitted.
   However, two of the IDPR protocols, namely flooding and path control,
   themselves require message generation timestamps for proper protocol
   operation.  Thus, instead of requiring CMTP to pass back a timestamp
   to an IDPR protocol, we simplify the service interface between CMTP
   and the IDPR protocols by allowing an IDPR protocol to specify the
   timestamp in the first place.

   Using the control message and accompanying parameters supplied by the
   IDPR protocol, CMTP constructs a DATAGRAM, adding to the header
   CMTP-specific parameters.  In particular, CMTP assigns a "transaction
   identifier" to each DATAGRAM generated, which it uses to associate
   acknowledgements with DATAGRAM messages.  Each DATAGRAM recipient
   includes the received transaction identifier in its returned ACK or
   NAK, and each DATAGRAM sender uses the transaction identifier to
   match the received ACK or NAK with the original DATAGRAM.

   A single DATAGRAM, for example a routing information message or a
   path control message, may be handled by CMTP at many different policy
   gateways.  Within a pair of consecutive IDPR entities, the DATAGRAM



Steenstrup                                                     [Page 20]

RFC 1479                     IDPR Protocol                     July 1993


   sender expects to receive an acknowledgement from the DATAGRAM
   recipient.  However, only the IDPR entity that actually generated the
   original CMTP DATAGRAM has control over the transaction identifier,
   because that entity may supply a digital signature that covers the
   entire DATAGRAM.  The intermediate policy gateways that transmit the
   DATAGRAM do not change the transaction identifier.  Nevertheless, at
   each DATAGRAM recipient, the transaction identifier must uniquely
   distinguish the DATAGRAM so that only one acknowledgement from the
   next DATAGRAM recipient matches the original DATAGRAM.  Therefore,
   the transaction identifier must be globally unique.

   The transaction identifier consists of the numeric identifiers for
   the domain and IDPR entity (policy gateway or route server) issuing
   the original DATAGRAM, together with a 32-bit local identifier
   assigned by CMTP operating within that IDPR entity.  We recommend
   implementing the 32-bit local identifier either as a simple counter
   incremented for each DATAGRAM generated or as a fine granularity
   clock.  The former always guarantees uniqueness of transaction
   identifiers; the latter guarantees uniqueness of transaction
   identifiers, provided the clock granularity is finer than the minimum
   possible interval between DATAGRAM generations and the clock wrapping
   period is longer than the maximum round-trip delay to and from any
   internetwork destination.

   Before transmitting a DATAGRAM, CMTP computes the length of the
   entire message, taking into account the prescribed