2.7.7 Multicast-Address Allocation (malloc)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 04-Jun-99


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

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Advisor:

Vern Paxson <vern@aciri.org>

Technical Advisor(s):

Thomas Narten <narten@raleigh.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:



Report on simulation and implementation efforts with existing protocol proposals. Address any problems in the specifications that were found.



Meet at Orlando IETF. Review and finalize the host-server protocol.



Submit the host-server protocol to the IESG for consideration as a Proposed Standard.



Repost the updated architecture document as a WG Internet-Draft



Repost the MADCAP scope-nesting option document as a WG Internet-Draft

Jul 99


Review and finalize the intra-domain and inter-domain protocols

Jul 99


Submit the abstract API document(s) to the IESG for consideration as Informational.

Aug 99


Submit the intra-domain protocol to the IESG for consideration as a Proposed Standard.

Aug 99


Submit the MIB for the host-server protocol to the IESG for consideration as a Proposed Standard.

Aug 99


Submit the MIB for the intra-domain protocol to the IESG for consideration as a Proposed Standard.

Aug 99


Submit the manual allocation experiment document to the IESG for consideration as Experimental

Aug 99


Submit the inter-domain protocol to the IESG for consideration as Experimental

Aug 99


Submit the MADCAP scope-nesting option document to the IESG for consideration as Proposed Standard

Aug 99


Submit the architecture document to the IESG for consideration as Informational


No Request For Comments

Current Meeting Report

Minutes of MALLOC Working Group
IETF 45 (Oslo, Norway)
Thursday, July 15, 1999

Minutes reported by B. Quinn and S. Hanna.


Agenda Bashing


Introduction & Document Status


Architecture Document Update


Static IPv4 Allocation


Static IPv6 Allocation


MASC Update




AAP Discussion




I. Introduction and Document Status

Steve Hanna gave an overview of the MALLOC architecture. Then he provided an update on MALLOC document status:

- Architecture doc: Recently updated and in WG discussion
- MADCAP doc: In IESG Review (near completion)
- AAP doc: In WG Discussion
- MASC doc: In WG Discussion (recently updated)
- Scope Nesting doc: New revision coming soon
- Abstract API doc: In WG Last Call
- MALLOC MIB doc: In WG Discussion
- Static Allocation: moved out of MALLOC into MBONED

Most documents should be able to go to IESG by August. AAP will probably be later. MIB will have to wait for AAP.

II. Architecture document update

Dave Thaler described the changes in the latest version of the MALLOC architecture document (draft-ietf-malloc-arch-02.txt). The latest draft is more abstract. It removes focus on specific protocol details (MADCAP, AAP and MASC) and now references roles, which can also apply to alternative proposals (like static allocation). A party that announces addresses available within a domain is now known as a "prefix coordinator" instead of a "MASC server," for instance.

Also, Dave has proposed that "large" scopes (which contain multiple allocation domains) now be called "divisible" and "small" scopes (which have a single allocation domain) now be called "indivisible." This idea was received with mixed emotions.

Dave proposed a 2 week working group last call for this document beginning July 23. There was general agreement.

III. IPv4 Static Allocation

Dave Meyer described the current status of the IPv4 multicast address static allocation method described in draft-ietf-mboned-static-allocation-00.txt.

The IANA just assigned the reserved multicast address range 233/8 for this proposal. These addresses are already being used by many ISPs.

There are many calculators available for converting an AS number into static multicast address assignments and vice versa. See http://gigapop.uoregon.edu/glop

Mark Handley asked how the MALLOC architecture would handle an AS (with a static allocation) that is larger than an allocation domain. It was agreed that you could use MASC or static configuration to break up the static allocation across multiple allocation domains. Mark agreed to help Dave Thaler add this to the Architecture document.

IV. Allocation of Multicast Addresses in IPv6

Brian Haberman described the IPv6 multicast address static allocation scheme described in draft-haberman-malloc-static-ipv6-alloc-00.txt.

