Citation
A Fault Tolerant Mobile IP based on Ring Protocol

Material Information

Title:
A Fault Tolerant Mobile IP based on Ring Protocol
Copyright Date:
2008

Subjects

Subjects / Keywords:
Computer technology ( jstor )
Disco ( jstor )
Engineering ( jstor )
Fault tolerance ( jstor )
Harps ( jstor )
Mobile devices ( jstor )
Personal computers ( jstor )
Self concept ( jstor )
Timing devices ( jstor )
Transmitters ( jstor )

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright the author. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
8/8/2002
Resource Identifier:
52205834 ( OCLC )

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

A F A UL T TOLERANT MOBILE IP BASED ON RING PR OTOCOL By VIJA Y V OKKAARNE A THESIS PRESENTED TO THE GRADUA TE SCHOOL OF THE UNIVERSITY OF FLORID A IN P AR TIAL FULFILLMENT OF THE REQUIREMENTS F OR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORID A 2002

PAGE 2

Cop yrigh t 2002 b y VIJA Y V OKKAARNE

PAGE 3

T o m y paren ts and m y dear sister.

PAGE 4

A CKNO WLEDGMENTS First and foremost, I w ould lik e to thank m y advisor, Dr. Ric hard E. Newman, for pro viding me this w onderful opp ortunit y to w ork under his guidance. He has alw a ys b een a source of tec hnical exp ertise, constan t supp ort and great inspiration. Without his in v aluable guidance and motiv ation, this thesis w ould not ha v e b een p ossible. I thank Dr. Ab delsalam Helal, Dr. Jonathan Liu and Dr. Janise McNair for kindly agreeing to participate in m y sup ervisory committee. I w ould also lik e to thank m y friends Kulanda y an Subramanian, Srikumar Sahasranaman and Sree Charan Kuc hibhotla for their v aluable suggestions. Finally , I thank m y paren ts and sister for their supp ort, encouragemen t and lo v e. iv

PAGE 5

T ABLE OF CONTENTS page A CKNO WLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv LIST OF T ABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii ABSTRA CT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x CHAPTERS 1 INTR ODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Wh y Mobile IP? . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 What Is Mobile IP? . . . . . . . . . . . . . . . . . . . . . . . 2 1.2.1 Agen t Disco v ery . . . . . . . . . . . . . . . . . . . . . 3 1.2.2 Registration . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.3 T unneling . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.4 Deregistration . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Motiv ation for the Thesis . . . . . . . . . . . . . . . . . . . . 6 1.4 Organization of the Thesis . . . . . . . . . . . . . . . . . . . 6 2 SUR VEY OF RELA TED RESEAR CH . . . . . . . . . . . . . . . . 8 2.1 Multiple Registrations . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Alternate Registrations . . . . . . . . . . . . . . . . . . . . . 9 2.3 F ault T oleran t Mobile IP based on P assiv e Replication . . . . 9 2.4 Chec k-p oin ting and Receiv er-based Message Logging Approac h 11 2.5 Home Agen t Redundancy Proto col (HARP) . . . . . . . . . 13 2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3 DESIGN OF THE PR OPOSED F A UL T TOLERANT MOBILE IP 16 3.1 Requiremen ts of Primary Bac kup Approac h . . . . . . . . . . 16 3.2 The Ring Proto col . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.1 Ring Proto col Primary . . . . . . . . . . . . . . . . . 18 3.2.2 Ring Proto col Bac kup . . . . . . . . . . . . . . . . . 22 3.3 System T ransformations due to F ailing Primary . . . . . . . 24 3.4 Mo difcations to the Ring Proto col for F ault T oleran t Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4.1 Mo difcations to Primary . . . . . . . . . . . . . . . . 25 v

PAGE 6

3.4.2 Mo difcations to Bac kup . . . . . . . . . . . . . . . . . 29 3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4 IMPLEMENT A TION AND SIMULA TION . . . . . . . . . . . . . . 34 4.1 Net w ork Sim ulator 2 . . . . . . . . . . . . . . . . . . . . . . 34 4.2 Mo difcations to Net w ork Sim ulator 2 Co de to Rerect the F ault T oleran t Proto col . . . . . . . . . . . . . . . . . . . . 35 4.3 Sim ulation Details and Scenarios . . . . . . . . . . . . . . . . 38 4.3.1 Mobile Host at Home . . . . . . . . . . . . . . . . . . 38 4.3.2 Mobile Host at F oreign Net w ork . . . . . . . . . . . . 38 4.3.3 Mobile Host Mo ving from One F oreign Net w ork to Another . . . . . . . . . . . . . . . . . . . . . . . . 40 4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5 RESUL TS AND PERF ORMANCE ANAL YSIS . . . . . . . . . . . 41 5.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.1.1 Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . 42 5.1.2 Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . 43 5.1.3 Scenario 3 . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.2.1 Scalabilit y with Resp ect to Num b er of Mobile Hosts p er Mobilit y Agen t . . . . . . . . . . . . . . . . . . 48 5.2.2 Scalabilit y with Resp ect to Latency Time During F ailureF ree Op eration . . . . . . . . . . . . . . . . . . . . . 48 5.2.3 Scalabilit y with Resp ect to T ak eo v er Time During Agen t F ailure . . . . . . . . . . . . . . . . . . . . . 49 6 CONCLUSIONS AND FUTURE W ORK . . . . . . . . . . . . . . . 51 6.1 Con tributions . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.2 F uture W ork . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 BIOGRAPHICAL SKETCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 vi

PAGE 7

LIST OF T ABLES T able page 5.1 Scenario 1 Av erage Latency Time (in ms) for Registration Requests with No Agen t F ailures . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2 Scenario 1 Av erage Latency Time (in ms) for Registration Requests with Agen t F ailures . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.3 Scenario 2 Av erage Latency Time (in ms) for Registration Requests with No Agen t F ailures . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.4 Scenario 2 Av erage Latency Time (in ms) for Registration Requests with Agen t F ailures . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.5 Scenario 3 Av erage Latency Time (in ms) for Registration Requests with No Agen t F ailures . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.6 Scenario 3 Av erage Latency Time (in ms) for Registration Requests with Agen t F ailures . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 vii

PAGE 8

LIST OF FIGURES Figure page 1.1 Registration Pro cess in Mobile IP . . . . . . . . . . . . . . . . . . . . 4 1.2 T unneling in Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Replication of Home Agen t to Ac hiev e F ault T olerance . . . . . . . . 8 2.2 F ailure and T ak eo v er of an HA . . . . . . . . . . . . . . . . . . . . . . 10 2.3 Reco v ery of a F ailed HA . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4 Registration Pro cess in F ault T oleran t Mobile IP based on P assiv e Replication, indicating High F ailure-F ree Latency . . . . . . . . . . 11 2.5 Registration Pro cess in F ault T oleran t Mobile IP based on Chec kp oin ting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.6 HARP Proto col Confguration . . . . . . . . . . . . . . . . . . . . . . 14 3.1 Ring Structure in a Fiv e Serv er Setup . . . . . . . . . . . . . . . . . . 18 3.2 Comm unication b et w een Primary and Bac kup Serv ers in the Ring . . 18 3.3 Ring Proto col Primary Main F unction . . . . . . . . . . . . . . . . 20 3.4 Ring Proto col Primary Pro cess F unction . . . . . . . . . . . . . . 21 3.5 Ring Proto col Bac kup . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.6 T ransformations in the System as the Primary Keeps F ailing . . . . . 25 3.7 System State (a) When Tw o of the Bac kups F ail and (b) When Tw o of the Bac kups and Primary F ail . . . . . . . . . . . . . . . . . . . 26 3.8 Mo difed Primary Proto col Main F unction . . . . . . . . . . . . . . 27 3.9 Mo difed Primary Proto col Pro cess F unction . . . . . . . . . . . . . 28 3.10 Psuedo-co de for evaluate() . . . . . . . . . . . . . . . . . . . . . . . . 29 3.11 Psuedo-co de for hand le r e c overy() . . . . . . . . . . . . . . . . . . . . 29 3.12 Mo difed Bac kup Proto col . . . . . . . . . . . . . . . . . . . . . . . . 32 viii

PAGE 9

4.1 Sim ulation Scenario 1 MH at Home Net w ork Being Serv ed b y HA . 39 4.2 Sim ulation Scenario 2 MH is Visiting a F oreign Net w ork . . . . . . . 39 4.3 Sim ulation Scenario 3 MH Mo ving from One F oreign Net w ork to Another . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.1 Scenario 1 Av erage Latency Time for Registration Requests with No Agen t F ailures . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2 Scenario 1 Av erage Latency Time for Registration Requests with Agen t F ailures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.3 Scenario 2 Av erage Latency Time for Registration Requests with No Agen t F ailures . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.4 Scenario 2 Av erage Latency Time for Registration Requests with Agen t F ailures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.5 Scenario 3 Av erage Latency Time for Registration Requests with No Agen t F ailures . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.6 Scenario 3 Av erage Latency Time for Registration Requests with Agen t F ailures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 ix

PAGE 10

Abstract of Thesis Presen ted to the Graduate Sc ho ol of the Univ ersit y of Florida in P artial F ulllmen t of the Requiremen ts for the Degree of Master of Science A F A UL T TOLERANT MOBILE IP BASED ON RING PR OTOCOL By VIJA Y V OKKAARNE August 2002 Chair: Dr. Ric hard E. Newman Ma jor Departmen t: Computer and Information Science and Engineering The In ternet has b ecome an indisp ensable part of ev ery computer user's life. The emergence of p ortable devices has led to an exp onen tial increase in the n um b er of p eople that y earn to access the In ternet, ev en when they are on the mo v e. As da ys go b y , more and more Mobile Users w an t an ytime, an ywhere access to the In ternet. In order to fulll suc h demands and accomplish the task of pro viding unrestricted net w ork connectivit y , Mobile IP proto col came in to existence. Mobile IP pro vides suc h seamless net w ork connectivit y b y pro viding t w o IP addresses Home Address and Care-of-Address for ev ery mobile host. Sp ecial mobilit y agen ts, called Home Agen t and F oreign Agen t, transparen tly main tain bindings b et w een these t w o IP addresses. The Home Agen t p erforms the task of re-routing the pac k ets destined for the mobile host while the mobile host is visiting a foreign net w ork. As almost all pac k ets in the Mobile IP system need to ro w through the Home Agen t, it b ecomes a single p oin t of failure. If the Home Agen t fails or crashes, it isolates the mobile host from the en tire w orld, thereb y defeating the whole purp ose of Mobile IP proto col. x

PAGE 11

