[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 01 02 03 04 05 06 07 rfc2771                                  
Network Working Group                                   Ross Finlayson
Internet-Draft                                          LIVE.COM
Expire in six months                                    1998.11.18

               An Abstract API for Multicast Address Allocation

                   <draft-ietf-malloc-api-04.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), ftp.ietf.org (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
- MulticastAddress: An actual multicast address (i.e., that could subsequently
        be used as the destination of a datagram)
- MulticastAddressRange: A set of contiguous "MulticastAddress"es
- LanguageTag: The code for a (human) language, as defined in [5]
- Scope: An "administrative scope" [4] from which a multicast address is
        to be allocated.  Each scope consists of a "MulticastAddressRange",
        and a non-empty set of (character-string) names, indexed by
        "LanguageTag".  (Each language tag has at most one corresponding name,
        per scope.)  For each scope, one (language tag, name) pair is defined
        to be the 'default' name for this scope. (See the section
        "Querying the name of a scope" below.)
        (An implementation of this abstract data type might also include other
        information, such as a default TTL for the scope.)
- 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.
- Status: A result code.

5. The Abstract Interface

Allocating a multicast address:
        alloc_multicast_addr(in AddressFamily family,
                             in Scope scope,
                             in Integer minDesiredAddresses,
                             in Integer maxDesiredAddresses,
                             in Duration minDesiredLifetime,
                             in Duration maxDesiredLifetime,
                             out MulticastAddressRange addresses,
                             out Duration lifetime)
        This operation attempts to allocate a contiguous set of
        multicast addresses (the size of this set is in the range
        [minDesiredAddresses, maxDesiredAddresses]) within the given
        family and scope, and within a given range of desired lifetimes.
        Unless an error occurs, it returns a range of allocated
        multicast addresses, along with their actual lifetime
        (which will be within the requested range).  (Each address within
        the returned range will have this same lifetime.)

        A "best-effort" attempt will be made to maintain multicast routing
        for allocated multicast addresses during their lifetime, even if
        there are topology changes (such as a change of upstream provider)
        during this time.  Also, during this time, the allocation service will
        make a "best-effort" attempt to not allocate any of these addresses
        to others.  (However, once an address's lifetime has expired, it can
        be allocated to others.)

        Note that multicast addresses are allocated for a limited lifetime.
        An application may attempt to extend this lifetime, but this
        operation may fail.  Therefore, an application must be prepared
        for the possibility it will not be able to use the same addresses
        for as long as it desires.  In particular, the application must
        be prepared to either quit early (because its original multicast
        address assignments have expired), or, alternatively, to occasionally
        'renumber' its multicast addresses (in some application or
        higher-level-protocol dependent way), by making a new allocation.
        However, because of the guarantee noted above, if an application needs
        to 'renumber', it will always know this in advance, at the time it
        acquired its current address(es).  An application will never need
        to be notified asynchronously of the need to 'renumber'.

        Possible errors:
                - bad address family
                - bad scope
                - bad desired number of addresses (e.g., max < min)
                - bad desired lifetime durations (e.g., max < min)
                - no addresses can be allocated (for the requested parameters)

        Note that a concrete (i.e., programming language-specific) API for
        multicast address allocation will probably include additional,
        specialized variants of this general allocation operation.  For
        instance, it may include operations for allocating only a single
        address (i.e., minDesiredAddresses = maxDesiredAddresses = 1),
        and/or for (attempting to) allocate an address with a single,
        fixed lifetime (i.e., minDesiredLifetime = minDesiredLifetime).

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 they have already expired)

Changing multicast addresses' lifetime:
        change_multicast_addr_lifetime(in AddressFamily family,
                                       in MulticastAddressRange addresses,
                                       in Duration minDesiredLifetime,
                                       in Duration maxDesiredLifetime,
                                       out Duration lifetime)
        This operation attempts to change the lifetime of previously
        allocated multicast addresses.  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 addresses' lifetime could not be changed
                  (and the existing lifetime was not in the requested range
                  [minDesiredLifetime,maxDesiredLifetime])
                - the addresses were not ones that we[*] had allocated
                        (or they have already expired)

