IP in UPMT Networking - Compare and Contrast

Size: px
Start display at page:

Download "IP in UPMT Networking - Compare and Contrast"

Transcription

1 The UPMT solution (Universal Per-application Mobility Management using Tunnels) Technical Report - Version 1.1, June 2011 S. Salsano (1), M. Bonola (1) (1) University of Rome Tor Vergata Available at: Contact: stefano.salsano@uniroma2.it DISCLAIMER This work has been partly funded by the EU in the context of IST PERIMETER project ( but it does not necessarily represent the official position of the project itself and of its partners. Authors are solely responsible for the views, results and conclusions contained in this work. COPYRIGHT "Copyright and all rights therein are retained by authors. This work may not be modified or reposted without the explicit permission of the copyright holder"

2 Contents 1. What is UPMT? Related work and problem statement Always Best Connected Mobility Management requirements for ABC scenarios Related Works Mobile IPv4 and Mobile IPv Proxy Mobile IPv4 and Proxy Mobile IPv IKEv2 Mobility and Multi-homing protocol SIP Mobility Support Host Identity Protocol Flow mobility in MIPv4, MIPv6 and HIP Per-application mobility Mobility Management in 3GPP LTE Discussion and comparison between UPMT, related works and our ABC requirements Specific comparison of UPMT against MIPv Discussion on HIP with respects to our ABC requirements UPMT per-application mobility vs. flow mobility UPMT vs. 3GPP LTE mobility management UPMT Basic Solution Networking architecture Detailed Tunnelling/NAT Operations Considerations about IP in UDP tunneling and virtual interfaces UPMT functional architecture Procedures and information flows Mapping of the Information Flows into SIP UPMT Scalability Extensions The VIpA Assignment Issue Per-Application Forwarding Table extension Procedures for Multi AN communication in UPMT-DAM Procedures for MH to FH communication in UPMT-DAM Dynamic MH-to-FH Static MH-to-FH MH to MH communications SIP architecture for MH to MH communications...34

3 5. S-UPMT S-UPMT procedures UPMT Signaling Protection UPMT Association Phase UPMT Association Phase 2 TLS protection mode UPMT Association Phase 2 IPsec protection mode Tunnel Server Redirection procedure S-UPMT signaling overview Data protection MH-to-AN tunnel operation details End to End tunnel operation details UPMT header compression IP Fragmentation support Security Considerations Impersonation of UPMT nodes Confidentiality, authentication and integrity of application data Protection of tunnel headers and vulnerabilities of implicit procedures UPMT Implementation The Big Picture User Space VS Kernel space tunneling UPMT Mobility/Multi-homing implementation UPMT Tunneling module a. Operations on packets from MH to CH b. Operations on packets from CH to MH c. Differences between MH and AN implementations d. Tunneling module configuration with Generic NETLINK UPMT Control Entity networking aspects UPMT application management UPMT connection tracker and application flow classification Per-application policies UPMT Graphical User Interface S-UPMT implementation S-UPMT Tunneling and IPsec integration S-UPMT signaling and IPsec configuration Summary Outgoing packets Incoming packets UPMT Android Porting Android at a glance Android Porting details...73

4 7. UPMT Performance evaluation System Level Performance Analysis User Level Performance Analysis Tunneling overhead analysis Detailed design of the first User Space solution Interface between UPMT Control Entity and UPMT Execution Entity in the Mobile Terminal Interface between UPMT Control Entity and UPMT Execution Entity in the Anchor Server (MMS) Interface between UPMT Control Entity and External Entity SIP Interface between MMC and MMS Example Flow (User Space solution) Implementation details for the support of legacy applications (in the User Space solution) Mobile Management Client s UEE Implementation Mobile Management Server s UEE Implementation...96 Acknowledgements...97 References...98

5 1. What is UPMT? UPMT is a mobility and multi-homing solution based on "IP in UDP" tunneling that provides per-application flow management, i.e. traffic flows of different applications can be independently routed on different access networks. UPMT provides transparent support of legacy applications, so that they can use UPMT without being modified or linked to updated versions of standard libraries. UPMT does not require any support from the access networks and is fully compatible with existing network infrastructures, in particular with all legacy NATs. UPMT is a mobility mulit-homing solution well suited for Always Best Connected scenarios, whose basic idea relies on the automatic selection "at any time" of the "best" interface for sending and receiving data. UPMT has been implemented for the "mainstream" Linux and then ported on the Android OS and the source code is available under the GPL open source license. For demonstration purposes, a UPMT Linux Live distribution is provided and both UPMT mobile and anchor nodes can be set up in a few steps. The home page for downloading source code, installing UPMT and retrieving more information about UPMT (including two.ppt presentation) is: 5

6 2. Related work and problem statement 2.1 Always Best Connected The concept of Always Best Connected has been thoroughly discussed in a 2003 paper [1] ever since it has entered the common nomenclature. ABC services can be described as follows: For a person to be always best connected means that he or she is not only always connected, but also connected through the best available device and access technology at all times. The definition of best depends on a number of different aspects such as personal preferences, size and capabilities of the device, application requirements, security, operator or corporate policies, available network resources, and network coverage. Depending on the applications and user preferences, a user can be connected over one access at a time or over multiple accesses in parallel. The ABC concept includes virtually all types of access technologies; fixed and wireless, and existing technologies as well as those that are yet to come.. Two aspects of the description reported above are worth being remarked. The statement always connected through the best available access technology at all times leads to following considerations: (1) ABC services require a mobility management solution that allows the ABC terminal to move seamlessly between different access network technologies, while maintaining connections to application servers. (2) no assumptions other then basic IPv4 connectivity about the possible access networks can be made, as well as no support from the access network can be required. Even though modifications to the access routers, or in general to the devices present in the access network, could improve the seamless mobility management, the case of no control over such devices has to meet; (4) no limitation regarding the applications and the correspondent hosts can be posed. In other words, the mobility management should support all types of application and should provide mechanisms to communicate with legacy correspondent hosts not implementing the mobility management mechanisms. Another important aspect is related to the statement depending on the applications and user preferences, a user can be connected over one access at a time or over multiple accesses in parallel. Since application and user preferences vary from application to application, a per-application independent multi-homing and mobility management is 6

7 required. In other words, a ABC terminal should be able to manage different application flows independently, and take different handover decision for each application. Moreover, regarding the mobility support provided by the ABC service, the following additional requirement has been considered: [ ] Certain types of services, commonly known as push services, require a means to locate a user at his or her current network location. Such a solution for reachability or presence can be included in the ABC service offered to the user [ ]. 2.2 Mobility Management requirements for ABC scenarios With regards to the considerations discussed in the previous section, we have identified a set of functional requirements for a mobility management solution to support ABC services in our vision. These requirements are summarized and listed hereafter: 1. The Mobility Management solution should not require additional support in the access networks. The access networks are only required to provide IP connectivity. The capability to offer Mobility Management services should not be an exclusive prerogative of the network operators. On the other hand, it should be possible for network operators to provide added value and enhanced services, by exploiting their network and servers assets. 2. The Mobility Management solution should be able to separately deal with different applications and decide different handovers for each one based on a set of criteria like for example: cost; QoS/QoE parameters like throughput, loss, delay/jitter; security (N.B. A discussion of the criteria is out of scope of this work) 3. The Mobility Management solution should be compatible with NAT traversal. Users should be able to roam from an access network to another, even when one or both access networks use private IP addressing and are behind a NAT. Terminals that are not connected behind a NAT or that are in the same access network should be able to communicate directly, wherever possible 4. Legacy application must be supported on the mobile host side, i.e. we should not require applications to be rewritten/recompiled to run on the mobile hosts and exploit mobility features. On the other hand it should be easy to deploy new applications or enhance existing applications to fully exploit the capability offered by the Mobility Management solution 5. The Mobility Management solution should support all types of applications. Both TCP and UDP based application needs to be supported, as well as all existing application level protocols. 6. The Mobility Management solution should not require any modifications to the Correspondent Hosts, nor to the applications running in the CHs. All existing terminals should be able to interoperate with roaming MHs. On the other hand, if the Correspondent Host / Correspondent application is aware of the Mobility Management solution, this should be exploited to provide a more efficient solution 7. The Mobility Management solution should be able to scale by distributing any server side capability into a set of nodes, taking into account load sharing issues as well as optimization of forwarding paths. 7

8 8. In order to preserve the privacy of the users, it should be possible to hide the actual location and the movements of the user to the CH, while maintaining reachability even in access networks behind NAT. 9. When switching from an access network to another one, the Mobility Management signaling should be sent over the new target network, since the old one could suddenly become unavailable; in such a case it is necessary to perform the whole handover procedure on the new network (this is known as Forward handover or break before make ). On the contrary, if the old network is still available, the availability of both networks can be exploited in order to assist and speed up the whole procedure ( make before break ). When two or more networks are available at the same time, they can be used in parallel ( multi-homing ). 10. The vertical handover must be as fast as possible. This means that the user should not perceive any service interruption. If it is not possible to completely hide the effect of the handover, then the service disruption should be minimized. 11. The Mobility Management solution should provide security services (message and entity authentication, data confidentiality, etc..) without necessarily depending on a particular existing security protocol. 2.3 Related Works This section presents some mobility management approaches among the large number of proposals that can be found in the literature and in the standards and try to relate them with the list of requirements reported in Section Mobile IPv4 and Mobile IPv6 Mobile IPv4 (MIPv4) [3] and Mobile IPv6 (MIPv6) [4] deal with IP mobility management issue from a network layer point of view. When a Mobile Host moves from the home network to a foreign network, a new IP address (Care of Address - CoA) is obtained. The Home Agent (HA) is informed of this movement and updates the binding between the MH Home Address (HoA) and the new CoA. Packets addressed to MH s HoA are intercepted by HA and tunneled (IPv4 in IPv4 or IPv6 in IPv6) in IP packets addressed to MH s CoA. Furthermore, both MIPv4 and MIPv6 specification define a route optimization mechanism that provides packets direct routing between MH and CH through the optimized path. As for additional security mechanisms, [6] describes the details of use of IPsec Security Associations (SA) for protection of MIPv6 signaling traffic between the MH and the HA. As for the tunnel data protection, the common approach is to secure IPv6 tunnels with IPsec tunnels. This approach can be applied also to MIPv4. MIPv4 is the first mobility management solution and presents different limitations, partially, due to implicit limitations of IPv4. Without listing all the issues, we want to consider the fact that MIPv4 requires support in the Foreign Network. This is a major limitation and makes MIPv4 not suitable for ABC scenarios under the requirement that existing access network should be supported: MIPv4 would require support in all possible access network visited by the MH. In addition, flow binding procedures for MIPv4 [5] are still under standardization process, so MIPv4 is not yet compatible with a per-application mobility management. MIPv6 benefits from both the previous work on MIPv4 and from some features offered by IPv6 itself, so it provides many improvements compared to MIPv4. MIPv6 shares many 8

9 features with UPMT and fulfils many requirements (e.g. multiple CoAs, flow binding update [7]). Anyway, IPv6 connectivity cannot be given as granted for most Internet Service Providers. Since MIPv6 mobility solutions for ABC are limited by the access and transport network infrastructure, MIPv6 is not suitable for ABC scenarios in our vision. As for MIPv6 security weaknesses, the use of IPsec fully protects the signaling traffic between MH and HA. Nevertheless, the simple substitution of IPv6 tunnels with IPsec tunnel suggested in the base MIPv6 specification leads to handover performances limitation due to the establishment of a new SA. As for the mobility of IPsec SA, please see Section Proxy Mobile IPv4 and Proxy Mobile IPv6 Without going into much details about the differences between the two versions, Proxy Mobile IP v4 v6 [12][10] is a localized mobility managements solution that changes the basic MIP v4 v6 approach by moving the mobility management from the terminal to the access routers. Mobile Nodes (MNs) in a PMIP domain never perceive the movement from two PMIP enabled access routers (called Mobility Access Gateway - MAG), as they are reassigned the same address for the entire session. The MAG notifies every MN movements to a topologically higher entity called Local Mobility Anchor (LMA) which is responsible for maintaining the mobile node s reachability. In the PMIP solution, the MNs are totally unaware of the mobility management procedures which are in fact performed by the MAG and the LMA. PMIP is a new and widely exploited IP mobility management solution (for example in 3G mobile networks) and provides different interesting features, among which support for multiple interfaces and support for flow mobility [7]. Nevertheless, its network centric paradigm (common to both v4 and v6 version) makes its use in our vision of ABC scenarios impossible. Indeed, PMIP architecture requires all access routers to implement PMIP functionalities, and this of course cannot be considered for granted. Moreover, PMIPv6 suffers from the same limitation related to the necessity of IPv6 connectivity as in MIPv IKEv2 Mobility and Multi-homing protocol A different approach based on dynamic update of IPsec SAs is provided by the IKEv2 Mobility and Multi-homing (MOBIKE) protocol [8]. MOBIKE is an extension to the Internet Key Exchange Protocol version 2 [9] (IKEv2) and provides a protocol to dynamically update the IP addresses associated to an already established IPsec SA. Therefore, MOBIKE gives an secure and end-to-end solution to the multi-homing and mobility issue by extending IKEv2 to efficiently manage IPsec in a scenario in which the host has multiple IP addresses or changes the IP address over time. MOBIKE solves the need of IPsec SA rekeying due to IP address reconfiguration, but it still suffers from some major limitations and does not provide a full solution to mobility and multi-homing. In fact, MOBIKE does not provide rendezvous mechanisms and thus, simultaneous movement and full NAT traversal are not supported. Moreover, since only one pair of SAs can be used simultaneously, load balancing and make before break handovers are not supported as well. 9

10 2.3.4 SIP Mobility Support According to the SIP protocol, an INVITE message is sent by a terminal to its correspondent to setup a communication session. The traditional SIP mechanism to provide terminal mobility during an active session [22] involves not only the mobile host (MH) but also the correspondent host (CH), which is the other party engaged in the call. It foresees that the MT sends another INVITE message to the CT to communicate the information about the new parameters of the communication session after the handover. Although this solution solves the problems of Mobile IP, it has some drawbacks too. The second INVITE (commonly referred to as Re- INVITE ) is sent end-to-end, and this could lead to high delays. Moreover, the handover procedure relies on the capability of the CT to handle this procedure. Different SIP-based approaches have been proposed to manage mobility, addressing the shortcomings of the end-to-end Re-INVITE mechanism. For example, in [23] it is assumed that the MT connects to the Internet through different ANs and that each of them has its own so-called Base Station. The Base Stations are able to handle the vertical mobility and perform a handover, by moving a communication from a base station to the other. Actually, the handover procedure is split in two phases. First the MT contacts the old Base Station and asks to receive/send packets over the new AN, using an INVITE message, which makes use of the JOIN SIP header [24]. For a certain time, media packets will be duplicated and sent over both wireless networks. As soon as the packets reach the MT through the newly activated interface, a re-invite message is sent by the MT to the CT through the new Base Station. Then, the media will flow through the new Base Station and over the new Access Network; a SIP BYE message will be sent to close the session with the old Base Station and a REGISTER message will be sent to the user home Registrar server to update the user contact information. This solution improves the performance of traditional SIP mechanisms in terms of handover duration and packet loss, but it still requires the involvement of the CT. Also, it requires a complex sequence of SIP transactions (INVITE, Re-INVITE, BYE and REGISTER) for each handover and it does not address NAT traversal issues. Anyway, regardless of the particular SIP based mobility management solution, such mechanisms are applicable only in case of SIP applications, and thus can not surely be used in ABC services Host Identity Protocol A totally different paradigm with respect to traditional mobility management solution is provided by the Host Identity Protocol (HIP) [13]. HIP deals with the mobility and multihoming problem with a radical architectural enhancement. It solves one known limitation of the Internet architecture by decoupling the double role of both topological locator and network interfaces identifier of the IP addresses. HIP introduces a new layer between transport and network layers so that application socket are no longer bound to IP addresses, but to Host Identities, which are not affected by any underlying addressing change. Compared to other solutions, HIP seems to be more suited for ABC services. HIP is totally end-to-end but also defines mechanisms for rendezvous services and host discovery. HIP works with NAT and with all existing network infrastructure. In addition, HIP security associations are not looked up by inspecting IP addresses, and thus, handovers without IPsec SA re-keying are supported. As for the support of flow mobility, the first version of an Internet Draft [17] has been recently proposed. 10

11 2.3.6 Flow mobility in MIPv4, MIPv6 and HIP MIPv4, MIPv6 and HIP solutions were originally conceived to provide host mobility or per-device mobility. Quite recently they have started considering the need to separately handle each single application flow ( per-flow mobility). In particular, as already mentioned in sections and 2.3.5, MIPv6 has been extended with RFC 6089 [7] (became RFC in January 2011, work started in 2007), while Internet drafts are currently under discussion for MIPv4 ([12]) and HIP ([13]) Per-application mobility The need to transport different applications on different access technologies at the same time, and take separate handover decisions for each application has been identified and addressed in [14], [15]. In [14] a per-application mobility management platform was first proposed. The solution is based on address translations on the two endpoints, and it requires that both endpoints are mobility-aware. The interoperability with NATs is not discussed and the solution is evaluated by simulation, no real implementation is reported. In [15], a per-application mobility management based on HIP (Host Identity Protocol) [10] has been proposed. This solution has only been simulated using a network simulator, and no real implementation has been developed Mobility Management in 3GPP LTE The 3GPP has been considering the issue of seamless mobility in its work on the System Architecture Evolution (SAE) [18]. The SAE is the core network architecture of 3GPP Long Term Evolution (LTE) [19]. Good introductions to SAE can be found in the white papers [20][21]. The Evolved Packet Core (EPC) is the main component of the SAE. It is realized through four new elements: Serving Gateway (SG-W), Packet Data Network (PDN) Gateway (PGW), Mobility Management Entity (MME), Policy and Charging Rules Function (PCRF), as shown in Figure 1. MME UE IP channel enodeb SGW PCRF e-utran PDN GW EPC - Evolved Packed Core Figure 1 Evolved Packet Core (EPC) main components The node involved in performing the handovers between LTE and other non-3gpp technologies is the PDN-GW. The PDN GW provides connectivity to the UE to external packet data networks and it acts as the anchor for mobility between 3GPP and non-3gpp networks. The interfaces of PDN-GW towards different types of non-3gpp networks are shown in Figure 2 and are named S2a, S2b and S2c. Citing from [21]: For handover between LTE and other non-3gpp technologies, PMIPv6 (Proxy Mobile IPv6) and client MIPv4 FA mode will be used over the S2a interface while PMIPv6 will be employed over 11

12 the S2b interface. DS-MIPv6 (Dual Stack MIPv6) is the preferred protocol over S2c interface. e-utran EPC Evolved Packet Core S2a PDN GW INTERNET Trustednon 3GPP IP access UE S2b Trusted/Untrusted 3GPP/non 3GPP IP access S2c epdg Untrustednon 3GPP IP access epdg: Evolved Packet Data Gateway Figure 2 PDN-GW interfaces towards non 3GPP networks 2.4 Discussion and comparison between UPMT, related works and our ABC requirements Rather than trying to patch existing solutions in order to fulfill the identified set of requirements, a new mobility management/multi-homing solution has been designed and implemented. In comparison with the above analyzed solutions, UPMT can provide ABC services fulfilling all the requirements listed in section 2.2. Some specific features of UPMT, which can differentiate UPMT from the other solutions are listed hereafter: 1. UPMT provides per-application independent mobility management and multihoming. 2. UPMT does not require support in the access and transport networks and is fully and natively compatible with all existing NATs. 3. From the networking point of view, UPMT consists of standard and well supported building blocks that makes its implementation easy and can be implemented without requiring modification to the OS Kernel (a preliminary implementation of UPMT has been realized in user space for Linux OS). Note that in order to support legacy applications in a completely transparent way and in order to achieve optimal performances, the full-fledged Linux and Android UPMT implementation does modify the Kernel. 4. UPMT combines the benefits of centralized and distributed mobility management solutions. UPMT supports scenarios with a single AN and with multiple ANs used in parallel to support communication with legacy CHs. UPMT is also compatible with procedures to realize end-to-end mobility in case of communications with UPMT aware CHs (the definition and implementation of such end-to-end scenario is still ongoing). 5. Since UPMT makes use of a virtual interface, support for legacy application is complete. Moreover, there is no possible conflict between virtual IP addresses ( VIpAs ) and real IP addresses. In fact, UPMT forwarding and standard IP 12

13 forwarding are independent and they are performed after the IP packet is filtered on a per-application base, e.g. using policy routing features. 6. UPMT uses SIP as signaling message transport. UPMT benefits from this choice because of several standard SIP services that can be reused for UPMT. In particular, MH reachability can be provided through SIP Registration and message forwarding with SIP proxies. 7. UPMT is independent from the particular method for protecting both signaling and data traffic. Even though we will propose a security extension based on IPsec, UPMT is independent from it, and possible solutions based on other security mechanisms (e.g. the Datagram Transport Layer Security protocol - DTLS) can be envisioned. 8. The proposed overlay approach fully decouples the real mobile interfaces and the fixed virtual interface. UPMT stack is totally unaware of what happens in the underlying layers and therefore UPMT does not suffer from some limitations affecting other solutions. For example: (i) UPMT does not depend on any Layer 2 (L2) protocol; (ii) there is no need to intercept and forward ARP o ICMPv6 messages; (iii) the Anchor Node location is not topologically restricted within the home network; (iv) IPsec SAs are bound to virtual IP addresses ( VIpAs ) and never change Specific comparison of UPMT against MIPv4 UPMT operates at application level, while MIPv4 at network layer. Some differences worth mentioning are: 1. UPMT is natively NAT friendly without need for new protocol numbers, port registration, NAT extension. This is a direct consequence of the use of IP/UDP encapsulation. Anyway, it has to be noted that IP/UDP encapsulation introduces additional 8 bytes (the length of UDP header) of overhead with respect to MIPv4 (see Section 7.3 for a discussion on overhead of UPMT). 2. UPMT does not require a Foreign Agent (FA), while MIPv4 needs a FA in NATed networks to perform de-tunneling and to share the same (in many cases) unique public IP address among several Mobile Hosts (MHs). Since UPMT uses UDP encapsulation, as long as the tunneled traffic is initiated by the MH, and as long as the MH periodically refreshes the binding at the NAT/router, the MH is always reachable by the AN and it is indeed the other tunnel endpoint 3. The overlay approach fully decouples the "virtual layer" and the "physical layer", and thus UPMT is really "L2 agnostic". MIPv4 requires interaction with ARP, and for example, a MIPv4 Home Agent (HA) might need to proxy ARP messages on behalf of the MH and a MH has to disable ARP broadcasting within a Foreign Network. 4. UPMT and MIPv4 both suffer from triangular routing. Even though, in theory, MIPv4 suffers from triangular routing only in communications from CH to MH, reverse tunneling is often used to avoid Ingress Filtering, and triangular routing affects also packets from MH to CH. This problem is clearly unavoidable when a MH is communicating with a legacy CH, since a packet relay is placed in the path between the MH and the CH. Anyway, the tunneling approach of UPMT is ready to support an end-to-end approach where tunnels can be established between two mobile hosts, using the Anchor Nodes only as rendezvous/nat traversal. 13

14 5. The MIPv4 HA location is topologically restricted within the MH s home network. In the standard configuration MIPv4 does not allow for multiple HAs, and indeed, the HA represents the only bottleneck since it necessarily has to forward all packets between a MH and its Correspondent Hosts (CHs). UPMT is compatible with a multi AN scenario, i.e. multiple ANs can be used in parallel, and no cooperation between the ANs is needed. This feature results in a better scalability of UPMT against MIPv Discussion on HIP with respects to our ABC requirements We have identified the following shortcomings of HIP with respect to our requirements. Even though a sort of HIP proxy can be introduced in communications between a MH and a totally unaware CH, a solution to support legacy CHs equivalent to UPMT CAM and DAM has not been defined so far. Another limitation is the tight relation between HIP and IPsec. The current HIP architecture relies on IPsec and other transport mechanisms besides ESP are not specified. In order to solve a mobility and multi-homing issue, HIP requires IPsec, which may slowdown a possible large scale deployment. Indeed, not only IPsec base specifications are not fully implemented in all existing operating system, but HIP also requires support for a novel tunnel mode. In facts, HIP makes use of the Bound End to End Tunnel (BEET) which is still under standardization process. Furthermore, even on open sources OSs like Linux or FreeBSD, HIP implementation seems to be still unstable and incomplete. Moreover, when MHs are behind NATs, the standard traversal solution is UDP encapsulation, that is exactly the UPMT proposed tunneling approach. Another aspect to be taken into account is the transparent support of legacy applications. Some of the possible solutions described in [16] are: virtual interfaces for server applications, local identifiers (in the form of IP addresses) statically bound to DNS names, modified DNS names, interception of DNS request, dynamically linkage of modified socket libraries. Anyway, some of the proposed solutions require ad-hoc countermeasures and can make legacy application support not trivial. Moreover, to fully benefit from HIP mobility and multi-homing solution, the HIP socket API has to be used UPMT per-application mobility vs. flow mobility UPMT provides per-application mobility, i.e. applications flows are handled separately and handover can be performed independently. The capability to separately handle each flow, referred to as flow binding or flow mobility, has been recently considered by MIPv6, MIPv4 and HIP mobility management solutions, as described in Section 2.3. We want to note that capability to perform flow binding / flow mobility is needed to realize to realize per-application mobility, but it may be not sufficient to offer perapplication mobility under the requirements that we have considered for ABC services (i.e. considering the requirement to support legacy applications). In facts, applications flows need to be classified and associated to some kind of local policies that binds the transmitting process to the outgoing interface. As thoroughly described in Section 6.3, the management of application flows is not a trivial problem in case of mobility unaware applications and it involves aspects related to the operating system and to the networking stack implementation. 14

15 2.4.4 UPMT vs. 3GPP LTE mobility management The mobility management solution envisaged in 3GPP LTE is based on MIPv6, so it depends on the deployment of MIPv6 in the LTE network but also in other non-lte networks which can be used to handover. The role of the LTE/SAE PDN-GW is similar to the role of the AN in the UPMT proposal. The UPMT AN does not depend on MIPv6, so it can be considered as a short-medium term alternative for mobility management. UPMT operates as an overlay on top of plain IP networks. An operator willing to offer a pre-lte mobility solution can do it with UPMT using existing networks. 15

16 3. UPMT Basic Solution 3.1 Networking architecture The proposed architecture is depicted in Figure 3. The MH is equipped with two (or more) interfaces connected through different access networks. Each interface has an IP address which may be either public or private. The MH will establish one tunnel to the AN for each interface that it may want to use for sending and receiving data. The data to any Correspondent Host (CH) is encapsulated and sent to the AN on one of the tunnels, likewise the data coming from any CH is sent by the AN on one of the tunnels. In the solution discussed in this document, the encapsulation performed at the MH and the AN is UDP/IP encapsulation (see section for details). Anchor Node (AN) Anchor NAT Correspondent Host (CH) IP/UDP Tunnel 1 NAT 1 NAT 2 IP/UDP Tunnel 2 Mobile Host (MH) Figure 3 High level network architecture The internal architecture of the MH is depicted in Figure 4. The Forwarding Agent will handle all the packets sent by the applications running on top of the Mobility Management 16

17 Client (MMC). The interface between applications and the TFA can be either a virtual IP interface in case of legacy applications or the UPMT socket API in case of UPMT aware. The TFA forwards the data packets on the proper tunnel according to the Per-Application Forwarding Table (PAFT). This forwarding is based on the source and destination IP addresses and TCP/UDP ports. In practice the PAFT maps an application flow into a tunnel (app-flow -> TID) with app-flow = (proto, IP.src, IP.dst, L4.sport, L4.dport), where proto is the transport protocol (UDP or TCP), IP.src and IP.dst are the IP source and destination addresses and L4.sport and L4.dport are the transport source and destination ports. Inside the tunnels, the MH uses a Virtual IP Address that is assigned to it by the Anchor Node and is never affected by any IP readdressing of the underlying real network interfaces. In other words, since the IP stack of the real NICs used to transmit/receive packets is hidden to the local applications, an arbitrary number of NICs can be used in parallel (multihoming) and can seamlessly roam from different access networks (mobility) without affecting any active application sessions. The building of the PAFT is a critical aspect: it is easy for UPMT aware applications that will explicitly open the sockets through the UPMT socket API, while we need to introduce a socket identification and classification mechanism for legacy applications. This is realized by a module in kernel space that associates packets to the process IDs of the applications. The Tunnel Manager performs all the operations to establish, update, refresh and destroy the UDP tunnels between each active interface of the MH and the AN. Figure 4 Networking architecture of Mobile Host and Anchor Node In the proposed architecture the AN (see Figure 4), has a threefold role: the AN acts as a tunnel broker for the MH. During the association procedure, a VIPA is assigned to the MH. This VIPA identifies the MH at the AN regardless of the particular tunnel through which the traffic is received. Each tunnel is univocally identified by the AN by the tunnel ID couple defined as TID = (IP source address, UDP source port). We call it source address and source port because they are the address and port of the incoming UDP packets (i.e. received by the AN) that opens the tunnel. The AN will send back packets on this tunnel with IP destination 17

18 address = received IP source address and UDP destination port = received source UDP port, in order to exploit the symmetric NAT traversal approach. Note that when the tunnel crosses a NAT, the IP source address and UDP source port of the packet received by the AN will be the NATed ones. In order to keep the pin-hole open in the NAT, a keep-alive mechanism handled by the client will be used, similar to the one defined in RFC 3948 [32]. the AN acts as the anchor point for the MH. All the tunnelled packets from MH to CH are decapsulated and forwarded by the AN. The associations between application data flows and the tunnel from which they are received are kept at the AN in the per-application Forwarding Table (PAFT). The PAFT is used by the AN to route packets coming from CH and destined to MH and its structure in the Mobile Management Server (MMS) is identical to the MMC, as it maps application flows into TIDs. the AN performs standard NAT operations on all packets tunnelled by the MH. In particular, after the packet is decapsulated, the virtual address assigned to the MH, which is the IP source address of the packets sent by the MH, is replaced with a public addresses of the Anchor NAT Detailed Tunnelling/NAT Operations In this section we provide a detailed example of tunneling and NAT operations taking into account the scenario depicted in Figure 5. The MH is equipped with two interfaces IF0 and IF1 connected to two different access networks. Figure 5 Example scenario with IP addressing Both interfaces have private IP addresses, respectively if0 = and if1 = Both interfaces are connected through a default gateway/nat with public IP addresses, respectively gw0 = gw1 = The AN has public IP address and the CH is a legacy UDP server with IP address ch and listening port The Virtual IP Address assigned by the AN to the MH in the association procedure is vipa0 = The MH has setup two tunnels (referred to as t0 and t1) respectively on the interfaces if0 and if1. The tunnels IDs are tid0 and tid1. The source ports respectively for tid0 and tid1: for the MN 1500 and 1600; for the AN and The destination port for both tunnels is

19 Figure 6 shows a generic exchange of two UDP packets between MH and CH. Assume that a legacy application running on the MH sends a UDP packet PCK1 with source port 2000 and destination port 3000, IP source address vipa0 and IP destination address ch , through the virtual interface vif0. This packet is handled by the local Tunnel Forwarding Agent and, according to the local PAFT is forwarded to the AN on tunnel t0. The outer IP/UDP header is formed according to the parameters of tunnel t0. Figure 6 Basic operations for data exchange The AN, upon receipt of PCK1, updates the PAFT by inserting the following forwarding rule: ,ch0, 2000; 3000 (UDP), tid0 PCK1 is then processed by the NAT module as follows: (i) the virtual IP source address is replaced with the public address an ; (ii) the UDP source port 2000 is replaced with port chosen by the NAT; (iii) the mapping is stored in the NAT table. Note that all operations performed by the NAT are standard symmetric address and port translations, and no NAT extensions are required. PCK1 is then forwarded to CH In response to PCK1, CH sends a UDP packet PCK2 with destination IP address an0 and destination UDP port Upon receipt of PCK2, the AN restores the NAT mapping by replacing: (i) IP destination address an0 with the virtual address ; (ii) UDP destination port with PCK2 is finally intercepted by the AN Tunnel Forwarding Agent, encapsulated and forwarded back to MH through the proper tunnel t0 according to the specific PAFT entry Considerations about IP in UDP tunneling and virtual interfaces Figure 7 shows the IP in UDP tunneling approach on which UPMT is based. We named the external header as Tunnel header and the encapsulated header (i.e.: the IP header of the application packets sent by the Mobile Host) as Original header. In a MH-AN-CH communication, the Tunnel header it is formed as follows: 19

20 the source IP address is the address of the MH physical interface from which the tunnel is initiated. Most likely, this address is changed by the NAT placed in the access network. the destination IP address is the public address of the anchor node. the UDP source port is a random port associated to the specific tunnel with the AN. Most likely, this port is changed by the NAT placed in the access network. The UDP destination port is the UPMT AN listening port, i.e.: the UDP port on which the AN is listening for tunneled packets. Figure 7 IP in UDP encapsulation The Original header is not modified by the UPMT stack and has the Virtual IP address as source IP address, and the CH IP address as destination IP address. As briefly stated in the previous sections, the mobility service is provided by the tunneling mechanism itself. Indeed, since the Tunnel header can change arbitrarily, the application sessions are never affected by IP readdressing of the physical NICs, as long as one active tunnel can be used within the application or transport timeout (e.g.: TCP timeout). In the same way, since multiple tunnel can be used in parallel for different applications, or even for different flows belonging to the same application, multi-homing is provided. How mobility and multi-homing is provided is clear, but how can applications be forced to use the Virtual IP address assigned by the AN without modifying them? The idea is to use a virtual interface and force applications to use this interface by modifying the local IP routing configuration (all the details will be given in Section 6). The Virtual interface acts as an abstraction layer that hides all the real physical interfaces so that any possible IP reconfiguration and connectivity loss is hidden to the applications sockets a. Why IP in UDP tunneling? The choice of using IP in UDP encapsulation can be motivated by the following considerations: 1. It provides native protocol independent NAT traversal without requiring new protocol number, port reservation and new protocol design. 2. It provides tunnel multiplexing from the same source address 1 with less overhead with respect to other solutions. In particular, let us consider Generic Routing Encapsulation protocol. This tunneling mechanism would requires the KEY option to multiplex different tunnels from the same source address. The resulting overhead for IP+GRE would be bytes against the bytes of UDP. 3. It can be easily implemented, even in user space with standard UDP sockets. 1 This is what happens when a NAT is between MHs and a AN. 20

21 4. It is the standard NAT traversal mechanism for IPsec, which can be used to protect tunneled traffic (see S-UPMT, section 5). Moreover, UPMT introduces less overhead then HIP in most of the cases. Indeed, if we consider the most likely scenario of MHs behind NATs, HIP would require the standard ESP NAT traversal mechanisms, which is IP/UDP encapsulation. Again, the resulting overhead would be greater than UPMT. For further details see Section UPMT functional architecture Figure 8 provides a simplified representation of the proposed UPMT functional architecture in a mobile host. A Decision engine module takes decisions considering a set of inputs. The first input to the Decision engine comes from the Classification of flows and applications module. The Interfaces/networks manager module continuously informs the Decision engine on what interfaces are available. Optionally, Quality of Service/Quality of Experience measurements module can gather measurements and report them to the decision engine. Finally, the decision is taken considering a set of Policies. A Graphical User Interface may allow the user to set the policies and to check the status of the system. The output of the Decision engine is used to drive the Mobility Management mechanisms (i.e. the UPMT networking solution partially described in this section) to route the packets on the chosen interface and to perform per-application independent handovers. Graphical User Interface Policies Classification of flows and applications Decision engine Mobility management mechanisms Interfaces/networks manager QoS/QoE measurements Figure 8: ABC modules in the Mobile Host Let us now discuss the issue of how to identify the flows related to a given application, so that it is possible to route them over a specific network interface according to the ABC policies. The first important design choice is if we want to consider applications that are aware of the ABC services offered by the Operating System or if we want to consider legacy applications that are not aware of this advanced network service and will behave as if they are talking over a single network interface. In the former case (ABC aware applications) the applications may take specific actions to drive the interface selection process or at least they can react to input from the mobility management modules in order for example to send a flow using different source and/or destination addresses/ports. In the latter case (legacy application) the application will manage its flows using the traditional IP sockets and cannot tolerate any change in the perceived addresses/ports. 21

22 While the identification of IP flows generated by ABC aware application could be trivial, the case of legacy application needs to be discussed. A given application flow can be univocally identified by the IP parameters of the incoming/outgoing packets (protocol, IP src, IP dst, Layer 4 source port, Layer 4 destination port) received/sent by the related application socket. In general, an application will use several flows, each one identified as above. The critical aspect for the support of legacy application is that we cannot classify a posteriori a flow as belonging to a given application, but we need to route the flow over a chosen interface since the very first packet of the flow. A non-optimal solution is to use destination IP addresses and/or ports to perform this classification. The disadvantage is that the destination IP address and/or ports need to be known in advance. This is only suited to the support of rather static scenarios where the end-points of the communications are fixed, and can be seen as a primitive form of per-application mobility management. On the other hand we want to identify the packets as belonging to a given application without any constraint on the destination IP addresses/ports. In order to support our vision, the classification module needs to provide: (i) efficient association of each IP packet with the process that transmitted it; (ii) asynchronous notifications of every newly created TCP or UDP flow in order to take proper decision before forwarding the packet. The second feature is already provided by the Linux kernel (conntrack module), while in order to achieve the first feature we added a process identifier to the kernel data structure that contains a packet (details will be shown in Section 6). The Interfaces/networks manager module monitors which interfaces are active and retrieves their IP configuration parameters (e.g. the default gateway of each interface). It follows interface state getting asynchronous notifications of interface disconnections or IP re-addressing. It provides input to the Decision engine module, which applies the decision policies as described in section b..The implementation of the Interfaces/networks manager module is dependent on the mobile host Operating System. In our Linux based implementation we started from existing tools (see section b. ). The QoS/QoE measurement module provides per-application independent active and passive monitoring of the QoS and QoE parameters. It has a special role in a user centric decision making process, since it allows to take into account the perceived quality of each active application. This will lead to more complex policies (i.e. from availability-based policies to measurement-based policies, see section 6.3.2). Currently, this module has not yet been integrated in our UPMT platform. The Decision engine module works on the base of Decision policies (see section b. ). It allows the mobile host to take mobility management decision. This is a device-centric / user centric approach as opposed to network centric / operator centric approaches, where the mobility management decision are taken by the network / by the operator. Nevertheless, this not precludes using UPMT in operator centric business scenarios for ABC services. 3.3 Procedures and information flows In this section, we first identify and describe at a logical level the four procedures and the associated information flows between the Mobile Host and the Anchor Node. An example sequence diagram is reported in Figure 9, while Table 1 shows the set of messages and their parameters. In section 3.4 we present the proposed mapping into protocols which has been realized in our test-bed. Association procedure - In order to associate with the MMS, the MMC sends an Association request message. The purpose of this message is initially to receive a virtual 22

23 IP address (VIPA) in the Association response message from the MMS. The association is a soft state and it has to be refreshed with periodic Association request messages. The refresh Association request messages include the already assigned VIPA. The Association request messages can be subject to authentication by the MMS, in this case the procedure could change from a two-way handshaking to a four-way handshaking as the MMS may need to send some challenge to the MMC. Figure 9 A sample temporal diagram showing a set of information flows Tunnel establishment - As for the tunnel establishment, we considered two solutions. It is possible to have an opportunistic approach where tunnels are simply created by sending the first packet on the tunnel. The second option is to use some form of explicit signaling at the establishment of the tunnel, with a Tunnel Setup request message. Explicit signaling can be used to support some form of authentication (e.g. to accept tunnels only from authorized MMC) Using explicit signaling it is possible to agree on an identifier for the tunnel, shared between the MMC and the MMS. This type of explicit signaling could be realized in several different ways: i) piggyback information on the data packets, for example by reserving a signaling field at the beginning of the UDP payload, just before the tunnelled IP packet; ii) have a similar signaling field to distinguish between tunnel packets carrying a tunnelled IP packet and signaling packets; iii) just to use a tunnelled IP packed with destination IP corresponding to the MMS and destination UDP port directed to a process in the MMS that handles this signaling. Handover Request - A Handover request message is used to switch a set of flows from one interface to another. The handover request message includes a list of flows and for each flow the target tunnel ID on which the flows needs to be handed off. If the request message is transmitted over a tunnel the target tunnel ID can be omitted for a flow and it 23

