Value of Virtualized Programmable Network Infrastructures Future Internet Assembly, Poznan, 25. October 2011 David Hausheer Department of Electrical Engineering  and Information Technology Technische Universität Darmstadt E-Mail: hausheer@kom.tu-darmstadt.de http://www.kom.tu-darmstadt.de/ Associated to:
1. What is the case/topic/application of virtualization highlighted?  Virtualized programmable network infrastructures  Split of physical networking equipment Isolation of different network «slices» Supporting co-existance of legacy and new network Network programmability enables to Customize networking equipment E.g. change packet forwarding or run arbitrary code Easily deploy and test new algorithms Future Internet Assembly, Poznan, 25. October 2011
2. What is the identified/visioned key value item: Who is the value creator? Who are value consumers?  Network Testbeds, e.g. GENI / FIRE  Fully programmable network testbeds Useful to experiment with new network protocols Value consumers: mainly network researchers, not application developers OpenFlow Limits network programmability to flow-based routing Software-defined treatment and forwarding of flows  Harness the power of the open source community (similar to Linux) Simplifies central management of the network and reduces costs Value consumers: networking  environments like datacenters Reduction in costs adds up over a large number of devices Future Internet Assembly, Poznan, 25. October 2011
3. Which is the key technology/feature to create value?  Deep programmability No limitations in support of new applications Supported features, e.g. priority scheduling, flow-state based decisions, time-stamping of packets, etc. Separation of traffic Isolation to avoid negative impact of malicious applications Protect applications against attacks and provide higher QoS Comes at a certain cost of efficiency Future Internet Assembly, Poznan, 25. October 2011
4. Which are the main bottleneck/challenges expected to hinder value creation? Programmability comes at a performance cost OpenFlow limits programmability, but doesn’t support of full range of apps E.g. decisions cannot be based on flow states There is no compelling “killer app” that truly needs the new features High bandwidth apps can be supported by overprovisioning etc. But: Killer apps cannot be tested w/o supporting infrastructure  ->  Deadlock! Network providers lack incentives for adoption Providers bear most of the risks (implementing  the changes) …  but may only get a small additional revenue At the same time, providers don’t bear the risk of the status quo Coordination problems among providers lead to  single domain islands Interoperability issues, conflicts of interest, revenue sharing Future Internet Assembly, Poznan, 25. October 2011
5. Which liability (value guarantor) and revenue scenarios are proposed/considered? Infrastructure needs to be used  by a wide community of users Compelling, accessible, and open platform Connect and excite real users (not only researchers) User-definable network With simple language to enable inexperienced user to quickly setup new apps Multi-Provider support Preserve distributed network management With different ownership and respective boundaries Provide appropriate incentives for provider coordination Support of E2E QoS, SLA verification, billing, revenue sharing, etc. E.g. E2E issues could be resolved via federations Cf. ongoing work in EU project ETICS Future Internet Assembly, Poznan, 25. October 2011
Future Internet Assembly, Poznan, 25. October 2011 Thank you for your attention! Questions? [email_address] http://hausheer.osola.com/

Value of Virtualized Programmable Network Infrastructures

  • 1.
    Value of VirtualizedProgrammable Network Infrastructures Future Internet Assembly, Poznan, 25. October 2011 David Hausheer Department of Electrical Engineering and Information Technology Technische Universität Darmstadt E-Mail: hausheer@kom.tu-darmstadt.de http://www.kom.tu-darmstadt.de/ Associated to:
  • 2.
    1. What isthe case/topic/application of virtualization highlighted? Virtualized programmable network infrastructures Split of physical networking equipment Isolation of different network «slices» Supporting co-existance of legacy and new network Network programmability enables to Customize networking equipment E.g. change packet forwarding or run arbitrary code Easily deploy and test new algorithms Future Internet Assembly, Poznan, 25. October 2011
  • 3.
    2. What isthe identified/visioned key value item: Who is the value creator? Who are value consumers? Network Testbeds, e.g. GENI / FIRE Fully programmable network testbeds Useful to experiment with new network protocols Value consumers: mainly network researchers, not application developers OpenFlow Limits network programmability to flow-based routing Software-defined treatment and forwarding of flows Harness the power of the open source community (similar to Linux) Simplifies central management of the network and reduces costs Value consumers: networking environments like datacenters Reduction in costs adds up over a large number of devices Future Internet Assembly, Poznan, 25. October 2011
  • 4.
    3. Which isthe key technology/feature to create value? Deep programmability No limitations in support of new applications Supported features, e.g. priority scheduling, flow-state based decisions, time-stamping of packets, etc. Separation of traffic Isolation to avoid negative impact of malicious applications Protect applications against attacks and provide higher QoS Comes at a certain cost of efficiency Future Internet Assembly, Poznan, 25. October 2011
  • 5.
    4. Which arethe main bottleneck/challenges expected to hinder value creation? Programmability comes at a performance cost OpenFlow limits programmability, but doesn’t support of full range of apps E.g. decisions cannot be based on flow states There is no compelling “killer app” that truly needs the new features High bandwidth apps can be supported by overprovisioning etc. But: Killer apps cannot be tested w/o supporting infrastructure -> Deadlock! Network providers lack incentives for adoption Providers bear most of the risks (implementing the changes) … but may only get a small additional revenue At the same time, providers don’t bear the risk of the status quo Coordination problems among providers lead to single domain islands Interoperability issues, conflicts of interest, revenue sharing Future Internet Assembly, Poznan, 25. October 2011
  • 6.
    5. Which liability(value guarantor) and revenue scenarios are proposed/considered? Infrastructure needs to be used by a wide community of users Compelling, accessible, and open platform Connect and excite real users (not only researchers) User-definable network With simple language to enable inexperienced user to quickly setup new apps Multi-Provider support Preserve distributed network management With different ownership and respective boundaries Provide appropriate incentives for provider coordination Support of E2E QoS, SLA verification, billing, revenue sharing, etc. E.g. E2E issues could be resolved via federations Cf. ongoing work in EU project ETICS Future Internet Assembly, Poznan, 25. October 2011
  • 7.
    Future Internet Assembly,Poznan, 25. October 2011 Thank you for your attention! Questions? [email_address] http://hausheer.osola.com/