Improving Network Management with Software Defined Networking

Posted 2022-11-15 chelinger

• Name of article：Improving Network Management with  Software Defined Networking
• Origin of the article：Kim H , Feamster N . Improving network management with software defined networking[J]. IEEE Communications Magazine, 2013, 51(2):114-119.

ABSTRACT：

Network management is challenging. To operate,  maintain, and secure a communication network,  network operators must grapple（扭打、打交道） with  low-level vendor-specific configuration to implement  complex high-level network policies.  Despite many previous（先前的） proposals（建议） to make networks  easier to manage, many solutions to network  management problems amount to stop-gap（权宜之计）  solutions because of the difficulty of changing the  underlying infrastructure. The rigidity（僵硬） of the  underlying infrastructure presents few possibilities  for innovation or improvement, since network  devices have generally been closed,  proprietary, and vertically integrated. A new  paradigm（范式） in networking, software defined networking  (SDN), advocates separating the data  plane and the control plane, making network  switches in the data plane simple packet forwarding  devices and leaving a logically centralized  software program to control the behavior of the  entire network. SDN introduces new possibilities  for network management and configuration  methods. In this article, we identify problems  with the current state-of-the-art（最先进的） network configuration  and management mechanisms and introduce  mechanisms to improve various aspects of  network management. We focus on three problems  in network management: enabling frequent  changes to network conditions and state, providing  support for network configuration in a highlevel  language, and providing better visibility and  control over tasks for performing network diagnosis（诊断）  and troubleshooting（排除）. The technologies we  describe enable network operators to implement  a wide range of network policies in a high-level  policy language and easily determine sources of  performance problems. In addition to the systems  themselves, we describe various prototype  deployments in campus and home networks that  demonstrate how SDN can improve common  network management tasks.

operate,  maintain, and secure a communication network 为了操作、维护和保护通信网络，网络运营商必须与特定于供应商的低级配置打交道，以实现复杂的高级网络策略。

closed,  proprietary, and vertically integrated 由于网络设备通常是封闭的、专有的和垂直集成的，因此底层基础设施造成网络僵化，几乎没有创新或改进的可能性。

一种新的网络模式，软件定义的网络（SDN）主张分离数据平面和控制平面，使数据平面上的网络交换机成为简单的包转发设备，并留下一个逻辑集中的软件程序来控制整个网络的行为

network management and configuration  methods SDN为网络管理和配置方法带来了新的可能性

我们关注网络管理中的三个问题：

network conditions and state 使网络条件和状态能够频繁更改

highlevel  language 用高级语言支持网络配置

better visibility and  control 为执行网络诊断和故障排除提供更好的可见性和对任务的控制

1.INTRODUCTION：

Computer networks are dynamic and complex;  unsurprisingly, as a result, configuring and managing  them continues to be challenging. These  networks typically comprise a large number of  switches, routers, firewalls, and numerous types  of middleboxes with many types of events occurring  simultaneously. Network operators are  responsible for configuring the network to  enforce various high-level policies, and to  respond to the wide range of network events  (e.g., traffic shifts, intrusions) that may occur.  Network configuration remains incredibly difficult  because implementing these high-level policies  requires specifying them in terms of  distributed low-level configuration. Today’s networks  provide little or no mechanism for automatically  responding to the wide range of events  that may occur

Today, network operators must implement  increasingly sophisticated（先进的） policies and complex  tasks with a limited and highly constrained set of  low-level device configuration commands in a  command line interface (CLI) environment. Not  only are network policies low-level, they are also  not well equipped to react to continually changing  network conditions. State-of-the-art network  configuration methods can implement a network  policy that deals with a single snapshot（快照、简介） of the  network state. However, network state changes  continually, and operators must manually（手动地） adjust  network configuration in response to changing  network conditions. Due to this limitation, operators  use external tools, or even build ad hoc  scripts（构建临时脚本） to dynamically reconfigure network  devices when events occur. As a result, configuration  changes are frequent and unwieldy（笨拙）, leading  to frequent misconfigurations

Network operators need better ways to configure  and manage their networks. Unfortunately,  today’s networks typically（典型地） involve integration（整合）  and interconnection of many proprietary（专有的）, vertically  integrated devices. This vertical integration  makes it incredibly difficult for operators to  specify high-level network-wide policies using  current technologies. Innovation in network  management has thus been limited to stop-gap  techniques and measures, such as tools that analyze  low-level configuration to detect errors or  otherwise respond to network events. Proprietary  software and closed development in network  devices by a handful of vendors make it  extremely difficult to introduce and deploy new  protocols. Incremental（增量） “updates” to configuration  methods and commands are generally dictated（支配）  unilaterally（单方面的） by vendors（供应商）. Meanwhile,  operators’ requirements for more functionality  and increasingly complex network policies continue  to expand.

Software defined networking (SDN) is a  paradigm where a central software program,  called a controller, dictates the overall network  behavior. In SDN, network devices become simple  packet forwarding devices (data plane), while  the “brain” or control logic is implemented in  the controller (control plane). This paradigm  shift brings several benefits compared to legacy  methods. First, it is much easier to introduce  new ideas in the network through a software  program, as it is easier to change and manipulate（操作）  than using a fixed（固定的） set of commands in proprietary  network devices. Second, SDN  introduces the benefits of a centralized approach  to network configuration, opposed（而不是） to distributed  management: operators do not have to configure  all network devices individually to make changes  in network behavior, but instead make networkwide  traffic forwarding decisions in a logically  single location, the controller, with global knowledge  of the network state.

In this article, we explore how SDN can provide  better mechanisms for common（共同的） network  management and configuration tasks across a  variety of different types of networks. While  many prior studies have explored the potential  benefits of applying SDN in computer networks  to facilitate the evolution of network technologies(e.g.,  RCP [5], 4D [6], and Ethane [2]), there  has been little study of how SDN might make  various tasks associated with managing and  operating a network easier

To allow operators to express and implement  reactive high-level policies in an easier manner,  we have designed and implemented Procera, an  event-driven network control framework based  on SDN paradigm. Our policy language and  accompanying control framework, Procera, is  based on functional reactive programming  (FRP). Procera allows operators to express highlevel  policies with this language, and translates  such polices into a set of forwarding rules, which  are used to enforce the policy on the underlying  network infrastructure, using OpenFlow [10].  We have used Procerato reimplement（重新配置） the existing  network policy in the Georgia Tech campus  network, which uses complicated（复杂的） VLAN technology  and many middleboxes to enforce the campus  policy. In combination with the BISmark  suite [11], we have implemented a home network  management system as well, which does  not exist or extremely hard to implement with  state-of-the-art（最先进的） legacy configuration methods.  Our deployment demonstrates that Procera and  SDN can greatly reduce the workload of network  configuration and management, and introduce  additional functionalities to the network  easily

dynamic and complex 计算机网络是动态的和复杂的，因此配置和管理它们仍然是一项挑战。

events occurring  simultaneously 这些网络通常由大量交换机、路由器、防火墙和多种类型的中间盒组成，其中许多类型的事件同时发生

distributed low-level configuration 网络配置仍然非常困难，因为实现高级策略需要用分布式低级配置来指定

limited and highly constrained 如今，网络运营商必须在命令行界面（CLI）环境中使用一组有限且高度受限的低级设备配置命令来实现越来越复杂的策略和任务

continually changing  network conditions 不仅网络策略低级，而且也没有很好的设备来应对不断变化的网络条件

manually adjust  network configuration 面对网络状态不断变化，运营商必须根据不断变化的网络条件手动调整网络配置

frequent and unwieldy 配置更改频繁且笨拙，导致频繁的错误配置

specify high-level network-wide policies 垂直整合使得运营商难以使用当前技术指定高级别的网络范围策略

brings several benefits 与传统方法相比，SDN带来了一些好处：

• change and manipulate 通过软件程序在网络中引入新思想要容易得多，因为与在专有网络设备中使用固定的命令集相比，它更容易更改和操作
• centralized approach SDN引入了集中式网络配置方法的优点，不必单独配置所有网络设备来更改网络行为

common network  management and configuration tasks 在本文中，我们将探讨SDN如何为跨各种不同类型的网络的公共网络管理和配置任务提供更好的机制

an  event-driven network control framework 为了使运营商能够以更简单的方式表达和实现反应性高级策略，我们设计并实现了基于SDN范式的事件驱动网络控制框架Procera

Procera允许运营商用这种语言表达高级策略，并将这些策略转换为一组转发规则，这些规则使用OpenFlow在底层网络基础设施上实施策略。

2.SDN AND OPENFLOW：

Software defined networking has roots in previous  network control systems such as RCP [5],  4D [6], and Ethane [2]. Recent work has introduced  the notion（概念） of southbound and northbound  interfaces. The southbound interface refers to  the interface and protocol between programmable  switches (SDN-capable switches)  and the software controller. The northbound  interface determines how to express operational  tasks and network policies, and also how to  translate them into a form the controller can  understand.

In Fig. 1, the protocol between the  controller and programmable switch layer is  referred to as southbound;

northbound refers to  the upper part of the controller, including the  policy layer.  OpenFlow [10] is one of the most common  southbound SDN interfaces. Many vendors,  including HP, NEC, NetGear, and IBM, produce  OpenFlow-capable network switches available  in the market. The Open Networking  Foundation (ONF) is responsible for standardizing  the OpenFlow protocol. There are a variety  of OpenFlow controllers, for example, NOX [7],  Floodlight, and Maestro [1]. NOX is a framework  that allows developers to program their  software program with C++ or Python, using a  set of application programming interfaces (APIs)  to interact with OpenFlow-capable switches,  while Floodlight is a Java-based controller. Maestro  focuses on achieving better performance  and scalability in a centralized controller using  multithreading. 

Although there has been much study and  industrial effort in defining, polishing, and  implementing the southbound part of SDN protocols,  there has been relatively little attention  on northbound interfaces and protocols. Procera  is one effort to define a northbound interface  that provides the ability to specify and implement  reactive policies.

previous  network control systems 软件定义的网络起源于以前的网络控制系统

southbound interface  南向接口是指可编程交换机（支持SDN的交换机）与软件控制器之间的接口和协议

northbound  interface 北向接口决定了如何表达操作任务和网络策略，以及如何将它们转换成控制器可以理解的形式

尽管在定义、完善和实现SDN协议的南向部分方面已经有了大量的研究和工业努力，但对北向接口和协议的关注相对较少。

provides the ability to specify and implement  reactive policies Procera致力于定义一个北向接口，该接口提供指定和实现响应策略的能力

3.PROCERA：

Procera is a network control framework that  helps operators express event-driven network  policies that react to various types of events  using a high-level functional programming language.  Procera effectively serves as a glue  between high-level event-driven network policies  and low-level network configuration.  To express event-driven network policies,  Procera offers a set of control domains that  operators can use to set certain conditions and  assign appropriate packet forwarding actions  corresponding to each condition. Additional  control domains can help operators implement  flexible, reactive network policies. Operators can  also combine control domains to implement rich  network policies, instead of relying on time or  event-triggered scripts, which are error-prone.

The set of control domains Procera supports are  summarized in Table 1

 

 

We do not claim that  the current set of control domains is complete,  but it is sufficient to support a range of network policies in different types of network environments  that are difficult to implement in conventional  configuration languages

• Time: Network operators often need to implement  policies where network behavior depends  on the date or time of day. For example, a campus  network operator may want to manage traffic  differently in semester breaks when traffic  loads are lower than they are during the academic  year. In a home network, users might  want to use the time of day as the basis for  parental control. 
• Data usage: Operators sometimes specify  policies whereby the behavior of the network  depends on the amount of data usage (download/upload)  or data transfer rate over a particular  time interval. 
• Status: An operator may wish to specify privileges  for different users or groups of users.  Moreover, a user’s privilege or status often  changes due to various reasons. A device’s privilege  should change according to the user who is  currently using the device. 
• Flow: Network operators want to specify different  network behaviors based on various field  values in multiple layers, specified in a packet or  flow. A flow is a 12-tuple control domain that  already exists in the OpenFlow specification

Figure 2 shows the Procera architecture. We  elaborate（详细说明） on each component in the following  subsections

 

 

EVENT SOURCES

Event sources are network components or middleboxes  that can send dynamic events to the  Procera controller. Intrusion detection systems,  network bandwidth monitoring systems, and  authentication systems are good examples of  event sources. Simple Network Management  Protocol (SNMP) or even values in /proc can  be good event sources as well. As long as there  is a parser in the policy engine component that  understands such events, any kind of event can  be raised.  We do not define a fixed interface protocol  between event sources and the policy engine,  and there can be various alternative methods,  such as JSON-RPC. Currently, as a proof of  concept, event sources in our deployment periodically  send files that contain relevant information,  such as the bandwidth usage of every  end-host device, along with timestamps.

POLICY ENGINE AND LANGUAGE

The policy engine component is responsible for  parsing the network policy expressed with a policy  language, and also processing various events  that come from event sources. Based on the  given policy language and asynchronous events,  the policy engine refreshes its policy state, which  defines the network policy to be enforced, and  sends the policy functions to the network controller  when the policy state changes. Some reactive  policies change the policy state simply  according to changes in the time of day, without  any external event; the policy language supports  these types of reactive changes.  The Procera policy language is based on functional  reactive programming (FRP). It allows  operators to specify complex and reactive network  policies in a simple and declarative language.  The policy is an embedded  domain-specific language in Haskell. Due to  scope and page limitations, we do not include  details on our policy language in this article;  more details are in a work paper on Procera

NETWORK CONTROLLER

Procera follows the software defined networking  paradigm, and thus has a controller that makes  all traffic forwarding decisions and updates lowlevel  network switch flow-table entries according  to this policy. The network controller translates  the network policy to actual packet forwarding  rules. The network controller establishes a connection  to each OpenFlow-capable switch through the OpenFlow protocol [10], and inserts,  deletes, or modifies packet forwarding rules in  switches through this connection. The network  controller also reacts to packet-in events and  switch-join events that come from switches. For  packet-in events, the network controller will  install relevant forwarding rules in the switch,  and for switch-join events, it will establish a new  connection with that specific switch. Currently,  Procera uses OpenFlow specification version  1.0.0.

event-driven network  policies Procera是一个网络控制框架，它帮助运营商表达事件驱动的网络策略

high-level functional programming language 这些策略使用高级函数式编程语言，对各种类型的事件作出反应

a set of control domains Procera提供了一组控制域，操作员可以使用这些域来设置特定条件，并根据每个条件分配适当的包转发操作

一组控制域：

• Time 网络运营商通常需要实施网络行为取决于一天中的日期或时间的策略
• Data usage 运营商有时会指定策略，根据该策略，网络的行为取决于特定时间间隔内的数据使用量（下载/上载）或数据传输速率
• Status 操作员可能希望为不同的用户或用户组指定权限
• Flow 网络运营商希望根据数据包或流中指定的多层中的不同字段值指定不同的网络行为

EVENT SOURCES 事件源是可以向PROCER控制器发送动态事件的网络组件或中间包

POLICY ENGINE AND LANGUAGE 策略引擎组件负责解析用策略语言表示的网络策略，并处理来自事件源的各种事件

NETWORK CONTROLLER Procera遵循软件定义的网络模式，因此有一个控制器，根据该策略做出所有流量转发决策并更新低级网络交换机流表条目

4.CAMPUS NETWORK DEPLOYMENT

We describe the deployment of Procera in a  campus network. Campus networks are dynamic  environments with many events occurring across  the network. Network policies for campus and  enterprise networks are very complex and thus  error-prone, which makes them a good subject  for deploying Procera.

