An Abstract API for Multicast Address Allocation
RFC 2771
|
Document |
Type |
|
RFC - Informational
(February 2000; No errata)
|
|
Author |
|
Ross Finlayson
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Internent Engineering Task Force (IETF)
|
|
Formats |
|
plain text
html
pdf
htmlized (tools)
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 2771 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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
Show full document text