24 means that the flow will be switched on the tunnel on which the Handover request message is received. This is the only option if there is no signaling to propagate the tunnel ID back to the MMC during the tunnel setup. A handover request message can be sent while the previous tunnel of the handed over flows is still active, thus supporting the so called make before break handover and minimizing the impairments. The Handover request can also be sent as a result of a sudden break of the connection supporting the previous tunnel. In this case, if the new tunnel is not yet active, the setup of the new tunnel and the handover request should ideally be performed at the same time in order to minimize the impairments. Data transfer - The DATA messages correspond to the tunnel packets that carry the tunnelled IP packet (which can be TCP or UDP or even a different protocol if the MMC NAT is able to handle them). The tunnelled IP packet extracted from the DATA message automatically triggers the association of the corresponding flow in the PAFT (flow/tunnel association table). This process resembles the learning process of a NAT box. If needed, DATA messages could be authenticated and/or encrypted using various techniques. Association request (VIPA) Note that VIPA is missing in the initial association Association response (VIPA) This message is sent using the same UDP socket of the tunnel Tunnel setup request () Tunnel setup response (tunnel ID) This message is sent using the same UDP socket of the tunnel Handover request ({[flow ID, tunnel ID]}) This message is sent on the same UDP socket of the tunnel. Therefore the tunnel ID can be omitted and (if omitted) implicitly derived from the received UDP port number/ip address. Note that a set of couples [flow ID, tunnel ID] can be transported in one single handover request message Table 1 Messages and their Parameters Keep alive - Periodic Keep Alive messages are needed for each setup tunnel, in order to keep the NAT pin-holes open. As a rough estimate, the Keep Alive period can be in the order of tens of second. As we have a number of tunnels equivalent to the number of interfaces, this will not be a concern. The solutions to support the keep alive procedure can be borrowed from the ones discussed above for the Tunnel Establishment. Actually using a combined solution for keep alive and tunnels establishment could result in higher efficiency (or at list in a simpler architecture). 3.4 Mapping of the Information Flows into SIP In this section we provide the proposed mapping of the information flows discussed in section 3.2 into SIP protocol messages. In principle, different protocols can be used to support the UPMT procedures, we used the SIP protocol because its features match very well the UPMT need as for its facility of extension and implementation. All UPMT messages are mapped into the SIP MESSAGE method. This method is used to exchange arbitrary information between two SIP entities, without setting up a session and is able to deal with retransmissions due to packet losses. In order to support UPMT we added a new header to carry the Virtual IP Address, called VIpAddr. The addition of this new header is not a problem, as the SIP messages with the new header needs will only be exchanged between our MMC and our MMS. The VIpAddr 24

