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. . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. . . . . . . . . . . . . . . . . . . . . 5 3.1.3. . . . . . . . . . . . . . . . . . . . . 6 3.1.4. . . . . . . . . . . . . . . . . . . . 6 3.1.5. . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.6. . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.7. . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.8. . . . . . . . . . . . . . . . . . . . 7 3.1.9. . . . . . . . . . . . . . . . . . . . . 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 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 exchange. 3.1. Reduced Protocol Operations The following sections describe the changes to the NETCONF base protocol operations. 3.1.1. A NETCONF Light implementation MUST support 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 operation is invoked with a element and filtering is not supported, an element is returned with an value of "unknown-element". Note that [I-D.ietf-netconf-4741bis] only requires to support the datastore as source parameter. 3.1.2. A NETCONF Light implementation supporting only a rather limited data model MAY choose to not support the operation. An implementation not supporting the operation must return an element with an value of "operation-not- supported" when an operation is invoked. Perelman, et al. Expires December 6, 2011 [Page 5] Internet-Draft NETCONF Light June 2011 3.1.3. A NETCONF Light implementation MUST support as defined in Section 7.1 of [I-D.ietf-netconf-4741bis]. Note that [I-D.ietf-netconf-4741bis] only requires to support the datastore as source parameter. If no other capabilities are announced, the source parameter of the operation will carry the element containing the complete configuration to copy. 3.1.4. A NETCONF Light implementation only supporting the datastore MAY choose to not support the operation since the only possible response would be an an . An implementation not supporting the operation must return an element with an value of "operation-not-supported" when a operation is invoked. 3.1.5. A NETCONF Light implementation MUST support the operation. Note that this is trivial to implement for implementations supporting only one session. 3.1.6. A NETCONF Light implementation MUST support the operation. Note that this is trivial to implement for implementations supporting only one session. 3.1.7. A NETCONF Light implementations MUST support the 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 operation is invoked with a element and filtering is not supported, an element is returned with an value of "unknown-element". Perelman, et al. Expires December 6, 2011 [Page 6] Internet-Draft NETCONF Light June 2011 3.1.8. A NETCONF Light implementation MUST support the operation. 3.1.9. A NETCONF Light implementation MUST support the operation. Note that implementations supporting only one session will always return an element with an value of "invalid-value". 3.2. Capability Negotiation NETCONF advertises the capabilities during the 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. urn:ietf:params:netconf:light:1.1 4 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, 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]