draft-ietf-dhc-mdhcp-00.txt   draft-ietf-dhc-mdhcp-01.txt 
Network Working Group Baiju V. Patel Network Working Group Baiju V. Patel
INTERNET DRAFT Intel Corporation INTERNET DRAFT Intel Corporation
Munil Shah Munil Shah
Microsoft Corporation Microsoft Corporation
March 1997 March 1997
Multicast address allocation extensions to the Multicast address allocation extensions to the
Dynamic Host Configuration Protocol Dynamic Host Configuration Protocol
<draft-ietf-dhc-mdhcp-00.txt> <draft-ietf-dhc-mdhcp-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 3, line 52 skipping to change at page 3, line 52
that passes DHCP messages between DHCP clients and DHCP servers. that passes DHCP messages between DHCP clients and DHCP servers.
DHCP is designed to use the same relay agent behavior as DHCP is designed to use the same relay agent behavior as
specified in the BOOTP protocol specification. specified in the BOOTP protocol specification.
o "binding" o "binding"
A binding is a collection of configuration parameters, including A binding is a collection of configuration parameters, including
at least an IP address, associated with or "bound to" a DHCP at least an IP address, associated with or "bound to" a DHCP
client. Bindings are managed by DHCP servers. client. Bindings are managed by DHCP servers.
1.3 Motivation 1.3 Motivation and protocol requirements.
The current mechanisms used for multicast address allocation are For multicast applications to be ubiquitous, there is a need to
fairly adhoc and are specific to the applications. For example, the standardize on a protocol to allocate multicast addresses to the
mbone tools listen to the SAP messages to determine the multicast applications. Following are the set of requirements on such a
addresses that are currently in use. Since there are no unified protocol.
mechanisms for allocating multicast address, each class of
applications or tools need to implement their own solution. This Conflict Free Allocation: When two applications obtain a
not only creates many different groups of address but also leads to multiast address (using a common multicast address allocation
potential conflict in address usage. The router that filters protocol), both applications are allocated identical addresses
multicast packets based on the administrative scopes must be
aware of different pools of addresses used by different
applications. If an organization intends to implement a multicast
allocation and use policy, each of every application must be aware
of it and know how the addresses are to be used within this
policy. The protocols that attempt to guess multicast addresses by
listening to SAP messages may at times lead to conflicting use of
multicast addresses as well. The conflicts may arise due to use of
different TTLs, Scoping, packet losses, and temporary shutdown of
the originating system. Consider an example where a site does not
allow any multicast to enter but allows all the out going
multicasts. In that case, an application internal to the site has
no way of determining which multicast address are in use outside
the site. Similarly, if some announcement packets are lost, the
application may incorrectly conclude that a multicast address is
not in use. Finally, since the multicast address allocation scheme
is adhoc, the organization cannot clearly define the policy for
multicasts.
Therefore, there is a need to provide a mechanism for requesting only if it can be guaranteed that no hosts will receive multicasts
and assigning a multicast address. If this mechanism is based on using same address from both the applications on the same network
client/server paradigm, the client is not responsible for ensuring interface provided that the multicast scoping is implemented correctly.
uniqueness of multicast address. Moreover, the organization may be
able to enforce a multicast policy through which all the multicast
addresses are assigned. An example of a policy would be to assign
multicast addresses from range X to be used within an organization,
range Y to used for an entire corporation etc. The applications
should not have to be manually configured to determine these
policies.
The proposed protocol does not address the specific means that are Session protocol independence: The address allocation protocol
needed at a DHCP server to determine the address to be should be independent of existing and future session control
allocated. For the administratively scoped addresses, the DHCP protocol. For example, it must be suitable for applications that
server may have a block of address that it can assign to the use SAP (session announcement protocol) and SIP (session invitation
application. Currently, it is not clear how will it determine the protocol).
addresses to be allocated for the Internet (mbone). If and when
these mechanisms become available, the DHCP server could act as a
proxy in obtaining those addresses as well.
1.4 Protocol Summary Small response time: The application should not have to wait for a
long time before it can be sure that it can use a multicast
address. The response time should be function of network and
system delays only and should not be in the order of several
minutes.
Low network load: The multicast address allocation protocol is a
control protocol. It should be designed to impose minimal load on
the network. In particular, it should not require periodic
broadcast/multicast messages from every application. Specifically,
the address allocation protocol should not overload a modem line
when used by a dial-in user.
Work with power managed systems: The protocol should not require
the client systems to be on all the time. It is perfectly
acceptable that once the multicast address is allocated, the system
may suspend or turn off for some time. The system may come back to
full power just before the application starts multicasting
traffic.
Multicast address scopes: The protocol must be able to
allocate both the administratively scoped addresses and global
addresses.
Efficient use of address space: The multicast address space is
smaller then IP address space. Moreover, a host or application may
require multiple address. Therefore, efficient use of address space
is a design goad of multicast address allocation protocol.
1.4 MHDCP Protocol Summary
From the client's point of view, MDHCP is an extension of the DHCP From the client's point of view, MDHCP is an extension of the DHCP
mechanisms. The MDHCP servers assigns multicast addresses to the mechanisms. The MDHCP servers assigns multicast addresses to the
hosts to be used within a specific scope, and valid for a specific hosts to be used within a specific scope, and valid for a specific
period. A client may request multiple multicast addresses. period. A client may request multiple multicast addresses.
The client requests a multicast address(es) to be used for a The client requests a multicast address(es) to be used for a
specific multicast scope available to it, and for a specific lease specific multicast scope available to it, and for a specific lease
period. The MDHCP server would ideally assign the address from the period. The MDHCP server would ideally assign the address from the
requested scope or may allocate it for a different scope. However, requested scope or may allocate it for a different scope. However,
skipping to change at page 6, line 17 skipping to change at page 6, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code | length=4 | | code | length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope id | | Scope id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope id | | Scope id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The client may obtain the scope list through the option described in The client may obtain the scope list through the option described in
[3] or using some other means. The scope id is the numeric representation [3] or using some other means. The scope id is the numeric representation
of the scope as described in [3]. of the scope as described in [3].
The 'code' for this option is TBD. The 'code' for this option is 101.
2.3 Start time Option 2.3 Start time Option
The start time is used in a client request (DHCPDISCOVER or The start time is used in a client request (DHCPDISCOVER or
DHCPREQUEST) to allow the client to request the starting time for DHCPREQUEST) to allow the client to request the starting time for
the use of the assigned address. This option allows client to the use of the assigned address. This option allows client to
request a multicast address for use at a future time. request a multicast address for use at a future time.
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
skipping to change at page 6, line 40 skipping to change at page 6, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| t1 | t2 | | t1 | t2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| t3 | t4 | | t3 | t4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The time is the Coordinated Universal Time(UTC) in unit of seconds The time is the Coordinated Universal Time(UTC) in unit of seconds
and is specified as a 32-bit integer and is specified in the network and is specified as a 32-bit integer and is specified in the network
time format. time format.
The 'code' for this option is TBD. The 'code' for this option is 102.
If IP Address Lease Time option specifies the duration of the lease If IP Address Lease Time option specifies the duration of the lease
beginning at Start Time option value. beginning at Start Time option value.
2.4 Multicast TTL Option 2.4 Multicast TTL Option
This option specifies the TTL value to be used with the multicast This option specifies the TTL value to be used with the multicast
address. The TTL is specified as an octet with a value between 1 address. The TTL is specified as an octet with a value between 1
and 255. and 255.
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code | length=1 | | code | length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | | TTL |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The 'code' for this option is 103.
2.5 Multicast Block Size option 2.5 Multicast Block Size option
In some cases, an application may require a group of consecutive In some cases, an application may require a group of consecutive
addresses to be assigned. This option is used by a client to request addresses to be assigned. This option is used by a client to request
n consecutive addresses. It is also used by the DHCP server to n consecutive addresses. It is also used by the DHCP server to
indicate number of consecutive addresses assigned starting at the indicate number of consecutive addresses assigned starting at the
address specified in ``yiaddr'' field. address specified in ``yiaddr'' field.
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code | length=1 | | code | length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n | | n |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The 'code' for this option is 104.
2.6 Client Port Option 2.6 Client Port Option
In order to facilitate implementations outside the operating system In order to facilitate implementations outside the operating system
kernel, and to allow two separate client implementations: one for kernel, and to allow two separate client implementations: one for
DHCP and one for MDHCP, if this option is specified, the MDHCP DHCP and one for MDHCP, if this option is specified, the MDHCP
server MUST use the source port number used in the server MUST use the source port number used in the
DHCPDISCOVER, DHCPREQUEST, DHCPINFORM, and DHCPRESEASE DHCPDISCOVER, DHCPREQUEST, DHCPINFORM, and DHCPRESEASE
as the destination port number in the response messages. as the destination port number in the response messages.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| code | | code |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The 'code' for this option is 105.
2.7 Cookie Option 2.7 Cookie Option
The MDHCP server may issue a cookie along with the multicast The MDHCP server may issue a cookie along with the multicast
address(es) so that a different user may use the cookie to renew address(es) so that a different user may use the cookie to renew
lease on address(es). lease on address(es).
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code | length=2 | | code | length=2 |
skipping to change at page 9, line ? skipping to change at page 8, line 11
identifier option. For example, if host X was issued a multicast identifier option. For example, if host X was issued a multicast
address, who decides to leave the multicast group that is using the address, who decides to leave the multicast group that is using the
assigned the address. Then, another participant in the group assigned the address. Then, another participant in the group
determines that the work group must continue beyond the lease time determines that the work group must continue beyond the lease time
for the multicast address, it may renew the lease by specifying the for the multicast address, it may renew the lease by specifying the
cookie to uniquely identify the group of multicast addresses. Note cookie to uniquely identify the group of multicast addresses. Note
that cookie is not used as a security capability but is used to that cookie is not used as a security capability but is used to
simplify the client and server implementations. simplify the client and server implementations.
The 'code' for this option is 106.
3. MDHP protocol 3. MDHP protocol
The client needs to obtain the IP address of the MDHCP server (this The client needs to obtain the IP address of the MDHCP server (this
may be a unicast or a multicast address for MDHCP group), and the may be a unicast or a multicast address for MDHCP group), and the
multicast scope list. This list may be obtained as part of the multicast scope list. This list may be obtained as part of the
normal DHCP protocol using the options specified in [3] or by some normal DHCP protocol using the options specified in [3] or by some
other means. other means.
The client selects one of multicast scopes and requests multicast The client selects one of multicast scopes and requests multicast
address(es) from the MDHCP servers. The fields and options that address(es) from the MDHCP servers. The fields and options that
skipping to change at page 9, line ? skipping to change at page 8, line 37
in the DHCP RFC[1]. in the DHCP RFC[1].
Note that all the messages in this exchange have their M flag set Note that all the messages in this exchange have their M flag set
and B flag not set. and B flag not set.
The MDHCP Client MUST provide client identifier option when sending The MDHCP Client MUST provide client identifier option when sending
messages for multicast address assignment. The client generates a messages for multicast address assignment. The client generates a
unique key and uses that as a client identifier in the DHCPDISCOVER unique key and uses that as a client identifier in the DHCPDISCOVER
message. When the server responds to this with DHCPOFFER, it also message. When the server responds to this with DHCPOFFER, it also
provides a cookie along with it. This cookie is generated on the provides a cookie along with it. This cookie is generated on the
server and it uniquely idenfies the transaction associated with the server and it uniquely identifies the transaction associated with the
multicast addresss(es) being offered to this client. For all the multicast address(es) being offered to this client. For all the
subsequent messages, client uses this cookie as a client identifier. subsequent messages, client uses this cookie as a client identifier.
Each client may be running several different multicast enabled Each client may be running several different multicast enabled
applications, and each application may require separate multicast applications, and each application may require separate multicast
address(es). Client MUST use separate unique client identifier when address(es). Client MUST use separate unique client identifier when
requesting separate multicast address(es) for each application. requesting separate multicast address(es) for each application.
A client implementation may choose to use hardware address, hardware A client implementation may choose to use hardware address, hardware
type and application instance number to generate unique client type and application instance number to generate unique client
identifier identifier
skipping to change at page 17, line 5 skipping to change at page 16, line 5
| | DHCPRELEASE \| | | DHCPRELEASE \|
| | | | | |
| | Discards lease | | Discards lease
| | | | | |
v v v v v v
Figure 2: Timeline diagram of messages exchanged between MDHCP Figure 2: Timeline diagram of messages exchanged between MDHCP
client and servers when allocating multicast client and servers when allocating multicast
address(es) using group multicast address for MDHCP address(es) using group multicast address for MDHCP
capable servers. capable servers.
5. Acknowledgements 5. MDHCP Protocol properties
Conflict free address allocation: In the intranet case, each MDHCP
server is allocated part of the administratively scoped address
space. As long as the address space managed by MDHCP servers is
non-overlapping for a given administratrices scope, the protocol
will allocate conflict free addresses. MDHCP protocol does not
directly address the mechanisms for determining address allocation
outside Intranet. However, we propose to use MDHCP as a front end
to any future address allocation protocol for the
Internet. The MDHCP protocol will preserve conflict free address
allocation property of the internet multicast address allocation
protocol.
Session protocol independence: The MDHCP protocol does not dictate
use of the address allocated, and does not rely on any session
control protocol. Therefore, it will work with SIP or SAP based
session control protocol.
Small response time: The response time for MDHCP protocol is
strictly based on the network propagation delay and the load on the
MDHCP server.
The MDHCP protocol does not require a client system to be on all
the time. Thus, it poses no additional requirements on power
managed systems.
Multicast address scopes: The administratively scoped multicast
address may be directly allocated by MDHCP server. However, it is
envisioned that the MDHCP protocol will be indirectly used for
Internet wide Multicast addresses allocation. In such deployment,
the MDHCP server will act as a front-end to future Internet
multicast address allocation protocols.
Efficient use of address space: The multicast address space may be
statically partitioned between MDHCP servers to provide sufficient
reliability and load management on servers. However, the multicast
based address request will be able to obtain addresses from any of
the available servers. Alternately, the MDHCP server can be
organized hierarchically where a master server allocates blocks of
addresses to the child servers (using MDHCP protocol). It is also
possible to provide further fault-tolerance using DHCP server-server
protocol.
6. Acknowledgements
The authors would like to thank Thomas Pfenning, Rajeev Byrisetty, The authors would like to thank Thomas Pfenning, Rajeev Byrisetty,
and Ramesh Vyaghrapuri for their assistance in creating this and Ramesh Vyaghrapuri for their assistance in creating this
document. document.
6. References 7. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC1541, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC1541,
October 1993 October 1993
[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 1533, Lachman Technology, Inc., Bucknell Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
University, October 1993. University, October 1993.
[3] Patel, B., and Shah, M., ``Multicast address allocation [3] Patel, B., and Shah, M., ``Multicast address allocation
extensions options'' extensions options''
skipping to change at line 769 skipping to change at line 822
Munil Shah Munil Shah
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone:206 703 3924 Phone:206 703 3924
Email:munils@microsoft.com Email:munils@microsoft.com
This document will expire on Sept, 1997 This document will expire on Sept, 1997

 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/