One of the criticisms of PBB-TE and T-MPLS is their focus on point-to-point connections. There are demands for PBB-TE and T-MPLS to extend this functionality with multipoint support. The following provides an overview of what has been achieved, but also shows that true any-to-any multipoint requires more.
By DANIEL JOSEPH BARRY
TPACK
The introduction of Packet Backbone Transport (PBT) and Transport Multi-Protocol Label Switching (T-MPLS) in 2005 has enlivened the otherwise mundane world of packet transport into passionate debate on their virtues (or otherwise) compared to IP/MPLS.
One of the major criticisms of both PBT (which is being standardized in IEEE under the name Provider Backbone Bridging -- Traffic Engineering, or PBB-TE) and T-MPLS is their focus on point-to-point connections. It is argued that for support of VPN and IPTV services, multipoint connectivity needs to be addressed. PBB-TE and T-MPLS supporters have taken note and tried to address this concern. In the following we will take a look at the proposed solutions and some of the additional activities taking place.
No protocol can do it all
Before exploring the solutions that are available for Layer 2 multipoint networks, we should stop and reflect on what we are actually talking about.
Critics of PBB-TE and T-MPLS claim that MPLS delivers both point-to-point and multipoint transmission and as such is the superior choice. But, if we are to be fair, then we need to dissect this statement and understand what exactly this means.
MPLS was introduced as both a performance improvement mechanism for Internet Protocol (IP), but also as a means of introducing connection-oriented traffic engineering to IP router networks. Connection-oriented networks are, by nature, point-to-point with the MPLS implementation based on label switched paths (LSPs). In this scenario, IP provides multipoint connectivity with MPLS providing point-to-point connectivity.
MPLS itself is not, and was not intended to be, a multipoint protocol. It has been extended to support point-to-multipoint applications, but any-to-any multipoint applications require additional complementary resources. These include IP virtual private networks (VPNs) based on Border Gateway Protocol (BGP, otherwise known as Layer 3 VPN or 2547bis networks) or virtual private LAN service (VPLS), which we will see below is more than just MPLS.
T-MPLS and PBB-TE actually support point-to-multipoint applications, T-MPLS using the same principles as point-to-multipoint MPLS, while point-to-multipoint PBB-TE is being addressed in IEEE 802.1Qay. So, the point of contention must be in regard to any-to-any multipoint applications. The remainder of the article will concentrate on this scenario where reference to multipoint should be understood as any-to-any multipoint.
Simplicity, ease of use, and determinism
For any-to-any multipoint networks, the challenge is to create a network architecture that is simple to establish and manage, where traffic can be controlled, but where it is open to the addition and removal of endpoints and clients without these changes unduly affecting the operation of the network.
Think of a VPN. While there might be a fixed number of clients or endpoints to connect at deployment time, the power of the VPN is that you can add, move, and remove these clients without disrupting the operation of the VPN.
It is therefore advantageous if the multipoint network has some means of autonomous establishment of connectivity to ease management, configuration, and complexity. This can be centralized in a network management provisioning system or decentralized in network control protocols running on each node.
IP and enterprise Ethernet are connectionless networks that were designed from the beginning to be multipoint. Adding, removing, and taking away clients of these networks are simple tasks to perform. This is made possible by autonomous routing protocols in the case of IP and MAC learning in the case of Ethernet. The network simply learns how to reach each endpoint or client and adapts when changes occur in the network.
However, this is also a disadvantage as it is difficult to predict which route traffic will take through the network at any given time. Indeed, traffic might follow an undesirable route or lead to congestion on some routes while others are underutilized. These factors create a desire for traffic engineering and connection-oriented behavior in large networks with expensive connectivity.
The challenge is, therefore, to find a multipoint approach that combines traffic engineering capabilities or determinism with autonomous, scalable, and simple implementation and operation. There are two levels of determinism to consider here. The first is routing determinism, where traffic will follow a predictable path during normal operation; the second is full determinism, where traffic will follow a predictable path both in normal operation and when a fault or other changes occur in the network.
MPLS, T-MPLS, and PBB-TE were introduced to provide traffic engineering capabilities and determinism. MPLS provides traffic engineering and some routing path determinism to IP; T-MPLS adds even more determinism with fixed path configuration. PBB-TE adds both traffic engineering and determinism to Ethernet. But none of these mechanisms are multipoint by nature. This is often forgotten in the case of MPLS. It is therefore necessary to complement these protocols with further technology and capabilities to implement a deterministic, scalable, and simple-to-use multipoint network.
Layer 2 multipoint today
Before looking at developments in T-MPLS and PBB-TE, it can be instructive to look at how multipoint packet networks are implemented today. IP routers can be used to provide Layer 3 VPNs based on BGP routing. However, for this article we will concentrate on Layer 2 multipoint networks or VPNs.
VPLS. The most popular implementation of Layer 2 VPNs today is VPLS. VPLS is based on an Ethernet over MPLS approach using Pseudowire End-to-End Emulation (PWE3). It is standardized in IETF recommendation RFC 4762 with PWE3 standardized in RFC 4448. (An alternative VPLS implementation is also standardized in RFC 4761, which uses BGP instead of LDP for PW setup.)
VPLS is an "emulated LAN" service. In other words, it tries to emulate the behavior of Ethernet LANs in a wide-area network. It is based on Ethernet as the user interface and forwarding mechanism, but requires transport tunnels, which in the current standard are based on MPLS. However, since VPLS is defined as a service, it can be supported by other transport technologies, such as T-MPLS and PBB-TE.
To understand more about VPLS, see "An Overview of VPLS."
VPLS based on T-MPLS tunnels. VPLS is a LAN emulation service, which requires full mesh connectivity between provider edge (PE) nodes. MPLS is used for underlying transport in the IETF standard approach, but another method is to use T-MPLS tunnels. Since T-MPLS is based on MPLS, it also supports PWE3 tunnels to transport Ethernet and other legacy protocols.
The implementation is thus similar to standard VPLS, with one distinction: T-MPLS LSPs are bidirectional by nature, making configuration slightly easier. The use of configuration to establish T-MPLS LSPs (T-MPLS uses centralized network management to establish LSPs rather than autonomous routing protocols) also means that traffic will always follow the same route. This is not always the case in MPLS, as changes in the network can cause the LSP to be rerouted. In T-MPLS, path changes can occur when a fault occurs and traffic is switched to a predefined backup path. Since the backup path is predefined, full determinism is preserved.
For a T-MPLS based approach, there is no need for a full router implementation, making it possible to introduce multipoint T-MPLS in Layer 2 nodes, such as multi-service provisioning platforms (MSPPs). This can be attractive for service providers who do not want to extend their router networks.
T-MPLS has been standardized by ITU-T in a series of recommendations, with G.8110.1, G.8112, and G.8121 the defining documents. These recommendations are currently being aligned with IETF's new MPLS Transport Profile (MPLS TP) initiative, which also provides a transport-focused version of MPLS very similar to T-MPLS. The two approaches differ with respect to operations, administration, and maintenance (OAM) and protection-switching mechanisms. However, from a multipoint perspective, MPLS TP will probably use a VPLS-like approach similar to MPLS and T-MPLS.
VPLS based on PBB-TE. A similar approach has also been suggested for PBB-TE by Hammerhead Systems. In this implementation, PBB-TE tunnels are used instead of MPLS LSPs to implement connectivity between VPLS nodes. Since Ethernet is natively supported by PBB-TE, there is no need for a pseudowire implementation -- the PBB-TE tunnel can be used directly.
As can be seen in Figure 1, the architecture is very similar to MPLS-based VPLS, but with only a single tunnel layer rather than both an LSP and pseudowire. The tunnels are also bidirectional and configured using a centralized network management system similar to T-MPLS. This provides the same advantages of full determinism and predictability as in T-MPLS.
Again, this approach is attractive in situations where an expansion of the existing router network is not desired. In this case, a Carrier Ethernet switch implementation provides an alternative to router deployment.
Alternatively, as Hammerhead Systems suggests, both MPLS and PBB-TE VPLS can be combined. Since the heart of the VPLS is the virtual switch instance (VSI) and this is a common component to both implementations, the use of different tunneling technologies is not an issue. This allows a mix of router and Carrier Ethernet switches to be used to implement a multipoint network.
Advantages and disadvantages of VPLS-based approaches
The advantage of a VPLS approach using a combination of connection-oriented tunnels and MAC learning is that it provides deterministic control of traffic while its autonomous operation allows endpoints and clients to be added and removed easily.
Nevertheless, there has been criticism of VPLS with regard to its ability to scale. The key issue is the architecture of VPLS, which requires a full bidirectional mesh of tunnels between all VPLS PE nodes for each VPLS instance. This means that N nodes require N2 connections, which can lead to scaling issues in a large network, not to mention the complexity of managing such a network. Addition of a new PE also requires that every PE's configuration must be updated to establish connectivity with the new PE. A standardization effort is ongoing to provide an automated method of achieving this for large networks.
H-VPLS has been introduced to address this. However, it only does so to a certain extent. (See "Overview of VPLS" for more info on H-VPLS.)
The criticisms of VPLS and H-VPLS have driven some to consider alternatives. Nortel, for example, has been active in the promotion of PBB and Provider Link State Bridging (PLSB) as an Ethernet-focused any-to-any multipoint method.
PBB is multipoint equivalent of PBB-TE
PBB was introduced to address some of the scalability and separation issues in IEEE 802.1ad stacked VLAN Ethernet, otherwise known as "Q-in-Q." In Q-in-Q, a customer VLAN (C-VLAN) and service provider VLAN (S-VLAN) are included in the Ethernet frame to provide administrative separation of customer and service provider traffic. However, customer MAC addresses still need to be learned by all nodes. In a large network this can result in MAC tables with over half a million MAC addresses or more per node.
PBB introduces a new frame format that supports a large number of service instances and a complete separation of transport/backbone and customer traffic. This feature is achieved using an additional backbone MAC (B-MAC) address and backbone virtual LAN (B-VLAN) ID as well as a 24-bit I-SID Service Identifier. This means that customer MAC addresses are only learned at the edge of the network, while forwarding in the backbone is performed based on B-MAC addresses and B-VLANs.
PBB uses Spanning Tree Protocol (STP) to ensure that there are no loops in the network. This is achieved by turning off ports or closing links (depending on your point of view) that could give rise to loop issues. However, this means that some bandwidth and ports are not used, which is wasteful in an expensive environment like a Wide Area Network (WAN).
PLSB is a new approach that suggests replacing STP with a more sophisticated control protocol based on Intermediate System to Intermediate System (IS-IS) signaling. This approach is more efficient and provides routing determinism, but is still new and seeking broader acceptance.
For more information on PBB and PLSB see "An overview of PBB and PLSB."
Scalability, complexity, and determinism
As can be seen from the examples above, it can be difficult to create a multipoint architecture that can satisfy the requirements of scalability, complexity, and determinism at the same time. The table provides an overview.
From the above, it can be seen that there are basically two approaches to any-to-any multipoint implementation today. One is based on VPLS with various transport technologies, while the other is based on a more traditional Ethernet approach possibly using PLSB.
However, there are no clear winners, and tradeoffs are required in each approach. What should be noted is that all of the above are multipoint-focused methods intended to complement existing point-to-point approaches based on PBB-TE tunnels and MPLS/T-MPLS LSPs.
Combining VPLS and PBB
A new approach combines VPLS and PBB and could overcome the tradeoffs in the options examined thus far (see Figure 2). Described in IETF draft-sajassi-l2vpn-vpls-pbb-interop, the architecture is based on a VPLS core with PBB "spokes" providing access to the VPLS. Like H-VPLS, there is a reduction in the number of pseudowires required as well as the number of MAC addresses to be learned, since PBB only presents B-MAC addresses. The large number of service instances supported by the I-SID can also be exploited.
This approach would appear to address many of the concerns with VPLS and could provide the balance between scalability, complexity, and determinism. As this method suggests, the path forward could be driven more by combinations of existing mechanisms to address the shortcomings of individual alternatives rather than development of entirely new approaches.
Multipoint PBB-TE and T-MPLS in perspective
From the above discussion, it should now be clear that when discussing multipoint PBB-TE and T-MPLS, certain things should be kept in mind.
Firstly, that any-to-any multipoint and point-to-point networks are different. There is no technology that inherently supports both well. MPLS brought point-to-point tunnels to multipoint IP. In VPLS, point-to-point MPLS LSPs are used to support PWE3 transport tunnels between Ethernet-based VSIs. As we have seen, this approach can also be implemented using T-MPLS and PBB-TE tunnels.
It should therefore be clear that it is the combination of MPLS and VPLS that allows support of point-to-point and multipoint connectivity and not MPLS alone. It should therefore be no surprise that T-MPLS and PBB-TE also require complementary mechanisms for multipoint -- a fact that shouldn't reflect more negatively on them than it does on MPLS. Indeed, as we have seen, these complementary mechanisms exist today.
Secondly, the continued development of Ethernet is creating more powerful complements, such as PBB and PLSB. These are providing a connectionless alternative to connection-oriented VPLS-like approaches.
Finally, by combining both VPLS and PBB, one has the potential to get the best of both worlds: determinism in the core using VPLS and traffic engineered tunnels, combined with scalability and ease of use at the edge using PBB.
One can expect continued activity in this area with improvements to all the abovementioned approaches. It is difficult to predict which approach will prevail, and it is therefore prudent to keep an open mind (and open implementation) to the new developments that will inevitably come.
Daniel Joseph Barryis director of marketing at TPACK (www.tpack.com).