Hi,
We prepared a draft document whose topic, we think, may belong to the scope of this group. We attached an abstract and the document for your reference. I wish to receive any comments. Many thanks in advance.
Taesang Choi
ETRI
Abstract
Currently, there is an ongoing activity in the IETF to define a
standard, XML-based protocol to manage the configuration of networks
and networking equipments. Defining initial requirements are underway
and one important requirement among them is co-existence with the
CLI. This document suggests a possible mechanism for this
requirement. It identifies some characteristics of CLI commands, and
provides the syntax of XML template which models such characteristics
of CLI commands. X-CLI is an API to manipulate XML templates in an
easy and robust way.
Internet-Draft BJ. Lee
Expiration Date: April 2003 TS. Choi
ETRI
October 2002
CLI-based Mediation Mechanism using XML for Configuration Management
Status of this Memo
This document is an Internet-Draft and is NOT offered in accordance
with Section 10 of RFC2026, and the autoer does not provide the IETF
with any rights other than to publish as an Internet-Draft.
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 April 2003.
Abstract
Currently, there is an ongoing activity in the IETF to define a
standard, XML-based protocol to manage the configuration of networks
and networking equipments. Defining initial requirements are underway
and one important requirement among them is co-existence with the
CLI. This document suggests a possible mechanism for this
requirement. It identifies some characteristics of CLI commands, and
provides the syntax of XML template which models such characteristics
of CLI commands. X-CLI is an API to manipulate XML templates in an
easy and robust way.
Conventions used in this document
Lee [Page 1]
Internet-Draft October 2002
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
1. Introduction
Traditionally, SNMP has been used as a major management protocol for
the IP network because of its simplicity. But as the network has
evolved and incorporated new technologies such as MPLS, VPN or QoS,
the policies for managing it has becomes too complex. Because of the
complexity of the policies for today's network, COPS was suggested as
one of the alternatives for SNMP. But, in spite of the several well-
defined and good features, like transaction management, security and
object-oriented message format, COPS is not being widely accepted by
network device vendors1. In addition, the PIB (Policy Information
Base) of COPS is being standardized more slowly than the evolution
speed of the new internet technologies. In that aspect, COPS is no
better than SNMP for the configuration management of network
providers.
For that reason, many administrators are using software systems
implemented on CLI (Command Line Interface) commands of the network
devices. CLI is the set of commands which are provided by the OS of a
network device. Those systems have a software component which
translates a policy into a sequence of CLI commands, and in most
cases, the component is written by some script-style programming
languages, such as Perl or Expect. The translation results are sent
to the network devices using the TELNET protocol, and the replies of
the devices are analyzed by the system to verify the execution result
of the CLI commands.
However, those ad-hoc systems are dependent on the syntax of the CLI
command. When the OS of a network device is upgraded, the
implementation of the translation module which does the policy-to-CLI
conversion should be modified. Moreover, the programming languages
used cannot be integrated easily with the other management solutions
written in general programming languages like C/C++.
In this document, we suggest X-CLI (XML wrapper API for CLI) as a
better alternative to SNMP, COPS, and CLI-based ad-hoc solutions. We
defined the syntax of the XML template to represent a group of CLI
commands, and provide the application programmers with X-CLI APIs
which have basic facilities for loading the XML template, passing
arguments, and sending generated CLI commands to the network devices.
X-CLI XML templates eliminate the need for programming policy-to-CLI
translation logic, and separate software from the syntax of CLI
commands.
Lee [Page 2]
Internet-Draft October 2002
Currently, there is an ongoing activity in the IETF to define a
standard, XML-based protocol to manage the configuration of networks
and networking equipments. Defining initial requirements are underway
and one important requirement among them is co-existence with the
CLI. This document suggests a possible mechanism for this
requirement.
2. The Characteristics of CLI Commands
2.1. Hierarchical Dependency
The CLI commands used in most network devices are executed in a
hierarchical manner. Figure 1 shows the configuration steps for
setting up an IBGP session between PE routers for the dissemination
of the route information in the VRF table.
+------------------------------------------------------------+
| (config)# router bgp 55555 |
| (config-router)#address-family ipv4 vrf VRF_SEOUL |
| (config-router-af)# neighbor 203.255.25.15 remote-as 55555 |
| (config-router-af)# neighbor 203.255.25.15 activate |
+------------------------------------------------------------+
Figure 1 : BGP configuration steps for
VPN at CISCO PE router
At each step, the prompt string for a CLI command changes according
to the dependency between the CLI commands: the execution of the
commands at the lower level of hierarchy depends on the success or
failure of the execution of the command at the upper level of
hierarchy. For example, the command "address-family ipv4 vrf VRF-
SEOUL" cannot be executed without the execution of the command
"router bgp 55555"± at the upper hierarchy. In this paper, we call
this kind of conditional behavior 'Hierarchical Dependency.'
2.2. Argument Dependency
The syntax of a CLI command consists of optional or required keywords
and arguments. A CLI command cannot be executed when required
arguments are omitted. The syntax of a command can be changed whether
the optional arguments are given or not. We name this kind of
behavioral and syntactic dependency "Argument Dependency." For
example, the command "router bgp <AS number>" in Figure 1 cannot be
executed if the required argument "<AS number>" is not given. An
example for argument dependency due to optional argument is shown in
section 3.1.
2.3. Result Dependency
Lee [Page 3]
Internet-Draft October 2002
As a result of the execution of one CLI command, one of the three
following messages is delivered to an administrator: (1) error report
string and prompt string (2) request for an additional input (3)
prompt string.
(1) indicates that the CLI command could not be processed for some
reason, and (2) notifies the administrator that he/she must give more
input to complete the operation of the command. (3) means that the
execution of the command was successful. When case (1) happens, most
of the commands which are scheduled to be given to the devices cannot
be delivered. For case (2), every scheduled command hangs until the
additional input is given by the administrator. We name this kind of
conditional behavior 'Result Dependency' between the current and the
waiting command.
The example for (2) can be found in Figure 2, which is an execution
result of an 'exit' command for Juniper routers. An additional input
is requested because that there are uncommitted configurations.
+-------------------------------------------------------+
| admin@m5# exit |
| The configuration has been changed but not committed. |
| Exit without uncommited changes? [yes/no] (yes) |
+-------------------------------------------------------+
Figure 2 : Request for additional input
for the command "exit"
3. XML Representation of the CLI commands
XML (Extended Markup Language) is a tag-based text format
standardized by W3C(http://www.w3.org). XML was formerly developed
for documents accessible through the WWW, but currently it is being
used in a variety of areas because it can represent data in a semi-
structured, easy-to-be-parsed form.
As briefly mentioned, we introduce the concept 'XML template' which
is correspondent to the 'function' in general programming languages
like C/C++. In addition, the XML template is designed to be able to
represent hierarchical dependency, argument dependency, and result
dependency. Because the XML template separates the policy-to-CLI
translation procedure from the software implementation, the network
management system implementation can be independent from the syntax
of a specific CLI command.
An XML template is loaded into memory by the X-CLI API and converted
into the sequence of CLI commands by passing arguments required. We
call this kind of conversion process "materialization." This process
Lee [Page 4]
Internet-Draft October 2002
is just like the act of passing arguments to a function which
generates some specific execution control flow.
The syntax of the XML template is covered in section 3.1 with a brief
explanation of the feature for representation of hierarchical
dependency and argument dependency. The materialization process is
described in section 4.1, and the execution procedure of the
materialization result is covered in the section 4.2 with the
representation method for the result dependency.
3.1 <cli> </cli>
The XML template is the hierarchy of <cli></cli> tag. We identified
the following attributes for <cli> tag to express the mentioned
dependencies. As their meanings are briefly described in the previous
part of the paper, some additional explanations will be given only
when needed. The name in the parenthesis is the actual attribute
name.
* identifier (tag)
* CLI command string (command)
* prompt string (prompt1, prompt2)
* error notification string (error)
* flag indicating that a CLI command can be executed in spite of
the execution failure of the previous CLI command (always)
* request for the additional input (ainput)
* response for the 'ainput' (ainputresponse)
The identifier (tag) is introduced for uniquely identifying
<cli></cli> tag. The prompt string is needed to send a CLI command to
the network device using TELNET protocol. Because the TELNET protocol
is interactive, there is no dedicated message format to detect that a
server has finished sending a message to a client. A client starts
sending messages to the server when the value of the attribute
'prompt1' is received from the server, and stops receiving replies
from the server until the value of the attribute 'prompt2' is
received. If not specified, the value of the attribute 'prompt2' is
the same as that of 'prompt2.'
The attribute 'command' has CLI command string as its value. The
attribute value consists of CLI keywords as defined by a network
device vendor, options enclosed by parenthesis, and formal argument
names starting with '$.' The formal argument names included in
options are called optional argument names, otherwise called required
arguments names. An example of the attribute value of 'command' is as
follows.
¡¡¡¡ping rapid $ipaddr ( count $count )
Lee [Page 5]
Internet-Draft October 2002
The above CLI command supported by the Juniper routers includes the
required argument name '$ipaddr' and optional argument name '$count.'
The CLI command is not materialized when the required argument value
is not passed by the programmer, and the option would not be included
in the materialized CLI command if the optional argument value is not
passed. Currently, we do not support nesting of options. Using the
required and optional argument names, the argument dependency is
represented.
A <cli> tag, which has no prompt and command attribute value, is
called a PAT (Pure Aggregation Tag). The other attributes of the PAT
are ignored. A PAT is used to specify that the enclosed group of
<cli> tags can be materialized repeatedly for one materialization of
the enclosing <cli> tag. A group of <cli> tags not enclosed by the
PAT can only be materialized once.
+---------------------------------------------+
| <!ELEMENT cli (#PCDATA | (cli)*) > |
| <!ATTLIST |
| tag CDATA #IMPLIED |
| prompt1 CDATA #IMPLIED |
| prompt2 CDATA #IMPLIED |
| command CDATA #IMPLIED |
| errorstr CDATA #IMPLIED |
| always (true | false) "false" |
| ainput CDATA #IMPLIED |
| ainputresponse CDATA #IMPLIED> |
+---------------------------------------------+
Figure 3 : DTD of <cli> tag
Using the attributes identified, we defined the DTD (Document Type
Definition) of the <cli> tag in Figure 3. DTD is the standardized
means of describing the component of XML documents. To express the
relations between the elements of XML documents, DTD supports syntax
which is similar to the regular expression grammar. The attributes of
a tag and their properties are also specified in the DTD.
In Figure 3, the 'ELEMENT' tag describes what element can be placed
between <cli> and </cli>: zero or more <cli></cli> tags or 'monitor
string.' The containment relationship between <cli> tags expresses
the hierarchical dependency, and the meaning of monitor string is
covered in the later part of this section.
The 'ATTLIST' tag lists the attributes of the <cli> tag. The first
column shows the names of the attributes, and their types are lined
up in the second column. 'CDATA' means that the type of the attribute
Lee [Page 6]
Internet-Draft October 2002
is a string. It is also possible to enumerate all the possible values
of the attribute in the form of '( true | false ).' The third column
is used to specify a default value for the attributes or to mark the
attributes as required or optional. The 'false' is specified as a
default value of the attribute 'always,' and all the other attribute
values are specified as optional by '#IMPLIED' keyword.
+--------------------------------------------------------------+
| <cli prompt1="#" command="config terminal" errorstr="^"> |
| <cli tag="bgp1" prompt1="#" |
| command="router bgp $asnum" errorstr="^"> |
| <cli> |
| <cli tag="bgp2" prompt1="#" |
| command="address-family ipv4 vrf $vrfname" |
| errorstr="^" |
| <cli> |
| <cli tag="bgp3" prompt1="#" |
| command="neighbor $ipn1 remote-as $nasnum" |
| errorstr="^"> |
| </cli> |
| <cli tag="bgp4" prompt1="#" |
| command="neighbor $ipn2 activate" |
| errorstr="^"> |
| </cli> |
| </cli> |
| <cli prompt1="#" always="true" command="exit"></cli> |
| </cli> |
| </cli> |
| <cli prompt1="#" always="true" command="exit"></cli> |
| </cli> |
| <cli prompt1="#" always="true" command="exit"></cli> |
| </cli> |
+--------------------------------------------------------------+
Figure 4 : XML template for Figure 1
The Figure 4 is an XML template for the CLI commands of Figure 1.
The hierarchy of the <cli> tags shows the dependency between those
CLI commands. When one <cli> tag cannot be materialized, the lower
tags belongs to it cannot be materialized. This kind of
materialization- related aspect of the hierarchical dependency is
closely covered in section 4.1. The operational aspects of the
hierarchical dependency are addressed in section 4.2 in depth.
As previously mentioned, it is possible to a have monitor string
between <cli> and </cli> instead of the other <cli> tags, and that
string is used to analyze the response which comes as an execution
result of a CLI command by the network device. The string can be
Lee [Page 7]
Internet-Draft October 2002
written following syntax which resembles that of the regular
expression grammar, and an example is provided in Figure 5.
+----------------------------------------------------------------+
| <cli tag="sysuptime" prompt1=">" command="show system uptime"> |
| Current time: $currentdate $currenttime |
| System booted: $bootdate $boottime |
| \( ($bootinfo)* \) |
| Protocols started: $protocoldate $protocoltime |
| \( ($protocolinfo)* \) |
| Last configured: $configuredate $configuretime |
| \( ($configureinfo)* \) |
| by $configuredbywho |
| $uptime up $updays $days, $time ( mins )*, |
| $numuser (user | users), |
| load averates: $load1, $load2, $load3 |
| </cli> |
+----------------------------------------------------------------+
Figure 5 : <cli> tag with monitor string
The tokens enclosed by '()*' can be repeated zero or more times, and
'|' represents an 'or' relationship. '´ is an escape sequence, and
the tokens starting with the '$' character are the output parameter
names. The execution results of a CLI command is pattern-matched with
a monitor string, and the matching result can be accessed through
output parameter names. To enhance the performance of the pattern
matching, the output parameter names can have types. The parameter
name prefixed with '$' is for string. '#' is used for integer and '@'
for date. '&' is used for floating-point real values. In section 4.3,
we present the detailed usage description of monitor string.
4. X-CLI API
The XML template addressed in the section 3 is classified into two
types by its usage. The first one is DCPF (Device Connection
Procedure File), and the second one is CLIF (CLI File).
The format of CLIF is already covered in the section 3. DCPF
describes the login procedure to the network device and can be
written in the same way as CLIF because the login id and the password
are delivered to the network device in the same way as the CLI
commands. The reason the connection procedure is separated from the
normal CLI commands is to facilitate the implementation of the
connection pooling mechanism and relieve the overhead of including
the connection procedure in every XML template.
The X-CLI API performs the following functions for the DCPF and CLIF.
Lee [Page 8]
Internet-Draft October 2002
* load DCPF into memory
* materialize DCPF by passing arguments
* execute the materialized DCPF
* load CLIF into memory
* materialize CLIF by passing arguments
* execute the materialized CLIF
X-CLI API has the architecture of Figure 6 to support above
functionalities effectively.
+---+ +-------------------------+
| A | | CLI Processor |
| P | | +------------+ +---+ | +--------+
| I | | | XML Parser | | C |<---->| Device |
| | | +------------+ | o | | +--------+
| I | | +------------+ | n | |
| n | | | Regular | | n | | +--------+
| t |<->| | Expression | | |<---->| Device |
| e | | | Processor | | P | | +--------+
| r | | +------------+ | o | |
| f | | +------------+ | o | | +--------+
| a | | | Connection |<->| l |<---->| Device |
| c | | | Manager | | | | +--------+
| e | | +------------+ +---+ |
+---+ +-------------------------+
Figure 6 : Architecture of X-CLI API
The API uses a CLI processor module, which is composed of XML parser,
a regular expression processor and a connection manager. The XML
parser translates the loaded XML template into an internal data
structure. The connection manager sends the materialized XML template
to the network device, and processes the response. The connection
manager manages the connection pool to improve the overall
performance of the API. The regular expression processor is only used
for the CLI command with a monitor string.
4.1 Materialization
After the XML template is loaded into the memory, that template is
translated into the internal data structure which is implemented by
C++. This data structure has a tree topology composed of the objects
which are the instances of a C++ class 'CLI.' This tree is
materialized to the sequence of the CLI commands.
The materialization steps for that tree are determined by the tree-
traversal algorithm which uses arguments as an input. The algorithm
traverses the tree following the order of the argument submission,
Lee [Page 9]
Internet-Draft October 2002
and when the traversal fails, it means that the argument submission
order is wrong and that the hierarchical dependency is broken.
XCLI bgp;
// ...
bgp.load_clif("bgp.xml");
bgp.clif.set_argument("bgp1", "asnum", "55555");
bgp.clif.set_argument("bgp2", "vrfname", "VRF-A-Seoul");
bgp.clif.set_argument("bgp3", "ipn1", "203.255.255.13");
bgp.clif.set_argument("bgp3", "nasnum", "5555");
bgp.clif.set_argument("bgp4", "ipn2", "203.255.255.13");
if ( bgp.clif.send("xxx.xxx.ne.kr", 23) <= 0 ) {
cout << "cli execution has failed" << enld;
}
Figure 7 : Usage of X-CLI API
The Figure 7 depicts a usage example of X-CLI API which loads CLIF
bgp.xml and passes some arguments and sends the materialized result
to the device. The argument passing is through the interface
'set_argument(),' and the passed arguments are stored in the argument
queue before they are used for the materialization. The
aterialization process is started by the invocation of function
'send(),' and the argument queue is used as an input for the process.
Because the user of the X-CLI API needs only to consider the order of
the argument passing, the codes dependent of the CLI syntax is
eliminated from the implementation of the management system, and this
enhances the overall maintainability of the system.
As briefly mentioned, the materialization process is defined by the
tree traversal algorithm. As only a fraction of the traversal path is
suggested by the argument passing order, we designed a
materialization algorithm which transforms the partial path of the
traversal into a sequence of the complete CLI commands in the Figure
1. The details about the error handling mechanism are omitted.
The algorithm of Figure 8 operates like this: if the node passed to
the algorithm is not PAT, check if the node needs an argument. If it
does, see if the argument at the front of the argument queue is
acceptable. If so, invoke the 'process()' function to materialize the
node. If not, return. If the node does not need an argument,
materialize it by calling the 'process()'. After that, recursively
apply the materialization algorithm to all the child nodes. When the
materialization for all the children ends, check if the current node
is PAT. If the node is PAT, there is a possibility of re-
materialization of the children. If the re-materialization is
Lee [Page 10]
Internet-Draft October 2002
possible, do it once again.
algorithm materialize(CLI root_node) {
if ( root_node is not a PAT ) {
if ( root_node needs an argument ) {
if ( argument at the front of argument_queue
is for the root_node ) {
argument = argument_queue.pop_front();
process(CLI, argument);
}
else {
return;
}
}
else {
process(CLI);
}
}
restart :
for ( i = 0; i < root_node.children_count(); ++i ) {
materialize(root_node.child[i]);
}
if ( root_node is PAT && argument at the front of
argument_queue is for one of the children of
root_node ) {
goto restart;
}
}
Figure 8 : Materialization algorithm
4.2 Sending the Materialized Result to the Device
The result of materialization is a sequence of objects of the type
'CLI_transformed.' 'CLI_transformed' is a C++ class which basically
includes all the attributes of the 'CLI' class as its attributes.
In addition to those basic attributes, objects of CLI_transformed
have an additional attribute 'BTEF (Branch Target for Execution
Failure)' to represent the result dependency. When there is an
execution failure of a CLI command, the following CLI command
scheduled to be executed is not executed when there is hierarchical
dependency between the failed and the scheduled command. If there is
no hierarchical dependency, the scheduled command is not executed if
the value of its 'always' attribute is 'false.'
For this result dependency, every materialized CLI command should
have two branch targets according to what CLI command should be
Lee [Page 11]
Internet-Draft October 2002
executed after the success or failure of a CLI command. If it is a
success, the branch target is always the next CLI command
materialized. Otherwise, the branch target is the next sibling CLI
command which shares the same parent CLI command with the current
one. Because it is enough to model the case of failure, only the
BTEF attribute is introduced.
+--------------------------------------+
|config terminal |
+--------------------------------------+
+--------------------------------------+
+----|router bgp 55555 |
| +--------------------------------------+
| +--------------------------------------+
| +--|address-family ipv4 vrf VRF-A-Seoul |
| | +--------------------------------------+
| | +--------------------------------------+
| | |Neighbor 203.255.15.13 remote-as 55555|
| | +------------------|-------------------+
| | +------------------v-------------------+
| | |Neighbor 203.255.15.13 remote-as 55555|
| | +------------------|-------------------+
| | +------------------v-------------------+
| | |exit |
| | +--------------------------------------+
| | +--------------------------------------+
| +->|exit |
| +--------------------------------------+
| +--------------------------------------+
+--->|exit |
+--------------------------------------+
Figure 9 : Materialized result of Figure 4
In the Figure 9, the materialization result is diagrammed. The XML
template in Figure 4 is used, and the arguments are provided by the
procedure described in Figure 7. The control flows from the top of
the Figure 9 to the bottom, step-by-step. At each stage of the CLI
command execution, the control flows following a BTEF when a failure
occurs. If there's no explicit BTEF configured to follow, the next
CLI command is the valid BTEF. After the first branch to the BTEF,
the control shifts following only the BTEF, and executes the CLI
command which has 'true' value for the attribute 'always.'
4.3. Response Processing
After the materialized CLI command is executed, the result of the
execution can be analyzed using a monitor string. As previously
Lee [Page 12]
Internet-Draft October 2002
mentioned, this analyzing process is done by the pattern-matching
procedure defined by the regular-expression-like syntax of the
monitor string. The monitor string is transformed into NFS (Non-
deterministic Finite Automata), and this automata is used for pattern
matching.
After the pattern matching, the outcome of the analyzing process can
be retrieved by the output argument name and OCID (Occurrence ID).
The OCID is introduced to interpret the nested structure of the
matched result. For example, let's assume the following monitor
string:
goo $g ( foo $f ( bar $b )* )*
For this monitor string, "goo g foo a bar b bar c foo aa bar bb" can
be successfully matched. But when you want to retrieve the value
matched for the output parameter $f, it becomes important to know
which value you want to get because there are two different values
matched for $f: 'a' and 'aa.' This is for the nested structure of the
matched string drawn in Figure 10.
+--------------------------------------+
| goo g (OCID : 1) |
| +----------------------------------+ |
| | foo a (OCID : 11) | |
| | +------------------------------+ | |
| | | bar b (OCID : 111) | | |
| | +------------------------------+ | |
| | +------------------------------+ | |
| | | bar c (OCID : 112) | | |
| | +------------------------------+ | |
| +----------------------------------+ |
| +----------------------------------+ |
| | foo aa (OCID : 12) | |
| | +------------------------------+ | |
| | | bar bb (OCID : 121) | | |
| | +------------------------------+ | |
| +----------------------------------+ |
+--------------------------------------+
Figure 10 : Nested structure and OCID
All part of the nested structure is identified by the OCID. The
topmost block of the nested structure always has OCID value 1. The
OCID of the other part of the structure can be calculated by the
following formula.
OCID = upper block's OCID*10 + occurrence number of this block
Lee [Page 13]
Internet-Draft October 2002
The following API is provided for the retrieval of response
processing outcomes. The argument to be passed is the identifier name
for identifying a CLI command(same value with attribute 'tag').
Because there can be multiple response analyze result, the return
type of the API is list.
list<CMonitorResult*>* CLIF::get_result(const string& tag);
By using that interface, a simple monitoring program which uses X-CLI
API and XML template which has been described in Figure 5 can be
written like this:
#include <iostream>
#include <list>
#include "xcli.h"
using namespace std;
int main() {
XCLI xcli;
//
// log in
//
xcli.dcpf.load("xcli-login-juniper.xml");
xcli.dcpf.set_argument("passwd1", "passwd1", "admin");
xcli.dcpf.set_argument("passwd2", "passwd2", "xxxxxx");
if ( xcli.dcpf.send("m5.xxxxx.ne.kr", 23) > 0 ) {
xcli.clif.load("showSystemUptime.xml");
if ( xcli.clif.send("m5.xxxxx.ne.kr", 23) > 0 ) {
list<CMonitorResult*>* result =
xcli.clif.get_result("sysuptime");
if ( result != 0 ) {
list<CMonitorResult*>::iterator i;
for ( i = result->begin(); i != result->end(); ++i ) {
cout << "current date : "
<< (*i)->get_argument("currentdate", 1)
<< endl;
}
}
else {
cerr << "result is not gathered" << endl;
}
}
Lee [Page 14]
Internet-Draft October 2002
else {
cerr << "monitor statement has failed" << endl;
}
}
}
Figure 11 : Sample program for monitoring
the get_argument() function of CMonitorResult object receives two
argument. The first is argument name, and the second is OCID.
5. Transaction issue
To guarantee the consistency of the device configuration, a policy
which could not be enforced to the device should be completely
removed from it. In the same manner, a policy which could not be
withdrawn from the device should be maintained. This kind of all-or-
nothing semantic should be followed.
But, the failure occured during executing a materialized sequence of
CLI commands leaves the device in a inconsistent state. To overcome
this, enforce-withdraw template pair can be used. Actually, for
every policy there should be an 'enforce' XML template to enforce
that policy to the device, and 'withdraw' XML template to withdraw it
from the device. this required pair of templates can be used to
quarantee the consistency of the device configuration.
Automatic rollback mechanism using the special CLI commands like
"rollback" cannot be used. Because that kind of command is not
supported by every vendor of the network devices, the machanism is
not a right fit for the mediation technology like X-CLI.
6. Other Considerations
There are number of issues which should be covered by this mechanism
for the completeness sake. Important ones are operations on
configuration blocks (whole or partial), operations on configuration
data objects, configuration validation, trasaction handling,
configuration rollback and transport security.
Operations on configuration blocks whether whole or partial can be
supported by this mechanism. Since this mechanism doesn't assume any
transport protocol and data representation, it can accept any form of
configuration data and can be converted into appropriate CLI
commands. For example, if the operation requires loading an entire
configuration file into a device, it can be read and converted into a
sequence of CLI commands. Configuration validation can be handled as
specified in section 4.3 in this document.
Lee [Page 15]
Internet-Draft October 2002
Issues about transaction handling and configuration rollback are
briefly covered in section 5. transport security can be achived by
replacing TELNET protocol with SSH or any other security-enabled
protocol which supports the virtual terminal capability which is
essential for the execution of CLI commands.
Another alternative is a SSH tunnel. If the SSH tunnel is used, the
implementation of X-CLI on top of the TELNET protocol can be intact.
A overhead only incurred by using it is some administration chores to
setup the tunnel between a X-CLI enabled application and network
devices.
Security Considerations
Security-related extension method of X-CLI API is briefly described
in section 6. Replacing TELNET with SSH or TELNET through the SSH
tunnel can be the most easy solution for solving problems about
transport security.
Lee [Page 16]
Internet-Draft October 2002
References
[1] Jim Bray, Jean Paoli, C. M. Sperberg-McQueen and Eve Marler,
"Extensible Markup Language(XML) 1.0 (Second Edition)",
http://www.w3.org/TR/2000/REC-xml-20001006.
[2] K.Chan et al., "COPS Usage for Policy Provisioning (COPS-PR)",
RFC3084, IETF, March, 2001.
[3] TS Choi, SH Yoon, HS Chung, CH Kim, JS Park, BJ Lee, TS Jeong,
"Wise<TE>: Traffic Engineering Server for a Large-Scale MPLS-
based IP Network", NOMS 2002, accepted for publication.
[4] CISCO, "MPLS Traffic Engineering and Enhancement", CISCO White
Paper, Release Numer 12.1(3)T, 2001. http://www.cisco.com
[5] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
Switching Architecture", RFC3031, IETF, January 2001.
[6] D. Awduche, J. Malcolm, J. Agogbua, M. D'Dell, J. McManus,
"Requirements for Traffic Engineering Over MPLS", RFC2701, IETF,
September 1999.
[7] Ivan Pepelnjak and Jim Guichard, "MPLS and VPN Architectures",
CISCO Press, 2000.
Author's Address:
Byung-Joon Lee
Engineering Staff,
ETRI, 161 Gajeong-Dong, Yuseong-Gu, Daejon, 305-350, South Korea
bjlee@etri.re.kr
Taesang Choi
Seniour Engineering Staff,
ETRI, 161 Gajeong-Dong, Yuseong-Gu, Daejon, 305-350, South Korea
choits@etri.re.kr
Lee [Page 17]