Sunday, September 8, 2013

Viability of MPLS in a traditional network

My Dear Friends of the Transmission Fraternity,

I am sorry, I had to again go on a recluse due to various reasons, some busy schedule and some very urgent professional commitments. But here I am, and I would like to today discuss on one of the burning topics that is taking the Telecom Transmission Industry by storm.

MPLS (Multi Protocol Label Switching)

I know this is a kind of deviation from our regular discussions on the RSTP that I promised but trust me this is important. Why this is important? Well because most of the reasons that are being used to actually use/misuse this technology, especially in India is wrong totally trashy.

So now let us in a very pure mind understand the viability of MPLS in a network that is traditionally a transmission network based on TDM. Can you realize MPLS on it.

If you ask this in the market as an operator, who is trying to enter to the data segment for the first time, you will get very very different answers. Some yes and some no. Some people would tell you that MPLS can never run on a TDM network, some would tell you that yes if the end devices are routing devices and the TDM acts only as the overlay you can realize it.... Well to tell you the truth... These are all vague answers to your pertinent queries. In fact these are not "Honest" answers at all.

To substantiate my point, I would like to draw your attention on this link of Wiki which tells about MPLS. Neutral, short but enough for an operator / beginner to understand to evolve his/her network.

Wikipedia Link describing MPLS

As told correctly in this link MPLS is a Media independant technology, working in between the L2 and the L3 layers of the OSI layer.

So this answers your vital question that MPLS can be actually realized on the boxes that you have purchased to run the TDM network. It can co-exist with a TDM/ATM/FR network that is traditionally old and can also evolve to the new network that are more Ethernet oriented.

The million dollar question is how does this thing happen?????

Well as described in my previous blog posts, if you have read them, there is a concept of EoSDH, which stands for Ethernet over SDH.  An EOSDH trail is a clear infrastructure entity, or a carrier on the layer-1 that encapsulates the Ethernet traffic over the SDH media. This encapsulation happens through the means of GFP (Generic Framing Procedure).  The EoSDH trail or the cross connect acts as a simulation of the ethernet link in the SDH back-haul. Many people, as I said before, mistake this for a SDH trail in totality, however they are wrong as the EOSDH trails have 100% properties of Ethernet and basic properties of SDH inculcated. So this should be treated more like a embedded Ethernet Link than a pure SDH trail.

When you do not have the fibers to make dark fiber Ethernet Link or you have very little requirement of Ethernet Bandwidth, not justifiable to actually spend a dark fiber on the case then EoSDH is a big tool to actually optimize your network.  Here SDH is used as a carrier and not as a service, and the actual service lies on the Ethernet plain.

When this EoSDH trail also has abilities of Label Encapsulation and Traffic engineering then this becomes a trail that can be used to run MPLS on the existing box with existing SDH capabilities.

So how is a MPLS enabled EoS Different from a Normal EoS?

The infrastructure that is created by a normal EOS using only Ethernet is actually a infrastructure that is subjected to the L1 and L2 rules. Under these conditions most of the devices in the Ethernet layer would act as a Provider Bridge. A Provider Bridge is actually an entity that will do the forwarding of the traffic based on Mac Learning or MaC lookup at every point, whether this is the start, end or the transit point.

So in a provider bridge kind of a scenario all the L2 devices have to remember the MAC tables of the entire topology for each and every services. Also as the number of devices increase and the services go high up the number of Mac address entries in the forwarding table would also go High.

This is prevented by making of VPNs (Virtual Private Networks) and VSI (Virtual switching instance) in the network. So VSI is a mechanism that can segregate the services from each other and create a virtual path however, what the VSI alone cannot do is actually giving a dedicated traffic engineered path for each and every sevices across two points in a ring or in  a Network without Mac learning in the Transit nodes.

Below is a picture of how a provider bridge would work with a traffic flowing from point -A to Point-D.  For simplicity I have taken the path of traffic as a liner L2, we will talk about protections later.

As seen in this picture we can see that at every transit location there is a need to learn the MAC address. So the traffic from A to D needs to have vFIB learnings at A, B, C and D. Similarly a traffic from A to C will need to have this in A, B and C.

This method is called the method of  Bridging. At every point the traffic is forwarded or Bridged on the basis of the Source and DA using the MAC table. MAC learning is the essence of learning addresses and forwarding traffic.

Needless to say as the number of transit node will increase so will the number of lookup location and so will be number of learning instances.

A MPLS enabled scenario actually eliminates this. This is shown in the next figure.

 As you can see in this figure there is one more entity in Yellow. This is a logical path that is defined from A to D. This is called as a LSP (Label Switched Path) or more colloquially Tunnel.  Due to this tunnel the traffic which was subjected to a VSI/VPN in A and in D between two ports is not only between one access port and the tunnel.

So the VPN constitutes of on A side the access port in red and the tunnel in yellow and the same is in the D side. This would mean no switching instances in B and C.

So the Mac learning would only be required at the points A and D typically Edges, thus the point A and D are now refered as PE or Provider Edge. While B and C are only going to look at the labels and merely act as transit points without looking at the MAC.

Advantages of this:

Less latency and more scalability. This also ensures more end to end BW integrity, which we will, I hope so see in our next Blog Posts.

This also helps to realize a more point to point architecture in traffic forwarding without the invenstment of physical resources thus saving time and saving money.

What my friends need to remember????

It is not essential to replace the whole install-base that you have purchased with your hard earned money, just becuase you want to include MPLS. Understand the purpose of MPLS before dancing on it.

MPLS is a technology, which is agnostic to device types. The MPLS algorithm and software can be put into any kind of a device be it a L2 switch or a L3 router.

MPLS is a technology that deals with multi-protocol support so if there is a kind of argument on IPv4 and IPv6 be sure this is not MPLS as MPLS doesn't care about which internal protocol is being forwarded.  Many people would flash their papers and give you this dope.

At the end of the day it is the ETHERNET SERVICE  that is actually carrying the traffic, so this needs to be given utmost attention. MPLS is an underlying technology to enhance the delivery of the SERVICE.

Till then .... Have Fun....

No comments:

Post a Comment