Changes between Version 29 and Version 30 of Internal/OpenFlow/Controllers/MultiCtl

Timestamp:

Oct 25, 2012, 8:57:37 PM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/MultiCtl

@@ -242 +242 @@
 
  * Some more discussion on use case was had, in the context of different management domains with multiple controllers owned by separate groups, but on the same network. In the traditional network setup, each group would have to actively collaborate in order to prevent controllers from trampling each others' policies. For example, a central controller orchestrator, when allowing a user to administrate the network, would only permit the user to configure their own controller. The orchestrator would have to "know" which users can access which controller, and how that controller may influence the network.  
-
+ 
 [[BR]]      
 End of week5 :[#iv Back to Logs.]
+
 ==== (10/16) ==== #w6
 The process chain was fleshed out further.
@@ -253 +254 @@
  * Added parser for controller service descriptions/requirements to the topology file. The configs for the controller are parsed, then pushed out as part of the service info exchange that controllers do with each other when establishing a connection. The aim is to be able to describe services in terms of the resources that it needs. The resources are in the form of events that the controller is capable of detecting and dispatching (messages, switches, and hosts/devices).
 
+==== (10/20) ====
+Preliminary decision to use Vendor extensions of !OpenFlow specs for inter-controller service messaging, at least for controllers to propagate information about the services that they export, and what event information they require to properly run the service. 
+
+The base of a vendor message includes an integer to specify the data type, which allows one to use one "vendor ID" with many message types.  
+ 
 [[BR]]      
 End of week6 :[#iv Back to Logs.]
-==== (10/22) ====#w7
-
+
+==== (10/24) ==== #w7
+Some terms to keep things organized:
+ * Control plane : the collection of communication channels just visible to the controllers. Assumed to be isolated from the data plane, in which the switches and network hosts reside. 
+ * network event : a message that notifies a controller of network state change, e.g. a switch joining the network, or a new !OpenFlow message. 
+ * Control entity : a SDN controller. May or may not be connected to switches but nevertheless capable of influencing network state by processing !OpenFlow messages or its derivatives.  
+ * Control plane server : a control entity that exports services to other controllers, and may subscribe to other controllers for network events. Also called "subscribers".    
+ * Control plane client : a control entity that relays network events to control entities interested in them. 
+
+A server is configured with the information required to advertise its services and subscriptions. A single controller can also be both client and server. 
+
+Three unique control messages were defined using OF Vendor messages:
+ 1. OFExportsRequest : sent by a control plane client when initially connecting to a control plane server. Akin to an OFFeatureRequest. 
+ 1. OFExportsReply : sent in response to a OFExportsRequest. Contains the names of the services exported by the server, and the events that it would like to subscribe to. 
+ 1. OFExportsUpdate : sent by a server to its clients, when it receives (as a client) any new OFExportsReply messages from its servers. 
+
+The Reply and Update messages convey subscriptions as one of three categories:
+ 1. Device : network host related events such as a host join, departure, or address/VLAN change.
+ 1. Switch : !OpenFlow switch joins and leaves. 
+ 1. Message : !OpenFlow messages distinguished by message type. 
+
+This reflects the event types that Floodlight recognizes by default, is well-defined, and is probably comprehensive enough to convey a very wide range of network events. The aim here is to define subscriptions as a combination of events from these event categories. 
+
+To keep things simple, of the Message category of events, focus will be placed on the Packet_In type (0x10), which is practically a catch-all for network host related messages. If more fine-tuned filtering is requires, a OFMatch structure may probably be used to describe the constraints on the types of Packet_Ins a subscriber may wish to hear about. 
+ 
 ----
 [#home Home.]