An IPv6 multicast address contains a 16 bit prefix (with flags, scope, etc.) and a 112 bit group ID. An IPv6 unicast address contains a 64 bit network prefix and a 64 bit interface ID. The proposal is to statically allocate IPv6 multicast addresses to network prefixes by putting the unicast network prefix at the top of the group ID. This will provide 2^48 groups for each scope, prefix pair.

A concern was raised about how often IPv6 unicast network prefixes might change (due to renumbering). If they change too often, this could cause problems for this scheme. The answer was that each prefix has a lifetime and an orderly transition should be done, with several weeks during which the old prefix is deprecated and the new one preferred. This should be OK.

One open issue is how this allocation scheme may interact with the technique used for mapping IPv6 multicast addresses to Ethernet group addresses. RFC 2464 uses only the low 32 bits of the multicast address. We should try to avoid collisions by attempting to ensure that the IPv6 multicast addresses in use map evenly over the Ethernet group address space.

Another open issue is which working group this draft should be in. ipng? malloc? This will be discussed with the ADs.

V. MASC Update

This presentation was prepared by Pavlin Radoslavov. However, Pavlin could not attend so Dave Thaler actually gave the presentation.

A new MASC draft was posted today. This draft should be ready for working group Last Call by the end of July and will then be submitted to the IESG for publication as an Experimental RFC.

This draft includes several bug fixes and other changes in light of Pavlin's implementation experience and suggestions from others. Here is a description of some of the most important changes:

Bootup Operation
- When a MASC server comes up, it should establish the TCP connection to its parents before its siblings or children. This helps avoid the node learning about its own PREFIX_MANAGED from its siblings or children.

Leaf vs. Non-Leaf MASC Domains
- Leaf and non-leaf MASC domains must behave differently. Leaf domains must advertise all addresses to their own allocation domain. Non-leaf domains must save some for themselves and leave others for their children.

Clock Skew Work-around
- Clock skew can cause problems with MASC. However, these problems can be avoided. First, timestamps are used to resolve claim collisions. Clock skew may result in one node's claims winning unfairly. But this should be rare and is not a big problem. More problematic is the possibility that clock skew may cause claims to be expired prematurely. To avoid this problem, all claims should be held for an extra 24 hours. And claims with clock skew approaching 24 hours should be rejected with an error.

Security Considerations
- When attempting to restore internal state after a reboot, information received from internal peers and parents should be preferred to information received from siblings or children. This prevents siblings or children from providing false state.
- A denial of service attack (too many collisions) by a single node can be identified by all its siblings, who can ignore that node's claims. A similar attack with multiple origin addresses can be prevented by accepting claims only through the parent.

Sample Algorithms Appendix
- Many simulations that have been performed are described.

An open issue was discussed. Currently, siblings with more than one common parent can multiplex all UPDATEs over a single TCP connection. This is too complicated and provides a negligible savings of a few TCP connections. Pavlin suggests opening a new TCP connection for each common pairing. There was general agreement that this sounded like a good idea.

Dave Thaler asked whether separate port numbers would be needed for these connections. He will send email to Pavlin.

MASC Implementation Status

Pavlin has implemented MASC and performed detailed testing, refining, and bug fixing of MASC processing code through simulations. He has also added QUERY/RESPONSE debug messages for debugging. The question arose as to whether these messages should be added to an appendix of the MASC spec. After some discussion, it was agreed that either a MASC MIB should be defined or the messages should be documented.

Pavlin is also working on implementing and testing the MASC-AAP interface. It would be helpful to him if someone who already has a MADCAP/AAP implementation could volunteer to do some testing with him. Nobody came forward.

Deborah Estrin said that Pavlin has lots of experimental and simulation results. He will publish an Internet Draft on these.