25 header is carried in the MESSAGE transporting the Association Request; this MESSAGE is sent outside the tunnels. Note that all the SIP response messages (the 200 OK messages in the figure) will follow the same path than the corresponding request messages. Therefore the 200 OK response message to the MESSAGE carrying the Association Request will be delivered outside the tunnels. All other 200 OK messages are carried back within the same tunnel of the corresponding request message. Figure 10 Protocol messages In the case of Tunnel Setup and Handover Request, we preferred not to define new SIP headers. Rather, the needed information is transported within the body of the MESSAGE, as plain text using JSON. Both the Tunnel Establishment and the Handover Request MESSAGEs are sent inside the tunnels (as the corresponding 200 OK messages). The two procedures can be combined into a single one when it is needed to open a new tunnel and handover a set of the flows on it (e.g. after the sudden failure of an active interface). Figure 10 reports the same scenario considered in Figure 9 with the protocol messages names. The (partial) content of the SIP messages is shown in Figure

26 M1: Association Request MMC to MMS REGISTER sip: SIP/2.0 Via: SIP/2.0/UDP ; branch=z9h; TID=Terminal_ID; rport; To: <Terminal_ID> From: <Terminal_ID>;tag=dba Contact: <sip:terminal_id> M2: Association Response 200 OK MMS to MMC SIP/ OK Via: SIP/2.0/UDP ; TID=Terminal_ID;received= To:< Terminal_ID > From:< Terminal_ID>; tag=dba VIpAddr: M3: Tunnel Setup Request MMC to MMS MESSAGE sip: SIP/2.0 Via: SIP/2.0/UDP ; branch=z9h; TID=Terminal_ID; rport; To: <sip: > From: <Terminal_ID>;tag=dba Contact: <sip:terminal_id> Content-Length: xx Content-Type: application/text { mtype : TunnelSetupReq, tunneltype : IPinUDP } M4: Tunnel Setup Response MMS to MMC MESSAGE sip: SIP/2.0 Via: SIP/2.0/UDP ; branch=z9h; TID=Terminal_ID; rport; To: <sip: > From: <Terminal_ID>;tag=dba Contact: <sip:terminal_id> Content-Length: xx Content-Type: application/text { mtype : TunnelSetupRes, result : 200 OK, tunneltype : IPinUDP, nettunnelid : } M5: Handover Request MMC to MMS MESSAGE sip: SIP/2.0 Via: SIP/2.0/UDP ; branch=z9h; TID=Terminal_ID; rport; To: <sip: > From: <Terminal_ID>;tag=dba Contact: <sip:terminal_id> Content-Length: xx Content-Type: application/text { mtype : HandoverRequest, "match":{"syntax":"iptables", "match":"-p tcp destination destinaton-port 80"}, "tunnelid":[ ,"any"] } Figure 11 SIP messages examples 26

