Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Understanding Provider Backbone Bridging on MX Series Routers

Provider backbone bridging (PBB) extends Layer 2 Ethernet switching to provide enhanced scalability, quality of service (QoS) features, and carrier-class reliability. The Juniper Networks Junos OS implementation of PBB supports the IEEE 802.1ah standard.

Note: PBB is supported only on MX Series routers with Dense Port Concentrators (DPCs). PBB is not supported on MX Series routers with Modular Port Concentrators (MPCs).

How PBB Improves on Q-in-Q in Layer 2 Ethernet Switching

When provider bridges (also known as Q-in-Q) extended Layer 2 Ethernet switching to create a two-level system of customer bridges and provider bridges, the solution adequately supported the needs of enterprise networks, but fell short of service provider network requirements.

The IEEE 802.1ad standard supporting Q-in-Q provides for an additional Q-tag that splits the VLAN plane to create two separate VLAN ID (VID) fields: a customer bridge VLAN ID (C-VID) used by customers and a provider bridge VLAN ID (S-VID) used by service providers. This hierarchical layer allows a packet from a C-VID to travel through the customer VLAN, then “stacks” a tag by adding an additional 802.1q tag for the service provider to facilitate segregated travel through a service provider’s VLAN. As the packet leaves the S-VID, the extra tag is removed in the downstream direction.

Provider bridge networks (PBNs) have the following limitations:

• Limited number of service instances—PBNs can support a maximum of 4096 service instances per PBN.
• Potential scaling issue—Service provider switches supporting 802.1ad control their own bridges (S-VIDs), but are also required to learn all customer end-station MAC addresses. As a service provider supports more customers, the increased number of learned MAC addresses doesn’t scale according to needs. When the number of entries exceeds the capacity permitted in the forwarding table, the forwarding table overflows and can potentially trigger a broadcast storm in the provider network.
• No clear demarcation between customer and provider networks—Customer networks cannot be cleanly separated from provider networks. A clear demarcation point determines what services are provisioned and how fault and performance management is performed for the services provided.

PBB (also known as MAC-in-MAC) is used by service providers to resolve these problems. PBBNs have the following benefits:

• Imposes no change to the Ethernet switching process in the core bridges.
• Supports Ethernet transparent LAN (E-LAN), Ethernet private line (E-LINE), and Ethernet tree service (E-TREE) connectivity models.
• Separates Ethernet as a service from Ethernet as infrastructure.
• Provides a clear demarcation between the customer and provider domain.
• Learns customer MAC addresses only through the backbone edge bridges (BEBs).
• Supports up to 16 million service instances.
• Achieves additional PBBN scaling and interconnection using hierarchical and peer PBBN features.

PBB duplicates the MAC layer of the customer packet and keeps it separate from the provider domain, creating an infrastructure that is transparent from a customer network. BEBs append their forwarding fields (source address [B-SA], destination address [B-DA] and a backbone VID [B-VID]) with the MAC address and a service identifier (I-SID) at the border. A service provider switch only encapsulates the MAC addresses at the edge, between the customer cloud and the provider cloud on the BEB.

To solve the issue of identifying a customer service instance, a new 24-bit I-SID field is used. I-SIDs enable a PBB to support up to 16 million service instances without any impact to the forwarding fields (B-VID, B-SA, and B-DA).

How PBB Works on MX Series Routers

A provider backbone bridged network (PBBN) is composed of a set of BEBs interconnected by some or all of the S-VLANs supported by a PBN. Each BEB provides interfaces that encapsulate (or verify the encapsulation of) customer frames, thus allowing customer MAC (C-MAC) addresses and VLANs to be independent of the backbone MAC (B-MAC) addresses and VLANs administered by the PBBN operator. The backbone is segregated into broadcast domains by means of a VLAN identifier (B-VID). A new 24-bit service identifier (I-SID) is defined and used to associate a given customer MAC frame with a provider service instance (also called the service delimiter).

To configure PBB on an MX Series router, configure an I-component routing instance and a B-component routing instance. The B-component is the provider routing instance. Each B-component routing instance contains the B-VLAN bridge domains of a PBBN network that map the backbone service instance tag (I-Tag) to a B-VLAN. The I-component is the customer routing instance. The I-component contains the S-VLAN bridge domains of a PBN network that map to a backbone service instance tag (I-Tag). Each S-VLAN is uniquely mapped to a single ISID (1:1 mapping), or multiple S-VLANs can be mapped to an ISID (N:1 mapping).

Each I-component routing instance must be associated with a pip interface, and each B-component routing instance must be associated with a cbp interface. These interfaces provide a connection between the customer routing instances (PBN or PBBN I-component) and a provider routing instance (PBBN B-component).

MX Series routers support multiple PBBNs (B-components) on a single router. Each router can support up to 16 PBBNs.

The Junos OS also supports enhanced carrier-level CoS and IEEE 802.1ag connectivity fault management (CFM) for PBB.

To configure PBB, include the routing-instance instance-name statement at the [edit] hierarchy level. You must create a routing instance for both the I-component and B-component.