基于OpenFlow的未来互联网试验技术研究

合集下载

SDN软件定义网络

软件定义网络软件定义网络（Software Defined Network, SDN ），是一种新型网络创新架构，其核心技术OpenFlow通过将网络设备控制面与数据面分离开来，从而实现了网络流量的灵活控制，为核心网络及应用的创新提供了良好的平台。

SDN诞生于美国GENI项目资助的斯坦福大学Clean Slate课题，斯坦福大学Nick McKeown教授为首的研究团队提出了Openflow的概念用于校园网络的试验创新，后续基于Openflow给网络带来可编程的特性，SDN的概念应运而生。

2006年，SDN诞生于美国GENI项目资助的斯坦福大学Clean Slate课题。

Clean Slate项目的最终目的是要重新发明英特网，旨在改变设计已略显不合时宜，且难以进化发展的现有网络基础架构。

2007年，斯坦福大学的学生Martin Casado 领导了一个关于网络安全与管理的项目Ethane，该项目试图通过一个集中式的控制器，让网络管理员可以方便地定义基于网络流的安全控制策略，并将这些安全策略应用到各种网络设备中，从而实现对整个网络通讯的安全控制。

2008年，基于Ethane 及其前续项目Sane的启发， Nick McKeown 教授等人提出了OpenFlow 的概念，并于当年在ACM SIGCOMM 发表了题为《OpenFlow: Enabling Innovation in Campus Networks》的论文，首次详细地介绍了OpenFlow 的概念。

该篇论文除了阐述OpenFlow 的工作原理外，还列举了OpenFlow 几大应用场景。

基于OpenFlow 为网络带来的可编程的特性，Nick McKeown教授和他的团队进一步提出了SDN（Software Defined Network，软件定义网络）的概念。

2009年，SDN 概念入围Technology Review年度十大前沿技术，自此获得了学术界和工业界的广泛认可和大力支持。

Openflow新型网络交换模型

Openflow新型网络交换模型——校园网络的创新1.互联网的现状互联网的应用迅速发展, 由于一开始的设计并没有考虑到后来互联网的规模会如此庞大、承载的应用会如此复杂、地位会变得如此重要，现代的互联网在过重的压力下已经凸显出太多亟待解决的问题:互联网太危险，恶意攻击、病毒、木马每年造成上千亿刀的损失;互联网太脆弱，无标度(Scale-free)的特性让整个网络可以在精心设计的少数攻击下即告崩溃;互联网太随意，p2p等应用的出现一度造成各大ISP网络堵塞，严重影响传统正常的访问;互联网太迟钝，现代臃肿的路由机制不能支持快速的更新，即便发现问题也无法快速反应。

运营商只得忙于扩容。

这一切的问题都隐隐的指向了互联网这个庞然大物最关键的软肋——可控性。

缺乏有效的控制措施让互联网这个为服务人类而设计的机器。

因此，业界希望能够有提高网络有效性的机制出现，目前学术界斯坦福大学、伯克利大学、麻省理工学院等牵头的研究组正在推动OpenFlow技术的发展。

2.openflow应运而生2006年到2014年分三个阶段主要致力于五个问题：是否继续采用分组交换、是否要改变端对端原理、是否要分开路由和包转发、拥塞控制跟资源管理、身份认证和路由问题。

FIND计划最主要的成果之一就是GENI——一套网络研究的基础平台OpenFlow的前世今生很自然的想法，如果我能控制整个Internet就好了，而网络中最关键的节点就是交换设备。

控制了交换设备就如同控制了城市交通系统中的红绿灯一样，所有的流量就可以乖乖听话，为我所用。

所以，自然而然的想法诞生，如果能有一套开放接口、支持控制的交换标准该多好?无论是交换机还是路由器，最核心的信息都存放在所谓的flow table里面，用来实现各种各样的功能，诸如转发、统计、过滤等。

flow table结构的设计很大程度上体现了各个厂家的独特风格。

OpenFlow就是试图提出这样一个通用的flow table设计，能够满足大家不同的需求，同时这个flow table支持远程的访问和控制，从而达到控制流量的目的。

浅谈SDN—软件定义网络与OpenFlow技术

浅谈SDN—软件定义网络与OpenFlow技术SDN（Software Defined Networking）是一种网络架构，其中网络控制平面和数据平面被分离，网络控制变得可编程化，数据平面提供灵活的网络服务。

SDN的出现解决了传统网络在复杂性、创新性和管理方面的局限性，为网络设备提供了更大的灵活性和可编程性。

SDN可以被视为一种分离网络域的方法，它将传统网络中紧密耦合的网络控制功能与数据转发分离开来，并将控制平面中的网络政策转移到集中的控制器中。

本文主要介绍SDN的概念、技术特点及其组成部分OpenFlow的作用。

一、SDN的概念和附加值SDN的概念源于硬件变得更加可编程化和网络变得更加复杂的需要。

软件定义网络（SDN）通过将网络控制和数据转发分离来实现。

SDN提供了许多附加值，包括但不限于：1.更好的网络控制SDN允许网络管理员在控制平面中实现更好的网络控制和定制，这可以让管理员更好地管理其网络。

SDN的控制器可以编写新的控制类别或插件，以添加新的网络控制操作并自动化，简化网络管理。

2.更好的网络管理SDN降低了网络管理成本，通过集中的控制器来全面监控网络和流量，简化了管理。

不仅消除了对每个硬件设备的母鸡控制器的需求，而且还提供了更好的网络可视化和更好的流量控制。

3.更好的性能SDN通过编程协议转发数据平面，可以通过实现更好的负载均衡和流量工程，同时获得更好的网络性能。

控制器可以在多个控制平面上实现负载均衡和流量工程，从而更快地响应发生的网络事件。

4.更好的安全SDN提供了更好的网络安全，因为控制器可以在网络上保护网络的指定岗位。

例如，控制器可以自动防止攻击或不常见的流量模式，防止入侵并建立更强大的网络安全。

二、SDN的技术特点1.中央控制器SDN中的中央控制器是网络的枢纽。

它确保与所有的SDN设备通信并处理网络事件。

控制器可以根据不同的策略和流量工程来修改网络，可以实现更复杂的网络控制。

2.网络流SDN中的网络流是需要交换的数据包，这些数据包可能会按照不同的路径在网络中流动。

基于OpenFlow的未来互联网试验网

２０１３年第２２卷第５期
ｈｔｔｐ：／／ｗｗｗ．ｃ・Ｓ－ａ．ｏｒｇ．ｃｎ
计算机系统应用
基于ＯｐｅｎＦｌｏｗ的未来互联网试验网①
韦世红。卢威
（重庆邮电大学通信与信息工程学院，重庆４０００６５）
（Ｃｏｎｔｒｏｌｌｅｒ）来共同完成，实现了数据转发和路由控制的分离．控制器可以通过事先规定好的接口操作来控制ＯｐｅｎＦｌｏｗ交换机中的流表，从而达到控制数据转
摘要：ＯｐｅｎＦｏｗ是为支持互联网创新研究而提出的基于流分类的新型网络试验技术，以ＯｐｅｎＦｌｏｗ为研究对象，
在ｍｉｎｉｎｅｔ测试平台下，利用ＯｐｅｎｖＳｗｉｔｃｈ交换机搭建虚拟交换试验网络模型，并进行了简单测试，从而为未来互联网试验创新技术的分析和研究提供便利．关键词：未来互联网：ＯｐｅｎＦｌｏｗ；网络创新；虚拟交换机
Ａｂｓｔｒａｃｔ：ＯｐｅｎＦｌｏｗ，ｐｕｔｆｏｒｗａｒｄｅｄｔｏｍｅｅｔｔｈｅｒｅｑｕｉｒｅｍｅｎｔｏｆＩｎｔｅｒｎｅｔｉｎｎｏｖａｔｉｏｎｒｅｓｅａｒｃｈ，ｉｓａｎｅｗｎｅｔｗｏｒｋｔｅｓｔ
ｎｅｔｗｏｒｋｔｅｓｔｍｏｄｅｌｉｎｈｅｔｍｉｎｉｎｅｔｔｅｓｔｐｌａｔｆｏｒｍｂｙｕｔｉｌｉｚｉｎｇｔｈｅＯｐｅｎｖＳｗｉｔｃｈｖｉｒｔｕａｌｍａｃｈｉｎｅ．Ｗｈａｔ ’ Ｓｍｏｒｅ，ｗｅａｌｓｏｄｏ