27 4. UPMT Scalability Extensions In the previous section we proposed UPMT, a mobility management solution that provides are the per-application handover and the full compatibility with legacy applications, legacy hosts and existing networking infrastructure. A critical issue of the existing proposal is the scalability, as the specification foresee a single Anchor Node (AN) handling the mobility management signalling procedure and acting as tunnel server for decapsulation and packet relaying to/from MH/CH. In this section we propose to enhance the basic UPMT solution by defining the UPMT-Distributed AN Mode (DAM). UPMT-DAM should: 1) provide the means for a MH to use different Access Nodes as needed to distribute load and to optimize performance (e.g. by choosing where possible an AN in the path between the Mobile Host and the Correspondent Host); 2) allow a fixed Correspondent Host to play the role of Anchor Node; 3) allow direct communication between Mobile Host bypassing Anchor Nodes whenever possible (the AN would be used as rendezvous point for signalling and to assist in the setup of end-to-end data tunnels). In other words, the idea is that AN used as packet relay should be used only if strictly necessary, i.e. (i) in communications with legacy Correspondent Hosts, (ii) in communications between UPMT aware MHs where at least one MH is behind a bad NAT. As shown in Figure 12 (left), a Mobile Host can be connected using several different access networks, most of which will provide private IP addresses and uses NATs to interwork with the Internet. In the basic UPMT solution (Centralized Ancor Node Mode - CAM), the MH connects to an Anchor Node using IP in UDP tunnels, one per each access network. The MH uses a Virtual IP Address VIpA that is assigned to it by the Anchor Node. The Anchor Node provides a second level NAT to the Mobile Host, allowing the host to access to the Internet using a public IP address provided by the Anchor Node. The forwarding and tunnelling of packets in the Mobile Host and in the Anchor Node is regulated by a table called Per Application Forwarding Table (PAFT), which is able to associate a socket to the tunnel used to send packets from the MH to the AN and vice versa. The UPMT-DAM approach proposed in this paper considers three scenarios for the distribution the functionality that was centralized in the basic UPMT solution: 1) Multi-ANs scenario (multian) in which MHs can use different ANs in parallel for communication with legacy CHs; 2) MH-to-FH end-to-end scenario (mh2fh) in which UPMT aware mobile hosts (MH) and fixed hosts (FH) communicate directly with each others without necessarily relying on ANs for packet forwarding; 3) MH-to-MH end-to-end scenario (mh2mh) in which 27

28 MHs communicate directly with each others without necessarily relying on ANs for packet forwarding and use different ANs. The multian and the mh2fh scenarios are depicted in Figure 12 (right), which shows three tunnels setup between the MH and the AN with solid lines. The MH could switch the tunnels to a second Anchor Node or directly to a Fixed Correspondent Host (tunnels drawn with dashed lines). Mh2mh scenario is depicted in the bottom of Figure 12. Anchor Node (AN) 2 Anchor Node (AN) Anchor Node (AN) Anchor NAT CH1 CH2 Anchor NAT AN3 Local NAT AN2 AN1 Public Internet Local NAT CH NAT CH NAT CH3 CH4 AN3 Local NAT AN2 (public IPs) AN1 Public Internet Local NAT Fixed Host 1 Mobile Host (MH) CH5 Mobile Host (MH) UPMT-CAM UPMT-DAM: multian & mh2fh Anchor Node (AN) L STUN server L SIP Proxy L SIP Proxy R STUN server R Local NAT-L AN-NAT Access Net L Public Internet Local NAT-R Mobile Host (MH-L) UPMT-DAM mh2mh Figure 12: UPMT Scenarios Mobile Host (MH-R) 4.1 The VIpA Assignment Issue In the UMPT-CAM solution all traffic for a given Mobile Host is relayed by a single Anchor Node. The Anchor Node assigns the MH a VIpA during the Association Request phase. For the AN, every MH in the UPMT overlay network is univocally identified by a VIpA and thus every inner IP packet carries all the information required to be correctly forwarded without inspecting the external IP/UDP header (the tunnelling approach is shown in Figure 13). Figure 13: IP in UDP tunneling In UMPT-DAM, we introduce a set of Anchor Nodes and allow direct communication between MH and UPTM aware Fixed Hosts and among MHs. If we want to keep the hypothesis of a bi-univocal association between a MH and a VIpA, we need to assign it in a coordinated way among the tunnel servers (multi AN, FHs or MHs). The VIpA 28

29 assignment procedures need to be coordinated and a DHCP-like protocol is required. Moreover, since VIpAs are merely IPv4 addresses, the UPMT architecture will eventually face the same addresses exhaustion limitation of IPv4. Therefore we propose to use a new approach, in which the VIpA is uniquely associated to a MH in each tunnel server that assigns it ( Per-Association Unique VIpA ). Therefore different tunnel servers may assign the same VIpA to different MHs and the MH will in general receive different VIpA by the different tunnel servers (either an AN, a FH or another MH) to which it will connect. If MH is associated with N UPMT peers, the MH will be identified by N VIpAs, each of which will be unique only at the Tunnel Server that has provided it. Since having N virtual interfaces on the MH would make the whole system not scalable and hard to transparently integrate legacy applications, the virtual interface will be configured with a fixed and locally unique IP address (VIpA_fix). Then we will have a NAT operation, internal to the mobile host, will be performed on IP.src for outgoing and incoming packets. For outgoing packets this NAT operation will change the IP.src with the VIpA, depending on the remote tunnel end-point to which the MH is communicating and on the given application flow. To realize this internal NAT of the VipA_fix address, a UPMT Tunnel Table (TT) is used to store all the bindings between each active tunnel and the VipA that has to be used as source IP address (for outgoing packets from that tunnel). The Tunnel Table can be either a different table or integrated in the PAFT. 4.2 Per-Application Forwarding Table extension The PAFT structure described in Section 3 is strictly limited to a scenario in which only one tunnel end point (or tunnel server ) is available for the mobile host. We now want to support an end-to-end scenario with different tunnel end points, therefore the PAFT need to consider all possible remote peers for each application flow. The extended PAFT (Table 2) consists in two fields: app_flow is the concatenation of the following fields: protocol, ip src, ip dest, src port, dest port; local_tid is a locally unique numeric identifiers for the tunnel bound to app_flow. The PAFT is therefore linked through the key local_tid to a Tunnel Table (TT) which consists of the following 4 fields: - local_tun : the couple (out_iface, local_tun_idx), it identifies the interface, the IP source address and the index for tunnel bound to app_flow. The format of local_tun_idx depends on the specific tunnel mechanism. For example: (i) in case of IP/UDP tunnels local_tun_idx would be the UDP source port of the external UDP header; (ii) in case of IP/GRE tunnels local_tun_idx would be a GRE key field. - remote_tun the couple (tun_end_point, remote_tun_idx). The first field is trivially the destination IP address of the tunnel. The second field is the remote tunnel index (again, UDP remote port or any other tunnel index depending on the tunnelling mechanism). - vip_nat is the local VIpA assigned to the peer MN is communicating to through the tunnel identified by local_tid. - un_tid is a numeric identifier that univocally identifies a tunnel between two endpoints. This field is used only with tunnels explicitly set up and allows signalling messages to be sent outside tunnels. Let us consider an example of communication between a MH and an AN when the perassociation unique VIpA assignment is performed. We assume a MH and two ANs as 29

