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

(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)

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 IF1 ------>|<== Tunnel_1 ==>| | Sends RS via IF2 ---------------------------------------->| | | |<== Tunnel_2 ==>| IF1 <----Rtr Adv--| | | IF2 <-------------------------------------Rts Adv---| Flow_1 from IF1-------->| | | | (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 IF2 ---------------------------------------->| | | | (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

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

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

draft-koodli-netext-flow-handover 8/28/2018 12: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

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