SlideShare a Scribd company logo
Three years of OFELIA –
taking stock
by Hagen Woesner
OFELIA project coordinator
Travelling back in time…
Taking stock
• OFELIA proposal was written in late 2009
– OpenFlow was at v0.9, way before anything like ONF
– Rob Sherwood and Srini Seetharaman were employees of DT
Labs
– Guru and Nick came over to Berlin quite frequently, talking
about their campus testbed in Stanford
– Some people of DT wanted to bring over this great idea to
Europe
I suggested calling the project OFELIA because of
the nice connotation to an open flow…
As a baby name, OFELIA is not very popular
Ophelia neither
Why was OpenFlow embraced by carriers?

• The world of network equipment vendors was
unchanged since ~1990
– Some consolidations in Europe, two new players from China

• The market of carriers was in full crisis
– Google
– Facebook
– Over the top players with no commercial connection to the
network owners
If your revenue falls 22% per annum, would
you call this a crisis?

Relative scale

5

Enormous complexity.

Traffic
Traffic *Cost
Traffic *Revenue
Rev/Cost
Router Cost per Mbit
Revenue per Mbit

4
3
2
1

0

0

1

2 Year

3

4

 Internet traffic growth at about 50% per year
 Cost reduction of router per Mbit/s 15 % per year
 Revenue per Mbit/s falls steeper (22 % per year)

(the

effect)

5

RFCs published annually Total number of RFCs

The gap of traffic, cost and revenue ...

6000
5000
4000
3000
2000
1000
0
1965

1970

1975

1980

1985

1990

1995

2000

2005

2010

500
400
300
200

100
0
1970

1980

1990

2000

2010 Year

 Huge and confusing amount of standards and RFC
 A lot of patches for Security, QoS, MPLS,
Demarcation etc.

(the

effect)
No wonder carriers were looking for ways out
of the dilemma to:

• Participate in revenues from OTT
– charging for netflix, youtube, spotify?
– If the customer pays a flat rate, revenue has to come from
service provider

• Make the network drastically simpler
– Split control from data planes
– Abandon all vendor-specific solutions
– Remove as much as possible session state from network
devices
Some details on “complexity” for the fixed access network
Upstream Interface
• IS-IS Routing
• BGP
• MPLS LDP
• Static Routing

RADIUS Interface
• LineID = User
• FilterClass by ID
• CoA for Filter Change
• All line Attributes included

Astra

UpStream
Routing

AAA

BNG Functionality
• S-Tags in Session Context
• RemoteID in Session Contex
• CircuitID in Session Context
• Static Filter Per Product
• Filter assigned by RADIUS
• Dynamic Change by CoA
• Six QoS Classes
• Bandwith control per Session
• Multicast Replication on BNG

RADIUS Client

Ethernet Port

BNG
Ethernet Port#1

S-TAG

Ethernet Port#1

S-TAG

S-TAG
-TAG

S-TAG

S-TAG
-TAG

S-TAG

VLAN#X PPPoE

BIP VLAN#Y

S-TAG

S-TAG

Ethernet Port

MSAN Functionality
• Port becomes S-TAG
• Pysical Port in Circuit-Id
MSANId+Port=Circuit-Id
• Provisioned Remote-Id per Port
Based on ITU-T M.1400
• PPPoE IA includes Ids
• C-Tags Transparent

Ethernet Port

MSAN#1

One S-TAG per Access Port

MSAN#2

Port#12

Port#12

VDSL

Port#12
VDSL

VDSL
VLAN#X PPPoE

Port#12

VLAN#X PPPoE

VDSL
BIP VLAN#Y

VLAN#X PPPoE

VDSL

VDSL

VDSL

VDSL

RG#1

RG#2

RG#1

RG#2

IAD Functionlity
• PPPoE Discovery on VLAN7
• Residential on VLAN7 flat
• BIP on VLAN #Y

10
So, two projects were initiated
• Split Architecture for Carrier networks (SPARC)
– DT and Ericsson
– iMinds, Acreo, EICT
• MPLS-controlled access
• BRAS
• Virtualization of networks

• And OFELIA, for trying out the things developed
OFELIA 2010-2013 FP7 project
SPARC+OFELIA at ONS 2011
Requirement

OFELIA

Resource discovery

Seeing aggregates in GUI, later on: topology

Resource reservation

Aggregate managers for VMs, Flowspaces, WiFi

Resource provisioning

Flowspace reservation manually approved by
island managers

Experiment control

WebGUI (expedient)

Monitoring

For island admins: zenoss, experimenters: web site

Permanent storage

n/a, but flowspace reservation remains in place for
30 days by default

Identity management

Currently: LDAP, coming up: O’House

Authorization

Open to the public. Closed and trusted group,
access granted once alongside with OpenVPN
certificate, to be improved with OHouse

SLA management

OHouse

First Level Support

Zenoss data on web site

Dataplane
interconnection

Currently best effort L2 tunnels across the Internet
VLAN stitching with lots of manual intervention

14
VLAN stitching
berli
n
brist
ol

ETH
Z

iMinds

• Researcher requests VLAN
space in each island
• Resolve conflicts later
• MANUALLY!
– Poor Bart.

i2cat

Trent
o/
Creat
e-Net

• “clashing engine” is being
implemented
Ways to overcome VLAN clashing

• Centralized assignment of VIDs
– As of now, we have a range for inter-island ViDs assigned

• VID translation
• Different slicing scheme
Centralized assignment of VIDs
• Centralized VLAN assignment
– For cross-island experiments VLANs to be assigned via
separate AM

GUI/omni

FOAM

VLAN AM

FOAM

FOAM

FOAM

FOAM
Centralized assignment of VIDs
• Wait until someone finds it too complicated and
cleans up
• centralized FOAM

GUI/omni

FOAM

VLAN
AM+FOAM

FOAM

FOAM

FOAM

FOAM
VLAN translation
• Slightly unusual practice for VLANs
– Not working in standard Ethernet switches

• Starts to look like MPLS (to me?)
– There are good papers on using MPLS for OF virtualisation

• In principle possible via software OF switches
– Need to create (and signal) the mappings
A different slicing mechanism?

Many were increasingly of the opinion that they'd all made a big
mistake in coming down from the trees in the first place. And some
said that even the trees had been a bad move, and that no one
should ever have left the oceans.

• VLANs seemed like a good idea because of aggregation, but
why did we want to aggregate?
– Because TCAM space is the scarce resource
• So why do we slice flowspace and not TCAM space?

• We (in OFELIA) have MAC address assignment under our
control, so we could slice on MACs?
– The FlowVisor explosion may be mitigated by clever setting of entries

• What about a combination of TCAM limitation and MAC
slicing?
Three ways of virtualizing
• Slicing the flowspace
– FlowVisor does this, partially

• Translating the flowspace
– FlowVisor 2.0 goes this way
– Process/modify each packet (incl. TTL!)

• Transparent tagging
– MPLS etc. (Pontus Sköldström and Wolfgang John: “Implementation and
Evaluation of a carrier-grade OpenFlow Virtualization Scheme”; EWSDN 2013)

This is the fundamental testbed question:
How much of the flowspace are we assigning for
experimentation, and how much for the experiment?
Without deciding on virtualization schemes,
what can we do?

• FlowVisor upgrade beyond OF 1.0

• OF datapath upgrade to new OF versions
• Signaling between islands (be it so VIDs)
FP7 project ALIEN
• Integration of FV functionality into OpenFlow
datapath
– Add flowspace management into the switch (mgmt interface
like fvctl)
– Add flowspace management into OpenFlow, eventually

• Deploy OpenFlow beyond Linux/x86
– NPUs (Cavium, Ezchip), NetFPGA, GEPON, optics

• Check https://www.codebasin.net/redmine/projects/xdpd/wiki
Three years of OFELIA - taking stock
FP7 project FELIX
Framework of EU-Japan collaboration

•
FP7 project FELIX

