G.8032 Ethernet ring protection switching

R-APS messages that carry the G.8032 protocol are sent on dedicated protocol VLAN called the Ethernet Ring Protection (ERP) instance. In a revertive case, G.8032 Protocol ensures that one Ring Protection Link (RPL) owner blocks the RPL link. R-APS messages are periodically sent around the ring to inform other nodes in the Ring about the blocked port in the RPL owner node. In non-revertive mode any link may be the RPL. Y.1731 Ethernet OAM CC is the basis of the RAPs messages. Y.1731 CC messages are typically used by nodes in the ring to monitor the health of each link in the ring in both directions. However CC messages are not mandatory. Other link layer mechanisms could be considered – for example Loss Of Signal (LOS) when the nodes are directly connected.

Initially each Ring Node blocks one of its links and notifies other nodes in the ring about the blocked link. When a ring node in the ring learns that another link is blocked, the node unblocks its blocked link possibly causing FDB flush in all links of the ring for the affected service VLANs, controlled by the ring control instance. This procedure results in unblocking all links but the one link and the ring normal (or idle) state is reached. In revertive mode the RPL link is the link that is blocked when all links are operable after the revert time. In non-revertive mode the RPL link is no different than other ring links. Revertive mode offers predictability particularly when there are multiple ring instances and the operator can control which links are blocked on the different instances. Each time there is a topology change that affects reachability, the nodes may flush the FDB and MAC learning takes place for the affected service VLANs, allowing forwarding of packets to continue. 0-1 G.8032 ring in the initial state depicts this operational state:

When a ring failure occurs, a node or nodes detecting the failure (enabled by Y.1731 OAM CC monitoring) send R-APS message in both directions. This allows the nodes at both ends of the failed link to block forwarding to the failed link preventing it from becoming active. In revertive mode, the RPL Owner then unblocks the previously blocked RPL and triggers FDB flush for all nodes for the affected service instances. The ring is now in protecting state and full ring connectivity is restored. MAC learning takes place to allow Layer 2 packet forwarding on a ring. 0-1 G.8032 ring in the protecting state depicts the failed link scenario.

When the failed link recovers, the nodes that blocked the link again send the R-APS messages indicating no failure this time. This in turn triggers RPL owner to block the RPL link and indicate the blocked RPL link the ring in R-APS message, which when received by the nodes at the recovered link cause them to unblock that link and restore connectivity (again all nodes in the ring perform FDB flush and MAC learning takes place). The ring is back in the normal (or idle) state.

Within each path, Y.1731 Maintenance Entity Group (MEG) Endpoints (MEPs) are used to exchange R-APS specific information (specifically to co-ordinate switchovers) as well as optionally fast Continuity Check Messages (CCM) providing an inherent fault detection mechanism as part of the protocol. Failure detection of a ring path by one of the mechanisms triggers to activate the protection links. Upon failure, reconvergence times are a dependent on the failure detection mechanisms. In the case of Y.1731, the CCM transmit interval determines the response time. The router supports message timers as low as 10 milliseconds (also 100 ms) so the restoration times are comparable to SONET/SDH. Alternatively, 802.3ah (Ethernet in the First Mile) or simple Loss of Signal can act as a trigger for a protection switch where appropriate. In case of direct connectivity between the nodes, there is no need to use Ethernet CC messaging for liveliness detection.

Revertive and non-revertive behaviors are supported. The Ring protection link (RPL) is configured and Ethernet-rings can be configured to revert to the RPL upon recovery.

G.8032 supports multiple data channels (VIDs) or instances per ring control instance (R-APS tag). G.8032 also supports multiple control instances such that each instance can support RPLs on different links providing for a load balancing capability. However, after services have been assigned to one instance the rest of the services that need to be interconnected to those services must be on the same instance. In other words each data instance is a separate data VLAN on the same physical topology. When there is any one link failure or any one node failure in the ring, G.8032 protocols are capable of restoring traffic between all remaining nodes in these data instances.

Ethernet R-APS can be configured on any port configured for access mode using dot1q, q-in-q encapsulation enabling support for Ethernet R-APS protected services on the service edge toward the customer site, or within the Ethernet backbone. ELINE services (using PBB Epipes with the B-VPLS configured with Ethernet rings), E-LAN services, and E-Tree data services can be afforded Ethernet R-APS protection and, although the Ethernet ring providing the protection uses a ring for protection the services are configured independent of the Ring properties. The intention of this is to cause minimum disruption to the service during Ethernet R-APS failure detection and recovery.

