Transcript PPT Version

XMLCONF
Topics
• Introduction
• Strategy
• Protocol Layering
• Session Management
• RPC Mechanism
• Capabilities Exchange
• Operational Model
• Protocol Operations
• Standard Schema
• Design Decisions
1
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
2
Introduction
History
• March, 2001 OPS-NM Area Meeting
Randy Bush asks crowd of 300 how many operators enable
SNMP writes. Zero hands raised
• April, 2001 – May 2002
OPS-NM Road show visits Operators at RIPE, NANOG, LISA to
determine network management needs
• June, 2002 IAB Workshop on Network Management
Operators want better scripting tools; Interest in XML
• July, 2002 XMLCONF BOF at IETF #54
Well attended, lots of interest, but no concrete proposals
• November, 2002
Small team started by Margaret Wasserman to write XMLCONF ID and attempt to get WG created
3
Introduction
Team members (in no particular order)
• Andy Bierman <[email protected]>
• Eliot Lear <[email protected]>
• David Perkins <[email protected]>
• Ted Goddard <[email protected]>
• Phil Shafer <[email protected]>
• Rob Enns <[email protected]>
• Ken Crozier <[email protected]>
• Steve Waldbusser <[email protected]>
• Margaret Wasserman <[email protected]>
4
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
5
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
6
Protocol Layering
Initial Protocol Mapping
XMLCONF
BEEP
TCP
IP
Other transport mappings (SSH, …) can be defined
7
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
8
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
9
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
10
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
11
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>
12
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
13
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
14
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
15
Operational Model
Configuration datastores
candidate
• Different
running
startup
variants of this model are possible
16
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
17
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
18
Protocol Operations: get-config
• Retrieve all or part of the specified configuration
• Parameters:
source: (@config-name)
config: (@element-tree | text)
format: (xml | text)
19
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>
20
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>
21
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
22
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)
23
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>
24
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
25
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
26
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>
27
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)
28
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
29
Protocol Operations: get-state
• Retrieve device state information
• Parameters:
state: (@element-tree | text)
format: (xml | text)
30
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>
31
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>
32
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)
33
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)
34
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
35
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
36
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>
37
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
38
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)
39
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…
40
Design Decisions
• Transport – Why BEEP first?
Connection oriented
Multi-channel capability
Simple and robust framing
Ability to initiate a connection from either end
41
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)
42
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 getnext
• Clear separation between configuration and state
information
43