OpenFlow Enabling Innovation in Campus Network以及中文翻译

附录A 外文原文OpenFlow: Enabling Innovation in Campus NetworksNick McKeown Stanford University Guru Parulkar Stanford UniversityTom AndersonUniversity of WashingtonLarry PetersonPrinceton UniversityHari BalakrishnanMITJennifer RexfordPrinceton UniversityScott Shenker University of California,BerkeleyJonathan Turner Washington University inSt. LouisThis article is an editorial note submitted to CCR. It has NOT been peer reviewed.Authors take full responsibility for this article’s technical ments can be posted through CCR Online.ABSTRACTThis whitepaper proposes OpenFlow: a way for researchers to run experimental protocols in the networks they use every day. OpenFlow is based on an Ethernet switch, with an internal ﬂow-table, and a standardized interface to add and remove ﬂow entries. Our goal is to encourage networking vendors to add OpenFlow to their switch products for deployment in college campus backbones and wiring closets. We believe that OpenFlow is a pragmatic compromise: on one hand, it allows researchers to run experiments on heterogeneous switches in a uniform way at line-rate and with high port-density; while on the other hand, vendors do not need to expose the internal workings of their switches. In addition to allowing researchers to evaluate their ideas in real-world traffic settings, OpenFlow could serve as a useful campus component in proposed large-scale testbeds like GENI. Two buildingsat Stanford University will soon run OpenFlow networks, using commercial Ethernet switches and routers. We will work to encourage deployment at other schools; and we encourage you to consider deploying OpenFlow in your university network too.Categories and Subject DescriptorsC.2 [Internetworking]: RoutersGeneral TermsExperimentation, DesignKeywordsEthernet switch, virtualization, flow-based1. THE NEED FOR PROGRAMMABLE NETWORKSNetworks have become part of the critical infrastructure of our businesses, homes and schools. This success has been both a blessing and a curse for networking researchers; their work is more relevant, but their chance of making an impact is more remote. The reduction in real-world impact of any given network innovation is because the enormous installed base of equipment and protocols, and the reluctance to experiment with production traffic, which have created an exceedingly high barrier to entry for new ideas. Today, there is almost no practical way to experiment with new network protocols (e.g., new routing protocols, or alternatives to IP) in sufficiently realistic settings (e.g., at scale carrying real traffi c) to gain the conﬁdence needed for their widespread deployment. The result is that most new ideas from the networking research community go untried and untested; hence the commonly held belief that the network infrastructure has “ossiﬁed”.Having recognized the problem, the networking community is hard at work developing programmable networks, such as GENI [1] a proposed nationwide research facility for experimenting with new network architectures and distributed systems. These programmable networks call for programmable switches and routers that (using virtualization) can process packets for multiple isolated experimental networks simultaneously. For example, in GENI it is envisaged that a researcher will be allocated a slice of resources across the whole network, consisting of a portion of network links, packet processing elements (e.g. routers) and end-hosts; researchers program their slices to behave as they wish. A slice could extend across the backbone, into access networks, into college campuses, industrial research labs, and include wiring closets, wireless networks, and sensor networks.Virtualized programmable networks could lower the barrier to entry for new ideas, increasing the rate of innovation in the network infrastructure. But the plans for nationwide facilities are ambitious (and costly), and it will take years for them to be deployed.This whitepaper focuses on a shorter-term question closer to home: As researchers, how can we run experiments in our campus networks? If we can ﬁgure out how, we can start soon and extend the technique to other campuses to beneﬁt the whole community.To meet this challenge, several questions need answering, including: In the early days, how will college network administrators get comfortable putting experimental equipment (switches, routers, access points, etc.) into their network? How will researchers control a portion of their local network in a way that does not disrupt others who depend on it? And exactly whatfunctionality is needed in network switches to enable experiments? Our goal here is to propose a new switch feature that can help extend programmability into the wiring closet of college campuses.One approach -that we do not take -is to persuade commercial “name-brand” equipment vendors to provide an open, programmable, virtualized platform on their switches and routers so that researchers can deploy new protocols, while network administrators can take comfort that the equipment is well supported. This outcome is very unlikely in the short-term. Commercial switches and routers do not typically provide an open software platform, let alone provide a means to virtualize either their hardware or software. The practice of commercial networking is that the standardized external interfaces are narrow (i.e., just packet forward ing), and all of the switch’s internalﬂexibility is hidde n. The internals differ from vendor to vendor, with no standard platform for researchers to experiment with new ideas. Further, network equipment vendors are understandably nervous about opening up interfaces inside their boxes: they have spent years deploying and tuning fragile distributed protocols and algorithms, and they fear that new experiments will bring networks crashing down. And, of course, open platforms lower the barrier-to-entry for new competitors.A few open software platforms already exist, but do not have the performance or port-density we need. The simplest example is a PC with several network interfaces and an operating system. All well-known operating systems support routing of packets between interfaces, and open-source implementations of routing protocols exist (e.g., as part of the Linux distribution, or from XORP [2]); and in most cases it is possible to modify theoperating system to process packets in almost any manner (e.g., using Click [3]). The problem, of course, is performance: A PC can neither support the number of ports needed for a college wiring closet (a fan out of 100+ ports is needed per box), nor the packet-processing performance (wiring closet switches process over 100Gbits/s of data, whereas a typical PC struggles to exceed 1Gbit/s; and the gap between the two is widening).Existing platforms with specialized hardware for line-rate processing are not quite suitable for college wiring closets either. For example, an ATCA-based virtualized programmable router called the Supercharged Planet Lab Platform [4] is under development at Washington University, and can use network processors to process packets from many interfaces simultaneously at line-rate. This approach is promising in the long-term, but for the time being is targeted at large switching centers and is too expensive for widespread deployment in college wiring closets. At the other extreme is NetFPGA [5] targeted for use in teaching and research labs. NetFPGA is a low-cost PCI card with a user-programmable FPGA for processing packets, and 4 ports of Gigabit Ethernet. NetFPGA is limited to just four network interfaces—insufficient for use in a wiring closet.Thus, the commercial solutio ns are too closed and inﬂex ible and the research solutions either have insufficient performance or fan out, or are too expensive. It seems unlikely that the research solutions, with their complete generality, can overcome their performance or cost limitations. A more promising approach is to compromise on generality and to seek a degree of switch flexibility that is:Figure 1 Idealized OpenFlow Switch. The Flow Table is controlled by a remote controllervia the Secure Channel.•Amenable to high-performance and low-cost implementations.•Capable of supporting a broad range of research.•Assured to isolate experimental traffic from production traffic. •Consistent with vendors’ need for closed platforms.This paper describes the OpenFlow Switch—a specification that is an initial attempt to meet these four goals.2. THE OPENFLOW SWITCHThe basic idea is simple: we exploit the fact that most modern Ethernet switches and routers contain ﬂow-tables (typically built from TCAMs) that run at line-rate to im plement ﬁrewalls, NAT, QoS, and to collect statistics. While each vendor’s ﬂow-table is diﬀerent, we’ve identiﬁed an interesting common set of functions that run in many switches and routers. OpenFlow exploits this common set of functions.OpenFlow provides an open protocol to program the ﬂow-table in diﬀerent switches and routers. A network administrator can partition traﬃc into production and research ﬂows. Researchers can control their own ﬂows -by choosing the routes their packets follow and the processing they receive. Inthis way, researchers can try new routing protocols, security models, addressing schemes, and even alternatives to IP. On the same network, the production traﬃc is isolated and processed in the same way as today.The datapath of an OpenFlow Switch consists of a Flow Table, and an action associated with each ﬂow entry. The set of actions supported by an OpenFlow Switch is extensible, but below we describe a minimum requirement for all switches. For high-performance and low-cost the data-path must have a carefully prescribed degree of ﬂexibility. This means forgoing the ability to specify arbitrary handling of each packet and seeking a more limited, but still useful, range of actions. Therefore, later in the pape r, deﬁne a basic required set of actions for all OpenFlow switches.An OpenFlow Switch consists of at least three parts: (1) A Flow Table, with an action associated with each ﬂow entry, to tell the switch how to process the ﬂow, (2) A Secure Channel that connects the switch to a remote control process (called the controller), allowing commands and packets to be sent between a controller and the switch using (3) The OpenFlow Protocol, which provides an open and standard way for a controller to communicate with a switch. By specifying a standard interface (the OpenFlow Protocol) through which entries in the Flow Table can be deﬁned externally, the OpenFlow Switch avoids the need for researchers to program the switch.It is useful to categorize switches into dedicated OpenFlow switches that do not support normal Layer 2 and Layer 3 processing, and OpenFlow-enabled general purpose commercial Ethernet switches and routers, to which the Open-Flow Protocol and interfaces have been added as a new feature.Dedicated OpenFlow switches. A dedicated OpenFlow Switch is a dumb datapath element that forwards packets between ports, as deﬁned b y a remote control process. Figure 1 shows an example of an OpenFlow Switch.In this context, ﬂows are broadly deﬁned, and are limit ed only by the capabilities of the particular implementation of the Flow Table. For example, a ﬂow could be a TCP con nection, or all packets from a particular MAC address or IP address, or all packets with the same VLAN tag, or all packets from the same switch port. For experiments involving non-IPv4 packets, a ﬂow could be deﬁned as all packets matching a speciﬁc (but non-standard) header.Each ﬂow-entry has a simple action associated with it; the three basic ones (that all dedicated OpenFlow switches must support) are:1 Forward this ﬂow’s packets to a given port (or ports). This allows packets to be routed through the network. In most switches this is expected to take place at line-rate.2 Encapsulate and forw ard this ﬂow’s packets to a con troller. Packet is delivered to Secure Channel, where it is encapsulated and sent to a controller. Typically used for the ﬁrst packet in a new ﬂow, so a controller can decide if the ﬂow should be added to the Flow Table. Or in some experiments, it could be used to forward all packets to a controller for processing.3 Drop this ﬂow’s packets. Can be used for security, to curb denial of service attacks, or to reduce spurious broadcast discovery traffic from end-hosts.An entry in the Flow-Table has three ﬁelds: (1) A packet header that deﬁnes the ﬂow, (2) The action, which deﬁnes how the packets should be processed, and (3) Statistics, which keep track of the number of packets and bytes foreach ﬂow, and the time since the last packet matched the ﬂow (to help with the removal of inactive ﬂows).In the ﬁrst generation “Type 0” switches, the ﬂow header is a 10-tuple shown in T able 1. A TCP ﬂow could be speciﬁed by all ten ﬁelds, whereas an IP ﬂow might not include the transport ports in its deﬁnition. Each header ﬁeld can be a wildcard to allow for aggregation of ﬂows, such as ﬂows in which only the VLAN ID is deﬁned would apply to all traﬃc on a particular VLAN.Table 1 The header ﬁelds matched in a “Type 0” OpenFlow switch.The detailed requirements of an OpenFlow Switch are defined by the OpenFlow Switch Specification [6].OpenFlow-enabled switches. Some commercial switches, routers and access points will be enhanced with the OpenFlow feature by adding the Flow Table, Secure Channel and OpenFlow Protocol (we list some examples in Section 5). Typically, the Flow Table will re-use existing hardware, such as a TCAM; the Secure Channel and Proto col will be ported to run on the switch’s operating system. Figure 2 shows a network of OpenFlow-enabled commercial switches and access points. In this example, all the Flow Tables are managed by the same controller; the OpenFlow Protocol allows a switch to be controlled by two or more controllers for increased performance or robustness. Our goal is to enable experiments to take place in an existing production network alongside regular traﬃc and applications. Therefore, to win theconﬁdence of network administrators, OpenFlow-enabled switches must isolate experimental traﬃc (processed by the Flow Table) from productiontraﬃc that is to be processed by the normal Layer 2 and Layer 3 pipeline of the switch. There are two ways to achieve this separation. One is to add a fourth action:4. Forward this ﬂow’s packets through the switch’s nor mal processing pipeline.The other is to deﬁne separat e sets of VLANs for experimental and production traﬃc. Both approaches allow normal production traﬃc that isn’t part of an experiment to be processed in the usual way by the switch. All OpenFlow-enabled switches are required to support one approach or the other; some will support both.Additional features. If a switch supports the header formats and the four basic actions mentioned above (and detailed in the OpenFlow SwitchSpeciﬁcation), then we call it a “Type 0” switch. We expect that many switches will support additional actions, for example to rewrite portions of the packet header (e.g., for NAT, or to obfuscate addresses on intermediate links), and to map packets to a priority class. Likewise, some Flow Tables will be able to match on arbitrary ﬁelds in the packet header, enabling experiments with new non-IP protocols. As a particular set of features emerges, we willdeﬁne a “Type 1” switch.Controllers.A controller adds and removes ﬂow-entries from the Flow Table on behalf of experiments. For example, a static controller might be a simple application running on a PC to statica lly establish ﬂows to interconnect a set of test computers for the duration of an experiment. In this case the ﬂows resemble VLANs in current networks— providing a simple mechanism toisolate experimental traﬃc from the production network. Viewed this way, OpenFlow is a generalization of VLANs.One can also imagine more sophisticated controllers that dynamicallyadd/remove ﬂows as an experiment progresses. In one usage model, a researcher might control the complete network of OpenFlow Switches and be free to decide how all ﬂows are processed.Figure 2 Example of a network of OpenFlow-enabled commercial switches and routers.A more sophisticated controller might support multiple researchers, each with diﬀerent accounts and permissions, enabling them to run multiple independent experiments on diﬀerent sets of ﬂows. Flows identiﬁed as under the control of a particular researcher (e.g., by a policy table running in a controller) could be delivered to a researcher’s user-level control program which then decides if a new ﬂow-entry should be added to the network of switches.3. USING OPENFLOWAs a simple example of how an OpenFlow Switch might be used imagine that Amy (a researcher) invented Amy-OSPF as a new routing protocol toreplace OSPF. She wants to try her protocol in a network of OpenFlow Switches, without changing any end-host software. Amy-OSPF will run in a controller; each time a new application ﬂow starts Amy-OSPF picks a route through a series of OpenFlow Switches, and adds a ﬂow-entry in each switch along the path. In her experiment, Amy decides to use Amy-OSPF for thetraﬃc entering the OpenFlow network from her own desktop PC— so she doesn’t disrupt the network for others. To do this, she deﬁnes one ﬂow to be all the traﬃc entering the Open-Flow switch through the switch port her PC is connected to, and adds a ﬂow-entry with the action “Enca psulate and forward all packets to a controller”. When her packets reach a controller, her new protocol chooses a route and adds a new ﬂow-entry (for the application ﬂow) to every switch along the chosen path. When subsequent packets arrive at a switch, they are processed quickly (and at line-rate) by the Flow Table. There are legitimate questions to ask about the performance, reliability and scalability of a controller that dynam ically adds and removes ﬂows as an experiment progresses: Can such a centralized controller be fast enough to process new ﬂows and program the Flow Switches? What happens when a controller fails? To some extent these questions were addressed in the context of the Ethane prototype, which used simple ﬂow switches and a central controller [7]. Preliminary results suggested that an Ethane controller based on a low-cost desktop PC could process over 10,000 new ﬂows per second —enough for a large college campus. Of course, the rate at which ne w ﬂows can be processed will depend on the complexity of the processing required by the re searcher’s experiment. But it gives us conﬁdence that mean ingful experiments can be run. Scalability and redundancy are possible by making acontroller (and the experiments) stateless, allowing simple load-balancing over multiple separate devices.3.1 Experiments in a Production NetworkChances are, Amy is testing her new protocol in a network used by lots of other people. We therefore want the network to have two additional properties:1 Packets belonging to users other than Amy should be routed using a standard and tested routing protocol running in the switch or router from a “name-brand” v endor.2 Amy should only be able to add ﬂow entries for her traﬃc, or for any traﬃc her network administrator has allowed her to control.Property 1 is achieved by OpenFlow-enabled switches. In Amy’s experiment, the default action for all packets that don’t come from Amy’s PC could be to forward them through the normal processing pipeline. Amy’s own packets would be forwarded directly to the outgoing port, without being processed by the normal pipeline.Property 2 depends on the controller. The controller should be seen as a platform that enables researchers to implement various experiments, and the restrictions of Property 2 can be achieved with the appropriate use of permissions or other ways to limit the powers of individual researchers to control ﬂow e ntries. The exact nature of these permission-like mechanisms will depend on how the controller is implemented. We expect that a variety of controllers will emerge. As an example of a concrete realization of a controller, some of the authors are working on a controller called NOX as a follow-on to the Ethane work [8]. A quite diﬀerent controller might emerge by extending the GENI management software to OpenFlow networks.3.2 More ExamplesAs with any experimental platform, the set of experiments will exceed those we can think of up-front — most experiments in OpenFlow networks are yet to be thought of. Here, for illustration, we oﬀer some examples of how OpenFlow-enabled networks could be used to experiment with new network applications and architectures.Example 1: Network Management and Access Con trol. We’ll use Ethane as our ﬁrst example [7] as it was the research that inspired OpenFlow. In fact, an OpenFlow Switch can be thought of as a generalization of Ethane’s datapath switch. Ethane used a speciﬁc implementation of a controller, suited for network management and control, that manages the admittance and routing of ﬂows. The basic idea of Ethane is to allow network managers to deﬁne a network-wide policy in the central controller, which is enforced directly by making admission control decisions for each new ﬂow. A controller checks a new ﬂow against a set of rules, such as “Guests can communicate using HTTP, but only via a web proxy” or “VoIP phones are not allowed to communicate with laptops.” A controller associates pack ets with their senders by managing all the bindings between names and addresses — it essentially takes over DNS, DHCP and authenticates all users when they join, keeping track of which switch port (or access point) they are connected to. One could envisage an extension to Ethane in which a policy dictates that particular ﬂows are sent to a user’s process in a controller, hence allowing researcher-speciﬁc processing to be performed in the network.Example 2: VLANs. OpenFlow can easily provide users with their own isolated network, just as VLANs do. The simplest approach is to statically declare a set of ﬂows which specify the ports accessible by traﬃc on a givenVLAN ID. Traﬃc identiﬁed as coming from a single user (for example, originating from speciﬁc switch ports or MAC addresses) is tagged by the switches (via an action) with the appropriate VLAN ID.A more dynamic approach might use a controller to manage authentication of users and use the knowledge of the users’ locations for tagging traﬃc at runtime.Example 3: Mobile wireless VOIP clients. For this example consider an experiment of a new call-handoﬀ mechanism for WiFi-enabled phones. In the experiment VOIP clients establish a new connection over the OpenFlow-enabled network. A controller is implemented to track the location of clients, re-routing connections — by reprogramming the Flow Tables — as users move through the network, allowing seamless handoﬀ from one access point to another.Example 4: A non-IP network. So far, our examples have assumed an IP network, but OpenFlow doesn’t require packets to be of any one format — so long as the Flow Table is able to match on the packet header. This would allow experiments using new naming, addressing and routing schemes. There are several ways an OpenFlow-enabled switch can support non-IP traﬃc. For example, ﬂows could be identiﬁed using their Ethernet header (MAC src and dst addresses), a new EtherType value, or at the IP level, by a new IP Version number. More generally, we hope that future switches will allow a controller to create a generic mask (oﬀset + value + mask), allowing packets to be processed in a researcher-speciﬁed way.Example 5: Processing packets rather than ﬂows.The examples above are for experiments involving ﬂows — where a controller makes decisions when the ﬂow starts. There are, of course, interesting experiments to be performed that require every packet to be processed. For example, an intrusion detection system that inspects every packet, an explicit congestion control mechanism, or when modifying the contents of packets, such as when converting packets from one protocol format to another.Figure 3: Example of processing packets through anexternal line-rate packet-processing device, such as a programmable NetFPGA router.There are two basic ways to process packets in an OpenFlow-enabled network. First, and simplest, is to force all of a ﬂow’s packets to pass t hrough a controller. To do this, a controller doesn’t add a new ﬂow entry into the Flow Switch — it just allows the switch to default to forwarding every packet to a controller. This has the advantage of ﬂexibility, at the cost of performance. It might provide a useful way to test the functionality of a new protocol, but is unlikely to be of much interest for deployment in a large network.The second way to process packets is to route them to a programmable switch that does packet processing — for example, a NetFPGA-based programmable router. The advantage is that the packets can be processed at line-rate in a user-deﬁnable way; Figure 3 shows an example of how this could be done, in which the OpenFlow-enabled switch operates essentially as a patch-panel to allow the packets to reach the NetFPGA. In some cases, the NetFPGA board (a PCI board that plugs into a Linux PC) might be placed in the wiring closet alongside the OpenFlow-enabled switch, or (more likely) in a laboratory.4. THE OPENFLOW CONSORTIUMThe OpenFlow Consortium aims to popularize OpenFlow and maintain the OpenFl ow Switch Speciﬁcation. The Con sortium is a group of researchers and network administrators at universities and colleges who believe their research mission will be enhanced if OpenFlow-enabled switches are installed in their network.Membership is open and free for anyone at a school, college, university, or government agency worldwide. The OpenFlow Consortium welcomes individual members who are not employed by companies that manufacture or sell Ethernet switches, routers or wireless access points (because we want to keep the consortium free of vendor inﬂuence). To join, send email to***********************.The Consortium web-site contain s the OpenFlow Switch Speciﬁcation, a list of consortium members, and reference implementations of OpenFlow switches.Licensing Model: The OpenFlow Switch Speciﬁcation is free for all commercial and non-commercial use. (The exact wording is on the web-site.) Commercial switches and routers claiming to be “OpenFlow-enabled” must conform to the requirements of an OpenFlow Type 0 Switch, as deﬁned in the OpenFlow Switch Speciﬁcation. OpenFlow is a trademark of Stanford University, and will be protected on behalf of the Consortium.5. DEPLOYING OPENFLOW SWITCHESWe believe there is an interesting market opportunity for network equipment vendors to sell OpenFlow-enabled switches to the research community. Every building in thousands of colleges and universities contains wiring closets with Ethernet switches and routers, and with wireless access points spread across campus.We are actively working with several switch and router manufacturers who are adding the OpenFlow feature to their products by implementing a Flow Table in existing hardware; i.e. no hardware change is needed. The switches run the Secure Channel software on their existing processor.We have found network equipment vendors to be very open to the idea of adding the OpenFlow feature. Most vendors would like to support the research community without having to expose the internal workings of their products. We are deploying large OpenFlow networks in the Computer Science and Electrical Engineering departments at Stanford University. The networks in two buildings will be replaced by switches running OpenFlow. Eventually, all traﬃc will run over the OpenFlow network, with production traﬃc and experimental traﬃc being isolated on different VLANs under the control of。