For EICT, this will eventually mean writing an AMSoil-based AM for NSI v.2
Intermediate conclusions
• There has to be a better solution than manual
assignment of VLAN IDs
• We should either upgrade FV or get rid of it
• Porting OpenFlow to alien hardware leads to
•  Open Source Hardware?
– Should there be an endorsement/requirement to use open
hardware for testbeds?

• NSI v2 seems to be the means of choice to bridge
networks between OF controlled islands.
– For high-bandwidth, on-demand applications
– Otherwise OpenVPN or manual (QinQ) SID assignment is just
fine.
What is the best collaborative model?
• One that is building on the egoistic interest of a
testbed user
– Only users can operate and develop testbeds

• Federation is key
– Increase geographic reach
– Draw on other researchers’ knowledge

• Three things required for federation
– Powerful resource description (language)  Rspecs
– Connectivity and resource provisioning  Aggregate
Managers
– Trust (authentication, authorisation)  Clearinghouse
Experiments and what we learned from them
Thanks to Panos and Matt of Lancaster
University for writing up their experience.
One experiment: virtual topology creation by
modified FlowVisors

Implemented mainly be Create-Net, Italy
Lancaster University joined the OFELIA project
as an experimenter.

To this effect they provided feedback at the beginning
of the 3rd year of the project, describing the usability of
the facility.
Experiment is on:

Video-on-Demand Content Caching
with OpenFlow
Video-on-Demand Content Caching with OpenFlow (1)

An OpenFlow network with peripheral content caches
Video-on-Demand Content Caching with OpenFlow (2)

First interaction: Content silently copied to cache
Video-on-Demand Content Caching with OpenFlow (3)

Later interactions: Content retrieved from cache
Proposed Hardware Platform
Proposed Software Platform
Now this is a workflow to really get lost, right?
“Registering, creating a project, adding a slice to it and the
respective Aggregate Managers (AMs) all work quite well.”

Uff…
However,
Remove the manual approval
delay from the process
• ...by approving everything automatically.
– The respective island managers should still get the
notification emails, but the default action from the system
should be to automatically approve a project (and/or an
associated action).
– This would make the facility appear way more responsive
and user-friendly. After all, when a user is creating a project,
he wants to start experimenting with the facility straight
away.
Where are all the OFELIA islands?
• As a more generic comment, we advertise having 10
islands on the OFELIA testbed but there are only 4
islands available for federated tests (through their
AMs); ETHZ, i2CAT, iMinds and Create-Net. Perhaps
adding the rest of the AMs would provide a more
enhanced facility.
• OK, one is providing strange resources like optical switches (AM for
this still under development), one had a hard disk crash, and others
are just on their way to really becoming available (joined recently)
More feedback to the experimenter!
• The way of booking resources for carrying out
federated experiments is not very clear (despite the
tutorial). In our opinion the user requires more
feedback as what he should do next (i.e. the next
step) and what the system tries to do each time as a
response to a user’s request. A few more concrete
suggestions :
Flowspaces and VLANs are unclear
• The concept of Flowspaces is not very clear to the user (i.e. what is it and
what he should do “with it”).

• Related to the above, the concept of VLANs is also not obvious to the user.
Obviously this is how experiments in OFELIA are defined, but it might be
worthwhile making it clear to the user that the same VLAN is needed for
tests across multiple islands (we expect him to figure it out).
– Furthermore, if certain VLANs are not available to the user (reserved in
certain islands) then Expedient should disallow these from being
requested by a user.
–Suggestion : Perhaps a drop down box of the available VLANs or an
informative table about the availability of VLANs would help.
And then some smallprint
1)Also, it is not very clear when the user should update his slice. Is updating the slice done
automatically every time we change the resources? Should the user update the slice when
he restarts his controller? (we’ve found that sometimes this is required).
a.Suggestion : perhaps more information regarding when the user should update this
slice in relation to the changes he does to his slice is required.
2)Some error messages are too generic and unhelpful to the user. For example, the error
messages coming from a FlowVisor do not report which FlowVisor is generating the
messages. The user does not know how to fix this problem (he doesn’t have access to any
FlowVisors) and he doesn’t even have enough information as to whom (i.e. which island
manager) he should contact regarding these messages[1].
a.Suggestion : Perhaps making the error messages more specific to the actual
problem. Also contact details of island managers or an alias email should be displayed
to the user so that he knows whom to contact if there is a particular error message.
3)Minor : The Topology of the slice is useful, but if the user has chosen a subset of it for his
experiments, it would be useful to see active just the subset in the main page of his slice.
a.Suggestion : Perhaps getting the links/machines/switches used in a Flowspace as
bold, or a drop down menu that would give the option of toggling between “Available
Topology” and “Used Topology” would be useful.
4)Minor : When the user hovers over a switch it would be useful to see information about
the links to VMs as well (in addition to the ones we see now for the connected switches).
And then some more smallprint
Minor : Sometimes when a small number or resources is allocated to a slice, the actual icons do not
appear in the Topology panel and they are “floating” around.
•Perhaps most importantly, the requirement for manual approval of the user’s requested Flowspace from each island manager involved in an
experiment, is making the facility non-friendly for experiments. It is important that we change to an automated approval of the Flowspace, as
it is high likely that in an experimental facility the user would add/remove AMs, update his controller, add/remove links/VMs/switches
frequently and thus waiting for hours/days for manual approval of each change from each respective island manager involved in the
experiment, makes the facility cumbersome for experimentation.
•There can be consistency issues between the visual interface and reality. For example, a newly created VM can get stuck in a perpetual state
of ‘starting’. Yet in reality, the VM has started perfectly fine and is fully accessible via SSH. There is no way to stop/delete these VMs stuck in
this perpetual state.
•The standard VM image used on the island is now somewhat dated. Ideally, this image should be replaced with a newer version of Debian. If
possible, a selection of distributions should also be made available. Many of the experiments that we envisaged on OFELIA require
current/cutting-edge packages and repositories that are otherwise not available in an older release. Building software is therefore
unnecessarily painful and time consuming. We also encountered a number of bugs that have been fixed in later releases of the OS.
•We also had a number of connectivity problems whilst experimenting on OFELIA. As a result, we had to turn to a number of island managers
to help us out. Although incredibly helpful and more than willing to assist us, the island managers seemed ill-equipped to debug issues quickly
and effectively. It might be worthwhile putting together a toolkit for troubleshooting islands, and then making this available to all island
managers. Furthermore, finding and isolating these problems quickly is of absolute importance, especially when non-project users are
experimenting on the testbed. An easy solution to this is to create a monitoring slice within the testbed (Matt is working on this). Periodically
checking for connectivity between islands could provide a simple feedback mechanism that can alert island managers when their island goes
‘dark’.
Next steps
• Finish Clearinghouse
• Get an idea on how to stitch VLANs
– Without introducing centralized VID mgmt
– VLAN “clashing engine” was implemented

• Drastically clean up workflow and GUI.
• Eventually: OCF in a box – VM appliance
• OFELIA project itself is ending now, but islands have
signed MoU to continue operation
– FIBRE, FELIX, ALIEN FP7 projects can carry out some
development work

• And I encourage you very much to do so!

More Related Content

What's hot

IRATI: an open source RINA implementation for Linux/OS
IRATI: an open source RINA implementation for Linux/OSIRATI: an open source RINA implementation for Linux/OS
IRATI: an open source RINA implementation for Linux/OS
ICT PRISTINE
 
RINA overview and ongoing research in EC-funded projects, ISO SC6 WG7
RINA overview and ongoing research in EC-funded projects, ISO SC6 WG7RINA overview and ongoing research in EC-funded projects, ISO SC6 WG7
RINA overview and ongoing research in EC-funded projects, ISO SC6 WG7
Eleni Trouva
 
Rlite software-architecture (1)
Rlite software-architecture (1)Rlite software-architecture (1)
Rlite software-architecture (1)
ARCFIRE ICT
 
What a difference 5 years make
What a difference 5 years makeWhat a difference 5 years make
What a difference 5 years make
Open Networking Summit
 
IRATI @ RINA Workshop 2014, Dublin
IRATI @ RINA Workshop 2014, DublinIRATI @ RINA Workshop 2014, Dublin
IRATI @ RINA Workshop 2014, Dublin
Eleni Trouva
 
