Mobile IP Agent Discovery


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:

  • Router advertisement A beacon that is sent at a defined interval by a router. The advertisement is a way for the router to say, "Hey, I'm out here, and here's what I can offer." When supporting Mobile IP, a router sends a router advertisement that contains an extension advertising the specific Mobile IP services that it supports, for example, reverse tunneling. The router is now saying, "Hey, I am a Mobility Agent, and here's what I can offer." These advertisements are known as Mobile IP agent advertisements, and they are sent either through IP multicast or IP broadcast.

  • Router solicitation A message that is sent by a node requesting that routers who hear this message send out their router advertisements. A Mobile IP agent solicitation is the same as a router solicitation, except that the TTL of the packet is set to 1. By sending a Mobile IP agent solicitation, the Mobile Node is asking, "Hey, are any Mobility Agents out there?" Solicitations by a Mobile Node allow location discovery to occur more quickly than if the Mobile Node had to wait for the periodic agent advertisement. A Mobile Node can send a solicitation through either multicast or broadcast.

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:

  • Lifetime This is the maximum lifetime that the Mobility Agent can support a Mobile IP registration.

  • CoA(s) If the Mobility Agent is serving as a FA, this field specifies the Foreign Agent-Care-of Address (FA-CoA). Note that more than one advertised FA-CoA can exist.

  • R (Registration Required) This bit specifies that Mobile IP registration is required through this FA, regardless of whether the Mobile Node is using an FA-CoA or a CCoA.

  • B (Busy) This bit specifies that the FA is busy and cannot accept Mobile IP registrations from additional Mobile Nodes.

  • H (Home Agent) This bit specifies that the Mobility Agent offers service as a Home Agent.

  • F (FA) This bit specifies that the Mobility Agent offers service as a FA.

  • M (Minimal Encapsulation) This agent supports receiving tunneled datagrams that use minimal encapsulation.

  • G (GRE Protocol) This agent supports receiving tunneled datagrams that use the generic routing encapsulation (GRE) protocol.

  • T (Reverse Tunneling) This bit specifies that the FA supports reverse tunneling. Reverse tunneling is described in Chapter 6, "Metro Mobility: Client-Based Mobile IP."

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:

  • Destination Address Advertisements must be sent to either the limited broadcast address (255.255.255.255) or the all-systems multicast address (224.0.0.1). Responses to solicitations can be either unicast to the Mobile Node or can be sent as a broadcast/multicast.

  • TTL Must always be set to 1, because the FA must be on the same link as the Mobile Node and the advertisement must not be forwarded to another link.

Here are the descriptions of the fields in the ICMP Header:

  • Type Type 9 is used for agent advertisements, and Type 10 is used for agent solicitations.

  • Code The code can either be 0 if the advertising agent is a fully capable router or 16 if it is only to be used as a Mobile IP agent.

  • Lifetime This is the maximum amount of time a Mobile Node should consider this agent as being reachable without hearing a new advertisement. The agent should send at least three advertisements during this window.

  • Router Address The router should list all the IP addresses that are configured on the interface from which the advertisement is being sent. These can be used as CoAs.

Here are the descriptions of the fields in the Mobility Advertisement Extension:

  • Type Type 16 is used for the Mobility Advertisement Extension.

  • Sequence Number This is a number that increases with each advertisement, starting at 0x0 after a reboot. When the maximum (0xFFFF) is reached, the agent begins with 0x00FF to distinguish a rollover from a reboot.

  • Registration Lifetime This is the maximum lifetime that the agent can accept in a registration.

  • Registration Required Flag The Mobile Node must register with a FA on this link, even if it wants to use a Colocated CoA.

  • Busy Flag When set, this FA is not currently accepting new registrations.

  • Home Agent Flag This agent offers Home Agent services.

  • FA Flag This agent offers FA services.

  • Minimal Encapsulation Flag This agent is capable of processing minimally encapsulated packets, as defined in RFC 2004.

  • GRE Flag This agent is capable of processing packets encapsulated with the GRE protocol, as defined in RFC 1701.

  • Reserved This originally specified Van Jacobson header compression support. This was removed in the second revision of the RFC because it was deemed unusable.

  • Reverse Tunnel This FA is capable of reverse tunneling.

  • CoA This is one or more IP addresses that the Mobile Node can use as its CoA if it registers through this FA.

Here are the descriptions of the fields in the Prefix Length Extension:

  • Type Type 19 is used for the prefix length extension.

  • Prefix Length Network prefix lengths are specified in order for each respective router address listed in the IRDP extension.

Here are the descriptions of the fields in the Challenge Extension:

  • Type Type 24 is used for the FA Challenge Extension.

  • Challenge This is a pseudorandom challenge that provides replay protection at the FA.

Location Discovery

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.

NOTE

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.

NOTE

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.

Steady-State 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.

Link-State Triggers

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.

NOTE

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.




    Mobile IP Technology and Applications
    Mobile IP Technology and Applications
    ISBN: 158705132X
    EAN: 2147483647
    Year: 2005
    Pages: 124

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net