openflow协议的工作原理与流程

openflow协议的工作原理与流程OpenFlow协议是一种新型的网络交换协议，它可以让管理者灵活地定义网络中的流行行为，为网络开发者提供更大的灵活性。

Openflow协议于2008年被Stanford University首次发布，经过近十年的发展，它已经成为一种流行的网络交换协议，被广泛应用于云计算和虚拟化网络中。

OpenFlow协议的核心是一种分布式控制器，该控制器可以与网络中的多个设备进行交互，包括交换机、路由器、防火墙和NAT设备等。

OpenFlow协议允许管理员灵活地控制网络中的流量，而无需重新设计网络架构，从而实现网络的自动化管理和安全性。

OpenFlow协议的工作原理是每一个网络设备（如交换机）建立一个控制连接，通过控制连接与控制器进行通信。

OpenFlow协议下的每一个网络设备都会发出报文，该报文中包含发送者、接收者、以及传输内容，以发送到控制器上。

控制器在收到报文后，会根据规则匹配和决策，并将控制指令下发到接收设备上，以实现网络中的流量控制。

OpenFlow协议的工作流程可以分为四个主要的步骤：1.网络设备发出报文：网络设备发出的报文中包括流入报文源、流出报文目的地以及传输内容。

2.控制器接受报文：控制器收到报文后，会根据规则匹配和决策，然后将控制指令下发到接收设备上。

