Software Defined Network week 2

学习目标：

• 区分控制平面和数据平面
• 识别论证平面功能
• 能够距离
  Key Terms

Mininet: A network emulation platform that has the ability to create a virtual OpenFlow network; controllers, switches, hosts, and links on a single real or virtual network.
Controller: A software program (typically running as a separate entity on the network, such as a server) that executes the control logic for the network and sends commands to the data plane to affect forwarding behavior. Example controllers include POX, NOX, and Onix.
Control channel: The communications channel over which an SDN controller communicates with the underlying network switches. OpenFlow has a standard control channel that allows an OpenFlow controller to update the switch’s forwarding table entries.



Terms

OpenFlow Interface: a standard open interface between the OpenFlow controller and the OpenFlow programmable devices (i.e., switches etc)

OpenFlow Controller: sits above the OpenFlow interface. The OpenFlow reference distribution includes a controller that acts as an Ethernet learning switch in combination with an OpenFlow switch. You’ll run it and look at messages being sent.

OpenFlow Switch: sits below the OpenFlow interface. The OpenFlow reference distribution includes a user-space software switch. Open vSwitch is another software but kernel-based switch, while there is a number of hardware switches available from Broadcom (Stanford Indigo release), HP, NEC, and others.

dpctl: command-line utility that sends quick OpenFlow messages, useful for viewing switch port and flow stats, plus manually inserting flow entries.

Wireshark: general (non-OF-specific) graphical utility for viewing packets. The OpenFlow reference distribution includes a Wireshark dissector, which parses OpenFlow messages sent to the OpenFlow default port (6633) in a conveniently readable way.

iperf: general command-line utility for testing the speed of a single TCP connection.

Mininet: network emulation platform. Mininet creates a virtual OpenFlow network - controller, switches, hosts, and links - on a single real or virtual machine. More Mininet details can be found at the Mininet web page .

cbench: utility for testing the flow setup rate of OpenFlow controllers.

Using dpctl

dpctl is a utility that comes with the OpenFlow reference distribution and enables visibility and control over a single switch’s flow table. It is especially useful for debugging, by viewing flow state and flow counters. Most OpenFlow switches can start up with a passive listening port (in your current setup this is 6634), from which you can poll the switch, without having to add debugging code to the controller.

Create a second SSH window if you don’t already have one, and run:

$ dpctl show tcp:127.0.0.1:6634

The ’show’ command connects to the switch and dumps out its port state and capabilities. Here’s a more useful command:

$ dpctl dump-flows tcp:127.0.0.1:6634

Since we haven’t started any controller yet, the flow-table should be empty.



delay是一次的，rtt要四次
h2 ifconfig
When you do a ”dpctl dump-flows” you can see an ”idle timeout” option for each entry. This means that the flow will expire after this many secs if there is no incoming traffic. Run again respecting this limit, or install a flow-entry with longer timeout.

So as we know, if a particular host wants to send traffic to another host IP address, it will use the address resolution protocol, or ARP, to send out a broadcast query that asks, who has a particular IP address? In other words, what is the MAC address for this particular IP address, that I would like to send to? And the trick here is that we don’t want the host, the destination host, to respond. Because it still thinks it has its old MAC address. What we can do in this case, because we have separate network control, is to use something they call a fabric manager, or a separate controller to basically intercept all of these r-queries. Or all these queries that are wanting to discover MAC addresses for particular IP addresses. So in this particular switch, receives a query that says, tell me the MAC address for a particular IP address. That switch can kick that query to a central controller or a fabric manager which can then reply with the topology dependent pseudo MAC, or P MAC. And then all of the traffic can be rewritten with the appropriate source and destination topology dependent MAC addresses. So that’s just one example of how a separate controller and a data center can allow a network administrator to get the best of both worlds. In terms of both topology dependencies and the benefits of a Layer 2 topology. We’ll look at data centers a lot more, in a particular module where we look at case studies of SDN later in the course. But this hopefully gives you a flavor of the types of benefits that separating control and data plane in a network can offer to network operators and administrators.



