NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 17-Aug-98
Chair(s):
Steve Hanna <steve.hanna@sun.com>
David Thaler <dthaler@microsoft.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>
Transport Area Advisor:
Vern Paxson <vern@ee.lbl.gov>
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:
May 98 |
|
Repost the architectural framework, including the abstract API model for allocating addresses, as WG Internet-Draft(s). |
Aug 98 |
|
Report on simulation and implementation efforts with existing protocol proposals. Address any problems in the specifications that were found. |
Oct 98 |
|
Post MIBs for the three levels as Internet-Drafts. |
Dec 98 |
|
Meet at Orlando IETF. Review and finalize the host-server protocol. |
Jan 99 |
|
Submit the host-server protocol to the IESG for consideration as a Proposed Standard. |
Jan 99 |
|
Submit the MIB for the host-server protocol to the IESG for consideration as a Proposed Standard. |
Jan 99 |
|
Submit the architecture and abstract API document(s) to the IESG for consideration as Informational. |
Apr 99 |
|
Submit the inter-domain protocol to the IESG for consideration as a Proposed Standard. |
Apr 99 |
|
Submit the MIB for the intra-domain protocol to the IESG for consideration as a Proposed Standard. |
Apr 99 |
|
Submit the intra-domain protocol to the IESG for consideration as a Proposed Standard. |
Apr 99 |
|
Submit the MIB for the inter-domain protocol to the IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· The Multicast Address Set Claim (MASC) Protocol
· Multicast address allocation based on the Dynamic Host Configuration Protocol
No Request For Comments
Minutes of MALLOC Working Group
IETF 42 (Chicago, IL)
Tuesday, August 25, 1998
Minutes reported by M. Smirnov and S. Hanna.
Agenda:
Agenda Bashing Hanna
Introduction Hanna
MASC Radoslavov
AAP Handley
MDHCP Hanna
MZAP Thaler
Advance Allocation Thaler
This is the first meeting of MALLOC as an IETF working group.
I. Agenda and Introduction
Steve Hanna presented the agenda and started with the introduction, which covered an
overview of the MALLOC architecture with 3 levels and subsequent protocols: MASC
for interdomain, AAP for intradomain and MDHCP for host-client interactions for
multicast address allocation. The introduction was concluded with the overview of the
status of MALLOC documents: architecture needs minor revisions (see later in minutes);
MASC, AAP, MDHCP and MALLOC API have been recently updated, however some
open issues do exist.
II. MASC
Pavlin Radoslavov gave a detailed overview of MASC according to draft-ietf-malloc-
masc-01.txt. Pavlin presented the goals, claim-collide mechanism, MASC topology
with possibly multiple relations (parent:child, sibling:sibling, internal:peer) in it. He
underlined that there is no requirement for a strict hierarchy, the MASC topology is
following unicast topology. A sample topology was introduced. MASC update messages
were presented with their formats and processing rules. The following issues were also
addressed: claims comparison function, expanding/renewing the prefix (via reclaim in
advance), releasing (via timestamp mechanism). Clash example based on the previously
introduced example of MASC topology was presented, as well as issues of dealing with
zones and changing the network provider. It was noted that MASC storage must keep
only local domain allocations.
In the following discussion it was proposed to start with a smaller range of addresses
managed by MASC while asking IANA to keep the rest of the whole range being
unassigned. There was a consensus that address ranges should not be mentioned in the
document while the TCP port number should be retained. It was also suggested and
generally accepted to move to a 32 bit MASC domain ID.
III. AAP
Mark Handley presented the new release of AAP: explanation was improved,
terminology (MASC router, MAAService, AAP node) was added; however there is no
IPv6 yet in the draft. The architecture permits every node to be a server, all AAP
messages are multicast. Six AAP messages are ASA, SSIG, ACLM, AITU, AU, ASRP.
There is no explicit Address Deletion message now while it is believed that timing
mechanisms will do the job. Mark has noted a number of open issues and possibilities
for improvements: server signature (SSIG) could be designed better, it is not clear
whether address prefixes (in ASA - Address set Announce) should be prefixes, masks
or ranges, AAP tunnelling (with a proxy MAAS in a previous domain).
The AAP discussion addressed the following questions. How many address sets would
usually be included in an ASA (Address Set Announce) message? This depends on the
behavior of the MASC server sending the message. Currently, we expect that such
servers would manage their addresses in such a way that the number of address sets in
an ASA message would be one or two.
Two new messages - Address Claim (ACLM) and Address Intent To Use (AITU) - are
serving in principle the same purpose. Which one should be used would be based on a
server load (busy server or quiet server). The document assumes that the decision on
whether a server is a busy or a quiet one is a local decision and should be kept for
implementation. Dave Thaler suggested that AITU is better anyway.
The requirement in the current draft for AAP servers to have stable storage should be
understood in such a way that if, e.g. a router has a stable storage then this router could
serve as a MAAS.
A question on ASRP (Address Space Report): How does a MASC router know when
it's time to decrease the allocation of addresses in a domain? By the absence of reports.
The opinion was expressed that the absense of explicit deletion in AAP is questionable.
While it could be considered an application side issue (which also could be linked with
the pre-allocation), the abstract API document has ADEL spec in it.
IV. MDHCP
Steve Hanna presented MDHCP update. It is based on DHCP design principles but is
not dependent on it. A server discovery is based on multicast, which should cause no
problem. Changes in the current draft are made in such a way that now it is completely
separate from the DHCP protocol, has a separate port number.
However, sharing of an options number space with DHCP might be dangerous,
therefore the DHCP WG approval is needed to avoid collisions between the two. One
of the open issues is which scope(s) to use for server discovery. There was a discussion
also on a motivation for support of MDHCP servers that provide services for scopes
they're not in, on language issues which are still to be addressed, on a desire to remove
unused fields from the MDHCP header, on a transition plan from a current practice to
a MALLOC architecture, and on the necessity to support whatever policies might be
introduced in the area.
Steve Hanna stated that the next steps are to resolve open issues and to go for the last
call for the MDHCP. The timeframe for this was stated as "a few months".
V. MZAP
Dave Thaler described how MZAP (Multicast-scope Zone Announcement Protocol) fits
into the malloc architecture, especially in distributing scope zone information.
It was noted that possible confusions with textual names should be resolved by boundary
routers. The multicast scope is considered to be small or big. For small scopes, MASC is
not used and AAP uses scope-relative addresses for communication. For large scopes,
MASC is used and AAP uses a single multicast address for communication.
Recommended is well-known allocation domain scope. With regard to this, the MALLOC
architecture document needs to be updated. Marc Handley pointed out that it is not clear
what to do with this, i.e. how to use big and small scopes: contributions are welcome.
VI. Advance Allocation
Dave Thaler presented then the issue of advance allocation as a summary of mailing list
discussion: motivation for pre-allocation and steps in pre-allocation. The steps are: pre-
allocation with return of (granted | trying | denied); advertisement with, say, 0.0.0.0 in
place of requested address; allocation (in case of "trying"); possibly (another) usage until
the start time. The maximum usage time of the addresses is an administrative decision.
Effects on other documents are as follows: abstract API and MDHCP need to include
"trying" result and way to fetch address later; AAP and MASC need no changes.
Michael Smirnov pointed that shortly before the 42nd IETF a new draft (draft-phillips-
malloc-util-00.txt) has been submitted with motivation for proactive pre-allocation. It
was decided to resubmit this draft for a discussion on the mailing list.
None received.