cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1519
Views
25
Helpful
15
Replies

MPLS TE Question

lamav
Level 8
Level 8

Hello:

I am trying to understand the applicability of MPLS TE in a SP cloud

I understand that a head-end router and a tail-end router will be the MPLS TE tunnel source and destination, and that the LSP path that is created for a specific TE flow can either be a product of dynamic negotiation with the IGP leveraging its TE extensions to pass resource data -- or it can be a product of an explicity configured LSP.

The dynamically created LSP may not necessarily be the "shortest" path, or better stated, the least cost path, because a bandwidth requirement for the TE tunnel may be higher than any particular link -- or set of links and interfaces -- in the "shortest" path can deliver. So, the LSP for MPLS TE can be a suboptimal path through the SP IGP cloud. Optimal paths can be congested, so it is useful to utilize the avilablity of less optimal paths.

Now that I am done rambling, what I dont understand is exactly how MPLS TE tunnels are leveraged in practical situations.

From my experience and knowledge of RSVP in a QoS environment, it is the application that will request resources from the network from each router in the path. In an MPLS TE environment, who is making the demand?

I think its the head-end router itself, but WHEN will it trigger a TE request and on behalf of whom? Unlike a QoS application for RSVP, I dont think the purpose of MPLS TE in an SP cloud is used by the SP for the same purpose.

Can someone with MPLS TE experience provide some of their thoughts on this topic?

Thanks

Victor

15 Replies 15

Reza Sharifi
Hall of Fame
Hall of Fame

Victor,

The Resource Reservation Protocol (RSVP) is a resource reservation setup protocol

that is used by both network hosts and routers. Hosts use RSVP to request a specific

quality of service (QoS) from the network for particular application flows. Routers

use RSVP to deliver QoS requests to all routers along the data path. RSVP also can

maintain and refresh states for a requested QoS application flow.

RSVP treats an application flow as a simplex connection. That is, the QoS request

travels only in one direction—from the sender to the receiver. RSVP is a transport

layer protocol that uses IP as its network layer. However, RSVP does not transport

application flows. Rather, it is more of an Internet control protocol, similar to

Internet Control Message Protocol (ICMP) and Internet Group Management Protocol

(IGMP).

HTH

Reza

Reza:

Thanks for the information, but it doesn't answer my question.

I know what RSVP does and how it works.

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Victor,

>>

I think its the head-end router itself, but WHEN will it trigger a TE  request and on behalf of whom? Unlike a QoS application for RSVP, I  dont think the purpose of MPLS TE in an SP cloud is used by the SP for  the same purpose.

As soon as you end  to configure the  tunnel, the headend router will try to setup the  MPLS TE tunnel. Your understanding is correct there is no need to wait for someone with an interesting flow to trigger MPLS TE creation.

An MPLS TE is unidirectional as any RSVP reservation, but it is part of network infrastructure as a physical link.

The declared bandwidth (if not using auto-bandwidth) is only a nominal value used for  Call admission control at tunnel setup.

After an MPLS TE tunnel is up nothing blocks traffic in excess of stated bandwidth so you can put 50 Mbps of traffic over a tunnel with a configured bandwidth of 1 Mbps.

To be noted that one thing is to configure and setup an MPLS TE tunnel, another aspect is how to use it.

When an MPLS TE tunnel is used for protection (link or node protection) it is normally up but no traffic flows over it.

In implementations we tested some years ago we didn't use the auto-route announce so the tunnel could be used only with appropriate static routes.

Our need was  to put on different MPLS sets of tunnels different types of traffic for example VoIP traffic between central offices.

Unfortunately at those times it was not possible to use BGP to advertise directly an MPLS TE tunnel as a next-hop.

( probably it is still not possible, tunnel has a 32 bit tunnel-id that should identify it in an MPLS TE topology)

For better scalability and to add flexibility we used an approach with service representing loopbacks:

each service IP subnets are advertised with a BGP next-hop = specific loopback on the PE different from MPLS TE router-id loopback

At remote PEs a static route with destination the service loopback that  specifies  a tunnel with destination = that PE MPLS TE router-id is used.

You can use an MPLS TE to carry an MPLS L3 VPN traffic or an EoMPLS pseudowire using similar approaches that use BGP recursion or MPLS forwarding FEC concept.

Other colleagues have reported use of MPLS TE for VPLS.

On the other hand, there are some useful applications of autoroute announce like auto mesh that can be useful if the objective is simply link / node protection.

What  makes MPLS TE attractive is the capability to move beyond hop by hop routing: using an explicit path allows to specify how traffic has to be handled on all network devices on the path: once head end router has decided to put traffic into the MPLS TE LSP, it is forwarded to destination.

Compare this with (for example) PBR: a PBR rule should be applied on each router hop in order to divert specific traffic from the IGP best path.

Hope to  help

Giuseppe

Giuseppe:

Thank you for all that information.

Perhaps my lack of clarity involves the more basic aspects of MPLS TE.

Lets start with the 'why'?

Lets back up a bit and do a quick review of the basic MPLS unicast IP forwarding within the SP cloud.

The IGP works with LDP to create a forwarding mechanism that will use the least cost route -- as determined by the IGP -- to forward labeled packets. So, the IGP creates the RIB, which generates the FIB (typical cef). The next hop in the FIB table for a particular prefix, coupled with the IP prefix-to-MPLS label bindings found in the LIB, are both used to generate entries in the LFIB. This is the outer label.

OK, so this mechanism should create a routing structure that creates least cost paths between the ingress and egresss PEs.

So, WHY is there a need for the MPLS TE tunnel that will construct paths that are sub-optimal? What is the SP trying to achieve? Wouldnt client traffic that needs to traverse the SP cloud suffer from having to use suboptimal paths?

Are the dynamic TE tunnels up all the time or are they constantly created and torn down as needed? If so, what circumstance creates that need? Is it a client request that is the reason for creating the tunnel? Or is it something completely internal to the SP and only for their benefit?

After reading your answer, I came to the conclusion that I need to review my basic understanding reagrding the need for these tunnels and how they are used.

I know I gave you a lot, so please feel free to take your time in answering.

Thanks!

Victor

I won't be going into as much detail as Giuseppe but from a higher level view -

OK, so this mechanism should create a routing structure that creates least cost paths between the ingress and egresss PEs.

So, WHY is there a need for the MPLS TE tunnel that will construct paths that are sub-optimal? What is the SP trying to achieve? Wouldnt client traffic that needs to traverse the SP cloud suffer from having to use suboptimal paths?

The key thing here is the least costs path may not the best one at all times. Lets say you have 2 paths one is 45Mb (P1) and the other is 20Mbps (P2).

Customer 1 is already sending 35Mbps of traffic on P1. Customer 2 now needs to send 15Mbps of traffic. If it sent on P1 which the IGP has worked out is the "best" path you now have congestion because you have exceeded the total capacity of the link. But if you sent customer 2's traffic down the other path then each customer will be satisifed and neither will suffer because of the others traffic.

This is the key element of MPLS-TE ie. the ability to override the IGP on an end-to-end path. As Giuseppe alluded to PBR is often used for this in IP networks but PBR is not an end-to-end path feature ie. it is simply per-hop. MPLS TE goes beyond that and gives the SP much more control of how traffic traverses their network. Without MPLS TE a lot of the guarantees that were inherent in ATM networks for example would not be possible within an MPLS cloud.

Jon

Jon:

Well stated.

Perhaps my understanding isnt as unclear as I thought...I was thinking just about exactly what you wrote.

But here is the part that confuses me. IP routing protocols do allow for traffic to traverse multiple equal cost paths across an IP network. In fact, a protocol like EIGRP allows unequal cost load sharing through the use of the variance command....so, when the LFIP is generated, the LIB bindings and the multiple paths in the FIB table can be used to generate multiple entries in the LFIB, thereby giving you the multiple paths you need to reach the same destination.

I undrestand that SPs do not use EIGRP, but it doesnt seem that the limitation regarding unequal cost path routing is a function of IP as much as it is a limitation of the routing protocol and the manner in which LSPs are constructed. I say this because, if you read literature on the reasoning behing MPLS TE, we are told that the limitations of IP are what necessitates the need for TE.

Also, how is it decided which traffic will traverse the tunnel and which will use the LSP constructed by basic MPLS unicast IP forwarding?

Thanks

Victor

I undrestand that SPs do not use EIGRP, but it doesnt seem that the limitation regarding unequal cost path routing is a function of IP as much as it is a limitation of the routing protocol and the manner in which LSPs are constructed. I say this because, if you read literature on the reasoning behing MPLS TE, we are told that the limitations of IP are what necessitates the need for TE.