In the implementation, the Ethernet Ring is built from a VPLS service on each node with VPLS SAPs that provides Ring path with SAPs. As a result, most of the VPLS SAP features are available on Ethernet rings if needed. This results in a fairly feature rich ring service.

The control tag defined under each Ethernet-ring is used for encapsulating and forwarding the CCMs and the G.8032 messages used for the protection function. If a failure of a link or node affects an active Ethernet ring segment, the services fail to receive the CCMs exchanged on that segment or receive a fault indication from the Link Layer OAM module. CCMs are optional but MEPs are always configured to provide G.8032 control. Note that the forwarding of CCMs and G.8032 R-APS messages continues in the control VPLS even if the service or its SAPs are administratively shut down. The Ethernet ring instance can be shut down if it is needed to stop the operation of the ring on a node.

For fault detection using CCMs three CC messages plus a configurable hold-off timer must be missed for a fault to be declared on the associated path. The latter mechanism is required to accommodate the existence of additional, 50 ms resiliency mechanism in the optical layer. After it receives the fault indication, the protection module declares the associated ring link down and the G.8032 state machine sends the appropriate messages to open the RPL and flush the learned addresses.

Flushing is triggered by the G.8032 state machine and the router implementation allows flooding of traffic during the flushing interval to expedite traffic recovery.

0-3 ring example illustrates a resilient Ring Service. In the example a PBB ring (solid line) using VID 500 carries 2 service VLANs on I-SID 1000 and 1001 for Service VIDs (Dot1q 100 and QinQ 400.1 respectively.) The RPL for the PBB ring is between A and B where B is the RPL owner. Also illustrated is a QinQ service on the (dotted line) ring that uses Dot1q VID 600 for the ring to connect service VLAN 100.50. The two rings have RPLs on different nodes which allow a form of load balancing. The example serves to illustrate that service encapsulations and ring encapsulation can be mixed in various combinations. Also note that neither of the rings is closed loop. A ring can restore connectivity when any one node or link fails to all remaining nodes within the 50 ms transfer time (signaling time after detection).

[ex:/configure eth-ring 1]
A:admin@node-B# info
    admin-state enable
    description "Ring PBB BLUE on Node B"
    guard-time 5
    revert-time 100
    rpl-node owner
    ccm-hold-time {
        down 100
        up 200
    }
    path "a" {
        # comment: allows protect switching 
        # comment: in absence of "tools perform eth-ring force" 
        admin-state enable 
        description "To A ring link"
        port-and-raps-tag 6/6/1:100
        rpl-end true
        eth-cfm {
            mep 
                description "Control MEP"
                ma-admin-name "association-1" 
                md-admin-name "domain-1" 
                mep-id 1 
        }
    }
    path "b" {
        admin-state enable
        description "To D ring link"
        port-and-raps-tag 6/6/2
        rpl-end true
        eth-cfm {
            mep 
                ma-admin-name "association-1" 
                md-admin-name "domain-1" 
                mep-id 1
        }
    }

A:node-2>config>eth-ring# info
----------------------------------------------
    description  "Ring PBB BLUE on Node B"
    revert-time 100
    guard-time 5
    ccm-hold-time down 100 up 200
    rpl-node owner
    path a  6/6/1 raps-tag 100 // CC Tag 100
        description "To A ring link"
        rpl-end
        eth-cfm
            mep 1 domain 1 association 1
                  // Control MEP
            no shutdown
            exit
        exit
        no shutdown // allows protect switching 
                      // in absence of "tools perform eth-ring force"
    exit
    path b  6/6/2 raps-tag 100  
    description "to D ring link"
        eth-cfm
            mep 1 domain 1 association 1
            no shutdown
            exit
        exit
        no shutdown
    no shutdown
    exit