In order to o v ercome this single p oin t of failure and mak e the Mobile IP system fault-toleran t, a new proto col is required. Suc h a proto col should b e simple and easy to incorp orate in to the existing infrastructure, without m uc h mo dication to the other en tities in the system suc h as F oreign Agen ts and Mobile Hosts. This thesis describ es suc h a F ault T oleran t Mobile IP system. The mo del prop osed in this thesis is based on the Ring Proto col for Distributed Systems in whic h a set of bac kup agen ts is main tained, with an established ring or der hier ar chy . The bac kups are up-to-date with the primary agen t. When the primary home agen t fails, the most up-to-date bac kup times out and tak es o v er. This thesis pro vides a detailed description of the mo dications to the Ring Proto col for adapting it in to Mobile IP . It also presen ts a comparison of the proto col put forth with man y existing approac hes, along with an analysis of the results obtained through sim ulations. xi

PAGE 12

CHAPTER 1 INTR ODUCTION The rise in the n um b er of p ortable devices and an increase in their usage b y p eople that are on the mo v e has led to a h uge increase in the demand for connectivit y to the In ternet irresp ectiv e of the ph ysical lo cation and time. Suc h Mobile Users y earn for net w ork access to b e a v ailable an y place and an y time. As suc h needs and demands increase, new proto cols that promise to fulll these needs emerge. Among the man y proto cols that came in to existence, Mobile IP [1, 2, 3, 4, 5 ] has b ecome p opular and widely accepted. Mobile IP pro vides seamless net w ork connectivit y irresp ectiv e of the user's mo v emen t. It has b een dev elop ed as an extension to the existing In ternet Proto col (IP) [6 ] infrastructure. 1.1 Wh y Mobile IP? The most widely emplo y ed net w ork proto col IP is not designed to handle the issues of mobilit y . In IP , ev ery net w ork access p oin t is b ound with a p ermanen t IP Address and an y host that connects to the net w ork via an access p oin t, main tains a binding of this IP Address with a long expiration time. IP p erforms the routing of pac k ets b y deciding the next hop based on the net w ork information from the destination IP address of the pac k et. This IP address is hierarc hical in nature and rerects the net w ork structure. This IP address consists of t w o comp onen ts namely the net w ork prex and the host prex. P ac k ets are routed from the source to the destination net w ork based on this net w ork prex. The higher la y er proto cols, lik e the T ransmission Con trol Proto col (TCP) [7], manage net w ork connections b y main taining information ab out the quadruplets con taining the IP addresses and 1

PAGE 13

2 the p orts of the end-p oin ts of the connections. These t w o features mak e the task of pro viding mobilit y supp ort under the existing proto col suite dicult, as there is a need for supp orting t w o con trasting features c hanging IP addresses for mobile no des and main taining activ e connections. Also, if the mobile no des mo v e far to dieren t net w orks, then it is not p ossible to route the pac k ets in the same w a y as the net w ork prexes k eep c hanging. In order to address these issues, Mobile IP came in to existence. 1.2 What Is Mobile IP? Mobile IP , a standard prop osed b y a w orking group of the In ternet Engineering T ask F orce (IETF), has b een designed to solv e the issue of address migration in mobile devices b y using t w o IP Addresses for ev ery Mobile Host (MH). One of them is a static home address b y whic h the MH and its net w ork connections, lik e TCP connections, are iden tied. The other IP address is a care-of-address (CoA) that c hanges as the MH's p oin t of attac hmen t to the net w ork c hanges. With these t w o addresses, Mobile IP striv es to mak e mobilit y transparen t to the higher la y er proto cols and minimizes the c hanges to the existing In ternet infrastructure. Sp ecialized routers kno wn as Mobilit y Agen ts main tain the binding b et w een the t w o addresses in a transparen t manner. These mobilit y agen ts can b e classied as Home Agen ts (HA) and F oreign Agen ts (F A). Ev ery MH has a home net w ork and an HA that is a designated router in the home net w ork of the MH. The HA main tains the mobilit y binding of the mobile hosts that it serv es, in a table called the Mobilit y Binding T able. The Mobilit y Binding T able consists of en tries in the form of tuples of < p ermanent home addr ess, temp or ary c ar e-of-addr ess, asso ciation lifetime > . An F A is a sp ecialized router on the foreign net w ork that the MH visits. The list of hosts that are curren tly visiting the foreign net w ork is main tained b y the F A again in the form of tuples of < p ermanent home addr ess, home agent addr ess,

PAGE 14

3 me dia addr ess of the mobile no de, asso ciation lifetime > . An F A helps the MH in comm unicating with its HA while a w a y from its home net w ork. It also helps in routing pac k ets from the MH to Corresp onden t No des (CN). The follo wing stages constitute the basic functioning of the Mobile IP proto col. Agen t Disco v ery for obtaining CoA Registration of the obtained CoA T unneling to the CoA Deregistration of the CoA 1.2.1 Agen t Disco v ery T o obtain a care-of-address, ev ery MH needs to nd an agen t that is willing to pro vide its services to the MH. This agen t disco v ery can b e carried out in t w o w a ys. The Mobilit y Agen ts adv ertise their presence b y broadcasting adv ertisemen t messages p erio dically . The MH can transmit agen t solicitation messages that are ac kno wledged b y the mobilit y agen ts. The agen t disco v ery pro cess of Mobile IP has b een built on top of the existing Router Adv ertisemen t mec hanisms. Th us, the existing router adv ertisemen t messages carry information ab out the default routers along with one or more care-of-addresses. 1.2.2 Registration Once an MH disco v ers a mobilit y agen t, it needs to register with the agen t, obtain a CoA and inform its HA ab out its new CoA. This is required to ensure that the binding information main tained b y the HA is alw a ys up-to-date and that none of the activ e net w ork connections are disrupted as the MH c hanges its lo cation. The registration pro cess (gure 1.1) in v olv es the follo wing steps.

PAGE 15

4 Home Agent Registration Request Registration Reply Registration Reply Foreign Agent Mobile Host Registration Request Mobility Binding Table List Visitor Figure 1.1: Registration Pro cess in Mobile IP First the MH nds out if it is on its home net w ork b y listening to adv ertisemen ts from its HA. If it is, then it con tin ues to op erate without an y requiremen t for mobile services. If the MH is on a foreign net w ork, it registers with the F A b y sending a Registration Request message, whic h includes the p ermanen t IP address of the MH, the IP address of its HA and the CoA information. The F A p erforms the registration pro cess on b ehalf of the mobile host b y rela ying this request to the HA. Up on receiving the request, the HA up dates its routing table, appro v es the request, and sends a Registration Reply bac k to the F A. The F A then up dates its visitor list and rela ys the reply to the MH. 1.2.3 T unneling In Mobile IP , the comm unication b et w een an y CN and an MH is brough t ab out b y the use of T unnels. When a CN wishes to comm unicate with an MH, it sends the IP pac k ets with the destination address set to the home address of the MH. This causes the pac k et to b e routed to the home net w ork of the MH where the HA in tercepts it. The HA determines if the MH is a w a y from the home net w ork visiting a foreign net w ork b y p erforming a lo ok-up in its Mobilit y Binding T able and determines the MH's curren t CoA. The HA then constructs a new pac k et addressed to the CoA using either IP-in-IP [3] or Minimal

PAGE 16

5 Encapsulation [4] sc hemes. This encapsulated pac k et is sen t to the MH. This pro cess of encapsulating the original IP pac k et in another pac k et, illustrated in gure 1.2, is called T unneling. When this encapsulated pac k et arriv es at the foreign net w ork, the F A strips o the pac k et header and determines the home address. It then consults its visitor list and obtains the corresp onding media address for the MH, and deliv ers the original pac k et to the MH. If the MH w an ts to comm unicate with the CN, it constructs IP Global Internet Mobile Node Correspondent Node 1 2 3 4 Home Agent Foreign Agent Figure 1.2: T unneling in Mobile IP pac k ets and forw ards them to the F A. The F A rela ys these pac k ets to the CN using normal IP routing mec hanism. The F A serv es the MH un til the registration lifetime expires. The MH can renew the lifetime b y issuing another Registration Request. This triangle routing has b een impro v ed for eciency b y Route Optimization tec hniques that suggest the use of binding up dates and binding w arnings. Route Optimization previous F As to main tain bindings for their former mobile visitors, sho wing a curren t CoA for eac h. With suc h information, if an F A receiv es a pac k et from a CN that is destined for an MH no longer in its domain, it reencapsulates a datagram with the righ t CoA and sends it along to the MH. It also sends a Binding W arning to the HA of the MH indicating that some CN has an out-of-date binding en try for the particular MH. The HA in turn sends a Binding Up date to the CN.

PAGE 17

6 1.2.4 Deregistration When an MH mo v es from one lo cation to another, it acquires a new CoA and the old CoA is discarded. This pro cess of discarding the CoA is called Deregistration. When the MH returns to its home net w ork, it needs to deregister its CoA. In order to deregister, the MH sends a Registration Request to the HA with a lifetime set to zero and the HA up dates its mobilit y binding table. The MH need not deregister at the F A, as the service oered b y the agen t will expire after the lifetime. The F A then drops the en try for the MH from its visitor list. 1.3 Motiv ation for the Thesis Though Mobile IP is successful in solving the issues of mobilit y , unfortunately it suers from a ma jor dra wbac k. Ev ery pac k et destined for the MH has to go through the HA. Ev en if route optimizations are emplo y ed, the HA is needed for initial connection setup b et w een the CN and the MH, as w ell as for deregistration and registration when the MH mo v es. Th us, the HA b ecomes a single p oin t of failure, as all the resp onsibilit y is en trusted with it. While the MH is visiting a foreign net w ork, if the HA fails for some reason, the MH will b e rendered completely disconnected from the en tire w orld. In order to o v ercome this single p oin t of failure and mak e the Mobile IP system more fault-toleran t, a new proto col is required. Suc h a proto col should b e simple and easy to incorp orate in to the existing infrastructure without m uc h mo dication to other en tities in the system suc h as F A and MH. This thesis aims to pro vide suc h a fault-toleran t Mobile IP . 1.4 Organization of the Thesis This c hapter pro vided a brief description of ho w Mobile IP has emerged as a solution to the issues of mobilit y . It also highligh ted ho w this proto col aims at pro viding seamless net w ork connectivit y but suers from a ma jor dra wbac k with

PAGE 18

7 the HA b eing a single p oin t of failure. It further discussed the need for a new fault-toleran t Mobile IP that can o v ercome this single p oin t of failure at the HA. Chapter 2 describ es some of the existing proto cols for ac hieving fault-tolerance in Mobile IP . It also pro vides an analysis of their dra wbac ks and explains the need for a new sc heme. Chapter 3 pro vides a detailed description of the prop osed fault-toleran t Mobile IP based on the Ring Proto col. In this c hapter, a description of the Ring Proto col for Distributed Systems is initially pro vided and then the mo dications to this proto col for adapting it to Mobile IP are discussed. Chapter 4 discusses the implemen tation and sim ulation details of the prop osed approac h. Chapter 5 details the results obtained and pro vides an analysis of these results. Chapter 6 nally concludes b y observing the merits and demerits of the prop osed proto col, and elab orates on the future scop e of this w ork.

