1. © Hitachi, Ltd. 2007. All rights reserved. NETCONF Configuration I/F Advertisement by WSDL and XSD Hideki Okita, Tomoyuki Iijima, Yoshifumi Atarashi, Ray S. Atarashi NETCONF Configuration I/F Advertisement with WSDL and XSD 70 th IETF, Vancouver Hideki Okita (Hitachi) Tomoyuki Iijima (ALAXALA Networks) Yoshifumi Atarashi (ALAXALA Networks) Ray S. Atarashi (IIJ) 2007/12/05

2. 2 © 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-netconf- schema-query-00.txt barring additional contributions from the community.)

3. 3 © Hitachi, Ltd. 2007. All rights reserved. 3 NETCONF Protocol Overview Basic Operation RFC4741 SSH Mapping RFC4742 SOAP Mapping RFC4743 BEEP Mapping RFC4744 Fine-grain locking Monitoring Advertise ment Configuration protocol Notification Protocol -11 Datamodel description language Notification datamodel Transport protocol mapping Configuration datamodel VLANDiff-ServACL XSDRelaxNGYang Chartered itemNot chartered itemNot published item

4. 4 © Hitachi, Ltd. 2007. All rights reserved. 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.

5. 5 © Hitachi, Ltd. 2007. All rights reserved. 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. Development Environment NMS developers Configuration I/F information Network Device edit-config Runtime Environment RFC get-config

6. 6 © Hitachi, Ltd. 2007. All rights reserved. 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

7. 7 © Hitachi, Ltd. 2007. All rights reserved. 7 Proposal IssueSolution How to know the config I/F information location Fixed URL How to get configuration I/F information HTTP RPC definition description method WSDL Type definition description method XSD (or RelaxNG, Schematron?)

8. 8 © Hitachi, Ltd. 2007. All rights reserved. 8 How to know config I/F info. location Model Example Method ProsCons OfflineFixed URL Implementati on cost Extensibility Online Original RPC (get-schema) ? NETCONF stack implementation cost BrokerUDDIExtensibility UDDI stack implementation cost Example URL: http://yourdevicename/netconf.wsdl (TBD)http://yourdevicename/netconf.wsdl We do not need to advertise the location on wire.

9. 9 © Hitachi, Ltd. 2007. All rights reserved. 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 Development Environment NMS developers Configuration I/F information Network Device HTTP GET Request HTTP Reply

10. 10 © Hitachi, Ltd. 2007. All rights reserved. 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 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 Message definition helloRequest, helloResponce rpcRequest, rpcResponce portType definition Service definition Binding definition Contents of a WSDL file XSD

11. 11 © Hitachi, Ltd. 2007. All rights reserved. 11 Example Type definition Several elements for configured functions are placed under the 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. interface id name type vlan id name ports acl id name flow diffserv id name flow XSD config Class diagram of an example datamodel XSD class XML SchemaClasses

12. 12 © Hitachi, Ltd. 2007. All rights reserved. 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.

13. 13 © Hitachi, Ltd. 2007. All rights reserved. 13 Thank you.

14. 14 © Hitachi, Ltd. 2007. All rights reserved. 14 Future NETCONF world Firewall device Carrier NMS Router Switch Enterprise NMS Home Gateway Set Top Box WLAN AP IPFIX Collector Switch AAA VLAN IP CALLHOME? VLAN IP IPFIX ACL VRRP VLAN Dot1X NETCONF VLAN Desired NETCONF datamodel IPFIX

15. 15 © Hitachi, Ltd. 2007. All rights reserved. 15 XSD or Yang ? Model by YangModel by WSDL & XSD Translation by Yang Tool Device developerNW Device NW OperatorManagement Tool NMS developerNMS Other Area Developer Other Area Device Each area has each preferable solution. However, standards should cover wide area.

16. 16 © Hitachi, Ltd. 2007. All rights reserved. 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.