both of them are behind of NAPT router. Route optimisation is not possible and the hosts must communicate through a proxy.
• Both hosts can be behind the same NAPT device, but the communication between the hosts is restricted by firewall (shown in Figure 3.1 d). Most of hotspot providers restrict the communication between the hosts in the LAN (“hub-and-spoke”). Even in the same network, the hosts cannot communicate directly with each other. This restriction at the local firewall is done for security reasons (protection against local LAN attacks). Although it is very controversial, the policy is in place.
• There is no NAPT between the devices. This is the best case, where route optimisation is certainly possible.
The route optimisation is not possible in many real cases. It is even difficult for the hosts to determine the exact NAPT constellation. The private IPs used behind the NAPT usually overlap and therefore, the knowledge of the IP address is insufficient to determine if the hosts are in the same network. Trying to exchange packets is the only way to find out if direct communication is possible. Sending packets and waiting to see if there is an answer, is not ideal for real time applications. There are protocols, like ICE [12], which try interactive to established direct connection when possible. The protocol is an extension of SIP [4] and controls the target IP addresses in SDP. The experience of ICE protocol shows that the benefits of trying on-the-fly to optimise the connection are far less than the implementation complexity. There are more states and error combinations.
Interactive re-routing to a shorter path is a security issue too. A possible attacker can try to hijack a connection by pretending to be closer to the destination host. The security structure and states become more complicated and the risk of implementation defects increases.
The network topology in mobile environments changes frequently because of host’s movements. The topology can change from transparent to behind different NAPT routers, thus from Figure 3.1 b) to c). Monitoring and switching during the communication require many resources on the mobile hosts. The communication session becomes very instable due to packet losses.
Mobile VPN should deliver mechanism for routing optimisation, but its implementation is optional. The route optimisation makes more sense in closed networks, like provider’s backbones and Intranets.
3.3 Architecture overview of Mobile VPN
The M-VPN defines host types and network element. The terminology must not be confused with Mobile IP or IPSec although there are some relations. The roles of the nodes are different in Mobile VPN since the target and architecture is different. To prevent the reader from making some wrong association to the existing protocols, the nodes roles are defined:
• Mobile Client (MC) is a host moving through different networks, changing its IP address. A typical example is a small hardware device, like a smart phone attaching to different IP networks whilst communicating. The M-VPN delivers a static IP layer to the applications running on the Mobile Client. The mobile host establishes a connection to the Mobile Server, thus the mobile host is the initiator of M-KE and M-SE connection.
• The Mobile Server (MS) accepts connections from a Mobile Clients. The Mobile Server must not have static IP address and includes mobile
3.3 Architecture overview of Mobile VPN 46
functionality too. In contrast to the Mobile Client, the Mobile Server cannot initiate connection. The Server can be only a responder. Furthermore, the server can provide information for other Mobile Servers in the same administrative domain. In this way, dynamic overlay networks can be created. It is subjectively assumed that the server is moving more slowly than the Mobile Node. It is assumed that the Mobile Client is aware of the Mobile Server’s IP even if it changes.
• Mobile Node (MN) is a host being either Mobile Client or Mobile Server. The term is used to describe properties typically for both: Mobile Client and Server. The term is more general then Mobile Node in Mobile IP.
• Tunnel Node (TN) provides tunnelling functionalities. It creates and terminates tunnels. It could be standard L2TP LNS/LAC or GRE. The Tunnel Node is an optional element, which is external to M-VPN protocol. The node does not need any specific M-VPN functionalities but it is relevant for the protocol.
• Home IP parameter. The constant IP parameters assigned by the tunnel node (TN) are called Home IP parameters. These are used by the applications. They remain permanent during the PoA changes (moving to different access IP networks).
• Home Network is called the network corresponding to the Home IP parameters.
Other elements (nodes) relevant to the protocols and already existing parts of the network infrastructure are AAA servers (Authentication, Authorisation and Accounting). They are usually part of the Intranet infrastructure and mostly use protocols, like Radius [23], Kerberos [24] etc.
The M-SE protocol delivers transparent transport layer and constant network layer. The constant network layer is not transparent because the IP addresses are exchanged by M-SE with IP Mappers, see 3.6.1. Over the transport layer, a tunnel can be built by the Tunnel Node (TN), which is independent of the M-VPN. This is called tunnel mode of operation. The TN must be present on both sides (start and termination point), thus Mobile Client und Mobile Server. The TN can be deployed physically on the Mobile Node (MN) or on a separate host. The TN is usually part of the Mobile Client (MC), such as L2TP LAC. In contrary, the TN will be typically implemented on a different host at the Mobile Server’s (MS) side. The MS is typically an aggregation point of multiple M-SE sessions and the separation increases the performance of node. To emphasis this possible implementation, the MC is drawn together with the tunnel end point in Figure 3.2, Figure 3.3 and Figure 3.4. The MS and its TN are drawn as two separate logical elements.
The M-VPN can be also used in so-called native mode, see 3.6. There is not Tunnel Node in this deployment. The native mode is much more restrictive and can be used in fewer scenarios. The native mode is not the main target of the M-VPN and not described further in this section.
There are principally two types of usage of M-VPN in tunnel mode: Intranet and Internet usage. In the first case, the MC accesses the Intranet, such as corporate LAN. This is shown in Figure 3.2. The home network is part of the Intranet. The M-SE session protects the exchanges for achieving mobility. A tunnel such as PPTP, L2TP [13] is built over the M-SE session. The TN is called LNS in the L2TP terminology [13]. The MC has two IP addresses, one corporate (typically private) and one public IP. The corporate IP is permanent and used for the communication. The public IP is dynamically changing according to the MC
3.3 Architecture overview of Mobile VPN 47
movements. The communication hosts to the Mobile Client must also be part of the Intranet. The Mobile Client cannot communicate with its corporate IP to Internet.
In the Internet usage, the home network consists of public routable addresses as shown in Figure 3.3. The MC has two public IP addresses. The first one is a constant IP of the tunnel interface. The second IP is dynamic and used for Internet access. The Mobile Client can communicate to all Internet hosts using its public Home IP and vice versa.
3.3.1 Advantages of the physical separation between Mobile Node and Tunnel Node
The advantages of using external Tunnel Node are:
• There are already developed Tunnel Nodes, which can serve thousands of parallel sessions using hardware acceleration modules. They are a well- studied and stable implementation. For example: all aDSL customers use Point-to-Point Protocol (PPP) and the ISPs server millions of customers.
• The existing TNs are already integrated into AAA structures.
• There are synergy effects of using the same infrastructure for M-VPN, PPPoE in aDSL, L2TP over IPSec etc.
• The existing TNs integrate typically dynamic routing protocols, like ISIS and BGP, which is major requirement of the Network Service Providers.
• A new Tunnel Node in M-VPN requires new hardware implementation, new settings at AAA etc. This will complicate significantly the deployment.
3.3.2 Redundancy and load sharing in M-VPN
The M-VPN enables working in topologies with parallel connections to the same resources. This improves the availability through redundancy. The Figure 3.4 presents redundant connection, where the same home network is reachable through two separate MSs. The M-VPN delivers load sharing when the redundant connections are actively used. The load sharing is a routing problem. In M-VPN, this is left to the standard routing mechanism. Generally, the routers perform load sharing, when there are multiple paths with the same
Figure 3.2: M-VPN for Intranet access
Figure 3.3: M-VPN for Internet access
Intranet Intranet NAPT Router Private network Private
network InternetInternet
Tunnel Node Internet Hosts Mobile Server 2 1 M-SE Home Home Mobile Client &
Tunnel Node Intranet Intranet NAPT Router Private network Private
network InternetInternet
Tunnel Node Mobile Client &
Tunnel Node Intranet Hosts Mobile Server 2 1 M-SE Home network Home network Tunnel
3.3 Architecture overview of Mobile VPN 48
metrics for the same destination. The two connections in Figure 3.4 can be used for load sharing and redundancy. The routing protocols can run statically or dynamically over the tunnel.
3.3.3 Dynamic overlay network with M-VPN
M-VPN breaks the static topologies where the peers must be predefined. The Mobile Nodes can discover resources and establish new connection. A dynamic overlay topology can be build using this property. Dynamic network topology is very important because in mobile environment the optimal provider to resources may dynamically change. This improves significantly the recovery time by network failures. Furthermore, it enables path diversity in VPN and load sharing.
The key feature is a procedure, called Mobile Server discovery (see 3.8 and 4.10.1). The Mobile Server provides information to the Mobile Clients for other known Mobile Servers and optional their resources, like Web services, Videos etc. The procedure is part of M-KE protocol. The Mobile Client requests resources information and the server responds with a list of known Mobile Server. The server list contains objects representing resources, like IP addresses, home parameter, ID, media content etc. The criteria for establishing a connection to certain Mobile Servers depends on the Mobile Client policy and can be every parameter of the server list, such as the ID, round trip delay to the destination, etc.
The Mobile Servers provide the list to the Mobile Clients. The Mobile Clients cannot announce a list to the Mobile Server in opposite way. The Mobile Client may only nonce single resource running at the same host. The same host can run Mobile Client and Server Client, thus the host can accept connection and initiate connection at the same time. In this case, the Mobile Node can announce to other servers that it is also running a Mobile Server. The announced resources are added in the server list of the other Mobile Server. The Mobile Node cannot announce resources, which are not directly provided by him. This protects from avalanche effect, when every Mobile Node announces all known elements. The system will be overloaded because the same resources will be re-announced permanently. This simple rule that only directly provided resources can be announced, assurances single object per resource in the list.
Every Mobile Server has its own list of other resources. There is no general master list between all nodes in Mobile VPN, which requires version managements and time synchronisation etc. There is no desire to rebuild the existing dynamic routing protocols, where the target is to maintain a consistent routing table over multiple elements. The routing protocols may be used between the Mobile Nodes implemented in classical way. There are no particular restrictions because of M-VPN, thus there is IP connectivity between hosts.
An overlay network built with Mobile VPN is presented in Figure 3.5: Dynamic overlay network. The Mobile Client A can reach the node G via two different paths: A-B-D-G or A-
Figure 3.4: Redundant connection with M-VPN
NAPT Router LAN LAN Internet Internet TN A MS A M-SE Home network Home network Tunnel TN B MS B M-SE Intranet Home network Mobile Client &
Tunnel Node
Intranet
Intranet LAN