Network Working Group Y. Teramoto
Internet-Draft Kyoto University
Intended status: Informational R. Atarashi
Expires: August 30, 2013 IIJ Research Laboratory
Y. Atarashi
Alaxala Networks Corp.
Y. Okabe
Kyoto University
Feb 26, 2013
Experience of Designing Network Management System
draft-teramoto-experience-network-management-01
Abstract
This document describes our experiences from designing and
implementing a large-scale local area network management system using
mainly NETCONF. We designed the data models for device
configurations and implemented NETCONF client to centrally control
multiple devices of various vendors. The document provides insight
on strong and weak points of current NETCONF approach. The document
also makes some recommendations about NETCONF and future network
management protocols.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 30, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Teramoto, et al. Expires August 30, 2013 [Page 1]
Internet-Draft Experience of Designing NMS Feb 2013
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Management System Setup . . . . . . . . . . . . . . . . . . . . 3
2.1. Required Information . . . . . . . . . . . . . . . . . . . 3
3. Experiences of Implementing NETCONF Client . . . . . . . . . . 4
3.1. Transport Protocol . . . . . . . . . . . . . . . . . . . . 4
3.2. Framing Mechanism on SSH transport . . . . . . . . . . . . 5
3.3. Capability Exchange . . . . . . . . . . . . . . . . . . . . 5
3.4. Lock and Commit Mechanism . . . . . . . . . . . . . . . . . 6
3.5. Notification . . . . . . . . . . . . . . . . . . . . . . . 6
4. Experiences with Data Model Design . . . . . . . . . . . . . . 7
4.1. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Experiences with Management Network . . . . . . . . . . . . . . 7
5.1. VLAN Configuration . . . . . . . . . . . . . . . . . . . . 7
6. Conclusions and Recommendations . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Teramoto, et al. Expires August 30, 2013 [Page 2]
Internet-Draft Experience of Designing NMS Feb 2013
1. Introduction
We designed a large-scale local area network management system that
can manage the network independently of physical topology and the
vendor of networking equipments composing the network system by
modeling the functions of network equipments and using widely used
network management protocols. To manage networks, we used mainly the
NETCONF protocol and the SNMP [RFC3416] because these protocols are
supported by various major vendors' networking equipments and does
not depend on specific architectures such as an OpenFlow or a MPLS.
This document describes the experiences from designing and
implementing such management system.
An NETCONF protocol is defined in [RFC6241] and is intended to manage
configurations of the networking equipment from computers. The
NETCONF protocol is supported by various network equipments such as
Cisco IOS and Junos and so on. We mainly used a NETCONF protocol to
get and edit configurations of networking equipments. Although many
networking equipments support the NETCONF protocol, there are some
kinds of data model designed by vendors. It is because the model
layer of NETCONF protocol is still developing. We designed the
unified data model for device configurations to manage multiple
equipments of various vendors and implemented NETCONF client to
control multiple devices simultaneously.
This document evaluates the NETCONF protocol design and makes some
recommendations about NETCONF and future network management protocols
to support large-scale network management.
2. Management System Setup
Our Network management system contains some information in database
to grasp network states and authorize management interface of
equipments. The NETCONF protocol and SNMP requires login
authorization on starting login. Moreover these protocols support
only the information for the configurations and states, and hence the
management system needs some information related to several
networking equipments such as the network topology and the routes of
IP packets. The remainder of this section describes the setup
information that is required to start network managing.
2.1. Required Information
Network Management systems usually require some information in
advance that the systems cannot retrieve from network devices
automatically like followings:
Teramoto, et al. Expires August 30, 2013 [Page 3]
Internet-Draft Experience of Designing NMS Feb 2013
Management Interface
One of the most fundamental information is login authorization for
connecting to management interfaces of network devices: management
IP address, user ID, password and so on. This is because
management protocols such as NETCONF and SNMP usually requires
authentication to get or edit device configurations at need to be
secured.
Device Information
The system requires the information for devices, such as the
vendor, the model and the version to determine the capabilities
and providing resource of the device, because NETCONF provides no
information and no unified models for them.
Network Information
Network Devices provides no information for network topology.
There are some protocols to get neighbor information such as LLDP,
however there is no standardized protocols to provide them into
client. Therefore, to manage network with network topology, the
topology information is to be prepared in advance.
3. Experiences of Implementing NETCONF Client
The NETCONF protocol is an XML-based protocol used to manage the
configuration of networking equipment. We implemented NETCONF client
to manage networking equipments centrally. This section provides
insight on NETCONF protocol.
3.1. Transport Protocol
The NETCONF protocol defines an SSH protocol as mandatory transport
protocol. The advantage of using the SSH protocol is that it
provides strong authentication mechanism and full encrypted
communication. However, there are some issues of using the SSH
protocol. It is very large protocol for developers to implement full
scratch client, therefore they need to use some existing libraries.
Network management systems often have their own architecture for
increasing performance, because it is often required high-performance
operation and response. SSH libraries also often have their own
architecture, and hence it is need to carefully bond two
architecture. This may cause performance degradation on multi-
threading software because these asynchronous events cannot be
concentrated into one. Furthermore, if encrypted communication is
forced like the SSH protocol, it is sometimes difficult to detect the
Teramoto, et al. Expires August 30, 2013 [Page 4]
Internet-Draft Experience of Designing NMS Feb 2013
cause of transport problems on debugging.
3.2. Framing Mechanism on SSH transport
The current framing mechanism of SSH transport is defined in
[RFC6242]. The previous version of NETCONF (version 1.0) defined
framing mechanism to separate each messages by the character sequence
"]]>]]>" according to the assumption that well-formed XML documents
does not contain the sequence, however it was found later that the
assumption is not collect. Therefore the current framing mechanism
of SSH uses chunked framing mechanism.
However framing mechanism still have confusing specification. The
framing mechanism defines no error notification mechanism when given
chunk-size is invalid or an error occurs on transport layer.
[RFC6242] requires the peer to terminate the NETCONF session
immediately without notifying error information when receiving such
an invalid message. This mechanism often causes confusing issues
that the developer cannot determine the reason of unexpected
disconnection, because the reason may exist on multiple layers from
physical layer to application layer. This problem also occurs on the
previous version.
3.3. Capability Exchange
Capabilities are advertised in messages sent by each peer during
session establishment as <hello> message. Each peer determines the
NETCONF version by comparing the sent capabilities with received one.
Furthermore this list can contain other additional capabilities such
as the capability of notification.
The mechanism of capability exchange have the same undesirable
specification as framing mechanism of the SSH transport. [RFC6241]
require peers to disconnect the session immediately when the
supporting capability version is mismatched or the treatment of
session-id is wrong.
The reaction of invalid <hello> varies by vendor implementations.
For example, the Junos returns error message as XML comments like
followings:
<!-- netconf error: unknown command -->
<!-- session end at 2012-08-30 19:01:10 UTC -->
Cisco IOS returns no error message and disconnected on receiving next
message by the frame chunk. This causes unexpected disconnection on
sending first <rpc> command.
This is notable that other management protocols that have capability
Teramoto, et al. Expires August 30, 2013 [Page 5]
Internet-Draft Experience of Designing NMS Feb 2013
exchange such as OpenFlow often support error notification mechanism
on receiving an invalid hello message.
3.4. Lock and Commit Mechanism
Lock mechanism of NETCONF is defined in [RFC6242] as mandatory
function. Commit mechanism is defined as optional function. These
commands are useful on controlling multiple devices.
3.5. Notification
The original NETCONF protocols does not provide networking equipments
to push some information to client. To send some information from
servers, notification mechanism is defined as optional capability in
[RFC5277].
Notification mechanism supports replaying the previous logs by
specifying startTime. After starting notification, the server can
only operate close-session command to terminate current session and
returns resource-denied error on receiving other commands. However,
the server that supports interleave capability can operate any
commands while notification phase. The client can specify stopTime
to stop the notification on the time. After stop time, NETCONF
session becomes ordinal mode and accept any NETCONF commands again.
This too complicated mechanism makes enormous number of session
states and conditions like following diagram; this makes it difficult
to create brief management system that support full NETCONF
specifications.
+-------+
| Hello |
+-------+
| <hello> exchange
S +-------+ <------+
t+>| RPC | <rpc> | return result
o| +-------+ -------+
p| | <create-subscription>
T| |<--------------------------+ Yes: return result
i| +--------+ <rpc> ----------- | No : return resource-denied
m+-| Notify |------< interleave? >-+
e +--------+ -----------
| <rpc><close-session/></rpc>
End
Figure 1: Session States and Conditions
Teramoto, et al. Expires August 30, 2013 [Page 6]
Internet-Draft Experience of Designing NMS Feb 2013
4. Experiences with Data Model Design
Current NETCONF protocol does not provide data models specification,
and hence there is no unified data models. Therefore, to manage
networking equipments of multiple vendors with same way, we designed
some models of the function that networking equipments provides.
This section describes the insight on current approach of
standardizing data models.
4.1. YANG
YANG is a data modeling language used to model configuration and
state data manipulated by the NETCONF defined in [RFC6020]. The
approach of YANG is to express various configurations using highly
expressive schema, while the approach of SNMP is to predefine
fundamental data model.
The same approaches of YANG often causes variability of configuration
model and also causes too large and complex data schema. Furthermore
YANG defines only the model schema, therefore the way to construct
model data is owed to the developer. We think the fundamental model
data, that is frequently used in configuration such as VLANs and
Interfaces, should be defined by NETCONF core specification like SNMP
in order to avoid such problems.
5. Experiences with Management Network
We designed the system to manage multiple network equipments of
multiple vendors that support the NETCONF protocol. This section
describes the experience with example of designing some function that
uses multiple networking equipments via NETCONF.
5.1. VLAN Configuration
VLAN configuration is one of most fundamental functions; however the
configuration needs various information. VLAN configuration requires
following information:
o Current VLAN assignment
o VLAN ID and port name to be assigned
o Additional information such as bandwidth, port state (some ports
may be disabled)
o Network topology
Teramoto, et al. Expires August 30, 2013 [Page 7]
Internet-Draft Experience of Designing NMS Feb 2013
First two information can be retrieved from NETCONF configurations.
The rest information, however, is more difficult than the former two.
NETCONF provides no information for the capability of networking
equipments, such as ports speed or the number of ports, that is not
shown as configuration text. NETCONF also does not offer topology or
neighbor information because of the same reason.
No current widely used protocols support the mechanism to retrieve
such information, therefore we have no choice but prepare them in
advance. However, an OpenFlow protocol now provide the way to get
them by handling LLDP packets using packet-out operation. This is
one of the reasons that an OpenFlow protocol is referred as a hot
protocol.
6. Conclusions and Recommendations
We come to deeply know about the NETCONF protocol on the view of
developers. This section conclude our experience and recommends some
requirements that future management protocol would satisfy.
The current NETCONF protocol have some undesirable specifications
like followings:
o Specify an SSH protocol as an mandatory transport protocol.
o Some undesirable error handling such as on capability exchange
failure
o Too many state and conditions of each session by notification
Furthermore, a current approach of models is going toward complicated
and large models by YANG. We propose future management protocols to
use simple transport protocol, to define appropriate error handling
that does not disconnect without any error notification, and to
provide simple notification mechanism that is supported by default
and supports interleave capability like function as default.
Current Network Management is required to use some similar protocols
such as NETCONF and SNMP. We found that the two protocol is covering
each other weakness that NETCONF does not support live information
and SNMP does not support configuration management. However, there
are few ways to get the capability of the networking equipments and
the information for constructing topology graphs. There are often
required to prepared in advance. There is a need to new management
protocols for flexibly control whole network by providing appropriate
models and information of the network.
Teramoto, et al. Expires August 30, 2013 [Page 8]
Internet-Draft Experience of Designing NMS Feb 2013
7. Security Considerations
In our experience, the NETCONF protocol require high security
considerations on the specification such as authorization and
encrypted messaging; therefore the use of the NETCONF protocol
improves the security of management.
To manage networking equipments centarally does not matter security
issues if they are used in separated logical network and operated
proper properly.
8. IANA Considerations
This document makes no request of IANA.
9. Normative References
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the
Simple Network Management Protocol (SNMP)", STD 62,
RFC 3416, December 2002.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011.
Teramoto, et al. Expires August 30, 2013 [Page 9]
Internet-Draft Experience of Designing NMS Feb 2013
Authors' Addresses
Yasuhiro Teramoto
Graduate School of Informatics Kyoto University
Yoshida-Hommachi
Sakyo-ku, Kyoto 606-8501
Japan
Phone: +81-75-753-7417
Fax: +81-75-753-7440
Email: teramoto@net.ist.i.kyoto-u.ac.jp
Ray S. Atarashi
IIJ Research Laboratory
Jinbocho Mitsui Bldg., 1-105 Kanda Jinbo-cho
Chiyoda-ku, Tokyo 101-0051
Japan
Phone: +81-3-5205-6464
Fax: +81-3-5205-6466
Email: ray@iijlab.net
Yoshifumi Atarashi
Alaxala Networks Corp.
Shin-Kawasaki Mitsui Bldg.
890 Saiwai-ku Kashimada
Kawasaki, Kanagawa 212-0058
Japan
Phone: +81-44-549-1735
Fax: +81-44-549-1272
Email: atarashi@alaxala.net
Yasuo Okabe
Academic Center for Computing and Media Studies Kyoto-University
Yoshida-Hommachi
Sakyo-ku, Kyoto 606-8501
Japan
Phone: +81-44-549-1735
Fax: +81-44-549-1272
Email: okabe@i.kyoto-u.ac.jp
Teramoto, et al. Expires August 30, 2013 [Page 10]