OpenDaylight NETCONF/RESTCONF implementation

This project hosts implementations of protocols defined by the IETF NETCONF Working Group. In particular, it implements:

• Network Configuration Protocol (NETCONF)
• RESTCONF Protocol

Your immediate interests may be:

• Documentation is in docs
• Ready-to-use applications are in apps

NETCONF/RESTCONF protocol layer assumptions

The code in this repository is organized roughly along the lines of NETCONF Protocol Layers. For the purposes of this implementation, we are making three distinct assuptions:

• RFC6241 Figure 1 looks like this:

            Layer                 Example
       +-------------+      +-----------------+      +----------------+
   (4) |   Content   |      |  Configuration  |      |  Notification  |
       |             |      |      data       |      |      data      |
       +-------------+      +-----------------+      +----------------+
              |                       |                      |
       +-------------+      +-----------------+              |
   (3) | Operations  |      |  <edit-config>  |              |
       |             |      |                 |              |
       +-------------+      +-----------------+              |
              |                       |                      |
       +-------------+      +-----------------+      +----------------+
   (2) |  Messages   |      |     <rpc>,      |      | <notification> |
       |             |      |   <rpc-reply>   |      |                |
       +-------------+      +-----------------+      +----------------+
              |                       |                      |
       +-------------+      +-----------------------------------------+
   (1) |   Secure    |      |  SSH, TLS, *TCP*                        |
       |  Transport  |      |                                         |
       +-------------+      +-----------------------------------------+
  

  We provide TCP for completeness and logical Netty pipeline structure: a Channel corresponds to the TCP transport and SSH and TLS are built on top of it by adding the corresponding ChannelHandlers.
• we read RFC8040 as if it included equivalent to Figure 1 as:

            Layer                 Example
       +-------------+      +-----------------+      +----------------+
   (4) |   Content   |      |  Configuration  |      |  Notification  |
       |             |      |      data       |      |      data      |
       +-------------+      +-----------------+      +----------------+
              |                       |                      |
       +-------------+      +-----------------+      +----------------+
   (3) | Operations  |      | PUT             |      |  Server-Sent   |
       |             |      |  /restconf/data |      |    Events      |
       +-------------+      +-----------------+      +----------------+
              |                       |                      |
       +-------------+      +-----------------------------------------+
   (2) |  Messages   |      |  HTTP Message                           |
       |             |      |                                         |
       +-------------+      +-----------------------------------------+
              |                       |                      |
       +-------------+      +-----------------------------------------+
   (1) |   Secure    |      |  HTTP Connection                        |
       |  Transport  |      |                                         |
       +-------------+      +-----------------------------------------+
  

  Every HTTP Connection is tied to its underlying transport as per RFC9110 specification of the two HTTP URI schemes:
  • http:// connections are built on top of TCP transport
  • https:// connections are built on top of TLS transport The object model for HTTP Message comes from Netty and is catered for by the channel pipeline, including any upgrades from HTTP/1 in a manner similar to how NETCONF negotiates its framing mechanism over both SSH and TLS. An HTTP client does not imply TCP connect, an HTTP server does not imply TCP listen -- we want to include the support call-home, where a network element (a RESTCONF server) is the first one to initiate the contact to its a network controller (a RESTCONF client).
• the two protocol implementations:
  • share the Content layer, centered around YANG Tools' NormalizedNode and surrounding infrastructure
  • share the Secure Transport layer configuration object model
  • do each their own thing at Messages and Operations layers
  • do not aim for NETCONF over HTTP requests
  • do not aim for RESTCONF over SSH channels

The gory details

There are sorts of things here:

• basic project infrastructure, including the BOM, Karaf features, Dynamic Karaf distribution, Static Karaf distribution and the Common Maven Parent
• YANG models relating to this project
• IETF Key Store implementation
• IETF Trust Store implementation
• Secure Transport layer implementation
• Low-level protocol implementations
• High-level protocol integrations, notably with MD-SAL
• a handful of unsorted things, both NETCONF-related and RESTCONF-related