2. Objective
• A software project, that feeds from research.
– Enable long-term research to happen on top of it.
• And leverage past research and assets.
• Create a community that allows several stakeholders to
contribute and benefit from a common NaaS software
stack.
• Open Source, Open community.
– Solid base functionality that can be used on a production
environement.
• Users increase life span.
• Faster research output adoption.
8. get & compile & install
• Built it from scratch:
8
$ git clone git://github.com/dana-i2cat/opennaas.git
$ cd opennaas
$ git checkout develop # optional
$ mvn install
$ cd opennaas
$ mvn clean
$ git pull git://github.com/dana-i2cat/opennaas.git
$ mvn install
$ cp –r platform/target/opennaas-0.10 /srv
$ cd /srv/opennaas-0.10
$ ./bin/opennaas.sh
• Update from source:
• Run it:
Fetch code
Fetch unstable
Built it
Clean past built
Fetch updates
Built it
Enjoy!
11. OpenNaaS Key Requirements
• On demand (commonly user-triggered) provisioning of
network resources.
• Recursive delegation of access right over managed resources.
• Lightweight Abstracted operational model.
– Decoupled from actual vendor-specific details.
– Flexible enough to accomodate diferent designs and orientations
– Fixed enough so common tools can be build and reused across
plugins.
• Security.
• Lifecycle.
• Monitoring.
• Deployment and upgrade.
• Service orchestration.
12. OpenNaaS Stakeholders
• Network Operators
with an interest on
NaaS:
– NREN.
– Cloud Datacenter.
– New services for ISP’s.
• ISV and integrators
– middleware-network
orchestration.
• Developers and
network researchers.
FUSE ServiceMix
Platform
Extensions
Third Party plugins
OTSdistribution
13. OpenNaaS Platform
• For developers and researchers:
– Modern IDEs available
– Maven based build system and
dependency management
– Plugin howto documentation
– Several available open source
plugins as reference
– An open OpenNaaS community
– Comercial support for underlying
technologies
• Leverage building blocks, both using
existing resources or for creating
new ones.
– Resource Respository and Manager
– Protocol Session Manager
– Standard Capabilities
– Protocol Endpoints for remoting
(SOAP, REST, etc).
– Platform manager
– *.apache.org deployment ready
libraries.
• While plugins can chose to use
technologies like hibernate, spring or
ESB, they don’t have to.
18. Platform
CLI
Persistence
Queue
Resource
Manager
. . .
Security
Protocol Session Manager
Resource Lifecycle
Resource Layer
RouterResource
NetworkResource
BoDResource
OpticalSwitch
Resource
...
Remoting
Scripting
GUI
OpenNebula
OpenStackNS
NSA(NSI)
...
3P
Extensions
3P
Middleware
OpenNaaS Architecture
Network Intelligence
• Integration with Northbound
Middleware
• IaaS/Cloud managers
• Other NMS.
• The user
NaaS Layer
• Network HAL abstraction to
infrastructure.
• Resources manageable by the user.
• Access controlled by the Sec.
Manager.
Platform
• Reusable building blocks, common to
all extensions.
• Controls access to the infrastructure.
• Integrity, Policy, etc..
Managed infrastructure
BoD
19. OpenNaaS Platform Base Components
• ResourceManager.
– Manages the persistence and lifecycle of Resources.
– There is a ResourceManager repository implementation for
each ResourceType.
• Which acts as a Factory for that type.
– Implements also Profiles, we’ll see that later.
– Which brings us to the NaaS abstraction reusable concepts;
• Resource
• Resource Type
• Capability
• Action
• ActionSet
• Profile
20. OpenNaaS Platform Base Components
• Reusable concepts:
– A Resource represents a manageable unit inside the NaaS
concept.
• A Resource can be a switch, a router, a link, a logical router, a
network, etc…
– Instantiations of a Resource Type.
• Resources share a simple lifecycle:
– Initialized, loaded in memory.
– Active, accepts calls.
Capability
Resource
RPC
Router
21. OpenNaaS Platform Base Components
• Reusable concepts:
– A Resource represents a
manageable unit inside the NaaS
concept.
• A Resource is decomposed in:
– A model
– An array of Capabilities.
• The ResourceType defines:
– The model.
– Which Capabilities are allowed.
• Which Capabilities are actually
callable will depend on that actual
Resource instance.
» The Resource can be
interrogated.
Capabil
Resourc
RPC
Router
Chassis
GRE
OSPF
22. OpenNaaS Platform Base Components
• Reusable concepts:
– A Capability is an interface to a given
Resource functionality.
• I.e. for a router:
– OSPF, IPv6, Create/manage logical routers,
etc.
• Callable by the user.
– This interface is, as the Model,
abstracted and vendor neutral.
– Internally the Capability, is
implemented for each kind of device.
• Hence, some capabilities might not be
available for some vendors.
– The Capability is the HAL limit for
OpenNaaS.
Capabil
Resourc
RPC
Router
Chassis
GRE
OSPF
23. OpenNaaS Platform Base Components
• Internally, Capabilities need a way to
abstract implementation details of the
devices.
– They use Actions.
• An Action is a vendor (and protocol)
specific implementation of a
configuration modification.
– It can be Queue’d.
– It can be undone (rollback).
• Actions are grouped into an ActionSet.
• On Action.execute(), the action usually
asks to the ProtocolSessionManager
for an appropriate ProtocolSession to
communicate with the device.
Capabil
Resourc
RPC
24. OpenNaaS Platform Base Components
• An Action can be implemented
from scratch:
– Just fill the execute() method with
some code.
• Or reused from some adaptors
we have.
– Most importantly, netconf actions
are very XML-intensive.
– They use a digester rule set for
XML processing
– And Velocity for XML creation.
Capabil
Resourc
RPC
25. OpenNaaS Platform Base Components
• A Profile is an alternative set of
ActionSets.
• They can be deployed at runtime to
the container.
• On creation time, a Profile can be
specified for a given Resource.
• When looking for an Action to execute
(or queue), Capabilities will first check
the Profile for an alternative Action.
– If found, it will be executed instead of
the default one.
• This is a mechanism for OpenNaaS
administrators to modify behaviour of
default capabilities.
Capabil
Resourc
RPC
26. OpenNaaS Platform Base Components
• The QueueManager is used to
stack all Actions to be executed.
– All modifications can be done over
the network at once.
– Allows rollback of Actions.
– Objective: the network-wide
rollback of actions.
– It is both a Capability and a OSGI
Service.
• The user can check and manipulate
the Queue as a Capability.
• The rest of Capabilities can work
with it via the OSGi registry.
– Saves a lot of serialization.
Capabil
Resourc
RPC
28. Fuse ServiceMix
• Standards based
• Open Source
• State of the art technologies
– OSGi, Java 6, Apache SF, Scala, etc
– Roll your own
• Componetized compilation of Apache library.
• Documented
• Comercial support.
• Portable
– Linux, Windows, Mac.
• Not always the latest library versions…
29. Platform
• Based on a component container:
– OSGi R4 (Apache Felix’s implementation)
• Mainly, this allows:
– The application is split components, and they are:
• Started and stopped at runtime.
– Which can be explored and manipulated via the CLI
– Which can be handled programmatically (via events, RPC, etc).
• Installed and updated from a (remote) repository.
– Components are isolated from each other.
• Classes from a bundle cannot import from other bundles.
• Unless explicitly allowed to.
• There is a service publication/consumption registry.
• On OSGi, these components are called bundles.
– A bundle is a jar + some special lines on the MANIFEST.
– Features.xml allow to specify a version of the platform + an initial set
bundles.
32. OpenNaaS Platform
• Embeddable and interoperable.
– Component of a bigger middleware
• i.e. a cloud management infrastructure.
– L-GPLv3 for the platform.
• Foundation of the NaaS layer.
• Reusable concepts across plugins
– Resource, Capability, Action, Lifecycle.
– A command toolset and remoting layer is built around this
concepts.
– Etc
• Shared but defined roadmap.
33. OpenNaaS Platform Base Components
• Leverage building blocks:
– Resource Respository and Manager
• Handles lifecycle and persistence.
– Protocol Session Manager
• Mantains protocol session lifecycle, with an eye on session reusability.
• Additional protocols can be added
– Standard Capabilities
• Queue (for configuration deployment).
– Protocol Endpoints for remoting (SOAP, REST, etc).
– Platform manager
– *.apache.org deployment ready libraries.
• While plugins can chose to use technologies like hibernate, spring or ESB,
they don’t have to.
34. OpenNaaS Platform Base Components
• Protocol Session Manager
– Implements the ProtocolSession abstraction
• Currently we have these implementations:
– Netconf (IRTF).
– Onesys (EMS Module).
– CLI (Telnet, SSH).
– TL1 (TCP, SSL).
– Manages ProtocolSession lifecycle.
• Performs pooling, if possible.
• Reuses sessions (keeps them alive for some minutes).
• ProtocolSession events.
– Isolates ProtocolSession usage from credentials.
• Loads and pairs ProtocolSessionContexts with appropiate device.
• transport://user:password@ip:port/subsystem
53. Roadmap
• Extensions and platform upgrades are performed according to:
– Research projects
– Internal initiatives from i2CAT
– Initiatives from third party extensions
– Privately funded projects from industry
• The roadmap is open to discussion on the usual project forums
(i.e. mailing lists).
54. Extensions Roadmap
Done Current Short-term (<6m) Mid-Term (>6m)
L1 ROADM
L2 BoD Domain client
• AutoBAHN
BoD Domain Server
• Porting Harmony IDB
BoD Domain Server
• NSI interface.
L2 / L3 Router
L3 Network
Manager GUI
Security Manager
• SAML Idp
Cloud Manager
connectors
• OpenStack NetworkS
ervice drop-in
replacement
• OpenNebula 3.0
• Energy consumption
metrics.
• Infrastructure
Marketplace.
OpenFlow Controller
55. Extensions Roadmap by Project
2012 2013 2014 2015 2016
Mantychore UC1 UC2
NOVI SFA Adapter
GEYSERS MAC Bridge
CONTENT
OFERTIE
SODALES
GN3+
Wifi/TDM Resources
OpenFlow SLA Manager
Wifi/TDM Orchestrator
ARN Resource
GN3
56. Third Party Extensions
• Mantychore extensions are ASLv2, so they can be
used as foundation for additional extensions
– Additional extensions can have any license.
• New extensions can have any license.
• Possibility to be hosted on private repositories.
– And both be installed with a platform well-known
command
• feature:install http://net.biz/3rd.party.feature
• Can leverage both platform functionality and
default extensions.
