阅读文章《The Road to SDN: An Intellectual History of Programmable Networks》，并根据所阅读的文章，书写一篇博客，回答以下两个问题：
1.过去20年中可编程网络的发展可以分为几个阶段？每个阶段的贡献是什么？
1) ac-tive networks (from the mid-1990s to the early 2000s),which introduced programmable functions in the networkto enable greater to innovation;
(2) control and data planeseparation (from around 2001 to 2007), which developedopen interfaces between the control and data planes; and
(3) the OpenFlow API and network operating systems(from 2007 to around 2010), which represented the firstinstance of widespread adoption of an open interface anddeveloped ways to make control-data plane separationscalable and practical.
2.网络虚拟化与SDN的关系？
Network virtualization (an abstraction of the physical network in terms of a logical network) clearly does not require SDN. Similarly, SDN (the separation of a logically
centralized control plane from the underlying data plane)
does not imply network virtualization. Interestingly, however, a symbiosis between network virtualization and SDN
has emerged, which has begun to catalyze several new research areas. SDN and network virtualization relate in
three main ways:
• SDN as an enabling technology for network virtualization. Cloud computing brought network virtualization to
prominence, because cloud providers need a way to allow multiple customers (or “tenants”) to share the same
network infrastructure. Nicira’s Network Virtualization Platform (NVP) [53] offers this abstraction without
9
requiring any support from the underlying networking
hardware. The solution is use overlay networking to provide each tenant with the abstraction of a single switch
connecting all of its virtual machines. Yet, in contrast to
previous work on overlay networks, each overlay node
is a actually an extension of the physical network—a
software switch (like Open vSwitch [57,63]) that encapsulates traffic destined to virtual machines running on
other servers. A logically centralized controller installs
the rules in these virtual switches to control how packets
are encapsulated, and updates these rules when virtual
machines move to new locations.
• Network virtualization for evaluating and testing SDNs.
The ability to decouple an SDN control application from
the underlying data plane makes it possible to test and
evaluate SDN control applications in a virtual environment before the application is deployed on an operational network. Mininet [41, 48] uses process-based virtualization to run multiple virtual OpenFlow switches,
end hosts, and SDN controllers—each as a single process on the same physical (or virtual) machine. The use
of process-based virtualization allows Mininet to emulate a network with hundreds of hosts and switches on
a single machine. In such an environment, a researcher
or network operator can develop control logic and easily
test it on a full-scale emulation of the production data
plane; once the control plane has been evaluated, tested,
and debugged, it can then be deployed on the real production network.
• Virtualizing (“slicing”) an SDN. In conventional networks, virtualizing a router or switch is complicated,
because each virtual component needs to run own instance of control-plane software. In contrast, virtualizing a “dumb” SDN switch is much simpler. The FlowVisor [68] system enables a campus to support a testbed for
networking research on top of the same physical equipment that carries the production traffic. The main idea
is to divide traffic flow space into “slices” (a concept introduced in earlier work on PlanetLab [61]), where each
slice has a share of network resources and is managed
by a different SDN controller. FlowVisor runs as a hypervisor, speaking OpenFlow to each of the SDN controllers and to the underlying switches. Recent work
has proposed slicing control of home networks, to allow different third-party service providers (e.g., smart
grid operators) to deploy services on the network without having to install their own infrastructure [89]. More
recent work proposes ways to present each “slice” of
a software-defined network with its own logical topology [1, 22] and address space [1]