Multicast-Address Allocation (malloc)
-------------------------------------
Charter
Last Modified: 2001-08-29
Current Status: Active Working Group
Chair(s):
Stephen Hanna <steve.hanna@sun.com>
Dave Thaler <dthaler@microsoft.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Transport Area Advisor:
Allison Mankin <mankin@isi.edu>
Technical Advisor(s):
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion:malloc@catarina.usc.edu
To Subscribe: malloc-request@catarina.usc.edu
Archive: catarina.usc.edu/pub/multicast/malloc/
Description of Working Group:
Note: This Working Group is co-chartered in the Internet Area.
Multicast address allocation is an essential part of using IP
multicast. Multicast addresses are an even more limited resource than
unicast addresses, and must be allocated dynamically if they are to
satisfy expected demand. To this end, the MALLOC WG will define three
protocols which work together to form a global dynamic multicast
address allocation mechanism. These protocols will be:
- a "host to Address Allocation Server" protocol used by a host to
obtain one or more multicast addresses from an address allocation
server within its domain.
- an intra-domain server to server protocol that address allocation
servers within the same domain can use to ensure that they do not
give
out conflicting addresses.
- an inter-domain protocol to provide aggregatable multicast address
ranges to domains, which the servers in that domain can then allocate
individual multicast addresses out of. This protocol will work in
conjunction with the IDMR WG's Border Gateway Multicast Protocol to
provide a scalable inter-domain multicast routing solution.
Although mechanisms for enforcing policies for multicast address
allocation may be considered, setting any such policies is not within
the scope of this WG. Alternative multicast models are also out of
scope.
Goals and Milestones:
Done Report on simulation and implementation efforts with existing
protocol proposals. Address any problems in the specifications
that were found.
Done Meet at Orlando IETF. Review and finalize the host-server
protocol.
Done Submit the host-server protocol to the IESG for consideration
as a Proposed Standard.
Done Repost the MADCAP scope-nesting option document as a WG
Internet-Draft
Done Repost the updated architecture document as a WG
Internet-Draft
Done Submit the abstract API document(s) to the IESG for
consideration as Informational.
Done Review and finalize the inter-domain protocol
Done Submit the inter-domain protocol to the IESG for consideration
as Experimental
Done Submit the architecture document to the IESG for consideration
as Informational
Done Submit the MADCAP scope-nesting option document to the IESG
for consideration as Proposed Standard
Done Review and finalize the intra-domain protocol
Done Complete action of withdrawing intra-domain protocol (due to
lack of community interest and serious fixes needed)
Aug 01 Submit the MIB to the IESG for consideration as a Proposed
Standard.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- --------------------------------------------
Jan 99 Jul 02 <draft-ietf-malloc-malloc-mib-07.txt>
Multicast Address Allocation MIB
Request For Comments:
RFC Stat Published Title
------- -- ----------- ------------------------------------
RFC2730 PS Dec 99 Multicast Address Dynamic Client Allocation Protocol
(MADCAP)
RFC2771 I Feb 00 An Abstract API for Multicast Address Allocation
RFC2907 PS Sep 00 MADCAP Multicast Scope Nesting State Option
RFC2908 I Sep 00 The Internet Multicast Address Allocation Architecture
RFC2909 E Sep 00 The Multicast Address Set Claim (MASC) Protocol
RFC3307 PS Sep 02 Dynamic Allocation Guidelines for IPv6 Multicast
Addresses