This project hosts implementations of protocols defined by the IETF NETCONF Working Group. In particular, it implements:
Your immediate interests may be:
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:
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.
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 read RFC8040 as if it included equivalent to Figure 1 as:
Every HTTP Connection is tied to its underlying transport as per RFC9110 specification of the two HTTP URI schemes:
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 | | | +-------------+ +-----------------------------------------+- 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
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