In traditional networks, the routers in the core of the network are responsible for two actions: making routing decisions and forwarding packets.

Software Defined Networks Yichen Shao, University of California Santa Barbara, [email protected]

Zhipeng Hui, [email protected]

Sijie Zhang, Xiamen University, [email protected]

Zongze Li, Cascadia Community College, [email protected]

Tongyu Chen, Hangzhou Foreign Language School, [email protected]

Abstract—This should be a very short overview of your entire paper. The reader should be able to figure out from the abstract if he/she wants to read the rest or not.

I. INTRODUCTION

A quick introduction to the idea of SDN and the differences with a conventionally managed network.

II. BACKGROUND

An overview of the SDN ideas. You should probabl specifi- cation. List important features of SDN that won’t be discussed in the rest of this paper, giving a paragraph or so of description of each. You might want to make subsections for each, in which case, follow this example. Make sure this section doesn’t overlap with McKeown, which has lots of the basic ideas of SDN.

A. SDN for Blockchain

Some text about this idea. Obviously, this is an example. You don’t need to write about the Blockchain unless you think it important.

III. THE RISE OF SDN

1. Introduction

Networks have been developed over decades. And it is both a blessing and a curse for networking researchers because that there is almost no practical way to experiment with some new network protocols in the real traffic. However, the OpenFlow surprised us with a whole new concept of a programmable networks model in campus networks.[1]

Researchers discovered that most modern Ethernet switches and routers contain flow-tables which have a common set of functions running in the flow-tables of switches and routers. Exploiting the common set of functions in flow-tables, OpenFlow introduces a new protocal to program the flow- table and makes it possible to programs in different switches and routers.

2. Basic Model

The basic model of OpenFlow Switches contain three parts: 1) A flow-table (a flow could be defined as all packets matching a specific header) 2) A Secure Channel that connects

the switch to a remote control process(controller) 3) The OpenFlow Protocol that provides a way for a controller to communicate with a switch.

An entry in the Flow-Table has three fields: 1) A packet header that defines the flow, 2) The action that defines how the packets should be processed, 3) Statistics that keep track of the number of packets and bytes for each flow. And each flow-entry has a simple action associated with it. There are three basic actions for ”Type 0” OpenFlow Switches: 1) Forward this flow’s packets to a given port which allows packets to be routed through the network. 2) Encapsulate and forward this flow’s packets to a controller. Packet is delivered to Secure Channel. Typically used for the first packet in a new flow, so a controller can decide if the flow should be added to the Flow Table. 3) Drop this flow’s packets. Typically used for security to curb denial of service attacks, or to reduce spurious broadcast discovery traffic from end- hosts. 4) Forward this flow’s packets through the switch’s normal processing pipeline. However, the model of OpenFlow Switches is not limited as ”type 0”. When a particular set of features emerges, such as rewrite portions of the packet header, match on arbitrary fields in the packet header to enable experiments with new non-IP protocols, we can also define a ”Type 1” switch.

A controller in the Secure Channel adds and removes flow-entries from the Flow Table on behalf of experiments. A controller could also be more sophisticated that dynamically add/remove flows as an experiments progresses. Here could be a new topic of using neutral network to enable the functionality of dynamically adding and removing flow- entries. On the other hand, the restrictions could also be imposed with appropriate use of permissions or other ways to limit the powers of individual researchers to control flow entries. The exact nature of these permission-like mechanisms will depend on how the controller is implemented and the aim of research.

3. Conclusion and Concerns

The model of OpenFlow in campus network is just a prototype which aims to achieve the goals: 1) Amenable to high-performance and low-cost implementations. 2) Capable of supporting a broad range of research. 3) Assured to isolate

experimental traffic from production traffic. The first goal could be achieved by the OpenFlow Switches. The second aim could be achieved by the implementation of the controller. And the third goal could be achieved by the Secure Channel as a whole. However, I do think the paper lacks of the discussion of the OpenFlow Switches and security problems. As the OpenFlow Switch contains two parts: software and hardware. That implies that the switch should contain the application layer which is different from normal switches. That could lead to multiple problems. Moreover, as the paper states that a researcher might control the complete network of OpenFlow Switches and be free to decide how flows are processed. That could lead to some serious security problems as there’s no super user of the entire network.

