Multicast traffic aggregation in MPLS-based VPN networks

This article gives an overview of the current practical approaches under study for a scalable implementation of multicast in layer 2 and 3 VPNs over an IP-MPLS multiservice network. These proposals are based on a well-known technique: the aggregation of traffic into shared trees to manage the forwarding state vs. bandwidth saving trade-off. This sort of traffic engineering mechanism requires methods to estimate the resources needed to set up a multicast shared tree for a set of VPNs. The methodology proposed in this article consists of studying the effect of aggregation obtained by random shared tree allocation on a reference model of a representative network scenario.Publicad

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)

Multi-partner Demonstration of BGPLS enabled multi-domain EON control and instantiation with H-PCE

The control of multidomain elastic optical networks (EONs) is possible by combining Hierarchical Path Computation Element (H-PCE)-based computation, Border Gateway Protocol with Extensions for Traffic Engineering Link State Information (BGP-LS) topology discovery, remote instantiation via Path Computation Element Communication Protocol (PCEP), and signaling via Resource Reservation Protocol with Extensions for Traffic Engineering (RSVP-TE). Two evolutionary architectures are considered, one based on stateless H-PCE, PCEP instantiation, and end-to-end RSVP-TE signaling (SL-E2E), and a second one based on stateful active H-PCE with per-domain instantiation and stitching. This paper presents the first multiplatform demonstration that fully validates both control architectures achieving multiprotocol interoperability. SL-E2E leads to slightly faster provisioning but needs to keep the state of the stitching of the end-to-end label-switched paths in the parent PCE

Inter-Domain Path Computation using Improved Crankback Signaling in Label Switched Networks

The paper deals with the problem of finding suboptimal routing paths in multi-domain Internet environment. The proposed solution can be used in traffic enginering with MPLS

Optimization of BGP Convergence and Prefix Security in IP/MPLS Networks

Multi-Protocol Label Switching-based networks are the backbone of the operation of the Internet, that communicates through the use of the Border Gateway Protocol which connects distinct networks, referred to as Autonomous Systems, together. As the technology matures, so does the challenges caused by the extreme growth rate of the Internet. The amount of BGP prefixes required to facilitate such an increase in connectivity introduces multiple new critical issues, such as with the scalability and the security of the aforementioned Border Gateway Protocol. Illustration of an implementation of an IP/MPLS core transmission network is formed through the introduction of the four main pillars of an Autonomous System: Multi-Protocol Label Switching, Border Gateway Protocol, Open Shortest Path First and the Resource Reservation Protocol. The symbiosis of these technologies is used to introduce the practicalities of operating an IP/MPLS-based ISP network with traffic engineering and fault-resilience at heart. The first research objective of this thesis is to determine whether the deployment of a new BGP feature, which is referred to as BGP Prefix Independent Convergence (PIC), within AS16086 would be a worthwhile endeavour. This BGP extension aims to reduce the convergence delay of BGP Prefixes inside of an IP/MPLS Core Transmission Network, thus improving the networks resilience against faults. Simultaneously, the second research objective was to research the available mechanisms considering the protection of BGP Prefixes, such as with the implementation of the Resource Public Key Infrastructure and the Artemis BGP Monitor for proactive and reactive security of BGP prefixes within AS16086. The future prospective deployment of BGPsec is discussed to form an outlook to the future of IP/MPLS network design. As the trust-based nature of BGP as a protocol has become a distinct vulnerability, thus necessitating the use of various technologies to secure the communications between the Autonomous Systems that form the network to end all networks, the Internet

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

PCE prototype with segment routing and BGPLS support

This project presents two contributions to the PCE implementation in Telefonica I+D: Segment Routing and the upgrade of the BGP-LS protocol to the 3rd version of the draft to support MPLS and GMPLS scenarios. Regarding the first contribution, this document is intended to assess the use of Segment Routing in centralised traffic-engineering scenarios. It will attempt to make a validation of such technology using the available IETF drafts and publications and trying, at all time, to back-up the use cases with experimental demonstrations. Moreover, the 3rd version of the BGP-LS protocol draft was implemented. This protocol opens the possibility to export the network’s topology and its Traffic Engineering parameters to external entities. The BGP-LS extensions developed enables to retrieve the TE parameters for MPLS and GMPLS networks. The development of the project was done in Telefonica R&D’s facilities within the Core Network Evolution group. The code extends Telefonica’s PCE and network protocols to support Segment Routing and the new version for BGP-LS. As such, both the PCEP and the BGP-LS protocols were enhanced with the latest IETF drafts that define the technology. Once the code was developed and debugged, a series of tests were run in order to validate that the format used followed all the proposed standards. These tests have been defined following the sections that constitute each draft in an attempt to proof the use of each protocol in the most exhaustive possible way. It is important to remark that the validation tests are done not only with Telefonica code, but also with external prestigious entities like Cisco, Telecom Italia, Centre Tecnològic Telecomunicacions Catalunya or Consorzio Nazionale Interuniversitario per le Telecomunicazioni.Ingeniería de Telecomunicació