PAGE 19

CHAPTER 2 SUR VEY OF RELA TED RESEAR CH Chapter 1 elab orated ho w Mobile IP suers from a single p oin t of failure and the need for fault-tolerance. Ha ving m ultiple Home Agen ts on ev ery net w ork is the most natural solution for ac hieving fault tolerance and high a v ailabilit y in Mobile IP . A n um b er of solutions based on this approac h ha v e b een suggested. The follo wing sections discuss some of these approac hes, their adv an tages and dra wbac ks. All the existing solutions for pro viding fault tolerance at the Home Agen t site discussed b elo w are built on the concept of replication of agen ts. The structural conguration of all these approac hes is depicted in gure 2.1 b elo w. FA 1 FA 2 FA m Foreign Network Wired Network HA 1 HA 2 HA n Home Network Figure 2.1: Replication of Home Agen t to Ac hiev e F ault T olerance 8

PAGE 20

9 2.1 Multiple Registrations The most trivial w a y of ac hieving fault tolerance in Mobile IP is to ha v e the MH register with all the existing HAs, and main tain tunnels from eac h HA to the MH. This requires that the MH b e a w are of the fault tolerance at the home net w ork and hence, results in mo dications to the MH. This also requires the HAs to ha v e some understanding in order to correctly in tercept the pac k ets destined for the MH and route them to the MH's lo cation. 2.2 Alternate Registrations Another trivial w a y of ac hieving fault tolerance is to mak e the MH a w are of HA failures. When an MH do es not get resp onse from its primary HA, it tries other bac kup agen ts. This approac h to o requires c hanges to the MH. 2.3 F ault T oleran t Mobile IP based on P assiv e Replication R. Ghosh and G. V arghese prop osed a fault toleran t Mobile IP proto col [8] based on passiv e replication of agen ts. In this approac h, m ultiple HAs are pro vided for eac h net w ork. All these mobilit y agen ts alw a ys main tain bindings of all MHs registering with the net w ork. In this proto col, if an y HA receiv es a Registration Request from an MH, it pro cesses the request and forw ards it to its p eers and w aits for ac kno wledgemen t messages from them. Eac h of the bac kups pro cesses the request message receiv ed from the primary HA and sends an ac kno wledgemen t. Once all the ac kno wledgemen ts are receiv ed, the primary HA sends a Registration Resp onse to the MH (gure 2.2a). The failure of one of the agen ts, sa y HA1, causes the p eer HA2 to recognize it and to tak e o v er the resp onsibilit y of the failed agen t. The fail-o v er happ ens b y the agen t HA2 p erforming a Gratuitous ARP [9] for the failed agen t HA1. HA2 no w

PAGE 21

10 accepts registration requests on b ehalf of HA1 and tunnels pac k ets in tended for MH to the F A (gure 2.2b). Registration Request from MN to FA R Registration Request from MNto HA1 forwarded by FA R R Reply forwarded to MN Request forwarded to HA1 and HA2. Acknowledgement from HA2 to HA1 is sent. Reply from HA1 is sent to FA Request is processed by HA1 and forwarded to received by HA2 and Replies are sent by HA2 Requests for HA1 are HA1 and intercepts packets for MN. It also re-routes them to FA. HA2 performs task of HA2 takes over for HA1 by Gratuitous ARP. HA1 fails. (a) Home Network (b) HA2 Home Network HA2 R FA MN HA1 MN Foreign Network Intermediate Routers Foreign Network HA1 FA Intermediate Routers Figure 2.2: F ailure and T ak eo v er of an HA (a) Registration F orw arding among HA to P eers: HA1 receiv es Registration Requests from MH and forw ards it to HA2, w aits for a reply from HA2 and up on receiving it, sends resp onse to MH. This ensures mobilit y binding is reliably recorded at the p eer. (b) HA Crashes: HA1 fails; HA2 p erforms Gratuitous ARP and replies to all Registration Requests in tended for HA1 It also in tercepts pac k ets destined for MH and tunnels them to F A. (from [8]) When a failed agen t HA1 comes up, it rst asserts itself b y p erforming Gratuitous ARP (gure 2.3). It then uses a TCP connection to reco v er its bindings from HA2. Using TCP pro vides the adv an tage of not ha ving to w orry ab out reliabilit y of transmission and retransmissions in case of pac k et loss. The ma jor dra wbac k of this approac h is the high failure-free latency during the registration pro cess. This is due to the time sp en t b y the primary HA in w aiting for ac kno wledgemen ts from all the p eers (gure 2.4). This w aiting time results in a signican t dela y in sending the resp onse to the MH and hence, this proto col is a Blo c king Proto col. The high failure-free latency of this proto col migh t cause the

PAGE 22

11 Home Network When HA1 recoveres after a crash, it performs an ARP for itself and contacts HA2 to obtain bindings through HA2 HA1 TCP connection. It then starts advertising for itself HA2 recognizes HA1 is alive by its advertisements and stops acting on behalf of HA1 Figure 2.3: Reco v ery of a F ailed HA HA 2 HA 1 HA n 1 7 2 4 3 4' 5 5' 6 Registration Request MessageUpdate Binding for Mobile NodeRegistration Reply / Acknowledgement Message Figure 2.4: Registration Pro cess in F ault T oleran t Mobile IP based on P assiv e Replication, indicating High F ailure-F ree Latency MH to timeout and retransmit its registration request. Hence, the proto col is not v ery scalable. 2.4 Chec k-p oin ting and Receiv er-based Message Logging Approac h J. Ahn and C. Hw ang describ ed another fault-toleran t Mobile IP proto col [10]. Multiple HAs are main tained in the home net w ork as in the ab o v e proto col. Ho w ev er, the ma jor dierence in this proto col is in the comm unication b et w een the agen ts. When an MH sends a registration request to an HA, the receiving HA

PAGE 23

12 up dates its binding table and concurren tly logs this message in a stable storage. The HA then sends a registration reply to the Mobile No de (gure 2.5). HA 1 HA n HA 2 Registration Reply / Acknowledgement Message 1 2 3 2' Registration Request MessageLog / Retrieve into Stable Storage Update Binding for Mobile Node Common Stable Storage Figure 2.5: Registration Pro cess in F ault T oleran t Mobile IP based on Chec kp oin ting In this proto col, if the primary HA fails, one of the other redundan t agen ts can reco v er the bindings from the stable storage. All the HAs p erio dically sa v e the bindings of all MH registering with them on the stable storage and remo v e the logged messages b ey ond a c hec kp oin t so that the storage space do es not gro w enormously . The main adv an tage of this approac h is the feature that when an y failed agen t comes up, it is able to reco v er bindings of the MH registering with it, ev en if all the agen ts in the net w ork fail. Ho w ev er, the main dra wbac k of this approac h is the need for a stable storage and garbage collection to k eep the storage space small.

PAGE 24

13 2.5 Home Agen t Redundancy Proto col (HARP) HARP [11], suggested b y B. Cham bless and J. Binkley , is another proto col based on the concept of replication. Here, all the HAs act as p eers that share a single IP subnet and a single IP net w ork address (gure 2.6). Eac h of the HARP p eers act in parallel to create or delete tunnels to the MH's remote CoA. This proto col requires that the HARP p eers exist in an in terior routing domain, that runs an IP in terior routing proto col, suc h that the pac k ets addressed to the subnet are routed to the HARP p eers according to the lo cal metrics of the in terior routing proto cols. In this proto col, when a registration pac k et is receiv ed b y a co-HomeAgen t (co-HA), it encapsulates the pac k et and forw ards it to another co-HA via a UDP [12] p ort. Th us, the p eer will also kno w the curren t CoA of the MH. Eac h of the HARP p eers tak es the same in ternal action whether it receiv es the registration pac k et directly from an MH or from its HARP p eer. If one of the HA fails, the in terior routing structure should notice that it has failed as a router, and normal routing con v ergence will remo v e that path to the subnet. As a result the Mobile IP system should b e able to surviv e the loss of an HA, as pac k ets will b e routed to a surviving HA. F urther, this proto col emplo ys a UDP messages (HARP PING and HARP A CK) for the HARP agen ts to determine if the p eers are up. The main adv an tage of this proto col is the use of UDP in order to forw ard the registration pac k ets b et w een the p eers. This results in the proto col b eing non-blo c king and hence, the failure-free latency is a v oided. Also, when a failed agen t reco v ers, a TCP connection with another HARP p eer is established and the reco v ery is p erformed. Ho w ev er, a ma jor dra wbac k of this proto col is the high dep endency on the in terior routing proto cols to iden tify failures of HARP p eers and to eliminate that path to the subnet. If static routes are used, then man ual route manipulation ma y

PAGE 25

14 Internet Router R2 Home Agent 2 Mobile IP Subnet Router R1 Home Agent 1 Figure 2.6: HARP Proto col Conguration b e required. Also, sp ecial UDP pac k ets are emplo y ed in order to determine the failure of an y agen t. 2.6 Summary In this c hapter, three approac hes prop osed for solving the single p oin t of failure in Mobile IP w ere discussed. The approac h based on P assiv e Replication suers from high failure-free latency . The approac h based on Chec kp oin ting requires additional hardw are suc h as high sp eed storage systems and garbage collection tec hniques. The HARP proto col relies en tirely on the in terior routing proto cols and uses sp ecial UDP messages. The ab o v e discussion of the v arious approac hes indicates that none of the proto cols ac hiev e all the desired prop erties of a fault toleran t Mobile IP , namely: resp onsiv eness b y pro viding for lo w failure-free latency , non-blo c king mo de of op eration,

PAGE 26

15 resilien t Arc hitecture that is easily scalable, and reduced n um b er of messages ro wing across the net w ork. Th us, there is need for a proto col that is capable of ac hieving these goals that at the same time do es not compromise on simplicit y and ease of use. The next c hapter describ es the Ring Proto col, whic h is w ell suited for this purp ose.

PAGE 27

