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
· How can/should you enforce allocation?
· What do providers want? They want to prevent someone from using "their" groups without allocating it and to know who's sending/joining to "their" groups.
· But you can only really prevent this within your domain.
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
· For 2 level hierarchy the overall utilization can be low
· reverse bit expansion does not work well in a hierarchy
· prefixes cannot be shrunk in utilization becomes very low
The adaption mechanism:
· two prefixes per domain (unequal sizes)
· no need for 100% utilization
· if a prefix cannot be expanded, get a bigger one and stop reusing the old one
· if utilization goes down, get a smaller one, and stop using the old larger one
· Optimize for reliability, and to avoid churn in addresses
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
· Lots of graphs were presented.
· GRIB size is okay, but has spikes when there are significant changes in the number of addresses wanted. This corrects itself reasonably quickly, as aggregation occurs.
· Conclusion: no more then 2 prefixes per domain, around 50% global allocation (70% per domain)
· It works!
Comments:
· How was the simulation done? Was it realistic? Response: Actually it's trying to be pessimistic. The problem is that there's no real data, so knowing what to simulate is hard.
V. Limiting Allocations -- Dave Thaler
Two questions are raised in MASC:
· Who has permission to be a TLD (Top Level Domain)?
· How to prevent someone from claiming too many addresses?
Permission to be a TLD
· providers/transit domains can prevent customers from being a TLD (filter claims)
· can any backbone domain (or incompletely filtered domain) be a TLD?
· Easiest solution: why not?
· There is a tradeoff between aggregation of routes and address space utilization.
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?
· need to look up how much unicast space they have
· easy part: customer asking for space from a provider
· otherwise, this gets tricky...
Recommendations for MASC
· a provider should check their customers' claims
· the spec should allow for space limit checking
· working group should evaluate hard/soft/squidgy checking
· working group should discuss how to obtain limits
· working group should discuss how long can grab space for
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 will be a standalone protocol, compatible with but not dependent on DHCP.
· We will develop a technique for finding a MDHCP server and fetching the scope list without DHCP.
· We may get a different port number for MDHCP separate from DHCP (if working group consensus holds that this is important).
· We will make the MDHCP spec standalone, not just deltas from DHCP (although we may have deltas in an appendix).
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:
· How do you find a server? Response: There is a well known multicast address per scope zone.
· But why not use standard DHCP to find the server? Why do we need a different way of finding the server?
· Which scope zone should applications look for the server in?
· Where does the current implementation allocate from? Response: It allocates from an admin scoped range.
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:
· Should sdr be a Multicast Address Allocation Server (MAAS) or a client of a MAAS? Response: It doesn't matter, but making it an allocator makes it easier to deploy AAP now. We may change it later.
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...