manuals/user-guide/src/main/asciidoc/controller/netconf/odl-netconf-northbound-user.adoc

   1 === Northbound (NETCONF servers)
   2 OpenDaylight provides 2 types of NETCONF servers:
   3
   4 * *NETCONF server for config-subsystem (listening by default on port
   5   1830)*
   6   ** Serves as a default interface for config-subsystem and allows
   7   users to spawn/reconfigure/destroy modules (or applications) in OpenDaylight
   8 * *NETCONF server for MD-SAL (listening by default on port 2830)*
   9 ** Serves as an alternative interface for MD-SAL (besides RESTCONF)
  10   and allows users to read/write data from MD-SAL's datastore and to
  11   invoke its rpcs (NETCONF notifications are not available in the
  12   Beryllium release of OpenDaylight)
  13
  14 NOTE: The reason for having 2 NETCONF servers is that config-subsystem and
  15 MD-SAL are 2 different components of OpenDaylight and require different
  16 approach for NETCONF message handling and data translation. These 2
  17 components will probably merge in the future.
  18
  19 ==== NETCONF server for config-subsystem
  20 This NETCONF server is the primary interface for config-subsystem. It
  21 allows the users to interact with config-subsystem in a standardized
  22 NETCONF manner.
  23
  24 In terms of RFCs, these are supported:
  25
  26 * http://tools.ietf.org/html/rfc6241[RFC-6241]
  27 * https://tools.ietf.org/html/rfc5277[RFC-5277]
  28 * https://tools.ietf.org/html/rfc6470[RFC-6470]
  29 ** (partially, only the
  30   schema-change notification is available in Beryllium release)
  31 * https://tools.ietf.org/html/rfc6022[RFC-6022]
  32
  33 For regular users it is recommended to use RESTCONF + the
  34 controller-config loopback mountpoint instead of using pure NETCONF.
  35 How to do that is spesific for each component/module/application
  36 in OpenDaylight and can be found in their dedicated user guides.
  37
  38 ==== NETCONF server for MD-SAL
  39 This NETCONF server is just a generic interface to MD-SAL in OpenDaylight.
  40 It uses the stadard MD-SAL APIs and serves as an alternative to
  41 RESTCONF. It is
  42 fully model driven and supports any data and rpcs that are supported
  43 by MD-SAL.
  44
  45 In terms of RFCs, these are supported:
  46
  47 * http://tools.ietf.org/html/rfc6241[RFC-6241]
  48 * https://tools.ietf.org/html/rfc6022[RFC-6022]
  49
  50 Notifications over NETCONF are not supported in the Beryllium release.
  51
  52 TIP: Install NETCONF northbound for MD-SAL by installing feature:
  53 +odl-netconf-mdsal+ in karaf. Default binding port is *2830*.
  54
  55 ===== Configuration
  56 The default configuration can be found in file:
  57 _08-netconf-mdsal.xml_. The file contains the configuration for all
  58 necessary dependencies and a single SSH endpoint starting on port 2830.
  59 There is also a (by default disabled) TCP endpoint. It is possible
  60 to start multiple endpoints at the same time either in the initial
  61 configuration file or while OpenDaylight is running.
  62
  63 The credentials for SSH endpoint can also be configured here, the
  64 defaults are admin/admin. Credentials in the SSH endpoint are not yet
  65 managed by the centralized AAA component and have to be configured
  66 separately.
  67
  68 ===== Verifying MD-SAL's NETCONF server
  69 After the NETCONF server is available it can be examined by a
  70 command line ssh tool:
  71
  72 ----
  73 ssh admin@localhost -p 2830 -s netconf
  74 ----
  75
  76 The server will respond by sending its HELLO message and can be used
  77 as a regular NETCONF server from then on.
  78
  79 ===== Mounting the MD-SAL's NETCONF server
  80 To perform this operation, just spawn a new netconf-connector as described in
  81 <<_spawning_additional_netconf_connectors_while_the_controller_is_running,
  82 Spawning netconf-connector>>.
  83 Just change the ip to "127.0.0.1" port to "2830" and its name to "controller-mdsal".
  84
  85 Now the MD-SAL's datastore can be read over RESTCONF via NETCONF by invoking:
  86
  87 GET http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/controller-mdsal/yang-ext:mount
  88
  89 NOTE: This might not seem very useful, since MD-SAL can be accessed
  90 directly from RESTCONF or from Application code, but the same method can be used to
  91 mount and control other OpenDaylight instances by the "master OpenDaylight".