1. Flow mobility support in PMIPv6 draft-trung-netext-flow-mobility-support-01 T. Tran, Y. Hong (ETRI) Y. Han (KUT) 2/12/20141 trungtm2909@gmail.com IETF 79 - Beijing

2. Outlines Flow mobility requirements Necessary PMIPv6 extensions NS3 implementation Conclusions 2/12/20142 trungtm2909@gmail.com

3. Flow mobility requirements (1) 5-tuple based flow description: Home Network Prefix should be able to be shared across its attachments (called shared-prefix model) 2/12/20143 trungtm2909@gmail.com

4. Flow mobility requirements (2) HNP based flow description: the HNP is not needed to be shared across interface. Unique-prefix can be assigned to each IF. 2/12/20144 trungtm2909@gmail.com

5. Flow mobility requirements (3) LMA should support flow-based routing 2/12/20145 trungtm2909@gmail.com TS (Flow inf.)HNPATTProxyCoA 1 (Voice)HNP13GPPMAG1 2 (Video)HNP1WiFiMAG2 FlowHNPATTProxyCoA 1 (Voice)HNP13GPPMAG1 2 (Video)HNP2WiFiMAG2 5-tuple based flow description HNP based flow description

6. PMIPv6 extensions for supporting shared prefix model Pro-active signaling – The same HNPs are assigned to all interfaces in advance Re-active signaling – HNP is shared across interfaces only when the flow mobility is occurred 2/12/20146 trungtm2909@gmail.com

7. 2/12/2014 trungtm2909@gmail.com 7 Pro-Active Signaling (1) Modify PBA message to include the HNPs that are assigned to the existing attachments (2) Extend the signaling between LMA/MAG to update new HNP to the MAG

8. 2/12/2014 trungtm2909@gmail.com 8 Re-Active Signaling (1) Extend the signaling between LMA/MAG to update new HNP to the MAG

9. PMIPv6 extensions for supporting Flow-based routing (1) Extend BCE to support multiple Care-of Address registration 2/12/2014 trungtm2909@gmail.com 9 BIDMN-IDATTHNPProxy-CoA 1MN13GPPHNP1IP1 (MAG1) 2MN1WiFiHNP2IP2 (MAG2) BIDMN-IDATTHNPProxy-CoA 1MN13GPPHNP1IP1(MAG1) 2MN1WiFi HNP 2 + HNP1 IP2(MAG2) (1) The MN1 attached to the network using 2 interfaces (2) LMA requests MAG2 to updated with HNP1

10. PMIPv6 extensions for supporting Flow-based routing (2) Add flow binding function to the LMA 2/12/2014 trungtm2909@gmail.com 10 (1) Before the flow mobility occurs (2)After the LMA decides to move TCP flow 1 to the MAG 2 FIDTSBIDActionMode 1TCP (Flow1)1ForwardActive 2UDP2ForwardInactive FIDTSBIDActionMode 1TCP (Flow1)2ForwardActive 2UDP2ForwardInactive

11. Implementation in NS3 We are now implementing our proposals in NS3 Why NS3? – It supports multi-interface nodes In our simulation, an MN will have WLAN, WiMAX, 3GPP interfaces. and also logical interface! – It supports (near-complete) IPv6 stack – It conforms to standard input/output formats so that other tools can be reused. e.g., pcap trace output 2/12/2014 trungtm2909@gmail.com 11

12. Conclusions PMIPv6 can be extended in two ways to support flow mobility: Pro-active and Re- active signaling No flow information is needed to be sent from LMA to MAG To support full flow granularity movement we should differentiate flows by using 5-tuple inf., otherwise we can support just partial handoff. The MN just obeys the flow policy from the network. It always uses the same interface to receive and send packets of a flow. 2/12/2014 trungtm2909@gmail.com 12

13. Q & A Thank you! 2/12/2014 trungtm2909@gmail.com13