NETCONF

Layer Example 1 History

Content Configuration Data Notification Data

The IETF developed the Simple Network Management

Operations <edit-config>, ...
Protocol (SNMP) in the late 1980s and it proved to be a
Messages <rpc>, <rpc-reply> <notification> very popular network management protocol. In the early
part of the 21st century it became apparent that in spite of
Secure
Transport SSH, TLS, (BEEP/TLS), (SOAP/HTTP/TLS), ... what was originally intended, SNMP was not being used
to congure network equipment, but was mainly being
used for network monitoring. In June 2002, the Internet
NETCONF protocol layers. Architecture Board and key members of the IETFs net-
work management community got together with network
operators to discuss the situation. The results of this
The Network Conguration Protocol (NETCONF) is
meeting are documented in RFC 3535. It turned out that
a network management protocol developed and standard-
operators were primarily using proprietary Command
ized by the IETF. It was developed in the NETCONF
Line Interfaces (CLI) to congure their devices. This had
working group[1] and published in December 2006 as
a number of features that the operators liked, including
RFC 4741[2] and later revised in June 2011 and published
the fact that it was text-based, as opposed to the BER-
as RFC 6241[3] . The NETCONF protocol specication
encoded SNMP. In addition, many equipment vendors
is an Internet Standards Track document.
did not provide the option to completely congure their
NETCONF provides mechanisms to install, manipulate, devices via SNMP. As operators generally liked to write
and delete the conguration of network devices. Its op- scripts to help manage their boxes, they found the CLI
erations are realized on top of a simple Remote Proce- lacking in a number of ways. Most notably was the unpre-
dure Call (RPC) layer. The NETCONF protocol uses an dictable nature of the output. The content and formatting
Extensible Markup Language (XML) based data encod- of output was prone to change in unpredictable ways.
ing for the conguration data as well as the protocol mes-
Around this same time, Juniper Networks had been using
sages. The protocol messages are exchanged on top of a
an XML-based network management approach. This was
secure transport protocol.
brought to the IETF and shared with the broader commu-
The NETCONF protocol can be conceptually partitioned nity. Collectively, these two events led the IETF in May
into four layers: 2003 to the creation of the NETCONF working group.
This working group was chartered to work on a network
conguration protocol, which would better align with the
1. The Content layer consists of conguration data and
needs of network operators and equipment vendors. The
notication data.
rst version of the base NETCONF protocol was pub-
lished as RFC 4741 in December 2006. Several exten-
2. The Operations layer denes a set of base protocol
sions were published in subsequent years (notications in
operations to retrieve and edit the conguration data.
RFC 5277 in July 2008, partial locks in RFC 5717 in De-
3. The Messages layer provides a mechanism for en- cember 2009, with-defaults in RFC 6243 in June 2011,
coding remote procedure calls (RPCs) and notica- system notications in RFC 6470 in February 2012, ac-
tions. cess control in RFC 6536 in March 2012). A revised
version of the base NETCONF protocol was published
4. The Secure Transport layer provides a secure and as RFC 6241 in June 2011.
reliable transport of messages between a client and
a server.
2 Protocol layers
The NETCONF protocol has been implemented in net-
work devices such as routers and switches by some ma- 2.1 Content
jor equipment vendors. One particular strength of NET-
CONF is its support for robust conguration change using The content of NETCONF operations is well-formed
transactions involving a number of devices. XML. Most content is related to network management.

1
2 4 REFERENCES

Subsequently support for encoding in JavaScript Object RPC invocations (<rpc> messages),
Notation (JSON) was also added.
RPC results (<rpc-reply> messages), and
The NETMOD working group has completed work to
dene a human-friendly modeling language for den- event notications (<notication> messages).
ing the semantics of operational data, conguration data,
notications, and operations, called YANG. YANG is de- Every NETCONF message is a well-formed XML doc-
ned in RFC 6020, and is accompanied by the Common ument. An RPC result is linked to an RPC invocation
YANG Data Types found in RFC 6021. by a message-id attribute. NETCONF messages can be
During the summer of 2010, the NETMOD working pipelined, i.e., a client can invoke multiple RPCs without
group was re-chartered to work on core conguration having to wait for RPC result messages rst. RPC mes-
models (system, interface, and routing) as well as work sages are dened in RFC 6241 and notication messages
on compatibility with the SNMP modeling language. are dened in RFC 5277.

2.4 Secure Transports

