EoS in the initial phase of Evolvement ( EoS is an Infrastructure and not a Service!!!)

As we evolve towards the complete Ethernet back-haul from the traditional TDM we have taken an entry level step of actually starting by evolving the network by including the Ethernet traffic on the EoS. We also studied about what are actually the cost advantages in the initial phase of including the EoS as a part of evolvement.

For a person who has been with the transport TDM technology for a long time has something to cherish with this. EoS is not a technical shock for this person. He/She is able to absorb this gradually, however EoS is not SDH and that needs to be clearly remembered by the person. They should not be carried away by the fact that, “Well this is just another variant of SDH so let us do all the things that we have been doing so far.”

This is a very overconfident and a very incorrect thinking by a transport engineer. This thinking itself leads to problems in the network and thus forces your planners in the network to think of expensive means to actually grow the network and most-importantly outgrow you. I am sure nobody wants such imbalance in the network and also in the organization and so with the change of field we need to understand the change of rules.

So here are some major tips for My Transport Fraternity

1.       EoS is not a service trail. It is actually meant for carriage of service and is not the service itself.

2.       A EoS interface is not a SDH interface. It is similar to a GiG port of a router or a Switch only that in this case the port interface in the card is logical and is cross connected with the SDH KLM.  This means every EoS trail that you make actually relinquishes a port so you have to understand that every new service is not a new port in the EOS. The new EOS port should only be relinquished when and only when there is a link to be created to another destination that is not “Physically or geographically” connected to the ring.  I am posting below some Pictures that are the right approach and the wrong approach of realizing services in the case of EoS. We will take the example as follows:

     There are two customers that are taking a drop from the same Multiplexer that has a data card. One of these customers has a Service commitment of 20Mb/s and another customer has a service commitment of 30Mb/s.  The point A and Point B are connected by one SDH Protected Link as shown in the figure below. 

Let us see the right and the wrong way of implementing them.

Let us look at the WRONG Implementation First. (Which Most of Indian Transport Planners do)

What is wrong in this?

While for many transport engineers/Planners and Noc engineers this configuration may seem to be the best configuration that can be created actually this is the most horrible configuration that one can make.

Ø  First of all for different customer using different EoS itself proves that the transmission in not planned an optimized properly.

Ø  This means that for every customer there would be a EoS infrastructure trail entitiy and this also means that the card ports will exhaust very soon.

Ø  For the planner, this means that very soon and sooner you would be constantly needing new cards.  Your management is soon going to take you to task and ask why the hell you are going on adding new cards. Trust me.

Ø  More complexity in the topology. Because the SDH link is same but there are two or more (Depending on the customers) EoS links. 

Ø  This configuration means that the transport engineer or planner is still looking at the implementation as a pure SDH implementation, which it is not and not looking at it from the Ethernet perspective. He should be told that the customer is actually looking for “ETHERNET SERVICE “ and doesn’t really care as to how many EoS trail the TX guy has made. 

Ø  Implementation is not optimized and in some cases can be disastrous is RSTP is involved. (This will be explained in my next blog posts).

Now let us have a look at the Right implementation. (Which very few of Indian Transport Planners Do)

So what is so right about this configuration?

Ø  First of all the planner has actually conceived the services well to be Ethernet service so the segregation is being done at the Ethernet level initially by means of separate VPNS.

Ø  Secondly the planner has used only one EoS trail that is of 50 Mb/s and can be scaled up as per his/her requirements in the future, thus he/she is looking at the EoS as an infrastructure and not as  a service and thus able to optimize the usage of the Data card/switch.

Ø  He/She is actually able to look at the service as a complete Ethernet service that may ride over the transport however; different services over the same physical topology need not take different infrastructure.

Ø  The 20Mb/s and the 30Mb/s is actually done on the Rate Limiter in the VPN.

Ø  The planning leaves more space for further augmentation of BW if required and also addition of another service over the same EoS trail infrastructure.

Ø  The configuration actually enables Bandwidth sharing and EIR upto 50Mb/s for each service keeping the committed SLAS intact to 20Mb/s and 30 Mb/s respectively.

Ø  This guy/gal is actually achieving the entire facilities of Ethernet Services without loading his CAPEX and thus impressing his planning bosses and management. 

Thus my dear companions of Transport Fraternity, we need to remember the most important thing in the first phase of evolution.

“ EoS is a boon when it is considered as an infrastructure of carrying Ethernet services on the TDM back-haul, however it becomes a major liability and a cause of headache when it itself is considered as a Service.”

In very simple words “STOP CREATING SEPARATE EOS TRAIL INFRASTRUCTURE FOR SEPARATE ETHERNET SERVICE REQUIREMENTS AND STOP BEING YOUR OWN EXECUTOR.”

EOS has a very good advantage in your network now if the Data traffic volume is less and can be accommodated in the transport Vs the Native Ethernet.

1.       EoS is the only infrastructure where you can achieve variable rates of BW in the link. Remember you can only achieve pipes of 150, 2, 32, 64, 48, 300, 600 Mb/s and various such combinations only in the EoS. This is because EoS can have Concatenations of various levels of the SDH Path objects like VC-12, VC-3 and VC-4.

2.       EoS is the only infrastructure where in addition to the L2 protection schemes and running of L3 internal protocols you can also achieve TDM carrier grade protections like MSP1+1, MS-SPRING and SNCP I and N.

For my companions from the Routing and “ALL – IP” Fraternity……

EoS is not a SDH implementation. It is a mere link between two devices that may be L2 or L2.5 or L3 using the SDH infrastructure. This is something like PoS, however unlike PoS this actually looks for the Ethernet header in the Raw Input.

EoS is as much capable to carry all the functions of the “ALL-IP” Transport (and please note this word TRANSPORT)  as any native  Ethernet Carrier.

Actually in some cases, for initial phase of deployments, if used judiciously as mentioned above, it is much better, less costly and more efficient than native variant of Ethernet.

In the next blog post we will see about how to optimize the physical interface also taking some help from the routing fraternity and thus reducing your cost on transport. 

"More you be with the science in the judicious manner, less you will spend on unnecessary events in your network."