Efficient XML Interchange Capability for NETCONF
draft-varga-netconf-exi-capability-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Robert Varga | ||
| Last updated | 2013-07-10 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-varga-netconf-exi-capability-00
NETCONF Working Group R. Varga
Internet-Draft Pantheon Technologies SRO
Intended status: Standards Track July 11, 2013
Expires: January 10, 2014
Efficient XML Interchange Capability for NETCONF
draft-varga-netconf-exi-capability-00
Abstract
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.
Requirements Language
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 [RFC2119].
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 January 10, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Varga Expires January 10, 2014 [Page 1]
Internet-Draft EXI Capability July 2013
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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. EXI Capability . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Capability Identifier . . . . . . . . . . . . . . . . . . 3
3.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 4
3.4.1. <start-exi> . . . . . . . . . . . . . . . . . . . . . 4
3.4.2. <stop-exi> . . . . . . . . . . . . . . . . . . . . . . 5
4. YANG module for <start-exit> and <stop-exi> Operations . . . . 6
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The NETCONF protocol [RFC6241] 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 [W3C.REC-exi-20110310] 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,
Varga Expires January 10, 2014 [Page 2]
Internet-Draft EXI Capability July 2013
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.
2. Terminology
This document uses the following terms defined in [RFC6241]:
o capability
o client
o message
o protocol operation
o remote procedure call
o server
3. EXI Capability
3.1. Overview
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.
3.2. Dependencies
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 [RFC6242]
when used with SSH transport.
3.3. Capability Identifier
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:
compression: This indicates that the sender is willing to perform EXI
compression. The parameter MUST contain a positive integral
Varga Expires January 10, 2014 [Page 3]
Internet-Draft EXI Capability July 2013
value, which indicates maximum compression block size which the
sender can process.
schemas: 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 [RFC6241].
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&schem
as=builtin
3.4. New Operations
3.4.1. <start-exi>
Description: 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.
Parameters:
alignment: Requested EXI alignment. If this parameter is not
present, bit-packed is assumed. The following values are
valid:
bit-packed: Set EXI alignment to bit-packed.
byte-aligned: Set EXI alignment to byte-aligned.
pre-compression: Set EXI alignment to pre-compression.
compressed: Do not specify EXI alignment, but perform EXI
Varga Expires January 10, 2014 [Page 4]
Internet-Draft EXI Capability July 2013
compression instead.
fidelity: Requested EXI fidelity options. If this parameter is
not present or empty, all fidelity options are disabled. The
following items may be specified:
<comments/>: EXI Preserve.comments
<dtd/>: EXI Preserve.dtd
<lexical-values/>: EXI Preserve.lexicalValues
<pis/>: EXI Preserve.pis
<prefixes/>: EXI Preserve.prefixes
Positive Response: If the device was able to satisfy the request, an
<rpc-reply> is sent that contains an <ok> element.
Negative Response: An <rpc-error> element is included in the <rpc-
reply> if the request cannot be completed for any reason.
Example:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<start-exi>
<alignment>pre-compression</alignment>
<fidelity>
<dtd/>
<lexical-values/>
</fidelity>
</start-exi>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
3.4.2. <stop-exi>
Varga Expires January 10, 2014 [Page 5]
Internet-Draft EXI Capability July 2013
Description: 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.
Positive Response: If the device was able to satisfy the request, an
<rpc-reply> is sent that contains an <ok> element.
Negative Response: An <rpc-error> element is included in the <rpc-
reply> if the request cannot be completed for any reason.
Example:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<stop-exi/>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
4. YANG module for <start-exit> and <stop-exi> Operations
The following YANG module defines the new operations introduced in
this document. The YANG language is defined in [RFC6020]. Every
NETCONF speaker that supports the :exi capability MUST implement this
YANG module.
TBD.
5. IANA considerations
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
6. Security Considerations
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.
Varga Expires January 10, 2014 [Page 6]
Internet-Draft EXI Capability July 2013
7. Acknowledgements
The author would like to thank Anton Tkacik, Miroslav Miklus and
Stefan Kobza for their contributions to this document.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011.
[W3C.REC-exi-20110310]
Schneider, J. and T. Kamiya, "Efficient XML Interchange
(EXI) Format 1.0", World Wide Web Consortium
Recommendation REC-exi-20110310, March 2011, <http://
www.w3.org/TR/2011/REC-exi-20110310>.
Author's Address
Robert Varga
Pantheon Technologies SRO
Mlynske Nivy 56
Bratislava 821 05
Slovakia
Email: robert.varga@pantheon.sk
Varga Expires January 10, 2014 [Page 7]