We obviously need the support of Interconnecting Structures to connect the Clusters. The only question is how much more support is required compared to what is currently offered [186]. IP transport between Gateway Nodes that are connected to the Interconnecting Structures is essential, but support from special servers may also benefit the operation of a PN. A contactable server somewhere in the Interconnecting Structures can offer services similar to a home agent in Mobile IP or a rendezvous server in HIP. We refer to such servers as PN Agents. Furthermore, the burden of Gateway Nodes may be reduced by special functionality offered by the access router that the Gateway Node connects to as been suggested by the MAGNET project [133]. Such routers with special PN functionality, we refer to as Edge Routers.
7.4.1
PN Agent
The PN Agent is a management entity located anywhere in the Interconnect- ing Structure or elsewhere from where it can be reached all the time (e.g., on a non-mobile Gateway Node). Each PN has a PN Agent and its task is to keep track of all Personal Nodes and Clusters in a PN. All the Gateway Nodes need to be aware of the IP address of their PN Agent. Therefore, the address is distributed to every Personal Node during the personalization. Gateway Nodes, which are always also Personal Nodes, hence know the address of the PN Agent.
Clusters that have obtained access to the Interconnecting Structure an- nounce their presence to the PN Agent as shown in Figure 7.1. More pre- cisely, the Gateway Node sends a registration message to the PN Agent. The information contained in the registration messages must be transferred in a secure way so that the information in the messages cannot be altered and is invisible to non-authorized parties. The registration messages need to contain at least the following essential information: PN identification, Node identification (e.g., intra-PN address), and the care-of addresses (CoA) of all
7.4. INFRASTRUCTURE SUPPORT 151
it’s active attachment points to the Interconnecting Structure. The PN iden- tification is needed since there might be more than one PN Agent running on one server. The PN Agent must also be able to check the credentials of the Gateway Node to access a certain PN and the message’s authenticity. The Gateway Node’s CoAs are of course needed, as this will represent the endpoints of the inter-Cluster tunnels. The PN Agent stores this information from all the Gateway Nodes in a secure database.
The information stored in the PN Agent can be queried by the Gateway Nodes in order to establish the inter-Cluster tunnels. Alternatively, the PN Agent may decide which tunnels should be established or maintained. The PN Agent can also assist in establishing tunnels between two Gateway Nodes that cannot directly establish a tunnel due to NATs and, if even that is impossible, the two Gateway Nodes may send their data traffic via the PN Agent.
The purpose of the PN Agent is quite similar to the home agent in Mobile IP or the rendezvous server in HIP. In this light, the PN Agent is best seen as an abstract entity and we could base the Gateway Node to PN Agent protocol on either Mobile IP or HIP. Mobile IP might not be the best choice, due to the difficulty of achieving direct tunnels between Gateway Nodes without modifying the protocol. HIP, on the other hand, implements functionalities that we do not need. As will be shown later, we will propose a protocol based on a simplified version of HIP, where the security parts of HIP are replaced with the PN Trust Relationships.
Note that the PN Agent also can provide additional functionality. It may assist in other PN-internal mechanisms such as name resolution and service discovery. Further, the PN Agent can be used by Foreign Nodes that wish to communicate with the PN. In that case, the address of the PN Agent is the only address a Foreign Node needs to know in order to be able to communicate with the PN. This will be discussed further in Chapter 8, where we will address the communication between PNs and Foreign Nodes.
Even though we have described the PN Agent as a single node in the Interconnecting Structure, it is not necessarily so. The PN Agent could be a distributed functionality running on several servers, a set of redundant servers [226], or a peer-to-peer network of servers (such as Chord [214]). There can be many reasons for for a distributed PN Agent, but the two most important reasons are increasing availability of the PN Agent functionality and reducing response time experienced by the Gateway Nodes.
Another important aspect is where the PN Agent server or servers should reside and under whose control and responsibility they are. The PN Agent can be a server in the Interconnecting Structure operated by the PN owner himself. A user that needs or wants total control of the PN Agent may want to run the PN Agent functionality on one of his own nodes, such as a Gateway Node in the home Cluster that connects to the Interconnecting Structures using a reliable and fixed connection without NAT. Alternatively,
Figure 7.2: Inter-Cluster communication with Edge Routers
network or service providers may offer PN Agent functionalities that can be used by their customers. We hope it is clear that there are several options for PN Agent deployment and which option is the best is not only a technical matter, but has, for instance, also business consequences.
7.4.2
Edge Routers
An Edge Router (ER) is an access router that sits on the edge of the Inter- connecting Structure, communicates with the Gateway Nodes and supports them by offering special functionality for PNs [136][125][76]. They need to be managed by a network or service provider and thus will probably be owned by the provider. On behalf of a Cluster, an ER can perform several intra- PN tasks, such as communicating with the PN Agent and taking care of the inter-Cluster tunnel establishment and management. In this way, ERs can relieve the Gateway Nodes of some of the work and thereby allow them to reduce their power consumption and resource requirements. Figure 7.2 shows an example of inter-Cluster communication using ERs. In this example, we assume that not all access networks provide ER-functionality and hence some Gateway Nodes still need to perform all tasks related to inter-Cluster tun- neling.
If we assume that Gateway Nodes need to maintain many tunnels, then this maintenance consumes valuable resources, such as processing and battery power. The tunnel maintenance may therefore overload the Gateway Nodes, which are often mobile and battery-powered. Thus, it will be useful to let ERs, which are fixed and powerful devices in the Interconnecting Structures, support the tunnel establishment as much as possible and thereby place the overhead needed for establishing and operating a PN in the Interconnecting Structures. Furthermore, ERs can assume other responsibilities as well, such as inter-Cluster routing, remote service discovery, service repository, and more.
7.4. INFRASTRUCTURE SUPPORT 153
The use of ERs has both advantages and disadvantages [186]. Let us summarize the advantages of an ER-based solution as follows:
1. Some tasks can be carried out by the ER, which leads to less consump- tion of scarce resources in mobile devices.
2. Mobile Gateway Nodes can be made more lightweight. This leads to simpler devices that have lower cost and less power consumption. Consequently, more PN Nodes can provide Gateway Node functional- ity, which leads to increased flexibility in accessing the Interconnecting Structures.
3. PN formation and maintenance are faster and hence can better support Cluster mobility.
4. ERs may support special functionality that can optimize handovers that current access technologies do not offer. This could, for instance, include Fast Handover for Mobile IPv6 (FMIPv6) [112] and/or Hierar- chical Mobile IPv6 Mobility Management (HMIPv6) [208].
The ERs are infrastructure-based entities that contain functionality ex- plicitly designed for PNs. However, this approach has serious drawbacks:
1. ERs need to be deployed. Since ERs are access routers uniquely de- signed for PNs, it is necessary modify the infrastructure by introducing these network elements. This has been proven to difficult in the past and therefore is likely to be a major stumbling block. If Gateway Nodes require ERs, then the deployment of PNs can only take place after op- erators have invested on a sufficient scale in ERs and hence there is a risk that this will slow down the success of PNs. Furthermore, the service providers need to maintain these more complex ERs.
2. ERs do not reduce the complexity of the PNs. Due to the expecta- tion that there will be many access networks without ERs, it is still necessary for the Gateway Nodes to implement full Gateway Node- functionality. As long as not all access networks offer ER-functionality, this will be a drawback. In the mean time, Gateway Nodes need to han- dle two cases: access networks with ERs and access networks without ERs.
3. The ERs need to be trusted by the user since ERs will support the internal mechanisms of the PN and this may endanger the security and privacy of PNs. In the case that an ER is not trusted, the Gate- way Node cannot use the ER and must instead perform all Gateway- functionalities itself. Furthermore, ERs must trust the PN Agents, even when they belong to another operator or to the user himself.
The issue of ER deployment is a major drawback that currently makes it important to support ER-less access networks. Future solutions may consider ER technologies as a way to optimize the performance of PNs. We will therefore mainly focus on solutions not requiring ERs in the remainder of this thesis.
7.4.3
PN networking without infrastructure support
It is of course possible to design an intra-PN communication system with- out special infrastructure support such as ERs and PN Agents. To do so, we need to turn our attention to peer-to-peer technology. The biggest advantage of peer-to-peer technology is that, in principle, it can make infrastructure- based support completely unnecessary. The peer-to-peer system ROAM [244], which we introduced in Section 7.2, unfortunately does not demon- strate this advantage. Instead, ROAM requires the deployment of i3 servers and it is these servers that form the peer-to-peer network.
To make both ERs and PN Agents superfluous, we need to make the Gateway Node themselves into peers in the peer-to-peer network. This means that the Gateway Nodes need to manage the inter-Cluster tunnels themselves. Each Gateway Node needs to remember the current locations (i.e., the CoA) of as many other Gateway Nodes in the PN as possible. This will work if some Gateway Nodes almost never move or if not all Gateway Nodes move at the same time. Normally, we can expect that at least one Gateway Node (e.g., the home-Cluster Gateway Node) never moves, which means that the other Gateway Nodes always can connect to that Gateway Node to be updated.
There are two main problems with not having the support of a PN Agent. The first major problem is the bootstrapping of the peer-to-peer overlay. In the beginning, all Personal Nodes need to gather in one single place and form one single Cluster in order to exchange the CoAs. New Gateway-capable Nodes added to the PN need to communicate with a connected and updated Gateway Node in order to retrieve all current CoAs. Whenever a Node has been deactivated for a long time, this procedure might need to be repeated. There is always the risk of some of the Gateway Nodes being disconnected from the rest and not knowing how to reconnect to the PN, even though it may work most of the time.
The second major problem in PNs without a PN Agent is the slow re- sponse to mobility. When a tunnel needs to be updated because an endpoint has moved, it is important that a new CoA or an alternative Gateway Node is found quickly. Unfortunately, when also several other Gateway Nodes have disappeared, it may take a while before the right Gateway Node has been queried. The alternative is to update all the other Gateway Nodes all the time, which, of course, introduces a lot of overhead. Because of these reasons, and the reason outlined in Chapter 8 regarding foreign communication, we propose to always make use of a PN Agent.