manuals/developer-guide/src/main/asciidoc/openflowplugin/odl-ofp-forwardingrules-sync.adoc

   1 === Application: Forwarding Rules Synchronizer
   2
   3 ==== Basics
   4
   5 ===== Description
   6
   7 Forwarding Rules Synchronizer (FRS) is a newer version of Forwarding Rules Manager (FRM). It was created to solve most shortcomings of FRM. FRS solving errors with retry mechanism. Sending barrier if needed. Using one service for flows, groups and meters. And it has less changes requests send to device since calculating difference and using compression queue.
   8
   9 It is located in the Java package:
  10
  11 [source, java]
  12 ----
  13 package org.opendaylight.openflowplugin.applications.frsync;
  14 ----
  15
  16 ===== Listeners
  17
  18 * 1x config - FlowCapableNode
  19 * 1x operational - Node
  20
  21 ===== System of work
  22
  23 * one listener in config datastore waiting for changes
  24
  25 ** update cache
  26 ** skip event if operational not present for node
  27 ** send syncup entry to reactor for synchronization
  28 *** node added: after part of modification and whole operational snapshot
  29 *** node updated: after and before part of modification
  30 *** node deleted: null and before part of modification
  31
  32
  33 * one listener in operational datastore waiting for changes
  34
  35 ** update cache
  36 ** on device connected
  37 *** register for cluster services
  38 ** on device disconnected remove from cache
  39 *** remove from cache
  40 *** unregister for cluster services
  41 ** if registered for reconciliation
  42 *** do reconciliation through syncup (only when config present)
  43
  44
  45 * reactor
  46 _(provides syncup w/decorators assembled in this order)_
  47
  48 ** Cluster decorator - skip action if not master for device
  49 ** FutureZip decorator (FutureZip extends Future decorator)
  50 *** Future - run delegate syncup in future - submit task to executor service
  51 *** FutureZip - provides state compression - compress optimized config delta if waiting for execution with new one
  52 ** Guard decorator - per device level locking
  53 ** Retry decorator - register for reconciliation if syncup failed
  54 ** Reactor impl - calculate diff from after/before parts of syncup entry and execute
  55
  56 ===== Strategy
  57
  58 In the _old_ FRM uses an incremental strategy with all changes made one by one, where FRS uses a flat batch system with changes made in bulk. It uses one service SalFlatBatchService instead of three (flow, group, meter).
  59
  60 ===== Boron release
  61
  62 FRS is used in Boron as separate feature and it is not loaded by any other feature. It has to be run separately.
  63
  64     odl-openflowplugin-app-forwardingrules-sync
  65
  66 ==== FRS additions
  67
  68 ===== Retry mechanism
  69
  70 * is started when change request to device return as failed (register for reconcile)
  71 * wait for next consistent operational and do reconciliation with actual config (not only diff)
  72
  73 ===== ZipQueue
  74
  75 * only the diff (before/after) between last config changes is sent to device
  76 * when there are more config changes for device in a row waiting to be processed they are compressed into one entry (after is still replaced with the latest)
  77
  78 ===== Cluster-aware
  79
  80 * FRS is cluster aware using ClusteringSingletonServiceProvider from the MD-SAL
  81 * on mastership change reconciliation is done (register for reconcile)
  82
  83 ===== SalFlatBatchService
  84
  85 FRS uses service with implemented barrier waiting logic between dependent objects
  86
  87 ==== SalFlatBatchService for FRS
  88
  89 SalFlatBatchService was created along forwardingrules-sync application as the service that should application used by default. This service uses only one input with bag of flow/group/meter objects and their common add/update/remove action. So you practically send only one input (of specific bags) to this service.
  90
  91 ===== Workflow
  92
  93 * prepare plan of actions
  94 ** mark actions where the barrier is needed before continue
  95 * run appropriate service calls
  96 ** start all actions that can be run simultaneously
  97 ** if there is barrier-needed mark, wait for all fired jobs and only then continue with the next action
  98
  99 error handling:
 100
 101 * there is flag to stop process on the first error (default set to false)