docs/user-guide/netide-user-guide.rst

   1 .. _netide-user-guide:
   2
   3 NetIDE User Guide
   4 =================
   5
   6 Overview
   7 --------
   8
   9 OpenDaylight’s NetIDE project allows users to run SDN applications
  10 written for different SDN controllers, e.g., Floodlight or Ryu, on top
  11 of OpenDaylight managed infrastructure. The NetIDE Network Engine
  12 integrates a client controller layer that executes the modules that
  13 compose a Network Application and interfaces with a server SDN
  14 controller layer that drives the underlying infrastructure. In addition,
  15 it provides a uniform interface to common tools that are intended to
  16 allow the inspection/debug of the control channel and the management of
  17 the network resources.
  18
  19 The Network Engine provides a compatibility layer capable of translating
  20 calls of the network applications running on top of the client
  21 controllers, into calls for the server controller framework. The
  22 communication between the client and the server layers is achieved
  23 through the NetIDE intermediate protocol, which is an application-layer
  24 protocol on top of TCP that transmits the network control/management
  25 messages from the client to the server controller and vice-versa.
  26 Between client and server controller sits the Core Layer which also
  27 speaks the intermediate protocol.
  28
  29 NetIDE API
  30 ----------
  31
  32 Architecture and Design
  33 ~~~~~~~~~~~~~~~~~~~~~~~
  34
  35 The NetIDE engine follows the ONF’s proposed Client/Server SDN
  36 Application architecture.
  37
  38 .. figure:: ./images/netide/netidearch.jpg
  39    :alt: NetIDE Network Engine Architecture
  40
  41    NetIDE Network Engine Architecture
  42
  43 Core
  44 ~~~~
  45
  46 The NetIDE Core is a message-based system that allows for the exchange
  47 of messages between OpenDaylight and subscribed Client SDN Controllers
  48
  49 Handling reply messages correctly
  50 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  51
  52 When an application module sends a request to the network (e.g. flow
  53 statistics, features, etc.), the Network Engine must be able to
  54 correctly drive the corresponding reply to such a module. This is not a
  55 trivial task, as many modules may compose the network application
  56 running on top of the Network Engine, and there is no way for the Core
  57 to pair replies and requests. The transaction IDs (xid) in the OpenFlow
  58 header are unusable in this case, as it may happen that different
  59 modules use the same values.
  60
  61 In the proposed approach, represented in the figure below, the task of
  62 pairing replies with requests is performed by the Shim Layer which
  63 replaces the original xid of the OpenFlow requests coming from the core
  64 with new unique xid values. The Shim also saves the original OpenFlow
  65 xid value and the module id it finds in the NetIDE header. As the
  66 network elements must use the same xid values in the replies, the Shim
  67 layer can easily pair a reply with the correct request as it is using
  68 unique xid values.
  69
  70 The below figure shows how the Network Engine should handle the
  71 controller-to-switch OpenFlow messages. The diagram shows the case of a
  72 request message sent by an application module to a network element where
  73 the Backend inserts the module id of the module in the NetIDE header (X
  74 in the Figure). For other messages generated by the client controller
  75 platform (e.g. echo requests) or by the Backend, the module id of the
  76 Backend is used (Y in the Figure).
  77
  78 .. figure:: ./images/netide/netide-flow.jpg
  79    :alt: NetIDE Communication Flow
  80
  81    NetIDE Communication Flow
  82
  83 Configuration
  84 ~~~~~~~~~~~~~
  85
  86 Below are the configuration items which can be edited, including their
  87 default values.
  88
  89 -  core-address: This is the ip address of the NetIDE Core, default is
  90    127.0.0.1
  91
  92 -  core-port: The port of on which the NetIDE core is listening on
  93
  94 -  address: IP address where the controller listens for switch
  95    connections, default is 127.0.0.1
  96
  97 -  port: Port where controller listens for switch connections, default:
  98    6644
  99
 100 -  transport-protocol: default is TCP
 101
 102 -  switch-idle-timeout: default is 15000ms
 103