RFC 7046
A Common API for Transparent Hybrid Multicast
Part 1 of 8 🎀
RFC 7046: A Common API for Transparent Hybrid Multicast ✨
okay so this RFC is from the Internet Research Task Force (IRTF), so it's research-y, not a standards-track thing 🧪 Here's the lineup:
- Number: RFC 7046 💖
- Category: Experimental 🦋
- ISSN: 2070-1721
- Date: December 2013 📅
- Authors: M. Waehlisch (link-lab & FU Berlin), T. Schmidt (HAW Hamburg), and S. Venaas (Cisco Systems) 👑
- Obsoletes / Updates: the title block doesn't list any, so this one doesn't obsolete or update anything else 🫶
Abstract
okay so group communication is EVERYWHERE and it comes in a zillion flavors, implemented at different protocol layers 🌈 Multicast (sending one thing to a whole group at once) is most efficient when it runs on the lowest layer available, BUT multicast tech is deployed unevenly across the Internet, so apps need to pick the best service at runtime 🔥 The tricky part is that it's genuinely hard to write one app that runs everywhere AND grabs the most efficient multicast service available 😭 So devs often give up and use a stable upper-layer protocol built into the app itself, which is giving "I'll just do it myself" 💅
This document describes a common multicast API that works for transparent communication in both underlay and overlay networks, and it gives you access to the different flavors of multicast 🦋 It proposes an abstract naming scheme based on multicast URIs, and it talks about mapping between different namespaces and distribution technologies 🧚 It also shows how to use this API to build gateways that connect the current Multicast Domains across the Internet 🌸 Lastly, it reports on an implementation of the programming Interface, including service middleware ✨ This document is a product of the Scalable Adaptive Multicast (SAM) Research Group 💜
Status of This Memo
This is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation. 🧪
This document defines an Experimental Protocol for the Internet community. It's a product of the Internet Research Task Force (IRTF), which publishes the results of Internet-related research and development. These results might not be suitable for deployment 💀 This RFC represents the consensus of the Scalable Adaptive Multicast Research Group of the IRTF. Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741 🙈
Information about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc7046 🔗
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document 🌈
Table of Contents 🗺️
1. Introduction ....................................................4
1.1. Use Cases for the Common API ...............................6
1.2. Illustrative Examples ......................................7
1.2.1. Support of Multiple Underlying Technologies .........7
1.2.2. Support of Multi-Resolution Multicast ...............9
2. Terminology ....................................................10
3. Overview .......................................................10
3.1. Objectives and Reference Scenarios ........................10
3.2. Group Communication API and Protocol Stack ................12
3.3. Naming and Addressing .....................................14
3.4. Namespaces ................................................15
3.5. Name-to-Address Mapping ...................................15
3.5.1. Canonical Mapping ..................................16
3.5.2. Mapping at End Points ..............................16
3.5.3. Mapping at Inter-Domain Multicast Gateways .........16
3.6. A Note on Explicit Multicast (Xcast) ......................16
3.7. MTU Handling ..............................................17
4. Common Multicast API ...........................................18
4.1. Notation ..................................................18
4.2. URI Scheme Definition .....................................18
4.2.1. Syntax .............................................18
4.2.2. Semantic ...........................................19
4.2.3. Generic Namespaces .................................20
4.2.4. Application-Centric Namespaces .....................20
4.2.5. Future Namespaces ..................................20
4.3. Additional Abstract Data Types ............................21
4.3.1. Interface ..........................................21
4.3.2. Membership Events ..................................21
4.4. Group Management Calls ....................................22
4.4.1. Create .............................................22
4.4.2. Delete .............................................22
4.4.3. Join ...............................................22
4.4.4. Leave ..............................................23
4.4.5. Source Register ....................................23
4.4.6. Source Deregister ..................................23
4.5. Send and Receive Calls ....................................24
4.5.1. Send ...............................................24
4.5.2. Receive ............................................24
4.6. Socket Options ............................................25
4.6.1. Get Interfaces .....................................25
4.6.2. Add Interface ......................................25
4.6.3. Delete Interface ...................................26
4.6.4. Set TTL ............................................26
4.6.5. Get TTL ............................................26
4.6.6. Atomic Message Size ................................27
4.7. Service Calls .............................................27
4.7.1. Group Set ..........................................27
4.7.2. Neighbor Set .......................................28
4.7.3. Children Set .......................................28
4.7.4. Parent Set .........................................28
4.7.5. Designated Host ....................................29
4.7.6. Enable Membership Events ...........................29
4.7.7. Disable Membership Events ..........................30
4.7.8. Maximum Message Size ...............................30
5. Implementation .................................................30
6. IANA Considerations ............................................30
7. Security Considerations ........................................31
8. Acknowledgements ...............................................31
9. References .....................................................32
9.1. Normative References ......................................32
9.2. Informative References ....................................33
Appendix A. C Signatures ..........................................35
Appendix B. Use Case for the API ..................................37
Appendix C. Deployment Use Cases for Hybrid Multicast .............38
C.1. DVMRP ......................................................38
C.2. PIM-SM .....................................................38
C.3. PIM-SSM ....................................................39
C.4. BIDIR-PIM ..................................................401. Introduction ✨
okay so bestie, right now group app programmers have to pick the distribution tech their app needs at runtime, which is giving very much "stuck choosing an outfit before knowing the party" 💀. There's no common communication Interface that hides multicast transmission and subscriptions from whatever the deployment looks like at runtime, and nobody has really settled on using DNS for Group Addresses 🙈. The standard multicast socket options [RFC3493] [RFC3678] are tied to one IP version because they don't separate the naming of a multicast identifier from its addressing. And group communication is honestly messy because it:
- comes in different flavors, like any-source multicast (ASM) vs. source-specific multicast (SSM) 🎀,
- happens on different layers (IP vs. application-layer multicast) 🧚, and
- can be built on different technologies on the same tier, like IPv4 vs. IPv6 🌈.
So the goal of this doc is to give programmers universal access to group services 👑.
Multicast app development should be decoupled from the technology deployed throughout the infrastructure 💅. What it needs is a common multicast API with calls to send and receive multicast data that don't care about the supporting layer or the underlying tech details ✨. For transmissions between different technologies, everyone also needs a consistent view of multicast states 🫶. This document describes an abstract group communication API and the core functions needed for transparent operations 🦋. Implementation guidelines for specific operating systems or programming languages are out of scope here, so don't come looking for them in this doc 🙈.
Compared to the standard multicast socket Interface, this API separates naming from addressing 💖. Using a multicast address in the current socket API basically locks in the routing layer 😭. In this spec, the multicast name you use to join a group is an application-layer data stream identified by a multicast URI, and it's not tied to any specific distribution technology 🌸. That Group Name can be mapped to variable routing identifiers ⭐.
The aim of this common API is twofold 👑:
- Let any application programmer build group-oriented data communication that doesn't depend on the underlying delivery mechanisms. It also allows a late binding of group applications to multicast technologies, so apps stay efficient but robust against deployment details 💅.
- Allow flexible namespace support in group addressing, so naming and addressing (or routing) schemes stay separate from the application design 🧚. This decouples programs from specific underlying protocols and might even open the door to specifically flavored group services 🌈.
Multicast technologies can be peer-to-peer of various kinds, IPv4 or IPv6 network-layer multicast, or built on some other application service 🦋. The matching namespaces could be IP addresses, DNS naming, overlay hashes, or other application-layer group identifiers like <sip:*@peanuts.org>, and they can also be names that applications define themselves 💜. Common namespaces show up later in this document, but the whole thing is built as an open concept that's ready for future extensions 🎀.
This document also covers mapping mechanisms between different namespaces and forwarding technologies, and suggests expressions of defaults for an intended binding 🍓. The multicast API also gives you internal Interfaces for reading the host's current multicast states 👀. Several multicast protocols can run in parallel on one host, and they can work together as a gateway that bridges data between different domains 🌉. The doc also describes how to use this API at gateways that sit between current multicast instances across the Internet ✨. Last but not least, there's a report on an implementation of the programming Interface, including service middleware 🔥.
This document represents the consensus of the SAM Research Group 🫶. It was reviewed by Research Group members active in this area of work 💅. On top of that, it was comprehensively reviewed by people who aren't "in" the Research Group but are experts in the field 🌟.
1.1. Use Cases for the Common API
Here are the generic use cases I found 💖. All of them need an abstract common API for multicast services 🦋:
- Application Programming Independent of Technologies: Application programmers get group primitives that stay independent of multicast technologies and their deployment in target domains 💅. So for a given app, they can write one program that runs in every deployment scenario ✨. Group Names in the form of abstract metadata types let apps stay namespace-agnostic, because resolving namespaces and name-to-address mappings can be handed off to a system service at runtime 🧚. Complexity drops because developers don't need to care how data is distributed in groups, while the system service can use the extended network information it picked up at startup 🌈.
- Global Identification of Groups: Groups can be identified independent of technological instantiations and beyond deployment domains 🌍. Thanks to the abstract naming, an app can match data it gets from different Interface technologies (like IPv4, IPv6, and overlays) and see that it belongs to the same group 🫶. That's not just more flexible, since an app can combine heterogeneous multipath streams 🔥. It also makes gateways simpler to design and implement 👑.
- Uniform Access to Multicast Flavors: The URI naming scheme uniformly supports different flavors of group communication, like any-source multicast, source-specific multicast, and selective broadcast, no matter the service instantiation 💅. The traditional SSM model, for example, can get lots of support by directly mapping the multicast URI (i.e.,
"group@instantiation") to an(S,G)state on the IP layer 🦋. It can also first resolve S for a later Group Address query, move the whole process to any of the various source-specific overlay schemes, or delegate to a plain replication server 🎀. The programmer can call any of these underlying mechanisms with the same line of code 🧚✨. - Simplified Service Deployment through Generic Gateways: The common multicast API lets you implement abstract gateway functions that map to specific technologies at the system level 🌸. Generic gateways can offer a simple bridging service and make inter-domain multicast deployment easier 🍓.
- Mobility-Agnostic Group Communication: Group naming and management in the common multicast API stay independent of locators 💜. So apps stay unaware of any mobility-related address changes 🙈. Handover-initiated re-addressing is delegated to the mapping services at the system level, and it can be designed to work smoothly with mobility management solutions at the network or transport layer (see [RFC5757] for mobility-related aspects) 🌈.
1.2. Illustrative Examples
1.2.1. Support of Multiple Underlying Technologies
Okay, picture this 🎀: the common multicast API gives the programmer one single Interface to manage multicast content, no matter what technology is underneath 💖. In the simple example in Figure 1, a multicast source S is connected via IPv4 and IPv6 🌐. It sends out one flow of multicast content (e.g., a movie) 🎬. The receivers are connected via IPv4/v6 and Overlay Multicast (OM), respectively 🦋.
+-------+ +-------+ +-------+
| S | | R1 | | R3 |
+-------+ +-------+ +-------+
v6| v4| |v4 |OM
| | / |
| ***| *** ***/ ** *** /*** *** ***
\* |* ** /** * * /* ** ** *
*\ \_______/_______*__v4__+-------+ * / *
*\ IPv4/v6 * | R2 |__OM__ *_/ Overlay Mcast *
* \_________________*__v6__+-------+ * *
* ** ** ** * * ** ** ** *
*** *** *** *** *** *** *** ***
Figure 1: Common Scenario: Source S Sends the Same Multicast Content
via Different TechnologiesUsing the current BSD socket API, the programmer has to decide on the IP technologies at coding time 😩. Extra distribution techniques, like overlay multicast, have to be integrated into the app one by one 🧩. For each technology, the programmer needs a separate socket and has to start a dedicated join or send 🙃. And since the current socket API doesn't tell apart Group Name and Group Address, the content gets delivered multiple times to the same receiver (cf. R2) 💀. Whenever the source sends content over a technology that the receivers or their Internet Service Provider don't support (cf. R3), a gateway is required 🚧. Gateway functions depend on a coherent view of the Multicast Group states 🫶.
The common multicast API makes multicast apps easier to program, because it separates content distribution from specific technologies 💅. Besides the calls that receive and send multicast data, the API has service calls for accessing the host's internal multicast states ✨. The API description in this document defines a minimal set of programming Interfaces to the system components at the host, which are needed to run group communication 🌸. It's up to specific implementations to add extra convenience functions for programmers 🍓.
Here's what the content distribution for the example in Figure 1 might look like 👀:
//Initialize multicast socket
MulticastSocket m = new MulticastSocket();
//Associate all available Interfaces
m.addInterface(getInterfaces());
//Subscribe to Multicast Group
m.join(URI("ham:opaque:news@cnn.com"));
//Send to Multicast Group
m.send(URI("ham:opaque:news@cnn.com"),message);
Send/receive example using the common multicast APIAnd the gateway function for R2 can be done with service calls that look like this 🌉:
//Initialize multicast socket
MulticastSocket m = new MulticastSocket();
//Check (a) host is designated multicast node for this Interface
// (b) receivers exist
for all this.getInterfaces() {
if(designatedHost(this.interface) &&
childrenSet(this.interface,
URI("ham:opaque:news@cnn.com")) != NULL) {
m.addInterface(this.interface);
}
}
while(true) {
m.send(URI("ham:opaque:news@cnn.com"),message);
}
Gateway example using the common multicast API1.2.2. Support of Multi-Resolution Multicast 🎀
okay so multi-resolution multicast is all about adjusting the stream so it works for totally different devices 📱💻. The same multicast data (think different compression levels) is usually announced on several multicast addresses that have nothing to do with each other. With the common API, an operator can make this happen behind the scenes using name-to-address mapping, or the subscriber can do it with systematic naming. Both work, and both are giving main character energy ✨.
Operator-Centric: An operator sets up a domain-specific mapping. Any multicast receiver, like a mobile user or a DSL user, subscribes to the same multicast name. That name then gets resolved locally to different multicast addresses. Each Group Address stands for a different level of data quality 🌈.
Subscriber-Centric: Here the multicast receiver picks the quality in advance, using a predefined naming syntax. Imagine a layered video stream called blockbuster, available at different qualities Q_i. Each quality is the base layer plus the sum of the EL_j enhancement layers, where j <= i. Each individual layer can be reached by a name like EL_j.Q_i.blockbuster (with j <= i), a specific quality bundles its layers under Q_i.blockbuster, and the full-size movie can simply be called blockbuster 🍿🎬. It's so organized I'm obsessed 😭🫶.
2. Terminology 💅
okay the terminology in this doc comes from the multicast protocols discussed in [RFC2710], [RFC3376], [RFC3810], [RFC4601], and [RFC4604]. On top of that, there are a few extra terms we're going to use:
Group Address: A Group Address is a routing identifier. It represents a technological specifier, so it reflects which distribution technology is in use. Multicast packet forwarding is based on this address 🚚.
Group Name: A Group Name is an application identifier. Applications use it to manage communication in a Multicast Group, like joining, leaving, sending, and receiving. The Group Name doesn't predefine any distribution technology. Even if it looks syntactically like an address, it's only a logical identifier 🏷️.
Multicast Namespace: A Multicast Namespace is a collection of designators (names or addresses) for groups that share a common syntax. Common examples are IPv4 or IPv6 multicast addresses, overlay group IDs, Group Names defined at the application layer (like SIP or email), or some human-readable string 📚.
Interface: An Interface is a forwarding instance of a distribution technology on a given node. For example, there's the IP Interface 192.168.1.1 on an IPv4 host, or an overlay routing Interface 🔌.
Multicast Domain: A Multicast Domain hosts nodes and routers that share one common, single multicast forwarding technology, and it's bound to a single namespace 🏠.
Inter-domain Multicast Gateway (IMG): An IMG is an entity that interconnects different Multicast Domains. Its job is to forward data between those domains, like between an IP layer and overlay multicast 🌉.
3. Overview 🧚
3.1. Objectives and Reference Scenarios 🎯
the default use case in this doc is for applications that join a group using some common identifier from some common namespace. This Group Name is usually learned at runtime from user interaction, like picking an IPTV channel, or from dynamic session negotiation, such as with the Session Initiation Protocol (SIP) [RFC3261] or Peer-to-Peer SIP (P2PSIP) [SIP-RELOAD]. It can also be predefined for an application as a common Group Name. Technology-specific system functions then quietly map the Group Name to Group Addresses so that:
- programmers can process Group Names in their programs without having to think about the technological mappings tied to specific deployments in target domains 💖;
- applications can identify packets that belong to a logically named group, no matter which Interface technology is used for sending and receiving packets; this shall also hold true for multicast gateways 🫶.
This document looks at two reference scenarios, which cover the hybrid deployment cases shown in Figure 2:
- Multicast Domains running the same multicast technology but staying isolated, possibly only connected by network-layer unicast 🏝️.
- Multicast Domains running different multicast technologies but hosting nodes that are members of the same Multicast Group 🌈.
+-------+ +-------+
| Member| | Member|
| Foo | | G |
+-------+ +-------+
\ /
*** *** *** ***
* ** ** ** *
* *
* Mcast Tech. A *
* *
* ** ** ** *
*** *** *** ***
+-------+ +-------+ |
| Member| | Member| +-------+
| G | | Foo | | IMG |
+-------+ +-------+ +-------+
| | |
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * +-------+ * *
* Mcast Tech. A * --| IMG |-- * Mcast Tech. B * +------+
* * +-------+ * * -|Member|
* ** ** ** * * ** ** ** * | G |
*** *** *** *** *** *** *** *** +------+ Figure 2: Reference Scenarios for Hybrid Multicast, Interconnecting
Group Members from Isolated Homogeneous and Heterogeneous Domains3.2. Group Communication API and Protocol Stack 🦋
the group communication API abstracts the socket concept and has four parts. Two of them handle the essential communication functions, and the other two offer optional extras for enhanced monitoring and management:
- Group Management Calls: provide the minimal API to instantiate an abstract multicast socket and manage group membership 👥;
- Send/Receive Calls: provide the minimal API to send and receive multicast data in a technology-transparent way 📨;
- Socket Options: provide extension calls for explicitly configuring the multicast socket, such as setting hop limits or associated Interfaces ⚙️;
- Service Calls: provide extension calls that grant access to internal multicast states of an Interface, such as the Multicast Groups under subscription or the multicast forwarding information base 🔍.
Multicast applications that use the common API need help from a group communication stack. This protocol stack serves two needs:
- it provides system-level support to transfer the abstract functions of the common API, including namespace support, into protocol operations at Interfaces 🛠️;
- it provides group communication services across different multicast technologies at the local host 🌐.
A general initiation of multicast communication in this setting goes like this:
- An application opens an abstract multicast socket.
- The application subscribes to, leaves, or (de)registers a group using a Group Name.
- An intrinsic function of the stack maps the logical group ID (Group Name) to a technical group ID (Group Address). This function may use deployment-specific knowledge, such as available technologies and Group Address management in its domain 🗺️.
- Packet distribution proceeds to and from one or several multicast-enabled Interfaces 📦.
The abstract multicast socket represents a group communication channel made up of one or multiple Interfaces. A socket can be created without any explicit Interface association by the application, which leaves the choice of underlying forwarding technology up to the group communication stack. An application can also bind the socket to one or multiple dedicated Interfaces, which predefines the forwarding technology and the Multicast Namespace(s) of the Group Address(es) 🎀.
Applications are not required to maintain mapping states for Group Addresses. The group communication stack handles the mapping of the Group Name to the Group Address(es) and back again. Multicast data passed to the application gets augmented with the corresponding Group Name. That means multiple multicast subscriptions can run on a single multicast socket without any Group Name encoding on the application side 🙌.
Hosts may support several multicast protocols. The group communication stack discovers available multicast-enabled Interfaces, and it provides a minimal hybrid function that bridges data between different Interfaces and Multicast Domains. The details of service discovery are out of scope for this document 🤷♀️.
The extended multicast functions can be implemented by middleware, as conceptually shown in Figure 3 💅:
*-------* *-------*
| App 1 | | App 2 |
*-------* *-------*
| |
*---------------------* ---|
| Middleware | |
*---------------------* |
| | |
*---------* | |
| Overlay | | \ Group Communication
*---------* | / Stack
| | |
| | |
*---------------------* |
| Underlay | |
*---------------------* ---| Figure 3: Architecture of a Group Communication Stack with Middleware
Offering Uniform Access to Multicast in Underlay and Overlay3.3. Naming and Addressing ✨
okay so apps use Group Names to find their groups 🫶 A Group Name can uniquely identify a group in a global communication context, and it hides all the technology stuff behind data distribution from the app, which is so iconic of it. Multicast forwarding is different, though. It works on Group Addresses. Even when both identifiers look exactly the same, they mean different things, and they can live in different Multicast Namespaces 🌸 A Group Address's namespace reflects a routing technology, while a Group Name's namespace represents the context the app is running in. Not the same vibe at all!
URIs [RFC3986] are a super common way to write namespace-specific identifiers in apps, kind of like an abstract metadata type 💅 Throughout this document, every Group Name follows URI notation using the syntax from Section 4.2. Some examples are ham:ip:224.1.2.3:5000 for a canonical IPv4 ASM group on UDP port 5000 🎀 and ham:sip:news@cnn.com for app-specific naming with a service instantiator and default port selection.
An implementation of the group communication stack can offer convenience functions that detect the namespace of a Group Name or make service instantiation more efficient ✨ In practice, a library like that gives the app high-level data types, kind of like some versions of the current socket API (for example, InetAddress in Java). Using one of those data types could figure out the namespace automatically 🦋 The details of automatic namespace identification or service handling are out of scope for this document, so we're leaving that for another day.
3.4. Namespaces 🧚
Namespace identifiers in URIs go in the scheme element, and they describe the syntax and semantics of the group identifier 💜 That's what makes the convenience functions and high-level data types work when URIs get processed. When they show up in names, they can point to an application context, or help with a default mapping and with recovering names from addresses. When they show up in addresses, they tell you what type of group identifier you're looking at.
Namespace schemes can be added, since that's just how URIs work 🌈 Examples of schemes are the generic one (see Section 4.2.3) and ones inherited from applications (see Section 4.2.4).
3.5. Name-to-Address Mapping 💖
The multicast communication paradigm needs every group member to subscribe to the same Group Name, taken from a shared Multicast Namespace. That's how everyone identifies the group in a technology-agnostic way, no cap 🔥 Following this common API, a sender registers a Group Name before it transmits anything.
At the communication end points, Group Names need to be mapped to Group Addresses before service gets instantiated on the endpoints' Interfaces 🎀 Gateways need a mapping too, so they can consistently translate between Group Addresses from different namespaces. Two requirements have to be met by a mapping function that translates between Multicast Names and Addresses:
- a. For a given Group Name, identify an Address that is appropriate for a local distribution instance.
- b. For a given Group Address, invert the mapping to recover the Group Name.
Mappings can get complicated, and they don't have to be invertible 🙈 A mapping can be done by embedding smaller namespaces into larger ones, or by picking an arbitrary, unused ID in a smaller target namespace. For example, it's not obvious how to map a huge identifier space (like IPv6) onto a smaller, collision-prone set like IPv4 (see [MCAST-v4v6-FRAMEWORK], [MCAST-v4v6], and [RFC6219]) 😭 Mapping functions can be stateless in some contexts but might need state in others. Which one you use depends on the cardinality of the namespaces, the structure of the address spaces, and possible address collisions. Still, some namespaces make a canonical, invertible transformation to default address spaces possible ✨
3.5.1. Canonical Mapping
Some Multicast Namespaces defined in Section 3.4 can express a canonical default mapping 💅 For example, ham:ip:224.1.2.3:5000 points to 224.1.2.3 in the default IPv4 multicast address space, on port 5000. This default mapping is tied to a technology and might not always be applicable, for instance when there are address collisions 💀 Note that under canonical mapping, you can completely recover the multicast URI from any data message received within that group. Iconic!
3.5.2. Mapping at End Points
Multicast listeners and senders need a name-to-address conversion for every technology they actively run in a group 🦋 Even though a mapping only applies to the local Multicast Domain, end points might need to learn a valid Group Address from neighboring nodes, for example from a gateway in the collision-prone IPv4 domain. Once it's set, an end point will always know the name-to-address correspondence, so it can invert the mapping on its own 🫶
3.5.3. Mapping at Inter-Domain Multicast Gateways
Multicast data can arrive at an IMG over one technology and ask the gateway to re-address the packets for another distribution system 🌸 When it first arrives, the IMG might not explicitly know the corresponding Multicast Group Name. To do a consistent mapping, the Group Name has to be acquired. It might have been distributed at source registration, or it might have been learned from a neighboring node. Those details are beyond the scope of this document 🧚
3.6. A Note on Explicit Multicast (Xcast) 👑
In Explicit Multicast (Xcast) [RFC5058], the multicast source explicitly predefines the receivers ✨ Conceptually, Xcast is just another distribution technology, meaning a new technology-specific Interface for this API 💜 Xcast needs aggregated knowledge of the receivers, and that knowledge has to be available at the origin of the distribution tree. The instantiation part of the Group Name can refer to a management instance and tree root, which could be the source or some co-located processor.
An implementation of Xcast then needs a topology-dependent mapping of the Group Name to the set of subscribers 🎀 The defining details of this multi-destination mapping are out of scope for this document.
3.7. MTU Handling 🌈
This API is built for a multi-technology scenario, where different technologies can have different Maximum Transmission Unit (MTU) sizes 🍓 Even when the MTU size between two hosts has been determined, it can change over time. The network can change it (for example, through path changes), or end hosts can (for example, through Interface changes caused by mobility) 😭
The design of this API is all about robust communication and easy app development 💖 That means MTU handling and fragmentation are guided by these observations:
- Application: App programmers need a simple way to send packets in a technology-agnostic fashion. So it's convenient, when coding, to rely on a transparent maximum amount of data that can be sent in one message from a socket. A regular program flow shouldn't get distracted by querying and changing MTU sizes. Technically, the maximum message size the app programmer configured can change and disrupt communication when (a) Interfaces are added or excluded, or (b) the path MTU changes during transmission and thereby disables the corresponding Interfaces 🙈
- Middleware: Middleware sitting between the app and the technology Interfaces provides general packet-handling capability, which in turn stops the app programmer from having to implement fragmentation 🫶 A uniform maximum message size that cannot be changed during runtime shall be guaranteed by the group communication stack (for example, the middleware). Otherwise, that would conflict with a technology-agnostic app 💅
- Technology Interfaces: Fragmentation requirements depend on the technology in use. So the (technology-bound) Interfaces need to cope with MTU sizes that can vary among Interfaces and along different paths 🦋
This API also aims to guarantee a maximum message size for the app programmer, so fragmentation gets handled at the Interface level when it's needed ✨ Still, the app programmer should be able to figure out the technology-specific atomic message size, for optimizing data distribution or for other reasons 🧚
The uniform maximum message size should take realistic values (for example, following IP clients) so services stay smooth and efficient 👑 A detailed selection scheme for MTU values is out of scope for this document.
4. Common Multicast API 🎀
4.1. Notation 💜
The common multicast API is described in pseudo-syntax here 🌸 Variables passed to function calls are declared by "in", and return values are declared by "out". A list of elements is denoted by "<>". The pseudo-syntax assumes that lists include an attribute that represents the number of elements.
The corresponding C signatures are defined in Appendix A ✨
4.2. URI Scheme Definition 🌈
Multicast Names and Multicast Addresses used in this API are represented by a URI scheme, which is specified in the subsections below 🫶 A matching ham-URI denotes a multicast channel and can be dereferenced to retrieve data published to that channel.
4.2.1. Syntax 🔥
The syntax of the multicast URI is specified using the Augmented Backus-Naur Form (ABNF) [RFC5234] and is defined as follows:
ham-URI = ham-scheme ":" namespace ":" group [ "@" instantiation ]
[ ":" port ] [ "/" sec-credentials ]
ham-scheme = "ham" ; hybrid adaptive multicast
namespace = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
group = "*" / 1*unreserved ; unreserved per [RFC3986]
instantiation = 1*unreserved ; unreserved per [RFC3986]
port = 1*DIGIT
sec-credentials = alg ";" val
alg = 1*unreserved ; unreserved per [RFC3986]
val = 1*unreserved ; unreserved per [RFC3986]Percent-encoding is applied to tell apart reserved and unreserved assignments of the same character in the same ham-URI component (cf. [RFC3986]) 💀
4.2.2. Semantic ✨
okay so here's what each piece of the ham-URI actually means 💅
- ham-scheme: this one refers to the specification of the assigned identifier
ham🦋 - namespace: this is the Multicast Namespace, and it's the boss 👑 It defines the syntax of the group and instantiation part of the ham-URI. A basic syntax for these elements is specified in Section 4.2.1. The namespace may further restrict the syntax of designators. Example namespaces are described in Sections 4.2.3 and 4.2.4.
- group: uniquely identifies the group within the Multicast Namespace given in the namespace. The literal
*represents all members of the Multicast Group 🌸 - instantiation: identifies the entity that generates the instance of the group (e.g., a SIP domain or a source in SSM, a dedicated routing entity, or a named processor that accounts for the group communication), using syntax and semantics as defined by the namespace. This parameter is optional. Note that ambiguities (e.g., identical node addresses in multiple overlay instances) can be distinguished by ports 🧚
- port: identifies a specific application at an instance of a group. This parameter is optional 🎀
- sec-credentials: used to implement security mechanisms (e.g., to authorize Multicast Group access or authenticate multicast operations). This parameter is optional.
algrepresents the security algorithm in use, andvalrepresents the actual value for Authentication, Authorization, and Accounting (AAA). Note that security credentials may carry a distinct technical meaning w.r.t. AAA schemes and may differ between group members. Hence, the sec-credentials are not considered part of the Group Name 🔐
4.2.3. Generic Namespaces 🌈
- IP: this namespace is basically regular IP node naming, so DNS names and addresses taken from any version of the Internet Protocol 🌍 The syntax of the group and instantiation follows the "host" definition in [RFC3986], Section 3.2.2. A processor dealing with the IP namespace is required to determine the syntax (DNS name, IP address, version) of the group and instantiation expression.
- SHA-2: this one carries address strings that are compliant with SHA-2 hash digests 🧮 The syntax of the group and instantiation follows the "val" definition in [RFC6920], Section 3. A processor handling those strings is required to determine the length of the expressions and passes appropriate values directly to a corresponding overlay.
- Opaque: this namespace transparently carries strings with no further syntactical information, meanings, or associated resolution mechanisms 🫥 The corresponding syntax for the group and instantiation part of the ham-URI is defined in Section 4.2.1.
4.2.4. Application-Centric Namespaces 💜
- SIP: the SIP namespace is an example of an application-layer scheme that bears inherent group functions (conferencing) 📞 SIP conference URIs may be directly exchanged and interpreted at the application, and mapped to Group Addresses at the system level to generate a corresponding Multicast Group. The syntax of the group and instantiation is represented by the "userinfo" component [RFC3261], Section 25.1.
- RELOAD: this namespace covers address strings that are valid in a REsource LOcation And Discovery [RELOAD] overlay network 🛰️ A processor handling those strings may pass these values directly to a corresponding overlay that may manage multicast distribution according to [RFC7019].
4.2.5. Future Namespaces 🔮
okay so the common multicast API lets in any namespace that complies with the superset syntax defined in Section 4.2.1 ✨ This document specifies a basic set of Multicast Namespaces in Sections 4.2.3 and 4.2.4. If additional namespaces are needed in the future, a registry for those namespaces should be created and should be defined in a future document. All namespaces defined in such a document should then also be assigned to the registry 📚
4.3. Additional Abstract Data Types 🎁
4.3.1. Interface 🔌
the Interface is the layer and instance where a call takes effect 💖 Following [RFC3493], we identify an Interface by an identifier, which is a positive integer starting at 1.
Properties of an Interface are stored in this data structure:
struct ifProp {
UnsignedInt if_index; /* 1, 2, ... */
String *ifName; /* "eth0", "eth1:1", "lo", ... */
String *ifAddr; /* "1.2.3.4", "abc123", ... */
String *ifTech; /* "ip", "overlay", ... */
};the following function grabs all the available Interfaces from the system:
getInterfaces(out Interface <ifs>);It extends the functions for Interface identification defined in [RFC3493], Section 4, and can be implemented by:
struct ifProp(out IfProp <ifsProps>);4.3.2. Membership Events 📣
a membership event gets triggered when the current node observes a multicast state change. It's related to a specific Group Name and may be receiver or source oriented 👀
eventType {
joinEvent;
leaveEvent;
newSourceEvent;
};
event {
EventType event;
Uri groupName;
Interface if;
};the group communication stack creates an event and passes it to applications that have registered for events 🫶
4.4. Group Management Calls 🗂️
4.4.1. Create 🌱
the create call starts a multicast socket and hands the application programmer a matching handle 🎀 If no Interfaces will be assigned based on the call, the default Interface gets selected and associated with the socket. The call returns an error code in the case of failures, e.g., due to non-operational communication middleware 😬
createMSocket(in Interface <ifs>,
out Socket s);The ifs argument denotes a list of Interfaces (if_indexes) that will be associated with the multicast socket. This parameter is optional.
On success, a multicast socket identifier is returned; otherwise, it is NULL.
4.4.2. Delete 🗑️
the delete call removes the multicast socket 👋
deleteMSocket(in Socket s, out Int error);The s argument identifies the multicast socket for destruction.
On success, the out parameter error is 0; otherwise, -1 is returned.
4.4.3. Join 🙋
the join call starts a subscription for the given Group Name. Depending on the Interfaces that are associated with the socket, this may result in an IGMP / Multicast Listener Discovery (MLD) report or overlay subscription, for example 🌊
join(in Socket s, in Uri groupName, out Int error);The s argument identifies the multicast socket.
The groupName argument identifies the group.
On success, the out parameter error is 0; otherwise, -1 is returned.
4.4.4. Leave 🚪
the leave call results in an unsubscription for the given Group Name 💔
leave(in Socket s, in Uri groupName, out Int error);The s argument identifies the multicast socket.
The groupName argument identifies the group.
On success, the out parameter error is 0; otherwise, -1 is returned.
4.4.5. Source Register 📡
the srcRegister call registers a source for a group on all active Interfaces of the socket s. This call may assist group distribution in some technologies (for example, the creation of sub-overlays) or may facilitate a name-to-address mapping. Likewise, it may remain without effect in some multicast technologies 🌟
srcRegister(in Socket s, in Uri groupName,
out Interface <ifs>, out Int error);The s argument identifies the multicast socket.
The groupName argument identifies the Multicast Group to which a source intends to send data.
The ifs argument points to the list of Interface indexes for which the source registration failed. A NULL pointer is returned if the list is empty. This parameter is optional.
If source registration succeeded for all Interfaces associated with the socket, the out parameter error is 0; otherwise, -1 is returned.
4.4.6. Source Deregister 🙅
the srcDeregister call says a source no longer intends to send data to the Multicast Group. This call may remain without effect in some multicast technologies 🫠
srcDeregister(in Socket s, in Uri groupName,
out Interface <ifs>, out Int error);The s argument identifies the multicast socket.
The groupName argument identifies the Multicast Group to which a source has stopped sending multicast data.
The ifs argument points to the list of Interfaces for which the source deregistration failed. A NULL pointer is returned if the list is empty.
If source deregistration succeeded for all Interfaces associated with the socket, the out parameter error is 0; otherwise, -1 is returned.
4.5. Send and Receive Calls 📬
4.5.1. Send 🚀
the send call passes multicast data destined for a Multicast Name from the application to the multicast socket 💌
It's worth noting that it's the programmer's choice whether to send data via one socket per group or to use a single socket for multiple groups 🧠
send(in Socket s, in Uri groupName,
in Size msgLen, in Msg msgBuf,
out Int error);The s argument identifies the multicast socket.
The groupName argument identifies the group to which data will be sent.
The msgLen argument holds the length of the message to be sent.
The msgBuf argument passes the multicast data to the multicast socket.
On success, the out parameter error is 0; otherwise, -1 is returned. A message that is too long is indicated by an implementation-specific error code (e.g., EMSGSIZE in C).
4.5.2. Receive 📥
the receive call passes multicast data and the corresponding Group Name up to the application. It may come in a blocking or non-blocking variant 🦋
It's worth noting that it's the programmer's choice whether to receive data via one socket per group or to use a single socket for multiple groups 🧠
receive(in Socket s, out Uri groupName,
out Size msgLen, out Msg msgBuf,
out Int error);The s argument identifies the multicast socket.
The groupName argument identifies the Multicast Group for which data was received.
The msgLen argument holds the length of the received message.
The msgBuf argument points to the payload of the received multicast data.
On success, the out parameter error is 0; otherwise, -1 is returned. A message that is too long is indicated by an implementation-specific error code (e.g., EMSGSIZE).
4.6. Socket Options ⚙️
the following calls configure an existing multicast socket 💅
4.6.1. Get Interfaces 🔎
the getInterfaces call returns an array of all available multicast communication Interfaces associated with the multicast socket ✨
getInterfaces(in Socket s,
out Interface <ifs>, out Int error);The s argument identifies the multicast socket.
The ifs argument points to an array of Interface index identifiers.
On success, the out parameter error is 0; otherwise, -1 is returned.
4.6.2. Add Interface 💖
okay so addInterface is how you add a distribution channel to a socket 🦋 It can be an overlay or an underlay Interface, like IPv6 or a Distributed Hash Table (DHT). You can also have multiple Interfaces of the same technology hooked up to one socket, which is giving main character energy ✨
addInterface(in Socket s, in Interface if,
out Int error);The s and if arguments tell us which multicast socket and which Interface we're talking about, respectively 🎀
If it works, the value 0 gets returned. If it doesn't, you get -1 💀
4.6.3. Delete Interface 🧚
delInterface is the opposite of addInterface. It removes the Interface from the multicast socket, bye bye 👋
delInterface(in Socket s, Interface if,
out Int error);Same deal as before: s and if identify the multicast socket and the Interface 🌸
On success, the out parameter error is 0. Otherwise, -1 is returned 🫶
4.6.4. Set TTL 🍓
setTTL is where you set the maximum hop count that a multicast message is allowed to travel through the socket. Basically how far the message is allowed to go before it gets cut off 🦋
setTTL(in Socket s, in Int h,
in Interface <ifs>,
out Int error);s identifies the multicast socket and h is the maximum hop count 💅
The ifs argument points to an array of Interface index identifiers. This parameter is optional, so you don't have to pass it if you don't want to 🌈
On success, the out parameter error is 0. Otherwise, -1 is returned ✨
4.6.5. Get TTL 💜
getTTL is the reverse of setTTL. It gives you back the maximum hop count that a multicast message is allowed to traverse for the interface bound to the socket 👑
getTTL(in Socket s, in Interface if,
out Int h, out Int error);The s argument identifies a multicast socket 🎀
The if argument identifies an interface that is bound to socket s 🌸
The h argument holds the maximum number of hops associated with that interface 🧚
On success, the out parameter error is 0. Otherwise, -1 is returned 💖
4.6.6. Atomic Message Size 🦋
getAtomicMsgSize returns the biggest message an app is allowed to send per socket in one go without it getting fragmented 📦 The tea here is that this number depends on which Interfaces are attached to the socket, so it can change while things are running. Plot twist, iykyk 🙈
getAtomicMsgSize(in Socket s,
out Int return);On success, the function returns a positive value for the appropriate message size. Otherwise, -1 is returned 💅
4.7. Service Calls ✨
Okay, this is the part where we get into the service calls. They're the helpers that let you ask the stack what's going on under the hood 🔍
4.7.1. Group Set 🌈
groupSet gives you back every Multicast Group registered at a given Interface 👑 That info can come from group management state or from routing protocols. The results also tell you whether you're a sender, a listener, or both, which is so useful ngl 🫶
struct GroupSet {
Uri groupName; /* registered Multicast Group */
Int type; /* 0 = listener state, 1 = sender state,
2 = sender and listener state */
}
groupSet(in Interface if,
out GroupSet <groupSet>, out Int error);The if argument identifies the Interface whose states we're looking at 🎀
The groupSet argument points to a list of group states 🦋
On success, the out parameter error is 0. Otherwise, -1 is returned 💖
4.7.2. Neighbor Set 🌸
neighborSet returns the set of neighboring nodes for a given Interface, as seen by the multicast routing protocol. It's like checking who's sitting next to you in the group chat 👀
neighborSet(in Interface if,
out Uri <neighborsAddresses>, out Int error);The if argument identifies the Interface you want neighbor info for 🧚
The neighborsAddresses argument points to a list of neighboring nodes when the call succeeds 🍓
On success, the out parameter error is 0. Otherwise, -1 is returned ✨
4.7.3. Children Set 🧚
childrenSet returns the set of child nodes that receive multicast data from a specified Interface for a given group. For a common multicast router, this call pulls up the multicast forwarding information base per Interface 🦋
childrenSet(in Interface if, in Uri groupName,
out Uri <childrenAddresses>, out Int error);The if argument identifies the Interface you're asking about 💅
The groupName argument defines the Multicast Group whose distribution we're looking at 🌈
The childrenAddresses argument points to a list of neighboring nodes when the call succeeds 💜
On success, the out parameter error is 0. Otherwise, -1 is returned 🫶
4.7.4. Parent Set 👑
parentSet is the flip side of childrenSet. It returns the set of neighbors that the current node gets multicast data from, at a given Interface, for the specified group 🎀
parentSet(in Interface if, in Uri groupName,
out Uri <parentsAddresses>, out Int error);The if argument identifies the Interface you want parent info for 🌸
The groupName argument defines the Multicast Group whose distribution we're considering 🧚
The parentsAddresses argument points to a list of neighboring nodes when the call succeeds 🍓
On success, the out parameter error is 0. Otherwise, -1 is returned 💖
4.7.5. Designated Host 🦋
designatedHost checks whether this host is the designated forwarder (or querier) or not. This info is provided by almost all multicast protocols, and it's there to stop packet duplication when more than one multicast instance is serving the same subnet. No double-sending drama 🙅♀️✨
designatedHost(in Interface if, in Uri groupName
out Int return);The if argument identifies the Interface you want designated forwarding info for 💅
The groupName argument specifies the group that the host might become the designated forwarder for 🌈
The function returns 1 if the host is a designated forwarder or querier. The return value -1 means there was an error. Otherwise, 0 is returned 💜
4.7.6. Enable Membership Events 🫶
enableEvents registers an app with the group communication stack so it can hear about group changes 👂 Those changes happen when someone new subscribes as a receiver, leaves, or when sources change. Once an event shows up, the group service can go grab more info using other service calls 🎀
enableEvents();Once you call this, the stack starts passing membership events up to the app. Each event comes with an event type identifier and a Group Name (see Section 4.3.2) 🦋
The multicast protocol doesn't have to support membership tracking for this feature to work. This function can also be implemented at the middleware layer 🌸
4.7.7. Disable Membership Events 🙈
disableEvents turns off the info about group state changes. Mute button activated 🔇
disableEvents();On success, the stack will not pass membership events to the application anymore 💀
4.7.8. Maximum Message Size 💅
getMaxMsgSize returns the maximum message size an app is allowed to send per socket at once. This value is statically guaranteed by the group communication stack, so it's not going to surprise you 💖
getMaxMsgSize(out Int return);On success, the function returns a positive value for the allowed message size. Otherwise, -1 is returned 🌈
5. Implementation ✨
A reference implementation of the Common API for Transparent Hybrid Multicast is available with the HAMcast stack [HAMcast-DEV] [GC2010] [LCN2012]. It's open source 🫶 It supports the multicast API (there's a C++ and a Java library) for group app development, plus the middleware as a user space system service, and several multicast-technology modules 👑 The middleware itself is written in C++ 💜
This API has been verified and adjusted based on real-world experiences gathered in the HAMcast project, plus feedback from other users of the stack 🎀
6. IANA Considerations 🦋
This document specifies the "ham" URI scheme. IANA registered it as one of the "Provisional URI Schemes" under [RFC4395] 🌸
URI scheme name ham
Status provisional
URI scheme syntax See Section 4.2.1.
URI scheme semantics See Section 4.2.2.
Encoding See Section 4.2.1
considerations
Applications/protocols The scheme is used by multicast applications
that use this URI to access multicast content.
scheme name
Interoperability None
considerations
Security See Section 7.
considerations
Contact Matthias Waehlisch, mw@link-lab.net
Author/Change IRTF
controller
References As specified in this document.7. Security Considerations 🔐
This document doesn't introduce any additional messages or novel protocol operations 🧚 No new messages, no new vibes, just the API 💅
8. Acknowledgements 🫶
We'd like to thank the HAMcast team at the HAW Hamburg (Nora Berg, Gabriel Hege, Fabian Holler, Alexander Knauf, Sebastian Meiling, Sebastian Woelke, and Sebastian Zagaria) for so many fruitful discussions and for their continuous critical feedback while they implemented the common multicast API and hybrid multicast middleware 👑 Special thanks to Dominik Charousset of the HAMcast team for his in-depth perspectives on the code 💜 We also gratefully acknowledge WeeSan, Mario Kolberg, and John Buford for reviewing the document and suggesting improvements 🎀 Thanks to the Name-Based Socket BoF (especially Dave Thaler) for clarifying insights into meta-function calls 🦋 We thank Lisandro Zambenedetti Granville and Tony Li for very careful reviews of the pre-final versions 🌸 And Barry Leiba and Graham Klyne gave very constructive input on finding a suitable URI scheme. They're gratefully acknowledged 🙌
This work is partially supported by the German Federal Ministry of Education and Research within the HAMcast project (see <http://hamcast.realmv6.org>), which is part of G-Lab 🇩🇪✨
9. References 📚
9.1. Normative References ✨
Okay, these are the must-read docs, bestie 📚 Here's the full list of the normative references, shown exactly as they're cited:
- [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
- [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
- [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
- [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
- [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
- [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
- [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
- [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
- [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
- [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
- [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
- [RFC5058] Boivie, R., Feldman, N., Imai, Y., Livens, W., and D. Ooms, "Explicit Multicast (Xcast) Concepts and Options", RFC 5058, November 2007.
- [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
- [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, April 2013.
9.2. Informative References 🌸
These ones are extra reading, the "ooh, tell me more" pile 🧚 Here they are, all of them:
- [AMT] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, October 2013.
- [GC2010] Meiling, S., Charousset, D., Schmidt, T., and M. Waehlisch, "System-assisted Service Evolution for a Future Internet - The HAMcast Approach to Pervasive Multicast", Proc. IEEE GLOBECOM 2010 Workshops, MCS 2010, pp. 913-917, Piscataway, NJ, USA, IEEE Press, December 2010.
- [HAMcast-DEV] "HAMcast developers",
<http://hamcast.realmv6.org/developers>. - [LCN2012] Meiling, S., Schmidt, T., and M. Waehlisch, "Large-Scale Measurement and Analysis of One-Way Delay in Hybrid Multicast Networks", Proc. 37th Annual IEEE Conference on Local Computer Networks (LCN 2012), Piscataway, NJ, USA, IEEE Press, October 2012.
- [MCAST-v4v6] Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An IPv4 - IPv6 multicast translator", Work in Progress, December 2010.
- [MCAST-v4v6-FRAMEWORK] Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 Multicast Translation", Work in Progress, June 2011.
- [RELOAD] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", Work in Progress, February 2013.
- [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey", RFC 5757, February 2010.
- [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", RFC 6219, May 2011.
- [RFC7019] Buford, J. and M. Kolberg, "Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD)", RFC 7019, September 2013.
- [SIP-RELOAD] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., Schulzrinne, H., and T. Schmidt, Ed., "A SIP Usage for RELOAD", Work in Progress, July 2013.
Appendix A. C Signatures 💅
This part lays out the C signatures for the common multicast API (Section 4). Here they all are, exactly as written 👑
int createMSocket(int* result, size_t num_ifs,
const uint32_t* ifs);
int deleteMSocket(int s);
int join(int msock, const char* group_uri);
int leave(int msock, const char* group_uri);
int srcRegister(int msock,
const char* group_uri,
size_t num_ifs,
uint32_t* ifs);
int srcDeregister(int msock,
const char* group_uri,
size_t num_ifs,
uint32_t* ifs);
int send(int msock,
const char* group_uri,
size_t buf_len,
const void* buf);
int receive(int msock,
const char* group_uri,
size_t buf_len,
void* buf);
int getInterfaces(int msock,
size_t* num_ifs,
uint32_t** ifs);
int addInterface(int msock, uint32_t iface);
int delInterface(int msock, uint32_t iface);
int setTTL(int msock, uint8_t value,
size_t num_ifs, uint32_t* ifs);
int getTTL(int msock, uint8_t* result);
int getAtomicMsgSize(int msock);
typedef struct {
char* group_uri; /* registered mcast group */
int type; /* 0: listener state
1: sender state
2: sender and listener state */
}
GroupSet;
int groupSet(uint32_t iface,
size_t* num_groups,
GroupSet** groups);
int neighborSet(uint32_t iface,
const char* group_name,
size_t* num_neighbors,
char** neighbor_uris);
int childrenSet(uint32_t iface,
const char* group_name,
size_t* num_children,
char** children_uris);
int parentSet(uint32_t iface,
const char* group_name,
size_t* num_parents,
char** parents_uris);
int designatedHost(uint32_t iface,
const char* group_name);
typedef void (*MembershipEventCallback)
(int, /* event type */
uint32_t, /* Interface id */
const char*); /* group uri */
int registerEventCallback(MembershipEventCallback callback);
int enableEvents();
int disableEvents();
int getMaxMsgSize();Appendix B. Use Case for the API 🎀
Quick heads-up: for readability, the examples use a high-level Java-like syntax, and error handling is left out on purpose 🙈
-- Application above middleware:
//Initialize multicast socket;
//the middleware selects all available Interfaces
MulticastSocket m = new MulticastSocket();
m.join(URI("ham:ip:224.1.2.3:5000"));
m.join(URI("ham:ip:[ff02:0:0:0:0:0:0:3]:6000"));
m.join(URI("ham:sip:news@cnn.com"));
-- Middleware:
join(URI mcAddress) {
//Select Interfaces in use
for all this.interfaces {
switch (interface.type) {
case "ipv6":
//... map logical ID to routing address
Inet6Address rtAddressIPv6 = new Inet6Address();
mapNametoAddress(mcAddress,rtAddressIPv6);
interface.join(rtAddressIPv6);
case "ipv4":
//... map logical ID to routing address
Inet4Address rtAddressIPv4 = new Inet4Address();
mapNametoAddress(mcAddress,rtAddressIPv4);
interface.join(rtAddressIPv4);
case "sip-session":
//... map logical ID to routing address
SIPAddress rtAddressSIP = new SIPAddress();
mapNametoAddress(mcAddress,rtAddressSIP);
interface.join(rtAddressSIP);
case "dht":
//... map logical ID to routing address
DHTAddress rtAddressDHT = new DHTAddress();
mapNametoAddress(mcAddress,rtAddressDHT);
interface.join(rtAddressDHT);
//...
}
}
}Appendix C. Deployment Use Cases for Hybrid Multicast 🦋
This part shows how the defined API can be used to build an IMG (the hybrid multicast gateway) 🌈
C.1. DVMRP ✨
Here's a transparent way to map a DVMRP-based any-source multicast service onto another many-to-many multicast technology, like an overlay 🫶
An ordinary Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] router won't be told about new receivers, but it will find out about new sources right away 👀 DVMRP doesn't have any central multicast instance, so the IMG can sit anywhere inside the multicast region. The catch is that the IMG does need a DVMRP neighbor connection 🔥 That means the group communication stack used by the IMG gets a DVMRP implementation added to it. New sources in the underlay get advertised through DVMRP flooding and show up at the IMG, which creates the new_source_event and passes it up to the application. The relay agent then starts a matching join in the native network and pushes the received source data toward the overlay routing protocol. Depending on the group states, that data gets spread out to the overlay peers 💜
Now for the tricky bit 😭 DVMRP builds source-specific multicast trees, so a graft message is only seen by DVMRP routers on the path from the new receiver's subnet back to the source. In general, an IMG doesn't see it. To fix that, data from multicast senders in the overlay can become visible through the Source Register call. An IMG can also do an all-group join in the overlay by using the namespace extension of the API 🧚 Every IMG is initially required to forward the data it receives in the overlay down into the underlay, no matter whether there are native multicast receivers. After that, subsequent prunes can cut back on the unwanted data distribution ✨
C.2. PIM-SM ✨
okay so this one is about taking PIM-SM any-source multicast and mapping it, transparently, onto a different many-to-many multicast tech, like an overlay 🦋
so PIM-SM [RFC4601] sets up rendezvous points (RPs) 💅 and the RPs are the ones catching listener subscriptions and source registrations for a domain. bestie, for a continuous update the IMG has to be co-located with an RP 🫶 like, same spot, no separating them 😭
whenever PIM register messages show up, the IMG MUST signal internally that there's a new multicast source, using the event new_source_event. 🔥 then the IMG joins the group, and a shared tree gets set up between the RP and the sources. this shared tree MAY change into a source-specific tree once PIM switches to phase three 🌈 (the way that the tree can just glow up, iconic)
source traffic gets forwarded to the RP based on the IMG join, even if there aren't any more receivers in the native Multicast Domain. no cap, that's giving "I'm still here for you" energy 💜
designated routers of a PIM domain send receiver subscriptions toward the PIM-SM RP. when those messages get received, they kick off the event join_event at the IMG, and the IMG starts a join toward the overlay routing protocol 🎀
overlay multicast data that arrives at the IMG then gets transparently forwarded in the underlay network and distributed through the RP instance. periodt 👑
C.3. PIM-SSM 🌸
this section is about mapping PIM-SSM source-specific multicast onto another one-to-many multicast tech, like an overlay 🧚
PIM Source-Specific Multicast (PIM-SSM) is part of PIM-SM, and it allows source-specific joins (S,G) following the source-specific host group model [RFC4604]. a multicast distribution tree can be built with no rendezvous point involved at all 🙈 main character energy
sources are NOT advertised within a PIM-SSM domain. 💀 so an IMG can't predict the local join inside a sender domain, and it can't push the multicast data to the overlay instance ahead of time. if an IMG in a receiver domain starts a group subscription through the overlay routing protocol, relaying fails, because the data just isn't available at the overlay instance yet 😭 the receiver-domain IMG therefore HAS TO locate the IMG instance of the source domain so it can trigger the matching join. in line with what PIM-SSM is going for, the signaling SHOULD NOT be flooded in the underlay and the overlay 🫶
one solution is to intercept the subscription at BOTH the source sites and the receiver sites. 🦋 to watch multicast receiver subscriptions (join_event or leave_event) in the underlay, the IMG gets placed on the path toward the source, for example at a domain border router. this router intercepts join messages, pulls out the unicast source address S, and starts an IMG-specific join to S over regular unicast. multicast data arriving at the IMG of the sender domain can then be distributed via the overlay ✨
finding the IMG of a multicast sender domain MAY be done analogously to Automatic Multicast Tunneling [AMT], using anycast. consequently, the source address S of the group (S,G) SHOULD be built from an anycast prefix. the matching IMG anycast address for a source domain is then derived from the prefix of S 💖
C.4. BIDIR-PIM 🍓
this one maps a BIDIR-PIM any-source multicast service onto another many-to-many multicast tech, like an overlay 💅
Bidirectional PIM [RFC5015] is a variant of PIM-SM. unlike PIM-SM, BIDIR-PIM pre-establishes bidirectional shared trees per group, connecting sources and receivers together 🌈 the rendezvous points are virtualized in BIDIR-PIM as an address that identifies on-tree directions (up and down) 🦋 routers with the best link toward the (virtualized) rendezvous point address get selected as designated forwarders for a link-local domain, and they represent the actual distribution tree 👑
the IMG is supposed to sit on the RP link, where the rendezvous point address lives. source data in either case gets transmitted to the RP link, so the BIDIR-PIM instance of the IMG receives the data and can internally signal new senders toward the stack via the new_source_event 🔥 the first receiver subscription for a new group within a BIDIR-PIM domain has to be transmitted to the RP to set up the first branching point. using the join_event, an IMG gets informed of group requests from its domain, and those requests are then delegated to the overlay 🎀
Authors' Addresses 💌
Matthias Waehlisch
link-lab & FU Berlin
Hoenower Str. 35
Berlin 10318
Germany
EMail: mw@link-lab.net
URI: http://www.inf.fu-berlin.de/~waehl
Thomas C. Schmidt
HAW Hamburg
Berliner Tor 7
Hamburg 20099
Germany
EMail: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Stig Venaas
Cisco Systems
Tasman Drive
San Jose, CA 95134
USA
EMail: stig@cisco.com📦 where this page comes from
- ietf: rfc7046 2013-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms