Back in 2010 (wow — 10 years ago!), I got involved with implementing something called a Path Computation Element (PCE) and the protocol (PCEP) it uses to communicate with its clients (Path Computation Client or PCC for short).
My journey with PCE began with reading RFC 4655 and RFC 5440, which describe the PCE architecture and protocol. The PCE Working Group (WG) goes way back to 2005 when it was chartered to produce the architecture and protocol for path computation in MPLS and GMPLS networks. I did the humble thing of subscribing to the PCE WG mailing list right about then.
I found the WG discussing exciting new use cases, from path computation in WSON, IP+Optical inter-layer path computation, multicast, and much more. I saw value in this and started experimenting with proof of concept of these exciting new use cases and proposed some new ideas myself.
My first IETF meeting was IETF 78 in Maastricht, Netherlands. It was surreal to see all the folks whose RFCs and drafts I had implemented right there in person. I had to remind myself that I belong and they all would have started just like me. I was blown away with the technical knowledge and passion with which the IETF worked and I wanted to be part of it.
Over the years, I proposed new ideas and collaborated with a lot of folk on these, some of them becoming RFCs. I also contributed back as a WG secretary over the years and later became the WG Co-Chair. I have seen the humble beginnings of this technology as well as its potential. One such potential was adding state to the PCE.
Stateful PCE and Segment Routing
Even though the PCE could do complex path computation based on various constraints and optimization criteria, it could only respond to a request by the client. Moreover, it also did not maintain the state of those paths (called LSPs) in the network.
A Stateful PCE on the other hand maintains the database of all the paths in the network and uses it along with the network topology traffic engineering database while doing path computation. PCEP also allowed a client to delegate control over the LSP to a PCE, allowing it to update the path at any time. A mechanism for PCE to initiate LSP all on its own was also added.
At the same time, the IETF was also working on a new source routine technique called Segment Routing (SR). The SR path, which in the case of the MPLS data-plane is represented as a label stack, needs to be computed beforehand, and the use of PCE was an ideal fit. The ubiquitous path computation is required in all sorts of traffic engineering networks and thus PCE finds its use case from flex-grid to SRv6.
PCE at the heart of SDN
Another interesting buzz in the networking world was Software-Defined Networking (SDN). Some saw it as a clear separation of the control-plane from the forwarding plane, whereas some saw it as network automation and programmability. Those of us working in PCE found the concept eerily similar to the idea of a stateful PCE and envisioned PCE at the heart of any SDN controller (see RFC 7491).
We also looked at the PCEP and compared it to the SDN’s southbound interface (SBI). That provided us with interesting ideas and we worked on PCE as a central controller architecture and some interesting use cases for label allocation instructions from the PCE to all nodes along the path. Further, the use of PCEP to identify and assign flows to paths was another interesting SBI feature that was added.
It has been an interesting journey of PCE and SDN. The idea of a dumb network device (devoid of any control-plane) is almost abandoned, a lesson that the PCE could have easily taught. Whereas the use of PCE as not just a computation engine but also capable of apprising myriads of instructions to the network nodes and thus enabling the use of PCE in many new use cases is something that we have SDN to thank for.
Get involved in making RFCs
Let me be explicit. With this post I wanted to achieve two things:
- Inspire those who read and consume RFCs as implementers, operators, or academics, that they should also participate in creating RFCs. Participating can take the form of mailing list discussions, reviewing drafts, as well as collaborating on new ideas.
- Share the journey of PCE and its entanglement with the buzz around SDN.
Reach out to me at dhruv.ietf at gmail.com if I failed (or succeeded) in the above.
Dhruv Dhody, Co-Chair of the PCE WG at the IETF.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.