3.接收设备收到控制指令：接收设备收到来自控制器的控制指令后，会根据控制指令重新定向流量，以实现流量控制。

4.网络流量控制：网络流量经过重新定向之后，即可实现对数据流的控制，从而提高网络的效率和安全性。

OpenFlow协议的出现标志着一种新的网络交换模式，可以让管理者灵活地定义网络的流行行为，具备更高的灵活性和更强的安全性，是网络管理技术革新的一个重要里程碑。

OpenFlow协议已经被广泛应用于虚拟化网络，云计算，SDN技术，它不仅能更好地满足企业和用户的需求，还能帮助管理者更加迅速、灵活、安全地管理网络。

下一代互联网体系结构研究现状和发展趋势

下一代互联网体系结构研究现状和发展趋势作者：吴建平李星刘莹来源：《中兴通讯技术》2011年第02期互联网已成为支撑现代社会发展及技术进步的重要的基础设施之一。

深刻地改变着人们的生产、生活和学习方式，成为支撑现代社会经济发展、社会进步和科技创新的最重要的基础设施。

互联网及其应用水平已经成为衡量一个国家基本国力和经济竞争力的重要标志之一。

随着超高速光通信、无线移动通信、高性能低成本计算和软件等技术的迅速发展，以及互联网创新应用的不断涌现，人们对互联网的规模、功能和性能等方面的需求越来越高。

