Internet DRAFT - draft-atarashi-netconfmodel-architecture
draft-atarashi-netconfmodel-architecture
Network Working Group R. Atarashi
Internet-Draft Internet Initiative Japan Inc.
Expires: January 15, 2007 H. Okita
Central Research Laboratory,
Hitachi, Ltd.
Y. Atarashi
Alaxala Networks Co.
E. Boschi
Hitachi Europe SAS
July 14, 2006
Netconf System Architecture
draft-atarashi-netconfmodel-architecture-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The NETwork CONFiguration (NETCONF) protocol has been designed to
configure routers, switches, firewalls and other network devices.
Atarashi, et al. Expires January 15, 2007 [Page 1]
Internet-Draft Netconf System Architecture July 2006
This document describes a high level description of the Netconf
architecture and how the Netconf framework relates to other network
management protocols and architectures.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. NETCONF Protocol . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
2. NETCONF System Architecture . . . . . . . . . . . . . . . . . 5
2.1. NETCONF Manager . . . . . . . . . . . . . . . . . . . . . 5
2.2. NETCONF Device . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. SOAP/HTTP(S) Transport Mapping . . . . . . . . . . . . 7
2.2.2. SSH Transport Mapping . . . . . . . . . . . . . . . . 8
2.2.3. BEEP Transport Mapping . . . . . . . . . . . . . . . . 9
2.3. NETCONF System Functions . . . . . . . . . . . . . . . . . 10
3. Relation to other Protocols . . . . . . . . . . . . . . . . . 12
3.1. NETCONF Role in Network Management System . . . . . . . . 12
3.2. Network Management System Reference Model using
NETCONF protocol . . . . . . . . . . . . . . . . . . . . . 12
4. NETCONF Applicability . . . . . . . . . . . . . . . . . . . . 15
4.1. Target Networks . . . . . . . . . . . . . . . . . . . . . 15
4.2. Network Operation Scenario . . . . . . . . . . . . . . . . 15
5. Event Notification . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Comparison of Event Notification Protocols . . . . . . . . 20
5.2. Event Handling Architecture . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6.1. Configuration Sniffing . . . . . . . . . . . . . . . . . . 24
6.2. Spoofing of the NETOCNF Manager . . . . . . . . . . . . . 24
6.3. Spoofing of the NETCONF Device . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
Atarashi, et al. Expires January 15, 2007 [Page 2]
Internet-Draft Netconf System Architecture July 2006
1. Introduction
1.1. NETCONF Protocol
NETCONF Protocol [2] is specified as standardized protocol for
network devices configuration by network management system. NETCONF
Protocol is used to configure routers, switches, firewall appliance
and other network devices. With NETCONF Protocol, the network
management system can configure the network devices in unified
procedure.
NETCONF Protocol is a client-sever type protocol based on RPC model
communication, which provides a response for each configuration
request. NETCONF uses Extensible Markup Language (XML) [13] to
describe its protocol messages and its configuration data.
Applications can access the structure and contents of the messages
and data with XML parsers. These features enable network management
systems to automate its network management process. For example,
with XML Stylesheet Language Transformation (XSLT) [14] , the
management system can transform responses from network devices into a
human-readable form to indicate the response for operators.
NETCONF Protocol is divided into four layers shown in the following
figure (Figure 1). NETCONF Protocol operations are classified into
configuration and notification. NETCONF configuration operations are
unified by NETCONF RPC. The NETCONF RPCs are mapped into three
transport protocols, SSH [3], SOAP/HTTP(S) [4] and BEEP [5]. NETCONF
notification [6] operations are mapped directly into the transport
protocols.
Layer Example
+-------------+ +-------------------------------------------+
| Content | | Configuration data |
+-------------+ +-------------------------------------------+
| |
+-------------+ +-------------------------------------------+
| Operations | | <get-config>, <edit-config> <notification>|
+-------------+ +-------------------------------------------+
| | |
+-------------+ +-----------------------------+ |
| RPC | | <rpc>, <rpc-reply> | |
+-------------+ +-----------------------------+ |
| | |
+-------------+ +-------------------------------------------+
| Application | | BEEP, SSH, SSL, console |
| Protocol | | |
+-------------+ +-------------------------------------------+
Atarashi, et al. Expires January 15, 2007 [Page 3]
Internet-Draft Netconf System Architecture July 2006
Figure 1: NETCONF Protocol Layers
1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [8].
1.3. Motivation
This document describes the Netconf architecture for the
configuration of routers, switches, firewalls and other network
devices. It provides a description of the Netconf framework key
components and their functions.
In the Operation and Management Area, there exist various management
protocols, such as for instance SNMP [9], SYSLOG, IPFIX, DIAMETER.
Each of these protocols is optimized for its objective. For example,
SNMP is a basic network management protocol implemented almost all
network devices and has an ability to set and extract MIB-defined
management information on network devices. SNMP has an event
notification function called "SNMP trap", and other of the above
mentioned protocols also have the ability to notify management
information, e.g. system status changes, flow statistics,
authentication, authorization and accounting.
This draft discusses the role of the NETCONF protocol in the entire
network management system and its relation to other operation and
management protocols.
Atarashi, et al. Expires January 15, 2007 [Page 4]
Internet-Draft Netconf System Architecture July 2006
2. NETCONF System Architecture
In this section, we describe the architectural components of the
NETCONF manager and the NETCONF device.
2.1. NETCONF Manager
Figure 2 shows the components on the NETCONF manager. With these
components, it automates network management operation.
NETCONF Manager
+------------------------------------------------------+
|+----------------------------------------------------+|
+----------+ || +-----------+ +---------+ +---------+ +----------+||
|Other | || |NETCONF | |Visualize| |User | |Configs, |||
|Network |<-++->|Automation | |Tool | |Interface| |Status, |||
|Management| || |Application| | | | | |Policies |||
|System | || | | | | | | | (XML DB) |||
|System | || +-----------+ +---------+ +---------+ +----------+||
+----------+ |+----------------------------------------------------+|
| ^ ^ |
| | | |
| | +------------+-------------------------+ |
| | | | | | |
| | | | v +-------------+| |
| | | +-------------------+ | Config || |
| | | | Network Level API | | Datamodel || |
| | | +-------------------+ | (XML Schema)|| |
| | | ^ +-------------+| |
| | | | | |
| | +------------+-------------------------+ |
| | | |
| +------+-----------------+-------------------------+ |
| | | | | |
| | v v +--------------+| |
| | +--------------------------+ | Config || |
| | | NETCONF API | | Datamodel || |
| | +--------------------------+ | (XML Schema) || |
| | +--------------+| |
| +--------------------------------------------------+ |
+------------------------------------------------------+
Figure 2: NETCONF Manager Components
Atarashi, et al. Expires January 15, 2007 [Page 5]
Internet-Draft Netconf System Architecture July 2006
Visual Design Tool: The visual Design Tool visualizes network
topology and type of each device on display. It follows network
topology change and update the links and nodes on the display. It
is also used to validate the network topology before the actual
change is carried out.
User Interface: The user interface is the interface for the operators
to instruct the NETCONF manager to transfer the configuration data
which they create to NETCONF device via NETCONF protocol. This
interface receives designation of the target device in the form of
IP address or host name. This interface indicates the operator
about the configuration data applied to the devices.
NETCONF Application: The NETCONF application is the main component of
the NETCONF manager to automate the network operation. It
implements configuration operation logic. According to this
logic, Network level API and NETCONF API are called from a NETCONF
application. Further, the application interacts with other
network management systems like SNMP server, and receives the
information about events which occurred in the network from the
systems.
Configs, Status, Policies: An XML database on the NETCONF manager
contains the configuration set, the abstract network model and the
network policies, which are described in XML. XML technologies
can also describe semantics including relation. We can generate
device dependent configuration from device independent
configuration using XML technology.
NETCONF Configuration Datamodel: A configuration datamodel defines
element type and data type in the NETCONF protocol message and
configuration data. This datamodel is composed of XML schema.
Components in the NETCONF manager share this datamodel.
NETCONF API: NETCONF API is the API to operate the objects defined in
a network device. This API , being called from upper layer
application, creates NETCONF RPC message to operate the designated
object(s) and transport this RPC message to corresponding NETCONF
device.
Network Level API: Network level API is the API to operate the
objects extended over the network. This API is called from upper
layer application and internally calls NETCONF API.
2.2. NETCONF Device
A NETCONF device has two kinds of functional blocks, NETCONF message
analysis block and device internal configuration interface. These
Atarashi, et al. Expires January 15, 2007 [Page 6]
Internet-Draft Netconf System Architecture July 2006
blocks cooperate for configuration of the device itself via NETCONF
protocol.
The NETCONF message analysis block receives the NETCONF protocol
message from the NETCONF manager. It extracts the operation command
described in XML from the NETCONF protocol message and translates the
operation command into internal message format and passes the
translated operation command to the internal configuration interface
block. This block contains transport protocol dependent block, XML
translation block, and configuration data model described by XML
schema. The transport dependent block and the XML translation block
use configuration datamodel to validate and analyze the received
NETCONF message.
The XML translation block contains Extensible Stylesheet Language
Transformations (XSLT) module and/or custom module(s). The custom
modules may use XML API like Document Object Model (DOM) [16] or
Simple API for XML (SAX) [17] to translate the NETCONF operation
message. The modules extract NETCONF operation block from the RPC
message, and starts the processes corresponding to the operation
block.
2.2.1. SOAP/HTTP(S) Transport Mapping
Since the NETCONF protocol has three candidates for its transport
protocol, components of the NETCONF device vary according to the
selected transport protocol. In the NETCONF device with SOAP/HTTP
transport mapping (Figure 3), the NETCONF message analysis block
executes SSL decryption followed by HTTP session termination. It
extracts SOAP data from the HTTP request and removes SOAP envelope
and extracts the NETCONF RPC message including NETCONF operation
message. The XSLT module or a custom module receives the operation
message including the transported configuration data.
The NETCONF device implementors can use the optional module of the
Web server implementation to implement SSL, SOAP, XSLT function
block. On Java 2 Enterprise Environment (J2EE), they can integrate
even proprietary module(s) as Enterprise Java Bean (EJB) on EJB
container. Each EJB is bound to the NETCONF operation extracted from
NETCONF RPC message.
Atarashi, et al. Expires January 15, 2007 [Page 7]
Internet-Draft Netconf System Architecture July 2006
Configuration Data
|
+-------------+---------------------------+
| | |
| v |
| +-----------------------------------+ |
| | +------------------+ +----------+ | |
| | | SSL Module | | Config | | |
| | +------------------+ | Model | | |
| | | HTTP Engine | | (XML | | |
| | +------------------+ | Schema | | |
| | | SOAP Module | | | | |
| | +------+-----------+ +----------+ | |
| | |XSLT |Custom | | |
| | |Module|Modules(s) | | |
| | +------+-----------+ | |
| +-----------------------------------+ |
| | |
| v |
| +-----------------------------------+ |
| | Network Device | |
| | Internal Configuration Interface | |
| +-----------------------------------+ |
+-----------------------------------------+
Figure 3: NETCONF Device Architecture (SOAP/HTTP(S) Mapping)
2.2.2. SSH Transport Mapping
In the NETCONF device with SSH transport mapping (Figure 4), the
NETCONF message analysis block has SSH stack and XML parse/RPC stack.
The SSH stack manages secure channels to the NETCONF manager, and
passes the transported NETCONF protocol message and configuration
data to the XML parse/RPC stack. The RPC stack specifies the
requested operation and, according to the operation type, calls the
corresponding internal configuration interface of the network device.
Atarashi, et al. Expires January 15, 2007 [Page 8]
Internet-Draft Netconf System Architecture July 2006
Configuration Data
|
+-------------+---------------------------+
| | |
| v |
| +-----------------------------------+ |
| | +------------------+ +----------+ | |
| | | SSH Stack | | | | |
| | +------------------+ | Config | | |
| | +------------------+ | Model | | |
| | | XML Parse | | (XML | | |
| | | /RPC Stack | | Schema) | | |
| | +------------------+ +----------+ | |
| | +-----++-----------+ | |
| | |XSLT ||Custom | | |
| | |Stack||Stack(s) | | |
| | +-----++-----------+ | |
| +-----------------------------------+ |
| | |
| v |
| +-----------------------------------+ |
| | Network Device | |
| | Internal Configuration Interface | |
| +-----------------------------------+ |
+-----------------------------------------+
Figure 4: NETCONF Device Architecture (SSH Mapping)
2.2.3. BEEP Transport Mapping
In the NETCONF device with BEEP transport mapping (Figure 5), the
NETCONF message analysis block has TLS and optionally SASL stack and
BEEP stack. The TLS stack manages the secure channels to the NETCONF
manager, and passes the transported NETCONF protocol message and
configuration data to the BEEP stack. According to the operation
type, the BEEP stack calls the corresponding internal configuration
interface of a network device.
Atarashi, et al. Expires January 15, 2007 [Page 9]
Internet-Draft Netconf System Architecture July 2006
Configuration Data
|
+-------------+---------------------------+
| | |
| v |
| +-----------------------------------+ |
| | +------------------+ +----------+ | |
| | | TLS/SASL Stack | | Config | | |
| | +------------------+ | Model | | |
| | +------------------+ | (XML | | |
| | | BEEP Stack | | Schema) | | |
| | +------------------+ +----------+ | |
| | +-----++-----------+ | |
| | |XSLT ||Custom | | |
| | |Stack||Stack(s) | | |
| | +-----++-----------+ | |
| +-----------------------------------+ |
| | |
| v |
| +-----------------------------------+ |
| | Network Device | |
| | Internal Configuration Interface | |
| +-----------------------------------+ |
+-----------------------------------------+
Figure 5: NETCONF Device Architecture (BEEP Mapping)
2.3. NETCONF System Functions
The NETCONF manager transports, via the NETCONF protocol, the
configuration data customized for each NETCONF device in the network.
The configuration operations are classified into merge, replace,
create and delete of the configuration on the NETCONF devices. The
NETCONF manager should confirm the acceptance or failure of the
configuration data on the NETCONF devices by NETCONF RPC reply from
the devices.
In addition to the configuration function, the NETCONF protocol has a
notification function[6], which allows asynchronous message
transmission between the NETCONF manager and the NETCONF devices.
The NETCONF devices notify errors, warnings and information about
configuration changes occurred on the devices to the NETCONF manager.
The NETCONF manager creates event notification subscription
specifying the events of interest.
In the configuration and notification operation, the NETCONF manager
and the NETCONF devices share the same data model to parse the
Atarashi, et al. Expires January 15, 2007 [Page 10]
Internet-Draft Netconf System Architecture July 2006
protocol message and configuration data described in XML. This
datamodel is described by XML schema and its contents are mapped into
objects on the NETCONF devices. From the application point of view,
application on the NETCONF manager accesses these mapped objects to
configure the NETCONF devices. NETCONF protocol intermediates this
object operation between the NETCONF manager and the NETCONF devices.
Atarashi, et al. Expires January 15, 2007 [Page 11]
Internet-Draft Netconf System Architecture July 2006
3. Relation to other Protocols
3.1. NETCONF Role in Network Management System
Traditional networks require human intervention to numerous events
happening in the network. Network operators should deal promptly
with network events, for example, topology change due to additional
router or switch they installed, and network trouble from device
failure. When these events occur, the operators create substitute
configuration optimized for each device and apply these configuration
to each device via proprietary configuration interface of each
device.
The role of the NETCONF protocol is transmission of the configuration
data from the NETCONF manager to the NETCONF devices, and
notification of the event information about configuration data on the
NETCONF devices. The objective of the NETCONF protocol adoption is
the reduction of network operation cost by automating network
operator's configuration task. A network management system with
NETCONF system configures the network devices automatically based on
the network event. Using the NETCONF protocol, the NETCONF system
distributes the configurations of the devices generated by the
network management system according to the pre-defined algorithm or
rule.
To automate network operation, network management system should
detect events and gather event information in the network. The
network management system combine NETCONF configuration/notification
function with other event management function, for example, Simple
Network Management Protocol (SNMP), IP Flow Information Export
(IPFIX) protocol, SYSLOG protocol. We should consider how we combine
these protocols with NETCONF protocol function. The interaction
between Netconf and those protocols should be addressed.
3.2. Network Management System Reference Model using NETCONF protocol
Figure 6 shows reference model of entire network management system.
It includes NETCONF manager, NETCONF devices and other network
management servers like SNMP server, Syslog server and Flow
Collector.
Atarashi, et al. Expires January 15, 2007 [Page 12]
Internet-Draft Netconf System Architecture July 2006
+-----------+
| NETCONF | Interaction
| Manager |<- -----------------+--------+---------+
| | | | |
+-----------+ | | |
^ | | |
NETCONF | | | |
Notification | +------+--------+---------+------+
| | | | | |
| | v v v |
| | +-------+ +------+ +---------+ |
NETCONF | | |SNMP | |Syslog| |flow | |
Configuration | | |Manager| |Server| |Collector| |
(RPC reply) | | +-------+ +------+ +---------+ |
| | ^ ^ ^ |
| | | | | |
| +------+--------+---------+------+
| | | |
NETCONF | | | |
Configuration | |SNMP |SYSLOG | IPFIX
(RPC request) | | | |
| | | |
+--------------+----------------------+ | | |
| | | | | |
| v | | | |
|+---------+ +---------+ +---------+ | | | |
|| Network | | Network | | Network |<-+--+ | |
|| Device | | Device | | Device |--+-----------+ |
|| | | | | |--+---------------------+
|+---------+ +---------+ +---------+ |
| |
+-------------------------------------+
Figure 6: Network Management System Reference Model using NETCONF
protocol
Following events can be a trigger of the NETCONF configuration in the
system.
Network operator's operation
NETCONF notification
Other event gathering
At first, network operators configure network device via NETCONF
protocol to define VLAN, assign IP address, initiate routing
Atarashi, et al. Expires January 15, 2007 [Page 13]
Internet-Draft Netconf System Architecture July 2006
protocol, activate filtering function, and management functions.
NETCONF manager applies configuration data to network devices by
NETCONF RPC. Network devices start to forward frames/packets and to
interact with management servers via SNMP, SYSLOG protocol, IPFIX
protocol, and some other management protocols. In the configuration
data, NETCONF manager tells addresses of management servers and
exported information.
Network devices send NETCONF notification message to the NETCONF
manager when configuration status or device construction changed.
These events come from direct configuration without the NETCONF
protocol or parts replacement of the devices by the operators, or
some failure of the devices.
Configured network devices notify asynchronously the corresponding
management servers of threshold exceeding of traffic counter,
protocol status change, flow statistics, and so on. In these
management servers, the SNMP server may access periodically network
devices and read synchronously the MIB-defined management information
from the devices. The NETCONF manager and the management servers
interact, and the NETCONF manager receives the event notifications
from the servers.
Receiving these event notifications, the NETCONF manager creates
substitute configuration data of the network devices to deal with the
events. For example, it activates the secondary device in slave
state to save user traffic when the primary device fails, and enables
bandwidth restriction to shape the traffic when traffic exceeds the
threshold.
Atarashi, et al. Expires January 15, 2007 [Page 14]
Internet-Draft Netconf System Architecture July 2006
4. NETCONF Applicability
4.1. Target Networks
NETCONF protocol has applicability for carrier network and enterprise
network and home or Small Office Home Office (SOHO) network as
following.
Carrier network It has numerous network devices widely deployed in
its service area. The devices contain normally multiple vendor's
products and have proprietary configuration method. By unifying
configuration procedure of the numerous devices with NETCONF
protocol, carrier operators can reduce their operation load.
Enterprise network Operators of enterprise networks are requested to
hold down administrative cost. The operators should configure the
network devices according to reorganization or additional service
deployment. Automation of the configuration can save the
administrative cost of enterprise networks.
Home/SOHO network Carrier or Internet Service Provider (ISP) can use
NETCONF protocol as a method for configuration of subscriber's
Home/SOHO network devices as one of their service. The concept of
the Home/SOHO network device configuration by the central
management system, named as CallHome, is discussed in netconf WG
about its required protocol procedures and its specification.
4.2. Network Operation Scenario
Figure 7shows a NETCONF system usage example. In this example, when
network topology changes occur, the NETCONF manager dynamically
configures the routing protocol of the routers deployed in a carrier
network.
Atarashi, et al. Expires January 15, 2007 [Page 15]
Internet-Draft Netconf System Architecture July 2006
+-----------------------+
| NETCONF Manager |
+-----------------------+
| | ^
NETCONF | | |
<edit-config> | | | SNMP Trap
+-------------+ | |
| | | Career Network
+-------+---------------------+-----------------------------+
| | | |
| | +-------------+ |
| | | Core Router | |
| | +-------------+ |
| | / | \ |
| | /- | \- |
| | / | \ |
| | / | \ |
| | /- OSPF | OSPF \- OSPF |
| | / | \ |
| | / | \ |
| | /- | \- |
| v / | \ |
| +-------------+ +-------------+ +-------------+ |
| | Edge Router | | Edge Router | | Edge Router | |
| +-------------+ +-------------+ +-------------+ |
+-----------------------------------------------------------+
Figure 7: NETCONF system usage example
The example system has a network manager, a core router and three
edge routers. The manager and the routers have NETCONF protocol
stack. The NETCONF manager is connected to the core router, and the
core router accommodates the edge routers to form tree topologies.
The core router and the edge routers exchange route information in
the network by OSPF routing protocol.
We assume that operator would add additional subnet by configuring
the network interface of the left side edge router. The routing
information of the additional route is distributed into the other
routers via OSPF routing protocol. The core router receives the
additional route information via OSPF and send it to the NETCONF
manager via SNMP trap. In addition to the SNMP trap, the routers can
notify the configuration change via the NETCONF notification.
The NETCONF manager extracts, from the SNMP trap, the route
information and ID of the origin edge router. The NETCONF manager
configures the router according to the new route. For example, the
Atarashi, et al. Expires January 15, 2007 [Page 16]
Internet-Draft Netconf System Architecture July 2006
NETCONF manager configures filter of the router to restrict clients
in newly added subnet to access a service. Receiving the SNMP trap,
the NETCONF manager creates automatically the configuration data
describing filter settings in XML and sends a RPC message including
the configuration data in an <edit-config/> element to the router.
The router parses this RPC message and updates its filter settings.
Figure 8 shows the message sequence between the NETCONF manager, the
core router and the edge router when the new route is added to the
edge router.
Atarashi, et al. Expires January 15, 2007 [Page 17]
Internet-Draft Netconf System Architecture July 2006
NETCONF Manger Core Router Edge Router
| | |
| Transport Initiation | |
|<----------------------------------------------------------->|
| | NECONF |
| | <hello><capabilities> |
|------------------------------------------------------------>|
| NETCONF | |
| <hello><capabilities> | |
|<------------------------------------------------------------|
| | |
| | NETCONF |
| | <rpc><create-subscription> |
|------------------------------------------------------------>|
| NETCONF | |
| <rpc-reply><ok> | |
|<------------------------------------------------------------|
| | |
| | +-------------+
| | | Route added |
| | +-------------+
| SNMP Trap | OSPF |
|<------------------------------|<----------------------------|
| | |
+-------------+ | |
| RPC Message | | |
| Generation | | |
+---+---------+ | NETCONF |
| | <rpc><edit-config> |
|------------------------------------------------------------>|
| | |
| | +-------------------+
| | | NETCONF Operation |
| | | Deployment |
| NETCONF | +-------------------+
| <rpc-reply><ok> | |
|<------------------------------------------------------------|
| | |
| NETCONF | |
|<notification><configuration/> | |
|<------------------------------------------------------------|
| | |
v v v
Figure 8: NETCONF Sequence
The NETCONF manager initiates NETCONF transport session with the edge
Atarashi, et al. Expires January 15, 2007 [Page 18]
Internet-Draft Netconf System Architecture July 2006
router. When the transport is opened, they exchange <hello> message
including <capabilities> element. If the edge router has a
capability of the NETCONF notification, the NETCONF manager creates
subscription of the notification about configuration change.
When an operator defines an additional network on the edge router,
which creates new route, the core router and the edge router exchange
the additional route information via OSPF. The core router sends an
SNMP trap to the NETCONF manager about the route information update.
Receiving the notification about the additional route via SNMP trap,
the NETCONF manager generates an RPC message to configure filtering
rules on the edge router. The NETCONF manager sends the <rpc>
message including <edit-config> element inside to the edge router via
NETCONF protocol.
The edge router analyzes the requested RPC from the NETCONF manager,
and creates additional filtering rules on its configuration store
according to the transported configuration data. If the edge router
succeed to create the filtering rules, it sends <rpc-reply> message
to the NETCONF manager including <ok> element in the message. In
addition to this <rpc-reply> message, the edge router sends
asynchronously a <notification> message to the NETCONF manager to
notify the configuration change.
By these interaction between the NETCONF manager and the network
devices, integrated with the existing management means, we can
automate network operation and reduce the administrative cost.
Moreover, we can tighten security by the prompt configuration against
the network incidents.
Atarashi, et al. Expires January 15, 2007 [Page 19]
Internet-Draft Netconf System Architecture July 2006
5. Event Notification
Network management system may contain multiple network management
protocols. Various event management protocols, SNMP, Syslog, IPFIX,
RADIUS / DIAMETER, and etc., are specified according to the
management information which operators want to obtain. Each protocol
has optimized sequence, datamodel and message encoding format.
When we construct a network management system, we do not need to
choose NETCONF notification as the unified event notification
protocol. Network management system is an organism composed of
multiple management means. Important point is to integrate the
multiple means to the management system and to choose appropriate
management protocol for each event notification.
5.1. Comparison of Event Notification Protocols
NETCONF Notification
Addition, change, removal of configuration
Addition, removal of a device component
SNMP
MIB-defined event
Syslog
Application independent event
IPFIX
Flow statistics information
Sampled packets information
Routing Protocol
Link state information
Route information
RADIUS, DIAMETER
Authentication, Authorization and Accounting (AAA) information
Atarashi, et al. Expires January 15, 2007 [Page 20]
Internet-Draft Netconf System Architecture July 2006
Proprietary
Device independent management information
As a general event notification means, SNMP and Syslog are widely
deployed. These management protocols are widely applied to, not only
a small network of a laboratory, but also enterprise's intra-network
or carrier's service network. These protocols are designed as
general-purpose protocol to transport various management information.
SNMP trap transports almost all kinds of management information. The
management information has hierarchical structure, and each
information node is specified by Object Identifier. Syslog
transports the notification mainly about status changes of the
control processes and device components. It has no hierarchical
datamodel. Its messages are described in human-readable format as
the main use-case of the Syslog is message logging for operators.
Unlike the general purpose protocols, IPFIX protocol, RADIUS /
DIAMETER protocol and routing protocol are designed to transport flow
statistics, AAA information and link state/route information,
respectively. It is respective decision whether it adopt
hierarchical structure for its datamodel and message format or not.
In the NETCONF notification, as the NETCONF configuration, protocol
messages and notification data are hierarchically described by XML so
that the NETCONF manager can analyze easily the data and react
automatically. The NETCONF notification conveys the event
information about configurations, hardware and software on the
NETCONF devices. When these components are added, removed or
replaced, the NETCONF devices send the NETCONF notification message.
The NETCONF notification, unlike IPFIX protocol, does not require
large capacity for its transported message size and frequency.
Change of configuration, hardware or software on the network device
seldom occurs since it affects network service directly. A huge, or
frequent notification message including many events means that the
network or its device fell into terrible and unrecoverable condition.
5.2. Event Handling Architecture
Figure 9 shows an example of the NETCONF manager handling the NETCONF
configuration, NETCONF notification and other notification. The
NETCONF notification and configuration use the same NETCONF transport
including SSH, SOAP/HTTP or BEEP.
Atarashi, et al. Expires January 15, 2007 [Page 21]
Internet-Draft Netconf System Architecture July 2006
NETCONF Manager
+-------------------------------------------------------+
| +-------------------------------------------------+ |
| | | |
| | NETCONF Application | |
| | | |
| +-------------------------------------------------+ |
| +---------------+ +--------------+ +--------------+ |
| | NETCONF | | NETCONF | | Other | |
| | Configuration | | Notification | | Notification | |
| |+-------------+| | | | | |
| || Operation || | | | | |
| |+-------------+| | | | | |
| |+-------------+| | | | | |
| || RPC || | | | | |
| |+-------------+| | | | | |
| +---------------+ +--------------+ | | |
| +--------------------------------+ | | |
| | NETCONF Transport | | | |
| | +-----+ +------+ +------+ | | | |
| | | SSH | | SOAP | | BEEP | | | | |
| | +-----+ +------+ +------+ | | | |
| +--------------------------------+ +--------------+ |
| | ^ ^ ^ ^ |
| | | | | | |
+-------+--+----------+---------------------+-----+-----+
| | | | |
| | | | |Event
| | | | |Notification
NETCONF| | NETCONF |NETCONF | +----+
RPC | | RPC |Event | | |Other NMS
request| | reply |Notification | | |
| | | | +----+
| | | | ^
v | | | |
+------------------------------------------------+
| NETCONF Device |
+------------------------------------------------+
Figure 9: Notification Handling on the Network Manager
This NETCONF manager handles, in addition to the NETCONF
notification, other event notifications on each transport protocol.
The other notifications comes directly from the NETCONF devices or
indirectly from other management server. Operators should select the
notification method to suit the event.
Atarashi, et al. Expires January 15, 2007 [Page 22]
Internet-Draft Netconf System Architecture July 2006
The NETCONF application integrates the network events received by
these multiple methods. According to the notification content, for
example, router added, device status changed, or flow threshold
exceeded, the NETCONF application selects the countermeasure and
apply it to the corresponding devices via the NETCONF configuration.
Atarashi, et al. Expires January 15, 2007 [Page 23]
Internet-Draft Netconf System Architecture July 2006
6. Security Considerations
The NETCONF system treats configurations of the network devices. The
configuration data is important and critical by nature. It can
reveal the network topology, address assignment, administrator's
password, flow filtering policy, user authentication policy, and so
on. So, it requires us to consider the security model for the
NETCONF system.
To consider the security model of the NETCONF system, we need to
clarify the possible threats in the system. We can assume following
threats on the NETCONF system.
6.1. Configuration Sniffing
Threat: The configuration data can be sniffed on the route between a
NETCONF manager and a network device.
Solution: The NETCONF system can use data encryption for the
transported message. We can use SSH/SSL/TSL for encryption in the
transport layer. Also, we can use XML encryption (XML-ENC) [15]
in the content layer.
6.2. Spoofing of the NETOCNF Manager
Threat: The network devices receive their configuration data from the
NETCONF manager. If a spoofing NETCONF manager sends the untruth
configuration data, the network device falls into inappropriate
behaviour and the network are confused.
Solution: The NETCONF system can use authentication of the NETCONF
manager. At the session initiation stage, The NETCONF device can
justify the manager by authentication method of the SSH/SSH/TLS
transport protocols. Also, the NETCONF device can justify the RPC
message generated by the NETCONF manager by XML signature [12].
6.3. Spoofing of the NETCONF Device
Threat: If the NETCONF system is configured to automatically start
NETCONF session with the newly added NETCONF device, the malicious
user can obtain the configuration data by introducing his computer
pretending to be NETCONF device. Not only the malicious user,
proper users are possible to connect their network devices to the
network.
Atarashi, et al. Expires January 15, 2007 [Page 24]
Internet-Draft Netconf System Architecture July 2006
Solution: Same as the authentication of the NETCONF manager, the
NETCONF system can use authentication of the NETCONF device. The
NETCONF manager prepares the database of the proper devices and
justifies the newly added devices in the initiation session, for
example, in the SSH/SSL/TLS transport initiation stage, or in the
<hello> message exchange stage. When the NETCONF system uses the
SOAP/HTTP as the transport method, the system can adopt HTTP over
TLS [11] concept to improve its security. The HTTP over TLS
mechanism is widely deployed to existing implementation of HTTP
server and application server. NETCONF system implementors can
reduce implementation cost by these existing resource.
Atarashi, et al. Expires January 15, 2007 [Page 25]
Internet-Draft Netconf System Architecture July 2006
7. IANA Considerations
This document has no actions for IANA.
Atarashi, et al. Expires January 15, 2007 [Page 26]
Internet-Draft Netconf System Architecture July 2006
8. References
8.1. Normative References
[1] Schoenwaelder, J., "Overview of the 2002 IAB Network Management
Workshop", RFC 3535, May 2003.
[2] Enns, R., "NETCONF Configuration Protocol",
draft-ietf-netconf-prot-12 (work in progress), March 2006.
[3] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration
Protocol over Secure Shell (SSH)", draft-ietf-netconf-ssh-06
(work in progress), March 2006.
[4] Goddard, T., "Using the Network Configuration Protocol (NETCONF)
Over the Simple Object Access Protocol (SOAP)",
draft-ietf-netconf-soap-08 (work in progress), March 2006.
[5] Lear, E. and K. Crozier, "Using the NETCONF Protocol over Blocks
Extensible Exchange Protocol (BEEP)", draft-ietf-netconf-beep-10
(work in progress), March 2006.
[6] Chisholm, S., "NETCONF Event Notifications",
draft-ietf-netconf-notification-02 (work in progress),
June 2006.
[7] Adwankar, S. and S. Chisholm, "Framework for Netconf Content",
draft-chisholm-netconf-model-05 (work in progress), April 2006.
8.2. Informative References
[8] Bradner, S. , "Key words for use in RFCs to Indicate
Requirement Levels" , BCP 14 , RFC 2119 , March 1997 .
[9] Harrington, D. , Presuhn, R. , and B. Wijnen , "An
Architecture for Describing Simple Network Management Protocol
(SNMP) Management Frameworks" , STD 62 , RFC 3411 ,
December 2002 .
[10] Harrington, D. and J. Schoenwaelder , "Transport Mapping
Security Model (TMSM) Architectural Extension for the Simple
Network Management Protocol (SNMP)" , draft-ietf-isms-tmsm-02
(work in progress) , May 2006 .
[11] Rescorla, E. , "HTTP Over TLS" , RFC 2818 , May 2000 .
[12] Eastlake, D. , Reagle, J. , and D. Solo , "XML-Signature
Syntax and Processing" , RFC 3075 , March 2001 .
Atarashi, et al. Expires January 15, 2007 [Page 27]
Internet-Draft Netconf System Architecture July 2006
[13] Orchard, D. , Maler, E. , and S. DeRose , "XML 1.0
Recommendation" , World Wide Web Consortium
FirstEdition http://www.w3.org/TR/1998/REC-xml-19980210 ,
February 1998 .
[14] Clark, J. , "XSL Transformations (XSLT) Version 1.0" , World
Wide Web Consortium
Recommendation http://www.w3.org/TR/1999/REC-xslt-19991116 ,
November 1999 .
[15] Eastlake, D. and J. Reagle , "XML Encryption Syntax and
Processing" , World Wide Web Consortium Recommendation http://
www.w3.org/TR/2002/REC-xmlenc-core-20021210 , December 2002 .
[16] Robie, J. , Byrne, S. , Hegaret, P. , Hors, A. , Wood, L. ,
Nicol, G. , and M. Champion , "Document Object Model (DOM)
Level 3 Core Specification" , World Wide Web Consortium Recomme
ndation http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407
, April 2004 .
[17] "Simple API for XML (SAX)" .
<http://www.saxproject.org/>
Atarashi, et al. Expires January 15, 2007 [Page 28]
Internet-Draft Netconf System Architecture July 2006
Authors' Addresses
Ray S. Atarashi
Internet Initiative Japan Inc.
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
Hideki Okita
Central Research Laboratory, Hitachi, Ltd.
1-280 Higashi-Koigakubo
Kokubunji, Tokyo 185-8601
Japan
Phone: +81-42-323-1111
Fax: +81-42-327-7868
Email: hideki.okita.pf@hitachi.com
Yoshifumi Atarashi
Alaxala Networks Co.
Shin-Kawasaki Mitsui Bldg.
890 Saiwai-ku Kashimada
Kawasaki, Kanagawa 212-0058
Japan
Phone: +81-44-549-1200
Fax: +81-44-549-1272
Email: atarashi@alaxala.net
Elisa Boschi
Hitachi Europe SAS
Immeuble Le Theleme
1503 Route des Dolines
Valbonne 06560
France
Phone: +33 4 89874180
Email: elisa.boschi@hitachi-eu.com
Atarashi, et al. Expires January 15, 2007 [Page 29]
Internet-Draft Netconf System Architecture July 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Atarashi, et al. Expires January 15, 2007 [Page 30]
