3. Despliegue tabla de opciones y haga clic en selección por atributos. Figura 24 Selección de atributos
6.2.3 Información que se puede obtener de la GDB
CDN replica server
The results of 50 tests are shown in Table 4.3 below:
h1 h4
Reference mean load time (together) mean: 236 std: 2.26
Mean load time with new CDN introduced mean: 56.9 std: 17.4 mean:135.2 std: 16.7 Table 4.3: Time taken to fully traverse and load the thesis.com testpages, in seconds.
The singular reference load time in this test indicates how long it took on average for both hosts, h1 and h4 to finish loading the thesis.com testpages when both hosts were accessing the congested CDN replica server h2 simultaneously. It is quite surprising to see that the standard deviation is comparatively low for this measurement. When this measurement was being taken, the two hosts would appear to load the website in random chunks, and ‘take turns’ in downloading content from h2. This measurement measures the entire time that h2 is put under load, so even if one host has finished the thesis.com testpages, the measurement continues until the other hosts finishes their run.
The large values for standard deviations seen in the other measurements here are caused via h1. If h1 was occupied with GET request responses from h2 at the 30 second mark, then it could take ten to twenty seconds for h1 to finish those downloads, and then get rerouted by our proposed mechanism. This had a flow on effect onto h4, whereby it would sometimes have to ‘wait’ for h1 to use another link, so h4 could utilise the now uncongested link.
As can be seen, the mean time for h1 to finish loading the thesis.com testpages is less than half that of h4’s. Similarly, mean time for h4 to finish loading the thesis.com testpages is almost half that of the reference time. This indicates that our proposed
ISP CDN request rerouting system can be used to utilise the introduction of rapidly established CDN replica servers to increase QoE for both users of the ISP’s network, but also for users outside the ISP’s network by indirectly reducing the load on their links.
Chapter 5
Evaluation
For the sake of convenience, we will reiterate the design goals specified in Chapter 3 here. Our proposed design should be:
1. Able to work around DNS caching/prefetching 2. Able to fully utilise network information 3. Easy to configure
4. Incrementally implementable
5. Able to utilise and act on the ability to rapidly create virtual CDN replica servers 6. Scalable for network and service expansion
7. Able to provide access to the CDN for end users that are not customers item of the ISP
We will now assess the effectiveness of our proposed request rerouting mechanism for ISP operated CDNs by discussing and evaluating the results achieved in the previous chapter.
5.1
Results
The experiments outlined in Section 3.3.2 were designed specifically to test if our design met goals 1, 2, and 5. As the results in Chapter 4 indicate, our proposed implementation of an ISP CDN’s request rerouting mechanism via NAT augmented DNs is successful in those areas. The simplicity of the table-miss flow rules employed by our Ryu controller as defined in Section 3.3.1.2, and the usage of simple shell scripts and REST APIs indicate that our system should be easy to integrate and configure in an ISP’s network, thus fulfilling goal 3. Because the proposed request rerouting mechanism is to be used as an addition to traditional DNS routing mechanisms, it is possible for an ISP to implement that first, and then incrementally introduce OpenFlow-enabled switches throughout their network as demand requires. This fulfills goal 4. Goal 7 is similarly fulfilled: Users outside of the ISP network can simply use the traditional DNS request rerouting method, they
just wont get the benefits as demonstrated in this thesis. The only goal not covered by the results of our experiments and/or mechanism design is goal 6; whether or not our proposed request redirection mechanism is scalable.
The results of our testing also confirms our claims about the ill effects of client side DNS caching. For example, in our first test procedure, browsers simply timed out, or had users refreshing for over a minute in order to get any kind of response.
5.2
Discussion
Our proposed request rerouting mechanism for ISP operated CDNs ended up being quite visibly successful. Load times were often cut in half 1 or more, compared to a request
rerouting system such as traditional DNS. Granted, the situations our tests described were edge cases that don’t happen very often in current enterprise networks. But as Akamai and Justine Sherry et al. [3, 37] claim, the way forward for ISPs and CDNs in the future involves the usage of cloud services to rapidly adapt to changes in the networking landscape and demands. This means that situations where our proposed request rerouting mechanisms are beneficial will only increase in the future.
The results of the thorough investigation into the effects of client side DNS caching are a bit surprising. Issues like how timing the refreshing of a page has an effect on how soon the page successfully refreshes are still not fully understood by the author. While we certainly expected some errors to occur due to DNS caching such as pages timing out, timing errors certainly were not. Unexpected behaviour such as this is exactly why such an investigation had to be undertaken, however.
Unfortunately, a rigorous examination on the scalability of of our proposed mechanism has not been undertaken. Because of the current infancy of SDN technology compared to legacy networks, published performance and scalability research is not yet widely available, especially for a purely reactive 2 system like the one we have proposed. Indeed, this may
be the cause of the 5 second gap between the reference timing and the successfully routed timing in our first two networking experiments. Adam Zarek [40] has done some research into the impact of flow timeout length on SDN performance, and indicates that a heuristic matching on TCP patterns is desirable. Given that the flow rules added by our controller are all TCP, and are designed to be short lived3, future work on determining the scalability
of our proposed mechanism looks promising.
A potential solution to possible future scalability problems is to move our proposed request rerouting mechanism away from the ISP’s edge router, and instead into the home routers and devices of home owners. This way, instead of a singular device having to
1Note that this depends on network context; rerouting someone from a 10Mbit connection to a 5Mbit
connection will obviously increase their load time. In the context of CDN request rerouting however, the reason you’re performing rerouting in the first place is to provide them with a faster connection to content.
2A reactive SDN system is one in which all new flows are sent to the controller for inspection. In our
set up, all previously unseen TCP flows are sent to the controller to determine if it is going to the right CDN node or not.
3Our flow rules are only of use when there’s a possibility of a user utilising cached DNS information,
handle thousands of flows, a single device handles tens of flows per household. Similar networking tools and APIs have already been researched [41], which indicates that future work on this request rerouting tool could indeed be brought into the home networking space.
Chapter 6
Conclusion
In this thesis we have successfully demonstrated a request rerouting mechanism for ISP operated CDNs. It is able to transparently reroute users away from nonoptimal CDN replica servers to optimal ones in the situation that the user has stale DNS information due to client side DNS caching, or if network conditions require it. It utilises SDN techniques to achieve this, using the OpenFlow1.3 spec on an OpenFlow enabled switch running in a mininet virtualised network. A controller operating on the Ryu framework allows the request rerouting mechanism to occur, by installing NAT and DNAT rules that act on TCP flows.
Such a request rerouting mechanism can find much use in both ISP operated CDNs, as well as ISPs that are collaborating with CDNs to provide a unified service. Current research shows that future requirements and design goals for ISPs include the ability to rapidly implement cloud-based services. Our proposed request rerouting mechanism offers an easily configured, incrementally implementable solution that can perform that role exactly.
We have also performed a first of it’s kind analysis of the effects of client side DNS caching on DNS based CDN request rerouting mechanisms. This analysis revealed that client side DNS caching can lead to a degradation in Quality of Experience and Quality of Service experienced by the end user performing that caching.
6.1
Future Work
Because this thesis dealt mainly with the request rerouting mechanism, and not the request rerouting algorithm to go with it, the natural extension of this work is to develop a request rerouting algorithm that can utilise the request rerouting mechanism proposed by this thesis efficiently.
Research could also be done on the scalability of the request rerouting mechanism outlined in this thesis, as tests have so far only been performed on a virtualised network on a desktop PC.
Bibliography
[1] J. Brodkin, “Its not a fast lane but comcast built a cdn to charge for video deliv- ery.” Arstechnica, http://arstechnica.com/information-technology/2014/05/its-not- a-fast-lane-but-comcast-built-a-cdn-to-charge-for-video-delivery/, accessed 09/2014, 2014.
[2] “The telstra media blueprint.” White paper, Telstra, 2012.
[3] B. Frank et al., “Pushing cdn-isp collaboration to the limit,” ACM SIGCOMM Com- puter Communication Review, vol. 43, no. 3, pp. 35–44, 2013.
[4] J. S. Otto, M. A. S´anchez, J. P. Rula, and F. E. Bustamante, “Content delivery and the natural evolution of dns: Remote dns trends, performance issues and alternative solutions,” in Proceedings of the 2012 ACM Conference on Internet Measurement Conference, IMC ’12, (New York, NY, USA), pp. 523–536, ACM, 2012.
[5] E. Nygren, R. K. Sitaraman, and J. Sun, “The akamai network: A platform for high- performance internet applications,” SIGOPS Oper. Syst. Rev., vol. 44, pp. 2–19, Aug. 2010.
[6] B. Ager, N. Chatzis, A. Feldmann, N. Sarrar, S. Uhlig, and W. Willinger, “Anatomy of a large european ixp,” in Proceedings of the ACM SIGCOMM 2012 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communica- tion, SIGCOMM ’12, (New York, NY, USA), pp. 163–174, ACM, 2012.
[7] “The content delivery network (cdn): Deliverying the ultimate web experience.” White paper, Bell Canada, 2010.
[8] “Cisco visual networking index: Forecast and methodology, 20132018.” White paper, Cisco, 2014.
[9] A. G. J. But Jason, Keller Urs, “Title a rationale for web caching in consumer isps : the impact of dns lookup times and http session characteristics.” Swinburne University of Technology, 2005.
[10] A. GRAVEY, F. GUILLEMIN, and S. MOTEAU, “Last Mile Caching of Video Con- tent by an ISP,” in ETS 2013 : 2nd European Teletraffic Seminar, no. 13826, (Karl- skrona, Sweden), p. ., Sept. 2013.
[11] “Netflix open connect, a content delivery networkprovided by netflix.” Information accessible at: https://www.netflix.com/openconnect, Last accessed October 2014. [12] A. Pathan and R. Buyya, “A taxonomy and survey of content delivery networks.”
Technical Report, GRIDS-TR-2007-4, Grid Computing and Distributed Systems Laboratory, The University of Melbourne, Australia., Feb. 2007.
[13] L. Wang, V. Pai, and L. Peterson, “The effectiveness of request redirection on cdn robustness,” SIGOPS Oper. Syst. Rev., vol. 36, pp. 345–360, Dec. 2002.
[14] B. Cain, A. Barbir, R. Nair, and O. Spatscheck, “Known content network (cn) request-routing mechanisms.” RFC 5685, 2003.
[15] “Load balancing without load balancers.” Industry blog, CloudFlare, 2013. Accessible at: http://blog.cloudflare.com/cloudflares-architecture-eliminating-single-p/.
[16] “Browser statistics.” Browser statistics, w3schools, 2014. Accessible at: http://www.w3schools.com/browsers/browsers stats.asp.
[17] “Dns ttl not honored.” Chromium issues board, Google, 2013. Accessible at: https://code.google.com/p/chromium/issues/detail?id=164026 The final comment explains chrome’s current DNS cache behaviour.
[18] “Network.dnscacheexpiration - mozillazine knowledge base.” Mozilla product documentation, Mozilla, 2010. Accessible at: http://kb.mozillazine.org/Network.dnsCacheExpiration.
[19] “How internet explorer uses the cache for dns host entries.” Microsoft support doc- umentation, Microsoft. Accessible at: http://support.microsoft.com/kb/263558. [20] P. Smith, Professional website performance: Optimizing the Front-End and Back-
End. John Wiley & Sons, 2012.
[21] “Dns prefetching - the chromium projects.” Chromium design documents, Google. Accesible at: http://www.chromium.org/developers/design-documents/dns- prefetching.
[22] “Link prefetching faq.” Mozilla design documents, Mozilla. Accessible at: https://developer.mozilla.org/en-US/docs/Web/HTTP/Link prefetching FAQ. [23] “Getting to the content you want, faster in ie11.” Internet Explorer design blog,
Microsoft, 2013. Accessible at: blogs.msdn.com/b/ie/archive/2013/12/04/getting- to-the-content-you-want-faster-in-ie11.aspx?Redirected=true.
[24] “How anycast routing is used at maxcdn.” Industry blog, MaxCDN, 2013. Accessible at: https://www.maxcdn.com/blog/anycast-ip-routing-used-maxcdn/.
[25] M. Prince, “A brief primer on anycast.” Industry blog, Cloudflare, 2011. Accessible at: http://blog.cloudflare.com/a-brief-anycast-primer.
[26] “Openflow: enabling innovation in campus networks.” White paper, OpenFlow, 2008. [27] Ryu SDN controller framework, main site accessible at: http://osrg.github.io/ryu/. [28] “Cdni data tracker.” Datatracker page for CDNI, IETF. Accessible at:
https://datatracker.ietf.org/wg/cdni/documents/.
[29] D. C. T. K. M-k Shin, H-J Kim, “Cdni request routing with sdn.” IETF draft, 2012. [30] Y. E. J. Y. C. D. Jingguo Ge, Yulei Wu, Investigation of Anycast implementation in
Software-Defined Networking. CRC Press, 2014.
[31] P. Georgopoulos, M. Broadbent, B. Plattner, and N. Race, Cache as a service. IEEE, 2014.
[32] J. V. Doorn, “Building a large scale cdn with apache traffic server.” Presented at ApacheCon North America, 2014.
[33] J. Graham-Cumming, “Route leak incident on october 2, 2014.” Industry blog, Cloudflare, 2014. Accessible at: https://blog.cloudflare.com/route-leak-incident-on- october-2-2014/.
[34] H. Ballani and P. Francis, “Understanding ip anycast,” tech. rep., Cornell University, 2006.
[35] F. Dobrian, V. Sekar, A. Awan, I. Stoica, D. Joseph, A. Ganjam, J. Zhan, and H. Zhang, “Understanding the impact of video quality on user engagement,” ACM SIGCOMM Computer Communication Review, vol. 41, no. 4, pp. 362–373, 2011. [36] M. Luhar, “‘game of thrones’ premiere crashes hbo go; 2nd
big outage.” Online news article, scpr.org, 2014. Accessible at: http://www.scpr.org/news/2014/04/07/43336/when-hbo-go-doesn-t-2nd-high- profile-streaming-out/.
[37] J. Sherry, S. Hasan, C. Scott, A. Krishnamurthy, S. Ratnasamy, and V. Sekar, “Mak- ing middleboxes someone else’s problem: network processing as a cloud service,” ACM SIGCOMM Computer Communication Review, vol. 42, no. 4, pp. 13–24, 2012. [38] Mininet Network virtualisation tool, main site accessible at: http://mininet.org/. [39] BIND9, a DNS Nameserver utility, main site accessible at: http://www.bind9.net/. [40] A. Zarek, “Openflow timeouts demystified,” Master’s thesis, University of Toronto,
Ontario, Canada, 2012.
[41] H. Gharakheili, J. Bass, L. Exton, and V. Sivaraman, “Personalizing the home net- work experience using cloud-based sdn,” in A World of Wireless, Mobile and Multi- media Networks (WoWMoM), 2014 IEEE 15th International Symposium on, pp. 1–6, June 2014.
Appendix 1
.1
An example of a DNS request for facebook.com,
a CDN hosted website.
Figure 1: A wireshark trace of a DNS request for facebook.com
.2
HTML for wikipedia.com
<!DOCTYPE HTML PUBLIC ”−//IETF//DTD HTML 2 . 0 / /EN”> <html><head>
< t i t l e >301 Moved Permanently </ t i t l e > </head><body>
<h1>Moved Permanently </h1>
<p>The document has moved <a h r e f =”h t t p : / /www. w i k i p e d i a . o r g /”> h e r e </a>.</p> </body></html>
.3
The Ryu controller for my thesis.
import j s o n import l o g g i n g
from o p e r a t o r import a t t r g e t t e r from ryu . b a s e import app manager from ryu . c o n t r o l l e r import o f p e v e n t
from ryu . c o n t r o l l e r . h a n d l e r import MAIN DISPATCHER, DEAD DISPATCHER, CONFIG DISPATCHER
from ryu . c o n t r o l l e r . h a n d l e r import s e t e v c l s from ryu . l i b import hub
from ryu . l i b import d p i d a s d p i d l i b from webob import Response
from ryu . app . w s g i import C o n t r o l l e r B a s e , WSGIApplication , r o u t e from ryu . l i b . p a c k e t import e t h e r n e t , t c p
from ryu . l i b . p a c k e t import p a c k e t
s i m p l e s w i t c h i n s t a n c e n a m e = ’ s i m p l e s w i t c h a p i a p p ’ u r l = ’ / s i m p l e s w i t c h / add /{ d p i d } ’
u r l 1 = ’ / s i m p l e s w i t c h / remove /{ d p i d } ’ f l a g = 0
c l a s s T h e s i s C o n t r o l l e r ( app manager . RyuApp ) : CONTEXTS = { ’ w s g i ’ : WSGIApplication } def i n i t ( s e l f , ∗ a r g s , ∗∗ kwargs ) : super ( T h e s i s C o n t r o l l e r , s e l f ) . i n i t ( ∗ a r g s , ∗∗ kwargs ) s e l f . d a t a p a t h s = {} s e l f . m a c t o p o r t = {} w s g i = kwargs [ ’ w s g i ’ ] w s g i . r e g i s t e r ( S i m p l e S w i t c h C o n t r o l l e r , { s i m p l e s w i t c h i n s t a n c e n a m e : s e l f } ) s e l f . s w i t c h e s = {} s e l f . f l o w s = {} s e l f . l o g g e r . i n f o ( ” Loading T h e s i s C o n t r o l l e r . . . \ n” ) # I n i t i a l i s e r . a d d s t h e t a b l e −m i s s f l o w e n t r y . @ s e t e v c l s ( o f p e v e n t . EventOFPSwitchFeatures , CONFIG DISPATCHER) def s w i t c h f e a t u r e s h a n d l e r ( s e l f , ev ) : d a t a p a t h = ev . msg . d a t a p a t h o f p r o t o = d a t a p a t h . o f p r o t o p a r s e r = d a t a p a t h . o f p r o t o p a r s e r s e l f . s w i t c h e s [ d a t a p a t h . id ] = d a t a p a t h s e l f . m a c t o p o r t . s e t d e f a u l t ( d a t a p a t h . id , { } ) s e l f . f l o w s . s e t d e f a u l t ( d a t a p a t h . id , { } ) # i n s t a l l t a b l e −m i s s f l o w e n t r y
#
# We s p e c i f y NO BUFFER t o m a x l e n o f t h e o u t p u t a c t i o n due t o
# OVS bug . At t h i s moment , i f we s p e c i f y a l e s s e r number , e . g . , # 1 2 8 , OVS w i l l s e n d Packet−In w i t h i n v a l i d b u f f e r i d and # t r u n c a t e d p a c k e t d a t a . In t h a t c a s e , we c a n n o t o u t p u t p a c k e t s # c o r r e c t l y . match = p a r s e r . OFPMatch ( ) a c t i o n s = [ p a r s e r . OFPActionOutput ( o f p r o t o . OFPP CONTROLLER, o f p r o t o . OFPCML NO BUFFER) ] s e l f . a d d f l o w ( datapath , 0 , match , a c t i o n s ) #T h i s i s t h e TCP t a b l e −m i s s f l o w e n t r y . S e t t o h i g h e r p r i o r i t y . match = p a r s e r . OFPMatch ( e t h t y p e =0x0800 , i p p r o t o =6 , i p v 4 s r c=” 1 0 . 0 . 0 . 1 ” , t c p d s t =80 , i p v 4 d s t =(” 1 0 . 0 . 0 . 0 ” , ” 2 5 5 . 2 5 5 . 2 5 5 . 0 ” ) ) a c t i o n s = [ p a r s e r . OFPActionOutput ( o f p r o t o . OFPP CONTROLLER, o f p r o t o .OFPCML NO BUFFER) ] s e l f . a d d f l o w ( datapath , 1 0 , match , a c t i o n s )
@ s e t e v c l s ( o f p e v e n t . EventOFPPacketIn , MAIN DISPATCHER) def p a c k e t i n h a n d l e r ( s e l f , ev ) : global f l a g msg = ev . msg d a t a p a t h = msg . d a t a p a t h o f p r o t o = d a t a p a t h . o f p r o t o p a r s e r = d a t a p a t h . o f p r o t o p a r s e r i n p o r t = msg . match [ ’ i n p o r t ’ ] pkt = p a c k e t . Packet ( msg . d a t a ) e t h = pkt . g e t p r o t o c o l s ( e t h e r n e t . e t h e r n e t ) [ 0 ] i f ( pkt . g e t p r o t o c o l ( t c p . t c p ) and e t h . s r c == ” 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 1 ” ) : # we g o t an unmatched TCP p a c k e t from h1 t c = pkt . g e t p r o t o c o l s ( t c p . t c p ) [ 0 ] d s t p o r t = t c . d s t p o r t s r c p o r t = t c . s r c p o r t d s t = e t h . d s t s r c = e t h . s r c
d p i d = d a t a p a t h . id s e l f . l o g g e r . i n f o ( ” R e c e i v e d TCP p a c k e t \n s r c p o r t : %d\ t d s t p o r t : %d” , s r c p o r t , d s t p o r t ) i f f l a g : s e l f . l o g g e r . i n f o ( ” F l a g s e t ! \ n” ) match = p a r s e r . OFPMatch ( t c p s r c=s r c p o r t , t c p d s t= d s t p o r t , i n p o r t=i n p o r t , i p p r o t o =6 , e t h t y p e =0x0800 ) i f d s t in s e l f . m a c t o p o r t [ d p i d ] : o u t p o r t = s e l f . m a c t o p o r t [ d p i d ] [ d s t ] e l s e : o u t p o r t = o f p r o t o . OFPP FLOOD i f f l a g and e t h . d s t == ” 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 2 ” : o u t p o r t = 3 a c t i o n s = [ p a r s e r . OFPActionSetField ( e t h d s t=” 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 3 ” ) , p a r s e r . OFPActionSetField ( i p v 4 d s t=” 1 0 . 0 . 0 . 3 ” ) , p a r s e r . OFPActionOutput ( o u t p o r t ) ] s e l f . a d d f l o w ( datapath , 2 0 , match , a c t i o n s ) match = p a r s e r . OFPMatch ( t c p s r c=d s t p o r t , t c p d s t =s r c p o r t , i n p o r t=o u t p o r t , i p p r o t o =6 , e t h t y p e =0x0800 ) # e t h . d s t i s t h e CDN d e s t i n a t i o n from t h e r e c e i v e d p a c k e t t h a t t h e # h o s t t h i n k s t h e y ’ r e g o i n g t o a c t i o n s = [ p a r s e r . OFPActionSetField ( e t h s r c=e t h . d s t ) , p a r s e r . OFPActionSetField ( i p v 4 s r c=” 1 0 . 0 . 0 . 2 ” ) , # ! ! ! SET THIS LATER p a r s e r . OFPActionOutput ( i n p o r t ) ] s e l f . a d d f l o w ( datapath , 2 0 , match , a c t i o n s ) e l s e : a c t i o n s = [ p a r s e r . OFPActionOutput ( o u t p o r t ) ] s e l f . a d d f l o w ( datapath , 2 0 , match , a c t i o n s ) e l s e : d s t = e t h . d s t s r c = e t h . s r c
d p i d = d a t a p a t h . id s e l f . m a c t o p o r t . s e t d e f a u l t ( dpid , { } ) s e l f . l o g g e r . i n f o ( ” p a c k e t i n %s %s %s %s ” , dpid , s r c , d s t , i n p o r t ) # l e a r n a mac a d d r e s s t o a v o i d FLOOD n e x t t i m e . s e l f . m a c t o p o r t [ d p i d ] [ s r c ] = i n p o r t i f d s t in s e l f . m a c t o p o r t [ d p i d ] : o u t p o r t = s e l f . m a c t o p o r t [ d p i d ] [ d s t ] e l s e : o u t p o r t = o f p r o t o . OFPP FLOOD a c t i o n s = [ p a r s e r . OFPActionOutput ( o u t p o r t ) ] # i n s t a l l a f l o w t o a v o i d p a c k e t i n n e x t t i m e i f o u t p o r t != o f p r o t o . OFPP FLOOD :
match = p a r s e r . OFPMatch ( i n p o r t=i n p o r t , e t h d s t =d s t )
s e l f . a d d f l o w ( datapath , 1 , match , a c t i o n s )
d a t a = None
i f msg . b u f f e r i d == o f p r o t o . OFP NO BUFFER : d a t a = msg . d a t a
out = p a r s e r . OFPPacketOut ( d a t a p a t h=datapath , b u f f e r i d= msg . b u f f e r i d ,
i n p o r t=i n p o r t , a c t i o n s= a c t i o n s , d a t a=d a t a ) d a t a p a t h . send msg ( out )
def a d d f l o w ( s e l f , datapath , p r i o r i t y , match , a c t i o n s ) : o f p r o t o = d a t a p a t h . o f p r o t o
p a r s e r = d a t a p a t h . o f p r o t o p a r s e r
i n s t = [ p a r s e r . O F P I n s t r u c t i o n A c t i o n s ( o f p r o t o . OFPIT APPLY ACTIONS ,
a c t i o n s ) ]
mod = p a r s e r . OFPFlowMod( d a t a p a t h=datapath , p r i o r i t y= p r i o r i t y ,
match=match , i n s t r u c t i o n s=i n s t ) d a t a p a t h . send msg (mod)
# T h i s i s t h e s t a r t o f t h e REST a p i .
c l a s s S i m p l e S w i t c h C o n t r o l l e r ( C o n t r o l l e r B a s e ) :
def i n i t ( s e l f , req , l i n k , data , ∗∗ c o n f i g ) :
super ( S i m p l e S w i t c h C o n t r o l l e r , s e l f ) . i n i t ( req , l i n k , data , ∗∗ c o n f i g )
s e l f . s i m p l s w i t c h s p p = d a t a [ s i m p l e s w i t c h i n s t a n c e n a m e ]
@route ( ’ s i m p l e s w i t c h ’ , u r l , methods =[ ’GET ’ ] , r e q u i r e m e n t s={ ’ d p i d ’ : d p i d l i b . DPID PATTERN} )
def l i s t m a c t a b l e ( s e l f , req , ∗∗ kwargs ) : global f l a g f l a g = 1 s i m p l e s w i t c h = s e l f . s i m p l s w i t c h s p p d p i d = d p i d l i b . s t r t o d p i d ( kwargs [ ’ d p i d ’ ] ) i f d p i d not in s i m p l e s w i t c h . m a c t o p o r t : return Response ( s t a t u s =404) m a c t a b l e = s i m p l e s w i t c h . m a c t o p o r t . g e t ( dpid , { } ) body = j s o n . dumps ( m a c t a b l e )
return Response ( c o n t e n t t y p e= ’ a p p l i c a t i o n / j s o n ’ , body= body )
@route ( ’ s i m p l e s w i t c h ’ , u r l 1 , methods =[ ’GET ’ ] , r e q u i r e m e n t s ={ ’ d p i d ’ : d p i d l i b . DPID PATTERN} )
def l i s t f l o w t a b l e ( s e l f , req , ∗∗ kwargs ) : global f l a g f l a g = 0 s i m p l e s w i t c h = s e l f . s i m p l s w i t c h s p p d p i d = d p i d l i b . s t r t o d p i d ( kwargs [ ’ d p i d ’ ] ) i f d p i d not in s i m p l e s w i t c h . f l o w s : return Response ( s t a t u s =404) f l o w t a b l e = s i m p l e s w i t c h . f l o w s . g e t ( dpid , { } ) body = j s o n . dumps ( f l o w t a b l e )
return Response ( c o n t e n t t y p e= ’ a p p l i c a t i o n / j s o n ’ , body= body )
.4
The mininet topology for my thesis
from m i n i n e t . c l i import CLI from m i n i n e t . l i n k import Link
from m i n i n e t . l i n k import TCLink from m i n i n e t . n e t import M i n i n e t
from m i n i n e t . node import R e m o t e C o n t r o l l e r from m i n i n e t . term import makeTerm
i f ’ m a i n ’ == n a m e : n e t = M i n i n e t ( c o n t r o l l e r=R e m o t e C o n t r o l l e r , a u t o S t a t i c A r p=True , autoSetMacs=True ) c0 = n e t . a d d C o n t r o l l e r ( ’ c0 ’ ) s 1 = n e t . addSwitch ( ’ s 1 ’ ) h1 = n e t . addHost ( ’ h1 ’ ) h2 = n e t . addHost ( ’ h2 ’ ) h3 = n e t . addHost ( ’ h3 ’ ) h4 = n e t . addHost ( ’ h4 ’ ) h5 = n e t . addHost ( ’ h5 ’ ) TCLink ( h1 , s1 , p o r t 2 =1 , bw=10 , d e l a y= ’ 10ms ’ ) TCLink ( h2 , s1 , p o r t 2 =2 , bw=1 , d e l a y= ’ 10ms ’ ) TCLink ( h3 , s1 , p o r t 2 =3 , bw=100 , d e l a y= ’ 10ms ’ ) TCLink ( h4 , s1 , p o r t 2 =4 , bw=10 , d e l a y= ’ 10ms ’ ) TCLink ( h5 , s1 , p o r t 2 =5 , d e l a y= ’ 10ms ’ ) n e t . b u i l d ( ) c0 . s t a r t ( ) s 1 . s t a r t ( [ c0 ] )
s 1 . sendCmd ( ’ ovs−v s c t l s e t b r i d g e s 1 p r o t o c o l s=OpenFlow13 ’ )
CLI ( n e t ) n e t . s t o p ( )