1 / 43

XMLCONF: Standard XML-based Network Configuration Framework

XMLCONF is an effort within the IETF to promote XML-based network management, with a focus on configuration. It aims to replace proprietary CLI scripts and provide a standard protocol for configuration, monitoring, and notifications.

williamslinda
Download Presentation

XMLCONF: Standard XML-based Network Configuration Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. XMLCONF Topics • Introduction • Strategy • Protocol Layering • Session Management • RPC Mechanism • Capabilities Exchange • Operational Model • Protocol Operations • Standard Schema • Design Decisions

  2. Introduction What is XMLCONF? • Effort within the IETF to promote XML based Network Management • Focus on configuration because it is the biggest unmet need wrt/ IETF NM standards • Include support for monitoring and notifications • Focus on replacement for Expect/Perl scripts which interact with proprietary CLI

  3. Introduction History • March, 2001 OPS-NM Area MeetingRandy Bush asks crowd of 300 how many operators enable SNMP writes. Zero hands raised • April, 2001 – May 2002OPS-NM Road show visits Operators at RIPE, NANOG, LISA to determine network management needs • June, 2002 IAB Workshop on Network ManagementOperators want better scripting tools; Interest in XML • July, 2002 XMLCONF BOF at IETF #54Well attended, lots of interest, but no concrete proposals • November, 2002Small team started by Margaret Wasserman to write XMLCONF I-D and attempt to get WG created

  4. Introduction Team members (in no particular order) • Andy Bierman <abierman@cisco.com> • Eliot Lear <lear@cisco.com> • David Perkins <dperkins@dsperkins.com> • Ted Goddard <ted.goddard@windriver.com> • Phil Shafer <phil@juniper.net> • Rob Enns <rpe@juniper.net> • Ken Crozier <kcrozier@cisco.com> • Steve Waldbusser <waldbusser@nextbeacon.com> • Margaret Wasserman <mrw@windriver.com>

  5. Strategy • Create a standard operational framework for configuration • Allow for monitoring and notifications, but focus on configuration • Separate the protocol from the data model • Allow for standard and proprietary content • Standardize the protocol first, and then start on content • Create a transport independent, RPC-based configuration mechanism • Standardize XMLCONF protocol over BEEP/TCP first • Develop high level protocol operations common to most devices • Focus on transactions

  6. Strategy • Allow implementation to mirror native capabilities of device • Text-based technology such as XML permits tight integration with CLI • No feature lag between XMLCONF and CLI

  7. Protocol Layering Initial Protocol Mapping Other transport mappings (SSH, …) can be defined

  8. Protocol Layering Functional Layers • XML Content • Standard or Proprietary XML Schemas • Protocol Operations • Standard XML Schema (XMLCONF) • RPC • Standard XML Schema (XMLCONF) • Session • Create standard channels through BEEP • Security • SASL, TLS through BEEP • Transport • TCP • Network • IP

  9. Session Management Channels • Management channel • Session control; creation of other channels • Abort command kills current command on the operations channel • Kill-session used to terminate the session of another user • Operations channel • Used for RPC requests and replies • Notification channel • Optional channel for asynchronous messages

  10. RPC Mechanism XML Based Messages • <rpc> • Request on operations channel • <rpc-reply> • Reply sent on operations channel • <rpc-progress> • Provides progress reports (percentage completion) for long duration RPC operations, sent on the management channel • <rpc-abort> • Provides a way to abort an RPC in progress, or queued for processing, sent on the management channel • <rpc-abort-reply> • Abort RPC reply, sent on the management channel

  11. RPC Mechanism Error reporting • <rpc-error> • Included in <rpc-reply> if an error occurs during processing of an RPC request • <ok> • Included in <rpc-reply> if no error occurred during processing of an RPC request

  12. Capabilities Exchange Base protocol + optional capabilities • Each peer sends capabilities summary during session startup • Capability is used only if both parties advertise the same version of the same capability • Capability expressed as a URI • <capability>http:/ietf.org/xmlconf/1.0/base</capability><capability>http:/ietf.org/xmlconf/1.0/base#notifications</capability> <capability>http:/ietf.org/xmlconf/1.0/base#candidate</capability><capability>http:/ietf.org/xmlconf/1.0/base#lock</capability> • At least 1 version of the base protocol must be advertised • Vendor specific capabilities may also be advertised • <capability>http:/example.com/xmlconf/1.0/extensions</capability>

  13. Capabilities List Initial set • Base protocol • Set, Get and Copy configuration commands • Get system state information • Optional Capabilities • Notification channel supported • Separate candidate (scratchpad) configuration • Lock configuration for exclusive writing • Candidate configuration (commit and rollback) • Configuration Validation • Separate startup (NV-stored) configuration • Named Configurations can be stored on the device

  14. Operational Model: Concepts Basic framework concepts • A device contains one or more configuration datastores • Some of these datastores have special semantics • candidate, running, startup • Configuration datastores can be created, copied, retrieved, deleted, and validated

  15. Operational Model: Datastores Special configuration datastores • candidate • Collects changes that are applied all at once to the running config • Exists only if candidate capability is supported • running • Current device configuration; changes to this config take effect immediately • Exists on all devices • startup • Configuration to apply to device upon next reboot • Exists only if distinct startup capability is supported

  16. Operational Model Configuration datastores candidate running startup • Different variants of this model are possible

  17. Operational Model: Named Configs • A simple text (or XML) file that contains a complete or partial configuration • Optionally supported by the device • Specified with a ‘file’ URL

  18. Protocol Operations Low Level Standard Commands • Base set • get-config, edit-config, copy-config, delete-config, get-state, kill-session • Configuration locking supported • lock, unlock • Configuration validation supported • validate • Candidate configuration supported • commit, discard-changes

  19. Protocol Operations: get-config • Retrieve all or part of the specified configuration • Parameters: • source: (@config-name) • config: (@element-tree | text) • format: (xml | text)

  20. Protocol Operations: get-config request <rpc id="102"> <get-config> <source><running></running></source> <config xmlns="http://example.com/schema/v2.1/config"> <users></users> </config> <format>xml</format> </get-config> </rpc>

  21. Protocol Operations: get-config reply <rpc-reply id="102“><get-config> <config xmlns="http://example.com/schema/v2.1/config"> <users> <user> <name>root</name> <type>superuser</type> </user> <user> <name>fred</name> <type>admin</type> </user> </users> </config></get-config> </rpc-reply>

  22. Protocol Operations: get-config notes • The element sub-tree specified in the <config> parameter is used to filter the response. • Multiple filter elements can be specified • Wildcard characters currently not supported in a standard way • Use of XPath subset being debated; More complicated but more standard and more powerful approach • One or more namespace declarations (xmlns) must be included in the <config> parameter which correspond to the XML Schema defining the configuration commands used (unless format is text) • Text format for <config> parameter allows CLI style ASCII instead of XML element tree

  23. Protocol Operations: edit-config • Load all or part of a specified configuration to the designated target configuration. • Parameters: • target: (@config-name) • test-option: (test-then-set | set) [default: set] • write-option: (merge | replace | overwrite) [default: merge] • error-option: (stop-on-err | ignore-err) [default: stop-on-err] • format: (xml | text) • config: (@URL | @config-name | @element-tree | text)

  24. Protocol Operations: edit-config request <rpc id="101"> <edit-config> <target><running></running></target> <test-option>test-then-set</test-option> <write-option>replace</write-option> <error-option>stop-on-error</error-option> <format>xml</format> <config xmlns="http://example.com/schema/v1.2/config"> <interface name="Ethernet0/0"> <address> <ipv4>1.2.3.4</ipv4> <ipv4-mask>255.0.0.0</ipv4-mask> </address> </interface> </config> </edit-config> </rpc>

  25. Protocol Operations: edit-config notes • One or more namespace declarations (xmlns) must be included in the <config> parameter which correspond to the XML Schema defining the configuration commands used (unless format is text) • Text format for <config> parameter allows CLI style ASCII instead of XML element tree • The <config> parameter includes zero or more commands; could be an entire configuration file

  26. Protocol Operations: copy-config • Overwrite the target configuration with the source configuration • Parameters: • source: (@config-name | URL) • target: (@config-name | URL) • format: (xml | text) • Restrictions • Remote to remote copy is not supported • Device may not support URL based source or target parameter • Device may restrict protocol types specified in URL

  27. Protocol Operations: copy-config request <rpc id="103"> <copy-config> <source> <url>ftp://example.com/myconfig.txt</url> </source> <target><running></running></target> <format>text</format> </copy-config> </rpc>

  28. Protocol Operations: copy-config edit-config and copy-config differences • <edit-config> is used to apply partial or complete configuration commands to the designated target configuration • Complex set options supported such as test-then-set or merge • <copy-config> is used to overwrite a complete configuration file with a different complete configuration file • Hardwired set options (set without validation, replace, ignore errors)

  29. Protocol Operations: delete-config • Remove a specific local configuration file • Parameters: • target: (@config-name) • Restrictions: • The running config cannot be deleted • The device may refuse to delete the startup config

  30. Protocol Operations: get-state • Retrieve device state information • Parameters: • state: (@element-tree | text) • format: (xml | text)

  31. Protocol Operations: get-state request <rpc id="104"> <get-state> <state xmlns="http://example.com/schema/v3.2/int-stats"> <interface name="ethernet0/1"> <statistics></statistics> </interface> </state> <format>xml</format> </get-state> </rpc>

  32. Protocol Operations: get-state reply <rpc-reply id="104"> <get-state> <state xmlns="http://example.com/schema/v3.2/int-stats"> <interface name="ethernet0/1“> <statistics> <inPkts>9456823</inPkts> <inOctets>1228484566</inOctets> <inErrors>4326</inErrors> <outPkts>4821050</outPkts> <outOctets>634712154</outOctets> <outErrors>2096</outErrors> </statistics> </interface> </state> </get-state></rpc-reply>

  33. Protocol Operations: lock, unlock • Lock is used to prevent any other sessions from writing to a specific configuration • Applies to all access mechanisms, not just XMLCONF • Partial locks are not supported in v1.0 • Can request automatic rollback on ungraceful unlock • Unlock is used to release a previously obtained lock • Lock can fail if: • Lock is already granted • Candidate configuration has already been written but not saved • Lock automatically released if the session is terminated for any reason • Kill-session operation used to force another session to release a lock • Configuration name is the only parameter (in v1.0)

  34. Protocol Operations: validate • Validate is used to check configuration commands before they are applied to the running configuration • Applies to any configuration datastore • Tests performed depend on the device • Syntax check is performed at a minimum • Referential check may be performed • Resource check may be performed • Parameters: • source: (@config-name) • format: (xml | text)

  35. Protocol Operations: commit • Commit operation activates candidate configuration • Available if ‘candidate’ capability is supported • Parameters: • confirmed: requires a confirming commit or commit will be backed out • confirmed-timeout: timeout period for confirmed commit, default is 10 minutes

  36. Protocol Operations: <rpc-error> • <rpc-error> is inserted in <rpc-reply> if an error occurred • Standard error message format (still TBD): • <rpc-error> <tag>UI_RANGE_ERROR</tag> <error-code>207</error-code> <severity>error</severity> <software-component>interface-daemon</software-component> <edit-path>interfaces so-0/0/0</edit-path> <statement>mtu 40000;</statement> <message>mtu exceeds allowable maximum</message> <action>discarded</action></rpc-error> • Multiple error responses would be returned per request if applicable

  37. Protocol Operations High Level Remote Procedure Call • Generic RPC provided to allow high-level operations, not replace low-level protocol operations • High level procedure such as ‘set-bgp-peer’ • Function could be achieved with multiple low-level operations, but done as a high-level RPC for ease-of-use • Example: • <rpc xmlns="http://ietf.org/xmlconf/1.0/rpc"> <my-own-method xmlns="http://example.net/me/1.0/my-own"> <my-first-parameter>14</my-first-parameter> <another-parameter>fred</another-parameter> </my-own-method></rpc>

  38. Notifications • An XMLCONF peer advertising the ‘notifications’ capability supports the notification channel • Used for sending asynchronous messages • <open-notifications> operation requests opening notification channel with specific parameters • format: rfc3195 is the only legal value (in v1.0) • <close-notifications> requests that the notification channel be closed

  39. Standard Schema • Version 1.0 will have some standard attributes • Some attributes are needed for the protocol to function properly: • Show session information • Show lock information • List named configurations (name, size, last modified timestamp) • Show debug information (capabilities advertised, capabilities in use)

  40. Design Decisions • RPC – Why not SOAP? • XMLCONF’s RPC is low overhead, easy to understand, implement, debug • SOAP’s interoperability value based on transport over HTTP – want XMLCONF transport over BEEP, SSH, console…

  41. Design Decisions • Transport – Why BEEP first? • Connection oriented • Multi-channel capability • Simple and robust framing • Ability to initiate a connection from either end

  42. XMLCONF Summary • Provides common operational framework for configuration management • Focus on features needed for configuration, like locking and rollback, generic high-level RPC mechanism • Support for simple transactions • Building block for network transactions • Configuration model maps to real-world networks (candidate, running, startup)

  43. XMLCONF Summary • Leverages existing standards • Standard and proprietary XML content is supported • Monitoring functions and notifications are supported, but protocol is not optimized for monitoring • Hierarchical content filtering used instead of get-next • Clear separation between configuration and state information

More Related