Understanding Cross talk prevention in EoS Circuits

The piece of article that I am writing today is actually influenced by one of the questions that was raised by Javin Shah. Javin had asked me on facebook a very interesting question  pertaining to the last blog-post.

“ In the recommended configuration of using only one EoS across two different elements for different services, what would happen if there is a problem or looping in one of the services? Would it also not loop my other service? In such a case why should I not go with the separate EoS trail approach?”

This is one of the major worries due to which a transmission engineer actually prefers to do separate EoS trails for separate services and not consolidate them in one NNI. This is the point where the user is actually considering the EoS to be actually a service and not an infrastructure.

When I say the word “Infrastructure” let us first understand what is infrastructure in the terms of telecom transmission provisioning.

Infrastructure is actually an entity on which (and this preposition is very important) the actual service runs. So if the service is a VC-12 trail the infrastructure for the VC-12 trail is the Channelized VC-4 and the infrastructure for the Channelized VC-4 is the Optical Fiber link.

Please see the figure below for a ready reference. 

As we can see in the Figure it is seen that the actual service (entity carrying the traffic) is the VC-12 Service trail from one point to another point. However this service is actually based on the Channelized STM-1 on which it rides or the Terminated VC-4 and the Terminated VC-4 is based on the Optical Fiber link maybe of STM-1/4/16 or 64.

A thing to note over here is that :

One Optical Fiber link may contain many Channelized STM-1s

One Channelized STM-1 may contain many VC-12 Services.

So the Optical fiber is the first layer of infrastructure and the Channelized STM-1 is the second layer of infrastructure.

Now if a user desires to may two trails of VC-12 service it is not required to actually have another set of Optical Fiber or another set of Channelized STM-1.  This means that the infrastructure is common for two trails of VC-12. However the traffic of one trail of VC-12 does not inter-mix with another trail of VC-12 and also the service ill-effects are also not carried over. Each VC-12 trail behaves as an individual service.

So as to say the service in the case of both the trails are segregated and do not interfere with each other, whether positively or negatively.

Same actually applies for the case of Ethernet services on EoS. However here the definitions slightly change as the layer of service is shifted one Layer up. Remember, we are doing this on Layer-2. In the case of our Layer -2 services or VPN the following picture actually shows the mapping of the infrastructure and the Service. 

K-L-M IN SDH IS SAME AS VLAN IN ETHERNET (FOR OPERATIONAL PURPOSES):

In SDH/TDM services the K-L-M indicator is the service differentiator similarly in the case of Ethernet services the service De-limiter is actually the VLAN. Just as in SDH as for a new K-L-M a new service trail is built in the case of Ethernet we have a different VPN for a different VLAN.

Hence, the VLAN actually forms the basis of the demarcation of the service. 

HOW IS VLAN DIFFERENT FROM THE K-L-M:

Having understood the concept of VLAN as a service is actually different from K-L-M. The Vlan a tag that is put on the data payload so that it can be identified and carried in the Packet Network through a VPN transparently without any kind of interference. The link below provides a conceptual property of the VLAN.

http://en.wikipedia.org/wiki/IEEE_802.1Q

In the case of VLAN there are priorities also so that we can have multiple streams in one Vlan with separate properties. The prioritization is something that is apart from SDH that happens on the Ethernet networks (Will be explained later).

A K-L-M is a logical indicator in the physical layer wheras the VLAN is a instance separation of different streams.

However, for operational constraints just like in a fiber we can map different services to different K-L-Ms the same we can actually do for the Ethernet services, mapping to different Vlans, in the EoS infrastructure.

WHAT IS TO BE UNDERSTOOD FURTHER:

Just like we do not have any cross-talk between the K-L-Ms of two different trails on the same Fiber link same way two different VLANs do not share information with each other even if they are on the same EoS trail.

Hence, when one service is affected or looped it is only that service which will face a problem and not the other service as the VPN/VLAN is different.

This is explained in the figure below. 

SO WHAT SHOULD MY TRANSPORT FRATERNITY REMEMBER:

1.       The service layer is to be identified for each and every service. A new service in Ethernet is not a new trail, the trail can be the same however the service is identified by VPN. This is the basic reason why the end user doesn’t mention port number of K-L-M in such cases. They mention VLAN.

2.       Data of one Service never interferes with the data of another service.

3.       If there is a malfunction/looping/broadcast in one of the segments of the service then the other service is never impacted.

4.       The user should remember that the Vlan can be reused just like the K-L-M can be reused in a different segment.

SO MY FRIENDS, REMOVE YOUR APPREHENSIONS AND GET OUT OF THE TYPICAL TRAIL PROVISIONING CUCOON AND IDENTIFY WHAT TO PROVISION WHEN…………

VCG, LCAS and the Pass-Through SDH concept

“There is member Failure in my VCG----- Link is going Down”

We may often come across such a problem.  I am saying this taking a cue from the previous post and also the kind of cases the operations me come across with.

My friends from the transport group, who have recently plunged into this field (EOS)  should be actually conversant about three things over here.

1.       VCG: Stands for Virtual Concatenation Group and this only sits on the Card or module that is responsible for the encapsulation of Ethernet to SDH and having the GFP or GEoS object.

2.       LCAS: Link Capacity Adjustment Scheme; and this deals with the Dynamic Payload Control. This ensures that the entire link is not going down when only one member of the VCG is going down.  The link below actually will describe LCAS in Detail and this is from the ITUT.

http://iie.fing.edu.uy/~javierp/SDH/NORMAS-ITU-T/T-REC-G%5B1%5D.7042-200402-P!!PDF-E.pdf

3.       Pass-through Elements:  These are elements in the intermediate section of the link that only deals with the cross connection between two different VCs. This doesn’t contribute to any kind of data processing and only contributes to the channelization of the path for the Data traffic.

A typical configuration of the link, in the unprotected domain is shown as follows.

A thing to note in this link is that the drop points of the SNCP connection are the Data card EoS objects and the LCAS is enabled also at the Data card at the End Multiplexer. The work of the pass-through object in this kind of connectivity is only limited to the SDH.

Also keep one thing in mind that the Pass-through object does not in any way contribute to any data processing. The VC-4s are all individual VC-4 that are connected by means of a cross connect fabric which is purely TDM.

If we logically look at the implementation then the implementation is actually perceived as follows.

As we can see in this figure,   Ethernet processing, LCAS, Virtual concatenation are all done on the terminal Data cards and they are the ones which are actually also acting as the SNCP drop points. The SNCP switchover also happens as the VC Members of the VCG on the DATA card and NOT ON THE SDH card.

Now why I am saying this? Let us look at a fault over here in the next figure.

As we can see that the complain is noted as one of the VC in the line had an AIS which was hitting one of the members of the EoS group. This was actually bringing the entire EoS group Down (Which it should not be).

However, the expectation of the person looking at this fault maybe as follows (shown in the next figure). 

As we can see in this figure that the fault attendant was actually expecting the connection to switch at the pass through level, which for obvious reasons as mentioned above should not be the expectation. This is because the pass-through element is not having the protection connection and nor having the information of any kind of grouping that should be there.

So the expectation that the switch should take place at the pass through level is a wrong expectation in such kind of configurations.

So then how to resolve this problem?

Ø  First of all it should be ensured that the LCAS is enabled at both the locations (end – points) and are running the same variant and also are compliant with each-other.

Ø  The SNCP connection should be checked, because if the SNCP is perfect then there should not be any kind of problem in switch-over. Actually the SNCP switch-over should happen at the terminal end only for one VC-4 and this should not lead to the link going down with LCAS enabled at both locations.

Ø  The SNCP variant that is being run should be made as a Non-intrusive SNCP which will respond to also errors in VC. Please remember SNCP works on a VC-4 level whereas the LCAS will work on the VCG (Multiframe level). And since in the pass-through element there is neither SNCP or Virtual concatenation, this operation is always done from the endpoints.

Hence, if we see clearly then the actual resolution should be as shown in the figure below.

So what are the things to remember in such configurations?

1.     The traffic is Ethernet encapsulated in SDH and the encapsulation and termination actually happens at the endpoints where the EoS object or Virtual Concatenation Group is present. The SNCP connection endpoints and the switching points are also present over there and not anywhere else.

2.     The pass-through element is just like a repeater which patches the VC-4s. This is a point where we can actually have a J SWAP that is changing of the VC-4 number like in any other TDM cross connect.

3.     Member going down should be addressed at the VCG level.

4.     Always keep the LCAS in synchronized mode.

5.     If required check trace of each and every VC-4.

6.     SNCP to be kept in non – intrusive mode.

So in the next post will share some interesting facts about implementing optimization in the LAN network using L2 devices and also the concept of Vlan.  Till then.....Goodbye....