NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 18-Feb-00
Chair(s):
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:
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 updated architecture document as a WG Internet-Draft |
Done |
|
Repost the MADCAP scope-nesting option document as a WG Internet-Draft |
Done |
|
Review and finalize the inter-domain protocol |
Done |
|
Submit the abstract API document(s) to the IESG for consideration as Informational. |
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 |
Mar 00 |
|
Review and finalize the intra-domain protocol |
Apr 00 |
|
Submit the intra-domain protocol to the IESG for consideration as a Proposed Standard. |
Apr 00 |
|
Submit the MIB for the host-server protocol to the IESG for consideration as a Proposed Standard. |
Apr 00 |
|
Submit the MIB for the intra-domain protocol to the IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· The Multicast Address Set Claim (MASC) Protocol
· The Internet Multicast Address Allocation Architecture
· Multicast Address Allocation MIB
Request For Comments:
RFC |
Status |
Title |
RFC2730 |
PS |
Multicast Address Dynamic Client Allocation Protocol (MADCAP) |
RFC2771 |
An Abstract API for Multicast Address Allocation | |
Multicast Address Allocation WG (malloc)
Thursday, March 30 at 0900-1130
===============================
CHAIRS: Dave Thaler <dthaler@dthaler.microsoft.com>
Steve Hanna <steve.hanna@sun.com>
AGENDA:
Agenda Bashing
Introduction and Document Status
Dave Thaler
(5 minutes)
AAP Updates:
Mark Handley
(30 minutes)
draft-ietf-malloc-aap-03.txt
MALLOC MIB Update:
Dave Thaler
(10 minutes)
draft-ietf-malloc-mib
IPv6 Multicast Address Allocation:
Brian Haberman
(5 minutes)
draft-haberman-malloc-ipv6-prefix-00.txt
draft-haberman-ipngwg-mcast-arch-00.txt
<Discussion on scoped source-specific groups added to end of agenda>
----------------------------------------------------------------------
Document Status
----------------
Two RFCs were published since the last meeting:
- MADCAP is now RFC 2730 (Proposed Standard)
- Abstract API is now RFC 2771 (Informational)
Three documents were sent to IESG since last meeting:
- Architecure Document (submitted for Informational)
- MADCAP Scope Nesting Option (submitted for Proposed Standard)
- MASC (submitted for Experimental)
Other WG Documents remaining:
- AAP
- MIB (blocked on AAP)
AAP Updates: Mark Handley
draft-ietf-malloc-aap-03.txt
----------------------------
lots of changes in 02
only explanation changes in 03
changes from 02 - 03
- Scaling Analysis (section 6) added: some errors, needs to be revised again
- Reccomendation that hosts use MADCAP instead of AAP if a MADCAP server is available
- Added discussion of allocation conflicts
- Beau Williamson asked: include text on how apps should deal with shifting addresses within a session? E.g. when we have an allocation conflict
- Dave Thaler responded: Not in AAP, this is part of session advertisements, this is something that is explained in the architecture document.
- Added examples (Appendix A)
- Noted reserved port number: 2878
- Removed Appendix D (Unresolved Issues)
recap from 01 - 02
1)
- Originally AAP assumed that could be large numbers of AAP speakers in a domain. e.g. sdr might speak AAP
- this no longer the intent
- can now use simpler algorithm for defending addresses
- use unform random backoff, not exponential random backoff
- aim is for approx 2-10 AAP speakers in a domain, with 1000 being the upper bound
2) Security mechanim
- Use IPSec AH instead of custom authentication
- Currently only use manual keying with a group-shared key
- SMuG is working on group-keying mechanisms for later on
What's next
- 3/00 Currently in WG last Call
- 4/00 Send to IESG, IETF Last Call
- 5/000? IESG approves as Proposed Standard
other docs will be discussed in zeroconf or mboned as approriate
MALLOC MIB Update: Dave Thaler
draft-ietf-malloc-mib-02.txt
----------------------------
RFC2465
- defines IPv6Address type
- IPv6-specific MIBs can use this -> draft-ops-endpoint-mib-07.txt
- defines protocol-independent InetAddress type
- should be RFC soon
- protocol-independent MIBs should use this
Changes to the MALLOC MIB
- IPv6 support now uses standard InetAddress types
- Updated MIB Boilerplate text
- Language names now use Language Tag type defined in Multicast MIB
- Added Guid type to identify leases
- Reading key now MUST return empty string (was MAY) (Thanks to Lars Viklund for reviewing this MIB)
ToDo
- Prefix coordinator config
- Has interval but not ranges to advertise
- Security
- currently has old "public key" objects
IPv6 Multicast Address Allocation: Brian Haberman
draft-haberman-ipngwg-mcast-arch-00.txt
---------------------------------------
presented in IPNG WG
Objectives
- Simplify IPv6 multicast address allocation
- Aid in debugging IPv6 multicast networks
- Single-source IPv6 multicast
Architecture change proposal
- borrow the idea from GLOP, but include the network prefix of the allocation domain in the mcast address
- can do this as only the bottom 32 bits actually get used
+---------+-----+----------------+----------+
| prefix | len | unicast prefix | group id |
+---------+-----+----------------+----------+
prefix is the multicast prefix to be reserved for this purpose
len is length of unicast prefix
Multicast Debugging
- Who owns the multicast address
- Who allocated the multicast address
Single-Source Multicast
- set "unicast prefix" to 0/0
This doc will been adopted as a WG document by the IPNG WG
IPv6 Multicast Allocation Guidelines: Brian Haberman
draft-haberman-malloc-ipv6-prefix-00.txt
----------------------------------------
- short document that describes guidelines for MAAS's for generating the low 32-bits of multicast addresses so as to avoid layer-2 clashes.
- use pseudo-random address, avoiding group IDs reserved by IANA for the All-hosts, All-routers, etc groups.
- should this be a malloc WG doc?
Thaler: must make explicit assumption that allocation of unicast implies allocation of multicast prefix as well.
There are content provides who would like to use scope to construct borders around countries etc. Is there enough richness there to allow these things?
Thaler: out of scope this WG is about allocation
Haberman: new IAB doc on scoped address architecture
Thaler: current IPv6 draft says that scopes must nest, can't define "arbitrary" ones unless they nest.
Handley: arbitrary scopes are hard to do beacuse they must be convex...you will create black holes
Handley: yes, this should be a malloc WG doc, it should probably be "proposed"
239 vs 232 Discussion
----------------------
Q: What addresses should be used for IPv4 source-specific, scoped groups?
A:
1) is to take one piece of the 232 range and divide it up for scoping things. Arg is don't do this as it makes advertising and filtering more difficult.
2) is to take a piece of each 239 subrange and make it source-specific. Arg is 239 is set aside as being scopable but not as source-specific. This can expand downwards into 238, though.
3) take 238 and carve it up just like 239, and distribution is the same. So MZAP announcement for (say) 239.192/16 implies that 238.192/16 is a source-specific range with the same distribution scope. This is much closer to the IPv6 proposal discussed earlier, where a single bit in the address can identify (independent of scope) whether the address is source-specific or not.
Casner: just let certain scopes in 239 be used as SSM
Holbrook: if we make the 232 range dynamic, then routers do
become the MZAP servers?
Handley/Casner: we need to keep 232 clean. If we put structure
in then we will run into allocaiton conflicts at scope
boundaries.
Handley: we could use MZAP to indicate SS range within 239,
this would require that ALL routers that could have local hosts
listen to MZAP in this range.
Thaler: If you're running IGMP then you could have local hosts.
The argument for 238 is that routers can filter on all of 238.
Casner: my main concern with 238 is fragmentation
email list: ssm@external.cisco.com
Actions:
1) Roger Kermode to resubmit MADCAP Nesting State Option Draft
to IESG after incorporating comments from ADs
2) Mark Handley to fix scaling analysis in AAP draft and resubmit
for WG last call
3) Brian Haberman to generate new document for immediate WG last call
4) Dave Thaler to generate new MIB and resubmit for WG last call
Thanks to Roger Kermode for taking minutes.
None received.