30 shown in Figure 12. The VIpA_fix address is assigned to the virtual interface of the MH at bootstrap (or when UMPT is started). The MH performs the UPMT association and tunnel setup request procedures with AN1 (UDP tunnel remote port p1). Upon completion the MH receives a virtual address VipA from AN1 and sets up a tunnel identified by tid1. Later on MH associates to AN2 (UDP tunnel remote port p2), gets a virtual address VipA and sets up a second tunnel identified by tid2. app_flow local_ti d app_flow1 Tid1 tid1 eth0,200 0 app_flow2 Tid2 tid2 eth0,300 0 local_tid local_tun remote_tun vip_na t Table 2 Extended PAFT AN1,p AN2,p un_tid As for the first application flow, the packets (with IP.src= ) are NATed so that IP.src is change to and sent to AN1. Packets related to the second flow are instead NATed so that IP.src= and sent to AN2. After this local NAT, packets are forwarded through the proper tunnels, respectively tid1 and tid2. When the encapsulated packets are received from the AN, upon de-tunnelling the inner packets received with the VIpA addresses as destination are NATed back so that IP.dst= Since a MN is identified by a VIpA by each tunnel server it is associated with, we can continue to exploit two important features that have been proposed in UMPT-CAM. First we have the implicit handovers, which means that an application can drive the handover by simply sending packet on a new target tunnel. The PAFT in the anchor node will use auto-learning and there is no need of explicit tunnel setup). Likewise, in the Anchor Node the standard NAT procedure called MASQUERADING is feasible based on the VIpA. 4.3 Procedures for Multi AN communication in UPMT-DAM Multi AN scenario does not require new procedures other than the ones described for the centralized single AN mode. A MH configured with multiple ANs will simply associate with each AN at start up, obtain a unique VIPA from each AN and set up a tunnel for each active interface. The MH will therefore have multiple tunnels for each active interface, and the decision regarding which tunnel to use for each application will be delegated to the MH policy decision engine. The tunneling/de-tunneling procedures for the Multi AN scenario are described in section Procedures for MH to FH communication in UPMT-DAM In this section we define two possible communication modes between ad MH and a FH. In the dynamic MH-to-FH mode (Section 4.4.1) the MH is not aware of the presence of a UPMT FH. At initial time, the tunnelled data traffic is forwarded by the AN as is case of legacy CHs. This mode makes use of the so called UPMT tunnel redirection procedure which allows the MH to dynamically discover the presence of a UPMT FH, to perform association and handoff the data traffic to a new end-to-end tunnel with the FH. In the static MH-to-FH mode (Section 4.4.2), the MH is statically configured with a set of IP addresses of UPMT FHs and association is performed at start up. Data traffic sent to 30

31 these FHs is distinguished from the traffic to others CHs and tunnelled directly toward the FHs Dynamic MH-to-FH Let us consider the case of a mobile client browsing a fixed web server. The web server can provide whatever content, from html pages to streaming of media. As shown in Figure 12 (right) there is the possibility to establish direct connections (dashed lines in the figure) between the MH and the fixed host, without using the Anchor Node as a relay. This is granted if the Fixed Host has a public IP address (like the Fixed Host 1 in Figure 12). If the fixed host is behind a NAT (like the Fixed Host 2) it depends on the type of the NAT and of the service that is offered to the Fixed Host), we consider a public IP address or a static IP/port mapping, as typical for web servers that needs to be accessed from the Internet. The basic idea is that the Anchor Node is not used for permanent relay of the data, but it becomes a support node that will help in the establishment of the connections and in the NAT traversal and will play a relay role only when needed. The two UPMT ends of the communication will try to exchange data in a peer to peer fashion. This is exactly the same approach used by ICE procedures, in which the communicating entities try to establish a direct communication across NATs with the help of servers (STUN, TURN) and falls back to a relayed communication when this is not possible. Moreover the Anchor Node will also be used as a rendezvous-point in some special cases, for example when both ends of the communication will move into a new access network at the same time (of course in the case of a MH to MH communication). We will now describe the procedure that allows to establish a connection with a UPMT server running a legacy application, for example a web server. The legacy web server in the fixed host will be listening on the port 80 of its public IP address. The UPMT module in the fixed host listens on an UDP port on its public IP address, offering a UPMT tunnel server. If the UPMT module in the Mobile Host would know the Tunnel Server Address (IP address and UDP port) of the Fixed Host (FH-TSA) associated with the legacy web server address (IP and TCP port), it could open a tunnel toward the Fixed Host and start sending packets within the tunnel. The chosen solution is shown in Figure 14. Let us consider an application flow between the MH and the FH, originated by the MH. The packets of this flow are first sent towards the Anchor Node in a tunnel; then the AN de-capsulate them, operates the NAT and forwards then to the UPMT FH. The FH receives the first packet coming from an IP address of the Anchor node (and from a port in a given range) and understands that it is coming from an AN acting as UPMT NAT on behalf of a MH. The packets of this application flow are handled by the UPMT module in a special way, as it has the potential to become a flow managed through the UPMT tunnels. Note that we rely on the assumption that the FH has to know the addresses and range of ports of the set of ANs it wants to support. FH will communicate to the AN (if not already done) the binding between the TSA and the application flow 2. This binding indication is a soft state in the AN and has an expiration that can be set by the UPMT FH and changed by the AN in the answer. 2 FH may also use a fixed TSA for every application (FH is a fixed host) so we just consider FH sending the fixed TSA to the AN. Anyway, the application flow is still needed by AN to retrieve the NATBI. 31

32 Figure 14 Flow redirection procedure The AN will browse into the NAT binding table and will understand which is the flow coming from the MH. The AN will send to the MH a Tunnel Server (TS) Redirect containing the TSA, together with an indication of the NAT association (NAT Binding Indication NATBI) between the source IP and port (app_src_port) at the ingress of the second level NAT in the AN and the source IP and port (IP_nat, PORT_nat) at the egress of the AN NAT. If the MH accepts the TSA Redirect, it will send a message to the AN to reserve the outgoing port (TS Redirect Accept). In this case the AN shall not reuse the same outgoing Source Port until explicitly allowed by the MH with a release port message (TS Redir Release), or after a timeout in the communication with the MH. Note that for each socket that it is opened from MH to FH a different message TSA Redirect will be sent and a different TS Redir Accept is sent. At the closure of the socket the MH will send a TS Redir Release message (and a single message can release a set of ports if more than one socket were open before switching to direct communication with the FH). The MH can decide to communicate directly with FH for the specified application flow. If so, MH will send an Association Request in which it will include the NATBI along with a unique SIP identifier. In the Association Response, the FH will provide the Per-Association Unique VIpA (VIpAu) to be used for the new association. As soon as the Association Response is sent, FH will store in a NAT table (FH_NAT) the binding between: (VIpAu, app_src_port) (IP_nat, PORT_nat) Upon receipt of the Association Response MH can update the local PAFT and send packets towards the FH over a new tunnel, using as source address the received VIPA address and as source port the one that it had already communicated in the Association Request message. It is important to note that once the Association is established, since the VIpAu univocally identifies the MH, implicit tunnel setup and implicit handover are still feasible as in the UPMT-CAM solution. As soon as the MH receives the Association Response containing the VIpA, it is ready to perform a handover for the application flow indicated in the NATBI. The handover is 32

33 performed by simply updating the PAFT. In particular, MH will change the remote_tun field of the PAFT with the TSA (IP address, UDP port) received in the TS Redirect. Upon receipt of tunnelled data packets the FH will: (1) update the local PAFT; (2) Remove the external header; (3) perform a source NAT, replacing the source IP and port with the source IP and port that the AN was using for this flow, as specified in the FH_NAT. In this way, the legacy application will not perceive any change. For response packets, FH performs the following operations: (1) FH_NAT is looked-up and destination IP address and port are restored; (2) PAFT is looked-up and packets are forwarded within the proper tunnel. In addition, once the association is established, the MH ca setup additional tunnels and handle the handovers among them, as it were using an Anchor Node Static MH-to-FH The static MH-to-FH mode assume that the MH knows in advance the addresses of a set of FHs with which it might communicate. This assumption is actually reasonable, because in a possible UPMT deployment scenario, a FH could be a well known server that wants to improve its offered services by providing seamless mobility without involving external third entities. In this scenario, it also appears reasonable for the MH to be configured with a set of known FH IP addresses for services the user might be interested in. Given a set of FHs, the MH performs authentication with all FHs, obtain a unique VIPA from each of them and set up with all FH a tunnel for each active interface. This procedures can be either performed at start up, or opportunistically every time the MH starts a session and are the same as in the MH-AN case. The MH PAFT is configured so that traffic toward either of the stored CH is encapsulated within the direct MH-TH tunnels, instead of passing through the AN. Each tunnel to the FHs indicates the correspondent unique VIPA to be used as source IP address. This scenario is equivalent to the Multi AN scenario and the tunneling/detunneling procedures performed by FH are the same as the ones described in Section 4.2. It is worth noting that the destination IP address of the inner packet is the same as the one in the tunnel header and therefore, the packet decapsulated by the FH is locally delivered without being masqueraded (as in the AN case). 4.5 MH to MH communications Even though the definition of UPMT mh2mh procedures is still object of our ongoing work, it is worth discussing how our proposed architecture is prepared to support a totally end to end configuration in which UPMT aware MHs can establish direct tunnels and communicate without passing through the AN. The final configuration of UPMT will be indeed a scenario in which the AN is used as packet relay only in case of communications with one legacy CH or UPMT aware nodes behind symmetric NATs and direct communications is performed when possible. It is important to note that the support for end to end mobility is direct consequence of some UPMT architectural choices. The IP/UDP tunneling mechanism and the SIP architecture behind the transport of UPMT signaling make possible for a MH to reach another MH behind NAT and perform a Interactive Connectivity Establishment (ICE [39]) like procedures to open direct IP/UDP flows. Moreover, the mh2mh scenario exploits the PAFT extension described in Section 4.2 to allow multiple tunnel endpoints in parallel. It is also worth remarking that all UPMT scenarios are supported at the same time, so that 33

34 UPMT can benefit from both centralized and distributed approaches and provide a versatile mobility management solution that can be adapted to different scenarios so to provide the MHs with the best possible connection at any time. The basic idea is to exploit SIP Registration and Proxy mechanisms to allow a UPMT MH to invite another UPMT MH to perform mutual association, authentication and set-up direct tunnels. The AN will act as rendezvous point, in the same way as a STUN [40] server, and will assist the MHs to discover each other s reflexive addresses. A set of reachability tests will be then performed between the two MHs and if direct tunnels are possible, these will be preferred to the relayed ones. Another aspect that makes mh2mh communications appealing, is the possibility to use S- UPMT procedures to protect end2end tunnels. In case of direct tunnel, S-UPMT in facts does not introduce the extra IPsec tunneling overhead and provide security enhanced end to end mobility management as in HIP 3. This aspect will be cleared up in Section SIP architecture for MH to MH communications In section 3.3 we presented the proposed UPMT information flows between the MH and the AN, which were mapped into the SIP protocol in section 3.4. We mentioned that the choice of SIP was not essential for the UPMT operations. In fact, this choice turns out to be very useful when extending UPMT for MH to MH communications. In the MH to AN scenario, the communication is always initiated by the MH, that sends the requests to the AN. On the other hand, in the MH to MH communication, a MH X that wants to comunicate with a corresponding MH Y, needs to first send an association request to the MH Y. In this case: i) the MH Y needs to be located, ii) there will be an incoming request to the MH Y; iii) this should work also if MH Y (and/or MH X) has a private IP address and is behind a NAT/FW. The SIP architecture has been exactly devised with these goals in mind and SIP protocol is used to establish multimedia session among SIP terminals. Within SIP architecture, a terminal performs a registration procedure with its Registrar Server. Incoming messages directed towards the terminal will be handled by an incoming SIP Proxy server. For simplicity we can assume that SIP Registrar and SIP Proxy server are co-located in an entity that we simply denote as SIP server and share a single user location DB. In UPMT, once a terminal has performed the Association procedure and has setup at least one tunnel towards the AN, it will perform a SIP registration procedure towards its SIP Registrar/Proxy server. In simple scenarios this server can be co-located with the default Anchor node of the user, but in general the SIP Registrar/Proxy server can be located anywhere in the Internet. Figure 15 shows how a terminal MH X with SIP address mh_x@an1.com is connected to Anchor Node 1 which is also its SIP server (i.e. Registrar and Proxy server), while a terminal MH_Y with SIP address mh_y@an1.com is connected to Anchor Node 2 which does not include the SIP server. Both MH X and MH Y will perform the registration procedure that will store their contact information into the common SIP server located in AN 1. When MH X wants to send an association request to MH Y, the association request message will be send to the SIP server that will locate the MH Y looking up its contact information and then it will forward the association request message to MH Y. Unfortunately, this straightforward procedure does not work if the MH Y is behind a NAT, as the contact information that MH Y can provide to SIP server is not 3 Moreover, since S-UPMT SAs don t need to be updated after a handover, end to end S-UPMT achieves the same HIP performances without requiring a new IPsec tunnel mode (i.e. the Bound End to End tunnel mode used in HIP). 34

