In this article we explore the architecture of NETCONF and YANG.  Much of the information presented in this article is derived from RFC 4741, “NETCONF Configuration Protocol”.

Introduction

The Network Configuration (NETCONF) protocol is designed as a simple mechanism through which the configuration data residing on a network device may be inspected and manipulated. The NETCONF protocol uses the abstraction of operations with parameters to facilitate the development of applications for configuration management of network devices.

Within the NETCONF architecture, there exist two peer roles: the NETCONF client and the NETCONF server.

The client role is fulfilled by a person or a management application.  The client is responsible for the configuration management of some number of network devices.  The server role is fulfilled by software residing on a network device.  The server is responsible for the exchange of NETCONF messages and for the orderly manipulation of local configuration data.

In order to exchange NETCONF messages, a client must first establish a NETCONF session with a server.  When a session is established, each NETCONF peer exchanges a list of its capabilities with the other peer.

A NETCONF capability is represented by a uniform resource name (URN).  Each capability corresponds to a set of features supported by a NETCONF peer.  A feature may provide support for an RPC operation or specify the semantics for parameters associated with an RPC operation.

The concept of capabilities is a powerful tool and enables the extensibility of the NETCONF protocol.  The base NETCONF capability is the minimum set of features each a NETCONF peer must implement, represented as “urn:ietf:params:netconf:base:1.0”.

NETCONF Protocol Layers

The NETCONF protocol can be conceptually partitioned into four layers.

Messages exchanged on a NETCONF session between a client and server pass through each layer.  We discuss the purpose of each layer within the NETCONF protocol in the following sections.

The Transport Protocol Layer

The transport protocol layer provides an end-to-end network connection for the exchange of messages between a client and a server.  Section 2 of RFC 4741 discusses requirements of the transport protocol layer.

The transport protocol provides the following features:

  • indicates the session type: client or server
  • connections are persistent, durable and stateful
  • reliably delivers an ordered sequence of messages
  • releases resources associated with a session when its connection terminates
  • responsible for user authentication

A NETCONF implementation must support the SSH transport protocol mapping.  The NETCONF mapping for SSH is specified in RFC 4742.  Optional transport mappings include console shell, and TLS (RFC 5539).

The RPC Layer

Tje RPC layer provides a communication model for framing NETCONF requests and responses. Section 4 of RFC 4741 discusses requirements of the RPC layer.

NETCONF requests use an <rpc> element and NETCONF replies use an <rpc-reply> element.  The <rpc> element within a NETCONF request contains a mandatory “message-id” attribute and may contain any optional attributes useful to the client.  The “message-id” attribute facilitates the correlation of a request with its response.  The <rpc-reply> element of a NETCONF response always contains an unmodified copy of the set of attributes present in the <rpc> element of the corresponding NETCONF request.

The RPC operation name and its parameters are encoded as the content within the <rpc> element.

When the result of an RPC operation contains errors, one or more <rpc-error> elements are present within the <rpc-reply> element of the response.  Each <rpc-error> element describes an error encountered during processing of the RPC operation.  When the result of an RPC operation is free of error, an <ok> element is present within the <rpc-reply> element of the response.

Once a NETCONF session is established, a client may send multiple requests to the server without waiting for a reply.  A NETCONF server responds to each request in the order it was received.

The Operations Layer

The operations layer provides a mechanism for the proper handling of NETCONF operations present within requests and for the proper handling of reply content present within responses.  Section 7 of RFC 4741 discusses requirements of the operations layer.

The NETCONF protocol base capability defines a small set of operations and associated parameters for the inspection and manipulation of configuration data.  The NETCONF protocol base capability is extensible.  A client or server that supports additional operations or parameters will advertise its extensions in its capabilities exchange when establishing a NETCONF session.

Each <rpc> element in a request contains a NETCONF operation name and an associated set of XML-encoded parameters. The following table summarizes the set of operations in the NETCONF protocol base capability.

operation name operation purpose
get retrieve the running configuration and state information
get-config retrieve all or a portion of a configuration datastore
edit-config load all or part of a source configuration into a target configuration datastore
copy-config create or replace an entire target configuration datastore with a complete source configuration
delete-config delete the contents of a configuration datastore
lock lock a configuration datastore for exclusive edits by a client
unlock release the lock on a configuration datastore
close-session gracefully terminate a NETCONF session
kill-session forcefully terminate a NETCONF session

Operations Supported by NETCONF 1.0 Base Capability

We will revisit NETCONF operations and associated parameters in a future article.

The Content Layer

The content layer provides the NETCONF protocol with a mechanism for encapsulating configuration data. Section 5 of RFC 4741 discusses requirements of the content layer.

Configuration data associated with a NETCONF operation is XML-encoded within a <config> element.  On a network device,  configuration data resides within a configuration datastore.

Proper configuration data is constrained by the semantics of the YANG schema defined for a network device.  The YANG data modeling language, currently a work-in-progress of the IETF NETMOD working group, was created primarily to address the needs of modeling the configuration and state data conveyed by the NETCONF protocol.

A YANG schema defines a set of data nodes organized as a hierarchical tree.  Each data node in the tree has a name and either a value or a set of child nodes.  YANG schema are structured into modules and submodules that  may be published by a standards organization, an enterprise or an industry forum.

A key design feature of YANG is its support for modular extensibility.  One YANG module may define additional data nodes augmenting the data nodes defined in another YANG module.

Since configuration data is specific to the data model of a network device, the NETCONF protocol does not inspect or manipulate configuration data.  The set of YANG modules defining the schema of a network device is identified within the list of capabilities sent by its server to a client when a NETCONF session is established.

The NETCONF client can subsequently retrieve and inspect the YANG schema for a network device to gain an understanding of the layout, containment, keying and other semantic constraints imposed upon the configuration and state data exchanged with a NETCONF server.  Note that the schema for a network device can be fully mapped from YANG to other XML based schema languages, such as DSDL to facilitate validation tasks.

The <get> and <get-config> NETCONF operations support subtree filtering when a <filter> element is present.  Subtree filtering enables a client to limit the data returned by a server to the set of subtrees matching the filter expression.

There are five types of components that may be present in a subtree filter:

  • Namespace Selection
  • Attribute Match Expressions
  • Containment Nodes
  • Selection Nodes
  • Content Match Nodes

An optional extension allows filters to use XPATH expressions.

Using the YANG data modeling language to create schema and using the NETCONF subtree filtering mechanisms to match portions of the schema tree are interesting topics that we will revisit in future articles.

This article is part of a series of articles. To view other articles in this series please follow the NETCONF and YANG tag.