The Georgia Tech campus network requires  every unregistered end-host device to undergo  an authentication process via an authentication  web portal. After successful authentication with  a username and password, the device is scanned  for possible vulnerabilities. If none are found,  the device is finally granted access to the internal  network and the Internet. This simplified  version of the actual network policy still involves  a complex mechanism that requires input from  multiple external tools. In particular, the Georgia  Tech campus network relies on virtual LAN  (VLAN) technology, where unregistered and  registered devices are separated by different  VLAN domains. Based on the authentication  and scanning results, devices are moved back  and forth from two different VLAN domains,  and network switches deployed in the network  have to constantly download the up-to-date  VLAN map from the central VLAN management  server (VMPS) to perform correct forwarding  behavior

Implementing such complex and reactive network  policy with static tools like firewall rules  and VLAN technology requires network operators  to independently configure multiple different  components, including middleboxes,  management servers, and numerous ad hoc  scripts. Procera significantly simplifies the  expression of these types of policies

POLICY

Figure 3 shows the Georgia Tech campus network  policy in terms of a state machine model.

 

The policy can be expressed elegantly with events  and transitions among different states. User  devices in unauthenticated state cannot access the  network. Successful authentication with credentials  (username and password) moves a device to  scanning state, where only traffic between the  vulnerability scanner is allowed. After no known  vulnerabilities are found, a device can transition  to the authentication state where the device is  finally granted full access to the network. Any  infection event from an intrusion detection system  can move the device state to limited, where  access to the network and Internet access are  blocked. After five hours of inactivity, the user is  required to authenticate again.

DEPLOYMENT STATUS

Our campus deployment spans three buildings in  the Georgia Tech campus, as shown in Fig. 4.

 

For packet forwarding, we use five OpenFlowcapable  network switches from HP, NEC, and  Toroki. There are two wireless access points  deployed in building 3, through which end-host  devices can connect to through a broadcasted  SSID. The authentication web portal, intrusion  detection system, and scanner, which are event  sources, are located in the data closet in building  2.

dynamic  environments 校园网是一个动态的环境，网络上发生着许多事件，网络策略非常复杂且容易出错

乔治亚理工大学校园网要求每个未注册的终端主机设备通过认证门户进行认证过程。使用用户名和密码成功进行身份验证后，将扫描设备是否存在可能的漏洞。如果没有找到，设备最终被授予访问内部网络和Internet的权限。

requires input from  multiple external tools 实际网络策略的这个简化版本仍然包含一个复杂的机制，需要来自多个外部工具的输入，而Procera大大简化了这些类型策略的表达

5.HOME NETWORK DEPLOYMENTS：

We describe the deployment of Procera in home networks, and how Procera makes it easier to express various types of policies

IMPROVING VISIBILITY: BISMARK

One of the problems about home networks is  that they offer only limited visibility into home  broadband performance and its overall status.  Measurements performed by individual users  with browser-based tools like speedtest.net  provide limited one-time measurement results,which are likely influenced by many different  factors, such as browser type or host computer  condition. Access Internet service providers  (ISPs) often want to continuously monitor the  status of home networks, and ensure that customers  receive their promised service. Content  providers may desire to know how their traffic  engineering decisions influence the home user  experience.  BISmark is a collection of home gateways  installed in households, a centralized management  and data collection server, and multiple  measurement servers deployed around the world.  The home gateway performs various types of  active and passive measurements, which are collected  in the centralized management and data  collection server for further analysis. As of  November 2012, there were around 270 active  BISmark gateways deployed around the world.  Periodic active and passive measurement results  can be used to validate (or invalidate) certain  expectations of home networks, and also reveal  interesting findings in our Internet [11].

IMPROVING CONTROL: SDN

limited visibility 家庭网络的一个问题是，它们只能提供有限的家庭宽带性能及其整体状况的可见性。

BISmark 这是一种安装在家庭中的家庭网关、集中管理和数据收集服务器以及部署在世界各地的多个测量服务器的集合

various types of  active and passive measurements 家庭网关执行各种类型的主动和被动测量，这些测量被收集在集中管理和数据收集服务器中以供进一步分析