[ex:/configure service]
A:admin@node-2# info
    vpls "10" {
        admin-state enable
        description "Ring Control VID 100 APS SAPS"
        customer "1"
        sap 6/6/1:100 {
            eth-ring 1 
            description "TAG for the Control Path a"
        }
        sap 6/6/2:100 {
            eth-ring 1 
            description "TAG for the Control Path b"
        }
    }
    vpls "40" {
        admin-state enable
        description "Ethernet Ring 1 VID 500"
        customer "1"
        pbb-type b-vpls
        sap 6/6/1:500 {
            eth-ring 1
            description "TAG for the Data Channel Path a"
        }
        sap 6/6/2:500 {
            eth-ring 1
            description "TAG for the Data Channel Path b"
        }
    }
    vpls "1000" {
        admin-state enable
        description "CPE traffic"
        pbb-type i-vpls
        pbb {
            backbone-vpls "40" {
                isid 1000
            }
        sap 3/1/1:100 {
            description "CPE SAP"
        }
    } 
    vpls "1001" {
        admin-state enable
        description "CPE traffic"
        pbb-type i-vpls
        pbb {
            backbone-vpls "40" {
                isid 1001
            }
        sap 3/1/2:400.1 {
            description "CPE SAP"
        }
    }

A:node-2>config>service# info
----------------------------------------------
        ....
        vpls 10 customer 1 create 
            no shutdown
            description "Ring Control VID 100 APS SAPS" 
            sap 6/6/1:100 eth-ring 1 create 
                             // TAG for the Control Path a
            exit
            sap 6/6/2:100 eth-ring 1 create 
                             // TAG for the Control Path b
            exit
        exit
        vpls 40 customer 1 b-vpls create //Data Channel on Ring
            no shutdown
            description "Ethernet Ring 1 VID 500" 
            sap 6/6/1:500 eth-ring 1 create 
                              // TAG for the Data Channel Path a
            exit
            sap 6/6/2:500 eth-ring 1 create 
                              // TAG for the Data Channel Path b
            exit
        exit
        vpls 1000 i-vpls // CPE traffic 
            no shutdown
            sap 3/1/1:100 create // CPE SAP 
            pbb
                backbone-vpls 40 isid 1000 
            exit 
        exit
        vpls 1001 i-vpls // CPE traffic 
            no shutdown
            sap 3/1/2:400.1 create   // CPE SAP 
            pbb
                backbone-vpls 40 isid 1001 
            exit
        exit
        ....

Ethernet Sub-Rings offer a dual redundant way to interconnect rings. The router supports Sub-Rings connected to major rings and a sub-ring connected to a VPLS (LDP based) for access rings support in VPLS networks. 0-4 G.8032 sub-ring illustrates a Major Ring and Sub-Ring scenario. In this scenario, any link can fail in either ring (ERP1 or ERP2) and each ring is protected. Furthermore, the sub ring (ERP2) relies on the major Ring (ERP1) as part of its protection for the traffic from C and D. The nodes C and D are configured as inter connection nodes.

Sub-Rings and Major Rings run similar state machines for the ring logic, however there are some differences. When Sub-Rings protect a link, the flush messages are propagated to the major ring. (A special configuration allows control of this option on the router.) When major rings change topology, the flush is propagated around the major ring and does not continue to any sub-rings. The reason for this is that Major Rings are completely connected but Sub-Rings are dependent on another ring or network for full connectivity. The topology changes need to be propagated to the other ring or network usually. Sub-Rings offer the same capabilities as major rings in terms of control and data so that all link resource may be used.

Ethernet CFM is enabled by configuring MEPs on each individual path under an Ethernet ring. Only down MEPs can be configured on each path and optionally, CCM sessions can be enabled to monitor the liveliness of the path using interval of 10 or 100 msec. Different CCM intervals can be supported on the path a and path b in an Ethernet ring. CFM is optional if hardware supports Loss of Signal (LOS) for example, which is controlled by configuring the following command:

• MD-CLI

  configure eth-ring path eth-cfm mep ccm false

• classic CLI

  configure eth-tunnel path eth-cfm mep no ccm-enable

Up MEPs on service SAPs which multicast into the service and monitor the active path may be used to monitor services.

When Ethernet ring is configured on two ports located on different cards, the SAP queues and virtual schedulers are created with the actual configuration on each card.

Ethernet ring CC messages transmitted over the SAP queues using the default egress QoS policy use NC (network class) as a forwarding class. If user traffic is assigned to the NC forwarding class, it competes for the same bandwidth resources with the Ethernet CCMs. As CCM loss could lead to unnecessary switching of the Ethernet ring, congestion of the queues associated with the NC traffic should be avoided. You must configure different QoS policies to avoid congestion for the CCM forwarding class by controlling the amount of traffic assigned into the corresponding queue.

Details of the Ethernet ring applicability in the services solution can be found in the respective sections of the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide.

The Ethernet rings are supported Layer 2 service, VPLS, I-VPLS, R-VPLS, and B-VPLS instances. The following considerations apply:

• Only ports in access mode can be configured as Ethernet-ring paths. The ring ports can be located on the same or different media adapter cards.

• Dot1q and QinQ ports are supported as Ethernet-ring path members.

• A mix of regular and multiple Ethernet-ring SAPs and pseudowires can be configured in the same services.