Introduction
A number of techniques have emerged in the industry to transport carrier Ethernet services and all have their advantages and challenges. This paper will explore how one such technology, provider backbone transport (PBT), addresses the existing challenges of natively delivering Ethernet services across a service provider's network. Until now, other technologies such as synchronous optical network (SONET)/synchronous digital hierarchy (SDH) or multiprotocol label switching (MPLS) have been required to build large-scale networks. However, many carriers are actively seeking native Ethernet networks to reduce operational and capital costs while still enabling the efficient delivery of a wide range of existing and emerging applications and services. Due to its ubiquity and ease of use, PBT Ethernet is positioned to capitalize on the sizable opportunity of delivering and transporting carrier Ethernet services.
Provider Backbone Transport
PBT has emerged to address limitations related to scalability and reliability in the delivery of carrier Ethernet services. PBT eliminates the need for backbone core devices to perform learning and flooding, two of the major drains on legacy systems. Instead, point-to-point tunnels to transport Layer 2 virtual private networks (L2VPNs) are provisioned using a sophisticated management platform. Additionally, using provisioned PBT tunnels — rather than rapid spanning tree protocol (RSTP)/multiple spanning tree protocol (MSTP), which are most commonly used to prevent loops — enables network administrators to utilize significantly more capacity.
Figure 1 shows the greater utilization of the backbone network with PBT enabled. Primary and backup paths or tunnels are provisioned.
Additionally, it is expected that Institute of Electrical and Electronics Engineers (IEEE) 802.1 will standardize PBT, as it is an innovative and increasingly popular transport technology. This is a significant advantage because PBT leverages the existing IEEE 802.1ah frame format, without modification, as shown in Figure 2, making implementation far easier for service providers.
Primary and backup PBT tunnels are preconfigured by a management system that enables the operator to traffic engineer according to path, bandwidth, and service requirements. Customers and services are associated with tunnels, taking into account the aggregate committed information rate (CIR) and excess information rate (EIR) bandwidth requirements. Tunnels are monitored through the use of IEEE 802.1ag connectivity fault management (CFM) continuity check messages (CCM). CCM control frames are sent and received every few milliseconds across PBT tunnels. If the primary tunnel should experience a fault, the tunnel endpoints automatically begin using the backup tunnel. The forwarding database entries are preconfigured along the backup path to minimize the failover and restoration times.
Superior solutions will support the draft of IEEE 802.1ag CFM, including MAC ping, MAC traceroute, and CCM. Using these powerful CFM facilities, both service connectivity and PBT tunnels resiliency is enhanced. In addition, configurable CCM thresholds provide tunable protection switching.
Figure 3 is an analysis of the benefits and limitations of PBT.
With virtual local-area network (VLAN)-enabled networks, occasionally, services are impacted by "soft" failures. A soft failure usually consists of configuration or operator errors. For instance, a set of VIDs on a particular device or port may be disabled by an administrator. Upon initial inspection, some troubleshooting techniques may conclude the port is active and other traffic is passing normally. This result may lead the operator to look elsewhere for the problem. A proposed project in IEEE 802.1 deals with these configuration errors. It is known as data-dependent CFM. These advancements will further enhance the ability of carrier Ethernet transport technologies such as PBT to provide lower-cost operations and enhanced resiliency.
How PBT Works
Figure 4 shows two provider bridge (PB) networks interconnected with a PBT network. Two customer L2VPNs are shown traversing primary and backup PBT tunnels through the core network.
Customer A (red) traffic originates at its site 1. The PB encapsulates the customer traffic by adding an S-tag containing the configured S-VID value of 100 reserved for customer A within its domain. The traffic is sent to a provider backbone edge bridge A (PBEB-A).
PBEB-A has been configured to assign customer A traffic (S-VID=100) to a 24-bit instance service identifier (I-SID) value of 10,000. The same I-SID value is associated with a primary PBT tunnel and a backup PBT tunnel. Each primary and backup tunnel is identified using the combination of a PBEB destination MAC address and a backbone-VID (B-VID).
This represents a significant difference between PBT and provider backbone bridging (PBB), which is commonly used in carrier Ethernet delivery. With PBB, B-VIDs represent flood domains that interconnect multiple PB networks. Alternatively, with PBT, B-VIDs, along with B-DAs, define the tunnel, creating a more robust delivery platform.
In this case, the PBEB-A encapsulates S-VID 100 traffic by adding a B-DA value of PBEB-D, a B-SA value of PBEB-A, a B-VID value of 4001 (primary tunnel), and the I-SID value of 10,000. This MAC header encapsulated traffic is forwarded to provider backbone core bridge C (PBCB-C). PBCB-C has been configured to not learn or flood traffic on B-VID 4001, which has been reserved for PBT use.
The fact that PBT does not learn or flood is extremely important in the delivery of services. Each PBCB device must be provisioned with forwarding database entries to properly forward traffic within tunnels.
The PBCB-C forwarding table contains an entry for {PBEB-D, B-VID 4001}, and the traffic is forwarded on the particular port in the direction of PBEB-D.
PBEB-D receives the traffic and removes the MAC header encapsulation. Since the S-VID values are only locally significant per PB network, a provider has the flexibility to translate the S-VID value. In this case, PBEB-D has been configured to associate I-SID 10,000 with S-VID 110.
Solutions such as PBT, which supports powerful remapping and translation capabilities for backbone-VIDs, service-VIDs, and customer-VIDs, give operators the greatest flexibility in designing and evolving core network architecture.
In the above example, traffic from the tunnel is de-encapsulated and the S-VID is remapped to the value of 110. The traffic is forwarded to the PB attached to customer A site 2. The S-tag encapsulation is removed by the PB device and the original customer frame from site 1 is delivered to site 2.
Conclusion
As carrier Ethernet continues to mature, service providers and their customers will demand even faster, more scalable, more reliable delivery of services. Superior platforms will be needed to ensure delivery meets these requirements. PBT addresses current challenges affecting the quality of service in carrier Ethernet service delivery and, with its easy-to-manage, resilient, and scalability-enhancing characteristics, will enable service providers to deliver the highest-quality services possible.
