A Survey on the Path Computation Element (PCE) Architecture

Quality of Service-enabled applications and services rely on Traffic Engineering-based (TE) Label Switched Paths (LSP) established in core networks and controlled by the GMPLS control plane. Path computation process is crucial to achieve the desired TE objective. Its actual effectiveness depends on a number of factors. Mechanisms utilized to update topology and TE information, as well as the latency between path computation and resource reservation, which is typically distributed, may affect path computation efficiency. Moreover, TE visibility is limited in many network scenarios, such as multi-layer, multi-domain and multi-carrier networks, and it may negatively impact resource utilization. The Internet Engineering Task Force (IETF) has promoted the Path Computation Element (PCE) architecture, proposing a dedicated network entity devoted to path computation process. The PCE represents a flexible instrument to overcome visibility and distributed provisioning inefficiencies. Communications between path computation clients (PCC) and PCEs, realized through the PCE Protocol (PCEP), also enable inter-PCE communications offering an attractive way to perform TE-based path computation among cooperating PCEs in multi-layer/domain scenarios, while preserving scalability and confidentiality. This survey presents the state-of-the-art on the PCE architecture for GMPLS-controlled networks carried out by research and standardization community. In this work, packet (i.e., MPLS-TE and MPLS-TP) and wavelength/spectrum (i.e., WSON and SSON) switching capabilities are the considered technological platforms, in which the PCE is shown to achieve a number of evident benefits

QoS Provisioning in Converged Satellite and Terrestrial Networks: A Survey of the State-of-the-Art

It has been widely acknowledged that future networks will need to provide significantly more capacity than current ones in order to deal with the increasing traffic demands of the users. Particularly in regions where optical fibers are unlikely to be deployed due to economical constraints, this is a major challenge. One option to address this issue is to complement existing narrow-band terrestrial networks with additional satellite connections. Satellites cover huge areas, and recent developments have considerably increased the available capacity while decreasing the cost. However, geostationary satellite links have significantly different link characteristics than most terrestrial links, mainly due to the higher signal propagation time, which often renders them not suitable for delay intolerant traffic. This paper surveys the current state-of-the-art of satellite and terrestrial network convergence. We mainly focus on scenarios in which satellite networks complement existing terrestrial infrastructures, i.e., parallel satellite and terrestrial links exist, in order to provide high bandwidth connections while ideally achieving a similar end user quality-of-experience as in high bandwidth terrestrial networks. Thus, we identify the technical challenges associated with the convergence of satellite and terrestrial networks and analyze the related work. Based on this, we identify four key functional building blocks, which are essential to distribute traffic optimally between the terrestrial and the satellite networks. These are the traffic requirement identification function, the link characteristics identification function, as well as the traffic engineering function and the execution function. Afterwards, we survey current network architectures with respect to these key functional building blocks and perform a gap analysis, which shows that all analyzed network architectures require adaptations to effectively support converged satellite and terrestrial networks. Hence, we conclude by formulating several open research questions with respect to satellite and terrestrial network convergence.This work was supported by the BATS Research Project through the European Union Seventh Framework Programme under Contract 317533

Path signalling in a wireless back-haul network integrating unidirectional broadcast technologies

The black-haul infrastructures of today's wireless operators must support the triple-play services demanded by the market or regulatory bodies. To cope with increasing capacity demand, in our previous work, we have developed a cost-effective heterogeneous layer 2.5 wireless back-haul (WiBACK) architecture, which leverages the native multicast capabilities of broadcast technologies such as DVB to off-load high-bandwidth broadcast content delivery. Furthermore, our architecture provides support for unidirectional technologies on the data and the control plane. This adopts a centralized coordinator approach, in which coordinator nodes install so-called management and data pipes. No routing state is kept at plain WiBACK nodes, which merely store QoS-aware pipe forwarding state. Consequently, the architecture requires a reliable protocol to push resource allocation and pipe forwarding state into the network, considering possibly unidirectional connectivity. Such a protocol, whose task is related to MPLS label distribution, is essential during the initial forming of WiBACK topologies and during regular network operations to reliably manage the data pipes. In this paper, we present a novel approach to extend our IEEE 802.21-inspired WiBACK TransportService and, based upon this, the design of an RSVP-TE-style pipe signalling protocol using nested hop-by-hop request/response MIH transactions that supports signalling over unidirectional technologies. A thorough evaluation and successful testbed deployments show that this protocol reliably signals pipe state even under high loss conditions

Link State Contract Routing

The Internet's simple design resulted in huge success in basic telecommunicationservices. However, the current Internet architecture has failed in terms of introducingmany innovative technologies as end-to-end (E2E) services such as multicasting,guaranteed quality of services (QoS) and many others. We argue that contractingover static service level agreements (SLA) and point-to-anywhere service definitionsare the main reasons behind this failure. In that sense, the Internet architecture needsmajor shifts since it neither allows (i) users to indicate their value choices at sufficientgranularity nor (ii) providers to manage risks involved in investment for new innovativeQoS technologies and business relationships with other providers as well as users.To allow these much needed economic flexibilities, we introduce contract-switching asa new paradigm for the design of future Internet architecture. In this work, we implementcontract-routing framework with specific focus on long-term contracted servicesin Link State Contract Routing scheme. Our work shows that E2e guaranteed QoSservices can be achieved in routing over contracted edge-to-edge service abstractionswhich are built on today's popular protocols with reasonable protocol overhead

Performance evaluation of the TFD-capable dynamic QoS assurance of HD video streaming in well-dimensioned network

The Traffic Flow Description (TFD) option of the IP protocol is an experimental option, designed by the Authors and described by the IETF’s Internet Draft. This option was intended for signalling for QoS purposes. Knowledge about forthcoming traffic (such as the amount of data that will be transferred in a given period of time) is conveyed in the fields of the option between end-systems. TFD-capable routers on a path (or a multicast tree) between the sender and receiver(s) are able to read this information, process it and use it for bandwidth allocation. If the time horizons are short enough, bandwidth allocation will be performed dynamically. In the paper a performance evaluation of an HD video transmission QoS assured with the use of the TFD option is presented. The analysis was made for a variable number of video streams and a variable number of TCP flows that compete with the videos for the bandwidth of the shared link. Results show that the dynamic bandwidth allocation using the TFD option better assures the QoS of HD video than the classic solution, based on the RSVP protocol