Implementation and Evaluation of Proxy Mobile IPv6 in NS-3 Network Simulator Hyon-Young Choi∗ , Sung-Gi Min∗ , Youn-Hee Han† , Jungsoo Park‡ and Hyoungjun Kim‡
∗ Department
of Computer and Radio Communication Engineering, Korea University, Seoul, South Korea Email: {neongas, sgmin}@korea.ac.kr † School of Computer Science and Engineering, Korea University of Technology and Education, CheonAn, South Korea Email:
[email protected] ‡ Standard Research Center, Electronics and Telecommunications Research Institute (ETRI), Daejeon, South Korea Email: {pjs, khj}@etri.re.kr Abstract—With the rapid growth in the number of mobile subscribers and mobile devices, the demand high-speed Internet access is becoming a primary concern in our lives. Not long ago, the most stable and well known solution of IP-based mobility management is Mobile IPv6 (MIPv6). Even if MIPv6 is a wellknown mature standard for IPv6 mobility management support, however, it has revealed some problems such as handover latency, packet loss, and signaling overhead. Thus, a new IPv6 mobility management protocol called Proxy Mobile IPv6 (PMIPv6) is being actively standardized by the IETF NETLMM Working Group. Unlike the various host-based protocols such as MIPv6, a network-based approach such as PMIPv6 has salient features and is expected to expedite the real deployment of IP-based mobility management. In this paper, we present an implementation of PMIPv6 in NS-3 network simulator and the evaluation of the simulation for validating.
I. I NTRODUCTION 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. Mobility management enables the serving networks to locate an MN’s point-of-attachment for delivering data packets (i.e., location management), and to maintain an MN’s connection as it continues to change its point-of-attachment (i.e., handover management). Nowadays the most stable and well known solution for host-based mobility management is Mobile IPv6 (MIPv6) that has been standardized by Internet Engineering Task Force (IETF) [1]. However, even if MIPv6 is a well-known mature standard for IPv6 mobility support, it has nevertheless revealed some problems in terms of the various actuality aspects during the past years. These are followed as below: 1) The MIPv6 specification is too complex to implement it in MNs with limited resources; 2) A lot of signaling of MIPv6 adds overhead to wireless access links;
3) Signaling overhead of MIPv6 causes MNs to consume their battery power; 4) MIPv6’s handover latency is very long; 5) The modification to an MN’s IP stack is necessary, since MIPv6 is a host-based mobility protocol. IETF MIPSHOP Working Group published two mobility supports protocols, Hierarchical Mobile IPv6 (HMIPv6) [2], [3] and Fast Handovers for Mobile IPv6 (FMIPv6) [4], [5], addressing the optimization of the handover procedure related to MIPv6 mechanisms. But, such protocols also require the modification to an MN’s IP stack and do not reduce the waste of the wireless link resources. No requirement for modification of MNs is expected to accelerate the practical deployment of IP-based mobility management protocols. Such an expectation can be easily demonstrated by the fact that in the WLAN switching market, no modification of the software on MNs has been required to support IP mobility, so these unmodified MNs have enabled network service providers to offer services to as many customers as possible [6]. The network-based mobility management protocol called Proxy Mobile IPv6 (PMIPv6) [7] is being actively standardized by the IETF NETLMM Working Group, and is starting to attract much attention among the telecommunication community 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 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 mobility management support to an MN in a topologically localized 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 and performs 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.
978-1-4244-8811-7/10/$26.00 ©2010 IEEE
MN
MAG MN Attachment
AAA Server
LMA
CN
AAA Query with MN-ID AAA Reply with Profile PBU with MN-ID PBA with MN-ID, Home Network Prefix option
RA**
Tunnel Setup [Proxy-CoA:LMAA][MN-HoA:CN](data)
[MN-HoA:CN](data)
[MN-HoA:CN](data)
Fig. 2.
Fig. 1.
Message flow in PMIPv6
Overview of PMIPv6
In this paper, we present an implementation of PMIPv6 in NS-3 network simulator (NS-3) [8] and the evaluation of the simulation for validating. 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 models included in the distribution, NS-3 has a good development momentum and is believed to have a better core architecture, better suited to receive community contributions. In addition, it is reportedly [9] one of the better performing simulation tools available today. The rest of this paper is organized as follows. In Section 2 and Section 3, we provide the overview of the representative network-based approach (i.e., PMIPv6) for IP mobility support and the overview of the NS-3 network simulator, respectively. In Section 4, we explain the implementation of PMIPv6 in NS-3 in detail, and the description of the simulation and the results is presented in Section 5. Finally we conclude the paper with a summary of results in Section 6. II. PMIP V 6 OVERVIEW In PMIPv6, the serving network controls mobility management on behalf of the MN; thus, the MN is not required to participate in any mobility-related signaling. The primary features of PMIPv6’s goals are as follows: 1) Support for unmodified MNs: Unlike MIPv6, a networkbased approach should not require any software update for IP mobility support on MNs. 2) Support for IPv4 and IPv6: Although the initial design of a network-based approach uses an IPv6 host, it is intended to work with IPv4 or dual-stack hosts as well. 3) Efficient use of wireless resources: A network-based approach should avoid tunneling overhead over a wireless link; hence, it should minimize overhead within the radio access network. 4) Handover performance improvement: A network-based approach should minimize the time required for handover. Fig. 1 illustrates an overview of how PMIPv6 works within a localized domain. The brief descriptions of the basic terminology are also shown in the figure. The new principal functional entities of PMIPv6 are the mobile access gateway (MAG) and local mobility anchor
(LMA). The MAG typically runs on an access router (AR). The main role of the MAG is detecting the MN’s movements and initiating mobility-related signaling with the MN’s LMA on behalf of the MN. In addition, the MAG establishes a tunnel with the LMA for enabling the MN to use an address from its home network prefix and emulates the MN’s home network on the access network for each MN. On the other hand, the LMA is similar to the HA in MIPv6. However, it has additional capabilities required to support PMIPv6. The main role of the LMA is to maintain reachability to the MN’s address while it moves around within a PMIPv6 domain, and the LMA includes a binding cache entry for each currently registered MN. The binding cache entry maintained at the LMA is more extended than that of the HA in MIPv6 with some additional fields such as the MN-Identifier, the MN’s home network prefix, a flag indicating a proxy registration, and the interface identifier of the bidirectional tunnel between the LMA and MAG. Such information associates an MN with its serving MAG, and enables the relationship between the MAG and LMA to be maintained. Fig. 2 shows the message flow of the overall operations in PMIPv6. Each step shown in Fig. 2 is described as follows: 1) Step 1: An MN first attaches to an access network connected to the MAG. 2) Step 2: The access authentication procedure is performed using an MN’s identity (i.e., MN-Identifier) via the deployed access security protocols on the access network. 3) Step 3: After successful access authentication, the MAG obtains the MN’s profile, which contains MN-Identifier, LMA address, supported address configuration mode, and so on from the policy store. 4) Step 4: The MAG sends a proxy binding update (PBU) message including the MN-Identifier to the MN’s LMA on behalf of the MN. 5) Step 5: Once the LMA receives the PBU message, it allocates an appropriate home network prefix for the MN. 6) Step 6: The LMA sends a proxy binding acknowledgment (PBA) message including the MN’s home network prefix option, and sets up a route for the MN’s home network prefix over the tunnel to the MAG.
h pT u
ˈuˉ
o
uT
w]tV w]s
t j
z
ˈhˉ
|y
ˈpTˉ
ccee
i|sV ij
j
ccee
p]t k
Fig. 3.
ˈoˉ ccee
p]t ih
The main NS-3 modules
p]t i| p]t s[w
u
Unlike MIPv6, a tunnel in PMIPv6 is established between the LMA and the MAG, and not an MN. This could be desirable because the tunneling increases the bandwidth constraints on the wireless link and the processing burden on the MN. Once the MAG receives the PBA message from the LMA, it has obtained all the required information to emulate the MN’s home network on the access network, and it then starts to send a router advertisement (RA) message to the MN. After receiving the RA message, the MN configures its home address by combining the home network prefix included in the RA message and its interface identifier, which is based on the supported address configuration mode (e.g., stateless or stateful address configuration mode) from the policy store. It must be noted that since PMIPv6 only supports the perMN prefix model and not the shared-prefix model, a unique home network prefix is assigned to each MN. Therefore, the MN always obtains its unique home address while it moves within a PMIPv6 domain. After the bidirectional tunnel is successfully set up, all traffic sent from the MN gets routed to its LMA through the tunnel. The LMA receives any data packets sent by the correspondent node (CN) to the MN. The LMA forwards the received packet to the MAG through the tunnel. After receiving the packets, the MAG on the other end of the tunnel removes the outer header and forwards the packets to the MN. III. NS-3 N ETWORK S IMULATOR OVERVIEW NS-3 is organized with a set of modules, as shown in Fig. 3. The core module provides additional C++ syntactic sugar to make programming easier, such as smart pointers [10], rich dynamic type system, COM-like [11] interface query system, callback objects, and runtime described object attributes. Other modules in NS-3 include common, containing data types related to the manipulation of packets and headers, and the simulator module, containing time manipulation primitives and the event scheduler. The node module sits conceptually above the previous modules and provides many fundamental features in a network simulator, such as a Node class, an abstract base class for a link-layer interface (NetDevice), and several address types. The mobility module contains an abstract base class for mobility models. A MobilityModel object may be aggregated with a Node object to provide the node with the ability to know its own position. NS-3 also contains a module internet-stack implementing a UDP/TCP/IPv4/IPv6 stack, and few NetDevice implementations including WiFi, CSMA, and PointToPoint. Although there is no concrete concept of operating system or system call,
ccee
p]{s[w
toV so
ccee
p]sZw p]sy p]zy p]zzy
{uk ~uk
ccee
ˈuTˉ ~t
juk o
p]t o
ˈjˉ
p]t i|o p]t iho p]t vo
Fig. 4.
Major PMIPv6 classes in NS-3
application module provides a form of user-level application using Linux-like socket interface. Finally, a helper module is on the side of other modules. This module provides a set of very simple C++ classes that do not use pointers and wrap the existing lower level classes with a more programmer-friendly interface. IV. I MPLEMENTATION OF PMIP V 6 IN NS-3 N ETWORK S IMULATOR In implementing PMIPv6 in NS-3, we focused on the integration with newer version of NS-3 because NS-3 is at an early stage and the cycle of releasing new stable version is fast. To minimize the module dependency with the existing modules, we added new code as possible, even if the existing code is reusable. In addition, we defined the minimal part of MIPv6 such as mobility headers and these handler classes because current NS-3 release does not have MIPv6 implementation yet. We depicted the major PMIPv6 classes with the match of the module classification in NS-3 in Fig. 4. White boxes mean classes which are already providing in NS-3 and gray boxes are newly defined classes for PMIPv6 implementation. Rounded box refers the part of NS-3 modules. There are three boxes which have two class names together. These mean that upon the role of the model such as the MAG or the LMA, either of two class names has relations with other classes. For example, in case of the MAG, Pmipv6Mag, BindingUpdateList, and MagHelper have relations with others. PBU, PBA and many option headers inherited from Header class are defined in common module. Node class in node
w]t
o
OX`PGowihOP
RwOP Rnz¡z¡OP Rz¡OP Rk¡OP
p]t ih p]t k OX^P
p]t o T w Ts T{ T T
t vm Tk Tv Rz¡OP Rk¡OP RhvOP TjwOP
XGGGGQ
p]t vo T T RnhOP
OX]PGnt OP
uk ~GGG Gthn
p]t s[w
OXXPGzOP
w]s
OX\PGyOP
p]sZw
OXWPGowi|OP
p]t i|
OX[PGyOP
p]t vt Tupo
O`PGwOP
uaawo
p]t k O_P
OXZPGj
p]t iT |o T Th To Ts Tw T
p]t iT ho
T Tw T T
O]PGyOP
uk
p]sZw
OZPGzOP
p]t vT opo
p]t vh T{ { o
O\PGyOP
p]sZw OYPGzOP
w]t
uaawo ~GGG Gsth
O[PGj
uk
OXPGuj
~t
Fig. 6. Fig. 5.
p]t s[w O^PGnt OP
uk p]t voT uwo
OXYPGzOP
p]sZw
OX_PGwOP
Process of binding update
Class diagram of packet headers
module manages all applications and net-devices as lists. Various types of net-devices in net-device module can exist in a node. TunnelNetDevice is a virtual net-device for tunneling data packets between the LMA and the MAG. UnicastRadvd in application module is a variance of Radvd application, which sends RA message to the specific MN only. Classes in the internet-stack module such as Ipv6L3Protocol, Ipv6MobilityDemux, Pmipv6Mag, and Pmipv6Lma are aggregated to the Node class. Ipv6L3Protocol is the main network layer control class. It manages upper layer protocols and passes the packet to the right transport layer protocol matched with the next-header field in IPv6 header. Two transport layer protocols are defined in the figure, which are Ipv6MobilityL4Protocol and Ipv6TunnelL4Protocol. Ipv6MobilityL4Protocol handles mobility packets such as PBU and PBA packet, and Ipv6TunnelL4Protocol handles IPv6-in-IPv6 tunneling packets. Ipv6L3Protocol also contains routing manipulate classes. In NS-3, default routing protocol is Ipv6ListRouting, which can manage many routing protocols with priority basis. Ipv6StaticRouting class is used for basic routing query and Ipv6StaticSourceRouting is used for source address based routing query. Ipv6MobilityDemux class de-multiplexes mobility packets to the matched handler class such as Ipv6MobilityBindingUpdate and Ipv6MobilityBindingAck. Pmipv6Mag or Pmipv6Lma class is PMIPv6 agent installed in the MAG or the LMA, respectively. It handles binding process related messages. To provide simple and easy way of initializing and setting up the classes to users, we defined two helper classes in helper module which are MagHelper and LmaHelper. Using these classes, user can setup all objects within only one or two function calls. A. Packet Headers PMIPv6 utilizes mobility header of MIPv6 with additional P flag in header field and many newly defined options such as Home Network Prefix option, Handoff Indicator option,
Access Technology Type option, and so on. Class diagram of packet headers is shown in Fig. 5. All headers including option headers are derived from Header class. The most important methods of Header class is Serialize() and Deserialize(). Serialize() method makes realistic packet format from stored values in the class variables and Deserialize() method, in reverse, fills the variables in the class from the packetized data. Print() method is used for displaying the header information in text format for trace and GetSerializedSize() method should return the number of bytes of the header data in forms of realistic packet format. Ipv6MobilityHeader class is base class for Ipv6MobilityBindingUpdateHeader and Ipv6MobilityBindingAckHeader. As the same as mobility header definition, Mobility options also have the common base class of Ipv6MobilityOptionHeader and are derived from it. Mobility Headers inherit MobilityOptionField class as well. This class has a role of managing all options included in the mobility header and calculating the padding to make sure that the whole mobility header packet size is multiple of 8-octets. CalculatePad() method is used for padding mechanism with the help of GetAlignment() method in Ipv6MobilityOptionHeader whenever new option is added by AddOption() method. GetAlignment() function returns the information of padding rule [1]. B. Binding Update Processing Binding update process begins with the attachment event of an MN from link-layer and ends with the completing the local configuration such as tunneling and routing after receiving PBA message from the LMA as a response of PBU message. Fig. 6 shows the process of binding update. As Wifi module is used for wireless environment, WifiMac can notice the attachment of a MN and it notifies to the Pmipv6Mag. Pmivp6Mag initializes binding update list and sends PBU packet to the LMA. Sent IPv6 packets from upper protocols are handled by IPv6L3protocol. It passes the packet to the proper net-device
kGGGGGGOjuGGtuP
uk O^PGzOP
p]sZw
oGuGwGy ZaXa[aXaaV][G¥G ZaXa[aaaV][
OX[PGzOP
ZaYaaYV][ _WaaYWWaaWWaY
ZaXaaXV][ _WaaYWWaaWWaZ
OXZPGzOP
p]{s[w thnX
p]zzy
thnY ZaXaaYV][ _WaaYWWaaWWa[
OZP˅˅ ypOP O[P˅˅ pmOP
~GGG GukG GGG GsthGGthn
p]zy OZP˅ ypOP O[P˅ pmOP
p]zy p]sy
O\PGzOP
p]sZw OZPGypOP
OXYPGyOP
OXXPGskOP
p]sZw
O`PGyOP
uaawo
uaawo
uk
ZaXaaZV][ _WaaYWWaaWWa\ o|i
ZaXaYaaXV][ _WaaYWWaaa
hwX
hwY
OXWPGypOP
OYPGyOP
OXPGj
ZaXaXaaXV][ _WaaYWWaaa
OXWP˅ ypOP OXXP˅ skOP
p]sy O[PGpmOP
ZaYaaXV][ _WaaYWWaaWWaX
p]sZw
O]PGzOP
{uk
ju
sth
uk
O_PGj
uk
tGOYWVP
tu
ZaXa[aXaYWWaaWWaV][ _WaaYWWaaWWa
kGGGGGOjuGGtuP
Fig. 8. Fig. 7.
Simulation topology
Process of data packet between the LMA and the MAG
for the destination after routing query. Once an IPv6 packet is arrived the net-device of the other node, it is delivered to the Ipv6L3Protocol through ProtocolHandler in Node class. Then, Ipv6L3Protocol checks the IPv6 next-header field in the packet, and passes to the right transport handler. As a result, PBU packet arrived at the LMA is handled by Ipv6MobilityL4Protocol. Ipv6MobilityL4Protocol de-multiplexes the packet to the Ipv6MobiltiyBindingUpdate based on mobility header type in PBU packet. Because PBU packet is P flag on, Ipv6MobilityBindingUpdate passes the packet to the Pmipv6Lma. Pmipv6Lma handles PBU packet with creating/updating binding cache and setting up tunneling and routing. After processing PBU packet successfully, PBA packet is delivered to the Pmipv6Mag as the similar process as PBU packet delivery. Pmipv6Mag completes binding update list and finishing the setting of tunneling and routing. C. Data Processing After binding update process completed, bidirectional tunnel between the LMA and the MAG is established and proper routing entries are inserted both the LMA and the MAG. From this moment, the MN can exchange data with a CN. Fig. 7 shows how data packets are processed through the tunnel between the LMA and the MAG. When a data packet is arrived at the LMA or the MAG, it is passed to Ipv6L3Protocol. Ipv6L3Protocol performs routing query for incoming packet by calling RouteInput() method of Ipv6ListRouting. Ipv6ListRouting performs subsequent routing query to Ipv6StaticRouting. Ipv6StaticSourceRouting can be used for routing query if it exists. Because the packet is towards the CN or the MN, the result of routing query is forwarding the packet to the tunnel, that is, out-going net-device is TunnelNetDevice. In TunnelNetDevice, the packet is encapsulated with another IPv6 header towards the opposite node between LMA and MAG, and is sent. On the opposite node, tunneled data packet is arrived at the Ipv6TunnelL4Protocol as a result of LocalDeliver() in
routing query. Ipv6TunnelL4Protocol decapsulates the packet and passes it to Ipv6L3Protocol. Then the packet is finally delivered to the CN or the MN. V. S IMULATION AND R ESULTS We have performed the simple simulation for validating the basic operation of PMIPv6 implementation. NS-3 3.8 is used for the simulation with IEEE 802.11 network environment. The network topology for the simulation is shown in Fig. 8. The CN is directly attached to the LMA, and the LMA manages two MAGs. Wired link speed is 50 Mbps, and the link delay, except for the link between the CN and the LMA, is 2ms. The link delay between the CN and the LMA is 10ms. MN’s address is assigned automatically with stateless auto-configuration based on RA message from the MAG. In order not to change MN’s default gateway after receiving RA message, all MAGs’ MAC addresses on the edge network are unified to ”00:00:AA:BB:CC:DD”. Therefore, the same link-local address is assigned as shown in Fig. 8. The MN is moving from the MAG1 to the MAG2 with the speed, 20m/s, while communicating with the CN. CBR over UDP with 10ms inter-packet delay and 1 kbyte packet size is used for data traffic. Fig. 9 and Fig. 10 are parts of PCAP trace file – PCAP is a binary format for storing (usually live captured) packets, used by programs such as wireshark and tcpdump. To check that the handover procedure in PMIPv6 is performed correctly, we focused on the moment of handover. Fig. 9 shows the packet trace of handover in the MN. The MN tries to find APs by sending Probe Request at 5.393847s because it is disconnected from MAG1’s AP. Then, it performs association process with the first responder of Probe Request which is MAG2’s AP. The second responder, which is MAG1’s AP, is ignored. We can notice that handover procedure in the MAG2 is started after receiving Association Request from the MN. After exchanging PBU and PBA message between the MAG2 and the LMA, the MAG2 starts to send RA message to the MN if binding update is succeeded. At 5.410915s, there is first RA message.
390
380
Sequence
5.3849s
Fig. 9.
PCAP trace of handover in the MN
370
360
350 5.2
Fig. 11.
Fig. 10.
PCAP Trace of binding update process in the LMA
For the data traffic, the last data packet before handover occurred is at 5.384772s, which is the second line in the figure. During handover, there are two more data packets from the previous AP but they are ignored. And the first data packet from MAG2’s AP is at 5.423765s. Fig. 10 shows the packet trace of binding update process in the LMA. It might show MIPv6 message but we can check the P flag is on. From the figure, binding update is successfully processed between the MAG2 and the LMA. To figure out the handover latency and packet drops, we put additional sequence number in UDP data. Fig. 11 shows the received sequence number of packets in MN. The received time in the figure is at UDP application, not link-layer. We define handover latency as the time difference between the last packet in previous MAG and the first packet in new MAG. In Fig. 11, the last packet is at 5.3849s and the first packet is at 5.42389s. Therefore handover latency in this case is 38.99ms. And the lost packets are three in total. It should be noted that IEEE 802.11 MAC implementation in NS-3 3.8 cannot scan APs over other channel. As channel for AP1 and AP2 is the same, the handover latency is not included channel scanning time. VI. C ONCLUSION PMIPv6 could be considered as the next-generation standard protocol from the perspective of the practical deployment. Currently, 3GPP and WiMAX consider PMIPv6 as a promising alternative of MIPv6.
5.42389s
5.25
5.3
5.35
5.4 Time(s)
5.45
5.5
5.55
5.6
Packet sequence diagram during handover in the MN
In this paper, we have implemented PMIPv6 in NS-3 network simulator. NS-3 is a new simulator that is intended to eventually replace the aging NS-2 simulator. NS-3 has good development momentum and better features comparing to other simulations including NS-2. Especially PCAP trace file based on realistic packets is remarkable. We performed simulation in IEEE 802.11 wireless network environment for testing the PMIPv6 operation and its performance. The simulation result showed this implementation works well and the handover latency is very short. ACKNOWLEDGEMENTS This research was supported by the ICT Standardization program of MKE(The Ministry of Knowledge Economy) (2010-P1-09, Development of Multi-Network Technology Standards using IPv6-based Multihoming) R EFERENCES [1] D. B. Johnson and C. E. Perkins and J. Arkko, Mobility Support in IPv6, IETF RFC 3775, June 2004. [2] C. Castelluccia, HMIPv6: A Hierarchical Mobile IPv6 Proposal, ACM Mobile Computing and Communications Review, Vol. 4, No. 1, pp. 4859, January 2000. [3] H. Soliman and C. Castelluccia and K.-E. Malki and L. Bellier, Hierarchical Mobile IPv6 Mobility Management (HMIPv6), IETF RFC 4140, August 2005. [4] L. Dimopoulou and G. Leoleis and I.O. Venieris, Fast Handover Support in a WLAN Environment: Challenges and Perspectives, IEEE Network, Vol. 19, No. 3, pp. 14-20, May-June 2005. [5] Rajeev Koodli, ed., Fast Handovers for Mobile IPv6, IETF RFC 4068, July 2005. [6] J. Kempf, and ed., Goals for Network-Based Localized Mobility Management (NETLMM), IETF RFC 4831, April 2007. [7] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil, Proxy Mobile IPv6, IETF RFC 5213, August 2008. [8] NS-3 network simulator hompage, http://www.nsnam.org. [9] E. Weing¨artner, H. vom Lehn, and K. Wehrle. A Performance Comparison of Recent Network Simulators, In Proceedings of the IEEE International Conference on Communications 2009 (ICC 2009), June 2009. [10] D. Edelson, Smart Pointers: They’re smart, but they’re not pointers, University of California, Santa Cruz, Computer Research Laboratory, 1992. [11] D. Box, Essential COM, Addison-Wesley, 1998.
