RFC 5757
Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey
Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey ✨
Okay bestie, let's get the title block sorted first 💖 This one is an Informational RFC from the Internet Research Task Force (IRTF), published in February 2010 as RFC 5757 🎀. It was written by T. Schmidt (HAW Hamburg), M. Waehlisch (link-lab), and G. Fairhurst (University of Aberdeen) 👑. Its ISSN is 2070-1721. It doesn't obsolete or update anything, so it's a clean standalone doc 🧚.
Reading the Abstract 🦋
Okay so the vibe here is: multicast (one packet, many receivers) gets super messy the second people start moving around 🌸 This doc looks at mobility extensions to IP-layer multicast, covering listeners who move and senders who move, using both Any Source Multicast and Source-Specific Multicast 🔥. It also gives a quick tour of routing and deployment issues for fixed IPv6 networks, plus how wireless tech interacts with multicast access, and then wraps up with a big map of the whole mobile multicast problem space and a road map for future standards work 🗺️ It's an RFC from the IRTF's MobOpts Research Group, so it's research-flavored, not a standard 💅
Heads up: this is a research and survey document, not a Standards Track spec. Nothing in here is a requirement you have to follow 🫶
Status of This Memo ✨
This document is not an Internet Standards Track specification; it is published for informational purposes 💜
It's an IRTF product, and the IRTF publishes research and development results that might not be suitable for deployment 🙈 This RFC represents the consensus of the MobOpts 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 💀
Info about the current status, errata, and feedback is at http://www.rfc-editor.org/info/rfc5757 🌈
Copyright Notice ✨
Copyright (c) 2010 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, since they describe your rights and restrictions with respect to this document 🫶
Table of Contents ✨
1. Introduction and Motivation .....................................4
1.1. Document Scope .............................................5
2. Problem Description .............................................6
2.1. General Issues .............................................6
2.2. Multicast Listener Mobility ................................9
2.2.1. Node and Application Perspective ....................9
2.2.2. Network Perspective ................................10
2.3. Multicast Source Mobility .................................11
2.3.1. Any Source Multicast Mobility ......................11
2.3.2. Source-Specific Multicast Mobility .................12
2.4. Deployment Issues .........................................13
3. Characteristics of Multicast Routing Trees under Mobility ......14
4. Link Layer Aspects .............................................15
4.1. General Background ........................................15
4.2. Multicast for Specific Technologies .......................16
4.2.1. 802.11 WLAN ........................................16
4.2.2. 802.16 WIMAX .......................................16
4.2.3. 3GPP/3GPP2 .........................................18
4.2.4. DVB-H / DVB-IPDC ...................................19
4.2.5. TV Broadcast and Satellite Networks ................19
4.3. Vertical Multicast Handovers ..............................20
5. Solutions ......................................................20
5.1. General Approaches ........................................20
5.2. Solutions for Multicast Listener Mobility .................21
5.2.1. Agent Assistance ...................................21
5.2.2. Multicast Encapsulation ............................22
5.2.3. Hybrid Architectures ...............................23
5.2.4. MLD Extensions .....................................23
5.3. Solutions for Multicast Source Mobility ...................24
5.3.1. Any Source Multicast Mobility Approaches ...........24
5.3.2. Source-Specific Multicast Mobility Approaches ......25
6. Security Considerations ........................................26
7. Summary and Future Steps .......................................27
Appendix A. Implicit Source Notification Options...................29
Informative References.............................................29
Acknowledgments....................................................371. Introduction and Motivation ✨
1.1. Document Scope 🦋
Hmm, the original text for Section 1 has no subsection 1.1 body yet, so this part picks up with the introduction 💅
Group communication is a huge building block for all sorts of apps 🎀 Think content broadcasting and streaming, voice and video calls, collaborative spaces, massive multiplayer games, and even distributed systems and autonomous networks organizing themselves 🌈 Network-layer multicast will be needed whenever you want communication that's globally distributed, scalable, serverless, or instantaneous 🔥
The early idea of Internet multicasting [1] led to wide adoption of Deering's host group model [2] 👑 Broadband media delivery is becoming the typical mass-market case, and it demands scalability and bandwidth efficiency from multicast routing 💖 Multicast mobility has been a concern for about ten years [3] and has produced lots of proposals, but there's still no generally accepted solution 🙈 Multicast support matters a lot for mobile environments, where users usually share limited-capacity frequency bands 🧚 "Infotainment" streams may soon need wide deployment of mobile multicast services ✨
Mobility in IPv6 [4] is standardized in the Mobile IPv6 RFCs [5][6], and it covers network-layer changes while moving between wireless domains 💜 MIPv6 [5] only roughly defines multicast mobility for Mobile Nodes (MNs), using either a remote subscription approach or bidirectional tunneling via the Home Agent (HA) 🦋 Remote subscription suffers from slow handovers, since it relies on multicast routing to adapt to handovers 😭 Bidirectional tunneling adds inefficient overhead and delay because of triangular forwarding, meaning packets get routed through the Home Agent instead of traveling on shortest paths 💀 So these approaches haven't been optimized for large-scale deployment 🌸 A mobile multicast service for a future Internet should offer "close-to-optimal" routing at predictable, limited cost, with robustness and service quality that fits real-time media distribution ⭐
Intricate multicast routing procedures aren't easy to extend for mobility 🎀 A client subscribed to a group during handovers needs the multicast traffic to follow it to its new location, and a mobile source needs the whole delivery tree to comply with or adapt to its changing position 🔥 A lot of effort has gone into protocol designs for mobile multicast receivers, but only limited work has targeted multicast source mobility, which is the trickier problem [65] 👑
In multimedia conferences, games, or collaborative environments, each member usually acts as both a receiver and a sender for multicast group communication 🌈 Real-time communication like voice or video also puts serious timing demands on mobility protocols 🫶 Typical seamless handover scenarios are expected to keep disruptions or delay under 100 - 150 ms [7] 💖 Jitter should not exceed 50 ms 🍓 Note that 100 ms is about the length of a spoken syllable in real-time audio 🧚 This problem statement is meant to apply to other scenarios with a range of delivery requirements appropriate to the general Internet too 💅
This document represents the consensus of the MobOpts Research Group 🎀 It was reviewed by Research Group members active in this area, and it was also comprehensively reviewed by multiple active contributors to the IETF MEXT, MBONED, and PIM Working Groups 🦋
Okay that's the first chunk, bestie! 💖 More parts are coming, so stay tuned 🫶
1.1. Document Scope 🦋
Okay so this part sets the problem scope for multicast mobility management 💅. It can get elaborated in future work. The challenges are split up by where they come from, and it points to existing proposals and the major bibliographic references 📚.
When we think about multicast node mobility, the network layer gets a sidekick: some wireless access technology 📡. There are two scenarios we care about. The first is single-hop mobility (Figure 1.a), and the second is multi-hop mobility (Figure 1.b). Single-hop is the main focus of this document, and it matches the MIPv6 [5] perspective 🌸. The key issues of mobile multicast membership control and the interplay of mobile and multicast routing get illustrated with this simple scenario, so it's a good place to start 🧚.
Multi-hop network mobility is a subsidiary scenario, and it's giving "bonus level" 🎮. All the major aspects are inherited from the single-hop problem, but traversing a mobile cloud adds extra complexity ☁️. This may be solved by either encapsulation or flooding ([8] provides a general overview). The specific issues that come with (nested) tunneling or flooding, especially keeping address transparency intact, need to be treated the same way MIPv6 treats them 🫶.
+------+ +------+
| MN | =====> | MN |
+------+ +------+
| .
| .
| .
+-------+ +-------+
| LAR 1 | | LAR 2 |
+-------+ +-------+
\ /
*** *** *** ***
* ** ** ** *
+------+ +------+ * *
| MN | =====> | MN | * Mobile Network *
+------+ +------+ * *
| . * ** ** ** *
| . *** *** *** ***
| . | .
+-------+ +-------+ +-------+ +-------+
| AR 1 | | AR 2 | | AR 1 | =====> | AR 2 |
+-------+ +-------+ +-------+ +-------+
| | | |
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Fixed Internet * * Fixed Internet *
* * * *
* ** ** ** * * ** ** ** *
*** *** *** *** *** *** *** ***
a) Single-Hop Mobility b) Multi-Hop MobilityFigure 1: Mobility Scenarios - A Mobile Node (MN) Directly Attaching to Fixed Access Routers (ARs) or Attached via Local Access Routers (LARs) 🌈
2. Problem Description ✨
2.1. General Issues 💭
Multicast mobility is a generic term, and it's basically an umbrella over a bunch of distinct functions 🌂. First, multicast communication gets split into Any Source Multicast (ASM) [2] and Source-Specific Multicast (SSM) [9][10]. Second, the roles of senders and receivers are distinct and asymmetric, and either one can be mobile on its own 🏃♀️. Their interaction is facilitated by a multicast routing protocol, like the Distance Vector Multicast Routing Protocol (DVMRP) [11], the Protocol Independent Multicast - Sparse Mode / Source-Specific Multicast (PIM-SM/SSM) [12][13], Bidirectional PIM [14], or inter-domain multicast prefix advertisements via Multiprotocol Extensions for BGP-4 (MBGP) [15]. IPv6 clients interact using the multicast listener discovery protocol (MLD and MLDv2) [16][17] 🎀.
Any solution for multicast mobility needs to take all of these functional blocks into account 🧩. It should enable seamless continuity of multicast sessions when moving from one IPv6 subnet to another, and that's the real vibe we're after ✨. It's desired to preserve the multicast nature of packet distribution and to approximate optimal routing 🦋. It should also support per-flow handover for multicast traffic, because the properties and designations of flows can be distinct 💅. Those distinctions may come from differing Quality-of-Service (QoS) / real-time requirements, but they may also be caused by network conditions that differ between groups 🌸.
The host group model extends the capability of the network-layer unicast service 🧚. Just like fixed networks, multicast mobility management should transparently use or smoothly extend the unicast functions of MIPv6 [5], its security extensions [6][18], its expediting schemes FMIPv6 [19] and Hierarchical Mobile IPv6 Environment (HMIPv6) [20], its context transfer protocols [21], its multihoming capabilities [22][23], emerging protocols like PMIPv6 [62], or future developments 🌈. From the perspective of an integrated mobility architecture, it's desirable to avoid both multicast-specific and unicast-restricted solutions, whenever general approaches can be derived that jointly support unicast and multicast 🫶.
Multicast routing dynamically adapts to the network topology at the locations of the sender(s) and receiver(s) in a multicast session, and that topology can change under mobility 🔄. However, depending on the topology and the protocol in use, current multicast routing protocols may need a time close to seconds to converge after a change in receiver or sender location 😭. That is far too slow to support seamless handovers for interactive or real-time media sessions 💀. The actual timing depends heavily on the multicast routing protocol in use, the configuration of routers, and the geometry of the current distribution tree. A mobility scheme that readjusts routing, i.e., partially changes or fully reconstructs a multicast tree, is forced to comply with the time scale for protocol convergence. In particular, it needs to consider a possible rapid movement of the mobile node, since that can happen at much higher rates than common protocol state updates ⚡.
The mobility of hosts using IP multicast can impact the service presented to higher-layer protocols 👑. IP-layer multicast packet distribution is an unreliable service that's bound to a connectionless transport service. Where applications are sensitive to packet loss or jitter, countermeasures need to be performed (loss recovery, content recoding, concealment, etc.) by the multicast transport or the application 🛠️. Mobile multicast handovers should not introduce significant additional packet drops 🙅♀️. Because of statelessness, bi-casting of multicast flows does not cause degradations at the transport layer, and applications should implement mechanisms to detect and correctly respond to duplicate datagrams. Nevertheless, individual application programs may not be robust with respect to repeated reception of duplicate streams 🙈.
IP multicast applications can be designed to adapt the multicast stream to the prevailing network conditions 🎢. That could mean adapting the sending rate to the level of congestion, adaptive tuning of clients in response to measured delay, dynamic suppression of feedback messages, and so on. An adaptive application may also use more than one multicast group, for example layered multicast, where a client selects a set of multicast groups based on its perceived available network capacity 🍓. A mobility handover may temporarily disrupt the operation of these higher-layer functions. The handover can invalidate assumptions about the forwarding path (for example, acceptable delivery rate or round-trip delay), which could impact an application and the level of network traffic 😬. Such effects need to be considered both in the design of multicast applications and in the design of network-layer mobility. Specifically, mobility mechanisms need to be robust to transient packet loss that may result from invalid path expectations after an MN hands over to a different network 🧯.
Group addresses, in general, are location transparent, even though they may be scoped and methods can embed unicast prefixes or Rendezvous Point addresses [24] 🗺️. The addresses of sources contributing to a multicast session are interpreted by the routing infrastructure and by receiver applications, and those receivers are frequently aware of source addresses 👀. So multicast inherits the mobility address duality problem of MIPv6 for source addresses. An address is a logical node identifier, i.e., the home address (HoA) on one hand, and a topological locator, the care-of address (CoA), on the other 🪞. At the network layer, the elements that make up the delivery tree (multicast senders, forwarders, and receivers) need to carefully account for address duality issues, for example by using binding caches, extended multicast states, or signaling 🔐.
Multicast sources, in general, operate decoupled from their receivers. A multicast source sends packets to a group of receivers that are unknown at the network layer, so it operates without a feedback channel 📭. It has no means to inquire about the properties of its delivery trees, and it can't learn about the network-layer state of its receivers 🙃. During an inter-tree handover, a mobile multicast source is therefore vulnerable to losing connectivity to receivers without noticing 😱. (Appendix A describes implicit source notification approaches 📖.) Applying a MIPv6 mobility binding update or return routability procedure will similarly break the semantics of a receiver group that remains unidentified by the source, so it can't be applied in unicast analogy 🚫.
Despite the complexity of the requirements, multicast mobility management should seek lightweight solutions with easy deployment 🍃. Realistic, sample deployment scenarios and architectures should be provided in future solution documents 📝.
2.2. Multicast Listener Mobility 🎧
2.2.1. Node and Application Perspective ✨
okay so a mobile multicast listener (the MN 🧚) walks into a new IP subnet and needs multicast reception to keep working right after the handover, in real time 😭. That means the multicast membership context has to move from the old point of attachment to the new one. You can do that by (re-)establishing a tunnel, or by transferring the MLD Listening State information of the MN's moving interface(s) to the new upstream router(s). In the second case, one of these three situations can happen:
- In the simplest scenario, packets of some, or all, of the subscribed groups of the mobile node are already being received by one or several other group members in the new network, so multicast streams natively flow once the MN arrives. 🌊
- The requested multicast service may be supported and enabled in the visited network, but the groups under subscription may not be forwarded to it, e.g., groups may be scoped or administratively prohibited. So the current distribution trees for the desired groups may only be re-joined at a (possibly large) routing distance. 🙃
- The new network may not be multicast-enabled, or the specific multicast service may be unavailable, e.g., unsupported or prohibited. So the current distribution trees for the desired groups need to be re-joined at a large routing distance by (re-)establishing a tunnel to a multicast-enabled network node. 🚧
The problem of achieving seamless multicast listener handovers is thus threefold 💅:
- Ensure multicast reception, even in visited networks, without appropriate multicast support.
- Minimize multicast forwarding delay to provide seamless and fast handovers for real-time services. Depending on Layer 2 (L2) and Layer 3 (L3) handover performance, the time available for multicast mobility operations is typically bound by the total handover time left after IPv6 connectivity is regained. In real-time scenarios, this may be significantly less than 100 ms. ⏱️
- Minimize packet loss and reordering that result from multicast handover management.
Moreover, in many wireless regimes, it is also desirable to minimize multicast-related signaling to preserve the limited resources of battery-powered mobile devices and the constrained transmission capacities of the networks. This may lead to a desire to restrict MLD queries towards the MN. Multihomed MNs may ensure smooth handoffs by using a "make-before-break" approach, which requires a per-interface subscription, facilitated by an MLD JOIN operating on a pre-selected IPv6 interface. 🔋
Encapsulation on the path between the upstream router and the receiver may result in MTU size conflicts, since path-MTU discovery is often not supported for multicast and can reduce scalability in networks with many different MTU sizes, or introduce potential denial-of-service vulnerabilities (since the originating addresses of ICMPv6 messages cannot be verified for multicast). Not ideal, bestie 😬 In the absence of fragmentation at tunnel entry points, this may prevent the group from being forwarded to the destination.
2.2.2. Network Perspective 🌐
The infrastructure providing multicast services is required to keep traffic following the MN without compromising network functionality. So mobility solutions have to face some immediate problems:
- Realize native multicast forwarding, and where applicable, conserve network resources and utilize link-layer multipoint distribution to avoid data redundancy.
- Activate link-multipoint services, even if the MN performs only a L2/vertical handover.
- Ensure routing convergence, even when the MN moves rapidly and performs handovers at a high frequency.
- Avoid avalanche problems and stream multiplication (n-casting), which potentially result from replicated tunnel initiation or redundant forwarding at network nodes. 🔁
There are additional implications for the infrastructure. When changing its point of attachment, an exclusive mobile receiver may initiate forwarding of a group in the new network and termination of a group distribution service in the previous network. Mobility management may impact multicast routing by, e.g., erroneous subscriptions following predictive handover operations, or slow traffic termination at leaf nodes resulting from MLD query timeouts, or by departure of the MN from a previous network without leaving the subscribed groups. Finally, packet duplication and reordering may follow a change of topology. 🌀
2.3. Multicast Source Mobility 🎀
2.3.1. Any Source Multicast Mobility
A node submitting data to an ASM group either forms the root of a source-specific shortest path tree (SPT), distributing data towards a rendezvous point (RP) or receivers, or it forwards data directly down a shared tree, e.g., via encapsulated PIM Register messages, or using bidirectional PIM routing. Native forwarding along source-specific delivery trees will be bound to the source's topological network address, due to reverse path forwarding (RPF) checks. A mobile multicast source moving to a new subnetwork is only able to either inject data into a previously established delivery tree, which may be a rendezvous-point-based shared tree, or to (re-)initiate the construction of a multicast distribution tree for its new network location. In the latter case, the mobile sender will have to proceed without knowing whether the new tree has regained ability to forward traffic to the group, due to the decoupling of sender and receivers. 🤷♀️
A mobile multicast source must therefore provide address transparency at two layers. To comply with RPF checks, it has to use an address within the source field of the IPv6 basic header, which is in topological agreement with the employed multicast distribution tree. For application transparency, the logical node identifier, commonly the HoA, must be presented as the packet source address to the transport layer at the receiver side. Two layers, two jobs, zero drama 💜
The address transparency and temporal handover constraints pose major problems for route-optimizing mobility solutions. Additional issues arise from possible packet loss and from multicast scoping. A mobile source away from home must respect scoping restrictions that arise from its home and its visited location [5].
Intra-domain multicast routing may allow the use of shared trees that can reduce mobility-related complexity. A static rendezvous point may allow a mobile source to continuously send data to the group by encapsulating packets to the RP with its previous topologically correct or home source address. Intra-domain mobility is transparently provided by bidirectional shared domain-spanning trees, when using bidirectional PIM, eliminating the need for tunneling to the corresponding RP (in contrast to IPv4, IPv6 ASM multicast groups are associated with a specific RP/RPs). 🦋
Issues arise in inter-domain multicast, whenever notification of source addresses is required between distributed instances of shared trees. A new CoA acquired after a mobility handover will necessarily be subject to inter-domain record exchange. In the presence of an embedded rendezvous point address [24], e.g., the primary rendezvous point for inter-domain PIM-SM will be globally appointed, and a newly attached mobile source can contact the RP without prior signaling (like a new source) and transmit data in the PIM register tunnel. Multicast route optimization (e.g., PIM "shortcuts") will require multicast routing protocol operations equivalent to serving a new source. 🚀
2.3.2. Source-Specific Multicast Mobility
Source-Specific Multicast has been designed for multicast senders with static source addresses. The source addresses in a client subscription to an SSM group are directly used to route identification. Any SSM subscriber is thus forced to know the topological address of the contributor to the group it wishes to join. The SSM source identification becomes invalid when the topological source address changes under mobility. Hence, client implementations of SSM source filtering must be MIPv6 aware in the sense that a logical source identifier (HoA) is correctly mapped to its current topological correspondent (CoA). 😵💫
As a consequence, source mobility for SSM requires a conceptual treatment beyond the problem scope of mobile ASM. A listener subscribes to an (S,G) channel membership and routers establish an (S,G)-state shortest path tree rooted at source S. Therefore, any change of source addresses under mobility requires state updates at all routers on the upstream path and at all receivers in the group. On source handover, a new SPT needs to be established that will share paths with the previous SPT, e.g., at the receiver side. As the principle of multicast decoupling of a sender from its receivers holds for SSM, the client updates needed for switching trees become a severe burden. 🥵
An SSM listener may subscribe to or exclude any specific multicast source and thereby wants to rely on the topological correctness of network operations. The SSM design permits trust in equivalence to the correctness of unicast routing tables. Any SSM mobility solution should preserve this degree of confidence. Binding updates for SSM sources thus should have to prove address correctness in the unicast routing sense, which is equivalent to binding update security with a correspondent node in MIPv6 [5]. 🔐
The above methods could add significant complexity to a solution for robust SSM mobility, which needs to converge to optimal routes and, for efficiency, is desired to avoid data encapsulation. Like ASM, handover management is a time-critical operation. The routing distance between subsequent points of attachment, the "step size" of the mobile from previous to next designated router, may serve as an appropriate measure of complexity [25][26]. 📏
Finally, Source-Specific Multicast has been designed as a lightweight approach to group communication. In adding mobility management, it is desirable to preserve the leanness of SSM by minimizing additional signaling overhead. SSM stays lean, we stay iconic 🌈👑
2.4. Deployment Issues 🚀
okay so multicast deployment has been moving super slowly for about 15 years now 😭, even though every major router vendor and OS ships support for it [27]. walled gardens and enterprise networks run point-to-multipoint services all the time, but multicast is still pretty limited on the public inter-domain internet [28]. there was also a whole debate about which layer group communication should even live at, and the research crowd got obsessed with application-layer multicast instead 🧚. this "efficiency versus deployment complexity" drama now spills into the mobile multicast world too [29]. Garyfalos and Almeroth [30] showed, from fairly generic principles, that once mobility enters the picture the performance gap between IP-layer and application-layer multicast widens across different metrics, up to a factor of four 📉.
ngl, deployment complexity is a real vibe check 💅. any mobile multicast solution that doesn't change the routing protocols is the dream 💖. mobility handling should ideally happen at the edge nodes, so the routing infrastructure stays mobility-agnostic 🌸. future research has to hunt for these simple, infrastructure-transparent solutions, even though there are reasonable doubts that they can work in every case 🙈.
still, multicast in mobile environments could become a must-have very soon ✨. multimedia services like Digital Video Broadcasting for Handhelds (DVB-H) [31][32] or IPTV are building a strong business case for portable IP-based devices 📱. as IP mobility becomes a big deal, and efficient link utilization matters more in expensive radio environments, multicast protocols are naturally going to evolve to fit mobility constraints 🦋.
3. Characteristics of Multicast Routing Trees under Mobility 🌳
multicast distribution trees have been studied with a focus on network efficiency 🔍. based on empirical observations, Chuang and Sirbu [33] proposed a scaling power-law for the total number of links in a multicast shortest path tree with m receivers, proportional to m^k. the authors consistently found the scale factor to be the constant k = 0.8 💜. this universal, heavy-tailed distribution suggests that multicast shortest path trees are self-similar, with lots of nodes of small degree and only a few of higher degree. so the trees end up shaped tall rather than wide 🌲.
later empirical and analytical work [34][35] debated whether the Chuang and Sirbu scaling law actually applies 🤔. Van Mieghem et al. [34] proved that the proposed power law cannot hold for an ever-growing internet or very large multicast groups, but that it is indeed applicable for moderate receiver numbers and the current Internet size of N = 10^5 core nodes ✨. looking at self-similarity, Janic and Van Mieghem [36] semi-empirically backed up the idea that multicast shortest path trees in the Internet can be modeled with reasonable accuracy by uniform recursive trees (URTs) [37], as long as m stays small compared to N 🫶.
the mobility angle on shortest path trees is about how much they change, meaning the degree of topological changes caused by movement 🦋. for receivers, and even more so for sources, this can be a useful measure of routing complexity 🧠. mobile listeners that move to neighboring networks only alter tree branches that extend over a few hops, which is very contained 💅. the source-specific multicast trees generated from source handover steps aren't independent of each other; they're highly correlated 👯. they most likely branch out to identical receivers at one or several intersection points 🎀. because of the self-similar nature, the persistent sub-trees (from the previous and the next distribution tree) rooted at any such intersection point show the scaling law behavior again. they're tall-shaped with mostly low-degree nodes, so they're likely to coincide 🌈. tree alterations under mobility were studied in [26], both analytically and through simulations, and the results were wild: even in large networks and for moderate receiver numbers, more than 80% of the multicast router states stay invariant under a source handover 🤯👑.
4. Link-Layer Aspects 🔗
4.1. General Background 🌍
scalable group data distribution has the highest potential in edge networks, where tons of end systems live 🏠. so it's not surprising that most LAN access technologies natively support point-to-multipoint or multicast services 💖. wireless access technologies inherently support broadcast/multicast at L2, but they run on a shared medium with limited frequency and bandwidth 📡.
there are several aspects to consider. first, different network access radio technologies cause distinct group traffic transmissions 🎀. there are:
- connection-less link services of a broadcast type, which are mostly bound to limited reliability 🙈;
- connection-oriented link services of a point-to-multipoint type, which require more complex control and frequently show reduced efficiency 😩;
- connection-oriented link services of a broadcast type, which are restricted to unidirectional data transmission ➡️.
also, multicast can be distributed over multiple point-to-point unicast links without using a dedicated multipoint radio channel 🧚. a fundamental difference between unicast and group transmission comes from power management ⚡. some radio technologies adjust transmit power to be as small as possible, based on link-layer feedback from the receiver, and that isn't done in multipoint mode 😬. they consequently take on a "multicast tax", which makes multicast less efficient than unicast unless the number of receivers is larger than some threshold 💀.
second, point-to-multipoint service activation at the network access layer needs a mapping mechanism from network-layer requests 🗺️. this is usually done with L3 awareness, i.e., IGMP/MLD snooping [70] or proxy [38], which is sometimes paired with Multicast VLAN Registration (MVR) 💜. MVR lets a single multicast IEEE 802.1Q Virtual LAN be shared in the network while subscribers stay in separate VLANs 🫧. this L2 separation of multicast and unicast traffic can be used as a workaround for point-to-point link models, to set up a common multicast link 🛠️.
third, an address mapping between the layers is needed so everyone can identify the same group 🪪. address resolution schemes depend on the framing details of the technologies in use, but they commonly cause a significant address overlap at the lower layer, meaning more than one IP multicast group address gets sent using the same L2 address 👯♀️.
4.2. Multicast for Specific Technologies 📶
4.2.1. 802.11 WLAN 🛜
IEEE 802.11 Wireless Local Area Network (WLAN) is a broadcast network of Ethernet type 🌟. it inherits multicast address mapping concepts from 802.3 💅. in infrastructure mode, an access point acts as a repeater, only bridging data between the Basic Service Set (BSS) and the Extended Service Set (ESS) 🔁. a mobile node submits multicast data to an access point in point-to-point acknowledged unicast mode when the ToDS bit is set 📤. an access point that receives multicast data from an MN simply repeats the multicast frames to the BSS and propagates them to the ESS as unacknowledged broadcast 📣. multicast frames received from the ESS get similar treatment 💫.
multicast frame delivery has some main characteristics, and they're kinda important 👀:
- as an unacknowledged service, it offers limited reliability 💔. frames (and hence packets) can be lost because of interference, collision, or time-varying channel properties 🌧️.
- data distribution may be delayed, because unicast power saving synchronization via Traffic Indication Messages (TIM) doesn't operate in multicast mode 😴. access points buffer multicast packets while waiting for a larger Delivery TIM (DTIM) interval, whenever stations use the power saving mode 🔋.
- multipoint data may cause congestion, because the distribution system floods multicast without further control 🌊. all access points of the same subnet replicate multicast frames 🫠.
to limit or prevent that last one, many vendors have implemented a configurable rate limit for forwarding multicast packets 🚦. on top of that, an IGMP/MLD snooping or proxy may be active at the bridging layer between the BSS and the ESS, or at switches interconnecting access points 🧠✨.
4.2.2. 802.16 WIMAX ✨
okay bestie, IEEE 802.16 WiMAX 🦋 is a whole family of connection-oriented radio transmission services that can run in single-hop point-to-multipoint (PMP) mode or in mesh mode. Mesh mode doesn't support multipoint transmission and has no deployment right now, so 💀. PMP runs between Base Stations and Subscriber Stations over distinguished, unidirectional channels. The Base Station is the one in charge of channels, handing out channel IDs (CIDs) within service flows to the Subscriber Stations. Service flows can optionally use Automatic Repeat Request (ARQ) to boost reliability, and they can run in point-to-point or point-to-multipoint mode, where point-to-multipoint is limited to downlink and doesn't use ARQ 🎀
A WIMAX Base Station works like a full-duplex L2 switch, and it switches based on CIDs 🔥. There are two IPv6 link models for mobile access. The first is a shared IPv6 prefix for IP over Ethernet Circuit Switched (CS) [39], which handles Media Access Control (MAC) separation within that shared prefix. The second is a point-to-point link model [40] that is recommended in the IPv6 Convergence Sublayer [41], where each connection to a mobile node counts as its own single link. The catch is that the point-to-point model clashes with consistent group distribution at the IP layer when you're using a shared medium (see Section 4.1 for MVR as a workaround) 💅
To invoke a multipoint data channel, the Base Station gives a common CID to all the Subscriber Stations in the group. The proposed way to map an IPv6 multicast address onto these 16-bit IDs is either to copy the 4 lowest bits while keeping the scope field, or to use the 8 lowest bits derived from Multicast on Ethernet CS [42]. For selecting group members, a Base Station may implement IGMP/MLD snooping or proxy, as foreseen in 802.16e-2005 [43] ✨
A Subscriber Station sends multicast IP packets to a Base Station as a point-to-point unicast stream. When IPv6 CS is used, those packets get forwarded to the upstream access router. The access router (or the Base Station, for IP over Ethernet CS) may send downstream multicast packets by feeding them into the multicast service channel. When a Subscriber Station receives them, it can't tell multicast streams apart from unicast streams at the link layer 🙈
Multicast services have the following characteristics:
- Multicast CIDs are unidirectional and available only in the downlink direction. Thus, a native broadcast-type forwarding model is not available.
- The mapping of multicast addresses to CIDs needs standardization, since different entities (Access Router, Base Station) may have to perform the mapping.
- CID collisions for different multicast groups may occur due to the short ID space. This can result in several point-to-multipoint groups sharing the same CID, reducing the ability of a receiver to filter unwanted L2 traffic.
- The point-to-point link model for mobile access contradicts a consistent mapping of IP-layer multicast onto 802.16 point-to-multipoint services.
- Multipoint channels cannot operate ARQ service and thus experience a reduced reliability.
4.2.3. 3GPP/3GPP2
The 3rd Generation Partnership Project (3GPP) System architecture spans a circuit switched (CS) domain and a packet-switched (PS) domain. In the PS domain, General Packet Radio Services (GPRS) incorporates the IP Multimedia Subsystem (IMS) [44] 🌸. The 3GPP PS is connection-oriented and built on the concept of Packet Data Protocol (PDP) contexts. PDPs define point-to-point links between the Mobile Terminal and the Gateway GPRS Support Node (GGSN). The Internet service types are PPP, IPv4, and IPv6, and the recommendation for IPv6 address assignment is to associate a prefix with each (primary) PDP context [45] 🧚
In Universal Mobile Telecommunications System (UMTS) Rel. 6, the IMS was extended to include Multimedia Broadcast and Multicast Services (MBMS). A point-to-multipoint GPRS connection service runs on radio links, while the gateway service to Internet multicast is handled at the IGMP/MLD-aware GGSN. Local multicast packet distribution is used within the GPRS IP backbone, which leads to the common double encapsulation at the GGSN: global IP multicast datagrams over Generic Tunneling Protocol (GTP) (with multipoint TID) over local IP multicast 🫶
The 3GPP MBMS has the following characteristics:
- There is no immediate Layer 2 source-to-destination transition, resulting in transit of all multicast traffic at the GGSN.
- As GGSNs are commonly regional, distant entities, triangular routing and encapsulation may cause a significant degradation of efficiency.
In 3GPP2, MBMS has been extended to the Broadcast and Multicast Service (BCMCS) [46], which operates on the routing layer very similarly to MBMS 👑. In both 3GPP and 3GPP2, multicast can be sent using either point-to-point (PTP) or point-to-multipoint (PTM) tunnels, and there is support for switching between PTP and PTM. PTM uses a unidirectional common channel, operating in unacknowledged mode without adjustment of power levels and with no reporting on lost packets 😭
4.2.4. DVB-H / DVB-IPDC
Digital Video Broadcasting for Handhelds (DVB-H) is a unidirectional physical layer broadcasting specification for the efficient delivery of broadband and IP-encapsulated data streams. It's published as an ETSI standard [47] (see http://www.dvb-h.org) 📺. It uses multiprotocol encapsulation (MPE) to carry IP packets over an MPEG-2 Transport Stream (TS) with link forward error correction (FEC). Each stream is identified by a 13-bit TS ID (PID), which, together with a multiplex service ID, is associated with IPv4 or IPv6 addresses [48] and is used for selective traffic filtering at receivers. Upstream channels may complement DVB-H using other transmission technologies. The IP Datacast Service, DVB-IPDC [31], specifies a set of applications that can use the DVB-H transmission network 🌈
Multicast distribution services are defined by a mapping of groups onto appropriate PIDs, which is managed at the IP Encapsulator [49]. To increase flexibility and avoid collisions, this address resolution is supported by dynamic tables provided within the self-contained MPEG-2 TS. Mobility is supported in the sense that changes of cell ID, network ID, or Transport Stream ID are foreseen [50]. A multicast receiver therefore needs to relocate the multicast services it's subscribed to during the synchronization phase, and update its service filters. Its handover decision may depend on service availability. An active service subscription (multicast join) requires initiation at the IP Encapsulator / DVB-H Gateway, which cannot be signaled in a pure DVB-H network 🥺
4.2.5. TV Broadcast and Satellite Networks
IP multicast may be enabled in TV broadcast networks, including those specified by DVB, the Advanced Television Systems Committee (ATSC), and related standards [49]. These standards are also used for one- and two-way satellite IP services. Networks based on the MPEG-2 Transport Stream may support either multiprotocol encapsulation (MPE) or unidirectional lightweight encapsulation (ULE) [51]. The second generation DVB standards allow the Transport Stream to be replaced with a Generic Stream, using Generic Stream Encapsulation (GSE) [52]. All of these encapsulation formats support multicast operation 🍓
In MPEG-2 transmission networks, multicast distribution services are defined by a mapping of groups onto appropriate PIDs, which is managed at the IP Encapsulator [49]. The addressing issues resemble those for DVB-H (Section 4.2.4) [48]. The issues for using GSE resemble those for ULE, except that the PID isn't available as a mechanism for filtering traffic. Networks that provide bidirectional connectivity may allow active service subscription (multicast join) to initiate forwarding from the upstream IP Encapsulator / gateway. Some kind of filtering can be achieved using the Input Stream Identifier (ISI) field 💜
4.3. Vertical Multicast Handovers
A mobile multicast node may change its point of Layer 2 attachment within homogeneous access technologies (horizontal handover) or between heterogeneous links (vertical handover). In either case, a Layer 3 network change may or may not take place, but multicast-aware links always need information about group traffic demands. Consequently, a dedicated context transfer of multicast subscriptions is required at the network access. This Media Independent Handover (MIH) is addressed in IEEE 802.21 [53], but it's relevant beyond IEEE protocols too. Mobility services transport for MIH is required as an abstraction for Layer 2 multicast service transfer in an Internet context [54], and it's specified in [55] 🦋
MIH needs to help with more than service discovery. There's a need for complex, media-dependent multicast adaptation, a possible absence of MLD signaling in L2-only transfers, and requirements that come from predictive handovers. A multicast mobility services transport needs to be comprehensive and abstract enough to initiate a seamless multicast handoff at network access ✨
Functions required for MIH include:
- Service discovery.
- Service context transformation.
- Service context transfer.
- Service invocation.
5. Solutions 💖
5.1. General Approaches 🎀
Okay bestie, there are three go-to approaches for mobile multicast [56] 💅:
- Bidirectional Tunneling 🔁: the mobile node tunnels all its multicast data through its home agent. This is the basic multicast solution, and it hides all the movement, which means the multicast trees stay static 🌳. Mobile listeners and sources can use it without noticing anything, but the cost is triangular routing and maybe some serious performance drop from long, widely spread data tunnels 🫠.
- Remote Subscription 🔄: the mobile node has to restart multicast distribution after each handover, for example by sending an MLD listener report to the subnet where the receiver just plugged in. This is tree discontinuation, and it leans on multicast dynamics to adjust to network changes. It causes a lot of service disruption, and it also leads to source addresses changing because of mobility, so it can't keep a session persistent under multicast source mobility 😭.
- Agent-based solutions 🤝: these try to find a middle ground between the two above. Static agents usually act as local tunneling proxies, which allows some inter-agent handover when the mobile node moves. The result of agent-based multicast mobility is a slowed-down inter-tree handover, aka "tree walking" 🐢. Extra effort is needed here to keep the session going, through address transparency for mobile sources.
MIPv6 [5] brings in bidirectional tunneling and remote subscription as its minimal standard solutions ✨. Lots of publications suggest using remote subscription for listener mobility only, and bidirectional tunneling for source mobility 💜. This dodges the "tunnel convergence" or "avalanche" problem [56], which is when the home agent has to copy and encapsulate packets for every receiver of the same group, even if those receivers are sitting on the same subnetwork 🙈. The catch is that multicast communication roles aren't explicitly known at the network layer, and they can change unexpectedly 💀.
None of the approaches above handle SSM source mobility, except for bidirectional tunneling 🫶.
5.2. Solutions for Multicast Listener Mobility 🦋
5.2.1. Agent Assistance
There are proposals for agent-assisted handover for host-based mobility 🌸. They complement the unicast real-time mobility setups of Fast MIPv6 (FMIPv6) [19], the M-FMIPv6 [57][58], and Hierarchical MIPv6 (HMIPv6) [20], the M-HMIPv6 [59], plus context transfer [60]. Those have all been analyzed in depth in [25][61] 🧠.
All of these solutions assume the context state was stored in a network node that can be reached both before and after a move 📍. But there could be situations where the MN has lost contact with the previous network by the time it arrives at the new location 😬. In that case the network itself can't help with the context transfer. This can happen when moving from one (walled) operator to another, and it means you need a backwards compatible way to recover from losing connectivity and context, using only the node itself 🔐.
Network-based mobility management, Proxy MIPv6 (PMIPv6) [62], is multicast transparent in the sense that the MN sees a point-to-point home link fixed at its static Local Mobility Anchor (LMA) 🗺️. This virtual home link is made of a unicast tunnel between the LMA and the current Mobile Access Gateway (MAG), plus a point-to-point link connecting the current MAG to the MN. A PMIPv6 domain inherits MTU-size problems from the tunnels that span to the receiver site 📏. There are also two avalanche problem points: the LMA may have to tunnel data to a huge number of MAGs, and an MAG may have to forward the same multicast stream to many MNs over individual point-to-point links [63] 😵. Future optimizations and extensions to shared links will preferably adapt native multicast distribution toward the edge network, possibly using a local routing option. That includes context transfer between access gateways to help IP-mobility-agnostic MNs 🌈.
An approach based on dynamically negotiated inter-agent handovers is presented in [64] 🤝. Outside of IETF work, plenty of publications present proposals for seamless multicast listener mobility. For example, [65] gives a comprehensive overview of the work done before 2004 📚.
5.2.2. Multicast Encapsulation
Encapsulating multicast data packets is an established way to shield mobility and to access remotely located data services, like streams from the home network 🎁. Generic packet tunneling in IPv6 [66] using a unicast point-to-point method will also let you transit multicast-agnostic domains 🚇. The downside is that it inherits the tunnel convergence problem and can cause traffic multiplication 😩.
Multicast-enabled environments can take advantage of point-to-multipoint encapsulation. That means generic packet tunneling using an appropriate multicast destination address in the outer header 📡. This multicast-in-multicast encapsulation also lets you receive remotely located streams, but it doesn't suffer from the scaling overhead that comes with unicast tunnels 🙌.
The tunnel entry point that does the encapsulation should provide fragmentation of data packets, so you avoid issues from MTU-size constraints within the networks that support the tunnels 🧩.
5.2.3. Hybrid Architectures
There's been recent interest in methods that avoid the complexity in the Internet core network 🌐. Think application-layer and overlay proposals for (mobile) multicast. The possibility of folding multicast distribution on the overlay into the network layer is also being looked at by the IRTF Scalable Adaptive Multicast (SAM) Research Group 👀.
An early hybrid architecture used reactively operating proxy-gateways at the Internet edges, introduced by Garyfalos and Almeroth [30] 🕰️. The authors presented an Intelligent Gateway Multicast, which acts as a bridge between mobility-aware native multicast management in access networks and mobility group distribution services in the Internet core. That can run on the network or application layer 🌉. The Hybrid Shared Tree approach [67] brought in a mobility-agnostic multicast backbone on the overlay 🦄.
Current SAM RG work is developing general architectural approaches for hybrid multicast solutions [68], plus a common multicast API for transparent access to hybrid multicast [69]. Both will need a detailed design in future work 🛠️.
5.2.4. MLD Extensions
The default timer values and Robustness Variable specified in MLD [17] weren't designed with mobility in mind 😤. This results in a slow reaction from the multicast-routing infrastructure (including L3-aware access devices [70]) after a client leaves. That can be a real disadvantage for wireless links, where performance may improve if you carefully tune the Query Interval and other variables 📶. Some vendors have optimized performance by putting a listener node table at the access router, which can get rid of the need for query timeouts when leave messages come in. That's explicit receiver tracking 🧾.
An MN doing predictive handover, for example using FMIPv6, may speed up multicast service termination when it leaves the previous network. It does this by sending an early Done message before the handoff 🏃♀️. MLD router querying lets the multicast forwarding state be restored if the prediction was wrong, meaning the anticipated move to a network never actually happened 🔄. Backward context transfer may otherwise make sure a leave gets signaled ✅. A further optimization was introduced by Jelger and Noel [71] for the special case where the HA is a multicast router 💡. A Done message that arrives through a tunnel from the mobile end node (generally through a point-to-point link directly connecting the MN) should not start standard MLD membership queries, which come with a later timeout. Treating point-to-point links explicitly like this cuts traffic and speeds up the control protocol 🚀. Explicit tracking ends up causing identical protocol behavior.
When it's away from home, an MN may want to rely on a proxy or "standby" multicast membership service, which can be offered by an HA or a proxy router 🏠. These functions depend on being able to restart fast packet forwarding quickly. So it can be handy for the proxy router to stay part of the multicast delivery tree, even when group data transmission is paused ⏸️. To enable this proxy control, the authors in [71] propose an extension to MLD that introduces a Listener Hold message, exchanged between the MN and the HA 🎟️. This idea was developed in [59] into multicast router attendance control, which allows general deployment of group membership proxies 🌟. Some IPTV solutions in use today combine this mechanism with a recent (video) frame buffer, so you get fast channel switching between several IPTV multicast flows, aka zapping 📺🍿.
5.3. Solutions for Multicast Source Mobility 🌷
5.3.1. Any Source Multicast Mobility Approaches
Solutions for multicast source mobility fall into three categories 🗂️:
- Statically Rooted Distribution Trees 🌳: these methods follow a shared tree approach. Romdhani et al. [72] proposed using the Rendezvous Points of PIM-SM as mobility anchors. Mobile senders tunnel their data to these "Mobility-aware Rendezvous Points" (MRPs) 🎯. Limited to a single domain, this scheme is equivalent to bidirectional tunneling. Looking at inter-domain mobile multicast, the authors designed a tunnel- or SSM-based backbone that distributes packets between MRPs 🌍.
- Reconstruction of Distribution Trees 🏗️: several authors have proposed building a completely new distribution tree after a mobile source moves, which means they have to make up for the extra routing (tree-building) delay ⏳. M-HMIPv6 [59] tunnels data into a previously established tree rooted at mobility anchor points, to cover the routing delay until a protocol-dependent timer expires ⌛. The Range-Based Mobile Multicast (RBMoM) protocol [73] adds an extra Multicast Agent (MA) that advertises its service range 📣. A mobile source registers with the closest MA and tunnels data through it. When it moves out of the previous service range, it does MA discovery and a re-registration, then keeps tunneling data through a newly established Multicast Agent in its new vicinity 🛰️.
- Tree Modification Schemes 🔧: for DVMRP routing, Chang and Yen [74] propose an algorithm that extends the root of a given delivery tree to bring in a new source location in ASM 🌿. The authors rely on a complex additional signaling protocol to fix DVMRP forwarding states and heal failures in the reverse path forwarding (RPF) checks 🧵.
5.3.2. Source-Specific Multicast Mobility Approaches 🦋
Okay so the shared tree approach of [72] got a glow-up to support SSM mobility 💅 by adding the HoA address record to the Mobility-aware Rendezvous Points (MRPs). The MRPs run on extended multicast routing tables that hold the HoA and CoA at the same time, so they can logically figure out which distribution tree is the right one. Mobility kind of brings rendezvous points back into SSM routing, which is giving full plot twist 🌀
Approaches for rebuilding SPTs in SSM depend on a client notification to set up new router state. They also have to keep address transparency for the client 🫶 Thaler [75] proposed introducing a binding cache and source address transparency that works like MIPv6 unicast communication 🎀 Initial session announcements and changes of source addresses get sent out periodically to clients through an extra multicast control tree rooted at the home agent. Source tree handovers then get activated when listeners make requests.
Jelger and Noel [76] suggest handover improvements that use anchor points inside the source network, so data reception keeps going during client-initiated handovers 🙌 Client updates get triggered out of band, e.g., by Source Demand Routing (SDR) / Session Announcement Protocol (SAP) [77]. So receiver-oriented tree construction in SSM stays unsynchronized with source handovers 😭
To fix the synchronization problem at the routing layer, a bunch of proposals went straight for modifying the distribution trees 🔧 A recursive scheme may use loose unicast source routes with branch points, based on a multicast Hop-by-Hop protocol. Vida et al. [78] optimized the SPT for a moving source on the path between the source and the first branching point. O'Neill [79] came up with a way to get past RPF check failures caused by multicast source address changes in a rendezvous point scenario. The trick is adding extended routing information that rides along with the data in a Hop-by-Hop option RPF redirect header.
The Tree Morphing approach of Schmidt and Waehlisch [80] used source routing to extend the root of a previously established SPT, which injects router state updates in a Hop-by-Hop option header. With extended RPF checks, the stretched tree automatically starts shortcuts and smoothly shrinks down into a new SPT rooted at the relocated source. An enhanced version of this protocol dropped the initial source routing and could be proved to comply with rapid source movement [81].
Lee et al. [82] introduced a state-update mechanism for reusing major parts of established multicast trees 🌳 They start from an initially established distribution state centered at the mobile source's home agent. A mobile source leaving its home network signals a multicast forwarding state update on the path to its home agent and, after that, distribution states according to the mobile source's new CoA along the previous distribution tree. Multicast data then flows natively using triangular routes via the elongation and an updated tree centered on the home agent.
Based on Host Identity Protocol identifiers, Kovacshazi and Vida [83] introduce multicast routing states that stay independent of IP addresses 🧚 Drawing on a similar scaling law argument, parts of these states may then be reused after source address changes.
6. Security Considerations 🔐
Okay, this part is seriously important, so no skipping it 🚨 This document discusses multicast extensions to mobility. It does not define new methods or procedures. Security issues arise from source address binding updates, specifically in the case of source-specific multicast. Threats of hijacking unicast sessions will result from any solution that jointly operates binding updates for unicast and multicast sessions 😱
Multicast protocols have a risk of network-based traffic amplification 📣 For example, an attacker may abuse mobility signaling to inject unwanted traffic into a previously established multicast distribution infrastructure. These threats are partially mitigated by reverse path forwarding checks by multicast routers. However, a multicast or mobility agent that explicitly replicates multicast streams, e.g., a Home Agent that n-casts data, may be vulnerable to denial-of-service attacks. In addition to source authentication, a rate control of the replicator may be required to protect the agent and the downstream network.
Mobility protocols need to think about the implications and requirements for Authentication, Authorization, and Accounting (AAA) 🛡️ An MN may have been authorized to receive a specific multicast group when using one mobile network, but that may not be valid when attaching to a different network. In general, the AAA association for an MN may change between attachments, or it may be individually chosen before network (re-)association. The most appropriate network path may be one that satisfies user preferences, e.g., using or avoiding a specific network or minimizing monetary cost, rather than one that only minimizes the routing cost. Consequently, AAA bindings may need to be considered when performing context transfer.
Admission control issues may arise when new CoA source addresses are introduced to SSM channels [84]. Due to lack of feedback, the admission [85] and binding updates [86] of mobile multicast sources require autonomously verifiable authentication. This can be achieved by, for instance, Cryptographically Generated Addresses (CGAs) 🔑
Modification to IETF protocols (e.g., routing, membership, session announcement, and control) as well as the introduction of new entities, e.g., multicast mobility agents, can introduce security vulnerabilities. They also require consideration of issues such as authentication of network entities, and methods to mitigate denial of service (in terms of unwanted network traffic, unnecessary consumption of router/host resources, and router/host state/buffers). Future solutions must therefore analyze and address the security implications of supporting mobile multicast 🚧
7. Summary and Future Steps 🌈
This document is meant to lay the groundwork for future design of mobile IPv6 multicast methods and protocols by:
- providing a structured overview of the problem space that multicast and mobility jointly generate at the IPv6 layer;
- referencing the implications and constraints arising from lower and upper layers and from deployment;
- briefly surveying conceptual ideas of currently available solutions;
- including a comprehensive bibliographic reference base.
It is recommended that future steps toward extending mobility services to multicast first solve the following problems 👑
- Ensure seamless multicast reception during handovers, meeting the requirements of mobile IPv6 nodes and networks. This addresses the problems of home subscription without n-tunnels, as well as native multicast reception in those visited networks that offer a group communication service.
- Integrate multicast listener support into unicast mobility management schemes and architectural entities to define a consistent mobility service architecture, providing equal support for unicast and multicast communication.
- Provide basic multicast source mobility by designing address duality management at end nodes.
Appendix A. Implicit Source Notification Options 💌
An IP multicast source transmits data to a group of receivers without requiring any explicit feedback from the group. Sources therefore are unaware at the network layer of whether any receivers have subscribed to the group, and they unconditionally send multicast packets that propagate in the network to the first-hop router (often known in PIM as the designated router). There have been attempts to implicitly obtain information about listening group members, e.g., by extending an IGMP/MLD querier to inform the source of the existence of subscribed receivers. Multicast Source Notification of Interest Protocol (MSNIP) [87] was one such suggested method, which allowed a multicast source to query the upstream designated router. However, this work did not progress within the IETF mboned working group and was terminated by the IETF 🥲
Multicast sources may also be controlled at the session or transport layer using end-to-end control protocols. A majority of real-time applications employ the Real-time Transport Protocol (RTP) [88]. The accompanying control protocol, RTP Control Protocol (RTCP), allows receivers to report information about multicast group membership and associated performance data. In multicast, the RTCP reports are submitted to the same group and thus may be monitored by the source to monitor, manage, and control multicast group operations. RFC 2326, the Real Time Streaming Protocol (RTSP), provides session layer control that may be used to control a multicast source. However, RTCP and RTSP information is intended for end-to-end control and is not necessarily visible at the network layer. Application designers may choose to implement any appropriate control plane for their multicast applications (e.g., reliable multicast transport protocols), and therefore a network-layer mobility mechanism must not assume the presence of a specific transport or session protocol 🧩
Informative References 📚
[1] Aguilar, L. "Datagram Routing for Internet Multicasting", In ACM SIGCOMM '84 Communications Architectures and Protocols, pp. 58-63, ACM Press, June, 1984.
[2] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[3] G. Xylomenos and G.C. Plyzos, "IP Multicast for Mobile Hosts", IEEE Communications Magazine, 35(1), pp. 54-58, January 1997.
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[6] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[7] ITU-T Recommendation, "G.114 - One-way transmission time", Telecommunication Union Standardization Sector, 05/2003.
[8] Akyildiz, I and Wang, X., "A Survey on Wireless Mesh Networks", IEEE Communications Magazine, 43(9), pp. 23-30, September 2005.
[9] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[10] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[11] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[12] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[13] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[14] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[15] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[16] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[17] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[18] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
[19] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[20] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[21] Loughney, J., Ed., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[22] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Work in Progress, May 2008.
[23] Narayanan, V., Thaler, D., Bagnulo, M., and H. Soliman, "IP Mobility and Multi-homing Interactions and Architectural Considerations", Work in Progress, July 2007.
[24] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[25] Schmidt, T.C. and Waehlisch, M. "Predictive versus Reactive - Analysis of Handover Performance and Its Implications on IPv6 and Multicast Mobility", Telecommunication Systems, 30(1-3), pp. 123- 142, November 2005.
[26] Schmidt, T.C. and Waehlisch, M. "Morphing Distribution Trees - On the Evolution of Multicast States under Mobility and an Adaptive Routing Scheme for Mobile SSM Sources", Telecommunication Systems, 33(1-3), pp. 131-154, December 2006.
[27] Diot, C. et al. "Deployment Issues for the IP Multicast Service and Architecture", IEEE Network Magazine, spec. issue on Multicasting, 14(1), pp. 78-88, 2000.
[28] Eubanks, M. http://multicasttech.com/status/, 2008.
[29] Garyfalos, A, Almeroth, K. and Sanzgiri, K. "Deployment Complexity Versus Performance Efficiency in Mobile Multicast", Intern. Workshop on Broadband Wireless Multimedia: Algorithms, Architectures and Applications (BroadWiM), San Jose, California, USA, October 2004. Online: http://imj.ucsb.edu/papers/BROADWIM-04.pdf.
[30] Garyfalos, A, Almeroth, K. "A Flexible Overlay Architecture for Mobile IPv6 Multicast", IEEE Journ. on Selected Areas in Comm., 23(11), pp. 2194-2205, November 2005.
[31] "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Set of Specifications for Phase 1", ETSI TS 102 468;
[32] ETSI TS 102 611, "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Implementation Guidelines for Mobility)", European Standard (Telecommunications series), November 2004.
[33] Chuang, J. and Sirbu, M. "Pricing Multicast Communication: A Cost- Based Approach", Telecommunication Systems, 17(3), 281-297, 2001. Presented at the INET'98, Geneva, Switzerland, July 1998.
[34] Van Mieghem, P, Hooghiemstra, G, Hofstad, R. "On the Efficiency of Multicast", IEEE/ACM Trans. Netw., 9(6), pp. 719-732, Dec. 2001.
[35] Chalmers, R.C. and Almeroth, K.C, "On the topology of multicast trees", IEEE/ACM Trans. Netw., 11(1), 153-165, 2003.
[36] Janic, M. and Van Mieghem, P. "On properties of multicast routing trees", Int. J. Commun. Syst., 19(1), pp. 95-114, Feb. 2006.
[37] Van Mieghem, P. "Performance Analysis of Communication Networks and Systems", Cambridge University Press, 2006.
[38] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[39] Jeon, H., Jeong, S., and M. Riegel, "Transmission of IP over Ethernet over IEEE 802.16 Networks", RFC 5692, October 2009.
[40] Shin, M-K., Ed., Han, Y-H., Kim, S-E., and D. Premec, "IPv6 Deployment Scenarios in 802.16 Networks", RFC 5181, May 2008.
[41] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008.
[42] Kim, S., Jin, J., Lee, S., and S. Lee, "Multicast Transport on IEEE 802.16 Networks", Work in Progress, July 2007.
[43] IEEE 802.16e-2005: IEEE Standard for Local and metropolitan area networks Part 16: "Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", New York, February 2006.
[44] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; "IP Multimedia Subsystem (IMS)"; Stage 2, 3GPP TS 23.228, Rel. 5 ff, 2002 - 2007.
[45] Wasserman, M., Ed., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[46] 3GPP2, www.3gpp2.org, "X.S0022-A, Broadcast and Multicast Service in cdma2000 Wireless IP Network, Rev. A.", http://www.3gpp2.org/Public_html/specs/tsgx.cfm, February 2007.
[47] ETSI EN 302 304, "Digital Video Broadcasting (DVB); Transmission System for Handheld Terminals (DVB-H)", European Standard (Telecommunications series), November 2004.
[48] Fairhurst, G. and M. Montpetit, "Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007.
[49] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-Nocker, B., and H. Linder, "A Framework for Transmission of IP Datagrams over MPEG-2 Networks", RFC 4259, November 2005.
[50] Yang, X, Vare, J, Owens, T. "A Survey of Handover Algorithms in DVB-H", IEEE Comm. Surveys, 8(4), pp. 16-24, 2006.
[51] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326, December 2005.
[52] Fairhurst, G. and B. Collini-Nocker, "Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)", RFC 5163, April 2008.
[53] "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE LAN/MAN Draft IEEE P802.21/D07.00, July 2007.
[54] Melia, T., Ed., "Mobility Services Transport: Problem Statement", RFC 5164, March 2008.
[55] Melia, T., Ed., Bajko, G., Das, S., Golmie, N., and JC. Zuniga, "IEEE 802.21 Mobility Services Framework Design (MSFD)", RFC 5677, December 2009.
[56] Janneteau, C, Tian, Y, Csaba, S. et al. "Comparison of Three Approaches Towards Mobile Multicast", IST Mobile Summit 2003, Aveiro, Portugal, 16-18 June 2003.
[57] Suh, K., Kwon, D.-H., Suh, Y.-J. and Y. Park, "Fast Multicast Protocol for Mobile IPv6 in the fast handovers environments", Work in Progress, January 2004.
[58] Xia, F. and B. Sarikaya, "FMIPv6 extensions for Multicast Handover", Work in Progress, March 2007.
[59] Schmidt, T. and M. Waehlisch, "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", Work in Progress, November 2005.
[60] Miloucheva, I. and K. Jonas, "Multicast Context Transfer in mobile IPv6", Work in Progress, June 2005.
[61] Leoleis, G, Prezerakos, G, Venieris, I, "Seamless multicast mobility support using fast MIPv6 extensions", Computer Comm., 29(18), pp. 3745-3765, 2006.
[62] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[63] Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang, "Multicast Support Requirements for Proxy Mobile IPv6", Work in Progress, July 2009.
[64] Zhang, H., Chen, X., Guan, J., Shen, B., Liu, E., and S. Dawkins, "Mobile IPv6 Multicast with Dynamic Multicast Agent", Work in Progress, January 2007.
[65] Romdhani, I, Kellil, M, Lach, H.-Y. et. al. "IP Mobile Multicast: Challenges and Solutions", IEEE Comm. Surveys, 6(1), pp. 18-41, 2004.
[66] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[67] Waehlisch, M., Schmidt, T.C. "Between Underlay and Overlay: On Deployable, Efficient, Mobility-agnostic Group Communication Services", Internet Research, 17(5), pp. 519-534, Emerald Insight, Bingley, UK, November 2007.
[68] J. Buford, "Hybrid Overlay Multicast Framework", Work in Progress, February 2008.
[69] Waehlisch, M., Schmidt, T., and S. Venaas, "A Common API for Transparent Hybrid Multicast", Work in Progress, October 2009.
[70] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[71] Jelger, C, Noel, T. "Multicast for Mobile Hosts in IP Networks: Progress and Challenges", IEEE Wirel. Comm., 9(5), pp 58-64, Oct. 2002.
[72] Romdhani, I, Bettahar, H. and Bouabdallah, A. "Transparent handover for mobile multicast sources", in P. Lorenz and P. Dini, eds, Proceedings of the IEEE ICN'06, IEEE Press, 2006.
[73] Lin, C.R. et al. "Scalable Multicast Protocol in IP-Based Mobile Networks", Wireless Networks, 8 (1), pp. 27-36, January, 2002.
[74] Chang, R.-S. and Yen, Y.-S. "A Multicast Routing Protocol with Dynamic Tree Adjustment for Mobile IPv6", Journ. Information Science and Engineering, 20(6), pp. 1109-1124, 2004.
[75] Thaler, D. "Supporting Mobile SSM Sources for IPv6", Proceedings of ietf meeting, Dec. 2001. URL: www.ietf.org/proceedings/01dec/slides/magma-2.pdf
[76] Jelger, C. and T. Noel, "Supporting Mobile SSM sources for IPv6 (MSSMSv6)",Work in Progress, January 2002.
[77] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[78] Vida, R, Costa, L, Fdida, S. "M-HBH - Efficient Mobility Management in Multicast", Proc. of NGC '02, pp. 105-112, ACM Press 2002.
[79] A. O'Neill "Mobility Management and IP Multicast", Work in Progress, July 2002.
[80] Schmidt, T. C. and Waehlisch, M. "Extending SSM to MIPv6 - Problems, Solutions and Improvements", Computational Methods in Science and Technology, 11(2), pp. 147-152. Selected Papers from TERENA Networking Conference, Poznan, May 2005.
[81] Schmidt, T.C., Waehlisch, M., and Wodarz, M. "Fast Adaptive Routing Supporting Mobile Senders in Source Specific Multicast", Telecommunication Systems, 43(1), pp. 95-108, 2009, http://dx.doi.org/10.1007/s11235-009-9200-y.
[82] Lee, H., Han, S. and Hong, J. "Efficient Mechanism for Source Mobility in Source Specific Multicast", in K. Kawahara and I. Chong, eds, "Proceedings of ICOIN2006", LNCS vol. 3961, pp. 82-91, Springer-Verlag, Berlin, Heidelberg, 2006.
[83] Kovacshazi, Z. and Vida, R. "Host Identity Specific Multicast", Third International Conference on Networking and Services ICNS, IEEE Press, pp. 1-1, June 2007.
[84] Kellil, M, Romdhani, I, Lach, H.-Y, Bouabdallah, A. and Bettahar, H. "Multicast Receiver and Sender Access Control and its Applicability to Mobile IP Environments: A Survey", IEEE Comm. Surveys & Tutorials, 7(2), pp. 46-70, 2005. 📚
[85] Castellucia, C, Montenegro, G. "Securing Group Management in IPv6 with Cryptographically Based Addresses", Proc. 8th IEEE Int'l Symp. Comp. and Commun, Turkey, July 2003, pp. 588-93. 🔐
[86] Schmidt, T.C, Waehlisch, M., Christ, O., and Hege, G. "AuthoCast - a mobility-compliant protocol framework for multicast sender authentication", Security and Communication Networks, 1(6), pp. 495-509, 2008. 🦋
[87] Fenner, B., Holbrook, H., and I. Kouvelas, "Multicast Source Notification of Interest Protocol (MSNIP)", Work in Progress, November 2001. 🌸
[88] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. 🎀
Acknowledgments 🫶
Okay bestie, this part is my favourite because it's where everyone gets their flowers 💐 Work on exploring the problem space for mobile multicast was pioneered by Greg Daley and Gopi Kurup within their early document "Requirements for Mobile Multicast Clients". Iconic start, honestly 👑
Since then, so many people have actively discussed the different issues and contributed to making this memo better 💖 The authors would like to thank (in alphabetical order) Kevin C. Almeroth, Lachlan Andrew, Jari Arkko, Cedric Baudoin, Hans L. Cycon, Hui Deng, Marshall Eubanks, Zhigang Huang, Christophe Jelger, Andrei Gutov, Rajeev Koodli, Mark Palkow, Craig Partridge, Imed Romdhani, Hesham Soliman, Dave Thaler, and last, but not least, very special thanks to Stig Venaas for his frequent and thorough advice 🧚✨ Stig really was the MVP, no cap 😭
Authors' Addresses 💌
Here's where you can find the people who wrote this thing, lowkey the most important contact list 📮
Thomas C. Schmidt
Dept. Informatik
Hamburg University of Applied Sciences,
Berliner Tor 7
D-20099 Hamburg, Germany
Phone: +49-40-42875-8157
EMail: schmidt@informatik.haw-hamburg.de
Matthias Waehlisch
link-lab
Hoenower Str. 35
D-10318 Berlin, Germany
EMail: mw@link-lab.net
Godred Fairhurst
School of Engineering,
University of Aberdeen,
Aberdeen, AB24 3UE, UK
EMail: gorry@erg.abdn.ac.ukThat's the whole RFC, bestie! 🌈💅 Literally so much brilliant work in one document, and I'm obsessed.
📦 where this page comes from
- ietf: rfc5757 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms