In Mobile IPv6, MN is able to retain all existing connections while moving and

Transcription

1 Chapter 3 Model for Mobility of Correspondent Node in Mobile IPv6 In Mobile IPv6, MN is able to retain all existing connections while moving and communicating with en. It has been observed in the literature that the functioning and implementation of Mobile IPv6 is based on static en. Unless the mobility of en is included, Mobile IPv6 would not be a complete mobility solution.. In this chapter, two additional mobility combinations due to mobility of en have been proposed and mobility header, binding update list and type 2 routing header of Mobile IPv6 protocol are modified. New procedures like reverse return routability procedure, mobile registration and correspondent tunneling are also presented. The performance of these two new mobility combinations have been compared with,mobile IP and it is found that one of the combination performs similar to Mobile IPv6. 65

2 3.1 Introduction The inclusion ~f mobility of CN will require several changes in Mobile IPv6. These changes will add complexity to the Mobile IPv6 protocol. It is therefore necessary to simulate the Mobil~ IPv6 protocol with CN mobility features. We have used OMNeT++ for simulation and for evaluation of the performance of mobility options. 3.2 Mobility Options While considering the mobility support to IPv6 only the mobility of MN has been discussed. We propose other possible combinations of mobility by adding the mobility of CN in order to get the complete mobility. There are four different cases, in which mobility ofmn and CN is possible. Case I - MN and CN are stationary Case II - MN is mobile and CN is stationary Case III - MN is stationary (restricted to its home network) and CN is mobile Case IV - MN and CN are mobile First two combinations are already existing and being widely discussed in the literature. Last two combinations have been proposed by us [119] and these are being discussed in this chapter Case I - When mobile node and correspondent node are stationary This is most prevalent case, in which MN (with the inherent capability of being mobile) is restricted to its home network or not mobile at all i.e. stationary. Similarly CN is stationed at one place. In this case neither of the nodes use any form of mobility and thus packets are routed from source to destination using conventional TCP/IP protocols 66

3 without using any mobility support. In TCPIIP based network like Internet, routing is based on a stationary IP address [121, 154] Case II - When mobile node is mobile and correspondent node is stationary In this case, mobility support [124, 125, 134, 143, 180] has been provided through Mobile IPv4 [38] for IPv4 based networks. Mobile IPv6 [44] has been standardized for IPv6 based networks and mobility has been integrated in IPv6 as header extensions [11] Case III - When correspondent node is mobile and mobile node is stationary In the above two cases, CN was stationary. In this case, CN is mobile and communicates with a MN that is stationary or restricted to its home network as shown in figure 3.1. The CN is initially connected to its home network and later on it has gone beyond its home Home network mobile node Home network of mobile correspondent node Visited IPv6 Internet Figure 3.1: General scenario ofmipv6 when correspondent node is mobile network to a visiting IPv6 network. We are using subscripts to differentiate processes 67

4 related to mobility of MN and MCN, like binding update for MN and MCN has been written as BUMN and BUCN. The mobile CN stores all the binding information in a new data structure called binding update list (BUL cn ). Whenever MCN crosses boundary, it " sends binding updates (BUCN) to HAcN and home agent ofmn (HAMN) so that MCN can continue sending or receiving packet to and from MN (stationary or restricted to its home network). A new procedure called 3RP is performed in this case which ensures that MCN is present at its claimed position. Typical scenario of interaction between MN and CN in this case is shown in figure 3.2. The algorithm with sequence of interactions is as follows. 1. MN (located in its home) starts sending packets to the CN at its home address as it is connected to its home only. CN has ~ot yet started moving so all the packets are delivered to CN through its home agent. 2. en starts moving and starts losing connection to its current HA (access router) or otherwise determines that it should switch over to another access router. 3. It reaches in foreign area and uses IPv6 neighbors discovery protocol. CN listens < to router advertisements and uses this information to determine that it has reached to a new link. 4. Now mobile CN needs to acquire a CoA so that it can communicate with MN. Stateless address configuration protocol or stateful protocol such as dynamic host configuration protocol version 6 (DHCPv6) can be used by MCN depending on the availability. a. In case of stateless address auto configuration p~otocol, the address prefix of router advertisement message is combined with a locally generated interface identifier to generate tentative global address by MCN. 68

5 b. DHCPv6 - ifused immediately responds with an address. 5. MCN updates its HA with new CoA using BU message ancl expects a BA from HA cn. M N HAMN Foreign Area CN HAcN MCN Link Down --" J-inkup ~ ~HCP Request -., Router Advertisement DHCP Response Binding Update Binding Acknowledgement ""-.... '~ "mu <.-«t COTi cn HOTi CN Q ~,HOT CN ",jw ~ 0 c==:>,",*,jg"\.. COT CN Binding Update " Binding Acknowledgemen --" 1/1 J~ DATA TRANSFER I~ V ~ Figure 3.2: Operations performed when only CN is mobile 6. Mobile registration is used by MCN to provide informatipn about its current location to MN. 3R procedure is performed as a part of this registration that enables the MN to obtain some reasonable assurance that MCN is in fact addressable as its claimed CoA as well as at its home address. 7. The MCN initiates the 3RP by sending two messages to the MN simultaneously. a. One of the messages home test in it (HOTi cn ) of 3RP is tunneled through 69