punt on 参与

Network Information Base (NIB) is a term used to describe the network graph that is built by a controller. Usually the network graph is built by using OpenFlow and other methods to build unified view of network topology.

The term was oft-used in a whitepaper on the Onix OpenFlow controller by Teemu Koponen et al but may be out of use by now.

但是bdp状态和逻辑是通过路由器分解的没有一个路由器有完整的bgp状态 每个路由器根据整个自治系统的局部和不完整的视图做出路由决策

它运行在一个自动系统路由的完整视图上 并为任何s中的所有路由器计算这些路由

One of the problems with BGP is that configuration state is decomposed across the routers inside a single autonomous system. So representing a single coherent network wide policy is quite difficult. For example consider the implementation of a simple policy such as don’t advertise routes learned from UUNet to Sprint.
3:15
In this case, the configuration is decomposed across routers inside the AS. So the routes themselves must carry state.
3:26
In the first portion of the configuration, routers assign routes from UUNet by tagging the routes.
3:34
At the ingress router, C.
3:36
In a separate part of the configuration at router A. In a separate part of the configuration at router A there’s a separate part of the configuration that looks for that particular tag that was set at C and implements the appropriate filter to ensure that, that set of routes are not readvertized to Sprint. This simple policy is decomposed to cross multiple routers making configuration relatively
4:02
difficult. By contrast the RCP centralizes configuration, it implements policies for the entire AS. It knows about sessions to all other ASes. An infamous policy, in terms of the relationships with those ASes. This results in much simpler configuration since the routers themselves don’t have to tag routes with state.

Another problem with BGP, is that it interacts with underlying protocols in strange and unexpected ways. such as IGP
In this example the router inside the AS, C1 learns a BGP route to some destination D from R1. And C2 learns a BGP route to the same destination from router RR2. Because of the way the IGP weights shown with numbers here. Are configured, C1 will send traffic to D via the shortest path to RR1 which is via C2. C2 on the other hand sends packets to D via a path that traverses both C1 and RR2 because the shortest path to the route it learned via RR2. Is via C1. This particular configuration results in a persistent forwarding group between C1 and C2. Each of which think they must forward the traffic to D via the other. The forwarding loop results because no single router has a complete view of the autonomous system state.

On the other hand. The RCP can compute routes with complete information.
The RCP learns all externally learned routes and computes consistent router-level paths across the entire autonomous system. As a result, there’s intrinsic loop freedom and convergence. An RCP, actually doesn’t even have to stick to the default decision process. It could even pin paths for traffic engineering and other purposes. By setting up custom paths between routers inside the AS and any egress router.

. While these features are appealing, of course an important question remains of how we get from here to there. In other words how we get from the situation where all the routers are running iBGP.
6:16
With one another making independent decisions to a state where the RCPs are making the decisions and communicating the BGP routes with one another across autonomous systems.

In the first phase, only a single autonomous system has to deploy an RCP. Before phase one, we just start with conventional iBGP.
Afterwards, a single RCP learns the best iBGP routes and iGP topology. Inside a single autonomous system. In this situation, only a single AS deploys RCP, but that single AS still gets the benefits of that deployment.

计算A不是最近的，也可以选定A作为出口
An example application of this limited deployment is controlling path changes. For example, as we know in BGP.
Routers take routes to the nearest exit, or egress, via the shortest IGP path.
So for example, router C might take a path on the left to router A. But if that particular length fails, IGP weights will change, and the shortest path from C to the exit A. Might increase.
What we don’t want to have happen is for that path from C to leave via different egress. For example via B. In standard BGP there’s no way to change that because C will always choose the route to the nearest exit. But the RCP can pin egress points. Even as the IGP weights change, ensuring that all of the routers inside the AS continue to select A as the egress router. Even as links fail, and internal topology changes.

