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

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