6 HA cn. It is sent through normal routing to HAMN which will deliver this HOTi cn to MN as MN is available within its home network. b. Care-oftest init (COTicN) is sent directly to MN. 8. One of responses, home test (HOT CN) is received from MN through tunnel from HAcN and other response (COT CN ) is received directly from MN. 9. After the 3RP has been completed, MCN can send actual BU message to the MN. 10. MN will accept BU only after above assurance and then sends its packets to COA CN. 11. MN should now update its BUL. 12. MN can now send packets directly to MCN at its CoA. MCN can also send packets directly to MN using type 2 routing header. It is possible that a node can take two different roles i.e. at one time, it is acting as a MN, when it is mobile and initiates communication with its CN. Other tirtle its role is changed in the sense that some other node is communicating with it and its role is that of a CN. Because it is acting as a CN, it processes mobile registration Case IV - When mobile node and correspondent node are mobile This is the most complicated case when MN and CN are mobile and have gone beyond their home networks. The MN has crossed its home area and CN has also moved to IPv6 subnet. This scenario has been shown in figure 3.3. Both of these moving nodes are required to register their CoAs with their respective HAs and to each other. 3RP is also used in this case but the HOTi cn and HOT CN are double tunneled from HAs of MCN and MN. When MN is mobile, it performs correspondent registration and when CN is mobile, it performs mobile registration. Now we take the case when MN has started moving and communicating with a stationary CN. Later on while the communication is going on, CN also starts moving. 70

7 Home network of mobile node Home network of mobile correspondent node d..,.,--. ~rf~,j;~«:t q.~~1jly1obil~.en.. ',ji.;;. Visited IPv6 Internet Figure 3.3: General scenario ofmipv6 when correspondent node and mobile node are mobile In this situation, both nodes are mobile and communicating. The algorithm for interactions among different entities is shown in figure 3.4 and the steps are given below: 1. MN starts moving and losing connection to its current HA and gets a new CoA. BU and BA are exchanged to update HA of MN. MN uses correspondent registration to provide information about its current location to CN. RRP is performed as a part of this registration. After exchanging BU and BA messages, MN and CN communicate with each other. 2. Now CN starts moving and starts losing connection to its current HA or access router or otherwise determines that it should switch over to another access router. 3. It reaches in foreign area and uses IPv6 neighbor discovery protocol. The CN listens to router advertisements and uses this information to determine that it has reached to a new link. 71

8 4. The MCN needs to acquire a CoA so that it can communicate with MN. Stateless address configuration protocol or DHCPv6 can be used by MCN depending on the availability. Foreign Area MN MN HA,.N Link Down Foreign Area en MCN Linkup Router Advertisem<:..nt DHCP Request DHCP Response c=='c:> CI-H_O_T.-",~N" i~1 COT~N Ir--'-":-:-~_-_-~~-J~ (~~HO_T_MN ~ /L--_--' 'I ----,---_L-- ~ "- / DATA TRANSFER ~,I 1,'/~-L-ink-D-ow-n i~ Linkup Route Advertisement DHCP Request DHCP Response :_r...:> I~ ~ H_O_~~N~-,-,~=~,_-,-,I \1, //----~------~------~--~I~ DATA TRANSFER ~// Figure 3.4 Operations performed when MN is mobile and CN is also mobile 5. Now MCN updates its HA with new address using BU and expects a BA from HA cn. 6. Mobile registration is used by MCN to provide information about its current location to MN. 7. 3R procedure is performed as a part of this registration. 3RP in this case works differently from the earlier case. In this case, HOTi cn and HOT CN are doubly tunneled through HA ofmn and MCN. 72

9 8. The MCN sends two messages to the MN simultaneously. 9. One of the messages HOTicN of 3RP is double tunneled through HA of MN and MCN. Initially it is tunneled from MCN to HAcN. From where it is sent through normal routing to HAMN which will tunnel this HOTicN to MN at its CoA. 10. COTicN is sent directly to MN. 11. One of responses HOT CN is received from MN through double tunnel. From COA MN, HOT CN is tunneled to HAMN. From where it is sent through normal routing to HAcN which will tunnel this HOT CN to MCN at its CoA. 12. Other response COTCN is received directly from MN. 13. After 3RP has been completed, CN can send actual binding update message to MN. 14. MN will accept binding updates from MCN only after the above assurance and then sends its packets to COACN. MN should now update its BUL. 15. MCN and MN can now communicate and transfer data. All the messages related to bindings are sent through mobility header (MH) or modified mobility header that is an extension header. Mobility header is used by any MN and also by home agents. Since, we are proposing that corresponding node can also be mobile, it is necessary to modify the MH. 3.3 Changes in Mobility Header The mobility of CN requires modification in the format of MH by. addition of a single flag bit (C) to indicate that the CN is mobile. This reduces the number of reserved bits from 16 bits to 15 bits over that originally specified for MH as shown in figure 3.5. The meaning of other fields in header remains as it is except MH type field which represents that these messages are to or from MCN. 73

