18 research outputs found

    Estudi d'implantació de la IPv6 al CTTC

    Get PDF
    In recent years, the number of devices connected to Internet has increased exponentially and in fact, it is estimated that the demand keep on increasing. When IPv4 protocol was introduced, this evolution was not expected. Over the years several limitations have arosen, including scalability and the unsustainable growth of the Internet routing table. In the late 90s, IPv6 protocol was defined to solve these issues and add new features. Currently, the Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) has been forced to propose IPv6 deployment on its network mainly caused by the IPv4 address depletion, the increasing demand for devices connectivity and the need to support IPv6. RedIris and CSUC are encouraging and supporting the affiliated institutions like CTTC to deploy IPv6. This project is carried out by the IT department of CTTC, the Centre de Serveis Informàtics (CSI). The purpose of this project is, on the one hand, to analyse and acknowlege the main features of IPv6 protocol and show the differences with IPv4. It also aims to implement native IPv6 network in CTTC. On the other hand, the CTTC needs to give support with IPv6 in some basic services like DNS and web services. Finally, it is thought to compare IPv6 and IPv4 performance on the CTTC network. We analysed the network equipment and the network topology before proposing an IPv6 compatible solution. This causes the replacement of some network equipment. To gradually integrate IPv6 in the CTTC network we have chosen the dual-stack deployment. IPv6 is deployed in parallel with IPv4 on all infrastructure and services. We are adapting the DNS and the website service to IPv6 requests. In this project we are measuring the performance of IPv6 versus IPv4. We are running some tests to evaluate the performance through the calculation of the Round-Trip Time (RTT), throughput and Time To First Byte (TTFB) parameters. The results of the performance tests in the CTTC network are not showing important differences between the two protocols. The RTT is larger in IPv6, the throughput is higher in IPv4 and the TTFB depends on if the dual stack is enabled. The network latency is lower in IPv6 on a dual stack scenario. However, when there is only one protocol set the result is opposite. Thedistance between the origin and the destination of communications is relevant because this affects the latency of the connection. This is due to the number of hops to destination, the network type and the service provided. In another test, we are comparing IPv6 with NAT (Network Address Translation) to evaluate this alternative method as a solution to the IPv4 address depletion. The results obtained in the comparison are quite similar

    Developing the Fringe Routing Protocol

    No full text
    An ISP style network often has a particular traffic pattern not typically seen in other networks and which is a direct result of the ISP’s purpose, to connect internal clients with a high speed external link. Such a network is likely to consist of a backbone with the clients on one ‘side’ and one or more external links on the other. Most traffic on the network moves between an internal client and the external world via the backbone. But what about traffic between two clients of the ISP? Typical routing protocols will find the ‘best’ path between the two gateway routers at the edge of the client stub networks. As these routers connect the stubs to the ISP core, this route should be entirely within the ISP network. Ideally, from the ISP point of view, this traffic will go up to the backbone and down again but it is possible that it may find another route along a redundant backup path. Don Stokes of Knossos Networks has developed a protocol to sit on the client fringes of this ISP style of network. It is based on the distance vector algorithm and is intended to be subordinate to the existing interior gateway protocol running on the ISPs backbone. It manipulates the route cost calculation so that paths towards the backbone become very cheap and paths away from the backbone become expensive. This forces traffic in the preferred direction unless the backup path ‘shortcut’ is very attractive or the backbone link has disappeared. It is the analysis and development of the fringe routing protocol that forms the content of this ME thesis

    Context Aware Routing Management Architecture for Airborne Networks

    Get PDF
    This thesis advocates the use of Kalman filters in conjunction with network topology information derived from the Air Tasking Order (ATO) during the planning phase for military missions. This approach is the basis for an algorithm that implements network controls that optimize network performance for Mobile Ad hoc Networks (MANET). The trajectories of relevant nodes (airborne platforms) participating in the MANET can be forecasted by parsing key information contained in the ATO. This information is used to develop optimum network routes that can significantly improve MANET performance. Improved MANET performance in the battlefield enables decision makers to access information from several sensors that can summarize mission execution status real-time. In one simulated test case there was a 25% percent improvement of network throughput, and 23% reduction on dropped packets. Using this technique we can selectively preserve the Quality of Service (QoS) by establishing network controls that drops low priority packets when necessary. The algorithm improves the overall MANET throughput while minimizing the packets dropped due to network congestion

    Deliverable DJRA1.2. Solutions and protocols proposal for the network control, management and monitoring in a virtualized network context

    Get PDF
    This deliverable presents several research proposals for the FEDERICA network, in different subjects, such as monitoring, routing, signalling, resource discovery, and isolation. For each topic one or more possible solutions are elaborated, explaining the background, functioning and the implications of the proposed solutions.This deliverable goes further on the research aspects within FEDERICA. First of all the architecture of the control plane for the FEDERICA infrastructure will be defined. Several possibilities could be implemented, using the basic FEDERICA infrastructure as a starting point. The focus on this document is the intra-domain aspects of the control plane and their properties. Also some inter-domain aspects are addressed. The main objective of this deliverable is to lay great stress on creating and implementing the prototype/tool for the FEDERICA slice-oriented control system using the appropriate framework. This deliverable goes deeply into the definition of the containers between entities and their syntax, preparing this tool for the future implementation of any kind of algorithm related to the control plane, for both to apply UPB policies or to configure it by hand. We opt for an open solution despite the real time limitations that we could have (for instance, opening web services connexions or applying fast recovering mechanisms). The application being developed is the central element in the control plane, and additional features must be added to this application. This control plane, from the functionality point of view, is composed by several procedures that provide a reliable application and that include some mechanisms or algorithms to be able to discover and assign resources to the user. To achieve this, several topics must be researched in order to propose new protocols for the virtual infrastructure. The topics and necessary features covered in this document include resource discovery, resource allocation, signalling, routing, isolation and monitoring. All these topics must be researched in order to find a good solution for the FEDERICA network. Some of these algorithms have started to be analyzed and will be expanded in the next deliverable. Current standardization and existing solutions have been investigated in order to find a good solution for FEDERICA. Resource discovery is an important issue within the FEDERICA network, as manual resource discovery is no option, due to scalability requirement. Furthermore, no standardization exists, so knowledge must be obtained from related work. Ideally, the proposed solutions for these topics should not only be adequate specifically for this infrastructure, but could also be applied to other virtualized networks.Postprint (published version

    Análisis del protocolo Ipv6 su evolución y aplicabilidad

    Get PDF
    El cambio de Internet 4 a Internet 6 es necesario conforme el espacio de direcciones asignables se reduce y crecen los sitios y aplicaciones que requieren les sea asignada una IP propia, por lo tanto es necesario que desde ya se empiece a desarrollar una metodología de migración en las redes locales, al igual que se desarrolla políticas de seguridad, de compartición de recursos, etc.Descripción de IPv4.- Organización de internet.- Modelo de referencia OSI frente a TCP/IP.- Problemas con IPv4.- Historia del IPv6.- Características de IPv6.- Notación IPv6.- Tipos de direcciones IPv6.- Datagrama IPv6.- DNS para IPv6.- principales protocolos en IPv6.- Seguridad en IPv6.- Organización administradores, políticas de distribución y asignación de direcciones Ipv6.- Funciones de DSTM.- Túneles .- Traductores.- Implementación de una isla IPv6 y conexión con el 6bone

    Privacy-Aware and Secure Decentralized Air Quality Monitoring

    Get PDF
    Indoor Air Quality monitoring is a major asset to improving quality of life and building management. Today, the evolution of embedded technologies allows the implementation of such monitoring on the edge of the network. However, several concerns need to be addressed related to data security and privacy, routing and sink placement optimization, protection from external monitoring, and distributed data mining. In this paper, we describe an integrated framework that features distributed storage, blockchain-based Role-based Access Control, onion routing, routing and sink placement optimization, and distributed data mining to answer these concerns. We describe the organization of our contribution and show its relevance with simulations and experiments over a set of use cases

    Comparison of routing software in Linux

    Get PDF
    Linux-käyttöjärjestelmä yleistyy nykyään yhä enemmän ja enemmän. Verkkoyhteydet tulevat nopeammiksi ja niiden määrä kasvaa koko ajan. Nykypäivän verkot tarvitsevat reititystä, jotta viestit voidaan välittää Internetissä eteenpäin kohti vastaanottajaa. Linux-järjestelmät voivat toimia reitittiminä. Tässä työssä käsittelemme sekä Linux-käyttöjärjestelmää että reititystoiminnallisuutta. Reititysohjelmistomme perustuu FreeBSD-käyttöjärjestelmään. Tässä työssä tutkimme, kuinka hyvin tämä ohjelmisto toimii Linuxissa. Ensimmäinen toimenpide on muokata reititysohjelmisto yhteensopivaksi Linuxin kanssa. Sen jälkeen tutkimme ohjelmiston toiminnallisuutta Linuxissa vertailemalla tätä reititysohjelmaa kahden kaupallisen ja yhden avoimeen lähdekoodiin perustuvan reititysratkaisun kanssa. Vertailu koostuu suorituskyky- ja ohjelmiston kompleksisuuden mittauksista. Näiden mittausten tulokset eivät pelkästään näytä, että ohjelmaa voidaan ajaa Linuxissa, vaan antavat myös lisätietoa siitä, miten reititysohjelmistot suorittavat reititystehtäviä. Ohjelmiston kompleksisuusmittausten tuloksena näemme lähdekoodin laadun vertailluissa reititysohjelmissa. Ohjelmiston kompleksisuus liittyy siihen, kuinka helppoa ohjelmistoa on ylläpitää.Linux operating system is becoming more and more popular today. Network connections are becoming faster and the amount is increasing all the time. Today's networks need routing so that the messages can go towards their destinations in the Internet. The routing can be performed in the Linux systems. In this thesis we handle both the Linux operating system and routing functionality. Our routing software is based on the FreeBSD operating system. This thesis studies how well that software works on Linux. The first step is to port this software on Linux. After that we examine the functionality of the software in Linux by comparing the routing daemon with two commercial routing solutions and an open source one. The comparison consists of performance and software complexity measurements. The results of these measurements not only show that the software is capable to be run on Linux, but also give even more information on how different routing software packages perform the routing tasks. The output of the software complexity measurements shows the type of source code in the compared routing solutions. The complexity of the software is related to the easiness to maintain it

    Evaluation of Network Mobility Schemes for Terrestrial and Satellite Networks

    Get PDF
    NEtwork MObility (NEMO) supports the mobility of multiple Internet-connected devices. However, NEMO Basic Support Protocol suffers from unoptimized route leading to large latency in communication and header overhead. To optimize route, a plethora of schemes have been proposed. These schemes differ in terms of several performance parameters, such as signaling, end-to-end delay andhandoff latency. However, no performance or cost evaluation exists in the literature to compare the schemes. In addition, mobility management is required to support the mobility of Internet-connected devices in satellite networks. Existing mobility management solutions for satellite networks are unable toprovide connectivity to the Internet when satellites are not directly connected to the ground.In this dissertation, a comprehensive evaluation of the schemes and a mobility management solution for satellite networks using NEMO are provided. The schemes are classified and compared to choose the optimal class. Using analytical and simulation-based models, the schemes in the chosen class are compared based on the performance parameters. The effect of the parameters on transmission Control Protocol, the dominant transport protocol in the Internet, is also evaluated. A cost evaluation is performed to determine the network resource consumption of the schemes. Finally, an architecture and extensions of the basic protocol are presented to apply NEMO in satellite networks. This dissertation fosters the application of NEMO to terrestrial and satellitenetworks by selecting and extending optimal route optimization schemes, and presenting new architecture and protocol

    Scalable Schedule-Aware Bundle Routing

    Get PDF
    This thesis introduces approaches providing scalable delay-/disruption-tolerant routing capabilities in scheduled space topologies. The solution is developed for the requirements derived from use cases built according to predictions for future space topology, like the future Mars communications architecture report from the interagency operations advisory group. A novel routing algorithm is depicted to provide optimized networking performance that discards the scalability issues inherent to state-of-the-art approaches. This thesis also proposes a new recommendation to render volume management concerns generic and easily exchangeable, including a new simple management technique increasing volume awareness accuracy while being adaptable to more particular use cases. Additionally, this thesis introduces a more robust and scalable approach for internetworking between subnetworks to increase the throughput, reduce delays, and ease configuration thanks to its high flexibility.:1 Introduction 1.1 Motivation 1.2 Problem statement 1.3 Objectives 1.4 Outline 2 Requirements 2.1 Use cases 2.2 Requirements 2.2.1 Requirement analysis 2.2.2 Requirements relative to the routing algorithm 2.2.3 Requirements relative to the volume management 2.2.4 Requirements relative to interregional routing 3 Fundamentals 3.1 Delay-/disruption-tolerant networking 3.1.1 Architecture 3.1.2 Opportunistic and deterministic DTNs 3.1.3 DTN routing 3.1.4 Contact plans 3.1.5 Volume management 3.1.6 Regions 3.2 Contact graph routing 3.2.1 A non-replication routing scheme 3.2.2 Route construction 3.2.3 Route selection 3.2.4 Enhancements and main features 3.3 Graph theory and DTN routing 3.3.1 Mapping with DTN objects 3.3.2 Shortest path algorithm 3.3.3 Edge and vertex contraction 3.4 Algorithmic determinism and predictability 4 Preliminary analysis 4.1 Node and contact graphs 4.2 Scenario 4.3 Route construction in ION-CGR 4.4 Alternative route search 4.4.1 Yen’s algorithm scalability 4.4.2 Blocking issues with Yen 4.4.3 Limiting contact approaches 4.5 CGR-multicast and shortest-path tree search 4.6 Volume management 4.6.1 Volume obstruction 4.6.2 Contact sink 4.6.3 Ghost queue 4.6.4 Data rate variations 4.7 Hierarchical interregional routing 4.8 Other potential issues 5 State-of-the-art and related work 5.1 Taxonomy 5.2 Opportunistic and probabilistic approaches 5.2.1 Flooding approaches 5.2.2 PROPHET 5.2.3 MaxProp 5.2.4 Issues 5.3 Deterministic approaches 5.3.1 Movement-aware routing over interplanetary networks 5.3.2 Delay-tolerant link state routing 5.3.3 DTN routing for quasi-deterministic networks 5.3.4 Issues 5.4 CGR variants and enhancements 5.4.1 CGR alternative routing table computation 5.4.2 CGR-multicast 5.4.3 CGR extensions 5.4.4 RUCoP and CGR-hop 5.4.5 Issues 5.5 Interregional routing 5.5.1 Border gateway protocol 5.5.2 Hierarchical interregional routing 5.5.3 Issues 5.6 Further approaches 5.6.1 Machine learning approaches 5.6.2 Tropical geometry 6 Scalable schedule-aware bundle routing 6.1 Overview 6.2 Shortest-path tree routing for space networks 6.2.1 Structure 6.2.2 Tree construction 6.2.3 Tree management 6.2.4 Tree caching 6.3 Contact segmentation 6.3.1 Volume management interface 6.3.2 Simple volume manager 6.3.3 Enhanced volume manager 6.4 Contact passageways 6.4.1 Regional border definition 6.4.2 Virtual nodes 6.4.3 Pathfinding and administration 7 Evaluation 7.1 Methodology 7.1.1 Simulation tools 7.1.2 Simulator extensions 7.1.3 Algorithms and scenarios 7.2 Offline analysis 7.3 Eliminatory processing pressures 7.4 Networking performance 7.4.1 Intraregional unicast routing tests 7.4.2 Intraregional multicast tests 7.4.3 Interregional routing tests 7.4.4 Behavior with congestion 7.5 Requirement fulfillment 8 Summary and Outlook 8.1 Conclusion 8.2 Future works 8.2.1 Next development steps 8.2.2 Contact graph routin
    corecore