Ethernet Provider Backbone Bridge/Transport (PBB and PBT)

Even MPLS is being challenged. As carriers move to a simplified and more cost-effective technology stack, the prospects of carrying IP within Ethernet directly over the OTN seem increasingly attractive. Traditional Ethernet has scaling and management problems, because its forwarding model depends on Ethernet switches flooding outbound network links with Ethernet frames where the destination is not known, and then learning which exit port to use in future by noting which port the reply eventually arrives at. For this to work, there has to be a unique path between any two points on the network, which is guaranteed by Ethernet’s spanning tree protocol. This turns off network links between Ethernet switches until a minimal covering tree remains, but the procedure has a number of problems including inefficient use of network resources and long recovery times in the event of link or node failure (a new tree has to be recomputed and established).

However, using Provider Backbone Transport, a subrange of VLAN tags is reserved for carrier forwarding purposes, the chosen tags (+ destination addresses) functioning somewhat similarly to MPLS labels. This forwarding information is provisioned into the carrier Ethernet switches by the central network management function, or by GMPLS, to create forwarding virtual circuits (and optionally failover restoration paths) across the carrier network. Unlike the situation with MPLS labels, however, the PBT combination of destination MAC header and VLAN tag is globally unique and identical across network switching elements. This offers significant advantages over MPLS in fault finding and tracing.

Carrier Ethernet is seeing a number of innovations that increase its capabilities, including:

§  MAC-in-MAC—the provision of a separate carrier forwarding address field, pre-pended to the enterprise customer header (defined in 802.1ah, and also called “Provider Backbone Bridge”)

§  Q-in-Q—used to create a hierarchy of VLAN tags allowing carriers to distinguish between customers (defined in 802.1ad, and also called “VLAN stacking”).

With these, Ethernet is now beginning to match MPLS accomplishments, both in traffic engineering and in the provision of customer VPNs. The battle to come will prove interesting.

GMPLS

Following the success of MPLS in the provision, configuration and management of virtual circuits for IP networks, some thought was given as to whether MPLS might be used to handle other sorts of virtual circuits, not as a transport mechanism, but as a signaling and control plane for:

§  Layer-2 virtual circuits for Frame Relay,

§  TDM virtual paths for SONET and SDH,

§  Wavelengths in an optical transport network (OTN),

§  Fiber segments linked via spatial physical port switches.

Thus was born Generalized MPLS (GMPLS), which applies the MPLS control plane (with extensions) to these other layers—the focus is typically on SONET/ SDH and optical (wavelength) networks. Cross-connects and Add-Drop Multiplexers in these networks need to exchange GMPLS protocol messages. This is not necessarily strange—all these devices today run element managers or SNMP agents that communicate via a management IP layer. In the TDM world, MPLS label allocation/de-allocation is identified with time-slot allocation; in the optical world it is equivalent to wavelength allocation.

In fact, GMPLS has had a mixed reception in the world’s carriers. Optical and transmission engineers don’t necessarily believe that the IP guys know best when it comes to controlling their networks. There is a history of virtual path management in SONET/SDH networks and optical channel management for OTNs being organized through the network management systems. With increasing element intelligence and more powerful management tools, it is widely felt that the management plane is adequate, and that replicating its functions in a new signaling plane is not required. Of course, opinions differ.