Network Working Group                                           B. Liu
Internet Draft                                                G. Zheng
Intended status: Informational                     Huawei Technologies
Expires: December 6, 2014                                 June 4, 2014

                A NETCONF Extension for Data Fragmentation
                  draft-liu-netconf-fragmentation-00.txt


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 December 6, 2014.

Copyright Notice

   Copyright (c) 2014 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
   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.










Liu, et al.           Expires December 6 2014                [Page 1]

Internet-Draft   draft-liu-netconf-fragmentation-00          June 2014




Abstract

   This document introduces an extension to NETCONF (Network
   Configuration) protocol. The extension allows NETCONF to handle large
   size data as fragmented RPC messages. Specifically, this document
   defines a new <get-block> capability and relevant operations to
   handle the fragmentations.

Table of Contents


   1. Introduction ................................................. 3
   2. Requirements Language and Terminology ........................ 3
   3. Problem Statement ............................................ 4
      3.1. Current Large size Handling Methods ..................... 4
         3.1.1. Stream-Oriented Handling ........................... 4
         3.1.2. Requesting a Portion of Data ....................... 4
      3.2. Problems ................................................ 4
   4. Solution ..................................................... 5
      4.1. Rationale: Standardized RPC Fragmentation Handling ...... 5
      4.2. Design Choice: <get-block> extension .................... 5
         4.2.1. <get-block> Capability ............................. 6
         4.2.2. <get-block> Operation .............................. 6
         4.2.3. Examples ........................................... 8
   5. Security Considerations ..................................... 11
   6. IANA Considerations ......................................... 11
   7. References .................................................. 11
      7.1. Normative References ................................... 11
      7.2. Informative References ................................. 11
   8. Acknowledgments ............................................. 12
   Authors' Addresses ............................................. 13















Liu, et al.           Expires December 6, 2014                [Page 2]

Internet-Draft   draft-liu-netconf-fragmentation-00          June 2014




1. Introduction

   NETCONF [RFC6241] is the next generation network management protocol
   for configuring devices. It is becoming more and more popular, and
   some NMS (Network Management System) only use NETCONF as its
   southbound interface. The message procedures of NETCONF are based on
   RPC (Remote Procedure Call) interactions. A NETCONF client/server
   sends a <rpc> message to the counterpart and then receives a replying
   <rpc-reply> message.

   In some situations, the <rpc-reply> message might be very large. For
   example, when NMS is retrieving a large amount of routes in a core
   router or doing a full-synchronizing with a device, the <rpc-reply>
   data might exceed Mega-Byte amount. Then there comes the problem of
   how to handle the large size data. In Section 3, this document
   briefly introduces two typical ways of current handling on this issue;
   and analyzes the problems of them.

   To fix the problems, in Section 4, this document proposes a method of
   extending the NETCONF protocol to allow handling large size data as
   fragmented <rpc-reply> messages. The fragmentation is done at the
   NETCONF level, so it allows the NETCONF client to terminate the large
   size data processing momentarily by protocol interactions; and also
   allows the fragmented messages to be instantly parsed piece by piece.
   Specifically, the fragmentation is achieved through a newly defined
   <get-block> capability and relevant operations.

2. Requirements Language and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119] when they appear in ALL CAPS.  When these words are not in
   ALL CAPS (such as "should" or "Should"), they have their usual
   English meanings, and are not to be interpreted as [RFC2119] key
   words.

   Terminology:

   DOM: Document Object Model, which is a cross-platform and language-
   independent convention for representing and interacting with objects
   in HTML, XHTML and XML documents. Objects in the DOM tree may be
   addressed and manipulated by using methods on the objects. [DOM-WIKI]




Liu, et al.           Expires December 6, 2014                [Page 3]

Internet-Draft   draft-liu-netconf-fragmentation-00          June 2014


   SAX: Simple API for XML, which is an event sequential access parser
   API developed by the XML-DEV mailing list for XML documents. SAX
   provides a mechanism for reading data from an XML document that is an
   alternative to that provided by the DOM. Where the DOM operates on
   the document as a whole, SAX parsers operate on each piece of the XML
   document sequentially. [SAX-WIKI]

   libxml: a software library for parsing XML documents.

   <get-block>: a capability and operation defined in this document to
   handle large size

3. Problem Statement

3.1. Current Large size Handling Methods

3.1.1. Stream-Oriented Handling

   Stream-Oriented handling mainly includes the following two aspects:

   - The server encapsulates the large size replying data in a <rpc-
   reply> message and streams it to the client through TCP protocol.

   - The client parses the received <rpc-reply> content in a stream-
   oriented way. More specifically, the client could utilize SAX [SAX-
   PARSING] to instantly parse the received content without waiting for
   the whole message been transported.