IV. GOOGLE’S DEPLOYMENT OF SDN WAN ARCHITECTURE

Abstract Google deployed B4, a global Software Defined WAN, to connect Google’s data center in 2013. This paper discusses how B4 improves the network mechanism and how Google establishes the architecture of Software Defined Network globally. Comparing to the traditional WAN architecture, B4 define the priority of the applications which enables B4 to drive the link utilization to nearly 100% and has control over the edges servers and the network. Google’s Software Defined WAN architecture is mainly defined in three layers which consist of global layer, site controllers , and switch hardware layer. Furthermore, Google uses centralized Traffic Engineering (TE) in TE server as its new SDN application to control the network resources according to priority and allocate paths for data in transmission.

Keywords: Centralized Traffic Engineering; Wide-Area Networks; Software Defined Networking; Routing

1. Introduction The Google company operates on two distinct WANS (wide area networks). The first one is user-facing networks for end users to deliver their requests and responses to Google’s data centers. The second one is the protagonist, B4, in this paper. B4 is used to connect data centers. The birth of B4 helps the network companies to save money on internet equipment. The traditional WAN architecture considers all the applications equally. In other words, it treats all bits equally no matter whether or not they deserve. As we all know, the packet loss is inevitable in data transmission because a queue preceding link only has finite capacity. Once it is full, it will drop the new coming packet. At that moment, the packet loss occurs. In order to prevent the users sensing the packet loss, network companies have to buy lots of high-end routing gears to increase the bandwidth. With the help of large bandwidth, even though the packet loss occurs, the network still has spare bandwidth to do the retransmission quickly. However, the shortcoming is obvious that the average utilization is only 30 ∼ 40%. The waste of network resources and expensive

equipment leads to the deployment of B4.

2. Design Decisions 2.1 Separate hardware from software The core idea of SDN is to separate hardware from software. Let the hardware to do the simplest job and let the software to be the leader. Hence, the protocols on software have rapid iteration without the limitation or revision of the hardware.

2.2 Drive links to 100% utilization In order to achieve 100% utilization of the network, Google categorizes thousands of applications which run on B4 and define them in different levels and different priority. These triple traffic classes are ordered in increasing volume, decreasing latency sensitivity and decreasing overall priority. The top of the pyramid is user data copies, such as email, documents, and video files because users’ satisfaction is significant. The users care about the latency and availability most. Their satisfaction is significant. These things have lowest volume in general. The second one is remote storage access such as fragmenting data and put them in different data centers or doing the computation on distributed servers. The last one is synchronization. Like if doing the computation on lots of servers in different data centers, servers need to interact with each other and know the states on the other servers. The idea here is to fulfill the demand of the highest priority mission. And the rest of bandwidth is filled by other missions which are not urgent. The shortcoming is that packet loss becomes inevitable, or we can say it is more obvious to the servers. As mentioned before, the traditional routing treats all bits same, so everyone has packet loss. However, large bandwidth hides it and make users or servers cannot sense it. Network has free bandwidth to do the retransmission. Even though, suddenly large bandwidth is needed, we can afford it. However, when the utilization reaches nearly 100%, there is no free bandwidth to hide packet loss. Especially the applications with lower priority. Because the bandwidth is mostly used by higher priority application. Once the link failures happen, there is no free bandwidth and packet loss cannot be fixed in short time. Controllers have to allocate the bandwidth dynamically and robs the bandwidth from higher priority applications. It needs time, at this time, the servers or end users will sense it.

2.3 Centralized Traffic Engineering The first SDN application is called TE, the traffic engineering. It mainly has three missions. The network resources are constrained, it controls the resources at the edge to decide who gets the resources. According to priority, use multipath tunneling to leverage network capacity. Dynamically reallocate bandwidth when link failures or shifting application demands occur. (needs more information to fulfill it, just put aside for a while)

2.4 B4 routers The third decision is B4 routers build from merchant switch silicon. Google chooses not to invent new instruments but

