T2: SDN basics and the Open Flow protocol

T2: SDN basics and the Open Flow

protocol

Summary

SDN aspect SDN support points SDN criticizing points

Separation of control

and data plane Flexible and capable mngm. Optimized capacity use and faster failure recovery via central topology view.

Northbound Interface (NBI) is an enable of innovation and

competition due to open

standardization. 

Interoperability between different network domains is open issue.

Missing NBI standardization may negatively affect interoperability of SDN applications if remains unaddressed for too long. Controller design Dynamics traffic decisions based on

current network state.  Fast reaction times via centralized logic but distributed controller implementation.  Cross-layer optimization possible.

How many and which header fields to use for flow rule construction?

State consistency issues with distributed controller design. Communication bottleneck between the controller and switches – reactive or proactive approaches, which to choose? Forwarding plane design Standardization on the Southbound

interface (SBI) allows for clear communication with the data place and supports interoperability between vendors.

Clear interface definition supports fine granularity of flow control. 

The data plane is currently too simple – it can perform some in-network processing for rapid and scalable flow handling.

Flow tables need to scale in size and speed of matching.

How long to keep flow rules? Switch CPU needs to improve to handle some local processing for better SDN scalability.

SDN extended use SDN can offer benefits to other types of networks, e.g., infrastructureless networks or radio access (wireless) networks.

Reverse optimization: fine tuning SDN based on knowledge on

network configuration, topology and traffic patterns.

Large number of SDN

applications should cause neither too complex SDN design, bringing us back to current network problems, nor too generic SDN design, simplifying too much and leaving deployment unclear.

Class discussion

SDN aspect SDN support points SDN criticizing points

Separation of control

and data plane NBI: Flexibility of the interface allows many interesting development but they could also diverge. To keep common operation possible one could provide guidelines on networking functionality that different operators should agree on. Examples to ensure NBI compatibility:

• BGP-inspired approach with negotiation;

• MPLS-inspired traffic handling;

• Path Control Elements/PCE;

• circuit-switching reservation style.

NBI standardization should be eventually addressed; building on top of a basic standard is always possible.

Interoperability between domains is challenging: 1. Ensure common interpretation of traffic handling rules, 2. Ensure SDN flexibility globally over several domains is more difficult.

Controller design Distributed controller design can help scalability and inter-domain

interaction.

Distributed controller design may help interoperation between

difference SDN application providers using different NBIs by allowing the controllers to share data and agree on functionality.

ForCES vs SDN: ForCES argues it can be faster adopted by vendors due to only logically keeping the separation of control and data place in the same physical device.

Distributed controller: state consistency between controllers can be done by using epochs in which the rules are valid.

• Careful definition of consistency level per application type is needed.

• Consistency during mobility scenarios can be either left to solve via new flow rules generation when the flow moves to a new switch or the controller can move the flow rule from the old to new switch.

• Consistency between controller and switches should also be ensured. Different domains can adopt different network protocols but the controllers need to agree on translation. Protocols in the control plane may even become obsolete and replaced by new, better & simple ones. Processing time in the

controller can be decreased by pre-computing most probably paths & flow rules.

Forwarding plane design Proactive flow rules calculation can be based on generality of traffic or statistical knowledge of traffic patterns, e.g., regularly scheduled back-ups.

Separation of traffic processing – small ‘mice’ flows processed by the switch and big ‘elephant’ flows processed by the controller. This requires categorization of flows.

Careful choice of which header fields and how many are needed for flow rule creation and will scale inside the switch (in time and flow table sizes) is needed.