10 Pay Load Proto I Checksum Header Length MH Type 1~~~ls Reserved Message Data Figure 3.5: Modified Mobility Header The setting of mobility of CN (C) bit affects the messages, which are described below. These messages are subscripted by CN to indicate that this bit is set: 1. Modified binding refresh request message: When MH type value is 0 and C bit is set, it indicates binding refresh requestcn. This message is sent by MN to request MCN to update its mobility bindings. 2. Modified home test init message: When MH type value is 1 and C bit is set, it indicates home test initcn (HOTiCN). MCN uses HOTiCN message to initiate 3RP and to request home keygen token from a MN. 3. Modified care-of test init message: When MH type value is 2 and C bit is set, it indicates care-of test initcn (COTiCN)' MCN uses COTicN message to initiate 3RP and to request care-ofkeygen token from a MN. 4. Modified home test message: When MH type value is 3 and C bit is set, it indicates home test (HOTcN). MN uses HOTcN message in giving response to HOTiCN message of MCN. This message contains home nonce index, home keygen. token from a MN and home init cookie as sent by MCN. 5. Modified care-of test message: When MH type value is 4 and C bit is set, it indicates care-of testcn (COTcN). MN uses COTcN in response to COTicN message of MCN. This message contains care-of nonce index, care-of keygen token only from MN and care-ofinit cookie as sent by MCN. 6. Modified binding update message: When MH type value is 5 and C bit is set, it 74

