mofi paper 2011 pmip

8/13/2019 Mofi Paper 2011 Pmip

1/6

PMIPv6-based Flow Mobility Simulation in NS-3

Hyon-Young Choi and Sung-Gi MinDepartment of Computer and Radio Communication Engineering,

Korea University,

Seoul, South Korea

Email: [email protected]

Youn-Hee HanSchool of Computer Science and Engineering,

Korea University of Technology and Education,

CheonAn, South Korea

AbstractProxy Mobile IPv6 (PMIPv6) is a network-basedmobility support protocol and it does not require MNs to beinvolved in the mobility support signaling. In flow mobilitysupport, although the virtual interface in the MN solved theproblems of vertical handover or flow mobility in heterogeneousnetwork, missing procedure of MN-derived flow handover makesflow mobility in PMIPv6 incomplete.

In this paper, enhanced flow mobility support is proposedfor actualizing and full-covering of the flow mobility supportin PMIPv6. Enhanced flow mobility support is based on a

virtual interface in the MN. Virtual interface makes all physicalinterfaces to hide from the network layer and above. FlowInterface Manager is placed at the virtual interface and FlowBinding Manager in the LMA is paired with Flow InterfaceManager. They manage the flow bindings and are used toselect proper access technology to send packets. Flow mobilityprocedure begins with three different triggering cases, which arecaused by new connection from the MN, the LMAs decision,and request from the MN, respectively. Simulation using NS-3network simulator is performed to provide clear and practicalprocedure of enhanced flow mobility support in PMIPv6.

Index TermsProxy Mobile IPv6; Flow Mobility; NS-3 Net-work Simulator

I. INTRODUCTION

The wireless network is increasing quickly with full growth

of wired network in communication market of recent times.

Equally, with the rapid growth in the number of mobile

subscribers and mobile nodes (MNs) such as cellular phone,

PDA (Personal Digital Assistant), and laptop computer, the

demand for the seamless mobility services such as VoIP (Voice

over IP), media streaming, is becoming one of the most

important issue in the mobility management. Moreover, such

mobile nodes often have more than one wireless interfaces.

As mobile devices can utilize various interfaces to access

the Internet, the demand of inter-technology handover (i.e.,

vertical handover) and flow mobility is becoming another

important issue in the mobility management as well.The network-based mobility management protocol called

Proxy Mobile IPv6 (PMIPv6) [1] is being actively standard-

ized by the IETF NetExt Working Group, and is starting to

attract much attention among the telecommunication com-

munity and Internet community. Unlike the various existing

protocols for IP mobility management such as MIPv6, which

are host-based approaches, a network-based approach such as

PMIPv6 has salient features and is expected to expedite the

real deployment of IP mobility management.

The fundamental foundation of PMIPv6 is based on MIPv6

[2] in the sense that it extends MIPv6 signaling and reuses

many concepts such as the home agent (HA) functionality.

However, PMIPv6 is designed to provide network-based mo-

bility management support to an MN in a topologically local-

ized domain. Therefore, an MN is exempted from participation

in any mobility-related signaling, and the proxy mobility agent

in the serving network performs mobility-related signaling on

behalf of the MN. Once an MN enters its PMIPv6 domain andperforms access authentication, the serving network ensures

that the MN is always on its home network and can obtain

its home address (HoA) on any access network. That is, the

serving network assigns a unique home network prefix to

each MN, and conceptually this prefix always follows the

MN wherever it moves within a PMIPv6 domain. From the

perspective of the MN, the entire PMIPv6 domain appears as

its home network. Accordingly, it is needless (or impossible)

to configure the care-of address (CoA) at the MN.

Despite the fact that network-based mobility management

is considered a better solution than host-based solution, the

progress of completing the detailed scheme is quite late. More-

over, there are some problems about flow mobility support.In this paper, we introduce enhanced flow mobility support.

Enhanced flow mobility support is based on the virtual inter-

face in the MN. Virtual interface makes all physical interfaces

to hide from the network layer and above. Flow Interface

Manager is placed at the virtual interface and Flow Binding

Manager in the LMA is paired with it. They manage the

flow bindings and are used to select proper access technology