35 valid in the Internet. The solution to this problem in our architecture is represented by the SIP Session Border Controller (SBC) entity. The SBC [41] is able to rewrite the contact information provided by the MHs so that incoming requests will be routed to the SBC itself. Moreover the SBC keeps an association with the MH, recording the IP address and port from which the MH messages are received. This IP address and port is used to send the incoming requests towards the MH, so that the open NAT pin-hole can be exploited. In the UPMT architecture, as shown in Figure 15 the Anchor Nodes also provide the SIP Session Border Controller (SBC) functionality. The SIP client is implemented on the same machine as the UPMT MH. For NAT traversal purposes, the SIP client is configured to use a Session Border Controller (SBC) at public IP address SBC_addr and port The SIP server (listening on port 5060) and the SBC (listening on port 5066) can be both implemented on the same machine of the UPMT AN (as shown for AN 1 in the figure), or the SIP server can be located anywhere in the Internet. The SBC performs Application Layer Gateway functionalities so that each SIP registration packet received from a client is inspected and contact header is modified by replacing the SIP client contact info with information pointing to the SBC itself. The IP address and the port of the IP packet transporting the SIP message is stored, and in case of NAT, it reflexes the address translation performed on the packet. SBC SIP Server NAT Anchor Node (AN1) SIP Client mh_x@an1.com Mobile Host X (MH) NAT Anchor Node (AN2) SIP Client SBC mh_y@an1.com Mobile Host Y (MH) Figure 15 UPMT SIP Architecture 35

UPMT Universal Per-application Mobility management using Tunnels

UPMT Universal Per-application Mobility management using Tunnels UPMT Universal Per-application Mobility management using Tunnels Stefano Salsano - stefano.salsano@uniroma2.it Marco Bonola - marco.bonola@uniroma2.it Always best connected (ABC) ABC service concept: automatic

More information

Telecommunication Services Engineering (TSE) Lab. Chapter III 4G Long Term Evolution (LTE) and Evolved Packet Core (EPC)

Telecommunication Services Engineering (TSE) Lab. Chapter III 4G Long Term Evolution (LTE) and Evolved Packet Core (EPC) Chapter III 4G Long Term Evolution (LTE) and Evolved Packet Core (EPC) http://users.encs.concordia.ca/~glitho/ Outline 1. LTE 2. EPC architectures (Basic and advanced) 3. Mobility management in EPC 4.

More information

Mobile IPv6 deployment opportunities in next generation 3GPP networks. I. Guardini E. Demaria M. La Monaca

Mobile IPv6 deployment opportunities in next generation 3GPP networks. I. Guardini E. Demaria M. La Monaca Mobile IPv6 deployment opportunities in next generation 3GPP networks I. Guardini E. Demaria M. La Monaca Overview of SAE/LTE Terminology SAE (System Architecture Evolution): core network/system aspects

More information

Mobility Management for All-IP Core Network

Mobility Management for All-IP Core Network Mobility Management for All-IP Core Network Mobility Management All-IP Core Network Standardization Special Articles on SAE Standardization Technology Mobility Management for All-IP Core Network PMIPv6

More information

IP and Mobility. Requirements to a Mobile IP. Terminology in Mobile IP

IP and Mobility. Requirements to a Mobile IP. Terminology in Mobile IP IP and Mobility Chapter 2 Technical Basics: Layer Methods for Medium Access: Layer 2 Chapter Wireless Networks: Bluetooth, WLAN, WirelessMAN, WirelessWAN Mobile Telecommunication Networks: GSM, GPRS, UMTS

More information

Mobile IP Part I: IPv4

Mobile IP Part I: IPv4 Mobile IP Part I: IPv4 Raj Jain Washington University in Saint Louis Saint Louis, MO 63130 Jain@cse.wustl.edu These slides are available on-line at: http://www.cse.wustl.edu/~jain/cse574-06/ 12-1 q Mobile

More information

Dissertation Title: SOCKS5-based Firewall Support For UDP-based Application. Author: Fung, King Pong

Dissertation Title: SOCKS5-based Firewall Support For UDP-based Application. Author: Fung, King Pong Dissertation Title: SOCKS5-based Firewall Support For UDP-based Application Author: Fung, King Pong MSc in Information Technology The Hong Kong Polytechnic University June 1999 i Abstract Abstract of dissertation

More information

Internet Architecture for Robust Mobility. Sangheon Pack (백상헌) Korea University shpack@korea.ac.kr

Internet Architecture for Robust Mobility. Sangheon Pack (백상헌) Korea University shpack@korea.ac.kr Internet Architecture for Robust Mobility Sangheon Pack (백상헌) Korea University shpack@korea.ac.kr Contents Introduction IETF Activity Home Agent Reliability Protocol P2P-based Approaches ROAM and SAMP

More information

Deploying IPv6 in 3GPP Networks. Evolving Mobile Broadband from 2G to LTE and Beyond. NSN/Nokia Series

Deploying IPv6 in 3GPP Networks. Evolving Mobile Broadband from 2G to LTE and Beyond. NSN/Nokia Series Brochure More information from http://www.researchandmarkets.com/reports/2379605/ Deploying IPv6 in 3GPP Networks. Evolving Mobile Broadband from 2G to LTE and Beyond. NSN/Nokia Series Description: Deploying

More information

Boosting mobility performance with Multi-Path TCP

Boosting mobility performance with Multi-Path TCP Boosting mobility performance with Multi-Path TCP Name SURNAME 1, Name SURNAME 2 1 Organisation, Address, City, Postcode, Country Tel: +countrycode localcode number, Fax: + countrycode localcode number,

More information

NAT and Firewall Traversal with STUN / TURN / ICE

NAT and Firewall Traversal with STUN / TURN / ICE NAT and Firewall Traversal with STUN / TURN / ICE Simon Perreault Viagénie {mailto sip}:simon.perreault@viagenie.ca http://www.viagenie.ca Credentials Consultant in IP networking and VoIP at Viagénie.

More information

Firewalls P+S Linux Router & Firewall 2013

Firewalls P+S Linux Router & Firewall 2013 Firewalls P+S Linux Router & Firewall 2013 Firewall Techniques What is a firewall? A firewall is a hardware or software device which is configured to permit, deny, or proxy data through a computer network

More information

LTE Performance and Analysis using Atoll Simulation

LTE Performance and Analysis using Atoll Simulation IOSR Journal of Electrical and Electronics Engineering (IOSR-JEEE) e-issn: 2278-1676,p-ISSN: 2320-3331, Volume 9, Issue 6 Ver. III (Nov Dec. 2014), PP 68-72 LTE Performance and Analysis using Atoll Simulation

More information

Internet Protocol: IP packet headers. vendredi 18 octobre 13

Internet Protocol: IP packet headers. vendredi 18 octobre 13 Internet Protocol: IP packet headers 1 IPv4 header V L TOS Total Length Identification F Frag TTL Proto Checksum Options Source address Destination address Data (payload) Padding V: Version (IPv4 ; IPv6)

More information

ITL BULLETIN FOR JANUARY 2011

ITL BULLETIN FOR JANUARY 2011 ITL BULLETIN FOR JANUARY 2011 INTERNET PROTOCOL VERSION 6 (IPv6): NIST GUIDELINES HELP ORGANIZATIONS MANAGE THE SECURE DEPLOYMENT OF THE NEW NETWORK PROTOCOL Shirley Radack, Editor Computer Security Division

More information

Network Mobility Support Scheme on PMIPv6 Networks

Network Mobility Support Scheme on PMIPv6 Networks Network Mobility Support Scheme on PMIPv6 Networks Hyo-Beom Lee 1, Youn-Hee Han 2 and Sung-Gi Min 1 1 Dept. of Computer Science and Engineering, Korea University, Seoul, South Korea. sgmin@korea.ac.kr

More information

SERVICE DISCOVERY AND MOBILITY MANAGEMENT

SERVICE DISCOVERY AND MOBILITY MANAGEMENT Objectives: 1) Understanding some popular service discovery protocols 2) Understanding mobility management in WLAN and cellular networks Readings: 1. Fundamentals of Mobile and Pervasive Computing (chapt7)

More information

Mobile IP. Bheemarjuna Reddy Tamma IIT Hyderabad. Source: Slides of Charlie Perkins and Geert Heijenk on Mobile IP

Mobile IP. Bheemarjuna Reddy Tamma IIT Hyderabad. Source: Slides of Charlie Perkins and Geert Heijenk on Mobile IP Mobile IP Bheemarjuna Reddy Tamma IIT Hyderabad Source: Slides of Charlie Perkins and Geert Heijenk on Mobile IP IP Refresher Mobile IP Basics 3 parts of Mobile IP: Outline Advertising Care-of Addresses

More information

ETSI TS 124 303 V8.9.0 (2012-07)

ETSI TS 124 303 V8.9.0 (2012-07) TS 124 303 V8.9.0 (2012-07) Technical Specification Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Mobility management based on Dual-Stack

More information

IP Flow Mobility: Smart Traffic Offload for Future Wireless Networks

IP Flow Mobility: Smart Traffic Offload for Future Wireless Networks 1 IP Flow Mobility: Smart Traffic Offload for Future Wireless Networks Antonio de la Oliva, Carlos J. Bernardos, Maria Calderon, Telemaco Melia and Juan Carlos Zuniga Universidad Carlos III de Madrid,

More information

6 Mobility Management

6 Mobility Management Politecnico di Milano Facoltà di Ingegneria dell Informazione 6 Mobility Management Reti Mobili Distribuite Prof. Antonio Capone Introduction Mobility management allows a terminal to change its point of

More information

REDUCING PACKET OVERHEAD IN MOBILE IPV6

REDUCING PACKET OVERHEAD IN MOBILE IPV6 REDUCING PACKET OVERHEAD IN MOBILE IPV6 ABSTRACT Hooshiar Zolfagharnasab 1 1 Department of Computer Engineering, University of Isfahan, Isfahan, Iran hoppico@eng.ui.ac.ir hozo19@gmail.com Common Mobile

More information

Demo 1. Network Path and Quality Validation in the Evolved Packet Core

Demo 1. Network Path and Quality Validation in the Evolved Packet Core Competence Center NGNI Demo 1 Network Path and Quality Validation in the Evolved Packet Core 1 Fraunhofer Institute FOKUS and TU Berlin AV AV provides education and applied research together with Fraunhofer

More information

NAT and Firewall Traversal with STUN / TURN / ICE

NAT and Firewall Traversal with STUN / TURN / ICE NAT and Firewall Traversal with STUN / TURN / ICE Simon Perreault Viagénie {mailto sip}:simon.perreault@viagenie.ca http://www.viagenie.ca Credentials Consultant in IP networking and VoIP at Viagénie.

More information

Diameter in the Evolved Packet Core

Diameter in the Evolved Packet Core Diameter in the Evolved Packet Core A Whitepaper November 2009 Page 2 DIAMETER in the Evolved Packet Core Mobile broadband is becoming a reality, as the Internet generation grows accustomed to having broadband

More information

How to secure an LTE-network: Just applying the 3GPP security standards and that's it?

How to secure an LTE-network: Just applying the 3GPP security standards and that's it? How to secure an LTE-network: Just applying the 3GPP security standards and that's it? Telco Security Day @ Troopers 2012 Peter Schneider Nokia Siemens Networks Research 1 Nokia Siemens Networks 2012 Intro

More information

SIP-BASED MOBILITY MANAGEMENT IN NEXT GENERATION NETWORKS

SIP-BASED MOBILITY MANAGEMENT IN NEXT GENERATION NETWORKS ACCEPTED FROM OPEN CALL SIP-BASED MOBILITY MANAGEMENT IN NEXT GENERATION NETWORKS STEFANO SALSANO AND ANDREA POLIDORO, UNIVERSITY OF ROME TOR VERGATA CHIARA MINGARDI AND SAVERIO NICCOLINI, NEC EUROPE LTD.

More information

IPv4 and IPv6 Integration. Formation IPv6 Workshop Location, Date

