One document matched: draft-schoenw-netconf-light-00.txt
Network Working Group V. Perelman
Internet-Draft J. Schoenwaelder
Intended status: Informational Jacobs University
Expires: December 6, 2011 M. Ersue
Nokia Siemens Networks
June 4, 2011
Network Configuration Protocol for Constrained Devices (NETCONF Light)
draft-schoenw-netconf-light-00.txt
Abstract
This document describes a profile of the NETCONF protocol for
resource constrained devices, called NETCONF Light.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 6, 2011.
Copyright Notice
Copyright (c) 2011 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
publication of this document. Please review these documents
Perelman, et al. Expires December 6, 2011 [Page 1]
Internet-Draft NETCONF Light June 2011
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 BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 4
3. NETCONF Light . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Reduced Protocol Operations . . . . . . . . . . . . . . . 5
3.1.1. <get-config> . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. <edit-config> . . . . . . . . . . . . . . . . . . . . 5
3.1.3. <copy-config> . . . . . . . . . . . . . . . . . . . . 6
3.1.4. <delete-config> . . . . . . . . . . . . . . . . . . . 6
3.1.5. <lock> . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.6. <unlock> . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.7. <get> . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.8. <close-session> . . . . . . . . . . . . . . . . . . . 7
3.1.9. <kill-session> . . . . . . . . . . . . . . . . . . . . 7
3.2. Capability Negotiation . . . . . . . . . . . . . . . . . . 7
4. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Example: NETCONF Light on AVR Raven / Contiki . . . . 11
Perelman, et al. Expires December 6, 2011 [Page 2]
Internet-Draft NETCONF Light June 2011
1. Introduction
The Network Configuration Protocol (NETCONF)
[I-D.ietf-netconf-4741bis] provides mechanisms to install,
manipulate, and delete the configuration of network devices. The
primary target 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 defines a
subset of NETCONF, called NETCONF Light, that can be implemented on
resource constrained devices.
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, ranging for example from 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.
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 December 6, 2011 [Page 3]
Internet-Draft NETCONF Light June 2011
2. Constrained Devices
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.
Perelman, et al. Expires December 6, 2011 [Page 4]
Internet-Draft NETCONF Light June 2011
3. NETCONF Light
NETCONF Light uses the NETCONF message framing as defined in
[I-D.ietf-netconf-4741bis]. In particular, it uses the same XML
encoding and XML namespace.
The NETCONF specification [I-D.ietf-netconf-4741bis] defines a set of
base operations and a number of optional capabilities. 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 MUST support <get-config> operation as
defined in Section 7.1 of [I-D.ietf-netconf-4741bis] with the
following restriction:
o A NETCONF Light implementation MAY choose to not support
filtering. If a <get-config> operation is invoked with a <filter>
element and filtering is not supported, an <rpc-error> element is
returned with an <error-tag> value of "unknown-element".
Note that [I-D.ietf-netconf-4741bis] only requires to support the
<running> datastore as source parameter.
3.1.2. <edit-config>
A NETCONF Light implementation supporting only a rather limited data
model MAY choose to not support the <edit-config> operation. 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.
Perelman, et al. Expires December 6, 2011 [Page 5]
Internet-Draft NETCONF Light June 2011
3.1.3. <copy-config>
A NETCONF Light implementation MUST support <copy-config> as defined
in Section 7.1 of [I-D.ietf-netconf-4741bis].
Note that [I-D.ietf-netconf-4741bis] 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 only supporting the <running>
datastore MAY choose to not support the <delete-config> operation
since the only possible response would be an an <rpc-error>. 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.
3.1.5. <lock>
A NETCONF Light implementation MUST support the <lock> operation.
Note that this is trivial to implement for implementations supporting
only one session.
3.1.6. <unlock>
A NETCONF Light implementation MUST support the <unlock> operation.
Note that this is trivial to implement for implementations supporting
only one session.
3.1.7. <get>
A NETCONF Light implementations MUST support the <get> operation as
defined in Section 7.7 of [I-D.ietf-netconf-4741bis] with the
following restriction:
o 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 is
returned with an <error-tag> value of "unknown-element".
Perelman, et al. Expires December 6, 2011 [Page 6]
Internet-Draft NETCONF Light June 2011
3.1.8. <close-session>
A NETCONF Light implementation MUST support the <close-session>
operation.
3.1.9. <kill-session>
A NETCONF Light implementation MUST support the <kill-session>
operation. Note that implementations supporting only one session
will always return an <rpc-error> element with an <error-tag> value
of "invalid-value".
3.2. Capability Negotiation
NETCONF advertises the capabilities during the <hello> exchange (see
Section 8.1 of [I-D.ietf-netconf-4741bis]). 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 announce the capability
"urn:ietf:params:netconf:light:1.1". The version number embedded in
the capability string is kept aligned with the NETCONF base
capability since NETCONF Light is designed to be a proper subset of
NETCONF.
In the following example, a server advertises the NETCONF light
capability.
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:light:1.1
</capability>
</capabilities>
<session-id>4</session-id>
</hello>
Perelman, et al. Expires December 6, 2011 [Page 7]
Internet-Draft NETCONF Light June 2011
4. IANA Consideration
IANA is requested to add the following capabilities to the registry:
+---------------------+-----------------------------------+
| Index | Capability Identifier |
+---------------------+-----------------------------------+
| :light:1.1 | urn:ietf:params:netconf:light:1.1 |
+---------------------+-----------------------------------+
Perelman, et al. Expires December 6, 2011 [Page 8]
Internet-Draft NETCONF Light June 2011
5. Security Considerations
NETCONF requires every implementation to support the SSH transport
(Section 2.3 of [I-D.ietf-netconf-4741bis]). 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 December 6, 2011 [Page 9]
Internet-Draft NETCONF Light June 2011
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs
to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[I-D.ietf-netconf-4741bis] Enns, R., Bjorklund, M., Schoenwaelder,
J., and A. Bierman, "Network
Configuration Protocol (NETCONF)",
draft-ietf-netconf-4741bis-10 (work in
progress), March 2011.
6.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 December 6, 2011 [Page 10]
Internet-Draft NETCONF Light June 2011
Appendix A. Example: 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 December 6, 2011 [Page 11]
Internet-Draft NETCONF Light June 2011
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
Perelman, et al. Expires December 6, 2011 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 06:03:36 |