to send the packet. Flow mobility procedure is divided into

three cases, which are caused by new connection from the

MN, the LMAs decision, and the MNs decision respectively.

HNP Update Request/Acknowledge message is defined for

LMA decision-based flow mobility. According to the concept

of network-based flow mobility, MN-derived flow handoverneeds the approval of the LMA.

I I . RELATEDW ORKS

There are several primitive solutions for supporting flow

mobility in PMIPv6 [4] [5] [6]. These approaches try to

support flow mobility without MNs involvement because

PMIPv6 is well-designed to support inter-technology han-

dover. However, performing inter-technology handover only in

the network side without MNs involvement has many practical

2011 Fifth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing

978-0-7695-4372-7/11 $26.00 2011 IEEE

DOI 10.1109/IMIS.2011.103

531

2011 Fifth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing

978-0-7695-4372-7/11 $26.00 2011 IEEE

DOI 10.1109/IMIS.2011.103

475


2/6

issues [9]. Major issue is that the session cannot be sustained

because the configured address of each interface which is

created based on different interface identifier is not matched.

The issues of supporting inter-technology handover in

PMIPv6 mean that the MN should be modified. Moreover,

in flow mobility handover, to sustain the session of traffic, the

IP address must be the same even when the vertical handover

is performed. The MN with physical interfaces only cannot

afford it without any modification. Logical interface supports

[7] [8] [9] are proposed as a solution of network-based scheme

for multi-homing, vertical handover, and flow mobility.

There is a logical interface as well as physical interface

in the MN, and IP layer always exchanges data only with the

logical interface. Therefore, IP layer and above think that there

is only one interface even if the MN has many interfaces. In

the procedure of logical interface, it must have the dispatch

module used to decide which physical interface is chosen to

send data traffic. For the MN under PMIPv6 domain, as home

network prefix (HNP) is assigned to each physical interface,

HNP is the important metric for dispatch module in the logical

interface.PMIPv6 extension [10] is the major solution of IETF NetExt

WG. It assumes that MN has multiple physical interfaces and a

logical interface. IP layer only operates with logical interface.

Hence, sending packets from MNs IP layer are delivered to

the logical interface, and it forwards them to the network

through the appropriate physical interface. All packets that

arrived at physical interfaces are forwarded to logical interface

first, and then, they are delivered to the network layer.

The critical issues for supporting flow mobility are solved by

adapting virtual interface on the MN. However, the solution

of [10] has some issues. At first, there is no MN-initiated

flow mobility. Network-based flow mobility should support

flow handover from an interface to another interface based onthe networks decision. However, it is not the full support of

flow mobility without considering the flow handover request

of the MN, that is, the situation that the MN wants to move a

flow from the currently served interface to another interface.

It does not mean that the network approves the flow handover

whenever the MN wants but the MNs flow handover request

should support under the control of the network. Secondly,

it does not have detailed definition of the flow and the flow

management scheme in the LMA and the MAG.

III. PMIPV6- BASEDF LOW M OBILITY S CHEME

A. Architectural DesignTo manage and process flow handover, basic definitions of

flow, session, and traffic selector is needed.

A flow is defined as a series of packets matching a particular

flow description. To define a flow description, various param-

eters which are mentioned for defining a flow in [3] can be

used. Significant and frequently used parameters among these

are 5-tuple such as source address, destination address, source

port, destination port, and protocol. So, in this paper, these

5-tuple parameters are used for defining a flow.

Fig. 1. MN Stack Architecture

If a flow is represented with 5-tuple informationi, it implies

a direction because there is a source node for sending a traffic

and a destination node for receiving the traffic. So, a flow

can be categorized into inbound flow and outbound flow.

Inbound flow is sent from a CN and finally received at the

MN. Outbound flow is, on the contrary, sent from the MN to

a CN. What LMA manages is which MAG (i.e., which tunnel

interface) is used for an inbound flow. The LMA manages

inbound flow only because there are multiple paths through

MAGs for the inbound flows in the LMA whereas there is a

path for the outbound flow to the CN. As the same reason asthe LMA, the MN manages only outbound flow.

A session can be defined as a symmetrically congruent

