And o Pen r outer
8. NEXT-ROUTER-DELETE (n.rt, src_set, dst)
For interface table change entries, for example, adding an interface table entry, we can start from the current router and calculate the path from the interface IP prefix to any destination prefix in the area using the recursion calculating the forwarding path algorithm. In deleting an interface entry, we must delete all the filtering table entries con-taining the interface IP prefix as its source IP prefix or destination IP prefix.
For routing table change entries, for example, adding a routing table entry, we can start from the current router and calculate the path from the possible source to the added routing destination prefix using the recursion calculating the forwarding path algorithm. In deleting a routing table entry, we must go through the old path from the cur-rent router toward the destination router and delete the filtering rules with related source-destination prefix pairs of the routers along the old path.
Because the updating process for interface table changes is very similar with the full calculating process, we only describe the updat-ing algorithm for routupdat-ing table changes. The algorithm is shown below.
6 3
IP SOURCE ADDRESS VALIDATION SOLUTION
Comparison of Two Algorithms In the traditional CPF in the cur-rent network architecture, the full calculating process runs periodi-cally. Now, analyze the complexity of the full calculating algorithm.
Suppose that there are n routers. The prefix number of router ri is mi, and the total number of prefix in the intra-AS is m. It means that
m mi i
n =
∑
=0 . For each router, we call the GEN-FILTER-TABLE function.In this function, the size of the src_set is mi, and for each destina-tion prefix, we call the COM-NEXT-ROUTER funcdestina-tion, in which the average recursive depth is the average path length n
2. As a result, for each des prefix, the complexity is n mi
2 . For each router, it is n m mi
2 .
So, for all the routers, the total complexity is n m m nm m nmi
So, every time the full calculating algorithm runs, the complexity is o(nm2).
In InSAVO, because it can acquire notifications for routing updates (thanks to OpenFlow+), it can just run a partial calculating algorithm when needed. Suppose that there is a network topology change and that CPF receives an interface update entry and an n routing update entry (one for each router). For one interface prefix added, the complexity of calculating the filter rules considering it as source will cost n m
2 (n 2 is recursive depth; m is the number of dst prefixes). Considering it as a destination will cost i n m nmi
n
2 2
1
∑
= = (n2 is recursive depth, starting from every other router; mi is the size of the src_set). As for the rout-ing update, for each router, there is one routrout-ing update change, and we will call the COM-NEXT-ROUTER function. mi is the size of the src_set, whereas n m2 i is the recursive depth. So, for all the routers, the total complexity is n m nmi the total complexity of a partial calculating algorithm for one network topology change is O(nm).Comparing the two algorithms, we can see that the traditional CPF in the polling mode will cost o(nm2) every polling interval time, whether or not the network topology has changed. However, in InSAVO, it first runs full calculating and runs partial calculating only when it receives updates. When there is no network topology change, it uses much less CPU resource than the traditional CPF.
Even when there is an update, as every network topology change will cause O(nm), only when the network topology change rate is bigger
than m
polling interval time m O nm= O nm
( )
( )
2 , InSAVO will cost much CPU resource than traditional CPF. Even so, however, in such an unstable network, the false positive of filter rules generated by tradi-tional CPF would be very large, thus resulting in very poor filtering performance. Considering the CPU use and the filtering performance of CPF, we can see that InSAVO is much better than traditional CPF.
Combination of Routing and InSAVO in OpenFlow Architecture
A New Algorithm to Generate FlowTable for Both Routing and Filtering InSAVO is a way to add intra-AS source address validation func-tions (CPF) in addition to today’s intra-AS routing protocols (OSPF, etc.) by OpenFlow technology. In this section, we propose to combine routing and InSAVO together in OpenFlow architec-ture by generating a forwarding and filtering table (two-dimen-sional forwarding table) by one single algorithm as an OpenFlow application.
In this new algorithm, we still use Dijkstra, which is used in today’s OSPF routing protocol.
Definition 3.1
Let Q denote the set of all routers v in the network:
v denotes a router in Q;
P(v) denotes all IP prefix at router v;
I(p) denotes the router interface of prefix p;
I(v1,v2) denotes the ingress interface of router v2, where v1 and v2 are connected together with a link;
6 5
IP SOURCE ADDRESS VALIDATION SOLUTION
O(v1,v2) denotes the egress interface of router v1, where v1 and v2 are connected together with a link;
dist[v] denotes the distance from the source router s to the destina-tion router v;
dist_between(u,v) denotes the distance between routers u and v;
previous[v] denotes the previous neighbor of router v on the path from the source to the destination;
following[v] denotes the following neighbor of router v on the path from the source to the destination;
FlowEntry(P1, P2, I, O) denotes a FlowTable entry, where P1 denotes the prefix of the source address; P2 the prefix of the destination address; I the ingress interface; O the egress interface; and F(v).add (FlowEntry(P1, P2, I, O)) denotes that the FlowTable entry is added at router v.
Algorithm 3.1
For a source router s, we calculate all the paths that start from s and end at all routers in Q:
1. For every router v in Q, set dist[v] = ∞ and dist[s] = 0; for all prefix in router s, generate a four-tuple FlowTable: for all P1, P2 ∈ P(s)(P1 ≠ P2), add FlowEntry (P1, P2, I(P1),I(P2)) in router s.
2. Select a router u from Q, where dist[u] is the minimal. If dist[u] = ∞, then go to the end. Otherwise, for all prefixes in s and u, add four-tuple FlowTable in all routers on the path from s to u: for P1 ∈ P(s), P2 ∈ P(v), recursively generating FlowEntry(P1, P2, I(previous[v], v), I(v,following[v]) in router v, previous[v],…, s. The recursive algorithm is shown below:
node := v
following[node] := undefined while node ! = s
for each P1 in P(s) for each P2 in P(dest)
if following[node] = undefined
F(node).add(FlowEntry(P1, P2, I(previous[node], node), I(P2)))
else
F(node).add(FlowEntry(P1, P2, I(previous[node], node), O(node,following(node))))
end if
oldnode:= node node:= previous[node]
following[node]:= node end for
end for end while
for each P1 in P(s) for each P2 in P(dest)
F(s).add(FlowEntry(P1, P2, I(P1), O(s,following[s]))) end for
end for
3. For all v ∈ neighbor(u), if dist[u] + dist_between(u,v) < dist[v], then previous[v] = u.
4. Repeat steps 2 and 3, until Q is an empty set.
Algorithm 3.1 is used to calculate FlowTable entries when router s is selected as the source node. Then, we can repeat n times (by select-ing each router in the network as the source node) to calculate all the FlowTable entries in the whole network (n denotes the total number of routers).
Evaluation
Now, we analyze the complexity of this algorithm:
1. The first step in Algorithm 3.1: First, we initialize the dist[];
the complexity is O(n). Then, we construct the four-tuple table. We let m(s) denote the number of prefixes in router s;
then it costs O(m(s)2). Because we need to calculate it for all routers in the graph m s
s Graph
( )2
∈
∑
, then the total complexity is O(m(s)2). Let m denote the total number of prefixes in all routers; then the complexity is O(m2).6 7
IP SOURCE ADDRESS VALIDATION SOLUTION
2. The second step in Algorithm 3.1: First, we select a router from Q by the following step: selecting the minimal cost, which is n n( −1)
2 (i.e., O(n2)); then the cost for generating four-tuple table entries[l·m(s)·m(u) entries, where l denotes the number of routers from s to u], which is l·m(s)·m(v1) + l·m(s)·m(v2) +……+
3. The third step in Algorithm 3.1: The complexity is O(E), where E is the total number of links in Q.
4. Then, the total complexity of the second and third steps in Algorithm 3.1 is O n E m s l m vi i
Then, the complicity can be denoted as O(mn2).
Although Algorithm 3.1 brings more complexity, in OpenFlow, we make use of CPU in a server to calculate the FlowTable. We know that the CPUs in a server are much more powerful than a CPU in a router. In our experiment with the Tsinghua campus network topology and prefixes at each routers (a total of 21 routers and 473 prefixes, i.e., n = 21, m = 473), we used a middle end server with 2.40-GHz CPU and 2-GB memory. The experimental results show that InSAVO costs 4.137 s, whereas Algorithm 3.1 costs 2.929 s. The reason that InSAVO costs more time is because it contains more match operations that costs more CPU time. Therefore, the experimental results show that the OpenFlow-based central calculation is feasible in the real network.
In InSAVO, the total number of generated table entries is the for-warding table entries n·m (generated by OSFP as a distributed routing protocol) and the filtering table entries n·m2 (generated by InSAVO as an OpenFlow application). In Algorithm 3.1, the total number of four-tuple FlowTable entries is just n·m2. We know that the hardware table resource in a router is valuable, so the new approach saves the valuable table resource.
Jun Bi
4466 5580 39,923 79,076 69,647 110,952 76,208 7168 1798 13,801 2210 26,431 9422 10,004 26,344 5085 1698 20,512 25,926 38,840 95,254
2385 7092 18,210 49,285 34,509 57,915 39,394 10,800 3536 14,800 10,805 45,701 20,318 34,607 17,349 8657 14,461 13,296 29,517 27,127 63,813
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Number of table entries
Routers Figure 3.10 Comparison of table entry consumption of InSAVO and Algorithm 3.1.
6 9
IP SOURCE ADDRESS VALIDATION SOLUTION
We did experiment with the Tsinghua campus network topology and prefixes at each router (a total of 21 routers and 473 prefixes, i.e., n = 21, m = 473). As shown in Figure 3.10, the dark bar denotes the filtering table generated by InSAVO, and the gray bar denotes the filtering table generated by Algorithm 3.1.
From the experimental result, we can tell the difference between the two approaches. In InSAVO, it costs more filtering tables at some core routers, whereas Algorithm 3.1 generates a more balanced filter-ing table. The reason is that, in InSAVO, the routfilter-ing table is affected by some manual configuration and policies. So, if we can combine the forwarding and filtering calculations with a centralized OpenFlow approach, it will generate more optimized FlowTable entries.
Another observation is that, although the theoretical estimation of the filtering table size is O(n·m2), in reality, in most routers, the table size is quite small, which makes the solution more realistic. However, in some core routers (such as routers 4, 6, and 21), the total number of FlowTable entries is still huge. Therefore, the study of FlowTable compression is still a future research direction.
Conclusion and Future Work
In this chapter, we illustrate an intra-AS source address validation application to the OpenFlow network architecture.
1. We extended the OpenFlow protocol based on the challenges of the production network. Then, we add OpenFlow exten-sion to a commercial router by software update, and we call it OpenRouter. OpenRouter not only can provide software-defined abilities to introduce some new network features but also can give a tradeoff between existing hardware and evolu-tion cost by software update inside a network device.
2. We applied the OpenFlow extension into the Nox controller (we name it Nox+). We designed and implemented a new com-munication interface between Nox+ and Application, which can be a generic communication interface between any network operating system and NAPP. Then, we implement the intra-AS source address validation method CPF as an application, and we call it InSAVO. InSAVO listens to and gets the routing
change information in time, and then generates filtering table in OpenFlow table format. The unified OpenFlow interfaces and timely routing update make InSAVO more deployable and efficient than CPF in the traditional network architecture.
3. The core algorithms of InSAVO are introduced. Thanks to the routing updates notification feature provided by it, we design partial calculating algorithm and invoke it only when network update happens. Compared with the traditional polling com-puting method, it will save much CPU resources and will get better filtering performance. Moreover, a new algorithm that combines both forwarding and filtering calculation by generat-ing four-tuple OpenFlow table entries is introduced. The evalua-tion in the Tsinghua campus network shows that this algorithm saves more valuable FlowTable entries in the router and that the computation cost is acceptable for a CPU in the server.
Although the evaluation proves that the proposed solution is fea-sible at the production network, we observed from the experimen-tal results that the size of the FlowTable in some core routers is still explosive. In future works, we will study how to handle the explosive FlowTable. We are also working on the enhancement of the controller software to upgrade it as a complete network operating system, which is called TUNOS [10].
Acknowledgments
This work is supported by the National High-Tech R&D Program (“863” Program) of China (no. 2013AA010605) and the National Science Foundation of China (no. 61073172).
References
1. McKeown, N., T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker et al. 2008. OpenFlow: Enabling innovation in campus networks. ACM Computer Communication Review 38(2):69–74.
2. Yao, G., J. Bi, and Z. Zhou. 2010. Passive IP traceback: Capturing the origin of anonymous traffic through network telescopes. ACM Computer Communication Review 40(4):413–414.
71
IP SOURCE ADDRESS VALIDATION SOLUTION
3. Wu, J., J. Bi, X. Li, G. Ren, and K. Xu. 2008. A source address validation architecture (SAVA) testbed and deployment experience. RFC5210.
4. Yao, G., J. Bi, and P. Xiao. 2011. Source address validation solution with OpenFlow/Nox architecture. In Proceedings of the 19th IEEE International Conference on Network Protocols (ICNP11), Vancouver, pp. 19–24.
5. Yao, G., J. Bi, and P. Xiao. 2013. VASE: Filtering IP spoofing traffic with agility. Computer Networks (Elsevier) 57(1):243–257.
6. Feng, T., J. Bi, H. Hu, G. Yao, and P. Xiao. 2012. InSAVO: Intra-AS IP source address validation solution with OpenRouter. 31st IEEE International Conference on Computer Communications (INFOCOM12), Orlando, FL.
7. Feng, T., J. Bi, and H. Hu. 2011. OpenRouter: OpenFlow extension and implementation based on a commercial router. In Proceedings of the 19th IEEE International Conference on Network Protocols (ICNP11), pp. 141–
142, Vancouver, Canada.
8. Gude, N., T. Koponen, J. Pettit, B. Pfa, M. Casado, N. McKeown, and S.
Shenker. 2008. Nox: Towards an operating system for networks. ACM Computer Communication Review 38(3):105–110.
9. Gamma, E., R. Helm, R. Johnson, and J. Vlissides. 1995. Design patterns:
Elements of reusable object-oriented software, Addison-Wesley.
10. Feng, T., J. Bi, and H. Hu. 2012. TUNOS: A novel SDN-oriented net-working operating system. In Proceedings of the 20th IEEE International Conference on Network Protocols (ICNP12), pp. 1–2, Austin, TX.
73