Chapter 15. Centralized Traffic Engineering

All the TE models discussed so far are distributed. In Chapter 13 and Chapter 14, Label Edge Routers (LERs) signal Label-Switched Paths (LSPs) by matching the Traffic Engineering Database (TED) against a set of locally defined constraints.

This chapter explores a totally different paradigm. Although LERs are still allowed to define LSPs on their own, the central controller is also capable of defining LSPs. A basic requirement for such a controller is to have an accurate and up-to-date view of the link-state database. To get that view, the controller establishes BGP sessions to one or more LSR/LER devices. Through these sessions, it receives link-state prefixes (BGP-LS NLRI). This is good due to the scalable and multihop nature of BGP.

Note

LERs always compute the TED locally and according to the distributed link-state database. This task is not (and should not be) centralized.

As soon as it has the TED view, the controller can perform path computations and ask the different LERs of the network to signal, resignal, or tear down LSPs in a precise manner. The controller could do that by accessing the LER configuration via Netconf or other similar mechanism, but this is a heavy approach. Using a protocol abstraction to signal LSPs on the fly is a more scalable strategy. Such a protocol exists and it’s called Path Computation Element Protocol (PCEP).

This model might remind you of OpenFlow, but there are some key differences. First, an LSP ...

Get MPLS in the SDN Era now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.