RFC 7429

Distributed Mobility Management: Current Practices and Gap Analysis

📅 published January 2015, from ietf

Distributed Mobility Management: Current Practices and Gap Analysis 💖

okay bestie, this is RFC 7429 🎀 from the IETF, dated January 2015. It's labeled Informational, so it's published for information and isn't a Standards Track spec 🌸 The ISSN is 2070-1721. The editors are D. Liu (China Mobile) and JC. Zuniga (InterDigital), and the other authors are P. Seite (Orange), H. Chan (Huawei Technologies), and CJ. Bernardos (UC3M). The title block doesn't list any RFCs that this one obsoletes or updates 🧚

Abstract ✨

so this doc looks at how existing IP mobility protocols are actually deployed in a distributed mobility management environment 🦋 Then it calls out the limitations it finds when you compare them to the requirements for a distributed mobility management solution. it's giving research + honesty energy 💅

Status of This Memo 🌈

this document is not an Internet Standards Track specification 🙈 It's published for informational purposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7429.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Functions of Existing Mobility Protocols  . . . . . . . . . .   4
4.  DMM Practices . . . . . . . . . . . . . . . . . . . . . . . .   5
  4.1.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .   5
  4.2.  IP Flat Wireless Network  . . . . . . . . . . . . . . . .   6
    4.2.1.  Host-Based IP DMM Practices . . . . . . . . . . . . .   7
    4.2.2.  Network-Based IP DMM Practices  . . . . . . . . . . .  12
  4.3.  Flattening 3GPP Mobile Network Approaches . . . . . . . .  15
5.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .  19
  5.1.  Distributed Mobility Management - REQ1  . . . . . . . . .  19
  5.2.  Bypassable Network-Layer Mobility Support for Each
        Application Session - REQ2  . . . . . . . . . . . . . . .  21
  5.3.  IPv6 Deployment - REQ3  . . . . . . . . . . . . . . . . .  22
  5.4.  Considering Existing Mobility Protocols - REQ4  . . . . .  23
  5.5.  Coexistence with Deployed Networks/Hosts and Operability
        across Different Networks - REQ5  . . . . . . . . . . . .  23
  5.6.  Operation and Management Considerations - REQ6  . . . . .  23
  5.7.  Security Considerations - REQ7  . . . . . . . . . . . . .  24
  5.8.  Multicast Considerations - REQ8  . . .  . . . . . . . . .  25
  5.9.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  25
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .  28
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  28
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  33
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33

1. Introduction 🎀

okay so existing network-layer mobility management protocols mostly use a mobility anchor 🦋 The anchor keeps a mobile node connected by forwarding packets that are going to the node, or coming from it, after the node moves to a different network. The anchor is deployed centrally, which means one anchor usually manages the traffic of millions of mobile nodes in an operator network. literally a lot of pressure on one spot 😭 This centralized setup for managing IP sessions causes several problems. To deal with them, a distributed mobility management (DMM) architecture has been proposed 💜

This document checks whether it's doable to deploy current IP mobility protocols in a DMM scenario so they meet the requirements in [RFC7333]. It also looks at current deployment practices for existing mobility protocols, and it finds the limitations (gaps) in those practices when it comes to meeting DMM requirements ✨ The analysis is mainly aimed at IPv6 deployment, but it can also apply to IPv4 wherever there are IPv4 counterparts equivalent to the IPv6 mobility protocols 🌸

The rest of this document is organized as follows. Section 3 analyzes existing IP mobility protocols by looking at their functions and how those functions can be configured and used to work in a DMM environment. Section 4 presents current practices in IP wireless networks and 3GPP architectures, and both network-based and host-based mobility protocols are covered. Section 5 presents the gap analysis against those current practices 🧚

2. Terminology 💅

All general mobility-related terms and their acronyms used in this document are to be interpreted as defined in the Mobile IPv6 base specification [RFC6275], in the Proxy Mobile IPv6 specification [RFC5213], and in the Distributed Mobility Management Requirements [RFC7333]. These terms include mobile node (MN), correspondent node (CN), home agent (HA), local mobility anchor (LMA), mobile access gateway (MAG), centrally deployed mobility anchors, distributed mobility management, hierarchical mobile network, flatter mobile network, and flattening mobile network. 🫶

In addition, this document also introduces some definitions of IP mobility functions in Section 3.

In this document there are also references to a "distributed mobility management environment." By this term, we refer to a scenario in which the IP mobility, access network, and routing solutions allow for setting up IP networks so that traffic is distributed in an optimal way without relying on centrally deployed mobility anchors to manage IP mobility sessions 👑

3. Functions of Existing Mobility Protocols 🦋

the host-based Mobile IPv6 (MIPv6) [RFC6275] and its network-based extension, Proxy Mobile IPv6 (PMIPv6) [RFC5213], plus Hierarchical Mobile IPv6 (HMIPv6) [RFC5380], are logically centralized mobility management approaches. They mainly address hierarchical mobile networks. even though they're centralized, they've got important mobility management functions that came out of years of serious work to develop and extend them 🙌 So it's useful to take those existing functions and look at them in a DMM scenario, to understand how to deploy the existing mobility protocols for distributed mobility management 💖

The main mobility management functions of MIPv6, PMIPv6, and HMIPv6 are the following:

  1. Anchoring Function (AF): allocation to a mobile node of an IP address, i.e., Home Address (HoA), or prefix, i.e., Home Network Prefix (HNP), topologically anchored by the advertising node. That is, the anchor node is able to advertise a connected route into the routing infrastructure for the allocated IP prefixes. This function is a control-plane function.
  2. Internetwork Location Management (LM) function: managing and keeping track of the internetwork location of an MN. The location information may be a binding of the advertised IP address/prefix, e.g., HoA or HNP, to the IP routing address of the MN, or it may be a binding of a node that can forward packets destined to the MN. It is a control-plane function.

In a client-server protocol model, location query and update messages may be exchanged between a Location Management client (LMc) and a Location Management server (LMs).

  1. Forwarding Management (FM) function: packet interception and forwarding to/from the IP address/prefix assigned to the MN, based on the internetwork location information, either to the destination or to some other network element that knows how to forward the packets to their destination.

FM may optionally be split into the control plane (FM-CP) and data plane (FM-DP).