CHAPTER 3 DESIGN OF THE PR OPOSED F A UL T TOLERANT MOBILE IP None of the existing proto cols that aim to pro vide fault tolerance at the home agen t site ac hiev e all the desired prop erties of F ault T oleran t Mobile IP . Th us, there is a need for a new proto col. The Ring Proto col for Distributed Systems, a mo dication of the Primary Bac kup approac h [13 , 14, 15], is a go o d candidate for F ault T oleran t Mobile IP . Before delving in to the details of the proto col, the fundamen tal requiremen ts of an y Primary Bac kup approac h need to b e review ed. 3.1 Requiremen ts of Primary Bac kup Approac h The basic requiremen ts [13] of an y Primary Bac kup approac h are as follo ws. PB1 : Eac h serv er s main tains a predicate P s . A t an y time, there is at most one site s whose state satises this predicate P s . This serv er will b e designated as the Primary Serv er. PB2 : Eac h clien t c main tains a serv er iden tit y S c and it directs its requests only to S c . PB3 : If a clien t request arriv es at a site that is not the primary , then that request is not en-queued b y the site and hence, not pro cessed. PB4 : There exist xed and b ounded v alues k and suc h that the service b eha v es lik e a single (k, ) b ofo serv er. 1 1 A request sen t to a primary-bac kup service can b e lost if it is sen t to a fault y primary serv er. P erio ds during whic h requests are lost are b ounded b y the time required for a bac kup to tak e o v er as the new primary . Suc h b eha vior is an instance of a b ofo service (b ounded outage 16

PAGE 28

17 Since the Ring Proto col is a mo dication of the Primary-Bac kup approac h, it satises all the ab o v e prop erties. A detailed analysis of this is pro vided in c hapter 4 of Ra vin utala's dissertation [16 ]. 3.2 The Ring Proto col The core of the Ring Proto col is a collection of serv ers arranged in a logical ring hierarc h y . Ev ery serv er in this hierarc h y has a designated iden tit y that enables the serv er to b e assigned a sp ot in the ring in relation to other serv ers. A serv er s has a R ing Or der that b egins from s and tra v erses along the ring, in the direction of the ring, up to the serv er that immediately precedes s . The n um b er of links tra v ersed from serv er s1 to s2 in the ring order is the distanc e from s1 to s2 . In this proto col, one of the serv ers is designated as the primary serv er and the others act as bac kups for the primary . As and when crashes o ccur, the role of the primary is passed along the ring in the ring order. The ring structure (gure 3.1) is sp ecic only to this proto col and is not related to the actual comm unication links. The main comm unication (gure 3.2) in this proto col is only from the primary to the bac kups. In the example sho wn, the ring order of serv er 3 is 3-4-5-1-2 and distance from 5 to 3 is 3. The next few sections describ e the original Ring proto col (as in Ra vin utala's dissertation [16 ]) that needs to b e run on the primary and the bac kup serv ers. Then, the mo dications needed to this proto col for adapting it to Mobile IP are discussed. nitely often). A (k, )-b ofo server is one for whic h all outages can b e group ed in to at most k p erio ds, eac h p erio d ha ving a duration of at most . [13 ]

PAGE 29

18 Backup Backup Backup Backup 2 3 4 5 1 Primary Figure 3.1: Ring Structure in a Fiv e Serv er Setup Backup Primary Backup Backup Backup 2 3 4 5 1 Figure 3.2: Comm unication b et w een Primary and Bac kup Serv ers in the Ring 3.2.1 Ring Proto col Primary The functionalit y of the primary serv er is ac hiev ed b y the algorithm primary() in gure 3.3 b elo w [16]. This function main tains t w o threads one that pro cesses the clien t requests and resp onds to them, and the other that main tains the status of the primary b y sending out he artb e at messages. In the primary algorithm, there exist t w o sections that are executed in parallel. The rst section causes the follo wing actions to b e tak en when the primary serv er receiv es a clien t request.

PAGE 30

19 A cop y of the request is placed on the queue along with a status rag indicating that the pro cessing of this request is not y et complete. Since the same causalit y of the requests needs to b e main tained ev en at the bac kup sites, it is essen tial that the bac kups see clien t requests in the same sequence as the primary serv er. As the pro cessing of clien t requests can complete out of order, a queue is emplo y ed in order to ac hiev e this causalit y . A thread is created to pro cess the request async hronously . The second parallel section ensures that the status of the primary is maintained b y sending out sp ecial heartb eat messages at regular in terv als. When the bac kups receiv e these messages, they resc hedule their timeout clo c ks. An imp ortan t note here is that the heartb eat messages are alw a ys sen t out in rev erse ring order. This is to ensure that ev en if the primary crashes midw a y during the pro cess of sending heartb eat messages, the nearest and hence, the most up-to-date bac kup serv er times out rst and tak es o v er as the new primary . When a primary receiv es a clien t request, a separate thread of execution is spa wned. The pr o c ess () function is giv en in the gure 3.4 b elo w. In the pr o c ess() algorithm, the follo wing three actions are p erformed. The clien t request is pro cessed and the resp onse ev aluated. This results in a state c hange for the serv er. If there are other p ending requests in the queue ahead of the one b eing pro cessed, then no further action is tak en. This ensures causalit y of the ev en ts and hence, pro vides consistency in the pro cessing of requests b y b oth primary and bac kups. Lastly , the request is dispatc hed to the bac kups as ST A TE UPD A TE messages and a resp onse is sen t to the clien t with the follo wing restrictions b eing imp osed:

PAGE 31

20 // queue: Queue to maintain or der of client r e quests and their status // self: Identity of self // Primary Main F unction primary() // Thr e ad to pr o c ess client r e quests cob egin for ever do r e quest receiv e message( ) queue insert ( queue , r e quest =request, status=INCOMPLETE) thread create (function= pr o c ess , args= r e quest ) endfor co end // Thr e ad to maintain primary status cob egin for ev ery time do for ev ery server (other than self ) in r everse ring or der do send message ( server , t yp e=I AM ALIVE) endfor endfor co end endprimary Figure 3.3: Ring Proto col Primary Main F unction { The ST A TE UPD A TE messages m ust b e sen t b efore the resp onse is sen t to the clien t. This ensures that the bac kups are not in an inconsisten t state if the primary crashes after transmitting the resp onse to the clien t. { The ST A TE UPD A TE messages are sen t in ring order to ensure the nearest bac kup serv er is the most up-to-date. If the primary fails and a bac kup tak es o v er, it will b e the most up-to-date bac kup serv er. { All the up date and resp onse messages m ust b e completed b efore the next request from the queue is pro cessed. This ensures the causalit y of the clien t requests.

PAGE 32

21 // queue: Queue to maintain or der of client r e quests and their status // self: Identity of self // up date mutex: Mutex lo ck to serialize up dates and r eply to client // Pr o c ess client r e quests pro cess ( r e quest ) // Evaluate client r e quest normal ly r esp onse ev aluate ( r e quest ) // If r e quests that arrive d e arlier did not c omplete, do nothing queue setitem ( queue , request= r e quest , status=COMPLETE) if ( r e quest 6 = queue head ( queue ).request) then thread exit () endif// Flush al l the pr o c esse d r e quests while ( queue head ( queue ).status == COMPLETE) do r e quest queue delete ( queue ).request // Br o adc ast to b ackups and r eply to client, al l in one br e ath m utex lo c k ( up date mutex ) for every server (other than self ) in ring order do send message ( server , t yp e=ST A TE UPD A TE, b o dy= r e quest ) endforsend message ( r e quest .sender, b o dy= r esp onse ) m utex unlo c k ( up date mutex ) endwhile endpro cess Figure 3.4: Ring Proto col Primary Pro cess F unction

PAGE 33

22 3.2.2 Ring Proto col Bac kup Figure 3.5 pro vides the functioning of the bac kup serv ers. The rst and the foremost action that ev ery bac kup serv er needs to p erform is to calculate its distance from the curren t primary . The bac kup serv ers undertak e dieren t actions for dieren t t yp es of messages that they receiv e. These are giv en b elo w. When a bac kup serv er receiv es a ST A TE UPD A TE message, it is a clien t request rela y ed b y the curren t primary for the bac kup to c hange its state accordingly . It is necessary for the bac kups to c hec k if the receiv ed request is not a retransmission of the last one. A separate thread of execution then pro cesses the receiv ed clien t request async hronously . If the receiv ed message is a heartb eat from the curren t primary , then only actions that need to b e p erformed are to note the iden tit y of the curren t primary and to reset the timer v alue. If a bac kup serv er times out w aiting for a heartb eat message from a primary , then it has to declare itself as the primary b y transmitting a heartb eat message to the remaining bac kup serv ers in the rev erse ring order. Again, the rev erse ring order is used to ensure that the most recen t bac kup times out rst up on failure of the primary . Then, the new primary has to retransmit the last receiv ed message in ring order, in order to ensure that all the bac kup serv ers are consisten t. After these steps, the Primary proto col is executed and the fail-o v er is complete.

PAGE 34

23 // primary: Identity of curr ent primary // self: Identity of self // last r e quest: L ast client r e quest r e c eive d // Backup bac kup () for ever do // Time out pr op ortional to distanc e fr om primary T ring distance ( primary , self ) * ( + ) // wher e is the p erio d of he artb e at // messages and is the maximum network delay message receiv e message (timeout=T) switc h message .t yp e // R e gular r elay of client r e quest pr o c ess normal ly case ST A TE UPD A TE: // Make sur e this r e quest has not b e en r e c eive d alr e ady if ( r e quest 6 = last r e quest ) then last r e quest = r e quest thread create (function= ev aluate , args= r e quest ) endifbreak; // This message is either fr om curr ent primary or a new one case I AM ALIVE: primary message .sender break; // Time out me ans primary has faile d b e c ome primary case TIMEOUT: primary self // First announc e to al l other b ackups ab out b e c oming // primary for ev ery server (other than self ) in r everse ring or der do send message ( server , t yp e=I AM ALIVE) endfor

PAGE 35

24 c ontd. fr om pr evious p age... // Br o adc ast last client r e quest sinc e some b ackups may // not have r e c eive d it for ev ery server (other than self ) in ring or der do send message ( server , t yp e=ST A TE UPD A TE, b o dy= last r e quest ) endfor// R un the pr oto c ol for primary primary()break; endswitc h endfor endbac kup Figure 3.5: Ring Proto col Bac kup 3.3 System T ransformations due to F ailing Primary Figure 3.6 illustrates the transformations in the system state as the primary k eeps failing. Figure 3.6(f ) indicates that none of the serv ers in the system are aliv e and hence, the service has failed in its en tiret y . Th us, in order for the service to b e eectiv e, there should b e at least one serv er that is aliv e. Therefore, this Ring Proto col pro vides a resilience of (n s -1) , where n s is the n um b er of serv ers a v ailable. Alternately , if an f-fault toleran t service is desired, then n s = (f + 1) serv ers are needed. Figure 3.7(a) b elo w indicates the system state when t w o of the bac kups (2 & 3) ha v e failed and gure 3.7(b) indicates the system state when t w o of the bac kups (2 & 3) and the primary 1 ha v e failed. 3.4 Mo dications to the Ring Proto col for F ault T oleran t Mobile IP Though the ab o v e Ring Proto col seems to b e v ery ecien t and w ell suited for Distributed Systems, it cannot b e emplo y ed directly for ac hieving fault tolerance in

PAGE 36

