The Current State of SDN Protocols

In last week’s blog post I started outlining the various standards needed to make SDN a reality. Here is more detail about the relevant protocols and the IETF’s progress on each one.

OpenFlow has emerged as a Layer 2 software defined networking (SDN) southbound protocol. Similarly, Path Computation Element Protocol (PCEP), BGP Link State Distribution (BGP-LS), and NetConf/YANG are becoming the de-facto SDN southbound protocols for Layer 3. The problem is that these protocols are stuck in various draft forms that are not interoperable, which limits the industry’s SDN progress. 

Path Computation Element Protocol (PCEP) 

PCEP is used for communicating Label Switched Paths (LSPs) between a Path Computation Client (PCC) and a Path Computation Element (PCE). PCEP has been in use since 2006. The stateful [draft-ietf-pce-stateful-pce] and PCE-initiated LSP [draft-ietf-pce-pce-initiated-lsp] extensions were added more recently and enable PCEP use for SDN deployments. The IETF drafts for both extensions have not yet advanced to “Proposed Standard” status after more than two years. 

Because the drafts went through many significant revisions, vendors are struggling to keep up with the changes in their release cycles. Major vendors and SDN controllers support the following two implementations: 

[1] draft-ietf-pce-stateful-pce-02 and draft-crabbe-pce-pce-initiated-lsp-00
[2] draft-ietf-pce-stateful-pce-07 and draft-ietf-pce-pce-initiated-lsp-00 

These two versions are not interoperable. As a result, SDN orchestration applications, such as our Network Access Broker (NAB), face a challenge in supporting multi-vendor networks. In addition, neither extension provides the bells and whistles that CLI could provide. For example, it is possible to set up a tunnel, but it is not yet possible to associate that tunnel to protect a link or a node in the network. 

BGP Link State (BGP-LS) 

Link State extension has been added to BGP to share network link state and traffic engineering topologies with external entities, such as the SDN controller. The extension is defined in draft-ietf-idr-ls-distribution. 

Like PCEP, this draft has been in draft status for more than two years. Vendors have found it difficult to reconcile its mergers and multiple revisions. The current supported version is draft-ietf-idr-ls-distribution-05. The interoperability report for various vendors and controllers is published in draft-ietf-idr-ls-distribution-impl-00. 

NetConf / YANG 

The IETF NETMOD working group defined the data modeling language YANG, which can be used to specify network management data models that are manipulated by the NETCONF protocol. The domain-specific YANG specifications are being developed in their respective working groups. The following are the significant YANG models that are being discussed and used in the community. 

[1] draft-ietf-i2rs-rib-info-model in the I2RS working group
[2] draft-clemm-i2rs-yang-network-topo used in the open-source SDN OpenDaylight project. [Also see http://www.ietf.org/proceedings/89/slides/slides-89-i2rs-11.pdf]
[3] Yang Models in GitHub for speedier review and adoption

Moving Ahead 

We need to advance these protocol definitions to “standards” (or at least close enough to being appropriate for wide-scale adoption) as soon as possible so that we can achieve interoperable implementations. We then (or in parallel) need to incorporate them into the various SDN controllers, including OpenDaylight. We will then be able to compute a tunnel using the data exported by BGP-LS, signal a tunnel using PCEP, and associate it to protect a node or a link using the NetConf protocol and YANG configuration models. This will represent a major step forward in realizing the benefits of SDN.