11 indicates binding updatecn (BUCNJ. This message is used by MCN to notify other nodes of a new CoA for itself. This message contains sequence, request for acknowledgement, lifetime value and several other flags. 7. Modified binding acknowledgement message: When MH type value is 6 and above C bit is set, it indicates binding acknowledgementcn (BAcNJ. This message is used to acknowledge receipt of a BUCN. This message contains sequence, lifetime value, key management, mobility flag and status information. 8. Modified binding error message: When MH type value is 7 and C bit is set it indicates binding errorcn (BEcNJ.This message is used by MN to signal an error related to mobility such as inappropriate attempt to use home address destination option without an existing binding. 3.4 Reverse Return Routability Procedure When MN is communicating with a mobile en, it needs to assure that MCN is addressable at its claimed CoA and its home address. MN uses 3RP get this assurance. After this assurance MN is able to accept BUs from MCN and it will direct all the data traffic for MCN to its claimed CoA. In 3RP, we are using following parameters used by ~ that was used when the mobility of only MN was being considered. The integrity and authenticity of the BU messages to CN are protected by a keyed... hash algorithm. The binding management key (Kbm) is used to key the hash algorithm for this purpose. Kbm is established using data exchanged during the RRP. The data exchange is accomplished by use of node keys, nonces, cookies, tokens, and certain cryptographic functions. Each CN has a secret key (a random number of20 octets), called the node key, which it uses to produce the keygen tokens sent to the MNs. The node key allows the CN to verify that the keygen tokens used by the MN in authorizing a BU are indeed i~., own. Each CN also 75

12 generates nonces at regular intervals using a random number generator. The home init cookie and care-of init cookie are 64 bit values sent to CN from MN, and later returned to MN. The home init cookie is sent in the home test initmessage, and returned in the home test message. The care-of init cookie is sent in the care-of test init message, and returned in the care-of test message. The home keygen token and c;are-of keygen token are 64-bit values sent by the CN to the MN via HA (using home test message) and CoA (using care-oftest message), respectively. The following four messages are used in 3RP. 1. Home Test InitcN (HOTicN): A MCN sends a this message to MN to acquire the home keygen token. This message conveys the home address ofmcn to MN. The MCN also sends along a home init cookie that the MN must return later. The MCN remembers these cookie values to obtain some assurance that its protocol, messages are being processed by the desired MN. The contents ofthis message are summarized below: * Source address = home addresscn * Destination address = COAMN * Parameters: home init cookie 2. Care-of Test InitcN (COTicN): The MCN sends this message to MN to acquire the careof keygen token. This message conveys the CoA of MCN to MN. The MCN also sends along a care-of init cookie that the MN must return later. The contents of COTtCN are summari~ed below: * Source address = COACN * Destination address = COAMN * Parameters: care-of init cookie 3. Home TestcN (HOTcNJ: This message is sent in response to a HOTtCN message. When MN receives HOTicN message, it generates a home keygen token which is formed from the first 64 bits of the MAC. The home keygen token tests that MCN can receive messages sent to its home address. The home init cookie from th~ MCN is returned in the HOTcN message, to ensure that message comes from a node on the route between 76

13 HAcN and MN. The contents of HOTcN message are: * Source address = COAMN * Destination address = home addresscn * Parameters: home init cookie, home keygen token, home nonce index 4. Care-of Test CN (COT cn ): This message is sent in response to,a care-of test initcn message. This message is not sent via HA but directly to MCN. When MN receives COTiCN message, it generates a care-of keygen token. The keygen token is formed from the first 64 bits of MAC address, and sent directly to MCN at its CoA. The care-of init cookie from COTiCN message is returned to ensure that the message comes from a node on route to the MN. The contents of the message are: * Source Address = COAMN * Destination Address = COAcN * Parameters: care-of init cookie, care-of keygen token, care-of nonce index When CN starts moving and changes its location, it uses 3RP to update the MN and its HA. In the beginning of procedure, MCN sends two messages (HOTiCN and COTicN) to MN simultaneously. These messages carry home address and CoA of MCN. MN finds out about the movement of CN from the value of C bit of MH. MN replies by sending HOTcN and COTcN messages with keygen tokens to MCN at its home address and CoA. These data are combined by the MCN into a binding management key. 3RP is different for above mentioned case III (in which MN is restricted to its home network and CN is mobile) and case IV (in which MN and MCN are mobile). In case III, destination address in HOTiCN and COTicN will be HAMN but for HOTcN and COTcN messages, source address will be HA MN. In case IV, destination address in HOTiCN and COTiCN will be COAMN but for HOTcN and COTcN messages, source address will be COAMN. HOTiCN, message is doubled tunneled (only in case IV) i.e. sent via HAcN and HAMN to MN. The care-of test initcn message is sent directly not via HAs to MN. The home testcn message is sent to MCN via HAMN and HAcN in case IV. It is also necessary that home address 77

14 option be used by MN to give its home address to MCN, so that HOTicN is sent by MCN through HAcN and HAMN to MN later on. Algorithm MCN initiates 3RP by sending HOTiCN and COTicN in parallel to home address and CoA of MN, respectively. The difference in HOTi and HOTicN is that the later is sent by MCN to MN with a specific bit set in mobility header to indicate that this HOTicN message is initiated by MCN. 1. For sendinghoticn, MCN ensures that C bit is set in MH and MH type value set to 1 along with home init cookie. Source address is set to home address of MCN and destination address is set to the home address of MN for case III and CoA of MN for case IV. 2. For sending COTicN, MCN ensures that C bit is set in MH and MH type value set to 2 along with care of init cookie. Source address is set to CoA of MCN and destination address is set to home address ofmn for case III and CoA ofmn for case IV. 3. BUL is updated with the IP address ofmn to which message wa's sent, home address of MCN (source address field of HOTiCN), time when HOTicN and COTiCN messages were sent and cookie used in HOTiCN and COTiCN messages. 4. In case III, HOTiCN is tunneled through HAcN and sent to MN which is either stationary or restricted to its home network. In case IV, HOTicN is doubled tunneled i.e. sent via HAcN and HAMN to MN. In case IV before sending HOTicN to MN, MCN is required to have the address of HAMN so that it can send packet to MN. 5. COTiCN is sent directly to CoA ofmn using modified type 2 routing header in both of the cases. Once HOTicN and COTicN have been sent, MCN waits for reply in the form of HOTcNand COTcN. 6. On receiving HOTcN, MCN ensures the following conditions in HOTcN message: 78

15 a) That the source address of packet belongs to MN with details in BUL and no home key gen tokens received so far. b) That the destination address is the home address of MCN and packet is received via tunnel from HA. c) That home init cookie matches with what is stored in BUL. If above conditions are satisfied, MCN records home nonce index and home keygen tokens in BUL else it discards packets silently. MCN also ensures above conditions for COTcN message. When MCN has received both the HOTcN and COTcN messages, 3R procedure is complete. As a result of 3RP, MCN has the required data so that MCN can send a BUCNto MN. 3.5 Mobile Registration This process involves authorization of BUcNfrom MCN and BAcNfrom MN after the 3R procedure. To authorize abu, MCN hashes tokens together to form a 20 octet kbm as described above. Binding Update: The contents of the BU include the source address as the address of MCN (COAcN), destination address as the address of MN (COAMN) and parameters like home address, sequence number, home nonce index, and care-of nonce index. Once the MN has verified the MAC, it can create a BUL entry for the MCN. BUs may also be sent to delete a previously estabiished binding. In this case, generation of the binding management key depends exclusively on the home keygen token and the care-of nonce index is ignored. Binding Acknowledgement: The contents of BA message include source address as the address of MN (COA MN), destination address as the address of MCN (COA cn) and sequence number as the. parameter. The BAcN contains the same sequence number as the 79

16 BUeN. Whenever CN is mobile, it informs MN and its HA about its current location. This updating of mobility information ensures continued communication with MN. Each of MCN maintains a data structure (BUL) where all the information related to bindings and mobility is stored. 3.6 Binding Update List All the bindings are stored and maintained in BUL so that whenever there is a reference, these can be used. Every MCN maintains a BUL. All the information about valid BU which are sent by MCNto its HA or MN, is maintained in BUL. It also contains BUs which are waiting for completion of 3RP. If several BUs have been sent to same destination, the most recent BU is kept in BUL. It also keeps track of all of BUs received from other MNs. It is referred by MCN for sending the packets directly to MN or vice versa. Each BUL entry contains the following fields: 1. The IP address of the node (mobile or HA) to which a BU was sent. 2. The home address for which that BU was sent. 3. The CoA of MCN which is sent in the BU. This value is necessary for MCN to determine if it has sent a BU giving its new CoA to this destination after changing its CoA. 4. The initial value of the lifetime field sent in the binding update. 5. The remaining lifetime of the binding. This lifetime is initialized from the lifetime value sent in BU and is decremented until it reaches zero, at which time this entry is deleted from BUL. 6. The maximum value of sequence number (16 bits) sent in previous BUs to this destination. 80

17 7. The time at which a BU was last sent to this destination. 8. The state of any retransmissions needed for this BU. This state includes the time remaining until the next retransmission attempt for the BU, and the current state of the exponential back-off mechanism for retransmissions. 9. A flag specifying whether or not future BUs be sent to this destination. The MCN sets this flag in BUL entry when it receives an ICMP parameter problem., 10. A flag defining the role of node either MN or MCN. Depending on this bit, the node will maintain BUL or BULcN. In addition to above fields, BUL also contains following data related to running the 3RP. This data is relevant only for BUs sent to MN. 11. The time at which a HOTiCN and COTiCN messages were last sent to this destination (MN). 12. The state of any retransmissions needed for 3RP. 13. Cookie values used in the HOTiCN and COTicN messages. 14. Home and care-ofkeygen tokens received from the MN. 15. Home and care-of nonce indices received from the MN. 16. The time at which each of the tokens and nonces were received from this MN. 3.7 Modified Type 2 Routing Header Type 2 routing header allows a packet to be routed directly from a CN to the CoA of MN. To reflect the mobility ofcn, type 2 routing header is modified by setting mobility ofcn (M) bit from the reserved bits as shown in figure 3.6. Setting ofm bit allows the packet to be routed directly from a MN to CoA of MCN. These modifications also enable firewalls to apply different rules to source routed packets. The COA CN is inserted in the IPv6 destination address field. 81

18 j Next Header I Hdr Extn Len = 2 I Routing Type = 2 I M~4 Resefiled ~,.,>.:~ ~ Segment Left = 1 Home Address, Figure 3.6 Modified Type 2 Routing header Once the packet arrives at the COA CN, MCN retrieves its home address from the routing header and this is used as the final destination address for the packet. Reserved field is reduced from 32 bits field to 31 bits field to account for the addition of M bit. All the ICMP messages like home address discovery request message, home address discovery reply message, mobile prefix solicitation message and mobile prefix advertisement message can also be used by MCN without any change. Once necessary binding messages have been exchanged between MN and CN, they can send and receive packets directly and efficiently. If bindings are not updated, packets will be received and sent through HAs. This method is not as efficient as earlier case, but allows the data transfer to take place even if nodes have changed their location. 3.8 Communication between Mobile Node and Correspondent Node Communication can take place in the form of data transfer between MN and CN. A CN can send and receive packets from MN. When nodes have updated their bindings, packets are transferred reliably and efficiently using modified type 2 routing header. Packets sent or received by a MN that does not have a BUL entry for MCN, are sent to the home address, captured by HA and tunneled (either single or double side depending 82

19 on the case III or case IV) to or from MCN Sending Packets For packets sent by a MN while CN is at home, no special processing is required. This data transfer relates to the general case of Mobile IPv6 which is represented as the case II in section For packets sent by the MCN while away from home and using the home address of MCN as the source, special processing of packets is done. This is done in two ways i.e. route optimization and correspondent tunneling. I Route Optimization This method of sending packets is faster and enables more reliable transmission. It is used in case III and case IV (section 3.2). Packets are delivered directly to the MN at its CoA without going through the home network. The MCN ensures that there exists a BUL entry for its home address so that MN can process the packet. The MCN examines its BUL for an entry which fulfills following conditions: The source address field of the packet being sent is equal to the home address in the entry. The destination address field of the packet being sent is equal to CoA of MN in the entry. One of the current CoA of the MCN appears as the CoA in the BUL ofmn. The BUL entry indicates that a binding has been successfully created.. The remaining lifetime of the binding is greater than zero. When these conditions are met, the MCN knows that the MN has ~,suitable BUL entry. As the packet is being sent by MCN directly to MN, it uses modified type 2 routing header with M bit set. MCN supplies the home address in a home address option, and sets the source address field of IPv6 header to CoA which the MCN has registered for 83

20 use with this MN. The MN then uses the address supplied in the home address option to send packets directly to MCN. The home address of MCN is then supplied to higher protocol layers and applications Correspondent Tunneling In this method, packets ~re tunneled through the home agent. It is not as efficient as the above mechanism, but it is needed if there is no binding yet with the MN or bindings are not updated. The steps required depending on the mobility ofmn and CN, are explained below. There are two variations of correspondent tunneling i.e. single side correspondent tunneling and double side correspondent tunneling as shown in figure 3.7. Single Side Correspondent Tunneling: It is used in the case III (section 3.2.3) when CN is mobile and MN is restricted to its home network. This method is used for packets that have the home address ofmcn as source address in IPv6 header. The packets are sent to HA of MCN using IPv6 encapsulation. The source address in the tunnelled packets is the primary CoA as registered with HA. The destination address in the'tunnelled packets is the address of HA of MCN. The HA then passes the encapsulated packets to the MN in its home network. Double Side Correspondent Tunneling: When MN and MCN are mobile (case IV in section 3.2.4), packets from MCN are sent through HA of MCN and MN. Packets from MCN travel through two tunnels. The first tunnel is created from MCN to HAcN and second tunnel is created from HAMN to MN. The packets are initially sent to HA ofmcn using IPv6 encapsulation. The source address in the tunneled packets is the primary CoA as registered with the HA. The destination address in the tunnelled packets is the address ofha of MCN. Packets from HAcNto HAMN are sent normally. The HA at receiving end intercepts the packets destined to MN and encapsulates them. These packets are 84

21 ultimately tunneled to CoA ofmn. MN Receiving c:>cf>d Packets Dc:) D ~------, Packets Figure 3.7 : Data Trans ers in Case III and Case I using Single and Double side correspondent Tunneling Receiving Packets When CN is mobile, it receives packets addressed to it using anyone of the two methods depending on the BUL entry as shown in figure 3.7. In case MN has a BUL entry for MCN and contains its current CoA, MN sends packets by using modified type 2 routing header. The packets are addressed to CoA of MCN with final hop in routing header directing the packets to the home address of MN. In case MN has no entry for MCN in BUL, the packets are sent to the home address of MCN. Theses packets are captured by the HA ofcn and tunneled to the CN that checks that the IPv6 source address of the tunneled packet is the IP address of its HA. In this 85

22 case, the MCN also sends a BU to the original sender of the packet. " 3.9 Simulation Architecture The OMNet ++, an object-oriented module discrete event simulator [78] has been used to simulate mobility of correspondent node. The goal of simulation is to examine the effect of mobility of correspondent node on end to end UDP communication session by. considering signaling overheads, rate of successful packet delivery and packet delay. UDP constant bit rate (CBR) sources provide constant traffic where no acknowledgements are required. This kind of traffic is usually generated due to its deterministic characteristics, without recovery mechanisms. Standard OMNet ++ version 2.3p1 was patched with the freely available OMNet++ wireless extension module. A card running S02.11 protocol was simulated under OMNet++. This was further extended for our implementation of different messages and protocols because of mobility of. correspondent node. With the architecture of figure 3.S it is possible to simulate given three scenarios. Internet Figure 3.S Simulation scenario Designed simulation architecture is composed of HAs of MN,and MCN that are 86

23 connected to Internet. Movement of MN or CN across access routers (AR) will be communicated to HA and the mobile node at the other end. Three types of traffic are simulated. In first type, static CN is communicating with a MN which is initially positioned near its home network. Later on MNstarts to move in a different network. This is a typical mobile IPv6 scenario. We will call it baseline MIPv6 (BMIPv6). In second type, static MN is communicating with a mobile CN, we will call this case as correspondent node MIPv6 (NMIPv6). In this case, CN is initially attached to its home agent and later on starts moving in a different network. The difference from earlier case is that here CN instead of MN is mobile. In third type, MN and CN are mobile and they send packets to each other. Initially MN and CN are attached to their home networks. MN then starts moving and communicating with static CN which later on also starts moving and continues communication. This is an example of conwlete mobility using MIPv6 and we will call it complete MIPv6 (CMIPv6). In simulation, an access network has been assumed that allows MN and MCN to have access via radio interfaces only. Following features have been implemented for the simulation of above three scenarios. Firstly, binding cache and binding update list are added to original OMNet ++ node model. This provided all nodes with the binding update functionality, satisfying the requirement for all mobile IPv6 qualified nodes. Binding mechanisr;n was constructed as an IPv6 destination option, allowing MN to bind home address with CoA. Security mechanism has been implemented into the binding updates using RRP and 3R procedure. Secondly, changes in the mobility'header and type 2 routing header are made to incorporate mobility of correspondent node bit in OMNet++. New tunneling mechanism has been added for single side and double side correspondent tunneling. Figure 3.8 shows the network topology used for simulation experiment. The performance of mobility of correspondent node was evaluated by simulating the 87

