Multicast-Address Allocation (malloc)


In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional MALLOC Page

Last Modified: 2003-03-12

Chair(s):

Stephen Hanna <steve.hanna@sun.com>
Dave Thaler <dthaler@microsoft.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Allison Mankin <mankin@psg.com>

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)
Done    Submit the MIB to the IESG for consideration as a Proposed Standard.

No Current Internet-Drafts

Request For Comments:

Multicast Address Dynamic Client Allocation Protocol (MADCAP) (RFC 2730) (120341 bytes)
An Abstract API for Multicast Address Allocation (RFC 2771) (20954 bytes)
MADCAP Multicast Scope Nesting State Option (RFC 2907) (27572 bytes)
The Internet Multicast Address Allocation Architecture (RFC 2908) (30515 bytes)
The Multicast Address Set Claim (MASC) Protocol (RFC 2909) (127278 bytes)
Dynamic Allocation Guidelines for IPv6 Multicast Addresses (RFC 3307) (15742 bytes)
Multicast Address Allocation MIB (RFC 3559) (68239 bytes)