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]