24 necessary exchange of signaling messages between MN, HAs and MeN for figure 3.8. The distance between ARs is assumed to be varying from 200 meters to 800 meters. Speed is constant and equal for all MNs and MeNs. We assumes a well-behaved MN and MeN movement pattern where these nodes move linearly from one access router to another at a constant speed of 10 meter/second. Whenever a MN cr~sses a cell boundary and it receives router advertisement, it will perform handover process. For movement detection, the MNs use periodic router advertisement sent from ARs. Traffic from MN to en or all other is 512 Kb/second exponentially distributed flow with constant packetsize. Background traffic consists of 8, 64 Kb/seconds streams generated from static correspondent nodes to access routers. All simulations have duration of 600 seconds with a 5 seconds warm up phase Simulation Results Analysis Series of simulation results have been performed in measuring the signaling overheads, rate of successful packet delivery and packet delay in above mentioned three types of traffic. Signaling overhead is defined as the number of additional bits required in establishing a connection or data transfer during mobility. When MN changes its point of, attachment frequently due to its mobility, binding management messages are sent. Figure 3.9 shows the graph which has been plotted for signaling overhead with reference to the varying distance between ARs. In case of BMIPv6, en initiates communication with MN which has started moving and crossed several access routers. It can be seen from the graph that number of bits required for signaling decrease with the increase in distance between ARs as there will be less handoffs. Performance of NMIPv6 is almost similar to that ofbmipv6. Here static MN is communicating with a mobile en. As the number of bits required for signaling are same, result is almost same for these two cases. 88

