rfc2730.txt

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

   that wants to discover MADCAP servers that can probably satisfy a
   REQUEST.

   MADCAP clients are not required to use the DISCOVER message.  They
   MAY employ other methods to find MADCAP servers, such as sending a
   multicast GETINFO message, caching an IP address that worked in the
   past or being configured with an IP address. Using the DISCOVER
   message has the particular advantage that it allows clients to
   receive responses from all servers that can satisfy the request.






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


   The MADCAP client begins by sending a multicast DISCOVER message to a
   MADCAP Server Multicast Address. Any servers that wish to assist the
   client respond by sending a unicast OFFER message to the client. If a
   server can only process the request with a shorter lease time or
   later start time than the client requested, it SHOULD send an OFFER
   message with the lease time or start time that it can offer.
   However, it MUST NOT offer a lease time shorter than the minimum
   lease time specified by the client or a start time later than the
   maximum start time specified by the client.

   For more details about the MADCAP Server Multicast Address, see
   section 2.10.

   If a client sends a DISCOVER message and does not receive any OFFER
   messages in response, the client SHOULD retransmit its DISCOVER
   message, as described in section 2.3.

   If a client sends a DISCOVER message and receives one or more OFFER
   messages in response, it SHOULD select the server it wants to use (if
   any) and send a multicast REQUEST message identifying that server
   within [DISCOVER-DELAY] after receiving the first OFFER message.  See
   section 2.2.4 for more information about the REQUEST message.

   The mechanism used by the client in selecting the server it wants to
   use is implementation dependent.  The client MAY choose the first
   acceptable response or it MAY wait some period of time (no more than
   [DISCOVER-DELAY]) and choose the best response received in that
   period of time (if the first response has a smaller lease time than
   requested, for instance).

   The value of [DISCOVER-DELAY] is also implementation dependent, but
   the RECOMMENDED value is the current retransmit timer, as specified
   in section 2.3. Waiting too long (approaching [OFFER-HOLD]) may cause
   servers to drop the addresses they have reserved.

   When a MADCAP client sends a DISCOVER message, it MAY include the
   Lease Time, Minimum Lease Time, Start Time, Maximum Start Time,
   Number of Addresses Requested, and List of Address Ranges options,
   describing the addresses it wants to receive. However, it need not
   include any of these options. If one of these options is not
   included, the server will provide the appropriate default (maximum
   available for Lease Time, no minimum for Minimum Lease Time, as soon
   as possible for Start Time, no maximum for Maximum Start Time, one
   for Number of Addresses Requested, and any addresses available for
   List of Address Ranges).  The Multicast Scope option MUST be included
   in the DISCOVER message so that the server knows what scope should be
   used. The Current Time option MUST be included if the Start Time or
   Maximum Start Time options are included. The Lease Identifier option



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


   MUST always be included.

2.2.3. OFFER

   The OFFER message is a unicast message sent by a MADCAP server in
   response to a DISCOVER message that it can probably satisfy.

   A MADCAP server is never required to send an OFFER message in
   response to a DISCOVER message. For instance, it may not be able to
   satisfy the client's request or it may have been configured to
   respond only to certain types of DISCOVER messages or not to respond
   to DISCOVER messages at all.

   If a MADCAP server decides to send an OFFER message, it MUST include
   the Lease Time and Multicast Scope options, describing the addresses
   it is willing to provide. However, it need not include the List of
   Address Ranges option. If the List of Address Ranges Allocated option
   is not included, it is assumed that the server is willing to provide
   the number of addresses that the client requested. If the Start Time
   option is not included, it is assumed that the server is willing to
   provide the start time requested by the client (if any). The Current
   Time option MUST be included if the Start Time option is included.

   If a server can process the request with a shorter lease time or
   later start time than the client requested, it SHOULD send an OFFER
   message with the lease time or start time that it can offer.
   However, it MUST NOT offer a lease time shorter than the minimum
   lease time specified by the client or a start time later than the
   maximum start time specified by the client.

   If the server sends an OFFER message, it SHOULD attempt to hold
   enough addresses to complete the transaction. If it receives a
   multicast REQUEST message with the same Lease Identifier option as
   the DISCOVER message for which it is holding these addresses and a
   Server Identifier option that does not match its own, it SHOULD stop
   holding the addresses.  The server SHOULD also stop holding the
   addresses after an appropriate delay [OFFER-HOLD] if the transaction
   is not completed. The value of this delay is implementation-specific,
   but a value of at least 60 seconds is RECOMMENDED.

   As with all messages sent by the server, the xid field MUST match the
   xid field included in the client request to which this message is
   responding. The Lease Identifier option MUST be included, with the
   value matching the one included in the client request. The Server
   Identifier option MUST be included, with the value being the server's
   IP address. And the packet MUST NOT be retransmitted.





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


