Page 56 7750 SR OS Services Guide
It is important that the configuration for the various services does not change when a new Ethernet
tunneling type is introduced on the backbone side. This is achieved by using a SAP to map the eth-
tunnel object into service instance.
The member port and control tag defined under each eth-tunnel path are then used for
encapsulating and forwarding the CCMs and the G.8031 PDUs used for protection function, the
latter frames being sent only on the secondary path. The configuration of the active path is also
used to instantiate the SAP object in the forwarding plane.
If a failure of a link or node affects the primary eth-tunnel path, the services will fail to receive the
CC messages exchanged on that path or will receive a fault indication from the link layer OAM
module.
For fault detection using CCMs, a number of 3.5 CC intervals 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 received the fault indication, the protection module will declare the associated path down, then
sends an indication to the remote protection module to switch the transmit direction to the backup
path.
In order to address unidirectional failures, the RDI bit will be set in CC messages transmitted in
the reverse direction upon detection of failure at the receiving service. The same applies for link
layer OAM. Until the protection switch indication arrives from the remote node, the local node
will continue to receive frames from both primary and backup paths to avoid the loss of in-flight
packets.
In case of direct connectivity between the nodes, there is no need to use Ethernet CCM messaging
for liveliness detection. Link level detection mechanisms like LoS (Loss of Signal) or IEEE
802.3ah link layer OAM can be used to detect link or nodal failure. This can be achieved by not
provisioning a MEP on the primary path.
Using the Ethernet Tunnel as a building block for Ethernet APS protection it is possible to provide
different protection schemes with different fate-dependency; or indeed to mix protected and non-
protected services on the same physical port.
The simplest model is the fate-independent model where each Ethernet Tunnel supports its own
protection using Y.1731 CCMs for example. In this case a single VLAN Tag may be used for
control and data traffic. In cases where Ethernet Tunnels can be guaranteed to share a common
physical path, it is possible to implement a fate-sharing model. This approach provides the
advantage of reducing the amount of Ethernet OAM signaling because only one control tag
determines the fate of many user tags.
To Next Page
Loading...