25 (e) (f) 1 1 2 1 2 3 1 4 3 2 1 2 3 4 5 (d) (c) (a) (b) Failed Backup Backup Backup Primary Backup Failed Primary Backup Backup Backup Failed Backup Backup Failed Primary Failed Backup Primary Failed Failed Primary Failed Failed Failed Failed Failed Failed Failed Failed 5 5 4 3 5 1 2 3 4 5 4 3 2 5 4 Figure 3.6: T ransformations in the System as the Primary Keeps F ailing Mobile IP; mo dications need to b e p erformed. The follo wing sections describ e the mo dications to b e p erformed to the primary and bac kup algorithms of the Ring Proto col. 3.4.1 Mo dications to Primary The main goal of this thesis is to ac hiev e fault tolerance at the home agen t site of Mobile IP . Ev ery HA has the fundamen tal c haracteristic of p erio dically transmitting agen t adv ertisemen ts in the form of ICMP pac k ets. This happ ens as long as the HA is aliv e. Hence, the functionalit y of the heartb eat messages in the

PAGE 37

26 1 (a) (b) 2 3 3 4 1 5 4 Failed 5 2 Backup Backup Failed Failed Primary Backup Failed Failed Primary Figure 3.7: System State (a) When Tw o of the Bac kups F ail and (b) When Tw o of the Bac kups and Primary F ail Primary algorithm can b e ac hiev ed b y these agen t adv ertisemen t messages. Th us, the second thread of the Primary proto col that is resp onsible for the transmission of the heartb eat messages can b e eliminated. Since the adv ertisemen ts are ICMP broadcasts, the bac kup serv ers ma y not receiv e them in the rev erse ring order. Hence, the timeout v alues of the bac kups need to b e adjusted appropriately . Secondly , the ev aluate ( ) function of the Primary proto col needs to b e mo died to p erform the pro cessing of the registration requests from the MH, up date the mobilit y binding at the site and then p erform ARP for the registering MH. Third mo dication is with resp ect to a reco v ering serv er. If a failed serv er has to reco v er, it needs to up date its binding table b y obtaining the latest information from the curren t primary HA. T o ac hiev e this, a separate thread listens on a sp ecic p ort for requests from reco v ering agen ts. This thread p erforms the follo wing actions. 1. Once a request is receiv ed, another thread is initiated to handle this request and the rst thread go es bac k to listening on the sp ecied p ort. This ensures that m ultiple failed agen ts can reco v er sim ultaneously . 2. The initiated thread establishes a TCP connection with the reco v ering agen t and transfers the latest binding table information, th us bringing the failed

PAGE 38

27 agen t up-todate. As suggested in HARP , a Binding T able Request message, a Binding T able Sync message and a Binding T able Sync Ac kno wledgemen t message can b e emplo y ed [17]. Using TCP connections optimizes this, as the proto col need not handle reliabilit y issues. Figure 3.8 giv es the mo died Main function and gure 3.9 is the mo died Pro cess function of Primary algorithm. // queue: Queue to maintain or der of client r e quests and their status // self: Identity of self // Primary Main F unction primary() // Thr e ad to pr o c ess client r e quests cob egin for ever do r e quest receiv e message () queue insert ( queue , request= r e quest , status=INCOMPLETE) thread create (function= pro cess , args= r e quest ) endfor co end // Thr e ad to pr ovide for r e c overy of a faile d agent cob egin for ever do listen on r e c overy p ort for incoming connections r e quest receiv e message ( r e c overy p ort ) thread create (function= handle reco v ery , args= r e quest ) endfor co end endprimary Figure 3.8: Mo died Primary Proto col Main F unction

PAGE 39

28 // queue: Queue to maintain or der of client r e quests and their status // self: Identity of self // up date mutex: Mutex lo ck to serialize up dates and r eply to client // Pr o c ess client r e quests pro cess ( request ) // Evaluate client r e quest normal ly r esp onse ev aluate ( r e quest ) // If r e quests that arrive d e arlier did not c omplete, do nothing queue setitem ( queue , request= request , status=COMPLETE) if ( r e quest 6 = queue head ( queue ).request) then thread exit() endif// Flush al l the pr o c esse d r e quests while ( queue head ( queue ).status == COMPLETE) do r e quest queue delete ( queue ).request // Br o adc ast to b ackups and r eply to client, al l in one br e ath m utex lo c k ( up date mutex ) for ev ery server (other than self ) in ring or der do send message ( server , t yp e=ST A TE UPD A TE, b o dy= r e quest ) endforsend message ( r e quest .sender, b o dy= r esp onse ) m utex unlo c k ( up date mutex ) endwhile endpro cess Figure 3.9: Mo died Primary Proto col Pro cess F unction

PAGE 40

29 The psuedo-co des for evaluate() and hand le r e c overy() functions are giv en in gures 3.10 and 3.11 resp ectiv ely . function ev aluate () b egin Pr o c ess the inc oming r e gistr ation r e quest Up date the Mobility Binding T able Perform ARP for the r e gistering Mobile No de end Figure 3.10: Psuedo-co de for evaluate() function handle reco v ery () b egin Establish TCP c onne ction with the r e c overing agent T r ansfer the binding table information T erminate the TCP c onne ction end Figure 3.11: Psuedo-co de for hand le r e c overy() 3.4.2 Mo dications to Bac kup A t startup, the bac kups do not kno w whic h serv er is the curren t primary . Hence, they need to listen for agen t adv ertisemen ts initially and then calculate their distance from the primary . Secondly , as in case of the primary algorithm, the heartb eat messages need to b e replaced with the agen t adv ertisemen ts. The third mo dication is with resp ect to a bac kup serv er taking o v er the failed primary . Once a bac kup serv er times out and tak es o v er, the new primary needs to p erform a Gratuitous ARP for the failed agen t. It also needs to p erform a Gratuitous ARP for eac h of the registered MH. The last mo dication deals with a reco v ering agen t. A failed serv er alw a ys reco v ers as a bac kup. Up on reco v ery , a bac kup needs to determine the curren t primary . Then the reco v ering bac kup needs to sync-up with

PAGE 41

30 the primary b y initiating a Binding T able Sync session. This, as explained ab o v e, can b e a TCP session. The mo died bac kup algorithm is giv en in gure 3.12. // primary: Identity of curr ent primary // self: Identity of self // last r e quest: L ast client r e quest r e c eive d // r e c overing: Flag indic ating that the agent faile d pr eviously and is r e c overing fr om the failur e // Backup bac kup () if ( !primary ) then b egin // sinc e atle ast one of the servers is always // functioning, we do not ne e d a time out her e advertisement receiv e message () primary advertisement .sender if ( r e c overing ) then b egin sync up : send message ( primary , t yp e= BINDING T ABLE SYNC REQ) message receiv e message () if ( message .t yp e == BINDING T ABLE SYNC A CK) then b egin while ( mor e messages ) do b egin message receiv e message () thread create (function= ev aluate , args= message ) endwhile

PAGE 42

31 c ontd. fr om pr evious p age... endifelse goto sync up endif endiffor ever do // Time out pr op ortional to distanc e fr om primary // and adjuste d for not me eting the ring or der r estriction // on he artb e at messages T ring distance ( primary , self ) * ( + ) * ( f + 1) // wher e is the p erio d of he artb e at messages, // is the maximum network delay // f is the numb er of messages al lowe d to b e misse d. message receiv e message (timeout= T ) switc h message .t yp e // R e gular r elay of client r e quest pr o c ess normal ly case ST A TE UPD A TE: // Make sur e this r e quest has not b e en r e c eive d alr e ady if ( r e quest 6 = last r e quest ) then last r e quest r e quest thread create (function= ev aluate , args= r e quest ) endifbreak; // This message is either fr om curr ent primary or a new one case A GENT AD VER TISEMENT: primary message .sender break; // Time out me ans primary has faile d b e c ome primary case TIMEOUT: primary self // First announc e to al l other b ackups // primary send message ( server , t yp e= A GENT AD VER TISEMENT)

PAGE 43

32 c ontd. fr om pr evious p age... // Br o adc ast last client r e quest sinc e some b ackups may not // have r e c eive d it for ev ery server (other than self ) in ring or der do send message ( server , t yp e=ST A TE UPD A TE, b o dy= last r e quest ) endforP erform ARP for failed agen t and registered MH // R un the pr oto c ol for primary primary()break; endswitc h endfor endbac kup Figure 3.12: Mo died Bac kup Proto col 3.5 Summary In this c hapter, the fundamen tal requiremen ts of Primary Bac kup approac h w ere discussed. T o reiterate, they are giv en b elo w. One of the serv ers is designated the primary serv er. Ev ery clien t main tains a serv er iden tit y and directs its requests to that serv er. If a clien t request arriv es at a serv er that is not primary , it is not pro cessed. There exist xed and b ounded v alues k and suc h that the service b eha v es lik e a single (k, ) b ofo serv er. A detailed explanation of the Ring Proto col sho w ed that it basically functions b y main taining a logical ring of serv ers. One of this is designated as the primary . Ev ery clien t request is forw arded b y the Primary to other Bac kup serv ers in the ring order. The most up-to-date Bac kup times out and tak es o v er if the Primary fails.

PAGE 44

33 The c hapter also pro vided a discussion of the mo dications to the proto col for adapting it to Mobile IP . In brief, they are the mo dications to the Primary Proto col and the Bac kup Proto col. The sp ecial heartb eat messages are replaced b y the ICMP agen t adv ertisemen ts. The ring distanc e() function is mo died to o v ercome the problem of not meeting the rev erse ring order restriction. The primary and bac kup proto cols w ere mo died to handle the reco v ery of failed agen ts. In c hapter 4, the implemen tation and sim ulation details will b e elab orated.

PAGE 45

CHAPTER 4 IMPLEMENT A TION AND SIMULA TION The eectiv eness of an y proto col can b e appreciated only when statistical data ab out the p erformance of the proto col is a v ailable. This applies to the prop osed fault toleran t mo del also. In order to collect the required statistical data, a sim ulation of the prop osed proto col w as p erformed and v arious scenarios of op eration w ere analyzed. Sim ulation pro vides for rep eatable, con trolled exp erimen tation with only a mo dest o v erhead required to construct and carry out sim ulations. This c hapter pro vides an explanation of the sim ulation of the prop osed proto col and the sim ulation scenarios dealt with. 4.1 Net w ork Sim ulator 2 Net w ork Sim ulator (ns-2) [18 ] has b een used to sim ulate the prop osed proto col. It is a discrete ev en t sim ulator targeted at net w orking researc h. It pro vides substan tial supp ort for sim ulation of TCP , routing, and m ulticast proto cols o v er wired and wireless (lo cal and satellite) net w orks. ns-2 is an ob ject-orien ted sim ulator, written in C++, with an OTcl in terpreter as a fron t-end. The sim ulator supp orts a class hierarc h y in C++ and a similar class hierarc h y within the OTcl in terpreter. The t w o hierarc hies are closely related to eac h other; from the user's p ersp ectiv e, there is a one-to-one corresp ondence b et w een a class in the in terpreted hierarc h y and one in the compiled hierarc h y . The wired-cum-wireless extensions for the wireless mo del in ns-2 pa v ed the path for supp orting wireless Mobile IP in ns-2. The Mobile IP mo del in ns-2 w as implemen ted b y Charles P erkins et al. of Sun Microsystems. 34