Also, how is it decided which traffic will traverse the tunnel and which will use the LSP constructed by basic MPLS unicast IP forwarding?

The key point here is that even with unequal cost load-balancing with EIGRP it is still done on a hop by hop basis. There is nothing in EIGRP that can see end-to-end. EIGRP does have the capability to include load etc. in it's metrics but it is strongly recommended not to because it can lead to flapping routes.

And even with unequal cost load-balancing it would not sort out the problem i referred to in the last post because it would simply use the variance to work out how many packets to send on each link. This would not necessarily mean that there was no congestion for either customer.

The "problem" with IP is that is connectionless or more specifically it is done on a hop by hop basis. Contrast this with ATM for example where a PVC is set up for the end-to-end path before any traffic is actually sent. ATM has it's limitations but it could guarantee a specified level of service from end-to-end by controlling whether traffic was allowed onto the network. IP by it's nature doesn't see end-to-end although obviously things such as RSVP were designed to alleviate this. It's kind of like the difference between Intserv and Diffserv with QOS, Intserv being end-to-end using RSVP and diffserv being done on a per-hop basis.

So modifications to certain routing protocols eg. OSPF allows the routing protocol to gather information on the end-to-end path such as current available bandwidth, ability to meet CoS requirements etc. and use this information in it's calculations. This is how which tunnel to use is decided. A customer who has been guaranteed 15Mbps of traffic at a certain CoS can be routed over an MPLS-TE that the IGP would not necessarily see as the best path but that OSPF with the MPLS TE extensions knows can deliver not just the bandwidth but the CoS as well.

Jon

'So modifications to certain routing protocols eg. OSPF allows the routing protocol to gather information on the end-to-end path such as current available bandwidth etc. and use this information in it's calculations. This is how which tunnel to use is decided. A customer who has been guaranteed 15Mbps of traffic at a certain CoS can be routed over an MPLS-TE that the IGP would not necessarily see as the best path but that OSPF with the MPLS TE extensions knows can deliver not just the bandwidth but the CoS as well.'

Right, that is the part that I have put on the back burner of my thinking and forgot to call up. I was thinking to myself that MPLS unicast IP forwarding is  also done on a hop-by-hop basis, as the LFIB is a product of the FIB itself, and forgetting that the extensions to OSPF and RSVP will allow this hop-by-hop querying of each router's resource availability to create an end-to-end wholistic approach to path construction.

I don't think I agree with you, though, that because IP is connectionless that it means that it does not have a view of the overall topology. I think that's only partially true, as in the case with distance vector protocols. A router using a distance vector algorithim only knows what the next hop knows. It's view is short-sighted. Link state protocols, however, which is what SPs use in the core (OSPF or IS-IS) do have a logical view of the network and they do create a logical tree with itself at the root, at least within the same area. Therefore, the best path selected for intra-area routes are indeed constructed based on end-to-end visibility. For inter-area routes, I will also agree that there is a distance vector characteristic that mitigates its view of the network.

Victor

Victor

I don't think I agree with you, though, that because IP is connectionless that it means that it does not have a view of the overall topology. I think that's only partially true, as in the case with distance vector protocols. A router using a distance vector algorithim only knows what the next hop knows.

Good point and i should have been more specific (+5)

Because OSPF uses elements of distance vector for inter-area routes lets concentrate on an intra-area route where OSPF has a full view of the logical topology ie. it knows the cost of all paths from the end-to-end and selects the best path. What i was trying to get across was that when a packet arrives at an OSFP router destined for a device within the same area the route lookup is still only done on a per hop basis ie. the router consults it's routing table, finds the longest match together with the next-hop associated with that match and forwards the packet onto the next-hop.

What it is not doing is checking the end-to-end path for available resources and that is what i meant by end-to-end, i just didn't explain it very well (it's that fog you were referring to in our last thread )

It should be emphasised this this is done on the head-end device only as Giuseppe pointed out and that it is not dynamic in nature although i believe the headend does have the ability to dynamically recalculate available bandwidth based on what has already been used.

Jon

Jon:

"when a packet arrives at an OSFP router destined for a device within the same area the route lookup is still only done on a per hop basis ie. the router consults it's routing table, finds the longest match together with the next-hop associated with that match and forwards the packet onto the next-hop."

True, but the information gleaned from the FIB and LFIB for an intra-area route will be the products of end-to-end intelligence.

"What it is not doing is checking the end-to-end path for available resources and that is what i meant by end-to-end..."

Exactly, and THAT is what I see as the qualitative difference between an MPLS LDP LSP and an MPLS TE LSP - its the resource capabilities of the redundant path. OSPF alone can let you know that an alternate and relatively least-cost path to a destination exists, but it doesn't give you absolute resource information, such as the actual bandwidth of the link, the available bandwidth, and/or the availabily of the interface queues to handle the RSVP request. For that, you need enhanced OSPF with Opaque LSA type 9,10 and 11 support, as well as modified RSVP for MPLS TE tunneling.

Agree?

Victor

Hello Victor,

>>

So, WHY is there a need for the MPLS TE tunnel that will construct paths that are sub-optimal? What is the SP trying to achieve? Wouldnt client traffic that needs to traverse the SP cloud suffer from having to use suboptimal paths?

sub-optimal paths travel over links that would be unused otherwise.

Jon has provided you an higher level view that it is useful

traffic engineering means the capability to move/divert some traffic quotas over underutilized paths in order to better use network topology.

Other application is fast convergence.

>> Are the dynamic TE tunnels up all the time

They need to be up to be ready to be used for fast rerouting. There can exist tunnels that are the backup of other tunnels.

But it is not the case to dig into more details at this phase.

MPLS TE tunnels state is refreshed with periodic RSVP TE messages.

>> Is it a client request that is the reason for creating the tunnel? Or is it something completely internal to the SP and only for their benefit?

Generally speaking it is a SP decision taken in order to satisfy a SLA with a customer.

Customer is interested on the traffic metrics it can measure between its own sites.

The fact that traffic is carried within an MPLS TE LSP rather then an MPLS LDP LSP is transparent to customer.

The trigger for a use of MPLS TE can be for example a very fast convergence time for an MPLS L3 VPN traffic.

In this case MPLS TE fast reroute or combinations of MPLS TE with IP fast convergence can be of help.

BGP convergence time can be lowered but only up to some point.

The same happens for LDP + IGP in use.

Edit:

to add to Jon's second post:

it is your responsability as a network engineer to avoid to overload an MPLS TE tunnel.

That is you need to perform traffic conditioning at network edge.

MPLS TE provides only static Call admission control at tunnel setup attempt. That is it is a subset of what ATM can do.

ATM can provide end-to-end dynamic CAC over PVCs or SVCs but this complexity has a great cost.

If an ATM DTE tries to go over the SCR part of traffic is marked down and then it can be dropped on its journey to destination.

Hope to help

Giuseppe

Giuseppe:

I need some time to digest what you are saying, so I dont have any response right now. I may ask you another question later, so I will keep this thread in mind.

Thanks

Victor

Giuseppe:

I was reading this book just now on MPLS and I ran across this paragraph.

"If TE is enabled in the network, you can use it in two distinct ways. First, you can create MPLS TE tunnels between each pair of edge LSRs in your network. As such, you can steer all traffic in the network, avoid congestion in it, and give all traffic the characteristics (bandwidth, delay, jitter, and so on) it needs. A good example is MPLS VPN, where you can create one TE tunnel from every PE router to every other PE router.

Second, you can enable MPLS TE everywhere in the network but not have TE tunnels until they are needed. You can create the TE tunnels on demand. A good example of this is when you create TE tunnels to steer traffic around a hotspot or overloaded point in the network. Equally important as how to steer traffic with the TE LSPs through the network is how to map traffic onto them. This is explained in the section “Forwarding Traffic onto MPLS TE Tunnels.” When no traffic enters the TE tunnels, the TE tunnels are idle."

This is exactly what I was getting at in my original question....

Hello Victor,

>> I was reading this book just now on MPLS and I ran across this  paragraph.

May I ask you what book are you referring to?

I agree the possible strategies are the two described in the book as also discussed in this thread

>> When no traffic enters the TE tunnels, the TE tunnels are  idle.

It would be interesting  to understand what the writer means with this sentence, if he/she is meaning that no user traffic is going over the MPLS TE tunnel this is agreeable in a backup scenario. However, a mesh of TE tunnels require load state on PE nodes and some signalling going on.

Hope to help

Giuseppe

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco