IPv6 networking and seamless handover study for mobile communications in Airplan
Full text
IPv6 Networking And Seamless Handover Study For Mobile Communiations In Airplanes By Ignasi Esteva Gras Tutor : Dr. Markus Wegner and Eriza Had Fazli TriaGnoSys GmbH TRIA GNO SY S Sup ervisor : Josep Paradells UPC (Universitat Politènia de Catalunya) Esola Tènia Sup erior d'Enginyeria de Teleomuniaió de Barelona ETSETB Munih (Germany) February 2009 - August 2009
Abstrat Aeronautial ommuniations have b een evolved and hanged radially during the last years and still doing so. Moreover, passenger ommuniations are going to b eome widespread in the nearly days. The needs for data transmissions is inreasing very fast, and the information exhange among all the parties involved in air tra management are demanding b etter and faster ways to transmit. In the future there will b e muh more airraft tra ompared to to day, and the apaity provided by urrently available ommuniation tehnology will not b e enough to manage these airrafts. Furthermore, providing new link tehnologies with higher apaity will not b e suient. In order to meet these future requirements, new networking onepts have to b e develop ed. Nowadays, one of the main problems in the airraft tra ommuniations (ATC) is the delay aused by the long distane that the signal has to pass through from the airplane to ground networks and vie versa. Also, when an airplane is moving and has to hange its p oint of attahment as it moves from one satellite over zone to another, another delay is pro dued in the ommuniation. Mobility handovers are just one asp et very imp ortant to b ear in mind in the design of the future aeronautial ommuniation. These drawbaks an b e solved using the new Internet Proto ol version 6 (IPv6) whih many networks are starting to use, replaing the urrent IPv4. Thanks to that new proto ol and its extensions, it an b e p ossible to reate and p erform new mehanisms that bring b etter b enets to mobile ommuniations. Mobile proto ols like Mobile IPv6 and NEMO, make p ossible the development of new tehnologies that p ermit entire networks to hange their p oint of attahment through dierent networks without having to hange their IP addresses. Thus, this pro jet deals the way to improve this mobility handlings and redue the delays pro dued in the atual airraft network handovers. To solve the problem, new ways will b e studied and new appliations develop ed to ameliorate the air tra management (ATM) using the new IPv6 proto ol and its mobile extensions that, as it will b e seen, will p ermit to have multiple routes b etween the airraft mobile network and the home base ground agent. That allows to share load and avoids to have to wait to make the transition from one p oint of attahment to another. i
Within the mark of the NEWSKY pro jet [1℄, we will design an aeronautial ommuniation system using those new mehanisms, whih will b e tested through real airraft ommuniation appliations to obtain onlusions of the new b enets. To have seamless handovers b etween a terrestrial link and a satellite link in an airplane-base ground ommuniation is one of the main ob jetives. This pro jet desrib es the design of a network test-b ed to simulate network handover b etween satellite and terrestrial ommuniation links based on MIPv6, NEMO, Mobile IP handover ahievement and TCP b ehaviour. Also, to improve seamless handovers and to bring new features like load balaning and routing p oliies, various solutions are searhed and disussed. The Multiple Care-of Addresses Registration extension proto ol (MCoA) solution is the one that will b e implemented and several test simulations will b e done to haraterize its b ehaviour in the test-b ed.
Contents Abstrat i List of Figures vii Abbreviations xi 1 Intro dution 1 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Bakground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1 NEWSKY pro jet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.2 TriaGnoSys lab oratory test-b ed . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 IPv6 and MIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6 Struture of this do ument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2 Internet Proto ol version 6 9 2.1 Intro dution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 The TCP/IP stak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 iii
2.2.1 Funtionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3 Dierenes b etween IPv4 and IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4 Basi IPv6 harateristis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.1 IPv6 header struture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.2 The addressing arhiteture and representation . . . . . . . . . . . . . . . 18 2.5 Intranetwork ommuniation: ICMPv6 . . . . . . . . . . . . . . . . . . . . . . . . 23 2.6 Auto onguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.6.1 Statefull Automati Conguration . . . . . . . . . . . . . . . . . . . . . . 25 2.6.2 Stateless Automati Conguration . . . . . . . . . . . . . . . . . . . . . . 25 2.7 Transition mehanisms b etween IPv4 and IPv6 . . . . . . . . . . . . . . . . . . . 25 2.7.1 Dual Stak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.7.2 IPv4 Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3 Mobility senario 29 3.1 Intro dution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2 The mobility problem and rst solutions . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.1 The solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3 Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.1 Requirements for Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.4 MIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.4.1 The senario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.4.2 Mobile IPv6 op eration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.4.3 Basi MIPv6 harateristis . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.5 IPv6 Mobile Networks: the NEMO proto ol . . . . . . . . . . . . . . . . . . . . . 41 3.5.1 Intro dution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.5.2 Op eration of the NEMO Basi Supp ort Proto ol . . . . . . . . . . . . . . 43 3.5.3 NEMO Proto ol Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.5.4 Appliations of NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.5.5 Sub-optimality with NEMO proto ol . . . . . . . . . . . . . . . . . . . . . 47 3.5.6 Future Work for NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4 Multiple Care-of Address registration extension proto ol 51 4.1 Multiple Care-of Address Registration mehanism . . . . . . . . . . . . . . . . . . 52 4.1.1 Proto ol harateristis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2 Binding Up date message arhiteture . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.3 Binding Identier mobility option . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.4 Multiple Bindings Management and p oliy routing . . . . . . . . . . . . . . . . . 55 5 NEWSKY Test-b ed 57 5.1 The real arhiteture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.2 Conguration of the test-b ed: proto ols and mehanisms . . . . . . . . . . . . . . 59 5.2.1 Network arhiteture and XEN mahines . . . . . . . . . . . . . . . . . . . 59 5.2.2 Communiation Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.3 Appliations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.1 Voie over IP (VoIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.2 Weather Streaming Information . . . . . . . . . . . . . . . . . . . . . . . . 62 5.4 Graphial User Interfae . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.5 Simulations and study of the system using NEMO proto ol supp orted in MR and HA............................................ 63 5.5.1 Handover pro ess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.5.2 VoIP all simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.6 Simulation and study of the system using MCoA registration extension . . . . . . 73 5.6.1 VoIP all simulation with MCoA registration proto ol . . . . . . . . . . . 76 6 Prop osed future work and onlusions 85 6.1 Remaining and future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 6.2 Conlusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Bibliography 89 App endix 91
A Test-b ed arhiteture and address onguration 91 A.1 Test-b ed arhiteture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 A.2 Mobile Router Address onguration . . . . . . . . . . . . . . . . . . . . . . . . . 91 A.3 Home Agent Address onguration . . . . . . . . . . . . . . . . . . . . . . . . . . 94 B GUI soure o de and ow hart 97 B.1 GUI soure o de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 B.2 GUI Flow Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 C RTP paket delay and throughput measurements 113 C.1 Measurements using only NEMO proto ol . . . . . . . . . . . . . . . . . . . . . . 113 C.2 Measurements with MCoA registration proto ol . . . . . . . . . . . . . . . . . . . 116
List of Figures 1.1 BGAN satellite overage map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Airraft Handover Pro ess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Growth of Internet hosts [9℄ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2 TCP/IP stak with some proto ols . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3 Example of data enapsulation within an UDP datagram . . . . . . . . . . . . . . 13 2.4 IP enapsulation and deapsulation pro ess . . . . . . . . . . . . . . . . . . . . . 13 2.5 IPv4 and IPv6 headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.6 Internet transmission frame with IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 16 2.7 IPv6 basi and extension headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.8 Next Header eld example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.9 Addressing Arhiteture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.10 Uniast Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.11 Link-lo al Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.12 Site-lo al Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.13 Anyast Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.14 Multiast Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.15 ICMPv6 paket struture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.16 ICMPv6 Error and Informational messages[13℄ . . . . . . . . . . . . . . . . . . . 24 vii
1.1. Overview Also, this do ument seeks to familiarize the reader with the new proto ols implemented in NEWSKY pro jet to failitate the understanding of future pro jets in the elds of mobile ommuniations. In this intro dution hapter a small review of the aeronautial tra and ommuniations situation studied in the pro jet is exp osed. Then, the senario where the pro jet will b e develop ed is presented. Then, it is explained the main goals, prop osals and requirements of the pro jet. Finally, there is a desription of this do ument struture. 1.1 Overview The senario whih the pro jet will refer onsists of an airplane whih has a network inside, a satellite whih onnets the airraft to the ground networks and a ground station. This network omprises a WLAN used by passengers to aess the Internet and a subnetwork used to share o kpit information. All these subnetworks are attahed to a router, whih has an antenna to onnet to the stations on ground. Nowadays, satellite ommuniations [3℄ are used b eause their overage area is bigger than any other system, whih means less handovers b etween aess p oints. However, there are some problems during the ommuniations like delays and pakets lost due to the trop osphere and the long distane that the signal must pass through. As an example of a overage area of a satellite, the Inmarsat BGAN satellite, used in the test-b ed, has a orevage like the one illustrated in the Figure 1.1. Figure 1.1: BGAN satellite overage map The router on b oard is onneted to a satellite, but, while the airplane is moving and reahes the limit of the satellite overage area, it has to hange its p oint of attahment and onnet to another satellite link (see Figure 1.2). When it happ ens, the router gets a new IP address, what auses a breakdown of the ongoing onnetions. This is b eause the TCP onnetions are haraterized by the address and p ort of the soure no de and the address and p ort of the 2
1. Intro dution Figure 1.2: Airraft Handover Pro ess destination. Then, if one of these hanges, the onnetion breaks down and a new one must b e established [4℄. The plane an also hange from one satellite system to another, if the signal is stronger in the new system at one p oint during the ight. That also means a hange of address and the orresp ondent ut in the onnetions. 1.2 Bakground TriaGnoSys Company is in harge of a lab oratory test-b ed within the NEWSKY pro jet, whih has the task to demonstrate network layer handovers in the middle of Voie over IP (VoIP) alls, and large data transfer. This pro jet will desrib e the test-b ed design and onguration and it will use it to make test simulations and to obtain onlusions from the results. 1.2.1 NEWSKY pro jet The NEWSKY pro jet (NetWorking the SKY for Aeronautial Communiations) is arried out by a group of Europ ean organizations with the aim to integrate dierent ommuniation tehnologies and dierent appliation lasses, into a global heterogeneous aeronautial ommuniations network with appropriate priority prop erties. As aeronautial ommuniations are going to b e radially hanged in the future, the needs for data transmission will dramatially inrease, with a view to share more and more information among all the parties involved in air tra management. It is said that in the future there will b e muh more airraft tra ompared to to day, and these airrafts an only b e managed if 3
1.2. Bakground all information related to them (p osition, altitude, intended ight path, remaining fuel...) are prop erly disseminated to all parts involved in managing them (air tra ontrollers). And this dissemination of information demands muh more apaity ompared to the one provided by urrently available ommuniation tehnology. Moreover, passenger ommuniations are going to b eome widespread in a few years. In order to meet these future requirements, NEWSKY pro jet tries to solve this problem: instead of using individual ommuniation systems for the various aviation ontrol areas and appliations, network solutions are prop osed to integrate all these systems, using as often as p ossible Commerial-O-The-Shelf omp onents. NEWSKY is a researh pro jet o-funded by the Europ ean Commission within its Sixth Framework Program (FP-6) that will enable to ahieve improved ommuniation apabilities and assists the exp eted paradigm shift in future ATM. Moreover, real air-ground integration is ahieved and System Wide Information Management (SWIM) is made available to the airraft. As a onsequene, the NEWSKY approah supp orts the realization of the Single Europ ean Sky onept and helps to reate a future Europ ean ATM system[1℄. 1.2.1.1 NEWSKY hallenges, ativities and b enets The main ob jetives and ativities arried out by NEWSKY are: Goals NEWSKY aims to oer global information availability and sharing that will solve the problem of ATM saturation. To pursue this global situation of "Networking the Sky", NEWSKY will integrate dierent ommuniation links and tehnologies. Conerning data links, it is working in dierent links to fulll the ATM ommuniation requirements, and new future ones will b e develop ed, with links ommuniations like ground-based ommuniations, satellite-based ommuniations, air-air ommuniations and ommuniations in and around airp orts. Also, the pro jet will integrate dierent appliations and servies in the same network. It will try to put together up-to-date servies and appliations like ATS (Air Tra Servie), AOC (Airlane Op erational Communiations), Airline Administrative Communiations (AAC) and APC (Air Passenger Communiations) into a single, seamless aeronautial network. This pro jet tries to develop and design an integrated aeronautial ommuniation network fo using on air-ground ommuniation with IPv6 tehnologies, using well proven industry standards to enable a ost-eient global provision of distributed servies. Ativities The rst ativity of NEWSKY is to identify appliation senarios and servie requirements. Then, a business ase study is onduted, with the development of a transition roadmap and a long-term evolution. The main part and hallenge of the pro jet is the development of a networking onept, omprising: • The proto ol stak arhiteture development, inluding standard interfaes to radio link layers. 4
1. Intro dution • The mobility management, inluding handover tehniques, routing and multihoming. • The Quality of Servie management. • The development of network seurity solutions. At the end, the NEWSKY integrated airb orne network design will b e validated by means of omputer simulations, and a lab oratory test-b ed. Benets NEWSKY will bring signiant b enets: • An inreased availability and reliability through the eient use of dierent ommuniation links. • A globally optimized network p erformane, oming from the use of the right ommuniation link. • Tehnology at the right plae and time. • An interop erability b etween the dierent ommuniation links resulting in a seamless system, whih will b e fully transparent to end users. • A mo dular system onept, whih enables the simple intro dution of new tehnologies. • An eient and exible utilization of the overall aeronautial frequeny sp etrum. 1.2.2 TriaGnoSys lab oratory test-b ed The TriaGnoSys Company is one of the memb ers of the NEWSKY pro jet, whose ontributions onsist of a Business Case Study and a Lab oratory Test-Bed demonstration, whih are aimed at demonstrating handovers pro edure b etween a terrestrial and a satellite links and validate seamless handovers. In order to make the demonstration as realisti as p ossible, typial aeronautial appliations will b e develop ed, like voie ommuniation, pilot-ontroller messaging and data streaming information through advaned weather multiast appliations [5℄. 1.2.2.1 Senario The senario where the pro jet will b e develop ed represents a network inside an airraft moving with dierent ommuniation links and with dierent appliations and mehanisms. The onguration of the test-b ed and its omp onents and proto ols will b e exp osed in detail in hapter 5, but here a short desription of them is exp osed: 5
1.3. IPv6 and MIPv6 1. New proto ols The test-b ed is implemented with the new network-layer version proto ol, the IPv6, as it is sp eied in the NEWSKY requirements. It oers more advantages ompared to IPv4. To improve seamless handovers for mobile hosts and networks, IPv6 extensions are used to supp ort mobility. That is why the Mobile IP proto ol, and its extension to mobile networks NEMO (NEtwork MObility), has to b e deployed. However, b eause the satellite network used is established over IPv4, it requires the use of a transition mehanism b etween our IPv6 network and the IPv4 satellite network. In Chapter 2 these proto ols are desrib ed. 2. Terrestrial and Satellite Links In order to rereate the terrestrial and satellite links, there are two p ossibilities: either emulating the mo dem and link b ehaviour, or using a real mo dem and link. For the terrestrial link, a B-AMC (Broadband - Aeronautial Multi-arrier Communiations) mo dem emulator will b e used. Conerning the satellite link, the real Inmarsat BGAN mo dem will b e employed. In Chapter 5, their main harateristis are detailed. 3. Appliations During the handover demonstration, several appliations (desrib ed in Setion 5.3) will have to b e running, suessively or at the same time, in order to qualify the eet of the handover and tra delays on these appliations: • Voie over IP, to make p ossible the ommuniation b etween the pilot and the ontroller. • Pilot - Controller messaging. • Weather streaming information, whih represents data ommuniations. 4. Demonstration GUI In order to make the presentation of the test-b ed learer and more onvining, a demonstration GUI (Graphial User Interfae) program is develop ed, whih displays a ight senario, and some imp ortant information ab out the whole system, in order to have an idea of the test-b ed system b ehaviour. 1.3 IPv6 and MIPv6 In the last few years, the IPv6 proto ol has b een designed as a new network-layer proto ol version to improve and resolve several problems that app eared with the urrent IPv4. As it will b e explained in Chapter 2, for example, the numb er of hosts to join Internet is inreasing and the IPv4 spae address is almost full, so a solution was required. The IPv6 brings this solution as it has more address spae as the addresses length is inreased, whih reahes 128 bits, whereas in IPv4 only 32 bits are used. From the b eginning, many organizations, like the IETF group (Internet Engineering Task Fore), have develop ed the IPv6 and several extensions that allow to solve the problems not only 6
1. Intro dution of limited address spae but also in many other areas where IPv4 ould not fae [6℄. With IPv6, air tra management will b e improved, and thanks to its mobility extensions, mobile networks will take an imp ortant part in airraft ommuniations. Those are the reason NEWSKY wants to use it. Due to the great imp ortane IPv6 will have in the near future and b eause it is an imp ortant mehanism used in the test-b ed of the pro jet, in Chapters 2 and 3 the IPv6 proto ol and its mobility extensions are desrib ed in detail. 1.4 Goals The ob jetive of this pro jet is to design a new aeronautial system based on a mobile network inside planes with new appliations and servies whih will b e able to hange its p oint of attahment with small delays. A study of its b ehaviour is arried out to see the issues that an b e improved as well as to ameliorate the proto ols implemented to obtain b etter ommuniations handovers. For that, several measurements using real ommuniation appliation systems, like voie over IP, will b e done to verify the b ehaviour of the system during simulated ights (where the mobile network hanges its p oint of attahment over dierent links) and to obtain results with the aim to get onlusions for future improvements. To reah this purp ose, it will b e used new mobile proto ols, suh as Mobile IPv6 proto ol and NEMO extensions. After a theoretial denition of those proto ols to get used to the new senario, they will b e implemented in the test-b ed where simulations using typial aeronautial appliations will b e done to see the improvements of seamless handovers and routing pro esses in air tra ommuniations. This pro jet also disusses the p ossibility to improve seamless handovers using reent develop ed mehanisms like MCoA extension proto ol, whih nally will b e implemented to the test-b ed and tested to see the improvements or not regarding the rst onguration. 1.5 System requirements The NEWSKY test-b ed should b e able to provide the following requirements: • Provide a mobile network transparent in front of the hange of the p oints-of-attahment during the handovers. • Users should not notie handovers b etween the dierent ground-satellite links. • The Quality of Servie should b e maintained and not redued. • It should supp ort Seurity Proto ols and VPN. • It should hange the funtionalities of existing proto ols as less as p ossible. • It should add small signaling and data overhead, when dealing with mobility as well as IPv6 over IPv4 links. 7
1.6. Struture of this do ument 1.6 Struture of this do ument The do ument b egins with a theorial explanation of the proto ols used in TriaGnoSys testb ed, as well as the MCoA registration proto ol as will b e also implemented to improve seamless handovers. Then, in Chapter 5, rst the test-b ed onguration is exp osed and after that, it disusses the results of several VoIP alls in ight simulations to see the RTP paket delay during handovers. With this results, it ompares the system b ehaviour b etween using only NEMO pro otol and implementing the MCoA extension proto ol. Finally, the do ument nishes with a onlusion. 8
Chapter 2 Internet Proto ol version 6 Internet is almost everywhere so it is not strange that nowadays the ma jority of entities are getting into its world. The worst issue related to that growth has b een the huge numb er of hosts that are onneting to the Internet, and the asso iated IP addresses that are b eing onsumed by those hosts [6℄. The most used IP proto ol in our days, the IPv4, is having some problems with this growth, so the IETF and other organizations started to searh for new solutions. The results of this researh was the new network-layer proto ol version IPv6 whih have solved all IPv4 drawbaks and improved new features. That is the reason why this pro jet will use this new proto ol and its extensions in almost all its parts. The implementation of this new mehanism will allow to improve systems mobility and have b etter results in ommuniation seamless handovers and for paket delays as it has b etter mobility extensions ompared to IPv4. In this hapter it is exp osed the harateristis and the main funtionalities of the IPv6 proto ol and the most signiant hanges and improvements from its predeessor IPv4. First of all, there is an intro dution ab out why it was neessary to design a new IP proto ol. Seondly, the set of ommuniations proto ols used for the Internet and other similar networks known as TCP/IP stak, is desrib ed to intro due the IP proto ol. Next, the new IPv6 proto ol is explained fo using on the new Header and its Extension Header, and the addressing arhiteture with its new addressing typ es and funtionalities [7℄[8 ℄. Also the hanges and improvements from IPv4 are disussed. Finally, the hapter ends with the desription of dierent solutions to traverse IPv6 pakets through IPv4 links. 2.1 Intro dution Sine the early 1990, the IETF has b een developing the IPv6, a new network layer proto ol whih will substitute the IPv4. The issue that motivated its developing was mainly b eause the 9
2.2. The TCP/IP stak Figure 2.1: Growth of Internet hosts [9℄ IPv4 addresses were almost all b eing used and new address spae was required. As the Figure 2.1 illustrate, the numb er of hosts onneted to Internet and onneted domains are growing at exp onential rates, with eah of those hosts needing a unique IP identier. The urrent IPv4 address spae an identify a theoretial 4.2 billion hosts (2 32 ), what imp oses some additional onstrains to its struture. In the other hand, IPv6 has inreased it from 32 bits to 128 bits p er address. There are other related problems, suh as the limited addressing hierarhy that is p ossible within the onnes of the 32-bit IPv4 address, plus the asso iated limitations on routing funtion saling. Besides those problems, IPv6 has added more funtionalities and has improved some the extensions and other issues, suh as new mobility extensions, seurity or real-time tra handling. Also addresses an b e auto ongurated, and multiast routing has got b etter. The Internet Proto ol version 6 eort is dynami and is b eing driven by worldwide sites urrently implementing and testing its funtionality. Multiple Request for Comments (RFC) and Internet Drafts have b een written to supp ort those interested in joining the testing eort. 2.2 The TCP/IP stak The IPv6 is an Internet proto ol that takes part of the TCP/IP stak mo del, whih means Transmission Control Proto ol/Internet Proto ol. It desrib es a set of proto ols to enable omputers to ommuniate over a network, sending and reeiving data. It is based on the notion 10
2. Internet Proto ol version 6 of IP addresses and provides end-to-end onnetivity sp eifying how data should b e formatted, addressed, transmitted, routed and reeived at the destination. This onept generates an IP address for eah devie onneted to the Interned network. This mo del is onstituted by four dierent layers with their proto ols, as we an see in the Figure 2.2. Figure 2.2: TCP/IP stak with some proto ols • Link Layer The Link Layer is the lowest omp onent layer of the Internet proto ols and is used to move pakets from a host to another physially onneted system plaed on the same link. TCP/IP is designed to b e hardware indep endent. As a result TCP/IP has b een implemented on top of virtually any hardware networking tehnology in existene, what allows them to adapt themselves to every new tehnology. The TCP/IP mo del inludes sp eiations of translating the network addressing metho ds used in the Internet Proto ol to data link addressing, suh as Media Aess Control (MAC), however all other asp ets b elow that level are impliitly assumed to exist in the Link Layer, but are not expliitly dened. • Network Layer The Network Layer solves the problem of sending pakets aross one or more networks. It has to analyze the datagrams reeived in the lower layer to determine if they are addressed or not. If it is the ase, it deapsulates the paket header and transmits the rest of the 11
2.4. Basi IPv6 harateristis • Routing header: This header lists one or more intermediate no des that are "visited" on the path from the soure to the destination. • Fragment header: It is used by an IPv6 soure to send pakets that are larger than would t in the path Maximum Transmission Unit (MTU) to their destinations. Fragmentation for IPv6 is only done at the soure no de, not at intermediate routers along the paket's delivery path (dierent from IPv4). • Enapsulating Seurity Payload Header: It is designed to provide ondentiality, data origin authentiation, onnetionless integrity and limited tra ow ondentiality. • No next header: It indiates that nothing follows that header. Extension headers may also employ a Next Header eld, linking to a subsequent extension header. Figure 2.8 illustrates how the Next Header eld lo ate the ontents of the paket for the router to interpret and pro ess. Figure 2.8: Next Header eld example 2.4.2 The addressing arhiteture and representation There are three dierent typ es of addresses, that varies somehow from the IPv4 addresses [11℄: • Uniast: is an identier to a single interfae. A paket sent to an uniast address is delivered to the interfae identied by that address. There are 3 sub ategories of uniast addresses: 18
2. Internet Proto ol version 6 Link-Lo al Addresses: are designed to b e used on a single link for the purp oses of address auto onguration and neighb our disovery, and for ommuniation b etween hosts when no routers are present on the link. Pakets ontaining link-lo al addresses, must never b e forwarded by routers or travel outside the lo al link. Site-Lo al Addresses: may b e used by a organization that is not onneted to the global Internet. Pakets ontaining site-lo al addresses must never b e forwarded by routers outside of the site in whih these addresses are b eing used. Globally Routable Addresses: must b e used by no des whih wish to ommuniate with other no des b oth outside of their own link and of their own site. A paket destined to a globally routable address may b e forwarded by routers and may b e sent from anywhere. • Anyast: is an identier for a set of interfaes (typially b elonging to dierent no des). A paket sent to an anyast address is delivered to one of the interfaes identied by that address (the nearest one, aording to the routing proto ol's measure of distane). • Multiast: is an identier for a set of interfaes. A paket sent to a multiast address is delivered to all interfaes identied by that address. The main dierene from IPv4 is that now the broadast funtion is done by the multiast denition. Another dierene is that in IPv6, addresses of all typ es are assigned to interfaes, not no des (one no de may have multiple interfaes). 2.4.2.1 Address representation The format of the IPv6 addresses onsists of three parts: an Address Prex, a Site Identier and a Host Identier. IPv6 addresses are 128 bits long, represented by groups of 16 bits dened in hexadeimal and separated by olons: x:x:x:x:x:x:x:x where eah x represents 16 bits. Eah of those 16 bits setions is dened in hexadeimal. An example ould b e: 2312 : 6453 : 3045 : 5500 : 6368 : 9463 : 0023 : 3344 If the address has groups of zeros, they an b e eliminated: 1932 : 0000 : 0000 : 0000 : 4324 : 0430 : 0032 : 5543 1932 :: 4324 : 430 : 32 : 5543 The double olon is restrited to app earing only one in an address. In text, it is ommon to represent them by address and prex length: 19
2.4. Basi IPv6 harateristis IPv6address/prefixlength 1234 : 0000 : 0454 : 6582 : 4332 : 4323 : 0000 : 0000/64 In that ase, the prex is: 1234000004546582 2.4.2.2 Addressing arhiteture To provide maximum exibility for b oth urrent and future address representation, the address may b e divided into a numb er of subelds. The leading bits alled the Format Prex, dene the sp ei typ e of IPv6 address. A multiast address b egins with the binary value 11111111; any other prex identies a uniast address. Anyast addresses are part of the allo ation for uniast addresses and are not given a unique identier. The Figure 2.9 shows the list of dierent address prexes. 2.4.2.3 Uniast addresses There are many forms for IPv6 uniast addresses. The most simple form is a uniast address with no internal struture, with no address-dened hierarhy. The other p ossibility is to sp eify a Subnet Prex within the 128-bit address, thus dividing the address into a Subnet Prex (with n bits) and an interfae ID (with 128-n bits)(Figure 2.10). The address 0:0:0:0:0:0:0:0 is dened as the unsp eied address, that indiates the absene of an address. It is used on startup when a no de has not yet an address assigned. The address 0:0:0:0:0:0:0:1 is dened as the lo opbak address. It is used by a no de to send a paket to itself. 2.4.2.4 Lo al Use Addresses • The link-lo al address is used for a single link and is intended for auto-address onguration, neighb our disovery or for ommuniation b etween hosts when no routers are present on the link. The link-lo al address b egins with the Format Prex 1111111010 and inludes a 64-bit interfae ID eld. Routers never forward pakets with link-lo al soure or destination addresses to other links (Figure 2.11). • The site-lo al address is used by organizations that have not yet onneted to internet. Routers never forward pakets with site-Lo al soure addresses outside of that site (Figure 2.12). 2.4.2.5 Anyast addresses An anyast address is one that is assigned to multiple interfaes, typially on dierent no des. A paket with an anyast destination address is routed to the nearest interfae that has that address. It is used to identify a set of routers attahed to a partiular subnet or for identifying a set of routers that provide entry to a partiular routing domain. Those addresses must not b e used as a soure address for an IPv6 paket and may only b e assigned to routers, not hosts (Figure 2.13). 20
2. Internet Proto ol version 6 Figure 2.9: Addressing Arhiteture 2.4.2.6 Multiast addresses The multiast address identies a group of no des and eah of these no des may b elong to multiple multiast groups. The multiast address b egins with the format prex 1111111 and inludes 21
2.4. Basi IPv6 harateristis Figure 2.10: Uniast Addresses Figure 2.11: Link-lo al Addresses Figure 2.12: Site-lo al Addresses three additional elds. The Flags eld ontains four one-bit ag. The Sop eld is a four-bit eld that is used to limit the sop e of the multiast group. The Group ID eld identies the multiast group, either p ermanent or transient, within the given sop e. Multiast addresses may not b e used as soure addresses in IPv6 datagrams or app ear in any routing header (Figure 2.14). 22
2. Internet Proto ol version 6 Figure 2.13: Anyast Addresses Figure 2.14: Multiast Addresses 2.5 Intranetwork ommuniation: ICMPv6 The ICMPv6 messages (Internet Control Message Proto ol) are used to rep ort paket pro essing errors, intranetwork ommuniation path diagnosis and multiast memb ership rep orting. They are ontained within IP datagrams, with the IP header preeding the ICMP message and ICMP data. The new ICMP version 6 is an evolution of the ICMPv4, where the main funtionalities of the old one have b een kept and obsolete messages have b een removed for simpliation. In the RFC 1885, the proto ol is dened [12℄. ICMPv6 pakets have three elds that are ommon to all messages: Typ e, Co de and Cheksum, plus a variable length message b o dy whose ontents dep end on the typ e of the message b eing transmitted (Figure 2.15). The messages are group ed into 2 ategories: Error Messages and Informational Messages . These two ategories are identied by the high-order bit of the message Typ e eld. • The Typ e eld is a 8-bit long whih indiates the typ e of message. This eld denes the ICMPv6 Message as either an error message or an informational message. A 0 in the high order bit of this eld indiates that the message is an error message. A 1 in the high order bit indiates that the message is an informational message. In this fashion, 23
2.5. Intranetwork ommuniation: ICMPv6 Figure 2.15: ICMPv6 paket struture typ e eld deimal values from 0 to 127 are error messages, and values from 128 to 255 are informational messages. • The Co de is a 8-bit eld whih reates an additional level of message. • The Cheksum is a 16-bit eld used to detet errors in the ICMP message. The Error Messages b elong to 4 ategories: Destination Unreahable, Paket To o Big, Time Exeeded and Parameter Problem. In the other hand, there exist eleven Informational Messages. The Figure 2.16 lists all error and informational messages with their resp etive Typ e value. Figure 2.16: ICMPv6 Error and Informational messages[13℄ 24
2. Internet Proto ol version 6 2.6 Auto onguration Unlike IPv4, IPv6 proto ol has two metho ds for obtaining addresses: the Stateless mehanism and a Stateful l mehanism. 2.6.1 Statefull Automati Conguration In a Statefull Auto onguration mo del, hosts obtain information of addresses onguration, parameters, et, from a server. That server maintains a database ontaining the neessary information and keeps tight ontrol over the address assignment. The Statefull Auto onguration mo del for IPv6 is dened by the prop osed Dynami Host Conguration Proto ol for IPv6 (DHCPv6) like IPv4 [14℄. This onguration mehanism is based on the version used for IPv4. 2.6.2 Stateless Automati Conguration Stateless Automati Conguration is a new proto ol designed for IPv6. This mo del requires no manual onguration or hosts, minimal onguration of routers and no additional servers. The stateless approah is used when a site is not onerned ab out the sp ei addresses that are used, as long as they are unique and routable. With Stateless Auto onguration, a host generates its own address derived from the MAC address of the network interfae, and using a sp ei algorithm. In IPv6, the rst 64 bits orresp ond to the subnet prex, and the last 64 bits are the lo al identier. This lo al identier will b e built using the 48 bits-MAC address. But Stateless Automati Conguration an also b e used to reate global IPv6 addresses. This requires the use of ICMPv6 Router Advertisement messages. In a lo al network, the routers send Router Advertisement messages, with the 02::1 destination address, whih orresp onds to the multiast group. These messages ontain the global 64 bits-prex, that will b e used by the hosts of the network to reate global addresses, app ending their lo al identier sux. Beause Router Advertisement messages are usually sent every 10 seonds, the hosts an stimulate the sending of Router Advertisements, using Router Soliitation messages, sent to the 02::2 (all-router multiast group) destination address. 2.7 Transition mehanisms b etween IPv4 and IPv6 As it was said b efore, nowadays there are many devies and networks that have IPv6 proto ol implemented, but IPv4 is still present everywhere. Thus, some mehanisms are needed to p ermit the interation b etween IPv6 devies with the ones with IPv4 implemented. In the test-b ed of this pro jet, there is a problem onerning that issue: the satellite link used may not b e upgraded to IPv6 at the same time as the airrafts, so only IPv4 is implemented. Then, ways to send version 6 pakets over this link should b e develop ed. In this study, a manual tunnel mehanism and a proto ol translation are implemented in the test-b ed in Linux. 25
2.7. Transition mehanisms b etween IPv4 and IPv6 At the time the new IP proto ol was designed, a simple and exible transition b etween IPv4 and IPv6 was required. By reating IPv6 in IPv4 mehanism, o-existene of the two proto ols is p ossible, so users an reate IPv6 links to take advantage of IPv6 while allowing the rest of their lo al network to upgrade as neessity arises. There are several kinds of transition mehanism, that an b e divided in two groups: the dual stak and the IPv4 link mehanism. 2.7.1 Dual Stak In this ase, a host or router have the two IP proto ol versions. Eah no de has two addresses: an IPv4 and an IPv6 addresses. Then, the no de an send and reeive messages b elonging either one proto ol or the other. This is the easiest metho d, but also the most exp ensive as it implies providing omplete implementations of b oth versions of the Internet Proto ol. Also, as pakets are not mo died nor added a header, the pro essing time and the bandwith used are less than other solutions. 2.7.2 IPv4 Link There are two solutions in that ase: • Tunneling mehanisms • Translation mehanisms 2.7.2.1 Tunneling mehanisms Tunneling is a pro ess where information from one proto ol is enapsulated inside the frame or paket of another one, thus enabling the original data to b e arried over that seond arhiteture. Thus the tunneling mehanism for IPv4/IPv6 is designated to enable an IPv4 infrastruture to arry IPv6 pakets by enapsulating the IPv6 information inside IPv4 datagrams (see Figure 2.17). Examples of tunneling mehanisms are the 6to4 tunnel, 6over4 tunnel and L2TP tunnel. The L2TP tunnel mehanism is desrib ed next as it is the one used in the test-b ed. 2.7.2.1.1 L2TP tunnel The Layer 2 Tunneling Proto ol is a tunneling proto ol used to supp ort Virtual Private Networks (VPN). Its name omes from the fat that L2TP allows to arry Point-to-Point Proto ol (PPP) frames over an IP network, b etween two end p oints. It was published in 1999, as prop osed standard RFC 2661 [15℄. Originally, it was develop ed in order to bring together the funtionalities of two older tunneling proto ols for PPP : Ciso's Layer 2 Forwarding (L2F) and Mirosoft's 26
2. Internet Proto ol version 6 Figure 2.17: The tunneling mehanism Point-to-Point Tunneling Proto ol (PPTP). A new version of this proto ol, L2TPv3, provides additional seurity features, improved enapsulation, and the ability to arry data links other than simply PPP over an IP network (Frame Relay, Ethernet, ATM, et...). But L2TP is atually a session layer (layer 5) proto ol, and uses the registered UDP p ort 1701. The overhead indued by L2TP reahes 37 bytes, whih is quite a big overhead. Moreover, L2TP do es not provide ondentiality or strong authentiation by itself. That is why IPse (Internet Proto ol Seurity) is often used to seure L2TP pakets by providing ondentiality, authentiation and integrity. But this makes the overhead even bigger. The two endp oints of an L2TP tunnel are alled the LAC (L2TP Aess Conentrator) and the LNS (L2TP Network Server). The LAC is the initiator of the tunnel, whereas the LNS is the server whih waits for tunnel requests. The neessary setup for tunneling a PPP session with L2TP onsists of two steps: 1. The LAC sends a request to the LNS in order to reate an L2TP Tunnel. Then, a Control Connetion Establishment signaling is p erformed, and the L2TP tunnel is set up. 2. One the tunnel is established, the network tra b etween the two p eers is bidiretional. In order to arry PPP frames through the tunnel, either the LAC or the LNS has to initiate a session, making a all through the tunnel. The tra for eah session is isolated by L2TP, so it is p ossible to establish multiple sessions aross a single tunnel. The pakets exhanged within an L2TP tunnel are ategorized as either ontrol pakets or data pakets. L2TP provides reliability features for the ontrol pakets, but no reliability for data pakets. Reliability for data pakets, if desired, must b e provided by the proto ols running within the session of the L2TP tunnel. 27
3.4. MIPv6 Figure 3.1: Mobile IPv6 senario sent to the Mobile No de. Consequently, the Home Address has to b e plaed in the IP address eld of its entry in the Domain Name System, so that other no des lo oking up the Mobile No de's hostname will nd it. When the Mobile No de moves from the home network to a foreign link, the following op erations are done: 1. The Mobile No de needs to obtain a new address to join the foreign network, but should not lo ose his Home Address to prevent a disonnetion of the urrent sessions. Then, when a Mobile No de joins to the new link, it gets a new address a well as the Home Address, alled Care-of Address (CoA). This new address asso iated with the moving host while visiting a foreign link, has the foreign subnet prex (of the foreign network) as its subnet prex. To get it, the Mobile No de p erforms an address auto onguration, as we will explain in Setion 3.4.2.1. This new address is advertised in one of the elds of the Router Advertisement messages sent by the Aess Router. As we an see in Figure 3.2, the prex of the Foreign Network is 2001:3::/64 and the new Care-of Address is 2001:3::230:5:fed3:518. 2. Consequently, the Mobile No de registers the Care-of Address aquired with its Home Agent, using a message-exhange dened by Mobile IPv6 proto ol. In the registration pro edure, the Mobile No de asks for servie from the Aess Router of the new link. In order to prevent remote denial-of-servie attaks, the registration messages are required to b e authentiated. The asso iation b etween a Mobile No de's Home Address and Care-of Address is known as a binding . The moving host p erforms this binding registration by sending a Binding Up date (BU) message to the HA as we an see in Figure 3.3. It replies to the Mobile No de by returning 34
3. Mobility senario Figure 3.2: Mobile No de visiting a foreign network a Binding Aknowledgment (BA) message saying that it has registered the Care-of Address in its binding ahe. The binding ahe is an address entry table used to asso iate the CoA with the Home Address of every Mobile No de visiting a foreign network. On the other side, the Mobile No de has also a Binding Up date list, where it has an item for every binding that the no de has or is trying to establish. Communiation b etween Mobile No de and Corresp ondent No de A Corresp ondent No de (CN) is any foreign network host that wants to ommuniate with the Mobile No de. When they try to establish a onnetion, the following op erations are done: 1. The CN sends an IP paket addressed to the p ermanent IP address of the Mobile No de, that is, the Home Address. 2. The Home Agent interepts the paket as it is sent to the MN's home link and onsults the mobility binding ahe table to nd out if the MN is already visiting any other network or otherwise is at "home". 3. In ase that the MN is in a foreign network, the Home Agent nds out the MN's Care-of Address and onstruts a new IP header that ontains the MN's Care-of Address as the destination IP address. The original IP paket is put into the payload of this IP paket and ready to b e sent. This pro ess of enapsulating one IP paket into the payload of another one is known as tunneling . In the example b eing used, the Home Agent would tunnel the IP paket like the way shown in the Figure 3.4 35
3.4. MIPv6 Figure 3.3: The binding op eration b etween Mobile No de and Home Agent Figure 3.4: IP paket tunneling 4. When the enapsulated paket reahes the Aess Router of the foreign network, the original paket is extrated from the tunnel and then delivered to the MN. It means that in b oth diretions, pakets are enapsulated in the Home Agent and deapsulated in the Aess Router. In the Figure 3.5 we an see the path that a paket sent by the Corresp ondent No de to the Mobile Router would follow. There are two p ossible mo des to establish ommuniation b etween Mobile No de and a Corresp ondent No de. • The rst mo de, bidiretional tunneling , do es not require Mobile IPv6 supp ort from the CN and is available even if the MN has not registered its urrent binding with the CN. As we an see in Piture 3.6, pakets from the CN are routed to the Home Agent and then tunneled to the MN and, in the other side, pakets to the CN are tunneled from MN to the Home Agent ("reverse tunneled") and then routed normally from the home network to the CN. This tunneling is p erformed using IPv6 enapsulation. 36
3. Mobility senario Figure 3.5: IP paket tunneling pro ess in MIPv6 • The seond mo de, route optimization , requires the Mobile No de to register its urrent binding at the CN. As illustrated in Figure 3.7, pakets from CN an b e routed diretly to the Care-of Address of the MN without visiting the Home Agent. When sending a paket to any IPv6 destination, the CN heks its ahed bindings for an entry for the paket's destination address. If a ahed binding for this destination address is found, the no de uses a new typ e of IPv6 routing header to route the paket to the Care-of Address indiated in this binding. Routing pakets diretly to the MN's Care-of Address allows the shortest ommuniations path to b e used. It also eliminates ongestion at the Mobile No de's Home Agent and home link. In addition, the impat of any p ossible failure of the Home Agent or networks on the path to or from it is redued. But on the other hand, the CN has to b e implemented with Mobile IPv6 tehnology. 37
3.4. MIPv6 Figure 3.6: Bidiretional tunneling Figure 3.7: Route optimization 38
3. Mobility senario 3.4.2.1 How do es a Mobile No de obtain a Care-of Address? There are two metho ds in order to aquire a Care-of Address: the Stateful and the Statless Address Auto onguration. The Router Advertisements sent by the Aess Router and reeived by the Mobile No de, arries the information that determine whih metho d should b e used [19 ℄. Stateful Address Auto onguration In this metho d, the Mobile No de simply asks a server for an address and uses it as a Care-of Address. In that ase, it also uses the proto ol for stateful address assignment for normal IPv6 proto ol: the Dynami Host Conguration Proto ol for IPv6 (DHCPv6). Stateless address auto onguration Mobile no des an also aquire a Care-of Address by Stateless Address Auto onguration. It works as follows: • The Mobile No de rst forms a link-dep endent identier for the interfae by whih it onnets to the foreign link. This identier is typially the no de's link-layer address on that interfae. For example, on Ethernet, the identier would b e the Mobile No de's 48-bit Ethernet address. • The Mobile No de examines the Prex Information Options that are ontained within Router Advertisements to determine the valid network-prexes on the urrent link. • The Mobile No de forms a are-of address by onatenating one of the valid network-prexes with the identier. Address auto onguration (stateful and stateless ones) ontains mehanisms by whih a no de an determine whether the address it has aquired is idential to an address b eing used by any other no de on the link. If there is suh a dupliate address, then the auto onguration proto ols dene ways in whih a unique address an b e aquired by the no de. 3.4.3 Basi MIPv6 harateristis 3.4.3.1 The Mobility Header The new feature that Mobile IPv6 brings to the IPv6 proto ol arhiteture is the Mobility Header. It is a new IPv6 extension header designed to ontain the MIPv6 signaling messages whih makes p ossible the mobility mehanism. The Mobility Header is used by Mobile No des, Home Agents and Corresp ondent No des (in ase of route optimization) for all messaging related on binding reation and management. The format of this header is illustrated in the Figure 3.8. The elds are: • Next Header: 8-bit seletor. Identies the typ e of header immediately following the Mobility Header. Uses the same values as the IPv6 Next Header eld. 39
3.4. MIPv6 Figure 3.8: The Mobility Header Format • Header Len: 8-bit unsigned integer, representing the length of the Mobility Header in units of 8 o tets, exluding the rst 8 o tets. The length of the Mobility Header has to b e a multiple of 8 o tets. • MH Typ e: 8-bit seletor. Identies the partiular mobility message in question. • Reserved: 8-bit eld reserved for future use. • Cheksum: 16-bit unsigned integer. This eld ontains the heksum of the Mobility Header. It is alulated from the o tet string onsisting of a "pseudo-header" followed by the entire Mobility Header starting with the Payload Proto eld. • Message Data: A variable length eld ontaining the data sp ei to the indiated Mobility Header typ e. The Mobility Header is identied by a next header value of 135 (deimal) in the IPv6 base header (or an alternative preeding optional header if there is one). The MH Typ e eld identies the sp ei mobility message in question and an b e one of the following: • Home Test Init (HoTI) • Care-of Test Init (CoTI) • Home Test (HoT) • Care-of Test (CoT) • Binding Request (BR) • Binding Up date (BU) • Binding Aknowledgement (BA) • Binding Missing (BM) 40
3. Mobility senario The Home Test Init, Home Test, Care-of Test Init and Care-of Test are four messages used to p erform the return routability pro edure from the Mobile No de to a Corresp ondent No de. Binding Up date: as was said b efore, a Binding Up date is used by a Mobile No de to notify the Mobile No de's Home Agent or a orresp ondent no de of its urrent binding. Binding Aknowledgement: A Binding Aknowledgement is used to aknowledge reeipt of a Binding Up date, if an aknowledgement was requested in the Binding Up date, the binding up date was sent to a Home Agent, or an error o urred. Binding Refresh Request: A Binding Refresh Request is used by a Corresp ondent No de to request a Mobile No de to re-establish its binding with the orresp ondent no de. This message is typially used when the ahed binding is in ative use but the binding's lifetime is lose to expiration. The Corresp ondent No de may use, for instane, reent tra and op en transp ort layer onnetions as an indiation of ative use. Binding Error: The Binding Error is used by the Corresp ondent No de to signal an error related to mobility, suh as an inappropriate attempt to use the Home Address destination option without an existing binding. 3.5 IPv6 Mobile Networks: the NEMO proto ol Nowadays, it exists many mobile platforms that provision Internet aess like planes, trains, ars, et, making it neessary to supp ort the mobility of omplete networks inside those vehiles and not only of one host. As said in Chapter 1, the senario studied omprises a network inside an airraft moving, whih means that many users should onnet to the Internet. A rst solution of that new situation ould b e enabling no de mobility supp ort in all hosts of the moving network, so they ould indep endently manage their mobility. However, it implies several problems: it would require all devies to b e apable to supp ort Mobile IP what would generate exess overhead as every devie has to p erform Mobile IP funtions. Moreover, it would not work b eause of the limited apaities of the no des (suh as in sensors or emb edded devies in the vehiles) or b eause it is not p ossible to up date the software in some older devies. Beause of these problems, it was needed to standardize a solution enabling network mobility at the IPv6 layer. Nowadays, a go o d solution would b e the NEtwork MObility (NEMO) Basi Supp ort Proto ol [20℄. The basi new feature of this mobile extension is the mobile router, a single entity that manages the mobility of the omplete network. No des of the mobile network will gain aess to the Internet through the mobile devie, using heap er and widely available aess tehnologies (for example, WLAN tehnology or Blueto oth). 3.5.1 Intro dution Network Mobility Basi Supp ort proto ol (NEMO) is an extension of Mobile IPv6 that enables to supp ort the movement of a omplete network that hanges its p oint of attahment to the xed infrastruture, maintaining the sessions of every devie of the network. 41
3.5. IPv6 Mobile Networks: the NEMO proto ol The most imp ortant dierene b etween the standard Mobile IPv6 proto ol and NEMO is that in that ase, instead of having a Mobile No de, we have a Mobile Router (MR) with an entire network b ehind it. This router is the only entity aware of mobility in the Mobile Network and whih onnets this network to the xed infrastruture. This is now the end-p oint of the mobility tunnel, whih is established b etween this Mobile Router and the Home Agent. The no des inside the Mobile Network are alled Mobile Network No des (MNN) and they are not aware of mobility. The end of the bidiretional tunnel at the side of the Mobile Router needs to b e up dated eah time the Mobile Network moves (and also p erio dially to refresh the binding up date at the home agent), to reet the urrent lo ation of the Mobile Router. As we will see in Setion 3.5.2, where the NEMO proto ol op eration is desrib ed, there are many similarities b etween the normal handover pro ess of a simple mobile no de and a omplete moving network. As we an see in the Figure 3.9, whih shows an example of a mobile network situation, the devies that take part of the senario are all almost the same as if we had just a simple Mobile No de. Figure 3.9: Mobile Network senario 42
3. Mobility senario 3.5.2 Op eration of the NEMO Basi Supp ort Proto ol To make easier to understand the funtion of the proto ol I will desrib e a network-mobility senario and the handovers pro ess of a mobile network through an example. A typial network mobility situation ould b e the one the Figure 3.10 depits, where there is a omplete network moving with a router and no des attahed to this mobile network. In that ase, only the router supp orts NEMO proto ol and the rest of the no des in the mobile network don't have any mobility implementation, so they see the network always in the same way like if they were not moving. The router onnets the mobile network to the Internet and plays the same role more or less as the Mobile No de in Mobile IPv6 proto ol. It is assumed that this NEMO network is assigned to a partiular network where it resides when it is not moving, known as its Home Network. The mobile network has a p ermanent prex address assigned to its home network: the Mobile Network Prex (MNP). Lo oking at the example Figure 3.10, it would b e 2001:b:1:1::/64. This address remains assigned to the NEMO network when it is away from home. All addresses b eginning with this prex have to b e routed in the Internet toward the Home Network. Of ourse, these addresses have top ologial meaning only when the NEMO network is at home. The handover op eration onsists: • The Mobile Router aquires a home address b efore moving away to a foreign network. • When the mobile network is away from home, only the Mobile Router aquires the Careof Address (CoA) from the Aess Router (AR) of the foreign network through Router Advertisements. • When the Mobile Router gets the Care-of Address it starts to send Binding Up dates (BU) to the Home Agent at the home network to register it in the binding ahe. This Binding Up date message still ontains the new primary Care-Of Address, but now also the Mobile Network Prexes. This is b eause the Home Agent has to know for whih destination addresses it has to send the pakets to the Mobile Router. • Then, the Mobile Router waits for Binding Aknowledges sent by the Home Agent. • As in an usual Mobile IPv6 proto ol senario, the Home Agent and the Aess Routers are always sending Router Advertisements to inform Mobile Routers of its p osition (if they are at home or away). Now, when any Corresp ondent No de (CN) wants to exhange information with a Mobile Network No de (MNN), the following op erations are involved in the ommuniation: 1. The paket sent by the Corresp ondent No de is routed to the Home Agent of the mobile network where it enapsulates the datagram to a new message and tunnels it to the mobile router. This datagram sent by the CN arries as its destination address the IPv6 address of the MNN, whih b elongs to the MNP of the NEMO. 43
3.5. IPv6 Mobile Networks: the NEMO proto ol Figure 3.13: Multihoming 3.5.6.3 Multiple Care-of Addresses This mehanism extension for NEMO proto ol, prop osed by Nautilus6 group, allows a Mobile Router to register several Care-of Addresses at the same time to its Home Agent. Main b enets, among others, are p oliy routing, fault tolerane for the Mobile Router, seamless handovers and load balaning. In Mobile IPv6 and NEMO proto ols, the Mobile Router an only register one Care-of Address every time, so it has just one p oint of attahment. The Home Agent an only asso iate one CoA for every Mobile Router's home address and network prex in the Binding Cahe. That is translated in delays during handovers of the mobile network, b eause every time that it moves, it has to de-register the old Care-of Address from the Binding Cahe, get another CoA of the new Aess Router and then register the new CoA again. This new mehanism p ermits the Mobile Router to b e onneted at the same time in two or more foreign networks using only one Home Address, so it p ermits to make seamless handovers and also balane the information through dierent Aess Routers. 50
Chapter 4 Multiple Care-of Address registration extension proto ol NEMO Basi Supp ort (NEMO BS) adds a mobility funtion to IPv6 routers and p ermits them to have a network b ehind, the mobile network, that b eomes logially stati. This funtion is onsidered useful when a network has a lot of no des that do not have a mobility apaity, so they an move with the network. As was explained in the previous hapter, for this funtion, a temp oral address is used, alled Care-of Address. Aording to the Mobile IPv6 and NEMO sp eiation, a Mobile No de or Mobile Router is not allowed to register more than one Care-of Addresses to a single home address. If a Mobile No de or Router sends Binding Up dates with more than one Care-of Address, Home Agents would always overwrite the Care-of Address reorded in the binding ahe with the one ontained in the latest reeived Binding Up date. So, it is imp ossible for a b oth mobile entities to register multiple Care-of Addresses in the Home Agent's binding ahe. The rst big problem with that sp eiation is that the Mobile Router and its mobile network will fae servie disruption of network onnetivity while the Mobile Router is moving from one network to another one. Thus, solutions are needed to supp ort ontinuous onnetivity allowing to have seamless handover. The test-b ed develop ed in TriaGnoSys has initially b een implemented using only NEMO extension proto ol in the Mobile Routers and Home Agents. But in order to obtain b etter seamless handovers for the mobile network ommuniations and not the disruptions mentioned b efore, some solutions were studied that ould fae those drawbaks. Thus, a new mehanism had b een implemented from a new mobile proto ol that has b een reated in the early days: the Multiple Care-of Address registration mobile extension. The Multiple Care-of Address registration mehanism is a mobile extension proto ol of IPv6 still b eing develop ed that tries to solve the problem of onnetivity disruptions in handovers, as it p ermit to register more than one Care-of Address at the same time with a unique Mobile 51
4.1. Multiple Care-of Address Registration mehanism Router and home address. I implemented it to the test-b ed system to ameliorate the handovers delays but also to study its b ehaviour and see if it ould b e a go o d mehanism for the future of aeronauti ommuniations through test simulation results. So, in this hapter I will explain the basi harateristis and funtions of the Multiple Care-of Address registration proto ol [25℄ and the advantages with resp et to the NEMO implementation. 4.1 Multiple Care-of Address Registration mehanism Multiple CoAs Registration mehanism makes p ossible to use multiple network interfaes on- urrently at the Mobile Router in a mobile network as it p ermits to register Multiple Care-of Addresses b ound to a single Home Address instead of the unique primary Care-of Address. Without MCoA, it is imp ossible to avoid the servie disruption during handovers. If multiple network interfaes onurrently an b e used in a Mobile Route, then it an prepare a network interfae for a new foreign network to where the it is going to move, b efore disonneting from the old foreign network. This extension is targeted to NEMO (NEtwork MObility) Basi Supp ort as well as to Mobile IPv6, what it means that an b e applied to a Mobile Router and to a Mobile No de. [26℄ 4.1.1 Proto ol harateristis The basi new addition brought by this new mobile extension that p ermits Mobile No des and Mobile Routers to register multiple Care-of Addresses to a single home address and reate multiple binding ahe entries in the Home Agent, is a new identiation numb er alled Binding Unique Identiation numb er (BID). It is intro dued to distinguish b etween multiple bindings p ertaining to the same home address. This numb er is reated for every Care-of Address that the Mobile No de and Router wants to register and is sent within the Binding Up date message. The Home Agent that reeives this message reates a separate binding for eah BID in its binding ahe list. As onsequene, also a new binding ahe management to store the BID and a new sub-option for binding up date to arry the BID is reated. As this extensions works for b oth Mobile Router and Mobile No de in the same way, I will explain the mehanism for the Mobile Router ase, as the NEWSKY test-b ed will deal with it. The new binding pro ess is quite the same as a normal MIPv6/NEMO op eration: when a mobile network visits a foreign network, the Mobile Router obtains a Care-of Address from the Aess Router and register it with the home address in the binding ahe of the Home Agent. In that ase, the Binding Up date message inludes a Binding Identier mobility option whih arries the BID. When the Home Agent reeives the Binding Up date, it opies the BID to the orresp onding eld in the binding ahe entry. If the mobile network detets another foreign network signal and wants to aess it, the Mobile Router an get another Care-of Address from the new Aess Router and send it within another Binding Up date message through the new link. This time, the Home Agent detets that there is another idential home address registered with dierent Care-of Address, but as it do esn't math with the one with existing entry, the Home Agent reates a new binding ahe entry for the new Care-of Address and BID. 52
4. Multiple Care-of Address registration extension proto ol Figure 4.1: Example of a mobile network with MCoA onguration With this extension, the Mobile Route an either register multiple Care-of Addresses at one in a single binding or in individual Binding Up dates. The Home Agent has to supp ort also the new extension proto ol so an register the BID in the binding ahe. For example, in Figure 4.1 there is a Mobile Router that obtains two Care-of Addresses at two foreign links. In that ase, the Mobile Router needs to have two dierent interfaes. The Mobile Route registers its CoAs (CoA1 and CoA2) at the same time to its Home Agent. As a result, two bi-diretional tunnels are established b etween them. The tra an b e distributed b etween the two tunnels. The distribution p oliy dep ends on the lo al p oliy of the network op erator, as will b e explained in Setion 4.4. In that ase, the home address of the Mobile Router would b e for example 2001:b:1::3/64 and it aquires the Care-of Address 2001:3::230:5:fed3:518 for the rst foreign link and the 2001:2:ab:24:32f1:7112:83 for the seond foreign link. The Mobile Router assigns two dierent Binding Identier numb ers for eah link attahed: BID1 and BID2. If the Mobile Router deides to at as a regular Mobile Router, with no multiple Care-of Addresses, it sends the Binding Up date without no binding identier mobility options. Then, the reeiver of the Bindig Up date deletes all the bindings registered with a BID and registers only a single binding for the Mobile Router. The binding ahe is reated this time based on the home address and the BID information if a BID is available. This is dierent from using just MIPv6/NEMO proto ols where only the home address is used for binding ahe lo okup. Also the BID is required to b e stored in the Binding Up date List struture of Mobile Routes so they an know through whih tunnel have to send the dierent kind of pakets. When a Mobile Router deides to delete all the bindings for its home address, it sends a regular de-registration Binding Up date with lifetime set to zero as dened in RFC3775. In that ase, the Binding Identier mobility option is not required. 53
4.2. Binding Up date message arhiteture If the Mobile Router deides to register only a single binding, it just sends a Binding Up date without a Binding Unique Identier sub-option (i.e. normal Binding Up date). The reeiver of the Binding Up date registers only a single binding for the mobile no de. If the reeiver has multiple bindings, one binding is registered without BID and the rest of bindings are deleted. If a Mobile Router wants to delete a partiular binding from its Home Agent, the Mobile Router sends a Binding Up date with lifetime set to zero and inludes a Binding Identier mobility option with the BID it wants to de-register. The reeiver will remove only the Care-of Address that math the sp eied BID. 4.2 Binding Up date message arhiteture The only feature added in the message struture of the Binding Up date of MIPv6/NEMO proto ols is a new ag, (the "O" ag that app ear in the message struture of the Figure 4.2). When this ag is set, all the binding ahe entries for a Mobile Route are replaed by new entries registering with this Binding Up date message. This ag is only used when the BID mobility option is arried with the Binding Up date. Figure 4.2: Binding Up date Header 4.3 Binding Identier mobility option This new option is inluded in the Binding Up date, Binding Aknowledgement, Binding Refresh Request, and Care-of Test Init and Care-of Test messages, explained in the hapter b efore. The elds that are integrated in the message are: 1. Typ e: the value for Binding Identier is 35. 54
4. Multiple Care-of Address registration extension proto ol 2. Length: is a 8-bit unsigned integer eld. Determines the length of the option payload, in o tets, exluding the Typ e and Length elds. 3. Binding ID (BID): arries the BID that is assigned to the binding indiated by the are-of address in the Binding Up date or the Binding Identier mobility option. The BID is a 16-bit unsigned integer. 4. Status: is a 8-bit unsigned integer. When the Binding Identier mobility option is in- luded in a Binding Aknowledgement, this eld overwrites the Status eld in the Binding Aknowledgement only for this BID. This Status eld is also used to arry error information related to the are-of address test in the Care-of Test message. 5. Simultaneous Home and Foreign Binding (H) ag: this ag indiates that the mobile no de registers multiple bindings to the home agent while it is attahed to the home link. This ag is valid only for a Binding Up date sent to the home agent. 6. Reserved: is a 7-bit Reserved eld. 7. Care-of Address: If a Binding Identier mobility option is inluded in a Binding Up date for the home registration, either IPv4 or IPv6 are-of addresses for the orresp onding BID an b e stored in this eld. For the binding registration to orresp ondent no des (i.e., route optimization), only IPv6 are-of addresses an b e stored in this eld. If no address is sp eied in this eld, the length of this eld must b e zero (i.e., not app ear in the option). If the option is inluded in any messages other than a Binding Up date, the length of this eld has to b e also zero. When a Mobile Router registers a given BID for the rst time, it must inlude the Care-of Address led in the Binding Identier mobility option. For any subsequent registrations that either re-register or de-register the same BID, the Mobile router need not no inlude the Care-of Address eld in the binding identier option. 4.4 Multiple Bindings Management and p oliy routing Some p oliies may b e bind to a BID in the Mobile Router. Those p oliies are used to divide the paket ows to multiple network interfaes that the Mobile Router uses. The ows an b e divided by ow typ e, p ort numb er, destination address, et. In addition, eah ommuniation ow sent to a distint network interfae, provides eient network bandwidth onsumption. It b eomes p ossible for users to selet the most appropriate network interfae dep ending on a visiting network environment, sine wireless networks are mutable and less reliable than wired networks and sine eah network interfae has dierent ost, p erformane, bandwidth, aess range, and reliability. Thanks to this mehanism, users are able to selet the most appropriate interfae p er ommuniation typ e. For example, TCP tra should b e transmitted over the wireless interfae, whereas UDP tra should b e transmitted over the wired interfae to avoid disturbing TCP onnetions, using dierent binding tunnels. 55
4.4. Multiple Bindings Management and p oliy routing In the other hand, the BID is used as a searh key for a orresp onding entry in the Home Agent's binding ahe in addition to the Home Address. When the Home Agent heks the binding ahe database for the Mobile Routes, it searhes a orresp onding binding entry with the Home Address and BID of the desired binding. To selet a sp ei binding, the Home Agent uses p oliies and lter informations. If a Mobile Route registers a binding with priority value, the priority an b e a key to selet a binding. If there is no desired binding, it searhes the binding ahe list with the Home Address as sp eied in Mobile IPv6 and the rst mathed binding entry may b e the one used. If multiple bindings exists, when pakets from or to a mobile no de are not delivered orretly, the Home Agent and the Mobile Router an hange the tunnel used, so what also means to hange the binding entry in order to reover the onnetion immediately. In the next hapter, the way to assign the priorities is explained, as it will b e used for the test-b ed onguration when using the MCoA extension proto ol. 56
Chapter 5 NEWSKY Test-b ed As said in the rst hapter, TriaGnoSys ontribution to NEWSKY pro jet onsists of a laboratory test-b ed with the aim to integrate a mobile network inside airrafts for new servies and appliations and validate its funtion in terms of tra delays and pakets lost to improve handovers b etween dierent networks. As part of the TriaGnoSys team that was in harge of the NEWSKY test-b ed, I help ed on building the system, onguring the mahines used and implement them with the proto ols desrib ed in past hapters as well as b eing the one in harge to nd out a way to improve the test-b ed's mobile network handovers to obtain seamless p oint-of-attahment hanges. In this hapter, the test-b ed arhiteture onguration is desrib ed as well as the dierent appliations we develop ed and whih will b e able to b e simulated in the system. Then I will exp ose some results of various tests I made to validate the test-b ed b ehaviour. At the end, I will explain a way to improve the handovers delays of the system, studying and implementing the Multiple Care-of Address registration proto ol. Also, some results of several tests will b e exp osed to ompare the two b ehaviours. 5.1 The real arhiteture In this setion, the real arhiteture that the test-b ed wants to rereate is desrib ed. As the Figure 5.1 shows, it would onsist on a Mobile Network, with its resp etives Mobile Router and Mobile Networks No des, lo ated in the airplane and whih will have onnetion with the Corresp ondent No de situated in the ground through the terrestrial-link Aess Router (AR1) or the satellite-link Aess Router (AR2). As we will see in next setions, the terrestrial link is b etter than the satellite link in terms of bandwidth, paket delays and paket loss during transmission, 57
5.1. The real arhiteture Figure 5.1: Real arhiteture design but its over area is smaller, just around the base-ground station, while the satellite link overs all over the world. These two links use dierent proto ols in the ommuniations and will b e the ones I will use to simulate handovers. In that senario, the Mobile Network No de will probably b e a terminal in the o kpit whih provides interfae to the pilot to make a phone (VoIP) all, download data, et. or any passenger using his mobile devie to onnet to the Internet. The Mobile Router will b e an entity in the airraft whih ontrols all ommuniation tra going in and out the airraft. The Home Agent will b e a no de in the Internet whih provides mobility servie. This ould b e provided by the airline, an aeronautial ommuniation servie provider or any other dediated organization. The Corresp ondent No de will b e, for instane, the air tra ontroller whih provides information to the o kpit. With this arhiteture, the Mobile Network No des in the airplane are able to ommuniate with any Corresp ondent No de in the IPv6 internet, and this without b eing aware of mobility, in a ompletely transparent way. As we an see, in this senario, there is no home link, so it means that the mobile network is always away from its home network. So, there will always exist a tunnel b etween the Mobile Router and the Home Agent through an Aess Router. The test-b ed will try to rereate this senario and demonstrate that a VoIP all (or a data transfer) an b e made b etween MNN and CN without breaking the all (or the data transfer) 58
5. NEWSKY Test-b ed through seamless handovers. 5.2 Conguration of the test-b ed: proto ols and mehanisms In this setion, the test-b ed we develop ed in TriaGnoSys is desrib ed. It tries to simulate the real aeronautial arhiteture desrib ed just b efore using the proto ols and mehanisms explained in previous hapters. After setting all the mahines that take part of this test-b ed, the simulated network arhiteture has the struture depited in the Figure 5.2. Figure 5.2: test-b ed network arhiteture 5.2.1 Network arhiteture and XEN mahines All the mahines are ongurated under Linux based OS. At rst, the Mobile Router and Home Agent mahines will supp ort only NEMO proto ol (explained in Setion 3.5) to allow to have a mobile network b ehind. Later, I will implement and develop a new mehanism for those two mahines to improve handover delays and ommuniations disruptions. The mobile network no des in the mobile network supp ort only the IPv6 proto ol and they are onneted to the Mobile Router. As the Figure 5.2 depits, this router has three interfaes: one is used for the link b etween the Mobile Router and the Aess Router 1 (the blue link in the gure) that simulates the terrestrial link, a seond one for the link b etween the Mobile Router and the Aess Router 2 (in red) that orresp onds to the satellite link and a third one used to onnet the mobile 59
5.5. Simulations and study of the system using NEMO proto ol supp orted in MR and HA Figure 5.6: test-b ed network arhiteture pakets to the Home Agent, through the Aess Router 2. But the whole pro ess, b etween the movement detetion and the reeiving of the Binding Up date, will last ab out 3,5 seonds, whih is to o muh, and leads to a lot of paket losses. 5.5.2 VoIP all simulation To see how are the delays through handovers during a phone all, I used the VoIP appliation. For this purp ose, I studied the RTP paket tra of a onversation b etween the Mobile Network No de and the Corresp ondent No de during a simulated ight. To apture the pakets sent b etween b oth mahines, I used the wireshark program. To trigger the handovers I used the GUI while simulating the appliation. To emulate the satellite link, I used the following ommands using the t to ol in the Aess Router 2: t qdis add dev eth1 parent 1:1 handle 10: tbf rate 64kbit buffer 1600 limit 3000 The t qdis means Tra Control Queuing Disipline. This ommand is used to limit the emission rate to 64 kbit/s on the eth1 interfae. t qdis add dev eth1 root handle 1:0 netem delay 270ms 10ms 25% loss 0.1% 20% 66
5. NEWSKY Test-b ed This ommand is used to add a delay of 270 ms on all pakets going through the eth1 interfae, with the following harateristis: • A 10 ms utuation around the 270 ms delay (thus the delay an utuate b etween 260 ms and 280 ms) • The paket delay dep ends on the 25% of the previous paket delay • A paket loss probability of 0.1% with a orrelation of 20% of the previous paket The terrestrial link has a bandwidth limited to 512 kbit/s and a delay of 30ms. Before starting the simulation, several daemons in the Mobile Router, Home Agent and Aess Routers must b e running in order to have Router Advertisement sent all the time, and the Mobile IPv6 daemon in the Mobile Router to b e able to get the Care-of Address and reate the tunnels. At the b eginning of the simulation, the airplane is supp osed to b e onneted to the terrestrial link, as it has not yet to ok o. So, when the terrestrial Aess Router starts advertising its network prexes through Router Advertisements, the Mobile Router obtains a Care-of Address b elonging to its network and hene the Home Agent will b e informed by means of a Binding Up date message. We an nd out what Care-of Address the Mobile Router have by onsulting its Binding Up date list. In that ase, and as it is depited in Figure A.1 of app endix A, the Care-of Address is 2001:3:0:0:216:3e:fe03:2f. Entering the next ommand on the Mobile Router mahine, we an see it: # telnet loalhost 7777 Trying 127.0.0.1... Conneted to loalhost.loaldomain (127.0.0.1). Esape harater is '^℄'. mip6d> bul == BUL_ENTRY == Home address 2001:50:1104:7400:0:0:0:2 Care-of address 2001:3:0:0:216:3eff:fe03:2f CN address 2001:50:1104:7400:0:0:0:1 lifetime = 96, delay = 91000 flags: IP6_MH_BU_HOME IP6_MH_BU_ACK IP6_MH_BU_MR ak ready lifetime 92 / 96 seq 25357 resend 0 delay 91(after 88s) As we an see, the home address is binded to the Care-of Address obtained. To hek if the Binding Up date and Binding Aknowledge pakets were well routed through the terrestrial link and b efore getting out of the ground over area, I just snied the interfae eth0 of the Aess Router 1 with tdump to ol. The result was: 67
5.5. Simulations and study of the system using NEMO proto ol supp orted in MR and HA # tpdump ip6 -i eth0 tpdump: verbose output suppressed, use -v or -vv for full protool deode listening on eth0, link-type EN10MB (Ethernet), apture size 96 bytes 2001:3::216:3eff:fe03:2f > 2001:50:1104:7400::1: DSTOPT mobility: BU seq#=18597 AH lifetime=96 2001:50:1104:7400::1 > 2001:3::216:3eff:fe03:2f: srrt (len=2, type=2, segleft=1, [0℄2001:50:1104:7400::2) mobility: BA status=0 seq#=18597 lifetime=96 fe80::216:3eff:fe01:3579 > home_agent: ICMP6, neighbor soliitation, who has home_agent, length 32 home_agent > fe80::216:3eff:fe01:3579: ICMP6, neighbor advertisement, tgt is home_agent, length 24 fe80::230:5ff:fed3:518 > 2001:a:1::28: ICMP6, neighbor soliitation, who has 2001:a:1::28, length 32 2001:a:1::28 > fe80::230:5ff:fed3:518: ICMP6, neighbor advertisement, tgt is 2001:a:1::28, length 24 fe80::230:5ff:fed3:518 > fe80::216:3eff:fe01:3579: ICMP6, neighbor soliitation, who has fe80::216:3eff:fe01:3579, length 32 fe80::216:3eff:fe01:3579 > fe80::230:5ff:fed3:518: ICMP6, neighbor advertisement, tgt is fe80::216:3eff:fe01:3579, length 24 fe80::216:3eff:fe01:3579 > fe80::230:5ff:fed3:518: ICMP6, neighbor soliitation, who has fe80::230:5ff:fed3:518, length 32 fe80::230:5ff:fed3:518 > fe80::216:3eff:fe01:3579: ICMP6, neighbor advertisement, tgt is fe80::230:5ff:fed3:518, length 24 2001:3::216:3eff:fe03:2f > 2001:50:1104:7400::1: DSTOPT mobility: BU seq#=18598 AH lifetime=96 2001:50:1104:7400::1 > 2001:3::216:3eff:fe03:2f: srrt (len=2, type=2, segleft=1, [0℄ 2001:50:1104:7400::2) mobility: BA status=0 seq#=18598 lifetime=96 2001:3::216:3eff:fe03:2f > 2001:50:1104:7400::1: DSTOPT mobility: BU seq#=18599 AH lifetime=96 2001:50:1104:7400::1 > 2001:3::216:3eff:fe03:2f: srrt (len=2, type=2, segleft=1, [0℄ 2001:50:1104:7400::2) mobility: BA status=0 seq#=18599 lifetime=96 A Binding Up date paket aptured sent from the Mobile Router to Home Agent is shown next, as an example: Internet Protool Version 6 Version: 6 Traffi lass: 0x00 Flowlabel: 0x00000 Payload length: 88 68
5. NEWSKY Test-b ed Next header: IPv6 destination option (0x3) Hop limit: 64 Soure address: 2001:2::216:3eff:fe53:847b (2001:2::216:3eff:fe53:847b) Destination address: 2001:50:1104:7400::1 (2001:50:1104:7400::1) Destination Option Header Next header: Mobile IPv6 (0x87) Length: 2 (24 bytes) PadN: 4 bytes Option Type: 201 (0x9) - Home Address Option Option Length: 16 Home Address: 2001:50:1104:7400::2 (2001:50:1104:7400::2) Mobile IPv6 / Network Mobility Payload protool: IPv6 no next header (0x3b) Header length: 7 (64 bytes) Mobility Header Type: Binding Update (5) Reserved: 0x00 Cheksum: 0xe03f Binding Update Sequene number: 6525 1... ....= Aknowledge (A) flag: Binding Aknowledgement requested .1.. ....= Home Registration (H) flag: Home Registration ..0. ....= Link-Loal Compatibility (L) flag: No Link-Loal Address Compatibility ...0 ....= Key Management Compatibility (K) flag: No Key Management Mobility Compatibility .... 0...= Multiple Care of Address (M) flag: No Multiple Care of Address Compatibility .... .1..= Mobile Router (R) flag: Mobile Router Compatibility Lifetime: 5 (20 seonds) Mobility Options PadN: 2 bytes Alternate are-of address: 2001:2::216:3eff:fe53:847b (2001:2::216:3eff:fe53:846b) An example of a Binding Aknowledge paket: Frame 5 (102 bytes on wire, 102 bytes aptured) Ethernet II, Sr: 4b:ed:7d (00:16:3e:4b:ed:7d), Dst: 53:84:7b (00:16:3e:53:84:7b) Internet Protool Version 6 Version: 6 69
5.5. Simulations and study of the system using NEMO proto ol supp orted in MR and HA Traffi lass: 0x00 Flowlabel: 0x00000 Payload length: 48 Next header: IPv6 routing (0x2b) Hop limit: 63 Soure address: 2001:50:1104:7400::1 (2001:50:1104:7400::1) Destination address: 2001:2::216:3eff:fe53:847b (2001:2::216:3eff:fe53:847b) Routing Header, Type 2 Next header: Mobile IPv6 (0x87) Length: 2 (24 bytes) Type: 2 Segments left: 1 Home Address: 2001:50:1104:7400::2 (2001:50:1104:7400::2) Mobile IPv6 / Network Mobility Payload protool: IPv6 no next header (0x3b) Header length: 2 (24 bytes) Mobility Header Type: Binding Aknowledgement (6) Reserved: 0x00 Cheksum: 0x33e Binding Aknowledgement Satuts: Binding Update aepted (0) 0... ....= Key Management Compatibility (K) flag: No Key Management Mobility Compatibility .1.. ....= Mobile Router (R) flag: Mobile Router Compatibility Sequene number: 6525 Lifetime: 5 (20 seonds) Mobility Options Link-Layer Address Option-Code: Unknown Link-layer address: 00 PadN: 6 bytes After proving the go o d b ehaviour of the system, I run the GUI to hek that all Binding Up dates and Binding Aknowledges pakets were also well transmitted through the orresp onding link during the ight simulation. Then, I made several VoIP alls to see how handovers aets to the transmission. For that, I aptured the RTP pakets in the Mobile Network No de and I traed the pakets' delay of the simulated onversation. Next, I present some of the results obtained. The Trae 5.7 shows the delay of almost 800 RTP pakets aptured during a simple one-way ight simulation. As I used the GUI to trigger the handovers, we an learly identify in the graph 70
5. NEWSKY Test-b ed the 3 phases of the ight. At the b eginning, the plane is over the Europ ean ontinent, so it is onneted to the ground base through the terrestrial link. During this onnetion, the pakets' delay is small, moving around 35 ms. Seondly, the plane hanges its p oint of attahment (it ies over the o ean), so a handover is made to the satellite link. While b eing onneted through the satellite, the pakets' delay is around 280 ms. And thirdly, the plane ies over the Amerian ontinent, and when it enters again to terrestrial over area, another handover to the terrestrial link take plae. The ordinate axis represents the delay in ms of every paket, represented by its sequene numb er, in the absissa axis. Figure 5.7: RTP paket delay during handovers Lo oking at the graph we an observe that there are two gaps while hanging the p oint of attahment. It is aused by a lost of pakets during the handover. To represent the pakets lost in the graph, I lo ated them in the origin of the ordinate axis (0 ms in one-way delay). It do esn't mean that they have a delay of 0 seonds, but as it is imp ossible to draw the trae to innite (what would b e the orret representation) and b eause there is no paket with real 0 seonds delay, I opted to represent them in the b ottom of the trae as it makes learer the whole graph to understand. So, all pakets lo ated in 0ms delay line means that they are lost. As we an see in detail in the Figure 5.8 and Figure 5.9, there are some pakets lost when the plane hanges the link onnetion. The 5.8 trae shows the pakets' delays during the handover from the terrestrial link to the satellite link. As said b efore, the pakets situated in the origin of the ordinate axis are the pakets lost. The Table 5.1 lists the pakets aptured just b efore, during and after this handover with its orresp ondent delay. We an see that 14 pakets are lost during the handover pro ess. The 5.9 trae shows the pakets' delays while hanging from the 71
5.5. Simulations and study of the system using NEMO proto ol supp orted in MR and HA satellite link to the terrestrial one. In that ase, 15 pakets are lost, as we an see in the 5.2 Table. Figure 5.8: RTP paket delay detail during terrestrial to satellite link handover Figure 5.9: RTP paket delay detail during satellite to terrestrial handover 72
5. NEWSKY Test-b ed The Graphi 5.10 shows the throughput of the RTP pakets that go from Corresp ondent No de to the Mobile Network No de, of the same all simulation. In that ase, the handovers an b e identied as the throughput dereases. In the seond 25, a handover from terrestrial link to satellite one is done, and then, around seond 65, another handover takes plae, when the airplane enters to the terrestrial over area again. As seen b efore, some pakets are lost during the handovers, what is translated on a fall in the trae. Figure 5.10: RTP paket throughput during handovers In App endix C, I present several RTP paket delay and thoughput measurements with dierent total numb er of pakets aptured during VoIP alls. 5.6 Simulation and study of the system using MCoA registration extension To improve the results obtained b efore, I lo oked for a solution in order to redue the delays and paket loss during the handovers. Creating more than one tunnel at the same time b etween the Mobile Router and the Home Agent with the aim to attah the mobile network over more than one foreign network, has b een the solution studied. Thus, I tried to integrate the MCoA registration extension proto ol to the test-b ed and see the new b ehaviour of the system's handovers. So this setion has the ob jetive to implement this new proto ol and to see if it is worth to use this new proto ol to improve the NEWSKY pro jet b enets. 73
5.6. Simulation and study of the system using MCoA registration extension As I said b efore, I start up from using the NEMO Platform for Linux (NEPL) develop ed by the Nautilus6 group. For this platform, it exists the new MCoA extension version that is still under development and thus still ontains some bugs and limitations. Now, the ob jetive is that moments b efore doing the handover b etween the two links, the mobile network will b e already attahed to the two foreign networks, sine it is able to have 2 CoA at the same time. The pro ess to bind the new CoA of the new foreign link with the Mobile Route's Home Address takes plae b efore doing the handover. So, when nally the mobile network hanges its p oint of attahment, there is no delay aused by the binding pro ess, what means deleting the old CoA of the Home Agent's binding ahe and establish the new bind. The new issue that MCoA registration mehanism brings to the test-b ed is that now we an attah the mobile network to the terrestrial and satellite link at the same time. Regarding to the handovers, it will p ermit the mobile network to have seamless moves from one link to the other, where the ongoing onnetions will almost not notie the hange. For that ob jetive, I had to implement several things. First of all, I have mo died the java o de of the GUI. In that ase, I programmed a new o de whih triggers the handovers in another way. Now, the airplane is onneted just through one link while b eing inside its overage area, but few meters b efore reahing the overage b ounds, the Mobile Router detets the new foreign network, so it starts to obtain the new CoA while still b eing onneted and transmitting through the old link. Thus, just b efore reahing the limits of the rst link area, the Mobile Router has already reated the new tunnel through the new Aess Router, binding its new Care-of Address with its home address in the Home Agent's binding ahe. Then, when the airplane rosses the b ounds, the Mobile Router just starts to transmit pakets through the new link diretly. In the App endix B, the hole handover pro ess is desrib ed as well as the GUI o de used for that ase. In that ase, I have just needed to implement the new extension in b oth Mobile Router and Home Agent. Now they will have to run another daemond while exeuting the simulations, with the onguration detailed b elow: The mip6d.onf le for the Home Agent: NodeConfig HA; DebugLevel 10; Interfae "eth0"; HaAeptMobRtr enabled; HaAeptMCoAReg enabled; # Disable MPS/MPA SendMobPfxAdvs enabled; SendUnsolMobPfxAdvs enabled; # MNP onfiguration HaServedPrefix 2001:a:1::/64; BindingAlPoliy 2001:a:1::1000 (2001:a:1::/64) MCoAReg allow; DefaultBindingAlPoliy deny; 74
5. NEWSKY Test-b ed # IPse onfiguration - NO IPSEC AT THE MOMENT UseMnHaIPse disabled; KeyMngMobCapability disabled; Mobile Router mip6d.onf le onguration: NodeConfig MN; DebugLevel 10; DoRouteOptimizationCN disabled; DoRouteOptimizationMN disabled; SendMobPfxSols enabled; UseCnBuAk disabled; # It is used Expliit Mode MobRtrUseExpliitMode enabled; OptimistiHandoff enabled; # The Binding Lifetime MnMaxHaBindingLife 20; Interfae "eth1" Bid 200; BidPriority 20; Reliable true; Interfae "eth2" Bid 100; BidPriority 10; Reliable true; #egress interfae MnHomeLink "eth0" IsMobRtr enabled; HomeAgentAddress 2001:a:1::1000; HomeAddress 2001:50:1104:7400::2/64 (2001:50:1104:7400::/64); RegMultipleCoA enabled; IfMultipleCoA "eth1", "eth2"; So, b efore doing the simulation tests, I have just run the GUI to see if the Binding Up dates and Binding Aknowledges were well sent, and the tunnels were reated as was planed, setting more than one bind in the Home Agent's binding ahe and Mobile Router's binding list. For 75
5.6. Simulation and study of the system using MCoA registration extension Table 5.2: RTP pakets delay measurement during handover from satellite to terrestrial link Pakets sequene numb er delay (ms) Pakets sequene numb er delay (ms) 3302 271.172 3329 lost 3303 291.109 3330 lost 3304 286.653 3331 lost 3305 282.681 3332 lost 3306 302.619 3333 lost 3307 309.081 3334 lost 3308 304.777 3335 lost 3309 305.247 3336 47.851 3310 300.742 3337 38.633 3311 300.739 3338 28.322 3312 296.704 3339 31.997 3313 297.19 3340 28.698 3314 292.69 3341 36.050 3315 294.788 3342 28.481 3316 314.722 3343 28.680 3317 290.89 3344 32.565 3318 291.579 3345 31.692 3319 307.517 3346 31.873 3320 307.066 3347 37.951 3321 lost 3348 34.203 3322 lost 3349 34.142 3323 lost 3350 38.411 3324 lost 3351 29.898 3325 lost 3352 34.623 3326 lost 3353 34.110 3327 lost 3354 28.186 3328 lost 3355 28.71 82
5. NEWSKY Test-b ed Table 5.3: RTP paket delay measurement during the handover from terrestrial to satellite link with MCoA registration Pakets sequene numb er delay (ms) Pakets sequene numb er delay (ms) 49630 30.514 49656 262.832 49631 32.952 49657 273.251 49632 36.421 49658 264.708 49633 28.924 49659 264.962 49634 32.241 49660 268.466 49635 32.234 49661 264.221 49636 32.375 49662 276.872 49637 28.037 49663 276.829 49638 28.421 49664 262.907 49639 32.611 49665 274.529 49640 34.789 49666 286.468 49641 35.009 49667 287.204 49642 34.968 49668 282.932 49643 38.559 49669 298.851 49644 31.023 49670 299.168 49645 30.481 49671 294.422 49646 34.945 49672 295.192 49647 29.117 49673 280.349 49648 32.609 49674 281.082 49649 36.109 49675 276.819 49650 lost 49676 277.528 49651 lost 49677 292.496 49652 278.978 49678 288.478 49653 279.174 49679 308.406 49654 274.327 49680 274.763 49655 266.843 49681 274.908 83
5.6. Simulation and study of the system using MCoA registration extension Table 5.4: RTP paket delay measurement during the handover from satellite to terrestrial link with MCoA registration Pakets sequene numb er delay (ms) Pakets sequene numb er delay (ms) 49958 338.957 49983 282.787 49959 334.446 49984 298.712 49960 284.862 49985 279.089 49961 280.339 49986 303.07 49962 280.552 49987 302.834 49963 276.202 49988 30.429 49964 296.135 49989 31.184 49965 282.72 49990 26.941 49966 279.269 49991 30.931 49967 299.203 49992 34.414 49968 294.746 49993 31.181 49969 274.763 49994 34.854 49970 290.693 49995 38.802 49971 291.222 49996 28.375 49972 286.713 49997 37.038 49973 277.032 49998 36.983 49974 272.504 49999 28.427 49975 288.964 50000 33.064 49976 288.408 50001 33.006 49977 284.869 50002 29.375 49978 284.339 50003 28.609 49979 280.742 50004 34.997 49980 300.415 50005 26.49 49981 266.654 50006 30.827 49982 266.405 50007 31.258 84
Chapter 6 Prop osed future work and onlusions In this hapter the remaining and future work is explained. Next, there is a nal onlusion of the pro jet. 6.1 Remaining and future work This do ument has explained how to design a system whih ould p ermit mobile networks to hange its p oint of attahment to the Internet without interrupting its ongoing transmissions. Besides the nal system worked well, there are still some work to do. Some tasks have to b e p erformed in the diretion of ontinuing the development and integration of the test-b ed, whih will b e used not only for NEWSKY, but also for p otential future pro jets. Issues like integration of Wimax system as one of the aess networks or the study and implementation IPv6 header ompression algorithms for eient transmission of IPv6 pakets in bandwith-limited satellie link, are some of the tasks that the NEWSKY test-b ed will try to implement so on as it an improve the whole aeronauti ommuniations system. The work remained to b e done within the NEWSKY Lab oratory test-b ed pro jet an b e summarized in: Quality of Servie: onerning the appliation part in the pro jet, there is at the moment no quality of servie implemented. This remains to b e done, in order to set priorities b etween the dierent kinds of tra (Voie over IP, messaging, data streaming). Co des: voie over IP an b e ahieved using a lot of dierent kinds of o des, with dierent ompression rates and sp ei harateristis. That's why some studies remain to b e arried out, in order to ho ose the b est suited o des to our system. 85
6.2. Conlusions Overhead in the satellite link: the overhead of RTP pakets in the satellite link is extremely high (3 or 4 times the size of the enapsulated data). That's why we need to nd solutions in order to redue the overhead, b eause it puts down the eieny of the link in a dramati way. The solution ould b e rst to use another o de that puts more data in eah RTP paket. Also header ompression an b e a go o d p ossibility. BGAN Tests: for the moment, the satellite link was only simulated thanks to the use of the Linux tra ontrol to ol. But for the nal demonstration, a real satellite link will have to b e used. Therefore, some tests with the real BGAN mo dem have to b e arried out. Weather Streaming Appliation: the weather streaming appliation has not b een develop ed yet. Up until now, we have only made FTP transfers in order to test the data transfer appliation. 6.2 Conlusions The ob jetive of this pro jet is to improve aeronautial tra management, designing a system whih, employing the latest tehnologies and mehanisms, ould p ermit pilots and passangers in airplanes onnet to Internet with minimum delay and paket loss as well as have aess to new appliations and servies. In this do ument, it has b een disussed the onguration of a test-b ed in order to implement a network inside airplanes and also the proto ols that have b een employed. First of all, it has exp osed the reasons why we have used the IPv6 proto ol for the system onguration instead of the IPv4. Then, it has dealt with dierent metho ds to get mobile networks. Finally, through the test-b ed, the dierent kind of mobile proto ols have b een tested. Considering the Internet Proto ol issue, we have ompared the two most used in reent days: IPv4 vs IPv6. We have seen that the seond one not only brings many more advantages and improvements but also IPv6 supp orts the newest mobile proto ols that IPv4 an't handles. But as the satellite link do es not supp ort IPv6 yet, and the pro jet was fo used in this IP proto ol version, we had to implement dierent mehanisms to traverse IPv6 pakets through IPv4 link. The mehanisms hosen has b een the L2TP and NAPT-PT. Ab out the network mobility, rstly we thought of implementing the mobile IPv6 proto ol in every no de was the solution. The MIPv6 is a proto ol whih p ermits a no de to move through dierent networks keeping its onnetions alive. However, thousands of passangers an o upy the same airplane so, if every no de uses this proto ol, the Mobile Router would ollapse with many Binding Up dates and Binding Aknowledges. Also, it means that every no de should supp ort the proto ol. The solution studied in this do ument is NEMO whih stands for network mobility. It p ermits entire mobile networks to hange its p oint-of-attahment through dierent links while maintaining its ongoing onnetions. In this mehanism, only the router supp orts the mobile proto ol, so the dierent no des are not aware of the mobility and do esn't know ab out the handovers. Another imp ortant issue of the pro jet is the handover pro ess. With NEMO proto ol, when a mobile network hanges its onnetion link, many pakets are lost. To solve that problem, 86
6. Prop osed future work and onlusions dierent solutions has b een exp osed, but the MCoA registration proto ol has b een the one studied and implemented. This mobile extension allows to reate more than one tunnel at the same time b etween the Mobile Router and the Home Agent, so the information an travel through several links. Some simulations with the test-b ed has b een arried out to ompare the dierent handover's b ehaviours using some appliations implemented in Linux. First, a VoIP all simulation was done using only NEMO proto ol. We have seen that during handovers b etween ground and satellite links, some pakets were lost. In the other hand, during VoIP all simulations using MCoA registration proto ol we ould see that the numb er of pakets lost was redued onsiderably. In onlusion, the Multiple Care-of Address registration p ermits a seamless handover, reduing delays pakets lost. Also, thanks to the p oliy of routes, this mehanism p ermits to have load balaning and share the tra through several links at the same time. Finally, I would like to remark that while doing this intership I obtained many b enets. I have learned a lot of interesting things onerning aeronautial ommuniations. Moreover, working in an enterprise enrihed myself and ab ove all the fat of realizing my thesis in Germany. And mention that I have enjoyed taking part of an exellent teamwork, very nie and helpful. 87
Bibliography [1℄ www.newsky-fp6.eu [2℄ A. Jahn and M. Holzb o k and others, "Evolution of aeronautial ommuniations for p ersonal and multimedia servies", Communiations Magazine, IEEE . [3℄ G. Maral and M. Bousquet, Satel lite Communiations Systems . Wiley, third ed., 1998. [4℄ Y.-W. Chen and J.-M. Shih, "Binding up dates for mobile networks by using multiast mehanism in IPv6 environment", Advaned Information Networking and Appliations, 2005. AINA 2005. 19th International Conferene on , vol. 2, pp. 790 795, Marh 2005. [5℄ www.triagnosys.om [6℄ M. A. Miller, Implementing IPv6 . M&T Bo oks, 1998. [7℄ P. Loshin, IPv6 Clearly Explained . Morgan Kaufmann, 1999. [8℄ S. Hagen, IPv6 Essentials . O'Reilly, 2006. [9℄ www.is.org [10℄ S. Deering and R. Hinden, "Internet Proto ol, Version 6 (IPv6) Sp eiation", RFC 2460 , 1998. [11℄ R. Hinden and S. Deering, "IP Version 6 Addressing Arhiteture", RFC 4291 , 2006. [12℄ A. Conta and S. Deering, "Internet Control Message Proto ol (ICMPv6) for the IP Version 6 Sp eiation", RFC 1885 , 1995. [13℄ http://ipv6.om/artiles/general/ICMPv6.ht m [14℄ R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney, "Dynami Host Conguration Proto ol for IPv6 (DHCPv6)", RFC 3315 , 2003. 89
Bibliography [15℄ W. Townsley, A. Valenia, A. Rub ens, G. Pall, G. Zorn, B. Palter, "Layer Two Tunneling Proto ol "L2TP"", RFC 2661 , 1999. [16℄ G. Tsirtsis, P. Srisures, "Network Address Translation - Proto ol Translation (NAT-PT) ", RFC 2766 , 2000. [17℄ D. Johnson, C. Perkins, and J. Arkko, "Mobility Supp ort in IPv6", RFC 3775 , 2004. [18℄ Charles M. Kozierok, The TCP/IP Guide: A Comprehensive, Il lustrated Internet Protools Referene , No Starh Press, 2004. [19℄ James D. Solomon, Mobile IP: The Internet . PTR Prentie Hall, 1997. [20℄ V. Devarapalli et al. , "Network Mobility (NEMO) basi supp ort proto ol", RFC 3963 , 2005. [21℄ Reuters, United to oer Web in the air , 2005. [22℄ T., K. Uehara, Conneting Automobiles to the Internet , 2002. [23℄ C. Perkins, and J. Arkko, "IP Mobility Supp ort for IPv4", RFC 3344 , 2004. [24℄ www.nautilus6.org/do /nepl-howto/ [25℄ R. Wakikawa, V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648 , 2009. [26℄ www.nautilus6.org [27℄ www.inmarsat.om/bgan [28℄ J. Rosenb erg, H. Shulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Sho oler, "SIP: Session Initiation Proto ol", RFC 3261 , 2002. 90
App endix A Test-b ed arhiteture and address onguration A.1 Test-b ed arhiteture The gure A.1 depits the senario used to simulate the appliations and to take the handover tests. It is the nal arhiteture of the test-b ed with all mahines and networks involved with its resp etive IPv6 addresses. The ground and satellite links are the ones used for the handover exp eriment. The TGS LAN simulates the Internet or Air Tra Control, where the Aess Routers, Home Agent and the Corresp ondent No de are attahed. The IPv6 addresses are assigned as follows: TGS LAN is emulating Air Tra Control (ATC) ground network, and has 2001:a:1::/64 pre- x. The Home Network has 2001:50:1104:7400::/64 prex, with HA at 2001:50:1104:7400::1/64 as the default router. Air Tra Servie (ATS) Mobile Network has 2001:50:1104:7401::/64 pre- x, with MR at 2001:50:1104:7401::1/64 as the default router. Aess Network 1 has 2001:3::/64 prex, with AR1 at 2001:3::2/64 as the default router. Aess Network 2 has 2001:2::/64 prex, with AR2 at 2001:2::2/64 as the default router. A.2 Mobile Router Address onguration In the ase that we use only the NEMO proto ol, the Mobile Router and the Home Agent only reate a unique tunnel for every Care-of Address. As we an see in the address onguration of b oth mahines, the tunnel reated is the virtual interfae ip6tnl1 and tap1. They are reated when the mipv6 daemon is running. 91
B.1. GUI soure o de private Thread displayRates, anim; private boolean planeReahable, planeReahableOld; private int sleep_time; publi DemoGUI() { setDefaultCloseOperation(JFrame.EXIT _ON_ CLOSE ); setTitle("Handover Simulation between satellite link and terrestrial link"); ontPane = getContentPane(); JLabel lati_d_lab = new JLabel("Departure Latitude :"); lati_d = new JTextField("49.01"); JLabel longi_d_lab = new JLabel("Departure Longitude :"); longi_d = new JTextField("2.33"); JLabel lati_sd_lab = new JLabel("Station 1 Latitude :"); lati_sd = new JTextField("51"); JLabel longi_sd_lab = new JLabel("Station 1 Longitude :"); longi_sd = new JTextField("-3.5"); JButton plus_button = new JButton("+"); plus_button.addAtionListener(new AtionListener() { publi void ationPerformed(AtionEvent e) { if(sleep_time > 1) sleep_time-=2; } }); JLabel lati_a_lab = new JLabel("Arrival Latitude :"); lati_a = new JTextField("33.39"); JLabel longi_a_lab = new JLabel("Arrival Longitude :"); longi_a = new JTextField("-84.25"); JLabel lati_sa_lab = new JLabel("Station 2 Latitude :"); lati_sa = new JTextField("36"); JLabel longi_sa_lab = new JLabel("Station 2 Longitude :"); longi_sa = new JTextField("-80.5"); JButton minus_button = new JButton("-"); minus_button.addAtionListener(new AtionListener() { publi void ationPerformed(AtionEvent e) { sleep_time+=2; } }); JLabel ov_dist_lab = new JLabel("Coverage (in kms) :"); ov_dist = new JTextField("1000"); JButton run_button = new JButton("Run !"); run_button.addAtionListener(new AtionListener() { publi void ationPerformed(AtionEvent e) { 98
B. GUI soure o de and ow hart if(!anim.isAlive()) runAnimation(); } }); JButton stop_button = new JButton("Stop !"); stop_button.addAtionListener(new AtionListener() { publi void ationPerformed(AtionEvent e) { if(anim.isAlive()) stopAnimation(); } }); JLabel om_link_lab = new JLabel("Com Link: "); om_link = new JLabel(); ontPane.setLayout(new GridBagLayout()); GridBagConstraints = new GridBagConstraints(); .fill = GridBagConstraints.BOTH; .weightx = 1; ontPane.add(lati_d_lab, ); ontPane.add(lati_d, ); ontPane.add(longi_d_lab, ); ontPane.add(longi_d, ); ontPane.add(lati_sd_lab, ); ontPane.add(lati_sd, ); ontPane.add(longi_sd_lab, ); ontPane.add(longi_sd, ); .gridwidth = GridBagConstraints.REMAINDER; ontPane.add(plus_button, ); .gridwidth = 1; ontPane.add(lati_a_lab, ); ontPane.add(lati_a, ); ontPane.add(longi_a_lab, ); ontPane.add(longi_a, ); ontPane.add(lati_sa_lab, ); ontPane.add(lati_sa, ); ontPane.add(longi_sa_lab, ); ontPane.add(longi_sa, ); .gridwidth = GridBagConstraints.REMAINDER; ontPane.add(minus_button, ); .gridwidth = 1; ontPane.add(ov_dist_lab, ); ontPane.add(ov_dist, ); ontPane.add(run_button, ); ontPane.add(stop_button, ); ontPane.add(om_link_lab, ); .gridwidth = GridBagConstraints.REMAINDER; ontPane.add(om_link, ); 99
B.1. GUI soure o de pan = new Panneau(); pan.setPreferredSize(new Dimension(1218, 785)); // .ipady = 800; ontPane.add(pan, ); alulateLines(); pan.setPlane(GeoToPixel(Double.parse Doub le(la ti_d .getT ext() ), Double.parseDouble(longi_d.getText() ))); displayRates = new DisplayRates(pan); displayRates.start(); sleep_time = 25; anim = new Thread(this); pak(); setVisible(true); } publi void runAnimation() { alulateLines(); lati_d.setEditable(false); lati_a.setEditable(false); longi_d.setEditable(false); longi_a.setEditable(false); lati_sd.setEditable(false); lati_sa.setEditable(false); longi_sd.setEditable(false); longi_sa.setEditable(false); ov_dist.setEditable(false); anim = new Thread(this); anim.start(); } publi void stopAnimation() { anim.stop(); lati_d.setEditable(true); lati_a.setEditable(true); longi_d.setEditable(true); longi_a.setEditable(true); lati_sd.setEditable(true); lati_sa.setEditable(true); longi_sd.setEditable(true); longi_sa.setEditable(true); ov_dist.setEditable(true); } publi void run() { int N=500; int j; 100
B. GUI soure o de and ow hart int diretion = 1; pan.setDiretion(diretion); while(true) { for(int i=0;i<=N;i++) { j = i; if(diretion == -1) j = N-i; double[℄ pos_avio = GreatCirle(Double.parseDouble(lat i_d.g etTe xt()) , Double.parseDouble(longi_d.getText() ), Double.parseDouble(lati_a.getText ()), Double.parseDouble (longi_a.getText()), (double)j/N); pan.setPlane (GeoToPixel(pos_avio[0℄, pos_avio[1℄)); planeReahableOld = planeReahable; if(isReahable(Double.parseDouble(la ti_s d.get Text ()), Double.parseDouble(longi_sd.getText( )), pos_avio[0℄, pos_avio[1℄, Double.parseDouble (ov_dist.getText())) || isReahable(Double.parseDouble(lat i_sa .getT ext( )), Double.parseDouble(longi_sa.getText( )), pos_avio[0℄, pos_avio[1℄,Double.parseDoub le(o v_dis t.ge tText ())) ) planeReahable = true; else planeReahable = false; if((j == 0) || (planeReahable != planeReahableOld)) { if(planeReahable) { om_link.setForeground(Color.red); om_link.setText("Ground-Based"); try { Runtime.getRuntime().exe("ssh root192.168.10.74 ./entering_ground.sh"); } ath(IOExeption e){} } else { om_link.setForeground(Color.blue); om_link.setText("Satellite-Based"); try { Runtime.getRuntime().exe("ssh root192.168.10.74 ./entering_satellite.sh"); } ath(IOExeption e){} } } pan.repaint(); try{Thread.sleep(sleep_time);} ath (InterruptedExeption e){} } diretion *= -1; pan.setDiretion(diretion); } } 101
B.1. GUI soure o de publi void alulateLines() { int N=50; double[℄ geo; Point[℄ points = new Point[N+1℄; Point[℄ departure_ov = new Point[N+1℄; Point[℄ arrival_ov = new Point[N+1℄; for(int i=0; i<=N; i++) { geo = GreatCirle(Double.parseDouble (lat i_d.g etTe xt()) , Double.parseDouble (longi_d.getText()), Double.parseDouble(lati_a.getText ()), Double.parseDouble(longi_a.getText() ), (double)i/N); points[i℄ = GeoToPixel(geo[0℄, geo[1℄); departure_ov[i℄ = Coverage(Double.parseDouble(la ti_sd .getT ext( )), Double.parseDouble(longi_sd.getText( )), Double.parseDouble(ov_dist.getT ext() ), (double)i/N*2*Math.PI); arrival_ov[i℄ = Coverage(Double.parseDouble(lati _sa.g etTex t()) , Double.parseDouble(longi_sa.getText( )), Double.parseDouble(ov_dist.getT ext() ), (double)i/N*2*Math.PI); } Point pos_sd = GeoToPixel(Double.parseDouble(lati _sd.g etTex t()) , Double.parseDouble(longi_sd.getTe xt()) ); Point pos_sa = GeoToPixel(Double.parseDouble(lati _sa.g etTex t()) , Double.parseDouble(longi_sa.getTe xt()) ); pan.setLines(points, departure_ov, arrival_ov, pos_sd, pos_sa); } publi stati double[℄ GreatCirle(double lat1, double lon1, double lat2, double lon2, double alpha) { double x1 = Math.os(lon1*Math.PI/180)*M ath. os(l at1*M ath.P I/18 0); // artesian oordinates on a radius 1 sphere (u1 vetor) double y1 = Math.sin(lon1*Math.PI/180)*M ath. os(l at1*M ath.P I/18 0); double z1 = Math.sin(lat1*Math.PI/180); double x2 = Math.os(lon2*Math.PI/180)*M ath. os(l at2*M ath.P I/18 0); // artesian oordinates on a radius 1 sphere (u2 vetor) double y2 = Math.sin(lon2*Math.PI/180)*M ath. os(l at2*M ath.P I/18 0); double z2 = Math.sin(lat2*Math.PI/180); double Psi = Math.aos(x1*x2 + y1*y2 + z1*z2); // earth enter angle in radians between (lon1, lat1) and (lon2, lat2) double x3 = (x2 - x1*Math.os(Psi))/Math.sin(Psi); // orthogonal angle to u1, in the (u1, u2) plane, on the u2 side (u3 vetor) double y3 = (y2 - y1*Math.os(Psi))/Math.sin(Psi) ; double z3 = (z2 - z1*Math.os(Psi))/Math.sin(Psi) ; double phi = alpha*Psi; double x = x1*Math.os(phi) + x3*Math.sin(phi); double y = y1*Math.os(phi) + y3*Math.sin(phi); 102
B. GUI soure o de and ow hart double z = z1*Math.os(phi) + z3*Math.sin(phi); double lat = Math.asin(z)*180/Math.PI; double lon = Math.atan2(y,x)*180/Math.PI; return new double[℄{lat,lon}; // latitude and longitude in degrees } publi stati Point Coverage(double lat, double lon, double dist, double alpha) { double x = Math.os(lon*Math.PI/180)*M ath. os(l at*M ath.P I/18 0); double y = Math.sin(lon*Math.PI/180)*M ath. os(l at*M ath.P I/18 0); double z = Math.sin(lat*Math.PI/180); double x1 = -x*Math.sin(lat*Math.PI/18 0)/Ma th. os(la t*Ma th.P I/180 ); double y1 = -y*Math.sin(lat*Math.PI/18 0)/Ma th. os(la t*Ma th.P I/180 ); double z1 = (1 - z*Math.sin(lat*Math.PI/180))/M ath. os(la t*M ath.P I/18 0); double x2 = y*z1 - z*y1; double y2 = z*x1 - x*z1; double z2 = x*y1 - y*x1; double x3 = x1*Math.os(alpha) + x2*Math.sin(alpha); double y3 = y1*Math.os(alpha) + y2*Math.sin(alpha); double z3 = z1*Math.os(alpha) + z2*Math.sin(alpha); double angle = (double)dist/20000*Math.PI; double x = x*Math.os(angle) + x3*Math.sin(angle); double y = y*Math.os(angle) + y3*Math.sin(angle); double z = z*Math.os(angle) + z3*Math.sin(angle); double lat = Math.asin(z)*180/Math.PI; double lon = Math.atan2(y,x)*180/Math.PI; return GeoToPixel(lat,lon); } publi stati boolean isReahable(double lat_station, double lon_station, double lat_plane, double lon_plane, double dist_max) { double xs = Math.os(lon_station*Math.PI /180) *Mat h.os (lat_ stat ion*M ath. PI/18 0); double ys = Math.sin(lon_station*Math.PI /180) *Mat h.os (lat_ stat ion*M ath. PI/18 0); double zs = Math.sin(lat_station*Math.PI /180) ; double xp = Math.os(lon_plane*Math.PI/1 80)*M ath. os(l at_pl ane* Math. PI/1 80); double yp = Math.sin(lon_plane*Math.PI/1 80)*M ath. os(l at_pl ane* Math. PI/1 80); double zp = Math.sin(lat_plane*Math.PI/1 80); double Psi = Math.aos(xs*xp + ys*yp + zs*zp); double dist = Psi/Math.PI*20000; if(dist<dist_max) return true; 103
B.1. GUI soure o de else return false; } publi stati Point GeoToPixel(double lat, double lon) // latitude and longitude in degrees { return new Point((int)(47 + 11.3821 * (lon + 89.6539)), (int)(612-650.4559*(Math.log((1+Math .sin (lat* Math .PI/1 80))/ (1-Math.sin(lat*Math.PI/180)))/2-0.4 021) )); } publi stati void main(String[℄ args) { //Shedule a job for the event-dispathing thread: //reating and showing this appliation's GUI. javax.swing.SwingUtilities.invokeLat er(n ew Runnable(){ publi void run() { new DemoGUI(); } }); } } /* The Panell lass is a JPanel, whih ontains all the graphial information of the GUI. It orresponds to the area of the GUI, where the map is displayed. */ lass Panell extends JPanel { private Image map; private Image avio; private Image avioni; private Point[℄ route; private Point[℄ departure_ov; private Point[℄ arrival_ov; private Point pos_sd; private Point pos_sa; private Point pos_avio; private int diretion; private int bottom_left_x, bottom_left_y, axe_x; private int rate1_px, rate2_px; private String rate1_kbit, rate2_kbit; private boolean bigSale; publi Panell() { map = getToolkit().getImage("atlanti .pn g"); avio = getToolkit().getImage("avio.p ng") ; avioni = getToolkit().getImage("avioni.png"); diretion = 1; bottom_left_x = 1038; 104
B. GUI soure o de and ow hart bottom_left_y = 755; axe_x = 28; rate1_px = 0; rate2_px = 0; rate1_kbit = ""; rate2_kbit = ""; } publi void setLines(Point[℄ route, Point[℄ departure_ov, Point[℄ arrival_ov, Point pos_sd, Point pos_sa) { this.route = route; this.departure_ov = departure_ov; this.arrival_ov = arrival_ov; this.pos_sd = pos_sd; this.pos_sa = pos_sa; } publi void setPlane(Point pos_avio) { this.pos_avion=pos_avio; } publi void paint(Graphis g) { g.drawImage (map, 0, 0, this); // Draws the satellite image (bakground image of the Panell lass) g.setColor(Color.WHITE); // Draws the white retangle where the rates are displayed g.fillRet(bottom_left_x,bottom_left _y-2 50,15 0,25 0); g.setColor(new Color(192,32,32)); // draws the rate information of AR1 (in red) g.drawString(rate1_kbit, bottom_left_x+axe_x+20, bottom_left_y-235); g.fillRet(bottom_left_x+axe_x+20,bo ttom _left _y-2 0-rat e1_px ,20, rate1 _px) ; g.drawString("B-AMC", bottom_left_x+axe_x+20,bottom_le ft_y5); g.setColor(new Color(32,32,192)); // draws the rate information of AR2 (in blue) g.drawString(rate2_kbit, bottom_left_x+axe_x+20+50, bottom_left_y-235); g.fillRet(bottom_left_x+axe_x+20+50 ,bot tom_l eft_ y-20rate2 _px, 20,ra te2_ px); g.drawString("SAT", bottom_left_x+axe_x+20+50,bottom_l eft_y -5); g.setColor(Color.BLACK); // draws the horizontal and vertial axes, and the "kbit/s" aption (in blak) g.drawLine(bottom_left_x+axe_x,botto m_le ft_y20,b ottom _left _x+1 40,bo ttom _left _y-2 0); g.drawLine(bottom_left_x+axe_x,botto m_le ft_y20,b ottom _left _x+a xe_x, bott om_le ft_y -235) ; g.drawString("kbit/s", bottom_left_x+1,bottom_left_y-2 39); if(bigSale) // draws the sale in ase of a high rate (up to 600 kbit/s) (in blak) { g.drawLine(bottom_left_x+axe_x-3,bot tom_ left_ y-20 ,bott om_le ft_x +axe_ x, bottom_left_y-20); g.drawString("0", bottom_left_x+14,bottom_left_y-15); g.drawLine(bottom_left_x+axe_x-3,bot tom_ left_ y-70 ,bott om_le ft_x +axe_ x, bottom_left_y-70); g.drawString("150", bottom_left_x,bottom_left_y-65); 105
B.1. GUI soure o de g.drawLine(bottom_left_x+axe_x-3,bot tom_ left_ y-12 0,bot tom_l eft_ x+axe _x, bottom_left_y-120); g.drawString("300", bottom_left_x,bottom_left_y-115); g.drawLine(bottom_left_x+axe_x-3,bot tom_ left_ y-17 0,bot tom_l eft_ x+axe _x, bottom_left_y-170); g.drawString("450", bottom_left_x,bottom_left_y-165); g.drawLine(bottom_left_x+axe_x-3,bot tom_ left_ y-22 0,bot tom_l eft_ x+axe _x, bottom_left_y-220); g.drawString("600", bottom_left_x,bottom_left_y-215); } else // draws the sale in ase of a low rate (up to 12 kbit/s) (in blak) { g.drawLine(bottom_left_x+axe_x-3,bot tom_ left_ y-20 ,bott om_le ft_x +axe_ x, bottom_left_y-20); g.drawString("0", bottom_left_x+14,bottom_left_y-15); g.drawLine(bottom_left_x+axe_x-3,bot tom_ left_ y-70 ,bott om_le ft_x +axe_ x, bottom_left_y-70); g.drawString("3", bottom_left_x+14,bottom_left_y-65); g.drawLine(bottom_left_x+axe_x-3,bot tom_ left_ y-12 0,bot tom_l eft_ x+axe _x, bottom_left_y-120); g.drawString("6", bottom_left_x+13,bottom_left_y-115); g.drawLine(bottom_left_x+axe_x-3,bot tom_ left_ y-17 0,bot tom_l eft_ x+axe _x, bottom_left_y-170); g.drawString("9", bottom_left_x+14,bottom_left_y-165); g.drawLine(bottom_left_x+axe_x-3,bot tom_ left_ y-22 0,bot tom_l eft_ x+axe _x, bottom_left_y-220); g.drawString("12", bottom_left_x+7,bottom_left_y-215); } Graphis2D g2d = (Graphis2D)g; g2d.setColor(Color.RED); // draws the "CDG" and "ATL" airport aptions, and the Great Cirle Route (in red) g2d.setFont(new Font("SansSerif",Font.BOLD,20 )); g2d.drawString("CDG", (int)route[0℄.getX()+10, (int)route[0℄.getY()+20); g2d.drawString("ATL", (int)route[route.length-1℄.getX( )-40, (int)route[route. length-1℄.getY()+20); g2d.setStroke(new BasiStroke( 3.0f )); //for(int i=0; i<route.length-1; i++) // g2d.drawLine((int)route[i℄.g etX() , (int)route[i℄.getY(), (int)route[i+1℄.getX(), (int)route[i+1℄.getY()); g2d.setColor(new Color(192,32,32)); // draws the 2 base stations, and the overage irles (in red) g2d.setStroke(new BasiStroke( 4.0f )); g2d.drawLine((int)pos_sd.getX(), (int)pos_sd.getY(), (int)pos_sd.getX(), (int)pos_sd.getY()); g2d.drawLine((int)pos_sa.getX(), (int)pos_sa.getY(), (int)pos_sa.getX(), (int)pos_sa.getY()); g2d.setStroke(new BasiStroke( 2.0f )); for(int i=0; i<route.length-1; i++) { g2d.drawLine((int)departure_ov[i℄.g etX( ), (int)departure_ov[i℄.getY(), (int)departure_ov[i+1℄.getX(), (int)departure_ov[i+1℄.getY()); g2d.drawLine((int)arrival_ov[i℄.get X(), (int)arrival_ov[i℄.getY(), (int)arrival_ov[i+1℄.getX(), (int)arrival_ov[i+1℄.getY()); } 106
B. GUI soure o de and ow hart if(diretion == 1) // draws the plane in the diretion Paris -> Atlanta g.drawImage (avioni, (int)pos_avio.getX()-50, (int)pos_avio.getY()-34, this); else // draws the plane in the diretion Atlanta -> Paris g.drawImage (avio, (int)pos_avio.getX()-50, (int)pos_avio.getY()-34, this); } publi void setRate1_px(int rate1_px) { this.rate1_px = rate1_px; } publi void setRate2_px(int rate2_px) { this.rate2_px = rate2_px; } publi void setRate1_kbit(String rate1_kbit) { this.rate1_kbit = rate1_kbit; } publi void setRate2_kbit(String rate2_kbit) { this.rate2_kbit = rate2_kbit; } publi void setBigSale(boolean bigSale) { this.bigSale = bigSale; } publi void setDiretion(int diretion) { this.diretion = diretion; } } /* The DisplayRates lass is a Thread whih simply reads the files rate1.txt and rate2.txt every 0.5 seond. Then, it analyses the rate to determine the sale and sends all the information to the Panneau objet for display.*/ lass DisplayRates extends Thread { Panell pan; int rate1_int, rate2_int; int ount; publi DisplayRates(Panell pan) { this.pan = pan; ount=0; } 107
C.1. Measurements using only NEMO proto ol Figure C.1: RTP paket delay during handovers Figure C.2: RTP paket throughput during handovers 114
C. RTP paket delay and throughput measurements Figure C.3: RTP paket delay during handovers Figure C.4: RTP paket throughput during handovers 115
C.2. Measurements with MCoA registration proto ol C.2 Measurements with MCoA registration proto ol The C.5 trae shows the delay of 800 RTP paket aptured during a VoIP all with MCoA registration mehanism implemented in the test-b ed. The pro edure followed to obtain the results are the same used in setion 5.6.1. The C.6 trae depits the RTP paket throughput. Figure C.5: RTP paket delay during handover with multiple CoA registration proto ol In that all simulation 2 pakets have b een lost while hanging the p oint of attahment from the terrestrial link to the satellite one. During the handover from the satellite to the ground link, 0 pakets have b een lost. The C.7 trae shows the delay of 4500 RTP pakets aptured during a VoIP simulation all. In that ase, 5 pakets have b een lost during the handover from terrestrial to satellite link and 1 pakets while hanging from satellite to terrestrial link. The C.8 graph represents the throughput. 116
C. RTP paket delay and throughput measurements Figure C.6: RTP paket throughput during handover using multiple CoA registration proto ol Figure C.7: RTP paket delay during handover using multiple CoA 117
C.2. Measurements with MCoA registration proto ol Figure C.8: RTP paket delay during handover using multiple CoA 118