LCAS function configuration and application on EoS services

Hello, everyone!

I would like to share with all of you the following guide about Link Capacity Adjustment Scheme (LCAS) function configuration and application on EoS services.

The LCAS function is realized by dynamically adjusting the number of virtual containers required for service mapping based on the control information that is carried in the reserved bytes of the SDH frame structure. Through LCAS, the bandwidth requirements of various services can be met and the bandwidth utilization increases.

LCAS is applicable to only the virtually concatenated channels (VC-12, VC-3 or VC-4).

The advantages of adopting the LCAS function on the network are as follows:

LCAS dynamically adjusts (adds or deletes) the service bandwidth without affecting the availability of the existing services.

When some of the physical channels in a virtual concatenation group (VCG) fail, LCAS shields the failed channels and dynamically allocates the services of the failed channels to the normal channels in the VCG for transmission. This prevents the services from being interrupted when some of the physical channels fail. After the failed physical channels are restored, they can transmit services again.

After this brief introduction, let's start with the LCAS function configuration example. Let's imagine that we have created 3xVC12s (between 2 EFS0 boards of 2 NEs) to play with them:

We create an EPL between those 2 NEs, with a Trunk Link of 2xVC12 bandwidth (4 Mbps).

As long as we have the LCAS function activated on the internal logical ports (VCTRUNK) that belong to the EPL, we will be able to dinamically bandwidth increase or decrease (in our case add new VC12s or delete existing VC12s of the Trunk Link) without having to undo and redo the EPL, and without service interruption.

The new VC12s that we will add to the Trunk Link must be previously created as SDH trails. The VC12s that we delete from the Trunk Link are only removed from the Trunk Link, but they don't disappear, aren't deleted as SDH trails.

Enable LCAS function

We do it on the internal logical ports (VCTRUNK) of each EFS0 board that make up the EPL:

After you enable the LCAS function, an NE dynamically adjusts service bandwidth without affecting the usability of services.

Dynamic Bandwidth Decrease (delete VC12s associated with Trunk Link)

On existing networks, data services are becoming a mainstream. In this case, the networks must be more flexible. That is, when user data services or data traffic decrease, the bandwidth needs to be reduced without affecting the existing data services. LCAS can dynamically decreases bandwidths, without affecting service availability.

During dynamic bandwidth decrease, the process of the control information interaction between the source and sink ends is shown below:

When a member is removed from a VCTRUNK, the bandwidth will be reduced accordingly. The process of the control information interaction between the source and sink ends is as follows:

1) The source end decides to delete one member and clear the data that this member carries, and then sends a message to the sink end to inform the sink end of this operation.

2) After receiving the message, the sink end stops extracting the data of the deleted member.

All process management is done from Trunk Link Management:

Our Trunk Link contains the VC12s named "prueba LCAS-1" and "prueba LCAS-2". From Trunk Link Management we select the Trunk Link in the window above ("Trunk_Link-pruebas LCAS") and the VC12s associated with this Trunk Link are automatically displayed in the window below.

To delete one of the 2xVC12 that make up the Trunk Link, we select it in the window below and then we click the Delete tab.

In this case we are going to delete the VC12 named "prueba LCAS-2". When clicking Delete tab it asks us for confirmation:

Click OK.

Now our Trunk Link ("Trunk_Link-pruebas LCAS") only has a single associated VC12 ("prueba LCAS-1"):

NOTE: We have deleted the VC12 ("prueba LCAS-2") from within the Trunk Link (Trunk Link bandwidth decrease), but we haven't deleted that VC12 trail. This VC12 still exists as a SDH trail. We verify it from SDH Trail Management:

That is, from Trunk Link Management the Delete option only removes the VC12 from the Trunk Link (Trunk Link bandwidth decrease), but it doesn't delete it as a SDH trail.

Dynamic Bandwidth Increase (add new VC12s to existing Trunk Link)

On existing networks, data services are increasing. If users need new services or new functions for original services, more data bandwidths are required without existing data services affected. The LCAS function can dynamically increase bandwidths, without affecting service availability.

During dynamic bandwidth increase, the process of the control information interaction between the source and sink ends is shown below:

After a member is added into a VCTRUNK, the bandwidth is dynamically increased. The process of the control information interaction between the source and sink ends is as follows:

1) When the bandwidth is ready to increase at the source end, the source end informs the sink end of the request.

2) After receiving the request, the sink end checks whether the necessary protocols and resources at the sink end are available for adding new members at the source end.

3) After confirming that new members can be added, the sink end instructs the source end to add new members.

4) After receiving the acknowledgement from the sink end, the source end starts to add new members and then informs the sink end of the data of the added members.

5) The sink end starts to extract data of the added members.

From the Trunk Link Management window, we can only add new VC12s to the Trunk Link ("Trunk_Link-pruebas LCAS") if the VC12s are previously created as SDH trails.

We start from the previous scenario in which we have decreased the bandwidth of the Trunk Link to 2 Mbps. We have deleted from the Trunk Link the VC12 named "prueba LCAS-2 and our Trunk Link is only has a single associated VC12 ("prueba LCAS-1").

We are going to Trunk Link bandwidth increase to 6 Mbps adding 2 new VC12s that we have previously created ("prueba LCAS-2" and "prueba LCAS-3").

To do this, from Trunk Link Management we select the Trunk Link and click the Add tab:

We see how the NMS automatically offers us all the VC12s already created and availble to assign to our Trunk Link. These VC12s are named as "prueba LCAS-2" and "pruebas LCAS-3".

We select both VC12s and click OK.

We can already check how our Trunk Link has been increased to 3xVC12 (6 Mbps):

In this way we have assigned to the Trunk Link the 3xVC12 that we had previously created for our example. If we now try to increase the bandwidth of the Trunk Link with another VC12, NMS will notify us that it can't be done because there are no more VC12s availble ("No Server Trail Available"):

We will have to go to Create SDH Trail window and create a new VC12 between the EFS0 boards:

Once we have created the VC12 trail, we can increase the bandwidth of the Trunk Link with that new VC12.

To do this, again from Trunk Link Management we have to click the Add tab:

Now the VC12 that we have previously created is available ("prueba LCAS-4"). We select it and click OK.

This new VC12 is added to the Trunk Link, increasing the Trunk Link bandwidth to 8 Mbps (4xVC12):

Deletion of Failed Members

When a member link fails (in our case VC12 channel member), the LCAS function can dynamically delete the failed link, without affecting the original services.

During deletion of failed members, the process of the control information interaction between the source and sink ends is shown below:

When a member link in a VCTRUNK breaks, the member of the faulty link fails. The process of the control information interaction between the source and sink ends is as follows:

1) When any failed members are detected in the path, the sink end stops extracting the data of the failed members and informs the source end of the information about the failed members.

2) After receiving the information about the failed members, the source end stops loading data to the failed members.

Restoration of Failed Members

When a failed member link is restored (in our case VC12 channel member), the LCAS function can dynamically restore the bandwidth of this link, without affecting the original services.

During restoration of failed members, the process of the control information interaction between the source and sink ends is shown below:

When a member link in a VCTRUNK breaks, the member of the faulty link fails. When the member is restored, the member link in the VCTRUNK is restored to normal. The process of the control information interaction between the source and sink ends is as follows:

1) When detecting that the previously failed members are restored, the sink end informs the source end at once.

2) The source end obtains the data of the restored members and reloads the data to the restored members, and then instructs the sink end to extract the data.

3) After receiving the instruction, the sink end starts to extract the data of the restored members.

References:

- HedEx