Ieee communication surveys & tutorials, vol. 16, No. 4, Fourth quarter 2014

B. Scalable Controller Management

With the application of SDN/OpenFlow in larger networks,

the network controllers could become a performance bottle-

neck due to large amount of incoming signaling messages

and forwarding requests. Those controllers do not necessarily

be deployed in the same sub-net since a company network

may cross multiple places (even in different countries, such

as IBM, Intel, etc.). The controllers located in a distributed

network may compete for common computing resources (such

as communication channels).

To manage the coordination issue of large-scale controller-

to-controller communication system, a carefully designed

scheduling strategy with collision avoidance should be used. On

one hand, SDN administrators want to see a virtually consistent

controller system. On the other hand, they need to design a

virtual-to-physical mapping model to manage the physically

distributed controllers. Perhaps a tree-based hierarchical man-

agement scheme could be used to coordinate those controllers.

The higher level controllers should be able to handle more

heavy requests. The root controller then communicates with

NOX on the global requests. Fault tolerance techniques could

be used for controllers system. Even one controller is down,

others should be able to compensate for the missing operations.

By using fault tolerance model, we could figure out the optimal

controller deployment strategy, such as which controller should

be deployed in which sub-net.

---

2202

IEEE COMMUNICATION SURVEYS & TUTORIALS, VOL. 16, NO. 4, FOURTH QUARTER 2014

Resource sharing strategies should also be made among

controllers. By using a queuing model with shared resource

pool, we could calculate the controller serving time and wait-

ing time.

Note that the flow table could handle the packets in differ-

ent granularity levels. It could define the packet forwarding

in individual packet level; or, it could define the flow-level

forwarding actions. The controllers must be able to manage

different granularity levels in order to accurately adjust the flow

table status (such as adding or deleting the forwarding rules).

C. Highly Flexible Language Abstractions

The SDN programming language should be able to adapt

to frequent flow rules changes. It should also be suitable

to policy changes due to network topology change, regular

SDN maintenance, emergent failures, etc. An SDN programmer

would like to use a good language to perform policy changes

atomically to each switch. However, atomic change is difficult

to implement since it needs the disruption of the entire network

during policy change [29]. The future SDN language should

at least achieve two levels of abstractions if the atomic level

cannot be achieved.

1) In packet level, the language should be able to specify

the policy changes for all packets that meet similar at-

tributes. It needs to make sure that all packets belonging

to the same context are delivered with the same structural

invariants such as loop-freedom.

2) In flow-level, the language should allow the definitions of

flow-oriented rules/policies, such as queuing models, de-

livery order, load balancing, etc. The compliers and run-

time system should be able to respond to the aggregated

flow-level rule changes.

Another language abstraction trend is to support modular

programming, that is, it should allow the handling of isolation

issues between multiple programs that control different portions

of the traffic. Each piece of program has different tasks, some

target host monitoring, some for failure recovery, some for vir-

tualization, and so on. How do we make all pieces of program

interface to each other in a transparent way? This needs a high

level of abstraction for SDN programming.