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-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 flow-table, and a standardized interface to add and remove flow 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 confidence 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 “ossified”.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 figure out how, we can start soon and extend the technique to other campuses to benefit 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 vendor s 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 internalflexibility is hidden. The internals di ffer 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 sol utions are too closed and inflex 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 flow-tables (typically built from TCAMs) that run at line-rate to im plement firewalls, NAT, QoS, and to collect statistics. While each vendor’s flow-table is different, we’ve identified 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 flow-table in different switches and routers. A network administrator can partition traffic into production and research flows. Researchers can control their own flows -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 traffic 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 flow 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 flexibility. 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 paper, define 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 flow entry, to tell the switch how to process the flow, (2) A Secure Chan nel 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 defined 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 defined b y a remote control process. Figure 1 shows an example of an OpenFlow Switch.In this context, flows are broadly defined, and are limited only by the capabilities of the particular implementation of the Flow Table. For example, a flow 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 flow could be defined as all packets matching a specific (but non-standard) header.Each flow-entry has a simple action associated with it; the three basic ones (that all dedicated OpenFlow switches must support) are:1 Forward this flow’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 flow’s packets to a controller. Packet is delivered to Secure Channel, where it is encapsulated and sent to a controller. 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. Or in some experiments, it could be used to forward all packets to a controller for processing.3 Drop this flow’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 fields: (1) A packet header that defines the flow, (2) The action, which defines how the packets should be processed, and (3) Statistics, which keep track of the number of packets and bytes foreach flow, and the time since the last packet matched the flow (to h elp with the removal of inactive flows).In the first generation “Type 0” switches, the flow header is a 10-tuple shown in T able 1. A TCP flow could be specified by all ten fields, whereas an IP flow might not include the transport ports in its definition. Each header field can be a wildcard to allow for aggregation of flows, such as flows in which only the VLAN ID is defined would apply to all traffic on a particular VLAN.Table 1 The header fields 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 traffic and applications. Therefore, to win theconfidence of network administrators, OpenFlow-enabled switches must isolate experimental traffic (processed by the Flow Table) from productiontraffic 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 flow’s packets through the switch’s nor mal processing pipeline.The other is to define separat e sets of VLANs for experimental and production traffic. Both approaches allow normal production traffic 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 SwitchSpecification), 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 fields in the packet header, enabling experiments with new non-IP protocols. As a particular set of features emerges, we willdefine a “Type 1” switch.Controllers.A controller adds and removes flow-entries from the Flow Table on behalf of experiments. For example, a static controller might be a simple application running on a PC to statically establish flows to interconnect a set of test computers for the duration of an experiment. In this case the flows resemble VLANs in current networks— providing a simple mechanism toisolate experimental traffic from the production network. Viewed this way, OpenFlow is a generalization of VLANs.One can also imagine more sophisticated controllers that dynamicallyadd/remove flows 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 flows 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 different accounts and permissions, enabling them to run multiple independent experiments on different sets of flows. Flows identified 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 flow-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 flow starts Amy-OSPF picks a route through a series of OpenFlow Switches, and adds a flow-entry in each switch along the path. In her experiment, Amy decides to use Amy-OSPF for thetraffic entering the OpenFlow network from her own desktop PC— so she doesn’t disrupt the network for others. To do this, she defines one flow to be all the traffic entering the Open-Flow switch through the switch port her PC is connected to, and adds a flow-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 flow-entry (for the application flow) 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 flows as an experiment progresses: Can such a centralized controller be fast enough to process new flows 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 flow 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 flows per second —enough for a large college campus. Of course, the rate at which ne w flows can be processed will depend on the complexity of the processing required by the re searcher’s experiment. But it gives us confidence 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” vendor.2 Amy should only be able to add flow entries for her traffic, or for any traffic 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 flow entries. 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 different 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 offer 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 first 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 specific implementation of a controller, suited for network management and control, that manages the admittance and routing of flows. The basic idea of Ethane is to allow network managers to define a network-wide policy in the central controller, which is enforced directly by making admission control decisions for each new flow. A controller checks a new flow 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 flows are sent to a user’s process in a controller, hence allowing researcher-specific 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 flows which specify the ports accessible by traffic on a givenVLAN ID. Traffic identified as coming from a single user (for example, originating from specific 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 traffic at runtime.Example 3: Mobile wireless VOIP clients. For this example consider an experiment of a new call-handoff 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 handoff 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 traffic. For example, flows could be identified 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 (offset + value + mask), allowing packets to be processed in a researcher-specified way.Example 5: Processing packets rather than flows.The examples above are for experiments involving flows — where a controller makes decisions when the flow 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 flow’s packets to pass through a controller. To do this, a controller doesn’t add a new flow ent ry into the Flow Switch — it just allows the switch to default to forwarding every packet to a controller. This has the advantage of flexibility, 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-definable 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 Specification. 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 influence). To join, send email to .The Consortium web-site contains the OpenFlow Switch Specification, a list of consortium members, and reference implementations of OpenFlow switches.Licensing Model: The OpenFlow Switch Specification 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 defined in the OpenFlow Switch Specification. 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 traffic will run over the OpenFlow network, with production traffic and experimental traffic being isolated on different VLANs under the control of network administrators. Researchers will control their own traffic, and be able to add/remove flow-entries.。
超融合技术白皮书
深信服超融合架构技术白皮书深信服科技有限公司修订记录深信服超融合架构技术白皮书文档密级：内部第1章、前言 (8)1.1IT时代的变革 (8)1.2白皮书总览 (9)第2章、深信服超融合技术架构 (11)1.1超融合架构概述 (11)1.1.1超融合架构的定义 (11)1.2深信服超融合架构组成模块 (11)1.2.1.1系统总体架构 (11)1.2.1.2aSV计算虚拟化平台 (12)1.2.1.2.1概述 (12)1.2.1.2.2aSV技术原理 (13)1.2.1.2.2.1aSV的Hypervisor架构 (14)1.2.1.2.2.2Hypervisor虚拟化实现 (17)1.2.1.2.3aSV的技术特性 (25)1.2.1.2.3.1内存NUMA技术 (25)1.2.1.2.3.2SR-IOV (26)1.2.1.2.3.3Faik-raid (27)1.2.1.2.3.4虚拟机生命周期管理 (28)1.2.1.2.3.5虚拟交换机 (29)1.2.1.2.3.6动态资源调度 (30)1.2.1.2.4aSV的特色技术 (30)1.2.1.2.4.1快虚 (30)1.2.1.2.4.2虚拟机热迁移 (31)1.2.1.2.4.3虚拟磁盘加密 (32)1.2.1.2.4.4虚拟机的HA (33)1.2.1.2.4.5多USB映射 (33)1.2.1.3aSAN存储虚拟化 (35)1.2.1.3.1存储虚拟化概述 (35)1.2.1.3.1.1虚拟后对存储带来的挑战 (35)1.2.1.3.1.2分布式存储技术的发展 (35)1.2.1.3.1.3深信服aSAN概述 (36)1.2.1.3.2aSAN技术原理 (36)1.2.1.3.2.1主机管理 (36)1.2.1.3.2.2文件副本 (37)1.2.1.3.2.3磁盘管理 (38)1.2.1.3.2.4SSD读缓存原理 (39)1.2.1.3.2.5SSD写缓存原理 (45)1.2.1.3.2.6磁盘故障处理机制 (49)1.2.1.3.3深信服aSAN功能特性 (60)1.2.1.3.3.1存储精简配置 (60)1.2.1.3.3.2aSAN私网链路聚合 (61)1.2.1.3.3.3数据一致性检查 (61)1.2.1.4aNet网络虚拟化 (61)1.2.1.4.1网络虚拟化概述 (61)1.2.1.4.2aNET网络虚拟化技术原理 (62)1.2.1.4.2.1SDN (62)1.2.1.4.2.2NFV (63)1.2.1.4.2.3aNet底层的实现 (64)1.2.1.4.3功能特性 (68)1.2.1.4.3.1aSW分布式虚拟交换机 (68)1.2.1.4.3.2aRouter (68)1.2.1.4.3.3vAF (69)1.2.1.4.3.4vAD (69)1.2.1.4.4深信服aNet的特色技术 (69)1.2.1.4.4.1网络探测功能 (69)1.2.1.4.4.2全网流量可视 (70)1.2.1.4.4.3所画即所得业务逻辑拓扑 (70)1.2.2深信服超融合架构产品介绍 (71)1.2.2.1产品概述 (71)1.2.2.2产品定位 (71)第3章、深信服超融合架构带来的核心价值 (73)1.1可靠性： (73)1.2安全性 (73)1.3灵活弹性 (73)1.4易操作性 (73)第4章、超融合架构最佳实践 (74)第1章、前言1.1 IT时代的变革20 世纪90 年代，随着Windows 的广泛使用及Linux 服务器操作系统的出现奠定了x86服务器的行业标准地位，然而x86 服务器部署的增长带来了新的IT 基础架构和运作难题，包括：基础架构利用率低、物理基础架构成本日益攀升、IT 管理成本不断提高以及对关键应用故障和灾难保护不足等问题。
SDN初学者的学习之路与心得
我与SDN的缘分一名初学者的学习之路与心得去年十一月，我在大三的计算机网络课程上与SDN初识。
今年三月中旬，我有幸得到老乡学长北邮–李呈的指引，真正地与SDN结缘，悄然走上学习之路。
SDN，Software Defined Network，是对传统网络架构的一次革新。
经过短短三四个月的学习和实践，我本着授人以渔的理念，辅以我的一些理解，将我的学习历程和心得叙写出来，送给各位想要入门的或跟我一样刚刚入门的朋友们。
文中有理解不到位的地方，还望各位朋友不吝赐教，非常感谢!SDN，软件定义网络，我们关键就是弄清楚三件事：网络、软件、软件与网络怎么结合。
一、走进网络既然我们要用SDN来改造网络，当然得先了解一下网络是何物，磨刀不误砍柴工。
我对网络的了解，是从高中开始的。
从OSI七层模型，到五层模型;从家庭组网，再到Socket 编程实践，我对网络的兴趣不断增长。
直到大二学了《计算机通信与网络》这门课，才算是对过往三四年积累的零星知识的一次大梳理，让我对网络有了一个系统性的了解。
(1)传统网络传统网络，我的老师用它代指我们一直以来都在使用的网络，用以跟SDN网络区别。
我是跟随着谢希仁前辈的《计算机网络》这本书学习的，也推荐给各位朋友。
跟随着大二的课程，我把五层模型的低四层学了个遍，主要是从物理层的拓扑、集线器，到数据链路层的网桥、MAC、CSMA/CD、CSMA/CA，再到网络层的路由器、最长前缀匹配、IP、ARP、OSPF、RIP、BGP，最后到传输层的UDP、TCP，掌握了这些，对我们网络的理解大有裨益。
根据我的SDN实践经验，深入理解一下最长前缀匹配，TCP的反馈重传、滑动窗口、三次握手、四次挥手，是非常有好处的。
(2)SDN网络在这里，我们需要弄清楚三个问题：①SDN是什么?②我们为什么需要SDN?③SDN可以用在何处?学习SDN伊始，我阅读了一些介绍SDN的文献资料，还有一些控制器的白皮书。
比较推荐大家从Open Network Fundation(ONF)组织的SDN白皮书入手，再辅以其他的介绍资料，了解SDN的架构是什么样，数据、控制、管理面，南向、北向、东西向，以及传统网络存在哪些不能适应新需求的问题、SDN针对这些问题有什么样的特性去应对。
openflow 协议报文格式
openflow 协议报文格式（实用版）目录1.OpenFlow 协议简介2.OpenFlow 协议报文格式3.OpenFlow 协议的应用4.OpenFlow 协议的未来发展正文1.OpenFlow 协议简介OpenFlow 协议是一种用于描述控制器和交换机之间交互所用信息的标准，以及控制器和交换机的接口标准。
它的核心部分是用于 OpenFlow 协议信息结构的集合。
OpenFlow 协议旨在实现网络设备的自动化配置和管理，从而提高网络的灵活性和可编程性。
2.OpenFlow 协议报文格式OpenFlow 协议报文是在控制器和交换机之间传递的信息。
它包括以下几种类型的报文：（1）Hello 报文：用于在控制器和交换机之间建立和维护连接，以及传递双方的支持能力和状态信息。
（2）Discover 报文：用于控制器发现交换机上的流表项，从而实现对交换机端口和流表项的动态管理。
（3）Open 报文：用于建立控制器和交换机之间的会话，以便进行更高级别的通信。
（4）Update 报文：用于控制器向交换机发送流表项的更新指令，以及实现对交换机端口的动态配置。
（5）Delete 报文：用于控制器向交换机发送流表项的删除指令。
3.OpenFlow 协议的应用OpenFlow 协议主要应用于以下场景：（1）虚拟私有网络（VPN）：通过 OpenFlow 协议，可以实现对虚拟私有网络的动态配置和管理，提高网络的灵活性和可编程性。
（2）负载均衡：OpenFlow 协议可以用于实现网络设备的负载均衡，从而提高网络的性能和可靠性。
（3）流量工程：通过 OpenFlow 协议，可以实现对网络流量的动态控制和管理，从而提高网络的性能和可编程性。
4.OpenFlow 协议的未来发展随着网络技术的不断发展，OpenFlow 协议也在不断完善和扩展。
未来，OpenFlow 协议将更加关注以下几个方面的发展：（1）提高网络的可编程性：通过引入更多的编程语言和抽象层，实现对网络设备的更加灵活和可编程的管理。
openflow协议的工作原理与流程
openflow协议的工作原理与流程OpenFlow协议是一种新型的网络交换协议，它可以让管理者灵活地定义网络中的流行行为，为网络开发者提供更大的灵活性。
Openflow协议于2008年被Stanford University首次发布，经过近十年的发展，它已经成为一种流行的网络交换协议，被广泛应用于云计算和虚拟化网络中。
OpenFlow协议的核心是一种分布式控制器，该控制器可以与网络中的多个设备进行交互，包括交换机、路由器、防火墙和NAT设备等。
OpenFlow协议允许管理员灵活地控制网络中的流量，而无需重新设计网络架构，从而实现网络的自动化管理和安全性。
OpenFlow协议的工作原理是每一个网络设备（如交换机）建立一个控制连接，通过控制连接与控制器进行通信。
OpenFlow协议下的每一个网络设备都会发出报文，该报文中包含发送者、接收者、以及传输内容，以发送到控制器上。
控制器在收到报文后，会根据规则匹配和决策，并将控制指令下发到接收设备上，以实现网络中的流量控制。
OpenFlow协议的工作流程可以分为四个主要的步骤：1.网络设备发出报文：网络设备发出的报文中包括流入报文源、流出报文目的地以及传输内容。
2.控制器接受报文：控制器收到报文后，会根据规则匹配和决策，然后将控制指令下发到接收设备上。
3.接收设备收到控制指令：接收设备收到来自控制器的控制指令后，会根据控制指令重新定向流量，以实现流量控制。
4.网络流量控制：网络流量经过重新定向之后，即可实现对数据流的控制，从而提高网络的效率和安全性。
OpenFlow协议的出现标志着一种新的网络交换模式，可以让管理者灵活地定义网络的流行行为，具备更高的灵活性和更强的安全性，是网络管理技术革新的一个重要里程碑。
OpenFlow协议已经被广泛应用于虚拟化网络，云计算，SDN技术，它不仅能更好地满足企业和用户的需求，还能帮助管理者更加迅速、灵活、安全地管理网络。
华为Agile Controller控制器标准接口白皮书
华为 Agile Controller 控制器标准接口技术白皮书数据中心敏捷控制器 Agile Controller-DCN 是华为数据中心解决方案的核心部件 , 提供从应用到物理网络的自动映射、资源池化部署和可视化运维，能够实现数据中心 VXLAN 网络的自动化部署。
AC 控制器是一个开放系统，基于开源平台设计，北向支持与业界主流 Openstack 云平台对接，南向支持和 vswitch 、物理交换机以及防火墙对接，控制器能够将北向的网络业务接口转换为南向的具体设备配置命令，实现网络自动化。
在没有云平台情况下，AC 控制器还能够提供单独的业务发放界面 , 支持与业界主流的计算资源管理系统对接，实现网络和计算协同。
AC 控制器和周边系统关系如下：业务发放REST API资源上报下面表格分别是南向、北向和东西向接口类型和具体作用解释。
一、北向和Openstack 云平台对接Openstack 是最主流的开源云管理平台，控制器能够和Openstack Neutron 对接，实现网络虚拟化，并且通过云平台能够和计算资源联动，在VM 创建/ 删除/ 迁移时候，按需调整网络配置。
AC 北向提供标准的Neutron REST API 的接口，通过在云平台Neutron 组件中插入Agent 或使用Driver 方式，实现从用户业务到Fabric 配置的逻辑抽象与协同下发。
AC 控制器和Openstack 之间对接接口如下：neutron-server 接收北向请求, 通过RESTCONF 将业务所需要的参数下发给AC, 通过AC 来实现vSwitch、物理交换机以及L4-L7 的VAS 设备管理。
•二层功能对接：AC 控制器通过ML2 Driver 实现二层虚拟网络管理，AC 支持创建VXLAN 类型网络，虚拟网络标识采用24bit VNID，虚拟网络标识可以突破4K 租户规模限制。
VXLAN 封装和解封装实体VTEP 可以位于TOR 也可以位于vswitch，前者为硬件VXLAN，后者为软件VXLAN。
【转】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。
OpenDaylight与Mininet应用实战之OpenFlow1.0协议分析
OpenDaylight与Mininet应用实战之OpenFlow1.0协议分析继本专题基本环境搭建（一）之后，本文在此基础上熟悉平台操作，以及通过wireshark 抓包工具分析OpenFlow（以下简写为OF）协议。
具体的OF官方协议及白皮书可在资料库栏目中下载阅读。
注：此文涉及的环境仅支持OF1.0版本，对于OF1.2、OF1.3版本可用其他平台测试，后续会另做专题讨论。
1打开wireshark并创建拓扑按照章节一搭建平台，启动ODL，并打开wireshark。
进入装有Mininet的VM，通过mn命令指定网络拓扑及指定此ODL控制器。
Mininet创建网络拓扑命令：此命令通过Mininet模拟创建一个含有两个交换机（Open vSwitch，以下简写为OVS）和两个主机的网络拓扑，其中192.168.5.203为ODL的IP，6633为ODL的默认端口，网络拓扑如下图所示：2查看网络在Mininet中通过操作网络命令，可以查看OVS间及OVS与主机间的连接关系，也可以查看Mininet是否远程连接控制器。
例如，通过nodes命令可以查看网络中所有的节点。
通过net命令可以查看并确认网络连接关系是否与预期一致以及节点信息，且可以了解具体的连接端口信息。
通过下面的dump命令可以看出，交换机通过远程方式连接到控制器，且能看到控制器的IP 和PORT。
3抓包并分析协议通过wireshark抓包可以直接看到控制器与OVS交换机的通信过程，下面分析该流程中的OF消息。
此专题应用的是直接支持OpenFlow协议的wireshark官网Stable Release(1.12.1)版本。
3.1建立连接控制器与交换机之间的OpenFlow协议是应用于TCP传输层上，所以解析应用层。
他们首先发送hello消息，建立初始化连接，协商使用的OpenFlow协议版本。
由下图可知，ODL与Mininet之间应用的是OpenFlow1.0版本协议（其他1.2、1.3协议会在协议OpenFlow 后面标识）。
Openflow-未来网络的基础协议(全文)
Openflow:未来络的基础协议(全文)2008年4月，一篇署名为NickMcKeown的论文《OpenFlow：enablinginnovationincampusnetworks》在ACMCommunicationsReview上发表。
至此，被美国斯坦福大学cleanslate研究组提出将近一年的Openflow向世人揭开了神秘面纱，一种将络转发与控制解耦的新型络交换模型逐渐浮出水面。
两年后，NickMcKeown又提出SDN（SoftwareDefineNetworks，软件定义络）的概念。
它起源于Openflow，也正是它，使Openflow引起业界重视，Openflow甚至在某种程度上成为SDN的代名词。
“SDN 是理念，Openflow是技术。
”盛科络CEO孙建勇一语道破SDN与Openflow之间的区别。
“在可以实现SDN的技术体系中，OpenFlow是相对成熟的技术之一。
”清华大学络研究院络体系结构与IPv6研究室主任毕军又指出了两者之间的关系。
虽然技术相对成熟，但是在追求标准化的IT界，尚未完全标准化的Openflow的标准化之路如何前行？这个过程会对SDN的发展起到什么样的作用？四个版本传统络架构由单独运行、封闭的设备连接构成，每台设备都有单独的操作系统，数据的转发和控制都由交换机和路由器完成，这会造成络的管控细节做得不是特别到位。
各种设备以及其相对孤立的操作系统在络中零散分布，也使络变得复杂且封闭。
此外，由于设备异构，络管理的兼容性也很难做到极致。
Openflow能够很好地解决以上问题。
与当今IT界追捧的“软硬件一体化”不同，SDN试图用软硬件分离的理念颠覆现有的络架构。
Openflow作为新一代络的核心技术，在分离软硬件方面肩负重任。
Openflow交换机以流表的方式进行数据的转发，FlowVisor负责对络进行虚拟化，控制器负责络控制，三者各司其职、分工明确而又相互配合，构成了Openflow的络架构。
openflow简介
匹 配
2021/3/10
10
OF消息
由交换机发起，而不 需要控制器预先发送 请求消息。对控制器 通告网络事件，交换 机状态或者报错事件。
asynchronous(异步) 消息
Controller-toswitch消息
symmetric(对称) 消息
由控制器发起，包括 握手、配置交换机、 修改状态、配置队列、 读取状态、发包、保 障等。
2021/3/10
OF消息类型
可以由任何一方发起， 用于建立连接和通告 生存状态。
11
OF消息
2021/3/10
12
SDN行业动态
秋季PlugFest结束 openflow1.3进入成 熟期 明年将开展
APPFest
2011
2012
2013
2021/3/10
6
OPENFLOW
交换机结构
控制器 负责数据处理
OPENFLOW交换机 负责数据转发
2021/3/10
7
OF交换机
OpenFlow交换机由流表（ ห้องสมุดไป่ตู้low Table）、安全通道 （Secure Channel）和 OpenFlow协议（ Openflow Protocol）三 部分组成。
8
OPENFLOW流表
• OpenFlow流表项结构
– OpenFlow流表的匹配域是从数据包中提取出来的，比如各种 包头字段，以太网源地址或者IPv4目的地址等，用于对交换机 接收到的数据包的包头内容进行匹配。
2021/3/10
9
流表匹配
控制器 发流表
转发给 控制器
当OpenFlow交换机接收到一个数据包时，将按照 优先级依次匹配其本地保存的流表中的表项，从匹 配的流表项中选择优先级最高的，并根据相应的动 作对数据包进行操作，同时流表项的计数器+1。
OpenFlow性能测试白皮书
摘要:测试一个交换机是否符合ONF要求的规格已经有一个成熟的标准和共识.但是ONF会给符合标准的交换机贴上一个ONF印章。
然而，openflow性能测试仍然处于初级阶段。
然而，存在少部分开源工具用来测试openflow性能，这些特性也开始出现在商业测试产品中，这里没有比较openflow产品性能的标准。
但是网络建设商们不仅需要知道建设用的器材是否符合ONF功能标准，而且需要知道产品性能是否能达到要求。
本文解释了openflow性能测试的重要性并且描述了公司可以自己用来测试openflow性能的方法。
为什么需要性能测试本文的一些参量Of解决方案中有一个或多个控制器和交换机，终端用户只关心完整的系统功能。
但是建设和整合者需要对每个组件进行单独的评估，以选择出更好的组件。
本文只是针对以太网交换机。
文中描述的例子主要是针对硬件交换机。
在性能测试方面，它比软件交换机更加综合和有趣。
然而软件交换机运行在标准的服务器上，硬件交换机则运用ASICs，它可以增大吞吐量。
当然，描述的方法同样适用于软件交换机。
针对of1.3.0性能测试的目标和挑战Of交换机不像传统的交换机主要看重包转发能力的测试。
它考虑例如交换机可以多快的处理flow-mod（控制器发给交换机的消息，作用是从交换机转发表中增加、删除、修改流表规则）消息和通过of管道怎么处理正交的包。
一旦of规则安装到硬件转发表中。
包就按照线速率进行转发。
这可以用传统的测试方法进行测试。
在of管道数据平面中的数据包存在大量流表项，包要进行大量的匹配，实行大量的动作，例如包修改和转发到目的端口。
根据不同解决方案，of交换机性能要求差异也很大。
有必要对控制器控制交换机增减流表规则性能进行测试表容量测试），可以用TCAM有不同TCAM大小，TCAM的数量也根据商家优化数量和流规则而变化很大Full 12-tuple match（of规则中，匹配所有12个头，，有些设备商提供掩盖表能力的优化，比如只匹配第二层的头到第二层的内存中而不是利用TCAMs）广泛地说，表能力测试需要确认流已经安装了（flow got installed）确定何时表满了，指出满的表中有多少流。
《图解OpenFlow》第一章：OpenFlow概要
《图解OpenFlow》第⼀章：OpenFlow概要1.1 OpenFlow的历史ONF：Open Networking Foundation（ONF，开放⽹络基⾦会），继承OpenFlow交换机论坛活动的形式，制定OpenFlow规范。
OpenFlow1.2之后的规范由ONF制定。
1.2 有效运⽤现有硬件，实现⾼效设计OpenFlow的初期设计思想是：⽆需设计新的硬件，⽀队现有硬件更新其软件。
因此，OpenFlow是以⽹络设备中内置了TCAM（Ternary Content-Addressable Memory）存储器为前提来实现的。
TCAM是对每个位（bit）实施0、1和don’t care三种匹配的三态电⼦器件，搭载该存储器的⽬的是在⽹络中通过硬件⾼速处理⼦⽹掩码和访问控制列表（ACL）。
1.3 所谓OpenFlow，具体是指什么传统⼆层交换机采⽤以太⽹地址和VLAN标签进⾏交换处理，⽽OpenFlow作为构建⽹络的标准规范，将各数据包（或帧）持有的以太⽹地址、VLAN标签、IP地址、TCP/UDP端⼝号等特征作为“流”来处理，在此基础上进⾏交换，并可以灵活设置路由的路径。
在构建OpenFlow⽹络时，原则上需要将控制⾯和数据⾯作为不同的⽹络，这并⾮必须要构建另外的物理⽹络。
还可以采⽤覆盖（Overlay）⽅式、使⽤VLAN等对同⼀物理⽹络进⾏逻辑分割、或者利⽤能同时⽤于数据⾯和控制⾯的“In-band控制通道”技术。
分别构建物理⽹络的优势是便于区分发⽣故障的部分。
数据⾯的构建⽅法有3种，即直接连接OpenFlow交换机的“Hop-by-Hop⽅式”、通过覆盖⽹络连接OpenFlow交换机的“覆盖⽅式”、组合以上两种⽅案的“混合⽅式”。
Hop-by-Hop⽅式就是OpenFlow交换机直接物理直连，覆盖⽅式则采⽤IP通道等技术构建⽤于数据⾯的覆盖⽹络。
覆盖⽅式具有同时使⽤现有⽹络和OpenFlow⽹络的优点，但处理性能不如Hop-by-Hop，存在MTU变⼩的缺点。
OpenFlow协议（OVS）
OpenFlow协议（OVS）
⽩⽪书（版本）：
功能（OpenFlow半年升级⼀次）
FlowTable流表：由很多个流表项组成，每个流表项就是⼀个转发规则。
进⼊的通过查询流表来获得转发的⽬的端⼝。
流表项由头域、计数器和操作组成；其中头域是个⼗元组，是流表项的标识；计数器⽤来计算流表项的统计数据；操作标明了与该流表项匹配的应该执⾏的操作。
Secure Channel：安全通道是连接OpenFlow到控制器的接⼝。
控制器通过这个接⼝控制和管理，同时控制器接收来⾃交换机的事件并向交换机发送。
和控制器通过安全通道进⾏通信，⽽且所有的信息必须按照OpenFlow协议规定的格式来执⾏。
OpenFlow协议：⽤来描述控制器和交换机之间交互所⽤信息的标准，以及控制器和交换机的接⼝标准。
协议的核⼼部分是⽤于OpenFlow协议信息结构的集合。
流表项1.0版本（查看流表项：dpclt dump-flows）
Action：
流表项1.3版本
对Action的集合操作（增加⼀部分对Action的逻辑操作指令）
基本上对应1.0版本的Action内容
按顺序执⾏：
注：TTL是 Time To Live的缩写，该字段指定IP包被路由器丢弃之前允许通过的最⼤⽹段数量。
TTL是IPv4包头的⼀个8 bit字段。
总结：
TimeOuts和Cookies
流表的匹配（1.1版本）
1.3版本
如何⽣成流表的呢？
连接的流程（通过抓包画出来的图⽚）
可以⽤WireShark来抓包分析
三类包信息
还有hello包（同步信息）等等
⽹络协议的交互。
openflow协议1.3.0中文版 完整版
OpenFlow交换机规范(概要)Version1.3.0（June25,2012）1介绍本文档描述了对OpenFlow交换机的要求。
此规范内容包括交换机的组件和基本功能，和一个远程控制器管理一个OpenFlow交换机的协议：OpenFlow。
2交换机部件OpenFlow的交换机包括一个或多个流表和一个组表，执行分组查找和转发，和到一个外部控制器OpenFlow的信道（图1）。
该交换机与控制器进行通信，控制器通过OpenFlow协议来管理交换机。
控制器使用OpenFlow协议，可以添加、更新和删除流流表中的表项，主动或者被动响应数据包。
在交换机中的每个流表中包含的一组流表项;每个流表项包含匹配字段，计数器和一组指令，用来匹配数据包（见5.2）。
匹配从第一个流表开始，并可能会继续匹配其它流表(见5.1）。
流表项匹配数据包是按照优先级的顺序，从每个表的第一个匹配项开始（见5.3）。
如果找到一个匹配项，那么与流表项相关的指令就会去执行。
如果在流表中未找到匹配项，结果取决于漏表的流表项配置：（例如，数据包可能通过OpenFlow信道被转发到控制器、丢弃、或者可以继续到下一个的流表，见5.4）。
与流表项相关联的指令包含行动或修改流水线处理（见5.9）。
行动指令描述了数据包转发，数据包的修改和组表处理。
流水线处理指令允许数据包被发送到后面的表进行进一步的处理，并允许信息以元数据的形式在表之间进行通信。
当与一个匹配的流表项相关联的指令集没有指向下一个表的时候，表流水线停止处理，这时该数据包通常会被修改和转发（见5.10）。
流表项可能把数据包转发到某个端口。
这通常是一个物理端口，但它也可能是由交换机定义的一个逻辑端口或通过本规范中定义的一个保留的端口（见4.1）。
保留端口可以指定通用的转发行为，如发送到控制器、泛洪、或使用非OpenFlow的方法转发，如“普通”交换机转发处理（见4.5）；而交换机定义的逻辑端口，可以是指定的链路汇聚组、隧道或环回接口（见4.4）。
SDN软件定义网络之南向协议——OpenFlow协议
SDN软件定义网络之南向协议——OpenFlow协议OpenFlow协议是一种用于SDN（软件定义网络）中的南向协议，它定义了控制器与交换机之间的通信协议。
本协议旨在实现网络控制平面与数据平面的分离，允许网络管理员通过集中式控制器来管理和控制网络交换机。
一、引言1.1 目的本协议的目的是定义OpenFlow协议的标准格式，以确保不同厂商的控制器和交换机能够互相兼容，实现网络的可编程性和灵活性。
1.2 背景传统的网络架构中，网络交换机负责数据转发和流量控制，而网络管理功能则由各个交换机独立实现。
这种分布式的管理方式导致网络管理复杂、难以扩展和定制化。
SDN的出现改变了这种情况，通过将网络控制平面与数据平面分离，实现了网络的集中管理和控制。
1.3 术语和缩写在本协议中，以下术语和缩写具有特定的含义：- SDN：软件定义网络（Software-Defined Networking）- 南向协议：控制器与交换机之间的通信协议- 控制平面：网络的逻辑控制中心，负责决策和管理网络- 数据平面：网络的数据传输部分，负责实际的数据包转发二、协议规范2.1 协议版本本协议的版本为OpenFlow X.X（根据实际情况填写具体版本号）。
2.2 协议消息格式OpenFlow协议的消息格式采用二进制格式，包括消息头和消息体两部分。
2.2.1 消息头格式消息头由以下字段组成：- 版本号：标识OpenFlow协议的版本号- 消息类型：标识消息的类型，如控制器发起的请求、交换机返回的回复等- 长度：消息体的长度，以字节为单位- 事务标识符：用于标识一组相关的消息，用于匹配请求和回复消息2.2.2 消息体格式消息体的具体格式根据消息类型的不同而有所不同，包括以下几种类型：- 控制器发起的请求消息：包括控制器向交换机发送的配置请求、查询请求等- 交换机返回的回复消息：包括交换机对控制器请求的回复，如配置回复、查询回复等- 异步通知消息：包括交换机主动向控制器发送的事件通知，如链路状态变化、端口状态变化等2.3 协议操作OpenFlow协议定义了一系列操作，用于控制器与交换机之间的交互。
OpenFlow
解析OpenFlow建立软件定义网络工作原理
使用OpenFlow协议建立软件定义网络，可以将网络作为一 个整体而不是无数的独立设备进行管理。传统交换机使用生成 树协议或其他一些新标准(如多链路透明互连，TRILL)来确定数 据包转发路径。而OpenFlow将转发决策从各个交换机转移到控 制器上，这一般是服务器或工作站。
管理应用程序执行控制器，负责与所有网络交换机进行交 互，配置数据转发路径，从而提高带宽利用率。这个应用程序 与云管理软件进行交互，保证有足够的带宽支持负载的创建和 变化。
OpenFlow标准定义了控制器与交换机之间的交互协议，以 及一组交换机操作。这个控制器—交换机协议运行在安全传输 层协议(TLS)或无保护TCP 连接之上。控制器向交换机发送指令， 控制数据包的转发方式，以及配置参数，如VLAN优先级。交换 机会在链路中断或出现未指定转发指令的数据包时，发送消息 通知控制器。
路由表指令会修改每一个数据包所设置的操作。一开始， 数据包会使用空操作集进行处理。这些操作可能要求数据包通 过指定的端口进行转发，或者需要修改数据包TTL、VLAN、 MPLS标签或数据包QoS。
第一个路由表的指令可能会对数据包执行操作，或者增加 一些将来执行的操作。这些指令会将数据包与其他路由表记录 进行比较，控制数据包的后续处理。后续路由表的记录的指令 可能会进一步增加操作，删除或修改之前添加的操作，或者执 行其他一些操作。
路由表的编号从0开始，到达的数据包对表0的记录进行比 较。如果匹配，路由计数会增加，然后执行指定的指令集。如 果到达的数据包不匹配任何路由表记录，那么必须创建一个新 流。有的交换机可能直接丢弃未定义的流，但是大多数情况下， 数据包都会转发到控制器上。然后，控制器为该数据包定义一 个新流，并且创建一个或多个路由表记录。然后，它会将记录 发送到交换机上，并增加路由表。最后，数据包会被送回交换 机，使用新创建的路由记录进行处理。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
OpenFlow携手校园网创新译者：北邮-李呈Homepage: 摘要本白皮书提出OpenFlow：一种为研究人员提供的可以在日常网络中运行协议的方式。
OpenFlow基于拥有内部流表，并能通过标准接口添加和删除流表项的以太网交换机。
我们的目标是鼓励网络厂商将OpenFlow部署在大学校园骨干网和配线间的交换机产品上。
我们认为，OpenFlow的是一个有意义的折衷：一方面，它使研究人员能够以统一的方式在线速和高端口密度的交换机进行实验。
而另一方面，厂商不必暴露自己的交换机内部工作细节。
除了允许研究者在真实流量环境中评价他们的想法，在提出像GENI那样的大型测试平台的过程中OpenFlow还能是一个有用的校园组件。
不久的将来斯坦福的两栋大楼会在商用以太网交换机和路由器上部署OpenFlow。
我们会鼓励其他学校也部署OpenFlow，而且我们也会鼓励你考虑将OpenFlow部署到你的学校。
分类和主题描述C.2[互联网络]：路由器普通术语实验,设计关键词以太网交换机,虚拟化,流1、可编程网络的需求分析网络已经成为公司，家庭，学校的重要的基础设施。
这个成功对于网路研究者来说以一个福音也是一个诅咒。
他们的工作将更有相关性，但是做出影响的机会也越来越遥远。
在任何给定的网络中对现实世界的影响在减少的原因在于我们安装了大规模的设备和协议，而不愿对产生的流量做实验，这已经给创新设立了一个过高的门槛。
今天，在足够逼真的设置下（例如，大规模引入真实流量），几乎没有实用的方法去做网络新协议的实验（比如新的路由协议，或IP的替代协议），以获得将其广泛部署所需要的信心。
所以导致网络研究界的大部分想法都是没有尝试和测试过的，因此人们普遍认为当今的网络基础设施已经僵化。
意识到问题之后，网络研究一直在努力开发可编程网络，例如研究新的网络架构和分布式系统的全国性网络研究机构提出的GENI。
这些可编程的网络要求程控交换机和路由器（使用虚拟化技术）可以处理数据包的多个相互隔离的实验网络同时进行。
例如，在GENI中，可以设想，一个研究者将得到分配资源的整个网络的切片，包括一部分的网络链路，分组处理元件（例如路由器）和终端主机;研究者可以根据他们的需求进行编程。
一个切片可以拓展到骨干网，接入网，校园网络和工业研究所，其包括配线间，无线网络和传感网络。
虚拟可编程网络能降低创新的门槛，加快在网络基础设施上的创新速度。
但是全国范围的部署设施是雄心勃勃的（也是昂贵的），而且这需要几年来完成这个部署。
本白皮书的重点是更现实的短期问题：作为研究者，我们怎么能在我们的校园网运行网络实验？如果我们知道如何去做，我们会马上开始，然后把技术推广到其他学校，让整个学术界都受益。
为了解决这个挑战，我们需要回答一些问题，其中包括：大学校园网络管理员如何才能舒服地把实验设备（交换机，路由器，无线接入点等）加入到网络中？研究者们如何在不影响其他使用该网络的人的情况下，控制一部分的本地网络？而真正需要哪些功能才能让交换机去支持实验？我们的目标是提出一种能把可编程拓展到校园配线间的交换机的新特性。
一种方法是说服商业“名牌”设备供应商提供一个在交换机和路由器上提供开放的，可编程的虚拟化平台，让研究人员可以部署新的协议，而网络管理员可以因为设备得到很好的支持而感到欣慰。
这在短期内是不可能的，所以我们并不采用。
商用交换机和路由器通常不提供开放的软件平台，更不用说提供虚拟化，无论是他们的硬件或软件的虚拟化。
商业网络的做法是，标准化的外部接口很窄（即只包转发），而所有的交换机的内部灵活性是隐藏的。
而不同的厂商的交换机内部都不同，这没有一个标准让研究者去验证他们的想法。
此外，网络设备厂商是对开放接口里面的盒子紧张是可以理解的：他们花了几年时间部署和调整脆弱的分布式的协议和算法，而且他们担心新的实验会带来网络崩溃。
而且，开放的平台降低了竞争者的准入门槛。
已经存在一些开放式的软件平台，但不具备我们所需要的性能和端口密度。
最简单的例子是有多个网络接口和一个操作系统的个人电脑。
所有知名的操作系统支持接口之间的数据包的路由和已部署的开源路由协议（例如，作为Linux发行版的一部分，或者从XORP[2]）;而且在大多数情况下，它可以修改的操作系统从，而以几乎任何方式处理数据包（例如，点击[3]）。
当然，个人电脑的问题在于性能：一台个人电脑无法支持大学校园配线间的端口数目需求（每个盒子需要100+的端口），也无法满足数据处理的性能（配线间交换机处理数据超过100Gbits/秒，而一个典型的个人电脑还在努力超过1千兆位/秒，而且两者之间的差距正在拉大）。
具有专门的硬件线速处理的现有平台也不太适合在校配线间。
例如，华盛顿大学正在研发基于ATCA的虚拟化可编程路由器--“增强型planelab平台”。
它采用网络处理器，实现多个接口的线速转发。
这种方法是从长期来讲是有用的，但目前只定位于大型交换中心，而且对于大范围在大学配线间部署还是太贵。
另一个极端是NETFPGA,主要用于教学和实验室研究。
NETFPGA是一个低成本的PCI卡，具有可编程能力，能实现数据包的处理，并拥有4个千兆以太网端口。
NETFPGA的限制在于仅仅有4个以太网口，对于大学配线间而言，这是远远不够的。
因此，商业解决方案过于封闭和僵化，而研究解决方案，要么性能或扇出不足，要么太昂贵。
这让研究具有完整通用性，又需要克服其性能和成本的限制的解决方案看起来不太可能。
一个更有前途的在一般和寻求一定程度的交换机灵活性之间折衷的方法是：●适合于高性能和低成本的部署●支持广泛研究的能力●确保实验流量和现网流量的隔离●兼容厂家的平台封闭性需求这篇论文描述了OpenFlow交换机，这是一个尝试满足以上四个要求的初级规范。
2、Openflow 交换机其基本思想很简单：我们知道目前最先进的以太网交换机和路由器都包含流表（通常是基于TCAM构建的），流表能使这些设备能够在在线速下实现防火墙，NA T，QoS和统计收集等操作。
尽管不同的厂商的流表是不同的，但是我们已经发现了在许多交换机和路由器上存在同样的功能集。
OpenFlow正是利用了这些公共功能集。
OpenFlow提供了一个开放的协议，能在不同的交换机和路由器上对流表进行编程。
网络管理员可以将流量分为现网流量和科研流量。
研究人员可以通过选择数据包途经的交换机和处理收取的数据包来控制自己的流。
通过这种方式，研究人员可以尝试新的路由协议，安全模式，寻址方案，甚至替代IP。
在相同的网络中，现网流量完全和科研流量分离，且数据的处理方式并没有发生任何变化。
OpenFlow交换机的数据路径由流表和每一个流表项相关联的动作集合组成。
这个由OpenFlow交换机支持的动作集合是可以拓展的，不过我们接下来就仅仅探讨所有交换机说应该具有的最小动作集。
为了达到高性能和低成本的目的，数据通路必须要经过仔细的设计，已达到应有的灵活性。
这就意味着需要放弃对每一个数据包进行处理的这种操作，转而去找到少数有限但是仍然有用的操作集合。
因此，在论文的后面章节中，将定义所有OpenFlow交换机所需的基本的动作集合。
一个OpenFlow交换机至少由以下三个部分组成：（1）一个流表，其中每一个表项都有动作与之对应，来告知交换机如何处理流。
（2）一个安全通道，用于连接交换机和远程控制程序（称之为控制器），安全通道能允许通过OpenFlow协议在交换机和控制器之间发送命令和数据包。
（3）OpenFlow协议，是一个用于控制器和交换机之间通信的开放标准。
通过制定的标准接口（OpenFlow协议），我们可以从外部定义流表项，从而避免研究者对OpenFlow交换机编程需求。
OpenFlow交换机可以分为两类：专用OpenFlow Switch，这种switch并不支持普通的2层交换和3层交换操作；支持OpenFlow功能的通用商用交换机和路由器，在这种设备上，OpenFlow协议和接口只是作为设备的一个新特性被添加进去。
专用的OpenFlow交换机专用的OpenFlow交换机是哑的数据通路元素，用于在端口之间转发数据包，这种转发行为由远程的控制器决定。
图1为OpenFlow交换机的一个例子。
在这种情况下，流可以被广泛地定义，且仅受限于流表的具体实现。
例如，一条流可以是一个TCP连接，或者是从某个MAC地址或者IP地址发出的所有数据包，又或者是带有同样vlan_tag的数据包，也可以是来自交换机某一个端口的所有数据。
为完成非IP报头的实验，流也可以定义为匹配某一特定报头的数据集合每一个流表项都有对应的动作。
其中最根本的3种如下（OpenFlow专用交换机都应该具备）：1：从指定端口将数据报转发，从而使数据包在网络中得到路由。
在绝大部分的交换机中这个动作应该是以线速完成的。
2：将流的数据封装和转发给控制器。
数据包应该被封装好，然后通过安全通道发给控制器。
通常情况是将新流的第一个数据包发送给控制器，控制器通过这个数据包决定是否添加一条新的流表。
在某些实验情况下，可以将所有的数据包转发给控制器，由控制器决定如何处理。
3：丢掉匹配流成功的数据包。
可以用于安全场景，例如用于防治DOS攻击，和减少主机发出的广播欺骗数据包。
流表中的流表项由三个部分组成：（1）定义流的数据报头域，（2）action域，定义了数据包的处理动作，（3）Statistics域，记录了流的数据包的数量和字节长度，以及最近收到的属于该流的最后一个数据包的接收时间。
第一代被“Type 0”交换机中，它的流表中的header域是一个十元组，如表1所示。
一个TCP流可以是匹配所有10个字段的数据集，而一个IP流并不需要匹配源端口和目的端口域。
Header域中的每个字段都可以通过通配符来完成流的聚合。
例如可以将所有VLAN ID字段不为空的分组数据转发到某个指定的VLAN 中。
详细的OpenFlow交换相关的需求见OpenFlow Switch Specification[6]支持OpenFlow功能的交换机普通的交换机，路由器和接入点等设备可以通过添加流表，安全通道和OpenFlow协议从而得到提升，成为支持OpenFlow的交换机（我们在第5部分列举了一些例子）。
通常，流表可以建立在交换机现有的硬件上，如TCAM；而安全通道和OpenFlow协议可以被移植到交换机的操作系统运行。
图2展示了一个支持OpenFlow协议的商用交换机和接入点的网络。
在这个例子里，所有的流表都由同一个控制器管理。
OpenFlow协议允许交换机可以受多个控制器的控制，从而达到更好的性能和鲁棒性。
我们的目标是实现在现网中进行科研实验，而不影响正常的流量和应用。
因为，为了赢得网络管理员的信任，支持OpenFlow的交换机必须能（通过流表）实现现有流量和实验流量的（由普通的交换机二层管道或者三层管道）隔离。