based on merchant’s existing switches. There are thousands of hardware and it is impossible to unify all of them in a new language. On the other hand, the traditional view is that the router must have great buffer capacity. The larger buffer means larger forwarding tables. Forwarding table maps addresses to outgoing link. However, this increases the complexity and cost of hardware. Hence, Google invents its own routers and switches which based on the merchant silicon. The central idea is to have smaller forwarding tables, stronger switches, and fewer data centers.

3 Three-layers Software Defined Network WAN architecture

3.1 Bottom layer: Switch hardware layer The bottom layer is switch hardware. It only forwards the traffic and has nothing to do with any complicated things, just like ergates who follow the queen ant’s orders and do the hardest job. Here, we can see the OFA, OpenFlow Agent. It’s a translator and supervisor. Its job is to translate the raw data, the status of the switch, into something OpenFlow controller can understand. Just like which ant is sick or busy.

3.2 Middle layer: Site controllers The middle layer is site controllers which hold OpenFlow controllers. Its mission is to decide how to forward the traffic according to switch hardware’s status. They are leaders of the departments in the company and give orders to workers. Now, OFC understands the working status. So, it communicates with Quagga by RAP. RAP is a bridge between them. The Quagga is three layers protocol stack. It contains all of the information about the sites, the paths, the ports. Then, the Quagga provides things back to OFC and OFC upload all of these information to TE agent. TE agent uploads to Gateway.

3.3 Top layer: Global layer The top layer is central traffic engineering server which logically controls the entire network. The Gateway is a secretary. It translates the topology, the raw data into something TE can understand and gives these data to central TE server. The TE server is CEO and does the calculations, like which application go which path. The following part is easy. CEO’s decision goes back to OFC and writes in switches. Now, switches know what to do.

V. PROMISES AND LIMITATIONS OF SDN

The concept of SDN was introduced about ten years ago. Representative work includes the previous two paper- OpenFlow and Google B4-and many other researches done on the structure design and model presentation of SDN. For a while, the public had much expectation on this emerging concept. Seeing that SDN has many seemingly attractive advantages, such as centralization and programmability, the business market and media hyped it up, praising it as an ideal structure. However, SDN is not as a perfect network

as it seems to be. When in practical use, it in fact do not achieved its promises. White et al. gave a detailed analysis on the three promises and characteristics of SDN-centralization, flow control and programmability-and proposed the drawback and limitations of SDN in their research paper.[2]

1 Centralization

1.1 Centralization Structure One of the biggest differences between SDN and traditional network is the main structure. Traditional network, such as IS-IS and BGP, uses distributed control planes. The whole network consists of many network nodes, each of which includes a control plane and a data plane. The control plane is responsible for managing the node’s operations, and communicates with neighbor nodes. Each node can decide their own settings, which is to say it is configured individually. The drawback of traditional network is its distribution. Because the configurations of nodes are totally different, the network operator has to store the information for every node, and manage complex policies between them. The huge amount of information storage then leads to the adoption of large and expensive devices. By contrast, SDN uses a centralized structure to eliminate the complexity of traditional network. The core component of SDN is the controller. It works as a network operating system, which receives requirements from network applications, calculate the forwarding path according to a set of rules, and send the forwarding command to forwarding devices. Because there are no individual configurations for nodes, and only the controller, but no routers, takes charge of the topology and calculation process, it is easier for the network operator to manage information, and forwarding devices can be cheaper and lighter than the traditional ones. However, complexity still exists in this situation. In reality, in case the controller is crushed, and also to ensure the SDN service can have global coverage, there has to be multiple controllers to run simultaneously. Therefore, the problem lies in how to deal with their relationship. This topic will be discussed in 1.4.

1.2 Reactive Forwarding Traditional network takes a proactive method in the forwarding procedure. That is to say, the forwarding path will be determined before the first packet is transmitted in the network. This method is accomplished by information aggregation of the routers in the network. They hold the accurate information of their neighbors through the process of flooding, processing and managing, and thus can decide the correct path. However, for an SDN network, it takes a reactive plan. Forwarding devices can only know reachability information when it receives the first packet. This is because for the controller, due to the large scale and complication of the network it takes control, it does not store all the forwarding

