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 |
| <perform-request/perform-response> |
| <abort-request/abort-response> |
| <notif/notif-confirm> |
+---------------------------------------------+
| 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
<perform-request messageId="message id"
operation="get/create/modify/delete"
transaction="stop-on-error/
continue-on-error/
rollback-on-error"/>
... any
</perform-request>
<perform-response messageId="message id">
<error>
<protocol-error code="">
... any
</protocol-error>
<application-error code="">
... any
</application-error>
</error>
... any
</perform-response>
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 <xsd:any/> in the operation XML schema. The <any>
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.
<perform-request messageId="09233523-567b"
operation="get"
transaction="continue-on-error"
xmlns="http://www.ietf.org/mops"
xmlns:example="http://example.com/schema">
<example:running-config name="active">
<example:ospf name="process 1">
<example:area name="area 0">
<example:interface action="get-all">
<address/>
<adminStatus>"up"</adminStaus>
</example:interface>
</example:area>
</example:ospf>
</example:running-config>
</perform-request>
<perform-response messageId="09233523-567b"
xmlns="http://www.ietf.org/mops"
xmlns:example="http://example.com/schema">
<error>
Chen and Allen Expire December 2003 [Page 5]
Internet Draft draft-weijing-netconf-interface-00 June 2003
<protocol-error code="noError"/>
<application-error code="noError"/>
</error>
<example:running-config name="active">
<example:ospf name="process 1">
<example:area name="area 0">
<example:interface name="Ethernet1/5">
<address>"192.116.67.5"</address>
<adminStatus>"up"</adminStatus>
</example:interface>
<example:interface name="Ethernet2/2">
<address>"135.104.57.3"</address>
<adminStatus>"up"</adminStatus>
</example:interface>
</example:area>
</example:ospf>
</example:running-config>
</perform-response>
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.
<perform-request messageId="09233523-567b"
operation="get"
transaction="continue-on-error"
xmlns="http://www.ietf.org/mops"
xmlns:example="http://example.com/schema">
<example:running-config action="get-readwrite" name="active">
</example:running-config>
</perform-request>
<perform-response messageId="09233523-567b"
xmlns="http://www.ietf.org/mops"
xmlns:example="http://example.com/schema">
<error>
<protocol-error code="noError"/>
<application-error code="noError"/>
</error>
<example:running-config name="active">
configuration data goes hereà
</example:running-config>
</perform-response>
The following example retrieves a XML snippet of device performance
information.
<perform-request messageId="09233523-567b"
operation="get"
xmlns="http://www.ietf.org/mops"
Chen and Allen Expire December 2003 [Page 6]
Internet Draft draft-weijing-netconf-interface-00 June 2003
xmlns:example="http://example.com/schema">
<example:running-config name="active">
<example:interface action="get-readonly" name="Ethernet0/1">
<example:statistics/>
</example:interface>
</example:running-config>
</perform-request>
<perform-response messageId="09233523-567b"
xmlns="http://www.ietf.org/mops"
xmlns:example="http://example.com/schema">
<error>
<protocol-error code="noError"/>
<application-error code="noError"/>
</error>
<example:running-config name="active">
<example:interface name="Ethernet0/1">
<example:statistics>
<inPackets>9456823</inPackets>
<inOctets>1228484566</inOctets>
<inErrors>4326</inErrors>
<outPackets>4821050</outPackets>
<outOctets>634712154</outOctets>
<outErrors>2096</outErrors>
<example:statistics>
</example:interface>
</example:running-config>
</perform-response>
The following example only modifies the "hello-interval".
<perform-request messageId="09233523-567b"
operation="modify"
transaction="continue-on-error"
xmlns="http://www.ietf.org/mops"
xmlns:example="http://example.com/schema">
<example:running-config name="active">
<example:ospf name="process 1">
<example:area name="area 0">
<example:interface action="modify-replace"
name="Ethernet1/5">
<hello-interval>10</hello-interval>
</example:interface>
</example:area>
</example:ospf>
</example:running-config>
</perform-request>
<perform-response messageId="09233523-567b"
xmlns="http://www.ietf.org/mops"
xmlns:example="http://example.com/schema">
Chen and Allen Expire December 2003 [Page 7]
Internet Draft draft-weijing-netconf-interface-00 June 2003
<error>
<protocol-error code="noError"/>
<application-error code="noError"/>
</error>
<example:running-config name="active">
<example:ospf name="process 1">
<example:area name="area 0">
<example:interface name="Ethernet1/5">
<hello-interval>10</hello-interval>
</example:interface>
</example:area>
</example:ospf>
</example:running-config>
</perform-response>
The following example creates the opsf area 0 with specified
interface and "hello-interval".
<perform-request messageId="09233523-567b"
operation="create"
transaction="rollback-on-error"
xmlns="http://www.ietf.org/mops"
xmlns:example="http://example.com/schema">
<example:running-config name="active">
<example:ospf name="process 1">
<example:area action="create-all" name="area 0">
<example:interface name="Ethernet1/5">
<hello-interval>10</hello-interval>
</example:interface>
</example:area>
</example:ospf>
</example:running-config>
</perform-request>
<perform-response messageId="09233523-567b"
xmlns="http://www.ietf.org/mops"
xmlns:example="http://example.com/schema">
<error>
<protocol-error code="noError"/>
<application-error code="noError"/>
</error>
<example:running-config name="active">
<example:ospf name="process 1">
<example:area name="area 0">
<example:interface name="Ethernet1/5">
<hello-interval>10</hello-interval>
</example:interface>
</example:area>
</example:ospf>
</example:running-config>
</perform-response>
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".
<perform-request messageId="09233523-567b"
operation="modify"
transaction="stop-on-error"
xmlns="http://www.ietf.org/mops"
xmlns:example="http://example.com/cli">
<example:cli xmlns="http://example.com/cli" action="modify-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
</example:cli>
</perform-request>
<perform-response messageId="09233523-567b"
xmlns="http://www.ietf.org/mops"
xmlns:example="http://example.com/cli">
<error>
<protocol-error code="noError"/>
<application-error code="noError"/>
</error>
<example:cli xmlns="http://example.com/cli">
</example:cli>
</perform-response>
2.1.2. Abort Operation
<abort-request messageId="message id of targeted request"/>
<abort-response messageId="message id of targeted request">
<error>
<protocol-error code="">
... any
</protocol-error>
<application-error code="">
... any
</application-error>
</error>
... any
</abort-response>
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.
<abort-request messageId="09233523-567b"
xmlns="http://www.ietf.org/mops"/>
<abort-response messageId="09233523-567b">
xmlns="http://www.ietf.org/mops"/>
<error>
<protocol-error code="operationFailure"/>
<application-error code="noError"/>
</error>
</abort-response>
2.1.3. Notification
<notif messageId="message id">
... any
</notif>
<notif-confirm messageId="message id">
<error>
<protocol-error code="">
... any
</protocol-error>
<application-error code="">
... any
</application-error>
</error>
... any
</notif-confirm>
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.
<notif messageId="09233523-567b"
xmlns="http://www.ietf.org/mops"
xmlns:example="http://example.com/schema"
Chen and Allen Expire December 2003 [Page 10]
Internet Draft draft-weijing-netconf-interface-00 June 2003
xmlns:syslog="http://www.ietf.org/mops/syslog">
<example:running-config name="active">
<example:ospf name="process 1">
<example:area name="area 0">
<example:interface name="Ethernet1/5">
<example:notification>
<syslog:log>
<syslog:date>Sep 26, 2002</syslog:date>
<syslog:time>16:32:02.848</syslog:time>
<syslog:facility>OSPF</syslog:facility>
<syslog:subfacility>config</syslog:subfacility>
<syslog:severity>5</syslog:severity>
<syslog:description>
hello interval changed
</syslog:description>
</syslog:log>
</example:notification>
</example:interface>
</example:area>
</example:ospf>
</example:running-config>
</notif>
<notif-confirm messageId="09233523-567b"
xmlns="http://www.ietf.org/mops"
xmlns:example="http://example.com/schema">
<error>
<protocol-error code="noError"/>
<application-error code="noError"/>
</error>
</notif-confirm>
2.2. Operations XML Schema
The formal specification of interface protocol operations is defined
in XML schema, which describes the operations message construct.
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.ietf.org/mops"
xmlns="http://www.ietf.org/mops"
elementFormDefault="qualified">
<xsd:simpleType name="NOPType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="no-op"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="GetType">
<xsd:restriction base="xsd:string">
Chen and Allen Expire December 2003 [Page 11]
Internet Draft draft-weijing-netconf-interface-00 June 2003
<xsd:enumeration value="get-all"/>
<xsd:enumeration value="get-readonly"/>
<xsd:enumeration value="get-readwrite"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="CreateType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="create-all"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ModifyType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="modify-replace"/>
<xsd:enumeration value="modify-merge"/>
<xsd:enumeration value="modify-copy"/>
<xsd:enumeration value="modify-validate"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="DeleteType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="delete-all"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ActionType">
<xsd:union memberTypes="NOPType
GetType
CreateType
ModifyType
DeleteType"/>
</xsd:simpleType>
<xsd:simpleType name="ProtocolErrorCode">
<xsd:restriction base="xsd:string>
<xsd:enumeration value="noError"/>
<xsd:enumeration value="xmlValidationFailure"/>
<xsd:enumeration value="operationFailure"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ApplicationErrorCode">
<xsd:restriction base="xsd:string>
<xsd:enumeration value="noError"/>
<xsd:enumeration value="xmlValidationFailure"/>
<xsd:enumeration value="xpathParseFailure"/>
<xsd:enumeration value="badArguments"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="ProtocolError">
<xsd:sequence>
<xsd:any minOccurs="0"/>
Chen and Allen Expire December 2003 [Page 12]
Internet Draft draft-weijing-netconf-interface-00 June 2003
</xsd:sequence>
<xsd:attribute name="code" type="ProtocolErrorCode"/>
</xsd:complexType>
<xsd:complexType name="ApplicationError">
<xsd:sequence>
<xsd:any minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="code" type="ApplicationErrorCode"/>
</xsd:complexType>
<xsd:complexType name="Error">
<xsd:sequence>
<xsd:element name="protocol-error" type="ProtocolError"/>
<xsd:element name="application-error"
type="ApplicationError"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="perform-request">
<xsd:complexType>
<xsd:sequence>
<xsd:any minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="messageId" type="xsd:string"
use="required"/>
<xsd:attribute name="operation" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="get"/>
<xsd:enumeration value="create"/>
<xsd:enumeration value="modify"/>
<xsd:enumeration value="delete"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="transaction" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="stop-on-error"/>
<xsd:enumeration value="continue-on-error"/>
<xsd:enumeration value="rollback-on-error"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="perform-response">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="error" type="Error"/>
<xsd:any minOccurs="0"/>
Chen and Allen Expire December 2003 [Page 13]
Internet Draft draft-weijing-netconf-interface-00 June 2003
</xsd:sequence>
<xsd:attribute name="messageId" type="xsd:string"
use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="abort-request">
<xsd:complexType>
<xsd:attribute name="messageId" type="xsd:string"
use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="abort-response">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="error" type="Error"/>
<xsd:any minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="messageId" type="xsd:string"
use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="notif">
<xsd:complexType>
<xsd:sequence>
<xsd:any minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="messageId" type="xsd:string"
use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="notif-confirm">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="error" type="Error"/>
<xsd:any minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="messageId" type="xsd:string"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>
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.
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:mops="http://www.ietf.org/mops"
targetNamespace="http://www.ietf.org/mops/capabilities"
xmlns="http://www.ietf.org/mops/capabilities"
elementFormDefault="qualified">
<xsd:simpleType name="Transaction">
<xsd:list>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="stop-on-error"/>
<xsd:enumeration value="continue-on-error"/>
<xsd:enumeration value="rollback-on-error"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:list>
</xsd:simpleType>
<xsd:simpleType name="Notification">
<xsd:list>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="notif"/>
<xsd:enumeration value="notif-confirm"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:list>
</xsd:simpleType>
<xsd:simpleType name="ModelSchema">
<xsd:list itemType="xsd:anyURI"/>
</xsd:simpleType>
<xsd:simpleType name="GetReadType">
<xsd:union memberTypes="mops:NOPType">
<xsd:simpleType>
<xsd:restriction base="mops:GetType">
<xsd:enumeration value="get-all"/>
<xsd:enumeration value="get-readonly"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:union>
</xsd:simpleType>
<xsd:element name="capabilities">
<xsd:complexType>
<xsd:all>
<xsd:element name="transaction">
Chen and Allen Expire December 2003 [Page 15]
Internet Draft draft-weijing-netconf-interface-00 June 2003
<xsd:complexType>
<xsd:extension base="Transaction">
<xsd:attribute name="action" type="GetReadType"
use="optional" default="no-op"/>
</xsd:extension>
</xsd:complexType>
</xsd:element>
<xsd:element name="notification">
<xsd:complexType>
<xsd:extension base="Notification">
<xsd:attribute name="action" type="GetReadType"
use="optional" default="no-op"/>
</xsd:extension>
</xsd:complexType>
</xsd:element>
<xsd:element name="modelschema">
<xsd:complexType>
<xsd:extension base="ModelSchema">
<xsd:attribute name="action" type="GetReadType"
use="optional" default="no-op"/>
</xsd:extension>
</xsd:complexType>
</xsd:element>
</xsd:all>
<xsd:attribute name="action" type="GetReadType"
use="optional" default="no-op"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>
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.
<perform-request messageId="09233523-567b"
operation="get"
transaction="continue-on-error"
xmlns="http://www.ietf.org/mops"
xmlns:cap="http://www.ietf.org/mops/capabilities"/>
<cap:capabilities action="get-all">
</cap:capabilities>
</perform-request>
<perform-response messageId="09233523-567b"
xmlns="http://www.ietf.org/mops"
xmlns:cap="http://www.ietf.org/mops/capabilities"/>
<error>
<protocol-error code="noError"/>
Chen and Allen Expire December 2003 [Page 16]
Internet Draft draft-weijing-netconf-interface-00 June 2003
<application-error code="noError"/>
</error>
<cap:capabilities action="no-op">
<cap:transaction>
stop-on-error continue-on-error
</cap:transaction>
<cap:notification>notif</cap:notification">
<cap:modelschema>http://example.com/schema</cap:modelschema>
</cap:capabilities>
</perform-response>
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.
<?xml verion="1.0"?>
<wsdl:definitions name="mopsAbsBinding"
targetNamespace="http://www.ietf.org/mops/absbinding.wsdl"
xmlns="http://www.ietf.org/mops/absbinding.wsdl"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"
xmlns:mops="http://www.ietf.org/mops">
<wsdl:message name="perform-request">
<wsdl:part name="request" element="mops:perform-request"/>
</wsdl:message>
<wsdl:message name="perform-response">
<wsdl:part name="response" element="mops:perform-response"/>
</wsdl:message>
<wsdl:message name="abort-request">
<wsdl:part name="request" element="mops:abort-request"/>
</wsdl:message>
<wsdl:message name="abort-response">
<wsdl:part name="response" element="mops:abort-response"/>
</wsdl:message>
<wsdl:message name="notif">
<wsdl:part name="notification" element="mops:notif"/>
</wsdl:message>
<wsdl:message name="notif-confirm">
<wsdl:part name="confirmation" element="mops:notif-confirm"/>
</wsdl:message>
<wsdl:portType name="PerformOperation">
<wsdl:operation name="perform-operation">
<wsdl:input message="perform-request"/>
Chen and Allen Expire December 2003 [Page 17]
Internet Draft draft-weijing-netconf-interface-00 June 2003
<wsdl:output message="perform-response"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="AbortOperation">
<wsdl:operation name="abort-operation">
<wsdl:input message="abort-request"/>
<wsdl:output message="abort-response"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="NotificationUnconfirm">
<wsdl:operation name="notification-unconfirm">
<wsdl:output message="notif"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="NotificationConfirm">
<wsdl:operation name="notification-confirm">
<wsdl:output message="notif"/>
<wdsl:input message="notif-confirm"/>
</wsdl:operation>
</wsdl:portType>
</definitions>
3.2. SOAP/HTTP Binding WSDL
SOAP/HTTP binding WSDL describes the SOAP over HTTP transport
protocols binding.
<?xml verion="1.0"?>
<wsdl:definitions name="mopsSOAPBinding"
targetNamespace="http://www.ietf.org/mops/soapbinding.wsdl"
xmlns="http://www.ietf.org/mops/soapbinding.wsdl"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap"
xmlns:mops="http://www.ietf.org/mops"
xmlns:absbinding=
"http://www.ietf.org/mops/absbinding.wsdl">
<wsdl:import namespace="http://www.ietf.org/mops/abscore.wsdl"
location="http://www.ietf.org/mops/abscore.wsdl">
<wsdl:binding name="PerformOperationSoapBinding"
type="absbinding:PerformOperation">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http">
<wsdl:operation name="PerformOperationSoap">
<soap:operation
soapAction="http://www.ietf.org/mops/PerformOperation"
style="document"/>
<wsdl:input>
Chen and Allen Expire December 2003 [Page 18]
Internet Draft draft-weijing-netconf-interface-00 June 2003
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</soap:binding>
</wsdl:binding>
<wsdl:binding name="AbortOperationSoapBinding"
type="absbinding:AbortOperation">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http">
<wsdl:operation name="AbortOperationSoap">
<soap:operation
soapAction="http://www.ietf.org/mops/AbortOperation"
style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</soap:binding>
</wsdl:binding>
<wsdl:binding name="NotificationUnconfirmSoapBinding"
type="absbinding:NotificationUnconfirm">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http">
<wsdl:operation name="NotificationUnconfirmSoap">
<soap:operation
soapAction=
"http://www.ietf.org/mops/NotificationUnconfirm"
style="document"/>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</soap:binding>
</wsdl:binding>
<wsdl:binding name="NotificationConfirmSoapBinding"
type="absbinding:NotificationConfirm">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http">
<wsdl:operation name="NotificationConfirmSoap">
<soap:operation
soapAction=
Chen and Allen Expire December 2003 [Page 19]
Internet Draft draft-weijing-netconf-interface-00 June 2003
"http://www.ietf.org/mops/NotificationConfirm"
style="document"/>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
</wsdl:operation>
</soap:binding>
</wsdl:binding>
</wsdl:definitions>
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.
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.ietf.org/mops/model"
xmlns="http://www.ietf.org/mops/model"
xmlns:mops="http://www.ietf.org/mops"
elementFormDefault="qualified">
<xsd:simpleType name="ModifyRunningType">
<xsd:restriction base="mops:ModifyType">
<xsd:enumeration value="modify-replace"/>
<xsd:enumeration value="modify-merge"/>
<xsd:enumeration value="modify-copy"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ActionRunningType">
<xsd:union memberTypes="mops:NOPType
mops:GetType
mops:CreateType
ModifyRunningType
Mops:DeleteType"/>
</xsd:simpleType>
Chen and Allen Expire December 2003 [Page 20]
Internet Draft draft-weijing-netconf-interface-00 June 2003
<xsd:simpleType name="ModifyCandidateType">
<xsd:restriction base="mops:ModifyType">
<xsd:enumeration value="modify-replace"/>
<xsd:enumeration value="modify-merge"/>
<xsd:enumeration value="modify-validate"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ActionCandidateType">
<xsd:union memberTypes="mops:NOPType
mops:GetType
mops:CreateType
ModifyCandidateType
Mops:DeleteType"/>
</xsd:simpleType>
<xsd:element name="candidate">
<xsd:complexType>
<xsd:sequence>
<xsd:any/>
</xsd:sequence>
<xsd:attribute name="action" type="ActionCandidateType"
use="optional" default="no-op"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="running">
<xsd:complexType>
<xsd:sequence>
<xsd:any/>
</xsd:sequence>
<xsd:attribute name="action" type="ActionRunningType"
use="optional" default="no-op"/>
<xsd:attribute name="copy-from"
type="xsd:string"
use="optional" default="candidate"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="startup">
<xsd:complexType>
<xsd:sequence>
<xsd:any/>
</xsd:sequence>
<xsd:attribute name="action" type="ActionRunningType"
use="optional" default="no-op"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>
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.
<perform-request messageId="09233523-567b"
operation="modify"
transaction="rollback-on-error"
xmlns="http://www.ietf.org/mops"
xmlns:model="http://www.ietf.org/mops/model">
<model:running action="modify-copy" copy-from="candidate">
</model:running>
</perform-request>
<perform-response messageId="09233523-567b"
xmlns="http://www.ietf.org/mops"
xmlns:model="http://www.ietf.org/mops/model">
<error>
<protocol-error code="noError"/>
<application-error code="noError"/>
</error>
<model:running>
copied configuration data goes hereà
</model:running>
</perform-response>
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Í���•����h�������Trend���������@�0Á²Î´‹<È@�0PEgµ‹<È�7���@�“�@œúWEþ 7�������@�’�@œúWEþ �²���� �0���'���draft-weijing-netconf-interface-00.txt���”�����¶7���� �‘���� �7���'���draft-weijing-netconf-interface-00.txt�� �7������.txt����·������±N®çKòfÁøó _µ K