Dynamic Service Chaining
Dynamic Service Chaining Dynamic Service Chaining
Dynamic Service Chaining
Tail-f Systems
 
Layers of tcpip.65 to 66
Layers of tcpip.65 to 66Layers of tcpip.65 to 66
Layers of tcpip.65 to 66
myrajendra
 
Experimental evaluation of a RINA prototype - GC 2014
Experimental evaluation of a RINA prototype - GC 2014Experimental evaluation of a RINA prototype - GC 2014
Experimental evaluation of a RINA prototype - GC 2014
Eleni Trouva
 
RINA detailed components overview and implementation discussion
RINA detailed components overview and implementation discussionRINA detailed components overview and implementation discussion
RINA detailed components overview and implementation discussion
Eleni Trouva
 
Improving the user experience of multimedia streaming services in highly dyna...
Improving the user experience of multimedia streaming services in highly dyna...Improving the user experience of multimedia streaming services in highly dyna...
Improving the user experience of multimedia streaming services in highly dyna...
The Research Council of Norway, IKTPLUSS
 
Update on IRATI technical work after month 6
Update on IRATI technical work after month 6Update on IRATI technical work after month 6
Update on IRATI technical work after month 6
Eleni Trouva
 
Rina IRATI GLIF Singapore 2013
Rina IRATI GLIF Singapore 2013Rina IRATI GLIF Singapore 2013
Rina IRATI GLIF Singapore 2013
Eleni Trouva
 
SDN: Situação do mercado e próximos movimentos
SDN: Situação do mercado e próximos movimentosSDN: Situação do mercado e próximos movimentos
SDN: Situação do mercado e próximos movimentos
Christian Esteve Rothenberg
 
DEVNET-1175 OpenDaylight Service Function Chaining
DEVNET-1175	OpenDaylight Service Function ChainingDEVNET-1175	OpenDaylight Service Function Chaining
DEVNET-1175 OpenDaylight Service Function Chaining
Cisco DevNet
 
The Third Network: LSO, SDN and NFV
The Third Network: LSO, SDN and NFVThe Third Network: LSO, SDN and NFV
The Third Network: LSO, SDN and NFV
OPNFV
 
NFV Linaro Connect Keynote
NFV Linaro Connect KeynoteNFV Linaro Connect Keynote
NFV Linaro Connect Keynote
Linaro
 
LinkedIn's Approach to Programmable Data Center
LinkedIn's Approach to Programmable Data CenterLinkedIn's Approach to Programmable Data Center
LinkedIn's Approach to Programmable Data Center
Shawn Zandi
 
Ch05
Ch05Ch05
SDN Networks Programming Languages
SDN Networks Programming LanguagesSDN Networks Programming Languages
SDN Networks Programming Languages
Flavio Vit
 
Introduction To Openflow
Introduction To OpenflowIntroduction To Openflow
Introduction To Openflow
Waqas Daar
 

What's hot (20)

IRATI: an open source RINA implementation for Linux/OS
IRATI: an open source RINA implementation for Linux/OSIRATI: an open source RINA implementation for Linux/OS
IRATI: an open source RINA implementation for Linux/OS
 
RINA overview and ongoing research in EC-funded projects, ISO SC6 WG7
RINA overview and ongoing research in EC-funded projects, ISO SC6 WG7RINA overview and ongoing research in EC-funded projects, ISO SC6 WG7
RINA overview and ongoing research in EC-funded projects, ISO SC6 WG7
 
Rlite software-architecture (1)
Rlite software-architecture (1)Rlite software-architecture (1)
Rlite software-architecture (1)
 
What a difference 5 years make
What a difference 5 years makeWhat a difference 5 years make
What a difference 5 years make
 
IRATI @ RINA Workshop 2014, Dublin
IRATI @ RINA Workshop 2014, DublinIRATI @ RINA Workshop 2014, Dublin
IRATI @ RINA Workshop 2014, Dublin
 
Dynamic Service Chaining
Dynamic Service Chaining Dynamic Service Chaining
Dynamic Service Chaining
 
Layers of tcpip.65 to 66
Layers of tcpip.65 to 66Layers of tcpip.65 to 66
Layers of tcpip.65 to 66
 
Experimental evaluation of a RINA prototype - GC 2014
Experimental evaluation of a RINA prototype - GC 2014Experimental evaluation of a RINA prototype - GC 2014
Experimental evaluation of a RINA prototype - GC 2014
 
RINA detailed components overview and implementation discussion
RINA detailed components overview and implementation discussionRINA detailed components overview and implementation discussion
RINA detailed components overview and implementation discussion
 
Improving the user experience of multimedia streaming services in highly dyna...
Improving the user experience of multimedia streaming services in highly dyna...Improving the user experience of multimedia streaming services in highly dyna...
Improving the user experience of multimedia streaming services in highly dyna...
 
Update on IRATI technical work after month 6
Update on IRATI technical work after month 6Update on IRATI technical work after month 6
Update on IRATI technical work after month 6
 
Rina IRATI GLIF Singapore 2013
Rina IRATI GLIF Singapore 2013Rina IRATI GLIF Singapore 2013
Rina IRATI GLIF Singapore 2013
 
SDN: Situação do mercado e próximos movimentos
SDN: Situação do mercado e próximos movimentosSDN: Situação do mercado e próximos movimentos
SDN: Situação do mercado e próximos movimentos
 
DEVNET-1175 OpenDaylight Service Function Chaining
DEVNET-1175	OpenDaylight Service Function ChainingDEVNET-1175	OpenDaylight Service Function Chaining
DEVNET-1175 OpenDaylight Service Function Chaining
 
The Third Network: LSO, SDN and NFV
The Third Network: LSO, SDN and NFVThe Third Network: LSO, SDN and NFV
The Third Network: LSO, SDN and NFV
 
NFV Linaro Connect Keynote
NFV Linaro Connect KeynoteNFV Linaro Connect Keynote
NFV Linaro Connect Keynote
 
LinkedIn's Approach to Programmable Data Center
LinkedIn's Approach to Programmable Data CenterLinkedIn's Approach to Programmable Data Center
LinkedIn's Approach to Programmable Data Center
 
Ch05
Ch05Ch05
Ch05
 
SDN Networks Programming Languages
SDN Networks Programming LanguagesSDN Networks Programming Languages
SDN Networks Programming Languages
 
Introduction To Openflow
Introduction To OpenflowIntroduction To Openflow
Introduction To Openflow
 

Similar to Three years of OFELIA - taking stock

OpenFlow Tutorial
OpenFlow TutorialOpenFlow Tutorial
OpenFlow Tutorial
Ja-seop Kwak
 
IRATI Experimentation, US-EU FIRE Workshop
IRATI Experimentation, US-EU FIRE WorkshopIRATI Experimentation, US-EU FIRE Workshop
IRATI Experimentation, US-EU FIRE Workshop
Eleni Trouva
 
Introduction to SDN
Introduction to SDNIntroduction to SDN
Introduction to SDN
Muhammad Moinur Rahman
 
On SDN Research Topics - Christian Esteve Rothenberg
On SDN Research Topics - Christian Esteve RothenbergOn SDN Research Topics - Christian Esteve Rothenberg
On SDN Research Topics - Christian Esteve Rothenberg
CPqD
 
07 (IDNOG02) SDN Research activity in Institut Teknologi Bandung by Affan Bas...
07 (IDNOG02) SDN Research activity in Institut Teknologi Bandung by Affan Bas...07 (IDNOG02) SDN Research activity in Institut Teknologi Bandung by Affan Bas...
07 (IDNOG02) SDN Research activity in Institut Teknologi Bandung by Affan Bas...
Indonesia Network Operators Group
 
Can today’s Internet protocols deliver URLLC?
Can today’s Internet protocols deliver URLLC?Can today’s Internet protocols deliver URLLC?
Can today’s Internet protocols deliver URLLC?
3G4G
 
Network research
Network researchNetwork research
Network research
Jisc
 
