Jump to content

NETCONF: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Aggplanta (talk | contribs)
External links: Yang-central is a dead link
Line 84: Line 84:
* [http://code.google.com/p/pyang/ pyang: Open Source YANG compiler]
* [http://code.google.com/p/pyang/ pyang: Open Source YANG compiler]
* [http://www.netconfcentral.org Netconf Central: NETCONF information and tutorials]
* [http://www.netconfcentral.org Netconf Central: NETCONF information and tutorials]
* [http://www.yang-central.org/twiki/bin/view/Main/WebHome Yang Central: YANG tutorials, and freely available YANG and DSDL tools]
* [http://www.ietf.org/rfc/rfc5381.txt RFC 5381: Experience of Implementing NETCONF over SOAP]
* [http://www.ietf.org/rfc/rfc5381.txt RFC 5381: Experience of Implementing NETCONF over SOAP]
* [https://github.com/Juniper-Workflow/net-netconf Ruby NETCONF: A Ruby gem for NETCONF]
* [https://github.com/Juniper-Workflow/net-netconf Ruby NETCONF: A Ruby gem for NETCONF]

Revision as of 21:10, 30 January 2013

The Network Configuration Protocol, NETCONF, is an IETF network management protocol. It was developed in the NETCONF working group and published in December 2006 as RFC 4741 and later revised in June 2011 and published as RFC 6241. The NETCONF protocol specification is an Internet Standards Track document.

NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices. Its operations are realized on top of a simple Remote Procedure Call (RPC) layer. The NETCONF protocol uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages. This in turn is realized on top of the transport protocol.

The NETCONF protocol can be conceptually partitioned into four layers:

       Layer                            Example
   +-------------+      +-------------------------------------------+
   |   Content   |      |     Configuration data                    |
   +-------------+      +-------------------------------------------+
             |                           |
   +-------------+      +-------------------------------------------+
   | Operations  |      |<get-config>, <edit-config>, <notification>|
   +-------------+      +-------------------------------------------+
             |                           |                    |
   +-------------+      +-----------------------------+       |
   |     RPC     |      |    <rpc>, <rpc-reply>       |       |
   +-------------+      +-----------------------------+       |
             |                           |                    |
   +-------------+      +-------------------------------------------+
   |  Transport  |      |   BEEP, SSH, SSL, console                 |
   |  Protocol   |      |                                           |
   +-------------+      +-------------------------------------------+

SVG format: File:NETCONF-layers.svg

Operations

Basic Operations

The base protocol includes the following protocol operations: <get>, <get-config>, <edit-config>, <copy-config>, <delete-config>, <lock>, <unlock>, <close-session>, <kill-session>.

Capabilities

Basic NETCONF functionality can be extended by the definition of NETCONF capabilities. The set of additional protocol features that an implementation supports is communicated between the server and the client during the capability exchange portion of session setup. Mandatory protocol features are not included in the capability exchange since they are assumed. RFC 4741 defines a number of optional capabilities including :xpath and :validate. Note that RFC 6241 obsoletes RFC 4741.

A capability to support subscribing and receiving asynchronous event notifications is published in RFC 5277. This document defines the <create-subscription> operation, which enables creating real-time and replay subscriptions. Notifications are then sent asynchronously using the <notification> construct. It also defines the :interleave capability, which when supported with the basic :notification capability facilitates the processing of other NETCONF operations while the subscription is active.

A capability to support partial locking of the running configuration is defined in RFC 5717. This allows multiple sessions to edit non-overlapping sub-trees within the running configuration. Without this capability, the only lock available is for the entire configuration.

A capability to monitor the NETCONF protocol is defined in RFC 6022. This document contains a data model including information about NETCONF datastores, sessions, locks, and statistics that facilitates the management of a NETCONF server. It also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines the <get-schema> operation to retrieve them.

Transport Protocols

NETCONF defines four transport mappings

  • SSH (RFC 4742), which is mandatory to implement
  • SOAP (RFC 4743)
  • BEEP (RFC 4744)
  • TLS (RFC 5539)

Content

The content of NETCONF operations is well-formed XML. Most content is related to network management.

The NETMOD working group has completed work to define a "human-friendly" modeling language for defining the semantics of operational data, configuration data, notifications, and operations, called YANG. YANG is defined in RFC 6020, and is accompanied by the "Common YANG Data Types" found in RFC 6021.

During the summer of 2010, the NETMOD working group was re-chartered to work on core configuration models (system, interface, and routing) as well as work on compatibility with the SNMP modeling language.

History

The IETF developed SNMP in the late 1980s and it proved to be a very popular network management protocol. In the early part of the 21st century it became apparent that in spite of what was originally intended, SNMP was not being used to configure network equipment, but was mainly being used for network monitoring. In 2002, the Internet Architecture Board and key members of the IETF's network management community got together with network operators to discuss the situation. The results of this meeting are documented in RFC 3535. It turned out that operators were primarily using proprietary Command Line Interfaces (CLI) to configure their boxes. This had a number of features that the operators liked, including the fact that it was text-based, as opposed to the BER-encoded SNMP. In addition, many equipment vendors did not provide the option to completely configure their devices via SNMP. As operators generally liked to write scripts to help manage their boxes, they did find the CLI lacking in a number of ways. Most notably was the unpredictable nature of the output. The content and formatting of output was prone to change in unpredictable ways.

Around this same time, Juniper Networks had been using an XML-based network management approach. This was brought to the IETF and shared with the broader community.

Collectively, these two events led the IETF to the creation of a protocol which it hopes will better align with the needs of network operators and equipment vendors.

See also