3.1.2. Requesting a Portion of Data

   The clients actively limit the search range of the data so that the
   servers only need to reply with a part of the large size data. Thus
   the clients could control the replies in a reasonable size. One
   example is that the clients get a list of the content, and provide a
   start offset and a max-count, to get a portion at a time.

3.2. Problems

   o Problems of Stream-Oriented handling

   Stream-Oriented method lacks the capability of discontinuing large
   size processing in the server. It would cause unnecessary
   resource/performance cost in the devices if the NMS has already got
   the intended portion or just canceled by the administrators.





Liu, et al.           Expires December 6, 2014                [Page 4]

Internet-Draft   draft-liu-netconf-fragmentation-00          June 2014


   Another problem is the implementation. SAX is not as widely supported
   as DOM [DOM-PARSING]. For example, it is not supported by some
   existing libraries such as libxml [LIBXML].

   o Problems of subsets request

   This method has an implication that the client needs to know the
   list/index of the intended large size data in advance before it
   starting the search request. It can't fit the scenarios of real-time
   on-demand data retrieving. And there is no standard to specify the
   list/index format in a uniform way. Thus it is only suitable for
   private implementation, thus multi-vendor interaction is not
   supported.

   More important, it is just an indirect way to solve the problem. It
   could not fit the scenarios where the client just needs the whole
   large size data in the server.

4. Solution

4.1. Rationale: Standardized RPC Fragmentation Handling

   To fix the problems analyzed above, this document proposes an RPC
   fragmentation mechanism to handle the large size data. Two essential
   requirements of the fragmentation are:

   1)  It needs to allow the NETCONF client to terminate the large size
   data processing momentarily by protocol interactions. In the proposed
   mechanisms in this draft, when the NETCONF server replies the client
   an <rpc-reply> fragmentation, it will wait the response from the
   client that whether it needs to send the next fragmentation. So if
   the initiator has got the intended portion, it could terminate the
   large size process immediately.

   2) It needs to allow the NETCONF client to instantly parse the
   fragmentations piece by piece through the more widely supported DOM
   parsing. So in this document, it specifies that each <rpc-reply>
   fragmentation MUST be in a complete XML form.

4.2. Design Choice: <get-block> extension

   This section introduces the specific extension to current NETCONF
   protocol to handle the fragmentation.






Liu, et al.           Expires December 6, 2014                [Page 5]

Internet-Draft   draft-liu-netconf-fragmentation-00          June 2014


4.2.1. <get-block> Capability

   The Get-block capability allows devices to interact with the clients
   when getting data. A client sends a <get-config> request, if the
   searched data is too big to be encapsulated in one <rpc-reply>, then
   the data was fragmented into multiple <rpc-reply> messages. A <rpc-
   reply> initial search request ID is included in each fragmented <rpc-
   reply>; the client sends a <get-block> operation rpc request to
   indicate the server response the next <rpc-reply>, or terminate the
   search request in advance.

4.2.2. <get-block> Operation

   o Function

   The devices can only use <get-block> operation when the Get-block
   capability was announced.

   The <get-block> fragmentation rules are:
   - There should be a Max-Size for fragmentation. [Open Question]Should
   there be a clear specification of the size? E.g. 64K bytes.
   - When the message reaches the Max-Size, it is sent to the client and
   the next message could be created in advance.
   - Different records from one same table could be put into different
   <rpc-reply> messages
   - All of the fields in one record MUST be put into one <rpc-reply>
   message.
   - XML syntax MUST be complete in each fragmented message, so that
   each fragmentation could be parsed individually.
   - If the record(s) of the child node(s)/table(s) and the parent
   node(s)/table(s) are replied in different fragmentations, the child
   node/table fragmentations MUST include the path and index information
   of all the ancestor node(s)/table(s) in a hierarchical mode.

   Following is an example of the above last rule. The child eTable is
   in a different message with the parents aTable->bTable->cTable-
   >dTable. Then the path and index information of all the ancestors
   MUST included in the search data.

   <aTable>

     <aEntity>

     <aIndex1>

     </aEntity>



Liu, et al.           Expires December 6, 2014                [Page 6]

Internet-Draft   draft-liu-netconf-fragmentation-00          June 2014


     <bTable>

       <bEntity>

   <bIndex1>

   </bEntity>

   <eTable>

     <eEntity>

       <eIndex1>

       <ef2>

       <ef3>

     </eEntity>

   </dTable>

     </bTable>

   </aTable>

   o Parameters

   <discard/>: in <get-block> operation  if the <discard/> parameter is
   conveyed, it means the operation is terminated. Then it doesn't need
   to reply the remaining fragmentations.

   o Successful Operation Reply

   A <rpc-reply> message conveying a <data> element indicates the
   operation is successful.

   If there exists a next fragment, then an set-id attribute MUST be
   included in the <rpc-reply> messge. The attribute set-id is used to
   identify different fragment sets.

   o Failed Operation Reply

   A <rpc-reply> message conveying a <rpc-error> element indicates the
   operation is failed.

   o Exception Handling


Liu, et al.           Expires December 6, 2014                [Page 7]

Internet-Draft   draft-liu-netconf-fragmentation-00          June 2014


   After the NETCONF server replies a fragment, if there is no
   corresponding Get-block request from the client in a reasonable
   period (the time valued to be specified in the future), then the
   server release the offset of the replying data and cannot use <get-
   block> operation anymore, and the remaining data needs to be replied.

4.2.3. Examples

   Example #1 Get the next fragment

        <rpc message-id="101"

             xmlns="urn:ietf:params:xml:ns:NETCONF:base:1.0">

          <get-config>

            <source>

              <running/>

            </source>

            <filter type="subtree">

              <top xmlns="http://example.com/schema/1.2/config">

                <users/>

              </top>

            </filter>

          </get-config>

        </rpc>



        <rpc-reply message-id="101"

             xmlns="urn:ietf:params:xml:ns:NETCONF:base:1.0"

             xmlns:hw=http://www.huawei.com/NETCONF/capability/base/1.0

   hw:set-id="101">

          <data>


Liu, et al.           Expires December 6, 2014                [Page 8]

Internet-Draft   draft-liu-netconf-fragmentation-00          June 2014


            <top xmlns="http://example.com/schema/1.2/config">

              <users>

                <user>

                  <name>root</name>

                  <type>superuser</type>

                  <full-name>Charlie Root</full-name>

                  <company-info>

                    <dept>1</dept>

                    <id>1</id>

                  </company-info>

                </user>

                <!-- additional <user> elements appear here... -->

              </users>

            </top>

          </data>

        </rpc-reply>



   <rpc message-id="102"

             xmlns="urn:ietf:params:xml:ns:NETCONF:base:1.0">

          <get-block
   xmlns="http://www.huawei.com/NETCONF/capability/base/1.0"

   set-id="1">

          </get-block>

        </rpc>



Liu, et al.           Expires December 6, 2014                [Page 9]

Internet-Draft   draft-liu-netconf-fragmentation-00          June 2014


        <rpc-reply message-id="102"

             xmlns="urn:ietf:params:xml:ns:NETCONF:base:1.0"

             xmlns:hw=http://www.huawei.com/NETCONF/capability/base/1.0

   hw:set-id="101">

          <data>

            <top xmlns="http://example.com/schema/1.2/config">

              <users>

                <user>

                  <name>admin</name>

                  <type>commonuser</type>

                  <full-name>Jim Green</full-name>

                  <company-info>

                    <dept>9</dept>

                    <id>90</id>

                  </company-info>

                </user>

                <!-- additional <user> elements appear here... -->

              </users>

            </top>

          </data>

        </rpc-reply>



   Example #2 Abandon the remaining fragments

        <rpc message-id="103"


Liu, et al.           Expires December 6, 2014               [Page 10]

Internet-Draft   draft-liu-netconf-fragmentation-00          June 2014


             xmlns="urn:ietf:params:xml:ns:NETCONF:base:1.0">

          <get-block
   xmlns=http://www.huawei.com/NETCONF/capability/base/1.0 set-id="1">

            <discard/>

          </get-block>

        </rpc>



        <rpc-reply message-id="103"

             xmlns="urn:ietf:params:xml:ns:NETCONF:base:1.0">

          <ok/>

        </rpc-reply>

5. Security Considerations

   TBD.

6. IANA Considerations

   None.

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.

   [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman,
             "Network Configuration Protocol (NETCONF)", RFC 6241, June
             2011.

7.2. Informative References

   [DOM-WIKI]http://en.wikipedia.org/wiki/Document_Object_Model

   [DOM-PARSING]
             http://www.w3.org/TR/DOM-Parsing/



Liu, et al.           Expires December 6, 2014               [Page 11]

Internet-Draft   draft-liu-netconf-fragmentation-00          June 2014


   [SAX-WIKI]http://en.wikipedia.org/wiki/Simple_API_for_XML

   [SAX-PARSING]
             http://www.saxproject.org/apidoc/org/xml/sax/Parser.html

   [LIBXML]  http://xmlsoft.org/

8. Acknowledgments

   Valuable comment was received from Gang Yan and Shouchuan Yang to
   form the draft.

   This document was prepared using 2-Word-v2.0.template.dot.



































Liu, et al.           Expires December 6, 2014               [Page 12]

Internet-Draft   draft-liu-netconf-fragmentation-00          June 2014


Authors' Addresses

   Bing Liu
   Q14-4-A Building
   Huawei Technologies Co., Ltd
   Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd.
   Hai-Dian District, Beijing
   P.R. China

   Email: leo.liubing@huawei.com


   Guangying Zheng
   Q14-4-A Building
   Huawei Technologies Co., Ltd
   Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd.
   Hai-Dian District, Beijing
   P.R. China

   Email: zhengguangying@huawei.com