rfc2730.txt

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

2.1. Message Format

   Figure 1 gives the format of a MADCAP message and Table 1 describes
   each of the fields in the MADCAP message. The numbers in parentheses
   indicate the size of each field in octets. The names for the fields
   given in the figure will be used throughout this document to refer to
   the fields in MADCAP messages.

   All multi-octet quantities are in network byte-order.

   Any message whose UDP data is too short to hold this format (at least
   12 bytes) MUST be ignored.























Hanna, et al.               Standards Track                     [Page 6]

RFC 2730                         MADCAP                    December 1999


                +-+-+-+-+-+-+-+-+
                |  version (1)  |
                +---------------+
                |  msgtype (1)  |
                +---------------+
                |  addrfamily   |
                |     (2)       |
                +---------------+
                |               |
                |    xid (4)    |
                |               |
                |               |
                +---------------+
                |               |
                |   options     |
                |  (variable)   |
                |      ...      |
                +---------------+

        Figure 1:  Format of a MADCAP message


  FIELD      OCTETS       DESCRIPTION
  -----      ------       -----------

  version       1  Protocol version number (zero for this specification)
  msgtype       1  Message type (DISCOVER, GETINFO, etc.)
  addrfamily    2  Address family (IPv4, IPv6, etc.)
  xid           4  Transaction ID
  options     var  Options field

          Table 1:  Description of fields in a MADCAP message

2.1.1. The version field

   The version field must always be zero for this version of the
   protocol.  Any messages that include other values in this field MUST
   be ignored.

2.1.2. The msgtype field

   The msgtype field defines the "type" of the MADCAP message.

   For more information about this field, see section 2.2.







Hanna, et al.               Standards Track                     [Page 7]

RFC 2730                         MADCAP                    December 1999


2.1.3. The addrfamily field

   The addrfamily field defines the default address family (such as IPv4
   or IPv6) for this MADCAP message, using the address family numbers
   defined in by the IANA (including those defined in [10]). Unless
   otherwise specified, all addresses included in the message will be
   from this family.

2.1.4. The xid field

   The xid field is a transaction identifier. This number MUST be chosen
   by the client so that the combination of xid, msgtype, and Lease
   Identifier is unique across all MADCAP messages received by a MADCAP
   server over a period of [XID-REUSE-INTERVAL] (10 minutes).

   The xid field is used by the client and server to associate messages
   and responses between a client and a server. Before a client sends a
   message, it chooses a number to use as an xid. The technique used to
   choose an xid is implementation-dependent, but whatever technique is
   used MUST make it unlikely that the same combination of xid, msgtype,
   and Lease Identifier will be used for two different messages within
   [XID-REUSE-INTERVAL] (even across multiple clients which do not
   communicate among themselves).  This allows enough time for the
   message to be dropped from all server response caches (as described
   in the next few paragraphs) and for any network delays to be
   accomodated.

   The RECOMMENDED technique for choosing an xid is to choose a random
   four octet number as the first xid in a session and increment this
   value each time a new xid is needed.  The random number chosen need
   not be cryptographically random. The random number may be chosen via
   any suitable technique, such as the one described in section A.6 of
   RFC 1889 [14].

   When a server responds to a client message, it MUST use the same xid
   value in the response that the client used in the request. This
   allows the client to associate responses with the message that they
   are responding to.

   When retransmitting messages (as described in section 2.3), the
   client MUST retransmit them without changing them, thereby using the
   same xid and and Lease Identifier.

   If a server receives a message with the same xid, msgtype, and Lease
   Identifier as one received within [RESPONSE-CACHE-INTERVAL], it MUST
   treat this message as a retransmission of the previously received one
   and retransmit the response, if any. After [RESPONSE-CACHE-INTERVAL],
   the server may forget about the previously received message and treat



Hanna, et al.               Standards Track                     [Page 8]

RFC 2730                         MADCAP                    December 1999


   any retransmissions of this message as if they were new messages. Of
   course, a server need not cache a message if it ends up ignoring that
   message. However, performance gains may be achieved by doing so.

   This avoids retransmissions causing multiple allocations, since
   requests are not idempotent.  An appropriate value for [RESPONSE-
   CACHE-INTERVAL] would be sixty seconds, but it may have any value
   from zero seconds to 300 seconds (five minutes) and may be adjusted
   dynamically according to resource constraints on the server.
   However, using a value less than sixty seconds is NOT RECOMMENDED
   because this is the normal client retransmission period.

