Network Working Group Ross Finlayson
Internet-Draft LIVE.COM
Expire in six months 1998.07.26
An Abstract API for Multicast Address Allocation
<draft-ietf-malloc-api-01.txt>
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
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 learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa) , nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast ), or
ftp.isi.edu (US West Coast).
2. Abstract
This document describes the ''abstract service interface'' for the dynamic
multicast address allocation service, as seen by applications. While it
does not describe a concrete API (i.e., for a specific programming
language), it describes - in abstract terms - the semantics of this
service, including the guarantees that it makes to applications.
Additional documents (not necessarily products of the IETF) would describe
concrete APIs for this service.
3. Introduction
Applications are the customers of a multicast address allocation service,
so a definition of this service should include not only the inter-node
network protocols that are used to implement it, but also the 'protocol'
that applications use to access the service. While APIs ("application
programming interfaces") for specific programming languages (or operating
systems) are outside the domain of the IETF, it is appropriate for us to
define - in abstract terms - the semantic interface that this service
presents to applications. Specific APIs would then be based upon this
abstract service interface.
Note that it is possible to implement the multicast address allocation
service in at least two different ways. The first (& perhaps most common)
way is for end nodes to allocate addresses by communicating with a separate
"Address Allocation Server" node, using the "Host to Address Allocation
Server" network protocol (MDHCP) [1]. Alternatively, an "Address Allocation
Server" implementation might be co-located (along with one or more
applications) on an end node, in which case some other, internal, mechanism
might be used to access the server. In either case, however, the abstract
service interface (and, presumably, any specific APIs) would remain the same.
The remainder of this document describes the abstract interface.
Note that this interface is intended only for the allocation of dynamic
multicast addresses, as used by the common multicast service model [2].
Other multicast service models - for example, "single-source multicast"
(e.g., [3]) - might allocate or assign multicast addresses in other ways,
but this is outside the scope of this document.
4. Abstract Data Types
The interface described below uses the following abstract data types:
- AddressFamily: e.g., IPv4 or IPv6
- Scope: The "administrative scope" [4] from which a multicast address is to
be allocated
- MulticastAddress: An actual multicast address (i.e., that could subsequently
be used as the destination of a datagram)
- Duration: A (non-negative) time interval. This is used for specifying the
"lifetime" of a multicast address: the length of time during which an
allocated multicast address is guaranteed to be usable. (It is also
used to specify the desired start time for an "advance allocation".)
Note that an actual API might prefer to specify these times using
absolute time (e.g., in UTC) instead of relative time.
Relative time, however, does not require any clock synchronization.
5. The Abstract Interface
Allocating a multicast address:
alloc_multicast_addr(in AddressFamily family,
in Scope scope,
in Duration minDesiredLifetime,
in Duration maxDesiredLifetime,
out MulticastAddress addr,
out Duration lifetime)
This operation attempts to allocate a multicast address in a given
family and scope, and within a given range of desired lifetimes.
Unless an error occurs, it returns an allocated multicast address,
along with its actual lifetime (which will be within the requested
range).
The allocated multicast address is guaranteed to be usable during its
lifetime, even if there are topology changes during this time.
Also, during this time, the allocation service will make a
"best-efforts" attempt to not allocate this same address to others.
(However, once an address's lifetime has expired, it can be allocated
to others.)
Note that an application that allocates a multicast address must be
prepared for the possibility it will not be able to allocate a
*single* address for the entire lifetime it desires. For example,
the application may be forced to quit early, or, alternatively, to
occasionally 'renumber' its multicast addresses (in some application
or higher-level-protocol dependent way). However, because of the
guarantee noted above, should an application need to 'renumber', it
can always know this in advance, at the time it acquired its current
address. An application will never need to be notified
asynchronously of the need to 'renumber'.
Possible errors:
- bad address family
- bad scope
- bad lifetime durations (e.g., max < min)
- no address can be allocated
Querying the lifetime of a multicast address:
query_multicast_addr_lifetime(in AddressFamily family,
in MulticastAddress addr,
out Duration lifetime)
This operation attempts to query the lifetime of a previously
allocated multicast address.
Possible errors:
- bad address family
- the address was not one that we[*] had allocated
(or it has already expired)
Changing a multicast address's lifetime:
change_multicast_addr_lifetime(in AddressFamily family,
in MulticastAddress addr,
in Duration minDesiredLifetime,
in Duration maxDesiredLifetime,
out Duration lifetime)
This operation attempts to change the lifetime of a previously
allocated multicast address. Unless an error occurs, it returns
the new lifetime (which might remain unchanged).
Possible errors:
- bad address family
- bad durations (e.g., max < min)
- the address was not one that we[*] had allocated
(or it has already expired)
Deallocating a multicast address:
deallocate_multicast_addr(in AddressFamily family,
in MulticastAddress addr)
This operation attempts to deallocate a previously allocated
multicast address.
Possible errors:
- bad address family
- the address was not one that we[*] had allocated
(or it has already expired)
Querying the set of usable multicast address 'scopes':
get_multicast_addr_scopes(in AddressFamily family,
out "set of" Scope)
This operation returns the set of administrative multicast address
scopes that are defined for this node.
Possible errors:
- bad address family
[*] An open question is: Who is allowed to deallocate (or query or change the
lifetime of) a previously allocated multicast address? Because these
operations have security implications, we guarantee only that:
A previously allocated multicast address can be deallocated (or have
its lifetime queried or changed) by the same "principal", and on the
same node, as that which originally allocated it.
The definition of "principal", however, is implementation dependent.
(It might, for example, be a "user" in the host operating system.)
Advance allocation
==================
With the basic address allocation operation - "alloc_multicast_addr" -
described earlier, a multicast address - once allocated - can be used
immediately (and until its lifetime expires). During this time, the
address is not available for allocation to others.
It is also possible to allocate a multicast address *in advance* - i.e.,
so that it has a future "start time" as well as an expiration time.
Before the start time, the multicast address may be allocated to others.
Advance allocation is convenient for allocating addresses for events that
begin far in the future - e.g., several weeks or months away. Without
advance allocation, it would be necessary to reserve an address for a long
period of time - even when it will not be used. Such a request would not
only be a wasteful use of the multicast address space, but it may also be
difficult to implement (especially since address allocations are expected
to remain valid in spite of topology changes).
advance_alloc_multicast_addr(in AddressFamily family,
in Scope scope,
in Duration minDesiredStartTime,
in Duration maxDesiredStartTime,
in Duration minDesiredLifetime,
in Duration maxDesiredLifetime,
out MulticastAddress addr,
out Duration startTime,
out Duration lifetime)
This operation is like "alloc_multicast_addr", except that it
returns a start time along with a multicast address (and lifetime).
The caller MUST NOT use (i.e., join or send packets to) this
multicast address prior to the start time. It MAY pass the address
to others (e.g., in session directory (SDP) announcements [5]),
provided that also passes the start time. Parties (such as session
directory browsers) that receive such announcements also MUST NOT
use the multicast address prior to the start time.
Possible errors: the same as "alloc_multicast_addr", plus:
- bad start time durations (e.g., max < min)
- requested start times conflict with requested lifetimes
(i.e., min start time > max lifetime)
query_multicast_addr_start_time(in AddressFamily family,
in MulticastAddress addr,
out Duration startTime)
This operation attempts to query the start time of a previously
allocated multicast address.
Possible errors: the same as "query_multicast_addr_lifetime"
change_multicast_addr_start_time(in AddressFamily family,
in MulticastAddress addr,
in Duration minDesiredStartTime,
in Duration maxDesiredStartTime,
out Duration startTime)
This operation attempts to change the start time of a previously
allocated multicast address. Unless an error occurs, it returns
the new start time (which might remain unchanged).
Possible errors: the same as "change_multicast_addr_lifetime"
6. References
[1] The "Host to Address Allocation Server" Protocol (MDHCP)
Work-in-Progress, IETF MALLOC Working Group
[2] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
August 1989.
[3] Cheriton, D., Holbrook, H., "EXPRESS Multicast",
Work-in-Progress, Stanford University.
[4] Meyer, D.,
"Administratively Scoped IP Multicast",
Work-in-Progress,
Internet-Draft "draft-ietf-mboned-admin-ip-space-06.txt", June, 1998.
[5] Handley, M., Jacobson, V. SDP: Session Description Protocol
Work-in-Progress,
Internet-Draft "draft-ietf-mmusic-sdp-07.txt", April, 1998.
7. Author's Address
Ross Finlayson,
Live Networks, Inc. (LIVE.COM)
email: finlayson@live.com
WWW: http://www.live.com/