TE: RSVP and LDP feeding into LFIB

[dknov]

Hi,

A conceptual question. Lets say you have MPLS Core running LDP in all the links and now you deploy TE tunnels. On the control plane RSVP will signal a path from headend to tailend as per TE operation, however on the data plane a particular router along the tunnel path will construct its LFIB taking into account both RSVP learnt label and LDP learnt label(s).

Is there a built-in mechanism that prefers RSVP labels over LDP ones and does not permit LDP label to enter LFIB if RSVP label exists?

If not, I would imagine that this will create a mismatch between control and data planes and undermine the whole purpose of TE tunnels...

Thanks,

David

[mheusing]

Hi David,

There is no control mechanism needed, as the decision at the headend is done by the IP routing (PBR, static, autoroute announce, forwarding adjacency). More prcisely, the FIB entry will determine the label imposition, i.e. will select the LSP. Once the traffic is on a LSP, f.e. created through a TE tunnel, then it will not "leave" it. The RSVP signalling allows a P router to learn the downstream router label for the tunnel. The LFIB will simply swap the P router label on a received labeled packet with the downstream router label as signalled. This is what makes MPLS "sexy": a P router does not investigate the payload to make "intelligent decisions", it just needs to do label swapping.

Just to note: the LSP of a TE tunnel to a certain destination does not have to match the IP routing table of a P router for that destination; the outgoing interfaces might be different. But in many cases this is the motivation to deploy TE, i.e. to take different pathes than IP routing.

You can see this with "show mpls forwarding-table".

The only mechanism needed in a LSR is to have unique labels for each FEC, independant of the control plane mechanism, i.e. LDP, RSVP or MP-BGP for L3VPN.

Hope this helps! Please use the rating system.

Regards, Martin

[dknov]

Hi Martin,

So if we talk for a second about regular LSP and not TE. It is true what you say about routing path being "pre-determined" during label exchange process (LDP), however should any routing change happen in the Core, LSP will change according to the FIB changes. LSP is a dynamic thing.

Now if we look into TE unless there is some internal mechanism in the router to "stick" the LSP to what had been signalled, I do not see why it won't react on FIB changes inside the MPLS Core.

Label header does not contain any routing information (like ERO), so each router takes independant decision according to its LFIB what label swaping should take place. Again, if there is no internal mechanism to prevent those changes for TE tunnels, i do not see why the routers would not dynamically change TE LSP according to the routing changes in the Core.

If there is no LDP and the whole Core is built only based on TE tunnels, then I can see that routing changes will not cause the traffic to skew from the signalled path and LSP change will be triggered only by periodic reoptimization (until then a traffic will be blackholes) or reoptimization as a result of Path Err message signalled back to the headend (if link failed for example).

With both LDP and TE in place, both LDP and RSVP will feed LFIB, so I do not see why LDP label mapping, which can change dynamically according to FIB changes will not take affect if RSVP label mapping "goes bad" (topology change).

I might be missing something, but it it looks to me that LDP can compensate for RSVP. As long as RSVP labels are in use, then datapath will be as signalled, but routing changes will put LDP into the picture and again unless routers are "smart" enough to disregard LDP labels datapath will change with routing changes in the Core.

Thanks,

David

[mheusing]

Hi David,

There seems to be some confusion about routing and RSVP (control plane) and resulting entries in the data plane.

As I said, once a LSP has been established for a TE tunnel, it will be used until a failure has been detected or manually changes are applied. This actually means, that a TE tunnel is NOT affected by any IP routing decisions in a core. It is only affected by a failed path, i.e. failed link or node, reoptimization or manual reconfiguration at the headend.

A failed link or node affecting a TE path will change IP routing and TE tunnel path.

A change in TE tunnel path will not influence IP routing and changes in IP routing will not affect TE tunnel pathes.

IP routing and TE are using different topologies respectively databases.

F.e. in OSPF opaque LSAs provide TE info, whereas LSA1 to LSA7 provide IP routing info.

The mechanism to "stick" the TE tunnel path is in fact implemented in the headend router, which is the only LSR deterining the TE tunnel path. The headend router will not change the path of a tunnel based on changes in the IP topology. Only, if the current path is not valid anymore (or with reoptimization) a new CSPF calculation is triggered and the outcome signalled.

Once established again, the LSP will transport data end-to-end. It is a general principle in MPLS, that traffic will not leave a LSP other then at the endpoint. There is no "choice" for a transit LSR to find a "better" path. Thus LDP can not compensate for RSVP. Both protocols setup LSPs and the decision, which available LSP to use is done at the edge LSR, and only there.

Regards, Martin