pair of flows in case of bidirectional session. If a session is

unidirectional, a flow can be a session.

Traffic selector is the information which is used for traffic

filtering to decide which MAG the traffic is forwarded to. The

definition of traffic selector is the same as that of flow. The

difference is that traffic selector can use a wildcard symbol (*,

asterisk) to match any value among 5-tuple in a flow.

The information of traffic selector and the priority list of

access technologies are managed as a flow binding.

Figure 1 depicts the stack architecture for flow mobility in

the MN. Virtual Interface layer is placed between networklayer and data link layer in the figure. It consists of Virtual

Interface and Flow Interface Manager. All packets from the

lower layer and from the upper layer are passed through the

Virtual Interface layer. Network layer and upper layers only

see Virtual Interface as a network interface. This can solve

many problems including address problem while performing

vertical handover or flow handover. Flow Interface Manager

makes a decision for choosing the physical interface for the

outbound flow from upper layers. Flow Interface Manager has

Flow Interface List for efficient physical interface choice.

Each entry of Flow Interface List contains flow ID, priority,

traffic selector, outbound interfaces, type, and lifetime fields.

Each entry is identified by flow ID. Traffic selector is used formatching the traffic with the entries. The matching order of

each entry is based on priority field. Outbound interface list

has the ordered list of physical interfaces and it is used for

selecting outgoing interface for the matched flow. It is noted

that outbound interface saved in the policy profile has only

access technology type. The information of physical interface

index matching with access technology type is filled after the

entry is inserted at Flow Interface List. In type field, available

values are static and dynamic. Static type means that the

532476


3/6

Fig. 2. LMA Stack Architecture

entry is created by policy profile and dynamic type means

that the entry is created dynamically. Static-typed entry has

infinite lifetime and dynamic-typed entry has definite lifetime

for validity check.

Like the MN, the LMA also manages Flow Binding List in

Flow Binding Manager as shown in Figure 43. The difference

of Flow Binding Manager is that it manages flow binding for

inbound flow and flow binding list contains binding cache

entry matched with the access technology type.

B. Flow Handover Procedure

If the MN-initiated flow handover is considered, the starting

of flow handover can be made by following three triggering

cases:

1) Flow Mobility by a New Connection: If the MN is

connected to the network with new physical interface,

the flow mobility can be supported. In this case, the flow

binding information in the LMA and the MN is used for

the flow distribution.

2) Flow Mobility by LMAs Decision at a Time: the LMA

can get the link conditions such as the activation of the

wired/wireless link, congestion, the number of serving

nodes, or the number of flows. Therefore, the LMA can

start the flow handover by its own decision.

3) Flow Mobility by MNs Request and LMAs approval:

The MN may want to move a particular flow from served

interface to another interface. As the network-based flowmobility, the network should give a grant for the flow

handover. Hence, the MN must send a request to the

LMA for flow handover, and it can start flow handover

after receiving LMAs approval.

When a new physical interface is activated, there are two

actions that can be considered. One is that there is no flow

handover because all flows are using higher preferred inter-

faces. The other is that flow handover occurs. If flow handover

is expected for the new interface, the LMA assigns the same

home network prefix with the target flow. Otherwise, the LMA

assigns new home network prefix.

Figure 3 shows the flow handover procedure for the flow

mobility by a new connection. There are three traffic flowsover the interface 1. It is assumed that the interface 2 is

higher preferred interface for the flow Y. When 3G interface is

activated, flow Y will be moved into new interface. In binding

update process, because flow handover is expected for the

new interface, the LMA assigns HNP2 to the new interface.

Therefore, 3G interface got HNP2 as a home network prefix.

Figure 4 shows the case of flow mobility by LMAs de-

cision at a time. It also has two possible actions based on

whether the home network prefix of the target flow has been

Fig. 3. Flow Handover Procedure by New Connection

Fig. 4. Flow Handover Procedure by LMAs Decision at a Time

assigned to the target interface when the LMA decides to

move a flow to the other interface at one time. If the target

interface has the home network prefix of the target flow, the

flow handover is performed immediately. Otherwise, it needs

additional procedure to assign the home network prefix of the

