Www.opennaas.org Overview.

www.opennaas.orghttp://www.opennaas.org/

Overview

Objective

• Create a project neutral software community that allows several stakeholders to contribute and benefit from a common NaaS software stack.– Enable research to happen on top of it.• And leverage past research

– Base functionality that can be trusted on a production environement.• Users increase life span

– Open Source, LGPLv3, Open community.

OpenNaaS

• 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.

NaaS Lightweight Abstraction

Capability

Resource

RPC

OpenN

aaS

OpenNaaS Stakeholders

• Network Operators with an interest on NaaS:– NREN.– Cloud Datacenter.– New services for ISP’s.

• ISV and integrators– Swiss Army Knife for

middleware-network integration.

• Developers and network researchers.

FUSE ServiceMix

OpenNaaS Platform

Default plugins

Third Party plugins

- Re

sear

ch +

- Stability +

OTS

dist

ributi

on

OpenNaaS Platform

• For NOC users– Coherent UX for NOC users.

• A single CLI.• Unified management of resources and its capabilities.

– Unified application/resource lifecycle.

• Unified security and ACL management (TODO).• Enterprise –level base technologies mean:

– Server monitoring– Clustering– Remote management– Easy upgrade management

– Extensibility and template customization.– Out-of-band reporting of errors.

OpenNaaS Platform

• For developers– 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.

Platform

CLI

Pers

iste

nce

Que

ue

Reso

urce

Man

ager

. . .

Security

Protocol Session Manager

Resource Lifecycle

Resource Layer

Rout

er R

esou

rce

Net

wor

k Re

sour

ce

BoD

Res

ourc

e

Opti

cal S

witc

h Re

sour

ce

. .

.

Remoting

Scrip

ting

GU

I

Ope

nNeb

ula O

penS

tack

N

S

NSA

(NSI

)

. . .

3P Extensions

3P Middleware

PLATFORM

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.

Bundle lifecycle

Component Architecture

Operating System

Java 6 VM

OSGi Container

OSGi

FUSE

NaaS

NaaS

Plug-in

FUSE

NaaS

NaaS

Plug-in

Plug-in

FUSE

NaaS

Plug-in

Plug-in

Plug-in

Bund

les

OSG

i Dist

rib.

Exported functionality

Deploy, Upgrade, Monitor, etc

Modern IDE, Remote debug, etc

Unix, Linux, MacOS, Windows, etc

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…

OpenNaaS Platform

• Embeddable– Component of a bigger middleware

• i.e. a cloud management infrastructure.

– L-GPL.• Defined, known roadmap.• Reusable concepts across plugins– Resource, Capability, Action, Lifecycle.– A command toolset is built around this concepts– Etc

• Provides an abstracted view of NaaS resources.– That the Resources layer will leverage.

OpenNaaS Platform Base Components

• Platform Manager– Allows to query some underling platform information.• Memory usage• OS• Java version• Etc…

– Was used as a remoting PoC in IaaS.– Right now is disabled.


• Protocol Session Manager– Implements the ProtocolSession abstraction

• Currently we have two implementations:– Netconf (IRTF).– Onesys (EMS Module).

– 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


• 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.


• 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


• 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 common lifecycle:– Initialized, loaded in memory.– Active, accepts calls.

CapabilityResource

RPC


• 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:– Which model.– Which Capabilities are allowed.– Which Capabilities are actually callable

will depend on that actual Resource instance.» The Resource can be interrogated. Capability

ResourceRPC


• 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.

CapabilityResource

RPC


• 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. Capability

ResourceRPC


• 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. Capability

ResourceRPC


• 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. Capability

ResourceRPC


• 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.

CapabilityResource

RPC

RESOURCES

NaaS Lightweight Abstraction

Capability

Resource

RPC

OpenN

aaS

Default plugins

• Under development:– L1 plugin

• Manage ROADMs

– L2 / L3 plugin• Manage Routers,

Switches.– Eth, switching, vlans,

mpls.– IP (4/6), Routing,

Firewall.

– Network Resource.• Heavy WIP.

• Mid term:– OpenStack

NetworkService API• Drop-in replacement for

default functionality• Leverage L1/L2/L3 plugin

functionality

– OpenNebula 3.0 integration.

– NSI Implementation.• Porting Harmony.

– OpenFlow controller.

29

Capabilities Map

Third Party Plugins

• Can be closed source.• Possibility to be hosted on private repositories.– And both be installed with a plaltform well-known

command• feature:install http://net.biz/3rd.party.feature

• Can leverage both platform functionality and default plugins.

NETWORK INTELIGENCE

See Mantychore FP7 use cases

ROADMAP

Roadmap

• TNC 2012 Demo• Remoting• Security• Queue Refactor + MetaQueue• RMC integration (GUI)• Fully capability coverage for Router Resource.

BACKUP

35

Www.opennaas.org Overview.

Documents

Transcript of Www.opennaas.org Overview.