[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Whitepaper on XML-based Network Management
This list has been far too quiet of late, so I've come up with a
way to fix that ;^)
Attached please find a whitepaper on XML-based network management
with some specifics about the XML-based API to Juniper Networks
boxes, called JUNOScript. Hopefully it will be useful at least as
a starting point for discussions of XML and its value in the network
management arena.
A postscript version can be found at:
ftp://ftp.juniper.net/pub/users/phil/nm-using-xml-rpc.ps
Thanks,
Phil
Network Management using an XML-based RPC
Phil Shafer
Juniper Networks
July 27th, 2001
phil@juniper.net
1. Introduction
Juniper Networks has incorporated an Application Programming
Interface (API) into the JUNOS Internet software. The JUNOScript API
is based on the W3C's Extensible Markup Language (XML) [1] and uses a
Remote Procedure Call (RPC) paradigm. This document describes XML,
the JUNOScript API, and surrounding technologies.
This information is being provided as input to the IETF's OPS-NM
working group for discussions on the future of network management.
The features and possibilities of XML-based network management are
leading edge and have the potential to improve the interaction
between network-management tools and the devices they manage.
This document is NOT offered in accordance with Section 10 of
RFC2026, and the author does not provide the IETF with any rights
other than to publish.
1.1. Existing Technologies
Many network engineers are unhappy with the level of control provided
by the two industry-standard network-management methods: SNMP and
Expect. The strengths and weaknesses of these technologies are well-
known.
SNMP is widely deployed and supported. It is a reasonable technology
for many network-management tasks, but is not always appropriate.
Many real world tasks cannot be addressed without the implementation
of proprietary MIBs, which presents problems for both the MIB
implementers and users.
When SNMP cannot be used, programmers use Expect, a tool that
provides immediate access to any data emitted by a device. Creating
regular expressions that match CLI output in both current and future
vendor software releases is a black art. Unfortunately, new software
often breaks Expect-based tools, adding to the cost and latency of
upgrading to new software and adapting the network-management tool
set to new software versions.
Vendors know their users write Expect scripts that parse CLI output,
and that they cannot change that output. The static nature of these
displays prevents iterative improvements, even when the improvement
makes Expect scripting easier. For example, changing an output string
to provide consistent output style breaks existing scripts that match
against the inconsistent output. One user's fix is another's bug.
An API was needed that allowed complex data to be encoded in an
extensible format using rules that are presented in precise detail
and with consistent syntax.
2. XML's Strength Is Describing Complex Data
The JUNOScript API encodes data for both requests and replies in the
W3C's Extensible Markup Language (XML) [1]. XML's simple encoding
allows the representation of arbitrary hierarchies of data using
ASCII text in HTML-like tags. The order and structure of the elements
can be defined using either Document Type Definitions (DTDs) or XML
Schemas [2].
An example of XML encoding might be the encoding of a person's
contact information:
<!-- Comments are encoded like this -->
<contact-information> <!-- An open tag begins an element,
which may contain text, other
elements, or both. -->
<person/> <!-- Empty tags like this represent
flags or other boolean
information -->
<last-name>Shafer</last-name><!-- Data elements contain data -->
<first-name>Phil</first-name>
<office> <!-- Nesting elements allows
representation of complex data
and relationships -->
<phone>1-888-586-4737</phone>
<address>
<street>940 Main Campus Drive</street>
<city>Raleigh</city>
<state abbreviation="NC">North Carolina</state>
<!-- Attributes may appear on open
or empty tags -->
</address> <!-- Close tags mark the end of
elements -->
</office> <!-- Every element must be closed -->
</contact-information> <!-- XML documents and document
fragments have one top-level
element ->
2.1. XML Basics
There are a small number of basic constructs in XML:
Open tags begin an element by giving the name of the element in
greater-than and less-than signs (aka. chevrons or angle brackets):
<foo>
Close tags end an element by preceding the name of the element with a
slash:
</foo>
An element refers to a particular open tag, its matching close tag,
and all content in between.
Empty tags are equivalent to an open and close tag and consist of the
element name followed by a slash:
<foo/>
Data is any text not otherwise part of a tag, normal appearing
between open and close tags:
<foo>bar</foo>
Attributes may appear in either open or empty tags, and consist of
the attribute name followed by an equals sign and the quoted
attribute value:
<foo bar="12"/>
Document type definitions (DTDs) define the syntactic relationships
between the elements, specifying containment relationships between
elements and attributes:
<!ELEMENT office (phone, address)>
<!ELEMENT address (street, city, state)>
<!ATTLIST state abbreviation CDATA #IMPLIED>
XML Schemas perform a similar function, but are encoded in xml,
allowing simpler manipulation and extension. They allow creation of
more complex element relationships, data-types, patterns, and
constraints, as well as allowing insertion of application-specific
information into a schema.
Namespaces allow the syntactic and semantic definitions of elements
(and their attributes and data values) to vary by associating
portions of documents with different namespace identifiers. Elements
in another namespace may be referenced by preceding the element name
with the prefix to which the namespace identifier has been mapped.
The 'xmlns' attribute is used to provide this mapping:
In the following example, the 'container' element defines namespace a
alias 'junos' which is tied to the unique identifying string
'http://juniper.net/junos.dtd'. Elements under the 'container'
element can refer to tags in that namespace using the alias as a
prefix:
<container xmlns:junos="http://juniper.net/junos.dtd";>
<junos:feature/> <!-- tag in another namespace -->
</container>
XML documents begin with a processing instruction (PI) that contains
the version of XML used in the document (currently fixed at "1.0")
and the character set encoding scheme, normally either "us-ascii,"
"iso-8859-1," or "UTF-8" for unicode:
<?xml version="1.0" encoding="UTF-8"?>
XML is simply structured text. It can be created using text editors
and printf() calls, parsed using open-source libraries, debugged
using the 'p' command in gdb, transported in e-mail, stored in text
files, manipulated using traditional Unix tools, indented and printed
using simple rules, and transmitted over normal inter-process
communication mechanisms. It's easy to generate, easy to understand,
easy to parse, and easy to debug.
2.2. Transforming XML Using XSLT
XML forms the center of a blast pattern of standards. The most
applicable for network management is the XML Stylesheet Language, XSL
[3]. Originally conceived as a stylesheet language for rendering XML
in browser windows (etc), XSL also functions as a transformation
language (XSLT), which can transform XML into either different XML or
text. Common transformations are:
- converting XML to XHTML [4], an XML form of HTML to be
displayed in browsers
- turning data into text reports or HTML Web pages
- sorting and reordering data
- inverting indices or reversing the hierarchy of tags in a
document
- discarding uninteresting information, such as zero values or
counters that aren't being monitored
- adding additional information, such as turning elements into
hyperlinks to additional information
- changing one vocabulary of XML into another vocabulary
XSLT is not a programming language, though it has some mechanisms for
pseudo-programming. There are IDEs that allow non-programmers to
build XSLT transformations, test, and debug them against real data.
By using this technology, the available pool of talent is expanded.
Finding someone to build a transformations will be easier that
finding a tools developer.
2.3. XPath: Finding What You Need
Another interesting XML-related standard is XPath, used to describe a
set of elements within an XML document. XPath allows the
specification of a path through the document's element hierarchy, as
well as a mechanism for selecting elements from that hierarchy.
The following XPath expression matches all 'name' elements that are
parented by 'physical-interface' that are in turn parented by
'interface-information' elements:
/interface-information/physical-interface/name
A 'predicate' expression can be added that further limits the set of
matching elements. These expressions appear in square brackets after
an element of attribute name.
This expression matches all 'status' elements that are parented by an
'environment-item' whose 'name' attribute is "Power Supply B":
environment-item[@name=="Power Supply B"]/status
XPath is used by XSLT to describe the nodes upon which
transformations are to be performed:
<xsl:template match="environment-item[status != 'OK']">
<!-- XSL statements here would be applied to an environment-item
element which contains a status element whose value is not
equal to "OK" -->
</xsl:template>
<xsl:template match="*[temperature/@junos:celsius > 40]">
<!-- XSL statements here would be applied to an element that
contains a temperature element whose junos:celsius
attribute is greater than 40. (The greater than symbol
must be escaped as '>' to avoid ambiguity.) -->
</xsl:template>
2.4. XML Tools Are Common
XML and its surrounding technologies are supported by common tools
across a variety of platforms and programming languages. Finding XML-
aware programmers and XML-capable tools is becoming easier. New
versions of many databases and applications are supporting XML
formats and features.
Stylesheet coders need not be programmers and XML Integrated
Development Environments (IDEs) provide integrated source,
stylesheet, and output viewing and manipulation. XSL provides
simple, compact descriptions of the tags being matched and the
operations being performed on them.
New XML technologies are emerging from the W3C's working groups at
great speed. The XML Query Language [5] and XML Encryption groups
seem particularly interesting. The Scalable Vector Graphics (SVG) [6]
standard is a powerful way to display graphics and, as an XML
application, can be generated using XSLT.
2.5. Live Data
Encapsulating data in XML makes life easier. Instead of using a
proprietary parser to handle requests and replies, any open-source
XML parser can be used. The use of common XML parser APIs allows
migration of source code between parsers.
Hierarchical data lends itself to tree representations, a familiar
programming construct. The W3C's Document Object Model (DOM) [7]
provides a simple language-independent API for traversing and
manipulating trees of XML elements. While DOM imposes memory
constraints that limits its utility with large data sets, it is easy
to learn and suitable for many tasks.
Data in XML can be exchanged between XML tools, allowing data
retrieved from a device to be:
- processed by an XSLT transformation
- stored in an XML database
- rendered into a Web page
- compared with previously recorded datasets
- transformed into a report detailing any important differences
- and e-mailed to a notification list.
Stated more simply, data encoded in XML is live data, and it can be
shared between XML-capable tools.
2.6. Compatibility
XML provides excellent forward and backward compatibility of data in
three ways:
First, elements for new features can be introduced without impairing
an application's ability to parse old elements.
<foo>
<older-feature>here</older-feature>
<new-feature>works</new-feature>
</foo>
Secondly, when an element's meaning needs to change, a device can
generate two elements in parallel; the old element can contain the
old value and the new element can contain the new value.
<foo>
<old-style>value</old-style>
<new-style><new-value-tag/></new-style>
</foo>
Finally, applications and devices can use the document version number
to detect incompatibilities and either adjust their behavior or abort
the operation.
<foo-protocol version="5.1">
The JUNOScript API uses a mixture of these techniques.
2.7. Supporting Environment
XML is standards-based, with a number of supporting standards and
technologies. An active community of developers contributes to open-
source software and lively discussions. Software vendors are rolling
XML into their applications and APIs. The Apache group has several
XML-related projects. Microsoft supports XML in IE5 and is embracing
it with a vengeance. IBM's Alphaworks site has a number of XML-
related projects. Companies are jumping on the XML bandwagon, not
just to be trendy but because they see the power that encoding data
in XML gives them and their customers. Big companies (Oracle, SUN)
and little companies (Neocore, XMLSPY) are all generating powerful
tools for XML. Common APIs like DOM and SAX allow code to migrate
between XML tool chains.
2.8. Summary
XML's simple encoding of complex hierarchical information in
extensible, self-describing tags allows data to be easily generated
and parsed using freely available libraries for all major programming
languages. XSLT transformations allows non-programmers to use the
power and flexibility of XML to perform operations that previously
required custom programming.
3. Model
A JUNOScript operation consists of a request and the corresponding
response, transmitted during a connection-oriented session using over
any transport protocol, including ssh, telnet, ssl, or a serial
console connection.
3.1. RPC Request and Reply
A request consists of an <rpc> element containing a method element
and any arguments for that method.
<!-- This RPC invokes the 'get-interface-information' method with
the interface-name of fxp0 (the management interface on a
Juniper Networks router) -->
<rpc>
<get-interface-information>
<interface-name>fxp0</interface-name>
<media/>
<brief/>
</get-interface-information>
</rpc>
<!-- This RPC invokes the 'get-chassis-inventory' method
with no arguments -->
<rpc>
<get-chassis-inventory/>
</rpc>
<!-- A more complex RPC -->
<rpc>
<get-ospf-database-information>
<!-- order of elements under an rpc does not matter -->
<summary/> <!-- booleans encode as empty tags -->
<lsa-id>152.1.4.128</lsa-id> <!-- keyword value pairs -->
<advertising-router>152.1.255.163</advertising-router>
<area>152.14.0.0</area>
<instance>big</instance>
</get-ospf-database-information>
</rpc>
The response to an <rpc> is an <rpc-reply> tag containing any output
the RPC generates.
<rpc-reply>
<interface-information xmlns=".../junos-interface.dtd">
<physical-interface>
<name>fxp0</name>
<admin-status junos:format="Enabled">up</admin-status>
<oper-status>up</oper-status>
<if-type>Ethernet</if-type>
<link-level-type>Ethernet</link-level-type>
<mtu>1514</mtu>
<speed>100mbps</speed>
<clocking>Unspecified</clocking>
<if-device-flags>
<ifdf-present/>
<ifdf-running/>
</if-device-flags>
<if-config-flags>
<iff-snmp-traps/>
</if-config-flags>
</physical-interface>
</interface-information>
</rpc-reply>
Attributes given in the <rpc> open tag are echoed on the <rpc-reply>
open tag, so the caller can insert additional information in the
reply.
<rpc host="my-router.foo-foo.com"
date="Wed July 24" timing="daily">
<get-something-interesting/>
</rpc>
This would return:
<rpc-reply host="my-router.foo-foo.com"
date="Wed July 24" timing="daily">
<something-interesting>
<awesome-data-here/>
</something-interesting>
</rpc-reply>
3.2. JUNOScript Sessions
A JUNOScript session is a series of <rpc> elements and corresponding
<rpc-reply> elements contained in a <junoscript> element. Sessions
can be opened over any connection-oriented transport protocol, while
allowing the time span of the connection to control issues like
database locking and stateful operations. The session begins with the
simultaneous exchange of a two part handshake between the client and
server. The first part is the xml processing instruction:
<?xml version="1.0" encoding="us-ascii"?>
This establishes the session as an XML document, with the current
version of XML and the character set encoding scheme.
The endpoints also exchange JUNOScript protocol version and release
information as attributes of the open tag for the JUNOScript session.
<junoscript version="1.0" release="5.0R1">
XML requires that a document have a single top-level tag containing
the entire document contents. By placing the entire JUNOScript
session inside the <junoscript> element, we allow either side of the
session to be treated as a complete document. Additionally each <rpc>
or <rpc-reply> element can be treated as a document fragment.
The JUNOScript version and release information can be used by both
sides to decide the status of session. Typically this is left to the
party with the higher version number, as a 1.0 client cannot deduce
its capacity to interoperate with a 2.0 server. If the version
difference is considered too large or drastic, the session can be
aborted. If there are significant protocol or content differences,
the higher numbered version party can adapt to the lower version
requirements. This version-compatibility logic should never be
required, since all future work should always be backwards
compatible, but is laid as groundwork for unforeseen future changes.
When either party is ready for the session to be torn down, it can
send a close </junoscript> tag, closing the <junoscript> element and
terminating the connection.
3.3. Access Mechanisms
The JUNOScript API needs only a connection-oriented data path, making
it suitable for a number of transport protocols. An ssh, telnet, or
serial console connection can easily carry a JUNOScript session. Once
a connection is established, the client uses the 'junoscript' command
to convert the CLI login into a JUNOScript session. The client and
server exchange the initial handshake described above, after which
further communications are in JUNOScript RPCs.
By using existing access mechanisms, we leveraged the functionality
(security, existing clients, and servers) of those mechanisms, while
also letting customers use well-known and trusted protocols. The
features and problems of ssh are well understood by network
engineers; the encryption and authentication schemes are well tested
and in use throughout the world. A JUNOScript-specific access
mechanism would require testing and experience before being
considered trustworthy. In addition, using normal device login
mechanisms allows support for all authentication modules currently
supported under the JUNOS software (Radius, TACACS+, local password)
and all existing features built upon them (such as allow/deny command
sets).
Emerging standards for XML-based RPCs, such as SOAP, were not mature
at the time of the initial JUNOScript release. Juniper Networks will
continue to look at emerging standards in this area with a view to
adopting them where feasible as they become mature, standardized, and
widely accepted by the community.
3.4. Configuration Data
The JUNOScript API presents configuration data in the same hierarchy
as the native JUNOS user interface, with simpler encoding rules. The
UI attempts to make output more palatable to humans, but a JUNOScript
client needs only simple, exact rules. The JUNOS UI uses nested
braces to represent hierarchy:
protocols {
bgp {
group local {
neighbor 10.0.0.1 {
local-address 10.0.0.2;
}
}
}
}
In constrast, the JUNOScript API uses hierarchies of elements:
<configuration>
<protocols>
<bgp>
<group>
<name>local</name>
<neighbor>
<name>10.0.0.1</name>
<local-address>10.0.0.2</local-address>
</neighbor>
</group>
</bgp>
</protocols>
</configuration>
All configuration appears inside the <configuration> element. This
element can be received as output from the <get-configuration> RPC
and passed as input to the <load-configuration> RPC.
<rpc>
<get-configuration>
<configuration>
<protocols>
<bgp/> <!-- Requesting only 'protocols bgp' configuration -->
</protocols>
</configuration>
</get-configuration>
</rpc>
The above RPC requests a portion of the configuration using an
element hierarchy under the <configuration> element. The reply is
given as the same element hierarchy under a <configuration> element:
<rpc-reply>
<configuration>
<protocols>
<bgp>
<!-- Complete BGP configuration here -->
</bgp>
</protocols>
</configuration>
</rpc>
This allows a client to download a portion of the configuration
database, modify it, and reload it using the same syntax and
elements.
The JUNOScript API uses attributes to carry flags for configuration
statements. Boolean attributes are encoded as <tag flag="flag"/> to
allow for future extensions. The 'inactive' and 'active' attributes
turn on and off the 'inactive:' flag on the configuration statement,
effectively commenting out an entire hierarchy of statements. This is
the equivalent of the JUNOS UI's 'activate' and 'deactivate'
commands.
The 'replace' attribute functions as the 'replace:' tag in the JUNOS
UI, telling the UI to remove the contents of a statement before
inserting the incoming data. The 'delete' attribute directs the UI to
remove a statement from the configuration. These four attributes can
work together to generate a patch file for a configuration:
<configuration>
<protocols>
<bgp active="active"/> <!-- Activate bgp configuration -->
<ospf replace="replace"> <!-- Old ospf config is discarded -->
<new-configuration-here/> <!-- Replacement configuration -->
</ospf>
<isis delete="delete"/> <!-- Remove all isis configuration -->
<pim>
<add-this-to-pim/> <!-- Merge in this configuration -->
</pim>
</protocols>
</configuration>
3.5. Database Locking
The JUNOScript API provides an exclusive lock to the configuration
database to avoid conflicts between scripts and human users. The
JUNOS software uses a commit-based configuration model, where
multiple configuration changes can be committed as a group. A client
script running unattended in the middle of the night needs to be able
to avoid committing partial changes being entered by a human or
another script.
An exclusive lock on the database is granted using the <lock-
configuration/> RPC. The lock is granted only if no other user or
client holds an exclusive lock and if there are no pending
configuration changes. Users browsing the configuration database in
the CLI are not forcibly removed from the configuration editor, but
are unable to make changes to the database once an exclusive lock is
granted. The exclusive lock remains in place until either the session
is terminated or the <unlock-configuration/> RPC is requested.
3.6. Failure Modes
The JUNOScript API reports errors using the <junos:error> element.
This element can appear at any point during the RPC, and the client
must decide whether the entire <rpc-reply> should be discarded.
<junos:error>
<source>routing</source> <!-- The routing procotol daemon -->
<filename>incoming.conf</filename>
<line-number>415</line-number>
<column>16</column>
<token>bad-value</token>
<edit-path>protocols bgp</edit-path>
<statement>peer-as bad-value;</statement>
<message>Invalid value 'bad-value' for peer-as</message>
</junos:error>
4. Examples
The power of XML lies in the user's ability to manipulate the data
with both specific mechanisms (like custom software looking for
specific elements) and generic mechanisms (like XSLT transformations
that sort, filter, mutate, reorder, and render the data).
4.0.1. Hardware Inventory
The <get-chassis-inventory/> RPC returns a complete list of hardware,
organized by geographic location within the device's chassis, with a
hierarchy that looks like:
<rpc-reply host="rtr1.foo-foo.com"> <!-- attributes given by caller -->
<chassis-inventory>
<chassis> <!-- may appear multiple times -->
<chassis-module> <!-- may appear multiple times -->
<name>FPC 1</name>
<fpc>1</fpc>
<version>REV 01</version>
<part-number>710-001292</part-number>
<serial-number>AE3916</serial-number>
<chassis-sub-module> <!-- may appear multiple times -->
<name>PIC 3</name>
<pic>3</pic>
<version>REV 07</version>
<part-number>750-002303</part-number>
<serial-number>AS3329</serial-number>
<description>4x F/E, 100 BASE-TX</description>
</chassis-sub-module>
</chassis-module>
</chassis>
</chassis-inventory>
</rpc-reply>
An application would perform this RPC across a set of routers, and
concatenate the replies into a single XML document. This document
could then be run through an XSLT transformation to convert it into a
more interesting order, such as:
<inventory-list>
<inventory-item> <!-- may appear multiple times -->
<part-number>750-002303</part-number>
<serial-number>AS3329</serial-number>
<description>4x F/E, 100 BASE-TX</description>
<location>
<host>rtr1.foo-foo.com</host>
<fpc>1</fpc>
<pic>3</pic>
<reported>2001-07-25</reported>
</location>
</inventory-item>
</inventory-list>
This can be converted into XHTML and displayed on a Web page or
converted into another XML dialect and loaded into a spreadsheet. It
could be saved to an XML database or into a relational database using
the database's XML interface. The <inventory-list> from yesterday's
run could be loaded and compared to today's output using an XML
comparison program and render that result into text to be mailed out
to a notification mailing list.
4.0.2. Diagnose
Most network engineers have a small set of commands they run on a
device to get an overview of its status or to quickly narrow the
scope of their search for problems. They must then dig through the
output of those commands and separate the interesting data from the
noise.
A 'diagnose' application could determine what is wrong with a device
by emitting the RPC equivalent of those commands, assembling the
output into a single XML document and passing that document through a
XSLT transformation that discards the uninteresting elements and
assigns priorities to the remaining elements according to the design
of the individual network. This result could be rendered into a Web
page, saved to a database, compared to a recent new diagnosis
retrieved from the same database, and the differences rendered into
e-mail and dispatched to a notification mailing list. The same scheme
could be applied to an entire network of devices to determine what is
wrong with a network.
4.0.3. Vendor Neutral Configuration
One promising application for XML-based network-management is
configuration, since nothing else offers the easy access to complex
data. However, a single vendor solution to provisioning in a large
multi-vendor networks only addresses a portion of the problem. The
central issue is having a vendor-independent or vendor-neutral
configuration XML Schema, and supporting XSLT transformations that
translate a centralized database of information into individual
configuration files or XML document fragments that can be easily
loaded throughout the network.
Given the rate and style of feature implementation among the vendor
community, creating a single must-fit-all configuration schema may
not be realistic, but vendor extensions to translations to and from a
meta configuration is an achievable goal. Using XML, XSLT, and
related tool sets should help bring this idea from the world of blue
sky into the realm of possibility.
5. Network Management using XML
XML provides an excellent mechanism for encoding the complex data
that is used to manage networking gear. Building an API around an
XML-based RPC gives a simple, extensible way to exchange this data
with a device. Receiving data in XML opens easy options for handling
the data using standards-based tools. XML is widely accepted in other
problem domains, and free and commercial tools are emerging at an
accelerating rate. Using XSLT transformations allows data to be
recast in differing lights and converted to and from common formats.
JUNOScript RPCs provide a standards-based API to Juniper Networks
devices, allowing external applications to take full advantage of
their capabilities. Use of traditional device access mechanisms and
communication protocols allows access to a device under any
circumstance. Use of existing authentication and authorization
mechanisms minimizes the amount of new code in use, reduces the risk
of security problems, and increases the trust and comfort of users.
5.1. Battle Ready Technology
So the next question is: Is using XML for network management
worthwhile? To be worthwhile, a new contender must offer features not
available in other management technologies. There are five categories
in which XML shows its strength.
5.1.1. Ease of Use
XML is ASCII and can be generated, parsed, handled, stored,
retrieved, debugged, and documented using normal ASCII tools. XML is
self-describing; a tag labeled '<input-bytes>' has an obvious
meaning. Testing can be done by typing raw XML into a connection to
the JUNOScript server. Sessions can be logged into text files. Bug
reports can include this text and can be reproduced by hand.
5.1.2. Handling Complex Data
XML is structured data, able to represent complex data types and
relations using a hierarchy of elements. The structure of this
hierarchy can be given precisely in DTDs or XML Schemas.
DTDs and XML Schemas provide a formal mechanism for notification of
changes in the underlaying data. Using XML comparison tools against
old and new XML Schema files can provide details of what features,
options, or output tags have been added or deprecated.
5.1.3. Tools and Live Data
XML defines a simple encoding mechanism, but a wide range of tools
and supporting standards continue to appear around it.
- XPath can be used to find elements that match a particular set of
criteria
- XSLT can transform one dataset into another
- XML-enabled databases can store and retrieve XML
- XML comparison tools can report changes between XML documents
- SVG can perform data visualization
Getting a dataset in a form that can be handed directly to other
applications means freedom from writing and supporting custom code to
turn queries into structured results. The response to a JUNOScript
query is structured data and this structured data can be used as
input to another application.
XSLT can even turn XML Schemas into XSLT transformation scripts which
can then be run against incoming data. This transformation could take
advantage of the Schema's ability to contain application-specific
information to carry specific instructions into the generated XSLT
scripts.
5.1.4. Configuration
Configuration is a promising application for XML-based network
management. JUNOScript's rich set of configuration options and
features makes a perfect match for provisioning applications,
centralized network databases, configuration patch files, and
configuration archival.
5.1.5. Extensibility and Compatibility
XML has enough capabilities to allow migration, enhancements,
maintenance, and support for fast moving software. New tags are
ignored by old applications and new applications can handle the
absence of new tags. Servers can emit both new and old tags. Clients
can inspect DTDs or Schemas to determine software capabilities.
One open issue is how standardization efforts will define new tags
and how clients and servers could adjust as elements migrate into
standard form. Devices could provide XSLT transformations to convert
the devices' XML output into standard XML. This would allow support
of new standards on old software releases without requiring changes
on the device.
Using XML in the JUNOScript API has been rewarding. Leveraging the
existing XML tools has allowed this project to move at record speed.
Sending XML to a client application means it is operating outside the
proprietary sphere of the device as soon as it gets the results of an
RPC. The contents of the response are JUNOS-specific XML, but the
tools to handle the response are not.
6. Acknowledgments
The author would like to thank Rob Enns, Simon Gerraty, Paul Traina,
Reid Wilson, Wendy Cartee, Aviva Garrett, Mark Trostler, Tony Mauro,
Andy Spenser, Ed Harper, and the members of the Juniper Networks
Engineering group for their comments on this paper and the
underlaying technology.
7. References
[1] http://www.w3c.org/TR/REC-xml
[2] http://www.w3.org/TR/xmlschema-0/
[3] http://www.w3c.org/TR/xslt
[4] http://www.w3.org/TR/xhtml1/
[5] http://www.w3.org/TR/xquery/
[6] http://www.w3.org/TR/SVG/
[7] http://www.w3.org/TR/REC-DOM-Level-1
[8] http://www.w3.org/TR/soap12/
[9] http://www.ietf.org/rfc/rfc3080.txt
The JUNOScript API was introduced in version 4.3 of the JUNOS
software. For more information, please refer to the documentation on
the Juniper Networks web site.
8. Author's Information
Phil Shafer
Juniper Networks, Inc.
940 Main Campus Drive, Suite 100
Raleigh, NC 27606
Email: phil@juniper.net