Intro to Project Calico: a pure layer 3 approach to scale-out networking
Intro to Project Calico: a pure layer 3 approach to scale-out networkingIntro to Project Calico: a pure layer 3 approach to scale-out networking
Intro to Project Calico: a pure layer 3 approach to scale-out networking
Packet
 
Introduction to Software Defined Networking (SDN)
Introduction to Software Defined Networking (SDN)Introduction to Software Defined Networking (SDN)
Introduction to Software Defined Networking (SDN)
Bangladesh Network Operators Group
 
Introductionto SDN
Introductionto SDN Introductionto SDN
Introductionto SDN
Md. Shariful Islam Robin
 
Future services on Janet
Future services on JanetFuture services on Janet
Future services on Janet
Jisc
 
Software Defined Optical Networks - Mayur Channegowda
Software Defined Optical Networks - Mayur ChannegowdaSoftware Defined Optical Networks - Mayur Channegowda
Software Defined Optical Networks - Mayur Channegowda
CPqD
 
Software Defined Optical Networks - Mayur Channegowda
Software Defined Optical Networks - Mayur ChannegowdaSoftware Defined Optical Networks - Mayur Channegowda
Software Defined Optical Networks - Mayur Channegowda
CPqD
 
Naveen nimmu sdn future of networking
Naveen nimmu sdn   future of networkingNaveen nimmu sdn   future of networking
Naveen nimmu sdn future of networking
OpenSourceIndia
 
Naveen nimmu sdn future of networking
Naveen nimmu sdn   future of networkingNaveen nimmu sdn   future of networking
Naveen nimmu sdn future of networking
suniltomar04
 
The Modern Telco Network: Defining The Telco Cloud
The Modern Telco Network: Defining The Telco CloudThe Modern Telco Network: Defining The Telco Cloud
The Modern Telco Network: Defining The Telco Cloud
Marco Rodrigues
 
The Challenges of SDN/OpenFlow in an Operational and Large-scale Network
The Challenges of SDN/OpenFlow in an Operational and Large-scale NetworkThe Challenges of SDN/OpenFlow in an Operational and Large-scale Network
The Challenges of SDN/OpenFlow in an Operational and Large-scale Network
Open Networking Summits
 
Openlab.2014 02-13.major.vi sion
Openlab.2014 02-13.major.vi sionOpenlab.2014 02-13.major.vi sion
Openlab.2014 02-13.major.vi sion
Ccie Light
 
Feec telecom-nw-softwarization-aug-2015
Feec telecom-nw-softwarization-aug-2015Feec telecom-nw-softwarization-aug-2015
Feec telecom-nw-softwarization-aug-2015
Christian Esteve Rothenberg
 
Software Defined Networking in GÉANT
Software Defined Networking in GÉANTSoftware Defined Networking in GÉANT
Software Defined Networking in GÉANT
GÉANT
 

Similar to Three years of OFELIA - taking stock (20)

OpenFlow Tutorial
OpenFlow TutorialOpenFlow Tutorial
OpenFlow Tutorial
 
IRATI Experimentation, US-EU FIRE Workshop
IRATI Experimentation, US-EU FIRE WorkshopIRATI Experimentation, US-EU FIRE Workshop
IRATI Experimentation, US-EU FIRE Workshop
 
Introduction to SDN
Introduction to SDNIntroduction to SDN
Introduction to SDN
 
On SDN Research Topics - Christian Esteve Rothenberg
On SDN Research Topics - Christian Esteve RothenbergOn SDN Research Topics - Christian Esteve Rothenberg
On SDN Research Topics - Christian Esteve Rothenberg
 
07 (IDNOG02) SDN Research activity in Institut Teknologi Bandung by Affan Bas...
07 (IDNOG02) SDN Research activity in Institut Teknologi Bandung by Affan Bas...07 (IDNOG02) SDN Research activity in Institut Teknologi Bandung by Affan Bas...
07 (IDNOG02) SDN Research activity in Institut Teknologi Bandung by Affan Bas...
 
Can today’s Internet protocols deliver URLLC?
Can today’s Internet protocols deliver URLLC?Can today’s Internet protocols deliver URLLC?
Can today’s Internet protocols deliver URLLC?
 
Network research
Network researchNetwork research
Network research
 
Intro to Project Calico: a pure layer 3 approach to scale-out networking
Intro to Project Calico: a pure layer 3 approach to scale-out networkingIntro to Project Calico: a pure layer 3 approach to scale-out networking
Intro to Project Calico: a pure layer 3 approach to scale-out networking
 
Introduction to Software Defined Networking (SDN)
Introduction to Software Defined Networking (SDN)Introduction to Software Defined Networking (SDN)
Introduction to Software Defined Networking (SDN)
 
Introductionto SDN
Introductionto SDN Introductionto SDN
Introductionto SDN
 
Future services on Janet
Future services on JanetFuture services on Janet
Future services on Janet
 
Software Defined Optical Networks - Mayur Channegowda
Software Defined Optical Networks - Mayur ChannegowdaSoftware Defined Optical Networks - Mayur Channegowda
Software Defined Optical Networks - Mayur Channegowda
 
Software Defined Optical Networks - Mayur Channegowda
Software Defined Optical Networks - Mayur ChannegowdaSoftware Defined Optical Networks - Mayur Channegowda
Software Defined Optical Networks - Mayur Channegowda
 
Naveen nimmu sdn future of networking
Naveen nimmu sdn   future of networkingNaveen nimmu sdn   future of networking
Naveen nimmu sdn future of networking
 
Naveen nimmu sdn future of networking
Naveen nimmu sdn   future of networkingNaveen nimmu sdn   future of networking
Naveen nimmu sdn future of networking
 
The Modern Telco Network: Defining The Telco Cloud
The Modern Telco Network: Defining The Telco CloudThe Modern Telco Network: Defining The Telco Cloud
The Modern Telco Network: Defining The Telco Cloud
 
The Challenges of SDN/OpenFlow in an Operational and Large-scale Network
The Challenges of SDN/OpenFlow in an Operational and Large-scale NetworkThe Challenges of SDN/OpenFlow in an Operational and Large-scale Network
The Challenges of SDN/OpenFlow in an Operational and Large-scale Network
 
Openlab.2014 02-13.major.vi sion
Openlab.2014 02-13.major.vi sionOpenlab.2014 02-13.major.vi sion
Openlab.2014 02-13.major.vi sion
 
Feec telecom-nw-softwarization-aug-2015
Feec telecom-nw-softwarization-aug-2015Feec telecom-nw-softwarization-aug-2015
Feec telecom-nw-softwarization-aug-2015
 
Software Defined Networking in GÉANT
Software Defined Networking in GÉANTSoftware Defined Networking in GÉANT
Software Defined Networking in GÉANT
 

More from FIBRE Testbed

WPEIF 2019 - Evolução do testbed FIBRE
WPEIF 2019 - Evolução do testbed FIBREWPEIF 2019 - Evolução do testbed FIBRE
WPEIF 2019 - Evolução do testbed FIBRE
FIBRE Testbed
 
Introdução ao Testbed FIBRE e visão de futuro
Introdução ao Testbed FIBRE e visão de futuroIntrodução ao Testbed FIBRE e visão de futuro
Introdução ao Testbed FIBRE e visão de futuro
FIBRE Testbed
 
Serviço para Experimentação FIBRE
Serviço para Experimentação FIBREServiço para Experimentação FIBRE
Serviço para Experimentação FIBRE
FIBRE Testbed
 
FIBRE presentation at GEC25
FIBRE presentation at GEC25FIBRE presentation at GEC25
FIBRE presentation at GEC25
FIBRE Testbed
 
Projeto de Elasticidade e Evolução do Projeto FIBRE
Projeto de Elasticidade e Evolução do Projeto FIBREProjeto de Elasticidade e Evolução do Projeto FIBRE
Projeto de Elasticidade e Evolução do Projeto FIBRE
FIBRE Testbed
 
Future Internet Brazilian Environment for Experimentation
Future Internet Brazilian Environment for ExperimentationFuture Internet Brazilian Environment for Experimentation
Future Internet Brazilian Environment for Experimentation
FIBRE Testbed
 