PAGE 46

35 Mobile IP scenario in ns-2 consists of HA and F A, and ha v e MH mo ving b et w een their HA and F A. The HA and F A are essen tially base-station no des and the MH are mobile no des. The metho ds and pro cedures for Mobile IP extensions are describ ed in the les mip.cc,h, mip-reg.cc, tcl/lib/ns-mip.tcl and tcl/lib/nswireless-mip.tcl. The le tcl/lib/ns-mobileno de.tcl describ es the some of the functionalities of mobile no des. The HA and F A no des are dened as MobileNo de/MIPBS ha ving a registering agen t (regagen t ) that sends out b eacon to the MH, sets up encapsulator and decapsulator as required, and replies to solicitations from MH. The MH no des are dened as MobileNo de/MIPMH, whic h to o ha v e a regagen t that receiv es and resp onds to b eacons and sends out solicitations to HA. The MobileNo de/MIPMH no de is v ery similar to MobileNo de/MIPBS except for the fact that it do es not ha v e an y encapsulator or decapsulator. 4.2 Mo dications to Net w ork Sim ulator 2 Co de to Rerect the F ault T oleran t Proto col The a v ailable implemen tation of Mobile IP in ns-2 had to b e mo died to rerect the prop osed proto col. The les mo died are mip-reg.cc, mip.h, ll.cc,h, arp.cc,h, tcl/lib/ns-mobileno de.tcl and tcl/lib/ns-lib.tcl. An HA or an F A is created in ns-2 as follo ws. $ns node-config -mobileIP ON n -adhocRouting $opt(rp) n -llType $opt(ll) n -macType $opt(mac) n -ifqType $opt(ifq) n -ifqLen $opt(ifqlen) n -antType $opt(ant) n -propType $opt(prop) n -phyType $opt(netif) n -channelType $opt(chan) n -topoInstance $topo n -wiredRouting ON # create base-station node (HA and FA)

PAGE 47

36 set HA [$ns node 1.0.0] where $ ns is the Sim ulator instance and no de-c ong is the parameter to congure the t yp e of the no de. $ opt(rp) is the routing proto col used, $ opt(l lT yp e) is the link la y er, $ opt(macT yp e) is the MA C la y er t yp e (802.11), $ opt(ifqT yp e) and $ opt(ifqL en) are the net w ork in terface t yp e and length, $ opt(antT yp e) and $ opt(pr opT yp e) are the an tenna and the propagation t yp es used, $ opt(chanT yp e) is the t yp e of the c hannel, top oInstanc e is the top ology used and wir e dR outing indicates that the no de is a base-station no de. Th us, in order to rerect the status of the HA (either Primary or Bac kup), a new option bsStatus has b een added to the no de-c ong command. Also, a command set-status has b een pro vided in the MobileNo de/MIPBS class in the mip-reg.cc le. When the no de is created, this function is in v ok ed with the agen t status as the parameter. F or example, a Primary HA is created b y adding -bsStatus PRIMAR Y to the ab o v e command as sho wn b elo w. This causes the no de to b e created as an instance of the MobileNo de/MIPBS class and the set-status of this instance to b e in v ok ed with the status PRIMAR Y . $ns node-config -mobileIP ON n -adhocRouting $opt(rp) n -llType $opt(ll) n -macType $opt(mac) n -ifqType $opt(ifq) n -ifqLen $opt(ifqlen) n -antType $opt(ant) n -propType $opt(prop) n -phyType $opt(netif) n -channelType $opt(chan) n -topoInstance $topo n -wiredRouting ON n -bsStatus PRIMARY # create base-station node (HA and FA) set HA [$ns node 1.0.0]

PAGE 48

37 A t startup, all the agen ts created should kno w whic h agen t is the primary and whic h are the bac kups. This is ac hiev ed b y the set-ring-or der command of the MobileNo de/MIPBS class. This command tak es the r e gagent of all the HA created as the parameter and sets the ring order for eac h of the agen ts. The status of an HA dictates the functionalit y of the agen t. If the agen t is congured as primary , along with its normal op eration of sending out p erio dic b eacons, it has to p erform the task of forw arding registration requests to the bac kups in the ring order. These c hanges ha v e b een incorp orated in to the a v ailable implemen tations b y mo difying the les mip-reg.cc and mip.h. If the agen t is congured as a bac kup, then it should listen for adv ertisemen ts from the primary agen t and, if no adv ertisemen ts are receiv ed within a fail-o v er p erio d, then the bac kup agen t should time out and tak e o v er. This requires a timer to b e set up with a timeout v alue of fail-o v er time. A new simple timer class, F ailo v erTimer, has b een implemen ted for this purp ose in les mip-reg.cc and mip.h. This timer is created during the creation of the bac kup agen t no de. When the bac kup receiv es an agen t adv ertisemen t from the primary agen t, this fail-o v er timer is reset. When a bac kup receiv es a registration request pac k et, it notes if the pac k et is a retransmission of the last pac k et. If it is, then no action is tak en. If not, then the bac kup agen t c hec ks if it is a de-registration pac k et and discards the earlier registration pac k ets for the MH. If the request is a new registration pac k et, then the bac kup app ends it to the list of earlier requests. This list is used during the fail-o v er pro cess. The fail-o v er pro cess in v olv es p erforming a Gratuitous ARP on b ehalf of all the MHs registered with the failed agen t, and the failed agen t itself. Gratuitous ARP functionalit y is not pro vided in ns-2 and hence, had to b e implemen ted as the function arpbr o adc ast() in the les arp.cc and arp.h. Gratuitous ARP results in the link la y er of the agen t taking o v er, pic king up the pac k ets destined for the

PAGE 49

38 failed agen t. Hence, the link la y er implemen tation in the les ll.cc and ll.h has b een mo died accordingly . 4.3 Sim ulation Details and Scenarios T o analyze the p erformance of the prop osed fault toleran t Mobile IP , three dieren t scenarios ha v e b een considered. They are: the MH remaining at home net w ork, the MH visiting a single foreign net w ork and b eing serv ed b y the F A of that net w ork, and the MH mo ving from one foreign net w ork to another and hence, b eing serv ed b y m ultiple F A in the time span of its mo v emen t. In all the three scenarios, three cases ha v e b een sim ulated. The rst of them is the baseline case wherein a single HA is a v ailable at the home net w ork and there is no agen t failure. The second case deals with m ultiple HAs at the home net w ork and no failures. This pro vides a clear picture of what the failure-free latency is and the scalabilit y of the prop osed proto col. The third case in v olv es m ultiple HAs at the home net w ork and a n um b er of agen t failures. This case helps in understanding the latencies observ ed during the registration pro cess when agen t failures o ccur. 4.3.1 Mobile Host at Home When an MH is at home, it listens for adv ertisemen ts from its HA and registers with it b y sending Registration Requests and receiving Registration Replies directly from the HA. Figure 4.1 illustrates the exp erimen tal setup used in this case. 4.3.2 Mobile Host at F oreign Net w ork When an MH is visiting a foreign net w ork, it is serv ed b y an F A and all the registration requests are rela y ed b y the F A to the HA and bac k to the MH as illustrated in the gure 4.2 b elo w.

PAGE 50

39 Wired Node HA 1 HA 2 HA k Figure 4.1: Sim ulation Scenario 1 MH at Home Net w ork Being Serv ed b y HA Wired Node HA 1 HA 2 HA k FA Figure 4.2: Sim ulation Scenario 2 MH is Visiting a F oreign Net w ork

PAGE 51

40 4.3.3 Mobile Host Mo ving from One F oreign Net w ork to Another When a MH mo v es from one foreign net w ork to another (gure 4.3), a hando o ccurs b et w een the F As of the t w o net w orks. This hando causes the MH to register a new CoA with the HA. Th us, this scenario indicates the latencies observ ed when there are rep eated handos and frequen t registrations. HA 1 HA 2 HA k Wired Node FA m FA 1 Figure 4.3: Sim ulation Scenario 3 MH Mo ving from One F oreign Net w ork to Another 4.4 Summary This c hapter elab orated on the details of the implemen tation and the sim ulation of the prop osed proto col. It discussed the c hanges to the Net w ork Sim ulator co de and also explained ho w to create primary and bac kup agen ts in the simulations. The c hapter further discussed the sim ulation scenarios that help in understanding the p erformance of the prop osed mo del. These are the cases where the MH is at home and the HA fails, the MH is at foreign net w ork and the HA fails, and the MH is mo ving from one foreign net w ork to another and the HA fails. The next c hapter discusses the obtained sim ulation results and analyzes these results.

PAGE 52

CHAPTER 5 RESUL TS AND PERF ORMANCE ANAL YSIS This c hapter summarizes the results obtained from sim ulation of the prop osed proto col. The p erformance index used for the ev aluation of scalabilit y of the prop osed proto col is the a v erage latency time for pro cessing a registration request message from an MH. This latency has b een calculated as the time it tak es for a registration request from an MH to reac h the HA, b e pro cessed at the HA and the registration reply to b e receiv ed b y the MH. In order to ev aluate the scalabilit y and p erformance of the prop osed approac h, t w o cases of op eration ha v e b een considered. The latency has b een calculated for the failure-free case and when there are rep eated failures of primary agen ts. The failure-free case pro vides a fair idea in determining the n um b er of redundan t agen ts that can b e pro vided at the HA site. The a v erage latency time when the primary agen t fails and is tak en o v er b y a bac kup pro vides an estimate of the aect of failures on the registration pro cess. The follo wing sections summarize the results obtained. 5.1 Results As discussed in the previous c hapter, three scenarios ha v e b een sim ulated for the prop osed proto col. In scenario 1, the MH resides in the home net w ork and there are m ultiple HAs. F ailure-free op eration and a n um b er of agen t failures are the t w o cases considered. In scenario 2, the MH is visiting a foreign net w ork and there are m ultiple HAs in the home net w ork. Again failure-free and agen t failures ha v e b een sim ulated. In the third scenario, the MH mo v es b et w een foreign net w orks and there is redundancy at the home net w ork. In this case to o, failurefree and agen t failure op erations ha v e b een considered. 41

PAGE 53