25 _ 30 I/) Co ~ 25 - ~ 20 Q).c L- Q) 15 > o C) 10 c: n; c: 5.21 U) Distance (meters) -+-BMIPv6, ---NMIPv6 ~CMIPv6 Figure 3.9: Signaling overhead In case of CMIPv6, initially MN crosses several ARs due its mobility and later on en also crosses ARs. HOT, HOTi, COT, COTi and binding management messages are used from both MN and CN and it can be seen in the graph that signaling overheads increase tremendously here. Packets which are sent from source should reach destination. Rate of successful packets defines the percentage of packets which have been received successfully at destination. In figure 3.1 0, graph ofthe rate of successful packets delivered with respect to distance ~ 100 If)... Q) ~ u ro "S BMIPv6 -If) If) ---NMIPv6 Q) u 40 -.l,...-cmipv6 U ::J If) -0 Q)... ro ~ Distance (meters) Figure 3.10 Rate of successful packets 89

26 between ARs is drawn. In case of BMIPv6 and NMIPv6 the success rate of packet delivery is very low initially which later on increases on increasing the distance between ARs. In case of CMIPv6 the packet success rate is less than earlier cases as the MN and CN both are involved in handoffs even when data is transferred through single or double side tunnels. Packet delay is the difference of time when the packet was sent by correspondent node and received by a mobile node or vice versa. This delay when taken into consideration with number of handoffs per minute, can be caused as a result of movement detection and signaling for registration as shown in figure til -g 2.5 ~ 2 ~ iti' 1.5 Q) "C 1 ~ al 0.5 c.. o Number of Handoffs -+-BMIPv6 NMIPv6 -"-CMIPv6 Figure 3.11: Packet delay due to handoff Packet delay is experienced by nodes in BMIPV6 and NMIPv6 because tunnel is created when handoff occurs and packets are transferred through this tunnel from previous access router to new access router. In case of CMIPv6, packet delay is more as the double side tunnels are created and packets experience longer delays. 90

27 3.11 Pseudo Code for mobility of Correspondenti node Class MCN Binding Cache Address Home AddressMN Care of AddressMN Timing Lifetime value Numbers Sequence Number Flag Home Registration Mobile Registration Class MCN-Binding Update List Address Home AddressMN IP AddressCN Care of AddressMN Time Lifetime Remaining Lifetime Value Time when BU sent Time when HOTi, COTi sent Time when Cookie, Nonce accepted Numbers Sequence Number Cookie Value Home & COA Key Gen Tokens Nonce Flags State of Retransmission Retransmission for RRR procedure 91

