The capability for mobility introduces a number of challenges to conventional wide area data networking. One measure of a mobile system's usefulness in the real world is the extent to which that system addresses these challenges.
The first challenge of mobility is the mapping of geographic coordinates to network addresses. Data networking is inherently topological in nature: two hosts are either (directly or indirectly) connected or they are not. Physical location of the hosts is immaterial, except for the physical limitations of the medium in use.
A network address, including a netid and a hostid, indicates the topological connectivity of a host (i.e., the subnet defined by the netid) but not its geographic location. Moving a host to a new geographic location might or might not require a change in network address, depending on whether the topological (network) connectivity has changed.
However, mobility is inherently a geographic capability-being able to be anywhere anytime. Since the essential problem of mobility is being able to receive communications anywhere and the routing of data to a host is via network address (netid), there needs to be a mapping of some sort between the geographic location of the mobile host and the network connectivity. This mapping can be either explicit or implicit, but it must be done to get data packets to a mobile host.
Because the geographical to topological mapping is loose and dependent on the systems technology and architecture, movement in the geographic sense may or may not be reflected in the topological sense. Either the system can provide this geographic to topological location mapping or corresponding entities must do this mapping themselves. This is the heart of mobility management.
Another challenge of mobility is the part-time connectivity of mobile entities. This is an issue for any networked host which is frequently unavailable.
Accessing an occasionally-connected host is an issue because it requires effort above and beyond what is normally required in conventional networks. Data networking paradigms today assume the essentially continuous availability of networked hosts to receive correspondence. If a host is unavailable, current applications must either continuously page for the intended recipient or have the temporarily disconnected host poll each of its potential application servers as soon as it rejoins the network.
In conventional networks and LANs, polling is not a problem because there is generally plenty of bandwidth to accommodate this overhead. However, in mobile WANs, which could support millions of users, accessing part-time destinations (which could be anywhere) is an issue! If each mobile host had to poll each of its application servers (accross a wide area) the result would be a system which does not scale well.
Another aspect of part-time destinations is the fact that connectivity is a network layer concern, while correspondence between entities is typically at the application layer. Thus, there needs to be an efficient mechanism for bridging between applications layer entities' desire to correspond and network layer connectivity.
What is needed in a mobile WAN environment is the capability for efficient storing and forwarding of data in a manner which is transparent to corresponding application entities. This might involve storing and forwarding of messages (application layer PDUs) rather than packets (network layer PDUs).
For example, if two systems need to exchange data but are never operating at the same time, an intermediary system of some kind is needed to facilitate the data exchange. The intermediary store-and-forward entity would first receive the data (e.g., Email) from the source when both are operating. The intermediary would then forward the data on to the destination system when they are both operating.
Another challenge of mobility is getting data to a potentially moving target. Given a geographic to topological address mapping capability and an efficient store and forward capability, there remains a need for efficient routing of the data to a host which frequently changes location. Routing tables need to be updated more frequently than a mobile host changes its cell location. This challenge is exacerbated in transient (i.e., Type 2) entities which can be in-motion at the time a correspondent is communicating with it.
Some systems address this moving target challenge by having the current mobile serving function notify its predecessor. This solution can be effective, but suffers from the creation of a potentially long trail of MSFs which forward messages from one to another until eventually reaching the current one. This is not unlike the method used by the postal service1.21 or cellular voice systems.
Another challenge of mobility is transparency. Neither an application on a mobile host nor the peer with which it is communicating should be directly impacted by location-independence. The application should operate and-to the human using it-it should look and feel the same as it would in a non-mobile context. Transparency requires standard Application Program Interfaces or APIs to provide the normal "look and feel" to applications and the humans using them; as we shall see, lack of standard APIs has limited the adoption of some otherwise appropriate mobile data systems.
The mobility of the host should also be transparent to the rest of the world with which it is communicating. Any entity wishing to communicate with a mobile entity should be able to do so regardless of the target's mobility.
The "hourglass" of protocols of Figure 1.16 depicts one way that transparency is naturally provided in internetworking environments. By having a common Layer 3 protocol-typically IP-many applications can be supported independently of the many subnetwork technologies and media available.
The conventional world of data networking is based on a paradigm of routing data packets based on the network address of the destination (host). This paradigm should be unaffected by the mobility of the destination. Whether the host is "at home" or "on the road," the peer attempting to communicate with it should not have to do anything special beyond what normally would be done to communicate with another host. As we shall see, this has many implications in areas such as directory services, routing, security and accounting.
Transparency of mobility has further implications. Since many applications require connection-oriented transport layer services, Type 2 Mobility data systems must maintain end-to-end transport connections even while the mobile host is in motion. This implies that host network addresses must not change to support mobility, otherwise transport and higher layers are impacted.
Finally, [IOAN93] says that: "an issue that cannot be handled in lower level protocols, is that of coping with intermittent operation, disconnected operation, or operation during which network characteristics such as bandwidth and latency change significantly. Even if the network layer hides the addressing aspect of mobility from higher levels, applications may want to be Ômobile-smart', and function differently as the service provided by the network link changes (for example, by increasing the granularity of communication)."
Another challenge of mobility is support for DNS-type directory services. The primary function provided by the Domain Name System (DNS) is the translation between host network layer addresses and more user-friendly names. These services allow applications such as Email to use names such as "joe@BigCompany.com" as destinations rather than the more human error-inducing addresses such as "joe@123.45.6.789." If changing geographic coordinates implies changes to network addresses, clearly DNS services cannot work in their current format. This again seems to imply the need for "permanent" network addresses of some kind for mobile hosts.
There has been much recent discussion about security in WAN environments. The focus of this discussion is the use of firewalls of various kinds [KAUF95] to prevent unauthorized access to networks from the outside. The assumption is that an attack will come from outside of the local subnet; unfortunately, a high percentage of security "incidents" involves people inside the subnet (e.g., disgruntled employees).
However, mobility of hosts creates new opportunities for compromised network security because the physical security of a subnet is not longer provided. Each time a mobile host establishes a new subnet point of attachment (SNPA), it must authenticate itself to the subnet it is attaching itself to. ( Authentication is the process of verifying a host's identity and is essential to detection and prevention of clone devices.)
Typically authentication involves the use of a password of some kind. Protection of this password as well as the identity and data of a mobile from potential "eavesdroppers" requires the use of encryption techniques. This (encryption and security in general) raises the costs of providing mobile data services in terms of network and processing overhead, royalties (for the security technology), key management, etc. All of this needs to be embedded within a mobile system, not a later add-on.
Security issues in mobile data networks are discussed in Chapter 6.
Mobility in WANs raises concerns of scalability to higher levels than ever before. In a mobile WAN environment one could expect millions of hosts and routers.
However, current routing update protocols (e.g., RIP) fail with much smaller numbers of hosts. The need to exchange mobile routing information across the network more frequently adds significantly to network overhead. Propagation of routing information takes longer the larger the network grows (e.g., larger routing tables); so does the amount of computation required at each router (to determine the next hop for a packet).
Additional concerns for authentication and accounting for system usage exacerbate the scalability concern. In a mobile WAN, where mobile hosts can suddenly appear anywhere, rapid access to authentication data is essential. However, replication of the data to enable rapid access raises concerns in areas such as distributed database consistency, etc.