Class-based multicast routing in interdomain scenarios

DiffServ-like domains bring new challenges to quality of service (QoS) multicast routing simply by shifting the focus from individual flows into classes of flows. Packets are marked at edge routers and receive differentiated treatment according to the class and not the flow that they belong to. DiffServ therefore became adverse to multicast, as packet replication inside the domain may require classification and remarking functions not present in core nodes. At the interdomain level, no doubt multicast QoS complexity is increased by the interleaving of DiffServ and non-Diffserv domains, making it more difficult to address QoS multicast in an end-to-end perspective. In today’s real interconnection world, classes of service have no meaning in certain links of a full interdomain path. While the problem is not new, as already pointed out, there are no real efforts to bring multicast back to a class-of-service domain without compromising its model of operation. In this article, we present an innovative multicast QoS routing strategy, clearly designed for the new class-of-service paradigm. The solution is based upon the construction of multiple trees, one per class of service available, while still allowing receivers to shift for source-specific trees in its own class of service. The strategy is presented in a full end-to-end perspective. Intradomain trees use differentiated routing paths thus helping traffic differentiation. Intradomain receivers are allowed to shift from shared trees into an adequate class-of-service source tree. At interdomain level, each class-of-service interdomain tree branch is accomplished by means of an improved path probing strategy enabling for QoS path establishment. This paper presents this new strategy, and associated protocols, for constructing several multicast and directed distribution trees, one per class of service, within each multicast group. This new strategy and associated protocols are then simulated using NS-2 platform. Simulation results are analyzed and compared with other multicast routing solutions, both at intra- and interdomain levels

Exploiting the power of multiplicity: a holistic survey of network-layer multipath

The Internet is inherently a multipath network: For an underlying network with only a single path, connecting various nodes would have been debilitatingly fragile. Unfortunately, traditional Internet technologies have been designed around the restrictive assumption of a single working path between a source and a destination. The lack of native multipath support constrains network performance even as the underlying network is richly connected and has redundant multiple paths. Computer networks can exploit the power of multiplicity, through which a diverse collection of paths is resource pooled as a single resource, to unlock the inherent redundancy of the Internet. This opens up a new vista of opportunities, promising increased throughput (through concurrent usage of multiple paths) and increased reliability and fault tolerance (through the use of multiple paths in backup/redundant arrangements). There are many emerging trends in networking that signify that the Internet's future will be multipath, including the use of multipath technology in data center computing; the ready availability of multiple heterogeneous radio interfaces in wireless (such as Wi-Fi and cellular) in wireless devices; ubiquity of mobile devices that are multihomed with heterogeneous access networks; and the development and standardization of multipath transport protocols such as multipath TCP. The aim of this paper is to provide a comprehensive survey of the literature on network-layer multipath solutions. We will present a detailed investigation of two important design issues, namely, the control plane problem of how to compute and select the routes and the data plane problem of how to split the flow on the computed paths. The main contribution of this paper is a systematic articulation of the main design issues in network-layer multipath routing along with a broad-ranging survey of the vast literature on network-layer multipathing. We also highlight open issues and identify directions for future work

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

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

Multidomain Network Based on Programmable Networks: Security Architecture

This paper proposes a generic security architecture designed for a multidomain and multiservice network based on programmable networks. The multiservice network allows users of an IP network to run programmable services using programmable nodes located in the architecture of the network. The programmable nodes execute codes to process active packets, which can carry user data and control information. The multiservice network model defined here considers the more pragmatic trends in programmable networks. In this scenario, new security risks that do not appear in traditional IP networks become visible. These new risks are as a result of the execution of code in the programmable nodes and the processing of the active packets. The proposed security architecture is based on symmetric cryptography in the critical process, combined with an efficient manner of distributing the symmetric keys. Another important contribution has been to scale the security architecture to a multidomain scenario in a single and efficient way.Publicad

Securing the RTP framework: why RTP does not mandate a single media security solution

This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP), and the associated RTP control protocol (RTCP), do not mandate a single media security mechanism. Guidelines for designers and reviewers of future RTP extensions are provided, to ensure that appropriate security mechanisms are mandated, and that any such mechanisms are specified in a manner that conforms with the RTP architecture