Internet DRAFT - draft-schoenw-netconf-light
draft-schoenw-netconf-light
Network Working Group V. Perelman
Internet-Draft J. Schoenwaelder
Intended status: Standards Track Jacobs University
Expires: July 21, 2012 M. Ersue
Nokia Siemens Networks
K. Watsen
Juniper Networks
January 18, 2012
Network Configuration Protocol Light (NETCONF Light)
draft-schoenw-netconf-light-01.txt
Abstract
This document describes a profile of the NETCONF protocol called
NETCONF Light. This profile modularizes the NETCONF protocol and
allows devices to announce that they only support a subset of the
NETCONF protocol operations. This is useful in situations where
devices are either too resource constrained to support all NETCONF
operations or where devices are gradually updated from proprietary
configuration interfaces to support NETCONF.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 21, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Perelman, et al. Expires July 21, 2012 [Page 1]
Internet-Draft NETCONF Light January 2012
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. NETCONF on Constrained Devices . . . . . . . . . . . . . . 4
2.2. Gradually Adding NETCONF Support . . . . . . . . . . . . . 4
3. NETCONF Light Overview . . . . . . . . . . . . . . . . . . . . 6
3.1. Reduced Protocol Operations . . . . . . . . . . . . . . . 6
3.1.1. <get-config> . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. <edit-config> . . . . . . . . . . . . . . . . . . . . 7
3.1.3. <copy-config> . . . . . . . . . . . . . . . . . . . . 7
3.1.4. <delete-config> . . . . . . . . . . . . . . . . . . . 7
3.1.5. <lock> and <unlock> . . . . . . . . . . . . . . . . . 7
3.1.6. <get> . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.7. <close-session> . . . . . . . . . . . . . . . . . . . 8
3.1.8. <kill-session> . . . . . . . . . . . . . . . . . . . . 8
3.2. Capability Negotiation . . . . . . . . . . . . . . . . . . 8
4. NETCONF Light YANG Module . . . . . . . . . . . . . . . . . . 10
5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. NETCONF Light on AVR Raven / Contiki . . . . . . . . 17
Appendix B. Experience at Juniper Networks . . . . . . . . . . . 18
Perelman, et al. Expires July 21, 2012 [Page 2]
Internet-Draft NETCONF Light January 2012
1. Introduction
The Network Configuration Protocol (NETCONF) [RFC6241] provides
mechanisms to install, manipulate, and delete the configuration of
network devices. This document modularizes the NETCONF protocol and
allows devices to announce that they only support a subset of the
NETCONF protocol operations. This is useful in situations where
devices are either too resource constrained to support all NETCONF
operations or where devices are gradually updated from proprietary
configuration interfaces to support NETCONF.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Perelman, et al. Expires July 21, 2012 [Page 3]
Internet-Draft NETCONF Light January 2012
2. Motivation
This section explains the motiviation for NETCONF Light.
2.1. NETCONF on Constrained Devices
The original target of NETCONF were network devices such as routers
or switches that usually have plenty of resources for running a
NETCONF server. However, there are a number of embedded systems
where resources (most notably memory) are tight and hence such
devices can only afford a subset of the NETCONF protocol operations.
This document allows constrained devices to implement a subset of
NETCONF and to communicate that subset to NETCONF management
applications in an interoperable way.
The usage of NETCONF Light on resource constrained devices is
attractive in environments where management applications have to deal
with a wide range of different devices, for example ranging from very
small embedded networked sensors over more powerful data aggregation
servers up to highly complex control networks. Typical examples are
Smart Grids or more general industrial control networks.
Constrained devices can be classified according to the memory they
have. A recently proposed classification is the following:
o Class 0: too small to securely run on the Internet (too
constrained).
o Class 1: about 10 KiB of data and 100 KiB of code (quite
constrained, 10/100)
o Class 2: about 50 KiB of data and 250 KiB of code (not so
constrained, 50/250)
According to these classes, NETCONF Light should be running fine in
"not so constrained" Class 2 devices and it may be running in "quite
constrained" Class 1 devices, with very little resources left for
other application code.
2.2. Gradually Adding NETCONF Support
While the NETCONF protocol defines a number of capabilities that may
be optionally implemented, the base protocol remains a significant
effort to add for existing devices. For these devices, adding
support for NETCONF is primarily driven by a specific integration
target, thus the intrinsic goal is to have an initial release that
satisfies the integration target and a subsequent release that
implements the remainder of the NETCONF protocol.
Perelman, et al. Expires July 21, 2012 [Page 4]
Internet-Draft NETCONF Light January 2012
Some scenarios where phasing in the imeplmentation would be helpful
include:
o The device's primary goal is to implement a vendor-specific
capability. In this case, the device is only using NETCONF for
its "Messages" layer (i.e. RPC, RPC-reply, and Notification).
o The device's primary goal is to just support read-only access to
its configuration. In this case, it only needs to implement <get-
config> initially, leaving the remaining operations for a future
release.
o The device's primary goal is to enable full configuration, but it
doesn't have the time to implement all the <edit-config>
operations. In this case, the device could implement just <copy-
config>.
o The device's primary goal is to enable full configuration, but it
is unable to implement <lock> or <unlock> due to its platform not
having a locking mechanism yet.
Each of these cases is satisfied by NETCONF Light, as the device can
adverise the specific subset of NETCONF operations it supports. The
ability for development teams to incrementally implement NETCONF
makes it a more appealing target for their short-term efforts.
Perelman, et al. Expires July 21, 2012 [Page 5]
Internet-Draft NETCONF Light January 2012
3. NETCONF Light Overview
NETCONF Light uses the NETCONF message framing as defined in
[RFC6241]. In particular, it uses the same XML encoding and XML
namespace.
The NETCONF specification [RFC6241] defines a set of base operations
and a number of optional capabilities. A NETCONF Light
implementation may choose to not support all NETCONF base operations.
The set of operations supported by a NETCONF Light server is
announced to a NETCONF client as features, see the definition of the
ietf-netconf-light YANG [RFC6020] module in Section 4.
A NETCONF Light implementation, like any NETCONF implementation, does
not have to support any of the optional NETCONF capabilities. The
normal NETCONF rules apply for the capability exchange with <hello>
messages.
A NETCONF Light implementation may support only a limited number of
concurrent sessions. On some devices, the number of concurrent
sessions might be as low as one. A NETCONF Light implementation
supporting only a limited number of sessions should reject the
establishment of a new transport, i.e., it should not even start the
NETCONF <hello> exchange.
3.1. Reduced Protocol Operations
The following sections describe the changes to the NETCONF base
protocol operations.
3.1.1. <get-config>
A NETCONF Light implementation MAY choose to not support the <get-
config> operation as defined in Section 7.1 of [RFC6241].
Furthermore, a NETCONF Light implementation MAY choose to support
<get-config> without filtering. An implementation not supporting the
<get-config> operation MUST return an <rpc-error> element with an
<error-tag> value of "operation-not-supported" when an <edit-config>
operation is invoked. If a <get-config> operation is invoked with a
<filter> element and filtering is not supported, an <rpc-error>
element MUST be returned with an <error-tag> value of "unknown-
element".
Note that [RFC6241] only requires to support the <running> datastore
as source parameter.
Perelman, et al. Expires July 21, 2012 [Page 6]
Internet-Draft NETCONF Light January 2012
3.1.2. <edit-config>
A NETCONF Light implementation supporting only a small data model MAY
choose to not support the <edit-config> operation defined in Section
7.2 of [RFC6241]. An implementation not supporting the <edit-config>
operation MUST return an <rpc-error> element with an <error-tag>
value of "operation-not-supported" when an <edit-config> operation is
invoked.
3.1.3. <copy-config>
A NETCONF Light implementation MAY choose to not support the <copy-
config> as defined in Section 7.3 of [RFC6241]. An implementation
not supporting the <copy-config> operation MUST return an <rpc-error>
element with an <error-tag> value of "operation-not-supported" when a
<copy-config> operation is invoked.
Note that [RFC6241] only requires to support the <running> datastore
as source parameter. If no other capabilities are announced, the
source parameter of the <copy-config> operation will carry the
<config> element containing the complete configuration to copy.
3.1.4. <delete-config>
A NETCONF Light implementation MAY choose to not support the <delete-
config> operation as defined in Section 7.4 of [RFC6241]. An
implementation not supporting the <delete-config> operation MUST
return an <rpc-error> element with an <error-tag> value of
"operation-not-supported" when a <delete-config> operation is
invoked.
Note that NETCONF implementations only supporting the <running>
datastore can trivially implement <delete-config> by always returning
a suitable <rpc-error> since the <running> datastore cannot be
deleted.
3.1.5. <lock> and <unlock>
A NETCONF Light implementation MAY choose to not support the <lock>
and <unlock> operations as defined in Sections 7.5 and 7.6 of
[RFC6241]. An implementation not supporting the <lock> operation or
the <unlock> operation MUST return an <rpc-error> element with an
<error-tag> value of "operation-not-supported" when a <lock>
operation is invoked.
Perelman, et al. Expires July 21, 2012 [Page 7]
Internet-Draft NETCONF Light January 2012
3.1.6. <get>
A NETCONF Light implementations MAY choose to not support the <get>
operation as defined in Section 7.7 of [RFC6241]. An implementation
not supporting the <get> operation MUST return an <rpc-error> element
with an <error-tag> value of "operation-not-supported" when a <get>
operation is invoked.
Some implementations MAY choose to support the <get> operation with
the following restriction: A NETCONF Light implementation MAY choose
to not support filtering. If a <get> operation is invoked with a
<filter> element and filtering is not supported, an <rpc-error>
element MUST be returned with an <error-tag> value of "unknown-
element".
3.1.7. <close-session>
A NETCONF Light implementation MAY choose to not support the <close-
session> operation as defined in Section 7.8 of [RFC6241]. An
implementation not supporting the <close-session> operation MUST
return an <rpc-error> element with an <error-tag> value of
"operation-not-supported" when a <close-session> operation is
invoked.
3.1.8. <kill-session>
A NETCONF Light implementation MAY choose to not support the <kill-
session> operation as defined in Section 7.9 of [RFC6241]. An
implementation not supporting the <kill-session> operation MUST
return an <rpc-error> element with an <error-tag> value of
"operation-not-supported" when a <kill-session> operation is invoked.
3.2. Capability Negotiation
NETCONF advertises the capabilities during the <hello> exchange (see
Section 8.1 of [RFC6241]). The NETCONF base capability,
"urn:ietf:params:netconf:base:1.1", indicates that the NETCONF peer
supports all the base protocol operations. Since this is not the
case for NETCONF Light implementations, a NETCONF Light peer MUST NOT
announce the NETCONF base capability and instead announce the NETCONF
light capability.
In the following example, a NETCONF Light server advertises the
NETCONF Light capability and support for the <get-config> and <copy-
config> operation (whitespace has been added for readability).
Perelman, et al. Expires July 21, 2012 [Page 8]
Internet-Draft NETCONF Light January 2012
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:xml:ns:yang:ietf-netconf-light?
module=ietf-netconf-light&
revision=2012-01-12&
features=get-config,copy-config
</capability>
</capabilities>
<session-id>4</session-id>
</hello>
Perelman, et al. Expires July 21, 2012 [Page 9]
Internet-Draft NETCONF Light January 2012
4. NETCONF Light YANG Module
This section defines the ietf-netconf-light YANG [RFC6020] module.
<CODE BEGINS> file "ietf-netconf-light@2012-01-12.yang"
module ietf-netconf-light {
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-light";
prefix "ncl";
organization
"IETF NETCONF (Network Configuration Protocol) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
WG Chair: Bert Wijnen
<mailto:bertietf@bwijnen.net>
WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com>
Editor: Vladislav Perelman
<mailto:v.perelman@jacobs-university.de>
Editor: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Editor: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com>
Editor: Kent Watsen
<mailto:kwatsen@juniper.net>";
description
"This module defines the base NETCONF protocol defined in RFC 6241
as a suite of optionally implemented features. The NETCONF Light
capability is expected to be advertized in the server's <hello>
message in lieu of the traditional base NETCONF capability. By
advertizing this capability, servers can indentify which parts of
the NETCONF protocol are supported. For the most part, NETCONF
Light defines a one-to-one mapping between base protocol
operations and features enabling them; exceptions include
<get-config>, which has one feature to enable the RPC and another
to enable subtree-filtering, and <lock>/<unlock>, which share a
Perelman, et al. Expires July 21, 2012 [Page 10]
Internet-Draft NETCONF Light January 2012
feature called \"locking\". Advertizing all NETCONF Light
features is equivalent to advertizing the NETCONF base capability
itself.
Copyright (c) 2012 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and
// remove this note
// RFC Ed.: remove this note
// Note: extracted from draft-schoenw-netconf-light-01.txt
// RFC Ed.: please update the date to the date of publication
revision 2012-01-12 {
description "Initial version.";
reference "RFC XXXX: Network Configuration Protocol for
Constrained Devices (NETCONF Light)";
}
// RFC Ed.: replace XXXX with actual
// RFC number and remove this note
feature get-config {
description
"This feature indicates that the server supports the
<get-config> protocol operation, albeit without subtree
filtering. The server must additionally advertize
the \"subtree-filtering\" feature to enable subtree
filtering. Alternatively, if the server only wants
to support XPath filtering, it may just advertize
the :xpath capability.";
}
feature subtree-filtering {
description
"This feature indicates that the server supports subtree
filtering for the <get-config> operation. This
feature is only meaningful if the "get-config" feature
Perelman, et al. Expires July 21, 2012 [Page 11]
Internet-Draft NETCONF Light January 2012
is advertized; if "get-config" is not also advertized,
this feature MUST be ignored.";
}
feature edit-config {
description
"This feature indicates that the server supports the
<edit-config> protocol operation. If the server is
unable to support all the <edit-config> attributes
(merge, replace, create, delete, remove), then it
should advertize the \"copy-config\" feature instead.";
}
feature copy-config {
description
"This feature indicates that the server supports the
<copy-config> protocol operation.";
}
feature delete-config {
description
"This feature indicates that the server supports the
<delete-config> protocol operation.";
}
feature locking {
description
"This feature indicates that the server supports the
<lock> and <unlock> protocol operations.";
}
feature get {
description
"This feature indicates that the server supports the
<get> protocol operation.";
}
feature close-session {
description
"This feature indicates that the server supports the
<close-session> protocol operation. When this feature
is not advertized, clients are expected to close the
underlying transport directly.";
}
feature kill-session {
description
"This feature indicates that the server supports the
Perelman, et al. Expires July 21, 2012 [Page 12]
Internet-Draft NETCONF Light January 2012
<kill-session> protocol operation.";
}
}
<CODE ENDS>
Perelman, et al. Expires July 21, 2012 [Page 13]
Internet-Draft NETCONF Light January 2012
5. IANA Consideration
This document registers a URI in the IETF XML registry [RFC3688].
Following the format in RFC 3688, the following registration is
requested.
URI: urn:ietf:params:xml:ns:yang:ietf-netconf-light
Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
This document registers a YANG module in the YANG Module Names
registry [RFC6020].
name: ietf-netconf-light
namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-light
prefix: ncl
reference: RFC XXXX
Perelman, et al. Expires July 21, 2012 [Page 14]
Internet-Draft NETCONF Light January 2012
6. Security Considerations
NETCONF requires every implementation to support the SSH transport
(Section 2.3 of [RFC6241]). On resource constrained devices, it is
crucial that a single security protocol can be shared between
different application protocols. While SSH tends to be popular for
remote login services, it seems that TLS [RFC5246] and its datagram
cousin DTLS [RFC4347] are enjoying much greater support on small
embedded devices. Hence it might be necessary to choose a different
mandatory to implement secure transport protocol for NETCONF Light.
Perelman, et al. Expires July 21, 2012 [Page 15]
Internet-Draft NETCONF Light January 2012
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011.
7.2. Informative References
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Perelman, et al. Expires July 21, 2012 [Page 16]
Internet-Draft NETCONF Light January 2012
Appendix A. NETCONF Light on AVR Raven / Contiki
An implementation of NETCONF Light on Contiki operating system has
been created. It is running on AVR Raven motes, which are Class 1
devices. The implementation is compliant with this Internet-Draft.
It does not support filtering, <edit-config> or any other optional
NETCONF capabilities. NETCONF messages are currently transported
over plain TCP connections.
Together with the Contiki operating system (which weighs about 10 KiB
RAM) and the System Manager application (0.4 KiB RAM), which is used
for retrieval of the operational state of the device, NETCONF Light
takes 13 KiB RAM out of 16 KiB RAM available. The operating system
together with the NETCONF Light implementation uses 78 KiB out of 128
KiB flash memory. This means that the current implementation of the
protocol itself takes 2.6 KiB RAM - a value, that can be lowered by
further code optimizations. 12 KiB out of the used 78 KiB of flash
memory are reserved for the four files in the Coffee File System.
These files are used for input / output manipulations in order to
avoid using more RAM than needed. The size of the files can be
changed if needed, however, it is not advisable to make the files
larger since this will constrain usage of the flash memory by other
applications. After installing NETCONF Light the device has 3.5 KiB
of RAM free, which can be used by other applications.
Perelman, et al. Expires July 21, 2012 [Page 17]
Internet-Draft NETCONF Light January 2012
Appendix B. Experience at Juniper Networks
Following are three case studies where NETCONF Light would have
helped.
As a disclaimer, please note that in accordance with the RFC, Juniper
does not claim its devices implement NETCONF or let them listen on
port 830 until the entire NETCONF protocol has been implemented.
o Juniper Networks' device management strategy depends on NETCONF
or, more precisely, on NETCONF plus capabilities we've defined to
support various aspects of the device (system, hardware, software,
licenses, etc.). In order to integrate with Juniper's NMS system,
a device must support a number of these capabilities before the
NMS will even attempt to configure the device. Thus it is common
that devices new to Juniper, either OEM'ed from a partner or
obtained through acquisistion, to initially support just the RPCs
needed for the most basic support by Juniper's NMS and then
implement the rest of the NETCONF protocol in a subsequent
release.
o As an extension to the previous example, it's not uncommon for a
device to intially support configuration using its native
configuration format, which is typically not XML. However, since
much of NETCONF still applies (getting/setting/locking datastores,
etc), some NETCONF operations are extended to allow passing the
device's native configuration format. Specifically, the <copy-
config> RPC and <get-config> RPC-reply are extended to support
passing an opaque payload. Naturally, subtree-filtering is
disabled for the <get-config> operation.
o One of the devices that Juniper acquired has no notion of locking.
The goal of the acquisition was to import the device's technology
into Junos, but customers owning the original device wanted to
continue using their existing hardware. However, since it was
deemed impossible to add NETCONF to this device (not enough
resources), the NSM team was forced to develop a device adapter
that could mediate between the NETCONF interface the NMS system
requires and the CLI interface the device provided. The adapter
project was successful with one exception, the adapter had to
implement the <lock>/<unlock> RPCs as null operations that blindly
returned <ok>.
Perelman, et al. Expires July 21, 2012 [Page 18]
Internet-Draft NETCONF Light January 2012
Authors' Addresses
Vladislav Perelman
Jacobs University Bremen
EMail: v.perelman@jacobs-university.de
Juergen Schoenwaelder
Jacobs University Bremen
EMail: j.schoenwaelder@jacobs-university.de
Mehmet Ersue
Nokia Siemens Networks
EMail: mehmet.ersue@nsn.com
Kent Watsen
Juniper Networks
EMail: kwatsen@juniper.net
Perelman, et al. Expires July 21, 2012 [Page 19]