In the second phase, a single AS can, not only control routes inside its AS but can implement AS-wide policy. Based on the eBGP routes it learns from its neighbors.
This requires an additional deployment step where by the RCP must learn not only all the internal routes, but the eBGP routes from it’s neighbors. So it must have additional eBGP sections configured.

One particular example is efficient aggregation of IP prefixes. Let’s suppose that two egress routers each learn a less specific prefix and a more specific prefix that’s contained inside that larger
prefix. In this case a router inside the autonomous system.Might want to aggregate these two prefixes since they overlap but neither of the routers inside the AS know whether it’s safe to do so because it may be the case that some routers need to forward traffic to a specific exit point based on the more specific route the egress router learned.

One the other hand, an RCP can determine which routers need more specific routes, and which routers can get by with less specific routes. In this case for example the RCP can determine that it’s not safe to aggregate, because a downstream router will make different decisions about where to forward traffic to different egresses based on those more specific prefixes.

In the third phase, all ASs have RCPs deployed, and the RCPs communicate with one another via some inter-AS protocol, which might not even be BGP.

An application of this third phase of deployment is more flexible routing through better network management and various protocol improvements.

Once RCPs are talking to one another, it’s possible to replace PGP entirely. So there is a very broad range of applications that could be deployed in this third phase.

In summary the RCP embodies two principles for inter-domain routing. It treats an AS as a single logical entity allowing it to compute consistent routes using a complete AS-wide view. By acting as a central control point for the AS it can also control various routing protocol interactions that were previously difficult to control. The separation of routing and control allows for simpler and more expressive routing configuration. Intrinsic robustness by avoiding forwarding loops and enabling faster convergence, and the ability to enable new applications and innovations including the opportunity for new types of traffic engineering applications.

The 4D Network Architecture

The control and data planes which we’ve all ready talked about, as well as a management plane, which constructs a network wide view, and is used to configure the routers to achieve various network wide goals. The control plane that the 4D architecture talks about is a little bit different than the control plane we’ve been talking about this far. And then it just really is talking about the routing protocols, the track topology changes, compute routes, and then install forwarding tables but isn’t really talking about something that would have a network-wide view. So, in that sense, we are talking about a control plane in the strictly conventional sense, something that would just compute routes but not do anything more sophisticated like achieve network-wide management calls.

The goal in the 4D routing architecture is to remove or minimize this conventional routing plan. In other words, it’s very similar to the goals of the RCP paper, which aims to remove the functions of routing from the routers themselves and move that into a separate software system. 路由器不再路由
The benefits of doing so include faster innovation in network management by moving a lot of the intelligence into software and removing the dependence on vendors in the IETF. Another consequence is simpler management systems. Since instead of inverting control plane operations to figure out what the network is going to do as a result of a particular routing configuration, the network management system can simply directly control the forming table of the network. Interoperability between vendors becomes easier because compatibility is only necessary in the on the wire protocols. For example, a protocol like BGP could be used to control the routers, but as long as the intelligence of figuring out how to populate routing tables is done in software, we have much more flexibility in designing that intelligence.
Routers should, hopefully, also be simpler and cheaper since there would be little or no software on the router. We’re seeing that kind of trend come to fruition today in the notion of white box switches.

• It’s possible to remove this conventional control plane, or the routing intelligence from the routers because control software can run elsewhere.
• System overhead can be amortized because a lot of functions are duplicated across routers

The 4D architecture has three goals. One is to achieve network level objectives, rather than router level objectives, and network operators should be configuring the entire network to achieve a goal, rather than individual routers. Those goals might include minimizing the maximum link utilization across the network, and ensuring connectivity under all layer two failures. A second goal of the 4D architecture is achieve network wide views. The complete visibility of what’s going on in the network allows for more coherent decision making.These views might include views of the network wide traffic matrix, the topology and the status of various equipment across the network. The third goal of the 4D architecture is direct control. The software subsystem that controls forwarding should have direct sole control over data plan operations such as packet forwarding, filtering, marking, and buffering.

