Netconf Working Group Weijing Chen Internet Draft Keith Allen Expiration Date: December 2003 SBC Labs June 2003 XML Network Management Interface draft-weijing-netconf-interface-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes XML network management interface between network managed system and network managing system. The XML network management interface is intended for use in diverse network environment where transport and data model requirements vary greatly. It is unlikely that a single transport and data model specification will meet the needs of all anticipated service operators. Therefore, the XML network management interface is partitioned into the layered components. Table of Contents 1. Introduction.................................................2 2. Protocol Operations..........................................3 2.1. Operation Descriptions......................................4 2.1.1. Perform Operation........................................4 2.1.2. Abort Operation..........................................9 Chen and Allen Expire December 2003 [Page 1] Internet Draft draft-weijing-netconf-interface-00 June 2003 2.1.3. Notification............................................10 2.2. Operations XML Schema......................................11 2.3. Capabilities XML Schema....................................14 3. Protocol Transport Binding..................................17 3.1. Abstract Binding WSDL......................................17 3.2. SOAP/HTTP Binding WSDL.....................................18 3.3. BEEP WSDL Binding..........................................20 3.4. SSH WSDL Binding...........................................20 4. A Data Model Schema.........................................20 5. Security Consideration......................................22 6. References..................................................22 7. Authors' Addresses..........................................23 1. Introduction This document describes XML network management interface between network managed system and network managing system. The XML network management interface is intended for use in diverse network environment where transport and data model requirements vary greatly. It is unlikely that a single transport and data model specification will meet the needs of all anticipated service operators. Therefore, the XML network management interface is partitioned into the following layered components. +---------------------------------------------+ | Data Model XML Schema: | | Standard | | CLI +---------------------+ | Proprietary | Capabilities | | | XML Schema | +-----------------------+---------------------+ | Protocol Operations: Operation XML Schema | | | | | | | +---------------------------------------------+ | Protocol Transport: Abstract WSDL | | | +---------------------------------------------+ | Protocol Transport: Concrete WSDL | | BEEP, SOAP/HTTP, SSH | +---------------------------------------------+ The protocol transport is divided into two components: abstract WSDL and concrete WSDL. WSDL (Web Service Description Language) is a formal specification language for XML-based Web service. Abstract Chen and Allen Expire December 2003 [Page 2] Internet Draft draft-weijing-netconf-interface-00 June 2003 WSDL describes the message interaction such as request and response. Concrete WSDL describes the actual transport protocols mapping. The protocol operations are specified in XML schema, which describes the operations message construct and is referred by transport WDSL. The capabilities of optional function are described in capabilities XML schema. It allows peers to exchange the actually functionality implemented in other end. The management data models are described in XML schema too. The dividing of interface allows the formal verification of interface message against interface specification using available general purpose XML toolkits as the following: Protocol Data Operation Model XML Schema Schema Instance \ / Dataset \ / / \ \ / / \ +---+-----+--+ +-----+--+ \ Interface | XML Schema | w/ XPath | XPath | \ ------------>| Validator |-----+-------->| Parser |--->Application Message +-----+------+ | +-------++ | | | | | w/o XPath | | +-----------------+---->Application | | | Error <--------+------------------------------+----------+ The interface XML message is validated against the protocol operation XML schema and specific data model XML schema using general purpose XML schema validator. If systems supports XPath and the interface XML message contains XPath element, the validated XML message is parsed and validated against live XML instances dataset in the systems using XPath parser. Thereafter the processed XML message is passed onto the management application for further processing. 2. Protocol Operations The protocol operations consist of three basic operations: perform, abort, and notification. Each operation has request and response message correlated through unique message id. Chen and Allen Expire December 2003 [Page 3] Internet Draft draft-weijing-netconf-interface-00 June 2003 2.1. Operation Descriptions 2.1.1. Perform Operation ... any ... any ... any ... any Perform operation is the primary interaction message between the managed system and managing system. The managing system (e.g. NMS) sends a perform-request message to the managed system and receives a perform-response message from the managed system. A perform-request message has a unique message id, operation attribute, and transaction attribute. The transaction attribute describes the transaction features as one of the followings: stop on error, continue on error, or rollback-on-error. The operation attribute describes the actual operation request as one of the following operations: get, create, modify, or delete. The further description of each operation is depended on the data model. Recommendation is that one attribute named "action" in the targeted element should specify the finer-grain action (attribute- as-action). The protocol operation XML schema has defined four corresponding "action" attribute types: GetType, CreateType, ModifyType, and DeleteType. The data model XML schema could further extend or restrict the permitted value of these types through attribute type definition mechanism. For get operation, the "action" attribute value in a data model should be type of GetType. For create operation, the "action" attribute value in a data model should be type of CreateType. For modify operation, the "action" attribute value in a data model should type of ModifyType. For delete operation, the "action" attribute value in a data model should be type of DeleteType. Chen and Allen Expire December 2003 [Page 4] Internet Draft draft-weijing-netconf-interface-00 June 2003 A perform-response message with message id is correlated back to originated perform-request message. Again, attribute-as-operation is recommended for the perform-response message construct. The "action" attribute value must be the type of NOPType XML attribute type, which should be the default value in the data model schema. The attribute-as-action makes operation behaviors belonging in the data model, not in the protocol operation layer. It is an object- oriented approach. The object reference is identified by XML element tree or XPath (if supported) in the message but the operation behaviors that may be performed on that object are determined by the objectÆs definition (i.e. data model XML schema). The child element of perform-request and perform-response message is defined as in the operation XML schema. The element enables the data model designers to create interface message containing elements beyond what was specified by the operation XML schema. It empowers the model designers with the ability to define what data models make sense to them. The validation of the whole interface message could be done by a general-purpose XML validator with operation XML schema and data model XML schema. The following example retrieves a XML snippet of configuration data. The operation XML schema is defined in the namespace "http://www.ietf.org/mops". The data model XML schema is defined in the namespace "http://example.com/schema". The attribute "action" is closely associated with targeted element and specified by data model instead of operation model, which makes interface flexible and extensible.
"up" Chen and Allen Expire December 2003 [Page 5] Internet Draft draft-weijing-netconf-interface-00 June 2003
"192.116.67.5"
"up"
"135.104.57.3"
"up"
The following example retrieves the whole running configuration, which could be loaded back to device later to restore the device configuration. Note that the attribute "action" has a value of "get-readwrite", which instruct the device not to retrieve the read- only element(s) since they are not configurable. configuration data goes hereà The following example retrieves a XML snippet of device performance information. 9456823 1228484566 4326 4821050 634712154 2096 The following example only modifies the "hello-interval". 10 Chen and Allen Expire December 2003 [Page 7] Internet Draft draft-weijing-netconf-interface-00 June 2003 10 The following example creates the opsf area 0 with specified interface and "hello-interval". 10 10 Chen and Allen Expire December 2003 [Page 8] Internet Draft draft-weijing-netconf-interface-00 June 2003 The following example modifies the configuration through non-XML content (i.e. plain text). Note that the attribute "action" has a value of "cli", which is specific to this data model "http://example.com/cli". enable config terminal ip vrf v7:yellow-s rd 64000:10004 route-target export 64000:5003 route-target import 64000:5002 maximum routes 500 80 2.1.2. Abort Operation ... any ... any ... any Chen and Allen Expire December 2003 [Page 9] Internet Draft draft-weijing-netconf-interface-00 June 2003 Abort operation pre-maturely terminates a previous issues perform- request message identified by the message id. For abort operation to be effective, abort-request message should be sent through separate transport channel from perform-request message. Otherwise abort-request message may be queued behind the intended perform- request message in the same channel. The following example aborts a previous perform-request message and receives a failure response. xmlns="http://www.ietf.org/mops"/> 2.1.3. Notification ... any ... any ... any ... any Notification operation provides a mechanism for managed system sending asynchronous notification to managing system. Ideally, the transport channel for notification message should be separated from normal interface message, i.e. perform-request and perform-response. The following example shows a managed system sending a XML-based syslog alarm to managing system. The managing system sends a confirmation back to managed system. Sep 26, 2002 16:32:02.848 OSPF config 5 hello interval changed 2.2. Operations XML Schema The formal specification of interface protocol operations is defined in XML schema, which describes the operations message construct. Chen and Allen Expire December 2003 [Page 11] Internet Draft draft-weijing-netconf-interface-00 June 2003 Chen and Allen Expire December 2003 [Page 12] Internet Draft draft-weijing-netconf-interface-00 June 2003 Chen and Allen Expire December 2003 [Page 13] Internet Draft draft-weijing-netconf-interface-00 June 2003 2.3. Capabilities XML Schema The capabilities of optional function are described in capabilities XML schema. It allows peers to exchange the actually functionality implemented in other end, ala a poor manÆs Web Service framework. Chen and Allen Expire December 2003 [Page 14] Internet Draft draft-weijing-netconf-interface-00 June 2003 The capabilities XML schema must be supported by the end systems. It is really a standardized data model schema. Chen and Allen Expire December 2003 [Page 15] Internet Draft draft-weijing-netconf-interface-00 June 2003 The following example shows a pair of peer systems exchanging the capabilities through the interface protocol operations. It is expected that this exchange would be the very first interface interaction once the end systems start up. Chen and Allen Expire December 2003 [Page 16] Internet Draft draft-weijing-netconf-interface-00 June 2003 stop-on-error continue-on-error notif http://example.com/schema 3. Protocol Transport Binding XML network management interface protocol operations can be layered over multiple transport protocols. 3.1. Abstract Binding WSDL Abstract binding WSDL describes the message interaction such as request and response. However, it does not specific any concrete transport protocol binding. Chen and Allen Expire December 2003 [Page 17] Internet Draft draft-weijing-netconf-interface-00 June 2003 3.2. SOAP/HTTP Binding WSDL SOAP/HTTP binding WSDL describes the SOAP over HTTP transport protocols binding. Chen and Allen Expire December 2003 [Page 18] Internet Draft draft-weijing-netconf-interface-00 June 2003 3.3. BEEP WSDL Binding TBD. 3.4. SSH WSDL Binding TBD. 4. A Data Model Schema This is a sample operating and data model schema. It demonstrates that how a particular operating and data model can be fit into the overall interface framework. Chen and Allen Expire December 2003 [Page 20] Internet Draft draft-weijing-netconf-interface-00 June 2003 Chen and Allen Expire December 2003 [Page 21] Internet Draft draft-weijing-netconf-interface-00 June 2003 The following example copies the candidate configuration to running configuration. copied configuration data goes hereà 5. Security Consideration Security concern of network management interface is very sensitive by its nature. The interface protocol operations do not explicitly address the security. It relies on the underline protocol transport and upper layer data model to provide proper security protection. 6. References [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", Bradner, S., March 1997. [XML1.0] "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC-xml-20001006, October 2000. [XML Schema-1] "XML Schema Part 1: Structures", W3C REC-xmlschema-1- 20010502, May 2001. [XML Schema-2] "XML Schema Part 2: Datatypes", W3C REC-xmlschema-2- 20010502, May 2001. [WSDL1.1] "Web Services Description Language (WSDL) 1.1", W3C NOTE- wsdl-20010315, March 2001. Chen and Allen Expire December 2003 [Page 22] Internet Draft draft-weijing-netconf-interface-00 June 2003 [XPath1.0] "XML Path Language (XPath) Version 1.0", W3C REC-xpath- 19991116, November 1999. 7. Authors' Addresses Weijing Chen SBC Labs 9505 Arboretum Blvd. Austin, Texas 78759 Phone: +1 512 372 5710 Email: wchen@labs.sbc.com Keith Allen SBC Labs 9505 Arboretum Blvd. Austin, Texas 78759 Phone: +1 512 372 5741 Email: kallen@labs.sbc.com Chen and Allen Expire December 2003 [Page 23] ë¹É<! 7 vÍ•hTrend@0Á²Î´‹<È@0PEgµ‹<È7@“@œúWEþ 7@’@œúWEþ ²0'draft-weijing-netconf-interface-00.txt”¶7 ‘7'draft-weijing-netconf-interface-00.txt7.txt·±N®çKòfÁøó _µ K