information. Therefore, it adopts some protocols and policies to decide possible paths as the forwarding paths of the first packet. If the packet arrives at a forwarding device successfully, the device will feedback this reachability information to the controller. The issue of reactive forwarding is that, before the forwarding devices receives the first packet and send the information back, the controller does not know the reachability of paths, which causes a disconnection to the real situation. For the same reason, there will be a lag between the first packet beginning to be transmitted and the path to be determined.

1.3 Reaction to Changes For a traditional network, when the state of a node changes, other nodes in the network receives the change information from its neighbor, and send it out to other neighboring nodes until all the nodes are aware of the change, and then new path will be calculated. Therefore, the reaction time is mainly spent on routers spreading messages and recalculation. When a local node changes or fails in SDN, first the message will be transmitted to the controller. The controller will then calculate and decide a new path, and transmit new forwarding rules to related nodes. Although the recalculation is much faster for a controller since it has limited information for nodes, still the spreading of new rules to the forwarding devices in the network is a slow process. Therefore, the reaction time for SDN is no faster than traditional network.

1.4 Reality of Centralization Centralization, one of SDN’s big promises, seems to be a very appealing advantage. Frustrated by complicated traditional distributed network, SDN’s method of centralizing control module will make management a lot easier. Totally physically centralized, however, is impossible in the real world. Firstly, to ensure reliability, there should be multiple controllers working together, while each of them gets a slice of workload. Secondly, to ensure scalability, controllers should be separated to different regions, with each region handled by an SDN system. As a result, SDN still deal with the whole network in distributed systems, which is inconsistent with its promise to be centralized, and the biggest problem emerges: how do different controllers communicate and exchange information? To make the SDN system uniform, we have to decide the format and new protocols applied between controllers.

2 Flow-based Network

The forwarding of SDN is flow-based rather than the destination-based method of traditional network. It aims to assign different paths in the network for individual applications to ensure that files with special requirements are transmitted efficiently. Flow-based forwarding enables more flexible and individual transmission, but it has significant disadvantages. Firstly, it produces too much connections. For traditional network, since it is only addresses but not files

that matter, only one TCP connection is needed between the source and destination, and all files are forwarded through it. However, for SDN, due to the different paths that different files take, it has to set up a TCP connection for each flow. The setup rate will also be slower because the format of the flow should be stored. Secondly, to store the huge amount of connection information, hardware cost will be quite high. Also, there will be more cost for each forwarding devices to examine the headers of flows to ensure they are in correct format and path.

3 Programmability

The most appealing part of SDN which attracts the business market is that it promises to be open and programmable. This feature did hold true in the beginning stage, providing a clean and flexible platform for users to develop their own functionalities. However, as SDN become more and more widely covered, eventually venders dominated the market, and they compete with each other. In order to make themselves stand out, venders develop new models continuously, along with new hardware and software requirements. Meanwhile, they prefer to make their product vertically integrated, which means they tends to develop the whole functionality from application interfaces, to controllers, and finally down to forwarding devices in order to make more profit. As a result, the configurations of SDN is likely to be diverse because of different venders, and is no longer uniform as people expect it to be. And on the other hand, venders are reluctant to disclose their programs, which has led to the development of SDN models being closed within these venders, and thus is not programmable as it was originally guaranteed.

In conclusion, the concept of SDN appeared bright when it was first proposed, but as it developed, the problems of its characteristics were also exposed. The three main features- centralization, flow control and programmability-are either flawed or invalid in the long run. Therefore, just as the author said, we should not view SDN as an ideal goal to reach. Instead, it is just a tool or a method that needs to be improved.

VI. AGARWAL2018

“Traffic Engineering in Software Defined Networking.” it has come to be a flexible network that offers opportunities to the research activities and more well-organized traffic engineering. SDN has two main components, that is, SDN Controller (SDN-C) SDN Forwarding Element (SDN-FE). SDN Controller (SDN-C): The controller is a rationally central purpose. A net is characteristically skillful by one or a few supervisors. The supervisors control the advancing trail for apiece movement in the system. SDN Forwarding Element (SDN-FE): The SDN-FEs establish the net information flat. The reason for advancing the packs is strongminded by the SDN organizer and is applied in the advancing table at the SDN-FE.

