Packet Technologies for Business Services
As cable turns to business services as the next big source for growth, the industry is faced with identifying the right technologies and reference architectures to deliver private networking services for voice, data and video business applications. Because many businesses expect provider network transparency for their private telecom needs, our job will be to identify the right "tunneling" technology that will provide the simplicity, deterministic behavior, and low cost points necessary to offer competitive services.
In this regard, the industry is in fact faced with a choice among three main packet technologies: provider backbone bridging-traffic engineering (PBB-TE), multi-protocol label switching/virtual private local area network [LAN] services (MPLS/VPLS) and transport-MPLS (T-MPLS). Having invested heavily in routed infrastructure, the normal reaction would be for most cable operators to head down either of the two MPLS paths. On the other hand, some of our telco counterparts, who have years of experience in offering business telecom services, are investing heavily in the emerging PBB-TE standard. In the spirit of leaving no stone unturned, it would be wise to capture their motivations by understanding how these three technologies work and how they compare. What is a pseudowire? A pseudowire is literally a virtual connection that traverses the network, containing – or emulating – a service. The service can be a circuit-emulated T-1, packetized frame relay or asynchronous transfer mode (ATM) traffic, Ethernet, etc. There are a number of pseudowire specifications, some produced by the Internet Engineering Task Force, by the International Telecommunications Union-Telecommunications and by the Metro Ethernet Forum. All these specifications accomplish the same thing – and in fact the headers of the different specifications are very similar – which is to define how to packetize the service with a unique identifier such that it can be transported through the provider packet infrastructure as if it were a circuit-switched infrastructure. The need for transparent tunneling Pseudowires, along with private networking business services, require that the provider network behave as a set of point-to-point transparent tunnels to the business customer’s network elements. For example, if a business needs a 10 Mbps connection between two offices in a metro area for LAN applications, it expects the provider to deliver an Ethernet interface in each office and that any packet transmitted into one of the interfaces will be received unadulterated through the other. In addition, many of the delivered services have stringent quality of service (QoS) requirements, essentially driving the need for a connection-oriented transport.
Unfortunately, the routed infrastructure built by most cable operators for high-speed data and voice over Internet protocol (VoIP) residential services cannot currently deliver these services. A migration to MPLS/VPLS, PBB-TE or T-MPLS will be needed to allow the creation of virtual point-to-point tunnels, where packets entering the network through a given ingress interface are literally encapsulated as-is and deterministically forwarded untouched through the network to a pre-determined egress interface, and where packets never leak between tunnels. This behavior is required from end to end: core, metro and access. MPLS/VPLS MPLS/VPLS is by far the most mature technology of the three, having been implemented in provider networks for many years. It possesses a solid control plane, a complete operations, administration and maintenance (OAM) feature set, and a scalable address space for service identification (20-bit labels).
On the other hand, of the three technologies, MPLS/VPLS is without question the most complex to configure and manage and the most expensive in terms of network equipment costs. This is because of the complexity of the required feature set and the fact that all elements must communicate up to layer 3 of the open systems interconnection (OSI) model. The MPLS operational model alone requires the configuration and management of an IP routing protocol (OSPF, IS-IS, BGP), of a label distribution protocol (LDP, RSVP), of MPLS-TE for fast-reroute and traffic engineering, and of a communication protocol to exchange the traffic-engineering attributes (such as RSVP-TE) on all provider network elements.
As a result, for cost reasons, MPLS/VPLS is labeled by the technical literature as unsuitable for access networks and questionable for metro. T-MPLS T-MPLS proposes to simplify the forwarding paradigm, control plane and configuration management aspects of MPLS to deliver a connection-oriented transport solution for the creation of transparent tunnels through the provider network. It is born of the realization that MPLS is too costly for network-wide deployments as well as the need to create a specification suitable for transport.
Much of the simplification brought by T-MPLS comes from the elimination of the MPLS IP control plane. As a result, T-MPLS elements must be individually configured through an element management system (EMS) with an explicit forwarding configuration on a per-LSP (local service provider) basis. Provider edge devices must also be configured with explicit classification policies per LSP, which can be based on port, L2 or L3/4 information. T-MPLS elements therefore do not need to run a routing protocol, nor exchange label information. T-MPLS includes sub-50 ms linear switching and ring protection mechanisms. In an effort to provide OAM integrity, T-MPLS eliminates the support of penultimate hop popping, LSP merging and equal cost multi-path. T-MPLS does not have a direct mapping to a physical layer. As a consequence, it must be carried over another protocol, such as Ethernet.
As illustrated in Figure 1, for Ethernet services, packets are encapsulated into a pseudowire "inner label" tunnel (PWE3 in the diagram), which are then transported through the network using the T-MPLS "outer-label." From a standardization perspective, T-MPLS contains definitions for the transport of IP/MPLS and pseudowire services for legacy applications (ATM, frame relay, Ethernet, etc.), with relatively well-defined functional architecture and transport hierarchy specifications. T-MPLS forwarding has been demonstrated by a number of vendors. On the other hand, although T-MPLS includes the adoption of ITU-T’s Y.1711 recommendation for its OAM methodology, it lacks some of the management tools provided by transport networks, and control plane signaling is still a key area for future development, with the expectation of perhaps using generalized multi-protocol label switching (GMPLS) protocols. The interoperability of MPLS and T-MPLS is work in progress. PBB-TE In 2005, the Institute of Electrical and Electronics Engineers created the 802.1ad specification (also known as Q-in-Q), which essentially added a second VLAN ID to the Ethernet header. Unfortunately, the 4096 possible VLANs supported by this new field didn’t provide the scalability necessary for provider use except in very small service networks. In 2006-2007, the IEEE created a new specification, 802.1ah, named PBB. Also known as MAC-in-MAC, PBB defines a second media access control (MAC) header dedicated for provider use, specifically designed to offer the scalability necessary to support a very large number of virtual private networks within the provider network.
As shown in Figure 2, in a PBB network, the incoming customer services are encapsulated into a "provider" Ethernet header, where the source and destination MAC addresses identify the provider network ingress and egress points. The backbone VLAN identifier (B-VID) allows 4096 backbone VLANs, and the service instance VLAN identifier (I-SID, 24 bits) allows up to 16 million unique service instances over the network. The forwarding paradigm of a PBB network is closely related to a 802.1q network, in the sense that provider edge bridge tables are required to forward packets based on customer-side MAC learning per VLAN and service instance, with the difference that a customer’s MAC addresses are learned and stored in memory only by its customer-facing provider backbone bridge port. All other network elements only learn of PBB equipment MAC information. Bridging tables in the PBB network are therefore small.
Unfortunately, the Ethernet bridged connectionless nature of PBB precludes hard QoS.
This is where PBB-TE (also known as 802.1Qay) comes in. PBB-TE is the standard version of provider backbone transport (PBT) being defined by the IEEE. PBB-TE tailors PBB to become suitable for point-to-point deterministic transport. It disables the flooding/broadcasting behavior of PBB and eliminates spanning tree, replacing it with explicit (and optionally) redundant path configurations and built-in continuity checks, yielding sub-50 ms fault recovery. The B-VID field is used together with the destination MAC address to indicate a unique primary and secondary path and optionally segregated QoS levels across the network.
As in traditional bridged networks, PBB-TE provides element and topology auto-discovery while giving the provider full control over the establishment of network paths on a per-service basis. Its connection-oriented nature enables connection admission control to allow for hard QoS. Being Ethernet based, PBB-TE benefits from the 802.1ag standard, also known as connectivity fault management (CFM), as well as other standards that define the OAM tools necessary to deploy and manage carrier Ethernet networks. Because of the flexible nature of Ethernet and the deterministic nature of PBB-TE, hard QoS and sub-50 ms fault recovery are supported in all network topologies (ring, mesh, hub and spoke, etc).
From a standards track perspective, the PBB standard is at revision 3.8, approved in October 2007. Version 4.0, proposed in November 2007, provides minor changes to the functional specification. As with T-MPLS, the PBB-TE standard is still being defined. It has reached the stage where multi-vendor interoperability has been demonstrated. Why are telcos investing in PBB-TE? As described earlier, although MPLS/VPLS is the most mature technology available today, it is also commonly viewed as cost-prohibitive for access and even metro deployments. The simple fact that T-MPLS is actively being defined as a simplified version of MPLS, to reduce complexity and cost and add transport capabilities, supports this claim.
So providers are left with only two options: T-MPLS or PBB-TE. At different stages of the standardization process, a side-by-side comparison of the two anticipated resulting specifications shows many similarities. Shared attributes are:
• Creation of connection-oriented transparent tunnels
• Support for pseudowire and Ethernet services
• Scalability needed for large provider network deployments
• Requirement to configure explicit paths
• Definition of hard QoS and sub-50 ms fault recovery mechanisms
• Standard definition of OAM capabilities
These two specifications are very similar from a functional perspective, but PBB-TE offers something that T-MPLS doesn’t: a direct tie-in with Ethernet.
The stars are aligning in favor of Ethernet-based technologies. Ethernet is becoming the universal service handoff interface. Transport and Ethernet LAN speeds are aligning (10 GE/OTU-2, and upcoming 100 Gig standards). And Ethernet is migrating to the metro and wide area network (WAN).
PBB-TE is an L2 transport standard that builds on an L2 standard that has its own L2 addressing scheme, L2 OAM standards, and universal L2 client. T-MPLS is an L2 transport standard without an inherent L2 (MAC) addressing scheme, with its own OAM standards, and with support for alien clients.
The telcos currently investing in PBB-TE are laying the foundation for a next generation all-Ethernet network where the provider infrastructure will be tightly wrapped around Ethernet standards, riding the cost curves of Ethernet technologies. PBB-TE delivers the scalability and feature set required to transport the full suite of business services along with the routed residential traffic.
As such, PBB-TE could be poised to become the converged infrastructure many have been seeking. Benoit Legault is director of cable marketing for Ciena. Reach him at [email protected]. Raghu Ranganathan is technology director, office of the CTO, for Ciena. Reach him at [email protected].