IPv4 and IPv6 Integration. Formation IPv6 Workshop Location, Date IPv4 and IPv6 Integration Formation IPv6 Workshop Location, Date Agenda Introduction Approaches to deploying IPv6 Standalone (IPv6-only) or alongside IPv4 Phased deployment plans Considerations for IPv4

More information

Practical Security Testing for LTE Networks BlackHat Abu Dhabi December 2012 Martyn Ruks & Nils

Practical Security Testing for LTE Networks BlackHat Abu Dhabi December 2012 Martyn Ruks & Nils Practical Security Testing for LTE Networks BlackHat Abu Dhabi December 2012 Martyn Ruks & Nils 06/11/2012 1 Today s Talk Intro to LTE Networks Technical Details Attacks and Testing Defences Conclusions

More information

Mobility (and philosophical questions about names and identity) David Andersen CMU CS 15-744. The problem

Mobility (and philosophical questions about names and identity) David Andersen CMU CS 15-744. The problem Mobility (and philosophical questions about names and identity) David Andersen CMU CS 15-744 The problem How to support mobile users What do we mean by support? Make it easy and convenient to effectively

More information

MOBILE VIDEO WITH MOBILE IPv6

MOBILE VIDEO WITH MOBILE IPv6 MOBILE VIDEO WITH MOBILE IPv6 DANIEL MINOLI WILEY A JOHN WILEY & SONS, INC., PUBLICATION CONTENTS PREFACE ABOUT THE AUTHOR xi xiii 1 THE MOBILE USER ENVIRONMENT: SMART PHONES, PORTABLE MEDIA PLAYERS (PMPs),

More information

TRIM: an Architecture for Transparent IMS-based Mobility

TRIM: an Architecture for Transparent IMS-based Mobility TRIM: an Architecture for Transparent IMS-based Mobility Ivan Vidal a,, Antonio de la Oliva a, Jaime Garcia-Reinoso a, Ignacio Soto b a Universidad Carlos III de Madrid. Avda. de la Universidad 30 28911

More information

Networking and High Availability

Networking and High Availability TECHNICAL BRIEF Networking and High Availability Deployment Note Imperva appliances support a broad array of deployment options, enabling seamless integration into any data center environment. can be configured

More information

Long-Term Evolution. Mobile Telecommunications Networks WMNet Lab

Long-Term Evolution. Mobile Telecommunications Networks WMNet Lab Long-Term Evolution Mobile Telecommunications Networks WMNet Lab Background Long-Term Evolution Define a new packet-only wideband radio with flat architecture as part of 3GPP radio technology family 2004:

More information

Introduction to Mobile IPv6

Introduction to Mobile IPv6 1 Introduction to Mobile IPv6 III IPv6 Global Summit Moscow Dr. Dimitrios Kalogeras dkalo@grnet.gr GRNET Outline Introduction Relevant Features of IPv6 Major Differences between MIPv4 and MIPv6 Mobile

More information

Wireless Networks: Network Protocols/Mobile IP

Wireless Networks: Network Protocols/Mobile IP Wireless Networks: Network Protocols/Mobile IP Mo$va$on Data transfer Encapsula$on Security IPv6 Problems DHCP Adapted from J. Schiller, Mobile Communications 1 Mo$va$on for Mobile IP Rou$ng based on IP

More information

Overview of Network Architecture Alternatives for 3GPP2 Femto Cells Jen M. Chen, et al. QUALCOMM Incorporated

Overview of Network Architecture Alternatives for 3GPP2 Femto Cells Jen M. Chen, et al. QUALCOMM Incorporated 3GPP2 Workshop, Boston, MA Title: Source: Contact: Overview of Network Architecture Alternatives for 3GPP2 Femto Cells Jen M. Chen, et al. QUALCOMM Incorporated Jen M. Chen QUALCOMM Incorporated 858-658-2543

More information

IPv6 SECURITY. May 2011. The Government of the Hong Kong Special Administrative Region

IPv6 SECURITY. May 2011. The Government of the Hong Kong Special Administrative Region IPv6 SECURITY May 2011 The Government of the Hong Kong Special Administrative Region The contents of this document remain the property of, and may not be reproduced in whole or in part without the express

More information

Security Testing 4G (LTE) Networks 44con 6th September 2012 Martyn Ruks & Nils

Security Testing 4G (LTE) Networks 44con 6th September 2012 Martyn Ruks & Nils Security Testing 4G (LTE) Networks 44con 6th September 2012 Martyn Ruks & Nils 11/09/2012 1 Today s Talk Intro to 4G (LTE) Networks Technical Details Attacks and Testing Defences Conclusions 11/09/2012

More information

Introducing Reliability and Load Balancing in Mobile IPv6 based Networks

Introducing Reliability and Load Balancing in Mobile IPv6 based Networks Introducing Reliability and Load Balancing in Mobile IPv6 based Networks Jahanzeb Faizan Southern Methodist University Dallas, TX, USA jfaizan@engr.smu.edu Hesham El-Rewini Southern Methodist University

More information

Mobility Management Framework in Software Defined Networks

Mobility Management Framework in Software Defined Networks , pp. 1-10 http://dx.doi.org/10.14257/ijseia.2014.8.8,01 Mobility Management Framework in Software Defined Networks Kyoung-Hee Lee Department of Computer Engineering, Pai Chai University, Korea leekhe@pcu.ac.kr

More information

Mobile SCTP Transport Layer Mobility Management for the Internet

Mobile SCTP Transport Layer Mobility Management for the Internet Mobile SCTP Transport Layer Mobility Management for the Maximilian Riegel Siemens AG, Munich, Germany E-mail: maximilian.riegel@icn.siemens.de Dr. Michael Tüxen Siemens AG, Munich, Germany E-mail: michael.tuexen@icn.siemens.de

More information

Mobility Management 嚴 力 行 高 雄 大 學 資 工 系

Mobility Management 嚴 力 行 高 雄 大 學 資 工 系 Mobility Management 嚴 力 行 高 雄 大 學 資 工 系 Mobility Management in Cellular Systems Cellular System HLR PSTN MSC MSC VLR BSC BSC BSC cell BTS BTS BTS BTS MT BTS BTS BTS BTS HLR and VLR HLR (Home Location Register)

More information

Technical Note. ISP Protection against BlackListing. FORTIMAIL Deployment for Outbound Spam Filtering. Rev 2.2

Technical Note. ISP Protection against BlackListing. FORTIMAIL Deployment for Outbound Spam Filtering. Rev 2.2 Technical Note ISP Protection against BlackListing FORTIMAIL Deployment for Outbound Spam Filtering Rev 2.2 April 14, 2009 Table of Contents 1 Objective IP address protection... 3 1.1 Context... 3 1.2

More information

Delivery of Voice and Text Messages over LTE

Delivery of Voice and Text Messages over LTE Delivery of Voice and Text Messages over LTE 1. The Market for Voice and SMS! 2. Third Party Voice over IP! 3. The IP Multimedia Subsystem! 4. Circuit Switched Fallback! 5. VoLGA LTE was designed as a

More information

SIP: NAT and FIREWALL TRAVERSAL Amit Bir Singh Department of Electrical Engineering George Washington University

SIP: NAT and FIREWALL TRAVERSAL Amit Bir Singh Department of Electrical Engineering George Washington University SIP: NAT and FIREWALL TRAVERSAL Amit Bir Singh Department of Electrical Engineering George Washington University ABSTRACT The growth of market for real-time IP communications is a big wave prevalent in

More information

Presentation_ID. 2001, Cisco Systems, Inc. All rights reserved.

Presentation_ID. 2001, Cisco Systems, Inc. All rights reserved. Presentation_ID 2001, Cisco Systems, Inc. All rights reserved. 1 IPv6 Security Considerations Patrick Grossetete pgrosset@cisco.com Dennis Vogel dvogel@cisco.com 2 Agenda Native security in IPv6 IPv6 challenges

More information

Network Address Translation (NAT)

Network Address Translation (NAT) Network Address Translation (NAT) Relates to Lab 7. Module about private networks and NAT. Taken from http://www.cs.virginia.edu/~itlab/ book/slides/module17-nat.ppt 1 Private Network Private IP network

More information

5.0 Network Architecture. 5.1 Internet vs. Intranet 5.2 NAT 5.3 Mobile Network

5.0 Network Architecture. 5.1 Internet vs. Intranet 5.2 NAT 5.3 Mobile Network 5.0 Network Architecture 5.1 Internet vs. Intranet 5.2 NAT 5.3 Mobile Network 1 5.1The Internet Worldwide connectivity ISPs connect private and business users Private: mostly dial-up connections Business:

More information

References and Requirements for CPE Architectures for Data Access

References and Requirements for CPE Architectures for Data Access Technical Report TR-018 References and Requirements for CPE Architectures for Data Access March 1999 '1999 Asymmetric Digital Subscriber Line Forum. All Rights Reserved. ADSL Forum technical reports may

More information

Tomás P. de Miguel DIT-UPM. dit UPM

Tomás P. de Miguel DIT-UPM. dit UPM Tomás P. de Miguel DIT- 15 12 Internet Mobile Market Phone.com 15 12 in Millions 9 6 3 9 6 3 0 1996 1997 1998 1999 2000 2001 0 Wireless Internet E-mail subscribers 2 (January 2001) Mobility The ability

More information

Virtual private network. Network security protocols VPN VPN. Instead of a dedicated data link Packets securely sent over a shared network Internet VPN

Virtual private network. Network security protocols VPN VPN. Instead of a dedicated data link Packets securely sent over a shared network Internet VPN Virtual private network Network security protocols COMP347 2006 Len Hamey Instead of a dedicated data link Packets securely sent over a shared network Internet VPN Public internet Security protocol encrypts

More information

Linux Based Implementation and Performance Measurements of Dual Stack Mobile IPv6

Linux Based Implementation and Performance Measurements of Dual Stack Mobile IPv6 Linux Based Implementation and Performance Measurements of Dual Stack Mobile IPv6 CHAMAN SINGH 1 K.L.BANSAL 2 1 Assistant Professor 2 Associate Professor chaman83mca@gmail.com kishorilalbansal@yahoo.co.in

More information

Nokia Siemens Networks Flexi Network Server

Nokia Siemens Networks Flexi Network Server Nokia Siemens Networks Flexi Network Server Ushering network control into the LTE era 1. Moving towards LTE Rapidly increasing data volumes in mobile networks, pressure to reduce the cost per transmitted

More information

Optimization Handoff in Mobility Management for the Integrated Macrocell - Femtocell LTE Network

Optimization Handoff in Mobility Management for the Integrated Macrocell - Femtocell LTE Network Optimization Handoff in Mobility Management for the Integrated Macrocell - Femtocell LTE Network Ms.Hetal Surti PG Student, Electronics & Communication PIT, Vadodara E-mail Id:surtihetal99@gmail.com Mr.Ketan

More information

3G/Wi-Fi Seamless Offload

3G/Wi-Fi Seamless Offload Qualcomm Incorporated March 2010 Table of Contents [1] Introduction... 1 [2] The Role of WLAN... 2 [3] 3G/Wi-Fi Seamless Offload Pathway... 2 [4] Application-Based Switching... 3 [5] Wi-Fi Mobility...

More information

Firewalls and VPNs. Principles of Information Security, 5th Edition 1

Firewalls and VPNs. Principles of Information Security, 5th Edition 1 Firewalls and VPNs Principles of Information Security, 5th Edition 1 Learning Objectives Upon completion of this material, you should be able to: Understand firewall technology and the various approaches

More information

ICS 351: Today's plan. IP addresses Network Address Translation Dynamic Host Configuration Protocol Small Office / Home Office configuration

ICS 351: Today's plan. IP addresses Network Address Translation Dynamic Host Configuration Protocol Small Office / Home Office configuration ICS 351: Today's plan IP addresses Network Address Translation Dynamic Host Configuration Protocol Small Office / Home Office configuration IP address exhaustion IPv4 addresses are 32 bits long so there

More information

IP Addressing A Simplified Tutorial

IP Addressing A Simplified Tutorial Application Note IP Addressing A Simplified Tutorial July 2002 COMPAS ID 92962 Avaya Labs 1 All information in this document is subject to change without notice. Although the information is believed to

More information

Architecture Overview NCHU CSE LTE - 1

Architecture Overview NCHU CSE LTE - 1 Architecture Overview NCHU CSE LTE - 1 System Architecture Evolution (SAE) Packet core networks are also evolving to the flat System Architecture Evolution (SAE) architecture. This new architecture optimizes

More information

Session Initiation Protocol Deployment in Ad-Hoc Networks: a Decentralized Approach

Session Initiation Protocol Deployment in Ad-Hoc Networks: a Decentralized Approach Session Initiation Protocol Deployment in Ad-Hoc Networks: a Decentralized Approach Simone Leggio, Jukka Manner, Antti Hulkkonen, Kimmo Raatikainen Department of Computer Science University of Helsinki,

More information

Tunnel Broker System Using IPv4 Anycast

Tunnel Broker System Using IPv4 Anycast Tunnel Broker System Using IPv4 Anycast Xin Liu Department of Electronic Engineering Tsinghua Univ. lx@ns.6test.edu.cn Xing Li Department of Electronic Engineering Tsinghua Univ. xing@cernet.edu.cn ABSTRACT

