HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 23:54:04 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 27 Apr 1998 14:30:00 GMT ETag: "2e9962-2f1d-35449668" Accept-Ranges: bytes Content-Length: 12061 Connection: close Content-Type: text/plain Network Working Group Ross Finlayson Internet-Draft Live Networks Expire in six months 1998/03/11 An Abstract API for Multicast Address Allocation 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 [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. In the remainder of this document, we first describe a basic, easy to understand abstract interface that would likely be used by most applications. We then describe additional, more advanced, operations that might become part of an extended interface. (This additional functionality remains speculative, however; this working group has not reached consensus about it.) 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. Note that an actual API might prefer to specify lifetimes using absolute time (e.g., in UTC) instead of relative time. Relative time, however, does not require any clock synchronization. 5. The Basic 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 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.) 6. Possible Extensions Some possible extensions to the basic interface have also been proposed. (These remain speculative, however.) i) Advance Allocation In the basic interface, 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. Some people have proposed that an application also be able to allocate a multicast address *in advance* - i.e., to have a future "start time" as well as an expiration time. Before the start time, the multicast address may be allocated to others (and therefore, should not be used by the original allocator). Advance allocation would be convenient for allocating addresses for events that begin far in the future - e.g., several weeks or months away. Without advance allocation, it is necessary to reserve an address for a long period of time - even when it will not be used. This is not only (arguably) 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). On the other hand, allocating a multicast address that cannot be used until some future start time is dangerous; it's rather like handing a child a package labeled "do not open before Christmas". It would be easy for a misbehaving application to join the group (or worse, send to it) prematurely. For this reason, an advance-allocated multicast address could not safely be used in session directory (SDP) announcements [5]. Instead, SDP announcements would have to contain a special 'placeholder' value (to be defined), which would get updated - with the real address - close to the start time. An alternative approach would be for the "advance allocation" operation to return a "promise": a special token that can be 'redeemed' (to reveal the actual multicast address) only on (or after) the start time. However, this would add some complexity to the interface (& implementation), and would still not solve the problem of how to make advance SDP announcements. ii) Token-Based Deallocation In the basic interface, described earlier, once a multicast address has been allocated, it is guaranteed only that it can be deallocated by the *same* node (& principal). Depending on the implementation, it might also be possible for other nodes within the same administrative domain to deallocate the address. However, *arbitrary* nodes - anywhere on the Internet - will not be able to deallocate the address. (Ditto for changing an address's lifetime.) To address this problem, it has been suggested that the "allocate" operation (or some variant thereof) return some sort of "token" in addition to the multicast address. This token would be used as a parameter to the "deallocate" (and "change lifetime") operation, and could potentially be used by a remote node. The major drawback of this suggestion is that it introduces a complex new mechanism, for relatively little benefit. These "tokens" would need to be globally unique, and would effectively be "capabilities" (in the security sense). 7. References [1] The "Host to Address Allocation Server" Protocol 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-04.txt", November, 1997. [5] Handley, M., Jacobson, V. SDP: Session Description Protocol Internet-Draft "draft-ietf-mmusic-sdp-05.txt" 8. Author's Address Ross Finlayson, Live Networks, Inc. email: finlayson@lvn.com WWW: http://www.lvn.com/