2.1.5. The options field

   The options field consists of a list of tagged parameters that are
   called "options". All options consist of a two octet option code and
   a two octet option length, followed by the number of octets specified
   by the option length. In the case of some options, the length field
   is a constant but must still be specified.

   The option field MUST contain a sequence of options with the last one
   being the End option (option code 0). Any message whose options field
   does not conform to this syntax MUST be ignored.

   Any MADCAP client or server sending a MADCAP message MAY include any
   of the options listed in section 3, subject to the restrictions in
   Table 5 and elsewhere in this document. They MAY also include other
   MADCAP options that are defined in the future. A MADCAP client or
   server MUST NOT include more than one option with the same option
   type in one MADCAP message.

   All MADCAP clients and servers MUST recognize all options listed in
   this document and behave in accordance with this document when
   receiving and processing any of these options. Any unrecognized
   options MUST be ignored and the rest of the message processed as if
   the unknown options were not present. If a MADCAP server receives a
   message that does not conform to the requirements of this document
   (for instance, not including all required options), an Invalid
   Request error MUST be generated and processed in the manner described
   in section 2.6. If a MADCAP client receives a message that does not
   conform to the requirements of this document, it MUST ignore the
   message.

   The order of options within a message has no significance and any
   order MUST be supported in an equivalent manner, with the exception
   that the End option must occur once per message, as the last option
   in the option field.




Hanna, et al.               Standards Track                     [Page 9]

RFC 2730                         MADCAP                    December 1999


   New MADCAP option codes may only be defined by IETF Consensus, as
   described in section 5.

2.2. Message Types

   The msgtype field defines the "type" of a MADCAP message. Legal
   values for this field are:

           Value   Message Type
           -----   ------------
             1     DISCOVER
             2     OFFER
             3     REQUEST
             4     RENEW
             5     ACK
             6     NAK
             7     RELEASE
             8     GETINFO

      Table 2:  MADCAP message types

   Throughout this document, MADCAP messages will be referred to by the
   type of the message; e.g., a MADCAP message with a message type of 8
   will be referred to as an GETINFO message.

   Here are descriptions of the MADCAP message types.  Table 5, which
   appears at the beginning of section 3, summarizes which options are
   allowed with each message type.

   MADCAP clients and servers MUST handle all MADCAP message types
   defined in this document in a manner consistent with this document.

   If a MADCAP server receives a message whose message type it does not
   recognize, an Invalid Request error MUST be generated and processed
   in the manner described in section 2.6. If a MADCAP client receives a
   message whose message type it does not recognize, it MUST ignore the
   message.

   Note, however, that under some circumstances this document requires
   or suggests that clients or servers ignore messages with certain
   message types even though they may be recognized. For instance,
   clients that do not send DISCOVER messages SHOULD ignore OFFER
   messages.  Also, secure servers SHOULD ignore DISCOVER messages and
   all servers SHOULD ignore DISCOVER messages that they cannot satisfy.

   New MADCAP message types may only be defined by IETF Consensus, as
   described in section 5.




Hanna, et al.               Standards Track                    [Page 10]

RFC 2730                         MADCAP                    December 1999


2.2.1. GETINFO

   The GETINFO message is used by a MADCAP client that wants to acquire
   configuration parameters, especially a multicast scope list.  This
   message also allows a client to determine which servers are likely to
   be able to handle future requests.

   The MADCAP client sends out an GETINFO message. The message may be
   unicast to a particular MADCAP server or multicast to a MADCAP Server
   Multicast Address. For more details about the MADCAP Server Multicast
   Address, see section 2.10.

   If a server receives an GETINFO message and it can process the
   request successfully, it MUST unicast an ACK message to the client.
   All GETINFO messages MUST include an Option Request List option. The
   server SHOULD try to include the specified options in its response,
   but is not required to do so (especially if it does not recognize
   them).

   If a server receives an GETINFO message and it does not process the
   request successfully, it MUST generate and process an error in the
   manner described in section 2.6.

   If a client sends an GETINFO message and does not receive any ACK
   messages in response, it SHOULD resend its GETINFO message, as
   described in section 2.3.

   When a MADCAP client sends an GETINFO message, it MAY include the
   Requested Language option, which specifies which language the client
   would prefer for the zone names in the Multicast Scope List. The
   proper way to handle this tag with respect to zone names is discussed
   in the definition of the Multicast Scope List option.

2.2.2. DISCOVER

   The DISCOVER message is a multicast message sent by a MADCAP client