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

Some open issues in multi-domain/multi-operator/multi-granular ASON/GMPLS networks

Large optical backbone networks may be composed of several domains, each one controlled by different administrators/operators. Besides, the bandwidth granularity of these domains may be different. Label Switched Paths (LSPs) provisioning in multi-domain/multi-operators/multi-layer network scenarios is a challenging problem actually, which has to be properly faced. In this paper, some open issues related to end-to-end bandwidth provisioning are discussed. Among others, the grooming problem in multi-layer/multi-domain optical networks and the performance degradation of recovery mechanisms due to limited inter-domain knowledge are analyzed.Postprint (published version

Restoration in multi-domain GMPLS-based networks

In this paper, we evaluate the efficiency of using restoration mechanisms in a dynamic multi-domain GMPLS network. Major challenges and solutions are introduced and two well-known restoration schemes (End-to-End and Local-to-End) are evaluated. Additionally, new restoration mechanisms are introduced: one based on the position of a failed link, called Location-Based, and another based on minimizing the additional resources consumed during restoration, called Shortest-New. A complete set of simulations in different network scenarios show where each mechanism is more efficient in terms, such as, resource overbuild or recovery delayPart of this work was supported by the Government of Catalonia (DURSI SGR-1202), and by the Spanish Science and Innovation Ministry (TRION TEC2009-10724

Architecture, design, and modeling of the OPSnet asynchronous optical packet switching node

An all-optical packet-switched network supporting multiple services represents a long-term goal for network operators and service providers alike. The EPSRC-funded OPSnet project partnership addresses this issue from device through to network architecture perspectives with the key objective of the design, development, and demonstration of a fully operational asynchronous optical packet switch (OPS) suitable for 100 Gb/s dense-wavelength-division multiplexing (DWDM) operation. The OPS is built around a novel buffer and control architecture that has been shown to be highly flexible and to offer the promise of fair and consistent packet delivery at high load conditions with full support for quality of service (QoS) based on differentiated services over generalized multiprotocol label switching

Survivability aspects of future optical backbone networks

In huidige glasvezelnetwerken kan een enkele vezel een gigantische hoeveelheid data dragen, ruwweg het equivalent van 25 miljoen gelijktijdige telefoongesprekken. Hierdoor zullen netwerkstoringen, zoals breuken van een glasvezelkabel, de communicatie van een groot aantal eindgebruikers verstoren. Netwerkoperatoren kiezen er dan ook voor om hun netwerk zo te bouwen dat zulke grote storingen automatisch opgevangen worden. Dit proefschrift spitst zich toe op twee aspecten rond de overleefbaarheid in toekomstige optische netwerken. De eerste doelstelling die beoogd wordt is het tot stand brengen vanrobuuste dataverbindingen over meerdere netwerken. Door voldoende betrouwbare verbindingen tot stand te brengen over een infrastructuur die niet door een enkele entiteit wordt beheerd kan men bv. weredwijd Internettelevisie van hoge kwaliteit aanbieden. De bestudeerde oplossing heeft niet enkel tot doel om deze zeer betrouwbare verbinding te berekenen, maar ook om dit te bewerkstelligen met een minimum aan gebruikte netwerkcapaciteit. De tweede doelstelling was om een antwoord te formuleren om de vraag hoe het toepassen van optische schakelsystemen gebaseerd op herconfigureerbare optische multiplexers een impact heeft op de overleefbaarheid van een optisch netwerk. Bij lagere volumes hebben optisch geschakelde netwerken weinig voordeel van dergelijke gesofistikeerde methoden. Elektronisch geschakelde netwerken vertonen geen afhankelijkheid van het datavolume en hebben altijd baat bij optimalisatie

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

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