The cost of protocol header processing (fields matching takes place in Content Addressable Memory/CAM) can drive simplification of protocols (decreasing the # of header fields or their use).

Critique

Pappas, Christos

1. The claim that SDN can be a remedy against "Internet ossification" is very strong and not well justified. "Internet ossification" - the inflexibility and inertia to deploy novel protocols and services - is merely a result of the huge success of the Internet. The Internet was designed for a different purpose with a different set of requirements in mind compared to today's requirements. Hence, today's requirements are not reflected in the Internet architecture and the unexpected success prevented radical changes. To fulfill the increasing demand, the infrastructure was optimized and specialized hardware - with its inherent inflexibility - was employed. Furthermore, the unpredictable problems that emerged received patch solutions (e.g., congestion control in TCP or DNS), which naturally became widely implemented and further aggravated the inflexibility problem. With this notion of "Internet ossification" in mind, it is unclear how SDN is a solution. Today SDN has been realized only within the boundaries of a single administrative domain and can provide flexibility and control only within the domain. It is not clear how SDN helps to "deossify" the Internet. For example, how would SDN help in replacing BGP?

2. There is no comment or criticism on today's realization of SDN in the forwarding plane. For example, it is known that MPLS is employed by ISPs because it simplifies the forwarding plane and reduces the infrastructure cost. Although MPLS is a distributed protocol, why cannot it not be combined with SDN? Specifically, the centralized controller could distribute the labels to the edge switches and configure the intermediate switches. This could combine SDN's flexibility and a more efficient forwarding plane.

3. Today SDN is realized through OpenFlow, which specifies the interface between the controller and the switches (southbound interface). However, to fully realize the network OS model that allows application development, the interface between the controller and the applications on top must be specified (northbound interface). Not specifying this interface, partly beats the purpose of SDN if every controller has a different API and introduces inflexibility. Moving an application to another controller or upgrading the controller can introduce compatibility issues and translates to costs.

Miladinovic, Djordje

1. SDN brings many nice features to the world of networking, but before deploying it, one should thouroghly think about the problems it might bring. One of the most obvious ones is performance. The designer of the network which will be using SDN, has to create a proper balance between the scalability and performance. In order to avoid scalability problems: too many entries in the table of a switch, the designer has to reduce the granularity of the network flows and this will potentially affect the overall performance of the system. The question is: how to create such a balance given the system specifications?

2. The second critique also concerns performance issues in SDN. As one could suspect the most probable bottleneck of the system will be the communication between the switches and the (logically) centralized controller (There is a study in the paper that supports this: B4 Google SDN implementation). In order to relax the bottleneck there are several techniques proposed: proactive rule placement, using short/long-live flows and physical distribution of the controller. The last one might

be the most interesting approach since it has some other advantages too: avoiding single point of failure, distributing the workload... The question is: How to chose where to place the controllers to maximize the performance?

3. The northbound interface is not standardized. This could be a big pitfall and could prevent OpenFlow/SDN conquering the world of networking. It is the issue that should be solved as soon as possible.

Van Gelder, Jasper

1. For a new technology or protocol to be adopted it is absolutely necessary to have backing by a majority. From the paper I extract that until now only openflow has been able to attract a large part of academia and industry. This means they have a good chance of being widely adopted and improved, but they should make sure they don’t make any misteps as for example happend to the Linux Gnome desktop project or what is currently happening in the debian/ubuntu projects where a few members try to force systemd (when these kinds of events happen the adoption might stall).

2. To me it makes a lot of sense to decouple the data and control plane because I my self have had issues with this in my own local lan ! In my case I wanted to route from vlan to vlan but this did cost too much cpu power so my openwrt tp-link box was unable to handle it. The way I did it now is to create one vm which would do the routing and all the switches would only forward packages. Which is basically what openflow tries to do.

3. In the paper it is also mentioned that based on openflow data certain devices could be turned on or of reducing the power usage of a data center. This would be really hard with classical solutions because either you will not even have the data or it will take you tremendous effort (it would be possible with SNMP queries and remote commands). But I think it does not end with simply turning a switch of I think it would even be possible to powerdown whole racks solely based on SDN data.

Shinde, Pravin

- The separation of routing into the controller, and ability of the forwarding plane to understand the rules based on IP and L4 header field gives very high flexibility.

- The approach of forwarding at the granularity of the flows instead of packets moves the slower controller path out of the critical path for most packets. The decision about which path to use needs to be done only once, at the beginning of the flow.

- The completely open NorthBound communication allows existing applications, systems and solutions to talk with controller to make requests or to provide additional information.

- The paper provides detailed context and background about the development of the SDN to realize that this is not completely out of the blue idea.

Criticism

- The metadata used in the connection looks like IP and L4 headers. Won't it be more flexible if they were just binary blobs (offset and value pairs) That way, it won't be restricted to currently supported IP or TCP/UDP protocols, allowing more experimentation with protocols in closed setups like Datacenters.

- It is not very clear how much latency will be added into new connections by having it forwarded to controller?

- The design also talks about multiple controllers. In such a setup, it's not clear how exactly the consistency between the controllers will be maintained?

- If the controller needs to decide on the configuration in the critical path, how much time can it spent in exploring the global view and to come up with the best possible decision?

- How does the SDN knows that the flow is over? Otherwise old flows will just be around, eating up valuable rule space!

- The paper does not give clear picture of the time budget controller has on making decision on each new connection. This information will be useful to envision the possible complexities that can be added into the controller.

Yu, Xinyuan

1. Extra traffic and performance delay: Forwarding elements must consult a controller each time. It causes a lot of extra traffic and performance delay. Although the performance delay can be decreased by proactive policies, it still has effect on the performance.

2. Security: I don’t have a clear idea with security protection in open flow. Is it possible to effect the decision of controller manually?

3. Consistency and staleness: Consistency and staleness may be effected when the physical architecture is distributed. It is difficult for the controllers to keep consistent. When inconsistency happens, some errors may happens, for example, cycles may caused.

Defense

Lee, Tae-Ho

1. I enjoyed reading the research challenge section towards the end of the first paper. Such section help readers to think about any new problems to work on (especially for graduate students). In particular, I liked two points that the section has discussed. First, it is interesting to think about how SDN could help in infrastructure-less networks, such as ad-hoc networks, self-organizing networks, spontaneous networks. Second, the problem of SDN in inter-networking is very interesting. There has been progress in this area, such as SDX in Sigcomm 2014, but it only offers the first step towards thinking about SDN in inter-domain networks. In particular it would be interesting to investigate how a centralized controller can accomodate the multi-party nature of the Inter-network ownership (In the Internet ASes are not willing to reveal information about their internal topology. In addition, they would be hesitant in surrendering controller over their own network to another party).

The second paper describes Path Computation Element (PCE), which defines coordination between multiple PCEs across multiple domains to coordinate QoS provisioning across multiple MPLS-TE networks. I felt a bit disappointed that the paper fails to mention about this aspect of PCE, and possibly explain any similar ongoing work in this space for OpenFlow. If no work exist, even acknowledging this fact would have strengthen the paper.

2. Both papers demonstrate the advantages of separating control- and data-plane. Perhaps the following may be another interesting line of thought. The separation allows the network architects/planners to take their network requirement/environments into account when thinking about

the necessary control-plane functionalities, and how to implement them. For example, in data-centers, where IP address-to-MAC address mapping is fairly constant and can be known in advance by the network administrator or controller, ARP may be more efficient if it is implemented as a query to a database that stores the IP-to-MAC mapping, instead of using the traditional broadcast mechanism, which can create burdensome broadcast storm.

3. I like the presentation of the first paper. For each component, the paper first state the generic problems associated with the component (e.g., memory limitation in forwarding devices), and then summarizes the existing works regarding how they attempt to solve the problems.

Birkner, Rüdiger

1. Separation of Data and Control Plane By standardizing the southbound interface, it is possible to use switches from different vendors that do implement the preferred southbound interface. This allows for a simpler switch design (bare-metal switches) and white box devices.

2. Central Controller Simplifies the Management of the Network The central network view of the controller allows for faster and better link failure recovery and it enables to optimize the utilization of the links and networking devices (e.g. Elastic Tree).

3. Network Slicing (e.g. FlowVisor) The current production network can be used for testing of different controllers or new controller applications alongside the normal production traffic. In addition, through slicing each tenant of a multi-tenant data center may run its own controller and fully control its slice of the network.

Chothia, Zaheer

* Similar to "Road to SDN" paper but modernized. Extensive and concise coverage of literature makes it good as an introduction to the area. Clear and logical structure (history, proposals, alternative implementations and use cases) but missing numbers on production deployments and their needs (litmus test for controller throughput, flow latency).

* Ideas have percolated from half a dozen research areas over ~20 years and the field has advanced significantly in the interim. Nonetheless, interesting to see that problem statement and requirements remain largely the same (need for more control, ability to innovate).

Benefits

* High-level benefits:

- The broad idea of a clean separation and revised abstractions to allow programmability are refreshing and overdue.

- Promises to address the problems discussed previously (T1: raising efficiency, easing debugging, virtualization, etc.)

- Consequence of standardization: vendor independence (assuming they retain interoperability). This will allow for portability and more competition -> good since the field is very insular.

* Further concrete advantages:

- Demonstrable gains (e.g. B4/SWAN link utilization)

- Proactive rules (install ahead-of-time) already in conventional networks, but now also have ability to react and adapt dynamically and on a shorter timescale.

- Granularity: flexibility to adapt treatment of individual flows and gather statistics at fine level of detail (per-flow/table/port)

- Flattening: "collapses L1-L4 control into a single layer" -> potential for cross-layer optimizations and conceptually simpler to program.

Skepticism

Many possible instantiations: OpenFlow is just one realization and I am not fully convinced: original spec was concise and elegant (flow table = match + action) but those are only the minimal flow primitives (cf. 'assembly language'). OF doesn't provide network abstractions, controller APIs or interfaces to applications (i.e. the network OS part).

The forwarding plane is rigid: "it targets fixed-function switches that recognize a pre-determined set of header fields and that process packets using a small set of predefined actions" [P4]. The ability to reconfigure and define new protocols, packet parsing and processing is consequently also limited. In a similar vein, can accomplish middlebox use cases (e.g. firewall, LB, DPI) but in-network processing is not directly supported and seems to be bolted on as an afterthought.

Logical centralization: provides global view of resources, simplified management. However, physical distribution is hard and many problems have been swept under the rug: cross-controller consistency, multiple failure domains, inter-AS control.

Chang, Michael

1. Small Deployments are Possible: SDN's advantages are evident even in a small deployment. This is in contrast with the T1 paper; the alternative protocols to the Spanning Tree algorithm required a large deployment and high investment cost to reap any kind of benefit. While it is not an entirely fair comparison, the benefits resulting from utilizing a SDN architecture can be reaped simply from a small deployment. The network administrator has the option of either deploying small networks of SDNenabled network devices, or integrating SDN-enabled network devices with existing networking infrastructure (this is the concept of a supercharged network devices).

2. Near ubiquitous adoption of Openflow as Southbound protocol: The paper lists a few different southbound protocols, but its remarkable that the industry has almost ubiquitously adopted Openflow as the standard. SDN already has plenty of challenges in terms of overcoming the barrier of adoption, but having industry agreement on the southbound protocol is truly an important first step.

3. No limitation of software running on Northbound interface: While the Northbound interface remains a major subject of discussion and research, the possibilities are accessible and virtually endless. The concept of programmable networks is indeed a powerful one.

4. Reducing Internet ossification: The “as long as it works and makes me money” mentality of the networking corporations needs to be changed. Instead of having a proprietary black box networking device, SDN inherently creates a separation of the device components. At a basic level, you would have the bare metal switch, the software running on the switch, a controller platform, and applications riding on the northbound API of the controller. Creating this separation opens the door to evolution and innovation, hopefully reducing Internet ossification which is not moving fast enough to keep up with the evolving usage of the Internet.