Further Improvements of an existing IPv6 Network Mobility Test-bed
Full text
Further Improvements of an existing IPv6 Network Mobility Test-bed JosepM a Tomàs Sanahuja Munich (Germany) September 2010 - March 2011 Tutor: Jaime M. Delgado Mercé Barcelona School of Informatics - FIB Universitat Politècnica de Catalunya - UPC TriaGnosys GmbH Supervisors: Àngels Via Estrem and Eriza Had Fazli
Agraïments A tots aquells que al llarg d'aquests últims anys han fet possible que seguís endavant en els moments més difícils i de necessitat, moltes grácies a tots vosaltres. A tu Joan que durant 3 anys has estat el meu cap en el departament del TSC, per tota la exibilitat otorgada al llarg d'aquests anys i l'ajut prestat quan l'he hagut de menester. Han estat uns tres anys els quals en guardaré molt bons records, gràcies per tot. Gràcies també Antonio per aquests tres anys al departament del TSC. Han estat tres anys dels que n'estic molt content de haver pogut viure i aprés. Gràcies. Voldria agraïr a la Núria Castell. Al llarg de l'últim període de la carrera t'he tingut com a professora de Inteligéncia Articial i he pogut mantindre converses sobre el com encarar la meva carrera en un llavors, valorar possibilitats per a fer un màster, tràmits per a beques a Japó i nalment la possibilitat de realitzar el projecte de nal de carrera (PFC) a l'extranger a Múnic, Alemanya. Ha estat una molt bona experiéncia de la qual sempre en mantindré un bon record i de la qual sempre me'n sentiré privilegiat de haver-la viscut. Agraïr a l'Ãngels i a l'Eriza per el seu ajut i suport en la tasca dins el projecte. També agraïr les recomanacions del meu tutor Jaime Delgado en el redactat nal de la memòria. Finalment agraïr a tota la meva familia per el suport donat al llarg d'aquests anys. A la meva àvia Pepeta que no vaig arribar mai a conèixer. Al meu avi Rafel Tomàs que en pau descansi. Al meu avi Blai Sanahuja que ens va deixar farà un any, ell sempre va procurar per la meva educació i benestar, sempre, sempre en va tenir cura i ns els seus últims dies en mantingué. Estic segur que n'estaries orgullós i n'estaries cofoi. En els últims dies abans que ens deixèssis et vaig dir: Estigues tranquil per què tiraré endavant i me'n ensortiré A dia de avui et puc dir: He complert, i continuaré tirant endavant, pots estar-ne segur. Res és impossible si amb esforç i voluntat un hi persisteix, tard o d'hora sempre se'n acaba obtenint resultat I nalment a les dues persones que ho han donat tot per a mi en aquesta vida i que tant de sacrici han fet, les dues persones per a les quals el meu present i el meu futur ho són i ho han estat sempre tot per a ells. A el meu pare i a la meva mare. Gràcies
Contents List of Figures v Abbreviations vii 1 Introduction 1 1.1 Motivation ....................................... 1 1.2 Goals .......................................... 3 1.3 ReportStructure.................................... 4 2 IPv6 Overview 5 2.1 Introduction....................................... 5 2.2 Basic characteristics of IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Introduction to Mobility IPv6 protocol . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1 MobileIPv6protocol.............................. 8 3 Testbed Current Status 11 3.1 Introduction to NEWSKY testbed architecture . . . . . . . . . . . . . . . . . . . 11 3.1.1 NEWSKYbackground............................. 11 3.1.2 NEWSKY testbed architecture . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 Introduction to SANDRA scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.1 SANDRAgoals................................. 12 3.2.2 SANDRA architecture and test-bed . . . . . . . . . . . . . . . . . . . . . 13 3.3 Aim of traversing IPv6 trac over a satellite IPv4 network . . . . . . . . . . . . 15 3.4 Relevant and non relevant trac types in SANDRA . . . . . . . . . . . . . . . . 15 i
4 Mobility + IPv4 Traversal 17 4.1 Considered Protocols as a solution for SANDRA . . . . . . . . . . . . . . . . . . 17 4.1.1 M6Tprotocol ................................. 17 4.1.2 DSMIPv6.................................... 19 4.1.3 NeXT ...................................... 20 4.2 Protocolcomparison .................................. 24 4.3 NeXTasoptionchosen ................................ 26 5 Testbed Automation 31 5.1 IPv6 Network Mobility Testbed Architecture - Technical features . . . . . . . . . 31 5.2 How the IPv6 Network Mobility Test-bed was switched on . . . . . . . . . . . . . 33 5.3 Considered options for the automation . . . . . . . . . . . . . . . . . . . . . . . . 34 5.3.1 Use of Cron + Bash scripts: . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.3.2 Use of /etc/rc.local + Bash scripts: . . . . . . . . . . . . . . . . . . . . . . 35 5.3.3 Use of /etc/rc.local + Java GUI + Bash scripts . . . . . . . . . . . . . . . 37 5.4 Final option: Use of /etc/rc.local + Java GUI + Bash scripts . . . . . . . . . . . 38 5.4.1 Dierent features of the Java GUI . . . . . . . . . . . . . . . . . . . . . . 38 5.4.2 Where are the scripts located and how are they executed ? . . . . . . . . 41 6 NeXT software architecture/design 43 6.1 NeXT rst protocol version design . . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.2 New NeXT requirements in SANDRA scenario . . . . . . . . . . . . . . . . . . . 44 6.3 Two dierent NeXT design approaches . . . . . . . . . . . . . . . . . . . . . . . 46 6.3.1 NeXTmultiprocess .............................. 47 6.4 ThreadsIntroduction ................................. 53 6.4.1 WhatisaThread................................ 53 6.4.2 Whyusingthreads? .............................. 55 6.4.3 What is pthread library? . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.5 NeXTthreads...................................... 56 6.6 NeXTdesignchosen .................................. 60
7 Test Cases 61 7.1 Case1.......................................... 61 7.2 Case2.......................................... 63 8 Conclusions and future Work 67 8.1 Conclusions....................................... 67 8.2 Futurework ...................................... 68 9 References and Bibliography 69
List of Figures 2.1 IPv6headerformat................................... 6 2.2 Mobilityprotocol(1).................................. 8 2.3 Mobilityprotocol(2).................................. 9 3.1 NEWSKY test-bed architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 SANDRAtopology................................... 13 3.3 SANDRAarchitecture................................. 14 3.4 Airtracnetwork ................................... 15 3.5 InmarsatcoverageArea ................................ 16 3.6 SANDRAtrac .................................... 16 4.1 M6Tdeployment.................................... 18 4.2 Outer packet in MR and Outer packet in HA . . . . . . . . . . . . . . . . . . . . 18 4.3 Packet in HA after UDP decapsulation is done by M6T entity, the outer IPv6 headeristheNEMOheader.............................. 18 4.4 PacketinCN ...................................... 19 4.5 NeXT .......................................... 20 4.6 NeXT headers with IPv6 and mobility legend . . . . . . . . . . . . . . . . . . . . 21 4.7 NeXT steps from MN to NeXTSlave . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.8 NeXTstepsfromCNtoMN.............................. 23 v
1.3. Report Structure 1.3 Report Structure A brief explanation of how the report is structured will be given for an easy understanding to all person that in a close future want to base its work projects into this project report. The report rst talks about the motivation of the project and mentions from an existent general scope that have been worked with. Tasks that have been done within this project are also mentioned in the Motivation section. Afterwards chapter 2 and chapter 3 introduces technology background that have been used. Chapter 2 and chapter 3 have no relation between them, the rst one talks about IPv6 technology which is used in the whole project, a brief description of some of its features are explained, whereas chapter 3 talks about the existing and the upcoming architecture in which the NeXT protocol is going to be deployed. This last chapter is very important because it introduces the test-bed architecture and changes that this testbed suered and was going to suer, but also it is important because some important decisions in terms of the new NeXT protocol design were based taking the test-bed topology architecture into account. Bear in mind one thing, chapter 2 and chapter 3 describes technologies that in this project have been used, however, other technologies will be introduced in other chapters in order to justify things and give a better comprehension of some aspects. This project is mainly about NeXT protocol and an IPv6 Mobility test-bed, however, NeXT protocol is deployed in the test-bed and both use other technologies for specic cases. Chapter 4 introduces the analysis process of choosing the most appealing protocol option to be considered for the coming SANDRA test-bed scenario. Some aspects of protocols are explained, there are also some comparisons between them and some conclusions. Chapters 1 to 3 are more theoretical, whereas chapter 4 introduces the analysis process in the project. Chapter 5 is about the test-bed Automation, it is explained the problem that there was, options considered and actions taken, some theory about some technologies is also given. Chapter 6 is a chapter that joins the design and implementation process in NeXT new version. In chapter 4 an introduction to old NeXT rst version was given, in chapter 6 a more technical explanation is given focused on the implementation aspects. An introduction to threads is also given. In chapter 7 some test cases are explained. Chapter 8 with conclusions and future work and nally chapter 9 introduces references and bibliography. 4
Chapter 2 IPv6 Overview The Internet Engineering Task Force (IETF) has been developing Internet Protocol version 6 since the 1990s, this protocol is expected to replace in a midterm the current IPv4 due to the scarce of new available addresses to assign, its address space is nearly to nish in a few years. Nowadays some companies and organizations are getting involved in the use of IPv6, an example given is the Olympic games of China where public net services used IPv6. 2.1 Introduction IPv6 uses a 128-bit address, whereas IPv4 uses only 32 bits. It means the new IPv6 address space supports 2128 (about 3.4x 1038 ) addresses. This expansion provides considerable exibility in allocating addresses and routing trac. As address size in IPv6 is 128 bits it solves the problem of scarcity address space in IPv4. It also adds the feature that addresses can be auto congured, multicast routing has been improved and new address type has been introduced, called Anycast address explained in 2.1. 2.2 Basic characteristics of IPv6 2.2.0.1 Header The IPv6 header has a xed length of 40 bytes, 32 bytes are for addresses and 8 bytes for general header information. The header of an IPv6 packet is specied in RFC 24601 . Figure 2.1 shows the IPv6 format. 5
2.2. Basic characteristics of IPv6 Figure 2.1: IPv6 header format 1. Version (4 Bits) . Internet Protocol version number. In this case is 6. 2. Trac Class (1 Byte) . This eld replaces the Type of Service eld in IPv4. Facilitates the handling of real-time data and any other data that requires special handling. 3. Flow Label (20 Bits) This eld distinguishes packets that require the same treatment, in order to facilitate the handling of real-time trac: routers keep track of ows so they can process packets belonging to the same ow more eciently because they do not have to reprocess each packet's header. 4. Payload Length (2 Bytes) . Length of the IPv6 payload counting the extension headers. 5. NeXT Header (1 Byte) . Identies the type of header immediately following the IPv6 header. 6. Hop Limit (1 Byte) . Expresses a number of hops permitted to reach the destination node. Every forwarding node decrements the number by one. 7. Source Address (16 bytes) . It contains the address of the node that generates the packet. 8. Destination Address (16 bytes) . It contains the address of the destination node. 6
2. IPv6 Overview Many elds that are considered Options in IPv4 are considered as Extension Headers in IPv6. Extension Headers can be from zero to more extension headers in a packet but they are always between the IPv6 header and the next layer header. For further details consult IPv6 RFC 2460a 2.2.0.2 Adressing IPv6 has 3 types of addresses: • Unicast address : unicast address uniquely identies a single interface of an IPv6 node within the scope of the unicast address type. Depending of the prex the address can be: Link-local : Is for use on a single link. Its prex is fe80 and it can be used for auto conguration mechanisms, for neighbor discovery and others. Site-Local : Its prex is fec0 . The address contains subnet information. It can only be routed within the site, therefore routers can not route packets outside the site. A site could be dened as a network area scope. Global : It uniquely identify a node all over the world and are structured as Aggregatable Global Unicast Addresses2 . • Multicast : It comprises a group of addresses, this address can have dierent scopes. Packets that are sent to a multicast address, are sent to all addresses that takes part in the multicast group. • Anycast : It is assigned to multiple interfaces (usually in multiple nodes). It can not be dierentiated from a Global address, all nodes that have an Anycast address type congured are the only ones to identify it as Anycast type address. When a packet is sent to an Anycast address it is sent only to one of them, usually the nearest one. An IPv6 address consists of three parts: a global routing prex, a subnet ID, and an interface ID. The addresses are written as follows: IPv6 address/prex length Addresses are divided into eight 16-bit hexadecimal blocks, separated by colons, an example is given: 2001:5c0:1505:6101:0000:0000:0000:3 IPv6 addresses can be simplied as follows: • Leading zeros can be simplied by skipping them. • Consecutive zeros can be replaced by a semicolon but it can only appear only once in an IPv6 address. After the transformation the IPv6 address looks like as follows: 2001:5c0:1505:6101::3 7
2.3. Introduction to Mobility IPv6 protocol 2.3 Introduction to Mobility IPv6 protocol Every node has an IPv6 globally unique address and a link local address. These addresses are related to the router in the network they are connected, thus when the node changes its point of attachment, IPv6 global unique addresses and link local addresses change. When the address changes the existent connections terminate because they can not be maintained. This happens because connections such as TCP are characterized by the address and ports of each one. It means that the information related with the interface ( the one that changes its point of attachment) changes and the other edge can not reach it because it has the old conguration address. A new connection with the new conguration must be opened. Mobile IPv6 overcomes this issue and allows maintaining the existing connections the mobile node that moves to a new network is communicating with. Section 2.3.1 explains briey how Mobile IPv6 protocol works. 2.3.1 Mobile IPv6 protocol When a node moves to a new network it acquires a new address, called Care-of Address (CoA) from the new local router. A CoA is a temporary address that the mobile device acquires when it joins to a foreign network. It identies the current point of attachment to the internet and makes it possible to connect from a dierent location without changing its permanent address, the Home Address (HoA). When the mobile device moves to a new network it also maintains HoA. When a node enters to a new network the IPv6 Mobility protocol works as follows: Figure 2.2: Mobility protocol (1) Before explaining how the IPv6 Mobility protocol works some terminology will be introduced for a better comprehension. • Care-of Address (CoA): It has been explained in the initial section paragraph. • Home Address (HoA): Is the permanent address that identies the point of attachment to the mobile node's home network. 8
2. IPv6 Overview • Home Network: Network to whom a mobile node belongs, the one that congures its permanent address (the HoA). • Foreign Network: Network in which a mobile node is operating when away from its home network. • Home Agent: Node that stores information about mobile nodes whose permanent home address is in the home agent's network. • Binding Update: Packet that creates or renew an association of the HoA with a CoA. • Binding Cache: Table maintained by a node. It contains the current bindings (associations) for mobile nodes. • Binding Update Acknowledgment: Conrmation of the BU packet. • Correspondent Node: Node that communicates with a mobile node that is out of its own network. The following steps correspond to gure 2.2: 1. Address auto conguration, called Care-of Addresses. 2. The node sends a Binding Update (BU) to the HA, it binds the CoA to the HoA in the HA which is in the Home network. If the node does not know the HA it uses HA discovery process. 3. When the HA receives the BU, it stores in the Binding Cache (BC) and sends back a Binding Update Acknowledgment. After receiving the BU Ack, the mobile node (mobile device) must use the Return Routability Process in order to send packets to the Correspondent Node. The following steps are related to this process. Figure 2.3 illustrates them. 1. The node sends a Home test Init (HoTI) message indirectly to the correspondent node, tunneling the message through the Home Agent. Figure 2.3: Mobility protocol (2) 9
2.3. Introduction to Mobility IPv6 protocol 2. The mobile node sends a Care-of Test Init (CoTI) message directly to the correspondent node. 3. The correspondent node sends a Home Test (HoT) message in response to the HoTI message. 4. The CN sends a Care-of Test (CoT) message in response to the CoTI message. After doing this process the nodes can communicate directly using Routing Optimization (RO) instead of using HA. When a node is in a foreign network it sends packets from its care-of address and includes the mobile node's Home Address in a Home Address option. One advantage of using RO is that it frees the HA from trac, HA tunnel interfaces tends to become a bottleneck. 10
Chapter 3 Testbed Current Status 3.1 Introduction to NEWSKY testbed architecture 3.1.1 NEWSKY background The development of ecient aeronautical communication systems is currently a predominant topic in view of the expected saturation of ATM communications by 2020-2025 due to air traf- c increase. In addition, the envisaged paradigm shift in ATM as developed in SESAR and the existing high market demand for passenger communications are the driving factors for the modernization of aeronautical communications. It is foreseen that dierent services, data links and networking solutions will be deployed. Dierent services with highly diverse requirements shall coexist and partly or totally share the aeronautical network infrastructure. No single service on its own justies the cost implication of a new communication system. Trends for the dierent aeronautical services include: • Air Trac Services (ATS): It will be primarily based on highly safety-related data communication whereas voice communication will be mostly used as fallback solution • Airline Operational Communications (AOC) data trac: It will strongly increase for e- cient airline operations • Air Passenger Communications (APC) systems: They foreseen to be further developed to meet passengers expectations of on-board broadband communication services. According to both SESAR and the Future Communications Study jointly performed by Eurocontrol and FAA under Action Plan 17, these services will use ground-based, satellite-based, aircraft-to-aircraft and airport communication systems to fulll the requirements: a satellite link (new standard developed within ESA IRIS program), an airport link (WiMAX), a high data rate air-ground link (L-DACS-1/2) and support of legacy data links (e.g. VDL2). In addition, further data links for APC are expected to be deployed. 11
3.2. Introduction to SANDRA scenario 3.1.2 NEWSKY testbed architecture Figure 3.1 shows the old NEWSKY test-bed architecture. It has not got any IPsec Security Gateways nor IPsec functionalities. Figure 3.1: NEWSKY test-bed architecture A further explanation of this type of topology is done in section 3.2.2. 3.2 Introduction to SANDRA scenario 3.2.1 SANDRA goals The SANDRA concept consists of the integration of complex and disparate communication media into a lean and coherent architecture that: • Provides and manages seamless service coverage across all airspace domains and all aircraft classes • Sustains growth in the service market and enables easy plug-in of future radio technologies through modularity and congurability • Is upgradeable, easy recongurable and radio technology independent • Is distributed and instantiated into consistent ground-based and airborne sub-networks ensuring full interoperability. SANDRA covers from RF and avionics components up to the middleware layer of the on-board network, assembled and integrated under the most stringent safety and security requirements. Ultimately, SANDRA pursues the architectural integration of aeronautical communication systems using: - Well-proven industry standards like IP, IEEE 802.16 (WiMAX), DVB-S2, Inmarsat SwiftBroadBand 12
3. Testbed Current Status - A set of common interfaces - Standard network protocols having IPv6 as nal unication point to enable a costecient global and reliable provision of distributed services across all airspace domains and to all aircraft classes. 3.2.2 SANDRA architecture and test-bed Figure 3.2 shows how SANDRA topology is in a laboratory environment. The upper box on the left is a lab environment that emulates a real scenario. The most right box of the picture can be considered as a black box, what happens inside it is transparent to us. It is the one that provide network access to the technology services such as satellite links (INMARSAT). The most left box is the one that corresponds to the airplane and that is also emulated in a laboratory environment. Keep in mind that the current testbed architecture is not like the one of the picture, but in a close future it should be something alike. Figure 3.2: SANDRA topology In gure 3.2 a box labeled IMR can be identied. IMR is an entity attached to MR that manages interface and trac information transparent to MR. Its mainly task is to take control of interfaces conguration. For instance, IMR determines that interface eth1 from MR is congured to be used with AR_Ku, it also handles situations where interfaces in MR go down and have to be reassigned to another AR_ link. 13
4.1. Considered Protocols as a solution for SANDRA In this scenario the mobile node is located in an IPv4/IPv6 network capable, however, it uses some application that requires IPv4 trac. • Scenario 5: IPv6 and IPv4-enabled networks In this scenario, the mobile node should prefer the use of an IPv6 care-of address for either its IPv6 or IPv4 home address. 4.1.3 NeXT NeXT is a protocol created and owned by TriaGnoSys GmbH company in Munich, Germany. The main aim of NeXT protocol is allowing the transmission of IPv6 packets through IPv4 links (i.e. Satellite). This is done by translating IPv6 headers to IPv4 and again to IPv6 after traversing these links. It can also work the other way round, to traverse IPv6 networks with IPv4 packets. Figure 4.5: NeXT NeXT consists of two main entities, • NeXTMaster • NeXTSlave 20
4. Mobility + IPv4 Traversal Both NeXTMaster and NeXTSlave consist of two sub-entities • NeXTMaster = NeXT64Master and NeXT46Master • NeXTSlave = NeXT64Slave and NeXT46Slave NeXT64 entity translates IPv6 trac into IPv4 trac and NeXT46 entity translates IPv4 trac into IPv6. In gure 4.6 the legend for the dierent types of packets used in gures 4.7 and 4.8 are shown. Figure 4.6: NeXT headers with IPv6 and mobility legend Figure 4.7 shows in a real world scenario which are the steps that NeXT does when MN starts talking to CN and MN is in a foreign network: 1. A node (MN) generates the the rst packet of a session, the destination is CN outside of the current MN network, thus the packet is sent to MR 2. When MR receives the packet it applies NEMO protocol to the packet (adding an extra IPv6 outer header). Afterwards it looks for an entry in the translation table(structure that holds the information required to translate the packet from one IP version into other), as it is the rst packet of the session it does not nd any entry matching the packet. Then a new entry is created and addresses and ports are assigned. 3. When an entry for the new packet is created the packet is sent with the IPv6 addresses and original ports as shown in gure 4.6. 4. The packet reaches NeXTSlave, it looks for an entry in the table, as it does not nd any entry it reads the IPv6 addresses from the packet and also the ports, then it creates a new entry for the packet. 5. The packet is translated and sent to the HA (remember that there is NEMO header in the packet). 21
4.1. Considered Protocols as a solution for SANDRA 6. The packet reaches the HA, due to in step 2 an outer IPv6 Header was included by NEMO using as source address the MR's HoA and as a destination address the HA's HoA. When the packet arrives to HA it decapsulates the packet (removes the NEMO outer header which includes the Home Addresses previously mentioned) it reads the CoA form the packet and searches it within its Binding cache (BC), if it is found in the BC then is routed to the CN. Figure 4.7: NeXT steps from MN to NeXTSlave Figure 4.8 show in a real world scenario which are the steps that NeXT does when CN starts talking to MN and MN is in a foreign network: 1. CN sends IPv6 packet to MN 2. Packet goes to HA 3. HA consults its BC and if the destination is found adds NEMO outer header (it includes source and destination HoAs) 4. HA forwards the packet to the destination HoA(MR HoA) 5. NeXT64Slave in AR receives the packet 22
4. Mobility + IPv4 Traversal Figure 4.8: NeXT steps from CN to MN 7. NeXT64Slave looks in the table if there is any entry that match the packet, as it does not nd any NeXT64Slave sends a signaling packet to the NeXTMaster with the addresses and ports in IPv6 and asking to NeXTMaster an allocation of a IPv4 address. NeXTSlave knows the master address due to it is specied in a conguration le, however, the address is also provided by the rst packet that NeXTMaster sends to NeXTSlave to start an exchange of trac data. For further details about this conguration please see gure 4.10. 8. NeXTMaster assigns a IPv4 address and ports and creates a new entry in its table structure. 9. NeXTMaster sends a request ack to NeXTSlave with the new information. 10. When NeXTSlave receives the information, it creates a new entry in the translation table and translates the header. Bear in mind that this packet that is going to be sent does not contain any IPv6 address since IPv6 address have been previously stored in NeXTMaster when the signaling request packet was sent. 11. NeXTSlave sends the packet 12. NeXTMaster receive the packet and translates it 23
4.2. Protocol comparison 13. NEMO protocol removes the outer IPv6 NEMO header, and forward to its recipient. NeXT protocol uses libnetlter_queue library. Libnetlter_queue is an userspace library providing an API to packets that have been queued by the kernel packet lter. It is part of a system that deprecates the old ip_queue /libipq mechanism. Libnetlter_queue has been previously known as libnfnetlink_queue. It allows receiving queued packets from the kernel nfnetlink_queue subsystem and also issuing verdicts and/or reinjecting altered packets to the kernel nfnetlink_queue subsystem. NeXT stands for an ecient way of using IPv4 links bandwidth. One kind of IPv4 link that nowadays is used is satellite links. It provides communication in vast areas where other technologies and mechanisms can not, for example in transatlantic airplanes ights. However, despite satellite links are currently thought as an appealing solution to intercommunicate (specially in the skyline) it has one feature, using a satellite link is expensive in terms of time/trac usage. NeXT introduces trac overhead saving by how it translates IPv6 packets into IPv4 format. NeXT saves space bandwidth on using the satellite link due to how it translates packets from IPv6 to IPv4. NeXT does save space by sending at rst all the IPv4 and IPv6 information required to NeXTSlave to do a mapping between the two IP versions (IPv6 address with ports 85000 and 86000 corresponds to the IPv4 address 184.67.9.5). When the NeXT Slave has a mapping entry in itself data structure the following packets from the ow only carry IPv4 information (IPv6 mobility headers also) due to IPv6 information had been previously stored in the NeXTMaster and NeXTSlave. It is not just UDP encapsulation, it is something more ecient than this. 4.2 Protocol comparison A list of drawbacks and advantages will be given for two of the three protocols introduced. M6T is not considered for the following reasons. In the earlier process of analyzing its features I thought that it was not worth to consider it anymore because it was something alike to NeXT protocol and furthermore it added a constant overhead into the satellite link. What is considered as overhead is the outer IPv4 and the UDP headers added to the original packet. A satellite link is something very expensive in terms of trac usage, normally whoever uses a satellite link will be normally paying for an amount of trac consume through the link. Therefore adding always 28 bytes of extra headers was not an appealing matter, NeXT solution managed even better and in an ecient way this issue. This is why for that reason M6T will not be considered in this comparison and pros and cons. DSMIPv6 and NeXT will be the only ones. Pros and Cons for DSMIPv6 protocol are shown below. Advantages : • Allow v4 CoA 24
4. Mobility + IPv4 Traversal • Allow v4 HoA • Is a Standard Disadvantages : • DSMIPv6 implementation is buggy • Can't run MultipleCoA-patched implementation + NEMO • NAT traversal is not implemented • Overhead with UDP addition The DSMIPv6 implementation that exists and has been considered in this analysis is the one from Nautilu67 . One of the drawbacks says that the MultipleCoA-patched implementation and NEMO patch cant not work together. There is not so much information about this drawback, it is only mentioned in its ocial website. Therefore it has been deduced that MultipleCoA-patched implementation and NEMO patch cant not work together due to how they are installed. Both of them are patches to the Linux kernel that add and replace lines from it, It can happen that there can be and overlapping of some kernel lines, therefore some functionalities of those patches can not work properly. In the test-bed, one very important feature was the use of multiple addresses, it was a must. Multiple-CoA had to be present in the test-bed. Moreover NEMO was also a feature of the testbed that was a must, on the top of that, they were both already installed in the testbed. For that reason it was an important drawback that subtracted points into consideration to DSMIPv6. Apart from that DSMIPv6 implementation performance was not quite stable. It showed so many troubles with handovers performance making the whole system unstable because after a serie of repetitive handovers the DSMIPv6 software crashed. There were other bugs such as some conguration policies dened by DSMIPv6 that were not removed after exiting from it. Having a stable behavior was something sought and DSMIPv6 didn't seem to provide it. Nowadays DSMIPv6 implementation hasn't got some functionalities, for example DSMIPv6 lacks of NAT traversal implementation. However, not all about DSMIPv6 is negative, it has positive features like the possibility of using a CoA v4 address and the dynamism it introduces because it makes possible to have only one Mobile IP protocol deployed. DSMIP is being also considered by companies such as Qualcomm whose Smart Mobility team is developing a solution based on the Dual Stack Mobile IP (DSMIP). Pros and Cons for NeXT protocol are shown below. Advantages : • Reliability of its functionality • Satellite bandwidth performance Disadvantages : • It is not a Standard 25
4.3. NeXT as option chosen 4.3 NeXT as option chosen NeXT protocol has been nally the chosen option for its deployment in the SANDRA scenario. It allows having Multiple-CoA and NEMO running at the same time. Furthermore it guarantees an ecient use of the satellite link bandwidth as it has been explained in section 4.1.3. Adopting NeXT for the SANDRA project has its implications and a deep process on analysis has to be performed. NeXT has two main entities, NextMaster and NextSlave. It was rst implemented as a one-to-one channel, it means NeXTMaster entity only communicates with NeXTSlave entities, a one-to-one speech. However within SANDRA this change due to its architecture. Figure 4.9: SANDRA scenario with NeXT What comes now is the whole analysis that was made to determine how NeXT would look like if it would have been used in SANDRA and which new requirements would appear as a result of this process. An explanation of gure 4.9 will be given next. Figure 4.9 shows the SANDRA topology scenario using NeXT. In this case what is on the right side of TriaGnoSys router is an emulation of SANDRA scenario but emulated inside TriaGnoSys network. TriaGnoSys router acts as an ARv4 that leads to an IPv4 network. Within this IPv4 network there are some ARv6 that correspond each one to a specic Regional Area IPv6 Network. A Regional Area Network is an IPv6 Network that can be related whether to a geographic area or a type of service. Lets suppose that there are two mobile nodes (two mobile devices) that have paid for some satellite data bandwidth and also for a certain time duration. Lets identify the two mentioned mobile nodes as device A (DA) and device B (DB). DB has paid for a better and quicker access to the network than DA. DB then is supposed to have better speed than DA. DA has paid for service A and DB has paid for service B. When packets from DA reaches MR, they are sent via the link that is associated to the type of service, service A in this case. Then packets reach TriaGnoSys ARv4 and some polices are consulted to determine to which ARv6 the packet has to be sent. Looking to gure 4.9 there is a Mobile Network attached to a MR. In the Mobile Network there are dierent nodes that use dierent contexts, by dierent contexts we mean there are 26
4. Mobility + IPv4 Traversal Figure 4.10: Flow packet dierent needs of using one specic resource or another (L-band, Ku-band, WiMax2,..) depending on the requirements in ow trac type. So in some how we depend of what IMR tells us, on which information it provides allowing to congure Policy Rules, NEMO, and NeXT Master in MR. • NeXT Master needs to know the interface information to establish a binding socket channel with NeXT Slave, i.e. NeXT Master needs (1) a local interface on the MR with an IPv4 address (IPv4 CoA) of the respective IPv4 access network (can be virtual I/F), and (2) the IPv4 address of the respective NeXT slave. This channel is used to exchange signaling and data. • Assuming this, it is supposed that IMR (an entity attached to MR that manages interface and trac information transparent to MR) provides the information required. The following ow chart illustrate what is exchanged since MR request information resource to the IMR, and to when all is properly congured. Figure 4.10 shows a owchart that describes the steps taken to allow the MR receiving some router advertisements from a regional ARv6 which it has not any bound yet with. The steps are the following: 27
4.3. NeXT as option chosen 1. MR asks for information (makes a resource request Resource Req 1) to IMR 2. IMR issues according resource request to the respective access network (chosen by either MR or the IMR) 3. ARv4 (ground station) replies giving a CoAv4 • CoAv4 can be public • CoAv4 can be private (NAT required in IMR or in access network) 4. With allocation of an CoAv4, the IMR needs to decide which virtual interface is set-up between IMR and MR (VLAN, ppp,...). CoAv4, VLANx, and AccessNetwork information is sent within the Ack to the MR. 5. MR receives the Ack from IMR 6. MR congures a CoAv4 and it congures a new interface. Now NeXTMaster (in MR) can establish a channel communication with NeXTSlave (in Regional ARv6). 7. NeXTMaster sends a packet with information to NeXTSlave using a src IPv4 address (the CoAv4) and a destination IPv4 address (the NeXTSlave IPv4 addr.). 8. NeXTSlave doesn't know about NeXTMaster, but Master does (it knows AccessNetwork/Ground Station, thus public address v4 of NeXTSlave is deduced (it is likely that there is a NAT before the NeXTSlave that must be congured accordingly to pass packets from the NeXTMaster to the proper NeXTSlave) 9. MR link hasn't got a CoAv6 yet, it is provided by Router Advertisements (Ra). However router advertisement 1 (Ra1) and router advertisement 2 (Ra2) can not reach MR till NeXTSlave knows about NeXTMaster. 10. Ra1 and Ra2 are discarded by the Arv6 because it doesn't know what to do with them. After NeXTSlave knows about Master router advertisement 3 (Ra3) is sent. 11. MR receives the Ra3 and congures an CoAv6 (NEMO does this). 12. Afterwards MR congures IPv6 policing rules to route the respective trac over the newly set-up (virtual) interface. The MR also need to transmit the applicable reverse policy routing rules to the HA. Which NeXTSlave shall be used by the NeXTMaster depends on a-priori assumptions w.r.t. where the ARv6 is located in the ground network for a given access network, i.e. it should be congured and dened by the user. Example: If the assumption is that the ARv6 of the Ku-band access network lies in Region 1, then it must be congured in the NeXTMaster that for all CoAv4 belonging to the Ku-band access network the NeXTSlave belonging to the ARv6 in Region 1 is used. This ensures: (a) The CoAv6 address allocated to the respective MR interfaces are belonging to the respective ARv6, which ensures that also the return packets (CN -> MNN) are routed over the correct ARv6 28
4. Mobility + IPv4 Traversal (b) NeXT packets are sent from the NeXTMaster to the right NeXTSlave. Further, there a several options that could be considered for the case when an access network and accordingly the resources already allocated on it become unavailable, however, it is out of the scope of my project considering them. But why NeXTSlave is said to be placed in ARv6s? The reason is the following one. Apart from ARv6s, the only feasible candidate to think for hosting NeXTSlave is the HA. However, placing NeXTSlave in HA means that there is no possible way at all to route the packets through a specic region network area due to the lack of routing information. Thus turning into an impossible task to guarantee that a packet traverses a specic Region network. That is why by using ARv6 it can be provided within router advertisements prexes addresses to congure an IPv6 CoA which solves the routing problem. 29
5.3. Considered options for the automation in Line 1 had previously congured some behavior. It can be said a matter of prerequisites and requirements. A typical /etc/rc.local structure is the following one from below: Figure 5.4: Rc.local le The le starts with a shebang line, the one that says #!/bin/sh -e . In computing, a shebang line is the character sequence consisting of the characters number sign and exclamation point (#!), when it occurs as the rst two characters in the rst line of a text le. In this case, the program loader in Unix-like operating systems parses the rest of the rst line as an interpreter directive and invokes the program specied after the character sequence with any command line options specied as parameters. After the command lines the script terminates with the exit command with a 0, saying it successfully exits from the script. As it has been mentioned, testbed nodes have various conguration scripts, some of them can be specied in the /etc/rc.local le, but there are others that are better not to because depending on which scenario it is intended to perform a simulation there will be some conguration scripts that will be load and others that won't. Besides, there are scripts that needs input values that dene for example packet delay, interfaces and other parameters. That means there is the need of human interaction to in a nal instance congure the testbed for a scenario that requires an specic behavior. It can be said that there are mainly two scenarios, each one with its correspondent scripts and conguration les. These two scenarios are: • Simulating a satellite link using tc command, adding delay to the packets. • Using BGAN satellite link. 36
5. Testbed Automation The steps to be followed in order to perform the automation process are: • Some conguration les are added to the /etc/rc.local • Once the node is either rebooted or started up the conguration les in /etc/rc.local are sequentially launched. • The user executes a bash script from the command line This last point of the list, executing a bash script from the command line is the step in which there is human interaction with the system in terms of conguration actions. An example of a scenario simulation base case will be now introduced. Base case: Given an scenario using Satellite emulation link, scripts A, B, C and D are dened in the /etc/rc.local. All the testbed nodes are rebooted. Then afterwards launching a script, it doesn't matter if it is whether from local computer or Humboldt. This script will make a series of question asking for specic behavior matters, such as, ¾Do you want to apply packet ltering¾`, if the answer is armative then some parameters to the packet ltering are suggested for the system. Afterwards the user is able to choose whether accept the suggestion or dene its owns parameters. This series of questions establish a specic conguration for the whole testbed behavior. Once the user has answered all the questions, a list of all the options previously chosen is shown and the user is asked to conrm if all the parameters and options are okay. In case of selecting No the user has the option to modify the parameters and options he wants. Until this step there has been no orders to any of the testbed nodes, what has been done is to store the options chosen by the user in variables. That means that only after the user conrmation remote commands using ssh are sent to the dierent nodes of the testbed to successfully launch the scripts that determine a behavior. 5.3.3 Use of /etc/rc.local + Java GUI + Bash scripts The third option considered for the testbed automation is the implementation of a Java Graphic User Interface (GUI). This Java GUI checks the node's status under request and manages the start, reboot, and shutdown of them either one per one or by various at same time. In sections 5.2 and 5.3.2 /etc/rc.local has been widely explained so its features and whereabouts will not be discussed again in this section. What this option oers as a new feature is the use of a Graphic Interface to manage all the nodes (start, reboot, shutdown), this means that to a user non familiar with shell environments it becomes easier to manage nodes because of the GUI, with just one mouse click the nodes are controlled. The main dierence between this option an the one in section 5.3.2 is the absence of a script asking the user input data in order to determine the nal behavior. Instead of that there is a GUI. This option aims to provide a better user interface usage. 37
5.4. Final option: Use of /etc/rc.local + Java GUI + Bash scripts Figure 5.5: Java GUI 5.4 Final option: Use of /etc/rc.local + Java GUI + Bash scripts Three possible options have been described as a solution for the IPv6 Network Mobility Testbed. 1. Use of Cron + Bash scripts 2. Use of /etc/rc.local + Bash scripts 3. Use of /etc/rc.local + Java GUI + Bash scripts One of the requisites was that the usage of the testbed conguration, switching either physical nodes or VM's on had not to be a hard task. For that reason the use of a Java GUI (third solution) has been decided as the best option for those purposes. 5.4.1 Dierent features of the Java GUI In section 5.3.2 it was said there were two main dierent scenarios behaviors, Simulating a satellite link and BGAN satellite link . It was mentioned that the testbed uses some XEN VMs, depending of which scenario behavior has to be tested those XEN VMs will need a dierent 38
5. Testbed Automation conguration le (.cfg) to be loaded. In this .cfg le there are all the information of the VM, the OS image (img) it uses, which interfaces has to be congured, MAC addresses to ensure they are unique and there is no conict, also which bridges are congured and other things. However, as the NEWSKY project was going to nish within some weeks and the testbed architecture was going to change in a close future it was nally decided not to devote some many time in that. Therefore some decisions were taken. One of them was the decision of letting as precongured the Satellite emulated link behavior, that means the VMs starts automatically with the correspondent .cfg le, in the GUI there is no option to change that, however in a future extension and adaptation of the GUI to the new SANDRA testbed architecture it could be done. A node is supposed to be up if it fullls the following requirements: 1. It is reachable through the network (3 ICMP packets are sent using ping -c 3 ) 2. All the processes within a list are running in the node The ow from below, gure 5.6 exemplies how the status of a node is checked. Figure 5.6: Flow Checking Nodes Status To check if whether a process is running or not a shh connection is deployed and afterwards a Unix command is executed. This Unix command tries to identify a nameprocess in the remote 39
5.4. Final option: Use of /etc/rc.local + Java GUI + Bash scripts node, the name of the process is the one that is extracted from lprocess.get(i). The line from below describes what has been explained in this paragraph. ssh ro[email protected] ps -e | grep " + lprocess.get(i) + " | tr -s /" /" | cut -d /" /" -f5 The following ow chart gure 5.7 shows the ow when a start action is called from the GUI. Bear in mind that in the Create HA VM box in the inner code it is established to use Satellite Link Emulation congure le (.cfg). In a future extension it can be programmed a functionality to change among this and the other. Figure 5.7: Flow Start Node The following ow chart gure 5.8 shows the ow when a stop action is called from the GUI. In the box Shutdown XEN ID VM a shutting down action is performed in Humboldt node. Humboldt node allocates dierent VMs in its domain, so what is done in the Shutdown XEN ID VM box is once the identier of the VM within Humboldt is captured it is used to identify the VM to be stopped. The command to stop the XEN VM is the one in gure 5.9. 40
5. Testbed Automation Figure 5.8: Flow Stop Node Figure 5.9: Stop VM command The ow chart from gure 5.10 exemplies the case when a node is being requested to be rebooted. If the node is not available because it is down then it can not be rebooted, otherwise the rebooting process is followed 5.4.2 Where are the scripts located and how are they executed ? Hardly all the scripts in a node are located in a specic path folder directory, this guarantees the scripts to be stored in the subversion, making it possible to easily reestablish all the scripts les in case of a major disaster. It can be said that they are all centralized in a directory instead of being spread along the node path directory tree. In section 5.3.3 it has been explained that scripts are previously predened in the /etc/rc.local script le. Two things have to be considered, one is that the actual conguration takes into account that as a precongured conguration is being used then the required scripts are dened in 41
5.4. Final option: Use of /etc/rc.local + Java GUI + Bash scripts Figure 5.10: Flow Reboot Node the /etc/rc.local. The other thing to take into account is that it is easily feasible to extend and modify the code to make that instead of dening some scripts in the /etc/rc.local they nally become executed by the GUI application by evoking them remotely. The Java GUI app can be executed from outside the testbed, there is no need of launching it from a testbed node. However some previous steps are needed to be followed. Those steps are mainly conguring a reliable shh key intercommunication channel. It is achieved by creating an own ssh key certificate8 copy it to the testbed nodes the computer will connect and also copy the ssh key-certicates from the testbed nodes to the local computer. Another step that needs to be done is copy the java GUI les from the subversion trunk or from one of the testbed nodes that has the java les in there. 42
Chapter 6 NeXT software architecture/design In this chapter some aspects of NeXT rst version (the previous one to my project) design will be explained for a better comprehension. Which changes have to be introduced into NeXT rst version in order to adapt it to the new SANDRA scenario will be also explained. And nally, two dierent NeXT new design approaches will be described. 6.1 NeXT rst protocol version design As it has been mentioned in section 4.3 in a previous chapter, NeXT rst code was thought for a one-to-one communication, it means NeXTMaster has only communication exchange with one NeXTSlave and viceversa. NeXTMaster only sees NeXTSlave and this last one only sees NeXTMaster. Figure 6.1 shows an example of NeXT deployment in a typical topology network in real world. Figure 6.1: NeXT real world architecture 43
6.2. New NeXT requirements in SANDRA scenario Figure 6.2: NeXT real world using satellite link Figure 6.2 shows a scenario using a satellite link within TriaGnoSys GmbH company network, using an AR with NAT as an entry gateway to the company network. NeXT uses some resources in order to make the translation from IPv6 packet to an IPv4 packet and the way round. These resources are related with processes identiers, addresses information and also some data structures that holds the information required to have an IPv6IPv4 mapping as commented in section 4.1.3. NeXT64(either NeXT64_Master or NeXT64_Slave) and NeXT46 (either NeXT64_Slave or NeXT46_Slave) holds its own data structure which is in charge of keeping the information required for a packet translation (one way IPv6 to IPv4 for NeXT64 and the other way, IPv4 to IPv6 for NeXT46). Apart from that NeXT uses SIGNALS9 to let NeXT46 entity and NeXT64 entity exchange information among them. Moreover SIGNALS are used for a proper termination of NeXT protocol under demand, when an order of termination is sent to NeXTMaster this one sends a notication to its NeXTSlave interlocutor saying that it is going to go down until new notication. NeXTSlave then cleans its context related with its NeXTMaster interlocutor. Some ows, will be shown to give a glance of how NeXT works, but just as example given. Please see gures 6.3 and 6.4 6.2 New NeXT requirements in SANDRA scenario As mentioned in section 4.3 NeXT has been chosen as the option to be deployed in SANDRA scenario. As a result of this it can be seen in gure 4.9 how does NeXT look like in this new scenario. Things to point out, assuming that only one MR is being considered, are: 1. There are multiple NeXTMaster instances in the same MR 2. There is one NeXTSlave in each Region Network Area (see gure 4.9) 44
6. NeXT software architecture/design Figure 6.3: NeXT64 Master ow What do this two last points mean? It means that the way NeXT worked before in its rst release version is not longer valid anymore due to the existence of multiple NeXTMaster instances in MR. In section 6.1 it has been said that NeXT was originally thought of a one-to-one protocol, this has some coding implications in terms of NeXT own resources management and NeXT inter-entities communication (NeXT46-NeXT64 communication ow). As an example given, if NeXT46 wanted to communicate some information to NeXT64 it looked in the Linux process list by using the command ps piped with other commands, and it searched for a process called NeXT64_Master. This proceeding didn't represent a problem of behavior in a one-to-one mode operation, however, as MR has turned into an entity with multiple NeXTMaster instances the proceeding previously explained would be problematic and would lead to a non stable behavior and performance. For instance, for a better comprehension in the following example it is assumed that MR has two NeXTMaster instances (2 x NeXT64Master and 2 x NeXT46Master), lets call them: • NeXT64Master_1 • NeXT64Master_2 • NeXT46Master_1 • NeXT46Master_2 45
6.3. Two dierent NeXT design approaches hardcoded) and each instance needs a dierent interface conguration in order to work. This hardcoding of the interfaces was done by dening in a .h le a set of interfaces using denes 10 , as this le is included in almost all the les they can be used. NeXT uses pugixml11 , it is a light-weight C++ XML processing library. It is developed and maintained since 2006 and has many users. All code is distributed under the MIT license, making it completely free to use in both open-source and proprietary applications. NeXT protocol is coded in C language, however the NeXT launcher is coded in C++, and it is the NeXT launcher that uses pugixml, to C les it is something transparent. The reason for using C++ in the launcher instead of C language is due to the intention of using threads, using the C library pthread.h , in NeXT threads an encapsulation using this library was made in order to make the code more object oriented. Leaving this matter of pugixml usage, in order to add this dynamism to NeXT the following modications were done, gure 6.9 shows a portion of the original code in the .h le previously mentioned. Figure 6.9: Interfaces hardcoded To add dynamism extern variables are used, they get the value from upper c les (NeXT64 and NeXT46 entities which received the information as input parameters, the ones read from the xml conguration le). In gure 6.10 it can bee seen. Figure 6.10: Interfaces hardcoded with dynamism When an extern variable is declared, the compiler is told that the variable was dened elsewhere. The compiler is told that a variable by that name and type exists, but the compiler should not allocate memory for it since it is done somewhere else. The extern keyword means "declare without dening". In other words, it is a way to explicitly declare a variable, or to force a declaration without a denition. When a #dene is done it allocates memory that remains until the program nishes its execution. It exists a xml conguration le per each NeXT working mode, an xml le is loaded depending on the parameters given to the NeXT launcher execution: ./NeXT start 3 master sat 1 If master and sat then Satellite master mode is loaded. All the possible modes are listed below: • Satellite master 52
6. NeXT software architecture/design • Satellite slave • Satellite emulation master • Satellite emulation slave Before this NeXT multiprocess approach NeXT had four launching scripts, each one for each of its working mode. In this scripts some parameters had also to be given. So, whenever NeXT had to be launched it had to be thought which scripts was the correct one. Now, by using the NeXT launcher this is reduced to a only one binary le. In the earlier paragraphs of this section it has been mentioned the use of process number identier (PID) in order to both kill NeXT instances running and send a SIGNAL to a specic NeXT entity. This PID information was stored in le systems and read by NeXT64 and NeXT46 entities. Sending a SIGNAL to a specic NeXT instance now is not as easy as searching one name process, now it is done by reading the PID from a le in the system, this introduces one problematic situation which is ¾How can it be guaranteed that the le that holds the PID has been created¾` . If the le has not been created then there is no way of reading the PID of the entity it is intended to send SIGNALS. It is solved by applying something similar to a handshaking process. Figure 6.11 shows how it is done. Figure 6.11: PID Handshaking 6.4 Threads Introduction 6.4.1 What is a Thread A thread is an application task that is executed by a host computer at the same time as others. It is an independent stream of instructions that can be scheduled to run as such by the operating system. For instance, imagine a main program (threadi.bin) that contains a number of 53
6.4. Threads Introduction Figure 6.12: UNIX thread procedures. Then imagine all of these procedures being able to be scheduled to run simultaneously and/or independently by the operating system. That would describe a "multi-threaded" program. In gure 6.12 an UNIX process structure and an UNIX THREAD is shown. Threads shares memory among themselves, it means almost all variables and information are shared. Threads can have its private data though. In gure 6.13 shows in large scale this last assertion. Things to bear in mind about threads: • Has its own independent ow of control as long as its parent process exists and the OS supports it • May share the process resources with other threads that act equally independently • Dies if the parent process dies • Is "lightweight" because most of the overhead has already been accomplished through the creation of its process. • Changes made by one thread to shared system resources (such as closing a le) will be seen by all other threads. • Reading and writing to the same memory locations is possible, therefore requires explicit synchronization. 54
6. NeXT software architecture/design Figure 6.13: Thread Memory 6.4.2 Why using threads? It has become a growing up option during last decade and it provides appealing performance results in multithreading capable nodes and nowadays almost all nodes are multithreading. It allows to have a better resource management. Historically, threading was rst exploited to make certain programs easier to write. If a program can be split into separate tasks, it's often easier to program the algorithm as separate tasks or threads. NeXT didn't match this description since what it did was follow a sequence of instructions for treating a packet. The idea of using threads in NeXT was to save space in terms of memory and a better performance taking advantage of nowadays multithreading nodes capabilities. Why saving space? NeXT new version needs to launch multiple NeXTMaster entities, this means for each NeXTMaster entity there is a memory space to be allocated, depending of the cardinality of the #NeXTMaster entities this can become something critical if the number of ARs is big enought. 6.4.3 What is pthread library? Pthreads are a set of C language programming types and procedure calls that NeXT threads uses. 55
6.5. NeXT threads Hardware vendors have implemented their own proprietary versions of threads for years. These implementations diered substantially from each other making it dicult for programmers to develop portable threaded applications. In order to take full advantage of the capabilities provided by threads, a standardized programming interface was required. For UNIX systems, this interface has been specied by the IEEE POSIX 1003.1c standard (1995). Implementations adhering to this standard are referred to as POSIX threads, or Pthreads. Nowadays most hardware vendors now oer Pthreads in addition to their proprietary API's. The latest version is known as IEEE Std 1003.1, 2004 Edition. 6.5 NeXT threads Figure 6.14: Thread Memory Figure 6.14 shows the NeXT thread design architecture, it can be appreciated that it is similar to the one in NeXT multiprocess (see section 6.7). In NeXT threads both NeXT Main Process and child processes remains alive until a terminate signal is sent. The reason is that as a thread uses the process memory space, if its process (the one that has created it) disappears then the thread has not memory space. NeXT64 and NeXT46 entity have each one a data structure that holds the information required to translate packets from IPv6 to IPv4 and viceversa. This data structures follows the concept of extern variables explained in section 6.3.1, they are dened as global variables in NeXT64 and NeXT46 entities (both has it declared with the same name) and whenever someone wants to use this data structure it has to declare it as extern. In NeXT multiprocess design this means that every data structure is unique and there is no conict of names due to the fact that NeXT64 is a process and NeXT46 is another independent process. The result is the following one from the gure 6.16, there is a link or union between NeXT64 and NeXT library (inside is called extern type_data_structure name), and another link dierent between NeXT46 and the NeXT library. These dierent links avoid name conicts with the data structure. However in NeXT threads there is one big problem, both NeXT64 and NeXT46 have a data structure declared with the same name struct tab table in a global way. As in threads 56
6. NeXT software architecture/design environment there is the shared concept introduced in section 6.4.1, both declarations generates a name conict declaration because there are two variables with the same name, struct tab table from NeXT64 sees the one from NeXT46 and viceversa. It also happens with the methods in the NeXT library as it can be seen in the gure 6.16. In order to solve this problem, I thought of two options: 1. Use a common table for both NeXT64 and NeXT46 2. Declare one struct tab with a unique name, struct tab table for NeXT64 and struct tab table_4 for NeXT46 The rst option was thought because of the shared memory feature, this allowed the two entities share the same resource and it simplied some code aspect modications in NeXT library. However, sharing the same resource had the following implications: • Same resource for both entities makes the concurrency of reads and writes raise, (this adds such a level of complexity that the number of reads and writes in the data structure are less than if two data structures are used due to locks for data integrity). • NeXT64 struct tab table had an order inside its specication of each of its elds. NeXT46 struct tab table had other order. Point two implied that almost all the code had to be changed, and there was no guarantee that it would have worked because there were so many things to be changed. NeXT code made a strong use of its data structure that hosts the information required for packets translation, thus it was like rewriting a big portion of the code. Doing this would have represented that identifying bugs in case of showing them up would have been dicult. The priority was to have a working NeXT solution in time. This option mention decreased the overall of writes and reads in a certain period time due to the ghting for the common resource and locking aspects. Figure 6.15: NeXT multiprocess table linkage 57
6.5. NeXT threads Figure 6.16: NeXT threads table linkage Declare one struct tab with a unique name, struct tab table for NeXT64 and struct tab table_4 for NeXT46 was what was more feasible and was developed in a nal term. Within NeXT library there were some methods exclusively used by NeXT64 and others only used by NeXT46, this allowed a dierentiation between struct tab table for NeXT64 and struct tab table for NeXT46. There was a problem with the le descriptor variable , it happened the same problem as the struct tab table. There was a global le descriptor variable dened in NeXT64 named fd_log , but there was another global le descriptor variable named fd_log in NeXT46. Due to the shared memory concept there was a name collision . For that reason the dierentiation between fd_log in both NeXT64 and NeXT46 was done, but only in those two. The le descriptor variable is used in a function inside the NeXT library methods, this method is: • int WriteLog( DebugLev debglev, char *str,...) Inside this function an extern FILE *fd_log is done. To solve the problem the WriteLog function had to change, turning into: • int WriteLog( DebugLev debglev, FILE* fd_log, char *str,...) Therefore, the fd_log variable had to be spread among the methods that used the WriteLog function in order to be used, extern variable was not used anymore. There is a well known saying that says, try not to merge SIGNALS and threads because it tends to be very tricky and a good performance and correct execution of the code can never be guaranteed. SIGNALS with threads is not something very recommended, at least there are so many opinions about that. One of the main reasons, not the only one, is the following one. If there are three threads, let's say T1, T2, T3, waiting to a specic SIGNAL, let's say SIGUSR1 SIGNAL. If the three threads have been created in the same process then, if a SIGUSR1 is 58
6. NeXT software architecture/design intended to be sent to T1, it can not be done the assumption that the SIGNAL will reach T1. The result will be something random. When a thread is created in a process the process is the one that handles SIGNAL reception. Whenever the process receives a SIGNAL it looks if there is some thread waiting to this specic type of SIGNAL, SIGUSR1 in our case. If the process has the information that there is at least one thread waiting to the specic type of SIGNAL, the process delivers the signal randomly to one of the threads that are waiting to the SIGNAL. By dividing the memory space for each NeXT pair the problem scale is reduced to two threads, both NeXT64 and NeXT46 share some SIGNALS type, thus en emulation of SIGNAL proceeding was done. Figure 6.17: NeXT threads SIGNALS In gure 6.17 it can be seen the design with this new SIGNAL emulation. The way it works is the following one. • NeXT64 creates the NeXTalarm thread which periodically sends information of the MR to NeXTSlave in order to keep the communication alive and its status. This information is sent via UDP packets upon NeXTalarm request. • NeXT NeXT64 creates the NeXTrequest thread and when NeXT46 receives a request from NeXTSlave, NeXT46 noties the NeXTrequest thread that a request has been stored in it and that it can read it now. This notication is sent by using pthread_cond_signal(pthread_cond_t *cond) pthread function and an emulation of semaphores with locks. For further information visit the pthread_cond_signal(3) Linux man page . 59
6.6. NeXT design chosen • NeXTrequest thread reads the request, makes its local tasks and notify NeXT46 that it has nished and that it can continue again with its tasks. • NeXtrequest thread waits for another notication Doing like this the SIGNAL behavior is emulated. It has to be said that SIGNAL emulation of SIGTERM was not implemented. There were some strange behaviors such as that after NeXTMaster had sent the rst packet (the one that tells NeXTSlave some information about NeXTMaster) to its NeXTSlave, no routers advertisements were observed. Instead of router advertisements there were some packets that seemed UDP data packets but they were considered by the NeXTMaster as router advertisements (Ra) when in the Wireshark sning tool they didn't appear as Ra. My guess is that the problem was due to a shared resource within the code, in charge of handling requests. 6.6 NeXT design chosen NeXT multiprocess has been chosen as the nal option. It is simpler than NeXT threads, it works, and it can be easily extended, modied, adapted and also maintained. NeXT threads implementation implied a non easy going code and a code not easily maintainable. However thread technology can contribute to good performance in a future NeXT version which is something good to consider in a close future. One of the objectives was to make NeXT and ROHC working together at the same time in the test-bed and it has been accomplished. Robust Header Compression (ROHC) is a standardized method to compress the IP, UDP, RTP, and TCP headers of Internet packets. It performs well over links where the packet loss rate is high,such as wireless links. In streaming applications, the overhead of IP, UDP, and RTP is 40 bytes for IPv4, or 60 bytes for IPv6. For VoIP this corresponds to around 60% of the total amount of data sent. Such large overheads may be tolerable in wired links where capacity is often not an issue, but are excessive for wireless systems where bandwidth is scarce. There is information in headers that can be predicted, there is information that is always the same, there is other information that can be predicted such as the sequence number of a packet in a specic ow. However there is other information that can not be predicted because there is no pattern to predict. ROHC take advantage of this dynamic elds in headers to save space, it converts them into a sequence number in the compressor and the decompressor interprets them. ROHC compresses these 40 bytes or 60 bytes of overhead typically into only 1 or 3 bytes by placing a compressor before the link that has limited capacity, and a decompressor after that link. The compressor converts the large overhead to only a few bytes, while the decompressor does the opposite. In SANDRA scenario using NeXT the compressor was placed at MR and the decompressor at HA. ROHC headers are placed in lower bits than NeXT headers, thus NeXT headers are applied after ROHC protocol is applied to the packet. It can be said that NeXT headers acts as a tunnel carrying ROHC headers. Both MR and HA can act as either compressor or decompressor. 60
Chapter 7 Test Cases The test cases that will be analyzed are two, Case1 (7.1) and Case2 (7.2) . Initially There were more test cases, however all of them could be summarize as Case 1 (7.1), so they were not specied in the report. Test cases analyzed are structured as follows. An explanation of which is the Aim of doing the test in the specic case is initially presented. There is afterwards an enumerated list of steps describing the conguration of the scenario and the steps that are taken to produce changes in that behavior. After this list it is shown the expected results of the testing and the real results observed after applying all steps in the testing. Finally there is a technical discussion about real results observed , and if it does not match with the expected results an explanation of why both two results do not match is given. In this report a gure of the current test-bed was previously presented, it is gure 5.1. Consulting gure 5.1 allows to follow easily explanations given after the results observed part in the specic case. It also helps on the understanding of the initial conguration of the test-bed specied in the enumerated list. It is recommended to consult gure 5.1, it can be used as support material. 7.1 Case 1 Aim of the test case: Demonstrate that with a starting scenario where two ARv4 are up and trac pass through them, if one AR goes down trac is redirected to the other AR link. 1. MR-AR1 and MR-AR2 links using IPv4 are up. 2. Ping from MNN SCgW to CN SCgW. 61
8.2. Future work and has shown positive results. It provides an interface to the nal user of something that is technical indeed but it can be seen as something less complex and easy to manage. This GUI is not a nal release, it is a young tool that has been conceived, a tool thought for being extended and also easy maintained and modied for other purposes (e.g. changes in the test-bed topology architecture, process of passing from NEWSKY project to SANDRA project). 8.2 Future work The Graphic User Interface is a tool that can be extended and adapted to new test-bed topologies. Some functionalities in the current GUI were discarded due time and objectives, the main objective was to dene an initial and operative base tool. Actions such as changing the type of the link that the MR uses can be done from the GUI (this function was implemented but was not full operative). Other tasks that can be done is to provide SNMP capabilities to the test-bed nodes for an easy monitored control. The test-bed uses XEN hypervisor, it uses XEN VM thus these VM has a limitation of 8 interfaces each one. This is a technical limitation documented in XEN web page that limits the testbed because it only allows to have two NEMO tunnel interfaces, this has been explained in section 7.1. It would be of interest to nd a way to replace the two interfaces dedicated to Mip6d, the idea would be to use tap interfaces. A tap is a loopback interface that works in layer 2. Some attempts were done to make it work but they were unsuccessful. An extension to the current NeXT implementation could be adding the functionality of launching and specic NeXT instance bound to an AR instead of always relaunching all previously dened in the xml conguration le. One of the objectives that has not been fullled is turning NeXT into threads due to technical reasons. Turning it into threads is something appealing however, things such as easy code upkeeping and code easy to understand have to be considered to decide whether it is worth or not. NeXT is an ecient technology applied to IPv4 traversal, and it is without any doubt a solution that can help into the intermediate process of migration from IPv4 to IPv6. 68
Chapter 9 References and Bibliography References 1. RFC 2460, Internet Protocol, Version 6 (IPv6) Specication 2. RFC 2374, An IPv6 Aggregatable Global Unicast Address Format 3. RFC 4301, Security Architecture for the Internet Protocol 4. http://www.inmarsat.com/Services/Land/BGAN/default.aspx 5. http://natisbad.org/m6t/ 6. RFC 5555, Mobile IPv6 Support for Dual Stack Hosts and Routers 7. http://www.nautilus6.org/ 8. Linux man page ssh-keygen 9. Linux man page signal 10. http://www.cprogramming.com/reference/preprocessor/dene.html 11. http://pugixml.org/ 69
Bibliography 12. RFC3095 (ROHC) 13. RFC 3963 (NEMO) 14. RFC 3775 (Mobile IPv6) 15. Understanding IPv6, Author: Joseph Davies, Microsoft Press (Book) 16. Programming with POSIX(R) Threads, Author: David R. Butenhof (Book) 17. Quadern de Laboratori de Xarxes de Computador (Book) Autors: Llorenç Cerdà-Alabern i José M. Barceló-Ordinas Departament d'Arquitectura de Computadors, Enginyeria en Informàtica Ref. 44301 18. Xarxes de Computadors, Conceptes bàsics (Book) Autor: Llorenç Cerdà Alabern Edicions UPC 19. Linux IPv6 Stack Implementation Based on Serialized Data State Processing (Paper) Hideaki YOSHIFUJI, Kazunori MIYAZAWA, Masahide NAKAMURA, Yuki SEKIYA, Hiroshi ESAKI, Jun MURAI. VOL.E87-B,NO.3 MARCH 2004 20. USAGI IPv6 IPsec Development for Linux (Paper) Mitsuro Kanda, Kazunori Miyazawa, Hiroshi Esaki 21. Versatile IPv6 Mobility Deployment with Dual Stack Mobile IPv6 (Paper) Romain Kuntz, Jean Lorchat 22. IPv6 IPsec and Mobile IPv6 implementation of Linux (Paper) Kazunori Miyazawa, Masahide Nakamura 23. Air Trac Management Network Based on IPv6 Protocol Stack (Paper) Eriza Had Fazli, Àngels Via Estrem, Núria Riera Díaz 24. IP Overhead Comparison in a Test-bed for Air Trac Management Services (Paper) Eriza Had Fazli, Àngels Via Estrem, Núria Riera Díaz, Sèbastien Duot, Markus Werner 25. The concept of robust header compression, ROHC (White Paper) EFFNET AB 26. An introduction to IP header compression (Wite Paper) EFFNET AB 27. Mobile IPv6 Technology Review (Document) Lancaster University 70
9. References and Bibliography 28. IPv6 Networking Over Satellite For Mobile User Group (Paper) Àngels Via Estrem, Axel Jahn 29. http://umip.linux-ipv6.org/index.php?n=Main.HomePage , [mip6d webpage] 30. http://www.cplusplus.com 31. http://stackoverflow.com 32. http://www.triagnosys.com 33. http://www.debian.org 34. http://www.linuxquestions.org 35. http://www.xen.org 36. http://www.netbeans.org 37. http://www.eclipse.org 38. http://live.gnome.org/Dia Note: - All RFC in both References and Bibliography have been read - (Links last visit - 23-03-2011) 71