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

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)

Route selection impacts on achieving enhanced IMS QoS

ArticleThe different planes in the IMS interact via specific reference points to deliver multimedia services to the user. QoS provisioning for IMS communications has been standardized for access networks only, with the assumption of an over provisioned IP core. Effective provisioning of multimedia services requires performance guarantee along the complete path of the sessions. End-to-end QoS in IP networks is affected by the route traversed by the user traffic. Moreover QoS guarantees in one ISP domain are not effective for transit traffic exiting the domain. QoS extensions to exterior gateway routing protocols have been proposed to transfer route QoS information beyond one autonomous system (domain). This paper explores options for mapping inter-domain QoS information learnt on the media plane into control plane session information for IMS QoS control. Through testbed evaluations we show the effect of routing on delays experienced in IMS communications.The different planes in the IMS interact via specific reference points to deliver multimedia services to the user. QoS provisioning for IMS communications has been standardized for access networks only, with the assumption of an over provisioned IP core. Effective provisioning of multimedia services requires performance guarantee along the complete path of the sessions. End-to-end QoS in IP networks is affected by the route traversed by the user traffic. Moreover QoS guarantees in one ISP domain are not effective for transit traffic exiting the domain. QoS extensions to exterior gateway routing protocols have been proposed to transfer route QoS information beyond one autonomous system (domain). This paper explores options for mapping inter-domain QoS information learnt on the media plane into control plane session information for IMS QoS control. Through testbed evaluations we show the effect of routing on delays experienced in IMS communications

BGRP: A Tree-Based Aggregation Protocol for Inter-domain Reservations

Resource reservation needs to accommodate the rapidly growing size and increasing service diversity of the Internet. Recently, hierarchical architectures have been proposed that provide domain-level reservation.However, it is not clear that these proposals can set up and maintain reservations in an efficient and scalable fashion. In this paper, we describe a distributed architecture and protocol,called the Border Gateway Reservation Protocol (BGRP), for inter-domain resource reservation that can scale in terms of message processing load. state storage and bandwidth. Each stub or transit domain may use its own intra-domain resource reservation protocol. BGRP builds a sink tree for each of the stub domains. Each sink tree aggregates bandwidth reservations from all data sources in the network.Since backbone routers only maintain the sink tree information, the total number of reservation states at each router scales, in the worst case, linearly with the number of domains in the Internet. BGRP relies on differentiated services for data forwarding. As a result, the number of packet classifier entries is small, not the number of micro-flows.To reduce the protocol message traffic, routers may reserve domain bandwidth beyond the current load so that sources can join or leave the tree or change their reservation without having to send messages all the way to the root for every such change. We use``soft state'' to maintain reservations. In contrast to RSVP, refresh messages are delivered reliably, allowing us to reduce the refresh frequency

Burst switched optical networks supporting legacy and future service types

Focusing on the principles and the paradigm of OBS an overview addressing expectable performance and application issues is presented. Proposals on OBS were published over a decade and the presented techniques spread into many directions. The paper comprises discussions of several challenges that OBS meets, in order to compile the big picture. The OBS principle is presented unrestricted to individual proposals and trends. Merits are openly discussed, considering basic teletraffic theory and common traffic characterisation. A more generic OBS paradigm than usual is impartially discussed and found capable to overcome shortcomings of recent proposals. In conclusion, an OBS that offers different connection types may support most client demands within a sole optical network layer