FIBRE testbed: Future Perspectives
FIBRE testbed: Future PerspectivesFIBRE testbed: Future Perspectives
FIBRE testbed: Future Perspectives
FIBRE Testbed
 
FIBRE testbed: passado, presente e perspectivas
FIBRE testbed: passado, presente e perspectivasFIBRE testbed: passado, presente e perspectivas
FIBRE testbed: passado, presente e perspectivas
FIBRE Testbed
 
Fibre legacy testbed cloudscape
Fibre legacy testbed cloudscapeFibre legacy testbed cloudscape
Fibre legacy testbed cloudscape
FIBRE Testbed
 
FIBRE (legacy) testbed Future Perspectives
FIBRE (legacy) testbed Future PerspectivesFIBRE (legacy) testbed Future Perspectives
FIBRE (legacy) testbed Future Perspectives
FIBRE Testbed
 
Using Future Internet testbeds in the classroom
Using Future Internet testbeds in the classroomUsing Future Internet testbeds in the classroom
Using Future Internet testbeds in the classroom
FIBRE Testbed
 
FIBRE on AmLight
FIBRE on AmLightFIBRE on AmLight
FIBRE on AmLight
FIBRE Testbed
 
Pilot Use Case 3: BoD services over the intercontinental FIBRE infrastructure
Pilot Use Case 3: BoD services  over the intercontinental FIBRE infrastructurePilot Use Case 3: BoD services  over the intercontinental FIBRE infrastructure
Pilot Use Case 3: BoD services over the intercontinental FIBRE infrastructure
FIBRE Testbed
 
FIBRE at a glance - TNC14
FIBRE at a glance - TNC14 FIBRE at a glance - TNC14
FIBRE at a glance - TNC14
FIBRE Testbed
 
Monitoring in Federated Future Internet Testbeds: the FIBRE case
Monitoring in Federated Future Internet Testbeds: the FIBRE caseMonitoring in Federated Future Internet Testbeds: the FIBRE case
Monitoring in Federated Future Internet Testbeds: the FIBRE case
FIBRE Testbed
 
SDN for Network Operators
SDN for Network OperatorsSDN for Network Operators
SDN for Network Operators
FIBRE Testbed
 
Approaching Content Delivery in Software Defined Networking
Approaching Content Delivery in Software Defined NetworkingApproaching Content Delivery in Software Defined Networking
Approaching Content Delivery in Software Defined Networking
FIBRE Testbed
 
Colt's SDN/NFV Vision
Colt's SDN/NFV VisionColt's SDN/NFV Vision
Colt's SDN/NFV Vision
FIBRE Testbed
 
From GMPLS to OpenFlow Control & Monitoring of Optical Networks
From GMPLS to OpenFlow Control & Monitoring of Optical NetworksFrom GMPLS to OpenFlow Control & Monitoring of Optical Networks
From GMPLS to OpenFlow Control & Monitoring of Optical Networks
FIBRE Testbed
 
Route flow autoconf demo 2nd sdn world congress 2013
Route flow autoconf demo   2nd sdn world congress 2013Route flow autoconf demo   2nd sdn world congress 2013
Route flow autoconf demo 2nd sdn world congress 2013
FIBRE Testbed
 

More from FIBRE Testbed (20)

WPEIF 2019 - Evolução do testbed FIBRE
WPEIF 2019 - Evolução do testbed FIBREWPEIF 2019 - Evolução do testbed FIBRE
WPEIF 2019 - Evolução do testbed FIBRE
 
Introdução ao Testbed FIBRE e visão de futuro
Introdução ao Testbed FIBRE e visão de futuroIntrodução ao Testbed FIBRE e visão de futuro
Introdução ao Testbed FIBRE e visão de futuro
 
Serviço para Experimentação FIBRE
Serviço para Experimentação FIBREServiço para Experimentação FIBRE
Serviço para Experimentação FIBRE
 
FIBRE presentation at GEC25
FIBRE presentation at GEC25FIBRE presentation at GEC25
FIBRE presentation at GEC25
 
Projeto de Elasticidade e Evolução do Projeto FIBRE
Projeto de Elasticidade e Evolução do Projeto FIBREProjeto de Elasticidade e Evolução do Projeto FIBRE
Projeto de Elasticidade e Evolução do Projeto FIBRE
 
Future Internet Brazilian Environment for Experimentation
Future Internet Brazilian Environment for ExperimentationFuture Internet Brazilian Environment for Experimentation
Future Internet Brazilian Environment for Experimentation
 
FIBRE testbed: Future Perspectives
FIBRE testbed: Future PerspectivesFIBRE testbed: Future Perspectives
FIBRE testbed: Future Perspectives
 
FIBRE testbed: passado, presente e perspectivas
FIBRE testbed: passado, presente e perspectivasFIBRE testbed: passado, presente e perspectivas
FIBRE testbed: passado, presente e perspectivas
 
Fibre legacy testbed cloudscape
Fibre legacy testbed cloudscapeFibre legacy testbed cloudscape
Fibre legacy testbed cloudscape
 
FIBRE (legacy) testbed Future Perspectives
FIBRE (legacy) testbed Future PerspectivesFIBRE (legacy) testbed Future Perspectives
FIBRE (legacy) testbed Future Perspectives
 
Using Future Internet testbeds in the classroom
Using Future Internet testbeds in the classroomUsing Future Internet testbeds in the classroom
Using Future Internet testbeds in the classroom
 
FIBRE on AmLight
FIBRE on AmLightFIBRE on AmLight
FIBRE on AmLight
 
Pilot Use Case 3: BoD services over the intercontinental FIBRE infrastructure
Pilot Use Case 3: BoD services  over the intercontinental FIBRE infrastructurePilot Use Case 3: BoD services  over the intercontinental FIBRE infrastructure
Pilot Use Case 3: BoD services over the intercontinental FIBRE infrastructure
 
FIBRE at a glance - TNC14
FIBRE at a glance - TNC14 FIBRE at a glance - TNC14
FIBRE at a glance - TNC14
 
Monitoring in Federated Future Internet Testbeds: the FIBRE case
Monitoring in Federated Future Internet Testbeds: the FIBRE caseMonitoring in Federated Future Internet Testbeds: the FIBRE case
Monitoring in Federated Future Internet Testbeds: the FIBRE case
 
SDN for Network Operators
SDN for Network OperatorsSDN for Network Operators
SDN for Network Operators
 
Approaching Content Delivery in Software Defined Networking
Approaching Content Delivery in Software Defined NetworkingApproaching Content Delivery in Software Defined Networking
Approaching Content Delivery in Software Defined Networking
 
Colt's SDN/NFV Vision
Colt's SDN/NFV VisionColt's SDN/NFV Vision
Colt's SDN/NFV Vision
 
From GMPLS to OpenFlow Control & Monitoring of Optical Networks
From GMPLS to OpenFlow Control & Monitoring of Optical NetworksFrom GMPLS to OpenFlow Control & Monitoring of Optical Networks
From GMPLS to OpenFlow Control & Monitoring of Optical Networks
 
Route flow autoconf demo 2nd sdn world congress 2013
Route flow autoconf demo   2nd sdn world congress 2013Route flow autoconf demo   2nd sdn world congress 2013
Route flow autoconf demo 2nd sdn world congress 2013
 

Recently uploaded

BLOCKCHAIN TECHNOLOGY - Advantages and Disadvantages
BLOCKCHAIN TECHNOLOGY - Advantages and DisadvantagesBLOCKCHAIN TECHNOLOGY - Advantages and Disadvantages
BLOCKCHAIN TECHNOLOGY - Advantages and Disadvantages
SAI KAILASH R
 
Semantic-Aware Code Model: Elevating the Future of Software Development
Semantic-Aware Code Model: Elevating the Future of Software DevelopmentSemantic-Aware Code Model: Elevating the Future of Software Development
Semantic-Aware Code Model: Elevating the Future of Software Development
Baishakhi Ray
 