The traffic engineering’s main objective is Developing a Software-Defined Networking (SDN) placement arrangement, which dynamically and adaptively achieves circulation in a network to house diverse circulation designs. The main contri- bution includes: Addresses Network performance issues in an SDN placed incrementally, formulation of SDN supervisor’s question of optimization and list FPTAS to compute the problem of controllers, SDN examination with simulations improvements that are considerable in loss and delay perfor- mance in a low SDN amounts elements positioned in a net, and outlining the algorithm for placement of forwarding elements determination.

The functions of SDN-FE include: 1. Forwarding – SDN works as a forwarding element. It is assumed that SDN-Fes can handle several hops that precede for a specific destination. If there are several preceding hops, the SDN-FEs can divide traffic to the terminus in a manner that is pre-specified across several preceding trips. 2. Measurement – The routing table has been modified a little, compared to other routing tables, to aid analysis at SDN-Fes. When SDN-FE handles a packet, it makes a long prefix match on the IP address it goes to for the determination of the previous hop. 3. Peering – SDN- C has routing logic and is coordinated with the routing of SDN-Fes so that excellent network performance is enhanced. The controller knows the actual weights of OSPF and the traffic flow amount on every link. 4. Route Computation – The controller computes the routing table for SDN-Fes in a network. Route computation computes the routing tables while considering the routing conducted by non-SDN-Fes, traffic at the link, and current traffic pattern.

About Formulation of the SDN-C’s Problem objective of the SDN-C is to route the controllable traffic such that delay and packet loss at the links are minimized.

Software-Defined Networking (SDN) is a new-fangled inter- acting model that differentiates network regulator flat from the pack advancing flat and delivers requests with an inattentive central opinion of the dispersed of the network state. Software -Defined Networks provides for flexibility, efficiency, and ease in functionality. Google has even decided to make use of SDN, showing that it is a good network option in the market today considering the status of the Google Company.

VII. LANGUAGES FOR SOFTWARE-DEFINED NETWORKS

Because managing networks in tasks such as routing and traffic monitoring is unnecessarily complicated and error-prone. SDN are poised to change this by offering an interface between networking devices and the software that controls them.

Although SDN makes it possible to program the network, it is still inefficient. The three designing of simple abstractions for network management in order to reach SDN’s full potential are: (i) monitoring network traffic, (ii) specifying and composing packet-forwarding policies, and (iii) updating policies in a consistent way.

Before, on each device, network operators must config- ure every protocol. However, the growing interests in SDNs nowadays promote a logically-centralized controller manages a distributed collection of switches.

SDNs make it possible for programmers to control the behavior of the network directly, by configuring the packet- forwarding rules installed on each switch. Some may regard this as a centralized control, though, for a higher scalability and fault tolerance, the controller is replicated and distributed. SDNs can simplify applications and build up platforms for developing new applications.

Conserving energy: Controllers selectively shut down links or even whole switches after directing traffic along other paths. Balancing the load between servers: The controller can split flows over several server replicas and migrate flows to new paths in response to congestion.

As a matter of fact, for today’s SDN controller, platforms for writing applications remain in low-level distributed pro- gramming.

1.1 FRENETIC As a replacement to the low-level imperative interfaces, Frenetic offers abstractions for querying network state, defining forwarding policies, and updating policies.

II. QUERYING NETWORK STATE

This is made possible in part by the underlying run-time system, which follows OpenFlow rules. Frenetic demonstrate three ways of the “control loop” for running a network. The first is Querying network state: a high-level query language including traffic statistics and topology changes. 2.1 A. Query Language Design Considerations Many monitor applications classify traffic using packet headers. Instance: if the programmers want all web server traffic excluding the host with IP source address 1.2.3.4. There are two rules— the upper matches packets from 1.2.3.4 with TCP source port 80, the lower is associate with all remaining traffic. Frenetic specify predicates like “srcip!=1.2.3.4 srcport=80,”.

Dynamic unfolding: The usage of efficient hardware, and the counters remain the information needed to implement.

Limiting traffic: Sending the first packet to the controller, and install rules for dealing future packets.