三十多年前发明的以IPv4协议为核心技术的互联网面临着越来越严重的技术挑战，主要包括：网络地址不足，难以更大规模扩展；网络安全漏洞多，可信度不高；网络服务质量控制能力弱，不能保障高质量的网络服务；网络带宽和性能不能满足用户的需求；传统无线移动通信与互联网属于不同技术体制，难以实现高效的移动互联网等等。

为了应对这些技术挑战，美国等发达国家从20世纪90年代中期就先后开始下一代互联网研究。

中国科技人员于20世纪90年代后期开始下一代互联网研究。

目前，虽然基于IPv6协议的新一代互联网络的轮廓已经逐渐清晰，许多厂商已开始提供成熟的IPv6互联设备，大规模IPv6网络也正在建设并在迅速发展。

但是互联网络面临的基础理论问题并不会随着IPv6网络的应用而自然得到解决，相反，随着信息社会和正在逐渐形成的全球化知识经济形态对互联网络不断提出新的要求，更需要人们对现有的互联网络体系结构的基础理论进行新的思考和研究。

近年来国际上已经形成了两种发展下一代互联网的技术路线：一种是“演进性”路线，即在现有IPv4协议的互联网上不断“改良”和“完善”网络，最终平滑过渡到IPv6的互联网；另一种是“革命性”路线，以美国FIND／GENI项目为代表，即重新设计全新的互联网体系结构，满足未来互联网的发展需要。

本文首先介绍国际下一代互联网体系结构的研究现状，涉及美国和欧洲的GENIE、FIND、FIRE以及FIA等计划。

【转】OpenFlow是什么？OpenFlow和SDN之间是什么关系？

【转】OpenFlow是什么？OpenFlow和SDN之间是什么关系？前⾔OpenFlow 是⼀种⽹络通信协议，应⽤于 SDN 架构中控制器和转发器之间的通信。

软件定义⽹络 SDN 的⼀个核⼼思想就是“转发、控制分离”，要实现转、控分离，就需要在控制器与转发器之间建⽴⼀个通信接⼝标准，允许控制器直接访问和控制转发器的转发平⾯。

OpenFlow 引⼊了“流表”的概念，转发器通过流表来指导数据包的转发。

控制器正是通过 OpenFlow 提供的接⼝在转发器上部署相应的流表，从⽽实现对转发平⾯的控制。

OpenFlow 的起源与发展OpenFlow 起源于斯坦福⼤学的 Clean Slate 项⽬，该项⽬的⽬标是要“重塑互联⽹”，旨在改变设计已略显不合时宜，且难以进化发展的现有⽹络基础架构。

在 2006 年，斯坦福的学⽣ Martin Casado 领导了⼀个关于⽹络安全与管理的项⽬，试图通过⼀个集中式的控制器，让⽹络管理员⽅便地定义基于⽹络流的安全控制策略，并将这些安全策略应⽤到各种⽹络设备中，从⽽实现对整个⽹络通讯的安全控制。

受此项⽬启发，Clean Slate 项⽬的负责⼈ Nick McKeown 教授及其团队发现，如果将传统⽹络设备的数据转发和路由控制两个功能模块相分离，通过集中式的控制器（Controller）以标准化的接⼝对各种⽹络设备进⾏管理和配置，那么这将为⽹络资源的设计、管理和使⽤提供更多的可能性，从⽽更容易推动⽹络的⾰新与发展。

于是，他们便提出了 OpenFlow 的概念，并且于 2008 年发表了题为的论⽂，⾸次详细地介绍了 OpenFlow 的原理和应⽤场景。

2009 年，基于 OpenFlow，该研究团队进⼀步提出了 SDN（Software Defined Network，软件定义⽹络）的概念，引起了⾏业的⼴泛关注和重视。

2011 年，由Google、Facebook、微软等公司共同发起成⽴了⼀个对 SDN 影响深远的组织 ONF（Open Networking Foundation），致⼒于发展 SDN。

基于OpenFlow的网络感知管理方案设计

ＤｅｓｉｇｎｏｎＮｅｔｗｏｒｋＡｗａｒｅｎｅｓｓａｎｄＮｅｔｗｏｒｋＭａｎａｇｅｍｅｎｔＳ
Ｌ１Ｙａｎ—Ｇｕａｎ．ＸＵＹａｈ
ｆ１．Ｔｈｅ５４ｔｈＲｅｓｅａｒｃｈＩｎｓｔｉｔｕｔｅｏｆＣＥＴＣ，ＳｈｉｊｉａｚｈｕａｎｇＨｅｂｅｉ（Ｊ５（）Ｉ）８１，（＇ｈｉｎａ２．Ｕｎｉｔ６１９３２，ＰＬＡ，Ｂｅｉｊｉｎｇ１０００（１０，Ｃｈｉｎａ）
基于ＯｐｅｎＦｌｏｗ的网络感知管理方案设计
李艳冠。，徐艳
（１．中国电子科技集团公司第五十四研究所，河北石家庄《｝５０ｔ｝８１；
２．中国人民解放军６１９３２部队，北京ｌ｛｝ＩｌＩｌＩ１１））
ａｄｊｕｓｍｌｅｌＦｔｏｆｐｒｉｏｒｉｔｙ＂．Ｔｈｅｓｉｎｍｌａｔｉｏｎｅｘｐｅｒｉｍｅｎｔｒｅｓｕｌｔｓｓｈｏ＼ｖｔｈａｔｔｈｉｓｓｃｈｅｌｌｌｅｉｓａｖａｉｌａｂｌｅａｎｄｆｅａｓｉｂｌｅ．
务类的忧圮．感知的基础上以一定的策略则进行决
ｃｏｎｄｉｔｉｏｎｏｆｌｉＪｎｉｔｅｄｎｅｔｗｏｒｋｒｅｓｏｕｒｃｅｓＩｎｖｉｅｗｏｆｔｈｉｓｐｒｏｂｌｅｍ，ｔｈｉｓｐａｐｅｒｄｅｓｉｇｎｓａＦｌｅＷｎｅｔｗｏｒｋａｗａｒｅｎｅｓｓａｎｄｎｌａｎａｇｅｎｌｅｎｔｓｃｈｅｌｌｌｅｂａｓｅｄＯｉｌＩｌ、ｖａｒｅｌｌｅＳＳｍｅｔｈｏｄｓｏｆＯｐｅｎＦｌｏｗｎｅｔｗｏｒｋａｎｄｔｒａｄｉｔｉｏｎａｌｎｅｔｗｏｒｋ．Ｔｈｉｓｓｃｈｅｍｅｐｅｒｆｏｎｎｓｍａｎａｇｅｎｌｅｎｔ，ｏｐｔｉｎｆｉｚａｔｉｏｎａｌｌｄａｌｌｏｃａｔｉｏｎｆｏｒｎｅｔｗｏｒｋｒｅｓｏｕｒｃｅｂｙｉｓｉｎｇｃｏｎｔｒｏｌｌｅｒ，ｃａｒｌｅｎｓｕｒｅｅｆｅｃｔｉｖｅｌｙｔｈｅｑｕａｌｉｔｙｏｆｓｅｒｖｉｃｅａｎｄｉｍｐｒｏｖｅｔｈｅｒｅｓｏｕｒｃｅｕｔｉｌｉｚａｔｉｏｎｂｙｔｈｅ

软件定义网络SDN文献综述

