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.
19 thoughts on “Need a quick recipe for SDN in WAN? Mix BGP-LS with PCE”
Very nicely explained & made the concept very simple.
Echo on your point ,two teams managing the two networks talk neither . Can be below:-
MPLS team & Optical Team
MPLS technology & Optical Technology.
I would still say that, seperate controller for IP & Optical is the best choice to reduce complexity. In short, Hierarchial controller including Client controller,IP Domain Controller, Core Transport Domain Controller, Metro Transport Domain Controller, and Operator’s Multilayer Global SDN Controller.
I would like to hear from you on which are all features seperated for optical domain, still debatable.
Looks like, again SDN controller is operator specific and not vendor specific. Why ? Bcos, now a days
equipments specially designed for service provider with specifications provider. Likewise, the story will be for “SDN Controller “.
Thanks Abdul Ravoof,
It depends as both seperate and integrated IP/optical controller work towards achieving same objectives.
BTW, SDN controller is not vendor specific. It is protocol and vendor agnostic.
Always insightful Faisal. Thanks for pulling this together. Good to see we are not reinventing the wheel but instead using the resources available to all. It really is about open source if SDX is to work.
You are right and reinventing the wheel would cost a lot 🙂
Nice article, it’s not an easy task for a single person to have expertise in both fields but its not impossible.
Thanks Javed, the changing times ask for combining this expertise, there are now tools available to help with that.
I see this as yet another informative blog from an informed person.
However I feel that there is a need of a sequel of this blog in which you should introduce some SDN controllers which are good for this task, their pros and cons.
Thanks Abdul Aziz,
I have taken a note of your comments
However for your information the Open daylight controller support these protocols.
Echo on “Abdul Azin Khan’s ” point. Yes, what are different controllers. Below are the one I read about it from Open standard docs:-
IP Domain Controller, Core Transport Domain Controller, Metro Transport Domain Controller, and Operator’s Multilayer Global SDN Controller.
Still practical approach to be learnt and understood on this.
Also, important to know what are all features will moved to controllers…Primary & secondary controllers for each domain like Tier 4 data center which has many redundancy options..
Thanks Abdul Ravoof, For the moment opendaylight controller seems to tackle the IP domain comprehensively. Have a look at the variety of protocols it supports.
Very helpful article. Thank you!
I’m really fascinated about SDN and related technologies.
Would there be any benefits of implementing Segment routing in the IGP domains, along with BGP-LS and PCE?
Thanks, Implementing Segment routing with BGP-LS and PCE can defintely make sense, actually it is recommended. Currently there are two protocols, in radar that can be implemented with BGP-LS/PCE, that is RSVP-TE or Segment routing.
Very nicely written article. I’ve very little knowledge in this area so I have a few queries;
1. If someone wants to implement BGP-LS and PCEP in their network, OpenDayLight would be the only choice as no other controller supports these SB protocols. Are there any open-source controllers supporting various SB protocols?
2. Which hardware device is required to support such a scenario? Afaik, only Cisco IOS-XR and Junos supports BGP-LS and PCEP.
3. I also read that “BGP and OpenFlow are monolithic, meaning they are not used simultaneously”. It means for running BGP, we have to compromise OpenFlow.
Hi Ali, Thanks,
1. ODL is the only one available to my knowledge
2. I think both support.
3. You are correct. But would you really use Openflow in WAN ? At least , not today as openflow has to evolve and is a fork for the network. you are already using BGP so evolution to BGP-LS and PCEP is much easier.
Very Nice article.
I was wondering about using this approach of PCECP+BGP-LS in architectures like seamless MPLS. Do you think this SDN approach could be a used in this architecture, for traffic optimization, for example?
Thank you for visiting website. Yes it would make sense to use BGP and PCEP in seamless MPLS but a word of caution. It needs a traffic engineering protocol.So you should either be using RSVP-TE as signalling protocol or in future Segment routing also. ( but not LDP)
(1)Is it a must for SDN based MPLS, must run PCEP+BGPLS? Any other protocols or methods?
(2)Based on comment above, seems like can use RSVP-TE instead of BGP-LS for TE. So it could be PCEP+RSVPTE? Please correct me.
(3) No LDP? but how about LDPoRSVP? Could you please advise.
Thank you sir.
Hey Faisal!!! Once again excellent & nicely explained technical article by you on upcoming technologies/standards. It is really useful for conceptual understanding of SDN in MPLS domain with application of PCE/BGP-LS.
Trust me you have been doing excellent work of knowledge sharing & making it easier to understand with your unique style.
Please keep it up 🙂
Thanks Rajesh.Glad that the blog benefited you.