In Mobile IPv6, the home agent (HA) typically provides the AF; the LMs is at the HA, whereas the LMc is at the MN; the FM function is distributed between the ends of the tunnel at the HA and the MN.

In Proxy Mobile IPv6, the local mobility anchor (LMA) provides the AF; the LMs is at the LMA, whereas the LMc is at the MAG; the FM function is distributed between the ends of the tunnel at the LMA and the MAG.

In HMIPv6 [RFC5380], the Mobility Anchor Point (MAP) serves as a location information aggregator between the LMs at the HA and the LMc at the MN. The MAP also provides the FM function to enable tunneling between HA and itself, as well as tunneling between the MN and itself. 🌈

4. DMM Practices ⭐

This section documents deployment practices of existing mobility protocols to satisfy distributed mobility management requirements. This description considers both IP wireless networks, e.g., evolved Wi-Fi hotspots, and 3GPP flattening mobile networks 🍓

While describing the current DMM practices, the section provides references to the generic mobility management functions described in Section 3, as well as some initial hints on the identified gaps with respect to the DMM requirements documented in [RFC7333]. 💜

4.1. Assumptions ✨

okay so there are SO many ways you could build a distributed anchoring and mobility setup 🧚 the gap analysis is mostly looking at current mobile network architectures and the standardized IP mobility solutions we already have, and it's only considering deployment options that don't break the original protocol specs 💅 to keep the DMM practices analysis from getting out of hand, we're going with these technical assumptions:

  1. Both host- and network-based solutions are considered. 🎀
  2. Solutions should allow selecting and using the most appropriate IP anchor among a set of available candidates. 💖
  3. Mobility management should be realized by the preservation of the IP address across the different points of attachment (i.e., provision of IP address continuity). This is in contrast to certain transport-layer-based approaches such as Stream Control Transmission Protocol (SCTP) [RFC4960] or application-layer mobility. 🦋

applications that can handle their IP address changing don't need IP mobility management protocols like DMM at all 🙈 usually a connection manager plus the operating system will set up the source address selection mechanism of the IP stack. this might mean figuring out what the app can do and turning on mobility support to match ✨ application management and source address selection are out of scope for this doc, but you can totally check out [RFC6724] if you want to go deeper 🫶

4.2. IP Flat Wireless Network 🌸

this section is all about common IP wireless network architectures and how we can flatten them from an IP mobility and anchoring point of view, using common and standardized protocols 🧚 we're using Wi-Fi as our example wireless tech since it's super well known and everywhere right now 📶 Figure 1 shows some representative Wi-Fi deployment setups:

                   +-------------+             _----_
  +---+            |   Access    |           _(      )_
  |AAA|. . . . . . | Aggregation |----------( Internet )
  +---+            |   Gateway   |           (_      _)
                   +-------------+             '----'
                      |  |   |
                      |  |   +-------------+
                      |  |                 |
                      |  |              +-----+
      +---------------+  |              | AR  |
      |                  |              +--+--+
   +-----+            +-----+         *----+----*
   | RG  |            | WLC |        (    LAN    )
   +-----+            +-----+         *---------*
      .                /   \            /     \
     / \          +-----+ +-----+  +-----+   +-----+
    /   \         |Wi-Fi| |Wi-Fi|  |Wi-Fi|   |Wi-Fi|
  MN1   MN2       | AP1 | | AP2 |  | AP3 |   | AP4 |
                  +-----+ +-----+  +-----+   +-----+
                     .                .
                    / \              / \
                   /   \            /   \
                  MN3  MN4         MN5  MN6

              Figure 1: IP Wi-Fi Network Architectures

so Figure 1 shows three typical deployment options [COMMUNITY-WIFI] 🍓 on the left, mobile nodes MN1 and MN2 connect straight to a Residential Gateway (RG) at the customer premises 🏠 the RG runs the 802.11 Access Point (AP) function so it can offer wireless Layer 2 access, and it also handles Layer 3 routing 🛜 in the middle, MN3 and MN4 hook up to Wi-Fi access points AP1 and AP2, which are managed by a Wireless LAN Controller (WLC) 🎛️ the WLC handles radio resource management on the APs, domain-wide mobility policy enforcement, and centralized forwarding for user traffic ✨ it could also do Layer 3 routing or plug into an access router (AR) 🔥 last but not least, on the right, AP3 and AP4 are directly connected to an access router 💜 this one can also work as a generic connectivity model 👑

IP mobility protocols can give heterogeneous network mobility support to users, like handing over from Wi-Fi to cellular access 📱 two kinds of protocols can do this: Proxy Mobile IPv6 [RFC5213] or Mobile IPv6 [RFC5555] 😭 the mobility anchor role (like a local mobility anchor or home agent) usually gets played by the edge router of the mobile network [SDO-3GPP.23.402] 🌈

we've been using Wi-Fi as the example here, but other flattening mobile network architectures exist too, like Worldwide Interoperability for Microwave Access (WiMAX) [IEEE.802-16.2009], which bakes in both host- and network-based IP mobility functions 🦋

existing IP mobility protocols can also be deployed in a flatter way, so the anchoring and access aggregation functions get distributed ✨ next up, we describe several practices for deploying existing mobility protocols in a distributed mobility management environment 🧚 this analysis only covers protocol solutions built on existing IP mobility protocols, whether host- or network-based, like Mobile IPv6 [RFC6275] [RFC5555], Proxy Mobile IPv6 (PMIPv6) [RFC5213] [RFC5844], and the Network Mobility (NEMO) Basic Support Protocol [RFC3963] 💅 extensions to these base protocol solutions are considered too, and the analysis is split into two parts: host-based and network-based practices 🫶

4.2.1. Host-Based IP DMM Practices ✨