More information

NAT TCP SIP ALG Support

NAT TCP SIP ALG Support The feature allows embedded messages of the Session Initiation Protocol (SIP) passing through a device that is configured with Network Address Translation (NAT) to be translated and encoded back to the

More information

Networking and High Availability

Networking and High Availability yeah SecureSphere Deployment Note Networking and High Availability Imperva SecureSphere appliances support a broad array of deployment options, enabling seamless integration into any data center environment.

More information

Extending the Internet of Things to IPv6 with Software Defined Networking

Extending the Internet of Things to IPv6 with Software Defined Networking Extending the Internet of Things to IPv6 with Software Defined Networking Abstract [WHITE PAPER] Pedro Martinez-Julia, Antonio F. Skarmeta {pedromj,skarmeta}@um.es The flexibility and general programmability

More information

Software Defined Networking (SDN) - Open Flow

Software Defined Networking (SDN) - Open Flow Software Defined Networking (SDN) - Open Flow Introduction Current Internet: egalitarian routing/delivery based on destination address, best effort. Future Internet: criteria based traffic management,

More information

Advisor:Whai-En Chen Speaker:Meng-Hsuan Lin

Advisor:Whai-En Chen Speaker:Meng-Hsuan Lin Network-Based Mobility Management in the Evolved 3GPP Core Network Irfan Ali, Motorola Inc. Alessio Casati, Alcatel-Lucent Kuntal Chowdhury, Starent Networks Katsutoshi Nishida, NTT DoCoMo Inc. Eric Parsons,

More information

Implementing VoIP support in a VSAT network based on SoftSwitch integration

Implementing VoIP support in a VSAT network based on SoftSwitch integration Implementing VoIP support in a VSAT network based on SoftSwitch integration Abstract Satellite communications based on geo-synchronous satellites are characterized by a large delay, and high cost of resources.

More information

Quality-of-Service Support for Mobile Users using NSIS Roland Bless, Martin Röhricht Networking 2009, Aachen

Quality-of-Service Support for Mobile Users using NSIS Roland Bless, Martin Röhricht Networking 2009, Aachen Quality-of-Service Support for Mobile Users using NSIS Roland Bless, Martin Röhricht Motivation 1 More and more resource demanding Internet applications and multimedia streams video broadcasts, Voice-over-IP,

More information

VLANs. Application Note

VLANs. Application Note VLANs Application Note Table of Contents Background... 3 Benefits... 3 Theory of Operation... 4 IEEE 802.1Q Packet... 4 Frame Size... 5 Supported VLAN Modes... 5 Bridged Mode... 5 Static SSID to Static

More information

Network Address Translation (NAT) Good Practice Guideline

Network Address Translation (NAT) Good Practice Guideline Programme NPFIT Document Record ID Key Sub-Prog / Project Infrastructure Security NPFIT-FNT-TO-IG-GPG-0011.06 Prog. Director Chris Wilber Status Approved Owner James Wood Version 2.0 Author Mike Farrell

More information

Review: Lecture 1 - Internet History

Review: Lecture 1 - Internet History Review: Lecture 1 - Internet History late 60's ARPANET, NCP 1977 first internet 1980's The Internet collection of networks communicating using the TCP/IP protocols 1 Review: Lecture 1 - Administration

More information

Mobility Management Advanced

Mobility Management Advanced Mobility Management Advanced Summer Semester 2011 Integrated Communication Systems Group Ilmenau University of Technology Outline Motivation Mobility Management Approaches in the TCP/IP Reference Model

More information

Network Virtualization Mist to MUST

Network Virtualization Mist to MUST Network Virtualization Mist to MUST Ching-Wen Cheng ITRI ICL M100 2015.03.07 Motivation and background (ITU-T T Aspect) Objectives and motivation FNs are recommended to provide services whose functions

More information

District of Columbia Courts Attachment 1 Video Conference Bridge Infrastructure Equipment Performance Specification

District of Columbia Courts Attachment 1 Video Conference Bridge Infrastructure Equipment Performance Specification 1.1 Multipoint Control Unit (MCU) A. The MCU shall be capable of supporting (20) continuous presence HD Video Ports at 720P/30Hz resolution and (40) continuous presence ports at 480P/30Hz resolution. B.

More information

OVERLAYING VIRTUALIZED LAYER 2 NETWORKS OVER LAYER 3 NETWORKS

OVERLAYING VIRTUALIZED LAYER 2 NETWORKS OVER LAYER 3 NETWORKS OVERLAYING VIRTUALIZED LAYER 2 NETWORKS OVER LAYER 3 NETWORKS Matt Eclavea (meclavea@brocade.com) Senior Solutions Architect, Brocade Communications Inc. Jim Allen (jallen@llnw.com) Senior Architect, Limelight

More information

Network Convergence and the NAT/Firewall Problems

Network Convergence and the NAT/Firewall Problems Network Convergence and the NAT/Firewall Problems Victor Paulsamy Zapex Technologies, Inc. Mountain View, CA 94043 Samir Chatterjee School of Information Science Claremont Graduate University Claremont,

More information

SOFTWARE-DEFINED NETWORKING IN HETEROGENEOUS RADIO ACCESS NETWORKS

SOFTWARE-DEFINED NETWORKING IN HETEROGENEOUS RADIO ACCESS NETWORKS SOFTWARE-DEFINED NETWORKING IN HETEROGENEOUS RADIO ACCESS NETWORKS Hao Yu Technical University of Denmark (DTU), Oersteds Plads 343, Kgs. Lyngby, 2800, Denmark e-mail: haoyu@fotonik.dtu.dk Paper type Research

More information

Basic Vulnerability Issues for SIP Security

Basic Vulnerability Issues for SIP Security Introduction Basic Vulnerability Issues for SIP Security By Mark Collier Chief Technology Officer SecureLogix Corporation mark.collier@securelogix.com The Session Initiation Protocol (SIP) is the future

More information

Mobile Computing/ Mobile Networks

Mobile Computing/ Mobile Networks Mobile Computing/ Mobile Networks TCP in Mobile Networks Prof. Chansu Yu Contents Physical layer issues Communication frequency Signal propagation Modulation and Demodulation Channel access issues Multiple

More information

Chapter 9 Firewalls and Intrusion Prevention Systems

Chapter 9 Firewalls and Intrusion Prevention Systems Chapter 9 Firewalls and Intrusion Prevention Systems connectivity is essential However it creates a threat Effective means of protecting LANs Inserted between the premises network and the to establish

More information

Secured VPN Models for LTE Backhaul Networks

Secured VPN Models for LTE Backhaul Networks Secured VPN Models for LTE Backhaul Networks Madhusanka Liyanage, Andrei Gurtov Centre for Wireless Communications University of Oulu, P.O. Box 45, FI-914 Oulu, Finland Email: [madhusanka, gurtov]@ee.oulu.fi

More information

Network functions virtualization and software management

Network functions virtualization and software management ericsson White paper Uen 284 23-3248 December 2014 Network functions virtualization and software management LEVERAGING THE FULL POTENTIAL WITH NETWORK SLICING Network Functions Virtualization technology

More information

Proxy Server, Network Address Translator, Firewall. Proxy Server

Proxy Server, Network Address Translator, Firewall. Proxy Server Proxy Server, Network Address Translator, Firewall 1 Proxy Server 2 1 Introduction What is a proxy server? Acts on behalf of other clients, and presents requests from other clients to a server. Acts as

More information

21.4 Network Address Translation (NAT) 21.4.1 NAT concept

21.4 Network Address Translation (NAT) 21.4.1 NAT concept 21.4 Network Address Translation (NAT) This section explains Network Address Translation (NAT). NAT is also known as IP masquerading. It provides a mapping between internal IP addresses and officially

More information

TCP and Wireless Networks Classical Approaches Optimizations TCP for 2.5G/3G Systems. Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme

TCP and Wireless Networks Classical Approaches Optimizations TCP for 2.5G/3G Systems. Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme Chapter 2 Technical Basics: Layer 1 Methods for Medium Access: Layer 2 Chapter 3 Wireless Networks: Bluetooth, WLAN, WirelessMAN, WirelessWAN Mobile Networks: GSM, GPRS, UMTS Chapter 4 Mobility on the

More information

Mobile Routing. When a host moves, its point of attachment in the network changes. This is called a handoff.

Mobile Routing. When a host moves, its point of attachment in the network changes. This is called a handoff. Mobile Routing Basic Notions of Mobility When a host moves, its point of attachment in the changes. This is called a handoff. The point of attachment is a base station (BS) for cellular, or an access point

More information

Towards Software Defined Cellular Networks

Towards Software Defined Cellular Networks Towards Software Defined Cellular Networks Li Erran Li (Bell Labs, Alcatel-Lucent) Morley Mao (University of Michigan) Jennifer Rexford (Princeton University) 1 Outline Critiques of LTE Architecture CellSDN

More information

Static and Dynamic Network Configuration

Static and Dynamic Network Configuration CHAPTER 6 This chapter describes: Static Networks Dynamic Networks Static Networks The mobile access router can be part of a static network or a dynamic network. A static network supports stub routers

More information

Applications that Benefit from IPv6

Applications that Benefit from IPv6 Applications that Benefit from IPv6 Lawrence E. Hughes Chairman and CTO InfoWeapons, Inc. Relevant Characteristics of IPv6 Larger address space, flat address space restored Integrated support for Multicast,

More information

Project 4: IP over DNS Due: 11:59 PM, Dec 14, 2015

Project 4: IP over DNS Due: 11:59 PM, Dec 14, 2015 CS168 Computer Networks Jannotti Project 4: IP over DNS Due: 11:59 PM, Dec 14, 2015 Contents 1 Introduction 1 2 Components 1 2.1 Creating the tunnel..................................... 2 2.2 Using the

More information

Multicasting with Mobile IP & The Session Initiation Protocol

Multicasting with Mobile IP & The Session Initiation Protocol Multicasting with Mobile IP & The Session Initiation Protocol Hamad el Allali and Cristian Hesselman Abstract This report discusses how Mobile IP deals with multicast communications and describes a possible

More information

Software Defined Networking to Improve Mobility Management Performance

Software Defined Networking to Improve Mobility Management Performance Department of Computer Science and the Electrical Engineering, The Netherlands Software Defined Networking to Improve Mobility Management Performance Morteza Karimzadeh, Anna Sperotto, and Aiko Pras m.karimzadeh@utwente.nl

More information

NETASQ MIGRATING FROM V8 TO V9

NETASQ MIGRATING FROM V8 TO V9 UTM Firewall version 9 NETASQ MIGRATING FROM V8 TO V9 Document version: 1.1 Reference: naentno_migration-v8-to-v9 INTRODUCTION 3 Upgrading on a production site... 3 Compatibility... 3 Requirements... 4

More information

NTT DOCOMO Technical Journal. Core Network Infrastructure and Congestion Control Technology for M2M Communications

NTT DOCOMO Technical Journal. Core Network Infrastructure and Congestion Control Technology for M2M Communications M2M 3GPP Standardization Further Development of LTE/LTE-Advanced LTE Release 10/11 Standardization Trends Core Network Infrastructure and Congestion Control Technology for M2M Communications The number

More information

Methods for Lawful Interception in IP Telephony Networks Based on H.323

Methods for Lawful Interception in IP Telephony Networks Based on H.323 Methods for Lawful Interception in IP Telephony Networks Based on H.323 Andro Milanović, Siniša Srbljić, Ivo Ražnjević*, Darryl Sladden*, Ivan Matošević, and Daniel Skrobo School of Electrical Engineering

More information

How To Make A Vpc More Secure With A Cloud Network Overlay (Network) On A Vlan) On An Openstack Vlan On A Server On A Network On A 2D (Vlan) (Vpn) On Your Vlan

How To Make A Vpc More Secure With A Cloud Network Overlay (Network) On A Vlan) On An Openstack Vlan On A Server On A Network On A 2D (Vlan) (Vpn) On Your Vlan Centec s SDN Switch Built from the Ground Up to Deliver an Optimal Virtual Private Cloud Table of Contents Virtualization Fueling New Possibilities Virtual Private Cloud Offerings... 2 Current Approaches

More information

SAE and Evolved Packet Core

SAE and Evolved Packet Core SAE and Evolved Packet Core Farooq Bari Seattle Communications (COM-19) Society Chapter Nov. 13, 2008 1 SAE/EPS Background Around 2005, 3GPP RAN groups initiated the LTE work and in parallel the SAE work

More information

Approaches to Multicast over Firewalls: an Analysis

Approaches to Multicast over Firewalls: an Analysis Approaches to Multicast over Firewalls: an Analysis Loïc Oria Loico@hplp.hpl.hp.com August 1999 1 Introduction Most commercial organisations, and increasingly even universities, use firewalls to constrain

More information

Wireless & Mobile. Working Group

Wireless & Mobile. Working Group Wireless & Mobile Working Group Table of Contents 1 Executive Summary... 3 2 Mission & Motivation... 3 3 Scope... 3 4 Goals & Non-Goals... 4 5 Deliverables... 5 6 Milestones... 6 7 Example Use Cases Summaries...

More information