RFC 2771

An Abstract API for Multicast Address Allocation

📅 published February 2000, from ietf

RFC 2771: An Abstract API for Multicast Address Allocation ✨

okay bestie, this is RFC 2771 🦋 It's titled "An Abstract API for Multicast Address Allocation," written by R. Finlayson from LIVE.COM, filed as Informational, and dated February 2000. It came out of the Network Working Group 🌸 The title block doesn't list anything it obsoletes or updates.

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 (C) The Internet Society (2000). All Rights Reserved.

Abstract ✨

okay so this doc describes the "abstract service interface" for the dynamic multicast address allocation service, as apps see it 💅 It doesn't give you a concrete API (like one for a specific programming language). Instead it explains the semantics of the service in abstract terms, including the guarantees it makes to applications 🔥

Other documents (not necessarily IETF products) would describe concrete APIs for this service 🧚

1. Introduction ✨

apps are the customers of a multicast address allocation service, so the definition should cover not just the inter-node network protocols that build it, but also the "protocol" that apps use to access it 💖 APIs ("application programming interfaces") for specific programming languages (or operating systems) are outside the IETF's domain, but it's totally appropriate for us to define the semantic interface this service shows to apps, in abstract terms. Specific APIs would then be built on top of this abstract service interface 🫶

Here's the tea 🍓 there are at least two different ways to implement the multicast address allocation service. The first (and probably the most common) is for end nodes to get addresses by talking to a separate "Address Allocation Server" node, using the "Host to Address Allocation Server" network protocol (MADCAP) [1][7]. The other option is that an "Address Allocation Server" implementation lives on an end node alongside one or more applications, in which case some other, internal mechanism might be used to reach the server. Either way, though, the abstract service interface (and presumably any specific APIs) would stay exactly the same ✨

The rest of this document describes the abstract interface 💅

Note that this interface is only meant for allocating dynamic multicast addresses, the kind used by the traditional multicast service model [2]. Future multicast service models might allocate or assign multicast addresses in other ways, but that's out of scope for this document 🌈

2. Abstract Data Types 🦋

The interface below uses the following abstract data types:

  • AddressFamily: e.g., IPv4 or IPv6 🌸
  • MulticastAddress: An actual multicast address (i.e., one 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] that multicast addresses are to be allocated from. 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".) 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 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. ✨

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 tries to allocate a set of multicast addresses (the size of the 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 allocation succeeds, the result comes back 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 try to extend this lifetime, but that operation may fail. So an application must be prepared for the possibility that it won't be able to use the same addresses for as long as it wants. Specifically, 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. 😭 The good news is that if an application needs to think about "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." 🫶

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, which means the requested allocation can't be made right now, but it might succeed if the caller retries 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 tries to change the lifetime of previously allocated multicast addresses. Unless an error occurs, it returns the new lifetime (which might stay 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 (see section 5.9) - or they have already expired 🙈

3.3 Deallocating multicast addresses 🍓

deallocate_multicast_addr(in Lease multicastAddressSetLease)

This operation tries 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 scopes that are defined for this node. 🔥

Possible errors:

  • bad address family

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

Possible errors:

  • bad scope.

3.6 Querying the nesting state of known usable multicast address scopes: 🦋

Okay bestie, this one is a matrix moment 💅 You hand over a set of scopes you already got from get_multicast_addr_scopes(...), and back comes a matrix showing how those scopes nest inside each other 🧚

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

Possible errors:

  • bad scope.
  • nesting state undetermined at this time.

Basically the matrix tells you the current nesting relationships between the scopes you passed in. Iconic, honestly 👑

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

Next up is get_larger_scopes. You give it one Scope, and it gives you back the set of administrative multicast address scopes that are known to encompass it. So basically the "bigger sisters" 🌈

get_larger_scopes(in Scope,
                  out "set of" 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: 🍓

And the flip side, get_smaller_scopes ✨ You give it a Scope and it returns the set of administrative multicast address scopes that are known to nest inside it. Also (NB!) this includes the scopes that are topologically identical to the one you supplied, so don't forget those 🙈

get_smaller_scopes(in Scope,
                  out "set of" Scope)

Possible errors:

  • bad scope.
  • nesting state undetermined at this time.

3.9 Note: 💜

Okay, this part is kind of a plot twist. Who is allowed to deallocate (or change the lifetime of) a multicast address set lease is implementation-specific 🫶 It depends on the security policy of the host system, so this abstract API doesn't spell it out. Not me being vague, the spec is literally leaving it to the implementers 💀

That said, there is one possible starting point they floated:

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

So basically, the one who grabbed it is the one who gets to let it go 🔥

3.10 Advance allocation 🎀

Here's the vibe check on timing ⏰

If you put minDesiredStartTime = maxDesiredStartTime = 'now', then the address allocation operation, alloc_multicast_addr (from above), gives you a set of multicast addresses you can use immediately, and keeps them until their lifetime expires. During that whole time, nobody else can be allocated those addresses 🔒

But you can also go in advance with the minDesiredStartTime and maxDesiredStartTime parameters. This means the addresses get a future "start time" and an expiration time. Before that start time rolls around, the addresses are still allowed to be given to other people 🦋

Advance allocation is super handy for events that are far off, like several weeks or months away 📅 Without it, you'd have to hold addresses for that whole long stretch even when you're not using them. That's a wasteful use of the multicast address space 😭 It can also be a pain to implement, since address allocations are expected to stay valid even when the topology changes 🌐

Advance allocation requests can produce the following errors (on top of the ones defined earlier):

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

There's also one more operation:

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

This one tries to change the start time of addresses you already allocated. If nothing goes wrong, it returns the new start time, which might just be the same as before ✨

Possible errors: the same as "change_multicast_addr_lifetime"

4. Security Considerations 🔐

Real talk, this section is serious, so let's go 😤

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

Multicast addresses are a finite resource, which means there's a potential for a "denial of service" attack. Someone could allocate a huge number of multicast addresses and never deallocate them 💀 Stopping that attack isn't the job of the API, though. It's the job of the underlying MAAS ("Multicast Address Allocation Server(s)" [6]) 🛡️

5. Acknowledgements 🫶

Huge thanks to the other people in the "MALLOC" working group, especially Steve Hanna, Dave Thaler, Roger Kermode, and Pavlin Radoslavov, for their valuable comments 💖

6. References 📚

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

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

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

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

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

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

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

7. Author's Address 🖊️

Ross Finlayson, Live Networks, Inc. (LIVE.COM)

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

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

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

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

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

Acknowledgement 💜

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

📦 where this page comes from