79 research outputs found

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

    Get PDF
    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

    RSVP-TE: Extensions to RSVP for LSP Tunnels

    Full text link

    Multi-Link Failure Effects on MPLS Resilient Fast-Reroute Network Architectures

    Get PDF
    © 2021 IEEE.MPLS has been in the forefront of high-speed Wide Area Networks (WANs), for almost two decades [1, 12]. The performance advantages in implementing Multi-Protocol Label Switching (MPLS) are mainly its superior speed based on fast label switching and its capability to perform Fast Reroute rapidly when failure(s) occur – in theory under 50 ms [16, 17], which makes MPLS also interesting for real-time applications. We investigate the aforementioned advantages of MPLS by creating two real testbeds using actual routers that commercial Internet Service Providers (ISPs) use, one with a ring and one with a partial mesh architecture. In those two testbeds we compare the performance of MPLS channels versus normal routing, both using the Open Shortest Path First (OSPF) routing protocol. The speed of the Fast Reroute mechanism for MPLS when failures are occurring is investigated. Firstly, baseline experiments are performed consisting of MPLS versus normal routing. Results are evaluated and compared using both single and dual failure scenarios within the two architectures. Our results confirm recovery times within 50 ms

    A Survey on the Contributions of Software-Defined Networking to Traffic Engineering

    Get PDF
    Since the appearance of OpenFlow back in 2008, software-defined networking (SDN) has gained momentum. Although there are some discrepancies between the standards developing organizations working with SDN about what SDN is and how it is defined, they all outline traffic engineering (TE) as a key application. One of the most common objectives of TE is the congestion minimization, where techniques such as traffic splitting among multiple paths or advanced reservation systems are used. In such a scenario, this manuscript surveys the role of a comprehensive list of SDN protocols in TE solutions, in order to assess how these protocols can benefit TE. The SDN protocols have been categorized using the SDN architecture proposed by the open networking foundation, which differentiates among data-controller plane interfaces, application-controller plane interfaces, and management interfaces, in order to state how the interface type in which they operate influences TE. In addition, the impact of the SDN protocols on TE has been evaluated by comparing them with the path computation element (PCE)-based architecture. The PCE-based architecture has been selected to measure the impact of SDN on TE because it is the most novel TE architecture until the date, and because it already defines a set of metrics to measure the performance of TE solutions. We conclude that using the three types of interfaces simultaneously will result in more powerful and enhanced TE solutions, since they benefit TE in complementary ways.European Commission through the Horizon 2020 Research and Innovation Programme (GN4) under Grant 691567 Spanish Ministry of Economy and Competitiveness under the Secure Deployment of Services Over SDN and NFV-based Networks Project S&NSEC under Grant TEC2013-47960-C4-3-

    Traffic Engineering And Supporting QoS

    Get PDF
    ABSTRACT Traffic Engineering describes techniques for optimising network performance by measuring, modelling, characterizing and controlling Internet traffic for specific performance goals [11]. This is a comprehensive definition. Traffic engineering performance goals typically fall into one of two categories. The first one is traffic related performance objectives such as minimizing packet loss, lowering end-to-end delay, or supporting a contracted Service Level Agreement (SLA). The second category is efficiency related objectives, such as balancing the distribution of traffic across available bandwidth resources. Traffic related performance goals are set in order to meet contracted service levels and offer competitive services to customers. Efficiency related goals, are required by the service provider to minimize the cost of delivering services, especially the cost of utilizing expensive network resources. The objective of this thesis is to present a description of Multi Protocol Label Switching (MPLS) architecture and its functionality to achieve a tool for performing traffic engineering and QoS support. We simulate traffic engineering with MPLS on a simple network and measure its performance. We analyse measurements related to queuing delay, throughput and other traffic related issues. We then move on fine-tuning the MPLS-TE network to also take into consideration QoS support when aggregating flows through a single label- switching path. We combine differentiated services with MPLS architecture in order to support QoS requirements. The simulation tool used in this thesis is called OPNET Modeler version 8.11

    Next generation control of transport networks

    Get PDF
    It is widely understood by telecom operators and industry analysts that bandwidth demand is increasing dramatically, year on year, with typical growth figures of 50% for Internet-based traffic [5]. This trend means that the consumers will have both a wide variety of devices attaching to their networks and a range of high bandwidth service requirements. The corresponding impact is the effect on the traffic engineered network (often referred to as the “transport network”) to ensure that the current rate of growth of network traffic is supported and meets predicted future demands. As traffic demands increase and newer services continuously arise, novel network elements are needed to provide more flexibility, scalability, resilience, and adaptability to today’s transport network. The transport network provides transparent traffic engineered communication of user, application, and device traffic between attached clients (software and hardware) and establishing and maintaining point-to-point or point-to-multipoint connections. The research documented in this thesis was based on three initial research questions posed while performing research at British Telecom research labs and investigating control of transport networks of future transport networks: 1. How can we meet Internet bandwidth growth yet minimise network costs? 2. Which enabling network technologies might be leveraged to control network layers and functions cooperatively, instead of separated network layer and technology control? 3. Is it possible to utilise both centralised and distributed control mechanisms for automation and traffic optimisation? This thesis aims to provide the classification, motivation, invention, and evolution of a next generation control framework for transport networks, and special consideration of delivering broadcast video traffic to UK subscribers. The document outlines pertinent telecoms technology and current art, how requirements I gathered, and research I conducted, and by which the transport control framework functional components are identified and selected, and by which method the architecture was implemented and applied to key research projects requiring next generation control capabilities, both at British Telecom and the wider research community. Finally, in the closing chapters, the thesis outlines the next steps for ongoing research and development of the transport network framework and key areas for further study

    Loop detection and prevention mechanism in multiprotocol label switching

    Full text link
    The extended color thread algorithm is based on running a thread hop by hop before the labels are distributed inside a MPLS Cloud Since the path for the data packets is set beforehand, the loop formation occurs at the control path. The shortest paths between selected source and destination have been calculated using Dijkstra\u27s shortest path algorithm and threads are allowed to extend through the routers. With the passage of each next hop, a distributed procedure is executed within the thread, generating a unique color at nodes. This keeps a track on router\u27s control path and at the same time ensures that no loop formation occurs. In loop prevention mode, a router transmits a label mapping, when it rewinds the thread for that particular LSP. Likewise, if a router operates in loop detection mode, it returns a label-mapping message without a thread object, after receiving a colored thread. The scheme is a loop prevention scheme, thus, ensuring loop detection and loop mitigation. The same algorithm is then extended to a proposed MPLS environment with global label space. (Abstract shortened by UMI.)

    Real-time bandwidth encapsulation for IP/MPLS Protection Switching

    Get PDF
    Bandwidth reservation and bandwidth allocation are needed to guarantee the protection of voice traffic during network failure. Since voice calls have a time constraint of 50 ms within which the traffic must be recovered, a real-time bandwidth management scheme is required. Such bandwidth allocation scheme that prioritizes voice traffic will ensure that the voice traffic is guaranteed the necessary bandwidth during the network failure. Additionally, a mechanism is also required to provide the bandwidth to voice traffic when the reserved bandwidth is insufficient to accommodate voice traffic. This mechanism must be able to utilise the working bandwidth or bandwidth reserved for lower priority applications and allocate it to the voice traffic when a network failure occurs
    corecore