target flow to the target interface. HNP Update Request (HUR)

and HNP Update Acknowledge (HUA) [11] are utilized for

this additional process. Then, the flow handover is performed.

Figure 5 depicts the the MN-derived flow handover pro-

cedure. New messages, Flow Handover Indicate and Flow

Handover Acknowledge are defined for flow handover fromthe MN. When the MN decides flow handover, it sends Flow

Mobility Indicate message with traffic selector of the flow

to be moved through the target interface. The message is

received by MAG, and then it sends PBU message with traffic

selector option to the LMA. LMA approves the request and

sends PBA message back to the MAG, and the MAG sends

Flow Mobility Acknowledge to the MN. After receiving flow

handover approval from the LMA, the MN moves the flow to

requested interface.

533477


4/6

Fig. 5. Flow Handover Procedure by MNs request and LMAs approval

Fig. 6. Simulation Topology

IV. SIMULATION ANDR ESULTS

NS-3 network simulator [12] [13] was used to perform sim-

ulation about flow mobility support. NS-3 is a new simulator

that is intended to eventually replace the aging NS-2. Even

though NS-2 still has a greater number of network models

included in the distribution, NS-3 has a good development

momentum, and is believed to have a better core architecture

and better suited to receive community contributions. NS-3

especially supports multiple interfaces fully in a node whereas

NS-2 cannot support purely.Figure 6 depicts the network topology with three physical

interfaces, WLAN, WiMax(WiBro), and 3G(PPP). Many CNs

are connected to the border router and can access the PMIPv6

domain network by passing through the LMA. The LMA

manages three MAGs. The wired link speed is all 100 Mbps,

and the link delay is 0.01 ms for all links. The link speeds of

WLAN, WiMax, and 3G are 54 Mbps, 75 Mbps, and 1 Mbps,

respectively. Interface queue size is 100 packets for wired

link, 400 packets and 5 seconds of lifetime for WLAN, 1024

TABLE ITRAFFICD ESCRIPTION

Flow Src. Dest. Proto. Rate Start Stop

UDP1 CN:56 MN:10 UDP 7 Mbps 2.0s 25.0s

UDP2 CN:57 MN:20 UDP 3 Mbps 2.0s 25.0s

UDP3 CN:58 MN:30 UDP 0.8 Mbps 12.0s 25.0s

UDP0.1 CN:59 MN:40 UDP 15 Mbps 2.0s 25.0s

UDP0.2 CN:60 MN:50 UDP 10 Mbps 14.0s 25.0s

TABLE IIINITIALF LOW B INDINGL IST INM N

Flow ID Priority Traffic Selector Binding IDs

3 15 (*, *, *, 30, UDP) 3G(-)WM(-)WL(-)

2 15 (*, *, *, 20, UDP) WM(-)3G(-)WL(-)

1 10 (*, *, *, *, UDP) WL(-)3G(-)WM(-)

packets including control packets for WiMax, and 100 packets

for PPP. In order not to change MNs default gateway after

receiving Router Advertisement, all MAGs MAC address on

edge network interface are unified to 00:00:AA:BB:CC:DD.

Therefore, the same link-local addresses for MAGs are shown

in the figure. The MN has virtual interface with Link-ID,00:00:11:22:33:44.

There are five UDP traffic flows from CNs to the MN as

shown in Table I. All traffics use HNP1 as destination address,

which is assigned to the first activated interface. To distinguish

each UDP, source port, and destination port are separated. In

order to check the flow handover operation, the start time of

UDPs is differentiated based on the scenario. The end time is

the same as the total simulation time. UDPs related to the flow

handover are UDP1, UDP2, and UDP3. UDP0.1 and UDP0.2

are used as background traffic.

Static Flow Binding list of the LMA and static Flow

Interface list of the MN are shown in Table II and Table

III, respectively. In static entries, Binding ID and Interface

ID contain only the priority among access technology types.

When an interface is activated or the PMIPv6 binding update

process is completed, the proper binding ID or interface index

is filled at the matched access technology type.

According to the lists, UDP2 is matched with Flow ID 2,

UDP3 is matched with Flow ID 3, and the other UDPs are