Okay so, Mobile IPv6 (MIPv6) [RFC6275] and its mobile-networks upgrade, the NEMO Basic Support protocol (I'll just call it NEMO from here, bestie) [RFC3963], are the OG host-based IP mobility protocols 💜. They rely on the home agent (HA), a centralized anchor, to give mobile nodes (hosts and routers) their mobility support 🧚. The HA usually handles the AF, FM function, and Location Management server (LMs) functions. The mobile node brings the Location Management client (LMc) function and the FM function so it can tunnel between the HA and itself 🫶. Next we'll look at some practices showing how MIPv6/NEMO and a few other protocol extensions can be deployed in a distributed mobility management environment 🦋.

One way to spread out the anchors is to deploy several HAs (see Figure 2) and give each MN the topologically closest anchor [RFC4640] [RFC5026] [RFC6611] 🌸. In the Figure 2 example, MN1 is assigned to HA1 and uses a home address anchored by HA1 to talk to CN1. MN2 gets the same treatment with HA2 and a home address anchored by HA2 to talk to CN2 💅. Note that MIPv6/NEMO specs do not stop one mobile node from using multiple home agents at the same time. In this model, the mobile node can use several anchors at once, with each one anchoring the IP flows that started at a different point of attachment 🎀. The catch? There is currently no mechanism specified in IETF standards for efficiently discovering available anchors and picking the most suitable one 😭.

    <-INTERNET-> <- HOME NETWORK -> <------- ACCESS NETWORK ------->
     +-----+                            +-----+       +--------+
     | CN1 |---                      ===| AR1 |=======|   MN1  |
     +-----+   \   +-----------+   //   +-----+       |(FM,LMc)|
                ---|    HA1    |===                   +--------+
                   |(AF,FM,LMs)|        +-----+       (anchored
                   +-----------+        | AR2 |          at HA1)
                                        +-----+
     +-----+       +-----------+
     | CN2 |-------|    HA2    |===
     +-----+       |(AF,FM,LMs)|   \\   +-----+=======+--------+
                   +-----------+     ===| AR3 |       |   MN2  |
                                        +-----+-------|(FM,LMc)|
     +-----+                              /           +--------+
     | CN3 |-----------------------------/            (anchored
     +-----+                                             at HA2)
                                        +-----+
                                        | AR4 |
                                        +-----+

    CN1   CN2  CN3   HA1   HA2         AR1   AR3      MN1    MN2
     |     |    |     |     |           |     |        |      |
     |<-------------->|<======tunnel====+=============>|      | BT mode
     |     |    |     |     |           |     |        |      |
     |     |<-------------->|<======tunnel====+==============>| BT mode
     |     |    |     |     |           |     |        |      |
     |     |    |<----------------------------+-------------->| RO mode
     |     |    |     |     |           |     |        |      |

      Figure 2: Distributed Operation of Mobile IPv6 (BT and RO)/NEMO

One big goal of running mobility protocols in a distributed mobility management environment is dodging the suboptimal routing that comes with centralized anchoring 🙅‍♀️. This is where Route Optimization (RO) support from Mobile IPv6 can help, giving you a flatter IP data forwarding path ✨. By default, Mobile IPv6 and NEMO use the so-called Bidirectional Tunnel (BT) mode, where data traffic is always encapsulated between the MN and its HA before it goes on to any other destination 🌈. The RO mode lets the MN update its current location on the CNs and then use the direct path between them 👑. Using the Figure 2 example, MN1 and MN2 are in BT mode with CN1 and CN2 respectively, while MN2 is in RO mode with CN3. Still, the RO mode has some drawbacks, and honestly they're a lot:

  • The RO mode is only supported by Mobile IPv6. There is no route optimization support standardized for the NEMO protocol because of the security problems posed by extending return routability tests for prefixes, although many different solutions have been proposed [RFC4889].
  • The RO mode requires signaling that adds some protocol overhead.
  • The signaling required to enable RO involves the home agent and is repeated periodically for security reasons [RFC4225]. Therefore, the HA remains a single point of failure.
  • The RO mode requires support from the CN.

Still, the RO mode does have the power to substantially cut down traffic going through the home agent, as long as the relevant correspondent nodes can support it 💖. Also, a mobile node can use its Care-of Address (CoA) directly [RFC5014] when talking to CNs on the same link or anywhere on the Internet. Just know that the IP stack won't provide any session continuity support in this case 🙈.

HMIPv6 [RFC5380], shown in Figure 3, is another host-based IP mobility extension that can complement the others to make the whole deployment less centralized 🍓. It cuts down on the amount of mobility signaling and improves the overall handover performance of Mobile IPv6 by adding a new hierarchy level to handle local mobility 🧚. That new level is the Mobility Anchor Point (MAP), a local mobility handling node deployed closer to the mobile node. The MAP provides LM intermediary function between the LMs at the HA and the LMc at the MN. It also performs the FM function to tunnel with the HA and with the MN 🔥.

    <INTERNET> <- HOME NETWORK -> <---------- ACCESS NETWORK ---------->
                                                   LCoA anchored
                                                      at AR1
                                                       +---+  +--------+
                                                    ===|AR1|==|   MN1  |
     +-----+    +-----------+      +----------+   //   +---+  |(FM,LMc)|
     | CN1 |----|    HA1    |======|   MAP1   |===            +--------+
     +-----+    |(AF,FM,LMs)|     /|(AF,FM,LM)|        +---+        HoA,
                +-----------+    / +----------+        |AR2|       RCoA,
                 HoA anchored   /  RCoA anchored       +---+       LCoA
                    at HA1     /      at MAP1
                              /                        +---+
                             /                         |AR3|
     +-----+                /      +----------+        +---+
     | CN2 |----------------       |   MAP2   |
     +-----+                       |(AF,FM,LM)|        +---+
                                   +----------+        |AR4|
                                                       +---+
    CN1   CN2        HA1               MAP1             AR1     MN1
     |     |          |                 |                |       |
     |<-------------->|<===============>|<====tunnel============>| HoA
     |     |          |                 |                |       |
     |     |<-------------------------->|<====tunnel============>| RCoA
     |     |          |                 |                |       |

                    Figure 3: Hierarchical Mobile IPv6

When HMIPv6 is in use, the MN gets two temporary addresses: the Regional Care-of Address (RCoA) and the Local Care-of Address (LCoA) 🎀. The RCoA is anchored at one MAP, which acts as a local home agent, while the LCoA is anchored at the access-router level. The mobile node uses the RCoA as the CoA it signals to its home agent. So while roaming inside a local domain handled by the same MAP, the mobile node doesn't need to update its home agent, meaning it does not change its RCoA 💅.

HMIPv6 also gives you a form of route optimization, since a mobile node might decide to use the RCoA directly as the source address for communicating with a given correspondent node 🦋. This is especially true if the MN doesn't expect to leave the local domain during the lifetime of that communication. It can be seen as a potential DMM mode of operation, though it doesn't provide session continuity if the MN moves outside the local domain 😭. In the Figure 3 example, MN1 uses its global HoA to talk to CN1, while it uses its RCoA to talk to CN2 ✨.

A local domain can also have several MAPs deployed, which opens up different kinds of HMIPv6 deployments that are flatter and more distributed 🌸. The HMIPv6 specification supports flexible MAP selection, including selection based on the MN's expected mobility pattern or on the distance between the MN and the MAP 🧚.

Another extension that can help distribute mobility management functions is the Home Agent switch specification [RFC5142]. It defines a new mobility header to signal to a mobile node that it should acquire a new home agent 🍓. [RFC5142] doesn't cover changing the mobile node's home address, because that might mean losing connectivity for ongoing persistent connections 🙈. Still, that specification could be used to force a change of home agent in situations where there are no active persistent data sessions that can't cope with a home address change 💜.

There are other standardized host-based approaches for mobility support too 🌈. For example, IKEv2 Mobility and Multihoming (MOBIKE) [RFC4555] lets a mobile node encrypting traffic through Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296] change its point of attachment while keeping a Virtual Private Network (VPN) session alive 🔐. MOBIKE can update the VPN Security Associations (SAs) when the base connection that was initially used is lost and needs to be re-established, and using it means you don't have to do a full IKEv2 renegotiation 🙌. Similar considerations to those for Mobile IPv6 apply to MOBIKE, though MOBIKE is best suited for situations where the address of at least one endpoint is relatively stable and can be discovered using existing mechanisms such as DNS 👑.

