Internet DRAFT - draft-atarashi-ngo-consider-architecture
draft-atarashi-ngo-consider-architecture
Network Working Group R. Atarashi
Internet-Draft Internet Initiative Japan Inc.
Intended status: Standards Track H. Okita
Expires: January 10, 2008 Central Research Laboratory,
Hitachi, Ltd.
Y. Atarashi
Alaxala Networks Co.
July 9, 2007
Consideration of NETCONF Architecture
draft-atarashi-ngo-consider-architecture-01
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 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Atarashi, et al. Expires January 10, 2008 [Page 1]
Internet-Draft Consideration of NETCONF Architecture July 2007
Abstract
The NETwork CONFiguration (NETCONF) protocol has been designed to
configure routers, switches, firewalls and other network devices.
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 Reference Model . . . . . . . . . . . . . . . . . . . 5
3. NETCONF System Architecture . . . . . . . . . . . . . . . . . 7
3.1. NETCONF Manager . . . . . . . . . . . . . . . . . . . . . 7
3.2. NETCONF Device . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. SOAP/HTTP(S) Transport Mapping . . . . . . . . . . . . 9
3.2.2. SSH Transport Mapping . . . . . . . . . . . . . . . . 10
3.2.3. BEEP Transport Mapping . . . . . . . . . . . . . . . . 11
3.3. NETCONF System Functions . . . . . . . . . . . . . . . . . 12
4. Relation to other Protocols . . . . . . . . . . . . . . . . . 14
4.1. NETCONF Role in Network Management System . . . . . . . . 14
4.2. Network Management System Reference Model using
NETCONF protocol . . . . . . . . . . . . . . . . . . . . . 14
5. NETCONF Applicability . . . . . . . . . . . . . . . . . . . . 17
5.1. Target Networks . . . . . . . . . . . . . . . . . . . . . 17
5.2. Network Operation Scenario . . . . . . . . . . . . . . . . 17
6. Event Notification . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Comparison of Event Notification Protocols . . . . . . . . 22
6.2. Event Handling Architecture . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7.1. Configuration Sniffing . . . . . . . . . . . . . . . . . . 26
7.2. Spoofing of the NETOCNF Manager . . . . . . . . . . . . . 26
7.3. Spoofing of the NETCONF Device . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Atarashi, et al. Expires January 10, 2008 [Page 2]
Internet-Draft Consideration of NETCONF Architecture July 2007
1. Introduction
1.1. NETCONF Protocol
NETCONF Protocol 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) [12] 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), 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 transport
protocols, SSH, SOAP/HTTP(S) and BEEP. NETCONF notification [5]
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 | | |
+-------------+ +-------------------------------------------+
Figure 1: NETCONF Protocol Layers
Atarashi, et al. Expires January 10, 2008 [Page 3]
Internet-Draft Consideration of NETCONF Architecture July 2007
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
NETCONF protocol defines function set of configurations for routers,
switches, and other network devices. When network devices are
configured, network behavior are changed, it impacts the performance
of applications and services running on the network. It means
applications and services may be able to change the network behavior
using NETCONF protocol. NETCONF can be used not only for the
operation management, but also for the collaboration between
application and network.
NETCONF Notification is reliable functions for getting configurations
of network devices. It can be applied for feedback system using with
NETCONF.
NETCONF and NETCONF Notification are designed based on the XML
technologies. XML-based protocols make collaboration with other
operation systems and applications easy. XML can also deal with data
model, it have a much broader range of applications.
The purpose of this draft is consideration of NETCONF architecture
for research application possibilities by expanding the scope to
application layer.
Atarashi, et al. Expires January 10, 2008 [Page 4]
Internet-Draft Consideration of NETCONF Architecture July 2007
2. NETCONF Reference Model
Figure 2 presents a proposed reference model for network
configuration system. Network configuration system consists of two
parts. One is Data model and Description part that manage abstract
configuration information. The other is network monitoring and
management based on SNMP.
Atarashi, et al. Expires January 10, 2008 [Page 5]
Internet-Draft Consideration of NETCONF Architecture July 2007
+----------------------------------------------------------------+
| Network +------+ +--------+ Data |
| Configuration |Visual|<----------------->|XML | Model |
| System |Design| +------------+ |Database| and |
| |Tool | |netconf | |(Policy,| Description|
| +--+---+ |datamodel | | rules, | |
| | +------------+ | Device,| |
| | | etc. | |
| | +---+----+ |
| | | |
| | +----------+ | |
| +---->|XML Config|<---------+ |
| |Controller| |
| +-+---+--+-+ |
+-------------------------/-----\--\-----------------------------+
/ \ \ netconf protocol
/ \ \ +-----+
ISP Service +----V--+ \ +--------->/ \
Area |Router/| +V------+ / \
|Switch | |Router/| +---------+
+-------+ |Switch | |Home/SOHO|
^ +----+--+ | -PDA |
| | | -Video |
| +-------+ | | -Devices|
| |Router/| | +---------+
| >Switch | |
| /+---+---+ |
| / | |
| / | |
+----------------------/-------------------------------------+
| | / | | |
| Current +------+++ | +---+----+ |
| Management |BB/ | | |SNMP/MIB| |
| System |PolicyDB| | +---+----+ |
| +--------+ | | |
| | | |
| | +---V----+ |
| +--->| NMS | Monitoring/ |
| +--------+ Observation |
| | |
+---------------------------------------|--------------------+
V
netconf datamodel (2)
Figure 2: NETCONF reference model
Atarashi, et al. Expires January 10, 2008 [Page 6]
Internet-Draft Consideration of NETCONF Architecture July 2007
3. NETCONF System Architecture
In this section, we describe the architectural components of the
NETCONF manager and the NETCONF device.
3.1. NETCONF Manager
Figure 3 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) |||
| | || +-----------+ +---------+ +---------+ +------------+||
+----------+ |+------------------------------------------------------+|
| ^ ^ |
| | | |
| | +----------+---------------------------+ |
| | | | | |
| | | v +-------------+| |
| | | +-------------------+ | Config || |
| | | | Network Level API | | Datamodel || |
| | | +-------------------+ | (XML Schema)|| |
| | | ^ +-------------+| |
| | | | | |
| | +----------+---------------------------+ |
| | | |
| +------+-----------------+---------------------------+ |
| | | | | |
| | v v +--------------+| |
| | +--------------------------+ | Config || |
| | | NETCONF API | | Datamodel || |
| | +--------------------------+ | (XML Schema) || |
| | +--------------+| |
| +----------------------------------------------------+ |
+--------------------------------------------------------+
Figure 3: NETCONF Manager Components
Atarashi, et al. Expires January 10, 2008 [Page 7]
Internet-Draft Consideration of NETCONF Architecture July 2007
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 configration from device independent configration
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.
Atarashi, et al. Expires January 10, 2008 [Page 8]
Internet-Draft Consideration of NETCONF Architecture July 2007
3.2. NETCONF Device
A NETCONF device receives NETCONF messages from the NETCONF manager
and analyzes the messages, then it applies the result of the analysis
to itself. A NETCONF device has two kinds of functional blocks,
NETCONF message analysis block and device internal configuration
interface.
The NETCONF message analysis block receives NETCONF protocol message
from the NETCONF manager. It parses the NETCONF protocol message and
extracts the operation command for the network device. Components of
this block vary according to the selected transport protocol.
A proprietary module may use XML API like Document Object Model (DOM)
[14] or Simple API for XML (SAX) [15] to parse XML documents. By
these API, the module extracts NETCONF operation block from the RPC
message, and starts the processes corresponding to the operation
block. Throughout the parsing, configuration datamodel described in
XML schema is used to validate the XML data. The processes call
internal lower configuration interface of the network devices.
3.2.1. SOAP/HTTP(S) Transport Mapping
In the NETCONF device with SOAP/HTTP transport mapping (Figure 4),
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
proprietary 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 10, 2008 [Page 9]
Internet-Draft Consideration of NETCONF Architecture July 2007
Configuration Data
|
+-------------+---------------------------+
| | |
| v |
| +-----------------------------------+ |
| | +------------------+ +----------+ | |
| | | SSL Module | | Config | | |
| | +------------------+ | Model | | |
| | | HTTP Engine | | (XML | | |
| | +------------------+ | Schema | | |
| | | SOAP Module | | | | |
| | +------+-----------+ +----------+ | |
| | |XSLT |Proprietary| | |
| | |Module|Modules(s) | | |
| | +------+-----------+ | |
| +-----------------------------------+ |
| | |
| v |
| +-----------------------------------+ |
| | Network Device | |
| | Internal Configuration Interface | |
| +-----------------------------------+ |
+-----------------------------------------+
Figure 4: NETCONF Device Architecture (SOAP/HTTP(S) Mapping)
3.2.2. SSH Transport Mapping
In the NETCONF device with SSH transport mapping (Figure 5), 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 10, 2008 [Page 10]
Internet-Draft Consideration of NETCONF Architecture July 2007
Configuration Data
|
+-------------+---------------------------+
| | |
| v |
| +-----------------------------------+ |
| | +------------------+ +----------+ | |
| | | SSH Stack | | | | |
| | +------------------+ | Config | | |
| | +------------------+ | Model | | |
| | | XML Parse | | (XML | | |
| | | /RPC Stack | | Schema) | | |
| | +------------------+ +----------+ | |
| | +-----++-----------+ | |
| | |XSLT ||Proprietary| | |
| | |Stack||Stack | | |
| | +-----++-----------+ | |
| +-----------------------------------+ |
| | |
| v |
| +-----------------------------------+ |
| | Network Device | |
| | Internal Configuration Interface | |
| +-----------------------------------+ |
+-----------------------------------------+
Figure 5: NETCONF Device Architecture (SSH Mapping)
3.2.3. BEEP Transport Mapping
In the NETCONF device with BEEP transport mapping (Figure 6), 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 10, 2008 [Page 11]
Internet-Draft Consideration of NETCONF Architecture July 2007
Configuration Data
|
+-------------+---------------------------+
| | |
| v |
| +-----------------------------------+ |
| | +------------------+ +----------+ | |
| | | TLS/SASL Stack | | Config | | |
| | +------------------+ | Model | | |
| | +------------------+ | (XML | | |
| | | BEEP Stack | | Schema) | | |
| | +------------------+ +----------+ | |
| | +-----++-----------+ | |
| | |XSLT ||Proprietary| | |
| | |Stack||Modules(s) | | |
| | +-----++-----------+ | |
| +-----------------------------------+ |
| | |
| v |
| +-----------------------------------+ |
| | Network Device | |
| | Internal Configuration Interface | |
| +-----------------------------------+ |
+-----------------------------------------+
Figure 6: NETCONF Device Architecture (BEEP Mapping)
3.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[5], 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 10, 2008 [Page 12]
Internet-Draft Consideration of NETCONF Architecture July 2007
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 10, 2008 [Page 13]
Internet-Draft Consideration of NETCONF Architecture July 2007
4. Relation to other Protocols
4.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.
4.2. Network Management System Reference Model using NETCONF protocol
Figure 7 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 10, 2008 [Page 14]
Internet-Draft Consideration of NETCONF Architecture July 2007
+-----------+
| 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 7: 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 10, 2008 [Page 15]
Internet-Draft Consideration of NETCONF Architecture July 2007
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 10, 2008 [Page 16]
Internet-Draft Consideration of NETCONF Architecture July 2007
5. NETCONF Applicability
5.1. Target Networks
NETCONF protocol has applicability for carrier network and home or
Small Office Home Office (SOHO) network.
Carrier network 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.
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.
5.2. Network Operation Scenario
Figure 8shows 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 10, 2008 [Page 17]
Internet-Draft Consideration of NETCONF Architecture July 2007
+-----------------------+
| NETCONF Manager |
+-----------------------+
| | ^
NETCONF | | |
<edit-config> | | | SNMP Trap
+-------------+ | |
| | | Career Network
+-------+---------------------+-----------------------------+
| | | |
| | +-------------+ |
| | | Core Router | |
| | +-------------+ |
| | / | \ |
| | /- | \- |
| | / | \ |
| | / | \ |
| | /- OSPF | OSPF \- OSPF |
| | / | \ |
| | / | \ |
| | /- | \- |
| v / | \ |
| +-------------+ +-------------+ +-------------+ |
| | Edge Router | | Edge Router | | Edge Router | |
| +-------------+ +-------------+ +-------------+ |
+-----------------------------------------------------------+
Figure 8: 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 10, 2008 [Page 18]
Internet-Draft Consideration of NETCONF Architecture July 2007
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 9 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 10, 2008 [Page 19]
Internet-Draft Consideration of NETCONF Architecture July 2007
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 9: NETCONF Sequence
The NETCONF manager initiates NETCONF transport session with the edge
Atarashi, et al. Expires January 10, 2008 [Page 20]
Internet-Draft Consideration of NETCONF Architecture July 2007
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 10, 2008 [Page 21]
Internet-Draft Consideration of NETCONF Architecture July 2007
6. 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.
6.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 10, 2008 [Page 22]
Internet-Draft Consideration of NETCONF Architecture July 2007
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.
6.2. Event Handling Architecture
Figure 10 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 10, 2008 [Page 23]
Internet-Draft Consideration of NETCONF Architecture July 2007
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 10: 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 10, 2008 [Page 24]
Internet-Draft Consideration of NETCONF Architecture July 2007
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 10, 2008 [Page 25]
Internet-Draft Consideration of NETCONF Architecture July 2007
7. 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.
7.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] in the
content layer.
7.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 [11].
7.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 10, 2008 [Page 26]
Internet-Draft Consideration of NETCONF Architecture July 2007
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 [9] 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 10, 2008 [Page 27]
Internet-Draft Consideration of NETCONF Architecture July 2007
8. IANA Considerations
This document has no actions for IANA.
Atarashi, et al. Expires January 10, 2008 [Page 28]
Internet-Draft Consideration of NETCONF Architecture July 2007
9. References
[1] Enns, R. , "NETCONF Configuration Protocol" ,
draft-ietf-netconf-prot-12 (work in progress) , March 2006 .
[2] 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 .
[3] 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 .
[4] Wasserman, M. and T. Goddard , "Using the NETCONF
Configuration Protocol over Secure Shell (SSH)" ,
draft-ietf-netconf-ssh-06 (work in progress) , March 2006 .
[5] Trevino, H. and S. Chisholm , "NETCONF Event Notifications"
, draft-ietf-netconf-notification-08 (work in progress) ,
July 2007 .
[6] Admankar, S. and S. Chisholm , "Using XML Schema to define
Netconf Content" , draft-chisholm-netconf-model-06 (work in
progress) , February 2007 .
[7] Harrington, D. and J. Schoenwaelder , "Transport Subsystem
for the Simple Network Management Protocol (SNMP)" ,
draft-ietf-isms-tmsm-09 (work in progress) , July 2007 .
[8] Bradner, S. , "Key words for use in RFCs to Indicate
Requirement Levels" , BCP 14 , RFC 2119 , March 1997 .
[9] Rescorla, E. , "HTTP Over TLS" , RFC 2818 , May 2000 .
[10] Harrington, D. , Presuhn, R. , and B. Wijnen , "An
Architecture for Describing Simple Network Management Protocol
(SNMP) Management Frameworks" , STD 62 , RFC 3411 ,
December 2002 .
[11] Eastlake, D. , Reagle, J. , and D. Solo , "XML-Signature
Syntax and Processing" , RFC 3075 , March 2001 .
[12] Sperberg-McQueen, C. , Bray, T. , and J. Paoli , "XML 1.0
Recommendation" , World Wide Web Consortium FirstEdition REC-
xml-19980210 , February 1998 ,
<http://www.w3.org/TR/1998/REC-xml-19980210> .
[13] Reagle, J. and D. Eastlake , "XML Encryption Syntax and
Atarashi, et al. Expires January 10, 2008 [Page 29]
Internet-Draft Consideration of NETCONF Architecture July 2007
Processing" , World Wide Web Consortium Recommendation REC-
xmlenc-core-20021210 , December 2002 ,
<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210> .
[14] Hegaret, P. , Nicol, G. , Robie, J. , Wood, L. , Byrne, S. ,
Hors, A. , and M. Champion , "Document Object Model (DOM) Level
3 Core Specification" , World Wide Web Consortium
Recommendation REC-DOM-Level-3-Core-20040407 , April 2004 ,
<http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407> .
[15] "Simple API for XML (SAX)" .
<http://www.saxproject.org/>
Atarashi, et al. Expires January 10, 2008 [Page 30]
Internet-Draft Consideration of NETCONF Architecture July 2007
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
Atarashi, et al. Expires January 10, 2008 [Page 31]
Internet-Draft Consideration of NETCONF Architecture July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Atarashi, et al. Expires January 10, 2008 [Page 32]