Zaitechno Handheld Raman Spectrometer.pdf
Zaitechno Handheld Raman Spectrometer.pdfZaitechno Handheld Raman Spectrometer.pdf
Zaitechno Handheld Raman Spectrometer.pdf
AmandaCheung15
 
Step-By-Step Process to Develop a Mobile App From Scratch
Step-By-Step Process to Develop a Mobile App From ScratchStep-By-Step Process to Develop a Mobile App From Scratch
Step-By-Step Process to Develop a Mobile App From Scratch
softsuave
 
Vertex AI Agent Builder - GDG Alicante - Julio 2024
Vertex AI Agent Builder - GDG Alicante - Julio 2024Vertex AI Agent Builder - GDG Alicante - Julio 2024
Vertex AI Agent Builder - GDG Alicante - Julio 2024
Nicolás Lopéz
 
Girls call Kolkata 👀 XXXXXXXXXXX 👀 Rs.9.5 K Cash Payment With Room Delivery
Girls call Kolkata 👀 XXXXXXXXXXX 👀 Rs.9.5 K Cash Payment With Room Delivery Girls call Kolkata 👀 XXXXXXXXXXX 👀 Rs.9.5 K Cash Payment With Room Delivery
Girls call Kolkata 👀 XXXXXXXXXXX 👀 Rs.9.5 K Cash Payment With Room Delivery
sunilverma7884
 
UX Webinar Series: Drive Revenue and Decrease Costs with Passkeys for Consume...
UX Webinar Series: Drive Revenue and Decrease Costs with Passkeys for Consume...UX Webinar Series: Drive Revenue and Decrease Costs with Passkeys for Consume...
UX Webinar Series: Drive Revenue and Decrease Costs with Passkeys for Consume...
FIDO Alliance
 
Acumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdf
Acumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdfAcumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdf
Acumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdf
BrainSell Technologies
 
Generative AI Reasoning Tech Talk - July 2024
Generative AI Reasoning Tech Talk - July 2024Generative AI Reasoning Tech Talk - July 2024
Generative AI Reasoning Tech Talk - July 2024
siddu769252
 
UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...
UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...
UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...
FIDO Alliance
 
Integrating Kafka with MuleSoft 4 and usecase
Integrating Kafka with MuleSoft 4 and usecaseIntegrating Kafka with MuleSoft 4 and usecase
Integrating Kafka with MuleSoft 4 and usecase
shyamraj55
 
Types of Weaving loom machine & it's technology
Types of Weaving loom machine & it's technologyTypes of Weaving loom machine & it's technology
Types of Weaving loom machine & it's technology
ldtexsolbl
 
kk vathada _digital transformation frameworks_2024.pdf
kk vathada _digital transformation frameworks_2024.pdfkk vathada _digital transformation frameworks_2024.pdf
kk vathada _digital transformation frameworks_2024.pdf
KIRAN KV
 
Google I/O Extended Harare Merged Slides
Google I/O Extended Harare Merged SlidesGoogle I/O Extended Harare Merged Slides
Google I/O Extended Harare Merged Slides
Google Developer Group - Harare
 
Use Cases & Benefits of RPA in Manufacturing in 2024.pptx
Use Cases & Benefits of RPA in Manufacturing in 2024.pptxUse Cases & Benefits of RPA in Manufacturing in 2024.pptx
Use Cases & Benefits of RPA in Manufacturing in 2024.pptx
SynapseIndia
 
The Impact of the Internet of Things (IoT) on Smart Homes and Cities
The Impact of the Internet of Things (IoT) on Smart Homes and CitiesThe Impact of the Internet of Things (IoT) on Smart Homes and Cities
The Impact of the Internet of Things (IoT) on Smart Homes and Cities
Arpan Buwa
 
Acumatica vs. Sage Intacct _Construction_July (1).pptx
Acumatica vs. Sage Intacct _Construction_July (1).pptxAcumatica vs. Sage Intacct _Construction_July (1).pptx
Acumatica vs. Sage Intacct _Construction_July (1).pptx
BrainSell Technologies
 
Using LLM Agents with Llama 3, LangGraph and Milvus
Using LLM Agents with Llama 3, LangGraph and MilvusUsing LLM Agents with Llama 3, LangGraph and Milvus
Using LLM Agents with Llama 3, LangGraph and Milvus
Zilliz
 
Gen AI: Privacy Risks of Large Language Models (LLMs)
Gen AI: Privacy Risks of Large Language Models (LLMs)Gen AI: Privacy Risks of Large Language Models (LLMs)
Gen AI: Privacy Risks of Large Language Models (LLMs)
Debmalya Biswas
 
Feature sql server terbaru performance.pptx
Feature sql server terbaru performance.pptxFeature sql server terbaru performance.pptx
Feature sql server terbaru performance.pptx
ssuser1915fe1
 

Recently uploaded (20)

BLOCKCHAIN TECHNOLOGY - Advantages and Disadvantages
BLOCKCHAIN TECHNOLOGY - Advantages and DisadvantagesBLOCKCHAIN TECHNOLOGY - Advantages and Disadvantages
BLOCKCHAIN TECHNOLOGY - Advantages and Disadvantages
 
Semantic-Aware Code Model: Elevating the Future of Software Development
Semantic-Aware Code Model: Elevating the Future of Software DevelopmentSemantic-Aware Code Model: Elevating the Future of Software Development
Semantic-Aware Code Model: Elevating the Future of Software Development
 
Zaitechno Handheld Raman Spectrometer.pdf
Zaitechno Handheld Raman Spectrometer.pdfZaitechno Handheld Raman Spectrometer.pdf
Zaitechno Handheld Raman Spectrometer.pdf
 
Step-By-Step Process to Develop a Mobile App From Scratch
Step-By-Step Process to Develop a Mobile App From ScratchStep-By-Step Process to Develop a Mobile App From Scratch
Step-By-Step Process to Develop a Mobile App From Scratch
 
Vertex AI Agent Builder - GDG Alicante - Julio 2024
Vertex AI Agent Builder - GDG Alicante - Julio 2024Vertex AI Agent Builder - GDG Alicante - Julio 2024
Vertex AI Agent Builder - GDG Alicante - Julio 2024
 
Girls call Kolkata 👀 XXXXXXXXXXX 👀 Rs.9.5 K Cash Payment With Room Delivery
Girls call Kolkata 👀 XXXXXXXXXXX 👀 Rs.9.5 K Cash Payment With Room Delivery Girls call Kolkata 👀 XXXXXXXXXXX 👀 Rs.9.5 K Cash Payment With Room Delivery
Girls call Kolkata 👀 XXXXXXXXXXX 👀 Rs.9.5 K Cash Payment With Room Delivery
 
UX Webinar Series: Drive Revenue and Decrease Costs with Passkeys for Consume...
UX Webinar Series: Drive Revenue and Decrease Costs with Passkeys for Consume...UX Webinar Series: Drive Revenue and Decrease Costs with Passkeys for Consume...
UX Webinar Series: Drive Revenue and Decrease Costs with Passkeys for Consume...
 
Acumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdf
Acumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdfAcumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdf
Acumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdf
 
Generative AI Reasoning Tech Talk - July 2024
Generative AI Reasoning Tech Talk - July 2024Generative AI Reasoning Tech Talk - July 2024
Generative AI Reasoning Tech Talk - July 2024
 
UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...
UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...
UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...
 
Integrating Kafka with MuleSoft 4 and usecase
Integrating Kafka with MuleSoft 4 and usecaseIntegrating Kafka with MuleSoft 4 and usecase
Integrating Kafka with MuleSoft 4 and usecase
 
Types of Weaving loom machine & it's technology
Types of Weaving loom machine & it's technologyTypes of Weaving loom machine & it's technology
Types of Weaving loom machine & it's technology
 
kk vathada _digital transformation frameworks_2024.pdf
kk vathada _digital transformation frameworks_2024.pdfkk vathada _digital transformation frameworks_2024.pdf
kk vathada _digital transformation frameworks_2024.pdf
 