Extensions have also been defined to optimize handover performance in the mobility protocol 🔥. Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] is the extension that targets handover latency. It defines a new access router discovery mechanism that runs before handover, which reduces the new network discovery latency. It also defines a tunnel between the previous access router and the new access router to reduce packet loss during handover 💖. The Candidate Access Router Discovery (CARD) [RFC4066] and Context Transfer Protocol (CXTP) [RFC4067] protocols were also standardized to improve handover performance 🫶. The DMM deployment practice discussed in this section can use those extensions too, to make handovers even smoother ✨.

4.2.2. Network-Based IP DMM Practices ✨

Okay so, the main network-based IP mobility protocol for IPv6 is Proxy Mobile IPv6 (PMIPv6) [RFC5213] 💅, and Proxy Mobile IPv4 [RFC5844] 🦋 adds some IPv4 extensions. In these setups the LMA usually handles the AF, FM function, and Location Management server (LMs) function 👑. The mobile access gateway (MAG) takes the Location Management client (LMc) function and the FM function so it can tunnel with the LMA 🎀. PMIPv6 is architecturally almost identical to MIPv6 🫶, because the mobility signaling and routing between LMA and MAG is basically like what goes on between the HA and MN in MIPv6 😭. The MAG also supplies the mobility functionality the MN needs, so the MN's involvement in mobility support is not required 🌸.

We're next going to look at some practices showing how network-based mobility protocols and several other protocol extensions can be deployed in a distributed mobility management environment 🧚.

One way to decentralize Proxy Mobile IPv6 operation is to deploy several LMAs and use some selection criteria to assign LMAs to attaching mobile nodes 💖. Figure 4 shows an example of this kind of assignment 👀:

 <INTERNET> <--- HOME NETWORK ---> <------ ACCESS NETWORK ------->
                                             +--------+      +---+
                                      =======|  MAG1  |------|MN1|
 +-----+       +-----------+       //       |(FM,LMc)|      +---+
 | CN1 |-------|    LMA1   |=======         +--------+
 +-----+       |(AF,FM,LMs)|
               +-----------+                +--------+
 +-----+                                    |  MAG2  |
 | CN2 |---                                 |(FM,LMc)|
 +-----+   \   +-----------+                +--------+
            ---|    LMA2   |=======
 +-----+       |(AF,FM,LMs)|       \\       +--------+      +---+
 | CN3 |       +-----------+         =======|  MAG3  |------|MN2|
 +-----+                                    |(FM,LMc)|      +---+
                                            +--------+
CN1   CN2        LMA1  LMA2                  MAG1 MAG3     MN1  MN2
 |     |          |     |                     |    |        |    |
 |<-------------->|<===========tunnel========>|<----------->|    |
 |     |          |     |                     |    |        |    |
 |     |<-------------->|<=====tunnel=============>|<----------->|
 |     |          |     |                     |    |        |    |

       Figure 4: Distributed Operation of Proxy Mobile IPv6

Just like with the client-based approach 🔥, a mobile node can use several anchors at the same time, with each one anchoring the IP flows that started at a different point of attachment 🦋. This assignment can be static or dynamic 🌈. The big perk of this simple approach is that the IP address anchor (aka the LMA) can be placed closer to the mobile node, so the resulting paths are close to optimal ✨. The catch? Once the mobile node moves, the path starts drifting away from that optimal one 💀.

Network-based IP mobility also has some extensions, similar to the host-based case, that are designed to reduce the suboptimal routing problems that can pop up because of a centralized anchor 🙈. The Local Routing extensions [RFC6705] make optimal routing possible in Proxy Mobile IPv6 in three situations 🍓:

  • i) when two communicating MNs are attached to the same MAG and LMA,
  • ii) when two communicating MNs are attached to different MAGs but to the same LMA, and
  • iii) when two communicating MNs are attached to the same MAG but have different LMAs.

In all three of these cases, traffic between the two mobile nodes doesn't go through the LMA(s), because it gets routed locally at the edge 💜. That's a form of path optimization, iykyk 😌. The main downside is that it only handles MN-to-MN communication, and only under certain circumstances 🥺.

Another cool extension that can make network-based mobility protocols easier to deploy in a distributed mobility management environment is the support of runtime LMA assignment described in [RFC6463] 🧁. This extension defines a runtime LMA assignment functionality plus corresponding mobility options for Proxy Mobile IPv6 💅. The runtime assignment happens during the Proxy Binding Update / Proxy Binding Acknowledgment message exchange between a mobile access gateway and an LMA 📨. It's mainly aimed at load balancing, but it can also be used to pick an optimal LMA from the routing point of view 🎯.

Runtime LMA assignment can change the assigned LMA of an MN, for example when the mobile node doesn't have any active session, or when the running sessions can survive an IP address change 🦋. Also, several possible dynamic LMA discovery solutions can be used, as described in [RFC6097] 🔍.

