Emergence of NETCONF - Part 2

This post is part two of a multi-part series on the NETCONF protocol. Today we will detail the steps required to configure a Nokia SROS device through the NETCONF interface using raw XML Remote Procedure Calls.

First we will understand all 4 layers of Netconf and than further we will go into how to make Netconf request to SROS device and response of that request

Secure Transport?- The Secure Transport layer provides, as the name suggests, the means of transport for NETCONF transactions between peers. The core conformity requirements for the transport layer is that it provides a persistent connection, replay protection, authentication and encryption. Two protocols commonly used to carry NETCONF messages are SSH and TLS.

Messages?- The Messages layer provides a well-defined, transport-independent framing mechanism for encoding NETCONF messages. The element name in the Messages layer will describe the message type and will be one of the values shown below.

• <rpc>?- RPC = Remote Procedure Call.
• <rpc-reply>
• <notification>

Operations?- The Operations layer describes the protocol operation invoked and is encapsulated inside the XML message element. A set of base protocol operations exist. Furthermore, clients and servers may extend the base set of protocol operations to allow for a high-level of customization. All operations supported by a client and server are reported to each other at the establishment of a NETCONF session via a capability exchange. All 4 CRUD operations supported by Netconf as well, Create / Delete / Update or Modify / Query. The set of base protocol operations is provided below.

<get>, <get-config>, <edit-config>, <copy-config>, <delete-config>, <lock>

<unlock>, <close-session>, <kill-session>

• Content?- The Content layer consists of XML data encapsulated inside the protocol operation element.
• The NETCONF protocol does not standardize the data inside the Content layer. Instead, NETCONF data models may be designed by anyone using the?RFC 6020?which standardizes the model structure.
• Network device manufacturers implementing the NETCONF interface on their hardware will need to embed YANG data models into their software. These YANG data models may be developed by the manufacturer themselves or they may conform to an open-source specification such as?OpenConfig.

Establishing a NETCONF Session

The NETCONF client and server use the RPC mechanism to communicate with each other. The communication is allowed only after a secure and connection-oriented session is established between them. The client sends an RPC request to the server, and the server returns a reply to the client after processing the request.

SSH transport for NETCONF is supported on TCP port 830 (default) or port 22 with IPv4 or IPv6 in-band in the ?Base” routing instance or in a VPRN, or out-of-band in the ?Management” routing instance on the CPM Ethernet ports.

NETCONF SSH sessions (the same as CLI, SCP, and sFTP sessions) are subject to any configurable and non-configurable session limits; for example, inbound-max-sessions.Both the SSH server and NETCONF protocol must be enabled in the router configuration to use NETCONF.NETCONF sessions do not time out automatically and are not subject to the CLI session timeout. Operators can disconnect sessions manually using the?admin?disconnect?command.

The following example shows a client on a Linux PC or NSP initiating a connection to an?SR?OS?NETCONF server. The SSH session must be invoked using an SSH subsystem (as recommended in RFC 6242).

ssh user_name@netconf_server_ip -p port_number -s netconf        

The following example shows an exchange of hello messages, which include advertisement of capabilities.

From the?SR?OS?server:

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <capabilities>
        <capability>urn:ietf:params:netconf:base:1.0</capability>
        <capability>urn:ietf:params:netconf:base:1.1</capability>
        ...
        ...
    </capabilities>
    <session-id>20</session-id>
</hello>
]]>]]>        

A NETCONF client can reply with a hello message as shown in either of the following:

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <capabilities>
        <capability>urn:ietf:params:netconf:base:1.0</capability>
    </capabilities>
</hello>
]]>]]>

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    <capability>urn:ietf:params:netconf:base:1.1</capability>
  </capabilities>
</hello>
]]>]]>        

The Steps of establishing and terminating a NETCONF session is as follows:

1.????A client (NSP) establishes an?SSH?connection with a server (SROS), and then establishes a NETCONF session with the server after authentication and authorization are complete.

2.????The client and server send Hello messages to negotiate capabilities.

3.????The client sends one or more RPC requests to the server. The following lists some request examples:

·??????Get, Edit and Commit the configuration.

·??????Query the configuration data or status.

·??????Perform maintenance operations on the device.

4.????The client (NSP) terminates the NETCONF session.

5.????The SSH connection is terminated.

NETCONF Message Format

The following figure shows the structure of a complete NETCONF YANG request message.

To retrieve BOF configurations, the ?bof” <configuration-region> must be specified within the <get-config> <source>. For example:

<?xml version="1.0" encoding="UTF-8"?> 
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
  <source>
     <configuration-region>bof</configuration-region>
     <running/>
  </source>
    <filter>
        <bof xmlns="urn:nokia.com:sros:ns:yang:sr:bof-conf">
        </bof>
    </filter>
</get-config>
</rpc>
]]>]]>        

XML encoding is used in NETCONF, allowing complex hierarchical data to be expressed in a text format that can be read, saved, and manipulated with both traditional text tools and XML-specific tools.

we will continue further more details on type of messages ..in next session.