2.2 Operations
NETCONF messages are exchanged using secure trans-
The base protocol denes the following protocol opera- ports. A secure transport must provide authentication,
tions: data integrity, condentiality, and replay protection. The
Basic NETCONF functionality can be extended by the mandatory to implement secure transport is NETCONF
denition of NETCONF capabilities. The set of addi- over SSH (RFC 6242). RFC 5539 denes a secure trans-
tional protocol features that an implementation supports port using TLS. Two additional secure transports, namely
is communicated between the server and the client during NETCONF over SOAP (RFC 4743) and NETCONF
the capability exchange portion of session setup. Manda- over BEEP (RFC 4744) were originally dened but later
tory protocol features are not included in the capability declared historic.
exchange since they are assumed. RFC 4741 denes a
number of optional capabilities including :xpath and :val-
idate. Note that RFC 6241 obsoletes RFC 4741. 3 See also
A capability to support subscribing and receiving asyn-
chronous event notications is published in RFC 5277. YANG
This document denes the <create-subscription> oper- Network management
ation, which enables creating real-time and replay sub-
scriptions. Notications are then sent asynchronously us- Conguration management
ing the <notication> construct. It also denes the :in-
terleave capability, which when supported with the basic Network monitoring
:notication capability facilitates the processing of other XML Schema
NETCONF operations while the subscription is active.
A capability to support partial locking of the running con-
guration is dened in RFC 5717. This allows multiple 4 References
sessions to edit non-overlapping sub-trees within the run-
ning conguration. Without this capability, the only lock [1] Network Conguration Working Group. IETF.
available is for the entire conguration.
[2] Enns, Rob (2006). NETCONF Conguration Proto-
A capability to monitor the NETCONF protocol is de- col (Technical report). IETF. doi:10.17487/RFC4741.
ned in RFC 6022. This document contains a data model RFC4741.
including information about NETCONF datastores, ses-
sions, locks, and statistics that facilitates the management [3] Enns, Rob; Bjrklund, Martin; Schnwlder, Jr-
of a NETCONF server. It also denes methods for NET- gen; Bierman, Andy (2011). Network Congura-
tion Protocol (NETCONF) (Technical report). IETF.
CONF clients to discover data models supported by a
doi:10.17487/RFC6241. RFC6241.
NETCONF server and denes the <get-schema> oper-
ation to retrieve them.

2.3 Messages

The NETCONF messages layer provides a simple,

transport-independent framing mechanism for encoding
 3

5 Text and image sources, contributors, and licenses

5.1 Text
NETCONF Source: https://en.wikipedia.org/wiki/NETCONF?oldid=761700849 Contributors: Greenrd, Madduck, Bobo192, John Van-
denberg, Mandarax, FlaBot, Anrie Nord, Diogenes00, Mellowiz, Bluebot, Frap, Chiz@sympatico.ca, Mazzid, Dougher, AlephGamma,
Hardaker, Vjardin, Lukeritchie, Duncanscottsharp, Addbot, Aggplanta, Bunnyhop11, Omnipaedista, Cmoberg, VS6507, Carapeto, Je-
Morriss, Rabbabodrool, Hiro42, PaulSCrook, Partain, BG19bot, IluvatarBot, MatjazVrecko, Cejkat, ArmbrustBot, EE1G, Radek.krejci,
Schoenw, Waihtai, Mjethanandani and Anonymous: 25

5.2 Images
File:Ambox_important.svg Source: https://upload.wikimedia.org/wikipedia/commons/b/b4/Ambox_important.svg License: Public do-
main Contributors: Own work, based o of Image:Ambox scales.svg Original artist: Dsmurat (talk contribs)
File:NETCONF-layers.svg Source: https://upload.wikimedia.org/wikipedia/commons/2/2f/NETCONF-layers.svg License: Public do-
main Contributors: http://tools.ietf.org/html/rfc6241 Original artist: Tomas Cejka
File:Question_book-new.svg Source: https://upload.wikimedia.org/wikipedia/en/9/99/Question_book-new.svg License: Cc-by-sa-3.0
Contributors:
Created from scratch in Adobe Illustrator. Based on Image:Question book.png created by User:Equazcion Original artist:
Tkgd2007
File:Text_document_with_red_question_mark.svg Source: https://upload.wikimedia.org/wikipedia/commons/a/a4/Text_document_
with_red_question_mark.svg License: Public domain Contributors: Created by bdesham with Inkscape; based upon Text-x-generic.svg
from the Tango project. Original artist: Benjamin D. Esham (bdesham)

5.3 Content license

Creative Commons Attribution-Share Alike 3.0