Carrier Ethernet Transport Scalability and Resiliency

Within the last few years, it has become evident that Ethernet would ultimately succeed in access and metro deployments. At the time, MPLS represented one viable option for interconnecting PB networks. Another development surfaced known as Provider Backbone Bridging (PBB). PBB uses MAC header encapsulation to alleviate MAC address and service scalability concerns. The figure below shows a typical PBB network:

The format of the 802.1ah Provider Bridge frame is shown below.

The original PB frame is preserved intact. Each of the fields, beginning with the customer destination address (C-DA) and customer source address (C-SA), is transported across the PBB network without modification. More importantly, these customer addresses are not learned by core devices, reducing the cost and complexity of PBB equipment.

The following is an analysis of the benefits and limitations of PBB.

Benefits	Limitations
Data plane	Data plane
16M services Transparency of multiple 4K S-VID ranges Customer MAC addresses tunneled on the provider network, enhancing security and scalability	Provider Backbone Edge Bridge (PBEB) devices learn all PBB devices and transiting Customer MACs PBB diameter limited by RSTP/MSTP constraints
Control plane	Control plane
Separation of Customer, Provider, and Backbone Control Domains Customer and PB layer two control protocols are transported through PBB network	Lower PBB network capacity due to RSTP/MSTP loop prevention

Topological loops within PBB networks are detected and blocked using either RSTP or MSTP. While this enables loop-free topologies, a byproduct is less efficient use of PBB capacity. World Wide Packets LightningEdge solution enables MSTP-based core network segmentation for greater flexibility and manageability.

Provider Backbone Bridging — Traffic Engineering

Provider Backbone Bridging — Traffic Engineering (PBB-TE) has emerged to address limitations related to scalability and reliability. PBB-TE may be deployed in place of PBB or may run in parallel with PBB. In both cases, PBB-TE eliminates the need for backbone core devices to perform learning and flooding. Instead, point-to-point tunnels to transport L2VPNs are provisioned using a sophisticated management platform. Rather than using RSTP/MSTP to prevent loops, the management platform traffic engineers the provider backbone network utilizing significantly more capacity.

The figure above shows the greater utilization of the backbone network with PBB-TE enabled. Primary and backup paths or tunnels are provisioned.

IEEE 802.1 has initiated a project to standardize this innovative and increasingly popular transport technology. An international standard will promote multi-vendor support and interoperability. IEEE 802.1Qay will leverage the existing IEEE 802.1ah Provider Backbone Bridging frame format, without modification, as shown below:

The following figure shows two PB networks interconnected with a PBB-TE network. Two customer L2VPNs are shown traversing primary and backup PBB-TE 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 the 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 10000. The same I-SID value is associated with a primary PBB-TE tunnel and with a backup PBB-TE tunnel. Each primary tunnel and backup tunnel are identified using the combination of a PBEB Destination MAC address and a Backbone-VID (B-VID).

This represents a significant difference between PBB-TE and PBB. Recall that with PBB, B-VIDs represent flood domains that interconnect multiple PB networks. With PBB-TE, B-VIDs along with B-DA’s define the tunnel.

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 or purple tunnel), and the I-SID value of 10000. 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 PBB-TE use.

The fact that PBB-TE does not learn or flood is an important point. Each PBCB device must be provisioned with forwarding database entries in order 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 10000 with S-VID 110.

World Wide Packets LightningEdge solution supports powerful remapping and translation capabilities for Backbone-VIDs, Service-VIDs, and Customer-VIDs. This gives operators the greatest flexibility in designing and evolving core network architecture.

In this illustration, 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.

Primary and backup PBB-TE tunnels are pre-configured by a management system. This enables the operator to engineer traffic 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 PBB-TE tunnels. If the primary tunnel should experience a fault, the tunnel endpoints automatically begin using the backup tunnel. The forwarding database entries are pre-configured along the backup path to minimize the failover and restoration times.

World Wide Packets LightningEdge solution supports the draft IEEE 802.1ag CFM including MAC ping, MAC traceroute, and CCM. Using these powerful CFM facilities, both service connectivity and PBB-TE tunnels resiliency is enhanced. In addition, configurable CCM thresholds provide tunable protection switching.

The following is an analysis of the benefits and limitations of PBB-TE.

Benefits	Limitations
Data plane	Data plane
16M services Transparency of multiple 4K S-VID ranges No learning or flooding in core network Customer MAC addresses tunneled on provider network enhancing security and scalability Maximum utilization of core network with engineered paths	PBEB devices learn all Backbone and transiting Customer MACs
Control plane	Control plane
Separation of Customer, Provider and Backbone Control Domains Customer and PB layer two control protocols are transported through PBB network 802.1ag CCMs monitor primary, backup tunnels	Sophisticated management system to provision core tunnels

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 within 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 PBB-TE, to provide lower-cost of operations and enhanced resiliency.

• Part 1:
  Introduction
• Part 2:
  Customer Service Delivery and Transparency
• Part 3:
  Carrier Ethernet Transport Scalability and Resiliency
• Part 4:
  Summary