软件定义网络SDN研究文献综述1.引言现有的网络设备(如交换机、路由器等）都是设备制造商在专门的硬件系统基础上高度集成大量网络协议、配备专用的设备控制系统，构成的一个相对独立封闭的网络设备［1］.在近几十年的发展过程中，云计算、移动互联网等相关技术的兴起和发展加快了网络技术的变革历程［2］。

网络带宽需求的持续攀升、网络业务的丰富化、个性化等都给新一代网络提出了更高的要求。

面对日益复杂的网络环境，这种紧耦合大型主机式的发展限制了IP网络创新技术的出现，更多的是通过不断增长的RFC数量对现行网络进行修修补补，造成了交换机／路由器设备控制功能的高度复杂。

网络研究人员想要在真实网络中基于真实生产流量进行大规模网络实验几乎是不可能的，因为网络设备是封闭的，没有提供开放的API，无法对网络设备进行自动化配置和对网络流量进行实时操控。

为了适应今后互联网业务的需求,业内形成了“现在是创新思考互联网基本体系结构、采用新的设计理念的时候”的主流意见［3］，并对未来网络的体系架构提出了新的性质和功能需求[4]。

软件定义网络［5］SDN的出现为人们提供了一种崭新的思路.本文从SDN的起源和概念出发,分析了SDN的逻辑架构与技术特点、描述了SDN 的标准化进程，梳理了国内外的研究进展与最新动态,在此基础上提出了SDN技术在未来的发展中面临的挑战并总结了可能的研究方向。

2.起源与概念2.1起源2006 年，斯坦福大学启动了名为“Clean-Slate Design for the Internet”项目，该项目旨在研究提出一种全新的网络技术，以突破目前互联网基础架构的限制,更好地支持新的技术应用和创新。

通过该项目，来自斯坦福大学的学生Martin Casado 和他的导师Nick McKeown 教授等研究人员提出了Ethane 架构[6］，即通过一个集中控制器向基于流的以太网交换机发送策略，实现对流的控制、路由的统一管理。

【毕业论文选题】计算机网络技术专业毕业论文题目

计算机网络技术专业毕业论文题目又到了各位应届别业生开始着手论文的时期了，目前一些计算机网络技术专业同学为论文题目而发愁，今天可以来看我们老师最新精选整理的200个题目，欢迎各位同学借鉴。

计算机网络技术专业毕业论文题目一：1、基于移动互联网下服装品牌的推广及应用研究2、基于Spark平台的恶意流量监测分析系统3、基于MOOC翻转课堂教学模式的设计与应用研究4、一种数字货币系统P2P消息传输机制的设计与实现5、基于灰色神经网络模型的网络流量预测算法研究6、基于KNN算法的Android应用异常检测技术研究7、基于macvlan的Docker容器网络系统的设计与实现8、基于容器云平台的网络资源管理与配置系统设计与实现9、基于OpenStack的SDN仿真网络的研究10、一个基于云平台的智慧校园数据中心的设计与实现111、基于SDN的数据中心网络流量调度与负载均衡研究12、软件定义网络（SDN）网络管理关键技术研究13、基于SDN的数据中心网络动态负载均衡研究14、基于移动智能终端的医疗服务系统设计与实现15、基于SDN的网络流量控制模型设计与研究16、《计算机网络》课程移动学习网站的设计与开发17、数据挖掘技术在网络教学中的应用研究18、移动互联网即时通讯产品的用户体验要素研究19、基于SDN的负载均衡节能技术研究20、基于SDN和OpenFlow的流量分析系统的研究与设计21、基于SDN的网络资源虚拟化的研究与设计22、SDN中面向北向的控制器关键技术的研究23、基于SDN的网络流量工程研究24、基于博弈论的云计算资源调度方法研究25、基于Hadoop的分布式网络爬虫系统的研究与实现26、一种基于SDN的IP骨干网流量调度方案的研究与实现27、基于软件定义网络的WLAN中DDoS攻击检测和防护28、基于SDN的集群控制器负载均衡的研究29、基于大数据的网络用户行为分析30、基于机器学习的P2P网络流分类研究31、移动互联网用户生成内容动机分析与质量评价研究32、基于大数据的网络恶意流量分析系统的设计与实现33、面向SDN的流量调度技术研究34、基于P2P的小额借贷融资平台的设计与实现35、基于移动互联网的智慧校园应用研究36、内容中心网络建模与内容放置问题研究237、分布式移动性管理架构下的资源优化机制研究38、基于模糊综合评价的P2P网络流量优化方法研究39、面向新型互联网架构的移动性管理关键技术研究40、虚拟网络映射策略与算法研究计算机网络技术专业毕业论文题目二：41、内容中心网络网内缓存策略研究42、内容中心网络的路由转发机制研究43、学习分析技术在网络课程学习中的应用实践研究44、互联网流量特征智能提取关键技术研究45、云环境下基于随机优化的动态资源调度研究46、基于OpenStack开放云管理平台研究47、基于OpenFlow的软件定义网络路由技术研究48、未来互联网试验平台若干关键技术研究49、基于云计算的海量网络流量数据分析处理及关键算法研究50、基于网络化数据分析的社会计算关键问题研究51、基于Hadoop的网络流量分析系统的研究与应用52、基于支持向量机的移动互联网用户行为偏好研究53、“网络技术应用”微课程设计与建设54、移动互联网环境下用户隐私关注的影响因素及隐私信息扩散规律研究55、未来互联网络资源负载均衡研究56、面向云数据中心的虚拟机调度机制研究57、基于OpenFlow的数据中心网络路由策略研究58、云计算环境下资源需求预测与优化配置方法研究59、基于多维属性的社会网络信息传播模型研究360、基于遗传算法的云计算任务调度算法研究61、基于OpenStack开源云平台的网络模型研究62、SDN控制架构及应用开发的研究和设计63、云环境下的资源调度算法研究64、异构网络环境下多径并行传输若干关键技术研究65、OpenFlow网络中QoS管理系统的研究与实现66、云协助文件共享与发布系统优化策略研究67、大规模数据中心可扩展交换与网络拓扑结构研究68、数据中心网络节能路由研究69、Hadoop集群监控系统的设计与实现70、网络虚拟化映射算法研究71、软件定义网络分布式控制平台的研究与实现72、网络虚拟化资源管理及虚拟网络应用研究73、基于流聚类的网络业务识别关键技术研究74、基于自适应流抽样测量的网络异常检测技术研究75、未来网络虚拟化资源管理机制研究76、大规模社会网络中影响最大化问题高效处理技术研究77、数据中心网络的流量管理和优化问题研究78、云计算环境下基于虚拟网络的资源分配技术研究79、基于用户行为分析的精确营销系统设计与实现80、P2P网络中基于博弈算法的优化技术研究计算机网络技术专业毕业论文题目三：81、OpenFlow网络中虚拟化机制的研究与实现82、基于时间相关的网络流量建模与预测研究83、B2C电子商务物流网络优化技术的研究与实现484、基于SDN的信息网络的设计与实现85、基于网络编码的数据通信技术研究86、计算机网络可靠性分析与设计87、基于OpenFlow的分布式网络中负载均衡路由的研究88、城市电子商务物流网络优化设计与系统实现89、基于分形的网络流量分析及异常检测技术研究90、网络虚拟化环境下的网络资源分配与故障诊断技术91、基于中国互联网的P2P-VoIP系统网络域若干关键技术研究92、网络流量模型化与拥塞控制研究93、计算机网络脆弱性评估方法研究94、Hadoop云平台下调度算法的研究95、网络虚拟化环境下资源管理关键技术研究96、高性能网络虚拟化技术研究97、互联网流量识别技术研究98、虚拟网络映射机制与算法研究99、基于业务体验的无线资源管理策略研究100、移动互联网络安全认证及安全应用中若干关键技术研究101、基于DHT的分布式网络中负载均衡机制及其安全性的研究102、高速复杂网络环境下异常流量检测技术研究103、基于移动互联网技术的移动图书馆系统研建104、基于连接度量的社区发现研究105、面向可信计算的分布式故障检测系统研究106、社会化媒体内容关注度分析与建模方法研究107、P2P资源共享系统中的资源定位研究108、基于Flash的三维WebGIS可视化研究109、P2P应用中的用户行为与系统性能研究5。

以SDN技术为基础的网络流量控制研究

以SDN技术为基础的网络流量控制研究一、引言网络流量是指在网络中传输的数据量，是网络性能的重要指标之一。

高效稳定的网络流量控制可以提高网络质量、保障用户体验、提高安全性，因此一直受到广泛的关注。

目前，软件定义网络(SDN)技术是网络流量控制领域的热门技术之一，具有灵活、可编程、安全等优势，针对不同应用场景的网络流量控制方案也得到了充分的研究。

本文将就SDN技术为基础的网络流量控制的相关研究进行探讨。

二、SDN技术概述SDN技术，即软件定义网络，将网络控制平面与数据平面分离，中央控制平面集中控制整个网络的行为，将网络的控制和管理交给软件程序来实现。

SDN技术具有以下优点：1、网络资源利用率高：SDN技术可以对网络流量进行管理和优化，实现资源的合理使用，提高网络的带宽利用率。

2、可编程性强： SDN技术支持自定义网络功能，可以灵活适应不同的应用场景和需求。

3、安全性高：SDN技术可以对网络流量进行实时监控和数据分析，快速识别和处理异常流量，提高网络的安全性。

4、管理方便：SDN架构对网络管理和监控进行了集中化管理，可以大大简化运维人员的工作。

三、SDN技术为基础的网络流量控制分类SDN技术为基础的网络流量控制可以按照不同的分类方式进行划分。

1、按应用场景划分根据应用场景的不同，SDN技术为基础的网络流量控制可以分为数据中心网络、企业级网络和WAN网络等不同类型。

每种网络类型都有其特定的网络流量控制需求。

2、按控制策略划分SDN技术可以通过流规则、ACL规则、QoS策略等方式来进行网络流量控制，不同控制策略可以根据不同需求灵活应用。

3、按控制对象划分SDN技术可以对不同网络对象的流量进行控制，如端口、IP地址、MAC地址等。

四、SDN技术为基础的网络流量控制方案1、基于OpenFlow的网络流量控制OpenFlow是SDN技术的一种网络控制协议，通过控制器和网络交换机之间的通信，将网络控制平面与数据平面分离。

基于OpenFlow的SDN技术研究

中文引用格式 : 左青云 , 陈鸣 ,赵广松 ,邢长友 ,张国敏 ,蒋培成 .基于 OpenFlow 的 SDN 技术研究 .软件学报 ,2013,24(5):1078 1097. /1000-9825/4390.htm 英文引用格式 : Zuo QY, Chen M, Zhao GS, Xing CY, Zhang GM, Jiang PC. Research on OpenFlow-based SDN technologies. Ruan Jian Xue Bao/Journal of Software, 2013,24(5):10781097 (in Chinese). /1000-9825/4390.htm
软件学报 ISSN 1000-9825, CODEN RUXUEW Journal of Software,2013,24(5):10781097 [doi: 10.3724/SP.J.1001.2013.04390] ©中国科学院软件研究所版权所有 .
E-mail: jos@ Tel/Fax: +86-10-62562563
网络范围视图网络层目标
Decision Disseminatቤተ መጻሕፍቲ ባይዱon Discovery Data
直接控制
4D architecture 4D 架构
图1
下 ,决策平面通过全局网络视图做出网络控制决策 ,并直接下发到数据平面 ;分发平面在决策平面和路由器之间
1080
Journal of Software 软件学报 Vol.24, No.5, May 2013
network applications and future Internet technologies. The development status of OpenFlow-based SDN technologies is surveyed in this paper. The research background of decoupled architecture of network control and data transmission in OpenFlow network is summarized first, and the key components and research progress including OpenFlow switch, controller, and SDN technologies are introduced. Moreover, current problems and solutions of OpenFlow-based SDN technologies are analyzed in four aspects. Combined with the development status in recent years, the applications used in campus, data center, network management and network security are summarized. Finally, future research trends are discussed. Key words: OpenFlow; future Internet; controller; virtualization; software-defined networking (SDN)

SDN——未来网络演进的重要趋势

SDN——未来网络演进的重要趋势赵慧玲;冯明;史凡【摘要】SDN已经成为通信界最热门的词汇之一,其基于控制和转发相分离的思路,实现了网络和业务的可编程,促进了网络的虚拟化和IT化以及硬件的归一化,为降低建设成本、运维难度和业务响应时间奠定了基础.SDN代表了网络演进的方向和趋势,以OpenFlow为代表的相关技术正在标准化过程中,业界也开始了相应的研发和部署试验,但总体上还处于起步阶段,值得各方加以重视,以促进未来网络的智能化发展.%Now the SDN becomes the hot topic in the telecom world.It is based on the separation of the control plane and data plane, also introducing the programming between network and service.So SDN can promote the network virtualization and device uniformity, as help to reduce the CAPEX/OPEX and release time for new service.SDN is the key trend for the future network evolution obviously even in its early stage now.The OpenFlow, which is the typical protocol in SDN is maturing step by step with the work in ONF.Also some R&D related with SDN is in progress all over the world, indicating the right future of the SDN.【期刊名称】《电信科学》【年(卷),期】2012(028)011【总页数】5页(P1-5)【关键词】软件定义网络;控制;可编程【作者】赵慧玲;冯明;史凡【作者单位】中国电信集团公司北京 100032【正文语种】中文1 引言自 2011 年以来，SDN（software defined network，软件定义网络）逐步成为业界最热门的词语之一，在InfoWorld于2011年11月公布的将影响未来10年的10项新技术中，SDN排名第二。

openflow协议

openflow协议OpenFlow协议是一种用于软件定义网络（SDN）的通信协议，它允许网络管理员动态地控制网络流量，并为网络带来更大的灵活性和可管理性。

本文将介绍OpenFlow协议的基本原理、作用和应用。

OpenFlow协议的基本原理是将网络数据转发和控制分离开来。

在传统网络中，路由器和交换机负责数据的转发和控制，而在SDN中，控制逻辑被抽象出来，集中在一个控制器中。

OpenFlow协议定义了控制器和交换机之间的通信方式，控制器可以通过OpenFlow协议向交换机下发流表规则，从而控制数据包的转发路径。

OpenFlow协议的作用主要体现在以下几个方面：首先，OpenFlow协议使得网络管理变得更加灵活和可编程。

传统网络设备的功能是固定的，而在SDN中，控制器可以根据网络管理员的需求动态地调整网络的行为，实现对网络流量的精细化控制。

其次，OpenFlow协议为网络创新提供了更多可能性。

由于控制逻辑被抽象出来，网络管理员可以通过编程的方式实现对网络的定制化控制，从而满足不同场景下的需求。

再次，OpenFlow协议可以提高网络的可管理性和安全性。

通过集中式的控制，网络管理员可以更加方便地监控和管理整个网络，对网络中的安全漏洞进行及时修复。

最后，OpenFlow协议为网络的自动化运维提供了基础。

通过编程的方式，网络管理员可以实现对网络的自动化配置和优化，降低了网络运维的成本和复杂度。

在实际应用中，OpenFlow协议已经被广泛应用于数据中心网络、校园网和企业网络等场景。

在数据中心网络中，OpenFlow协议可以实现对数据流的动态负载均衡和流量调度，提高了网络的性能和可靠性。

在校园网和企业网络中，OpenFlow协议可以实现对网络流量的细粒度控制，保障了网络的安全性和稳定性。

总之，OpenFlow协议作为SDN的重要组成部分，为网络的管理和控制带来了革命性的变化。

它不仅提高了网络的灵活性和可编程性，还为网络创新和自动化运维提供了基础。

互联网改革新军OpenFlow论坛

如果我从一个全新的开始设计互联网，我
会怎么做 ”和 “５年后的互联网应该是什１
咖
～
渗
，
么样子 ” 。为此，改革派们开始了一系列新的设计方案，本期所介绍的就是改革派大
军中的一个新兴组织ＯｅＦｏ交换机论坛ｐｎｌｗｆｈｐｎｌｗｔｈＣｎｏｔｍ，ＴｅｅＦｏＳｉｏｓｒｕ后文简称Ｏｗｃｉ
ＯｅＦｏｐｎｌｗ论坛）。
重新设计互联网
上图分别为全球互联网情况和流量情况图，面对这样规模的应用，要重新设计互联网，一切推倒重来，无疑是一
与那些动辄成立多年的论坛相比，
个极大的挑战。新兴组织ＯｅＩｐｎｏＦｗ论坛主要解决的是重新设计互联网的实验环境问题。
的设计者之一，ＯｅＦｏｐｎｌｗ论坛希望防止制造商的利益冲突被引入论坛。
设备提供商的噩梦
ＯｅＦｏｐｎｌｗ论坛主要解决的是重新设计
互联网的实验环境问题。在纯的实验网上
总难以有足够多的实际用户或者足够大的
互联网改革新军ＯｐｎＩｗ论坛ｅＦｏ
网络拓扑来测试新协议的性能和功能，最
好的方法是将运行新协议的实验网络嵌入
实际运营的网络，利用实际的网络环境来
检验新协议的可行性和存在的问题。传统的解决方案有两种，要求设备制
造商完全开放平台接Ｅ或实验者自ｌ行制造设ｐｎｌｗ：０８随着互联网的发展，今天的互联网业ＯｅＦｏ论坛只是￣２０年刚刚成立的新备。设备制造商完全开放平台接口让研究者ｐｎｌｗ论坛起源于斯坦福大学可以使用商用网络设备进行二次开发，务对互联网提出了越来越高的传输质量要兴组织。ＯｅＦｏ寻找Ｃｅｌｅ计划（ａｔ斯坦福大学的“ ｌｎ实验协议与传统协议并存的方法（１ｏＣｅａ求，如何修改互联网以满足新业务的需求，的 “ ｌｎＳａ ” 图出现了改良派和改革派两种不同的做法。Ｓａｅ１ ”计划是一个致力于研究重新设计互ｔ但是，直接开放网络设备的开发接口改良派认为可以在原有的基础设施上联网的项目，这个计划目前支持了大约１对设备提供商而言是一场噩梦，一方面与Ｏ添加新的协议来解决问题，改革派则认为个不同方向致力于重新设计互联网的项商用平台的封闭性相冲突，开放开发的二必须推到一切重来。改革派向自己提出这样的两个问题：“ 自己目前掌握的知识，就目）最早的成员只有斯坦福大学的高性能次接口无疑会有暴露自身技术细节的风险，，

OpenFlow技术分析和应用

OpenFlow技术分析和应用摘要：随着网络技术的不断发展，在现有的网络设备及协议基础之上，对已有网络进行创新性试验变得越来越困难。

当前条件下，新型网络协议在进行广泛部署前缺少有效途径对其进行试验，导致多数网络创新思想得不到测试和验证。

因此，为了在现有网络上试验新型网络协议，2008年3月，Nick McKeown等人提出了OpenFlow：一种基于流分类的新型网络试验技术，用来解决当前网络面对新业务产生的种种瓶颈。

关键词：OpenFlow；网络协议1OpenFlow技术综述1.1OpenFlow产生的背景和意义1.1.1互联网发展现状随着互联网技术的不断发展和成熟，网络上承载的业务种类呈现越来越复杂化的趋势。

随之而来的应用需求不断升级，导致现有的网络架构已经越来越难以承担传输用户业务所带来的技术挑战及沉重负荷。

当前互联网的体系架构距其刚形成时的技术条件和应用需求发生了很大的变化，然而其体系架构却并没有适应这种变化做出相应的调整，只是采取了渐进性修补的弥补策略，并没有从本质上解决网络异构化和业务复杂化随之而来的诸多问题。

随着一些网络新技术的出现，传统互联网的网络架构面临着深度调整乃至根本性变革的挑战，以满足不断提高的用户对网络服务质量、网络可管理性以及网络安全性方面的主观需求。

1.1.2可编程网络的需求和发展美国科学基金会提出的GENI，主要对网络架构、服务、功能进行革命性设计以适应经济、社会增长的需求。

GENI项目分为可控试验和试验验证两个部分，研究人员通过可控试验对相关网络试验进行设计和验证，并进行仿真，最后通过现实认证、检验其在现实的复杂网络环境下的运行性能。

这些可编程的网络需要可编程的交换机和路由器，通过虚拟化技术同时为多个隔绝的试验网络处理数据包。

然而，商业的交换机和路由器不会专门的提供一个开放的软件平台，对其进行软硬件虚拟化。

不同厂家的设备内部结构迥异，没有一个标准的平台可供研究者进行试验。

SDN和Openflow详解mininet与opendaylight环境搭建与测试

基于OpenFlow的SDN技术1. SDN与OpenFlow技术简介SDN指的是软件定义网络。

你可以这样去理解SDN：如果将网络中所有的网络设备视为被管理的资源，那么参考操作系统的原理，可以抽象出一个网络操作系统（Network OS）的概念—这个网络操作系统一方面抽象了底层网络设备的具体细节，同时还为上层应用提供了统一的管理视图和编程接口。

这样，基于网络操作系统这个平台，用户可以开发各种应用程序，通过软件来定义逻辑上的网络拓扑，以满足对网络资源的不同需求，而无需关心底层网络的物理拓扑结构。

云计算的发展，是以虚拟化技术为基础的。

云计算服务商以按需分配为原则，为客户提供具有高可用性、高扩展性的计算、存储和网络等IT资源。

虚拟化技术将各种物理资源抽象为逻辑上的资源，隐藏了各种物理上的限制，为在更细粒度上对其进行管理和应用提供了可能性。

近些年，计算的虚拟化技术（主要指x86平台的虚拟化）取得了长足的发展；相比较而言，尽管存储和网络的虚拟化也得到了诸多发展，但是还有很多问题亟需解决，在云计算环境中尤其如此。

OpenFlow和SDN尽管不是专门为网络虚拟化而生，但是它们带来的标准化和灵活性却给网络虚拟化的发展带来无限可能。

SDN的最重要特征：将传统网络设备的数据转发（data plane）和路由控制（control plane）两个功能模块相分离，通过集中式的控制器（Controller）以标准化的接口对各种网络设备进行管理和配置，那么这将为网络资源的设计、管理和使用提供更多的可能性，从而更容易推动网络的革新与发展。

OpenFlow是实现SDN最常用的的一种协议，OpenFlow的原理和基本架构如下图。

其实，这张图还很好地表明了OpenFlow Switch规范所定义的范围—从图上可以看出，OpenFlow Switch规范主要定义了Switch的功能模块以及其与Controller之间的通信信道等方面。

OpenFlow技术及应用优势分析

ＩＳ１０－３４ＳＮ０９０４
Ｅ— ｉｎｏｃｃｎｔｎｍａｌｆ＠ｃｃ．ｅ．：ｉｏ
ｈｔｐ：ｗｗｗ．ｎｚ．ｅ．ｎｔ／／ｄｓｎｔｃＴｅ：６—５ —５０ｌ＋８５１６９９６３５６０９９６４
ＣｍｕｅｎｗｅｇｎｅｈｏｇｏｐｔＫｏｌｅａｄＴｃｎｌｙ电脑知识与技术ｒｄｏ
网络。
ቤተ መጻሕፍቲ ባይዱ
当前网络的报文转发过程完全由交换机／由器等交换设备控制，ＯｅＦｏ路而ｐｎｌｗ网络中报文转发过程由交换机和控制器共同完
成，而实现了数据转发和路由控制的分离。控制器可以通过事先规定好的接口操作来控制ＯｅＦｏ从ｐｎｌｗ交换机中的流表，如修改流
实验，并希望他们的服务器能够直接访问交换机的转发表。在后来的斯坦福大学的ＣｅｎＳａｅｌａｌ计划中ＯｅＦｏｔｐｎｌｗ作为计划投资的一开放式标准协议，ｌａｌｅＣｅｎＳａ计划致力于研究在现有网络上利用ＯｅＦｏｔｐｎｌｗ技术试验新型的网络协议，其最终目标是能够重新设计
表表项以改变流量在网络中的走向，从而达到控制数据转发的目的。
Ｖｏ．，Ｎｏ２１８．５，Ｓｐｅｅ０１ｅｔｍｂｒ２２．
ＯｐｎＩｗ技术及应用优势分析ｅＦｏ
黄宝赵座，喜求
（四川大学计算机学院，四川成都６０６）１０４－
摘要：文介绍了一种新型网络技术一ｏｐｎ１ｗ。Ｏｐｎｌ网络将路由控制和数据传输分离，决了当前网络因复杂功该ｅＦｏｅＦｏｗ解能导致网络交换设备臃肿和设备性能提升空间小的问题。该文分析了Ｏｐｎｌｗ网络体系结构以及Ｏｐｎｌｗ的应用优ｅＦｏｅＦｏ势，提出了０ｐｎｌｗ技术研究挑战。并ｅＦｏ关键词：ｅＦｏ网络协议；Ｏｐｎｌｗ；交换机中图分类号：Ｐ９文献标识码：文章编号：０９３４（０２２ — ９５０Ｔ３３Ａ１Ｏ — ０４２１）５５８ — ３