28 Mobile en_sending packets 0 *This function is used by mobile correspondent node for sending packets while it is away from home * Do while packet sending = True if MCN at home = True {Send packets 0 If Binding Cache = True CN _Route Optimization 0 else CN_single Tunneling 0 *for case III* / CN _double Tunneling 0 *for case IY* Send packets 0 if packets part of Transport layer = True { Use home AddresscN else { use COACN Prepare and transmit packets en_single Tunneling 0 *This is used for case III* Tunnel packets to HACN Source address in packet = primary COACN Destination Address = HAcN send packets from HACN To HAMN HACN of sent packet = HAMN en_double Tunneling 0 *This is used for case IY* Tunnel packets to HAcN Source address in packet = primary COACN Destination Address = HACN HAcN of sent packet = HAMN Tunnel packets from HACN To COAMN Source address in packet = HAMN 92

29 Destination Address = COAMN CN_Route Optimization 0 Check BULcN If remaining time >0 { if source address of packet being sent = home address in BULcN and destination address = Care-of Address ofmn { if COACN = anyone of COA in BUL { packet Source Address = HAcN Insert Home Address Option (copy from original value of SA) MCN use modified type 2 routing header for sending packets Source Address of packet = COA ofmcn **MN sends packets directly to CoACN** Receive_packets_MCN 0 ifmcn home = True { Receive packets through usual IP routing at HA else if packet sent by MN _ cache entry = True { MN_sen(jJacket_ using modified type 2 Routing Header 0 else { Packet_sent by MN_No Cache entry case III 0 / Packet_sent by MN_No Cache entry case IVO Packets_sent by MN_no cache entry case III 0 ifip Address of tunneled packets = IP Address ofhacn MN sends packet to HAcN HACN Captures packet Tunnel to MCN at its current COA MCN send a BU to MN for Cache entry (original sender Mpacket) Packets_sent by MN_no cache entry case IV 0. ifip Address of tunneled packets = IP Address ofhacn 93

30 MN tunnels packets from current COA to HAMN Source address in packet = primary COAMN Destination Address = HAMN HAMN sends packets to HAcN HACN captures packets and Tunnels to MCN at its current COA Source address in packet = HACN Destination Address = primary COACN MCN send a BU to MN for Cache entry (original sender of packet) Packets_sent by MN using modified Type 2 Routing Header 0 MCN Checks Next Headers chain if length field = 2 & sequence_length_field = 1 { HA_Routing Header = home address of Any Node if Type 2 Routing Header = True and Mbit = True { Swap IPv6 destination field = HA - Routing Header Decrement segment left by one Resubmit packet to IP for processing Next Header Reverse Return Routability Procedure 0 *This procedure is used by mobile correspondent node * variable key gen tokens Record in BUL { IP address of the node HA ofmn (Source Address field of HOT i) Time when messages sent Cookies used in message send home test init case III 0 send home test init case IV 0 *different for case III & case IV* 94

31 send care-of test inito *same for case III and case IY* Receive_Horne_Test case III 0 Receive_Horne_Test case IY 0 *different for case III & case IY* Receive_Care_oetest 0 *same for case III and case IY*, Send home test init case III 0 MCN sends home test initcn to HAcN source address = COACN destination address = HAcN HACN captures packet HACN sends home test initcn to MN source address = Home addresscn destination address = COAMN parameter = home init cookie Send home test in it case IV 0 MCN sends home test initcn to HAcN source address = COACN destination address = HACN HACN captures packet HAcN sends Home test initcn to HAMN source address = HAcN destination address = HAMN HAMN sends Home test initcn to MN source address = HAMN destination address = COAMN parameters = home initi cookie Send care of test init 0 MCN sends care of test initcn to MN source address = COACN destination address = COAMN parameters = care of init cookie Receive care of test 0 Get packets from MN if source address of packet in BUL = care of address ofmn { if care ofkeygen token = not nil { if destination address of packet = COACN { if care of init cookie in BUL = care of cookie 95

32 { store care of nonce Index in BUL store care ofkeygen token in BUL else silently ignore this packet. Receive_Horne_Test case III 0 Get packets from MN If source address of packet = BUL _Home Address of MN { If Home_Key_Gen_Token = not nil { if destination address of packet = HA of CN { packet received in single tunnel from HAcN to MCN source address = HAcN destination address = COACN If Home init cookie = BUL Home Cookie { Store Home Nonce Index in BUL Store Home Keygen Token in BUL else silently ignore this packet Receive_Horne_Test case IV 0 Get packets from MN If source address of packet = BUL_Home Address ofmn { If Home_Key _ Gen _Token = not nil { if destination address of packet = HA of CN { Home testcn received in double tunnel from HACN source address = COAMN * First Tunnel * destination address = HAMN 96

33 HAMN captures Home tes1:cn and ~ends to HAcN HAcN tunnels Home test ini1:cn to MCN source address = HAcN destination address = COACN If Home init cookie = BUL Home Cookie { Store Home Nonce Index & Home Keygen Token in BUL else silently ignore this packet *End of Pseudo Code for mobility of Correspondent node* 97