rfc1479.txt

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

   integrity/authentication scheme, and then computes the
   integrity/authentication value over the whole message.  CMTP includes
   both of these quantities, which are crucial for checking message
   integrity and authenticity at the recipient, in the DATAGRAM header.
   After sending a DATAGRAM, CMTP saves a copy and sets an associated
   retransmission timer, as directed by the IDPR protocol parameters.
   If the retransmission timer fires and CMTP has received neither an
   ACK nor a NAK for the DATAGRAM, CMTP then retransmits the DATAGRAM,
   provided this retransmission does not exceed the transmission
   allotment.  Whenever a DATAGRAM exhausts its transmission allotment,
   CMTP discards the DATAGRAM, informs the IDPR protocol that the
   control message transmission was not successful, and logs the event
   for network management.  In this case, the IDPR protocol may either
   resubmit its control message to CMTP, specifying an alternate
   destination, or discard the control message altogether.










Steenstrup                                                     [Page 21]

RFC 1479                     IDPR Protocol                     July 1993


2.2.  Message Reception

   At the receiving entity, when CMTP obtains a DATAGRAM, it takes one
   of the following actions, depending upon the outcome of the message
   validation checks:

   - The DATAGRAM passes the CMTP validation checks.  CMTP then delivers
     the DATAGRAM with enclosed IDPR control message, to the appropriate
     IDPR protocol, which in turn applies its own integrity checks to
     the control message before acting on the contents.  The recipient
     IDPR protocol, except in one case, directs CMTP to generate an ACK
     and return the ACK to the sender.  That exception is the up/down
     protocol (see section 3.2) which determines reachability of
     adjacent policy gateways and does not use CMTP ACK messages to
     notify the sender of message reception.  Instead, the up/down
     protocol messages themselves carry implicit information about
     message reception at the adjacent policy gateway.  In the cases
     where the recipient IDPR protocol directs CMTP to generate an ACK,
     it may pass control information to CMTP for inclusion in the ACK,
     depending on the contents of the original IDPR control message.
     For example, a route server unable to fill a request for routing
     information may inform the requesting IDPR entity, through an ACK
     for the initial request, to place its request elsewhere.

   - The DATAGRAM fails at least one of the CMTP validation checks.
     CMTP then generates a NAK, returns the NAK to the sender, and
     discards the DATAGRAM, regardless of the type of IDPR control
     message contained in the DATAGRAM.  The NAK indicates the nature of
     the validation failure and serves to help the sender establish
     communication with the recipient.  In particular, the CMTP NAK
     provides a mechanism for negotiation of IDPR version and
     integrity/authentication scheme, two parameters crucial for
     establishing communication between IDPR entities.

   Upon receiving an ACK or a NAK, CMTP immediately discards the message
   if at least one of the validation checks fails or if it is unable to
   locate the associated DATAGRAM.  CMTP logs the latter event for
   network management.  Otherwise, if all of the validation checks pass
   and if it is able to locate the associated DATAGRAM, CMTP clears the
   associated retransmission timer and then takes one of the following
   actions, depending upon the message type:

   - The message is an ACK.  CMTP discards the associated DATAGRAM and
     delivers the ACK, which may contain IDPR control information, to
     the appropriate IDPR protocol.

   - The message is a NAK.  If the associated DATAGRAM has exhausted its
     transmission allotment, CMTP discards the DATAGRAM, informs the



Steenstrup                                                     [Page 22]

RFC 1479                     IDPR Protocol                     July 1993


     appropriate IDPR protocol that the control message transmission was
     not successful, and logs the event for network management.
     Otherwise, if the associated DATAGRAM has not yet exhausted its
     transmission allotment, CMTP first checks its copy of the DATAGRAM
     against the failure indication contained in the NAK.  If its
     DATAGRAM copy appears to be intact, CMTP retransmits the DATAGRAM
     and sets the associated retransmission timer.  However, if its
     DATAGRAM copy appears to be corrupted, CMTP discards the DATAGRAM,
     informs the IDPR protocol that the control message transmission was
     not successful, and logs the event for network management.

2.3.  Message Validation

   On every CMTP message received, CMTP performs a set of validation
   checks to test message integrity and authenticity.  The order in
   which these tests are executed is important.  CMTP must first
   determine if it can parse enough of the message to compute the
   integrity/authentication value.  (Refer to section 2.4 for a
   description of CMTP message formats.)  Then, CMTP must immediately
   compute the integrity/authentication value before checking other
   header information.  An incorrect integrity/authentication value
   means that the message is corrupted, and so it is likely that CMTP
   header information is incorrect.  Checking specific header fields
   before computing the integrity/authentication value not only may
   waste time and resources, but also may lead to incorrect diagnoses of
   a validation failure.

   The CMTP validation checks are as follows:

   - CMTP verifies that it can recognize both the control message
     version type contained in the header.  Failure to recognize either
     one of these values means that CMTP cannot continue to parse the
     message.

   - CMTP verifies that it can recognize and accept the
     integrity/authentication type contained in the header; no
     integrity/authentication is not an acceptable type for CMTP.

   - CMTP computes the integrity/authentication value and verifies that
     it equals the integrity/authentication value contained in the
     header.  For key-based integrity/authentication schemes, CMTP may
     use the source domain identifier contained in the CMTP header to
     index the correct key.  Failure to index a key means that CMTP
     cannot compute the integrity/authentication value.

   - CMTP computes the message length in bytes and verifies that it
     equals the length value contained in the header.