Polling and combining statistics: The run-time system queries the traffic counters, returning results to the application. 2.2 B. Example Frenetic Queries

MAC learning and Traffic histogram: An Ethernet switch performs to identify what interface to use to reach a host. Select(packets) * GroupBy([srcmac]) * SplitWhen([inport]) * Limit(1)

The result is a stream of packets to the ingress port. Frenetic’s language gives the programmer a sense of the cost of a query. The run-time system directs all packets to the controller, but gradually installs packet-forwarding rules after the first packet for the MAC-learning query.

III. COMPOSING NETWORK POLICIES Reconfiguring the network: This is a way without having to manually install, actually allows programmers to reconfigure the network. The run-time system ensures that during an update, all packets (or flows) are processed with the old policy or the new policy, and never a mixture of the two. This guarantee ensures that functional invariants are never seperated and broken during periods of policies’ transition.

3.1 A. Creating Modular Programs A. Creating Modular Programs This is a method that consid- ering a program which blend in repeater functionality with web-traffic monitoring functionality.

In comparison to Python program, Frenetic makes it easier for programmers to write and compose independent modules. def repeater(): rules=[Rule(inport:1, [fwd(2)]), Rule(inport:2, [fwd(1)])] register(rules) def web monitor(): q = (Select(bytes) * Where(inport=2 srcport=80) * Every(30)) q ¿¿ Print() def main(): repeater() monitor() The main function assembles components into a program. Eas- ily swapping out the given network monitor without touching repeater code or change the forwarding logic .

3.2 B. Efficient Run-Time System The flow table of switch is empty at the very beginning, so every packet is sent to the controller.When receiving a packet, the run-time system traverses the registered forwarding policies collecting a list of actions for that switch. The run- time system has the ability to refine the rules based on the actual traffic, supporting policies with arbitrary functions that the switches cannot implement. The run-time system can customize rules to make the switch more portable. According to the newest versions of the OpenFlow provide, an interface to the tables in modern hardware. In the future tasks, programmers plan to extend run-time system to represent sophisticated policies.

IV. CONSISTENT UPDATES Programs need to transfer from one policy to another and changes in network load. As we have designed high-level network that traffic will be processed consistently, the update operations provides useful guarantees about network behavior during transitions. 4.1 A. Per-Packet Consistent Updates ”Guarantees that every packet flowing through the network is

processed with exactly one forwarding policy.” In fact, a majority of upgrades are possible when the policies are similar. If the new one is comparatively simple or retrac- tion, updates will become simpler and less sophisticated to operate.

4.2 B. Per-Flow Consistency Although per-packet consistency is powerful, it is not enough. Some applications require streams of related packets. A per- flow update ensures streams to process with i.e., all packets share almost the same configuration. From personal perspec- tive, the reason why implementing is more sophisticated than per-packet consistency is that the belonging to active flows. By letting the old version in place, the run-time system can preinstall the new configuration as in a stable consistency. The controller uses timeouts on the rules for the old configuration and also installs the lower but new one. When all of the flows matching one of the same rule complete, the rules for a completely new go into service .

CONCLUSION To conclude, the Frenetic language provides programmers with several crucial and powerful abstractions . Compiler and run- time system implements these abstractions. Furthermore, ex- ploring ways to raise the level of abstraction is still on progress and have not reach it’s climax. By this, support program modules that operate on different “views” of the network can make people believe that abstractions will continue to break the barrier and create new applications on SDN. According to the writer of the original paper, the researches about Frenetic are still progressing, but Frenetic is executed to be efficient than any others before.

VIII. CONCLUSION

Your conclusion should restate the important parts of your paper in very short, succinct statements. It should not be a copy of your introduction, though you often see academic papers that do so.

ACKNOWLEDGMENT

The authors would like to thank...

REFERENCES

[1] Nick McKeown et al. “OpenFlow: Enabling Innovation in Campus Networks”. In: (Mar. 2008).

[2] Russ White and Shawn Zandi. “Cloudy-Eyed: Complex- ity and Reality with Software-Defined Networks”. In: Internet Protocol Journal 19.3 (Nov. 2016), pp. 31–41.