RFC relevance of allocate

As per Relevance of the word allocate, we have this rfc below:

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

An Abstract API for Multicast Address

Status of this

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

Copyright

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

This document describes the "abstract service interface" for
dynamic multicast address allocation service, as seen
applications. While it does not describe a concrete API (i.e., for
specific programming language), it describes - in abstract terms -
the semantics of this service, including the guarantees that it
to applications

Additional documents (not necessarily products of the IETF)
describe concrete APIs for this service

1.

Applications are the customers of a multicast address
service, so a definition of this service should include not only
inter-node network protocols that are used to implement it, but
the 'protocol' that applications use to access the service.
APIs ("application programming interfaces") for specific
languages (or operating systems) are outside the domain of the IETF
it is appropriate for us to define - in abstract terms - the
interface that this service presents to applications. Specific
would then be based upon this abstract service interface

Note that it is possible to implement the multicast
allocation service in at least two different ways. The first (
perhaps most common) way is for end nodes to allocate addresses
communicating with a separate "Address Allocation Server" node,
the "Host to Address Allocation Server" network protocol (MADCAP
[1][7]. Alternatively, an "Address Allocation Server"

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
node, in which case some other, internal, mechanism might be used
access the server. In either case, however, the abstract
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
dynamic multicast addresses, as used by the traditional
service model [2]. Future multicast service models might allocate
assign multicast addresses in other ways, but this is outside
scope of this document

2. Abstract Data

The interface described below uses the following abstract data types

- AddressFamily: e.g., IPv4 or IPv

- MulticastAddress: An actual multicast address (i.e., that
subsequently be used as the destination of a datagram

- MulticastAddressSet: A set of "MulticastAddress"

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

- Scope: An "administrative scope" [3] from which
addresses are to be allocated. Each scope is
"MulticastAddressSet", with an associated set
(character-string) names - indexed by "LanguageTag". (
language tag has at most one corresponding name,
scope.) For each scope, a (language tag, name) pair may
defined to be the 'default' name for this scope. (See
section "Querying the name of a scope" below.)

(An implementation of this abstract data type might
include other information, such as a default TTL for
scope.)

- Time: An (absolute) event time. This is used for specifying
"lifetime" of multicast addresses: the period of time
which allocated multicast addresses are guaranteed to
available. (It is also used to specify the desired
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
these times as relative times (i.e., relative to the
time-of-day), rather than absolute time. (Relative
have the advantage of not requiring clock synchronization.)

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

- [MulticastAddressSet] The set of addresses that
allocated

- [AddressFamily] The address family of these

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

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

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

- Status: A result code

Finlayson Informational [Page 3]

RFC 2771 Abstract API for Multicast Address Allocation February 2000

3. The Abstract

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 (
size of this set is in the range [minDesiredAddresses
maxDesiredAddresses]) within the given address family and scope,
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
"multicastAddressSetLease" (with "status" = OK).

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

Multicast addresses are allocated for a limited lifetime.
application may attempt to extend this lifetime, but this
may fail. Therefore, an application must be prepared for
possibility it will not be able to use the same addresses for as
as it desires. In particular, the application must be prepared
either quit early (because its original multicast address
have expired), or, alternatively, to occasionally 'renumber'
multicast addresses (in some application or higher-level-
dependent way), by making a new allocation. However, if
application needs to consider 'renumbering', it will always know
in advance, at the time it acquired its current address(es) -
checking the lifetime in the returned lease. An application
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
- bad
- bad desired number of addresses (e.g., max < min
- bad desired lifetimes (e.g., max < min
- errors with the two "start time" parameters (
"Advance allocation" below
- no addresses can be allocated (for the requested parameters

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

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

Note that a concrete (i.e., programming language-specific) API
multicast address allocation will probably include additional
specialized variants of this general allocation operation.
instance, it may include separate operations for

- allocating only a single
(i.e., minDesiredAddresses = maxDesiredAddresses = 1);
- (attempting to) allocate an address with a single,
lifetime (i.e., minDesiredLifetime = maxDesiredLifetime);
- (attempting to) allocate an address for immediate
(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
allocated multicast addresses. Unless an error occurs, it
the new lifetime (which might remain unchanged).

Possible errors

- bad address
- 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
(and the existing lifetime was not in the requested
[minDesiredLifetime,maxDesiredLifetime])
- the addresses were not ones that we had
(see section 5.9) - or they have already

3.3 Deallocating multicast addresses

deallocate_multicast_addr(in Lease multicastAddressSetLease)
operation attempts to deallocate previously allocated
addresses

Possible errors

- bad address
- the addresses were not ones that we had
(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
scopes that are defined for this node

Possible errors

- bad address

3.5 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.
the scope has a name in the specified "language", then this name (
language) is returned. Otherwise, the scope's default (language
name) pair is returned

Possible errors

- bad scope

Finlayson Informational [Page 6]

RFC 2771 Abstract API for Multicast Address Allocation February 2000

3.6 Querying the nesting state of known usable multicast address scopes

get_scope_nesting_state(in "set of" Scope
out "matrix of" NestingRelationship

Possible errors

- bad scope
- nesting state undetermined at this time

This operation would return a matrix that shows
current nesting relationships between the
set of scopes which would have previously been
via the get_multicast_addr_scopes(...) function

3.7 Querying the set of scopes that a given scope is known to nest inside

get_larger_scopes(in Scope
out "set of" Scope

This operation returns the set of administrative
address scopes that are known to encompass the
Scope

Possible errors

- bad scope
- nesting state undetermined at this time

3.8 Querying the set of scopes that are known to nest inside a given scope

get_smaller_scopes(in Scope
out "set of" Scope

This operation returns the set of administrative multicast
scopes that are known to nest inside the supplied Scope (NB
would include those scopes that are topologically identical to
supplied scope).

Possible errors

- bad scope
- nesting state undetermined at this time

Finlayson Informational [Page 7]

RFC 2771 Abstract API for Multicast Address Allocation February 2000

3.9 Note: The decision as to who is allowed to deallocate (or
the lifetime of) a previously allocated multicast address set
is implementation-specific, and depends upon the security policy
the host system. Thus it is not specified in this abstract API
One possible starting point, however, is the following

A previously allocated multicast address can be deallocated (
have its lifetime queried or changed) by the same "principal",
on the same node, as that which originally allocated it
("principal" might, for example, be a "user" in the host
system.)

3.10 Advance

By specifying "minDesiredStartTime = maxDesiredStartTime = 'now'",
the address allocation operation - "alloc_multicast_addr" -
described above can be used to request a set of
addresses that can be used *immediately* (and until their
expires). During this whole time, the addresses are not
for allocation to others

It is also possible - using the "minDesiredStartTime"
"maxDesiredStartTime" parameters - to allocate multicast
*in advance* - i.e., so that they have a future "start time"
well as an expiration time. Before the start time, the
addresses may be allocated to others

Advance allocation is convenient for allocating addresses
events that begin far in the future - e.g., several weeks
months away. Without advance allocation, it would be necessary
allocate addresses for a long period of time - even when it
not be used. Such a request would not only be a wasteful use
the multicast address space, but it may also be difficult
implement (especially since address allocations are expected
remain valid in spite of topology changes).

Advance allocation requests can produce the following errors (
addition to those defined earlier):

- bad start time durations (e.g., max < min
- requested start times conflict with requested
(i.e., min start time > max lifetime

Finlayson Informational [Page 8]

RFC 2771 Abstract API for Multicast Address Allocation February 2000

The following operation is also defined

change_multicast_addr_start_time(in Lease multicastAddressSetLease
in Time minDesiredStartTime
in Time maxDesiredStartTime
out Time startTime

This operation attempts to change the start time of
allocated multicast addresses. Unless an error occurs, it
the new start time (which might remain unchanged).

Possible errors: the same as "change_multicast_addr_lifetime

4. Security

As noted in section 5.9 above, each implementation of this
API should define a security policy that specifies when (and by whom
previously allocated multicast addresses can be deallocated (
queried, or have their lifetime changed).

Because multicast addresses are a finite resource, there is
potential for a "denial of service" attack by allocating a
number of multicast addresses without deallocating them.
such an attack, however, is not the role of the API, but rather
the underlying MAAS ("Multicast Address Allocation Server(s)" [6]).

5.

Many thanks to other participants in the "MALLOC" working group -
particular Steve Hanna, Dave Thaler, Roger Kermode, and
Radoslavov - for their valuable comments

6.

[1] Hanna, S., Patel, B. and M. Shah, "Multicast Address
Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.

[2] Deering, S., "Host Extensions for IP Multicasting", STD 5,
1112, August 1989.

[3] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
2365, July, 1998.

[4] Alvestrand, H., "Tags for the Identification of Languages",
1766, March 1995.

Finlayson Informational [Page 9]

RFC 2771 Abstract API for Multicast Address Allocation February 2000

[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.

[6] Estrin, D., Handley, M. and D. Thaler, "The Internet
Address Allocation Architecture", Work in Progress

[7] Kermode, R., "MADCAP Multicast Scope Nesting State Option",
in Progress

7. Author's

Ross Finlayson
Live Networks, Inc. (LIVE.COM

EMail: finlayson@live.
WWW: http://www.live.com

Finlayson Informational [Page 10]

RFC 2771 Abstract API for Multicast Address Allocation February 2000

8. Full Copyright

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

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Finlayson Informational [Page 11]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX