MALLOC BOF at 40th IETF (Washington, D.C.)

• Overview of Architecture (slides)

  Mark Handley presented the overall architecture, which consists of the following elements:
  • MASC Proposal-Interdomain level
  • AAP Proposal-Intradomain level
  • MDHCP Proposal-Host level
  • Abstract API-Application level

  Requirements:

  • Allocate addresses on demand
  • Minimize probability of address allocation clashes
  • Maximize usage of the limited address space

  Non-goals: No guarantees of unique address allocation-not possible (with meeting other constraints, and not necessary)

• MASC Proposal-Interdomain level (Dave Thaler) (slides)

  MBONE Meetings happen every Monday.

  Draft made the I-D deadline.

  Low probability of collision.

  Adapt to long-term changes in topology (i.e. days)

  Avoid third-party dependencies.

  BGP was going to be used to distribute group range information, but BGP doesn't have all that is needed.

  MASC devices claim a range that gets advertised to all via MASC peerings. It waits to hear if there are any conflicts for a set period of time. If no conflicts, then they get advertised via BGP.

  1. Each AS picks a "parent". The heuristics for this are uncertain, but the examples created. The allocation hierarchy is not necessarily the same as the routing hierarchy, though it may be that the routing hierarchy provides a useful heuristic for parent selection.
  2. Select a subrange based on MASC advertisements received, by listening for parents' MASC advertisments. Child and parent both advertise via MASC, but NOT BGP.
  3. Wait for 48 hours (?) to detect collisions. All MASC speakers know the allocations for its parents, its siblings, and its children. If collision is detected, pick another subrange.
  4. If no collisions, then advertise route (make it official). This means injecting it into BGP in G-RI. Border routers send successfully-claimed ranges to a locally-scoped group of address allocators.
  5. BR's monitor address space utilization. If space gets tight, request new/larger range. If space empties out, can give back space by decreasing space in prefix announcements sent internally and stop defineding claim in MASC and withdraw from BGP G-RIB.

  The top-level consists of several sibling BGP peers in the current model. This generated a lot of discussion, since people were unclear how the top-level allocation will shake out from this, and were generally uncomfortable with the fuzziness level here. This is a big open issue.

  Overallocation is penalized because by overallocating, one agrees to become the root router for that whole new "domain".

  • MASC builds a hierarhy and allocates addres sets
  • BGP+ will then distribute to address sets in a G-RIB
  • BGMP uses the G-RIB to do multicast routing

  MASC is not tied to BGP or BGMP, but will prbably be in practice. Usually, BGP and BGMP will be expected at borders of the AS. There may be multiple multicast ASs within a single unicast AS.

  Claim-collide was chosen to avoid single root allocator.

  Group addresses have finite lifetimes, and expire if not defended.

  Open issue: contiguous vs. non-contiguous masks for suballocation.

  Pavlin from USC/ISI is running the simulations, and the initial results were presented. More on the website at http://netweb.usc.edu/pavlin/masc-results/.

• AAP Proposal-Intradomain level (Mark Handley, ISI) (slides)

  Since there may be many MAAS servers allocating from the same address set, they coordinate that activity via multicast. It's modeled after SAP.

  Near 100% utilization of addresses within a domain block.

  "Domain" will typically be an AS. If a unicast AS is too large, it can be split into multiple multicast AS's and BGMP run at the border.

  Very robust.

  The implementation of this is that a MAAS server must warm up a fixed period of time (e.g. 5 minutes) before ever allocating an address. After that time, the server chooses a random provisional announcement, waits for a collision, and if there's no problem, it claims and defends that address.

  A MAAS server can preallocate address by allocating them before receiving a request.

  Addresses can be deleted as an optimization. Since everything expires, this isn't a necessary feature, but probably desireable.

  MAAS servers send periodic ADDRESS-SPACE-REQUIRED messages reporting current or desired address space requrements to MASC servers.

• MDHCP Proposal-Host level (Munil Shah, Microsoft)(slides)

  Ability to request finite-time address allocations. MDHCP servers have a well-known multicast address in the admin scope. Applications obtain a list of multicast scopes from MDHCP servers. Client options: multicast scope, number of address, lease start and end. Server options: list of address ranges allocated. TTL of the addresses. Contiguous allocations are not necessarily supported. Munil then presented the API's that he implemented. Current drafts:
  • draft-ietf-dhc-mdhcp-03.txt
  • draft-ietf-dhc-multopt-02.txt

• Abstract API-Application level (Ross Finlayson) (slides)

  Only general API guidelines, not specific API. Two levels:
  • "Bozo-proof" basic API for most programmers.
  • Detailed API for advanced apps
  Basic API- alloc_multicast_addr which has scope, minimum life, maximium life, and spits out address and lifetime. dealloc_multicast_aaddr which just deallocates a multicast address. Open issue: are advance allocations necessary in API? Open issue: token-based allocations, which give a method of remote deallocations.

More information about all of this stuff can be found at the malloc web site at http://north.east.isi.edu/malloc/.