4.3. Flattening 3GPP Mobile Network Approaches ✨

okay so 3GPP is the standards body behind the 3rd generation mobile network and the Evolved Packet System (EPS) 📡 [SDO-3GPP.23.402]. EPS is mainly made of the Evolved Packet Core (EPC) plus a brand new radio access network, usually called LTE (Long Term Evolution) 💜

Architecturally, the 3GPP EPC is lowkey giving an IP wireless network running PMIPv6 or MIPv6 🎀 It leans on the Packet Data Network Gateway (P-GW) as an anchor to give mobile nodes their mobility support (check Figure 5 👇). 3GPP has both client-based and network-based mobility solutions, and for simplicity we'll look at them together 🫶 Next up, we'll see how 3GPP mobility protocols and a few other finished or in-progress extensions can be deployed to hit some of the DMM requirements [RFC7333] 🦋

          +---------------------------------------------------------+
          |                           PCRF                          |
          +-----------+--------------------------+----------------+-+
                      |                          |                |
 +----+   +-----------+------------+    +--------+-----------+  +-+-+
 |    |   |          +-+           |    |  Core Network      |  |   |
 |    |   | +------+ |S|__         |    | +--------+  +---+  |  |   |
 |    |   | |GERAN/|_|G|  \        |    | |  HSS   |  |   |  |  |   |
 |    +-----+ UTRAN| |S|   \       |    | +---+----+  |   |  |  | E |
 |    |   | +------+ |N|  +-+-+    |    |     |       |   |  |  | x |
 |    |   |          +-+ /|MME|    |    | +---+----+  |   |  |  | t |
 |    |   | +---------+ / +---+    |    | |  3GPP  |  |   |  |  | e |
 |    +-----+ E-UTRAN |/           |    | |  AAA   |  |   |  |  | r |
 |    |   | +---------+\           |    | | SERVER |  |   |  |  | n |
 |    |   |             \ +----+   |    | +--------+  |   |  |  | a |
 |    |   |   3GPP AN    \|S-GW+---- S5---------------+ P |  |  | l |
 |    |   |               +----+   |    |             | - |  |  |   |
 |    |   +------------------------+    |             | G |  |  | I |
 | UE |                                 |             | W |  |  | P |
 |    |   +------------------------+    |             |   +-----+   |
 |    |   |+-------------+ +------+|    |             |   |  |  | n |
 |    |   || Untrusted   +-+ ePDG +-S2b---------------+   |  |  | e |
 |    +---+| non-3GPP AN | +------+|    |             |   |  |  | t |
 |    |   |+-------------+         |    |             |   |  |  | w |
 |    |   +------------------------+    |             |   |  |  | o |
 |    |                                 |             |   |  |  | r |
 |    |   +------------------------+    |             |   |  |  | k |
 |    +---+  Trusted non-3GPP AN   +-S2a--------------+   |  |  | s |
 |    |   +------------------------+    |             |   |  |  |   |
 |    |                                 |             +-+-+  |  |   |
 |    +--------------------------S2c--------------------|    |  |   |
 |    |                                 |                    |  |   |
 +----+                                 +--------------------+  +---+

    where E-UTRAN - Evolved Universal Terrestrial Radio Access Network
          GERAN   - GSM EDGE Radio Access Network
          HSS     - Home Subscriber Server
          MME     - Mobility Management Entity
          PCRF    - Policy and Charging Rule Function
          SGSN    - Serving GPRS Support Node
          UTRAN   - Universal Terrestrial Radio Access Network

            Figure 5: EPS (Non-roaming) Architecture Overview

The GPRS Tunneling Protocol (GTP) 🧚 [SDO-3GPP.29.060] [SDO-3GPP.29.281] [SDO-3GPP.29.274] is a network-based mobility protocol for 3GPP networks, covering the S2a, S2b, S5, and S8 interfaces. Like PMIPv6, it can handle mobility without the mobile nodes needing to be involved 🙈 Instead, the mobile node functionality gets handled by proxy, by the Serving Data Gateway (S-GW), the Evolved Packet Data Gateway (ePDG), or the Trusted Wireless Access Gateway (TWAG [SDO-3GPP.23.402]) .

3GPP specs also cover client-based mobility support 💅 It's built on Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for the S2c interface [SDO-3GPP.24.303]. In this setup, the User Equipment (UE) runs the binding update functionality, and the P-GW plays the home agent role 👑

