RFC 7864
Proxy Mobile IPv6 Extensions to Support Flow Mobility
Proxy Mobile IPv6 Extensions to Support Flow Mobility ✨
okay bestie, this is RFC 7864 🎀 It was written by C.J. Bernardos (Ed.) from UC3M and dated May 2016. It's a Standards Track doc, so it's official Internet protocol stuff 👑 It updates RFC 5213 (the base PMIPv6 spec) and doesn't obsolete anything. The ISSN is 2070-1721 🦋
Abstract 🌸
Proxy Mobile IPv6 (PMIPv6) lets a mobile node connect to the same PMIPv6 domain through different interfaces 📱 This doc adds extensions to PMIPv6 that are needed for network-based flow mobility over multiple physical interfaces ✨
This document updates RFC 5213. The extensions are the stuff the local mobility anchor and the mobile access gateway do to manage the prefixes given to each of the node's interfaces 💅 It also covers how the network handles forwarding policies so flow mobility stays consistent 🫶
Status of This Memo 🎀
This is an Internet Standards Track document.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 💜 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.
For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7864 🌈
Copyright Notice 💖
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 🦋
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. Read them carefully, because they spell out your rights and restrictions for this document 🫶 Code components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Simplified BSD License 🔥
Table of Contents 💅
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of the PMIPv6 Flow Mobility Extensions . . . . . . . 4
3.1. Use Case Scenarios . . . . . . . . . . . . . . . . . . . 4
3.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. MN Sharing a Common Set of Prefixes on All MAGs . . . 6
3.2.2. MN with Different Sets of Prefixes on Each MAG . . . 9
3.3. Use of PBU/PBA Signaling . . . . . . . . . . . . . . . . 11
3.4. Use of Flow-Level Information . . . . . . . . . . . . . . 12
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Home Network Prefix . . . . . . . . . . . . . . . . . . . 13
4.2. Flow Mobility Initiate (FMI) . . . . . . . . . . . . . . 13
4.3. Flow Mobility Acknowledgement (FMA) . . . . . . . . . . . 14
5. Conceptual Data Structures . . . . . . . . . . . . . . . . . 14
5.1. Multiple Proxy Care-of Address Registration . . . . . . . 14
5.2. Flow Mobility Cache (FMC) . . . . . . . . . . . . . . . . 15
6. Mobile Node Considerations . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 191. Introduction 🧚
Okay so PMIPv6, which is specified in [RFC5213], gives network-based mobility management to hosts that connect to a PMIPv6 domain 🌸 It brings in two new functional entities: the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the one that notices the Mobile Node's (MN's) attachment and provides IP connectivity. The LMA assigns one or more Home Network Prefixes (HNPs) to the MN and is the topological anchor for all of the MN's traffic 👑
PMIPv6 lets an MN connect to the same PMIPv6 domain through different interfaces 💖 This document adds protocol extensions between the LMA and the MAGs to enable "flow mobility", which means distributing specific traffic flows across different physical interfaces 🦋 It's assumed that the MN's IP-layer interface can attach to multiple MAGs at once or one after another, possibly over multiple media ✨ One way to get that multiple attachment is described in [RFC7847], which lets the MN carry traffic flows on different physical interfaces no matter what prefixes are assigned to those interfaces 🫶 Another option is to set up the MN's IP stack to behave according to the Weak ES Model (commonly called the weak host model) [RFC1122] 💅
So this document explains how to enable "flow mobility" in the PMIPv6 network (meaning the LMAs and MAGs) 🎀 To do that, two main things are needed: i) proper prefix management by the PMIPv6 network, and ii) consistent flow forwarding policies 🔥 This memo looks at different possible use case scenarios, each with its own prefix assignment requirements and therefore its own PMIPv6 network extensions for "flow mobility" 🌈
2. Terminology 💜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🫶
These terms come from Proxy Mobile IPv6 [RFC5213] 🦋
- Local Mobility Anchor (LMA)
- Mobile Access Gateway (MAG)
- Proxy Mobile IPv6 Domain (PMIPv6-Domain)
- LMA Address (LMAA)
- Proxy Care-of Address (Proxy-CoA)
- Home Network Prefix (HNP)
These terms come from the Multiple Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support [RFC6089] 🌸
- Binding Identification (BID) Number
- Flow Identifier (FID)
- Traffic Selector (TS)
These terms are defined and used in this document 💖
- Flow Mobility Initiate (FMI): A message the LMA sends to the MAG, carrying the info needed to enable flow mobility in a PMIPv6-Domain 🌈
- Flow Mobility Acknowledgement (FMA): A message the MAG sends back in reply to an FMI message 🎀
- Flow Mobility Cache (FMC): A conceptual data structure that supports the flow mobility management operations described in this document 🧚
3. Overview of the PMIPv6 Flow Mobility Extensions 🦋
3.1. Use Case Scenarios 💅
Typical handovers are when you give up a physical medium and then get it back again 🙈 Flow mobility is different, because it assumes an MN can have simultaneous access to more than one network 🔥 In this spec, the LMA is assumed to know that the MN can access both access networks at the same time, and that it can handle either the same set of prefixes or a different set on each access ✨ How that awareness happens is outside the scope of this spec 🫶
There are different flow mobility scenarios. In some, the MN might share one common set of prefixes across all of its physical interfaces. In others, the MN might have a different subset of prefixes configured on each physical interface 💖 The scenarios are:
- At the time of a new network attachment, the MN gets the same prefix, or the same set of prefixes, that's already assigned to an existing session. This isn't the default behavior with basic PMIPv6 [RFC5213], so the LMA needs to be able to give the same assignment even for simultaneous attachment (not just the handover case) 👑
- At the time of a new network attachment, the MN gets a new prefix or a new set of prefixes for the new session. This is the default behavior with basic PMIPv6 [RFC5213] 🌸
You can also mix the two above-mentioned scenarios 🌈 At the time of a new network attachment, the MN can get a combination of prefix(es) already in use and new prefix(es). That's a hybrid of the two scenarios above 🎀 The local policy decides whether the new prefix is exclusive to the new attachment or can also be assigned to an existing attachment 🧚
How to enable flow mobility in each of these scenarios is explained in Sections 3.2.1 and 3.2.2 💜
The extensions in this document support all of the scenarios above 🦋
3.2. Basic Operation 🌸
This section describes how the PMIPv6 extensions in this document enable flow mobility support 💖
Both the MN and the LMA MUST have local policies in place so that packets get forwarded coherently for unidirectional and bidirectional communications 🔥 How that consistency gets ensured is out of scope for this document 🫶 Either the MN or the LMA can start IP flow mobility. If the MN makes the flow mobility decision, the LMA follows it and updates its forwarding state to match ✨ The network can also trigger mobility on the MN side through out-of-band mechanisms (e.g., 3GPP / Access Network Discovery and Selection Function (ANDSF) sends updated routing policies to the MN) 🌈 In a given scenario and MN, the decision on IP flow mobility MUST be taken either by the MN or the LMA, but it MUST NOT be taken by both 💅👑
3.2.1. MN Sharing a Common Set of Prefixes on All MAGs ✨
okay so this one is the first use case from Section 3.1 🎀. When a new attachment happens, we need extensions to the basic PMIPv6 [RFC5213] signaling so that every interface on the same MN that's connected at the same time gets the same prefix (or set of prefixes) 🧚. After that, the local mobility anchor and the MAG don't need to chat any more. Flows just get forwarded according to the policy rules on the LMA and the MN 💅.
If the LMA hands out one common prefix (or set of prefixes) to all the physical interfaces in the domain, then every MAG already has the routing info it needs to forward uplink and downlink packets, once it's done its Proxy Binding Update / Proxy Binding Acknowledgement (PBU/PBA) registration 🦋. The LMA doesn't have to send any signaling to move flows between the different physical interfaces, because moving flows is its own local decision 👑. Signaling MAY be exchanged if the MAG needs flow-level info (for example, to link flows with the right QoS paths and/or to tell the MN [RFC7222]) 💜. That part is optional, so it's totally a vibe check.
The LMA needs to know when to give all of an MN's physical interfaces the same set of prefixes 🤔. It can figure that out in different ways, like policy configuration, default policies, and so on. In this document, we define a new Handoff Indicator (HI) value, ("Attachment over a new interface sharing prefixes" (6)) 🌈. With it, the MAG can tell the LMA that the same set of prefixes MUST be assigned to the MN 🔥. This spec also updates the considerations in Section 5.4.1 of [RFC5213] like this:
- If there is at least one Home Network Prefix Option present in the request with a NON_ZERO prefix value, there exists a Binding Cache Entry (BCE) (with all HNPs in the BCE matching the prefix values of all Home Network Prefix Options of the received Proxy Binding Update message), and the entry matches the MN identifier in the Mobile Node Identifier Option of the received Proxy Binding Update message, and the value of the HI of the received Proxy Binding Update is equal to "Attachment over a new interface sharing prefixes".
- If there is a Mobile Node Link-layer Identifier Option present in the request, and the BCE matches the Access Technology Type (ATT) and the MN-LL-Identifier, then the request MUST be considered as a request for updating that BCE. 🍓
- If there is a Mobile Node Link-layer Identifier Option present in the request, and the BCE does not match the Access Technology Type (ATT) and the MN-LL-Identifier, then the request MUST be considered as a request for creating a new mobility session sharing the same set of HNPs assigned to the existing BCE found. 🙈
- If there is not a Mobile Node Link-layer Identifier Option present in the request, then the request MUST be considered as a request for creating a new mobility session sharing the same set of HNPs assigned to the existing BCE found. ✨
LMA Binding Cache
+---+ ========================
|LMA| MN1, ATT1, pref1, MAG1
+---+ MN1, ATT2, pref1, MAG2
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| +-------+ |
| | I P | |
| +---+---+ |
|---|if1|if2|----|
+---+---+
MN1
Figure 1: Shared Prefix Across Physical Interfaces ScenarioOkay, let's walk through how flow mobility works in this case 🦋. In Figure 1, we've got a mobile node (MN1) with two physical interfaces: if1 (access technology type ATT1) and if2 (access technology type ATT2) 🎀. Each interface is hooked up to a different MAG, and both MAGs are run by the same LMA 💖. Both interfaces get the same prefix (pref1) when they attach to the MAGs 🧚. If the IP layer on the MN shows one single logical interface (like in [RFC7847]), then the MN has one IPv6 address configured at the IP layer, pref1::mn1 ✨. Otherwise, per-interface IPv6 addresses (like pref1::if1 and pref1::if2) get configured, and each address MUST be valid on every interface 🙈. We're going with the first case for the example below and for the rest of this doc 💅. To start, flow X goes through MAG1 and flow Y goes through MAG2 🌸. Later on, flow Y can be moved so it also goes through MAG1 🦋. Figure 2 shows the case where no flow-level info needs to be exchanged, so there's no signaling between the LMA and the MAGs at all 💜.
Lowkey important: if different IPv6 addresses are configured at the IP layer, IP-session continuity still works for each of the configured addresses 🫶. The network delivers packets for a particular IP address of the MN to whichever of the MN's physical interfaces the flow was moved to, and the MN also picks that same interface when it sends traffic back uplink 🔥.
+-----+ +------+ +------+ +-----+
Internet | LMA | | MAG1 | | MAG2 | | MN1 |
+-----+ +------+ +------+ +-----+
| | | | |
| flow X to | flow X to | flow X to |
| pref1::mn1 | pref1::mn1 | pref1::mn1 |
|<----------->|<------------->|<-------------------------->if1
| flow Y to | flow Y to | flow Y to |
| pref1::mn1 | pref1::mn1 | pref1::mn1 |
|<----------->|<----------------------------->|<---------->if2
| | | | |
| ============ | | ============
| || flow || | | || flow ||
| || policy || | | || policy ||
| || update || | | || update ||
| ============ | | ============
| | | | |
| flow Y to | flow Y to | flow Y to |
| pref1::mn1 | pref1::mn1 | pref1::mn1 |
|<----------->|<------------->|<-------------------------->if1
| | | | |
Figure 2: Flow Mobility Message Sequence with a Common Set of
PrefixesNext up is Figure 3 📊, which shows what the different network entities look like after we move flow Y in the example above 🧚. This doc reuses some of the terminology and mechanisms from the flow bindings and multiple care-of address registration specs 💖. Notice that the BIDs in this figure are assigned locally by the LMA, since nothing needs signaling in this scenario 🙈. That said, alternative implementations of flow routing at the LMA MAY be used, because they don't change how the solution works in this case 👑.
LMA Binding Cache LMA flowmob state
(BID, MN-ID, ATT, HNP, PCoA) (BID, TS)
+---+ =========================== ===================
|LMA| 1, MN1, ATT1, pref1, MAG1 1, flow X
+---+ 2, MN1, ATT2, pref1, MAG2 1, flow Y
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\ MAG1 routing state
+----+ +----+ ================================
|MAG1| |MAG2| (dest) (next hop)
+----+ +----+ pref1::/64 p2p-iface-with-MN1
| | ::/0 LMA
| |
| | MAG2 routing state
| +-------+ | ================================
| | I P | | (dest) (next hop)
| +---+---+ | pref1::/64 p2p-iface-with-MN1
|---|if1|if2|----| ::/0 LMA
+---+---+
MN1
Figure 3: Data Structures with a Common Set of Prefixes3.2.2. MN with Different Sets of Prefixes on Each MAG ✨
okay bestie, this scenario is sooo fun 💅. Here the LMA hands out a different set of prefixes to each physical interface of the same mobile node 🦋. It covers the second case, or a mix of cases, from Section 3.1. Extra signaling is needed between the LMA and the MAG so the MAGs know which prefixes the MN is going to receive traffic for, and their local routing entries get set up to match 🧚.
Signaling is needed whenever a flow gets moved from its original interface to a new one 🔁. Here's the tea 🍵: the LMA can't send a PBA that wasn't triggered by a PBU it received, so this spec uses two mobility messages, FMI and FMA 🫶. They use the format of the Update Notifications for PMIPv6 from [RFC7077]. The trigger for moving a flow can come from the MN (like layer-2 signaling with the MAG) or from the network (like congestion and measurements). The network then notifies the MN for the final IP flow mobility decision, as Section 3.1 explains 🌸. Policy management functions like 3GPP/ANDSF can be used for that 💜. How the network actually notifies the MN is out of scope for this document 🙈.
If a flow is moved from its default path (the one determined by its destination prefix) to a different one, the LMA builds an FMI message 📦. This message includes a Home Network Prefix Option for each prefix that should get flow mobility support on the new MAG. These prefixes aren't anchored by the target MAG, so the MAG MUST NOT advertise them on the MAG-MN link, and the off-link bit (L) is set to one 🚫. The FMI MUST be sent to the new target MAG, which is the one selected to forward the flow. The MAG replies with an FMA 💌. Here's the message sequence, shown in Figure 4 🎀.
+-----+ +------+ +------+ +-----+
Internet | LMA | | MAG1 | | MAG2 | | MN1 |
+-----+ +------+ +------+ +-----+
| | | | |
| flow X to | flow X to | flow X to |
| pref1::mn1 | pref1::mn1 | pref1::mn1 |
|<----------->|<------------->|<-------------------------->if1
| flow Y to | flow Y to | flow Y to |
| pref2::mn1 | pref2::mn1 | pref2::mn1 |
|<----------->|<----------------------------->|<---------->if2
| | | | |
| ============ | | ============
| || flow || | | || flow ||
| || policy || | | || policy ||
| || update || | | || update ||
| ============ | | ============
| | | | |
| | FMI[MN1-ID, HNPs] | |
| |-------------->| | |
| | FMA | | |
| |<--------------| | |
| flow Y to | flow Y to | flow Y to |
| pref2::mn1 | pref2::mn1 | pref2::mn1 |
|<----------->|<------------->|<-------------------------->if1
| | | | |
Figure 4: Flow Mobility Message Sequence When the LMA Assigns
Different Sets of Prefixes per Physical InterfaceNow let's check the state in the network after a flow moves when the LMA assigns a different set of prefixes 👀. It's shown in Figure 5.
LMA Binding Cache LMA flowmob state
(BID, MN-ID, ATT, HNP, PCoA) (BID, TS)
+---+ ============================ ===================
|LMA| 1, MN1, ATT1, pref1, 1, flow X
+---+ pref2, MAG1 1, flow Y
//\\ 2, MN1, ATT2, pref2, MAG2
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\ MAG1 routing state
+----+ +----+ ================================
|MAG1| |MAG2| (dest) (next hop)
+----+ +----+ pref1::/64 p2p-iface-with-MN1
| | pref2::/64 p2p-iface-with-MN1
| | ::/0 LMA
| |
| +-------+ | MAG2 routing state
| | I P | | ================================
| +---+---+ | (dest) (next hop)
|---|if1|if2|----| pref2::/64 p2p-iface-with-MN1
+---+---+ ::/0 LMA
MN1
Figure 5: Data Structures When the LMA Assigns a Different Set of
Prefixes3.3. Use of PBU/PBA Signaling
This specification introduces the FMI/FMA signaling, which lets the LMA swap required information with the MAG to enable flow mobility without waiting for a PBU 🏃♀️💨. But sometimes the trigger for flow mobility is tied to a new MN interface attachment. In that case, the PBA sent in response to the PBU received from the new MAG can carry the same signaling the FMI does ✨. So here the LMA MUST include a Home Network Prefix Option in the PBA for each prefix that should get flow mobility support on the new MAG, with the off-link bit (L) set to one 💅.
3.4. Use of Flow-Level Information
This specification doesn't mandate that flow-level information gets exchanged between the LMA and the MAG to provide flow mobility support 🙅♀️. It only requires that the LMA keeps a flow-level state (Section 5.2). That said, there are situations where the MAG might need to know which flow(s) are coming in on a prefix that has been moved, so it can link them to the proper QoS path(s) and, optionally, let the MN know 🎀. This section describes the extensions used to put flow-level information into the signaling between the LMA and the MAG 📨.
This specification reuses some of the mobility extensions and message formats from [RFC5648] and [RFC6089], namely the Flow Identification Mobility Option and the Flow Mobility Sub-Options 🧩.
If the LMA wants to send flow-level information to the MAG, it MUST include in the FMI (or the PBA) a Flow Identification Mobility Option for all the flows the MAG needs to be aware of at flow granularity. Each Flow Identification Mobility Option MUST include a Traffic Selector Sub-Option with that flow-level information 🔍.
To remove a flow-binding state at the MAG, the LMA just sends an FMI (or a PBA, if it's responding to a PBU) that includes flow identification options for all the flows that need to be refreshed, modified, or added. It simply leaves out the ones that should be removed 🗑️.
Even when a common set of prefixes is used, giving the MAG flow-level information still requires signaling between the LMA and the MAG 🫶. This is done by sending an FMI message (or a PBA, if it's sent in response to a PBU).
4. Message Formats 🎀
This section defines modifications to the PMIPv6 [RFC5213] protocol messages 💜.
This specification requires implementation of Update Notification (UPN) [RFC7077] and Update Notification Ack (UPA) [RFC7077] messages, using the specific Notification Reason and Status Code values defined by this document. This document doesn't require implementing any other aspects of [RFC7077] 🙌.
4.1. Home Network Prefix
A new flag (L) is added to the Home Network Prefix Option so the MAG knows whether the conveyed prefix has to be hosted on-link on the point-to-point interface with the MN, or not. A prefix is hosted off-link for the flow mobility purposes defined in this document 🦋. The rest of the Home Network Prefix Option format stays the same as defined in [RFC5213] 🧁.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |L| Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Off-link Home Network Prefix Flag (L):
The Off-link Home Network Prefix Flag tells the MAG that the HNP in the option is not to be hosted on-link, but has to be considered for flow mobility purposes and therefore added to the MAG routing table 🗺️. If the flag is set to 0, the MAG assumes that the HNP has to be hosted on-link 🏡.
4.2. Flow Mobility Initiate (FMI)
The FMI message used in this specification is the UPN message specified in [RFC7077] 📬. Its message format, transport, and security considerations are as specified in [RFC7077]. The format of the message is specified in Section 4.1 of [RFC7077]. This specification doesn't modify the UPN message, but it does define the following new notification reason value for use in this specification ✨:
Notification Reason:
FLOW-MOBILITY (8): Request to add/refresh the prefix(es) conveyed in the Home Network Prefix Options included in the message to the set of prefixes for which flow mobility is provided 🌈.
The Mobility Options field of an FMI MUST contain the MN-ID, followed by one or more Home Network Prefix Options. Prefixes for which flow mobility was provided that aren't present in the message MUST be removed from the set of flow mobility-enabled prefixes 🧹.
4.3. Flow Mobility Acknowledgement (FMA)
The FMA message used in this specification is the UPA message specified in Section 4.2 of [RFC7077] 💌. Its message format, transport, and security considerations are as specified in [RFC7077]. The format of the message is specified in Section 4.2 of [RFC7077]. This specification doesn't modify the UPA message, but it does define the following new status code values for use in this specification 🫶:
Status Code:
0: Success131: Reason unspecified132: MN not attached
When the Status code is 0, the Mobility Options field of an FMA MUST contain the MN-ID, followed by one or more Home Network Prefix Options 🥰.
5. Conceptual Data Structures 🧠
This section sums up the extensions to PMIPv6 that are needed to manage flow mobility 💖.
5.1. Multiple Proxy Care-of Address Registration 💖
okay so the LMA's binding cache gets a glow-up ✨ It can now take multiple proxy care-of address (Proxy-CoA) registrations, so the mobile node can keep using the same address (prefix) even when it's beyond a single interface and MAG 🦋 The LMA keeps multiple BCEs for an MN. The number of BCEs for an MN equals the number of the MN's interfaces attached to any MAGs.
This spec reuses the extensions from [RFC5648] to manage multiple registrations, but in the PMIPv6 context 💅 The binding cache is extended to hold more than one proxy care-of address and to link each one to a BID. Note that the BID is a local identifier. The local mobility anchor assigns and uses it to figure out which entry of the FMC decides how a given flow gets routed 🧚
+---------+-----+-------+------+-----------+------------+
| BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA |
+---------+-----+-------+------+-----------+------------+
| 20 | 1 | MN1 | WiFi | HNP1,HNP2 | IP1 (MAG1) |
| 30 | 2 | MN1 | 3GPP | HNP1,HNP3 | IP2 (MAG2) |
+---------+-----+-------+------+-----------+------------+
Figure 6: Extended Binding CacheFigure 6 is an example of an extended binding cache with two BCEs for a mobile node called MN1, which is connected through two different access technologies 🌸 Both attachments share the same prefix (HNP1), but they're bound to two different Proxy-CoAs (two MAGs). Iconic multihoming behavior ngl 👑
5.2. Flow Mobility Cache (FMC) 🌸
Each LMA MUST maintain an FMC as shown in Figure 7. The FMC is a conceptual list that's separate from the binding cache 💖 It has one entry for each registered flow. This spec reuses the format of the flow-binding list from [RFC6089]. Each entry includes these fields:
- Flow Identifier Priority (FID-PRI)
- Flow Identifier (FID)
- Traffic Selector (TS)
- Binding Identification (BID)
- Action
- Active/Inactive
+---------+-----+-----+------+---------+----------+
| FID-PRI | FID | TS | BIDs | Action | A/I |
+---------+-----+-----+------+---------+----------+
| 10 | 2 | TCP | 1 | Forward | Active |
| 20 | 4 | UDP | 1,2 | Forward | Inactive |
+---------+-----+-----+------+---------+----------+
Figure 7: Flow Mobility CacheThe BID field holds the identifier of the BCE that packets matching the flow info in the TS field get forwarded to. When it's decided that a flow should move, the affected BID(s) in the table get updated 🦋
Like the flow binding from [RFC6089], each FMC entry points to a specific BID. When a flow moves, the LMA just updates the pointer of the flow-binding entry to the BID of the interface where the flow is going 💅 The TS in the flow-binding table is defined in [RFC6088]. TS classifies packets of flows based on specific parameters like service type, source and destination address, and so on. Packets matching the same TS get the same forwarding policy. FID-PRI is the order of precedence for taking action on the traffic. The action may be to forward or drop. If a binding entry becomes "Inactive", it doesn't affect data traffic. An entry only becomes "Inactive" if all of the BIDs are de-registered 😭
The MAG MAY also maintain a similar data structure. If no full flow mobility state is needed at the MAG, the Binding Update List (BUL) data structure is enough, and no extra conceptual data entries are needed 🧚 If full per-flow state is required at the MAG, it SHOULD also maintain an FMC structure.
6. Mobile Node Considerations 🎀
This spec assumes the mobile node's IP-layer interface can attach to multiple MAGs at the same time and/or one after another, possibly over multiple media 📱 The MN MUST be able to enforce uplink policies to pick the right outgoing interface. One alternative for this multiple attachment is described in [RFC7847], which lets the MN support traffic flows on different physical interfaces, no matter which prefixes are assigned to those interfaces 💜 Another option is configuring the MN's IP stack to behave according to the weak host model [RFC1122].
7. IANA Considerations 🦋
This spec sets up new assignments in the IANA mobility parameters registry:
- Handoff Indicator Option type: "Attachment over a new interface sharing prefixes" has been assigned the value 6 from the "Handoff Indicator Option type values" registry, defined in
http://www.iana.org/assignments/mobility-parameters. - Update Notification Reason: "FLOW-MOBILITY" has been assigned the value 8 from the "Update Notification Reasons Registry", defined in
http://www.iana.org/assignments/mobility-parameters. - Update Notification Acknowledgement Status: "Reason unspecified" has been assigned the value 131, and "MN not attached" has been assigned the value 132, from the "Update Notification Acknowledgement Status Registry".
8. Security Considerations ⚠
Hold onto your bonnets, bestie, this one's serious 😭
The protocol-signaling extensions in this document share the same security concerns as Proxy Mobile IPv6 [RFC5213]. They don't pose any extra security threats beyond the ones already identified in [RFC5213] and [RFC7077] 🔥
The MAG and the LMA MUST use the IPsec security mechanism that Proxy Mobile IPv6 [RFC5213] mandates to secure the signaling described in this document. No skipping this part, periodt 💀
9. References 📚
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008,
<http://www.rfc-editor.org/info/rfc5213>.
[RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst,
T., and K. Nagami, "Multiple Care-of Addresses
Registration", RFC 5648, DOI 10.17487/RFC5648, October
2009, <http://www.rfc-editor.org/info/rfc5648>.
[RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings", RFC 6088,
DOI 10.17487/RFC6088, January 2011,
<http://www.rfc-editor.org/info/rfc6088>.
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
Network Mobility (NEMO) Basic Support", RFC 6089,
DOI 10.17487/RFC6089, January 2011,
<http://www.rfc-editor.org/info/rfc6089>.
[RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and
J. Korhonen, "Update Notifications for Proxy Mobile IPv6",
RFC 7077, DOI 10.17487/RFC7077, November 2013,
<http://www.rfc-editor.org/info/rfc7077>.9.2. Informative References
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[RFC7222] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S.
Gundavelli, "Quality-of-Service Option for Proxy Mobile
IPv6", RFC 7222, DOI 10.17487/RFC7222, May 2014,
<http://www.rfc-editor.org/info/rfc7222>.
[RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface
Support for IP Hosts with Multi-Access Support", RFC 7847,
DOI 10.17487/RFC7847, May 2016,
<http://www.rfc-editor.org/info/rfc7847>.Acknowledgments 🫶
The authors would like to thank Vijay Devarapalli, Mohana Dahamayanthi Jeyatharan, Kent Leung, Bruno Mongazon-Cazavet, Chan-Wah Ng, Behcet Sarikaya, and Tran Minh Trung for their valuable contributions, which helped make this document happen 💖
The authors would also like to thank Juan-Carlos Zuniga, Pierrick Seite, and Julien Laganier for all the useful discussions on this topic 🌈
Finally, the authors would like to thank Marco Liebsch, Juan-Carlos Zuniga, Dirk von Hugo, Fabio Giust, and Daniel Corujo for their reviews of this document ⭐
The work of Carlos J. Bernardos has been partially performed in the framework of the H2020-ICT-2014-2 project 5G NORMA 🎀
Contributors 🌸
This document reflects contributions from the following authors (in alphabetical order).
Kuntal Chowdhury
Email: kc@altiostar.com
Sri Gundavelli
Email: sgundave@cisco.com
Youn-Hee Han
Email: yhhan@kut.ac.kr
Yong-Geun Hong
Email: yonggeun.hong@gmail.com
Rajeev Koodli
Email: rajeevkoodli@google.com
Telemaco Melia
Email: telemaco.melia@googlemail.com
Frank Xia
Email: xiayangsong@huawei.comAuthor's Address 🍓
Carlos J. Bernardos (editor)
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/📦 where this page comes from
- ietf: rfc7864 2016-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms