whole exchange.
The client now has a two hour "lease" on the multicast address.
If the client had not received an ACK from the server, it would have
retransmitted its REQUEST packet for a while. If it still received no
response, it would start over with a new DISCOVER message.
The following figure illustrates this exchange.
Server Client Server
(not selected) (selected)
v v v
| | |
|Begin multicast address request|
| | |
| _____________/|\_____________ |
|/ DISCOVER | DISCOVER \|
| | |
Reserves | Reserves
Address | Address
| | |
|\ | ____________/|
| \_________ | / OFFER |
| OFFER \ |/ |
| \ | |
| Collects replies |
| \| |
| Selects Server |
| | |
| _____________/|\_____________ |
|/ REQUEST | REQUEST \|
| | |
| | Commits address
| | |
| | _____________/|
| |/ ACK |
| | |
| assignment complete |
| | |
v v v
Figure 3: Timeline diagram of messages exchanged
in Multicast Address Allocation example
3. Lease Extension
This is a continuation of the previous example. The client has
already allocated a multicast address from the global scope for use
during the next two hours. Half way through this two hour period, it
decides that it wants to extend its lease for another hour.
The client unicasts a RENEW packet to the server from which it
allocated the address. This packet includes the Lease Time and Lease
Identifier options. The Lease Identifier matches the one used for the
original allocation. The time included in the Lease Time is two
hours, since the client wants the lease to expire two hours from the
current time.
The server responds with an ACK packet indicating that the lease
extension has been granted. This packet includes the Lease Time,
Server Identifier, Lease Identifier, Multicast Scope, and List of
Address Ranges options.
If the server did not want to grant the requested lease extension, it
would have responded with a NAK packet with the Lease Identifier
option.
The following figure illustrates this exchange.
Client Server
v v
| |
|\_____________ |
| RENEW \|
| |
| Extends lease
| |
| _____________/|
|/ ACK |
| |
| |
v v
Figure 4: Timeline diagram of messages exchanged
in Lease Extension example
4. Address Release
This is a continuation of the previous example. The client has
already allocated a multicast address and extended its lease for
another two hours. Half an hour later, the client finishes its use of
the multicast address and wants to release it so it can be reused.
The client unicasts a RELEASE packet to the server from which it
allocated the address. This packet includes the Lease Identifier
option. The Lease Identifier matches the one used for the original
allocation. When the server receives this packet, it cancels the
client's lease on the address and sends an ACK packet to the client
indicating that the lease has been released. This packet includes the
Server Identifier and Lease Identifier options.
The following figure illustrates this exchange.
Client Server
v v
| |
|\_____________ |
| RELEASE \|
| |
| Cancels lease
| |
| _____________/|
|/ ACK |
| |
v v
Figure 5: Timeline diagram of messages exchanged
in Address Release example
5. Unicast Address Allocation
This is a continuation of the previous example. At some later time,
the client decides to allocate another multicast address. Since it
has recently worked with a server, it decides to try sending a
unicast REQUEST to that server. If this doesn't work, it can always
try a multicast DISCOVER, as illustrated in example 2.
The client unicasts a REQUEST packet to the server from which it
wants to allocate the address. This packet includes the Lease Time,
Lease Identifier, and Multicast Scope options.
The server responds with an ACK packet containing the Lease Time,
Lease Identifier, and Multicast Scope options from the REQUEST
packet, as well as the Server Identifier option and a List of Address
Ranges option listing the address allocated.
The client now has a lease on the multicast address.
If the client had not received an ACK from the server, it would have
retransmitted its REQUEST packet for a while. If it still received no
response, it would start over with a multicast DISCOVER message.
The following figure illustrates this exchange.
Client Server
v v
| |
|\_____________ |
| REQUEST \|
| |
| Allocates address
| |
| _____________/|
|/ ACK |
| |
v v
Figure 6: Timeline diagram of messages exchanged
in Unicast Address Allocation example
APPENDIX B: Recommended Constant Values
Table 6 lists recommended values for constants defined in this
specification.
Constant Name Recommended Value
------------- -----------------
[CLOCK-SKEW-ALLOWANCE] 30 minutes
[DISCOVER-DELAY] current retransmit delay
[EXTRA-ALLOCATION-TIME] 1 hour
[NO-RESPONSE-DELAY] 60 seconds
[OFFER-HOLD] at least 60 seconds
[RESPONSE-CACHE-INTERVAL] at least 60 seconds (5 minutes maximum)
[XID-REUSE-INTERVAL] 10 minutes (required)
Table 6: Recommended Constant Values
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.