Since many PN Nodes are mobile, it is natural that also foreign commu- nication paths need to change. There are several reasons why mobility is required:
1. The Gateway Node switches its point of attachment to the Intercon- necting Structure requiring a different care-of address (CoA).
2. Direct communication between a Personal Node and a Foreign Node is no longer possible due to mobility. Consequently, a switch to Intercon- necting Structure-based communication may be required.
3. When direct communication becomes possible, it is usually better to switch from a connection via an Interconnecting Structure to a direct connection. Usually, a direct connection can offer better bandwidth, better QoS, and lower cost.
4. The selected Gateway Node becomes unavailable or loses its connection to the Foreign Node (or the Interconnecting Structure) and another Gateway Node must be used.
5. The Foreign Node might be mobile. However, in that case, it can be assumed that it has its own support for mobility.
These examples demonstrate the importance of good mobility solutions, also for foreign communication, as we would like on-going sessions to proceed without interruption. To overcome this problem, we propose two solutions. The first one is very simple, but non-optimal. It relies on always using Interconnecting Structures and routing the traffic through the PN Agent, which is a fixed node with a fixed address. The second solution is more complex but achieves much better routing, since traffic is routed through the most appropriate Gateway Node. In this case, mobility of the Gateway Node (terminal mobility) as well as a switch to another Gateway Node must be supported.
8.5. MOBILITY AND GATEWAY NODE HANDOVER 185
Figure 8.7: Foreign communication at the service level with another PN
8.5.1
Always using the PN Agent
The main advantage of this solution is its simplicity. All foreign communica- tion goes through the PN Agent, which means that only the PN Agent needs to implement the bridging as shown in Figure 8.7. The PN Agent never changes its address so there is no need for any external mobility solution between the PN Agent and the Foreign Nodes unless the Foreign Node is mobile. In addition, the intra-PN routing will be very simple. Packets with a Foreign Node destination are forwarded to a Gateway Node and then over the Interconnecting Structure to the PN Agent. A default route within the PN can achieve this. Hence, there is no need for source routing or tunneling to make sure the packets arrive at a particular Gateway Node.
Obviously, this solution has many limitations. To route all foreign traffic (both directions) through the PN Agent leads to non-optimal routing and a potential bottleneck. Furthermore, direct communication to a Foreign Node is not at all possible. On the other hand, this solution handles mobility of the PN Clusters also when communicating with Foreign Nodes. The link between the PN Agent and Foreign Node remains stable and does not change unless the Foreign Node is mobile. All mobility of the Personal Nodes takes place within the PN and is handled by the dynamic tunneling provided by the PN, which can be extended to include the PN Agent. The Cluster Gateway Nodes inform the PN Agent about their care-of addresses (CoAs), including changes thereof. This enables the Personal Nodes to be mobile while communicating with Foreign Nodes and this only at the cost of non-optimal routing on the Interconnecting Structure side.
This solution is similar to MobileIPv4, when using reverse tunneling as described in [150], except that foreign agents are never used in our case. While it would be possible to actually use Mobile IP, it would mean using two mobility solutions in parallel, which is of course unnecessary. Hence, it is better to rely on the mobility mechanisms already provided by the PN.
Figure 8.8: Foreign communication at the service level with another PN
There is one more important reason why this solution is good and that is privacy. If the traffic goes directly from the Gateway Node to the Foreign Node, the CoA of the Gateway Node will be known to the Foreign Node and this address can reveal the user’s current location. If the traffic goes via the PN Agent, this address will be hidden from the Foreign Node, thereby guarding the location privacy of the user.
8.5.2
Using the optimal Gateway Node
To enable mobility with optimal routing for foreign communication, two problems must be handled. First, address changes and multi-homing at the Gateway Node must be handled. Second, support for switching between two Gateway Nodes (or the PN Agent) must also be available. To sustain the ongoing connections, both require some sort of mobility support between the Gateway Node and the Foreign Node as shown in Figure 8.8. Hence, a common external mobility protocol is needed. In addition to this, a Gate- way Node handover also requires the two Gateway Nodes to exchange state information.
Consequently, there is a need for an intra-PN protocol that can commu- nicate the intention to change Gateway Node and then transfer these states between the two Gateway Nodes. The protocol should preferably be able to act before the old Gateway Node looses its connectivity or becomes unavail- able. The protocol must also trigger the external mobility protocol to take appropriate actions.
It cannot be assumed that Foreign Nodes can handle a sudden change of address at the Gateway Node without mobility support. Most current IP nodes on the Internet or elsewhere cannot handle such changes without loosing the connection. A widely deployed mobility standard is required; otherwise, the chance that a Foreign Node actually implements a proper
8.5. MOBILITY AND GATEWAY NODE HANDOVER 187
solution is very slim. With this in mind, there are only a few options that can handle mobility between the Gateway Node and the Foreign Node: Mobile IPv4 [178] This is a well-established protocol for mobility on IPv4
networks. The PN Agent can act as home agent (HA) and the Foreign Node can use IPv4 as usual without any modifications. Whenever a Gateway Node changes address or another Gateway Node is selected, the HA at the PN Agent is informed. However, the Foreign Node cannot be informed, which is a limitation of Mobile IPv4 as it is now being standardized. Consequently, the Foreign Node will always send its packets via the HA (PN Agent), which is still non-optimal. Only packets from the Personal Node to the Foreign Node will take the direct path. Furthermore, Mobile IPv4 is not able to switch to direct local communication when such possibilities exist. Instead, all traffic has to go via Interconnecting Structures. In the end, the benefits of this option, compared to always routing through the PN Agent, is rather limited.
Mobile IPv6 [103] The most important difference between Mobile IPv4 and Mobile IPv6 is the use of binding updates (BU), which are the messages sent to the HA to update the CoA. In Mobile IPv6, BUs are also sent to the Foreign Node. If the Foreign Node implements IPv6 and Mobile IPv6, it can directly send its packet to the Gateway Node instead of via the HA (i.e., PN Agent). Otherwise, the two protocols work in the same way and have the same limitations.
Host Identity Protocol (HIP) [151] HIP is also able to handle mobility [165], though it currently seems that it too lacks support for local direct communication. However, HIP is not yet a standard and still has a long way to go before becoming one. It is therefore unlikely that we can expect Foreign Nodes to implement HIP in the near future. However, if the Foreign Node supports HIP, then this could be a good choice. Transport and application layer mobility protocols As explained ear-
lier, many proposals have been made for mobility handling at the trans- port layer [142] [207] [12] [238] and at the application layer [203]. How- ever, all of them have the same problem as HIP; none is a standard yet and none has any real deployment. However, if any of them should take off and become widely deployed; they may all be good candidates. Contact networking [28] The most important benefit of contact network- ing compared to the previous alternatives is its support for local direct communication. This perhaps makes contact networking the best op- tion as long as it is widely deployed. However, no standardization effort is currently under way regarding this proposal. Furthermore, the security aspects are still to be addressed.
If two PNs are communicating, there is one more possibility. It would be possible to deploy special functionality at the Gateway Nodes that handles mobility between the PNs. In the case that any of the Gateway Nodes needs to change network address, a special inter-PN mechanism could be used to maintain the connection. They could exchange the addresses of their PN Agents to fall back on, in case the current communication link breaks. In addition, the address changes should be communicated directly between the foreign Gateway Nodes in the same way as in the protocols above.
In an ideal world, we conclude that a solution based on a combination of HIP and contact networking is probably the best solution. Such a solu- tion should be able to handle both security and mobility across both direct connections as well as Interconnecting Structures for all types of foreign com- munication.
Another important aspect of Gateway Node mobility is the handover delay. Coordination among the Personal Nodes and the Gateway Nodes, selection of a new Gateway Node, transfer of states, and the operations of the external mobility protocol all introduce delay. If a connection carries real- time data, serious quality problems may arise if the time to adapt becomes too long. Acting in advance, with a “make before break”-approach in combination with very speedy operations of all involved mobility interactions, is preferable.
8.5.3
Using Service Proxies
When using Service Proxies instead of NAT, it is still possible to use the same solutions for mobility between the Gateway Node and the Foreign Node. There is also the possibility to use service level mobility such as SIP mobility [203] instead of Mobile IP. Inside the PN, nothing at the network level needs to change.
The only additional problem that needs to be handled is the change of Ser- vice Proxy. Imagine that a Gateway Node running a Service Proxy is about to become unavailable, then a change to another Gateway Node with the same type of proxy is needed. This would require similar handover procedures as in the network level solution. However, the amount of state information that must be transferred may be larger and more complex. Typically, a Service Proxy will keep more state information related to the Service itself. Perhaps buffered data or remote procedure calls as well. Except for this, a transfer from one Gateway Node to another will work in the same way.