Efficient XML Interchange Capability for NETCONF

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.

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: EXI Preserve.comments EXI Preserve.dtd EXI Preserve.lexicalValues EXI Preserve.pis EXI Preserve.prefixes 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.

Example:

pre-compression

]]>

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.

Example:

]]>