Efficient XML Interchange Capability for NETCONF
Pantheon Technologies SROMlynske Nivy 56Bratislava821 05Slovakiarobert.varga@pantheon.skNETCONF Working Group
The Network Configuration Protocol (NETCONF) provides mechanisms to install,
manipulate, and delete the configuration of network devices via exchange of XML
messages in textual representation. Efficient XML Interchange (EXI) is a
W3C-recommended binary representation of XML Information Set, which is more
efficient from both CPU and bandwidth utilization perspective. This document
defines a capability-based extension to the NETCONF protocol that allows peers
to agree to exchange protocol messages using EXI encoding.
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 .
The NETCONF protocol is defined in terms of two peers,
client and server, exchanging XML messages in an RPC pattern. These messages are
encoded as XML text documents, which makes the exchange easily understandable by
human operators by simply observing them on the wire. Unfortunately, this feature
takes its toll on both computation and network resources, as the representation
contains redundant information and verbose names.
Efficient XML Interchange is a W3C
Recommendation which defines a more efficient way of encoding XML Information Set
than the usual text representation. This is achieved by a combination of reduced
verbosity, binary encoding and, optionally, pruning of non-essential information
like comments.
It seems advantageous to allow clients and servers participating on a NETCONF
session to sacrifice human readability to increase processing efficiency,
especially in environments with high transactional activity and/or limited
computing resources.
This document uses the following terms defined in :
capabilityclientmessageprotocol operationremote procedure callserver
The :exi capability indicates that the peer supports EXI message encoding and
is willing to use it. The capability has no effect on data being handled by
the NETCONF protocol, nor does it affect protocol message exchanges.
EXI-encoded documents are binary data, this capability may only be used when
the underlying transport is 8-bit clean and preserves message boundaries in
face of arbitrary binary data. Notably this requires use of Chunked Framing
mechanism as described in when used with SSH
transport.
The EXI capability is identified by the following capability string:
urn:ietf:params:netconf:capability:exi:1.0
The identifier MAY have a the following parameters:
This indicates that the sender is willing to perform EXI compression.
The parameter MUST contain a positive integral value, which indicates
maximum compression block size which the sender can process.
This indicates that the sender can use schema-informed grammars for
EXI encoding. The parameter MUST contain a value, which has to be one
of "builtin" or "base:1.1". The value "builtin" indicates the ability
to use the XML schema built into the EXI specification. The value of
"base:1.1" is a superset of the "builtin" value and indicates that the
sender additionally supports schema-informed EXI encoding, based on
netconf.xsd schema published in .
Examples:
urn:ietf:params:netconf:capability:exi:1.0?compression=1000000
urn:ietf:params:netconf:capability:exi:1.0?schemas=builtin
urn:ietf:params:netconf:capability:exi:1.0?schemas=base:1.1
urn:ietf:params:netconf:capability:exi:1.0?compression=20000&schemas=builtin
The <start-exi> operation requests that the message encoding be
switched to EXI. The operation is invoked by the client and
validated by the server. If the server finds the parameters
acceptable, it will issue a positive response in the current
session encoding. It MUST encode all subsequent messages using EXI
encoding with the supplied parameters. It will also expect all
incoming messages to be EXI-encoded.
The client MUST NOT send any messages to the server between the
time is sends this request and the time it receives a response.
Once it receives a positive reply, it MUST encode all subsequent
messages using the EXI encoding with the parameters supplied in the
RPC.
If the operation fails, the session message encoding remains
unchanged.
Requested EXI alignment. If this parameter is not present,
bit-packed is assumed. The following values are valid:
Set EXI alignment to bit-packed.
Set EXI alignment to byte-aligned.
Set EXI alignment to pre-compression.
Do not specify EXI alignment, but perform EXI
compression instead.
Requested EXI fidelity options. If this parameter is not
present or empty, all fidelity options are disabled. The
following items may be specified:
Preserve.comments EXI Fidelity option
Preserve.dtd EXI Fidelity option
Preserve.lexicalValues EXI Fidelity option
Preserve.pis EXI Fidelity option
Preserve.prefixes EXI Fidelity option
Optional parameter. This specifies what schema options
should be enabled in the EXI encoding process. The
following values are valid:
Do not use schema-informed grammars at all. This
translates to using schemaId of
<xsd:nil>true</xsd:nil> in the EXI Options
header.
Do no use schema-informed grammars, but use the
build-in XML data types. This translates to using
an empty schemaId in the EXI Options header.
Use schema-informed grammar based on netconf.xsd
as published in in
non-strict mode. The value "base:1.1" should be
carried in the schemaId field in the EXI Options.
If the device was able to satisfy the request, an <rpc-reply> is
sent that contains an <ok> element.
An <rpc-error> element is included in the <rpc-reply> if the
request cannot be completed for any reason.
The <stop-exi> operation requests that the message encoding be
switched to textual XML. The operation is invoked by the client and
validated by the server. If the server is able to switch the
encoding to XML, it will issue a positive response in the current
session encoding. It MUST encode all subsequent messages using
standard XML encoding. It will also expect all incoming messages to
be XML-encoded.
The client MUST NOT send any messages to the server between the time
is sends this request and the time it receives a response. Once it
receives a positive reply, it MUST encode all subsequent messages
using the standard XML encoding.
If the operation fails, the session message encoding remains
unchanged. If the session currently uses XML encoding, this RPC
is a no-operation and SHOULD NOT fail.
If the device was able to satisfy the request, an <rpc-reply> is
sent that contains an <ok> element.
An <rpc-error> element is included in the <rpc-reply> if the
request cannot be completed for any reason.
The following YANG module defines the new operations introduced in this document.
The YANG language is defined in . Every NETCONF speaker
that supports the :exi capability MUST implement this YANG module.
This document registers the following capability identifier URN in the 'Network
Configuration Protocol (NETCONF) Capability URNs' registry:
urn:ietf:params:netconf:capability:exi:1.0
The compression option present in EXI specification may increase CPU and memory
requirements for encoding the response. Devices should ensure this overhead is
acceptable before agreeing to using EXI encoding, such that no operational risks
are introduced.
The author would like to thank Anton Tkacik, Miroslav Miklus and Stefan Kobza for
their contributions to this document.