A preliminary implementation of a content–aware network node

1,029 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,029
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

A preliminary implementation of a content–aware network node

  1. 1. !st Workshop on Multimedia-Aware Networking 2011 (WoMAN ‘11)<br />A PRELIMINARY IMPLEMENTATION OF A CONTENT–AWARE NETWORK NODE<br />N. Vorniotakis, G. Xilouris, G. Gardikis, N. Zotos, E. Palis, A. Kourtis<br />
  2. 2. Contents<br />Introduction<br />Scope<br />Content-Awareness Enablers<br />Design <br />Experimental Testbed<br />Validation and experimental results<br />Acknowledgments - Conclusions<br />2<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />
  3. 3. Introduction<br />Multimedia content is anticipated to be increased at least by a factor of 6 in 2012<br />Network nodes are currently agnostic to the content they deliver<br />In order for future network architectures to cope with this environment <br />continue to provide fast switching and forwarding at the core <br />push the intelligence to the edge <br />Given the constant evolution in hardware capabilities — in terms of CPU power and memory availability there is the capability to:<br />Provide new functionalities to the network nodes in order to make the network aware of the content being transferred hence applying specific policies or routing respectively<br />3<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />
  4. 4. Scope <br />This work presents a preliminary design of a content-aware network node<br />Discusses the main concepts and principles governing this design <br />Presents an preliminary implementation of an algorithm for identification of multimedia streams over RTP protocol<br /> Validates the proof-of-concept through experimental results<br />4<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />
  5. 5. Content-Awareness Enablers<br />Flow awareness<br />content-awareness should be performed per-flow of network data<br />Use of hash tables where every active flow record, is maintained by the network node<br />Mechanisms for removal of idle or zombie flows are mandatory in order to be detected and removed, and free memory <br />Enables the processing of the minimum required amount of packets<br />Resulting<br />Smaller processing delays <br />Better scalability<br />5<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />
  6. 6. Content-Awareness Enablers<br />Traffic Classification<br />Current techniques exploit information taken from OSI Layer 3 to Layer 7<br />Many techniques combine multilayer information with application data inspection (DPI) for accurate traffic identification<br />Less invasive to privacy methods involve statistical analysis of the flow dynamics<br />Methods used to classify traffic at application level include<br />Exact Matching<br />Prefix Matching <br />Heuristics methods<br />Machine learning based on statistical features<br />6<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />
  7. 7. Design<br /><ul><li>Content Awareness Module depends on the Heuristics functions to determine the service of each flow using either Deep Packet Inspection (DPI) techniques or Port to Service Mapping for simple services identification
  8. 8. Policer Module is in charge of applying the desired policies at the respective flows. This module includes also the queue schedulers that are used for traffic control (shaping, differentiation, prioritization)
  9. 9. C-A functions were designed to be modular and scalable
  10. 10. Flow Handling module comprises of
  11. 11. the Packet Capturer module that captures incoming network packets
  12. 12. Flow Handler that organizes incoming packets to network flows.
  13. 13. Routing module comprises of:
  14. 14. Packet Marker and the Routing Tables Handler</li></ul>7<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />
  15. 15. Design – Routing Module<br /><ul><li>Routing Module
  16. 16. for every incoming flow, after the content is identified three main decisions need to be made.
  17. 17. how to police the traffic at the ingress interface
  18. 18. how to route the flow
  19. 19. how to handle (shaping, conditioning, prioritization) the flow at the egress.
  20. 20. This module exploits functionalities provided by the Linux OS kernel and User Space utilities (i.e. iptables, traffic control
  21. 21. Content Mapping Table that contains information on how to police and condition the flows depend- ing on content type
  22. 22. A number of alternative local RIBs is used that are statically pre-assigned</li></ul>8<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />
  23. 23. Design – RTP dissector<br /><ul><li>Incoming packets are traversing the processing loop, each one is checked to determine whether it belongs to an already established flow
  24. 24. The actual detection algorithm is much more complex so it can be accurate on most cases since it has more passes and also takes into account RTCP data.</li></ul>9<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />
  25. 25. Design – RTP dissector<br /><ul><li>Incoming packets are traversing the processing loop, each one is checked to determine whether it belongs to an already established flow
  26. 26. The actual detection algorithm is much more complex so it can be accurate on most cases since it has more passes and also takes into account RTCP data.</li></ul>10<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />
  27. 27. Experimental Test-bed<br /><ul><li>streaming server streams a flow of a video using RTP to the client that is considered to be a high priority service
  28. 28. traffic generator is used to create a gradually increasing source of background traffic</li></ul>11<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />
  29. 29. Experimental - Cases<br />Testing Scenarios<br />Case1 - content agnostic network<br />Case2 - traffic classification based on policies and HTB<br />Case3 - traffic classification based on content identification<br />12<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />
  30. 30. Experimental-Results<br />Case1<br />Case3<br /><ul><li>The proof of concept of the content-aware network node is proved
  31. 31. In case3 the content aware features of the ingress node allow the selection of different path in the network
  32. 32. The one way delay is not affected by the operation of the C-A algorithm</li></ul>Case2<br />13<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />
  33. 33. Acknowledgments<br />This work has been supported by the European Research Project FP7<br />“MediA Ecosystem Deployment Through Ubiquitous Content-Aware Network Environments”ICT-ALICANTE Project No. 2010-2013. <br />http://www.ict-alicante.eu<br />14<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />
  34. 34. Thank you for your attention<br />Questions ?<br />Contact information<br />NikolaosVorniotakis (nkvorn@iit.demorkritos.gr)<br />George Xilouris (xilouris@iit.demokritos.gr)<br />15<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />
  35. 35. 16<br />ICME 2011 Conference, WOMAN Workshop July 11 2011, Barcelona<br />

×