Changes between Version 9 and Version 10 of Internal/OpenFlow/Controllers/MultiCtl

Timestamp:

Sep 12, 2012, 7:34:18 PM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/MultiCtl

@@ -85 +85 @@
 The service reply will probably communicate a service type (topology, network storage, etc.) and a location to find it, such as port on a datapath where a NAS is located (if network storage). This is basically a way for the network to advertise location of services to topology-aware elements, as opposed to a server attached to a network doing the adverts for hosts. 
 
+==== (9/11) ====
+Some work was done to develop a general architecture of a single controller, tentatively named a "Unit".
+
+[[BR]] 
+[#iv Back to Logs.]
+==== (9/12) ====
+Several points were discussed.
+
+ 1. '''''Same versus different channels for switches and controllers.''''' Same channels for both implies a need for a strictly defined protocol between controllers, and a more sophisticated upstream message handler for the channel. Different channels allows the system to be more modular, and removes the need to develop the "smart" handler that may become cumbersome to debug and develop overall.
+
+ 2. '''''Vertical versus horizontal inter-controller channels.''''' Vertical channels are connections between controllers in different layers of the hierarchy, whereas horizontal channels are between those in the same layer. Horizontal channels may contain both !OpenFlow control and derived messages. Vertical messages may not conform to !OpenFlow, with the exception of the vertical channel between the first level controllers and switches (the traditional OF channel). 
+
+ 3. '''''Nature of non-conforming messages.''''' The Vertical messages are "domain-specific", that is, only conform to rules that are agreed upon between adjacent layers. Therefore, some translation must occur if a message is to pass across several layers. Alternately, one message type may be interpreted differently across different tiers. An Example is one layer using a VLAN tag as a normal tag, and another, a session ID. 
+
+ 4. '''''Interdomain handoffs.''''' The network may be a mix of IP and non-IP networks, governed by controllers not necessarily able to communicate - each should be able to operate in their local scope, facilitating the translation of outgoing messages so that it may be handled properly by the IP portions of the internetwork. 
+
+ 5. '''''Use case.''''' A small setup of three switches, two hosts (one moving), and two tiers of controllers. The first tier may be a simple forwarding unit, and the second dictates a higher (protocol) layer logic - to keep it simple, authentication. The logical layout between the two tiers changes behaviors of the tiers:
+
+  1. Tier two connects to just one tier one controller: the connection point must communicate the higher-tier's commands to others in its tier. 
+  2. Tier two connects to all tier one controllers: tier two in this case is a global 'overseer' that can actively coordinate, in this case, a handoff where permitted.         
+
 ----
 [#home Home.]