Steenstrup                                                     [Page 23]

RFC 1479                     IDPR Protocol                     July 1993


   - CMTP verifies that the message timestamp is in the acceptable
     range.  The message should be no more recent than cmtp_new (300)
     seconds ahead of the entity's current internal clock time.  In this
     document, when we present an IDPR system configuration parameter,
     such as cmtp_new, we usually follow it with a recommended value in
     parentheses.  The cmtp_new value allows some clock drift between
     IDPR entities.  Moreover, each IDPR protocol has its own limit on
     the maximum age of its control messages.  The message should be no
     less recent than a prescribed number of seconds behind the
     recipient entity's current internal clock time.  Hence, each IDPR
     protocol performs its own message timestamp check in addition to
     that performed by CMTP.

   - CMTP verifies that it can recognize the IDPR protocol designated
     for the enclosed control message.

   Whenever CMTP encounters a failure while performing any of these
   validation checks, it logs the event for network management.  If the
   failure occurs on a DATAGRAM, CMTP immediately generates a NAK
   containing the reason for the failure, returns the NAK to the sender,
   and discards the DATAGRAM message.  If the failure occurs on an ACK
   or a NAK, CMTP discards the ACK or NAK message.

2.4.  CMTP Message Formats

   In designing the format of IDPR control messages, we have attempted
   to strike a balance between efficiency of link bandwidth usage and
   efficiency of message processing.  In general, we have chosen compact
   representations for IDPR information in order to minimize the link
   bandwidth consumed by IDPR-specific information.  However, we have
   also organized IDPR information in order to speed message processing,
   which does not always result in minimum link bandwidth usage.

   To limit link bandwidth usage, we currently use fixed-length
   identifier fields in IDPR messages; domains, virtual gateways, policy
   gateways, and route servers are all represented by fixed-length
   identifiers.  To simplify message processing, we currently align
   fields containing an even number of bytes on even-byte boundaries
   within a message.  In the future, if the Internet adopts the use of
   super domains, we will offer hierarchical, variable-length identifier
   fields in an updated version of IDPR.

   The header of each CMTP message contains the following information:








Steenstrup                                                     [Page 24]

RFC 1479                     IDPR Protocol                     July 1993


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    VERSION    |  PRT  |  MSG  |  DPR  |  DMS  |    I/A TYP    |
   +---------------+-------+-------+-------+-------+---------------+
   |           SOURCE AD           |           SOURCE ENT          |
   +-------------------------------+-------------------------------+
   |                           TRANS ID                            |
   +---------------------------------------------------------------+
   |                           TIMESTAMP                           |
   +-------------------------------+-------------------------------+
   |            LENGTH             |       message specific        |
   +-------------------------------+-------------------------------+
   |         DATAGRAM AD           |         DATAGRAM ENT          |
   +-------------------------------+-------------------------------+
   |                             INFORM                            |
   +---------------------------------------------------------------+
   |                            INT/AUTH                           |
   |                                                               |
   +---------------------------------------------------------------+

   VERSION
        (8 bits) Version number for IDPR control messages, currently
        equal to 1.

   PRT (4 bits) Numeric identifier for the control message transport
        protocol, equal to 0 for CMTP.

   MSG (4 bits) Numeric identifier for the CMTP message type,equal to 0
        for a DATAGRAM, 1 for an ACK, and 2 for a NAK.

   DPR (4 bits) Numeric identifier for the original DATAGRAM's IDPR
        protocol type.

   DMS (4 bits) Numeric identifier for the original DATAGRAM's IDPR
        message type.

   I/A TYP (8 bits) Numeric identifier for the integrity/authentication
        scheme used.  CMTP requires the use of an
        integrity/authentication scheme; this value must not be set
        equal to 0, indicating no integrity/authentication in use.

   SOURCE AD (16 bits) Numeric identifier for the domain containing the
        IDPR entity that generated the message.

   SOURCE ENT (16 bits) Numeric identifier for the IDPR entity that
        generated the message.




Steenstrup                                                     [Page 25]

RFC 1479                     IDPR Protocol                     July 1993


   TRANSACTION ID (32 bits) Local transaction identifier assigned by the
        IDPR entity that generated the original DATAGRAM.

   TIMESTAMP (32 bits) Number of seconds elapsed since 1 January 1970
        0:00 GMT.

   LENGTH (16 bits) Length of the entire IDPR control message, including
        the CMTP header, in bytes.

   message specific (16 bits) Dependent upon CMTP message type.

        For DATAGRAM and ACK messages:

             RESERVED
                  (16 bits) Reserved for future use and currently set
                  equal to 0.

        For NAK messages:

             ERR TYP (8 bits) Numeric identifier for the type of CMTP
                  validation failure encountered.  Validation failures
                  include the following types:

                  1.   Unrecognized IDPR control message version number.

                  2.   Unrecognized CMTP message type.

                  3.   Unrecognized integrity/authentication scheme.

                  4.   Unacceptable integrity/authentication scheme.