Deliverable JRA1.1: Evaluation of current network control and management planes for multi-domain network infrastructure

This deliverable includes a compilation and evaluation of available control and management architectures and protocols applicable to a multilayer infrastructure in a multi-domain Virtual Network environment.The scope of this deliverable is mainly focused on the virtualisation of the resources within a network and at processing nodes. The virtualization of the FEDERICA infrastructure allows the provisioning of its available resources to users by means of FEDERICA slices. A slice is seen by the user as a real physical network under his/her domain, however it maps to a logical partition (a virtual instance) of the physical FEDERICA resources. A slice is built to exhibit to the highest degree all the principles applicable to a physical network (isolation, reproducibility, manageability, ...). Currently, there are no standard definitions available for network virtualization or its associated architectures. Therefore, this deliverable proposes the Virtual Network layer architecture and evaluates a set of Management- and Control Planes that can be used for the partitioning and virtualization of the FEDERICA network resources. This evaluation has been performed taking into account an initial set of FEDERICA requirements; a possible extension of the selected tools will be evaluated in future deliverables. The studies described in this deliverable define the virtual architecture of the FEDERICA infrastructure. During this activity, the need has been recognised to establish a new set of basic definitions (taxonomy) for the building blocks that compose the so-called slice, i.e. the virtual network instantiation (which is virtual with regard to the abstracted view made of the building blocks of the FEDERICA infrastructure) and its architectural plane representation. These definitions will be established as a common nomenclature for the FEDERICA project. Other important aspects when defining a new architecture are the user requirements. It is crucial that the resulting architecture fits the demands that users may have. Since this deliverable has been produced at the same time as the contact process with users, made by the project activities related to the Use Case definitions, JRA1 has proposed a set of basic Use Cases to be considered as starting point for its internal studies. When researchers want to experiment with their developments, they need not only network resources on their slices, but also a slice of the processing resources. These processing slice resources are understood as virtual machine instances that users can use to make them behave as software routers or end nodes, on which to download the software protocols or applications they have produced and want to assess in a realistic environment. Hence, this deliverable also studies the APIs of several virtual machine management software products in order to identify which best suits FEDERICA’s needs.Postprint (published version

Performance evaluation of HIP-based network security solutions

Abstract. Host Identity Protocol (HIP) is a networking technology that systematically separates the identifier and locator roles of IP addresses and introduces a Host Identity (HI) name space based on a public key security infrastructure. This modification offers a series of benefits such as mobility, multi-homing, end-to-end security, signaling, control/data plane separation, firewall security, e.t.c. Although HIP has not yet been sufficiently applied in mainstream communication networks, industry experts foresee its potential as an integral part of next generation networks. HIP can be used in various HIP-aware applications as well as in traditional IP-address-based applications and networking technologies, taking middle boxes into account. One of such applications is in Virtual Private LAN Service (VPLS), VPLS is a widely used method of providing Ethernet-based Virtual Private Network that supports the connection of geographically separated sites into a single bridged domain over an IP/MPLS network. The popularity of VPLS among commercial and defense organizations underscores the need for robust security features to protect both data and control information. After investigating the different approaches to HIP, a real world testbed is implemented. Two experiment scenarios were evaluated, one is performed on two open source Linux-based HIP implementations (HIPL and OpenHIP) and the other on two sets of enterprise equipment from two different companies (Tempered Networks and Byres Security). To account for a heterogeneous mix of network types, the Open source HIP implementations were evaluated on different network environments, namely Local Area Network (LAN), Wireless LAN (WLAN), and Wide Area Network (WAN). Each scenario is tested and evaluated for performance in terms of throughput, latency, and jitter. The measurement results confirmed the assumption that no single solution is optimal in all considered aspects and scenarios. For instance, in the open source implementations, the performance penalty of security on TCP throughput for WLAN scenario is less in HIPL than in OpenHIP, while for WAN scenario the reverse is the case. A similar outcome is observed for the UDP throughput. However, on latency, HIPL showed lower latency for all three network test scenarios. For the legacy equipment experiment, the penalty of security on TCP throughput is about 19% compared with the non-secure scenario while latency is increased by about 87%. This work therefore provides viable information for researchers and decision makers on the optimal solution to securing their VPNs based on the application scenarios and the potential performance penalties that come with each approach.HIP-pohjaisten tietoliikenneverkkojen turvallisuusratkaisujen suorituskyvyn arviointi. Tiivistelmä. Koneen identiteettiprotokolla (HIP, Host Identity Protocol) on tietoliikenneverkkoteknologia, joka käyttää erillistä kerrosta kuljetusprotokollan ja Internet-protokollan (IP) välissä TCP/IP-protokollapinossa. HIP erottaa systemaattisesti IP-osoitteen verkko- ja laite-osat, sekä käyttää koneen identiteetti (HI) -osaa perustuen julkisen avainnuksen turvallisuusrakenteeseen. Tämän hyötyjä ovat esimerkiksi mobiliteetti, moniliittyminen, päästä päähän (end-to-end) turvallisuus, kontrolli-informaation ja datan erottelu, kohtaaminen, osoitteenmuutos sekä palomuurin turvallisuus. Teollisuudessa HIP-protokolla nähdään osana seuraavan sukupolven tietoliikenneverkkoja, vaikka se ei vielä olekaan yleistynyt laajaan kaupalliseen käyttöön. HIP–protokollaa voidaan käyttää paitsi erilaisissa HIP-tietoisissa, myös perinteisissä IP-osoitteeseen perustuvissa sovelluksissa ja verkkoteknologioissa. Eräs tällainen sovellus on virtuaalinen LAN-erillisverkko (VPLS), joka on laajasti käytössä oleva menetelmä Ethernet-pohjaisen, erillisten yksikköjen ja yhden sillan välistä yhteyttä tukevan, virtuaalisen erillisverkon luomiseen IP/MPLS-verkon yli. VPLS:n yleisyys sekä kaupallisissa- että puolustusorganisaatioissa korostaa vastustuskykyisten turvallisuusominaisuuksien tarpeellisuutta tiedon ja kontrolliinformaation suojauksessa. Tässä työssä tutkitaan aluksi HIP-protokollan erilaisia lähestymistapoja. Teoreettisen tarkastelun jälkeen käytännön testejä suoritetaan itse rakennetulla testipenkillä. Tarkasteltavat skenaariot ovat verrata Linux-pohjaisia avoimen lähdekoodin HIP-implementaatioita (HIPL ja OpenHIP) sekä verrata kahden eri valmistajan laitteita (Tempered Networks ja Byres Security). HIP-implementaatiot arvioidaan eri verkkoympäristöissä, jota ovat LAN, WLAN sekä WAN. Kaikki testatut tapaukset arvioidaan tiedonsiirtonopeuden, sen vaihtelun (jitter) sekä latenssin perusteella. Mittaustulokset osoittavat, että sama ratkaisu ei ole optimaalinen kaikissa tarkastelluissa tapauksissa. Esimerkiksi WLAN-verkkoa käytettäessä turvallisuuden aiheuttama häviö tiedonsiirtonopeudessa on HIPL:n tapauksessa OpenHIP:iä pirnempi, kun taas WAN-verkon tapauksessa tilanne on toisinpäin. Samanlaista käyttäytymistä havaitaan myös UDP-tiedonsiirtonopeudessa. HIPL antaa kuitenkin pienimmän latenssin kaikissa testiskenaarioissa. Eri valmistajien laitteita vertailtaessa huomataan, että TCP-tiedonsiirtonopeus huononee 19 ja latenssi 87 prosenttia verrattuna tapaukseen, jossa turvallisuusratkaisua ei käytetä. Näin ollen tämän työn tuottama tärkeä tieto voi auttaa alan toimijoita optimaalisen verkkoturvallisuusratkaisun löytämisessä VPN-pohjaisiin sovelluksiin

A survey of Virtual Private LAN Services (VPLS): Past, present and future

Virtual Private LAN services (VPLS) is a Layer 2 Virtual Private Network (L2VPN) service that has gained immense popularity due to a number of its features, such as protocol independence, multipoint-to-multipoint mesh connectivity, robust security, low operational cost (in terms of optimal resource utilization), and high scalability. In addition to the traditional VPLS architectures, novel VPLS solutions have been designed leveraging new emerging paradigms, such as Software Defined Networking (SDN) and Network Function Virtualization (NFV), to keep up with the increasing demand. These emerging solutions help in enhancing scalability, strengthening security, and optimizing resource utilization. This paper aims to conduct an in-depth survey of various VPLS architectures and highlight different characteristics through insightful comparisons. Moreover, the article discusses numerous technical aspects such as security, scalability, compatibility, tunnel management, operational issues, and complexity, along with the lessons learned. Finally, the paper outlines future research directions related to VPLS. To the best of our knowledge, this paper is the first to furnish a detailed survey of VPLS.University College DublinAcademy of Finlan

Layer 3 Multiprotocol Label Switching Virtual Private Network

Layer 3 Multiprotocol Label Switching Virtual Private Networks (L3 MPLS VPNs) is becoming a key technology of Service Providers' Services for corporations who desire to use remote connectivity. It is getting more popularity by customers for its significant advantages over the prior VPN technologies such as Frame relay and ATM. The main purpose of this thesis project was to develop an understanding of L3 MPLS VPNs in theory and practice. It is targeting to explain the technology briefly and demonstrate how it works to prepare a learning material for Data Network Services course given at VAMK, University of Applied Sciences. The practical part of this project took place in the Technobothnia Research Center using Cisco technology. Four Cisco 2801 routers, laboratory computers and Ethernet and serial media links were used to build the network and accomplish connectivity. There are also software tools used such as HyperTerminal to configure the routers and WireShark packet analyzer to examine the communication protocols used for connectivity

Planning tools for MPLS networks

Verkot, joissa MPLS-tekniikkaa (Multi Protocol Label Switching) käytetään pakettien reitittämiseen, kasvavat jatkuvasti yhä suuremmiksi ja toiminnallisuus, jota verkoissa tarvitaan, monipuolistuu koko ajan. Tämän syyn vuoksi verkon suunnittelija tarvitsee yhä parempia apuvälineitä, jotta suunnittelu olisi onnistunutta, optimaalista ja tuottaisi halutun tuloksen. Tämän diplomityön tarkoitus on selvittää tärkeimmät toiminnallisuudet ja ominaisuudet, joita MPLS-verkkojen suunnitteluun laadittu työkalu vaatii. Diplomityö on jaettu kolmeen osaan. Ensimmäisessä osassa valotetaan MPLS-verkkojen käyttämää tekniikkaa. Tuossa osiossa käydään läpi tekniikat ja protokollat, joita MPLS-verkot käyttävät erinäisiin tehtäviin. Ensin käydään läpi yleisesti miksi MPLS-tekniikkaa ylipäätään tarvitaan ja miksi sitä käytetään verkkojen reitittämiseen. Tämän jälkeen tarkastellaan MPLS-protokollan otsikkokenttää ja sen osien käyttötarkoitukset selitetään. Sitten tarkastellaan MPLS-verkon rakennetta ja siihen kuuluvia laitteita. Seuraavaksi siirrytään osioon, joka selvittää kaikki yleisesti MPLS-polkujen rakentamiseen käytettävät protokollat ja miten ne eroavat toisistaan. Tämän jälkeen kerrotaan MPLS-vuonohjauksesta Differentiated Services-tekniikan avulla ja siitä miten se auttaa erilaisten liikenneluokkien erittelyssä MPLS-liikenteessä. Viimeinen kohta tässä osassa listaa erilaiset VPN-yhteydet, jotka ovat mahdollisia MPLS-tekniikkaa käytettäessä. Osio selventää näiden tekniikoiden eroavaisuudet ja mahdollisuudet, joita nämä MPLS-tekniikan avulla toteutettavat VPN-yhteydet suovat verrattuna aiempiin VPN-toteutuksiin. Toinen osa tässä diplomityössä kertoo verkon suunnittelusta. Ensin käydään läpi verkon suunnittelua yleisellä tasolla. Tämä osa sisältää verkon suunnittelun eri vaiheet pääosittain: erilaiset ennustusmallit esitellään ja selvitetään mitoituksen ja vuonohjauksen rooli verkkosuunnittelussa. Näiden jälkeen siirrytään yleisestä verkonsunnittelusta osioihin, joita käytetään MPLS-verkon suunnittelussa ja joiden yleisesti oletetaan tai halutaan löytyvän MPLS-verkkoihin tarkoitetusta suunnittelutyökalusta. Viimeinen kohta kertoo toiminnallisuus- ja skaalautuvuushaasteista, joihin MPLS:n on tekniikkana vastattava nykypäivänä. Kolmannessa osiossa tarkastellaan kahta eri suunnittelutyökalua, jotka on laadittu MPLS-verkkojen suunnitelua varten: WANDL-yhtiön julkaisemaa IP/MPLSView:ta ja Aria Networks Oy:n julkaisemaa iVNT:ta. Tässä osiossa käydään läpi näiden työkalujen toiminnallisuutta kertomalla erilaisista simulaatiomahdollisuuksista, joita kumpikin työkalu tarjoaa. Lisäksi kerrotaan mitä toimintoja ja protokollia näihin työkaluihin on mallinnettu, miten hyvin työkalut skaalautuvat kaupallisten MPLS-verkkojen tarpeisiin ja minkälaisita moduuleista työkalut on rakennettu. Työn lopussa on pohdittu näiden kolmen osion perusteella, että mitkä ominaisuudet tulisi ottaa huomioon MPLS-verkon suunnittelutyökalua laadittaessa ja millä tavalla nämä ominaisuudet tulisi toteuttaa työkalussa. Näiden jälkeen on työhön vielä tehty loppuyhteenveto, joka kertoo työ tuloksista ja mahdollisista jatkokehitysmahdollisuuksista. MPLS-verkon suunnittelu koostuu monesta eri vaiheesta, ja jokainen vaihe sisältää suuren määrän toiminnallisuusvaatimuksia. Nämä toiminnallisuusvaatimukset on mallinnettava MPLS-verkkojen suunnitteluun laaditussa työkalussa, jos halutaan että työkalu pystyy mallintamaan koko verkon suunnitteluprosessin alusta loppuun. Tärkeimmät toiminnallisuudet, jotka MPLS-verkon suunnittelutyökalun tulee omata ovat simulointimahdollisuudet MPLS-poluille (LSP:t), MPLS-TE:lle, eri VPN-tyypeille ja DiffServ-liikenteelle, sillä nämä ovat tärkeimmät toiminnallisuudet MPLS-verkoissa tänä päivänä. Jos edellä mainittu toiminnallisuus on toteutettu ja mallinnettu suunnittelutyökalussa ja työkalu osaa optimoida liikennettä hyvin saadaan verkon pääoma- ja operaationaaliset kulut laskemaan. MPLS-verkon suunnittelutyökalua laadittaessa on myös tärkeää ottaa huomioon työkalun skaalautuvuusominaisuudet. Runkoverkot voivat koostua tänä päivänä tuhansista solmuista ja sadoista tuhansista liikennevirroista, joten suunnitelutyökalun tulisi omata toiminnallisuutta joka automatisoi joitain vaiheita verkonsuunnittelussa, mikä mahdollistaa tämän kokoluokan verkkojen suunnittelun. Tällainen toiminnallisuus voisi esimerkiksi olla automatisoitu vuonohjaus ja verkkojen topologiakokonaisuuden vienti ja tuonti suunnittelutyökaluun ja siitä ulos. /Kir1

Multi Protocol Label Switching: Quality of Service, Traffic Engineering application, and Virtual Private Network application

This thesis discusses the QoS feature, Traffic Engineering (TE) application, and Virtual Private Network (VPN) application of the Multi Protocol Label Switching (MPLS) protocol. This thesis concentrates on comparing MPLS with other prominent technologies such as Internet Protocol (IP), Asynchronous Transfer Mode (ATM), and Frame Relay (FR). MPLS combines the flexibility of Internet Protocol (IP) with the connection oriented approach of Asynchronous Transfer Mode (ATM) or Frame Relay (FR). Section 1 lists several advantages MPLS brings over other technologies. Section 2 covers architecture and a brief description of the key components of MPLS. The information provided in Section 2 builds a background to compare MPLS with the other technologies in the rest of the sections. Since it is anticipate that MPLS will be a main core network technology, MPLS is required to work with two currently available QoS architectures: Integrated Service (IntServ) architecture and Differentiated Service (DiffServ) architecture. Even though the MPLS does not introduce a new QoS architecture or enhance the existing QoS architectures, it works seamlessly with both QoS architectures and provides proper QoS support to the customer. Section 3 provides the details of how MPLS supports various functions of the IntServ and DiffServ architectures. TE helps Internet Service Provider (ISP) optimize the use of available resources, minimize the operational costs, and maximize the revenues. MPLS provides efficient TE functions which prove to be superior to IP and ATM/FR. Section 4 discusses how MPLS supports the TE functionality and what makes MPLS superior to other competitive technologies. ATM and FR are still required as a backbone technology in some areas where converting the backbone to IP or MPLS does not make sense or customer demands simply require ATM or FR. In this case, it is important for MPLS to work with ATM and FR. Section 5 highlights the interoperability issues and solutions for MPLS while working in conjunction with ATM and FR. In section 6, various VPN tunnel types are discussed and compared with the MPLS VPN tunnel type. The MPLS VPN tunnel type is concluded as an optimal tunnel approach because it provides security, multiplexing, and the other important features that are reburied by the VPN customer and the ISP. Various MPLS layer 2 and layer 3 VPN solutions are also briefly discussed. In section 7 I conclude with the details of an actual implementation of a layer 3 MPLS VPN solution that works in conjunction with Border Gateway Protocol (BGP)

Case Study - IPv6 based building automation solution integration into an IPv4 Network Service Provider infrastructure

The case study presents a case study describing an Internet Protocol (IP) version 6 (v6) introduction to an IPv4 Internet Service Provider (ISP) network infrastructure. The case study driver is an ISP willing to introduce a new “killer” service related to Internet of Things (IoT) style building automation. The provider and cooperation of third party companies specialized in building automation will provide the service. The ISP has to deliver the network access layer and to accommodate the building automation solution traffic throughout its network infrastructure. The third party companies are system integrators and building automation solution vendors. IPv6 is suitable for such solutions due to the following reasons. The operator can’t accommodate large number of IPv4 embedded devices in its current network due to the lack of address space and the fact that many of those will need clear 2 way IP communication channel. The Authors propose a strategy for IPv6 introduction into operator infrastructure based on the current network architecture present service portfolio and several transition mechanisms. The strategy has been applied in laboratory with setup close enough to the current operator’s network. The criterion for a successful experiment is full two-way IPv6 application layer connectivity between the IPv6 server and the IPv6 Internet of Things (IoT) cloud