rfc2771.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 620 行 · 第 1/2 页

Network Working Group                                     R. Finlayson
Request for Comments: 2771                                    LIVE.COM
Category: Informational                                  February 2000


            An Abstract API for Multicast Address Allocation


Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

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.

1. 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 (and
   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 (MADCAP)
   [1][7].  Alternatively, an "Address Allocation Server" implementation



Finlayson                    Informational                      [Page 1]

RFC 2771     Abstract API for Multicast Address Allocation February 2000


   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 traditional multicast
   service model [2].  Future multicast service models might allocate or
   assign multicast addresses in other ways, but this is outside the
   scope of this document.

2. 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)

   -  MulticastAddressSet: A set of "MulticastAddress"es

   -  LanguageTag: The code for a (human) language, as defined in [4]

   -  Scope: An "administrative scope" [3] from which multicast
             addresses are to be allocated.  Each scope is a
             "MulticastAddressSet", with an associated set of
             (character-string) names - indexed by "LanguageTag".  (Each
             language tag has at most one corresponding name, per
             scope.)  For each scope, a (language tag, name) pair may be
             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.)

   -  Time: An (absolute) event time.  This is used for specifying the
            "lifetime" of multicast addresses: the period of time during
            which allocated multicast addresses are guaranteed to be
            available.  (It is also used to specify the desired start
            time for an "advance allocation".)







Finlayson                    Informational                      [Page 2]

RFC 2771     Abstract API for Multicast Address Allocation February 2000


            Note that a concrete API might prefer to specify some of
            these times as relative times (i.e., relative to the current
            time-of-day), rather than absolute time.  (Relative times
            have the advantage of not requiring clock synchronization.)

   -  Lease: A compound data type that describes the result of a
             (successful) multicast address allocation.  It consists of:

             -  [MulticastAddressSet] The set of addresses that were
                allocated;

             -  [AddressFamily] The address family of these addresses

             -  [Time] The lifetime of these addresses (the same for
                each address)

             -  [Time] The "start time" of the allocation.  (See the
                discussion of "advance allocation" below.)  (A concrete
                API would likely also include a MADCAP "Lease
                Identifier" [1].)

   -  NestingRelationship: A binary data type that describes whether or
                           not two scopes nest. Two scopes nest if
                           traffic sent sent to a multicast group within
                           one scope could be seen by all hosts present
                           within the other scope were they to join the
                           multicast group within the first scope. This
                           value would be "False" for overlapping scopes
                           where only some (or none) of the hosts within
                           the second scope could see traffic sent to an
                           address due to the presence of an
                           administratively scoped boundary. In cases
                           where the first and second scopes are
                           topologically identical this value would be
                           "True."

   -  Status: A result code.














Finlayson                    Informational                      [Page 3]

RFC 2771     Abstract API for Multicast Address Allocation February 2000


3. The Abstract Interface

3.1 Allocating multicast addresses:

   alloc_multicast_addr(in AddressFamily family,
                        in Scope scope,
                        in Integer minDesiredAddresses,
                        in Integer maxDesiredAddresses,
                        in Time minDesiredStartTime,
                        in Time maxDesiredStartTime,
                        in Time minDesiredLifetime,
                        in Time maxDesiredLifetime,
                        out Lease multicastAddressSetLease,
                        out Status status)

   This operation attempts to allocate a set of multicast addresses (the
   size of this set is in the range [minDesiredAddresses,
   maxDesiredAddresses]) within the given address family and scope, and
   within a given range of desired lifetimes.  ("minDesiredStartTime"
   and "maxDesiredStartTime" are used to specify "advance allocation";
   this is described in more detail below.)

   If the address allocation succeeds, the result is returned in
   "multicastAddressSetLease" (with "status" = OK).

   During the lifetime of this lease, the allocation service will make a
   "best-effort" attempt to not allocate any of these addresses to
   others.  (However, once the lease's lifetime has expired, any of its
   addresses can be allocated to others.)

   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, if an
   application needs to consider 'renumbering', it will always know this
   in advance, at the time it acquired its current address(es) - by
   checking the lifetime in the returned lease.  An application will
   never need to be notified asynchronously of the need to 'renumber'.








Finlayson                    Informational                      [Page 4]

RFC 2771     Abstract API for Multicast Address Allocation February 2000


   Possible errors:

         - bad address family
         - bad scope
         - bad desired number of addresses (e.g., max < min)
         - bad desired lifetimes (e.g., max < min)
         - errors with the two "start time" parameters (see
           "Advance allocation" below)
         - no addresses can be allocated (for the requested parameters)

   An allocation attempt can also fail with a result "status" code of
   TRY_LATER, indicating that the requested allocation cannot be made at
   this time, but that it might succeed if the caller retries the
   attempt at some future time.  (This future time is returned in the
   "start time" field of the

   "multicastAddressSetLease";
           the other parts of this lease are undefined.)

   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 separate operations for:

           - allocating only a single address
             (i.e., minDesiredAddresses = maxDesiredAddresses = 1);
           - (attempting to) allocate an address with a single, fixed
              lifetime (i.e., minDesiredLifetime = maxDesiredLifetime);
           - (attempting to) allocate an address for immediate use
             (i.e., minDesiredStartTime = maxDesiredStartTime = 'now')

3.2 Changing multicast addresses' lifetime:

    change_multicast_addr_lifetime(in Lease multicastAddressSetLease,
                                   in Time minDesiredLifetime,
                                   in Time maxDesiredLifetime,
                                   out Time 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)





Finlayson                    Informational                      [Page 5]

RFC 2771     Abstract API for Multicast Address Allocation February 2000


           - 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
             (see section 5.9) - or they have already expired

3.3 Deallocating multicast addresses:

   deallocate_multicast_addr(in Lease multicastAddressSetLease) 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)

3.4 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