Here are the 4D plans. At the lowest level we have the data plane, which is exactly as it exists today. The responsibility of the data plane is simply to forward traffic according to what is in the forwarding tables. At the top level, we have the decision plan, which performs all management and control. It’s essentially the brains of the network, if you will. It comprises all of the logic.That makes decisions about what should ultimately go in the data plane. In between the decision and the data plane, we have two other planes.
One is the dissemination plane that simply a control channel that allows the decision plane to receive a network-wide view from the data plane and to directly control the data plane based on decisions that it makes. In the context of RCP, the dissemination plane is, for example, the BGP routing protocol, which the RCP uses to get a network wide view, as well as to push routing decisions to individual routers. Finally, we have the discovery plane, which allows the decision plane. To discover topology, monitor traffic, and discover other things about the network.

The decision plane includes essentially all functions that operate on a view of the entire network, and perform any network level objectives. These include path selection and traffic engineering, reachability control, configuration of VPNs, and so forth.
The Dissemination Plane includes all functions that support the creation of a network wide view, such as topology discovery and other measurements. It is also responsible for installing statements of the data plane.

The key observation of the 4D Architecture is that good abstractions should reduce complexity or as before the routing protocol contain a lot of complexity and a lot of duplicated function with things that network operators would want to do at higher levels in this so called management plane. In the 4D architecture, the dissemination plane becomes simply a control channel between the decision plane and the data plane. In other words, routing protocols become nothing more than a control channel, and all complex logic resides in the decision plane. Let’s look at two network management applications in the context of 4D.

In traffic engineering, topology information from the dissemination plane is used to both compute the traffic matrix and to compute the paths that should achieve at the particular network level objective.

Traffic engineering also takes traffic load information from the data plane and passes it to the decision plane for help in computing that traffic matrix.

Once the resulting tasks are computed, the decision plane uses the dissemination plane to push those decisions back to the data plane.

As another example, lets suppose that we want to use access control or some other mechanism to isolate traffic. In this case, we have the same type of interaction as in traffic engineering, but the operator might also specify a reachability matrix, that specifies who should be able to talk to who and who should not be able to talk to who. So in addition to pushing paths, the decision playing might also push axis control lists. The interesting thing about this example is that because the decision plane sees both traffic engineering and access control , it can perform decisions that optimize traffic load while still respecting reachability constraints. This is in stark contrast to a conventional network where these configuration options are often performed independently.

the decision plan where logical centralized controllers convert network wide objectives into the state that handles packet and forwards traffic

in phase 1 RCP只和AS边界路由器交流，它只能得知每个路由器到一个目的地的最佳路由，并不是所有边界路由器的路由都会学习
它和route reflector 不一样，它能每个路由器选择不同的最佳路由
应该只选上面两项

在由10个路由器组成的全网状IBGP网络中，仅需要90个单独的CLI语句（分布在拓扑中的所有路由器中）来定义每个对等方的远程AS：这很快就变得令人头疼。RR拓扑可以将这90条语句减少到18条，从而为ISP管理的较大网络提供了可行的解决方案
RR服务器根据以下规则在AS内部传播路由：

如果从非客户端对等体收到路由，则仅向客户端和EBGP对等体反映。
如果从客户端对等方收到路由，则将其反映给所有非客户端对等方，也要反射给客户端对等方（路由的发起者除外），并反映给EBGP对等方。

最后一条的报错信息意味着我完全不懂traffic engineering是啥
Traffic engineering is a method of optimizing the performance of a telecommunications network by dynamically analyzing, predicting and regulating the behavior of data transmitted over that network. Traffic engineering is also known as teletraffic engineering and traffic management.
只选上面三项

在phase2的时候，和邻居AS的对等体建立EBGP绘画，它能得到邻居所拥有的的信息
可以减小路由表的大小


现在的路由器和交换机都变得更简单了——whitebox switches

keep track of topology 这个选项有点莫名其妙啊