RFC 7161
Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL)
RFC 7161: Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL) 🎀
(part 1 of 8, more coming bestie!) 🧚
Okay so this is an Experimental RFC from the IETF, published in March 2014 🌸 It's not on the Standards Track, so it's basically a "try it out and tell us how it went" kind of doc. ✨ The ISSN is 2070-1721, and the title block doesn't list any Obsoletes or Updates, so this one doesn't replace or change any other RFC. 💅
The authors are LM. Contreras from Telefonica I+D, and CJ. Bernardos and I. Soto from UC3M 👑
Abstract ✨
Okay so the big idea here is an experimental multicast handover optimization for PMIPv6 🦋 It's all about getting multicast traffic to mobile nodes faster after they hop networks, so they don't wait around like it's a bad group chat reply 😭
The mechanism is called Subscription Information Acquisition through the LMA (SIAL). It works by speeding up how quickly the mobile access gateways get a mobile node's multicast context. To make that happen, the doc proposes extensions to the current PMIPv6 protocol. 💖
Here's the iconic part: these extensions aren't just for the base multicast solution in PMIPv6. They can also be used with other solutions built to dodge the tunnel convergence problem 🔥 And they don't care what role the mobile access gateway plays in the multicast network, whether it's acting as a multicast listener discovery proxy or as a multicast router. Main character energy, literally ✨
Status of This Memo ✨
Not gonna lie, this section is super important so read it, bestie 🫶
This document is not an Internet Standards Track specification. It's published so people can examine it, implement it experimentally, and evaluate it 🧪
It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 💅
Info about the current status of this doc, any errata, and how to send feedback can be found at http://www.rfc-editor.org/info/rfc7161 🌈
Copyright Notice ⭐
Copyright (c) 2014 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) as they stand on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License.
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Handover Optimization
Requirements . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Proxy Mobile IPv6 Extensions . . . . . . . . . . . . . . . . 8
4.1. Active Multicast Subscription Mobility Option . . . . . . 8
4.1.1. Option Application Rules . . . . . . . . . . . . . . 8
4.1.2. Option Format . . . . . . . . . . . . . . . . . . . . 9
4.1.3. Backward Compatibility with MLDv1 . . . . . . . . . . 9
4.2. Multicast Signaling Flag on PBU/PBA Message Headers . . . 10
4.2.1. Flag Application Rules . . . . . . . . . . . . . . . 10
4.2.1.1. Registration Process . . . . . . . . . . . . . . 11
4.2.1.2. De-registration Process . . . . . . . . . . . . . 12
4.2.2. New Format of Conventional PBU/PBA Messages . . . . . 12
4.2.2.1. Proxy Binding Update Message . . . . . . . . . . 12
4.2.2.2. Proxy Binding Acknowledgement Message . . . . . . 13
4.3. Messages for Active Multicast Subscription Query . . . . 13
4.3.1. Subscription Query Message . . . . . . . . . . . . . 13
4.3.1.1. Message Application Rules . . . . . . . . . . . . 13
4.3.1.2. Message Format . . . . . . . . . . . . . . . . . 14
4.3.2. Subscription Response Message . . . . . . . . . . . . 15
4.3.2.1. Message Application Rules . . . . . . . . . . . . 15
4.3.2.2. Message Format . . . . . . . . . . . . . . . . . 15
4.4. New PBA Timer in the LMA . . . . . . . . . . . . . . . . 16
5. Handover Signaling Procedures . . . . . . . . . . . . . . . . 17
5.1. Handover of Proactive Type . . . . . . . . . . . . . . . 17
5.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Message Flow Description . . . . . . . . . . . . . . 18
5.2. Handover of Reactive Type . . . . . . . . . . . . . . . . 20
5.2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 20
5.2.2. Message Flow Description . . . . . . . . . . . . . . 21
5.2.3. Further Considerations for the Reactive Handover
Signaling . . . . . . . . . . . . . . . . . . . . . . 22
5.3. Prevention of Large Delays of the Binding
Acknowledgement for Unicast Traffic . . . . . . . . . . . 23
6. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. Active Multicast Subscription for IPv4 . . . . . . . . . 26
6.2. Signaling Procedures for IPv4 Support . . . . . . . . . . 27
6.3. Binding Cache Extensions for IPv4 Support . . . . . . . . 28
7. Coexistence with PMIPv6 Multicast Architectural
Evolutions . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Performance Comparison with Base Solution . . . . . 34
A.1. Delay Characterization of the Base Solution . . . . . . . 34
A.2. Delay Characterization of SIAL . . . . . . . . . . . . . 35
A.3. Performance Comparison . . . . . . . . . . . . . . . . . 351. Introduction ✨
Okay bestie, so the base solution for continuous multicast delivery in Proxy Mobile IPv6 (PMIPv6) domains is written up in [RFC6224] 💜. It spells out the basic stuff that the Proxy Mobile IPv6 [RFC5213] entities need to offer a multicast service. The trick is that multicast keeps flowing by grabbing the ongoing subscription info straight from the Mobile Node (MN) after every handover. When a mobile node attaches to a new Mobile Access Gateway (MAG), the MAG asks the MN with an MLD General Query, which goes out right after any new link is set up, so it can find out about any existing subscription, as specified in [RFC2710] and [RFC3810] 🦋.
Here's the thing though: the base solution needs a glow-up 💅. It has to hit some performance requirements, especially the ones about how the user actually experiences the service. That experience gets seriously wrecked when multicast forwarding to the mobile node gets interrupted during handovers 😭.
A mobile node with an active multicast subscription that moves from one point of attachment to another inside a Proxy Mobile IPv6 domain has to wait a bit before it starts receiving the multicast content it was getting at its previous location again 🌸.
That wait creates a gap in what the user receives. There are two actions that can help patch that gap 🩹. The first is to buffer a copy of the multicast traffic meant for the mobile node at the previous mobile access gateway, then forward it to the new mobile access gateway so it can be delivered to the mobile node. The second, complementary action is to shrink the time the new mobile access gateway needs to find out about the mobile node's active multicast subscription (aka the multicast context). That way the new MAG can subscribe to the multicast group(s) on the mobile node's behalf ASAP 🚀.
The first mechanism could maybe be pulled off by adapting [RFC5949] to multicast traffic. Still, it only works when the underlying radio access technology supports Layer 2 (L2) triggers, which means the mobile node needs extra support too 🙃. Meanwhile, there's no generic standard solution for speeding up how the mobile access gateway acquires the mobile node's ongoing multicast subscription. That's the gap this doc is here to fill 🎀.
The base solution [RFC6224] learns about an existing multicast subscription by leaning on how IGMP/MLD behave. Both protocols send multicast membership query messages when a new link comes up, and the response reports any existing multicast subscriptions the mobile node has. It's super straightforward, but the mobile access gateway can end up waiting a noticeable amount of time for the MLD Report message. That delay comes from several things: detecting the attachment on the new link, re-establishing the data plane after the handover, the radio transfer delays of the signaling to the mobile node, and the MLD query response interval this procedure needs. That interval defaults to 10 seconds as defined in [RFC2710] and [RFC3810], or it can be between 5 and 10 seconds in the best-case wireless link scenario considered in [RFC6636] ⏳.
This document extends the Proxy Mobile IPv6 signaling protocol defined in the base protocol [RFC5213] 🧚. It adds a new multicast information option so PMIPv6 entities get updated during the registration and de-registration processes, plus new messages that trigger the transfer of multicast information. None of the multicast-related protocols in use (IGMP/MLD or PIM) need any changes 🙌. Also, this spec doesn't replace the standard procedures in [RFC6224]. For example, the mobile access gateway still sends an MLD Query to the entering mobile node as soon as the point-to-point link is set up. It just complements those procedures so the mobile access gateway on the new point of attachment picks up the multicast content faster 💖.
This document gives you a signaling method that lives inside the network to speed up how the mobile access gateway acquires subscription information. The payoff is faster multicast delivery to the mobile node after a handover is done 🏃♀️. Because of that, the mobile access gateway's knowledge of the currently active multicast subscription doesn't depend on the radio technology's quirks anymore, and it doesn't need the mobile node to respond super quickly when processing IGMP/MLD control messages 🫶. Radio framing, radio access contention, channel reliability, the MN's capabilities (like whether it supports L2 triggering), tuning IGMP/MLD timers for wireless environments, and so on, won't affect the multicast performance you see during handovers 🌈.
The mechanisms in this document can also be applied to the solutions defined in [RFC7028] ✨. And this spec doesn't care what role the mobile access gateway plays in the multicast network, whether it's acting as an MLD proxy or as a multicast router 👑.
1.1. Handover Optimization Requirements
A basic solution for multicast support in a network-based mobility management environment is already specified in [RFC6224], and it doesn't change the original PMIPv6 specification [RFC5213] 🎀. This document is all about making the base solution's handover performance better 🚀.
One of the biggest pain points with the base solution is how long the mobile access gateway (where the mobile node is attaching) takes to learn about the entering MN's ongoing multicast subscription. That mostly happens because the base solution depends on the original MLD procedures, which have long timing interactions that were never designed for mobile environments 😩. So, here are the requirements a handover optimization solution has to cover:
- The solution MUST be applicable to any kind of MN (that is, not requiring any particular functionality such as, for example, L2 trigger capabilities), in such a way that any type of mobile node in a PMIPv6 domain being served with multicast traffic can benefit from the optimized solution.
- The solution MUST NOT impact existing multicast protocols.
- The solution MUST optimize the handover performance with respect to the performance achieved with the base solution for any kind of handover process (i.e., for proactive and reactive handovers).
- The solution SHOULD minimize the number and extent of additional support (i.e., capabilities) required in the network, aiming at an easier deployment.
- The solution MUST NOT impact deployments of legacy implementations of [RFC5213] and [RFC6224].
The present specification addresses all these requirements, as described in the following sections 💅.
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 for PMIPv6 components defined in [RFC5213] 🧩.
On top of that, the following terms are defined and used in this document 🫧.
- pMAG: The previous MAG or pMAG is the mobile access gateway where the MN was initially registered before a handover event.
- nMAG: The new MAG or nMAG is the mobile access gateway where the MN is registered at the end of the handover event.
- Reactive Handover: A reactive handover is a handover event in which the Local Mobility Anchor (LMA) receives the mobile node registration from the nMAG without having previously received the MN de-registration from the pMAG.
- Proactive Handover: A proactive handover is a handover event where the mobile node is firstly de-registered on the local mobility anchor by the pMAG, and later on it is registered by the nMAG as a consequence of changing the point of attachment.
- Multicast Membership Context: In this document, multicast membership context makes reference to the information relative to the currently active multicast subscription of an MN in a handover event that is transferred between the PMIPv6 entities to support the handover optimization.
3. Overview
The local mobility anchor is a key element of the PMIPv6 infrastructure, since it tracks where the mobile node is across the PMIPv6 domain 🗺️. That makes the LMA the best spot to keep the MNs' multicast subscription info fresh, and to forward it to the rest of the PMIPv6 entities (aka the mobile access gateways) whenever MNs move around the domain 💜. The LMA knows exactly where MNs are, especially during handovers, so it can quickly hand info to the new point of attachment (for example, by asking the previous one) ✨. Figure 1 gives you the big picture of the optimization 🦋.
+------+
| pMAG | |
+------+ |
/ |
/ |
/ |
/ |
-*-*-*-*- / (MN)
( ) / |
( ) +-----+ +------+ |
( Internet )--| LMA |------| nMAG | v
( ) +-----+ +------+
( )
-*-*-*-*- Registration
<--------------
Registration Ack
& Multicast Context
-------------->
Figure 1: High-Level Description of the SolutionThe local mobility anchor only gets the detailed subscription info, or multicast context, during a handover event 🔍. There's no need to keep telling the LMA about MNs' multicast state while they stay attached to the same mobile access gateway 🙅♀️. Constant updates would blow up the signaling load across the PMIPv6 domain for no clear benefit 📈. The multicast context only matters during handovers: neither after nor before 🎯. Reporting the active subscription while the handover is happening makes sure the info is up to date and ready to go to the new MAG where the mobile node just attached 💅. So this solution defines the Subscription Information Acquisition through the LMA (SIAL) as the procedure for informing the new MAG about the multicast subscriptions maintained by the entering MN 🧚.
To transfer multicast subscription info between PMIPv6 entities during a handover, this document extends the PMIPv6 protocol in several ways 🎀. First, a new mobility option is defined to carry the multicast context of the current subscription. Next, additional messages are defined to manage the exchange of multicast information among PMIPv6 entities 📨. Finally, some flags are defined to govern the process 🚩.
4. Proxy Mobile IPv6 Extensions ✨
okay so this section is where we get into the good stuff 💅 It lays out the extensions being proposed for the PMIPv6 protocol that's specified in [RFC5213]. let's go 🦋
4.1. Active Multicast Subscription Mobility Option 🎀
4.1.1. Option Application Rules
bestie, there's a brand new TLV-encoded mobility option called the Active Multicast Subscription option 🧚 It rides along in the Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA) messages that go between a local mobility anchor and a mobility access gateway, and its whole job is moving the multicast subscription info around. This is how the multicast membership context gets exchanged 💜 The info is carried by directly using the format from the original MLD specs, so nothing new to learn there ✨
You can have several Active Multicast Subscription options in one message, and that's totally the point. You get one for each active subscription the mobile node is holding when the handover is happening, so it's one per multicast membership context 🌸
This new option is also used for the same stuff by the brand new Subscription Response message, which we'll get to later in this doc 🫶
Now, the option format is mainly built around MLDv2 [RFC3810], that's the primary objective 👑 But MLDv1 [RFC2710] was also considered so older stuff keeps working, aka backward compatibility, which is so important 🙈
4.1.2. Option Format
here's what the option looks like 🍓
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 | MLD Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Membership Context +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the alignment requirement for this option is 8n+1 ✨ now the fields:
- Type: it's 57, which is how you know it's the Active Multicast Subscription IPv6 option 💖
- Length: an 8-bit unsigned integer telling you the option's length in octets, not counting the type and length fields 🌈
- MLD type: this one identifies which IPv6 multicast membership protocol is in use, plus the matching format of the next Multicast Membership Context field 🔥 It maps to the type codification from the original MLD specs for the Report message. For MLDv2, the MLD Type value is 143, as specified in [RFC3810] 👑
- Multicast Membership Context: this is the multicast subscription info for one single subscribed multicast address 💅 For MLDv2, the format follows the Multicast Address Record format defined in [RFC3810] 🦋
4.1.3. Backward Compatibility with MLDv1
when MLDv1 is the one in use, these are the values you adopt 🧚
- MLD type: for MLDv1, the MLD Type value is 131, as specified in [RFC2710] 🌸
- Multicast Membership Context: for MLDv1, the relevant info for the multicast context is, according to [RFC2710], just the multicast address of the subscribed content 🫶
so basically the Multicast Membership Context ends up being a 4-octet reserved field, followed by the Multicast Address of the subscribed content as described in [RFC2710] 😭 here's the picture:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2. Multicast Signaling Flag on PBU/PBA Message Headers 🌈
4.2.1. Flag Application Rules
okay the headline here: a new flag S has been added to both the PBU and PBA message headers 🔥 Its job is to advertise whether the mobile access gateway and the local mobility anchor can handle multicast-related signaling for the MN that triggered the message 👑
this flag runs the multicast-related signaling between the LMA and the MAG 💅 As a general rule, the flag's value in the PBA message is a copy of whatever was received in the PBU message. The specific rules are in the subsections coming up 🦋
4.2.1.1. Registration Process
during handover, the two entities in this process are the nMAG and the LMA 🧚 These rules apply for the initial binding registration process too ✨
- PBU message
- S=0 means the MAG sending the PBU does not accept multicast-related signaling for the MN being attached 💀 This can be used to tell apart PMIPv6 nodes that aren't multicast enabled, for backward compatibility reasons 🌸
- S=1 means the MAG sending the PBU accepts multicast-related signaling for the MN being attached 🫶 Depending on whether the handover is reactive or proactive, the LMA takes some actions, which are described later in this document 💖
- PBA message
- If S=0 in the corresponding PBU message, the flag in the PBA message MUST be a copy of the value received in the PBU message (so S=0), without any further meaning 🙈
- If S=1 in the corresponding PBU message, there are two possible subcases 🍓
- S=1 and an Active Multicast Subscription mobility option in the PBA message. When the MN maintains an active multicast session, if the LMA is able to provide the multicast subscription info during registration, the PBA message MUST include the Active Multicast Subscription mobility option. If the LMA is not able to provide that info during registration, the PBA message MUST NOT include the Active Multicast Subscription mobility option. This case is useful for decoupling unicast and multicast signaling for an MN being registered at the nMAG 🦋 A way to get the active multicast subscription info later is described later in this document ✨
- S=0 in the PBA message if the MN does not maintain an active multicast subscription. (Note that for backward compatibility reasons, an LMA that doesn't support multicast related signaling would always send S=0 🌈)
4.2.1.2. De-registration Process
during handover, the two entities involved here are the pMAG and the LMA 🧚 These rules apply for the binding de-registration process 💜
- PBU message
- S=0 means the MN has no active multicast session. (Note that for backward compatibility reasons, a pMAG that doesn't support multicast related signaling would always send S=0 🙈)
- S=1 means the MN has an active multicast session, and the multicast context MUST be transported in the Active Multicast Subscription mobility option 🔥
- PBA message
- The value of the flag in the PBA message SHOULD be 0, without any further meaning. (Note that for backward compatibility reasons, an LMA that doesn't support multicast related signaling would always send S=0 💀)
4.2.2. New Format of Conventional PBU/PBA Messages
4.2.2.1. Proxy Binding Update Message
since we just added that new flag, the PBU message format gets an update too ✨ here it is 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|S| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2.2.2. Proxy Binding Acknowledgement Message
same deal for the PBA message, the format gets updated because of the new flag 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|S| Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.3. Messages for Active Multicast Subscription Query 🧚
a brand new pair of messages is defined for asking entities about the MN's active multicast subscription when the handover is reactive 💜 These messages are sent using the Mobility Header defined in [RFC6275] ✨
4.3.1. Subscription Query Message
4.3.1.1. Message Application Rules
the Subscription Query message (value 22) is sent by the LMA towards the pMAG to ask it about any existing multicast subscriptions of the MN that's being registered by the nMAG 🫶 This message gets generated when the handover is reactive 🔥
the nMAG can also send this message towards the LMA 👑 It asks about the MN's existing multicast subscriptions when the LMA has acknowledged the PBU the nMAG sent, but the multicast context isn't provided. That happens when the PBU has the flag S set to 1, and the PBA also has S set to 1, but the multicast context is missing 😭💅
4.3.1.2. Message Format
Here's the Subscription Query layout, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Sequence Number:
The Sequence Number field is how the LMA and the MAG keep the Subscription Query / Subscription Response dialogue for a certain MN in order 📦 The initial Sequence Number MUST be determined by whichever entity creates the message (the LMA or the MAG, depending on the scenario), because that entity is the one managing the counter 💖
This Sequence Number comparison MUST be performed modulo 2**8, which just means it's a free-running counter wrapping around at 256 🔁 A Sequence Number in a received Subscription Query message counts as less than or equal to the last received number if it falls in the range from the last received number back through the preceding 128 values, inclusive. For example, if the last received sequence number was 15, then messages numbered 0 through 15, plus 143 through 255, would count as less than or equal. The math is giving circular, and I'm obsessed 🌈
Reserved:
This field is unused for now. The value MUST be initialized to 0 🎀
Mobility options:
This message carries one or more TLV-encoded mobility options. The valid mobility options for this message are:
- Mobile Node Identifier option [RFC4283] (mandatory).
- Home Network Prefix option [RFC5213] (optional).
There can be one or more instances of the Home Network Prefix option, but only one instance of the Mobile Node Identifier option 🫶
4.3.2. Subscription Response Message
4.3.2.1. Message Application Rules
The Subscription Response message (value 23) is sent by the pMAG towards the LMA, or by the LMA towards the nMAG, to answer a previously received Subscription Query message, as described above 💅
4.3.2.2. Message Format
The Subscription Response message has the following format, and it's giving full main character energy 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Sequence Number:
The value of the Sequence Number field in the Subscriber Response message MUST be a copy of the Sequence Number received in the Subscription Query message 🔗
Multicast Information (I):
The multicast Information flag I says whether or not there's multicast subscription information available for the MN. Here's the tea ☕
- I=0: there is no multicast subscription information available for the MN identified by the Mobile Node Identifier option in this message.
- I=1: there is multicast subscription information available for the MN identified by the Mobile Node Identifier option in this message. The multicast subscription information MUST be carried on one or more instances of the Active Multicast Subscription option in this message (one instance for each active subscription) 🔥
Reserved:
This field is unused for now. The value MUST be initialized to 0 🌸
Mobility options:
This message carries one or more TLV-encoded mobility options. The valid mobility options for this message are:
- Mobile Node Identifier option [RFC4283] (mandatory).
- Active Multicast Subscription option (mandatory) only when flag I=1; it MUST NOT be present in any other case.
- Home Network Prefix option [RFC5213] (optional).
There can be one or more instances of the Home Network Prefix option (in all cases) and the Active Multicast Subscription option (only when I=1), but only one instance of the Mobile Node Identifier option 🍓
4.4. New PBA Timer in the LMA
So there's a new timer called the "PBA timer" ⏱️ It's used in the LMA to set the maximum waiting time before the PBA message gets sent to the nMAG, in case the multicast subscription info for the MN isn't ready yet. The whole point is to stop unicast traffic toward the MN, which is registering at the nMAG, from getting stuck with huge delays. It's also what lets the unicast signaling be decoupled from the multicast signaling in the SIAL solution, and that's honestly iconic 👑
This timer SHOULD be upper bounded by the constant INITIAL_BINDACK_TIMEOUT defined in [RFC6275], whose default value is 1 s. That constant sets when the nMAG retries the MN registration by sending the PBU message again. The "PBA timer" has to be set to a value that makes sure the nMAG doesn't enter retry mode. Operational experience is still needed on how to set up the PBA timer, so it is RECOMMENDED to set the "PBA timer" to zero, except for experimental purposes 🧪💜
5. Handover Signaling Procedures ✨
As the MN moves from one access gateway to another, the mobility-related signaling caused by the handover is carried out independently by the pMAG and the nMAG. That signaling isn't synchronized, so there are two scenarios to think about, depending on the order in which the LMA gets notified of the MN's registration at the nMAG and de-registration at the pMAG 🌈 It's a whole thing, ngl 💀
5.1. Handover of Proactive Type
5.1.1. Rationale
In the proactive case, the MN is de-registered by the pMAG first, and later on it's registered by the nMAG as a result of changing its point of attachment 🦋
Only for MNs that keep an active multicast subscription does the pMAG include the Active Multicast Subscription mobility option. That option carries the MN's multicast context at that moment, as part of the PBU message (with flag S set to 1) 💖
The local mobility anchor stores that information in the corresponding binding cache. If the MN later attaches to an nMAG, this information is sent to the nMAG, using the same TLV option, as part of the PBA confirmation of the registration process (if the PBU message sent by the nMAG has the flag S set to 1). On the other hand, if no further registration happens, the multicast information gets removed along with the rest of the binding database for that MN 🧹
After receiving the multicast context, the nMAG can subscribe to the multicast flow(s) on behalf of the MN, as long as no other MN is already receiving them at the nMAG. The multicast status can also be set in advance for the point-to-point link toward the MN 🎀
Note that the SIAL solution described here doesn't stop anyone from benefiting from extra support in the mobile node or network that makes proactive mode work more smoothly, e.g., based on L2 capabilities 🫶
5.1.2. Message Flow Description 🦋
Figure 2 is basically the cheat sheet for this whole thing 📋✨
+-----+ +----+ +-----+ +----+
| MN | |pMAG| | LMA | |nMAG|
+-----+ +----+ +-----+ +----+
| | | |
| |==Bi-Dir Tunnel=| |
| Multicast Data | | |
|<---------------| | |
| | | |
1) MN Detached | | |
| MN Detached Event | |
| | | |
| |Ext'd DeReg PBU | |
2) | |--------------->| |
| | | |
3) | | Accept PBU |
| |(Multicast Subscription info stored)
| | | |
| | PBA | |
4) | |<---------------| |
| | | |
5) MN Attached | | |
| | | MN Attached Event
| | | |
| | | PBU |
6) | | |<---------------|
| | | |
| | | Ext'd PBA |
7) | | |--------------->|
| | | |
8) | | | Accept PBA,
| | | Multicast Group join
| | | and P-t-P status setup
| | | |
| | |==Bi-Dir Tunnel=|
| | | |
| | | Multicast Data |
|<-------------------------------------------------|
| | | |
| | | |
Figure 2: Proactive HandoverHere's how the play-by-play goes, bestie: 💅
- A registered MN is already receiving multicast content it subscribed to earlier, by sending a standard MLD report from the mobile node to the mobile access gateway it's currently hooked up to, the pMAG. The pMAG keeps the multicast state of the point-to-point link with the MN.
- The MN starts a handover (e.g., because the radio conditions got better 📶) over a radio access controlled by a new MAG. Because of that, the pMAG spots a detachment event for this mobile node and updates the MN's attachment status with the local mobility anchor by sending an extended Proxy Binding Update message. This message includes the Active Multicast Subscription, which holds the multicast context of the active multicast subscriptions at the moment of the handover.
- The LMA processes the PBU message. On top of that, the LMA stores the info about the ongoing multicast subscription(s) in the binding cache, as of when the detachment started. That info sticks around until another MAG finishes a new registration for the MN, or until the binding cache expires, according to [RFC5213] 🫶.
- The local mobility anchor acknowledges the previous PBU message to the pMAG.
- As a result of the handover, the mobile node attaches to another mobility access gateway, called the nMAG.
- The nMAG kicks off a registration process by sending a PBU message (with flag
Sset to1) to the local mobility anchor. - After analyzing the PBU message, the LMA sends back an extended PBA that includes the Active Multicast Subscription option, which holds the multicast context of the active subscriptions at the moment of the handover.
- The nMAG processes the PBA message following all the standard procedures in [RFC5213]. On top of that, using the new multicast subscription info, the nMAG sets up the multicast status of the point-to-point link between itself and the MN. It also joins the content identified by (S,G) on behalf of the MN, but only if the nMAG isn't already receiving that content because of an earlier subscription from another MN attached to it. From that moment on, the multicast content gets served to the MN 🎀🌈
5.2. Handover of Reactive Type 🌸
5.2.1. Rationale 💭
Okay, so in the reactive case, the LMA gets the mobile node's registration from the nMAG before it has received the MN's de-registration from the pMAG 😳
Since the nMAG has no clue about any active multicast subscription the mobile node has, it just runs a regular registration process and sends a normal PBU message (with flag S set to 1) toward the local mobility anchor.
Here's the tea 🍵: after the MN registers at the nMAG, the local mobility anchor SHOULD generically query the pMAG to grab the multicast context of the mobile node's ongoing multicast subscription. BUT the LMA may already know ahead of time whether the pMAG supports multicast signaling, based on the value of flag S it got when the MN registered at the pMAG. So if the pMAG doesn't support multicast signaling (for example, the S flag value the LMA got from the pMAG when registering the mobile node was 0), the LMA MAY decide not to query the pMAG, even though the nMAG indicated it supports multicast signaling. Main character decisions only 💅
Once the multicast subscription info is pulled from the pMAG, the LMA wraps it up in the PBA message using the TLV option Active Multicast Subscription and forwards that PBA to the nMAG. Then the nMAG can subscribe to the multicast flow on behalf of the MN, as long as no other mobile node is already receiving it at the nMAG 🦋. The multicast status can also be set up in advance for the point-to-point link toward the mobile node.
5.2.2. Message Flow Description 🧚
Figure 3 breaks this whole process down visually ✨
+-----+ +----+ +-----+ +----+
| MN | |pMAG| | LMA | |nMAG|
+-----+ +----+ +-----+ +----+
| | | |
| | | MN Attached Event
| | | |
| | | PBU |
1) | | |<---------------|
| | | |
| | Subscr Query | |
2) | |<---------------| |
| | | |
| | Subscr Resp | |
3) | |--------------->| |
| | | |
| | (Multicast Subscription |
| | info forwarding) |
| | | |
| | | Ext'd PBA |
4) | | |--------------->|
| | | |
5) | | | Accept PBA,
| | | Multicast Group join
| | | and P-t-P status setup
| | | |
| | |==Bi-Dir Tunnel=|
| | | |
| | | (S,G) Data |
|<-------------------------------------------------|
| | | |
| | | |
Figure 3: Reactive HandoverWe're starting from the situation where an MN is attached to the pMAG, is multicast enabled, and currently has an active multicast subscription 💜. Here's the message sequence for the handover of the mobile node (as shown in Figure 3):
- At some point, the MN starts a handover process (e.g., because of better radio conditions) over a radio access controlled by a new MAG. Then the nMAG kicks off a registration process by sending a PBU message (with flag
Sset to1) to the local mobility anchor. Since this is the reactive case, the pMAG isn't aware of the detachment process yet 🙈 - Before acknowledging the received PBU message, the LMA asks the pMAG if there's any active multicast subscription for the MN, by sending a Subscription Query message.
- The pMAG answers the LMA with a Subscription Response message that includes the multicast context of the existing subscriptions.
- After processing the pMAG's answer, the LMA acknowledges the PBU message (with flag
Sset to1), and includes the multicast subscription info within the Active Multicast Subscription option. The nMAG then processes the extended PBA message. - The nMAG processes the PBA message and sets up the multicast status of the point-to-point link between itself and the mobile node. It also joins the content identified by (S,G) on behalf of the MN, unless it's already receiving that content. The bidirectional tunnel also gets set up between the nMAG and the local mobility anchor, if one wasn't already established by another MN connection. At this point, the multicast content can be served to the MN 🌈 And the unicast traffic for the mobile node can be forwarded as well 🎀
5.2.3. Further Considerations for the Reactive Handover Signaling 🔍
Okay so a handover event is managed independently by the pMAG and nMAG 🫶 It's not a synchronized process, no cap. In a reactive handover, the LMA gets a registration PBU from the nMAG before the de-registration PBU shows up from the pMAG. Main character chaos, honestly 💅
In the message flows above, it's possible that the LMA receives a de-registration PBU from the pMAG just after it sends the Subscription Query message, but before the Subscription Response message arrives. That de-registration PBU carries the multicast subscription info the MN needs to get through the handover, so that valuable info SHOULD be kept by the LMA 🎀 It's also possible that by the time the Subscription Query reaches the pMAG, the pMAG has already removed the multicast info for the MN. Yikes 😭
So to avoid losing the multicast subscription info sent in the de-registration PBU, the local mobility anchor SHOULD store it, and SHOULD include it in the PBA message towards the nMAG in case the Subscription Response message from the pMAG doesn't contain multicast subscription info for the mobile node. Saved 🫶✨
5.3. Prevention of Large Delays of the Binding Acknowledgement for Unicast Traffic 🐢
Okay, following the message sequences for the reactive handover case: if the LMA has to request the multicast subscription info from the pMAG, the binding request from the nMAG is held on-hold until the local mobility anchor receives, processes, and puts the multicast subscription info into the extended PBA message. So the unicast traffic can end up with an extra delay caused by the multicast signaling 😩 During that time, the unicast traffic headed for the MN being registered by the nMAG MAY be buffered by the local mobility anchor.
To avoid any potential large delay in forwarding unicast traffic from the LMA to the MN, a mechanism SHOULD be implemented to decouple multicast from unicast traffic reception by the MN. Figure 4 shows how it works 👀
+-----+ +----+ +-----+ +----+
| MN | |pMAG| | LMA | |nMAG|
+-----+ +----+ +-----+ +----+
1) | |==Bi-Dir Tunnel=| |
| unicast data | | |
|<-v-v-v-v-v-v-v-| | |
| | | |
| Multicast Data | | |
|<---------------| | |
| | | MN Attached Event
| | | PBU |
2) | | |<---------------|
| | Subscr Query | |
3) | |<---------------| |
| | | |
4) | | <PBA timer starts> |
| | /// |
| | /// |
5) | | <PBA timer expires> |
| | | |
| | | Ext'd PBA |
| | |--------------->|
| | | |
| | | Accept PBA
| | | |
| | |==Bi-Dir Tunnel=|
| | | |
| | | Unicast Data |
|<-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-|
| | | |
| | | Subscr Query |
6) | | |<---------------|
| | Subscr Resp | |
7) | |--------------->| |
| | | |
| | (Multicast Subscription |
| | info forwarding) |
| | | |
| | | Subscr Resp |
8) | | |--------------->|
| | | |
| | | Multicast Group join
| | | and P-t-P status setup
| | Multicast Data | |
|<-------------------------------------------------|
| | | |
Figure 4: Decoupling of Unicast and Multicast SignalingHere's the sequence of messages:
- An MN is attached to the pMAG. The MN is multicast-enabled and gets unicast and multicast traffic at the same time 🦋
- Some time later, the MN starts a handover (e.g., because the radio conditions are better 📶) over a radio access controlled by a new mobile access gateway. Then the nMAG kicks off registration by sending a PBU message (with flag S set to 1) to the local mobility anchor. Since it's a reactive case, the pMAG isn't aware of the detachment process 🙈
- Before acknowledging the PBU, the LMA decides to ask the pMAG whether there's any active multicast subscription for the mobile node, by sending a Subscription Query message 🧐
- Right after the LMA sends the Subscription Query message, it starts the "PBA timer", which sets the maximum waiting time before the PBA is sent, to avoid any potential large delay in forwarding unicast traffic to the MN ⏱️
- If the "PBA timer" expires, the LMA acknowledges the PBU by sending the PBA message with flag S=1, without the multicast context info. The nMAG then processes the extended PBA message. This acknowledgement lets the mobile node receive unicast traffic from that point on 🎉 The bidirectional tunnel is also set up between the nMAG and the LMA if it wasn't set up before.
- At the same time, the nMAG sends a Subscription Query message to the LMA, asking for the multicast subscription details that are still unknown for the mobile node 🙋♀️
- The pMAG answers the Subscription Query message the LMA originally sent, and includes the multicast context 📦
- After processing the pMAG's answer, the LMA sends a Subscription Response message to the nMAG, with the multicast subscription info inside the Active Multicast Subscription option. The nMAG processes the PBA message, sets up the multicast status of the point-to-point link between the nMAG and the mobile node, and joins the content identified by (S,G) on behalf of the MN, unless the nMAG is already receiving that content. The bidirectional tunnel is also set up between the nMAG and the LMA if it wasn't set up before. Now the multicast content can finally be served to the mobile node 🌈
The "PBA timer" in the LMA decides whether the signaling flow follows Figure 3 or Figure 4 in a reactive handover. A value of 0 for the "PBA timer" guarantees the unicast traffic doesn't suffer any delay (following the Figure 4 flow), because the PBA gets sent right after the LMA receives the PBU from the nMAG ⚡ A small non-zero "PBA timer" value MAY be used to reduce the signaling load in the LMA and MAGs (as in the Figure 3 flow, if the Subscription Response message from the pMAG reaches the LMA before the "PBA timer" expires). But this has to be carefully balanced against the added delay to unicast traffic ⚖️
6. IPv4 Support ✨
IPv4-based mobile nodes (IPv4/IPv6 dual-stack or IPv4-only) can be supported in a PMIPv6 domain according to [RFC5844]. When we talk about multicast membership protocols and procedures, that means IGMP functionality also has to be supported between the PMIPv6 entities, as documented in [RFC6224], so the mobile access gateway can request multicast content from the mobility anchor on behalf of the mobile nodes attached to it 🧚
6.1. Active Multicast Subscription for IPv4 🌸
The Active Multicast Subscription option defined in Section 4.1, which carries the multicast membership context of the mobile node during handover, should be compatible with IGMP-based formats. Specifically, the option format for IPv4-based MNs looks like this 💖
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 | IGMP Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Membership Context +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IGMPv3 is the main target for defining the option format 🎯 IGMPv1 and IGMPv2 are also considered for backward compatibility. The alignment requirement for this option is 4n+1.
Type: 56, which indicates the Active Multicast Subscription IPv4 option.
Length: An 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields.
IGMP type: This field identifies the IPv4 multicast membership protocol in use, and the matching format of the next Multicast Membership Context information field. It maps the type codification used in the original IGMP specifications for the Report message. The values are:
0x12: Use of IGMPv1 multicast membership protocol.0x16: Use of IGMPv2 multicast membership protocol.0x22: Use of IGMPv3 multicast membership protocol.
Multicast Membership Context: Multicast subscription info for a single subscribed multicast address. Depending on the IGMP version the mobile node uses, the Multicast Membership Context can follow these formats:
- For IGMPv1, the Group Address format as defined in [RFC1112].
- For IGMPv2, the Group Address format as defined in [RFC2236].
- For IGMPv3, the Group Record format as defined in [RFC3376]. 🫶
6.2. Signaling Procedures for IPv4 Support
Okay so the generic signaling for IPv4 in PMIPv6 domains is already specced out in [RFC5844] 💅. To stop errors while the ongoing multicast subscription gets signaled for a mobile node during handover, these extensions have to be considered in SIAL ✨.
o If the registration/de-registration process in a handover is for an IPv6-only MN, and the type of the received Active Multicast Subscription option indicates IPv4, then the multicast membership context received MUST be silently discarded 🙈.
o If the registration/de-registration process in a handover is for an IPv4-only MN, and the type of the received Active Multicast Subscription option indicates IPv6, then the multicast membership context received MUST be silently discarded 💀.
o If the registration/de-registration process in a handover is for a dual stack MN, the received Active Multicast Subscription option (or options) MUST be accepted independently of the type indication 🫶.
6.3. Binding Cache Extensions for IPv4 Support
Additionally, the multicast membership info is temporarily stored in the mobility anchor under some circumstances (e.g., proactive handover), so the binding cache entry for an IPv4-based multicast-enabled MN SHOULD be extended to store the IGMP-based context formats mentioned above, including the IGMP version indicator 🧚.
Wait, I need to fix that: the original says "should", so it's lowercase in the source and I'm keeping it that way. Here is the correct line:
Additionally, the multicast membership info is temporarily stored in the mobility anchor under some circumstances (e.g., proactive handover), so the binding cache entry for an IPv4-based multicast-enabled MN should be extended for storing the IGMP-based context formats mentioned above, including the IGMP version indicator 🧚.
7. Coexistence with PMIPv6 Multicast Architectural Evolutions ✨
Throughout this document, the base solution for multicast support in Proxy Mobile IPv6, described in [RFC6224], has been implicitly considered 🦋. That means both unicast and multicast traffic addressing a mobile node gets delivered via the standard PMIPv6 bidirectional tunnel between LMA and MAG. While here all multicast traffic is assumed to be delivered via the local mobility anchor, the SIAL approach described in this document can also be applied to other solutions where the multicast content is served from other entities in the PMIPv6 domain, as described in [RFC7028] to solve the tunnel convergence problem 👑.
In this case, the transfer of the multicast context would also pass through the local mobility anchor, as described here. However, the nMAG subscribes to the multicast content through the node in charge of distributing multicast according to the adopted solution for multicast distribution in the PMIPv6 domain 🌈.
8. Security Considerations 🔥
This is serious bestie, so read this part carefully 😭.
This proposal does not pose any additional security threats to those already identified in [RFC5213]. All the security considerations in [RFC5213] are directly applicable to this protocol. The signaling messages, Proxy Binding Update, and Proxy Binding Acknowledgement (extended with the new options defined in this document), the Subscription Query Message, and the Subscription Response Message exchanged between the mobile access gateway and the local mobility anchor, MUST be protected using end-to-end security association(s) offering integrity and data origin authentication 🔐.
The mobile access gateway and the local mobility anchor MUST implement the IPsec security mechanism mandated by Proxy Mobile IPv6 [RFC5213] to secure the signaling described in this document. In the following, we describe the Security Policy Database (SPD) and Security Association Database (SAD) entries necessary to protect the new signaling introduced by this specification (Subscription Query Message and Subscription Response Message). We use the same format used by [RFC4877]. The SPD and SAD entries are only example configurations. A particular mobile access gateway implementation and a local mobility anchor home agent implementation could configure different SPD and SAD entries as long as they provide the required security of the signaling messages 💖.
For the examples described in this document, a mobile access gateway with address "mag_address_1", and a local mobility anchor with address "lma_address_1" are assumed 🎀.
mobile access gateway SPD-S:
- IF local_address = mag_address_1 &
remote_address = lma_address_1 &
proto = MH & (remote_mh_type = Subscription Query |
local_mh_type = Subscription Response |
remote_mh_type = Multicast Activity Indication Ack.|
local_mh_type = Multicast Activity Indication)
Then use SA1 (OUT) and SA2 (IN)
mobile access gateway SAD:
- SA1(OUT, spi_a, lma_address_1, ESP, TRANSPORT):
local_address = mag_address_1 &
remote_address = lma_address_1 &
proto = MH
- SA2(IN, spi_b, mag_address_1, ESP, TRANSPORT):
local_address = lma_address_1 &
remote_address = mag_address_1 &
proto = MH
local mobility anchor SPD-S:
- IF local_address = lma_address_1 &
remote_address =mag_address_1 &
proto = MH & (remote_mh_type = Subscription Response |
local_mh_type = Subscription Query |
remote_mh_type = Multicast Activity Indication |
local_mh_type = Multicast Activity Indication Ack.)
Then use SA2 (OUT) and SA1 (IN)
local mobility anchor SAD:
- SA2(OUT, spi_b, mag_address_1, ESP, TRANSPORT):
local_address = lma_address_1 &
remote_address = mag_address_1 &
proto = MH
- SA1(IN, spi_a, lma_address_1, ESP, TRANSPORT):
local_address = mag_address_1 &
remote_address = lma_address_1 &
proto = MHWhile in the base solution the LMA has learned of the subscribed multicast groups per MAG, in this specification the LMA is aware (during a handover process) of the multicast groups to which an MN visiting the PMIP domain is subscribed 🧠.
9. IANA Considerations 🌸
This document establishes new assignments to the IANA mobility parameters registry 📋.
o Mobility Header types: the Subscription Query (22) and Subscription Response (23) mobility header types. The Type value for these Headers has been assigned from the "Mobility Header Types - for the MH Type field in the Mobility Header" registry defined in <http://www.iana.org/assignments/mobility-parameters>.
o Mobility options: the Active Multicast Subscription mobility option for both IPv4 (56) and IPv6 (57) modes of operation. The Type value for these Mobility options has been assigned from the "Mobility Options" registry defined in <http://www.iana.org/assignments/mobility-parameters>.
o Flags: this document reserves a new multicast Signaling flag (S). This flag has been reserved as value 0x0020 in the "Binding Update Flags" registry and value 0x04 in the "Binding Acknowledgment Flags" registry. These registries appear on <http://www.iana.org/assignments/mobility-parameters>.
10. Contributors 🫶
Dirk Von Hugo (Telekom Innovation Laboratories, Dirk.von-Hugo@telekom.de) extensively contributed to this document 💜.
11. Acknowledgments 🌷
The authors would like to thank (in alphabetical order) Hitoshi Asaeda, Sergio Figueiredo, Georgios Karagiannis, Marco Liebsch, Behcet Sarikaya, Thomas C. Schmidt, and Stig Venaas for their valuable comments and discussions on the MULTIMOB mailing list. The authors are also grateful with Hitoshi Asaeda, Akbar Rahman, Behcet Sarikaya, and Stig Venaas for their reviews of this document ✨.
The research of Carlos J. Bernardos leading to these results has received funding from the European Community's Seventh Framework Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL project), being also partially supported by the Ministry of Science and Innovation (MICINN) of Spain under the QUARTET project (TIN2009-13992-C02-01) 🦋.
The research of Ignacio Soto has also received funding from the Spanish MICINN through the I-MOVING project (TEC2010-18907) 🌈.
12. References 📚
12.1. Normative References
[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.
[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.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, April
2007.
[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.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.12.2. Informative References
[Papagiannaki]
Papagiannaki, K., Moon, S., Fraliegh, C., Thiran, P., and
C. Diot, "Measurement and Analysis of Single-Hop Delay on
an IP Backbone Network", IEEE Journal on Selected Areas in
Communications, vol. 21, no. 6, August 2003.
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
September 2010.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of
the Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) for Routers in Mobile
and Wireless Networks", RFC 6636, May 2012.
[RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and
Y. Kim, "Multicast Mobility Routing Optimizations for
Proxy Mobile IPv6", RFC 7028, September 2013.
[Verizon] Verizon, "LTE: The Future of Mobile Broadband Technology",
Verizon White Paper, 2010,
<http://opennetwork.verizonwireless.com/pdfs/
VZW_LTE_White_Paper_12-10.pdf>.
[Y.1541] ITU-T, "Network performance objectives for IP-based
services", ITU-T Recommendation Y.1541, December 2011.Appendix A. Performance Comparison with Base Solution ✨
Okay bestie, this informative annex is giving "how much faster is our handover really?" 💅 It briefly compares the fast handover extensions from this document with the base multicast solution in [RFC6224]. The goal is to figure out how much delay we can shave off when the nMAG grabs the MN's multicast subscription info during a handover. So the analysis only looks at the extra delay that multicast adds on top of the unicast handover, for both approaches. 🦋
Different delay pieces matter here. The actors in the handover (MN, pMAG, nMAG, LMA) interact differently in each solution, so each one has its own sources of delay. 🧚
A.1. Delay Characterization of the Base Solution 💜
The base solution uses the standard MLD procedures to get the multicast subscription info straight from the MN. 😭 Once the nMAG finishes setting up the point-to-point link to the attaching MN (this can happen at the same time as the link is set up as a downstream interface of an MLD proxy instance), it immediately sends an MLD General Query towards the MN to find out about any active multicast subscriptions. When the MN gets the MLD Query, it answers with its active memberships in an MLD Report message. Once that Report gets through over the wireless point of attachment to the nMAG, the matching MLD proxy instance at the nMAG sets the multicast status of the downstream interface. So the delay comes from the MAG-MN communication. 🌸
The delay components for the base solution are:
D_bh, the one-way delay on the transmission path between the nMAG and the wireless point of attachment. 🍓D_radio, the one-way delay from sending the MLD Query and Report messages over the radio channel (user plane) between the wireless point of attachment and the MN. 📡D_mld, the delay the MN takes to answer the MLD Query. 🎀
The total observed delay is:
D_base = 2 x (D_bh + D_radio) + D_mldA.2. Delay Characterization of SIAL 🌈
There are two scenarios here, depending on the order in which the LMA gets the MN registration and de-registration notifications from the nMAG and the pMAG. 🔥
In the proactive case, the pMAG de-registers the MN first, and the nMAG registers it later. The LMA stores the multicast subscription info, which gets handed to the nMAG during the MN registration process. Registration always happens before the MLD Query and Report exchange from the base solution, so the proactive case is inherently faster. Honestly, since the subscription info is already acquired during registration, the delay is zero. 👑
In the reactive case, the LMA gets the MN registration from the nMAG before it has received the MN de-registration from the pMAG. If the MN has an active subscription, the LMA queries the pMAG to get the subscription info, and that info is forwarded to the nMAG. So this delay comes from the MAG-LMA communication. 💅
The delay component for SIAL is:
D_net, the one-way delay on the network path between the LMA and the MAG. 🫶
The total observed delay is:
D_sial = 2 x D_netA.3. Performance Comparison 💖
The base solution really depends on the radio technology the MN uses to attach to the PMIPv6 domain. Different radio technologies have their own vibes when it comes to radio framing, contention or collision avoidance, channel reliability, and so on. 🦋
New radio access technologies, like the ones in the new Long Term Evolution (LTE) standards, aim to cut latency so we get high-speed communications. ✨ Even so, typical one-way latencies in LTE radio access will stay around 15 ms [Verizon]. 🚀
The backhaul delay is kind of messy to characterize. A real network can use several backhaul options, depending on topology (ring, star, point-to-point, etc.) and technology (optical fiber, microwave transmission, xDSL-based accesses, etc.). Each one has different performance, reliability, and delay. These options often coexist in a real mobile network, so an MN changing its point of attachment can move smoothly from one option to another. A value of D_bh = 5 ms is a typical backhaul latency in modern networks. 🌸
The MLD-induced delay is baked into the MLD protocol itself. A host that receives an MLD Query waits a random time in the range (0, Maximum Response Delay) before sending its MLD Report. The default Maximum Response Delay (configurable through the Query Response Interval in MLD) is 10 s in [RFC2710] and [RFC3810]. [RFC6636] looks at what happens when you tune the Query Response Interval, and 5 s is the smallest value it recommends (best case). So on average, you can expect a potential delay of 5 s or 2.5 s, for the default and best case respectively. 😭🔥
So, as we've seen, D_base is on average greater than 2.5 s even with the best Query Response Interval value recommended in [RFC6636]. That means the handover delay for the base solution is on the order of seconds, while in the solution from this specification it's on the order of milliseconds (more on that below). 🙈 You could lower the Query Response Interval even further to improve the base solution, but the implications would need to be carefully analyzed first. 🧐 Even if the Query Response Interval were 0 s, D_base would be around 2 x (5 ms + 15 ms) = 40 ms for last-generation systems. Note that this doesn't include the time needed to re-establish the data plane after the handover so the MLD Query can be received. ⚠️ It gets much worse for older generations, too. For example, 3G-based radio systems can have radio delays on the order of hundreds of ms. 💀
For SIAL, the delay on the MAG-LMA communication comes from the network diameter, meaning the number of hops between the MAG and the LMA in the PMIPv6 domain. This depends a lot on internal network planning. An administrative domain can typically have on the order of five hops from access to the interconnection gateway that provides connectivity to other networks. 🗺️
Even though the LMA is topologically central in the PMIPv6 domain, five hops seems reasonable in a common nation-wide network. Each hop between MAG and LMA adds some delay, estimated at around 1 ms in the best case [Papagiannaki] and 3 ms in the worst case [Y.1541]. With that in mind, a total D_sial of around 2 x 5 x 3 ms = 30 ms can be expected in the worst case. 🎀
So, in conclusion, in a typical deployment, the SIAL proposal, even in the worst case, performs better than the best case for the base solution, which uses last-generation radio technology, LTE. For any other radio technology, the base solution shows even bigger deviations from the delay that SIAL can achieve. 🏆
Authors' Addresses 🦋
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid 28050
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/
Ignacio Soto
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
EMail: isoto@it.uc3m.es📦 where this page comes from
- ietf: rfc7161 2014-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms