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. . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. . . . . . . . . . . . . . . . . . . . . 7 3.1.3. . . . . . . . . . . . . . . . . . . . . 7 3.1.4. . . . . . . . . . . . . . . . . . . . 7 3.1.5. and . . . . . . . . . . . . . . . . . 7 3.1.6. . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.7. . . . . . . . . . . . . . . . . . . . 8 3.1.8. . . . . . . . . . . . . . . . . . . . . 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 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 operations. In this case, the device could implement just . o The device's primary goal is to enable full configuration, but it is unable to implement or 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 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 MAY choose to not support the operation as defined in Section 7.1 of [RFC6241]. Furthermore, a NETCONF Light implementation MAY choose to support without filtering. An implementation not supporting the operation MUST return an element with an value of "operation-not-supported" when an operation is invoked. If a operation is invoked with a element and filtering is not supported, an element MUST be returned with an value of "unknown- element". Note that [RFC6241] only requires to support the datastore as source parameter. Perelman, et al. Expires July 21, 2012 [Page 6] Internet-Draft NETCONF Light January 2012 3.1.2. A NETCONF Light implementation supporting only a small data model MAY choose to not support the operation defined in Section 7.2 of [RFC6241]. An implementation not supporting the operation MUST return an element with an value of "operation-not-supported" when an operation is invoked. 3.1.3. A NETCONF Light implementation MAY choose to not support the as defined in Section 7.3 of [RFC6241]. An implementation not supporting the operation MUST return an element with an value of "operation-not-supported" when a operation is invoked. Note that [RFC6241] 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 MAY choose to not support the operation as defined in Section 7.4 of [RFC6241]. An implementation not supporting the operation MUST return an element with an value of "operation-not-supported" when a operation is invoked. Note that NETCONF implementations only supporting the datastore can trivially implement by always returning a suitable since the datastore cannot be deleted. 3.1.5. and A NETCONF Light implementation MAY choose to not support the and operations as defined in Sections 7.5 and 7.6 of [RFC6241]. An implementation not supporting the operation or the operation MUST return an element with an value of "operation-not-supported" when a operation is invoked. Perelman, et al. Expires July 21, 2012 [Page 7] Internet-Draft NETCONF Light January 2012 3.1.6. A NETCONF Light implementations MAY choose to not support the operation as defined in Section 7.7 of [RFC6241]. An implementation not supporting the operation MUST return an element with an value of "operation-not-supported" when a operation is invoked. Some implementations MAY choose to support the operation with the following restriction: 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 MUST be returned with an value of "unknown- element". 3.1.7. A NETCONF Light implementation MAY choose to not support the operation as defined in Section 7.8 of [RFC6241]. An implementation not supporting the operation MUST return an element with an value of "operation-not-supported" when a operation is invoked. 3.1.8. A NETCONF Light implementation MAY choose to not support the operation as defined in Section 7.9 of [RFC6241]. An implementation not supporting the operation MUST return an element with an value of "operation-not-supported" when a operation is invoked. 3.2. Capability Negotiation NETCONF advertises the capabilities during the 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 and operation (whitespace has been added for readability). Perelman, et al. Expires July 21, 2012 [Page 8] Internet-Draft NETCONF Light January 2012 urn:ietf:params:xml:ns:yang:ietf-netconf-light? module=ietf-netconf-light& revision=2012-01-12& features=get-config,copy-config 4 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. 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: WG List: WG Chair: Bert Wijnen WG Chair: Mehmet Ersue Editor: Vladislav Perelman Editor: Juergen Schoenwaelder Editor: Mehmet Ersue Editor: Kent Watsen "; 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 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 , which has one feature to enable the RPC and another to enable subtree-filtering, and /, 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 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 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 protocol operation. If the server is unable to support all the 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 protocol operation."; } feature delete-config { description "This feature indicates that the server supports the protocol operation."; } feature locking { description "This feature indicates that the server supports the and protocol operations."; } feature get { description "This feature indicates that the server supports the protocol operation."; } feature close-session { description "This feature indicates that the server supports the 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 protocol operation."; } } 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, 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 RPC and RPC-reply are extended to support passing an opaque payload. Naturally, subtree-filtering is disabled for the 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 / RPCs as null operations that blindly returned . 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]