Multicast traffic aggregation in MPLS-based VPN networks

Abstract

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. site L2VPN. This is the context where P2MP LSPs may save bandwidth for the SP at the cost of a significant increase of forwarding state in core routers. As we shall review, experts have surrendered to the evidence that only an intelligent aggregation of multiple VPNs into the same multicast/broadcast tree can yield important bandwidth savings at a reasonable cost. How this partition and assignment of VPNs to trees should be made is an open research issue, given the diversity of topologies, traffic, and sites of different VPNs and backbone networks. On the other hand, high-rate flows may justify the setup of group-membership-aware multicast trees to avoid traffic in nodes not leading to group receivers. ADVANCES IN CONTROL AND MANAGEMENT OF CONNECTION-ORIENTED NETWORKSIsaiasThe rest of this article is organized as follows. We describe how to build P2MP trees in an MPLS network suitable for arbitrary aggregation of VPN trees. We present the problem of how to bundle and share multipoint LSPs in a scalable way and the techniques being developed in the Internet Engineering Task Force (IETF) for this purpose. We explore the trade-off of state vs. bandwidth in the particular multicast VPN context. We draw a few practical conclusions and suggest directions for future work. SIGNALING POINT-TO-MULTIPOINT MPLS LSPSA fundamental functionality required to take advantage of multicast in the network core is the ability to set up and use P2MP label-based forwarding entries. There are two protocols defined by the IETF to build LSPs in MPLS networks: Resource Reservation Protocol with Traffic Engineering (RSVP-TE) and Label Distribution Protocol (LDP). Both can be extended to support P2MP LSPs [2][3][4]. RSVP-TE builds the P2MP trees from the root to the leaves, whereas LDP builds the trees from the leaves to the root. In the case of IP multicast trees, LDP is intended to build the LSP following the IP multicast routing protocol. However, since all the solutions developed for scalable VPN multicast services are based on traffic engineered multi-VPN tree sharing, RSVP-TE is a more suitable tree setup protocol for this purpose. In fact, RSVP-TE indeed allows a tree to be constructed from a root router to a given set of leaf routers -in our case, the set of provider edge (PE) routers serving the sites of all the VPNs that have been selected to share the tree. ...

On forwarding state control in VPN multicast based on MPLS multipoint LSPs

“…The idea of aggregation was firstly studied in [8], further exploited by A. Fei et al for IP multicast routing with/without MPLS in [9][10][11], and it has been revisited in the specific context of MPLS VPNs in several works [7,12] where different aspects are addressed together with aggregation, including P2MP tree signaling and frame encapsulation mechanisms on the shared tree. In [10] the authors address many implementation aspects of group management and introduce a centralized management entity called tree manager, which is in charge of assigning groups to existing trees or create new ones.…”

“…An alternative methodology to analyze the behavior and benefits of using shared aggregation trees in MPLS-based VPN networks was proposed in [7]. In this work, a simple state vs. bandwidth trade-off analysis was presented, showing the benefits of aggregation even if the best tree-matching algorithm is replaced by uniform random tree allocation.…”

“…It is the case of tripleplay providers [6], that deliver TV over IP multicast to their ADSL residential clients, where usually the last hop is delivered over IP unicast from a multimedia relay at the SP point of presence (PoP), or over native IP multicast to the set-top-box. This can easily scale to thousands of channels and users, if implemented with IP/MPLS over point-to-multipoint (P2MP) label switched paths (LSP) sent from a content delivery root to the relays [7]. Therefore, a careful utilization of multicast LSPs is paramount to build a more efficient and scalable multi-service network.…”

“…Therefore, a careful utilization of multicast LSPs is paramount to build a more efficient and scalable multi-service network. However, as pointed out in [1,3,5,7], the trouble with the tree approach is the trade-off between used bandwidth and forwarding state. The problem is that the core network nodes must keep per-multicast-group per-vpn per-tree information.…”

“…All VPN specific information should remain at the PE (Provider Edge) routers instead. Therefore, the standard approach [1,2] recommends to use a number of trees to be shared by many VPNs, that conversely, introduces new bandwidth consumption penalty [7] and a complex traffic grooming optimization problem: how to aggregate multicast groups into shared trees. In [5] authors identify the trade-off issue and claim that further work is required to study it.…”