MPLS

Also, one more thing -- rfc031 says about ILM or FTN tables mapping "to a set of NHLFEs". I can't understand how it is possible to have a *set* of nexthop entries? Could someone elaborate on this? Thanks.

Mark

You need a way to get routes into the router (just like you would with IP) - the common way is to use routing protocols since MPLS networks normally are large scale.

Now, MPLS operates with labels, but it has

not quite.

1 of the big advantages of MPLS is 1 core network can do several jobs

- but the flip side is you need several protocols, and the MPLS switching often works at 2 or more levels.

if you have an MPLS backbone then you need labels as well as IP routes propagating between the nodes for the "native" MPLS topology - typically a carrier would use an IP routing protocol so the nodes can find each other (often IS-IS or OSPF), and a label distribution protocol to propagate the labels such as LDP for MPLS.

You can use the native MPLS topology directly if you were say an ISP and you wanted to get some MPLS label advantages in the core network, but most corporate networks use "MPLS VPN".

Here you have a 2nd set of labels and IP routes which are per VRF, so that each customer network has its own IP routing table and topology - this needs route + label propagation, often by BGP.

There are lots of complications you can use for faster convergence, resource reservation and so on, but those are optional addons.

In the general case the MPLS core may be supporting several sets of protocols at higher level for different lots of instances of services

- common ones are IPv4 VPNs, layer 2 / Ethernet VPNs (VPWS and VPLS), IPv6 VPNs, with plenty of others being pushed - whether they turn out to be useful and popular...?

Load balancing isnt anything to do with MPLS directly, MPLS just gives a couple of useful tools to help.

Equal cost paths is something that "just happens" with a routing protocol - the cost to get from 1 router to a subnet happens to be (or is designed to be) equal over 2 or more different paths.

The issue is whether the routing protocol and actual router implementation you are using knows what to do to load balance traffic across those paths. This at least involves recognising multiple equal paths, putting more than 1 into a forwarding table at the same time, and splitting the traffic load across the paths.

The limitation is the routes have to be equal - that is easy in simple cases - eg when you have dual links at the same speed between 2 routers, but gets much harder as you add more boxes + complex topologies + unequal speed routes.

And being clever with the costing etc can backfire easily - a simple config mistake might mean good balancing in 1 case but only 1 path out of several gets optimised. In another that the aggregate bandwidth is the same as the slowest parallel link...

MPLS does have some useful ways to split traffic across non equal cost routes without causing loops - because "labels" mean paths are effectively connections and involve having some path state you can stitch multiple unequal paths and load balance across them, without getting forwarding loops.

Mind you - the resulting complexities are worth avoiding if you dont have to have the benefits - so not sure how much this is used in practice....

Hello Stephen,

thanks for your comments.

[skip]

The one thing I'm trying to understand now is about relation between FTN, ILM and NHLFE -- reading rfc3031 it appears that on LSR ILM can map an incoming label to a *set* of NHLFEs, that means we can have multiple nexthops per label.

But can we have multiple labels per FTN entry?

So we have such relations:

FTN NHLFE for un-labeled packets ILM NHLFE for labeled packets

Does it make sense?

Thanks.

Mark

never had to try, but yes.

A lot of the clever tuning in MPLS implementations is about splitting traffic across multiple paths to a destination.

have a look at

not much in there about the details of how it works though......