6. IEEE 802.1ah Provider Backbone Bridging (PBB)

Note:

Provider Backbone Bridging (PBB) is supported only on the 7210 SAS-T operating in the network mode.

This chapter provides information about PBB, process overview, and implementation notes.

6.1. IEEE 802.1ah PBB overview

IEEE 802.1ah draft standard (IEEE802.1ah), also known as Provider Backbone Bridges (PBB), defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs - IEEE802.1ad QinQ networks). PBB is defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. IEEE 802.1ah employs Provider MSTP as the core control plane for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks. The 7210 SAS-T in network mode supports a native PBB Ethernet backbone deployment.

The IEEE model for PBB is organized around a B-component handling the provider backbone layer and an I-component concerned with the mapping of Customer or Provider Bridge (QinQ) domain (for example, MACs, VLANs) to the provider backbone (for example, B-MACs, B-VLANs), that is, the I-component contains the boundary between the Customer and Backbone MAC domains. PBB encapsulates customer payload in a provider backbone Ethernet header, providing for Customer MAC hiding capabilities. With PBB, 7210 SAS platforms can be used for tier-1/2 aggregation, encapsulating customer service frames in PBB, allowing the PE-rs devices deployed in the metro core to be aware of only provider MAC addresses and for metro service scaling.

7210 SAS platforms fully support only native PBB deployment. They do not support the integrated PBB VPLS model. In particular, 7210 SAS platforms do not support use of SDPs in PBB services.

6.2. PBB features

6.2.1. Integrated PBB-VPLS solution

H-VPLS introduced a service-aware device in a central core location to provide efficient replication and controlled interaction at domain boundaries. The core network facing provider edge (N-PE) devices have knowledge of all VPLS services and customer MAC addresses for local and related remote regions resulting in potential scalability issues as shown in the following figure.

Figure 75:  Large H-VPLS deployment 

In a large VPLS deployment, it is important to improve the stability of the overall solution and to speed up service delivery. These goals are achieved by reducing the load on the N-PEs and respectively minimizing the number of provisioning touches on the N-PEs.

The integrated PBB-VPLS model provides an additional PBB hierarchy in the VPLS network to address these goals, as shown in the following figure.

Figure 76:  Large PBB-VPLS Deployment 

PBB encapsulation is added at the user facing PE (U-PE) to hide the customer MAC addressing and topology from the N-PE devices. The core N-PEs need to only handle backbone MAC addressing and do not need to have visibility of each customer VPN. As a result, the integrated PBB-VPLS solution decreases the load in the N-PEs and improves the overall stability of the backbone.

In the preceding figure, 7210 devices can only be used as U-PEs supporting only native Ethernet PBB services.

6.2.2. PBB technology

IEEE 802.1ah specification encapsulates the customer or QinQ payload in a provider header as shown in the following figure.

Figure 77:  QinQ payload in provider header example 

PBB adds a regular Ethernet header where the B-DA and B-SA are the backbone destination and respectively, source MACs of the edge U-PEs. The backbone MACs (B-MACs) are used by the core N-PE devices to switch the frame through the backbone.

A special group MAC is used for the backbone destination MAC (B-DA) when handling an unknown unicast, multicast or broadcast frame. This backbone group MAC is derived from the I-service instance identifier (ISID) using the rule: a standard group OUI (01-1E-83) followed by the 24 bit ISID coded in the last three bytes of the MAC address.

The BVID (backbone VLAN ID) field is a regular DOT1Q tag and controls the size of the backbone broadcast domain.

The following ITAG (standard Ether-type value of 0x88E7) has the role of identifying the customer VPN to which the frame is addressed through the 24 bit ISID.

6.2.3. PBB mapping to existing VPLS configurations

The IEEE model for PBB is organized around a B-component handling the provider backbone layer and an I-component concerned with the mapping of the customer/provider bridge (QinQ) domain (MACs, VLANs) to the provider backbone (B-MACs, B-VLANs). For example, the I-component contains the boundary between the customer and backbone MAC domains.

The Nokia implementation is extending the IEEE model for PBB to allow support for MPLS pseudowires using a chain of two VPLS context linked together as shown in the following figure.

7210 SAS does not support MPLS pseudowires in a PBB B-component and PBB I-component.

Figure 78:  PBB mapping to VPLS constructs 
Note:

I-PW and B-PW are not supported on 7210 SAS platforms.

A VPLS context is used to provide the backbone switching component. The white circle marked B, referred to as backbone-VPLS (B-VPLS) operates on backbone MAC addresses providing a core multipoint infrastructure that may be used for one or multiple customer VPNs. The Nokia B-VPLS implementation allows the use of native PBB infrastructures.

Note:

7210 SAS implementation allows the use of only native PBB over Ethernet infrastructures.

Another VPLS context (I-VPLS) can be used to provide the multipoint I-component functionality emulating the ELAN service (refer to the triangle marked “I” in the preceding figure). Similar to B-VPLS, I-VPLS inherits from the regular VPLS and native Ethernet (SAPs) hand-offs accommodating this way different types of access: for example, direct customer link, QinQ or H-VPLS.

To support PBB ELINE (point-to-point service), the use of an Epipe as I-component is allowed. All Ethernet SAPs supported by a regular Epipe are also supported in the PBB Epipe.

6.2.4. SAP support

This section contains information about the following topics:

  1. PBB B-VPLS
  2. PBB I-VPLS

6.2.4.1. PBB B-VPLS

  1. SAPs
    1. Ethernet dot1q is supported - this is applicable to most PBB use cases, for example, one backbone VLAN ID used for native Ethernet tunneling
    2. Ethernet null is supported - this is supported for a direct connection between PBB PEs, for example, no BVID is required
    3. Default SAP types are blocked in the CLI for the B-VPLS SAP.
  2. The following rules apply to the SAP processing of PBB frames:
    1. For “transit frames” (not destined to a local BMAC), there is no need to process the ITAG component of the PBB Frames. Regular Ethernet SAP processing is applied to the backbone header (BMACs and BVID).
    2. If a local I-VPLS instance is associated with the B-VPLS, “local frames” originated/terminated on local I-VPLSes are PBB encapsulated/de-encapsulated using the pbb-etype = 0x88e7.

6.2.4.2. PBB I-VPLS

  1. Port Level
    1. All existing Ethernet encapsulation types are supported (for example, null, dot1q, qinq).
  2. SAPs
    1. The I-VPLS SAPs can coexist on the same port with SAPs for other business services, for example, VLL, VPLS SAPs.
    2. All existing Ethernet encapsulation are supported: null, dot1q, qinq.

Existing SAP processing rules still apply for the I-VPLS case; the SAP encapsulation definition on Ethernet ingress ports defines which VLAN tags are used to determine the service that the packet belongs to:

  1. null encap defined on ingress
    Any VLAN tags are ignored and the packet goes to a default service for the SAP.
  2. dot1q encap defined on ingress
    Only first VLAN tag is considered.
  3. QinQ encap defined on ingress
    Both VLAN tags are considered; wildcard support for the inner VLAN tag.
  4. For dot1q/qinq encapsulations, traffic encapsulated with VLAN tags for which there is no definition is discarded.
  5. Note that any VLAN tag used for service selection on the I-SAP is stripped before the PBB encapsulation is added. Appropriate VLAN tags are added at the remote PBB PE when sending the packet out on the egress SAP.

6.2.5. PBB packet walk-through

This section describes the walk-through for a packet that traverses the B-VPLS and I-VPLS instances using the example of a unicast frame between two customer stations as shown in the following network diagram in the following figure.

Figure 79:  PBB packet walk-through 

