1. draft-jeyatharan-netext-pmip-partial-handoff-02
LMA
[3]
Operation
MN sends partial handoff trigger to MAG-T or MAG-S . Partial handoff trigger comprises of sub set of prefixes that needs to be transferred from one interface to a new one or existing interface [1]
T-MAG inserts new HI option value to inform partial handoff of prefix to LMA in PBU. Sub set of prefixes that needs to be transferred are inserted in HNP options [2]
LMA revokes the subset of prefixes from previous connection and informs MAG-S [3]
[2]
[1]
MAG-S
MAG-T
[1]
[1] MN
Role of MN
MN’s preference regarding flow mobility sent to target MAG using L2 procedure or stored at source MAG and transferred via context transfer
MN has virtual interface implementation. Partial flow mobility or partial handoff of sub set prefixes handled transparently without any changes to IP layer and applications

2. (logical IP interface)
draft-melia-netext-flow-mob-solution-01
SOLUTION OVERVIEW
REQUIREMENTS
CN1
CN2
Light extension to RFC 5213
Limited to Per-MN prefix model
Orthogonal to PMIPv6 handover
Flow mobility service as part of the default MN profile
Support of network-controlled traffic differentiation
None or limited effort at MN
Extensible specification
LMA
LMA state
(addr, pCoA1, flow1, mgid) (addr, pCoA2, flow2, mgid)
pCoA1
pCoA2
MAG1
MAG2
MAG state if1 -> mgid
if1
if2
MAG State if2 -> mgid MN
Addr
(logical IP interface)

3. Flow tracking procedure for PMIPv6 draft-trung-netext-flow-tracking-00
Necessary extensions
Add a new field to BCE and BULE for storing Flow Identification (eg. Flow-Label, 20bits)
Add Flow Identification mobility option to PBU, PBA to perform Flow Binding Update (FBU)
Extend the operation of MAG and LMA
MAG operation
Analyzes IPv6 packets headers for tracking the Identification of new flow sent from MN
Updates BULE with the Identification of the new Flow
Sends Flow Binding Updates message to inform LMA about a new flow sent via MAG
LMA operation
Analyzes FBU messages coming from MAG
Updates BCE, binds the flow to the appropriate tunnel (Proxy-CoA)
Sends FBA to MAG for setting up new routing path for the flow
| MN | |MAG 1| | LMA | |MAG 2|
| | | |
Sends RS via IF >|<== Tunnel_1 ==>| |
Sends RS via IF >|
| | |<== Tunnel_2 ==>|
IF1 <----Rtr Adv--| | |
IF2 < Rts Adv---|
Flow_1 from IF >| | |
| (1) Analyzes Flow_1’s ID | |
| (2) Updates BULE | |
| |-(3) Send FBU ->| |
| | Binds Flow_1 to Tunnel_1 |
| |<-- Sends FBA --| |
|<-Flow 1 Data ->|<-Flow 1 Data ->| |
| | |
| MN | |MAG 1| | LMA | |MAG 2|
| | | |
Flow_1 moves | | |
From IF1 to IF >|
| | | (1) Analyzes
| | | Flow_1’s ID
| | | (2) Update BULE
| | |<-(3)Sends FBU -|
| | (1) Analyzes FBU | | | (2) Binds Flow_1 to Tunnel_2 |
| | |-(3) Sends FBA->|
|<-Flow 1 Data ->|< Flow 1 Data >|
Flow Binding Update (FBU) Messages
Flow 1 moves from IF1 to IF2

4. Service Flow Identifier in Proxy Mobile IPv6 draft-hui-netext-service-flow-identifier
This document proposes service flow identifier option to PMIP6 that
Allows flow identification and binding
Enable PMIP tunnels set up based on the service flow granularity between a pair of LMA/MAG
Service Flow Identifier option
included in the PBU/PBA
Service Flow Identifier
the unique identifier within the LMA for the service flow of the mobile node.
Service Flow Description option
The detailed binary could follow the defined binary traffic selector in draft- ietf-mext-binary-ts. Or the new traffic selector can be defined

5. IKEv2 based flow control extension of PMIPv6 (http://tools. ietf
Motivation
Flow mobility requires UE and network to communicate about flow control information
Which flow the UE wants to take action
Action: routing filter
It is preferred to reuse existing protocol between the UE and WAG
In 3GPP scenario, S2b interface is based on PMIPv6; ePDG acts as MAG
There is IKEv2/IPSec protocol running between the UE and ePDG
Whether it is feasible to extend IKEv2 configuration payload to carry flow control information
Proposal:
New configuration attribute type and value
Configuration payload of IKEv2
New extension of configuration attributes

6. draft-koodli-netext-flow-handover
8/28/ :13 PM
draft-koodli-netext-flow-handover
Defines Flow Start,
Terminate and
Flow Binding Refresh messages
Internet 4
LMA decides to use LTE for
Flow 2 (e.g., as a response to
VoIP call set up)
LMA
Flow 1 3
LMA and MAG
establish binding 5
LMA and MAG exchange
Flow Handover Request and
Response Messages
IP Network
MAG1
MAG2
Flow 2 starts on LTE
interface 6
UE attaches to
Network 1
(e.g., WiFi) 1
UE attaches to
Network 2
(e.g., LTE) 2 MN

7. Way Forward
The WG will make use of the Logical Interface as the basis for flow mobility work
The signaling is limited to LMA and MAGs
A common protocol specification, making use of the existing documents and the Logical Interface, will be produced
Target date for the initial version is June’10