RFC 6058
Transient Binding for Proxy Mobile IPv6
Transient Binding for Proxy Mobile IPv6 🦋
Bestie, this is RFC 6058 📜 It's from March 2011, and the authors are M. Liebsch (Ed.) from NEC, A. Muhanna from Ericsson, and O. Blume from Alcatel-Lucent Bell Labs. It's Experimental, not Standards Track, with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's its own thing 💅
Abstract ✨
okay so this doc tweaks Proxy Mobile IPv6 signaling so the network can make a transient binding cache entry 🧚 The whole point is to make handovers smoother for dual radio handover (two radios) and single radio handover (one radio). It works for an MN moving between MAGs (Mobility Access Gateways), whether it's using one interface or different ones 🫶
The doc looks at the handover problem space using the PMIPv6 base protocol, and describes how transient binding cache entries live at the local mobility anchor. The extension makes sure downlink and uplink packets between mobile nodes and the network are forwarded in an optimized way, and it avoids superfluous packet forwarding delay or even packet loss 😭🔥
Status of This Memo 📝
This one is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧪
It defines an Experimental Protocol for the Internet community. It's a product of the IETF, it reflects the IETF community's consensus, and it got public review and approval from the IESG. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓
You can find the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc6058 🌸
Copyright Notice ©️
Copyright (c) 2011 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 they stood on the publication date. Read them carefully, because they explain your rights and restrictions. Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🎀
Table of Contents 🗂️
1. Introduction ....................................................4
2. Conventions and Terminology .....................................5
2.1. Conventions Used in This Document ..........................5
2.2. Terminology and Functional Components ......................5
3. Analysis of the Problem Space ...................................6
3.1. Handover Using a Single Interface ..........................6
3.2. Handover between Interfaces ................................6
3.2.1. Issues with Downlink Traffic ........................7
3.2.2. Issues with Uplink Traffic ..........................9
3.3. Need for a Common Solution ................................10
4. Use of Transient Binding Cache Entries .........................11
4.1. General Approach ..........................................11
4.2. Impact on Binding Management ..............................13
4.3. Role of the LMA and nMAG in Transient State Control .......14
4.3.1. Control at the nMAG ................................14
4.3.2. Control at the LMA .................................15
4.4. LMA Forwarding State Diagram ..............................15
4.5. MAG Operation .............................................18
4.6. LMA Operation .............................................19
4.6.1. Initiation of a Transient BCE ......................19
4.6.2. Activation of a Transient BCE ......................20
4.7. MN Operation ..............................................22
4.8. Status Values .............................................22
4.9. Protocol Stability ........................................22
5. Message Format .................................................24
5.1. Transient Binding Option ..................................24
6. IANA Considerations ............................................25
7. Security Considerations ........................................25
8. Protocol Configuration Variables ...............................26
9. Contributors ...................................................26
10. Acknowledgments ...............................................26
11. References ....................................................26
11.1. Normative References .....................................26
11.2. Informative References ...................................26
Appendix A. Example Use Cases for Transient BCE ..................28
A.1. Use Case for Single Radio Handover ........................28
A.2. Use Case for Dual Radio Handover ..........................30
Appendix B. Applicability and Use of Static Configuration at
the LMA ..............................................33
B.1. Early Uplink Traffic from the nMAG ........................33
B.2. Late Uplink Traffic from the pMAG .........................33
B.3. Late Switching of Downlink Traffic to nMAG ................341. Introduction ✨
The IETF gave us Proxy Mobile IPv6 (PMIPv6) [RFC5213], a protocol for network-based localized mobility management. It covers the basics: registration, tunnel management, and deregistration 🚇 To get rid of the risk of lost packets, this doc adds an extension to PMIPv6. It uses a new mobility option in the Proxy Binding Update (PBU) and the Proxy Binding Acknowledgement (PBA) between the new MAG (nMAG) and the Local Mobility Anchor (LMA) 💌
Here's the drama 🎭 Under the PMIPv6 base spec, the LMA updates an MN's Binding Cache Entry (BCE) and switches the forwarding tunnel once it gets a PBU from the MN's new MAG (nMAG). At the same time, the LMA disables the forwarding entry toward the MN's previous MAG (pMAG). For an inter-technology handover, the MN's target interface has to be configured based on the Router Advertisement the nMAG sends. Address configuration and any radio-bearer setup specific to the access technology can delay the new interface from being fully ready to send or receive data packets ⏳ So if the LMA follows [RFC5213] and starts forwarding packets to the new interface right after it gets the PBU from the nMAG, some packets might get lost or hit major delay 💀
The transient BCE extension in this doc boosts handover performance (less packet loss and forwarding delay) for MNs with several network interfaces that switch from one interface to another 🦋 It also helps single radio MNs, which lean on existing radio-layer forwarding mechanisms and reuse active handover techniques they already have 🙌
Some implementation-specific fixes can help with a few of the issues in this doc. For example, the LMA can be statically configured to accept uplink packets from the old MAG as well as the new MAG for a short time during the handover, and the new MAG can do buffering. See Appendix B for more details. The dynamic solution from this protocol, though, is what optimizes things across lots of different handover situations and radio characteristics 🌈
The doc also brings in an advanced binding cache management mechanism at the LMA, built around well-defined transient BCE states. This keeps the forwarding states at LMAs in line with the different handover scenarios 🎀 During a transient state, an MN's BCE points to two Proxy Care-of-Address (Proxy-CoA) entries, one from the pMAG and one from the nMAG. MAGs can set up transient binding settings on the LMA through signaling. The LMA can also set up or change those settings based on events, like a timeout, a change of radio technology during a handover, or a completed radio bearer setup or configuration of an MN's IP address. Other protocols can trigger these events too, like Authentication, Authorization, and Accounting (AAA) messages 🔐
This doc specifies advanced binding cache control through a Transient Binding option, which works with PMIPv6 signaling to support transient BCEs. It also specifies forwarding behavior based on the binding's current state, so the LMA can switch the forwarding tunnel from the pMAG to the nMAG during an inter-MAG handover, depending on the handover conditions 🔄 The result is that handover performance gets a major glow-up, and the MN's handover is smoother without adding major complexity to the system 💅✨
2. Conventions and Terminology 💅
2.1. Conventions Used in This Document
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] 📖
2.2. Terminology and Functional Components
- IF - Interface. Any network interface that gives a mobile node wireless or wired access to the network infrastructure. If an MN has several interfaces, they get numbered (IF1, IF2, etc.) 📶
- Transient Binding Cache Entry. A temporary state of the mobile node Binding Cache Entry that sets the forwarding characteristics of the MN's forwarding tunnels to the nMAG and pMAG. This transient BCE state gets created when the Transient Binding option is included in the PBU and PBA, as this doc specifies. The LMA forwards MN traffic according to the current transient BCE characteristics, as this doc specifies. The transient BCE state is transparent to the pMAG 🫧
- Active Binding Cache Entry. A valid mobile node Binding Cache Entry according to
[RFC5213]that is not in a transient state 🌸
3. Analysis of the Problem Space 🔥
This section sums up the analysis of the handover problem space for inter-technology handover, and also for intra-technology handover, when PMIPv6 is used as in [RFC5213] 🧐
3.1. Handover Using a Single Interface
okay so in some active handover scenarios, the nMAG has to be set up as the handover target before the link-layer handover is finished 🦋 Packets the LMA sends to the nMAG before that link-layer handover completes will get lost unless they're buffered 😭
in some systems, the nMAG also gets uplink traffic before the procedure that leads to the PBU/PBA handshake is done 💅 those packets can't be forwarded to the LMA, which is giving major "not yet bestie" energy 🙈
during an intra-technology handover, some of the MN's uplink traffic can still be in transit through the pMAG 🌸 right now, following the PMIPv6 base protocol [RFC5213], the LMA only forwards the MN's uplink traffic that came in over a tunnel for as long as the source IP address of that traffic matches the IP address of the mobile node's registered Proxy-CoA in the associated BCE. so if packets show up at the LMA from the MN's pMAG after the LMA has already switched the tunnel to point at the nMAG, they get dropped 💀 not iconic at all
3.2. Handover between Interfaces
ngl this is where it gets spicy 🌶️ in client-based mobility protocols, the MN is the one running the whole handover sequence. it updates its binding and routing info at its mobility anchor only after IP connectivity is up on the new link ✨ PMIPv6 is different, because it aims to take IP mobility signaling off the MN's plate, while the mobile node still controls link configuration during a handover 🎀 that creates a problem when the MN switches between interfaces.
according to the PMIPv6 base protocol [RFC5213], the Access Authentication and the Proxy Binding Update (PBU) get triggered in the access network by the radio attach procedure, transparently for the MN. on top of that, the delay for configuring the address on the MN's new interface isn't part of the handover procedure at all 😬 so the LMA updating the MN's BCE right after it gets the PBU from the MN's nMAG ends up hurting the performance of both the MN's downlink and uplink traffic 🫠 we'll look at how downlink and uplink each get affected in the subsections below 🧚
3.2.1. Issues with Downlink Traffic
the MN's network interface can be delayed by certain protocol operations it has to run to configure its new interface, and those operations can take a while ⏳ to finish address auto-configuration on the new interface, the MN has to send a Router Solicitation and wait for a Router Advertisement. once it gets a Router Advertisement from the new MAG, the MN can finish its address configuration and may run Duplicate Address Detection (DAD) [RFC4862] on the new interface. only then is the MN's new interface actually ready to receive packets 🌈
address configuration can take more than a second to complete ⏰ if the LMA has already switched the mobile node's tunnel to point at the nMAG and started forwarding data packets for the MN to the nMAG during that time, those data packets might get delayed or lost, since the MN's new interface isn't ready to receive data yet 😭 and here's the catch: delaying the PBU isn't an option. the PBU gets sent from the new MAG to the LMA after the MN's new interface has attached to the network, and the new MAG needs the PBA to get configuration data for the MN from the LMA, like the MN's Home Network Prefixes (HNPs) and the link-local address to be used at the MAG 💜
the problem above is illustrated in Figure 1, which assumes that the HNP(s) will be assigned under control of the LMA. so the HNP option in the PBU that the new MAG sends to the LMA is set to ALL_ZERO 🍓 an MN is attached to the network with interface (IF) IF1 and receives data on it. when the MN's new interface IF2 comes up and gets detected by the new MAG, the new MAG sends a PBU and receives a PBA from the LMA. if the LMA decides to forward data packets for the MN via the new MAG, the new MAG has to buffer those packets until address configuration on the MN's new interface is complete and the interface is ready to receive packets 🫶 while IF2 is being set up, the MN may not reply to address resolution signaling [RFC4861] sent by the new MAG [A]. if the MAG's buffer overflows, or the MN can't reply to address resolution signaling for too long, data packets for the MN get dropped, and the MN can experience severe packet losses during an inter-access handover [B] until IF2 is ready to receive and send data [C] 😱
+------+ +----+ +----+ +---+
| MN | |pMAG| |nMAG| |LMA|
+------+ +----+ +----+ +---+
IF2 IF1 | | |
| | | | |
| |- - - - - - - - - Attach | |
| | |---------------PBU--------------->|
| | |<--------------PBA----------------|
| |--------RtSol------->| | |
| |<-------RtAdv--------| | |
| Addr. | | |
| Conf. | | |
| |<--------------------|==================data============|--
| | | | |
|- - - - - - - - - - - - - - - - - Attach |
| | | |----------PBU-------->|
| | | |<---------PBA---------|
| | | |<-====data============|--
[A]?|<-----------NSol---------------------|<-====data============|--
| | | [B] ?|<-====data============|--
| | | ?|<-====data============|--
|-----------RtSol-------------------->|<-====data============|--
|<----------RtAdv---------------------| : |
Addr. | | | : |
Conf. | | | : |
|<-----------NSol---------------------| : |
|------------NAdv------------------->[C] |
!|<------------------------------------|======data============|--
| | | | |
| | | | |Figure 1: Issue with dual radio handover
another risk for a delay in forwarding data packets from a new MAG to the MN's IF2 is latency in setting up a particular access technology's radio bearer, or its access-specific security associations, after the new MAG has received the MN's HNP(s) from the LMA in the PBA signaling message 🌸
if an access network needs the MN's IP address or HNP to set up a radio bearer between the MN's IF2 and the network infrastructure, the access network might have to wait until the nMAG has received the associated information from the LMA in the Proxy Binding Acknowledgment. so the delay in forwarding packets from the nMAG to the MN's IF2 now depends on how long it takes to set up the radio bearer 🫠
a similar problem can happen when setting up a required security association between the MN's IF2 and the network takes time, and that setup can only be done once the MN's IP address or HNP is available on the nMAG 🔐
both of these scenarios, as shown above, can be found in [TS23.402], where the protocol sequence during a handover between different accesses has a PMIPv6 handshake between the nMAG and the LMA to retrieve the MN's HNP(s) before the access-specific operations can be completed 👑
3.2.2. Issues with Uplink Traffic
in an inter-technology handover between two interfaces, the MN may be able to keep connectivity on IF1 while it finishes address configuration on IF2 🦋 this is called "make-before-break", and it can avoid uplink packet loss in client-based Mobile IP ✨ but in a PMIPv6 domain, attaching the MN on IF2 makes the nMAG send a PBU to the LMA, and that makes the LMA update the BCE for this mobility session of the MN 💅 according to Section 5.3.5 of the PMIPv6 base specification [RFC5213], the LMA may drop all subsequent packets that the MN's pMAG forwards, because the updated BCE now refers to the nMAG as a "Proxy-CoA" 💀
uplink packets have one more issue, and it comes from differences in travel time between the nMAG and LMA compared with the travel time between the pMAG and LMA 🐢 even if the MN stops sending packets on IF1 before the PBU goes out (so, before it attaches IF2 to the nMAG), uplink packets from the pMAG can still reach the LMA after the LMA has already received the PBU from the nMAG 😩 this is especially likely when the MN's previous link has high delay (for example, a Global System for Mobile Communications (GSM) link) and is slow compared to the handover target link. Figure 2 shows this behaviour 🌈
+------+ +----+ +---+
| MN | |nMAG| |LMA|
+------+ +----+ +---+
IF2 IF1 | |
| |\ | |BCE exists
| | \ | | for pMAG
|- -|- - - - \- - - - Attach |
| | s\ |---------PBU----------->|BCE update
| | l\ |<--------PBA------------| for nMAG
| | o\ |
| | | w\ |
| | | l\ |
| | | i\ |
| | | n \ |packet dropped
| | | k --->| as BCE has only
| | | | entry for nMAG
| | | |
| | | |Figure 2: Uplink traffic issue with slow links
3.3. Need for a Common Solution
okay so bestie, an MN can help itself dodge packet loss by picking its settings so the network interface config goes faster 🏃♀️, and tuning stuff like buffer capacity on MAG components can make handover performance better too 🎀. BUT ngl, some network stuff like access link delay or bearer setup latency can't really be fine-tuned for each handover scenario 😭. So what we actually want is a common solution that dynamically controls and enhances all that handover complexity, using a simple extension to the PMIPv6 base protocol ✨. It's lowkey the only sane way 🫶.
This document specifies transient BCEs as an extension to the PMIPv6 protocol 🦋. Setting up and configuring a transient BCE happens through extended PMIPv6 signaling messages between the MAG and the LMA, using a brand new Transient Binding mobility option 💖. The transient BCE mechanism supports three clearly distinguished sequences of transient states, so it fits lots of different handover situations and improves handover performance for both inter- and intra-technology handover 🌈. Because of transient BCEs, excessive packet buffering at the nMAG during the MN's handover isn't necessary, and packet losses and major jitter can be avoided 💜.
4. Use of Transient Binding Cache Entries ✨
4.1. General Approach
The use of transient BCE during an MN's handover (HO) gives us way more control over forwarding of uplink (Ul) and downlink (Dl) traffic 💅. The goal is to harmonize handover performance with what the handover source and target access networks can actually do 🎯. Updating an MN's BCE at an LMA is split into different phases, before and after the radio setup and IP configuration tied to the MN's handover from a pMAG to an nMAG 🦋.
So the transient BCE during an MN's handover splits into an initiation phase and a phase that turns the transient BCE into an active BCE 🌸. Figure 3 shows the whole procedure for entering and leaving a transient BCE during an MN's handover. Once the MN attaches at the nMAG, the first PBU from the MN's nMAG can turn the MN's BCE at the LMA and the nMAG into transient state, by including a Transient Binding option (Section 5.1) 💖. The LMA adds the nMAG as a further forwarding entry to the MN's BCE, without deleting the existing forwarding entry, and marks the BCE state as 'transient' 🧚. Alternatively, if the nMAG doesn't include a Transient Binding option, the LMA can decide to use a transient BCE during the MN's handover and tell the nMAG about it by adding a Transient Binding option in the PBA 👑. After receiving the PBA, the nMAG enters the MN's data, such as the assigned HNP(s), into its Binding Update List (BUL), and marks the MN's binding with the LMA as 'transient' 🫶. That mark is how the nMAG knows the transient BCE needs to be turned into an active BCE 🔥.
During the transient state, the LMA accepts uplink packets from both MAGs, the pMAG and the nMAG, for forwarding 🦋. To make use of the downlink path from pMAG to MN that's still available, the LMA keeps forwarding downlink packets towards the pMAG until the transient BCE is turned into an active BCE 💜. This downlink forwarding behaviour is called "late path switch" (L) 🌈. During a dual radio handover, an MN can receive downlink packets via its previous interface. During a single radio handover, the late path switch lets the radio access network reuse forwarding mechanisms it already has 🎀. Appendix A describes both use cases 📚.
Deciding whether an MN's BCE is classified as transient during a handover can be done either by the nMAG or by the LMA 🙌. Detailed mechanisms showing how an nMAG or an LMA figures out that it should use the transient BCE procedure are out of scope for this document 🙈.
A transient BCE can be turned into an active BCE in different ways: a timeout at the LMA, a PBU from the nMAG that has no Transient Binding option included, or a deregistration PBU from the pMAG 🦋. As soon as the MN's BCE has been started on its way to becoming an active BCE, the LMA switches the forwarding path for downlink packets from the pMAG to the nMAG ✨.
+-----+ +----+ +----+ +-----+
| MN | |pMAG| |nMAG| | LMA |
+-----+ +----+ +----+ +-----+
| | | |[pMAG serves
| | | | MN as
| | | | Proxy-CoA]
| | | |
|<-----------------|===============data tunnel=====|--->data
| | | |
[Handoff | | |
Start] | | |
| | | |
e|-----------------------[MN Attach] |
x| | | |
e| | |---PBU(transient)--->|[Add nMAG to
c| | | | MN's BCE,
u| | |<--PBA(transient)----| enter trans-
t| | | | ient state]
i| | | |
o|<-----Dl+Ul-------|===============data tunnel=====|--->data
n|--------Ul------------------|=====data tunnel=====|--->data
| | | |
[Handoff/ | | |
Configuration | | |
Completed] | [HO Complete] |
| | |--------PBU--------->|[Activate
| | | | MN's BCE,
| | |<-------PBA ---------| update for-
| | | | warding path
| | | | to nMAG]
| | | |
|<---------------------------|=====data tunnel=====|--->data
| | | |Figure 3: General mechanism and forwarding characteristics during handover with transient BCE
This specification considers an optional state when turning the transient BCE into an active BCE: a transient BCE with a late path switch, which keeps the pMAG as the forwarding entry in the transient BCE for some extra time, solely to make sure delayed uplink packets from the pMAG still get forwarded 🐢. This optional activation state has a lifetime attached to it, and ending it doesn't need any signaling 💤.
Whether or not to enter this optional activation state is up to the LMA 🧠. The LMA may look at the access technology info for the MN's pMAG and nMAG from the MN's BCE to decide if the activation state is worth it, for example when a slow link is associated with the pMAG and uplink packets from the pMAG might arrive late at the LMA 🐌.
The Transient Binding option lets you configure the transient BCE late path switch and signal its associated settings 🎀. Signaling the Transient Binding option, along with the LMA's choice on the optional activation state, defines the sequence through the clearly defined transient BCE states, as illustrated and described in Section 4.4 💅. Section 4.2 describes the extension an LMA's binding cache needs to support transient BCE operation 📝. Section 4.3 gives a quick overview of the roles the nMAG and the LMA can play in controlling a transient BCE handover sequence 🧚. The details about the Transient Binding option and how it's used are in Sections 4.5 and 4.6 🦋.
4.2. Impact on Binding Management
Using a transient BCE means keeping two forwarding entries in the MN's BCE at the LMA for a while: one that refers to the MN's pMAG, and one that refers to its nMAG 💫. Forwarding entries are represented according to [RFC5213], and they include the interface identifier of the tunnel interface associated with each MAG, plus the access technology information linked to it 🛠️.
Each forwarding entry gets a forwarding rule that admits and controls forwarding of uplink and downlink traffic to and from the associated MAG 🚦. So under this specification, a forwarding entry can have either a rule that only allows uplink traffic from the associated MAG, or a rule that allows bidirectional forwarding from and to the associated MAG 💖. At any given time, only one of the two forwarding entries can have a bidirectional forwarding rule ☝️. The interface identifier and access technology type info can be taken from the PBU received at the LMA and linked to each forwarding entry accordingly 📎.
MAGs should keep track of the status of an MN's binding, and of the lifetime tied to a transient BCE at the LMA, in their binding update list 🗂️. This matters most when the new MAG needs to explicitly turn a binding into an active BCE, once the MN's new interface has shown it's ready to handle IP traffic 🙌.
4.3. Role of the LMA and nMAG in Transient State Control
This section gives an overview of what the nMAG and the LMA can do to control a transient BCE 🧚♀️. For a detailed protocol description, check out the Protocol Operations sections instead (Sections 4.5 and 4.6) 📖.
4.3.1. Control at the nMAG
Okay bestie, the nMAG (the new MAG) is basically the one who knows what kind of handover is happening 🧚. It needs that info to set the Handoff Indicator (HI) option in the PBU and to figure out whether the handover changes the radio interface or technology. So it's the perfect entity to delay the downlink path switch in a controlled way using a transient BCE ✨.
- Initiate a late path switch: The nMAG can only start a transient BCE handover for an MN when it knows the MN supports a delayed downlink path switch (Section 4.7) under this specification. It can know that from a few different things. Like, during dual radio handover, most cellular networks do controlled handovers where the network already knows the host is moving from one attachment to another 🦋. The link layer can then tell the mobility functions "hey, this is a movement, not a brand new attachment," and that the MN has enough control over its interfaces to do a transient BCE handover 💅. If there's no link-layer support and the network can't give the nMAG any such indication, the nMAG MUST assume the host can't do this mode and use standard behavior from [RFC5213]. So basically, the nMAG does a regular [RFC5213] handover 🙈.
The nMAG is also the best one to estimate the maximum delay until the new connection can be used, since it knows its own locally connected radio network characteristics 📡. So it can set the maximum lifetime that delimits the transient BCE softstate at the LMA. The LMA may still override the proposed lifetime and tell the nMAG the new lifetime in the Transient Binding option included in the PBA 👑.
- Activation of a transient BCE to perform a downlink path switch: During a transient BCE handover, the nMAG may get an indication that the MN's radio link can be used and that the MN has finished setting up the IP address to send and receive data packets over the new link 🎀. Then the nMAG can turn the transient BCE into an active BCE before the maximum transient BCE lifetime runs out. To do that, it sends a PBU without the Transient Binding option to the LMA, and this results in a downlink path switch to the nMAG 🌸.
4.3.2. Control at the LMA
- Initiate a late path switch: If the LMA gets a PBU without a Transient Binding option included, it can decide to use a transient BCE to optimize the handover performance 🔥. The LMA indicates its selected settings for the late path switch (L) and the associated maximum lifetime in the Transient Binding option, which goes in the PBA and gets sent to the nMAG 💜.
- Decision to use an optional activation state: The LMA knows the MN's previous and new access technology, so it's the suitable entity to decide whether to use an optional activation state ✨. It can use an activation state to temporarily keep forwarding uplink packets from both MAGs, the pMAG and the nMAG, even though the downlink path has already switched to the nMAG 🧚. One reason to enter that activation state could be a slow link between the pMAG and the LMA, as described in Section 3.2.2 🐢.
4.4. LMA Forwarding State Diagram
Here's where it gets spicy 🌶️. The current specification covers three clearly defined transient BCE states at the LMA that can be used during an MN's handover 💖. Each state has its own characteristic for forwarding entries, where forwarding rules for uplink traffic are kept separate from downlink traffic 🦋. This section walks through how the forwarding state changes step by step during the optimized handoff 👑. Different handover scenarios can go through different sequences of forwarding states, so Figure 4 shows the possible cases, their sequences, and the triggers for each transition ✨. If you want the full story, Appendix A breaks down two example use cases in detail 📖.
According to this specification, each BCE has a state, which can be either Active or one of the transient states Transient-L, Transient-LA, or Transient-A 🌈. When a BCE is in the Active state, its information and associated forwarding conform to [RFC5213] 💅.
Any of the transient states means the transient BCE has two forwarding entries, called pMAG and nMAG in the forwarding state diagram 🫶. Each entry has a forwarding rule, and that rule tells you whether the entry only forwards Uplink (Ul) traffic or does bi-directional forwarding for both Uplink (Ul) and Downlink (Dl) traffic 🎀.
State transitions can be triggered by processing a received PBU or by a local timeout event on the LMA ⏰. In the chart below, the presence of a Transient Binding option in a PBU is shown as Topt as an argument to a PBU or PBA. The source of a PBU, either the MN's nMAG or pMAG, is also given as an argument 🧚. A PBA is always sent by the LMA and addressed to the originator of the associated PBU 💌.
A handover with a transient BCE is triggered either when the nMAG sends a PBU with a Transient Binding option, or when the LMA decides to answer a normal PBU with a PBA that includes a Transient Binding option 🦋. Figure 4 shows the transitions between an active BCE and a transient BCE from the LMA's point of view. It also shows the direct transition between two active BCE states during an MN's handover according to [RFC5213], bypassing any transient states 🌸.
The diagram refers to two timeout events 🕰️. TIMEOUT_1 is set according to the Lifetime value in a Transient Binding option (see Section 5 for the format of the Transient Binding option), while TIMEOUT_2 is set to ACTIVATIONDELAY (see Section 8 for the default value) 💜.
The first sequence is followed when the LMA decides not to use the optional activation state and goes through the Transient-L state 🌷. In that state, the LMA keeps forwarding downlink packets to the pMAG, while uplink packets are accepted and forwarded from both the pMAG and the nMAG 💅. When the LMA gets a PBU without a Transient Binding option from the nMAG, or a TIMEOUT_1 event happens, or it receives a deregistration PBU from the pMAG, the forwarding entry of the pMAG is removed from the MN's BCE and the BCE state changes to active 🎉.
If the LMA decides to use the activation state, the second sequence is used 🔥. In this case, the BCE state turns into Transient-LA 💖. Forwarding in Transient-LA is the same as in Transient-L, but Transient-LA moves on to Transient-A when the LMA receives a PBU from the nMAG without a Transient Binding option included, or when a TIMEOUT_1 event occurs 🦋. In Transient-A, the LMA performs a downlink forwarding path switch from the pMAG to the nMAG, while uplink packets are still accepted and forwarded from both the pMAG and the nMAG 🧚. Transient-A ends with a TIMEOUT_2 event: the forwarding entry of the pMAG is removed from the MN's BCE and the BCE state turns to active ✨. If the LMA receives a deregistration PBU from the pMAG while the MN's BCE is in Transient-LA, the uplink forwarding rule of the pMAG is no longer valid, so the transition through Transient-A is skipped 🙈. In that case, the BCE turns into the active state immediately 🌈.
+----------------+ Before
PBU(nMAG) & PBA(LMA) | Active | Handover
+-----------------------| | --------
| | pMAG [Dl,Ul] | .
| *----------------* .
| | .
| | V
| PBU(nMAG, Topt) | PBU(nMAG) & PBA(LMA, Topt) .
| | .
| | .
| V Handover
| __________ Procedure
| / LMA \ .
| _________ / selects \ _________ .
| No| \ activation / |Yes .
| | \_state_?__/ | .
| | | V
| V V .
| +--------------+ +--------------+ .
| | Transient-L | | Transient-LA | .
| | | | | .
| | pMAG [Dl,Ul] | +-------| pMAG [Dl,Ul] | .
| | nMAG [Ul] | | | nMAG [Ul] | .
| +--------------+ | +--------------+ .
| | | |
| | PBU(pMAG, | PBU(nMAG) | TIMEOUT_1
| | lifetime=0)| | .
| | | V .
| | | +--------------+ .
| | | | Transient-A | .
| PBU(nMAG) | TIMEOUT_1 | | | .
| | | | nMAG [Dl,Ul] | .
| |PBU(pMAG, | | pMAG [Ul] | .
| | lifetime=0) | +--------------+ .
| | | |
| | | PBU(pMAG, | TIMEOUT_2
| | | lifetime=0)| .
| | | | V
| | | | -------
| | | | Handover
| | | V Complete
| | | +--------------+
| | +------->| Active |
| +-------------------------->| |
+----------------------------------------->| nMAG [Dl,Ul] |
+--------------+Figure 4: Possible transient forwarding states during a handover
4.5. MAG Operation
Okay so, when a handover happens, the MN's nMAG (the new MAG the MN just showed up at) can decide to have the LMA handle the MN's handover as a late path switch, using the transient BCE procedure 💅. If it does, the nMAG adds a Transient Binding option to the PBU and sets the L-flag to 1 to say "late path switch, pls" ✨. The nMAG MUST set the Lifetime field of that option to a value larger than 0. That's the max lifetime it's proposing for the transient BCE, and it also sets how long the downlink path can wait before it switches over to the nMAG ⏰. The lifetime in the Transient Binding option SHOULD be smaller than the lifetime chosen for the PBU registration. Everything else in the PBU follows [RFC5213] 🎀
Now, if the nMAG didn't include a Transient Binding option but the LMA decides to do a handover with the transient BCE procedure anyway, the nMAG may get a Transient Binding option back with the PBA, since it was the one that sent the PBU 🧚
If the nMAG gets a PBA with a Transient Binding option whose L-flag is set to 1, it SHOULD link the transient BCE sequence info and the transient BCE lifetime to the MN's entry in the BUL 📝. Because L-flag = 1 means late path switch, the nMAG MAY turn the MN's transient BCE into an active BCE before the transient BCE lifetime (TIMEOUT_1) runs out. That could happen when the nMAG notices, or gets told, that address configuration and radio bearer setup are done 🙌. To make that happen, the nMAG sends a PBU to the LMA with no Transient Binding option. All the PBU fields are set according to the binding lifetime extension procedure in Section 5.3.3 of [RFC5213]. If the transient BCE's lifetime expires, or the LMA approves turning the transient BCE into an active BCE because of a PBU from the nMAG, the nMAG MUST delete all the transient BCE info from the MN's BUL entry 😭
If the nMAG puts a Transient Binding option in the PBU, only one instance of that option per PBU is allowed 🙅
Here's the big rule: a MAG that's serving the MN's current Proxy-CoA, while the LMA already has an active or transient binding pointing to this MAG, SHALL NOT include a Transient Binding option in any later PBU that tries to create or update a transient BCE for the MN's current registration with this MAG. Not allowed, bestie 🚫
4.6. LMA Operation
4.6.1. Initiation of a Transient BCE
So the LMA gets a handover PBU from the MN's nMAG with no Transient Binding option, and the MN's BCE is active and not in transient state. In that case, the LMA MAY decide to use a transient BCE and tell the nMAG about the transient BCE characteristics by putting a Transient Binding option in the PBA 🦋. The LMA should know whether the nMAG can support the Transient Binding option. Then the LMA sets up the MN's transient BCE according to this section and the state it picked. If none of that applies, the LMA just handles the PBU under PMIPv6 [RFC5213] and does a normal update of the MN's BCE 💖
If the PBU from the nMAG does have a Transient Binding option, the LMA must go through the sequence of transient BCE states, depending on whether it decides to use an optional activation state. If the LMA decides not to use an activation state, it sets up the MN's transient BCE and the forwarding rules according to the Transient-L state 🌸. Result: the LMA does a late path switch and forwards downlink packets for the MN toward the MN's pMAG. Meanwhile, uplink packets coming from both Proxy-CoAs (the MN's pMAG and its nMAG) get routed by the LMA 🔀
If the PBU from the nMAG has a Transient Binding option and the LMA does decide to use an optional activation state, the LMA sets up the MN's transient BCE and the forwarding rules according to the Transient-LA state ✨. Same deal: late path switch, downlink goes toward the pMAG, and uplink from both Proxy-CoAs gets routed by the LMA. The extra bit is that the LMA also marks the transient BCE to enter a temporary activation phase in Transient-A state, once it has received an indication to turn the transient BCE into an active BCE 🎬
The LMA sets the transient BCE lifetime to whatever the nMAG asked for in the Transient Binding option's lifetime field, or it can shorten it based on its policy 📏. If the lifetime value in the Transient Binding option is bigger than the lifetime value tied to the PBU message, the LMA MUST reduce the transient BCE lifetime to something smaller than the registration lifetime in the PBU message. When the transient BCE registration works out, the LMA sends a PBA with a Transient Binding option back to the nMAG. The L-flag of that Transient Binding option MUST be set to 1 in this version of the specification 💜. The lifetime field gets set to whatever value the LMA finally picked.
Watch out for this one 👀: if the LMA sees an L-flag of 1 on the received Transient Binding option but the lifetime field is 0, the LMA MUST ignore the Transient Binding option and process the PBU according to [RFC5213]. Once the PBU has been processed successfully, the LMA sends back a PBA with the status field set to PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH 🙈
If the LMA gets a Transient Binding option with the L-flag set to 0, this version of the specification mandates that the LMA ignore the Transient Binding option and process the PBU according to [RFC5213]. After the PBU has been processed successfully, the LMA sends back a PBA with the status field set to PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH 🥹
Last one in this part: if the LMA gets a PBU with a Transient Binding option from a MAG that's already acting as the Proxy-CoA for the MN in an active or transient BCE, the LMA MUST ignore the Transient Binding option and process the PBU according to [RFC5213]. After it processes the PBU successfully, the LMA sends back a PBA with the status field set to PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH. Now, if the MN's BCE was in transient state before that PBU arrived from the MAG, the LMA SHALL read this PBU as the signal to turn the transient BCE into an active BCE, and then leave the Transient-L or Transient-LA state, depending on which one it was in 🔄
If the LMA includes a Transient Binding option in the PBA, only one instance of that option per PBA is allowed 🌈
4.6.2. Activation of a Transient BCE
When the LMA gets a PBU from the MN's nMAG with no Transient Binding option, but the MN's BCE is in a transient state, or when the LMA gets a local event trigger because the MN's transient BCE expired, the LMA should check whether the forwarding rules for the MN are routing the MN's downlink traffic to the MN's pMAG 🔍. If the forwarding entry for downlink packets points at the MN's pMAG, the LMA must update the forwarding info so downlink packets go toward the MN's nMAG. Once the forwarding path has switched, the LMA must update the MN's BCE to match 🚦
If the transient BCE says the LMA must consider the Transient-A activation state after leaving the transient BCE has been initiated, the LMA must keep both forwarding entries (for the pMAG and the nMAG) for uplink packets, and forward packets it receives from both Proxy-CoAs 🫶. If no activation phase is indicated, the LMA sets the MN's BCE state to active and deletes any forwarding entry pointing at the MN's pMAG. The LMA must also delete any scheduled timeout event for the MN that's tied to the transient BCE ✂️
When the LMA gets a deregistration PBU from the MN's pMAG (registration lifetime set to 0) and the MN's BCE is in transient state, the LMA must update the forwarding rules for the MN and switch the downlink traffic path from the pMAG to the nMAG 🛤️. It also sets the MN's BCE state to active and removes any forwarding entry toward the pMAG from the MN's BCE. This happens whether or not the transient BCE was set up to enter the Transient-A activation state 💅
When the LMA gets a local event trigger from a timer that was set to ACTIVATIONDELAY and scheduled to end the activation state of an MN's transient BCE, the LMA sets the MN's BCE state to active and removes any forwarding entry toward the pMAG from the MN's BCE ⏱️
When the LMA gets a PBU for binding lifetime extension from the MN's pMAG while the MN's BCE is in transient state, the LMA must approve the lifetime extension to the pMAG according to [RFC5213]. Then it carries on with the transient BCE handover toward the nMAG, following this specification 🧸
When the LMA gets a PBU from the pMAG or a (n+1)MAG that indicates a handover (for example, based on the indications specified in [RFC5213]) while the MN's BCE is in any of the specified transient states, the LMA MUST end the transient state and do a handover to the pMAG or the (n+1)MAG, respectively, according to [RFC5213]. After it processes that PBU successfully, the LMA sends back a PBA to the MAG that sent the PBU. If that PBU included a Transient Binding option, the LMA must ignore the Transient Binding option and set the status code of the PBA to PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH 🛑
4.7. MN Operation
For a single radio handover, this specification doesn't require any extra functionality on the mobile node compared to [RFC5213] 📱
Dual radio handover is where the MN gets the biggest win from the transient BCE extension to PMIPv6. The MN can keep talking over the previous interface while it sets up its handover target interface, using the configuration context it got when the new interface attached to the nMAG 🦋. There are a few ways to make that work, like using a virtual interface on top of the physical radio interfaces [NETEXT], or doing implementation-specific extensions to the MN's protocol stack. How to enable this make-before-break support on the MN is out of scope for this document 🙌
4.8. Status Values
This section defines the PBA status value 6 for transient binding cache entry support. It's below 128 and it's been added to the set of status values in [RFC5213] 🔢
PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH: 6
The LMA has processed and accepted the PBU, but the attached
Transient Binding option has been ignored.That's the end of this part, and we're still going, bestie 🌈💖
4.9. Protocol Stability ✨
Okay so the whole point of transient BCEs is that correct PMIPv6 operation according to [RFC5213] will not be broken in any case 💅. That includes losing signaling info, and also an nMAG and an LMA disagreeing because one of them doesn't support the transient BCE option 🙈. Here's the rundown of how PMIPv6 handles each of these bad vibes and keeps things stable 🫶.
- LMA does not support transient BCEs: If the nMAG sends a PBU with a Transient Binding option to an LMA that doesn't support transient BCEs, the LMA ignores the unknown option [RFC3775] and processes the PBU according to [RFC5213]. The nMAG then gets a PBA with no Transient Binding option, so it doesn't set any transient binding info in the MN's BUL entry and just operates according to [RFC5213] 🦋.
- nMAG does not support transient BCEs: Here the LMA decides to do a handover using any of the specified transient BCE sequences and puts a Transient Binding option in the PBA. The nMAG ignores the unknown option [RFC3775] and processes the PBA according to [RFC5213]. The LMA never gets any feedback that the nMAG didn't get it 💀, so the LMA enters the selected transient state, which ends at the latest after (TIMEOUT_1 + ACTIVATIONDELAY) seconds. During that time the nMAG acts like normal PMIPv6 per [RFC5213], while the LMA accepts all uplink packets for the MN, from the pMAG and from the nMAG, following the transient BCE spec. The nMAG doesn't notice if the LMA forwards downlink packets to the pMAG during the transient BCE phase, so no protocol conflict pops up from the different states on the nMAG and the LMA 🎀.
- Loss of Transient Binding option: The Transient Binding option rides in the PBU and PBA, so recovering from lost signaling packets follows the normal PMIPv6 protocol operation and its retransmission mechanisms [RFC5213] 🌸.
- Missing PBU to turn a transient BCE into an active BCE: The spec says a lifetime for TIMEOUT_1 is signaled in the Transient Binding option, and turning a transient BCE into an active BCE gets kicked off at the latest once TIMEOUT_1 has elapsed. If the PBU signaling gets lost, or the nMAG fails to start turning a transient BCE into an active BCE, the transient state of the MN's BCE ends when the set lifetime expires. That means stable PMIPv6 operation [RFC5213] has reliably recovered 🧚.
- Lost connection with pMAG during late path switch: Say an MN loses connectivity to its pMAG during a transient BCE phase with a late path switch, and the nMAG fails to turn the transient BCE into an active BCE to do the path switch to the nMAG. In the worst case, downlink packets get dropped until TIMEOUT_1 expires 😭. After TIMEOUT_1 seconds, the protocol has recovered successfully. This case is very unlikely though, for two reasons 👑. First, if the connection to the pMAG is lost, the pMAG sends a deregistration PBU for the MN to the LMA, which turns the transient BCE into an active BCE and does a path switch. Second, the nMAG starts turning the transient BCE into an active BCE as soon as the data link between the MN and the nMAG has been set up (Section 4.4). Also note this case mostly hits downlink packets, while uplink packets can go through the new connection once a broken link to the pMAG has been detected 💜.
- Binding lifetime extension from pMAG while MN's BCE is transient: The binding lifetime of the pMAG and the nMAG aren't correlated, so the pMAG may send a PBU for a binding lifetime extension to the MN's LMA while the MN's BCE is in a transient state. In that case the LMA approves the binding lifetime extension to the pMAG according to [RFC5213] and keeps going with the transient BCE handover towards the nMAG according to this spec 🌈.
The transient BCE extension keeps PMIPv6 stable even when the MN does super frequent handovers, like moving again while its handover between the pMAG and the nMAG is still in progress 🏃♀️. These corner cases are summarized in the list below.
- Handover to (n+1)MAG during transient BCE: If the MN's BCE is transient because of a handover from the pMAG to the nMAG, and during that transient BCE the MN hands over again to a MAG that is different from both the pMAG and the nMAG (say, the (n+1)MAG), the LMA ends the transient BCE and does a handover to the (n+1)MAG according to [RFC5213] 🔥.
- Handover back to pMAG during transient BCE (ping pong): If the MN's BCE is transient because of a handover from the pMAG to the nMAG, and the MN moves back from the nMAG to the pMAG during that transient BCE, the LMA ends the transient BCE and does a handover to the pMAG according to [RFC5213] 🏓.
5. Message Format 🎀
5.1. Transient Binding Option 💖
This section describes the format of the Transient Binding option, which can be included in a Proxy Binding Update message and a Proxy Binding Acknowledge message. The use of this Mobility Header option is optional 🌟.
The Transient Binding option can go in a PBU message that an MN's nMAG sends as a result of a handover. When it does, the nMAG controls the transient BCE on the LMA. Alternatively, the LMA can attach the Transient Binding option to a PBA for two reasons. Either it replies to a received PBU that had an attached Transient Binding option, to approve or correct the transient BCE lifetime, or it tells the nMAG about its decision to enter a transient BCE without having gotten a Transient Binding option from the nMAG in the associated PBU beforehand 🦋.
The Transient Binding option has no alignment requirement. Here's what it 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 | Reserved |L| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: Identifies the Transient Binding option (43).
- Length: An 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and the Length fields. This field MUST be set to 2 🙌.
- L-Flag: Indicates that the LMA applies late path switch according to the transient BCE state. If the L-flag is set to 1, the LMA keeps forwarding downlink packets towards the pMAG. Different settings of the L-Flag may be used for future use ✨.
- Lifetime: The maximum lifetime of a Transient-L state, in multiples of 100 ms ⏰.
6. IANA Considerations 🗂️
This specification adds a new Mobility Header option, the Transient Binding option. The Transient Binding option is described in Section 5.1. The Type value (43) for this option has been registered in the Mobility Options registry, which is the numbering space allocated for the other mobility options, as defined in [RFC3775] 💅.
This specification also adds one status code value to the Proxy Binding Acknowledge message: the PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code (6). The PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code is described in Section 4.8. Its value has been assigned from the Status Codes sub-registry as defined in [RFC3775], and it has a value smaller than 128 🎉.
7. Security Considerations 🔐
Okay bestie, this part is SERIOUS. Signaling between MAGs and LMAs, plus the info carried in PBU and PBA messages, is protected and authenticated according to the mechanisms described in [RFC5213]. No new security considerations are introduced beyond the ones in [RFC5213], so the security considerations described throughout [RFC5213] apply here too 🚨.
In case the MAGs or LMAs use a further protocol interface to an external component, such as for supporting transient BCE control, that associated protocol must be protected and its information must be authenticated 🛡️💀.
8. Protocol Configuration Variables ⚙️
LMA values:
ACTIVATIONDELAY: This value is set by default to 2000 ms and can be administratively adjusted 🕹️.
9. Contributors 🫂
Many thanks to Jun Awano, Suresh Krishnan, Long Le, Kent Leung, Basavaraj Patil, and Rolf Sigle for contributing to this document 💖.
10. Acknowledgments 🙏
The authors would like to thank Telemaco Melia, Vijay Devarapalli, Rajeev Koodli, Ryuji Wakikawa, and Pierrick Seite for their valuable comments to improve this specification 🌷.
11. References 📚
11.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
11.2. Informative References
- [NETEXT] Melia, T., Ed. and S. Gundavelli, Ed., "Logical Interface Support for multi-mode IP Hosts", Work in Progress, October 2010.
- [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
- [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
- [TS23.401] "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access",
http://www.3gpp.org. - [TS23.402] "Architecture enhancements for non-3GPP accesses (Release 9)",
http://www.3gpp.org.
Appendix A. Example Use Cases for Transient BCE 🧁
A.1. Use Case for Single Radio Handover 📱✨
Okay so, in some systems like the 3GPP Evolved Packet Core 🌸, PMIPv6 handles network-based mobility between the Serving Gateway (aka the MAG) and the Packet Data Network Gateway (aka the LMA). The handover magic happens in the access network, which makes handover way smoother for single radio mobile nodes [TS23.401] 💖
In that setup there's a well-structured inter-MAG handover procedure that people actually use, and it's honestly iconic 👑. To switch the data tunnel path between the LMA and the pMAG in an organized way that keeps packet loss and delay low, this handover first sets up the uplink data path from the mobile node, through the nMAG, and over to the LMA 🦋. Once that uplink path is up, the mobile node can start sending uplink packets through the nMAG to the LMA. Slay.
The downlink path between the LMA and the nMAG doesn't get set up at the same time as the uplink, so the LMA must keep forwarding downlink packets to the pMAG 🧚. There's also a layer 2 forwarding mechanism going from the previous Access Network (pAN) to the new Access Network (nAN). That's what gets downlink packets to the mobile node's location while it's attached to the nMAG 🫶.
Now, for the LMA to forward the mobile node's uplink packets out to the Internet, the nMAG uses the transient BCE mechanism. It sends a PBU with the Transient Binding option, which lets the LMA create a transient BCE for the mobile node with uplink forwarding ✨. Meanwhile, the uplink and downlink forwarding for the Proxy-CoA hosted at the pMAG stays up and running. Main character energy 💅.
While the transient BCE is alive, the LMA keeps accepting uplink traffic from both the previous and the new MAG, but it only forwards downlink traffic to the pMAG 🌈. The mobile node can still receive downlink traffic through the pMAG. How the pMAG's access network forwards that downlink traffic to where the mobile node currently is, in the nMAG's access network, during an intra-technology handover? That's out of scope for this description, so we're skipping it 🙈.
When the nMAG gets an indication that the inter-MAG handover is done, it sends another PBU, this time without a Transient Binding option 🎀. That PBU updates the mobile node's transient BCE into a regular PMIPv6 BCE with bi-directional capabilities. The LMA reads this as the signal to switch the tunnel over to the nMAG, and the result is a smoother handover for the MN 💜.
Figure 5 shows an example of using a transient BCE for an intra-technology handover 🍓. When the nMAG notices that the MN is moving from the pMAG's access network into the nMAG's area, it sends a PBU on the MN's behalf to the MN's LMA. In this PBU, the nMAG includes the MN-ID, the HNP, and the interface ID, following the PMIPv6 base protocol [RFC5213] 🦋.
The nMAG also flags the intra-technology handover using the HI option, and it includes the Transient Binding option. That tells the LMA this registration should produce a transient BCE with a late downlink path switch 🔥. The nMAG sets the transient BCE lifetime to a value that depends on the deployment and what the operator wants [D]. Very deployment-specific, bestie 🌸.
Heads up: once the nMAG hears that the MN has finished the handover and the data path is ready to move the tunnel completely from the pMAG to the nMAG, it SHOULD send a PBU. That PBU lets the LMA turn the MN's transient BCE into a regular BCE and switch the data path fully over to the new Proxy-CoA ✨. In this PBU the nMAG sends the MN-ID, Interface ID, and HNP, and it indicates the intra-technology handover with the HI option. The nMAG MUST NOT include the Transient Binding option in this PBU, as shown in Figure 5 [E]. No exceptions, periodt 💀.
What if the nMAG gets downlink traffic for the MN from the LMA after it already sent a PBU with the Transient Binding option? Then the nMAG MUST deliver that downlink traffic to the MN 💖. In that case, the nMAG SHOULD also send a PBU to make sure the transient BCE has been turned into an active BCE 🫶.
Here's the whole picture in Figure 5 👇
+-----+ +----+ +----+ +-----+
| MN | |pMAG| |nMAG| | LMA |
+-----+ +----+ +----+ +-----+
| | | bi-directional |
| |<<<<<<<<======================>>>>>>>>|<-->
| | | |
| | | |
[Handoff Event] | | |
| [MN HO Event] | |
| | [HO Event Acquire] |
| | | |
[LL Attach to | | |
nMAG] | |-----PBU(transient)----->|
| | | [D]
| | |<-----PBA(transient)-----|
| | | |
| | bi-directional |
| |<--->|<<<<<<<<======================>>>>>>>>|<-->
| pAN | | |
| |----------->| | |
| | nAN | |
|<------------------| |uplink only |
|------------------>|---->|>>>>>>===========>>>>>>>>|--->
| | | |
| | [HO Complete] |
| | |----------PBU----------->|
| | | [E]
| | |<---------PBA -----------|
| |` | |
| | |<<<<<<<<=========>>>>>>>>|<-->
| | | |
Figure 5: Transient BCE support for an intra-technology handoverA.2. Use Case for Dual Radio Handover 📱✨
Okay so during an inter-technology handover, the LMA shall, on one hand, be able to accept uplink packets of the MN as soon as the MN has finalized address configuration at the new IF2 and may start using the new interface for data traffic. That means the PBU for the uplink shall be done before the radio setup procedure is finalized. 💖 But the MN still needs to keep sending its data traffic on IF1 during the handover, so uplink packets with the previously existing binding on IF1 shall still be accepted by the LMA until the MN detaches from pMAG with IF1 and the pMAG has deregistered the MN's attachment at the LMA by sending a PBU with lifetime 0. This is a big deal, bestie, because sending the registration PBU from the nMAG is transparent to the mobile node. The MN does not know when the PBU has been sent. 😭
On the other hand, switching the downlink path from the pMAG to the nMAG shall be performed at the LMA only after completion of the IP configuration at the MN's IF2 and after a complete setup of the access link between the MN and the nMAG. How long this takes depends on some interface-specific settings on the MN, as well as on the duration of the target system's radio layer protocols. That part is transparent to the LMA but may be known to MAGs. 🧚
Similar to the use case for single radio handover, a transient BCE can be utilized for MNs with dual radio capability. Such MNs are still able to send and receive data on the previous interface during the address configuration on the new interface, which is so iconic 🦋. Forwarding between the nMAG and pMAG is not required, but the case in which the LMA immediately starts forwarding downlink data packets to the nMAG has to be avoided. 🙈 This is enabled by a PBU that has the Transient Binding option included, so it is not necessary that the MN and LMA synchronize the point in time for switching interfaces and turning a transient BCE into an active BCE. Main character energy, no stress. 👑
When the handover is finalized, the nMAG sends a second PBU without including the Transient Binding option, and the LMA turns the MN's BCE into an active BCE. This PBU may overtake packets-on-the-fly from MN to LMA via pMAG. For example, this can happen if the previous interface was of type GSM or Universal Mobile Telecommunications System (UMTS) with up to 150 milliseconds of uplink delay. The LMA has to drop all these packets from the pMAG due to the characteristics of the MN's active BCE. 💀 This can be avoided by entering another transient BCE state (Transient-A) during the activation phase, and this is characteristic for this use case. Whether or not to enter a Transient-A state is decided by the LMA. 💅
The use of a transient BCE for an inter-technology handover is exemplarily illustrated in Figure 6. The MN attaches to the PMIPv6 network with IF1 according to the procedure described in [RFC5213]. The MN starts receiving data packets on IF1. When the MN activates IF2 to prepare an inter-technology handover, the nMAG receives an attach indication and sends the PBU to the LMA to update the MN's point of attachment and to retrieve configuration information for the MN (e.g., HNP). The LMA is able to identify an inter-technology handover by processing the HI option that comes along with the PBU sent by the nMAG. 🔥 As in this example, the nMAG includes the Transient Binding option in the PBU to control the transient BCE at the LMA. The LMA then updates the MN's BCE according to the transient BCE specification described in this document and marks the state of the BCE as 'transient' [F].
As a result of the transient BCE, the LMA keeps using the previous forwarding information towards the pMAG binding as forwarding information until the transient BCE gets turned into active. The LMA acknowledges the PBU by sending a PBA to the nMAG. The nMAG now has relevant information available, such as the MN's HNP, to set up a radio bearer and send a Router Advertisement to the MN. ✨ While the MN's BCE at the LMA has a transient characteristic, the LMA forwards uplink packets from the MN's pMAG as well as from its nMAG. The nMAG may recognize when the MN's IF2 is able to send and receive data packets, and then it sends a new PBU to the LMA without including the Transient Binding option to initiate turning the MN's transient BCE into an active BCE [G]. As a result of successfully turning the MN's transient BCE into an active BCE, downlink packets will be forwarded towards the MN's IF2 via the nMAG [H]. 🌈
+------+ +----+ +----+ +---+
| MN | |pMAG| |nMAG| |LMA|
+------+ +----+ +----+ +---+
IF2 IF1 | | |
| | | | |
| |- - - - - - - - - Attach | |
| | |---------------PBU--------------->|
| | |<--------------PBA----------------|
| |--------RtSol------->| | |
| |<-------RtAdv--------| | |
| Addr. | | |
| Conf. | | |
| |<------------------->|==================data============|<--->
| | | | |
|- - - - - - - - - - - - - - - - - Attach |
| | | |----PBU(transient)--->|
| | | |<---PBA(transient)---[F]
|------RAT Configuration--------------| |
| |<--------------------|==================data============|<---
|-------RtSol-(optional)------------->| |
|<-----------RtAdv--------------------| |
Addr. | | | |
Conf | | | |
|------------NSol-------------------->|---------PBU-------->[G]
| | | |<--------PBA----------|
|<------------------------------------|========data=========[H]<-->
| | | | |
| | | | |
| | | | |Figure 6: Late path switch with PMIPv6 transient BCEs
Appendix B. Applicability and Use of Static Configuration at the LMA 🎀
During the working group discussion of the functionality introduced by this document, it was mentioned that some current Home Agents are already handling some features and functionality introduced in this document via some static configuration. This Appendix captures the analysis that describes which functionality can be handled securely using a static configuration and which can not. 🧐 In those cases where static configuration can be used, this section documents the possible disadvantages versus using the procedures captured in this document.
B.1. Early Uplink Traffic from the nMAG 🚀
This use case is related to the handoff scenario when the access network establishes the uplink tunnel to the LMA before the downlink portion is done. Consequently, when the mobile node is attached to the nMAG and in the case of active handoff, the UE will start sending uplink traffic to the LMA through the nMAG. 🌸
Since the LMA has a proxy BCE for this mobile node that points to the Proxy-CoA hosted at the pMAG, the LMA has a routing entry for the MN HNP that points to the pMAG-LMA tunnel. Any uplink packet coming from the nMAG will be dropped by the LMA. 🙅♀️
Allowing the LMA to forward the received uplink traffic from the nMAG to the Internet while the MN BCE points to the Proxy-CoA hosted at the pMAG is a violation of all mobility protocols that require a secure signaling exchange between the nMAG and the LMA before forwarding such traffic to the Internet. Otherwise, the LMA will be modifying the mobile node's routing entry based on an unsecured data traffic packet coming from the nMAG. 😱
Therefore, this case cannot be addressed by any statically configured information on the LMA. On the contrary, a secure signaling using Transient Binding option as detailed in this document is required to create a transient state for the mobile node BCE at the LMA. This transient state will allow a temporary routing entry of the mobile node to point to the nMAG Proxy-CoA. 🦋
B.2. Late Uplink Traffic from the pMAG 🍓
This case is a very common case where the mobile node is handing over to another MAG while there is still some uplink traffic in flight coming from the pMAG. In this case, the LMA has the MN BCE pointing to the mobile node's location before the handoff, i.e., pMAG Proxy-CoA. Then the LMA receives a PBU from the nMAG over a secure signaling tunnel, e.g., IPsec tunnel, which indicates some type of handoff as per the value in the handoff indicator mobility option. 💜
If the PBU received from the nMAG was sent using the secure tunnel and successfully processed by the LMA, the LMA according to [RFC5213] switches the IP-in-IP tunnel to point to the nMAG Proxy-CoA. However, as the LMA is fully aware of the mobile node movement via secure signaling from the nMAG and the content of the PBU (which, in particular, contains the Handoff Indicator mobility option), the LMA can process some intelligence to allow the mobile node's late in-flight uplink traffic coming over the pMAG-LMA tunnel to proceed to the Internet. 🧠✨
In order to handle all handoff circumstances, the activation mechanism described in this document is preferable over a statically configured timer. It would dynamically help in ending the late forwarding from the pMAG based on a protected signaling from the pMAG. 🔐💅
B.3. Late Switching of Downlink Traffic to nMAG ⭐
One main use case of transient bindings is the late switching of downlink traffic routing at the LMA. This allows IP mobility protocol signaling between nMAG and LMA to be performed decoupled from the setup of the new link-layer connectivity, e.g., for performing a handover to an interface with time-consuming link setup procedures or for a make-before-break handover between interfaces. 🌈
LMA behavior according to [RFC5213] does not allow for late path switching. The LMA, according to [RFC5213], can only act upon the Handover Indicator and has no information on the time of completion of link layer setup. Even if an LMA implementation were configured to delay the path switching by a fixed time, which would violate [RFC5213], this would not lead to smooth handover performance but would even add latency to the handover. 😤 Only additional signaling as provided by this document provides the information that late switching is applicable and enables a synchronization of the handover sequence. That means the switching is adapted both to the finalization of the link between mobile terminal and nMAG and to the release of the link between mobile terminal and pMAG, whatever comes first. Stable handover performance is achieved using protected PMIPv6 signaling as per [RFC5213]. 🫶
Authors' Addresses ✨
Okay so this is the contact card at the very end of RFC 6058 🎀 Three people wrote it, and each one gets their own little address block so you can actually reach them 💌
Marco Liebsch is the editor, the one who kept the whole thing on track 🫶 He's based at NEC Laboratories Europe, NEC Europe Ltd., Kurfuersten-Anlage 36, 69115 Heidelberg, Germany. You can call him at +49 6221 4342146 or email marco.liebsch@neclab.eu 📞
Next up is Ahmad Muhanna 🦋 He works at Ericsson, 2201 Lakeside Blvd., Richardson, TX 75082, USA. His phone is +1 (972) 583-2769 and his email is ahmad.muhanna@ericsson.com 💖
Last but not least, Oliver Blume 🌸 He was at Alcatel-Lucent Deutschland AG, Bell Labs, Lorenzstr. 10, 70435 Stuttgart, Germany. Phone: +49 711 821-47177. Email: oliver.blume@alcatel-lucent.com 💅
Main character energy for all three of them, no cap 👑
📦 where this page comes from
- ietf: rfc6058 2011-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms