Need a quick recipe for SDN in WAN? Mix BGP-LS with PCE

Thinking of implementing SDN in your MPLS  WAN ? without a forklift ?

Look no further ! as BGP-LS ( BGP-Link State) and PCE ( Path computation Element) give a right combination.

In this Blog, I talk about an evolutionary ( not the revolutionary approach) to SDN in WAN.

SDN-based MPLS network, running PCE and BGP-LS offers considerable flexibility, visibility, and control.

It’s like running MPLS on steroids.

This means not only basic things expected from a controller, i.e. its ability to manage ( create, modify and delete) LSPs ( Label Switched Paths) without touching a single line of config on a router.

But more advanced things; for example:

• Providing services like bandwidth-on-demand and auto-bandwidth-calendaring.
• Planning maintenance windows for routers with point and click.
• Traffic optimization and distribution by efficiently using optical links.
• Service orchestration across multiple MPLS networks.

And last but not the least, this is an enabler for integrating  an MPLS core with an Optical core.

I know, this hurts many service providers: the independent build out of routing and DWDM domain, costing both CAPEX and OPEX.

This happens because the MPLS domain DOES NOT  talk to the optical domain at all. And this happens because the two teams managing the two networks  talk neither.

Why centralization of  MPLS network is necessary ?

Implementing SDN in MPLS network demands centralization of network control.

Controlling  optical domain is easier as it  is already driven by a  powerful network management system. On the other hand, controlling  IP/MPLS is complex as it is based on a distributed control plane with a control plane residing on every box making a local decision.

Therefore, integrating IP/MPLS with optical domain would demand some sort of centralization in IP/MPLS, the way it is, in the optical domain.

But let’s be clear on it:

We are not talking about OpenFlow here. Neither a complete offload of the control plane from the data plane as the SDN purists would suggest.

Such a strategy would not be realistic even if it is possible as this is revolutionary and need a forklift upgrade. As operators have invested in their WAN infrastructure, they want to use it to the maximum.

On the other hand, we are talking about selectively offloading one small part of the control plane. That is, a decision to compute and engineer a labeled path in an MPLS network. And delegating that to an SDN controller.

And here is a good news:

You don’t need to forklift your WAN. You can build upon something which you already have!

BGP-LS and PCE in WAN just promise those evolutionary approaches that you can take today on your WAN without a forklift upgrade. You don’t need to change hardware but add software only.

How BGP-LS and PCE help an SDN controller?

Let’s start with the problem that an SDN controller wants to address.  That is a need to manage an LSP  from A to C going through E  in the WAN shown below. To be more specific, the management means the ability to create, tear down and modify the red LSP  shown.

This can be done by the PCE using standard protocol PCEP ( Path Computation Element (PCE) Communication Protocol (PCEP)

Here are the three things you need to remember regarding PCE :

– PCE ( Path computation element) is a software element that sits in the SDN controller and is responsible for path computation.

– PCC ( Path computation client) is  the client that sits in the router. PCE sends path computation to the PCC client.  PCC can report back the status of LSPs for which, it is the ingress router.

-PCEP is the name of the protocol used by PCE to communicate with the PCC.

A question may be asked here:

Why not just use CLI to configure this LSP?

Becuase CLI is vendor specific , proprietary and a one-way command. PCEP is standard and  has important reporting features which are important for state synchronization between the network and controller.  PCEP allows two-way communication between PCE and PCC and can be stateful about the active paths/LSPs and their  reserved resources.

So by using PCE, SDN controller can effectively configure the red route shown above.

And as you can see that with PCE we have selectively offloaded the path computation responsibility of the LSP from the routers to the central controller.

But wait a minute !

There seems nothing new here.

The RFC 4655  for PCE has been around since 2006, while  the RFC 5440 for PCEP has existed since 2009.

Much before the SDN was introduced.

PCE is half the story. BGP-LS completes the story

SDN controller with an effective PCE is not the only requirement for SDN controller.

There are still unanswered questions like

1. How the SDN controller knows about the topology/link state of the network.

2. How the SDN controller knows about the traffic engineering info like, Bandwidth, SRLGs , colored links etc

IGP can do these but not very effectively as IGP is restricted in one domain only.

BGP-LS answers just these questions.

BGP-LS stands for BGP Link state. It is a newly  standardized RFC 7752 ( March 2016)  called “ North-bound distribution of link state and traffic engineering information using BGP”.

Actually, a router maintains a database for storing link-state information about nodes and links in any given area. Some of these attributes include interface identifiers, link metrics, TE metrics, reserved bandwidth, Class of Service, Shared Risk Link Group (SRLGS). The router BGP process can retrieve topology from this database and distribute it to an SDN controller by using a new NLRI ( Network Layer reachability Information) encoding format defined in the RFC.

Have a look at the network below:

There are three areas with B, Cand G as  BGP-LS speakers.

For example, G and B can export link state info they learned via IGP into BGP-LS. In this way, C is aware of the TE and  link state info of all the areas.

And the  controller just needs one session with C to know about the complete TE and link state info about all areas.

That way the SDN controller gets all the information about the network from C.

Therefore, in conclusion, the following two processes are needed for the SDN controller to function.

· BGP-LS allows visibility of the network topology and export Traffic engineering info to an SDN controller

· SDN controller uses the knowledge of BGP-LS info  in setting up traffic engineered Paths in MPLS network using PCEP protocol.

What’s next- The multi-layer Optimization of IP and Optics

By implementing centralization in MPLS it would make sense to take the next step towards a converged IP and Optics domain.

There are multiple approaches here.

One is using the GMPLS UNI  with the IP domain requesting the services from the Optical domain using the client-server architecture.

The other approach is to have a separate optical controller that uses optical PCE that can share the optical information ( especially SRLGs ) with the IP controller using standard YANG models. There is active work going on in the IETF to standardize the model for information transfer between the two PCEs.

For those of you interested in reading more about this. Here is the draft link

YANG Data Model for TE Topologies draft-ietf-teas-yang-te-topo-03

Whatever model you follow , the point is that it makes sense to go towards the centralization of MPLS domain using the PCEP and BGP-LS in order to  take a step toward IP/Optics integration but open your MPLS network to more control, service agility and sell value added services ( as mentioned in the beginning)  beyond layer 2 and layer 3 VPNs.

Now it’s your turn to share your opinions in the comment section below on what do you think on this topic.