Network Working Group BJ. Lee Internet-Draft TS. Choi Expiration Date: April 2003 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. Lee Expires April 2003 [Page 1] Internet-Draft CLI-based Mediation Mechanism using XML October 2002 Conventions used in this document 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 Lee Expires April 2003 [Page 2] Internet-Draft CLI-based Mediation Mechanism using XML October 2002 commands. 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 " in Figure 1 cannot be executed if the required argument "" is not given. An example for argument dependency due to optional argument is shown in section 3.1. Lee Expires April 2003 [Page 3] Internet-Draft CLI-based Mediation Mechanism using XML October 2002 2.3. Result Dependency 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 Lee Expires April 2003 [Page 4] Internet-Draft CLI-based Mediation Mechanism using XML October 2002 into the sequence of CLI commands by passing arguments required. We call this kind of conversion process "materialization." This process 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 The XML template is the hierarchy of tag. We identified the following attributes for 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 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. Lee Expires April 2003 [Page 5] Internet-Draft CLI-based Mediation Mechanism using XML October 2002 ¡¡¡¡ping rapid $ipaddr ( count $count ) 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 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 tags can be materialized repeatedly for one materialization of the enclosing tag. A group of tags not enclosed by the PAT can only be materialized once. +---------------------------------------------+ | | | | +---------------------------------------------+ Figure 3 : DTD of tag Using the attributes identified, we defined the DTD (Document Type Definition) of the 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 and : zero or more tags or 'monitor string.' The containment relationship between 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 tag. The first Lee Expires April 2003 [Page 6] Internet-Draft CLI-based Mediation Mechanism using XML October 2002 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 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. +--------------------------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +--------------------------------------------------------------+ 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 tags shows the dependency between those CLI commands. When one 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 and instead of the other tags, and that Lee Expires April 2003 [Page 7] Internet-Draft CLI-based Mediation Mechanism using XML October 2002 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 written following syntax which resembles that of the regular expression grammar, and an example is provided in Figure 5. +----------------------------------------------------------------+ | | | 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 | | | +----------------------------------------------------------------+ Figure 5 : 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. Lee Expires April 2003 [Page 8] Internet-Draft CLI-based Mediation Mechanism using XML October 2002 The X-CLI API performs the following functions for the DCPF and CLIF. * 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- Lee Expires April 2003 [Page 9] Internet-Draft CLI-based Mediation Mechanism using XML October 2002 traversal algorithm which uses arguments as an input. The algorithm traverses the tree following the order of the argument submission, 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 Lee Expires April 2003 [Page 10] Internet-Draft CLI-based Mediation Mechanism using XML October 2002 is PAT. If the node is PAT, there is a possibility of re- materialization of the children. If the re-materialization is 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.' Lee Expires April 2003 [Page 11] Internet-Draft CLI-based Mediation Mechanism using XML October 2002 For this result dependency, every materialized CLI command should have two branch targets according to what CLI command should be 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 Lee Expires April 2003 [Page 12] Internet-Draft CLI-based Mediation Mechanism using XML October 2002 After the materialized CLI command is executed, the result of the execution can be analyzed using a monitor string. As previously 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. Lee Expires April 2003 [Page 13] Internet-Draft CLI-based Mediation Mechanism using XML October 2002 OCID = upper block's OCID*10 + occurrence number of this block 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* 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 #include #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* result = xcli.clif.get_result("sysuptime"); if ( result != 0 ) { list::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 Expires April 2003 [Page 14] Internet-Draft CLI-based Mediation Mechanism using XML 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 Lee Expires April 2003 [Page 15] Internet-Draft CLI-based Mediation Mechanism using XML October 2002 sequence of CLI commands. Configuration validation can be handled as specified in section 4.3 in this document. 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 Expires April 2003 [Page 16] Internet-Draft CLI-based Mediation Mechanism using XML 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: 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 Expires April 2003 [Page 17]