RFC 7333
Requirements for Distributed Mobility Management
Requirements for Distributed Mobility Management 🦋
Okay bestie, RFC 7333 is an Informational document, not a Standards Track one, so it's a requirements doc and doesn't define a protocol. It's from August 2014, has ISSN 2070-1721, and was written by five people: H. Chan, Ed. (Huawei Technologies), D. Liu (China Mobile), P. Seite (Orange), H. Yokota (Landis+Gyr), and J. Korhonen (Broadcom Communications). Its header has no Obsoletes or Updates lines, so it doesn't replace or update any other RFC 💅✨
Abstract
This doc sets out the requirements for Distributed Mobility Management (DMM) at the network layer 🌸 Traditional wireless networks are hierarchical, which mostly led to mobility anchors being deployed centrally. Some wireless networks are moving away from that hierarchy, so a distributed model for mobility management could be really useful. In that model, traffic doesn't have to go through centrally deployed mobility anchors that sit far from the optimal route. The abstract also explains the motivation and the problem each requirement is solving.
Status of This Memo
Not an Internet Standards Track spec, just published for info purposes 🧚
This doc is a product of the Internet Engineering Task Force (IETF) and reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for more.
For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7333.
Copyright Notice
Copyright (c) 2014 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. Please read them carefully, because they spell out your rights and restrictions for this doc. Code Components pulled from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes.
Table of Contents
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................4
2.1. Requirements Language ......................................4
2.2. Terminology ................................................4
3. Centralized versus Distributed Mobility Management ..............5
3.1. Centralized Mobility Management ............................6
3.2. Distributed Mobility Management ............................7
4. Problem Statement ...............................................8
5. Requirements ...................................................10
6. Security Considerations ........................................16
7. Contributors ...................................................17
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................211. Introduction ✨
Over the past decade, a bunch of network-layer mobility protocols got standardized: [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213] 🎀 They each have different functions and message formats, but they all use a mobility anchor so a mobile node stays reachable after it moves to a different network. The anchor does a lot of things, and one of the big ones is keeping connectivity by forwarding packets to and from the mobile node. It counts as centrally deployed because today's architectures have only a few of these anchors, and one anchor usually handles the traffic of millions of mobile nodes in an operator network. A mobility anchor may also still have to live in the subscriber's provider network when the subscriber is roaming in a visited network. The reason is that the provider's network can do things like charging and billing more easily that way. An example provider network is a Third Generation Partnership Project (3GPP) network.
Distributed mobility management (DMM) is the alternative to that centralized setup 🦋 Here's why people got interested in studying it:
(1) Mobile users are consuming more and more Internet content, including content from local Content Delivery Networks (CDNs) 📱 That traffic puts new demands on mobile core networks. To avoid running past the available core network capacity, service providers need new strategies like selective IPv4 traffic offload (e.g., [RFC6909], 3GPP Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) work items [TS.23.401]) through alternative access networks like Wireless Local Area Networks (WLANs) [MOB-DATA-OFFLOAD]. There's also a gateway selection mechanism that takes user proximity into account inside the Evolved Packet Core (EPC) [TS.29.303]. These mechanisms weren't pursued in the past, though, because of charging and billing concerns that need solutions beyond the mobility protocol. So assigning a gateway anchor node from a visited network when roaming has only recently happened, and it's limited to voice services 🙈
Both traffic offloading and CDN mechanisms could benefit from mobile architectures with fewer hierarchical levels in the data path, introduced by the mobility management system. This "flattening" of mobile networks works best for direct communication between peers in the same geographical area. DMM in flattening mobile networks would anchor the traffic closer to the user's point of attachment 🌈
(2) Today's mobile networks give service providers new challenges 💅 Mobility patterns show that mobile nodes often stay attached to the same point of attachment for long stretches of time [LOCATING-USER]. Applications that start and finish their sessions while the mobile node stays on the same point of attachment don't need specific IP mobility management support. The catch is that IP mobility support is designed for always-on operation right now, so it keeps all the context parameters for each mobile subscriber for as long as they're connected to the network. That can waste resources and cost the service provider extra. Infrequent node mobility combined with application intelligence suggests mobility support could be provided selectively, for example as described in [DHCPv6-CLASS-BASED-PREFIX] and [IPv6-PREFIX-PROPERTIES]. That would cut down the amount of context kept in the network 🧠
DMM may distribute the mobility anchors in the data plane as the mobile network flattens, so the anchors sit closer to the user. Ideally, mobility agents could be collocated with the first-hop router 🌸 Because the anchors are distributed, it may become possible to use mobility protocol support selectively, depending on whether it's actually needed. DMM can reduce the amount of state information that has to be kept in the various mobility agents of the mobile network. It can also avoid setting up mechanisms that forward traffic from an old mobility anchor to a new one when they aren't needed 🙌
This document compares distributed and centralized mobility management in Section 3. The problems DMM can address are summarized in Section 4. The mandatory requirements and the optional requirements for network-layer distributed mobility management are in Section 5. Security considerations are covered in Section 6.
The problem statement and use cases [DMM-SCENARIO] can be found in [DIST-MOB-REVIEW].
2. Conventions Used in This Document 📚
2.1. Requirements Language
Okay, the key words are the ones that carry the actual weight here 🔥 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 RFC 2119 [RFC2119].
2.2. Terminology
All the general mobility-related terms, and their acronyms as used in this document, are interpreted as defined in the Mobile IPv6 base specification [RFC6275], the Proxy Mobile IPv6 (PMIPv6) specification [RFC5213], and "Mobility Related Terminology" [RFC3753] 🧚 Those include mobile node (MN), correspondent node (CN), and home agent (HA) per [RFC6275]. They also include local mobility anchor (LMA) and mobile access gateway (MAG) per [RFC5213], and context per [RFC3753].
This doc also introduces these terms:
Centrally deployed mobility anchors
Refers to mobility management deployments with very few mobility anchors, where one anchor manages the traffic of millions of mobile nodes in an operator network. 🏰
Centralized mobility management
Makes use of centrally deployed mobility anchors. 📍
Distributed mobility management
Is not centralized, so traffic doesn't have to go through centrally deployed mobility anchors that are far from the optimal route. 🌈
Hierarchical mobile network
Has a hierarchy of network elements arranged in multiple hierarchical levels, which are introduced into the data path by the mobility management system. 🪜
Flattening mobile network
Refers to a hierarchical mobile network that's going through the trend of reducing its number of hierarchical levels. 📉
Flatter mobile network
Has fewer hierarchical levels compared to a hierarchical mobile network. ✨
Mobility context
Is the collection of information required to provide mobility management support for a given mobile node. 💖
3. Centralized versus Distributed Mobility Management ✨
okay so bestie, mobility management exists because a mobile node's IP address can change as it moves 🦋 Mobility management functions can live at different layers of the protocol stack. At the IP (network) layer, it can be client-based or network-based 💖
IP-layer mobility management usually works on one big idea: keep a session identifier and a forwarding address separate, then keep a mapping between the two 🧚 In Mobile IP, the node's new IP address after it moves is the forwarding address, and the original IP address from before the move is the session identifier. The location management (LM) information is kept by tying the forwarding address to the session identifier. Packets sent to the session identifier go to the original network first, which redirects them using the forwarding address so they reach the session 🌸 Redirecting like this can make routes super long 💀 An existing optimization routes directly using the host's forwarding address, so it's a host-based solution 💅
The next two subsections explain centralized and distributed mobility management functions in the network 🎀
3.1. Centralized Mobility Management
In centralized mobility management, the location information (a mapping between the session identifier and the forwarding address) is kept at one single mobility anchor, and packets for the session identifier get forwarded through that anchor 👑 So these systems are centralized in both the control plane and the data plane (mobile node IP traffic), no cap 🔥
Lots of existing mobility management deployments use centralized mobility anchoring in a hierarchical network architecture, as shown in Figure 1 ✨ Examples are the home agent (HA) and local mobility anchor (LMA), which are the anchors for the mobile node (MN) and mobile access gateway (MAG) in Mobile IPv6 [RFC6275] and Proxy Mobile IPv6 [RFC5213] respectively 🫶 Cellular networks like 3GPP General Packet Radio System (GPRS) networks and 3GPP Evolved Packet System (EPS) networks also use centralized mobility management 📱 In the 3GPP GPRS network, the Gateway GPRS Support Node (GGSN), Serving GPRS Support Node (SGSN), and Radio Network Controller (RNC) make up a hierarchy of anchors. In the 3GPP EPS network, the Packet Data Network Gateway (P-GW) and Serving Gateway (S-GW) make up another hierarchy of anchors 🌈
3GPP GPRS 3GPP EPS MIP/PMIP
+------+ +------+ +------+
| GGSN | | P-GW | |HA/LMA|
+------+ +------+ +------+
/\ /\ /\
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
+------+ +------+ +------+ +------+ +------+ +------+
| SGSN | | SGSN | | S-GW | | S-GW | |MN/MAG| |MN/MAG|
+------+ +------+ +------+ +------+ +------+ +------+
/\ /\
/ \ / \
/ \ / \
+---+ +---+ +---+ +---+
|RNC| |RNC| |RNC| |RNC|
+---+ +---+ +---+ +---+Figure 1: Centralized Mobility Management 🧚
3.2. Distributed Mobility Management
Mobility management functions can also be distributed in the data plane across multiple networks, as shown in Figure 2 🦋 That way, a mobile node in any of these networks can be served by a nearby function with appropriate forwarding management (FM) capability 💖
+------+ +------+ +------+ +------+
| FM | | FM | | FM | | FM |
+------+ +------+ +------+ +------+
|
+----+
| MN |
+----+Figure 2: Distributed Mobility Management 🌸
DMM is distributed in the data plane, but the control plane can be either centralized or distributed [DMM-SCENARIO] 💅 The centralized case implicitly assumes that data and control planes are separated, as described in [PMIP-CP-UP-SPLIT] 🫶 Mobility management can be distributed, but other functions like subscription management, subscription databases, and network access authentication don't have to be distributed the same way 🎀
A distributed mobility management scheme for a flattening mobile network made of access nodes is proposed in [DIST-DYNAMIC-MOB] 🌈 Its benefits over centralized mobility management have been shown through simulations [DIST-CENTRAL-MOB] ✨ Also, the (re)use and extension of existing protocols in designing both fully distributed mobility management [MIGRATING-HAs] [DIST-MOB-SAE] and partially distributed mobility management [DIST-MOB-PMIP] [DIST-MOB-MIP] have been reported in the literature 🧚 So, before designing new mobility management protocols for a future distributed architecture, it is recommended to first consider whether existing mobility management protocols can be extended 💜
4. Problem Statement 🔥
The problems that DMM can address are summarized as follows 💖
PS1: Non-optimal routes 🦋
Forwarding via a centralized anchor often gives non-optimal routes, which increases the end-to-end delay 🌸 You see this, for example, when accessing a nearby server or one of the servers of a Content Delivery Network (CDN), or when receiving locally available IP multicast packets or sending them 💅 (Existing route optimization is only a host-based solution. On the other hand, localized routing with PMIPv6 [RFC6705] only fixes part of the problem, where both the MN and the correspondent node (CN) are attached to the same MAG. It doesn't work when the CN doesn't behave like an MN 🙈)
PS2: Divergence from other evolutionary trends in network architectures such as distribution of content delivery 🌈
Mobile networks have generally been evolving toward flatter and flatter networks 🧚 Centralized mobility management is non-optimal with a flatter network architecture, so it doesn't support this evolution 😭
PS3: Lack of scalability of centralized tunnel management and mobility context maintenance 🫶
Setting up tunnels through a central anchor and maintaining mobility context for each MN usually needs a lot of concentrated resources in a centralized design, which reduces scalability 💀 Distributing the tunnel maintenance function and the mobility context maintenance function among different network entities, with proper signaling protocol design, can avoid growing the concentrated resources as the number of MNs goes up ✨
PS4: Single point of failure and attack 💥
Centralized anchoring designs may be more vulnerable to a single point of failure and to attacks than a distributed system is 🔥 The impact of a successful attack on a system with centralized mobility management can also be way bigger 😱
PS5: Unnecessary mobility support to clients that do not need it 🙈
IP mobility support is usually provided to all MNs 💅 But it isn't always required, and not every parameter of the mobility context is always used 🎀 For example, some applications or nodes don't need a stable IP address during a handover to keep session continuity 🦋 Sometimes the entire application session runs while the MN doesn't change its point of attachment 🌸 Also, some sessions, e.g., SIP-based sessions, can handle mobility at the application layer, so they don't need IP mobility support. It's then unnecessary to provide IP mobility support for such sessions 💜
PS6: Mobility signaling overhead with peer-to-peer communication 🍓
Resources may be wasted when mobility signaling (e.g., maintenance of the tunnel, keep-alive signaling, etc.) isn't turned off for peer-to-peer communication 😩
PS7: Deployment with multiple mobility solutions 🌈
There are already lots of variants and extensions of MIP, plus mobility solutions at other layers 🧚 Deploying new mobility management solutions can be really challenging, and debugging can be hard too, when they coexist with solutions already in the field 💅
PS8: Duplicate multicast traffic 👯
IP multicast distribution over architectures that use IP mobility solutions (e.g., [RFC6224]) may lead to duplicated multicast subscriptions converging toward the downstream tunnel entity (e.g., the MAG in PMIPv6) 🫠 Specifically, when multicast subscription for individual mobile nodes is coupled with mobility tunnels (e.g., a PMIPv6 tunnel), duplicate multicast subscription(s) are likely to be received through different upstream paths 😵💫 This problem may also exist, or be even worse, in a distributed mobility environment 💖
5. Requirements ✨
Now that we've compared distributed mobility management with centralized deployment (Section 3) and described the problems (Section 4), this section identifies the following requirements 👑
REQ1: Distributed mobility management 🦋
IP mobility, network access solutions, and forwarding solutions provided by DMM MUST enable traffic to avoid traversing a single mobility anchor that's far from the optimal route 💅
This requirement on distribution applies to the data plane only 🌸 It doesn't put constraints on whether the control plane should be distributed or centralized. However, if the control plane is centralized while the data plane is distributed, it's implied that the control plane and data plane need to separate (Section 3.2) 🫶
Motivation: This requirement is motivated by current trends in network evolution: (a) it is cost- and resource-effective to cache contents, and the caching (e.g., CDN) servers are distributed so that each user in any location can be close to one of the servers; (b) the significantly larger number of mobile nodes and flows calls for improved scalability; (c) single points of failure are avoided in a distributed system; and (d) threats against centrally deployed anchors, e.g., a home agent and a local mobility anchor, are mitigated in a distributed system. 🧚
This requirement addresses the problems PS1, PS2, PS3, and PS4 described in Section 4 💖
REQ2: Bypassable network-layer mobility support for each application session
REQ2 wrap-up 🎀
DMM solutions MUST enable network-layer mobility 🦋, but it MUST be possible for any individual active application session (flow) to not use it ✨. Mobility support is needed, for example, when a mobile host moves and an app can't handle its IP address changing 💀. It's also needed when a mobile router changes its IP address as it moves along with a host, and with ingress filtering in place, an app on that host gets interrupted 😭. Lowkey though, mobility support at the network layer isn't always needed 🙈. A mobile node can often just be stationary, and mobility support can also live at other layers. So it's not always necessary to keep a stable IP address or prefix for an active application session 🌸.
Different sessions can also differ when it comes to needing network-layer mobility support 💅. So IP mobility, network access solutions, and forwarding solutions provided by DMM MUST give each application session of a user or mobile device its own independent handling 🫶. Handling mobility down to a single session of a user or device SHOULD need proper session identification on top of user/device identification 🧚.
Motivation: the whole point is more efficient forwarding and better use of network resources 🍓. You pick an IP address or prefix based on whether mobility support is actually needed, and you don't keep context at the mobility anchor when there's no need for it 🫧.
This requirement addresses the problems PS5 and PS6 described in Section 4 🎀.
REQ3: IPv6 deployment 🌈
DMM solutions SHOULD aim for IPv6 as the main deployment environment, and SHOULD NOT be specially tailored to support IPv4, especially when private IPv4 addresses and/or NATs are in play 💜.
Motivation: this lines up with the general direction of IETF work 🧭. DMM deployment is expected "on the mid- to long-term horizon", when IPv6 will be way more common than it is today 🌷.
This avoids the overcomplicated move of giving IPv4 and IPv6 the same level of features 🙅♀️. Some IPv6-specific features just aren't available for IPv4 at all 🙈.
REQ4: Existing mobility protocols ⭐
A DMM solution MUST first look at reusing and extending IETF standard protocols before it specifies brand-new ones 🧠.
Motivation: reusing existing IETF work is more efficient and less error-prone 💖.
This requirement tries to avoid building new protocols, which can be time-consuming and error-prone too ⏳.
REQ5: Coexistence with deployed networks/hosts and operability across different networks 🦋
A DMM solution may require loose, tight, or no integration with existing mobility protocols and host IP stacks 🫧. Whatever the integration level, DMM implementations MUST be able to coexist with existing network deployments, end hosts, and routers that may or may not implement existing mobility protocols 🤝. Furthermore, a DMM solution SHOULD work across different networks, possibly run as separate administrative domains, when the needed mobility management signaling, forwarding, and network access are allowed by the trust relationship between them 🌉.
Motivation: (a) keep backwards compatibility so existing networks and hosts aren't affected and keep working as usual, and (b) allow inter-domain operation if that's wanted 💅.
This requirement addresses the problem PS7 described in Section 4 🎀.
REQ6: Operation and management considerations 🛠️
A DMM solution needs to consider configuring a device, monitoring its current operational state, and responding to events that impact the device, possibly by changing the configuration and storing the data in a format that can be analyzed later 📊. There are different management protocols out there, for example:
- (a) the Simple Network Management Protocol (SNMP) [RFC1157], with definitions of standardized management information base (MIB) objects for DMM that allow the monitoring of traffic steering in a consistent manner across different devices
- (b) the Network Configuration Protocol (NETCONF) [RFC6241], with definitions of standardized YANG [RFC6020] modules for DMM to achieve a standardized configuration
- (c) syslog [RFC5424], which is a one-way protocol allowing a device to report significant events to a log analyzer in a network management system
- (d) the IP Flow Information Export (IPFIX) Protocol, which serves as a means for transmitting traffic flow information over the network [RFC7011], with a formal description of IPFIX Information Elements [RFC7012]
This document is not about picking which management protocol(s) should be used 🙅♀️. An inventory of the management protocols and data models is covered in [RFC6632] 📚.
The paragraphs below list the operation and management considerations for a DMM solution. This list may not be exhaustive and may be expanded according to the needs of the solutions 🌱.
A DMM solution MUST describe how, and in what types of environments, it can be scalably deployed and managed 🌍.
A DMM solution MUST support mechanisms to test whether the DMM solution is working properly 🧪. For example, when a DMM solution employs traffic indirection to support a mobility session, implementations MUST support mechanisms to test that the appropriate traffic indirection operations are in place, including the setup of traffic indirection and the subsequent teardown of the indirection to release the associated network resources when the mobility session has closed 🧹.
A DMM solution SHOULD expose the operational state of DMM to the administrators of the DMM entities 👀. For example, when a DMM solution employs separation between a session identifier and forwarding address, it should expose the association between them 🔗.
When flow mobility is supported by a DMM solution, the solution SHOULD support means to correlate the flow routing policies and the observed forwarding actions 🔍.
A DMM solution SHOULD support mechanisms to check the liveness of a forwarding path 💓. If the DMM solution sends periodic update refresh messages to configure the forwarding path, the refresh period SHOULD be configurable, and a reasonable default configuration value SHOULD be proposed 🎛️. Information collected can be logged or made available with protocols such as SNMP [RFC1157], NETCONF [RFC6241], IPFIX [RFC7011], or syslog [RFC5424] 📝.
A DMM solution MUST provide fault management and monitoring mechanisms to manage situations where an update of the mobility session or the data path fails 🚨. The system must also be able to handle situations where a mobility anchor with ongoing mobility sessions fails 🛟.
A DMM solution SHOULD be able to monitor usage of the DMM protocol 📈. When a DMM solution uses an existing protocol, the techniques already defined for that protocol SHOULD be used to monitor the DMM operation. When these techniques are inadequate, new techniques MUST be developed 🧑🔬.
In particular, the DMM solution SHOULD:
- (a) be able to monitor the number of mobility sessions per user, as well as their average duration ⏱️
- (b) provide an indication of DMM performance, such as:
- (1) handover delay, which includes the time necessary to reestablish the forwarding path when the point of attachment changes
- (2) protocol reactivity, which is the time between handover events such as the attachment to a new access point and the completion of the mobility session update
- (c) provide means to measure the signaling cost of the DMM protocol 💸
- (d) if tunneling is used for traffic redirection, monitor:
- (1) the number of tunnels
- (2) their transmission and reception information
- (3) the encapsulation method used, and its overhead
- (4) the security used at the node level 🔐
DMM solutions SHOULD support standardized configuration with NETCONF [RFC6241], using YANG [RFC6020] modules, which SHOULD be created for DMM when needed for such configuration 🧩. However, if a DMM solution creates extensions to MIPv6 or PMIPv6, the allowed addition of definitions of management information base (MIB) objects to the MIPv6 MIB [RFC4295] or the PMIPv6 MIB [RFC6475] that are needed for the control and monitoring of the protocol extensions SHOULD be limited to read-only objects 👁️.
Motivation: a DMM solution designed from the start for operability and manageability can implement efficient operations and management solutions 🏆. These requirements keep DMM designs from making operations and management difficult or costly 💰.
REQ7: Security considerations 🔐
⚠️ Security is not a side quest here, bestie. Read this one carefully. ⚠️
A DMM solution MUST support any security protocols and mechanisms needed to secure the network and to keep making continuous security improvements 🛡️. On top of that, security has to be part of the design from the very beginning 🏗️. A DMM solution MUST NOT introduce new security risks, and MUST NOT amplify existing security risks that cannot be mitigated by existing security protocols and mechanisms 🚫💥.
Okay so the motivation here is basically "DMM can get attacked, so lock it down" 😭 Impersonation, denial of service, man-in-the-middle attacks, the whole drama. An illegitimate node could try to get into a network that's running DMM 🙅♀️ Or a malicious node could forge a bunch of signaling messages and redirect traffic away from its legit path 💀 Then the nodes the traffic got redirected to could be stuck under a denial-of-service attack, and everyone else stops getting their traffic at all. Not it.
So the vibe is: access control, integrity, authentication, authorization, confidentiality, all of that should be used to protect the DMM entities, the same way they already protect regular networks and the existing IETF mobility protocols 🛡️ But here's the tea: if a DMM solution is built so that those existing security mechanisms/protocols can't keep it safe even when they're used properly, then that solution is causing uncontrollable security problems 🚨 No thanks.
This requirement is there so a DMM solution can't bring in mobility management protocols that are impossible to control and make deployment a no-go. Platforms running those protocols are at risk for data loss and a bunch of other dangers, including financial harm to the users 😭💸 We are not doing that to people.
REQ8: Multicast considerations 🌸
DMM SHOULD enable multicast solutions to be developed to avoid network inefficiency in multicast traffic delivery.
Motivation: Multicast got added to existing deployments after the reference mobility protocol was already designed, and honestly that's why things got messy 🙃 Inefficient delivery and non-optimal forwarding for multicast traffic, what a mess. DMM should think about multicast from the very beginning, so the solutions can actually account for how efficient multicast delivery is supposed to work, like avoiding duplicate multicast subscriptions toward the downstream tunnel entities 🧠 And the multicast solutions should not restrict all IP multicast traffic to one host through a dedicated (tunnel) interface on multicast-capable access routers. Main character energy is sharing the stage, bestie 🎀
This requirement addresses the problems PS1 and PS8 described in Section 4. 💅
6. Security Considerations 🔒
Okay bestie, all the security tea is over in REQ7 in Section 5, so go read that one first 🫶
7. Contributors ✨
This requirements document is a team project from a bunch of participants, and the reviews were iconic. Valuable comments and suggestions from these area directors and IESG members made it so much better 👑 Russ Housley, Catherine Meadows, Adrian Farrel, Barry Leiba, Alissa Cooper, Ted Lemon, Brian Haberman, Stephen Farrell, Joel Jaeggli, Alia Atlas, and Benoit Claise 🦋
Besides the authors, these people also made very significant and important contributions to this work 💖
Charles E. Perkins
Huawei Technologies
EMail: charliep@computer.org
Melia Telemaco
Alcatel-Lucent Bell Labs
EMail: telemaco.melia@googlemail.com
Elena Demaria
Telecom Italia
via G. Reiss Romoli, 274, Torino, 10148, Italy
EMail: elena.demaria@telecomitalia.it
Jong-Hyouk Lee
Sangmyung University, Korea
EMail: jonghyouk@smu.ac.kr
Kostas Pentikousis
EICT GmbH
EMail: k.pentikousis@eict.de
Tricci So
ZTE
EMail: tso@zteusa.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30, Leganes, Madrid 28911, Spain
EMail: cjbc@it.uc3m.es
Peter McCann
Huawei Technologies
EMail: Peter.McCann@huawei.com
Seok Joo Koh
Kyungpook National University, Korea
EMail: sjkoh@knu.ac.kr
Wen Luo
ZTE
No. 68, Zijinhua Rd, Yuhuatai District, Nanjing, Jiangsu 210012, China
EMail: luo.wen@zte.com.cn
Sri Gundavelli
Cisco
sgundave@cisco.com
Hui Deng
China Mobile
EMail: denghui@chinamobile.com
Marco Liebsch
NEC Laboratories Europe
EMail: liebsch@neclab.eu
Carl Williams
MCSR Labs
EMail: carlw@mcsr-labs.org
Seil Jeon
Instituto de Telecomunicacoes, Aveiro
EMail: seiljeon@av.it.pt
Sergio Figueiredo
Universidade de Aveiro
EMail: sfigueiredo@av.it.pt
Stig Venaas
EMail: stig@venaas.com
Luis Miguel Contreras Murillo
Telefonica I+D
EMail: lmcm@tid.es
Juan Carlos Zuniga
InterDigital
EMail: JuanCarlos.Zuniga@InterDigital.com
Alexandru Petrescu
EMail: alexandru.petrescu@gmail.com
Georgios Karagiannis
University of Twente
EMail: g.karagiannis@utwente.nl
Julien Laganier
Juniper
EMail: julien.ietf@gmail.com
Wassim Michel Haddad
Ericsson
EMail: Wassim.Haddad@ericsson.com
Dirk von Hugo
Deutsche Telekom Laboratories
EMail: Dirk.von-Hugo@telekom.de
Ahmad Muhanna
Award Solutions
EMail: asmuhanna@yahoo.com
Byoung-Jo Kim
ATT Labs
EMail: macsbug@research.att.com
Hassan Ali-Ahmad
Orange
EMail: hassan.aliahmad@orange.com
Alper Yegin
Samsung
EMail: alper.yegin@partner.samsung.com
David Harrington
Effective Software
EMail: ietfdbh@comcast.net8. References
8.1. Normative References
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", STD 15,
RFC 1157, May 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli,
"Mobile IPv6 Management Information Base", RFC 4295,
April 2006.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa,
"Proxy Mobile IPv6 Management Information Base", RFC 6475,
May 2012.
[RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network
Management Standards", RFC 6632, June 2012.
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of
the IP Flow Information Export (IPFIX) Protocol for the
Exchange of Flow Information", STD 77, RFC 7011,
September 2013.
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow
Information Export (IPFIX)", RFC 7012, September 2013.8.2. Informative References 📚✨
these are the receipts bestie, the research papers and drafts behind everything 🧠💜
[DHCPv6-CLASS-BASED-PREFIX]
Bhandari, S., Halwasia, G., Gundavelli, S., Deng, H.,
Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
based prefix", Work in Progress, July 2013.
[DIST-CENTRAL-MOB]
Bertin, P., Bonjour, S., and J-M. Bonnin, "Distributed or
Centralized Mobility?", Proceedings of the 28th IEEE
Conference on Global Telecommunications (GlobeCom),
December 2009.
[DIST-DYNAMIC-MOB]
Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed
Dynamic Mobility Management Scheme Designed for Flat IP
Architectures", Proceedings of 3rd International
Conference on New Technologies, Mobility and Security
(NTMS), 2008.
[DIST-MOB-MIP]
Chan, H., "Distributed Mobility Management with Mobile
IP", Proceedings of IEEE International Communication
Conference (ICC) Workshop on Telecommunications: from
Research to Standards, June 2012.
[DIST-MOB-PMIP]
Chan, H., "Proxy Mobile IP with Distributed Mobility
Anchors", Proceedings of GlobeCom Workshop on Seamless
Wireless Mobility, December 2010.
[DIST-MOB-REVIEW]
Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu,
"Distributed and Dynamic Mobility Management in Mobile
Internet: Current Approaches and Issues", Journal of
Communications, vol. 6, no. 1, pp. 4-15, February 2011.
[DIST-MOB-SAE]
Fischer, M., Andersen, F., Kopsel, A., Schafer, G., and M.
Schlager, "A Distributed IP Mobility Approach for 3G SAE",
Proceedings of the 19th International Symposium on
Personal, Indoor and Mobile Radio Communications (PIMRC),
2008.
[DMM-SCENARIO]
Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case
scenarios for Distributed Mobility Management", Work in
Progress, October 2010.
[IPv6-PREFIX-PROPERTIES]
Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and
D. Liu, "IPv6 Prefix Properties", Work in Progress,
July 2013.
[LOCATING-USER]
Kirby, G., "Locating the User", Communications
International, 1995.
[MIGRATING-HAs]
Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home
Agents Towards Internet-scale Mobility Deployments",
Proceedings of the ACM 2nd CoNEXT Conference on Future
Networking Technologies, December 2006.
[MOB-DATA-OFFLOAD]
Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile
Data Offloading: How Much Can WiFi Deliver?", Proceedings
of the ACM SIGCOMM 2010 Conference, 2010.
[PMIP-CP-UP-SPLIT]
Wakikawa, R., Pazhyannur, R., and S. Gundavelli,
"Separation of Control and User Plane for Proxy Mobile
IPv6", Work in Progress, July 2013.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008.
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised",
RFC 5944, November 2010.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility
Support in the Internet", RFC 6301, July 2011.
[RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.
Dutta, "Localized Routing for Proxy Mobile IPv6",
RFC 6705, September 2012.
[RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R.
Koodli, "IPv4 Traffic Offload Selector Option for Proxy
Mobile IPv6", RFC 6909, April 2013.
[TS.23.401]
3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 12.5.0, June 2014,
<http://www.3gpp.org/ftp/Specs/html-info/23401.htm>.
[TS.29.303]
3GPP, "Domain Name System Procedures; Stage 3", 3GPP
TS 29.303 12.3.0, June 2014, <http://www.3gpp.org/ftp/
Specs/html-info/29303.htm>.Authors' Addresses 🎀
meet the squad who wrote this 🫶
H. Anthony Chan (editor)
Huawei Technologies
5340 Legacy Dr. Building 3
Plano, TX 75024
USA
EMail: h.a.chan@ieee.org
Dapeng Liu
China Mobile
Unit 2, 28 Xuanwumenxi Ave, Xuanwu District
Beijing 100053
China
EMail: liudapeng@chinamobile.com
Pierrick Seite
Orange
4, rue du Clos Courtel, BP 91226
Cesson-Sevigne 35512
France
EMail: pierrick.seite@orange.com
Hidetoshi Yokota
Landis+Gyr
EMail: hidetoshi.yokota@landisgyr.com
Jouni Korhonen
Broadcom Communications
Porkkalankatu 24
Helsinki FIN-00180
Finland
EMail: jouni.nospam@gmail.com📦 where this page comes from
- ietf: rfc7333 2014-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms