Mobile IPv6 extensions to support nested mobile networks - CiteSeerX

7 downloads 2282 Views 647KB Size Report
Mobile IPv6 Extensions to support Nested Mobile Networks. ZhiJun Gu. LGE [email protected]. Dongmin Yang. POSTECH [email protected]. Cheeha Kim.
Mobile IPv6 Extensions to support Nested Mobile Networks ZhiJun Gu LGE [email protected]

Dongmin Yang POSTECH [email protected]

Abstract Unlike host mobility support, network mobility is concerned with situations where an entire network changes its point of attachment to the Internet. Furthermore, we should consider the situation of several mobile networks recursively attached together. The goal of network mobility support is to provide continuous and optimal Internet access to all nodes located in the mobile network. In this paper we present a solution to support nested network mobility by extending MIPv6. Note that the IETF MIPv6[2] protocol is for mobile nodes and not for mobile networks. The main idea is to register a prefix binding in HA and CN with a chain of intermediate mobile router’s (MR’s) care-of-addresses (CoAs). To the main idea, we introduce new option; The Nested Care-of-Address Option (NCO) is used to carry a sequence of MR’s CoAs in the header. The Router Alert Option (RAO) is used to indicate that NCO is set. When RAO is set, it is not necessary to encapsulate an outgoing packet. The HA and CN can use the addresses in its binding cache to construct a Type 2 Routing Header to send packets into the mobile network. This extension allows our scheme to give an optimal routing path, avoid the tunnel-in-tunnel problem, save the bandwidth resource and reduce the computation overhead in the home network.

1. Introduction In the last ten years, the computer industry has faced a huge evolution. The geographical mobility of people is increasing, which in turn, generates a need for more mobility. However, the Internet can hardly support perfectly this mobility request, because protocols used in the Internet are not conceived for devices that frequently change their point of attachment to the Internet. The aim of mobility support is to make mobile nodes keep connectivity without

Cheeha Kim POSTECH [email protected]

modification when roaming. The most important improvement in Mobile IPv6 (MIPv6) [2] is to provide a powerful and flexible optimization mechanism between a mobile node and a correspondent node by establishing a binding between a mobile node’s home address and its current CoA, which allows the correspondent node directly to send a packet to the new location of the mobile node. But MIPv6 cannot scale to handle the mobility of a network. Indeed, mobility support should be concerned with mobile hosts as well as the mobile networks. There are situations where an entire network moves and attaches to different places in the Internet. An airline or a train company may want to provide permanent on-board Internet access. In this case, airplane or train may be an example of mobile network. Some solutions were proposed in [3,4,5,6,7] to support network mobility. In the case of Nested Mobile Network (Mobile Network), these solutions suffer from the tunnel-in-tunnel and non-optimal routing problem. This can decrease the performance of the router and, consume more bandwidth and generate more traffic overhead. The IETF Network Mobility Work Group (NEMO) briefly proposes two approaches for supporting network mobility: Prefix Scope Binding Update (PSBU) [6], and Reverse Routing Header approach (RRH) [7]. The PSBU only can support single mobile network. In the Nested Mobile Network, this scheme cannot work well because the communication between CN and Nested MoNET will suffer from the tunnel in tunnel problem. On the other hand, RRH is dedicated to supporting Nested Mobile Network. The RRH is specified to reduce the encapsulation overhead which can be generated in the Nested MoNET. This scheme is based on the bi-direction tunnel between HA and MR. RRH can support Nested MoNET without suffering from the tunnel in tunnel problem. However, since every packet goes through the bi-direction tunnel between MR and HA, an optimal routing path does not exist, and the traffic congestion will be increased in the home link.

Proceedings of the 18th International Conference on Advanced Information Networking and Application (AINA’04) 0-7695-2051-0/04 $ 20.00 © 2004 IEEE

In this paper we present a solution to support nested network mobility by extending MIPv6. Note that the IETF MIPv6[2] protocol is for mobile nodes and not for mobile networks. The main idea is to register a prefix binding in HA and CN with a chain of intermediate mobile router’s (MR’s) care-of-addresses (CoAs). To the main idea, we introduce new option; The Nested Care-of-Address Option (NCO) is used to carry a sequence of MR’s CoAs in the header. The Router Alert Option (RAO), is used to indicate that NCO is set. When RAO is set, it is not necessary to encapsulate an outgoing packet. The HA and CN can use the addresses in its binding cache to construct a Type 2 Routing Header to send packets into the mobile network. The remainder is structured as follows. We present the proposed idea in section 2 to support Nested MoNET. In section 3, we evaluate the proposed protocol. Section 4 concludes the paper.

When HA and CN send packets to MoNET, using a binding cache, those packets are routed through an optimal routing path. Also, when packets are sent out of the Nested MoNET, using a RAO, we obtain an optimal routing.

2.1. Extensions Router Advertisement: We define a new bit “N” in the router advertisement to indicate that it can support Network Mobility. When a MR attaches to a new link and finds that its upper router supports network mobility, it should solicit its upper mobile router for a sequence of upper mobile router’s CoAs. Also if a MR receives this kind of solicitation, it should send back a chain of CoAs. Nested Care-of-Address Option (NCO): This is a Mobility Sub-Option added to the PSBU message in order to carry mobile router’s CoAs.

2. Proposed Protocol As mentioned in the previous section, PSBU and RRH protocols have some problems in supporting Nested MoNET. The first approach will suffer from the tunnel-in-tunnel problem and the second protocol has a non-optimal routing path. Before going any further, we should specify some constraints. First, the routing path between CN and MNN (nodes located in mobile network) should be optimal with a minimal signaling overhead. Second, the movement of mobile network should be transparent to MNN. Finally, the scheme should be scalable to the number of mobile networks. This proposed protocol is designed to solve problems with the previous two approaches. We want to find a solution to support Nested MoNET during the BU registration process. We propose to extend the PSBU message to carry sufficient topology information about the Nested MoNET to HA. The binding associates the Network Prefix with the mobile router’s CoA and a sequence of intermediated mobile router’s CoAs. The MoNET prefix identifies the home link within the Internet topology. All MNNs share the same IP prefix. All the mobile router’s CoAs are the intermediated hops when a packet routing into the MoNET. MR will send a PSBU message with a chain of CoAs when registering with HA and CN. After HA and CN receive this BU message, they can build a binding entry like this in their binding cache: MoNET prefix Æ a chain of intermediated MR’s CoA, MR’s CoA.

Router Alert Option (RAO): This option is used when MR encapsulates data out of the MoNET. It indicates that the mobile router need not to encapsulate it again and merely needs to replace the source address with its CoA. If there is no RAO in the IPv6 header, an MR must encapsulate the packet to avoid ingress filtering. Since the RAO has been defined already in [8], we can apply new values used in our scheme. Type 2 Routing Header (RH2): We extend this routing header in MIPv6 to carry multiple hops. HA and CN should use a binding cache to construct it, to route packets into the Nested MoNET. Mobile IPv6 Extension: The MIPv6 protocol has to be extended to operate those two new options specified previously. We also need to extend CN’s capability of de-capsulation.

2.2. Protocol Operation A. Initialization. When a MR moves into a new link, it constructs a new CoA and, it solicits its upper mobile router for the upper mobile router’s CoAs (a chain of CoAs). When the MR sends a PSBU datagram to its HA, the datagram contains an option with MoNET’s prefix, an NCO including CoAs, a RAO, and a Home Address Option with MR’s home address (Figure 1). MR2 replaces the source address with MR2.CoA and forwards to MR1.HA instead of encapsulation because of RAO in the header. Then, HA replaces the source

Proceedings of the 18th International Conference on Advanced Information Networking and Application (AINA’04) 0-7695-2051-0/04 $ 20.00 © 2004 IEEE

address using the address in HAO and checks a security. If success, HA builds a PSBU with two addresses: MR1’s Prefix -> MR2.CoA, MR1.CoA.

HA2 CN

HA1

Internet

IPv6 Hdr (src=MR1.CoA, dst=MR1.HA) Hop-by-Hop Opt: Router Alert Option Dst Opt: HAO(MR1.HoA) AH/ESP Mobility Hdr: BU option(MR1’s Network prefix) Nested CoA option(MR2.CoA, MR1.CoA)

Prefix1 -> MR2 coa MR1.coa

MR2 coa AP MoNET2 MR1 coa

MoNET1 LFN

Figure 1. BU from MR1 to HA1

B. MR Operation. Receiving an incoming packet with a type 2 routing header, MR operates like a normal router, and switches the destination to next hop. If the packet is tunneled from its HA, MR should send a PSBU to the original source node, including the NCO. Receiving an outgoing packet with RAO in the header, MR merely overwrites the source address with its CoA and forwards it to the next router. If the packet has no RAO, MR must encapsulate it, set the source address to its CoA and, insert a RAO into the outer header. After this process, MR continues to forward this packet to the next router (Figure 2). Since the data from LFN must be encapsulated to avoid the ingress filtering, CN must have the capability to decapsulate.

Figure 3. First Datagram transits via HA into MoNET1.

C. CN Operation. If CN wants to communication with LFN, the first datagram will be intercepted by HA1 and tunneled to MR1 using RH2. MR1 decapsulates it and forwards the inner data to LFN (Figure 3). Since this packet is tunneled from HA1, MR1 should register its prefix to CN, the same as with HA1. Sending other packets to LFN, CN checks its binding cache and understands that this address belongs to MoNET’s prefix. Those packets should be routed via several CoAs. So, those subsequent packets are sent to LFN via MR2.coa, MR1.coa using RH2 (Figure 4). HA2 CN

HA2 CN HA1

Internet MR2 HA1

Internet

Prefix1 -> MR2 coa MR1.coa

MR2 coa

Prefix1 -> MR2 coa MR1.coa

MR2 coa

AP MoNET2 MR1 coa

AP MoNET2

MoNET1 LFN

MR1 coa MoNET1 LFN

Figure 2. MR1 encapsulates outgoing Data, and inserts RAO in the header. MR2 replaces the source address with its own CoA.

Figure 4. Optimal Routing Between CN and LFN

3. Evaluation According to those operations, we believe that our solution is well adapted in supporting Nested MoNET.

Proceedings of the 18th International Conference on Advanced Information Networking and Application (AINA’04) 0-7695-2051-0/04 $ 20.00 © 2004 IEEE

The sequence of mobile router’s CoAs ensures an optimal routing between CN and MoNET.

So we can say our solution can support Nested MoNET well if the mobility frequency of a mobile network is low.

3.1. Advantages First, we allow an MR to register a chain of CoAs with its HA and CN in the registration process. This can save on registration time compared with RRH, since it needs another scheme to finish registration process first. Second, we can obtain the optimal routing in the outgoing direction through the RAO, obtain optimal routing in the incoming direction through RH2. In our protocol, there is no tunnel in tunnel problem. Third, communication between CN and MoNET can have an optimal routing without passing through home link. This can alleviate the failure affection of home link to MoNET, reduce the computation overhead in HA side.

3.2. Drawbacks Our solution requires extensions at CN. CN must have the capability of de-capsulation. Also, we add two new options, Nested Care-of-Address Option and Router Alert Option, for our scheme. These options will add some signaling overhead to the registration process. Sine the MIPv6 protocol is still under researched, these drawbacks should be limited. A most important drawback is if the number of CN is great the signaling overhead will be too large for a rapid moving network. Our scheme only can be used in a slow mobility situation.

4. Conclusions

References [1] Cizault, “IPv6”, Editions O’Reilly, 2nd edition, 1999. [2] David B.Johnson, Charles E.Perkins, Jari Arkko, “Mobility Support in IPv6”, IETF Internet Draft, draft-ietfmobileip-ipv6-19.txt, 29 Oct 2002, Work in progress. [3] Thierry ERNST, “Network Mobility Support in IPv6”, Doctor Thesis, University Joseph Fourier, Department of Mathematics and Computer Science, France, 29th, October,2001. [4] Raihan Al-Ekram, “A Mobile IPv6 Extension to Suport Total Mobility in the Internet”, 5th, December, 2001. [5] Thierry Ernst, “Extending Mobile IPv6 with Multicast to support Mobile Networks in IPv6”, In IP based Celluar Network conference (IPCN), Paris La Defense, France, May 2000. [6] Thierry Ernst, Ludovic Bellier, Alexis Olivereau, Claude Castelluccia and Hong-Yon Lach, “Mobile Networks Support in Mobile IPv6 (Prefix Scope Binding Updates)”, IETF Internet Draft, draft-ernst-mobileip-v6-network-03.txt, March 2002, Work in progress. [7] P.Thubert, M.Molteni, “IPv6 Reverse Routing Header and its application to Mobile Networks”, IETF Draft, draftthubert-nemo-reverse-routing-header-01.txt, October, 2002. [8] Hidetoshi Yokota, Akira Idoue, Toru Hasegawa, Toshihiko Kato, “Link Layer Assisted Mobile IP Fast Handoff Method over Wireless LAN Networks”, MOBICOM’02, September, 2002.

In this paper, we have discussed the MIPv6 ability in supporting mobile networks. We describe PSBU and RRH two approaches. PSBU can support a single mobile network well but, in the Nested MoNET case, there is a tunnel in tunnel problem. In RRH, there is a non-optimal routing problem. RRH only can be used after MR finishing the registration process. Finally, we propose our solution in supporting Nested MoNET. The key idea is to register a chain of intermediated mobile router’s CoA with HA and CN when sending a PSBU message. HA and CN can obtain a map of the topology in the Nested MoNET. So they can construct a routing header to route packet into Nested MoNET in an optimal way. The second idea is to use a Router Alert Option. With this option, we can obtain an optimal routing in the outgoing direction. MR will not encapsulate the outgoing packet if a RAO existed in the IPv6 header.

Proceedings of the 18th International Conference on Advanced Information Networking and Application (AINA’04) 0-7695-2051-0/04 $ 20.00 © 2004 IEEE