Google I/O Extended Harare Merged Slides
Google I/O Extended Harare Merged SlidesGoogle I/O Extended Harare Merged Slides
Google I/O Extended Harare Merged Slides
 
Use Cases & Benefits of RPA in Manufacturing in 2024.pptx
Use Cases & Benefits of RPA in Manufacturing in 2024.pptxUse Cases & Benefits of RPA in Manufacturing in 2024.pptx
Use Cases & Benefits of RPA in Manufacturing in 2024.pptx
 
The Impact of the Internet of Things (IoT) on Smart Homes and Cities
The Impact of the Internet of Things (IoT) on Smart Homes and CitiesThe Impact of the Internet of Things (IoT) on Smart Homes and Cities
The Impact of the Internet of Things (IoT) on Smart Homes and Cities
 
Acumatica vs. Sage Intacct _Construction_July (1).pptx
Acumatica vs. Sage Intacct _Construction_July (1).pptxAcumatica vs. Sage Intacct _Construction_July (1).pptx
Acumatica vs. Sage Intacct _Construction_July (1).pptx
 
Using LLM Agents with Llama 3, LangGraph and Milvus
Using LLM Agents with Llama 3, LangGraph and MilvusUsing LLM Agents with Llama 3, LangGraph and Milvus
Using LLM Agents with Llama 3, LangGraph and Milvus
 
Gen AI: Privacy Risks of Large Language Models (LLMs)
Gen AI: Privacy Risks of Large Language Models (LLMs)Gen AI: Privacy Risks of Large Language Models (LLMs)
Gen AI: Privacy Risks of Large Language Models (LLMs)
 
Feature sql server terbaru performance.pptx
Feature sql server terbaru performance.pptxFeature sql server terbaru performance.pptx
Feature sql server terbaru performance.pptx
 