Deallocating multicast addresses:
        deallocate_multicast_addr(in AddressFamily family,
                                  in MulticastAddressRange addresses)
        This operation attempts to deallocate previously allocated
        multicast addresses.

        Possible errors:
                - bad address family
                - the addresses were not ones that we[*] had allocated
                        (or they have 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

Querying the name of a scope:
        get_scope_name(in Scope scope,
                       in LanguageTag language,
                       out String name,
                       out LanguageTag languageForName)
        This operation returns a character-string name for a given scope.
        If the scope has a name in the specified "language", then this name
        (and language) is returned.  Otherwise, the scope's default
        (language, name) pair is returned.

        Possible errors:
                - bad scope


[*] An open question is: Who is allowed to deallocate (or query or change the
lifetime of) a previously allocated multicast address?  This is an
implementation-specific decision, dependent upon the security policy of the
host system, and is not specified in this abstract API.  One possible
starting point, however, is the following:
        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.  ("principal" 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 Integer minDesiredAddresses,
                                     in Integer maxDesiredAddresses,
                                     in Duration minDesiredStartTime,
                                     in Duration maxDesiredStartTime,
                                     in Duration minDesiredLifetime,
                                     in Duration maxDesiredLifetime,
                                     out Status status,
                                     out MulticastAddressRange addresses,
                                     out Duration startTime,
                                     out Duration lifetime)
        This operation is like "alloc_multicast_addr", except that
        (if "status" is OK) it returns a start time as well as a multicast
        address range (and lifetime).  The caller MUST NOT use (i.e., join
        or send packets to) any of these multicast addresses prior to the
        start time (unless, of course, an address happens to be used as part
        of a different multicast session).  The caller MAY pass these
        addresses to others (e.g., in session directory (SDP) announcements
        [6]), provided that it 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.

        The other possible value of "status" is TRY_LATER, indicating that
        the requested allocation could not be made, but that the caller should
        retry the advance allocation attempt after a delay of at least
        "startTime".  (In this case "addresses" and "lifetime" are undefined.)

        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 MulticastAddressRange addresses,
                                         in Duration minDesiredStartTime,
                                         in Duration maxDesiredStartTime,
                                         out Duration startTime)
        This operation attempts to change the start time of previously
        allocated multicast addresses.  Unless an error occurs, it returns
        the new start time (which might remain unchanged).

        Possible errors: the same as "change_multicast_addr_lifetime"

Note that a concrete implementation of this API does not have to provide
separate operations (as described above) for advance allocation.  As an
alternative, each of the "lifetime" parameters in the earlier operations
could be specified as a pair of durations: (start,end).

6. Security Considerations

As noted in point [*] above, each implementation of this abstract API should
define a security policy that specifies when (and by whom) a previously
allocated multicast address can be deallocated (or queried, or have its
lifetime changed).

Because multicast addresses are a finite resource, there is a potential for
a "denial of service" attack by allocating a large number of multicast
addresses without deallocating them.  Preventing such an attack, however,
is not the role of the API, but rather the underlying protocols (AAP [7]
and MASC [8]) that implement it.

7. References

[1] Patel, B., Shah, M., Hanna, S., "Multicast address allocation based on
    the Dynamic Host Configuration Protocol",
    Work-in-Progress, Internet-Draft "draft-ietf-malloc-mdhcp-01.txt",
    November, 1998.
[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",
    RFC 2365 (BCP 23), July, 1998.
[5] Alvestrand, H., "Tags for the Identification of Languages",
    RFC 1766, March 1995.
[6] Handley, M., Jacobson, V., "SDP: Session Description Protocol",
    RFC 2327, April 1998.
[7] Handley, M., "Multicast Address Allocation Protocol (AAP)",
    Work-in-Progress, Internet-Draft "draft-ietf-malloc-aap-01.txt",
    August 1998.
[8] Estrin, D., Handley, M., Govindan, R., Thaler, D., Radoslavov, P.,
    Kumar, S., "The Multicast Address Set Claim (MASC) Protocol",
    Work-in-Progress, Internet-Draft "draft-ietf-idmr-masc-01.txt",
    August 1998.

8. Author's Address

        Ross Finlayson,
        Live Networks, Inc. (LIVE.COM)
        email: finlayson@live.com
        WWW: http://www.live.com/