Move detection and location discovery, two of the most important requirements of a mobility protocol, are addressed in Mobile IP through the use of agent advertisements. Mobile IP agent advertisements are built on top of the Internet Control Message Protocol (ICMP) Router Discovery Protocol (IRDP), which was first proposed in RFC 1256. IRDP consists of two messages that are enhanced to support Mobile IP, as follows:
Use of the Mobile IP agent advertisement and Mobile IP agent solicitation are depicted in Figure 2-8.
Figure 2-8. Mobile IP Agent Discovery
The use of these messages allows a Mobile Node to learn which Mobility Agents are out there and what Mobile IP services they are providing. The Mobile Node can also learn the specific subnets that are available on the link. Specifically, the Mobile Node pays attention to the following important fields and options bits in the Mobile IP advertisement extension:
Example 2-1 shows the agent advertisement message in detail. In this example, the Mobility Agent is a FA with CoA 192.168.100.6, supporting GRE and reverse tunneling. The FA is advertising mobility support for 10 hours.
Example 2-1 is a packet capture and decode of an actual agent advertisement taken with Ethereal, a network protocol analyzer. Protocol analyzers are widely used for troubleshooting and provide a field-by-field view of the packet.
Example 2-1. Mobile IP Agent Advertisement Protocol Detail
Internet Protocol, Src Addr: 192.168.100.6, Dst Addr: 255.255.255.255 Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 54 Identification: 0xd838 Flags: 0x00 Fragment offset: 0 Time to live: 1 Protocol: ICMP (0x01) Header checksum: 0xbce0 (correct) Source: 192.168.100.6 (192.168.100.6) Destination: 255.255.255.255 (255.255.255.255) Internet Control Message Protocol Type: 9 (Router advertisement) Code: 0 Checksum: 0x6ba4 (correct) Number of addresses: 1 Address entry size: 2 Lifetime: 30 seconds Router address: 192.168.100.6 Preference level: 0 Ext: Mobility Agent Advertisement Extension Extension Type: Mobility Agent Advertisement Extension (16) Length: 10 Sequence Number: 3 Registration Lifetime: 36000 Flags: 0x15 0... .... = Registration Required: False .0.. .... = Busy: False ..0. .... = Home Agent: False ...1 .... = Foreign Agent: True .... 0... = Minimal Encapsulation: False .... .1.. = GRE: True .... ..0. = Reserved: False .... ...1 = Reverse Tunnel: True Reserved: 0x00 Care-Of-Address: 192.168.100.6 (192.168.100.6) Ext: Challenge Extension Extension Type: Challenge Extension (24) Length: 4 Challenge: B858BED2
Here are the descriptions of the fields in the IP Header:
Here are the descriptions of the fields in the ICMP Header:
Here are the descriptions of the fields in the Mobility Advertisement Extension:
Here are the descriptions of the fields in the Prefix Length Extension:
Here are the descriptions of the fields in the Challenge Extension:
Recall that a Mobile Node can find itself in two types of locations: the Home Network and the visited network. To identify which one of these network locations it is currently in, the Mobile Node must look at two parts of the agent advertisement. To determine whether it attached to its Home Network, the Mobile Node compares its Home Address and prefix to the router address(es) in the IRDP portion of the message, which identify each subnet that is routed to the link. If any of the router addresses is on the Mobile Node's Home Network, the Mobile Node knows it is at home. If the Mobile Node is not at home, it looks at the CoA(es) listed in the message. The Care-of Address Extension carries one or more IP addresses from the FA. These address(es) can be the same as the interface address(es) advertised in the router address portion of the advertisement, or they can be address(es) from other interfaces. When we look at Mobile IP deployment scenarios starting in Chapter 4, "IOS Mobile IP in the Lab," you see that the recommended CoA for a FA is a single loopback address, not a physical interface address.
If the Mobile Node does not receive an agent advertisement on a link, it can attempt to use a dynamic addressing mechanism such as DHCP to determine its current location. The address it obtains through the dynamic addressing mechanism can be used as a CCoA during the Mobile IP registration process.
As you see in the next section, some aspects of location discovery and move detection are intentionally vague or left out of the standard because they do not impact interoperability. This allows tremendous flexibility in the implementation of Mobile Node clients, but makes it difficult for us to tell you how the Mobile Node will behave. What we present here is either directly addressed in the standard or introduced as a common, but not standard, feature.
One of these undefined portions of the standard surrounds how a Mobile Node can determine whether it should use a FAbased CoA or a CCoA. Common logic would suggest that a Mobile Node wait for a Mobile IP agent advertisement, possibly following a solicitation, and then attempt to use a CCoA, if necessary. In the interest of speed, some Mobile Nodes attempt to solicit for a Mobile IP advertisement and begin the DHCP process of obtaining a Colocated CoA at the same time, assuming that the DHCP address can be released if a FA is found. Some Mobile Nodes avoid the uncertainty by forcing the user to define which type of CoA is to be used on a per-interface basis.
Move Detection and Mobile IP Handover Policy
Move detection is the process that the Mobile Node uses to determine changes in the usability of its access links. This information is coupled with the Mobile IP handover policy to determine when the Mobile Node needs to initiate a Mobile IP Handover, as defined in the section "Mobile IP Handover," later in this chapter. The two are so tightly coupled in Mobile IP that move detection often implies Mobile IP handover policy, although some important distinctions exist.
Before we go any further, we take a closer look at access links. Every Mobile Node has at least one interface that it can use to connect back into the network. With only one access link available, the Mobile IP handover policy is relatively easy to determine. More-complex algorithms become necessary when a Mobile Node has more than one access interface. Adding to the challenge, some link types associate with only one "base station" at a time, similar to the way Ethernet worksthe cable has two ends, one at the client and the other at the base station. However, more advanced link types allow the client to communicate with more than one base station at a time. The latter is ideal for Mobile IP because the Mobile Node can maintain its association with one base station while registering through another.
A Mobile IP handover policy governs the Mobile Node's behavior upon move detection and can be classified as either reactive or proactive. The RFC specifies two reactive Mobile IP handover policy algorithms, described in the following two sections, but the option to use other algorithms is left up to Mobile Node implementers. With these reactive algorithms, it is hard to distinguish between move detection and Mobile IP handover policy, because move detection is based strictly on Mobile IP messages. On the other hand, proactive algorithms show the importance of separating the two concepts. The proactive algorithms track movement, but they only trigger a Mobile IP handover when a better communication link is available, as described in the section "Link-State Triggers," later in this chapter. Mobile Nodes are not restricted to using a single Mobile IP handover policy. The Mobile IP handover policy algorithms described in the next sections do not have standardized names, but names are used here to show the key characteristics of the algorithm.
The first Mobile IP handover policy defined in the RFC can be classified as the steady-state algorithm.
In this algorithm, the Mobile Node holds on to its current FA as long as it can. After the Mobile Node establishes a valid registration with a FA, it continues to listen for advertisements from other FAs. However, the Mobile Node does not register with a new FA until the current FA's advertisement lifetime has expired. The steady-state algorithm is depicted in Figure 2-9. This means that even if the Mobile Node hears an agent advertisement from another FA on the same interface, it does not register through the new FA until the current FA's advertisement expires.
Figure 2-9. Steady-State Algorithm
The steady-state algorithm minimizes the number of Mobile IP registrations, because a Mobile Node does not attempt to register through a new FA as long as it thinks it still has connectivity through its current FA. In a sense, it aims to maintain a constant link for communication between the Mobile Node and FA. However, the problem is that the Mobile Node could go the entire hold time (the amount of time that the Mobile Node considers the Mobility Agent still reachable without having received an agent advertisement) without connectivity.
New Network Algorithm
The new network algorithm requires the use of the prefix length extension, which specifies the network prefix lengths in order for each respective router address that is listed in the agent advertisement. Using the Mobile IP agent advertisement and the prefix length extension, the Mobile Node knows exactly which subnets are available on the current link, whether it is on the Home Network or a Foreign Network. When a Mobile Node hears an advertisement on that link advertising a different subnet, it can assume that it has changed its point of attachment to the network. Specifically, the Mobile Node compares the network prefix(es) of its current Mobility Agent's advertisement against any newly received agent advertisements. If they differ, the Mobile Node can assume that it has roamed and needs to initiate a Mobile IP handover. Use of the new network algorithm is depicted in Figure 2-10.
Figure 2-10. New Network Algorithm
The new network algorithm is more efficient than the steady-state algorithm, because the Mobile Node does not wait until the hold time expires before it considers a new Mobility Agent. Rather, with this method, a Mobile Node can hand over in less than the new network's advertisement interval. However, if the new network advertisement interval is longer than the previous network's hold time, this method is less efficient than the steady-state method.
The ideal Mobile IP handover policy is to use link-state triggers and can be considered either reactive or proactive, depending on the action taken. This method is not specified in the core Mobile IP RFC because it cannot be implemented at Layer 3, but rather relies on information from Layer 2. Moreover, the quality and quantity of link-state triggers are device and access-link specific. However, in real-world implementations, many Mobile Nodes are in fact capable of detecting link state effectively, for example, when physical cables are unplugged and when wireless links hand over. Using this Layer 2 information along with Mobile IP agent solicitations, the Mobile Node can determine even more quickly whether it has moved. For example, as illustrated in Figure 2-11, if the Mobile Node receives a Layer 2 trigger that its wireless Local Area Network (LAN) connection is handing over, the Mobile Node can solicit for Mobile IP agent advertisements on the new wireless link. Upon hearing a new agent advertisement in response to the solicitation, the Mobile Node can immediately register with its Home Agent.
Figure 2-11. Using Link-State Triggers
When using link-state triggers, move detection latency is reduced to the sum of the link-state detection and notification delay, and the Mobile IP solicitation and agent response delay.
When using link-state triggers proactively, the Mobile Node makes an active choice to initiate a handover, even if its existing link is still functional. In this context, a proactive handover can be at Layer 2 or Layer 3, and might be from one interface to another, or it might be to force an interface to reassociate with a new base station. When a Mobile Node forces an interface to move, it behaves just like a link-state change. However, now, rather than the interface telling the Mobile Node it has moved, the Mobile Node tells the interface to move. This can be useful in wireless environments, where the Mobile Node can determine information, such as signal strength and quality, about other base stations. A proactive handover due to link-state triggers is most often implemented between two interfaces, which is one of the most powerful features of Mobile IP. Although not defined in RFC 3344, nearly all Mobile IP clients include some from of proactive handover.
Proactive handover is similar to route selection in traditional routing protocols. Valid agent advertisements are combined with a series of metrics to determine which advertisement is the best to use. Typical metrics include link bandwidth and link cost, although other metrics, like signal strength and latency, could also be applied. Metrics do not need to be standardized because they are assigned and used only by the Mobile Node. The network infrastructure does not perform route selection. Depending on the implementation, metric precedence is either predefined or user controllable. Typically, metrics are evaluated independently. For example, cost is evaluated first, and if cost is equal, bandwidth is evaluated. For example, if a Mobile Node has a 10-Mbps wireless LAN link, a 56-kbps cellular link, and a 128-kbps satellite link, the Mobile Node can adjust the metric so that cellular is preferred over satellite because of the associated cost of the satellite link.