Binary Encoding for NETCONFmjethanandani@gmail.comCisco Systems, Inc.lamj@cisco.comCisco Systems, Inc.alfleung@cisco.com
Operations and Management Area
NETCONF WGThis document describes a method by which a NETCONF [RFC6241] client
and server can negotiate an alternate form of encoding.This document updates RFC 6241.NETCONF, by default, supports XML
encoding for its payload. However, XML can be very verbose, specially
for operational data. That combined with parsing of tags leads to slow
processing of the data. This document proposes a mechanism by which
clients and servers can negotiate an alternate form of encoding, e.g.
binary encoding, and use that to exchange data. Binary encoding can
reduce the physical size of the data exchanged, in some cases by as much
as 66%, and improve the time that is required to process the data, while
preserving the original data.Several binary encoding mechanisms have been proposed, including
CBOR. This document does not advocate any
particular binary encoding format. Instead, it leaves it up to the
negotiation between client and server to decide the form of encoding.
For an example of how to encode YANG in CBOR format, see CBOR Encoding of Data Modeled with
YANG.NETCONF clients and servers exchange a hello as part of establishing
a connection. As part of the hello exchange, each of them advertises
their set of capabilities. This draft suggests advertisement of the
following additional capability.The :encoding capability indicates what encoding format each side
is willing to support. If the client and server are capable of
supporting multiple forms of encoding, they can list each of them.
There is no need to include xml in the list, as that is supported by
default.When using this capability, any binardy encoding needs the
underlying transport to be 8-bit clean, and which preserves message
boundaries when dealing with arbitrary binary data. This requires
use of Chunked Framing mechanism as described in NETCONF over SSH.The :encoding capability is identfied by the following capability
string:urn:ietf:params:netconf:capability:encoding:1.0?format={name,
...}The :encoding capability URI MUST contain a "format" argument
assigned a comma-separated list of formats supported by the device.
For example:urn:ietf:params:netconf:capability:encoding:1.0?format=cbor,gpb,thriftDescription:After each side has exchanged capabilities, a client can
initiate a request to switch to a new encoding format using the
<activate> operation.Parameters:encoding:The <activate> operation instructs the server to switch
to the new binary format. If the server does not support the new
binary format or is unable to switch to the new binary format for
any reason, it MUST fail with the <error-tag> value of
"not-supported" and keep the existing encoding format it is
using.If the system does not have the :encoding capability, the
<activate> operation is not available. If there is a desire
to fall back to default encoding of XML, the client needs to
terminate the existing connection and establish a new
connection.Positive Response:If the device is able to satisfy the requests, an
<rpc-reply> is sent that contains an <ok> element.Negative Response:An <rpc-error> element is included in the
<rpc-reply> with the <type> element set to
"not-supported". The <error-tag> element must be set to
"server-error".Example:This document registers a URI in the IETF XML
registry . Following the format in RFC 3688, the following
registration is requested to be made:IANA registry "Network Configuration Protocol (NETCONF) Capability
URNs" needs to be updated to include the following capability.