T. Goddard
Internet-Draft Wind River Systems
Expires: December 2002 June 2002
Towards XML Based Management and Configuration
draft-goddard-xmlconf-survey-00.txt
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.
This Internet-Draft will expire on December 25, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This informational document surveys a variety of existing
technologies relevant to the exploration of an XML-based technology
for network management and configuration. The technologies surveyed
include SOAP, WSDL, SyncML, WBEM, RDF, CC/PP, and JUNOScript. The
data representation capability of XML with and without schemas and
DTDs is compared with SMIv2.
Goddard Expires: December 2002 [Page 1]
Internet-Draft June 2002
1. Introduction
Technologies for management and configuration cover a broad spectrum,
from abstract information models, to model representation languages, to
encodings, to protocols. XML itself focuses on structured data
encoding, but specifications such as SOAP or WSDL use XML to represent
data and to describe the communication semantics. Some specifications,
such as SyncML and WBEM include explicit communication bindings, such as
to OBEX or HTTP.
2. Relevant XML Technologies
2.1. SOAP/WSDL
SOAP and WSDL form the cornerstones of web services. They are well
described by their specification abstracts [SOAP] [WSDL]:
SOAP is a lightweight protocol for exchange of information in a
decentralized, distributed environment. It is an XML based protocol
that consists of three parts: an envelope that defines a framework
for describing what is in a message and how to process it, a set of
encoding rules for expressing instances of application-defined
datatypes, and a convention for representing remote procedure calls
and responses. SOAP can potentially be used in combination with a
variety of other protocols; however, the only bindings defined in
this document describe how to use SOAP in combination with HTTP and
HTTP Extension Framework.
WSDL is an XML format for describing network services as a set of
endpoints operating on messages containing either document-oriented
or procedure-oriented information. The operations and messages are
described abstractly, and then bound to a concrete network protocol
and message format to define an endpoint. Related concrete endpoints
are combined into abstract endpoints (services). WSDL is extensible
to allow description of endpoints and their messages regardless of
what message formats or network protocols are used to communicate,
however, the only bindings described in this document describe how to
use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.
Thus, SOAP provides a document or object-oriented RPC encapsulation
mechanism and WSDL provides a general interface description language.
SOAP and WSDL can be used independently, but together they do make a
powerful combination.
The following example [WSDL] shows the wire format for SOAP messages
Goddard Expires: December 2002 [Page 2]
Internet-Draft June 2002
embedded in HTTP requests. A sample WSDL document describing the
interface used below is found in Appendix 1.
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: 265
SOAPAction: "Some-URI"
DIS
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: 268
34.5
2.2. SyncML
SyncML is based on the idea of synchronizing databases of name-value
pairs. Since the "value" can be any type capable of being encoded or
embedded in XML, a wide variety of management operations can be
performed, including the exchange of structured data or software update.
The prototype application is to maintain the same address book on a PC
and a PDA, but it is easy to see how this idea of data synchronization
can be extended to more generic management and configuration.
One could think of the command set being built up from "Put" and "Get".
"Add", "Copy", "Delete", and "Replace" extend these primitives with
natural additional semantics, and "Atomic" and "Sequence" allow
controlled grouping of commands. "Exec" and "Alert" provide invocation
and notification respectively. Remaining commands round out the
Goddard Expires: December 2002 [Page 3]
Internet-Draft June 2002
database capabilities of the protocol.
Protocol Command Elements:
Add: add an item to the database
Alert: notifications and requests
Atomic: grouping of commands in a transaction
Copy: copy or link an item in the database
Delete: permanently remove an item from the database
Exec: execute an arbitrary remote procedure call
Get: retrieve an element
Map: modify item identifier mapping table (participating
databases may use different item identifier values,
possibly due to resource constraints)
MapItem: individual item identifier mapping
Put: transmit an element
Replace: add with overwrite
Results: returned results from a command
Search: find matching elements in the database
Sequence: grouping of commands that must be processed in sequence
Sync: grouping of commands
The following example illustrates how SyncML combines authorization,
command history, and a name-value pair data model.
POST ./servlet/syncit HTTP/1.1
Host: http://www.syncml.host.com
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-Type: application/vnd.syncml+xml; charset="utf-8"
1.1SyncML/1.111http://www.datasync.org/servlet/syncitIMEI:001004FF1234567Bruce1's Device
QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Goddard Expires: December 2002 [Page 4]
Internet-Draft June 2002
1234syncml:auth-md5b64
Zz6EivR3yeaaENcRN6lpAQ==
./mail/bruce1./calendar1246./12text/x-vCalendar
BEGIN:VCALENDAR
VERSION:1.0
BEGIN:VEVENT
DTSTART:20000531T160000Z
DTEND:20000531T160100Z
SUMMARY:Release v0.9 of specs
END:VEVENT
END:VCALENDAR
2.3. WBEM
Web-Based Enterprise Management (WBEM) [WBEM] is a set of Distributed
Management Task Force (DMTF) standards including a DTD for the
representation of the Common Information Model (CIM) in XML and a
specification for CIM operations over HTTP. The example below shows a
query operation.
M-POST /cimom HTTP/1.1
HOST: http://www.myhost.com/
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
Man: http://www.dmtf.org/cim/mapping/http/v1.0 ; ns=73
Goddard Expires: December 2002 [Page 5]
Internet-Draft June 2002
73-CIMOperation: MethodCall
73-CIMMethod: EnumerateClassNames
73-CIMObject: root/cimv2
FALSE
HTTP/1.1 200 OK
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
Ext:
Cache-Control: no-cache
Man: http://www.dmtf.org/cim/mapping/http/v1.0 ; ns=73
73-CIMOperation: MethodResponse
CIM provides a comprehensive object-oriented information model in the
form of a hierarchy of classes and associations. To give a small
Goddard Expires: December 2002 [Page 6]
Internet-Draft June 2002
sample, it covers classes for hardware (Cluster, Chassis, Slot,
CoolingDevice, PowerSupply, Modem, etc.), services (WakeUpService,
PrintJob), fault tolerance (RedundancyGroup, ActsAsSpare), operating
system resources (LogicalFile, Thread), configuration (SoftwareFeature,
CompatibleProduct), security (IPsecRule), and users (Role,
OrganizationalEntity). New developments with CIM using SOAP, WSDL, and
schemas are sure to be of interest.
2.4. RDF and CC/PP
The Resource Description Framework (RDF) is an XML language for
representing metadata about anything specified by Uniform Resource
Identifiers (URIs). The idea is that URI, as a generalization of URL,
is suitable for naming all conceivable resources [RFC2396]. Note that
URIs can refer to RDF statements themselves, thereby providing a fairly
rich mechanism for representing knowledge.
RDF/XML Syntax Specification (Revised)Dave Beckett
The Composite Capabilities/Preferences Profile (CC/PP) is an RDF-based
framework (with the goal to include language and protocols) for
describing user agent (such as web browser) capabilities. For instance,
the following edited XML fragment [E] describes the capabilities of an
Ericsson T68 mobile phone.
101x80T68R1
Goddard Expires: December 2002 [Page 7]
Internet-Draft June 2002
ISO-8859-1US-ASCIIUTF-8ISO-10646-UCS-215x68YesYesYesPhoneKeypad0Ericsson Mobile Communications ABYes1x1
2.5. Juniper Networks
Juniper Networks has developed a proprietary DTD for a language they
call JUNOScript [J]. It is an RPC (Remote Procedure Call) over ssh,
SSL, or telnet and uses structured data represented in XML. The example
below shows a query operation.
Chassis1122M10Midplane
Goddard Expires: December 2002 [Page 8]
Internet-Draft June 2002
3. Common Elements
3.1. Resource Identification
Several of the specifications (SOAP, RDF, SyncML) use URLs or URIs to
specify the target of an operation. Thus, a basic issue for an XML
based management system may be a scheme for identifying network elements
and their components by URIs.
3.2. Data Representation
It may be possible to use a common data representation based on schemas
(possibly including RDF) with a variety of protocols (such as both SOAP
and SyncML). Fortunately, XML content is easily parsed and transformed
to allow one document to be embedded in another.
4. SNMP Transition
4.1. SNMP Drawbacks
It is important that a new management protocol address the shortcomings
of its predecessors. We examine a few areas of difficulty with SNMP and
comment on possible resolutions that could be brought by a new XML based
protocol.
4.1.1. Multi-device Transactions
It may be important to distinguish between "multi-device transaction"
and "coordinated multi-device operation". For example, if the goal is
to assign new IP addresses to all machines in a site, it is important
that as many assignments succeed as is possible, but a rollback of the
entire assignment due to one failure on a malfunctioning unit may not be
desired. What may be effective is for the administrator to have
explicit control over "prepare" and "commit" phases of an operation. In
any case, a protocol such as SOAP allows a "transaction context" or
"operation context" to be included in the message envelope header. Note
that SNMPv3 provides no inherent way to address multiple devices.
4.1.2. Atomic Operations
Atomic operations (in this case transactions with single device scope)
are provided in SNMP, but the difficulty is that the atomic grouping is
Goddard Expires: December 2002 [Page 9]
Internet-Draft June 2002
always given by the entire contents of the PDU. The complaint is often
that operations placed in the same PDU to save bandwidth are not always
expected to be applied atomically.
What is needed is an explicit syntax for the grouping of atomic
operations, and SyncML provides guidance in this with its ATOMIC and
SEQUENCE tags.
4.1.3. Classes and Types
SMIv2 has been used to model systems of considerable complexity, but
there are many cases where the ability to define new classes or types
would have been a great asset. Proper use of XML schemas and namespaces
provides a rich type definition system.
4.1.4. RPC
Remote Procedure Call may not be as frequent as "get" and "set" when
managing devices, but it is at times essential, and the emulation of RPC
by "get" and "set" is awkward. Existing XML based protocols give
several options: SOAP with WSDL is built with documents and procedures
in mind; SyncML includes an EXEC tag; WBEM supports method invocation;
and JUNOScript is based on RPC.
4.1.5. Error Codes
SNMP restricts error codes to integer values, and this does not
generally provide enough information to diagnose problems. Since XML is
essentially a document format, there are many options for providing
human and machine readable error messages.
4.1.6. OID Based Data Structures
While the OID system is compact and effectively managed through a
standards process, it is not the easiest system in which to build
complex data structures. Schemas, XPath, and namespaces can combine to
provide an XML based system with data structures that are both rich and
capable of decentralized definition: schemas allow complex data
structures that include internal "keys" to be defined, XPath allows fine
grained internal and external references, and namespaces make it
possible to explicitly refer to external standards definitions.
Goddard Expires: December 2002 [Page 10]
Internet-Draft June 2002
4.1.7. Lexicographic Order
However simple it may be to define lexicographic order on OIDs, history
makes it clear that this causes problems with usage and implementation.
An XML based system can make more use of string based sorting and
addressing, and can generate complex data structures as return types,
thereby making the system more intuitive to both developers and users.
4.2. Expressiveness of SMIv2 and XML
4.2.1. SMIv2 Data Types
SMIv2 has fourteen primitive data types.
Integer32 (signed 32 bit integer)
INTEGER (labeled values from 32 bits)
Unsigned32 (unsigned 32 bit integer)
Gauge32 (unsigned 32 bit integer with specified min and max)
Counter32 (increasing unsigned 32 bit integer)
Counter64 (increasing unsigned 64 bit integer)
TimeTicks (unsigned 32 bit integer giving hundredths of a second)
OCTET (sequence of 8 bit characters)
STRING
OBJECT (OID integer sequence)
IDENTIFIER
IpAddress (IPv4 four octet address)
Opaque (ASN.1 BER encoded binary sequence)
BITS (labeled bits in an OCTET STRING)
Complex data structures are built from a mixture of trees and tables
using the lexicographic order of OIDs acting as "names" for values typed
as above.
4.2.2. XML Data Types
The concept of "data type" is not central to XML 1.0 without schemas, as
it is derived from the document markup language SGML (Standard
Generalized Markup Language). It could be said that there are only two
XML data types, consisting of raw and tagged unicode strings, and this
does make the representation of validated primitive types in XML
difficult:
CDATA (raw character data)
PCDATA (parsed character data)
Goddard Expires: December 2002 [Page 11]
Internet-Draft June 2002
However, this unfairly portrays the capability of XML as a data
language, as XML 1.0 with DTD (Document Type Definition) is well suited
to representing complex, structured data. For instance, a DTD can
describe arbitrary containment and ordering of named data elements.
Consider the following standalone document; it may be impractical, but
it illustrates what is possible in theory even with just DTDs. Here,
the DTD is contained in the initial DOCTYPE element, but it is common to
refer to an external DTD.
]>
Of course, the above example is interesting only in theory, and it
illustrates that without schemas, it is not possible to capture even the
existing SMIv2 type system (as an integer type of a fixed size is not
practical to specify). This is not surprising, as the intent of DTD is
type definition for documents; it is only with the development of
schemas that type definition for data has been extensively considered.
4.2.3. XML Schema Data Types
XML schemas are generally more verbose than equivalent DTDs, but XML
Schema is vastly more expressive. For instance, the following schema
fragment could be used to define a simple type for an OID in
hexadecimal:
Goddard Expires: December 2002 [Page 12]
Internet-Draft June 2002
Note that a regular expression for a decimal representation of an OID
would be complicated. If a decimal representation was preferred, it
might be more effective to represent each sub-identifier as an integer
and gather them together in an OID complex type.
It is fair to say that XML Schema surpasses the data representation and
validation capabilities of SMIv2. XML Schema allows new primitive types
to be defined through regular expressions, and significantly exceeds the
capabilities of DTDs for defining complex types. As is illustrated
above, it is possible to define a subclass (OIDhex) of a class (string)
in a remote document. Careless use of dependencies between distributed
documents could be a disaster, but this is a very powerful feature from
the point of view of a standards body.
4.3. XML Drawbacks
4.3.1. Embedded Binary Data
Three techniques for embedding binary data in XML documents are
described in [GS].
1. Refer to the data externally (such as with a URL)
2. Represent the data with MIME
3. Embed the binary data as CDATA
Note that CDATA cannot truly contain binary data as the CDATA end marker
"]]>" is merely an unusual sequence, not a forbidden one (for arbitrary
binary data, and especially for other XML content). Multipart MIME has
a superior solution by allowing the end marker to be defined within the
data stream. To benefit from this, an option is to include the XML
document as one part of a multipart MIME document.
4.3.2. Compression
It could be said that XML compresses very well; however, this is because
it is much more verbose than an equivalent binary representation.
Fortunately, a variety of data compression technologies are readily
available.
4.3.3. Footprint
There is no question that XML combined with associated standards is more
complex than SNMP, and could therefore be expected to have higher static
and dynamic implementation footprints. However, what must be determined
Goddard Expires: December 2002 [Page 13]
Internet-Draft June 2002
is if the "glue" between the application and its external interface
could be simpler with XML, possibly resulting in an overall reduction in
footprint.
5. Conclusion
When combined with schemas, XML can be used to encode and validate data
of arbitrary complexity in a way that is verbose but faithful to
application design. XML encoded data can be easily compressed,
transformed, or embedded into container formats by a wide variety of
emerging tools. A standardized XML encoding for network management and
configuration could be used for both persistent storage and interactive
management, and could be transported over higher level protocols such as
SOAP or SyncML, or directly over lower level protocols like HTTP.
Security Considerations
Security considerations are of critical importance to management
protocols, but are not covered in this draft. SSL and IPsec are
compatible with all protocols mentioned in this document.
References
[CCPP] Composite Capabilities/Preferences Profile,
http://www.w3.org/Mobile/CCPP/
[E] Ericsson T68 profile, http://mobileinternet.ericsson.com/
UAprof/T68R1.xml
[GS] Shankar, Gowri, "Embedding Binary Data in XML Documents",
http://www-106.ibm.com/developerworks/xml/library/x-binary/
[J] JUNOScript, Example of a JUNOScript Session,
http://www.juniper.net/techpubs/software/junos53/
junoscript53-guide/html/session-guide37.html
[RDF] Resource Description Framework, http://www.w3.org/RDF
[RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource
Identifiers (URI): Generic Syntax,
http://www.ietf.org/rfc/rfc2396.txt
[SOAP] D. Box, D Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. K.
Nielsen, S. Thatte, D. Winer, Simple Object Access Protocol (SOAP)
1.1, http://www.w3.org/TR/SOAP/
Goddard Expires: December 2002 [Page 14]
Internet-Draft June 2002
[WBEM] Web Based Enterprise Management, http://www.dmtf.org
[WSDL] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, Web
Services Description Language (WSDL 1.1), http://www.w3.org/TR/wsdl
[XML] Extensible Markup Language, http://www.w3.org/XML
Appendix 1: WSDL Example
Goddard Expires: December 2002 [Page 15]
Internet-Draft June 2002
My first service
Author's Address:
Ted Goddard
Wind River Systems
#180, 6815-8th St NE
Calgary, Alberta, Canada
T2E 7H7
ted.goddard@windriver.com
Goddard Expires: December 2002 [Page 16]