The station with CMAC (customer MAC) X needs to send a unicast frame to CMAC Y through the PBB-VPLS network. A customer frame arriving at PBB-VPLS U-PE1 is encapsulated with the PBB header. The local I-VPLS FIB on U-PE1 is consulted to determine the destination BMAC of the egress U-PE for CMAC Y. In our example, B2 is assumed to be known as the B-DA for Y. If CMAC Y is not present in the U-PE1 forwarding database, the PBB packet is sent in the B-VPLS using the standard group MAC address for the ISID associated with the customer VPN.

Next, only the Backbone Header in green is used to switch the frame through the green B-VPLS/VPLS instances in the N-PEs. At the receiving U-PE2, the CMAC X is learned as being behind BMAC B1; then the PBB encapsulation is removed and the lookup for CMAC Y is performed.

6.2.6. PBB ELINE service

ELINE service is defined in PBB (IEEE 802.1ah) as a point-to-point service over the B-component infrastructure. The Nokia implementation provides support for PBB ELINE through the mapping of multiple Epipe services to a Backbone VPLS infrastructure.

The use of Epipe scales the ELINE services as no MAC switching, learning or replication is required to deliver the point-to-point service.

All packets ingressing the customer SAP are PBB encapsulated and unicasted through the B-VPLS “tunnel” using the backbone destination MAC of the remote PBB PE.

All the packets ingressing the B-VPLS destined for the Epipe are PBB de-encapsulated and forwarded to the customer SAP.

6.2.6.1. PBB resiliency for PBB Epipe service

The PBB Epipe service can be protected using G.8032 (the G8032 instance is created to protect the PBB B-VPLS service). For more information and for an example see Overview of G.8032 operation.

6.2.6.2. PBB resiliency for B-VPLS

The following VPLS resiliency mechanisms are also supported in PBB VPLS:

  1. Native Ethernet resiliency supported in both I-VPLS and B-VPLS contexts.
  2. Distributed LAG, MC-LAG, RSTP.
  3. MSTP in a management VPLS monitoring (B- or I-) SAPs.
  4. The G.8032 is supported for B-VPLS service. The G.8032 support is used only with PBB Epipe service from the current releases and cannot be used with PBB I-VPLS service.

6.2.7. Access multi-homing for native PBB (B-VPLS over SAP infrastructure)

The Nokia PBB implementation allows the operator to use a native Ethernet infrastructure as the PBB core. Native Ethernet tunneling can be emulated using Ethernet SAPs to interconnect the related B-VPLS instances. This kind of solution might fit certain operational environments where Ethernet services was provided in the past using QinQ solution. The drawback is that no LDP signaling is available to provide support for Access Multi-homing for Epipe (pseudowire Active/Standby status) or I-VPLS services (LDP MAC Withdraw). An alternate solution is required.

A PBB network using Native Ethernet core is shown in the following figure. MC-LAG is used to multi-home a number of edge switches running QinQ to PBB BEBs.

Figure 80:  Access dual-homing into PBB BEBs - topology view 

The interrupted line from the MC-LAG represents the standby, inactive link; the solid line is the active link. The BEBs are dual-homed to two core switches BCB1 and BCB2 using native Ethernet SAPs on the B-VPLS side. Multi-point B-VPLS with MSTP for loop avoidance can be used as the PBB core tunneling.

6.2.8. PBB QoS

The following QoS processing rules apply for PBB B-VPLS SAPs:

  1. B-VPLS SAP ingress
    1. If dot1p classification is enabled, the BTAG fields will be used by default to evaluate the internal forwarding class (fc) and discard profile if there is a BTAG field.
    2. If dot1p classification is not explicitly enabled or the packets are untagged then the default fc and profile is assigned.
  2. B-VPLS SAP egress
    1. If the access port based policy contains FC and profile to dot1p mapping, this entry is used to mark the dot1p bits in the B-TAG of the frame going out of the SAP. The I-Tag of the frame is not modified in any case.
    2. If no explicit mapping exists, the related dot1p DE bits are set to zero on both ITAG and BTAG if the frame is originated locally from an I-VPLS. If the frame is transiting the B-VPLS the ITAG stays unchanged, the BTAG is set according to the type of ingress SAP.
      1. If the ingress SAP is tagged, the values of the dot1p, DE bits are preserved in the BTAG going out on the egress SAP.
      2. If the ingress SAP is untagged, the dot1p, DE bits are set to zero in the BTAG going out on the egress SAP.
  3. I-SAP Ingress
    1. SAP ingress classification using mac-criteria or IP DSCP is supported.
  4. I-SAP Egress
    1. Access port based marking is supported for I-SAPs (dot1q and QinQ SAPs).

6.2.9. PBB ACL support

Filter policies are supported for ingress and egress of PBB I-SAP in both PBB Epipe and PBB VPLS service.

Only MAC criteria Filter policies is available for use with PBB B-SAPs on ingress with the following functionality:

  1. For PBB B-VPLS B-SAPs, the MAC filter matches the outer MAC header fields (that is, B-DA, B-SA, B-Tag) for traffic received on a B-SAP and forwarded to another B-SAP in the system.
  2. For PBB B-VPLS B-SAPs, the MAC filter matches the inner MAC header fields (that is, the customer MAC DA, SA and VLAN tags) for traffic received on a B-SAP and forwarded out of an I-SAP in the system.

Only MAC criteria filter policies is available for use with PBB B-SAPs on egress. This filter policy only matches the BCB traffic. BEB traffic (that is, PBB originated traffic) cannot be matched using the egress filter policy attached to PBB B-SAP.

6.2.10. Configuration guidelines

Listed as follows are the configuration guidelines for a PBB service:

  1. PBB services are supported only on 7210 SAS devices configured in network mode.
  2. A PBB service instance (identified by the ISID) cannot be used to encapsulate customer payloads with additional VLAN tags, if that service instance is being used to transport frames received on a QinQ access SAP. If a particular service instance is in use by a QinQ access SAP, then the system drops the packets that are received with additional tags on all the SAPs (NULL or Dot1q) using the same instance. Packets received with one or more tags on a NULL SAP, more than one tag on a Dot1q SAP, and more than two tags on a QinQ SAP are classified as packets with additional VLAN tags.
  3. Service MTU is not available for use.
  4. Port-based SHG is available for use with I-VPLS and B-VPLS service. Service based SHG is not available for use in an I-VPLS and a B-VPLS service.
  5. The system uses the internal loopback to flood/replicate BUM traffic received on the B-SAP, to create an additional copy for processing in the I-VPLS context. The system also uses the internal loopback to for egress port mirroring.
    The user needs to ensure that aggregate amount of mirrored traffic in the system and the BUM traffic received on a B-SAP does not exceed the available internal loopback bandwidth. Ingress meters can be used to limit the amount of BUM received and processed from a B-SAP and user can limit the number of ports setup for port egress mirroring to control the maximum amount of traffic that needs to be circulated for two pass processing using the internal loopback. NOTE: If only PBB Epipe is used (no I-VPLS service is configured for use), then egress port mirroring can be enabled without affecting PBB traffic, since PBB Epipe traffic does not use the two-pass approach.
  6. Multiple B-SAPs on the same port cannot be part of the same B-VPLS service. Two B-SAPs on the same port need to be configured in two different services.
  7. Processing rules for packets received with multiple B-tags on a SAP:
    1. If the B-Tag header has two tags, the packet is processed and forwarded appropriately and sent out of an I-SID service or another B-VPLS B-SAP.
    2. If the node is acting as a pure BCB (with no ISID/service termination), then the packets are flooded and switched appropriately and if the node is acting as a BCB + BEB, then the packets are flooded and switched appropriately on the B-SAPs, but they will not switched or flooded to a I-SAPs (both VPLS and Epipe I-SAPs).
  8. PBB I-tag etype is not configurable, it is set to 0x88e7.
  9. PBB B-tag etype is not configurable; it is set to 0x8100.
  10. PBB packets received from a destination MAC address other than the one configured in the Epipe service is not accepted by 7210 devices.
  11. In the current release, PBB packets with UCA bit set are dropped.
  12. Aging of MAC addresses learned in the B-domain - As long as a Customer MAC (C-MAC) or an Epipe service is associated with an B-SA/B-MAC, do not age out the B-SA. When the last customer MAC ages out or the last Epipe service using the particular B-SA MAC is removed, remove the corresponding B-SA entry. This means that as long as an Epipe service is associated with a particular PBB destination MAC address, the corresponding B-MAC will not age out and will occupy an entry in the Layer 2 learning table. Note, that if only I-VPLS is in use, then aging out of C-MAC will automatically trigger aging out B-MAC, when the last C-MAC associated with the B-MAC is aged out.

6.2.11. Configuration guidelines for the 7210 SAS-T

The following configuration guidelines are specific to the 7210 SAS-T operating in the network mode.

When “discard-unknown” is enabled on a B-VPLS, the following behavior can be observed:

  1. Unknown unicast (B-DA) packets arriving on a B-SAP are dropped.
  2. Unknown unicast (C-DA) packets arriving on a B-SAP are processed in the I-VPLS, if the B-DA is not unknown unicast.
  3. Unknown unicast (C-DA) packets arriving on an I-SAP are not dropped and are flooded in the B-VPLS, because B-DA is equal to the “Group Mcast MAC” and is a known value
  4. Port based SHG is available for use with both I-VPLS and B-VPLS service. Service based SHG is not available in both.

6.3. Configuration examples

Use the CLI syntax displayed to configure PBB.

6.3.1. PBB ELAN and ELINE

Use the following syntax to bring up PBB B-VPLS - common to both ELAN and ELINE services.

CLI Syntax:
config>service# vpls 200 customer 1 b-vpls create
description “This is a B-VPLS.”
sap 3/1/3:33 create
description “B-VPLS SAP”

Use the following syntax to bring up PBB ELAN.

CLI Syntax:
config>service# vpls 2000 customer 6 i-vpls create
description “This is an I-VPLS.”
sap 4/1/3:20 create
description “I-VPLS SAP”
backbone-vpls 200

Use the following syntax to bring up PBB ELINE.

CLI Syntax:
config>service# epipe 1000 customer 10 create pbb-epipe
description “This is an Epipe.”
sap 4/1/3:20 create
description “Epipe SAP”
pbb-tunnel 200 backbone-dest-mac 00-01-10-1E-C6-67 isid 752

6.3.2. MC-LAG multi-homing for native PBB

This section describes a configuration example for BEB C configuration with the following assumptions:

  1. BEB C and BEB D are MC-LAG peers
  2. B-VPLS 100 on BEB C and BEB D
  3. VPLS 1000 on BEB C and BEB D
  4. MC-LAG 1 on BEB C and BEB D
CLI Syntax:
service pbb
source-bmac ab-ac-ad-ef-00-00
port 1/1/1
ethernet
encap-type qinq
lag 1
port 1/1/1 priority 20
lacp active administrative-key 32768
redundancy
multi-chassis
peer 1.1.1.3 create
source-address 10.1.1.1
mc-lag
lag 1 lacp-key 1 system-id 00:00:00:01:01:01 system-priority 100
source-bmac-lsb use-lacp-key
service vpls 100 bvpls
sap 2/2/2:100 // bvid 100
mac-notification
no shutdown
service vpls 101 bvpls
sap 2/2/2:101 // bvid 101
mac-notification
no shutdown
// no per BVPLS source-bmac configuration, the chassis one (ab-ac-ad-ef-00-00) is used
service vpls 1000 ivpls
backbone-vpls 100
sap lag-1:1000 //automatically associates the SAP with ab-ac-ad-ef-00-01 (first 36 bits from BVPLS 100 sbmac+16bit source-bmac-lsb)
service vpls 1001 ivpls
backbone-vpls 101
sap lag-1:1001 //automatically associates the SAP with ab-ac-ad-ef-00-01(first 36 bits from BVPLS 101 sbmac+16bit source-bmac-lsb)