Transcript NETCONF Configuration I/F Advertisement by WSDL and XSD

NETCONF Configuration I/F
Advertisement with WSDL and XSD
70th IETF, Vancouver
2007/12/05
Hideki Okita (Hitachi)
Tomoyuki Iijima (ALAXALA Networks)
Yoshifumi Atarashi (ALAXALA Networks)
Ray S. Atarashi (IIJ)
© Hitachi, Ltd. 2007. All rights reserved.
2
netconf WG re-charter
• 3. Schema advertisement:
– Currently the NETCONF protocol is able to advertise
which protocol features are supported on a particular
netconf-capable device. However, there is currently
no way to discover which XML Schema are supported
on the device. The NETCONF working group will
produce a standards-track RFC with mechanisms
making this discovery possible.
– This item may be merged with "NETCONF
monitoring" into a single document.
– (The initial draft will be based on draft-scott-netconfschema-query-00.txt barring additional contributions
from the community.)
© Hitachi, Ltd. 2007. All rights reserved.
2
3
NETCONF Protocol Overview
Configuration datamodel
VLAN
Diff-Serv
Notification
datamodel
ACL
Datamodel description language
XSD
RelaxNG
Yang
Configuration protocol
Basic
Operation
RFC4741
Fine-grain
locking
Monitoring
Notification Protocol
-11
Advertise
ment
Transport protocol mapping
SSH Mapping
RFC4742
Chartered item
SOAP Mapping
RFC4743
BEEP Mapping
RFC4744
Not chartered item Not published item
© Hitachi, Ltd. 2007. All rights reserved.
3
4
NETCONF datamodel users
• There are several types of NETCONF
datamodel users:
–
–
–
–
–
Network device developers
Network operators
NMS developers
IT System developers
IT System operators
• We focus on NMS developer’s requirement.
© Hitachi, Ltd. 2007. All rights reserved.
4
5
Requirement from NMS developers
• To advertise NETCONF device
configuration interface as Remote
Procedure
– To incorporate remote procedure into the
NMS developer’s development environment.
NMS
Development
developers Environment
get-config
edit-config
Network
Device
Configuration
I/F information
RFC
Runtime
Environment
© Hitachi, Ltd. 2007. All rights reserved.
5
6
Approach
• Follow existing RPC-base programming:
– Know where the RPC information is located.
– Get actual RPC information from the place and the method.
• RPC definition (name, input type, output type)
• Type definition
– Generate stub classes on their development environment from
the RPC information.
• E.g. helloResType hello( helloReqType );
• Major development environments, Java and .NET support automatic
stub class generation from WSDL and XSD.
• RelaxNG provides plug-ins for these environments.
– Write original code with the stub classes.
• We need to standardize following methods.
–
–
–
–
How to know the location of RPC information (config I/F info.)
Access method to the RPC information
RPC definition description method
Type definition description method
© Hitachi, Ltd. 2007. All rights reserved.
6
7
Proposal
Issue
How to know the config
I/F information location
How to get configuration
I/F information
RPC definition
description method
Type definition
description method
Solution
Fixed URL
HTTP
WSDL
XSD (or RelaxNG,
Schematron?)
© Hitachi, Ltd. 2007. All rights reserved.
7
8
How to know config I/F info. location
Example
Method
Pros
Cons
Offline
Fixed URL
Implementati
on cost
Extensibility
Online
Original RPC
(get-schema)
?
NETCONF stack
implementation cost
Extensibility
UDDI stack
implementation cost
Model
Broker
UDDI
Example URL: http://yourdevicename/netconf.wsdl (TBD)
We do not need to advertise the location on wire.
© Hitachi, Ltd. 2007. All rights reserved.
8
9
How to get configuration I/F information
• Proposal
– HTTP access to configuration I/F information
• GET method implementation does not require much resource
to your device.
• Based on RFC4743
HTTP GET Request
HTTP Reply
Network
Device
NMS
Development
developers Environment
Configuration
I/F information
© Hitachi, Ltd. 2007. All rights reserved.
9
10
RPC/Type definition by WSDL/XSD
• WSDL can define RPC
interface.
– It defines method name, input
type, and output type.
– Vendor specific RPCs can be
added.
• Type definition by XSD is
included in <types> in a
WSDL file.
• We can use other semantic
description language like
OWL for additional semantics.
• This proposal is based on
RFC4743 and the NMS
product vendor’s request.
Types definition
XSD
Message definition
helloRequest, helloResponce
rpcRequest, rpcResponce
portType definition
<hello> <rpc>
Binding definition
Service definition
Contents of a WSDL file
© Hitachi, Ltd. 2007. All rights reserved.
10
11
Example Type definition
• Several elements for
configured functions are
placed under the
<config> element
• Each element or a vendor
specific type can be
defined by specific XSD
and namespace.
• XSD is translated from
UML class diagram.
• This is based on the
router/switch product
development sequence.
config
interface
id
name
type
vlan
id
name
ports
acl
id
name
flow
diffserv
id
name
flow
Class diagram of an example datamodel
XSD
XSD
XSD
XSD
XSD
XSD
XSD
class
XML Schema
Classes
© Hitachi, Ltd. 2007. All rights reserved.
11
12
Summary
• We focus on NMS developers’ requirement
– Advertisement of the NW device’s configuration I/F
information to NMS development environment.
• We propose combination of following methods.
– Fixed URL and HTTP
– WSDL/XSD for RPC/type definition
• Our proposal is based on RFC4743, product
implementation, and NMS vendor’s request.
– WSDL/XSD/UML are not future technologies. They
have long history and are widely deployed on major
development environments.
• Compared to other solution, NMS developers
can minimize their implementation cost by this
proposal.
© Hitachi, Ltd. 2007. All rights reserved.
12
13
Thank you.
© Hitachi, Ltd. 2007. All rights reserved.
13
14
Future NETCONF world
Carrier NMS
Enterprise NMS
Router
Firewall device
IP
IPFIX
Switch
ACL
NETCONF
VLAN
IPFIX
Switch
VRRP
VLAN
Dot1X
IPFIX Collector
IPFIX
NETCONF
Home Gateway
AAA
CALLHOME?
IP
Set Top Box
NETCONF
VLAN
WLAN AP
VLAN
Desired NETCONF datamodel
© Hitachi, Ltd. 2007. All rights reserved.
14
15
XSD or Yang ?
Model by Yang
Model by WSDL & XSD
Translation by Yang Tool
Device developer
NW Operator
NW Device
Management
Tool
NMS developer
Other Area
Developer
NMS
Other Area
Device
Each area has each preferable solution.
However, standards should cover wide area.
© Hitachi, Ltd. 2007. All rights reserved.
15
16
NETCONF applicability
• NMS development
– Remote procedures on NW devices are incorporated by the
advertised NETCONF configuration I/F information
– I/F advertisement by WSDL/XSD is suitable since they are
widely deployed on major commercial development
environments
• Network device development
– Readability and independency are important.
– Making NETCONF datamodel with Yang may suitable for
developers not familiar with XSD.
– Yang to XSD translation contributes to expand NETCONF
application to wide area including APP area in IETF and other
W3C-related area.
© Hitachi, Ltd. 2007. All rights reserved.
16