42 5.1.1 Scenario 1 T able 5.1 sho ws the details of the latency times (in ms) observ ed when there are no agen t failures and the n um b er of redundan t HAs is increased. T able 5.1: Scenario 1 Av erage Latency Time (in ms) for Registration Requests with No Agen t F ailures Num b er of HA 1 2 3 5 10 Num b er of MH 5 11.54 18.35 23.57 30.46 51.73 10 20.31 29.70 38.64 55.31 98.85 20 44.66 60.04 74.74 107.90 109.07 T able 5.2 sho ws the latency times obtained for registration requests when there are home agen t failures. In eac h of the cases, if there are x agen t failures, then there are (x + 1) agen ts b eing main tained. T able 5.2: Scenario 1 Av erage Latency Time (in ms) for Registration Requests with Agen t F ailures Num b er of HA F ailures 1 2 4 9 Num b er of MH 5 18.14 24.02 30.97 53.34 10 30.29 39.18 56.32 100.84 20 59.36 71.19 108.28 113.35 The ab o v e table 5.1 indicates that the a v erage latency time for registration requests increases as the n um b er of redundan t agen ts is increased. This is as exp ected since the primary agen t has to forw ard the registration pac k ets to the bac kups. In table 5.2, the latency times again increase as the n um b er of agen ts is increased. Ho w ev er, the latency times are not v ery high ev en when there are agen t failures. This indicates that the prop osed proto col has a go o d turnaround time in case of agen t failures.

PAGE 54

43 During failures, it is exp ected for the MH to lose some pac k ets for a brief time and hence, retransmit. Once the bac kup agen t tak es o v er, the MH will con tin ue to receiv e undisrupted service. 5.1.2 Scenario 2 The follo wing t w o tables indicate the results obtained when the MH is visiting a foreign net w ork and b eing serv ed b y an F A. T able 5.3: Scenario 2 Av erage Latency Time (in ms) for Registration Requests with No Agen t F ailures Num b er of HA 1 2 3 5 10 Num b er of MH 5 14.47 24.78 28.46 30.21 30.56 10 21.73 45.40 52.00 54.24 54.53 20 41.75 85.90 89.80 96.79 97.09 T able 5.4: Scenario 2 Av erage Latency Time (in ms) for Registration Requests with Agen t F ailures Num b er of HA F ailures 1 2 4 9 Num b er of MH 5 17.55 24.64 28.76 31.02 10 27.05 30.32 42.44 43.09 20 54.73 60.31 87.88 79.95 Again from the ab o v e t w o tables, it can b e inferred that the a v erage latency for registration requests increases as the n um b er of agen ts increases. Ho w ev er, the increase in the n um b er of agen t failures helps in bringing do wn the latency times as the n um b er of rela ys from the primary to the bac kups decreases. 5.1.3 Scenario 3 The tables 5.5 and 5.6 indicate the results obtained for this scenario with and without failures. As observ ed in the ab o v e t w o scenarios, the results for this scenario are similar with the latency times increasing with the rise in the n um b er of HAs. Also during

PAGE 55

44 T able 5.5: Scenario 3 Av erage Latency Time (in ms) for Registration Requests with No Agen t F ailures Num b er of HA 1 2 3 5 10 Num b er of MH 5 14.44 21.64 27.33 28.71 30.66 10 21.04 30.73 36.41 37.69 47.52 20 39.29 48.99 56.34 64.05 65.04 T able 5.6: Scenario 3 Av erage Latency Time (in ms) for Registration Requests with Agen t F ailures Num b er of HA F ailures 1 2 4 9 Num b er of MH 5 19.58 19.55 24.41 30.13 10 23.19 27.59 39.95 56.15 20 40.82 49.56 99.29 104.29 failures, the latency times drop do wn indicating that the primary has to rela y the requests to few er agen ts.The ab o v e results ha v e b een plotted in the graphs sho wn b elo w.

PAGE 56

45 Figure 5.1: Scenario 1 Av erage Latency Time for Registration Requests with No Agen t F ailures Figure 5.2: Scenario 1 Av erage Latency Time for Registration Requests with Agen t F ailures

PAGE 57

46 Figure 5.3: Scenario 2 Av erage Latency Time for Registration Requests with No Agen t F ailures Figure 5.4: Scenario 2 Av erage Latency Time for Registration Requests with Agen t F ailures

PAGE 58

47 Figure 5.5: Scenario 3 Av erage Latency Time for Registration Requests with No Agen t F ailures Figure 5.6: Scenario 3 Av erage Latency Time for Registration Requests with Agen t F ailures

PAGE 59

48 5.2 Analysis This section pro vides an analysis of the scalabilit y of the prop osed proto col as compared to the t w o proto cols based on P assiv e Replication [8 ] and Chec k-p oin ting [10]. These analyses are pro vided with resp ect to the n um b er of MH p er mobilit y agen t, the latency time p er registration request during failure-free op eration and the tak eo v er time incurred during agen t failures. F or the purp ose of analysis, PRMIP denotes the F ault T oleran t Mobile IP based on P assiv e Replication and CPMIP denotes the F ault T oleran t Mobile IP based on Chec k-p oin ting and Reco v ery . 5.2.1 Scalabilit y with Resp ect to Num b er of Mobile Hosts p er Mobilit y Agen t First the scalabilit y of the prop osed proto col, with resp ect to the n um b er of mobile no des registering p er mobilit y agen t, during failure-free op eration as compared to the proto cols PRMIP [8] and CPMIP [10] is analyzed. The rate at whic h the n um b er of mobile no des whose bindings are managed b y the agen ts increases in PRMIP [8] is high, since ev ery Mobilit y Agen t has to main tain the bindings for ev ery no de that registers with the primary agen t. Ho w ev er, in CPMIP [10], this rate increases at a slo w er pace since only the agen t with whic h the MH registers has to main tain the bindings. In the prop osed proto col, this rate of increase will b e similar to the proto col PRMIP [8] since all the agen ts main tain bindings of ev ery MH registering with the primary agen t. Ho w ev er, since the primary agen t do es not exp ect ac kno wledgemen ts from the bac kups for ev ery registration request, the turnaround time for the requests is prett y small as compared to the proto col PRMIP b y Ghosh and V arghese. 5.2.2 Scalabilit y with Resp ect to Latency Time During F ailure-F ree Op eration The scalabilit y of the prop osed proto col with resp ect to latency time for registration requests is ev aluated as compared to the other t w o proto cols. In PRMIP

PAGE 60

49 [8], ev ery bac kup agen t has to pro cess the request receiv ed from the primary and then send an ac kno wledgemen t. The primary collects all the ac kno wledgemen ts and sends a reply to the MH. This results in a high latency during failure-free operation, and hence, causes the MH to timeout and to retransmit its request. Also, the n um b er of messages generate p er registration request receiv ed is (2 (NOMA 1)) where NOMA is the n um b er of mobilit y agen ts in the net w ork. In CPMIP [10 ], only the primary agen t pro cesses the registration request and forw ards it to the stable storage serv er. The stable storage serv er sa v es the reco v ery information on the stable storage and sends an ac kno wledgemen t. Th us in this case, the n um b er of messages p er registration request is 2. In the prop osed proto col, ev ery registration request receiv ed b y the primary agen t is propagated to the bac kups and no ac kno wledgemen t is exp ected bac k. Th us, the n um b er of messages p er registration request is (NOMA 1) . Th us, the prop osed proto col has the adv an tage of few er messages and also a v oids the need for stable storage. 5.2.3 Scalabilit y with Resp ect to T ak eo v er Time During Agen t F ailure The o v erheads of the proto cols PRMIP [8] and CPMIP [10 ] for taking o v er failed mobilit y agen ts can also b e compared with that of the prop osed proto col. In PRMIP [8 ], all the mobilit y agen ts main tain bindings of all the MHs that register with the primary agen t. Hence, the tak eo v er time is less as compared to that of the proto col b y Ahn and Hw ang. In the prop osed proto col to o, the mobilit y agen ts main tain bindings of all MHs that register with the primary agen t. Hence, the tak eo v er time will b e similar to that in proto col PRMIP [8] and b etter than that in CPMIP [10]. The usage of additional high-sp eed scalable storage systems as suggested in CPMIP [10] is also a v oided in the prop osed proto col.

PAGE 61

50 The ab o v e discussion indicates that the prop osed proto col has the adv an tages of the proto cols in PRMIP [8] and CPMIP [10].

PAGE 62

CHAPTER 6 CONCLUSIONS AND FUTURE W ORK As there is a proliferation in the n um b er of mobile no des in the w orld, the need for fault tolerance in Mobile IP will increase. Mobilit y Agen ts the HA and the F A will b e required to pro vide impro v ed p erformance and a v ailabilit y . The existing approac hes to mak e Mobile IP fault toleran t are successful in masking the failures of the mobilit y agen ts. Ho w ev er, they result in high failure-free latency during registration pro cess and require other system en tities lik e stable storage or in terior routing proto col to handle the failures. This thesis prop osed a new fault toleran t approac h for impro ving the a v ailabilit y of mobilit y agen ts in Mobile IP . This proto col w as based on the Ring Proto col for distributed systems. 6.1 Con tributions Through this thesis, a new approac h for pro viding fault tolerance in Mobile IP proto col has b een iden tied. Though the Ring Proto col is w ell suited for distributed systems, it is not directly applicable to Mobile IP . This thesis iden tied and prop osed the c hanges to the Ring Proto col in order to adapt it in to Mobile IP . The Ring Proto col w orks b y main taining a logical ring hierarc h y among the mobilit y agen ts. One of the agen ts in the ring is designated as the primary and the remaining act as bac kups. When the primary agen t receiv es a registration request from a mobile no de, it pro cesses the request and forw ards it to the bac kups. It also sends a reply to the mobile no de. The bac kups pro cess the registration request indep enden t of the primary agen t and th us, b ecome up-to-date with the primary . 51

PAGE 63

52 This forw arding of requests b y primary is p erformed in the ring order so that the nearest bac kup is the most up-to-date. Eac h of the bac kups listens for p erio dic agen t adv ertisemen ts from the primary and determines that the primary is aliv e. If the primary crashes, then the nearest and hence, the most up-to-date bac kup times out. This time out v alue is congured based on the ring distance of the bac kup agen t from the primary . The bac kup that times out p erforms the pro cess of fail-o v er and tak es o v er the failed agen t. The other agen ts act as bac kups to the new primary . This thesis also discussed a few sim ulations p erformed in order to ev aluate the p erformance and scalabilit y of the prop osed proto col. The results obtained w ere quite encouraging. An analysis of the obtained results indicates that the prop osed proto col ac hiev es lo w failure-free latency and b etter scalabilit y unlik e the proto col suggested b y Ghosh and V arghese [8]. The suggested proto col also has b etter tak eo v er time than the fault-toleran t approac h based on Chec kp oin ting and Reco v ery suggested b y Ahn and Hw ang [10]. Also, this proto col a v oids the necessit y of a common stable storage and hence, o v ercomes the cen tralized b eha vior unlik e the proto col b y Ahn and Hw ang [10]. Ho w ev er, the only dra wbac k of the prop osed proto col is the need for at least one of the agen ts to b e functioning. If all the agen ts in the system fail, then it is not p ossible for an y of the failed agen ts to reco v er unlik e the proto col b y Ahn and Hw ang [10] and hence, the service fails in its en tiret y . Hence, the prop osed proto col has a resilience of f = (n s 1) where n s is the n um b er of agen ts in the system. 6.2 F uture W ork This thesis is a stepping stone to w ards a go o d fault toleran t Mobile IP . Here an initial v ersion of the prop osed fault toleran t proto col has b een implemen ted. A basic w orking of this proto col has b een v eried through sim ulations. Ho w ev er,

