rfc2730.txt

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

2.9. Locating MADCAP Servers

   There are several ways for a MADCAP client to locate a MADCAP server.
   For instance, the client may be configured with an IP address.

   The RECOMMENDED technique is for the client to send an GETINFO
   message to a MADCAP Server Multicast Address and wait for ACK
   responses. This technique is described in more detail in the next
   section.

2.10. MADCAP Server Multicast Address

   Each multicast scope has an associated MADCAP Server Multicast
   Address. This address has been reserved by the IANA as the address
   with a relative offset of -1 from the last address of a multicast
   scope.

   A MADCAP client looking for servers that can provide multicast
   allocation services MAY send an GETINFO message to a MADCAP Server
   Multicast Address. Any MADCAP servers listening to this address
   SHOULD respond with a unicast ACK message to the client if they wish
   to offer a response.






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


   The MADCAP Server Multicast Address used by a client MAY be
   established by configuration. If a client has no such configuration,
   it SHOULD use the MADCAP Server Multicast Address associated with
   IPv4 Local Scope (or SCOP 3 for IPv6) with maximum TTL of 16, unless
   otherwise configured.

2.11. Going Beyond the Local Scope

   If a client receives no response to a message sent to a MADCAP Server
   Multicast Address (after retransmission), it MAY send the message to
   a larger scope and repeat this process as necessary. However, the
   client MUST NOT send a MADCAP message to the MADCAP Server Multicast
   Address associated with the global scope.

   This technique allows MADCAP servers to provide services for scopes
   in which they do not reside. However, this is a dangerous and
   complicated technique and is NOT RECOMMENDED at this time.
   Therefore, MADCAP clients SHOULD only send multicast messages to the
   MADCAP Server Multicast Address corresponding to the IPv4 Local Scope
   (or SCOP 3, if using IPv6), unless configured otherwise.

   MADCAP servers that wish to provide services for scopes in which they
   do not reside MUST make special efforts to ensure that their services
   meet clients' needs for largely conflict-free allocation and accurate
   scope list information.  In particular, coordinating with other
   servers that provide services for this scope may be difficult. Also,
   establishing which scope the client is in may be difficult. If a
   MADCAP server is not prepared to provide services for scopes in which
   it does not reside, it SHOULD ignore DISCOVER and REQUEST messages
   whose scope does not match or enclose the scope of the MADCAP Server
   Multicast Address on which the request was received. It SHOULD also
   ignore GETINFO messages that are not received on the MADCAP Server
   Multicast Address for IPv4 Local Scope.

2.12. Clock Skew

   The Current Time option is used to detect and handle clock skew
   between MADCAP clients and servers. This option MUST be included in
   any MADCAP message that includes an absolute time (such as the Start
   Time option). It MAY be included in any DISCOVER, OFFER, REQUEST,
   RENEW, or ACK message.

   Clock skew is a situation where two systems have clocks that are not
   synchronized. Many protocols (such as DHCP) ignore clock skew by
   using relative times. MADCAP could use a similar technique, but this
   leads to nasty situations due to the way multicast addresses are
   used.




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


   For example, assume that at 1 PM UTC a client whose clock is one hour
   fast requests a lease for one hour starting in one hour. If we were
   using relative times for MADCAP, the server, whose clock is set
   correctly, would reserve a multicast address for 2 to 3 PM UTC and
   grant the request. If the client was the only one using the lease,
   everything would be OK. The client would start using the lease in one
   hour and continue for one hour. This would coincide with the time the
   server had reserved (although the client would think it was 3 to 4 PM
   UTC).

   However, multicast addresses are usually used by several parties at
   once.  The client would probably use SAP (or some other mechanism for
   conveying SDP) to advertise a session using the multicast address
   just leased. SDP uses absolute times, since it may be sent via email,
   web, or other store-and-forward mechanisms. So the client would
   advertise the session as running from 3 to 4 PM UTC. Any clients
   whose clocks are set correctly would use the address during this
   interval. Since the server only reserved the address from 2 to 3 PM
   UTC, this might cause the address to be used for multiple sessions
   simultaneously.

   MADCAP cannot solve all clock skew problems. That is the domain of
   NTP [4].  However, it does attempt to detect substantial clock skew
   between MADCAP clients and servers so that this clock skew does not
   cause massive collisions in multicast address usage later on.

   The Current Time option contains the sender's opinion of the current
   time in UTC at or about the time the message was assembled. Because
   of delays in transmission and processing, this value will rarely
   match the receiver's opinion of the current time at the time the
   option is processed by the receiver. However, difference greater than
   a minute or two probably indicate clock skew between the sender and
   the receiver.

   MADCAP servers SHOULD expect and tolerate a small amount of clock
   skew with their clients by ensuring that multicast addresses are
   allocated for an extra period of time [EXTRA-ALLOCATION-TIME] on
   either side of the lease given to the client. However, large amounts
   of clock skew require special handling. The value of [EXTRA-
   ALLOCATION-TIME] MUST be a configurable parameter, since local
   circumstances may vary.  The RECOMMENDED default is one hour.

   However, large amounts of clock skew will cause problems later when
   sessions are advertised. If a MADCAP server detects clock skew
   greater than [CLOCK-SKEW-ALLOWANCE], it MUST generate and process an
   Excessive Clock Skew error, as described in section 2.6. The server
   MAY also log a message. The value of [CLOCK-SKEW-ALLOWANCE] MUST be a
   configurable parameter, since local circumstances may vary.  The



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


   RECOMMENDED default is 30 minutes.