Three years of OFELIA - taking stock

  • 1. Three years of OFELIA – taking stock by Hagen Woesner OFELIA project coordinator
  • 3. Taking stock • OFELIA proposal was written in late 2009 – OpenFlow was at v0.9, way before anything like ONF – Rob Sherwood and Srini Seetharaman were employees of DT Labs – Guru and Nick came over to Berlin quite frequently, talking about their campus testbed in Stanford – Some people of DT wanted to bring over this great idea to Europe
  • 4. I suggested calling the project OFELIA because of the nice connotation to an open flow…
  • 5. As a baby name, OFELIA is not very popular
  • 7. Why was OpenFlow embraced by carriers? • The world of network equipment vendors was unchanged since ~1990 – Some consolidations in Europe, two new players from China • The market of carriers was in full crisis – Google – Facebook – Over the top players with no commercial connection to the network owners
  • 8. If your revenue falls 22% per annum, would you call this a crisis? Relative scale 5 Enormous complexity. Traffic Traffic *Cost Traffic *Revenue Rev/Cost Router Cost per Mbit Revenue per Mbit 4 3 2 1 0 0 1 2 Year 3 4  Internet traffic growth at about 50% per year  Cost reduction of router per Mbit/s 15 % per year  Revenue per Mbit/s falls steeper (22 % per year) (the effect) 5 RFCs published annually Total number of RFCs The gap of traffic, cost and revenue ... 6000 5000 4000 3000 2000 1000 0 1965 1970 1975 1980 1985 1990 1995 2000 2005 2010 500 400 300 200 100 0 1970 1980 1990 2000 2010 Year  Huge and confusing amount of standards and RFC  A lot of patches for Security, QoS, MPLS, Demarcation etc. (the effect)
  • 9. No wonder carriers were looking for ways out of the dilemma to: • Participate in revenues from OTT – charging for netflix, youtube, spotify? – If the customer pays a flat rate, revenue has to come from service provider • Make the network drastically simpler – Split control from data planes – Abandon all vendor-specific solutions – Remove as much as possible session state from network devices
  • 10. Some details on “complexity” for the fixed access network Upstream Interface • IS-IS Routing • BGP • MPLS LDP • Static Routing RADIUS Interface • LineID = User • FilterClass by ID • CoA for Filter Change • All line Attributes included Astra UpStream Routing AAA BNG Functionality • S-Tags in Session Context • RemoteID in Session Contex • CircuitID in Session Context • Static Filter Per Product • Filter assigned by RADIUS • Dynamic Change by CoA • Six QoS Classes • Bandwith control per Session • Multicast Replication on BNG RADIUS Client Ethernet Port BNG Ethernet Port#1 S-TAG Ethernet Port#1 S-TAG S-TAG -TAG S-TAG S-TAG -TAG S-TAG VLAN#X PPPoE BIP VLAN#Y S-TAG S-TAG Ethernet Port MSAN Functionality • Port becomes S-TAG • Pysical Port in Circuit-Id MSANId+Port=Circuit-Id • Provisioned Remote-Id per Port Based on ITU-T M.1400 • PPPoE IA includes Ids • C-Tags Transparent Ethernet Port MSAN#1 One S-TAG per Access Port MSAN#2 Port#12 Port#12 VDSL Port#12 VDSL VDSL VLAN#X PPPoE Port#12 VLAN#X PPPoE VDSL BIP VLAN#Y VLAN#X PPPoE VDSL VDSL VDSL VDSL RG#1 RG#2 RG#1 RG#2 IAD Functionlity • PPPoE Discovery on VLAN7 • Residential on VLAN7 flat • BIP on VLAN #Y 10
  • 11. So, two projects were initiated • Split Architecture for Carrier networks (SPARC) – DT and Ericsson – iMinds, Acreo, EICT • MPLS-controlled access • BRAS • Virtualization of networks • And OFELIA, for trying out the things developed
  • 14. Requirement OFELIA Resource discovery Seeing aggregates in GUI, later on: topology Resource reservation Aggregate managers for VMs, Flowspaces, WiFi Resource provisioning Flowspace reservation manually approved by island managers Experiment control WebGUI (expedient) Monitoring For island admins: zenoss, experimenters: web site Permanent storage n/a, but flowspace reservation remains in place for 30 days by default Identity management Currently: LDAP, coming up: O’House Authorization Open to the public. Closed and trusted group, access granted once alongside with OpenVPN certificate, to be improved with OHouse SLA management OHouse First Level Support Zenoss data on web site Dataplane interconnection Currently best effort L2 tunnels across the Internet VLAN stitching with lots of manual intervention 14
  • 15. VLAN stitching berli n brist ol ETH Z iMinds • Researcher requests VLAN space in each island • Resolve conflicts later • MANUALLY! – Poor Bart. i2cat Trent o/ Creat e-Net • “clashing engine” is being implemented
  • 16. Ways to overcome VLAN clashing • Centralized assignment of VIDs – As of now, we have a range for inter-island ViDs assigned • VID translation • Different slicing scheme
  • 17. Centralized assignment of VIDs • Centralized VLAN assignment – For cross-island experiments VLANs to be assigned via separate AM GUI/omni FOAM VLAN AM FOAM FOAM FOAM FOAM
  • 18. Centralized assignment of VIDs • Wait until someone finds it too complicated and cleans up • centralized FOAM GUI/omni FOAM VLAN AM+FOAM FOAM FOAM FOAM FOAM
  • 19. VLAN translation • Slightly unusual practice for VLANs – Not working in standard Ethernet switches • Starts to look like MPLS (to me?) – There are good papers on using MPLS for OF virtualisation • In principle possible via software OF switches – Need to create (and signal) the mappings
  • 20. A different slicing mechanism? Many were increasingly of the opinion that they'd all made a big mistake in coming down from the trees in the first place. And some said that even the trees had been a bad move, and that no one should ever have left the oceans. • VLANs seemed like a good idea because of aggregation, but why did we want to aggregate? – Because TCAM space is the scarce resource • So why do we slice flowspace and not TCAM space? • We (in OFELIA) have MAC address assignment under our control, so we could slice on MACs? – The FlowVisor explosion may be mitigated by clever setting of entries • What about a combination of TCAM limitation and MAC slicing?
  • 21. Three ways of virtualizing • Slicing the flowspace – FlowVisor does this, partially • Translating the flowspace – FlowVisor 2.0 goes this way – Process/modify each packet (incl. TTL!) • Transparent tagging – MPLS etc. (Pontus Sköldström and Wolfgang John: “Implementation and Evaluation of a carrier-grade OpenFlow Virtualization Scheme”; EWSDN 2013) This is the fundamental testbed question: How much of the flowspace are we assigning for experimentation, and how much for the experiment?
  • 22. Without deciding on virtualization schemes, what can we do? • FlowVisor upgrade beyond OF 1.0 • OF datapath upgrade to new OF versions • Signaling between islands (be it so VIDs)
  • 23. FP7 project ALIEN • Integration of FV functionality into OpenFlow datapath – Add flowspace management into the switch (mgmt interface like fvctl) – Add flowspace management into OpenFlow, eventually • Deploy OpenFlow beyond Linux/x86 – NPUs (Cavium, Ezchip), NetFPGA, GEPON, optics • Check https://www.codebasin.net/redmine/projects/xdpd/wiki
  • 25. FP7 project FELIX Framework of EU-Japan collaboration •
  • 26. FP7 project FELIX For EICT, this will eventually mean writing an AMSoil-based AM for NSI v.2
  • 27. Intermediate conclusions • There has to be a better solution than manual assignment of VLAN IDs • We should either upgrade FV or get rid of it • Porting OpenFlow to alien hardware leads to •  Open Source Hardware? – Should there be an endorsement/requirement to use open hardware for testbeds? • NSI v2 seems to be the means of choice to bridge networks between OF controlled islands. – For high-bandwidth, on-demand applications – Otherwise OpenVPN or manual (QinQ) SID assignment is just fine.
  • 28. What is the best collaborative model? • One that is building on the egoistic interest of a testbed user – Only users can operate and develop testbeds • Federation is key – Increase geographic reach – Draw on other researchers’ knowledge • Three things required for federation – Powerful resource description (language)  Rspecs – Connectivity and resource provisioning  Aggregate Managers – Trust (authentication, authorisation)  Clearinghouse
  • 29. Experiments and what we learned from them Thanks to Panos and Matt of Lancaster University for writing up their experience.
  • 30. One experiment: virtual topology creation by modified FlowVisors Implemented mainly be Create-Net, Italy
  • 31. Lancaster University joined the OFELIA project as an experimenter. To this effect they provided feedback at the beginning of the 3rd year of the project, describing the usability of the facility. Experiment is on: Video-on-Demand Content Caching with OpenFlow
  • 32. Video-on-Demand Content Caching with OpenFlow (1) An OpenFlow network with peripheral content caches
  • 33. Video-on-Demand Content Caching with OpenFlow (2) First interaction: Content silently copied to cache
  • 34. Video-on-Demand Content Caching with OpenFlow (3) Later interactions: Content retrieved from cache
  • 37. Now this is a workflow to really get lost, right?
  • 38. “Registering, creating a project, adding a slice to it and the respective Aggregate Managers (AMs) all work quite well.” Uff…
  • 40. Remove the manual approval delay from the process • ...by approving everything automatically. – The respective island managers should still get the notification emails, but the default action from the system should be to automatically approve a project (and/or an associated action). – This would make the facility appear way more responsive and user-friendly. After all, when a user is creating a project, he wants to start experimenting with the facility straight away.
  • 41. Where are all the OFELIA islands? • As a more generic comment, we advertise having 10 islands on the OFELIA testbed but there are only 4 islands available for federated tests (through their AMs); ETHZ, i2CAT, iMinds and Create-Net. Perhaps adding the rest of the AMs would provide a more enhanced facility. • OK, one is providing strange resources like optical switches (AM for this still under development), one had a hard disk crash, and others are just on their way to really becoming available (joined recently)
  • 42. More feedback to the experimenter! • The way of booking resources for carrying out federated experiments is not very clear (despite the tutorial). In our opinion the user requires more feedback as what he should do next (i.e. the next step) and what the system tries to do each time as a response to a user’s request. A few more concrete suggestions :
  • 43. Flowspaces and VLANs are unclear • The concept of Flowspaces is not very clear to the user (i.e. what is it and what he should do “with it”). • Related to the above, the concept of VLANs is also not obvious to the user. Obviously this is how experiments in OFELIA are defined, but it might be worthwhile making it clear to the user that the same VLAN is needed for tests across multiple islands (we expect him to figure it out). – Furthermore, if certain VLANs are not available to the user (reserved in certain islands) then Expedient should disallow these from being requested by a user. –Suggestion : Perhaps a drop down box of the available VLANs or an informative table about the availability of VLANs would help.
  • 44. And then some smallprint 1)Also, it is not very clear when the user should update his slice. Is updating the slice done automatically every time we change the resources? Should the user update the slice when he restarts his controller? (we’ve found that sometimes this is required). a.Suggestion : perhaps more information regarding when the user should update this slice in relation to the changes he does to his slice is required. 2)Some error messages are too generic and unhelpful to the user. For example, the error messages coming from a FlowVisor do not report which FlowVisor is generating the messages. The user does not know how to fix this problem (he doesn’t have access to any FlowVisors) and he doesn’t even have enough information as to whom (i.e. which island manager) he should contact regarding these messages[1]. a.Suggestion : Perhaps making the error messages more specific to the actual problem. Also contact details of island managers or an alias email should be displayed to the user so that he knows whom to contact if there is a particular error message. 3)Minor : The Topology of the slice is useful, but if the user has chosen a subset of it for his experiments, it would be useful to see active just the subset in the main page of his slice. a.Suggestion : Perhaps getting the links/machines/switches used in a Flowspace as bold, or a drop down menu that would give the option of toggling between “Available Topology” and “Used Topology” would be useful. 4)Minor : When the user hovers over a switch it would be useful to see information about the links to VMs as well (in addition to the ones we see now for the connected switches).
  • 45. And then some more smallprint Minor : Sometimes when a small number or resources is allocated to a slice, the actual icons do not appear in the Topology panel and they are “floating” around. •Perhaps most importantly, the requirement for manual approval of the user’s requested Flowspace from each island manager involved in an experiment, is making the facility non-friendly for experiments. It is important that we change to an automated approval of the Flowspace, as it is high likely that in an experimental facility the user would add/remove AMs, update his controller, add/remove links/VMs/switches frequently and thus waiting for hours/days for manual approval of each change from each respective island manager involved in the experiment, makes the facility cumbersome for experimentation. •There can be consistency issues between the visual interface and reality. For example, a newly created VM can get stuck in a perpetual state of ‘starting’. Yet in reality, the VM has started perfectly fine and is fully accessible via SSH. There is no way to stop/delete these VMs stuck in this perpetual state. •The standard VM image used on the island is now somewhat dated. Ideally, this image should be replaced with a newer version of Debian. If possible, a selection of distributions should also be made available. Many of the experiments that we envisaged on OFELIA require current/cutting-edge packages and repositories that are otherwise not available in an older release. Building software is therefore unnecessarily painful and time consuming. We also encountered a number of bugs that have been fixed in later releases of the OS. •We also had a number of connectivity problems whilst experimenting on OFELIA. As a result, we had to turn to a number of island managers to help us out. Although incredibly helpful and more than willing to assist us, the island managers seemed ill-equipped to debug issues quickly and effectively. It might be worthwhile putting together a toolkit for troubleshooting islands, and then making this available to all island managers. Furthermore, finding and isolating these problems quickly is of absolute importance, especially when non-project users are experimenting on the testbed. An easy solution to this is to create a monitoring slice within the testbed (Matt is working on this). Periodically checking for connectivity between islands could provide a simple feedback mechanism that can alert island managers when their island goes ‘dark’.
  • 46. Next steps • Finish Clearinghouse • Get an idea on how to stitch VLANs – Without introducing centralized VID mgmt – VLAN “clashing engine” was implemented • Drastically clean up workflow and GUI. • Eventually: OCF in a box – VM appliance • OFELIA project itself is ending now, but islands have signed MoU to continue operation – FIBRE, FELIX, ALIEN FP7 projects can carry out some development work • And I encourage you very much to do so!