Steve Hanna described the current status of MADCAP. draft-ietf-malloc-madcap-04.txt went to the IESG in March. Since then, several rounds of comments have been received from the ADs. Draft -05 was published in May and draft -06 should be published very soon. After that, the spec should go to Proposed Standard status.

The changes in -05 included:
- adding an overview and glossary
- INFORM now MUST include Option Request List
- adding an Error option for NAK

Draft -06 will include minor clarifications. Also, the INFORM message will be renamed to GETINFO.

VII. AAP Discussion

Steve Hanna led a discussion of the AAP protocol. He started off with a protocol overview, then a status update, and finally a discussion of open issues.

AAP is designed to fit into the middle tier in three-tier MALLOC architecture (intradomain). It will be used by prefix coordinators to announce addresses available for allocation and by Multicast Address Allocation Servers (MAAS's) to coordinate and ensure that allocations do not conflict.

All messages are UDP multicast to scope-relative addresses (in the Allocation Scope for "large" scopes, in the scope being allocated from for "small" scopes).

The AAP spec was written by Mark Handley last year. It was based on SAP (the Session Announcement Protocol). Steve Hanna joined as a co-author in March, with high hopes to resolve open issues quickly and move to Last Call by August. However, other things have intervened and little progress has been made as of yet. The last "working draft" has been converted to ASCII and published as draft-ietf-malloc-aap-01.txt in June. Steve is now aiming to for Last Call in December.

The protocol overview has been omitted here. See the protocol specification for details.

The first open issue was whether to add failover support to AAP. In this context, failover means the ability for one MAAS to take over seamlessly if another one fails (able to renew leases issued by the failed MAAS, etc.). Implementing failover would introduce a lot more complexity: sending per-lease information to backup servers, detecting server failure or network partition, backing off to a safe mode, and resynchronizing to recover.

It was generally agreed that we should wait on this for now and just get out a simple AAP spec and get some experience with that. Implementors can use proprietary protocols or other means to address this for now. And we can develop a standard protocol for it later, if need be. This is similar to what the dhc working group did with DHCP.

The second open issue was whether to add support for MADCAP Server Mobility to AAP. We aren't sure how to do this at this point without introducing lots of complexity (like failover). We agreed to think about this for a few weeks. If we can't come up with a reasonably simple solution, we'll punt on it for now.


Dave Thaler talked about the MALLOC MIB (draft-ietf-malloc-mib-01.txt). The initial MIB instrumented generic MAAS and objects. The WG consensus was that protocol-specific objects should be in the same document, so the MIB was updated in June.

It now contains several different conformance groups that different entities will implement depending on which protocols they speak:

- mallocBasic: all entities
- mallocClient: clients
- mallocClientScope: clients (optional)
- madcapClient: clients that speak MADCAP
- mallocServer: MAASs
- madcapServer: MAASs that speak MADCAP
- aapServer: MAASs that speak AAP
- aapKeyServer: AAP key advertisers
- aapRangeServer: Prefix coordinators that speak AAP

The MADCAP-specific groups contain various MADCAP config options as specified in MADCAP spec, as well as counters for each error type and counters for each packet type.

The AAP-specific groups contain various AAP config options as specified in the AAP spec, as well as a write-only private key configuration entry with appropriate precautions, a read-only public key table, and a trap for when you stop hearing ASA messages.

This draft also includes a few other changes. The scope table has been split onto a scope table and an allocation range table to support divisible ("large") scope better. And IPv6 support has been added by making address objects generic.

The MIB should wait for all the protocol specs to go Proposed Standard. This means it will need to wait for AAP. However, the protocol documents don't need to wait for the MIB.

Brian Haberman asked whether this MIB should use the generic object for IPv4/IPv6 address representation in MIBs that is being developed. Dave said that if this object is done soon enough, we'll use it. Otherwise, we will move ahead with the current proposal.


Allocation of Multicast Addresses in IPv6
Multicast Address-Set Claim (MASC) Update