matched with Flow ID 1. Hence, the highest priority among

interfaces is WiMax for UDP2, 3G for UDP3, and WLAN for

the others.

Table IV shows the simulation scenario. This simulation

scenario is set up to check the validity of the proposed

procedure. Total simulation time is 25 seconds. It is dividedinto three phases. The first phase is for the flow mobility

procedure by new connection, the second phase is by LMAs

TABLE IIIINITIALF LOW I NTERFACELIST INL MA

Fl ow ID Priorit y Traffic Sel ector Interface IDs

3 15 (*, *, 30, *, UDP) 3G(-)WM(-)WL(-)

2 15 (*, *, 20, *, UDP) WM(-)3G(-)WL(-)

1 10 (*, *, *, *, UDP) WL(-)3G(-)WM(-)

534478


5/6

TABLE IVSIMULATION S CENARIO

Phase Time (s) Event

- 0.0 - Simulation starts

Phase1 0.0 - WLAN is activated(0.0s 10.0s) 2.0 - UDP1, UDP2, and UDP0.1 start to send

5.0 - WiMax is activated

Phase2 10.0 - 3G(PPP) is activated(10.0s 20.0s) 12.0 - UDP3 start s to send

14.0 - UDP0.2 starts to send15.0 - LMA moves UDP1 to WiMax

Phase320.0 - MN requests to move UDP3 to WLAN

(20.0S 25.0s)

- 25.0 - All UDP stop- Simulation stops

decision, and the third phase is by MNs request and LMAs

approval.

There are several detailed events for each phase and the

reactions for each event are easily expected. When UDP1,

UDP2, and UDP0.1 start to send at 2.0 seconds, these traffics

are delivered to the MN through MAG1 (WLAN) because

WLAN is the only activated interface at that time. Since UDP2has the highest priority for WiMax, when WiMax is activated

at 5.0 seconds, it performs flow handover from WLAN to

WiMax. It can be expected that WiMax gets the same HNP as

the WLAN because the LMA knows that UDP2 will perform

flow handover when new interface is activated. UDP1 and

UDP2 do not change anything when 3G is activated at 10.0

seconds. 3G interface gets new HNP which is different from

that of WLAN and WiMax because there is no influenced

flow for activating 3G interface. When UDP3 starts to send

at 12.0 seconds, it must use 3G interface which is the highest

priority for UDP3 and has been activated since 10.0 seconds.

At 14.0 seconds, UDP0.2 starts to send via WLAN. This traffic

causes the network congestion of WLAN and degradation ofsending rate of UDP1. Hence, by LMAs decision, the LMA

enforces flow handover of UDP1 to the WiMax by inserting

a new dynamic entry at 15.0 seconds. In similar way, the

MN requests a flow handover of UDP3 to the WLAN at 20.0

seconds with the assumption of running out of 3G data service.

Figure 7 depicts the throughput of the flows for three

phases in the MN. After WLAN is activated at the beginning

of the simulation, UDP1, UDP2, and UDP0.1 start to send

via WLAN at 2.0 seconds. Since the bandwidth of WLAN

is 54 Mbps, these traffic cannot serve with their full rate.

When WiMax is activated at 5.0 seconds, UDP2 performs flow

handover from WLAN to WiMax because WiMax has higher

priority for the UDP2. It can be noticed that the throughputof UDP2 increases with more than the serving rate just after

flow handover is performed. The interface queue of WLAN

is the main reason. When UDPs are using WLAN only, the

bandwidth of wireless link is smaller than the arriving rate.

Hence, the packets are queued in the interface queue. When

flow handover occurs, UDP2 packets in the interface queue are

still sending while UDP2 packets through WiMax arrived at

the MN. After this period, UDP2 serves with the full serving

rate. After UDP2 serves as its serving rate, the throughput of

UDP1 and UDP0.1 also increases.

In phase 2, as UDP3 starts at 12.0 seconds, there is a

throughput for the UDP3 in the MN. UDP1 and UDP0.1

which are served through WLAN show the degradation in

throughput from 14.0 seconds due to the start of UDP0.2. After

performing flow handover for UDP1 to the MAG2 based on