2.2.4. REQUEST

   The REQUEST message is used by a MADCAP client that wants to allocate
   one or more multicast addresses. It is not used for renewing an
   existing lease. The RENEW message is used for that.

   If a REQUEST message is completing a transaction initiated by a
   DISCOVER message, the following procedure MUST be followed so that
   all MADCAP servers know which server was selected. The client MUST
   multicast a REQUEST message to the same MADCAP Server Multicast
   Address that the DISCOVER message was sent to. The same Lease
   Identifier used in the DISCOVER message MUST be used in the REQUEST
   message.  Also, the Server Identifier option MUST be included, using
   the Server Identifier of the server selected.

   If a REQUEST message is not completing a transaction initiated by a
   DISCOVER message, the REQUEST message MUST be unicast to the MADCAP
   server that the client wants to use. In this case, the Server
   Identifier option MAY be included, but need not be.

   If the selected server can process the request successfully, it
   SHOULD unicast an ACK message to the client. Otherwise, it SHOULD
   generate and process an error in the manner described in section 2.6.
   If a server can process the request with a shorter lease time or
   later start time than the client requested, it SHOULD send an ACK
   message with the lease time or start time that it can offer. However,
   it MUST NOT offer a lease time shorter than the minimum lease time
   specified by the client or a start time later than the maximum start
   time specified by the client.

   When a MADCAP client sends a REQUEST message, it MAY include the
   Lease Time, Minimum Lease Time, Start Time, Maximum Start Time,
   Number of Addresses Requested, and List of Address Ranges options,
   describing the addresses it wants to receive. However, it need not
   include any of these options. If one of these options is not
   included, the server will provide the appropriate default (maximum
   available for Lease Time, no minimum for Minimum Lease Time, as soon
   as possible for Start Time, no maximum for Maximum Start Time, one
   for Number of Addresses Requested, and any addresses available for
   List of Address Ranges). The Multicast Scope option MUST be included
   in the REQUEST message so that the server knows what scope should be
   used. The Current Time option MUST be included if the Start Time or
   Maximum Start Time options are included.

   If a client sends a REQUEST message and does not receive any ACK or
   NAK messages in response, the client SHOULD resend its REQUEST
   message, as described in section 2.3.




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


   If the server responds with a NAK or fails to respond within a
   reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the
   client MAY try to find another server by sending a DISCOVER message
   with another xid or sending a REQUEST message with another xid to
   another server. The RECOMMENDED value for [NO-RESPONSE-DELAY] is 60
   seconds.

2.2.5. ACK

   The ACK message is used by a MADCAP server to respond affirmatively
   to an GETINFO, REQUEST, or RELEASE message. The server unicasts the
   ACK message to the client from which it received the message to which
   it is responding.

   The set of options included with an ACK message differs, depending on
   what sort of message it is responding to.

   If the ACK message is responding to an GETINFO message, it SHOULD
   include any options requested by the client using the Option Request
   List option.

   If the ACK message is responding to a REQUEST message, it MUST
   include Lease Time, Multicast Scope, and List of Address Ranges
   options.  It MAY include a Start Time option. If a Start Time option
   is included, a Current Time option MUST also be included. If no Start
   Time option is included, the lease is assumed to start immediately.

   If the ACK message is responding to a RENEW message, it MUST include
   Lease Time, Multicast Scope, and List of Address Ranges options.  It
   MAY include a Start Time option. If a Start Time option is included,
   a Current Time option MUST also be included. If no Start Time option
   is included, the lease is assumed to start immediately.

   If the ACK message is responding to a RELEASE message, it MUST only
   include Server Identifier and Lease Identifier options.

   As with all messages sent by the server, the xid field MUST match the
   xid field included in the client request to which this message is
   responding. The Lease Identifier option MUST be included, with the
   value matching the one included in the client request. The Server
   Identifier option MUST be included, with the value being the server's
   IP address. And the packet MUST NOT be retransmitted.

2.2.6. NAK

   The NAK message is used by a MADCAP server to respond negatively to a
   message. The server unicasts the NAK message to the client from which
   it received the message to which it is responding.



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


   As with all messages sent by the server, the xid field MUST match the
   xid field included in the client request to which this message is
   responding. The Lease Identifier option MUST be included, with the
   value matching the one included in the client request. The Server
   Identifier option MUST be included, with the value being the server's
   IP address. The Error option MUST be included with an error code
   indicating what went wrong. And the packet MUST NOT be retransmitted.

2.2.7. RENEW

   The RENEW message is used by a MADCAP client that wants to renew a
   multicast address lease, changing the lease time or start time.

   The client unicasts the RENEW message to a MADCAP server. If the
   server can process the request successfully, it SHOULD unicast an ACK
   message to the client. Otherwise, it MUST generate and process an
   error in the manner described in section 2.6.

   The lease to be renewed is whichever one was allocated with a Lease
   Identifier option matching the one provided in the RENEW message.

   When a MADCAP client sends a RENEW message, it MAY include the Lease
   Time, Minimum Lease Time, Start Time, and Maximum Start Time options,
   describing the new lease it wants to receive. However, it need not
   include any of these options. If one of these options is not
   included, the server will provide the appropriate default (maximum
   available for Lease Time, no minimum for Minimum Lease Time, as soon
   as possible for Start Time, and no maximum for Maximum Start Time).
   The Current Time option MUST be included if the Start Time or Maximum
   Start Time options are included.

   If a client sends a RENEW message and does not receive any ACK or NAK
   messages in response, the client SHOULD resend its RENEW message, as
   described in section 2.3.

   If the server responds with a NAK or fails to respond within a
   reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the
   client MAY send a RENEW message with another xid to another server,
   provided that the Server Mobility feature was used in the original
   REQUEST message and that this feature is required for the subsequent
   RENEW message sent to another server. For more information about the
   Server Mobility feature, see section 2.13.1. The RECOMMENDED value
   for [NO-RESPONSE-DELAY] is 60 seconds.








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


2.2.8. RELEASE