Now, a Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) enabled network [SDO-3GPP.23.401] can offload some IP services at the local access network, above the Radio Access Network (RAN), so the traffic doesn't have to travel all the way back to the P-GW (see Figure 6) 🌸

   +---------+ IP traffic to mobile operator's CN
   |  User   |....................................(Operator's CN)
   | Equipm. |..................
   +---------+                 . Local IP traffic
                               .
                         +-----------+
                         |Residential|
                         |enterprise |
                         |IP network |
                         +-----------+

                       Figure 6: LIPA Scenario

SIPTO lets an operator offload certain types of traffic at a network node close to the UE's point of attachment to the access network. To do this, it picks a set of GWs (S-GW and P-GW1 in the figure below) that are geographically or topologically close to that point of attachment 🍓

                      SIPTO Traffic
                           |
                           .
                           .
                       +-------+        +------+
                       | P-GW1 |   ---- | MME  |
                       +-------+  /     +------+
                            |    /
 +------+     +-----+   +------+/       +-------+
 |  UE  |.....| eNB |...| S-GW |........| P-GW2 |... CN Traffic
 +------+     +-----+   +------+        +-------+

                    Figure 7: SIPTO Architecture

LIPA, on the other hand, lets an IP addressable UE connected via a Home evolved Network B (HeNB) reach other IP addressable entities in the same residential or enterprise IP network, without crossing the mobile operator's network core in the user plane 🏠 To make that happen, a Local GW (L-GW) collocated with the HeNB gets used. To set up LIPA, the UE requests a new Public Data Network (PDN) connection to an access point name where LIPA is permitted, the network selects the Local GW associated with the HeNB, and then the network turns on a direct user-plane path between the Local GW and the HeNB ⭐

 +------------+  +------+  +----------+  +-------------+    =====
 |Residential |  | HeNB |  | Backhaul |  |Mobile       |   ( IP  )
 |Enterprise  |..|------|..|          |..|Operator     |..(Network)
 |Network     |  | L-GW |  |          |  |Core network |   =======
 +------------+  +------+  +----------+  +-------------+
                    /
                    |
                    /
                +-----+
                | UE  |
                +-----+

                     Figure 8: LIPA Architecture

The 3GPP architecture specs also have mechanisms for discovering and selecting gateways [SDO-3GPP.29.303] 🔍 These mechanisms make decisions that take topological location and gateway collocation into account, and they rely on the DNS as a "location database" 🧠

Real talk: both SIPTO and LIPA have very limited mobility support, especially in 3GPP specs up to Rel-12 😭 LIPA mobility is limited to handovers between HeNBs that are managed by the same L-GW (i.e., mobility within the local domain). And there is no guarantee of IP session continuity for SIPTO. Yikes 💀

5. Gap Analysis 💅

This section is where we check the limitations in the current practices, described in Section 4, against the DMM requirements listed in [RFC7333]. Let's see what's missing 🔥

5.1. Distributed Mobility Management - REQ1 💖

okay so, REQ1 comes from [RFC7333], and it says IP mobility, network access, and forwarding solutions provided by DMM must make it possible for traffic to avoid traversing a single mobility anchor that's far from the optimal route 🦋 no single far-away anchor should be the bottleneck, bestie 😭

From the analysis in Section 4, a DMM deployment can meet the requirement "REQ1 Distributed mobility management" usually by relying on the following functions:

  • Multiple (distributed) anchoring: the ability to anchor different sessions of a single mobile node at different anchors. To get better routing, some anchors might need to sit closer to the mobile node or to the corresponding node 🌸
  • Dynamic anchor assignment/re-location: the ability to i) assign the initial anchor, and ii) dynamically change the initially assigned anchor and/or assign a new one. This may also require transferring mobility context between anchors. It can be done either by switching the anchor for all ongoing sessions, or by assigning new anchors just for new sessions 🧚

GAP1-1: Okay, the main client-based and network-based IP mobility protocols (namely MIPv6, DSMIPv6, and PMIPv6) already let you deploy multiple anchors (home agents and localized mobility anchors), so the multiple anchoring function is covered ✨ BUT existing solutions only do an initial anchor assignment, so the lack of dynamic anchor change and new anchor assignment is a gap 💀 Neither the HA switch nor the LMA runtime assignment lets you change the anchor during an ongoing session. This is actually several gaps in a trench coat: being able to do anchor assignment at any time (not only when the MN first attaches), the current anchor being able to initiate or trigger the relocation, and being able to transfer registration context between anchors 🍓