2.13. Optional Features

   Each MADCAP client or server MAY implement one or more optional
   features.  Optional features of MADCAP are identified with a two
   octet feature code.

   A MADCAP client MAY request, require, or indicate support for an
   optional feature by including a Feature List option in a message. For
   more information about optional features, see the description of the
   Feature List option.

   Table 4 lists the feature codes defined at this time and sections
   2.13.1 and 2.13.2 describe how these features work.

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

           Feature Code   Feature Name
           ------------   ------------
                0         Server Mobility
                1         Retry After
                2         Shared Lease Identifier

      Table 4:  MADCAP Feature Codes

2.13.1. Server Mobility

   The Server Mobility feature allows an address allocated on one MADCAP
   server to be renewed or released on a different MADCAP server. This
   requires communication and coordination among MADCAP servers. The
   primary benefits are immunity to the failure of a single MADCAP
   server and perhaps greater performance through load balancing.

   In order to take advantage of the Server Mobility feature, a MADCAP
   client must ensure that the feature is implemented by both the server
   that is used for the original allocation and the server that is used
   for the renewal or release. The best way to ensure this is to include
   the Server Mobility feature in the required list of a Feature List
   option in the REQUEST message used to allocate the address (and the
   DISCOVER message, if one is used). When the time comes to renew or
   release the address, the client SHOULD send a unicast RENEW or
   RELEASE message to the server from which it allocated the address.
   However, if this server is unavailable, the client MAY send the RENEW
   or RELEASE message to any other server that includes the Server
   Mobility feature in its list of supported features. The client can
   find such a server by (for instance) sending an GETINFO message with



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


   an Option Request List option that includes the Feature List option
   code.

   If the MADCAP client does not want to require this feature when
   allocating addresses, it may include the feature in the requested
   list of a Feature List option and see if the server includes the
   feature in the required list of a Feature List option in the ACK
   message.

   Even if the Server Mobility feature is used, there is no guarantee
   that a server will be available to perform the renewal or release or
   that the renewal or release will succeed. Server connectivity may
   have failed, for instance.

2.13.2. Retry After

   The Retry After feature allows a MADCAP server to ask the MADCAP
   client to retry its request later, as may be required when allocating
   large numbers of addresses or allocating addresses for a long period
   of time.

   For instance, if a MADCAP client requests 1000 addresses,
   administrative approval may be required or allocation of more
   addresses from another MASC domain may be necessary. This may take
   several hours or several days.  If the MADCAP client and server both
   support the Retry After feature, the MADCAP server can send back an
   ACK message with a Retry Time option indicating when the addresses
   may be ready. The client can retry its request after the Retry Time
   to get the addresses.

   If a MADCAP client includes the Retry After feature in the supported
   list of a Feature List option in a REQUEST message, a MADCAP server
   that supports the Retry After feature MAY decide to begin a lengthy
   allocation process. In this case, the MADCAP server will include an
   empty List of Address Ranges option in its ACK message, a Feature
   List option that includes the Retry After feature in the required
   list, and a Retry Time option with a time after which the client
   should retry the REQUEST.

   The client MUST NOT include the Retry After feature in the requested
   or required list of a Feature List option, since the decision about
   whether Retry After is desirable should be left to the MADCAP server.









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


   At some later time (preferably after the time indicated in the Retry
   Time option), the client SHOULD send a REQUEST message with all the
   same options as the original REQUEST message (especially the Lease
   Identifier option), but with a new xid value.  The server MAY return
   a normal ACK or NAK message at this point or it MAY continue the
   transaction to a later time by including an empty List of Address
   Ranges option in its ACK message, a Feature List option that includes
   the Retry After feature in the required list, and a Retry Time option
   with a later time after which the client should retry the REQUEST.

   At any point after receiving the initial ACK message with the Retry
   Time option, the client MAY terminate the allocation process and any
   accompanying lease by sending to the server performing the allocation
   (or another server if the Server Mobility feature is also in effect)
   a RELEASE message with the Lease Identifier included in the original
   REQUEST message.

   The Retry After feature may also be used when renewing a lease.  In
   this case, the description above applies except that the client sends
   a RENEW message instead of a REQUEST message.

   If a client sends a RENEW message with a Lease Identifier that
   matches a lease which is currently undergoing allocation with the
   Retry After feature in response to a REQUEST message, the server MUST
   generate and process an Invalid Request error in the manner described
   in section 2.6.  Also, if a client sends a RENEW message with a Lease
   Identifier that matches a lease which is currently undergoing
   allocation with the Retry After feature in response to a RENEW
   message, but the options supplied with the two RENEW messages do not
   match, the server MUST generate and process an Invalid Request error
   in the manner described in section 2.6.

   Note that the Retry After feature may complicate the application API.
   For this reason, a MADCAP client may request the Retry After feature
   for some messages and not for others. This should not cause problems
   for a robust MADCAP server. In general, servers should not expect
   consistent behavior from clients except as required by this
   specification. This also applies to clients' expectations.

2.13.3. Shared Lease Identifier

   For conferenci