NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99
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 |
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 |
Internet-Drafts:
· The Multicast Address Set Claim (MASC) Protocol
· The Internet Multicast Address Allocation Architecture
· An Abstract API for Multicast Address Allocation
· Multicast Address Dynamic Client Allocation Protocol (MADCAP)
· Multicast Address Allocation MIB
No Request For Comments
Minutes of MALLOC Working Group
IETF 46 (Washington, DC)
Friday, November 12, 1999
Minutes reported by R. Quinn and S. Hanna.
Agenda:
- Agenda Bashing
- Introduction and Document Status
- Architecture Updates: Dave Thaler (draft-ietf-malloc-arch-03.txt)
- MADCAP Updates: Steve Hanna (draft-ietf-malloc-madcap-07.txt)
- MADCAP Scope Nesting Option Updates - Roger Kermode (draft-ietf-malloc-madcap-nest-opt-02.txt)
- AAP Updates: Steve Hanna (draft-ietf-malloc-aap-02.txt)
- MASC: Dave Thaler for Pavlin Radoslav (draft-ietf-malloc-masc-04.txt)
- Zero Configuration Multicast - Dave Thaler (draft-thaler-zeroconf-multicast-00.txt, sent to malloc list)
Agenda Bashing Thaler
Introduction & Document Status Thaler
Architecture Document Update Thaler
MADCAP Update Hanna
MADCAP Scope Nesting Option Update Kermode
AAP Update Hanna
MASC Update Thaler
Zero Configuration Multicast Thaler
I. Introduction and Document Status
Dave Thaler gave an overview of document status.
- Architecture doc: Recently revised to reflect comments from WG Last Call
- MADCAP doc: Approved by IESG for Proposed Standard
- AAP doc: In WG Discussion (recently updated)
- MASC doc: Recently revised to reflect comments from WG Last Call
- Scope Nesting doc: Recently revised to reflect comments from WG Last Call
- Abstract API doc: Sent to IESG for Informational
- MALLOC MIB doc: Waiting for AAP
- Static Allocation: moved out of MALLOC into MBONED
A revised version of the IPv6 multicast address static allocation scheme described in draft-haberman-malloc-static-ipv6-alloc-00.txt is expected soon (but this is not a MALLOC work item).
Dave also gave an overview of the MALLOC architecture.
II. Architecture Document Update
Dave described the changes made in the most recent version of the architecture document (draft-ietf-malloc-arch-03.txt) in response to feedback during the WG Last Call.
- A definition of "Allocation Scope" was added, with a proposed range of IPv4 admin scoped addresses and an IPv6 SCOP (6).
- A Security Considerations section was added.
There were no objections to sending the Architecture document directly to the IESG without another WG Last Call. This will be confirmed on the mailing list.
III. MADCAP Update
Steve Hanna explained that MADCAP (draft-ietf-malloc-madcap-07.txt) has been approved by the IESG for publication as a Proposed Standard. The changes since the last IETF meeting were pretty minor. The most significant one was that the INFORM message type was renamed to GETINFO, since the client uses it to request information from the server, not to inform the server of anything.
The next steps are implementation, then interoperability testing and eventually a move to Draft Standard status. Steve mentioned that Microsoft has client and server implementations in Windows 2000 and that he is working on a client implementation in Java.
Steve Casner asked what were the plans for the Java implementation and Steve Hanna said that no solid plans have been established yet. Anyone with strong opinions should contact him.
IV. Multicast Nesting State Option Update
Roger Kermode described the changes included in the latest version of the Multicast Nesting State Option document, which was sent to the malloc mailing list on Tuesday (draft-ietf-malloc-madcap-nest-opt-03.txt).
Typos were fixed. The requirement that the Multicast Nesting State Option appear after the Multicast Scope List option was removed. The INFORM message type was renamed to GETINFO to match the change in the MADCAP spec. Dependencies on MZAP were removed from the text (since you can statically configure scopes or use some other protocol for scope announcements and notification). And the document was restructured.
The next step is to assign a MADCAP option ID for this option and send the document to the IESG for publication as a Proposed Standard. Steve Hanna pointed out that we need to wait for MADCAP to be published as an RFC before this can happen.
V. AAP Update
Steve Hanna described the changes included in the latest version of the AAP specification (draft-ietf-malloc-aap-02.txt). This was a substantial rewrite of the document.
Support for IPv6 addresses was added. Address ranges are now used, instead of single addresses. IPsec is now used for security. And there is a new message type (ANA). Also several missing sections were filled in.
Steve then described AAP Security in more detail. Authentication of messages is the primary concern. The previous solution was to include a digital signature in each packet, but this would be expensive. The new solution is to use IPSec to authenticate packets. Because Ipsec does not currently include support for group key establishment, manual keying will need to be employed for now to establish and maintain a shared group key. However, the Secure Multicast Research Group (SMuG) in the IRTF is working on group key mgmnt and efficient per-sender authentication and it is hoped that this work will make AAP key management simpler in the future.
The choice to use IPSec was the result of discussions on the MALLOC mailing list. Steve asked if the group approved of the use of Ipsec and there was a generally positive repsponse from those present in the room (noone was against it, anyway).
Steve described the ANA message type that was added to the latest version of AAP. This message was added because the previous version of the spec required that one MAAS in the domain send periodic ASRP messages reporting on address space utilization, but it didn't provide a way for this MAAS to find out about failed allocations.
A MAAS sends ANA (Address Not Available) when an allocation fails. Other MAAS's make a note of the failure and address range. When any MAAS sends an address space report (ASRP) message to the prefix coordinator, it includes a summary of failed allocations. The ANA message is just sent a few times (not forever).If it is lost, it's not a big deal.
Dave Thaler said that the spec should point out that if you have responsive prefix coordinators, this should be a rare occurance. Normally, you won't have a huge jump in usage, so the allocation coordinator can track and predict usge. Failed allocations should be an exception condition rather than a normal state. Hence, using an ANA is a fall-back mechanism.
Roger Kermode asked if the ANA message could be used to mount a Denial of Service (DoS) attack. Steve said yes, that's one reason why authenticating AAP messages is important.
Steve asked that people read the latest spec and send comments to the MALLOC mailing list ASAP. He plans to put out another version next month and go to WG last call in December 1999. We hope to have the spec approved for publication as a Proposed Standard by spring.
Dave Thaler asked if timer reconsideration (a la SAP) should be done in AAP. Steve said that AAP uses a constant interval between messages, so timer consideration does not apply. Dave pointed out that a constant interval can cause scaling problems. Steve said that this is understood and we do not expect to have lots of AAP speakers in an allocation domain. We do not expect hosts to do AAP, except in highly constrained environments (which have small numbers of hosts anyway). Steve Casner pointed out that in SAP the number of announcements depends on the number of sessions, not the number of servers. Because AAP allows for many addresses to be included in a single AIU message, this does not apply to AAP.
VI. MASC Update
This presentation was prepared by Pavlin Radoslavov. However, Pavlin could not attend so Dave Thaler actually gave the presentation.
The MASC draft has recently been revised to reflect comments received during working group last call. This draft will eventually be submitted for publication as an Experimental RFC.
Summary of changes
- OPEN and UPDATE messages format modification: domain ID and Node ID lengths depend on AddrFam to get their lengths (to accomodate IPv6)
- The "A-bit" (active prefix bit in a claim) was renamed to "D-bit" (deprecated bit) and its polarity was reversed
- The "C-bit" (Close connection-bit in a notification message) was renamed to "O-bit" (the "keep connection Open" bit) and its polarity was reversed, to align with BGP and BGMP (to be consistent and allow code reuse). The purpose of this bit is to allow sending a non-fatal error that indicates the TCP connection should remain open.
- Authentication code option must include 2 values instead of 3: "The algorithm for computing values of Marker fields" is removed to try to keep this info private (to avoid helping an attacker and because it was unnecessary anyway).
- The "QUERY/RESPONSE debug messages" appendix was removed and is going to be put in separate document.
Any objections to submitting this to the IESG for publication as an Experimental RFC? There was some discussion about whether we would want to advance this to Proposed Standard at some later time and how that might be accomplished. But no objections were raised to going to Experimental at this time.
MASC Implementation Status
Pavlin has posted source code for a MASC implementation at http://netweb.usc.edu/masc/mascd. The next step for this implementation is to update it to reflect the changes in the latest MASC spec.
Pavlin has an experimental top level domain (TLD) and is allocating addresses. Feel free to launch your own experimental TLD and start peering with his. In response to a question, Dave clarified that Pavlin is using addresses from 225/8.
VII. Zero Configuration Multicast Allocation
Dave Thaler presented the ideas described in draft-thaler-zeroconf-multicast-00.txt. He gave this talk in the ZeroConf working group meeting, but only focused on the subset relevant to requirements (since that is all they are currently concentrating on there, as of yet).
A zeroconf environment is one where no configuration is done for any device (e.g. a home network). A configured environment is one where some devices (especially routers and servers) require configuration. Also, the zeroconf working group has restricted its work to environments which contain no more than one router and one gateway (a router leading out of the zeroconf environment).
Dave described the scopes where dynamic allocation of multicast addresses is allowed: node-local, link-local, local, other small scopes, other large scopes, global, and global single-source. Currently, node-local and link-local addresses are only available for dynamic allocation with IPv6 addresses. And global single-source addresses are only supported for IPv4 addresses (in 232/8).
Node-local, link-local, local, global, and global single-source scopes are well-known. That is, they have a well-defined range of reserved addresses that should always be present.
Dave pointed out that there may be a need for administratively scoped single source addresses. Where should these go? In 232/8 or 239/8 or somewhere else? Nobody expressed an opinion, so Dave promised to ask on the list.
The protocols that Dave suggests using to implement zeroconf multicast address allocation are: MADCAP, AAP, and MZAP.
The first service that applications need is scope enumeration: obtaining a list of scopes to allocate from, so they can choose one. Scope enum is NOT required to allocate from a well known scope.
Zeroconf hosts can assume existence of well-known scopes with default names. The hosts SHOULD do a MADCAP scope-enum query and cache answers. Preferably this should be done at startup and periodically thereafter, but it could be done at request time. If no MADCAP responses are received, the host MAY listen for MZAP messages.
A gateway should have the same behavior as a host, in a configured environment. It should also create a local scope boundary between the configured and zeroconf environments and reply to MADCAP scope-enum queries from the zeroconf side.
The second service that applications need is address allocation. Node-local and single source addresses can be allocated instantly, since each node has its own pool of these addresses. Allocation of link local, local, and other "small" addesses should always be available. Allocation of other ("big" and global) addresses should be available whenever possible.
Zeroconf hosts can handle allocation from node-local and single source addresses on their own. Link-local addresses can be allocated using a subset of AAP (what Dave calls "ARPing": choosing an address and sending a multicast claim for it, then using and advertising it if no collision is detected). For local and other "small" addresses, the host should send a MADCAP request first. If that fails, the host can ARP for an address. For global and other "big" scopes, the host should send a MADCAP request. If that fails, no addresses should be allocated from that scope.
Steve Hanna pointed out that there are scaling limits to the ARPing technique. Also, if a zeroconf network is connected to another zeroconf network (or to a configured network), previously allocated addresses may encounter collisions. Thaler said that zeroconf hosts must be able to deal with such situations.
Steve Casner asked how useful link-local allocaton is for hosts? Dave said that it is mainly useful for expanding ring/scope searches and situations where there is a large number of hosts and you want very local scopes.
Zeroconf gateways can act as mini-MAAS's, providing multicast address allocation services to hosts in the zeroconf area. For node-local, link-local, and single source addresses, they won't be involved. For local addresses, they can act as a full MAAS, but then they need to have stable storage. Or they can let hosts ARP, but that doesn't scale well. For other small addresses, they can pass requests to a parent MADCAP server. If that fails, they can act as a full MAAS or let hosts ARP. For global and other large addresses, they must pass requests to a parent MADCAP server.
This is a nice extension to what the MALLOC group has done.
Steve Hanna asked why not let the gateway act as a full MAAS for global and other large addresses. Dave said maybe this is right.
Steve Hanna said this should not require any changes to the MADCAP spec, which is good, but we may need changes to the AAP spec. Dave said it requires an additonal field in AAP, but we wanted to do this anyway.
Steve Casner asked what names should be assigned to scopes when there's no MADCAP server. It was generally agreed that a host can provide reasonable defaults if no information is available. But a zeroconf gateway should provide a way to set the zone name for the Local scope (for instance).
Steve Casner also asked how an application can figure out the semantics of the scopes in the scope list. Dave said that the application could use the scope ID for well-known scopes.