| INTERNET DRAFT |
R Briscoe
|
| MALLOC(?) Working Group |
M Tatham
|
| Expiration: 26 May 1998 |
BT
|
|
21 Nov 1997
|
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
The primary problem is that multicast addresses are fixed by session initiators, but aggregation relies on a clustering pattern emerging from the demography of the receivers. Further, the initiator usually doesn't know who the receivers will be until after the addresses to be used have been fixed. Therefore, any clustering beyond small-scale aggregation within applications will have to be achieved on a longer time-scale by session initiators predicting the likely demography of their session (e.g. based on past experience of similar sessions). The job of these predictive systems will be much simpler if they have some degree of pre-existing aggregation to nucleate around, rather than having to crystallise aggregation from complete chaos without any bootstrap process.
A large class of applications utilises multiple multicast addresses
internally. Further, many such applications consist of varying sets of
multiple multicast groups that are all sub-sets of a bigger set (e.g. news,
stock-feeds, network games, virtual worlds, distributed simulations, all
applications using layered multicast [1]).
Any solution should ensure that such "nucleating applications" use aggregations
of addresses that can be identified as such.
Related work is described later. Most is
in the area of straightforward multicast address allocation, which is,
perhaps surprisingly, far from being sorted out. It is very difficult,
indeed probably reckless, to comment on proposals that have only been hinted
at in the odd mailing list posting, or conference presentation. However,
it appears that most schemes are assuming that aggregation will be possible
if addresses are allocated based on the topological position in the Internet
of the root of the multicast tree. Although this may well be the case,
it is only true if most multicast applications will tend to be used by
groups of users that happen to use the same ISP (Internet Service Provider),
or they use ISPs that have a common parent ISP. No evidence that this is
the case has been presented. In some cases the tree root even seems to
be (erroneously) assumed to be in the same place as the session initiator
(the party requesting the address). Certainly, nowhere does it seem to
be taken into account that the likely receiver topology is just as important
in determining whether multicast trees can be aggregated. Some of the proposals
that are available also seem to implicitly assume that routing state will
be aggregated in the same way unicast routing is aggregated - by discarding
the right-hand bits of addresses which have common left-hand bit fields,
despite there being no greater significance to any bit in a multicast address.
These criticisms may prove to be unfounded when the work in question is
published in detail.
The primary thesis of this paper is that it will never be possible
to aggregate multicast state in routers if there is no means to name
aggregations of multicast addresses. In unicast, an address prefix
is an aggregation name, but for multicast the prefix means nothing. A similar
concept is required, but with radically different properties and requirements.
These names must take up significantly less space than would the list of addresses themselves. Further, if only some sizes of aggregations can be named, this will lead to wastage of addresses. Therefore, any solution must offer a way to name arbitrary sized aggregations. Further, the naming of aggregations must not make any one type of address more in demand than others (e.g. addresses with trailing zeroes, or with sequences of zeros) or encourage the hoarding of certain addresses. It should also be possible to grow or shrink the size of the set identified by the name, while avoiding clashes with addresses in use by other sessions. An informal list of further requirements of address allocation schemes, which are not directly relevant to the discussion here, is at [26].
These aggregation names should themselves be open to aggregation, implying the naming should be recursive. Otherwise the small-scale clustering that the "nucleating applications" will be able to engender, will simply result in these small clusters collecting in routers deeper into the network. Where two names might be aggregated, it should be possible to test this possibility, based on the structure of the names, rather than by trial and error or exhaustive expansion to the lists of addresses that the names resolve to.
To encourage their use, these aggregation names should offer convenience and efficiency for the programmer. Preferably they should enable bulk joins to and leaves from sets of multicast addresses. The "nucleating applications" would then naturally assist the network in aggregating together multicast addresses, not out of any sense of altruism, but because using an atomic name for an aggregation is convenient for the programmer and efficient for the system it runs on.
This approach could be accused of moving away from random address allocation and therefore possibly encouraging address hoarding. Certainly, once a pattern emerges, the aim should be to bias address allocation to re-inforce the pattern. However, this is still originally based on random allocation, so shouldn't lead to hoarding as long as we don't aim to re-inforce patterns to such an extent that they become entrenched beyond their useful life.
For conciseness, we shall refer to this tuple of multicast address and aggregation parameters as an aggregated multicast address (AMA(i)).
Thus, it is intended that AMAs are used in future versions of Internet
Group Management Protocol (IGMP) [3, 4]
and the various multicast routing protocols (DVMRP [5,
6], CBT [7, 8,
9] & PIM [10, 11,
12]) to replace multicast addresses wherever
they are used. It would also be highly advantageous for session directory,
invitation and announcement protocols (e.g. SDP [13],
SAP [14] & SIP [15])
to evolve to use AMAs in place of multicast addresses. Evolution from the
current version of IGMP and multicast routing protocols and from current
session description protocols is discussed under the "Evolution"
section.
Further, it would be natural for evolving multicast address allocation
schemes ([20, 21]) to use
AMAs to define allocations concisely. Just as sets of related AMAs can
be aggregated together into a single AMA, the reverse is also possible.
Thus parts of large allocations can be "sub-allocated" to further parties
if required. However, allocation of multicast addresses (and hence AMAs)
is not as straightforward as for unicast addresses. Allocation issues are
discussed under the section on "Probability
of address aggregation".
Firstly we shall define how an AMA is constructed and how its construction
affects its meaning. Then we shall follow through a typical life-cycle
of an AMA:
The address-like component of an AMA is defined to be a concatenation of bit-fields as shown (with recommended values of bit widths shown for IPv4 - see discussion later):
If n + d > wr , the bit mask simply wraps round into the right-hand end of the remainder, r.
The value within the masked bits, vmin (100b
in this example) determines the base or minimum address of the AMA(ii).
The value of the aggregate size, s, (recall this is
associated with an address, not part of it) determines the upper or maximum
address of the AMA by setting the maximum value in the masked bits, vmax,
where:
For convenience, we might denote an AMA as so far described by the tuple:
Further, as the sequence of pairs along the AMA is processed,
Again continuing the above example to illustrate this point, if we denote a8 as the address related to a0 like so:
Although trees "a" and "d" have roots that could well be in the same domain (autonomous system), their receiver sets have caused them to grow in completely opposite directions so no aggregation would be possible. Tree "e" is completely contained within tree "d" although their roots could well be in completely unrelated domains. Thus it should be possible to aggregate the routing information they need. Tree "a" is nearly contained within tree "b", so it would be desirable to be able to aggregate their routing at least where they overlap. Trees "a" and "c" have a similar relationship to that between "a" and "b". Trees "b" and "c" cross eachother at the network core so some aggregation may be possible where the directions of the trees coincide on certain links. There could even be occaisions where the routing of "a", "b" and "c" can all be aggregated together.
It should now be possible to see that, although it is more likely that two trees with close roots will have routing information that is condusive to aggregation, this is by no means a necessary or sufficient condition. In fact it appears that receiver distribution is a better indication of aggregation potential.
A multicast address needs to be allocated when a session is initiated, at which time the likely receiver topology may be difficult to predict. For certain types of tree (e.g. source-based) it is much easier to be certain where the root should be at this early stage. For core-based trees, the positioning of the core is ideally dependent on the prediction of the receiver topology (which can be sketchy, as we have already said).
Receiver topology is difficult but not impossible to predict. This usually reduces to a marketing-type problem. What is clear is that address allocation schemes that are based exclusively on the position of the root of the multicast tree (or worse the position of the session initiator, who may not even be taking part once the session is going) will not realise anything close to the full aggregation potential of any conceivable topologies of multicast trees that are likely on the Internet. A good scheme must allow addresses to be allocated to sessions based on a combination of root and receiver topology. It is outside the scope of this paper to solve how this allocation would be done, but it is clear that a scheme that disallows a future solution to this problem is a bad scheme.
The scheme proposed for AMAs allows just such a combination of allocation between root and receiver topology. Taking the example AMA used already,
A simple short term solution for an address allocation scheme might be to generate g, d and f from an algorithm seeded by a unicast address prefix (or a set of a few representative prefixes) that represents the majority of likely receivers and the unicast address of the tree root. The latter would be necessary if the tree were source-based, but it may be possible for the allocation service (or some other service) to suggest the best tree root position if using core-based multicast.
Therefore, it is recommended that ws be dependent on the value of m at least in the environments indicated:
It is recommended, at least for router storage, that m = 0 is used to indicate an AMA that is actually just a single discrete multicast address, where associating a size of 1 with it would be a waste of space.
However, this appears to make the widest possible mask 15 bits, because it precludes using m = 0 to mean n = 16. Although the need for a 16 bit wide mask is likely to be rare, it is still possible to force the mask to be this wide by exploiting the equivalence of the two AMAs in the following example (due to the ability of t to increment m, given in formula (3)):
Note that the width of t would always follow the same rule as that for s. That is:
Note that if t forces m to increment into a range that would alter the width of both t and s (formula (4)), the increase in width of t doesn't happen until the next pair of t and s, if at all, while the s in the current pair should be widened immediately. The reasoning, is that the width of t mustn't be affected by its own value.
The application (or session initiator) now predicts the likely receiver topology for the session it is initiating. From this, it decides the best position for the root of the multicast tree(s) that make up the session (or some other service does this at its request). The application would then pass all these constraining parameters, including the size of AMA it required to the address allocation service. The address allocation service would return an AMA of the required size.
To arrive at an AMA, it would internally (probably) allocate g
based on the receiver topology and d and f based on the
root and receiver topology given to it by the application.
Also, internally, it would have to calculate n such that 2n-1
< smax, but 2n >= smax
.
In other words, it would decide integer n where no more than
2n multicast addresses are needed in the session. m
follows rather straightforwardly from formula (1).
For example, if the session needed 6 multicast addresses and m0
= 0, it would use m = n = 3.
We shall assume the address allocated is the example address used above.
It then joins 6 multicast groups simultaneously by sending one message to join the AMA:
In fact, if there is a finite possibility of simultaneous allocation, the above is not necessarily the best opening strategy for grabbing a set of free multicast addresses. Which strategy is best depends on the size of the set required and the level of utilisation of the address space (which will oscillate daily and increase into the future, decreasing the probability of finding a free set in a single attempt). This is a large enough problem space to become a topic for study in its own right (see Further Work), so it is not gone into in any depth here, save to make some broad generalisations.
If the probability of finding a free set of multicast addresses first
time is high, the obvious strategy would be to just try another address
set if part of the first was busy. If the allocation service couldn't guarantee
all its allocations were not in use, it would have to be possible to receive
a slightly different response to a repeated identical request.
Otherwise it may be best to test a larger set than is required, then
drop the busy ones. AMAs make this easy, as it is often possible to derive
one smaller AMA from a larger one to deliberately avoid some of the addresses.
Yet a third method would be to try a number of contiguous or overlapping
AMAs, then drop those that tested busy and amalgamate the remaining ones
into one AMA (again often but not always possible).
The comments in this section on allocation of AMAs for applications apply equally well to allocation of AMAs to allocation sub-authorities in an allocation hierarchy. However, it is made clear in the section on Probability of aggregation that allocation hierarchies per se are not a panacea where multicast is concerned.
It might be desirable to send the same information to multiple multicast group addresses using only one socket and one flow of packets through the network. If a clear need for this were identified, it would be sensible to use the same addressing scheme as AMAs provide. However, no clear need is immediately apparent to the author, so it would not be sensible to update APIs for sending to multicast sockets and the router code that disseminates multicast packets so that they act on this extra parameter.
Similarly, a call to leave an AMA would translate directly to a (future) IGMP call to leave. If the call to leave an AMA resolved to a sub-set of the multicast addresses previously joined, the router would be designed to be able to handle contracting the size of the AMA it considered was still of interest on that interface (or layer 2 address) down to the AMA that mapped to the remaining addresses. The host stack would also have to be able to contract its AMA for it to regularly refresh the soft-state of the remaining joined addresses.
The stack would have to ensure the frequency of join refreshes remained sufficient while it amalgamated or contracted down any out of phase AMA refreshes.
AMAs can be used as a consistent computational type for addressing any number of multicast addresses, whether the AMA resolves to many or just a single multicast address. In fact, APIs (application programming interfaces) could pre-empt the introduction of AMAs into the network, by presenting AMAs to the programmer but having middleware or the stack convert AMAs into sets of discrete multicast addresses until the network is upgraded. However, it would be sensible for routers and protocols to signify an AMA of size 1 by not storing or passing the aggregation size parameters at all (see Further storage optimisation - this would help backward compatibility too). Otherwise the efficiency benefits of the scheme would be offset by the 25% increase in storage required for each non-aggregated, isolated address. On the other hand, to hide AMAs from those programmers not interested in sessions with multiple multicast addresses, it may well be best to implement an API for AMAs by overloading a similar one for discrete multicast addresses(iii).
The section on Router Implementation should be referred to for more detail on these matters.
To expand a session beyond the original smax but still with a single AMA sometimes requires time for preparation of the ground and a degree of luck. In all cases this is because one is attempting to acquire use of extra multicast addresses without altering the addresses already being used. This limits the sets of interesting multicast addresses to AMAs that are related to the one in use. This is a limitation of the AMA scheme when compared to schemes based on arbitrary masks such as [19] (which has different limitations discussed under Related work). However, this was a concious compromise to avoid the larger storage needed for arbitrary masks as opposed to contiguous ones.
The following operations would (probably) be enacted by the address
allocation service in response to a request to increase the size of an
existing allocation (the uncertainty is because the detailed design of
such a service is outside the scope of this paper).
Firstly, if not already there, smax should be increased
to 2n and the new addresses tested for prior allocation.
If enough addresses still aren't free, n can be incremented without harm, then s can be doubled for every increment and the new addresses tested.
If this doesn't find enough free addresses, keeping n incremented , vmin can be changed while s is increased to try addresses related to the current range which will still give the network a chance to aggregate addresses as long as other receivers are co-operating within the same rules.
If this doesn't work, one can look for a close but disjoint AMA (or AMAs) and watch for a gap between the current AMA and the new one until it can be closed by a superset AMA later.
Beyond that, the only solution is to give up and use more than one AMA, but this is unlikely to be necessary.
Currently, the most general form of multicast routing table is a database with (a usually large number of) rows for each unique address/source pair as follows:
The routing row for this super-AMA is similar to the previous row structure, except that:
Obviously, the row structure above isn't the most efficient for routing look-ups. It is more suited for routing updates. This suggests that a read-optimised data-structure should be built from this write-optimised structure and both held by the router, with the former being regularly refreshed from the latter. This is similar to the way most unicast routing is implemented. Whether there is one read-optimised table per router or a number of sub-sets of the main table specific to each interface is beyond the scope of this paper.
For IPv4, a width of 4 for the offset was a compromise. Ideally the width would have allowed any offset value across the remainder (28 - wd). Note that, if the offset did allow the mask to start anywhere in the remainder, this does not mean there would be no space in the remainder that was guaranteed to always be outside the mask (e.g. for address allocation related to the position of the tree root - see "How an application would assign an AMA" above). This depends on the mask width, not the offset size. Therefore, wd could have been set to 5 leaving the remainder 23 bits wide. However, this would only have used half the value of the fifth bit, so 4 was chosen as a compromise between availability of more descriptions for AMAs and utilisation of bits. It should be noted that, because AMAs overlap in their use of addresses, there are diminishing returns in having more ways to split the description of sub-groups of the address space. Also a 5/23 split was "binarily awkward" compared to a 4/24 split.
The bit mask is deliberately fixed on its right-hand end so that when m is varied, the LSB of the mask stays in the same place otherwise large-scale aggregation would be terribly hard.
AMA-enabled hosts and routers shouldn't send or forward joins or leaves
to routers that don't understand AMAs, they should convert the AMAs to
lists of discrete multicast addresses.
This assumes routers can determine which version of a multicast routing
protocol their upstream router for each interface is using. This should
be straightforward as version stamped routing will also be arriving at
the interface down that link (multi-host links will cause complications
for some routing protocols). This also assumes hosts can determine which
version of IGMP is being used by their upstream router which should be
possible, but is probably difficult.
Session descriptions would either have to use both forms for an interim period, or parallel descriptions in the two versions would have to be transmitted on different channels.
IGMP, multicast routing protocols and the session description protocols could evolve independently as long as applications and AMA-enabled routers had the capability installed to convert AMAs into lists of discrete multicast addresses when necessary.
Where allocation of ranges of addresses to organisations is concerned there is concensus among the known proposals that these should not be static. Range allocations should be over one (longish) timescale with the allocation of addresses from within that range for the duration of individual sessions. The intention is to avoid long term "ownership" of addresses ranges by assuring organisations that they will be able to have addresses on demand as long as they co-operate with everyone else in returning unused address space. Thus the multicast address allocation proposals are distinct from unicast in the following aspects:
The BGMP (Border Gateway Multicast Protocol) draft [24], proposes a new architecture for Inter-Domain IP multicast:
Aggregation of multicast addresses by this scheme will probably mean it is more efficient for routers to store multicast routing state keyed on interface than on multicast address. In other words, a table of aggregated multicast addresses would be held for each interface, rather than a table of interfaces for each address. The implications of this need investigation.
The problem of how a router would efficiently look up each multicast packet in a table of AMAs has been deliberately left to one side. Because AMAs are logically similar to unicast address prefixes, similar techniques should be appropriate. This may not appear obvious, because an AMA is more obfuscated than a unicast routing prefix. Briefly, the first item to be extracted from an incoming packet would be d. This would point to where the mask started. The eight bits to the right of this mask would then be guaranteed to be unmasked (invariant), so d and this octet could be looked up in a Patricia trie or similar but more efficient data-structure [16]. The two potentially masked octets would then have to be built into another similar look-up table. Finding any one address in this structure would again be akin to the longest prefix (shortest mask) problem.
It is possible that m is redundant, but it is believed that keeping it will make the aggregation maths a lot easier .
Applicability of AMAs as a solution to reliable multicast clustering/layering
needs assessment.
Applicability of AMAs for aggregation in RSVP (reservation protocol)
[27] when used for multicast needs assessment.
Further work is needed on the potential for using AMAs to insulate upstream routers from high join/leave churn by introducing pessimistic inertia in the aggregation. The effect on leave latency (particularly where used for congestion control in layered multicast) would need careful study.
The assertion that the weak capability for allocation growth (as compared to kampai-style addressing) is offset by more efficient storage needs more justification.
It is believed that, due to topological realities, aggregation in the network will never approach the aggregation potential of applications that use sessions with multiple multicast addresses. This would be a strong argument against aggregation schemes that are not end to end, but this needs proving.
Evolution from current versions of protocols needs more careful analysis.
The design of an AMA scheme for IPv6 [18] needs to be done.
ATM (asynchronous transfer mode) multicast may benefit from a scheme based on similar thinking?
It is possible that the aggregation of multicast addresses into sets for use in the description of complex sessions will cause service providers to hoard multicast addresses more than when they are allocated singly. The scheme has been carefully designed to avoid such a tendency on technical grounds, but predicting how selfish people adapt based on their understanding of a mechanism moves us into the realms of psychology where anything goes. In other words, address hoarding shouldn't be any worse than the situation was without this proposal as long as people don't misunderstand.
This proposal is considered independent of all aspects of the security of (encrypted, tamper-proofed, authenticated etc.) multicasts.
For IPv4, AMAs look like a 32 bit IP address coupled with, typically, an extra octet (but more generally with two octets) representing the size of the aggregation of addresses. The list of addresses that form the aggregation are defined by identifying a string of bits (of defined width) within the address, which are incremented as if they were a binary number in their own right until the aggregation size is reached. All but the first four bits of the address-like component represents the base address of the aggregation from which the incrementation starts. Because multicast addresses always(iv) start with the same four bits in IPv4 (1110b), the first four bits of an AMA can be used to store another value in transit and storage, but replaced by 1110b to derive the base multicast address of the aggregation when required. The value stored in the first four bits of an AMA represents the width of the field within the AMA which varies to define the list of addresses. Related but disjoint AMAs can also be represented efficiently by using the most general AMA form: an AMA followed by a sequence of alternating pairs of numbers which represent respectively a further jump from the based address then a further size of aggregation on top of this.
In the scheme recommended for IPv4, potentially an arbitrary-sized aggregation of any size up to 216 - 1 multicast addresses could be represented by a field the size of an IPv4 address (4B) plus 2B (256kB reduced to 6B). However, it should be understood, that such ultra-large-scale aggregation has a low probability of happening without higher-level organisation of the address space by end-systems. First or second order aggregation will occur naturally under this scheme due to the large class of applications that build sessions from multiple multicast addresses. Medium-scale aggregation will be possible where routers can identify overlap or concatenation within multicast routing tables, which was not possible before without a way to describe aggregations of multicast addresses. This is because the AMA scheme is inherently recursive, so that it is possible to merge certain sets of AMAs into one AMA. To improve the chances of aggregation in multicast routing tables, address set allocation schemes must fulfil certain criteria that are laid down in this paper.
The proposal is that AMAs will completely replace multicast addresses in contexts where aggregation makes sense, that is when describing, joining, leaving or updating the routing of multicast addresses. For sending data to and receiving data from multicast addresses, aggregation, and therefore AMAs, are not relevant. This implies protocols for describing multicast sessions (such as SDP, SAP, SIP, RSVP etc.) and protocols for updating the routing of multicast addresses (such as IGMP, DVMRP, CBT, PIM) will all need to be updated to handle AMAs in place of discrete multicast addresses. Independent evolution of all these protocols is considered to be reasonably straightforward. Although this represents a major round of protocol upgrades, all these protocols are experimental, and it is a commonly held view that multicast as it stands is not sufficiently scalable for wide-area deployment.
It should be clarified that, although joining and leaving aggregates of multicast addresses can be achieved in single bulk operations, AMAs deliberately overlap in their use of individual addresses. Thus, allocation remains on a per address basis. In other words, when joining an AMA, it may be found that some of the addresses within it are in use if a strong address allocation scheme is not in use. An AMA allocation procedure is described in the text for mutating the AMA to cover an overlapping set of addresses to avoid those addresses in use while testing different addresses, until a full set of unused addresses is obtained without losing the addresses in the original AMA that were free.
To summarise, we have presented a new paradigm(v) for multicasting, such that describing, joining, leaving and updating multicast routing can and should all be discussed in terms of aggregates of multicast addresses (even if they are of size unity) rather than discrete multicast addresses. We have introduced an efficient, elegant way to name such aggregates that preserves all the architectural principles on which multicast addressing is founded, and which will allow potentially large-scale aggregation of multicast addressing by both end-systems and routers in end to end co-operation.
[2] S.E.Deering, "Multicast Routing in Internetworks and Extended LANs", In Proceedings of the ACM SIGCOMM'88, Stanford, California, Aug 1988
[3] S.E.Deering (Stanford U.), "Host Extensions for IP Multicasting", IETF RFC, Aug 1989 <rfc1112.txt>
[4] W. Fenner (Xerox PARC), "Internet Group Management Protocol, Version 2", IETF Internet Draft, 01 Nov 1997, <draft-ietf-idmr-igmp-v2-08.txt>
[5] D. Waitzman, C. Partridge, S. Deering, "Distance Vector Multicast Routing Protocol" v1, IETF RFC, Nov 1988, <rfc1075.txt>
[6] T. Pusateri (Juniper Networks), "Distance Vector Multicast Routing Protocol", IETF Internet Draft, 30 Oct 1997, <draft-ietf-idmr-dvmrp-v3-05.txt>
[7] A.Ballardie, J.Crowcroft, "Core Based Trees: An Architecture for Scalable Inter-Domain Multicast Routing", In Proceedings of the ACM SIGCOMM'93, San Francisco, Sep 1993
[8] A. Ballardie, "Core Based Trees (CBT) Multicast Routing Architecture", IETF RFC, Sep 1997, <rfc2201.txt>
[9] A. Ballardie, "Core Based Trees (CBT version 2) Multicast Routing", IETF RFC, Sep 1997, <rfc2189.txt>
[10] S.E.Deering, D.Estrin, D.Farinacci, V.Jacobsen, L.Ching-Gung and L.Wei, "An Architecture for Wide-Area Multicasting". In Proceedings of the ACM SIGCOMM'94, London, Sep 1994
[11] Deering, S, et. al., "Protocol Independent Multicast Version 2, Dense Mode Specification", IETF Internet Draft, 28 May 1997 <draft-ietf-idmr-pim-dm-spec-05.txt>
[12] Estrin, D, et. al., "Protocol Independent Multicast Sparse-Mode (PIM-SM): Protocol Specification", IETF Internet Draft, 9 Sep 1997, <draft-ietf-idmr-pim-sm-specv2-00.ps>
[13] M. Handley (ISI) and V. Jacobson (LBNL), "SDP: Session Description Protocol", IETF Internet Draft, 02 Sep 1997, <draft-ietf-mmusic-sdp-04.ps>
[14] M. Handley (ISI), "SAP - Session Announcement Protocol", IETF Internet Draft (currently expired, see Multiparty Multimedia Session Control IETF working group charter for status <http://www.cs.utk.edu/~moore/san-jose/wg/mmusic/charter.html>)
[15] M. Handley (ISI), H. Schulzrinne (Columbia U.), E. Schooler (Caltech), "SIP: Session Initiation Protocol", IETF Internet Draft, 13 Nov 1997, <draft-ietf-mmusic-sip-04.ps>
[16] M.Degermark, A.Brodnik, S.Carlsson, S.Pink, "Small Forwarding Tables for Fast Routing Look-ups", In Proceedings of the ACM SIGCOMM'97, Cannes, France, Sep 1997 <http://www.acm.org/sigcomm/sigcomm97/program.html#ab192>
[17] D. Meyer, University of Oregon, "Administratively Scoped IP Multicast", IETF Internet Draft, Nov 1997, <draft-ietf-mboned-admin-ip-space-04.txt>
[18] R. Hinden, Ipsilon Networks and S. Deering, Xerox PARC, "IP Version 6 Addressing Architecture", IETF RFC <rfc1884.txt>
[19] P. Tsuchiya, Bellcore, "Efficient and flexible Hierarchical Address Assignment", to be published - author's address: <tsuchiya@thumper.bellcore.com>
[20] M. Handley (ISI), "AAP: Address Allocation Protocol" (presentation), In Proceedings of the 39th IETF (mmusic working group) <http://www.ietf.org/proceedings/97aug/toc-97aug.html>
[21] D. Estrin (ISI), M. Handley (ISI) and D. Thaler (Merit), "MASC: Multicast Address Set Claim" (presentation), In Proceedings of the 39th IETF (idmr working group) <http://www.ietf.org/proceedings/97aug/toc-97aug.html>
[21] Tony Bates et al., Cisco Systems, Juniper Networks, "Multiprotocol Extensions for BGP-4", 26 Sep 1997, <draft-ietf-idr-bgp4-multiprotocol-01.txt>
[22] Baiju V. Patel, Intel Corp, Munil Shah, Microsoft Corp. "Multicast address allocation extensions to the Dynamic Host Configuration Protocol", IETF Internet Draft, 24 Nov 1997, <draft-ietf-dhc-mdhcp-03.txt>
[23] Internet Assigned Numbers Authority, "Internet Multicast Addresses", <ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses>
[24] D. Thaler (U. Michigan), D. Estrin (USC/ISI) and D. Meyer (U. Oregon) , "Border Gateway Multicast Protocol (BGMP): Protocol Specification", IETF Internet Draft, 30 Oct 1997, <draft-ietf-idmr-gum-01.txt>
[25] R. Briscoe, "Rejected ideas for End to End Aggregation of Multicast Addresses", 13 Nov 1997, <http://www.labs.bt.com/people/briscorj/projects/lsma/e2ama_rejects.html>
[26] M. Handley, "Multicast address allocation", in archive of postings to ipmulticast mailing list, 19 Jun 1997, <http://www.ipmulticast.com/hypermail/ipmulticast/0144.html>
[27] L. Zhang, S. Deering, D. Estrin, S. Shenker, and D. Zappala, "RSVP: A New Resource ReSerVation Protocol" In IEEE Network, Sep 1993, <http://www.isi.edu/div7/rsvp/pub.html>
[28] This paper itself, in HTML format <http://www.labs.bt.com/people/briscorj/projects/lsma/e2ama.html>
ii) The multicast addresses that are within the bit mask defined by the width m, but not between vmin & vmax (defined by vmin and s) are not "wasted" by using an AMA. In the example used above, the addresses with v = 001, 010 & 011 are not reserved by the AMA. They can be used by a completely different application and different set of users. The bit mask is just a way of narrowing the context of the s parameter (to define when it wraps). It causes no direct effect on address space utilisation, but without it, it is believed aggregation would be a lot more difficult.
iii) Application programs and even routers should never need to know the list of multicast addresses that an AMA resolves to (other than for evolution from today's protocols). They will not need to bit shift along multicast addresses to find the value of d, then bit shift d bits back from the end to find the mask etc. The AMA tuple can be used by applications in all cases in place of listing the set of addresses it resolves to {this statement needs proving, mind - I haven't worked through AMA aggregation, expansion and contraction maths yet, but we live in hope!}.
iv) A discussion of the issues if this turns out to not always be the case is under the section on "Further storage optimisation".
v) There are some places where the "p word" really is appropriate.