Minutes from MALLOC BOF - IETF 41, Los Angeles CA

Reported by Colin Perkins and Steve Hanna

Agenda

I. Introduction and agenda bashing [Thaler]
II. Architecture Review [Handley]
III. Charter and work items [Hanna]
IV. "Enforcing" allocation [Thaler]
V. Inter-domain Layer
VI. MASC simulations [Radoslavov]
VII. Limiting allocations [Thaler]
VIII. Host-to-Server Layer
IX. MDHCP implementation and integration update [Shah/Patel/Hanna]
X. Server-to-Server Layer (Intra-domain)
XI. Implementation Plans [Handley]

II. Architecture Review -- Mark Handley

There are four parts to the multicast address allocation architecture:

· an abstract api for allocation
· a local protocol that a host can use to request a protocol from a MAAS. There are two drafts in this area, which will merge in the near future.
· a domain wide announcement protocol that reserves addresses on a timescale of seconds (AAP)
· an interdomain hierarchical protocol to assign aggregatable address sets to domains (MASC)

There is an overview draft and specific drafts for each part.

II. Charter and Work Items -- Steve Hanna

The charter has already been distributed and discussed on the mailing list, so only an overview was presented. The mission is to "form a global dynamic multicast address allocation mechanism" to satisfy increased demand. The specific tasks for the working group are to define three protocols: host to Address Allocation Server, server to server, and inter-domain. The host-server protocol, architecture, and API are to be submitted by 12/98. The server-to-server and inter-domain protocols are to be submitted by 3/99.

Comments:

· This is a meaningless mission. Multicast address aggregation is useless. Response: That is really an IDMR issue.
· This is not a protocol issue, but rather an operational issue.
· What's the policy for who can be allocated an address? You need a global policy.
· There is an issue of address hoarding. We do need some guidelines.
· Are there interactions with IANA? Can't you just register multicast addresses with them? Response: That doesn't scale.
· This is something to be discussed later in the meeting!

III. "Enforcing" Allocation -- Dave Thaler

Proposal:

· Border routers learn of internal allocations (via AAP, etc). We need to do this for MASC anyway.
· BR consults allocation table when receiving external packet or join for a locally owned group.
· If unallocated, BR drops joins and data packets.

Result:

· You only get full connectivity of allocated groups.
· Data/join still comes to the edge of the root domain, so the group prefix owner learns of "offenders".

Comments:

· What about router restarts? Answer: Whilst waiting for the state refresh after a restart, we can't enforce this.
· Use PIM-SM, with DNS RP allocation. This will control everything. Request: Please write this up so we can understand.
· This depends on someone not hitting an address that has been allocated. Surely this is an incentive to allocate but not use large ranges, to get good enforcement?

IV. MASC Prefix Allocation Algorithm -- Pavlin Radoslavov

MASC overview

· MASC operates to associate group ranges (prefixes) with ASs.
· It injects local associations into G-RIB to be used by BGMP.

MASC Goals

· state aggregation
· efficient
· minimize flux in G-RIB
· avoid third-party dependency

Prefix expansion algorithm

· Reverse bit expansion algorithm (Thaler, inspired by Kampai)
· Non-contiguous masks would also work, but people have trouble understanding them

Issues/problems with the basic scheme

The adaption mechanism:

Comments:

· Doesn't changing prefixes cause problems? No, since we don't change addresses during the lifetime of a group. Addresses have a limited lifetime when allocated, so this works. Applications which want a very long lived address must renew their allocations and may have their addresses changed.
· When decreasing, you don't need to allocate a new prefix, just allocate out of half your existing prefix and then drop the other half. This may result in fragmentation? No.
· What is the policy for defining the length of time for which an address may be allocated?
· This makes writing long-lived applications harder, since you may have a forced renumbering.
· How to prevent the space from depleting itself when the requesting force (user base) is growing? i.e.: how fast does your allocation grow? Where are the new allocations made? How to prevent fragmentation?

Results/conclusions

Comments:

V. Limiting Allocations -- Dave Thaler

Two questions are raised in MASC:

Permission to be a TLD

Should we limit how much you can get?

· social disincentive resulting from BGMP? More space you allocate, more traffic you get If you limit, is it a hard limit (check when receiving claim) or a soft limit (let the claim succeed, and alert the operator)?

Comments:

· Do you have to allocate space? No, you can allocate from your parent's prefix.
· Do we require BGMP as the inter-domain protocol? Response: No, but we assume something which can take advantage of address clustering. Also, things will likely work better if we evolve MASC/BGMP together.
· We can't enforce allocation policy. This will be done by the ISPs. We should discuss this with them.

How to specify limits?

· Possible rule of thumb: limit is 1/16 size of the unicast space that domain has (since mcast space is 1/16 the unicast address space size)
· You may or may not want to allow exceptions.

How could we test limits?

Recommendations for MASC

Comments:

· Why not statically allocate 1/16th the unicast space to each provider? Response: Because some providers may want to allocate less than their full limit and may then want to grow their allocation later.
· We only need to enforce limits when we're running out of space. This technique provides us a statistical mux of address allocation.

VI. MDHCP Update -- Munil Shah, Baiju Patel, and Steve Hanna

Changes since last meeting:

· IANA has assigned an address for MDHCP. Relative mcast addr number 1 valid in ALL admin scope zones (e.g.: 239.255.255.254 in IPv4 local scope)
· Developed a COM API interface layer over C APIs

Reconciliation of MDHCP/MARP

MDHCP Implementation

· It is very easy to extend DHCP to support MDHCP.
· Robust implementation has existed for several months in the current Windows NT 5.0 beta.
· This allows us to leverage DHCP management, configuration, and administration tools.
· This has been tested with real applications.
· There is no backend to AAP yet.

Conclusion

· It works!
· You can use MDHCP in an intranet today, with whatever allocator at the backend you feel like.

Comments:

VII. Address Allocation Protocol -- Mark Handley

· There have been no changes to the draft since the last meeting.
· I want to implement in sdr to test it out.

Comments:

General discussion followed.

· The group web page is at http://north.east.isi.edu/malloc.
· Why can't we statically assign address prefixes to ISPs? Response: We believe in statistical mux. Let's allow address reuse to make optimal use of the space.
· If demand is driven bottom up, we need only allocate what is needed, and we get much better utilization.
· We have a lot of multicast addresses, why worry about this?
· Response: But we thought we had lots of unicast addresses too!
· Let's claim rough consensus that dynamic allocation is the way we wish to go.
· It's more important that things are dynamic as we move down the tree. We're likely to have essentially static assignment at the high level, but more dynamic/flexible assignment at the lower end.
· Bradner: We cannot tie limits to unicast space. We're not allowed to proscribe business practice.
· Then we should let the market decide on the top level limits?
· Yes, we should put some wording about this into the architecture document.
· Who would enforce the top level limits? Maybe it has to be soft enforcement here.
· Remember: We're designing an allocation mechanism for the current multicast service model. Let's stay on track. Do we need a place to discuss different multicast service models?
· Are we working on IPv6 too? Yes...

Slides

MASC Prefix Allocation Algorithm