GAP1-2: Dynamic anchor assignment may lead the MN to manage different mobility sessions served by different mobility anchors. This is not an issue with client-based mobility management, because the mobility client natively knows which anchor goes with each of its mobility sessions 💅 However, there is one gap: the MN should be capable of handling IP addresses in a DMM-friendly way, meaning the MN can do smart source address selection (i.e., deprecating IP addresses from previous mobility anchors so they aren't used for new sessions) 🙈 Besides, managing different mobility sessions served by different mobility anchors may raise issues with network-based mobility management. Here, the mobile client located in the network (e.g., MAG) usually gets the MN's anchor from the MN's policy profile, as described in Section 6.2 of [RFC5213]. Right now, the MN's policy profile implicitly assumes a single serving anchor, so it doesn't keep track of the association between home network prefix and anchor. Not it 😤

GAP1-3: Once the mobility anchors are distributed, there might be more than one available anchor for a mobile node to use, and that creates an anchor discovery and selection issue 🔥 Currently there's no efficient mechanism specified for dynamically discovering which nodes can play the anchor role, discovering their capabilities, and picking the most suitable one. There's also no mechanism for selecting the node that is currently anchoring a given home address/prefix (a capability sometimes required to meet REQ#2). That said, some mechanisms could help with discovering anchors: Dynamic Home Agent Address Discovery (DHAAD) [RFC6275], the home agent flag (H) in Router Advertisements (which indicates that the router sending the Router Advertisement is also functioning as a Mobile IPv6 home agent on the link), or the MAP option in Router Advertisements defined by HMIPv6. Also, 3GPP has mechanisms that provide that functionality, defined in [SDO-3GPP.29.303] 🌈

Regarding being able to transfer registration context between anchors, there are already some solutions that could be reused or adapted to fill that gap 🫶 For example, Fast Handovers for Mobile IPv6 [RFC5568] can redirect traffic from the old anchor to the new one, the Context Transfer Protocol [RFC4067] can transfer the registration information between anchors, and the Handover Keying architecture solutions [RFC6697] can speed up re-authentication after an anchor change. Just know that some extensions might be needed for DMM, since these protocols were designed for centralized client IP mobility (focused on access reattachment and authentication) 🧸

GAP1-4: Also, REQ1 is meant to stop data-plane traffic from taking a suboptimal route. So distributed processing of the traffic may only be needed in the data plane. Providing this distributed processing capability should not conflict with using a centralized control plane. Other control-plane solutions (such as charging, lawful interception, etc.) should not be constrained by the DMM solution. On the flip side, combining the control-plane and data-plane forwarding management (FM) function may limit your choices to solutions that distribute both the data plane and the control plane together. To distribute only the data plane without distributing the control plane, you'd need to split the forwarding management function into a control-plane component (FM-CP) and a data-plane component (FM-DP), and there is currently a gap here 🦋

5.2. Bypassable Network-Layer Mobility Support for Each Application Session - REQ2 🎀

The REQ2 requirement for "bypassable network-layer mobility support for each application session," introduced in [RFC7333], is all about flexibility in deciding whether network-layer mobility support is needed at all 👑 It lets you choose whether or not to use network-layer mobility support. Two functions are needed for this:

  • Dynamically assign/relocate anchor: a mobility anchor is assigned only to sessions that use network-layer mobility support. So the MN may manage more than one session, where some are tied to anchored IP address(es) and others are tied to local IP address(es) 🌸
  • Multiple IP address management: this one goes hand in hand with the item above. It's about the mobile node's ability to use multiple IP addresses at the same time and pick the best one (from an anchoring point of view) for each session/application/service. For this, the MN needs to get information about the properties of its available IP addresses 🧚

GAP2-1: Dynamic anchor assignment/relocation needs to guarantee IP address continuity for sessions that use that mobility support at the relocated anchor (e.g., in some scenarios, providing mobility only within a limited area might be enough from the point of view of the mobile node or the application) ✨ Implicitly, DMM may release the needed resources when no applications are using network-layer mobility support. So DMM is potentially required to know which sessions at the mobile node are active and using mobility support. Typically, only the MN knows this (e.g., through its connection manager), and it would require some signaling support, such as socket API extensions, so applications can tell the IP stack whether or not mobility support is required. This may imply knowing which sessions at the mobile node are active and using mobility support. Again, that's something typically known only by the MN (e.g., by its connection manager), and it would also typically need signaling support, such as socket API extensions, from applications to indicate whether mobility support is required 🔥 So (part of) this knowledge might need to be transferred to, or shared with, the network 🫶

GAP2-2: Managing multiple IP addresses gives the MN the choice to pick the right address (e.g., one provided with mobility support or one not provided with it) depending on the application's requirements 💅 With client-based mobility management, the MN itself knows the anchoring capabilities of its assigned IP addresses. That isn't necessarily the case with network-based IP mobility management, because current mechanisms don't let the MN know the properties of its IP addresses. For example, the MN doesn't know whether or not its allocated IP addresses are anchored. However, there are proposals like [CLASS-PREFIX], [PREFIX-PROPERTIES], and [MULTI-ARCH], where the network could indicate such properties during IP address assignment procedures. These proposals could be seen as attempts to fix the gap 🌈

GAP2-3: Handling mobility management at the granularity of an individual session of a user/device needs proper session identification, in addition to user/device identification 🍓

5.3. IPv6 Deployment - REQ3 🧚

This requirement says DMM solutions should primarily target IPv6 as the main deployment environment. IPv4 support is not considered mandatory, and solutions should not be tailored specifically to support IPv4 💖

All of the analyzed DMM practices support IPv6 ✨ Some of them, such as MIPv6/NEMO (including support for dynamic HA selection), MOBIKE, and SIPTO, also have IPv4 support. Some solutions, e.g., PMIPv6, also have some limited IPv4 support. So in conclusion, existing DMM practices meet this requirement 👑

5.4. Considering Existing Mobility Protocols - REQ4 🧚

okay so a DMM solution must first consider reusing and extending IETF-standardized protocols before it specifies new ones 💅 this is giving "don't reinvent the wheel bestie" energy

as [RFC7333] says, a DMM solution could reuse existing IETF and standardized protocols before specifying new protocols 🫶 and Section 4 of this document covers the different ways to flatten and distribute current mobility solutions ✨ ngl nothing actually stops mobility functions from being distributed inside IP mobility protocols 🦋 but as Sections 5.1 and 5.2 explain, there are limitations 😭

the 3GPP data-plane anchoring function (the P-GW) can also be distributed, but it comes with limits like no anchoring relocation and no context transfer between anchors and the centralized control plane 💀 the 3GPP architecture is also moving toward flattening with SIPTO and LIPA, though they don't give full mobility support 🙈 for example, mobility support for SIPTO traffic can be pretty limited, and offloaded traffic cannot access operator services 😬 so the operator has to be very careful about which traffic gets offloaded 🍓

5.5. Coexistence with Deployed Networks/Hosts and Operability across Different Networks - REQ5 🌈

according to [RFC7333], DMM implementations are required to coexist with existing network deployments, end hosts, and routers 🎀 DMM solutions are also expected to work across different networks, which might be run as separate administrative domains, as long as the necessary mobility management signaling, forwarding, and network access are allowed by the trust relationship between them 🤝 all current mobility protocols can coexist with existing network deployments and end hosts 💖 so there's no gap for this requirement, periodt ✨

5.6. Operation and Management Considerations - REQ6 ⚙️

this requirement is actually made up of several aspects, and here's the rundown 👑

  • A DMM solution needs to consider configuring a device, monitoring the current operational state of a device, responding to events that impact the device, possibly by modifying the configuration, and storing the data in a format that can be analyzed later.
  • A DMM solution has to describe in what environment and how it can be scalably deployed and managed.
  • A DMM solution has to support mechanisms to test if the DMM solution is working properly.
  • A DMM solution is expected to expose the operational state of DMM to the administrators of the DMM entities.
  • A DMM solution, which supports flow mobility, is also expected to support means to correlate the flow routing policies and the observed forwarding actions.
  • A DMM solution is expected to support mechanisms to check the liveness of the forwarding path.
  • A DMM solution has to provide fault management and monitoring mechanisms to manage situations where update of the mobility session or the data path fails.
  • A DMM solution is expected to be able to monitor the usage of the DMM protocol.
  • DMM solutions have to support standardized configuration with Network Configuration Protocol (NETCONF) [RFC6241] using YANG [RFC6020] modules, which are expected to be created for DMM when needed for such configuration.

GAP6-1: Existing mobility management protocols have not thoroughly documented how, or whether, they support the above list of operation and management considerations. Each of the above needs to be considered from the beginning in a DMM solution. 😭

GAP6-2: Management Information Base (MIB) objects are currently defined in [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. Standardized configuration with NETCONF [RFC6241], using YANG [RFC6020] modules, is lacking. 🥺

5.7. Security Considerations - REQ7 🔐

this one is serious bestie, security is not a vibe to skip 🚨

as [RFC7333] says, a DMM solution has to support any security protocols and mechanisms needed to secure the network and to make continuous security improvements 🛡️ on top of that, since security gets considered early in the design, a DMM solution cannot introduce new security risks or privacy concerns, or amplify existing security risks that cannot be mitigated by existing security protocols and mechanisms 💜

any solutions meant to fill the gaps identified in this document need to meet this requirement 🫡 right now it doesn't look like using existing solutions to support DMM has introduced any new security issues ✨ for example, Mobile IPv6 defines security features to protect binding updates sent to home agents and correspondent nodes 🔒 it also defines mechanisms to protect data packet transmission for Mobile IPv6 users 🎀 Proxy Mobile IPv6 and other variations of mobile IP have similar security considerations too 🌸

5.8. Multicast Considerations - REQ8 📡

[RFC7333] states that DMM solutions are expected to allow the development of multicast solutions, so that multicast traffic delivery doesn't end up inefficient 🦋

current IP mobility solutions mainly address the mobility problem for unicast traffic 🙃 solutions that rely on an anchor point to tunnel multicast traffic down to the access router, or down to the mobile node, bring in the so-called "tunnel convergence problem" 😵 this means multiple copies of the same multicast traffic can converge on the same node, which kills the advantage of using multicast protocols 💀

[RFC6224] documents a baseline solution for that issue, and [RFC7028] documents a routing optimization solution 🧠 the baseline solution suggests deploying a Multicast Listener Discovery (MLD) proxy function at the MAG, and either a multicast router or another MLD proxy function at the LMA 🍓 the routing optimization solution describes an architecture where a dedicated multicast tree mobility anchor or a direct routing option can be used to avoid the tunnel convergence problem 🧚

besides the solutions mentioned above, there are no other mechanisms for mobility protocols to address the multicast tunnel convergence problem 🫶

5.9. Summary 📋

here are the main gaps we found from the analysis above, lined up for you 💅

GAP1-1: Existing solutions only provide an optimal initial anchor assignment, and the gap is the lack of dynamic anchor change or new anchor assignment. Neither the HA switch nor the LMA runtime assignment allows changing the anchor during an ongoing session. MOBIKE allows change of GW, but its applicability has been scoped to a very narrow use case. 🙈

GAP1-2: The MN needs to be able to perform source address selection. A proper mechanism to inform the MN is lacking, so there is not a basis for performing the correct selection. 🤷‍♀️

GAP1-3: Currently, there is no efficient mechanism specified by the IETF that allows the dynamic discovery of the presence of nodes that can play the role of anchor, discover their capabilities, and allow the selection of the most suitable one. However, the following mechanisms could help discovering anchors:

  • Dynamic Home Agent Address Discovery (DHAAD): The use of the home agent flag (H) in Router Advertisements (which indicates that the router sending the Router Advertisement is also functioning as a Mobile IPv6 home agent on the link) and the MAP option in Router Advertisements defined by HMIPv6. 🔍

GAP1-4: While existing network-based DMM practices may allow the deployment of multiple LMAs and dynamically select the best one, this requires keeping some centralization in the control plane to access the policy database (as defined in RFC 5213). Although [RFC7389] allows a MAG to split its control and user planes, there is a lack of solutions or extensions that support a clear control- and data-plane separation for IETF IP mobility protocols in a DMM context. 🧩

GAP2-1: The information about which sessions at the mobile node are active and are using the mobility support needs to be transferred to, or shared with, the network. Such a mechanism has not been defined. 📲

GAP2-2: The mobile node needs to simultaneously use multiple IP addresses with different properties. There is a lack of a mechanism to expose this information to the mobile node, which can then update its source address selection mechanism accordingly. 🌐

GAP2-3: The handling of mobility management has not been done at the granularity of an individual session of a user or device before. The combination of session identification and user/device identification may be lacking. 🎯

GAP6-1: Mobility management protocols have not thoroughly documented how, or whether, they support the following list of operation and management considerations:

  • A DMM solution needs to consider configuring a device, monitoring the current operational state of a device, and responding to events that impact the device possibly by modifying the configuration and storing the data in a format that can be analyzed later.
  • A DMM solution has to describe in what environment, and how, it can be scalably deployed and managed.
  • A DMM solution has to support mechanisms to test if the DMM solution is working properly.
  • A DMM solution is expected to expose the operational state of DMM to the administrators of the DMM entities.
  • A DMM solution, which supports flow mobility, is also expected to support means to correlate the flow routing policies and the observed forwarding actions.
  • A DMM solution is expected to support mechanisms to check the liveness of the forwarding path.
  • A DMM solution has to provide fault management and monitoring mechanisms to manage situations where update of the mobility session or the data path fails.
  • A DMM solution is expected to be able to monitor the usage of the DMM protocol.
  • DMM solutions have to support standardized configuration with NETCONF [RFC6241], using YANG [RFC6020] modules, which are expected to be created for DMM when needed for such configuration. 🧾

GAP6-2: Management Information Base (MIB) objects are currently defined in [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. Standardized configuration with NETCONF [RFC6241], using YANG [RFC6020] modules, is lacking. 💜

6. Security Considerations 🔐

Okay bestie, this part is serious, so let's go. Using existing IP mobility protocols for DMM brings up security threats that look a lot like the ones in centralized mobility management systems 😬. Without authentication, a malicious node could forge signaling messages and redirect traffic away from its legit path. That's basically a denial-of-service attack on whichever node or nodes the traffic was meant for 💀.

Distributed mobility anchoring keeps the current security mechanisms, but it might need more security associations to be managed by the mobility management entities. That can lead to scalability and performance issues 📉. It also makes mobility security way more complicated, because traffic redirection requests might come from origins nobody thought about before. Hello, distributed points of attack 🙈.

So the DMM security design has to account for how security associations get spread across the extra mobility entities, and it has to fulfill the security requirement of [RFC7333]. No shortcuts, periodt 💅✨.

7. References

7.1. Normative References

7.2. Informative References

Contributors 🫶

This document has benefited from valuable contributions from the following person:

Charles E. Perkins
Huawei Technologies
EMail: charliep@computer.org

Charles produced a matrix comparing the different mobility protocols and extensions against a list of desired DMM properties. That was super useful in the early days of the gap analysis 🙌. He also kept giving suggestions and did extensive reviews of this document. Iconic behavior 👑.

Authors' Addresses 💌

Dapeng Liu (editor)
China Mobile
Unit 2, 28 Xuanwumenxi Ave, Xuanwu District
Beijing  100053
China

EMail: liudapeng@chinamobile.com


Juan Carlos Zuniga (editor)
InterDigital Communications, LLC
1000 Sherbrooke Street West, 10th floor
Montreal, Quebec  H3A 3G4
Canada

EMail: JuanCarlos.Zuniga@InterDigital.com
URI:   http://www.InterDigital.com/


Pierrick Seite
Orange
4, rue du Clos Courtel, BP 91226
Cesson-Sevigne  35512
France

EMail: pierrick.seite@orange.com


H Anthony Chan
Huawei Technologies
5340 Legacy Dr. Building 3
Plano, TX  75024
United States

EMail: h.a.chan@ieee.org


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/

That's the whole RFC, bestie! 🌈💖 Every single author and reference made it in ✨

📦 where this page comes from