Engineering:Provider Backbone Bridge Traffic Engineering

From HandWiki
Short description: Standard that adapts Ethernet technology to carrier class transport networks

Provider Backbone Bridge Traffic Engineering (PBB-TE) is a computer networking technology specified in IEEE 802.1Qay, an amendment to the IEEE 802.1Q standard.[1] PBB-TE adapts Ethernet to carrier class transport networks. It is based on the layered VLAN tags and MAC-in-MAC encapsulation defined in IEEE 802.1ah (Provider Backbone Bridges (PBB)), but it differs from PBB in eliminating flooding, dynamically created forwarding tables, and spanning tree protocols. Compared to PBB and its predecessors, PBB-TE behaves more predictably and its behavior can be more easily controlled by the network operator, at the expense of requiring up-front connection configuration at each bridge along a forwarding path. PBB-TE Operations, Administration, and Management (OAM) is usually based on IEEE 802.1ag. It was initially based on Nortel's Provider Backbone Transport (PBT).

PBB-TE's connection-oriented features and behaviors, as well as its OAM approach, are inspired by SDH/SONET. PBB-TE can also provide path protection levels similar to the UPSR (Unidirectional Path Switched Ring) protection in SDH/SONET networks.

Principle of operation

The IEEE 802.1Qay PBB-TE standard extends the functionality of IEEE 802.1ah Provider Backbone Bridges, adding a connection-oriented mode using point-to-point trunks that deliver resiliency and configurable performance levels.[2]

A service is identified by an I-SID (Backbone Service Instance Identifier) and each service is associated with a PBB-TE trunk. Each PBB-TE trunk is identified by a triplet of B-SA, B-DA and B-VID. The B-SA and B-DA identify the source and destination bridges, respectively, that are the endpoints of the trunk. The B-VID is a backbone VLAN identifier that is used to distinguish different trunks to the same destination. The management system configures the PBB-TE trunks on all the edge and core bridges by creating static forwarding database entries; the management system is responsible for ensuring that there are no forwarding loops.

The backbone edge bridges map frames to and from an I-SID and perform the MAC header encapsulation and decapsulation functions. The core bridges act as transit nodes. The packets are forwarded based on outer VLAN ID (B-VID) and Destination MAC address (B-DA).

Forwarding is based on the static forwarding database (FDB) entries; dynamic MAC learning is not used. Any incoming broadcast or multicast frames are either dropped or encapsulated as unicast within the trunk. All Destination Lookup Failure packets are dropped rather than flooded. By eliminating any broadcasting or flooding, and by using only the loop-free forwarding paths configured by management, there is no longer any need to use a spanning tree protocol.

Path protection is provided by configuring one work and one protect B-VID for each backbone service instance. In case of work path failure (as indicated by loss of 802.1ag continuity check messages, CCMs) the source bridge swaps the B-VID value to redirect the traffic onto the preconfigured protection path within 50 ms.

PBB-TE equipment leverages economies of scale inherent in Ethernet, promising solutions that are 30% to 40% cheaper than T-MPLS networks with identical features and capabilities,[3] giving PBB-TE a better overall return on investment.[4]

Key features

  • Traffic and resiliency
  • Secure
  • Service scalability
  • Operational simplicity
  • Ethernet tunneling with full MPLS interoperability
  • Service and transport layer independence—the services inside the tunnel could be Ethernet, IP, MPLS pseudo-wires, or VPLS.

History

Provider Backbone Bridge Traffic Engineering was originally developed in 2006 as a Nortel specific protocol named Provider Backbone Transport (PBT). The company championed the technology and brought it to the IEEE 802.1 committee where it was renamed to PBB-TE and a working group, P802.1Qay, was chartered on May 7, 2007.[5] 802.1Qay was in sponsor ballot from January 2009[6] to April 2009.[7] It was ratified by the IEEE Standards Association on June 18, 2009.[1] It was published in August 2009.[8]

See also

References

External links