RFC 7028
Multicast Mobility Routing Optimizations for Proxy Mobile IPv6
RFC 7028: Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 🎀
okay bestie, this one is RFC 7028 💖 It's called Multicast Mobility Routing Optimizations for Proxy Mobile IPv6, and it came out in September 2013. It's an Experimental doc (so not a Standards Track thing), and its ISSN is 2070-1721. The authors are JC. Zuniga from InterDigital Communications, LLC, LM. Contreras from Telefonica I+D, CJ. Bernardos from UC3M, S. Jeon from Instituto de Telecomunicacoes, and Y. Kim from Soongsil University 👑 The title block doesn't list any documents it obsoletes or updates, so it's a standalone vibe ✨
Abstract
this doc proposes some experimental glow-ups to the base solution for supporting IP multicasting in a Proxy Mobile IPv6 (PMIPv6) domain 🦋 the two big ideas are a multicast tree mobility anchor that acts as the topological anchor point for multicast traffic, and a direct routing option where the Mobile Access Gateway can give access to multicast content on the local network. the goal is to cut down on multicast traffic replication and support different PMIPv6 deployment scenarios 💅
Status of This Memo
not gonna lie, this section is kind of a serious one 🙈 this document is not an Internet Standards Track specification. it's published for examination, experimental implementation, and evaluation.
it does define an Experimental Protocol for the Internet community, and it's a product of the Internet Engineering Task Force (IETF) 🌸 it represents the IETF community's consensus, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details.
for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7028.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. please read those carefully because they spell out your rights and restrictions for this doc 📜 code components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................5
3.1. MTMA/Direct Routing Mode Selection .........................5
3.2. Multicast Tree Mobility Anchor (Subscription via MTMA) .....5
3.3. Direct Routing (Subscription via Direct Routing) ...........7
4. Mobile Access Gateway Operation .................................9
4.1. Extensions to Binding Update List Data Structure ...........9
4.2. MAG as MLD Proxy ...........................................9
4.2.1. MTMA Mode (Subscription via MTMA) ...................9
4.2.2. Direct Routing Mode (Subscription via
Direct Routing) ....................................11
5. Local Mobility Anchor Operation ................................14
5.1. Dynamic IP Multicast Selector Option ......................14
5.1.1. Option Application Rules ...........................14
5.1.2. Option Format ......................................14
6. Multicast Tree Mobility Anchor Operation .......................16
6.1. Conceptual Data Structures ................................17
7. Mobile Node Operation ..........................................17
8. IPv4 Support ...................................................17
9. IANA Considerations ............................................18
10. Security Considerations .......................................18
11. Contributors ..................................................19
12. References ....................................................20
12.1. Normative References .....................................20
12.2. Informative References ...................................21
Appendix A. MTMA Deployment Use Cases .............................22
A.1. PMIPv6 Domain with Ratio 1:1 ...............................22
A.2. PMIPv6 Domain with Ratio N:1 ...............................22
A.3. PMIPv6 Domain with Ratio 1:N ...............................24
A.4. PMIPv6 Domain with H-LMA ...................................261. Introduction ✨
okay so Proxy Mobile IPv6 [RFC5213] is a network-based way to solve the IP mobility problem 🦋 in a PMIPv6 domain, the Mobile Access Gateway (MAG) acts as a proxy mobility agent in the network and does the mobility management on behalf of the Mobile Node (MN). the Local Mobility Anchor (LMA) is the home agent for the MN and the topological anchor point. PMIPv6 was originally designed for unicast traffic, but a PMIPv6 domain may actually handle data from both unicast and multicast sources 👀
the Internet Group Management Protocol (IGMPv3) [RFC3376] is what IPv4 hosts use to report their IP multicast group memberships to neighboring multicast routers. Multicast Listener Discovery Version 2 (MLDv2) [RFC3810] does a similar job for IPv6 routers, helping them find IPv6 multicast hosts. the IGMP/MLD proxy specification [RFC4605] lets an intermediate (aka edge) node look like a multicast router to downstream hosts and like a host to upstream multicast routers 🧚 the thing is, IGMP and MLD weren't originally designed to handle the IP mobility of multicast listeners, because they were built for fixed networks 🙈
a base solution for both IPv4 and IPv6 multicast listener mobility in a PMIPv6 domain is specified in [RFC6224]. it describes deployment options without changing the mobility and multicast protocol standards 💜 PMIPv6 lets a mobile access gateway set up multiple PMIPv6 tunnels with different local mobility anchors, e.g., up to one per mobile node. but with multicast traffic, several instances of the same traffic can converge on the same MAG. so when IP multicasting gets applied to PMIPv6, it may lead to redundant traffic at a MAG. this is the tunnel convergence problem 😭
to fix this, the doc proposes an experimental solution with two complementary enhancements: multicast anchor and direct routing 🌟 the first one uses a Multicast Tree Mobility Anchor (MTMA) as the topological anchor point for delivering multicast traffic remotely. the second one uses direct routing, which takes advantage of local multicast source availability and lets a mobile access gateway connect directly to a multicast router for simple access to local content 🍓
neither scheme affects the mobile node's support for IPv4 and IPv6 multicast listener mobility, and neither affects the wider Internet, since they only touch the PMIPv6 domains where they're deployed 🫶 also, although the document says "MLD proxy," it should be read as also including "IGMP/MLD proxy" functionality (see Section 8 for details). the status of this proposal is Experimental, and that may be reconsidered later, once there's more implementation feedback and deployment experience, including performance results for the two schemes and operational feedback on scheme selection 🔥
2. Terminology ✨
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💅
this document uses the terminology defined in [RFC5213], [RFC6275], and [RFC3810]. specifically, the definition of PMIPv6 domain is reused from [RFC5213] and reproduced here for completeness 🎀
Proxy Mobile IPv6 Domain (PMIPv6-Domain): this is the network where the mobility management of a mobile node is handled using the Proxy Mobile IPv6 protocol as defined in [RFC5213]. the PMIPv6 domain includes local mobility anchors and mobile access gateways, between which security associations can be set up and authorization for sending proxy binding updates on behalf of the mobile nodes can be ensured 🔐
in this doc, the definition gets refined based on the kind of traffic served to the MN, like this:
PMIPv6 unicast domain: this is the network covered by one LMA for unicast service. it supports mobility as the MN moves from one MAG to another, as long as both are associated with the same LMA for the MN's unicast traffic 💖
PMIPv6 multicast domain: this is the network covered by one network element called MTMA (defined below) for multicast service, in such a way that an MN using that service isn't aware of mobility as it moves from one MAG to another ✨
so from those definitions, a PMIPv6 domain can have several PMIPv6 unicast domains and PMIPv6 multicast domains 🌈 a few more terms get introduced here too:
MTMA or multicast tree mobility anchor: an entity that works as the topological anchor point for multicast traffic. it manages the multicast groups subscribed by all (or a subset of) the MAGs in a PMIPv6 multicast domain, on behalf of the MNs attached to them. so an MTMA performs the functions of either a designated multicast router or an MLD proxy 👑
H-LMA or Hybrid-LMA: an entity dedicated to both unicast and multicast services, able to work as both LMA and MTMA at the same time 🧚
Direct routing: this scheme uses the native multicast infrastructure to retrieve multicast data. for an operator with its own local content, this also includes the case where the content source is directly connected to the MAG 🍓
Subscription via MTMA: a multicast subscription mode where the content is retrieved from the remote (or home) MTMA 💜
Subscription via direct routing: a multicast subscription mode where the content is retrieved using direct routing from the local domain 🦋
3. Overview 🌸
3.1. MTMA/Direct Routing Mode Selection
okay so this spec gives us two complementary operational modes for delivering multicast traffic in a PMIPv6 domain: multicast tree mobility anchor and direct routing 🦋. There are a few ways to pick between them, and it depends on what the operator prefers and how their PMIPv6 deployment is set up ✨. For example, the mode can be configured by hand on the mobile access gateway, based on the multicast tree deployment in the domain and how the operator has set up multicast distribution on it 💅. Another option is to use dynamic policies, sent in the PBU (Proxy Binding Update) / PBA (Proxy Binding Acknowledgement) signaling with the Dynamic IP Multicast Selector option from Section 5.1 🎀. Next up, let's meet each of the two modes 🧚.
3.2. Multicast Tree Mobility Anchor (Subscription via MTMA)
bestie, the multicast tree mobility anchor is the mobility anchor for multicast traffic 🌸. The MTMA is either a designated multicast router or an MLD proxy. Usually, the MTMA is the thing you use to reach remote multicast content 👑.
The MTMA hooks up to the mobile access gateway as described in [RFC6224], and it can reuse native PMIPv6 features like tunnel establishment and security [RFC5213], heartbeat [RFC5847], and more 🔥. Unicast traffic keeps going to the local mobility anchors in the PMIPv6 domain, as described in [RFC5213] 💜. A MAG that connects to the MTMA acts as an MLD proxy 🫶.
This section explains how the MTMA handles MN attachment and multicast mobility 🍓. It focuses on the case where the LMA and the MTMA both live in one unique PMIPv6 domain. Some other deployment scenarios are covered in Appendix A ✨.
Figure 1 shows a PMIPv6 domain that supports multicast mobility 🌈. The local mobility anchor is dedicated to unicast traffic, and the multicast tree mobility anchor is dedicated to multicast traffic 💖. You can think of the MTMA as a kind of upstream multicast router with tunnel interfaces, so that MNs can subscribe through it 🦋.
As Figure 1 shows, MAG1 can connect to both the unicast (LMA) and multicast (MTMA) entities, so a given MN can get unicast and multicast traffic at the same time 😭. In Figure 1, MN1 and MN2 receive unicast traffic, multicast traffic, or both, while MN3 only receives multicast traffic 🙈.
+--------------+
|Content Source| || - PMIPv6 Tunnel
+--------------+ | - Multicast
| Data Path
|
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Unicast Traffic * * Multicast Traffic *
* * * *
* ** ** ** * * ** ** ** *
*** *** *** ** *** *** *** ***
| |
| |
| |
+-----+ +------+
Unicast | LMA | | MTMA | Multicast
Anchor +-----+ +------+ Anchor
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
\\ // ||
+------+ +------+
| MAG1 | | MAG2 | MLD Proxy
+------+ +------+
| | |
| | |
{MN1} {MN2} {MN3}Figure 1: Architecture of Multicast Tree Mobility Anchor (MTMA)
3.3. Direct Routing (Subscription via Direct Routing)
direct routing runs on native multicast infrastructure, so a mobile access gateway can connect straight to a multicast router (as its next hop) in the PMIPv6 domain 🌷. A MAG acts as an MLD proxy here too 🧁.
The big point of direct routing is giving you optimal connectivity for local content 💅. So it takes over from the MTMA for channel management and data delivery of content that's available locally 🎀. Unicast traffic still goes to the LMAs in the PMIPv6 domain, like normal 🦋.
This section explains how direct routing works when MNs attach and multicast mobility happens ✨.
Multicast Tree
:
: || - PMIPv6 Tunnel
+----------+ +----------+ | - Multicast Data Path
| LMA | | MR |
+----------+ +----------+
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ / |
|| \\ |
|| /\\ |
|| / \\ |
|| / \\ |
|| / \\ |
|| / \\ |
+--------+ +--------+
| MAG1 | | MAG2 | MLD proxy
+--------+ +--------+
: :
+------+ +------+
| MN1 | -----> | MN1 |
+------+ +------+Figure 2: Architecture for Direct-Routing-Based PMIPv6 Multicasting
Figure 2 shows the architecture for local routing using native multicasting infrastructure [PMIP6-REQ] 🌸.
The local mobility anchor handles unicast traffic only, and the multicast traffic comes from an upstream multicast router that sits in the PMIPv6 domain 🫶. There can be multiple LMAs for unicast traffic in a given PMIPv6 domain (they aren't drawn in Figure 1, to keep things simple) 💖.
As Figure 2 shows, a mobile access gateway can connect to both unicast (LMA) and multicast routers (MRs), so a given mobile node can receive unicast and multicast traffic at the same time 🌈.
As you can see in Figure 2, each MAG has a direct connection (meaning it doesn't use the PMIPv6 tunnel interface) to a multicast router 🧚. Depending on the multicast support on the visited network, there are different ways to set up that direct connection between the MAGs and the multicast router(s) 👑. For example, they can sit on the same shared link, or use a tunneling approach such as Generic Routing Encapsulation (GRE) tunnels [RFC2784] or Automatic Multicast Tunneling (AMT) [AUTO] 🔥. To make IGMP/MLD signaling and multicast traffic forwarding work, the MLD proxy function defined in [RFC4605] is something the MAG SHOULD implement 🙈. There SHOULD also be direct connectivity between the MAG and the local multicast router (or the additional MLD proxy) 😭.
4. Mobile Access Gateway Operation ✨
This section describes how the mobile access gateway operates, given that the MAG includes MLD proxy functions as defined in [RFC4605] 💅.
4.1. Extensions to Binding Update List Data Structure
A Binding Update List (BUL) at the MAG, like the one specified in [RFC5213], MUST be maintained 🎀. It handles the relationship between the serving entities (for example, the MTMA and the LMA) and the mobile nodes, for both unicast and multicast traffic 🦋.
4.2. MAG as MLD Proxy
4.2.1. MTMA Mode (Subscription via MTMA) 🧚
Okay so for subscription via MTMA, every MAG that's connected to the MTMA must support the MLD proxy function [RFC4605] 💅 Not optional, bestie. Looking at Figure 1, each of the MAG1-MTMA and MAG2-MTMA tunnel interfaces defines its own MLD proxy domain 🦋. The mobile nodes sit on the downstream interface of the MLD proxy (of the MAG), and the MTMA sits on the upstream interface (of the MAG), as per [RFC4605]. Also, the mobile access gateway could be an IGMP proxy instead 🌸
Figure 3 shows what happens when MN1 attaches to a MAG and sets up both its LMA (unicast) association and its MTMA (multicast) association 💖
MN1 MAG1 LMA MTMA
| (MLD proxy) (Unicast) (Multicast)
MN1 attaches to MAG1 | | |
| | | |
|----Rtr Sol--------->| | |
| |--PBU---->| |
| | | |
| |<----PBA--| |
| | | |
| |=Unicast==| |
| | Tunnel | |
|<---------Rtr Adv----| | |
| | | |
|< ------ Unicast Traffic------->| |
| | | |
| |==Multicast Tunnel===|
| | | |
|<-------MLD Query----| | |
| | | |
MN1 requires | | |
multicast services | | |
| | | |
|----MLD Report (G)-->| | |
| | | |
| |----Aggregated------>|
| | MLD Report (G) |
| | | |
| | | |
|<-----------Multicast Traffic------------->|
| | | |Figure 3: MN Attachment and Multicast Service Establishment for MTMA
In Figure 3, the MAG first sets up the PMIPv6 tunnel with the LMA for unicast traffic, as defined in [RFC5213], right after the Router Solicitation from MN1 kicks things off. Unicast traffic then flows between MN1 and the LMA ✨
For multicast, a multicast tunnel may already be pre-configured between the MAG and the MTMA, or it can be set up dynamically when the first MN shows up at the MAG 🎀
MN1 sends an MLD report (when its upper-layer applications need it) as defined in [RFC3810], in response to an MLD Query from the MAG. That Query is generated as defined by [RFC6224] during handover. The MAG, acting as an MLD proxy as defined in [RFC4605], then sends an Aggregated MLD Report to the multicast anchor, the MTMA. This assumes it's a new multicast group the MAG hadn't previously subscribed to. Multicast traffic then flows from the MTMA towards MN1. The MTMA acts as an MLD Querier, so it periodically queries each mobile access gateway about the subscriptions it maintains (not shown in Figure 3) 🫶
Next up, a mobility scenario 👀 MN1 has an ongoing multicast subscription and moves from one MAG to another. Following the baseline solution signaling method in [RFC6224], after MN1 moves, the new mobile access gateway, in its role as MLD proxy, sends an MLD Query to the newly observed mobile node on its downlink. Assuming the next MLD Report from MN1 requests membership for a new multicast group (from the new MAG's point of view), an Aggregated MLD Report gets sent to the MTMA from the new mobile access gateway. That message travels through a multicast tunnel between the new MAG and the MTMA, which is either pre-established or dynamically established 🦋
When MN1 detaches, the old MAG may keep the multicast tunnel with the MTMA if there are still other MNs using it. Even if no mobile nodes are on the multicast tunnel right now, the old MAG may decide to keep it around temporarily for potential future use 🌈
As discussed above, existing MLD (and MLD proxy) signaling handles a large part of the multicast mobility management for the mobile node 👑
4.2.2. Direct Routing Mode (Subscription via Direct Routing) 🧚
In this case, the MLD proxy instance is configured to obtain the multicast traffic locally 💅 Figure 4 shows an example of multicast service establishment. The mobile access gateway first sets up the PMIPv6 tunnel with the local mobility anchor for unicast traffic, as defined in [RFC5213], after being triggered by the Router Solicitation message from the mobile node. Unicast traffic then flows between the MN and the LMA.
For multicast traffic, it's assumed that the upstream interface of the MLD proxy instance has been configured to point to a multicast router internal to the PMIPv6 domain (or towards an additional MLD proxy node in the domain), for all the multicast channels. As a consequence, those channels have to be local 🔥 There should be direct connectivity between the MAG and the local multicast router (or additional MLD proxy).
MN1 MAG1 LMA MR
| (MLD proxy) (Unicast) (Multicast)
MN1 attaches to MAG1 | | |
| | | |
|----Rtr Sol--------->| | |
| |--PBU------->| |
| | | |
| |<-------PBA--| |
| | | |
| |===Unicast===| |
| | Tunnel | |
|<---------Rtr Adv----| | |
| | | |
|<--------Unicast Traffic---------->| |
| | | |
| | | |
|<-------MLD Query----|<-------------MLD Query----|
| | | |
MN1 requires | | |
multicast services | | |
| | | |
|--MLD Report (G)---->| | |
| | | |
| |----Aggregated------------>|
| | MLD Report (G) |
| | | |
| | | |
|<-------------Multicast Traffic----------------->|
| | | |Figure 4: Multicast Service Establishment for Direct Routing
Upon detecting node attachment from an incoming interface, the MAG adds each downstream interface to the MLD proxy instance, with an upstream link to an MR, according to the standard MLD proxy operations in [RFC4605]. It then sends an MLD Query message towards the MN. The mobile node sends the MLD report message (when its upper-layer applications need it) in response to an MLD Query from the MAG. When the MAG receives an MLD Report message from each incoming interface, it checks the MLD proxy instance associated with the downstream interface. The MLD Report messages are then aggregated and forwarded to the upstream link associated with the MR. This assumes it's a new multicast group the MAG hadn't previously subscribed to. Multicast traffic then flows from the local multicast router towards the mobile node 💖
MN1 P-MAG N-MAG LMA MR
| | | | |
| | | | |
|<------------|<-- Multicast Data----------------|
| | . | | |
| | . | | |
| | . | | |
Link Handover | | |
Disconnected Detection | | |
| | | | |
| | | | |
| | MN Attachment | |
| | | | |
| | | | |
|----Rtr Sol------------->| | |
| | | | |
| | |--PBU----->| |
| | | | |
| | |<-----PBA--| |
| | | | |
|<-----------MLD Query----| | |
| | | | |
|----MLD Report---------->| | |
| | | | |
| | |----Aggregated------->|
| | | MLD Report |
| | | | |
|<------------------------|<---Multicast Data----|
| | | | |Figure 5: Multicast Mobility Signaling for Direct Routing
Figure 5 shows the handover operation procedure for the direct routing operation mode 🦋 When MN1 hands off to the next MAG (N-MAG) from the previous MAG (P-MAG), the N-MAG detects the newly arrived attached mobile node and performs the binding update procedure by exchanging PBU/PBA signaling messages with the LMA. At the same time, an MLD proxy instance detecting MN1 transmits an MLD query message to the mobile node. After receiving that MLD query message, MN1 sends an MLD report message that includes the multicast group information. The N-MAG then sends an aggregated MLD report message to the upstream link associated with the MR. An upstream interface of the MLD proxy instance is chosen towards a certain multicast router. The upstream interface selection can be done according to dynamic policies conveyed in the Dynamic IP Multicast Selector option (as described in Section 5.1), or according to manually configured policies. Note that in the base solution defined in [RFC6224], the interface selection is determined for each MN based on the Binding Update List. When the N-MAG receives the multicast packets from the MR, it simply forwards them without tunnel encapsulation. The N-MAG updates MN1's location information to the LMA by exchanging PBU/PBA signaling messages 🎀
5. Local Mobility Anchor Operation ✨
This section includes a new mobility option to support dynamic policies on subscription via MTMA/direct routing, based on the local mobility anchor conveying the required info to the mobile access gateway in the proxy binding acknowledgement message 🌸
5.1. Dynamic IP Multicast Selector Option
5.1.1. Option Application Rules ✨
okay so this is the Dynamic IP Multicast Selector option, a brand new TLV-encoded mobility option 🦋 It rides along in the proxy binding acknowledgement that an LMA and a MAG swap, and its whole job is to pass along dynamic policies for subscription via MTMA or direct routing 💅 It carries the IP addresses of the group the MN is subscribed to, plus the source(s) delivering it, plus the filter mode. The info is carried by reusing the Multicast Address Record format straight from [RFC3810], so it's giving déjà vu 🌸 You can have several "Dynamic IP Multicast Selector" options in one message, up to one per active subscription the MN is holding 🫶
5.1.2. Option Format 🎀
Here's the layout of this new option, bestie 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |M| Reserved |Nr of Mcast Address Records (N)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address Record [1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address Record [2] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address Record [N] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: the value is
54💖 - Length: an 8-bit unsigned integer giving the length of the option in octets, excluding the type and length fields 🧚
- Protocol: this field says which multicast membership protocol is in play, and what format the next Multicast Address Record is in. It mirrors the type codes from the original MLD Report message. For MLDv2 [RFC3810] the Protocol value MUST be 143, and for MLDv1 [RFC2710] the Protocol value MUST be 131 🔥
- Dynamic IP Multicast Selector Mode Flag (M-bit): this is the subscription via MTMA/direct routing switch 🦋
- If the (M) flag is set to (1), the multicast traffic for the group(s) in the Multicast Address Record(s) SHOULD be routed locally (subscription via direct routing mode) 🌈
- If the (M) flag is set to (0), the multicast traffic for the group(s) in the Multicast Address Record(s) in this mobility option(s) SHOULD be routed to the home network, via the MTMA (subscription via MTMA mode) 🏠
- The mobile access gateway MAY also choose to use static pre-established policies instead of following what the local mobility anchor says 💅
- All other IP traffic tied to the mobile node gets handled by a default policy configured at the PMIPv6 multicast domain ✨
- Reserved: this field is unused for now 🙈 The value MUST be initialized to 0 by the sender, and MUST be ignored by the receiver 💜
- Nr of Mcast Address Records (N): a 16-bit unsigned integer telling you how many Mcast Address Records (N) are in this option 🍓
- Multicast Address Record: the multicast subscription info for one multicast address, as defined in [RFC3810], or in [RFC2710] for MLDv1 🫶
6. Multicast Tree Mobility Anchor Operation 🌸
Okay the MTMA is basically the bridge to the multicast infrastructure outside the PMIPv6 domain 🌉 It can be an extra MLD proxy, but only when every connected mobile access gateway is also an MLD proxy. In that case it reports up to some further node an aggregated view of the subscriptions in the PMIPv6 multicast domain 📊 Or it can act as a designated multicast router for all the MAGs in that domain 👑 Either way, the MTMA requests the multicast content on behalf of the MAGs (and the mobile nodes behind them) 🙌 It also creates and maintains the right multicast forwarding states for each tunnel interface pointing at the MAGs 💅 And no matter what role it plays, when the MAGs are acting as MLD proxy, the MTMA becomes the MLD querier of the MLD proxy instance living in each MAG 🔥
6.1. Conceptual Data Structures 🧚
The MTMA doesn't directly talk to the mobile nodes attached to any MAG, bestie 🙈 It only keeps track of the multicast groups subscribed per MAG on behalf of the MNs attached to it. So the stuff the MTMA should store is: the tunnel interface identifier (tunnel-if-id) of the bidirectional multicast tunnel between the MTMA and every MAG (kind of like the unicast case in [RFC5213]), the IP addresses of the multicast groups delivered per tunnel to each MAG, and the IP addresses of the sources injecting multicast traffic per tunnel into the multicast domain defined by the MTMA 💖
7. Mobile Node Operation 💜
The mobile node operation isn't affected by having an MTMA as the anchor for multicast traffic, or by using direct routing 🦋 The MN just follows the operations in [RFC5213] and [RFC6224], no drama ✨
This document assumes that every mobile node asking for multicast-only services has already registered in a PMIPv6 unicast domain to get a unicast IP address 🎀 That registration might also be needed for other stuff, like remote management, billing, multicast configuration, and so on 🌈
A given mobile node's policy profile info must be updated so it can store the IPv6 addresses of both the local mobility anchor and the multicast tree mobility anchor. The MTMA one is for the subscription via MTMA case 🫶
8. IPv4 Support 🌍
This document doesn't bring in any IPv4-specific issues around [RFC5844] 🙌 For the solution to work with IPv4, all the network elements described here (the MAG, the MTMA, and the MR) must support IGMP. In that case, the MAG and MTMA work as described in [RFC6224], with the MTMA mirroring the requirements that were described for the LMA. And for the MR, it must also be dual-stack (IPv6/IPv4) enabled 🔥
Even though the document says "MLD proxy" a lot, just know it's also meant to cover "IGMP/MLD proxy" functionality 💅
Now, about the Dynamic IP Multicast Selector Option format: it SHOULD consider IPv4 compatibility, like this 🦋
- Protocol field: for IPv4, this field maps the type codes from the original IGMP Report message, like so 💖
- For IGMPv1 it MUST be 0x12 🌸
- For IGMPv2 it MUST be 0x16 🌸
- For IGMPv3 it MUST be 0x22 🌸
- Multicast Address Record field: the format depends on which IGMP version the MN is using 🧚
9. IANA Considerations 📋
This document defines a new mobility option, the Dynamic IP Multicast Selector. IANA assigned it Type 54 ✨ That Type value comes from the same numbering space used for the other mobility options, as defined in [RFC6275]: http://www.iana.org/assignments/mobility-parameters. 🌈
10. Security Considerations 🔐
This one's serious, bestie 😭 Read it all.
This document describes two complementary operational modes for delivering multicast traffic in a PMIPv6 domain: multicast anchor and direct routing 🦋 It describes different ways to decide which mode gets selected: i) using pre-configured/pre-provisioned policies at the mobile access gateway, or ii) using dynamic policies. Approach ii) could introduce a potential security issue if the protocol signaling isn't properly secured 💀 The Dynamic IP Multicast Selector option described in the document requires message integrity protection and source authentication. So the IPsec security mechanism recommended by Proxy Mobile IPv6 [RFC5213] MUST be used to secure the Dynamic IP Multicast Selector option conveyed in the PBA (Proxy Binding Acknowledgement) 🔒
This document doesn't add any extra security threats beyond the current security considerations of PMIPv6 [RFC5213], MLD [RFC3810], IGMP [RFC3376], and IGMP/MLD Proxying [RFC4605] 🫶
11. Contributors 🌷
The following individuals made significant contributions to this document 💖
Akbar Rahman InterDigital Communications, LLC EMail: akbar.rahman@interdigital.com
Ignacio Soto Universidad Carlos III de Madrid EMail: isoto@it.uc3m.es
12. References 📚
12.1. Normative References 📚✨
Okay bestie, these are the normative references, which means the stuff this spec leans on so hard you can't skip it 🫶
- [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
- [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
- [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
- [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
- [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
- [RFC4605] 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.
- [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
- [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
- [RFC5847] Devarapalli, V., Koodli, R., Lim, H., Kant, N., Krishnan, S., and J. Laganier, "Heartbeat Mechanism for Proxy Mobile IPv6", RFC 5847, June 2010.
- [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
12.2. Informative References 🌸
These ones are the extra reading. Helpful, not required, and some of them are still drafts that were Work in Progress when this was written 💅
- [AUTO] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, July 2013.
- [MLDPROXY] Asaeda, H. and S. Jeon, "Multiple Upstream Interface Support for IGMP/MLD Proxy", Work in Progress, February 2013.
- [MUIIMP] Zhang, H. and T. Schmidt, "Multi-Upstream Interfaces IGMP/MLD Proxy", Work in Progress, July 2013.
- [MULTIMOB] Schmidt, T., Gao, S., Zhang, H., and M. Waehlisch, "Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains", Work in Progress, July 2013.
- [PMIP6-REQ] Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang, "Multicast Support Requirements for Proxy Mobile IPv6", Work in Progress, July 2009.
- [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
- [UPSTREAM] Contreras, LM., Bernardos, CJ., and JC. Zuniga, "Extension of the MLD proxy functionality to support multiple upstream interfaces", Work in Progress, February 2013.
Appendix A. MTMA Deployment Use Cases 🦋
This informative appendix is the big-picture tour 🗺️ It walks through a few ways to deploy the MTMA, looking at it from the network architecture point of view.
These options are sorted by how many LMAs and MTMAs live in a PMIPv6 domain, and by the service relationship a set of MNs gets from them. That relationship is written as a "LMA : MTMA" ratio. So the approaches break down like this:
- A set of MNs is served in a PMIPv6 domain by two entities, one MTMA for multicast service, and one LMA for unicast, in such a way that the ratio is 1:1 (one common PMIPv6 unicast and multicast domain).
- A set of MNs is served in a PMIPv6 domain by several entities, one MTMA for multicast service, while the others (LMAs) for unicast, in such a way that the ratio is N:1 (N PMIPv6 unicast domains coexist with a unique multicast domain).
- A set of MNs is served in a PMIPv6 domain by several entities, one LMA for unicast, while the others (MTMAs) are devoted to multicast service, in such a way that the ratio is 1:N (one single PMIPv6 unicast domain coexists with multiple multicast domains).
Scenarios with an N:M ratio are considered to be a combination of the previous ones ✨
A.1. PMIPv6 Domain with Ratio 1:1 💖
This approach refers to the architecture presented in Figure 1. It's the simple couple era 💑 A common set of MNs is served by a couple of entities, one LMA for unicast and one MTMA for multicast. All the MNs of the set are served by these two elements as they move around the PMIPv6 domain.
A.2. PMIPv6 Domain with Ratio N:1 🧚
This approach is the one where a common set of MNs is served by a unique MTMA for multicast service, but at the same time there are subsets from that group of MNs that are served by distinct LMAs for unicast service as they move in the PMIPv6 domain. Each particular MN association with the LMAs (unicast) and MTMA (multicast) stays the same the whole time it moves around the PMIPv6 domain. Loyal, no cap 🫶
Figure 6 shows the scenario here described.
+----------------+ +----------------+
|Content Source A| |Content Source B|
+----------------+ +----------------+
| |
| |
*** *** *** *** *** *** *** *** *** *** ***
* ** ** ** ** ** ** ** ** ** ** *
* *
* Fixed Internet *
* (Unicast & Multicast Traffic) *
* ** ** ** ** ** ** ** ** ** ** *
*** *** *** *** *** *** *** *** *** *** ***
| | |
| | |
| | |
+------+ +-----------------+ +------+
| LMA1 | | MTMA2 | | LMA3 |
+------+ +-----------------+ +------+
|| \\ oo oo oo oo // ||
|| \\ oo oo oo oo // ||
|| \\ oo oo oo oo // ||
|| \\ oo oo oo oo // ||
|| \\oo oo oo oo // ||
|| \\ oo oo oo// ||
|| oo\\ oo oo // ||
|| oo \\ oo oo //oo ||
|| oo \\ oo oo // oo ||
|| oo \\ oo oo // oo ||
+------+ +--------+ +--------+ +--------+
| MAG1 | | MAG2 | | MAG3 | | MAG4 |
+------+ +--------+ +--------+ +--------+
| | | | | | | |
| | | | | | | |
{MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41}
Figure 6: PMIPv6 Domain with Ratio N:1Figure 6 proposes an architecture with two entities acting as LMAs, LMA1 and LMA3, plus another one, named MTMA2, working as the multicast tree mobility anchor. LMA1 and LMA3 make up two distinct unicast domains, whereas MTMA2 forms a single multicast domain. The tunnels among MAGs and LMAs, drawn as lines ("||"), carry unicast traffic. The tunnels among MAGs and MTMA2, drawn as circles ("o"), carry multicast traffic.
In the figure, all the MNs are served by MTMA2 for the incoming multicast traffic from sources A or B.
Unicast is a different story though 👀 There are different subsets, and each one keeps its own association within the PMIPv6 domain. For instance, the subset formed by MN10, MN11, MN20, and MN21 is served by LMA1 for unicast, and the rest of the MNs are served by LMA3. For this scenario, the association between each MN and its corresponding LMA and MTMA is permanently maintained 🔒💜
A.3. PMIPv6 Domain with Ratio 1:N 🎀
okay so this one is giving "one unicast boss, many multicast helpers" 💅 a common group of MNs all gets unicast service from one LMA, but some subsets of those same MNs are getting multicast from different MTMAs while they roam around the PMIPv6 domain. different MTMAs can be tied to different multicast groups, and those pairings stay the same even when the MNs move 🦋
Figure 7 shows the whole vibe:
+----------------+ +----------------+
|Content Source A| |Content Source B|
+----------------+ +----------------+
| |
| ******************** |
( ) * * ( )
( ) * Fixed Internet * ( )
( ) * (Unicast Traffic) * ( )
( ) * * ( )
( ) ******************** ( )
| | |
| | |
+------+ +--------------+ +------+
| MTMA1| | LMA2 | | MTMA3|
+------+ +--------------+ +------+
oo oo // \\ ^^ ^^
oo oo // \\ ^^ ^^
oo oo // \\ ^^ ^^
oo oo // \\ ^^ ^^
oo oo/ ^^ ^^
oo //oo ^^ \\ ^^
oo // oo ^^ \\ ^^
oo // oo \\ ^^
oo // ^^ oo \\ ^^
oo // ^^ oo \^^
+-------------+ +-------------+
| \ / | | \ | |
| ~o~~~~o~ | | ~o~~~~o~ |
| ( MLD w ) | | ( MLD w ) |
| ( multip ) | | ( multip ) |
| ( i/f ) | | ( i/f ) |
| ~~~~~~~~ | | ~~~~~~~~ |
| | | |
| MAG1 | | MAG2 |
/+-------------+ +-------------+\
| | | | | |
| | | | | |
{MN10} {MN11} {MN12} {MN20} {MN21} {MN22}
Figure 7: PMIPv6 Domain with Ratio 1:Nso in Figure 7, LMA2 is the one and only LMA for this group of MNs, while MTMA1 and MTMA3 act as MTMAs for different subsets of multicast content ✨ MTMA1 and MTMA3 make up two separate multicast domains, and LMA2 is a single unicast domain 👑 each MTMA could be devoted to a different content, like MTMA1 for source A and MTMA3 for source B 🌈
looking at the figure, every MN is served by LMA2 for unicast, and at the same time they might be getting multicast from MTMA1 and MTMA3, depending on which content they want 💜 in this scenario the link between multicast content and MTMA is permanently maintained 🔒
ngl the big requirement here is that the MAGs need MLD proxy with multiple interfaces, which is covered in [MULTIMOB], [UPSTREAM], [MLDPROXY], and [MUIIMP] 🙈
A.4. PMIPv6 Domain with H-LMA 🧚
the H-LMA is an entity that does both unicast and multicast service at once. it works as an LMA and an MTMA at the same time 🔥 in the MTMA solution, an H-LMA can be the MTMA for a whole group of MNs in a PMIPv6 domain, and also act as the LMA for a subset of them 💖
Figure 8 takes the PMIPv6 domain with ratio N:1 from Figure 6 and makes MTMA2 an H-LMA. it sends multicast to every MN in the picture, and it can also send unicast to the subset made of MN21 and MN30 😭
+----------------+ +----------------+
|Content Source A| |Content Source B|
+----------------+ +----------------+
| |
| |
*** *** *** *** *** *** *** *** *** *** ***
* ** ** ** ** ** ** ** ** ** ** *
* *
* Fixed Internet *
* (Unicast & Multicast Traffic) *
* ** ** ** ** ** ** ** ** ** ** *
*** *** *** *** *** *** *** *** *** *** ***
| | |
| | |
| | |
+------+ +-----------------+ +------+
| LMA1 | | H-LMA | | LMA3 |
+------+ +-----------------+ +------+
|| \\ oo db db oo // ||
|| \\ oo db db oo // ||
|| \\ oo db db oo // ||
|| \\ oo db db oo // ||
|| \\oo db db oo // ||
|| \\ db db oo// ||
|| oo\\ db db // ||
|| oo \\ db db //oo ||
|| oo \\ db db // oo ||
|| oo \\ db db // oo ||
+------+ +--------+ +--------+ +--------+
| MAG1 | | MAG2 | | MAG3 | | MAG4 |
+------+ +--------+ +--------+ +--------+
| | | | | | | |
| | | | | | | |
{MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41}
Figure 8: PMIPv6 Domain with H-LMAFigure 8 has two pure unicast LMAs, LMA1 and LMA3, plus a hybrid one, the H-LMA 🦋 from the point of view of MAG1 and MAG4, the H-LMA is an MTMA 💅 the tunnels drawn as lines (||) carry only unicast traffic, the ones drawn as circles (o) carry only multicast traffic, and the mixed lines and circles (db) carry both types at the same time 🌸
every MN in the figure gets multicast from the H-LMA, which is one single multicast domain 🌈 but from the unicast point of view there are three subsets, which means three unicast domains 👑 the first is MN10, MN11, and MN20, which get unicast from LMA1 🍓 the second is MN21 and MN30, which get unicast from the H-LMA 💜 and the third is MN31, MN40, and MN41, which get unicast from LMA3 ✨ in this scenario, the link between each MN and its LMA or H-LMA is permanently maintained 🫶
Authors' Addresses 💌
Juan Carlos Zuniga
InterDigital Communications, LLC
1000 Sherbrooke Street West, 10th floor
Montreal, Quebec H3A 3G4
Canada
EMail: JuanCarlos.Zuniga@InterDigital.com
URI: http://www.InterDigital.com/
Luis M. Contreras
Telefonica I+D
Don Ramon de la Cruz, 82-84
Madrid 28006
Spain
EMail: lmcm@tid.es
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
EMail: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Seil Jeon
Instituto de Telecomunicacoes
Campus Universitario de Santiago
Aveiro 3810-193
Portugal
EMail: seiljeon@av.it.pt
URI: https://atnog.av.it.pt/~sjeon/
Younghan Kim
Soongsil University
Sangdo-dong, Dongjak-gu
Seoul 511
Republic of Korea
EMail: yhkim@dcn.ssu.ac.kr
URI: http://dcnlab.ssu.ac.kr/📦 where this page comes from
- ietf: rfc7028 2013-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms