Ethernet G.8031 tunnels

Overview

The IEEE 802.1ah Provider Backbone Bridging specification employs Provider MSTP to ensure loop avoidance in a resilient native Ethernet core. With P-MSTP, failover times depend largely on the size of the network and the connectivity model used in the network. MPLS tunnels provide core scaling and fast failover times using MPLS FRR. A service based on native Ethernet backbone achieves the same fast failover times as MPLS FRR.

Core Ethernet tunnels compliant with the ITU-T G.8031 specification achieve 50 ms resiliency for backbone failures. A configured Ethernet tunnel can be selected when configuring an L2 access interface on a B-VPLS.

The NFM-P uses two different approaches to configure Ethernet tunnels in the network.

• Approach 1 (recommended):

  The NFM-P provisions an end-to-end Ethernet G.8031 tunnel which reduces configuration errors and aids the diagnosis of any problem in the tunnel. The NFM-P automatically configures the Ethernet tunnel endpoint and path endpoint on each of the participating NEs. See To configure an Ethernet tunnel for more information.

  The Ethernet tunnel and path are network wide objects that provide the following benefits:

  • the Ethernet tunnel provides the aggregated State of the Tunnel and reports any inconsistency in the configuration of the endpoints or paths

  • faster and easier provisioning that allows you to configure common properties such as holdTime and revertTime at the network level and then apply them to each tunnel endpoint

  • The NFM-P accelerates the creation of global and local MAs, and MEPs by using a continuity check

• Approach 2:

  The NFM-P provides the ability to provision Ethernet tunnel endpoints and path endpoints separately on each NE. See To configure an Ethernet tunnel endpoint for more information on creating Ethernet endpoints. If Ethernet tunnel endpoints are created this way (or discovered from the NE) you can associate them to a network-wide Ethernet tunnel and path, but this must be done manually.

Note: Network-wide Ethernet tunnels and paths are not automatically discovered from the NE.

Transit services

You can use the NFM-P to configure and manage transit services on supporting 7210 SAS and 7705 SAR NEs.

Transit services use default QinQ SAPs (which are also called transit SAPs) to forward traffic for data services. Transit SAPs (notation *.*) receive and forward frames with any encapsulation value, and eliminate the need for customer VLAN-specific SAPs on virtual switching instances for service sites with transit SAPs. Data services use transit services for transparent forwarding, which can reduce configuration time and move traffic more efficiently.

Although transit services function as service tunnels, they are managed in the same way as other VPLS and VLL services in the NFM-P: they have service IDs, appear as services in navigation trees, contain sites and interfaces, and appear on service topology maps. Properties forms for transit services share the same tab structure and functionality as forms for other services in the NFM-P. You can use the Transported Services tab to view and access the data services that use the transit service (you must first discover the services). You can also view and access a transit service that is associated with a VLAN Uplink, using the Transit Services tab on the VLAN Uplink form. You can access VLAN Uplink forms from the service topology map. See Service topology maps in Topology map types for more information.

Any alarms that are generated on a transit service are propagated to the data service that uses the transit service, and appear as alarms on related objects on the Faults tab of the data service properties form.

You can create transit services automatically for VPLS G.8032 Ethernet rings using the Create Transit Services function. See To configure a transit service on an Ethernet ring for more information. Transit services created by this method are new services, and contain only transit SAPs. The NFM-P creates linked transit SAPs on all sites on the ring.

For non-G.8032 VPLS and VLL services, manually-configured transit SAPs on the services are used as a transit service by the NFM-P when the transit SAPs are connected by a physical link.

When you use the Connect to Ethernet Ring function to connect a data service to an Ethernet ring configured with a transit service, the NFM-P creates VLAN-specific SAPs for the data service only on the ring site for which Connect to Ethernet Ring is selected. The transit SAPs on the ring transparently forward traffic through other sites on the service.

You can combine transit services using the composite service functionality in the NFM-P. Composite services are created automatically when Auto Discover Composite Services is enabled in System Preferences, or manually using the Rediscover Composite Services function. See Chapter 85, Composite service management for more information about composite services.

For more information about transit services and transit SAPs (default QinQ SAPs), including restrictions, see the appropriate NE documentation.