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

Traffic engineering in multihomed sites

It is expected that IPv6 multihomed sites will obtain as many global prefixes as direct providers they have, so traffic engineering techniques currently used in IPv4 multihomed sites is no longer suitable. However, traffic engineering is required for several reasons, and in particular, for being able to properly support multimedia communications. In this paper we present a framework for traffic engineering in IPv6 multihomed sites with multiple global prefixes. Within this framework, we have included several tools such as DNS record manipulation and proper configuration of the policy table defined in RFC 3484. To provide automation in the management of traffic engineering, we analyzed the usage of two mechanisms to configure the policy table.This work has been partly supported by the European Union under the E-Next Project FP6-506869 and by the OPTINET6 project TIC-2003-09042-C03-01.Publicad

Mechanisms for AAA and QoS Interaction

Proceedings of Third IEEE Workshop on Applications and Services in Wireless Networks, ASWN 2003. Bern, Switzerland, July 2-4, 2003.The interaction between Authentication, Authorization and Accounting (AAA) systems and the Quality of Service (QoS) infrastructure is to become a must in the near future. This interaction will allow rich control and management of both users and networks. DIAMETER and DiffServ are likely to turn into the future standards in AAA and QoS systems, but they are not designed to interact with each other. To face this, we propose a new Diameter-Diffserv interaction model and describe the Application Specific Module (ASM) implemented to allow this interaction. The ASM has been implemented and tested in a complete AAA-QoS IPv6 scenario

A Test Bed for Evaluating the Performance of IoT Networks

The use of smaller, personal IoT networks has increased over the past several years. These devices demand a lot of resources but only have limited access. To establish and sustain a flexible network connection, 6LoWPAN with RPL protocol is commonly used. While RPL provides a low-cost solution for connection, it lacks load balancing mechanisms. Improvements in OF load balancing can be implemented to strengthen network stability. This paper proposes a test bed configuration to show the toll of frequent parent switching on 6LoWPAN. Contiki’s RPL 6LoWPAN software runs on STM32 Nucleo microcontrollers with expansion boards for this test bed. The configuration tests frequency of parent changes and packet loss to demonstrate network instability of different RPL OFs. Tests on MRHOF for RPL were executed to confirm the working configuration. Results, with troubleshooting and improvements, show a working bed. The laid-out configuration provides a means for testing network stability in IoT networks

Segment Routing: a Comprehensive Survey of Research Activities, Standardization Efforts and Implementation Results

Fixed and mobile telecom operators, enterprise network operators and cloud providers strive to face the challenging demands coming from the evolution of IP networks (e.g. huge bandwidth requirements, integration of billions of devices and millions of services in the cloud). Proposed in the early 2010s, Segment Routing (SR) architecture helps face these challenging demands, and it is currently being adopted and deployed. SR architecture is based on the concept of source routing and has interesting scalability properties, as it dramatically reduces the amount of state information to be configured in the core nodes to support complex services. SR architecture was first implemented with the MPLS dataplane and then, quite recently, with the IPv6 dataplane (SRv6). IPv6 SR architecture (SRv6) has been extended from the simple steering of packets across nodes to a general network programming approach, making it very suitable for use cases such as Service Function Chaining and Network Function Virtualization. In this paper we present a tutorial and a comprehensive survey on SR technology, analyzing standardization efforts, patents, research activities and implementation results. We start with an introduction on the motivations for Segment Routing and an overview of its evolution and standardization. Then, we provide a tutorial on Segment Routing technology, with a focus on the novel SRv6 solution. We discuss the standardization efforts and the patents providing details on the most important documents and mentioning other ongoing activities. We then thoroughly analyze research activities according to a taxonomy. We have identified 8 main categories during our analysis of the current state of play: Monitoring, Traffic Engineering, Failure Recovery, Centrally Controlled Architectures, Path Encoding, Network Programming, Performance Evaluation and Miscellaneous...Comment: SUBMITTED TO IEEE COMMUNICATIONS SURVEYS & TUTORIAL

A practical approach to network-based processing

The usage of general-purpose processors externally attached to routers to play virtually the role of active coprocessors seems a safe and cost-effective approach to add active network capabilities to existing routers. This paper reviews this router-assistant way of making active nodes, addresses the benefits and limitations of this technique, and describes a new platform based on it using an enhanced commercial router. The features new to this type of architecture are transparency, IPv4 and IPv6 support, and full control over layer 3 and above. A practical experience with two applications for path characterization and a transport gateway managing multi-QoS is described.Most of this work has been funded by the IST project GCAP (Global Communication Architecture and Protocols for new QoS services over IPv6 networks) IST-1999-10 504. Further development and application to practical scenarios is being supported by IST project Opium (Open Platform for Integration of UMTS Middleware) IST-2001-36063 and the Spanish MCYT under projects TEL99-0988-C02-01 and AURAS TIC2001-1650-C02-01.Publicad

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