Transcript netext-6

draft-jeyatharan-netext-pmip-partial-handoff-02
Operation
LMA
[3]
 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]
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]
[1]
MAG-S
MAG-T
[1]
[1]
MN
draft-melia-netext-flow-mob-solution-01
SOLUTION OVERVIEW
REQUIREMENTS
CN2
CN1
• Light extension to RFC 5213
• Limited to Per-MN prefix model
• Orthogonal to PMIPv6 handover
LMA state
(addr, pCoA1, flow1, mgid)
(addr, pCoA2, flow2, mgid)
LMA
•Flow mobility service as part of the
default MN profile
pCoA1
• Support of network-controlled traffic
differentiation
• None or limited effort at MN
• Extensible specification
pCoA2
MAG1
MAG state
if1 -> mgid
MAG2
if1
if2
MN
Addr
(logical IP interface)
MAG State
if2 -> mgid
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 ->|
|
|
|
|
Flow Binding Update (FBU) Messages
+-----+
+-----+
+-----+
+-----+
| 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 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- ietfmext-binary-ts. Or the new traffic selector can be defined
IKEv2 based flow control extension of PMIPv6
(http://tools.ietf.org/id/draft-liu-netext-flow-pmip-01.txt)
 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
Defines Flow Start,
Terminate and
Flow Binding Refresh messages
Internet
4 LMA decides to use LTE for
LMA
Flow 1
3
Flow 2 (e.g., as a response to
VoIP call set up)
5
LMA and MAG
establish binding
IP Network
MAG2
MAG1
LMA and MAG exchange
Flow Handover Request and
Response Messages
6 Flow 2 starts on LTE
interface
1
UE attaches to
Network 1
(e.g., WiFi)
2 UE attaches to
Network 2
(e.g., LTE)
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