LMAs decision at 15.0 seconds, UDP1 is served as its full

rate as well as UDP2 is. The reason of the rapid increase of

throughput is that the MN receives UDP1 packets from both

WLAN and WiMax at the same time as explained situation in

phase 1. It ls also noted that there are oscillations in WiMax

interface because WiMax transfers series of packets at one

time and it has longer interval between transmissions.

In phase 3, it performs MNs flow handover request at 20.0

seconds, which is moving UDP3 from 3G interface to WLAN

interface. In WLAN interface, there are two background traffic

UDP1 and UDP2 while congested. As a result, the throughput

of UDP3 slightly decreases after flow handover is completed.

V. CONCLUSION

PMIPv6 is a network-based mobility support protocol and

it does not require MNs to be involved in the mobility support

signaling. Even though the virtual interface in the MN solved

the problems of vertical handover or flow mobility in hetero-

geneous network, definite procedure of flow mobility has not

been provided yet, and missing procedure of MN derived flow

handover makes flow mobility in PMIPv6 incomplete.

In this paper, enhanced flow mobility support with MN

virtual interface have been presented for actualizing and full-

covering of the flow mobility support in PMIPv6. Enhanced

flow mobility support is based on the virtual interface in the

MN. Virtual interface makes all physical interfaces to hide

from the network layer and above. Flow Interface Manager is

placed at the virtual interface and Flow Binding Manager inthe LMA is paired with it. They manage the flow bindings and

are used to select proper access technology to send the packet.

Flow mobility procedure is divided into three triggering cases,

which are caused by new connection from the MN, the

LMAs decision, and the MNs decision respectively. NS-3

simulation showed that the enhanced flow mobility support can

perform well for possible flow mobility scenarios including

MN derived mobility support.

ACKNOWLEDGEMENT

This work was supported by the IT R&D program of

MKE/KEIT [10035245: Study on Architecture of Future Inter-

net to Support Mobile Environments and Network Diversity].REFERENCES

[1] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil,Proxy Mobile IPv6, IETF RFC 5213, August 2008.

[2] D. B. Johnson and C. E. Perkins and J. Arkko, Mobility Support inIPv6, IETF RFC 3775, June 2004.

[3] G. Tsirtsis, Traffic Selectors for Flow Bindings, draft-ietf-mext-binary-ts-04, February 2010.

[4] M. Hui, G. Chen, and H. Deng, Service Flow Identifier in Proxy MobileIPv6, draft-hui-netext-service-flow-identifier-03, July 2010.

[5] F. Xia, and B. Sarikaya, Flow Binding in Proxy Mobile IPv6, draft-xia-netext-flow-binding-02, June 2010.

535479


6/6

Fig. 7. UDP Throughput Trace at the MN

[6] R. Koodli and K. Chowdhury, Flow Handover for Proxy Mobile IPv6,draft-koodli-netext-flow-handover-01, October 2009.

[7] H. Yokota, S. Gundavelli, T. Tran, Y. Hong and K. Leung, VirtualInterface Support for IP Hosts, draft-yokota-netlmm-pmipv6-mn-itho-support-03, March 2010.

[8] T. Melia, Ed., Logicla Interface Support for multi-mode IP Hosts,draft-melia-netext-logial-interface-support-01, July 2010.

[9] S. Krishnan, H. Yokota, T. Melia, and C. Bernardos, Issues withNetwork based Inter-Technology Handovers, draft-krishnan-netext-intertech-ps-02, July 2009.

[10] CJ. Bernardos, Ed., Proxy Mobile IPv6 Extensions to Support FlowMobility, draft-bernardos-netext-pmipv6-flowmob-02, Feburary 2011.

[11] T. Tran, Y. Hong, and Y. Han, Flow Mobility Support in PMIPv6,draft-trung-netext-flow-mobility-support-01, October 2010.

[12] NS-3 Network Simulator, http://www.nsnam.org[13] H. Choi, et. al, Implementation and Evaluation of Proxy Mobile IPv6

in NS-3 Network Simulator, In Proceedings of the IEEE InternationalConference on Ubiquitous Information Technology & Applications2010, December 2010.

536480

mofi paper 2011 pmip

Documents