PAGE 64

53 further extensions to the prop osed proto col can b e pro vided in order to pro vide a complete fault toleran t system. When a mobile no de returns home, it listens to agen t adv ertisemen ts from its home agen t and deregisters with the home agen t. Ho w ev er, if the mobile no de returns home and its home agen t crashes and is tak en o v er b y another agen t, the mobile no de will not realize that it has returned home since it receiv es no adv ertisemen ts from its home agen t. This issue needs to b e handled in a detailed manner b y either making c hanges to the mobile no de or b y emplo ying some other net w ork address masking tec hniques. Secondly , ev ery failed agen t reco v ers as a bac kup. The reco v ery pro cess in itself needs to b e addressed in greater detail. In this thesis, the reco v ery pro cess has b een describ ed as a TCP connection b eing established b et w een the reco v ering agen t and the curren t primary , and a transfer of mobilit y bindings b et w een them. Ho w ev er, it is not ecien t for an y primary agen t to transfer the en tire mobilit y binding table to the reco v ering agen t. Hence, there needs to b e some mec hanism to reduce this information ro w. This can b e some form of c hec k-p oin ting and reco v ery algorithm. This reco v ery pro cess can b e further impro v ed b y making the reco v ering agen ts request information from other bac kups in addition to the primary . This helps in reducing the burden on the primary agen t. This approac h w ould require the reco v ery thread to b e in the bac kup in addition to the primary . A t the end of sync hronization, the reco v ering agen t should inform the primary that it is aliv e and request the primary to transmit an y further up dates. Ho w ev er, during this time p erio d, there ma y b e some up dates that ha v e already b een rela y ed to other bac kups. Hence, the bac kups and the primary need another thread to request and transmit the missing up dates.

PAGE 65

54 Another impro v emen t to this proto col can b e in the form of broadcast or m ulticast transmission of registration requests b y the primary . If all the agen ts are in a single net w ork, they can listen on a single m ulticast/broadcast address and the primary can forw ard the registration requests from mobile no des on this address. Ho w ev er, this approac h needs to b e further review ed for side eects. In the prop osed proto col, when the registration requests are forw arded to the bac kups, there ma y b e instances when some up dates are lost due to net w ork parameters. Bac kups should b e able to request for suc h lost up date messages from the primary . This requires a thread in the primary and the bac kups, and the primary and the bac kups need to main tain cac he of up dates. This thesis discusses the application of the fault-toleran t approac h at the home agen t site. The prop osed proto col can b e emplo y ed at the foreign net w ork with minor mo dications. As another extension to this thesis, the securit y features of Mobile IP proto col can b e handled. This thesis w ork do es not pa y an y atten tion to w ards the securit y asp ects of Mobile IP . Some form of authen tication b et w een the primary and the bac kup agen ts needs to b e established. Also, authen tication b et w een bac kups and mobile no des along with the foreign agen ts needs to b e p erformed. In this thesis, en tire systems are suggested to b e dedicated bac kups. Ho w ev er in practice, it is not economically feasible to assign dedicated bac kup systems for ev ery home agen t in an y net w ork. Hence, the proto col can b e easily extended to pro vide some form of load balancing. There ma y b e m ultiple ring orders main tained among a set of agen ts. Agen ts can pla y roles of bac kups for dieren t primary agen ts leading to in tersecting ring orders. Also, eac h of the agen ts can b e assigned a set of mobile no des to handle, th us balancing the load on the system and impro ving p erformance.

PAGE 66

55 Finally , though sim ulations pro vide a fair idea of the proto col's p erformance, it is essen tial that the prop osed proto col b e implemen ted and deplo y ed in real w orld net w orks. This can in itself b e another topic of researc h.

PAGE 67

REFERENCES [1] Charles E. P erkins, Mobile IP Design Principles and Pr actic es , AddisonW esley Wireless Comm unications Series, Reading, MA, Oct 1997. [2] Charles E. P erkins, IP Mobility Supp ort , In ternet Engineering T ask F orce RF C 2002, Oct 1996. [3] Charles E. P erkins, IP Enc apsulation within IP , In ternet Engineering T ask F orce RF C 2003, Oct 1996. [4] Charles E. P erkins, Minimal Enc apsulation within IP , In ternet Engineering T ask F orce RF C 2004, Oct 1996. [5] Charles E. P erkins and Andrew P . Myles, Mobile IP , T. J. W atson Researc h Cen ter, IBM, Y orkto wn Heigh ts, NY and Macquarie Univ ersit y , Sydney , Australia. [6] J. B. P ostel, Internet Pr oto c ol , In ternet Engineering T ask F orce RF C 791, Sep 1981. [7] J. B. P ostel, T r ansmission Contr ol Pr oto c ol , In ternet Engineering T ask F orce RF C 793, Sep 1981. [8] Ra jib Ghosh and George V arghese, F ault-T oler ant Mobile IP , T ec hnical Rep ort, WUCS-98-11, W ashington Univ ersit y , St. Louis, MO, Apr 1998. [9] Da vid C. Plummer, A n Ethernet A ddr ess R esolution Pr oto c ol or Converting Network Pr oto c ol A ddr esses to 48.bit Ethernet A ddr ess for T r ansmission on Ethernet Har dwar e , In ternet Engineering T ask F orce RF C 826, No v 1982. [10] JinHo Ahn and ChongSun Hw ang, Ecien t F ault-toleran t Proto col for Mobilit y Agen ts in Mobile IP, A nnual IEEE Workshop on F ault-T oler ant Par al lel and Distribute d Systems FTPDS'01, San F rancisco, CA, Apr 2001. [11] Bjorn Cham bless and Jim Binkley , HARP Home A gent R e dundancy Pr oto c ol , In ternet Draft, In ternet Engineering T ask F orce, draftc ham bless-mobileip-harp-00.txt, W ork in Progress, Oct 1997. Av ailable at h ttp://www.glob ecom.net/ietf/draft/draft-c ham bless-mobileip-harp-00.h tml [12] J. B. P ostel, User Datagr am Pr oto c ol , In ternet Engineering T ask F orce RF C 768, Aug 1980. 56

PAGE 68

57 [13] Na vin Budhira ja, Keith Marzullo, F red B. Sc hneider and Sam T oueg, Optimal Primary-Bac kup Proto cols, In Pr o c e e dings of the 6th International Workshop on Distribute d A lgorithms , V olume 647 of lecture notes in Computer Science, pages 362-378, Haifa, Israel, No v 1992. [14] Na vin Budhira ja, Keith Marzullo, F red B. Sc hneider and Sam T oueg, Lo w er Bounds for a Primary-Bac kup Implemen tation of a Bofo Service, In Pr o c e e dings of the Thir d IFIP Working Confer enc e on Dep endable Computing for Critic al Applic ations , Mondello, Italy , Sep 1992. [15] Na vin Budhira ja and Keith Marzullo, T r ade os in Implementing PrimaryBackup Pr oto c ols , T ec hnical Rep ort, Departmen t of Computer Science, Cornell Univ ersit y , Ithaca, NY, 1992. [16] Sekhar Ra vin utala, R esilient and R esp onsive Servers for Distribute d Systems , PhD Dissertation, Departmen t of Computer and Information Science and Engineering, Univ ersit y of Florida, Gainesville, FL, 1996. [17] Ken t Leung and Madha vi Subbarao, Home A gent R e dundancy in Mobile IP , In ternet Draft, In ternet Engineering T ask F orce, draft-subbaraomobileip-redundancy-01.txt, W ork in Progress, Dec 2001. Av ailable at h ttp://searc h.ietf.org/in ternet-drafts/draft-subbarao-mobileip-redundancy01.txt [18] Kevin F all and Kannan V aradhan, The ns Manual (formerly ns Notes and Do cumen tation), The VINT Pro ject (Collab oration Bet w een Researc hers at UC Berk eley , LBL, USC/ISI and Xero x P AR C), Dec 2000. Av ailable at h ttp://www.isi.edu/nsnam/ns/ns-do cumen tation.h tml

PAGE 69

BIOGRAPHICAL SKETCH Vija y w as b orn in the garden cit y of Mysore, India, in 1978. He receiv ed his undergraduate degree of Bac helor of Engineering in computer science and engineering from the Univ ersit y of Mysore in 1999. He w ork ed as a soft w are engineer in Wipro Global R & D from 1999 to 2000. In Spring 2001, Vija y secured admission to the Master of Science with a ma jor of computer engineering, in the Computer and Information Science and Engineering (CISE) departmen t, Univ ersit y of Florida. His ma jor area of in terests are computer net w orking, op erating systems and mobile computing. He will b e graduating in August 2002. 58

PAGE 70

A F A UL T TOLERANT MOBILE IP BASED ON RING PR OTOCOL VIJA Y V OKKAARNE (352) 373-8516 Computer and Information Science and Engineering Chair: Dr. Ric hard E. Newman Degree: Master of Science Graduation Date: August 2002 The emergence of p ortable devices and the gro wth of In ternet has led to an exp onen tial increase in the n um b er of p eople that y earn to access the In ternet, ev en when they are on the mo v e. As da ys go b y , more and more Mobile Users w an t an ytime, an ywhere access to the In ternet. In order to fulll suc h demands, Mobile IP proto col came in to existence. Mobile IP pro vides suc h seamless net w ork connectivit y b y pro viding t w o IP addresses for ev ery mobile host. Sp ecial mobilit y agen ts, called Home Agen t and F oreign Agen t, transparen tly main tain the mapping b et w een the t w o IP addresses. The Home Agen t p erforms the task of re-routing the data destined for the mobile host while the mobile host is visiting a foreign net w ork. As almost all data in the Mobile IP system need to ro w through the Home Agen t, it b ecomes a single p oin t of failure. If the Home Agen t fails or crashes, it isolates the mobile host from the en tire w orld, thereb y defeating the whole purp ose of Mobile IP proto col. In order to o v ercome this single p oin t of failure and mak e the Mobile IP system fault-toleran t, a new proto col is required that is simple and easy to incorp orate in to the existing infrastructure, without m uc h mo dication to other en tities in the system. This thesis describ es suc h a F ault T oleran t Mobile IP system based on the Ring Proto col for Distributed Systems, in whic h a set of bac kup agen ts is maintained with an established ring or der hier ar chy . It pro vides a detailed description of the mo dications to the Ring Proto col for adapting it in to Mobile IP . It also presen ts a comparison of the proto col put forth with man y existing approac hes, along with an analysis of the results obtained through sim ulations.