an open and collaborative ecosystem for iot

IMTC Connect 2015

An Open and Collaborative Ecosystem for IoTCharles Eckel, Open Source Developer Evangelist, Cisco [email protected]

mailto:[email protected]

2© 2015 Cisco and/or its affiliates. All rights reserved.

Agenda

• Promise and Challenges• Open Source and Open Standards

• OpenStack• OpenDaylight

• Conclusions


Promise and Challenges


So Many Devices, Apps, Protocols, Verticals...So Little Time


Solution Lock-inBody Cameras Quick Facts

• In the US, funding for 50,000 cameras, list price ~ $400• Video stored for 5 years• Largest deployment to date – Oakland, 600 cameras


Many Disjoint Efforts

• Many organizations (re)defining terms for basic concepts • E.g. temperature and on/off defined within own namespace• These become inseparable parts of the data model

• Different protocols available to address different use case requirements

• Different application semantics and data models• Data models tied to dedicated protocols result in all-or-

nothing solutions


Standards • Internet build on top of IPv4

• IPv6 meets scalability required for IoT

• But for IoT devices:• Bandwidth is 250 kbit/s, not 250 Mbit/s• Program memory size is 256 kB, not 256 MB• Requires scale down 1000x for protocol complexity and traffic

• RFC 7252 - The Constrained Application Protocol (CoAP)

• IPv6 over Networks of Resource-constrained Nodes (6lo)• Good work, but entire industry does not wait for resulting RFCs

Image source: http://www.edensunshine.com/

https://tools.ietf.org/html/rfc7252

https://datatracker.ietf.org/wg/6lo/charter/


• Complex set of pieces:• New projects often start quickly, then slowly fade away• Fragments, many OSS projects that solve 20% of problem but

cannot easily be used together• Hidden gaps, missing functionality, due to lack of overall

architecture

• But which manages to:• Leverage a vast community• Innovating at a very fast pace• Sometimes resulting in de facto standard

Open Source Software (OSS)


• Industry moving too fast to do everything yourself• Projects have a sweet spot in the ecosystem:

• Marrying an appropriate niche with the right expertise • Should OpenStack do EVERYTHING in Cloud• Should OpenDaylight do EVERYTHING in Networking• NFV has cloud and network implications• IoT has ties into cloud, networking, NFV

• Classic “feature” vs. “stability/scale” demand tradeoffs results in deceleration (i.e. in core)

• “Outstrip the Means”

Core vs. Context


OpenStack


Overview• Cloud computing platform for

public/private clouds

• Abstracts data centers into pools of resources

• Provides management layer for efficient, automated allocation of resources

• Empowers operators, admins, users via self service portals

• Provides APIs to develop cloud-aware applications


The OpenStack Community• Founded in Sept 2012

• Rackspace and NASA

• Apache 2.0 license

• Designed and developed in an open collaborative fashion

• 24,000 developers

• 500 companies

• 20 million lines of code

• Releases every six months

• Current stable release - “Kilo”• Version 2015.1.1• Released June 30, 2015• 1500 developers contributed• 150 companies involved• 20,000 patch sets


http://stackalytics.com/?release=kilo&metric=marks


Extensible Software ArchitectureApplications / Services

Physical and Virtualized Infrastructure

OpenStack Service APIs, SDK, CLI

Infrastructure Plugins

Compute

Service

(Nova)

Storage

Services

(Cinder and

Swift)

Network

Service

(Neutron)

Many more

Services

Dashboard

(Horizon)

Identity

(Keystone)


OpenDaylight


- Lithium

Service Abstraction Layer/Corea.k.a. MD-SAL

Base Network Functions

OpenFlow Enabled Devices

DLUXVTN

Coordinator

OpenStack Neutron

SDNI Wrapper

Network Applications Orchestrations &

Services

Open vSwitches Additional Virtual & Physical Devices

Data Plane Elements (Virtual Switches, Physical Device

Interfaces)

Controller Platform Services/Applications

OpenFlow Stats Manager

OVSDB NETCONF PCMM/COPSSNBILISP BGP PCEP SNMPSXP

Southbound Interfaces &

Protocol Plugins

OpenFlow

OpenFlow Switch Manager

USCCAPWAP OPFLEX CoAPHTTP

OpenFlow Forwarding Rules Mgr

L2 SwitchHost Tracker

Topology Processing

AAA AuthN Filter

OpenDaylight APIs REST/RESTCONF/NETCONF

Data Store (Config & Operational) Messaging (Notifications / RPCs)

LACP

Network ServicesService Function Chaining

ReservationVirtual Private Network

Virtual Tenant Network Mgr.Unified Secure Channel Mgr

OVSDB Neutron

Device Discovery, Identification & Driver Management

LISP ServiceDOCSIS Abstraction

SNMP4SDN

Network Abstractions (Policy/Intent)

ALTO Protocol ManagerNetwork Intent CompositionGroup Based Policy Service

Platform ServicesAuthentication, Authorization &

Accounting

Neutron NorthboundPersistence

SDN Integration AggregatorTime Series Data RepositoryLink Aggregation Ctl Protocol


The OpenDaylight Community• Founded in February 2013• Run by the Linux Foundation• Eclipse Public License• 15 founding companies donated

software and development resources

• 600 contributors• 2,000 code commits• 2.5M lines of code• Mostly Java

• First release “Hydrogen” February 2014

• Releases roughly eight months apart

• Current stable release - “Lithium”• Released June 29, 2015• “Lithium SR-1” update August 18

• Beryllium release targeted for Q12016


• Project started in December 2014• Enable authorized apps to retrieve IoT data uploaded by any device• Provide open source IoT Middleware based on OpenDaylight• Compliant with oneM2M• Basic set of resources supported• Delivery: June 2015, Lithium release• https://wiki.opendaylight.org/view/IoTDM:Main

IoT Data Broker (IoTDM)

https://wiki.opendaylight.org/view/IoTDM:Main


oneM2M• Common embedded IoT middleware

• Interoperability amongst myriad of devices

• Founded by 7 SDOs, 230 partners and members • USA: TIA, ATSI• Japan: ARIB, TTC• China: CCSA• Europe: ETSI• Korea: TTA

• Common services applicable to any sector• E.g. energy, home, transportation, etc.)


Scope

Applications

Common Services

Underlying Network Services

Other common services

Reference point

Reference point

Reference point

oneM2M scope

Common Services Entity (CSE)• Data Exchange• Remote Device Management• Security & Access control• Connectivity Handling

Underlying network provides value added servicese.g. QoS, device management, location services


Architecture

Data Collection(IoTDM)

Service Abstraction LayerPlugin Manager, Capability Abstractions, Inventory…

ODL Service Modules

Other ODL

Services

Data Store

ODL APIs (ReST)

Legacy DB

(Oracle, MSN, …)

CoAPHTTP

JSON OAuthCoAP

TLS/DTLSPKI

Em

bedded IoT S

tack

Devices and Things

IoT App

Vertical IoT Apps (Integration if

needed)

REST HTTPSQL

IoT GWs and Mgmt Systems

Other IoT Protocols

IoTDM Open SourceComponents

Network Devices & Services

Plugins to Network Elements

Device Adapter

MQTT


The Building Blocks

IoT App

Device Plugin

Protocol Plugin

Core Functions

CoAP/HTTP/

MQTT…

CoAP/HTTP/

MQTT…

Programing API (Python, Java, C, etc…)

RPC Call/Resp

Protocol Binding

Client Middleware: IoTDM

Data Stor

e

JSON Payload{"cr":"jb", "mni":"1", "mbs":"3", "or":”foo.bar.org"}

Protocol Binding


• Time series data repository and services as MD-SAL services modules• Collect, store, query and maintain time series data in ODL environment• Support 3rd party data store implementations via plugins• Leverage MD-SAL’s clustering capability for performance/scalability• Northbound APIs for apps to retrieve time series data

• E.g. Security risk detection, performance analysis, operational configuration optimization, traffic engineering, network analytics, etc.

• https://wiki.opendaylight.org/view/TSDR:Main

Time Series Data Repository(TSDR)

https://wiki.opendaylight.org/view/TSDR:Main

https://wiki.opendaylight.org/view/TSDR:Main


https://wiki.opendaylight.org/images/7/7f/TSDR1.jpg





Putting the Pieces Together


Compute NetworkStorage

Open DaylightOpenStack

Neut

ron

API

Neut

ron

ML2

pl

ugin

GBP

VNFs

NFV Orchestration and Management

OPNFV: ContinuousIntegration and Deployment

OPNFV: ContinuousTesting

OPNFV:Requirements

Integration Testing Requirements

General Architecture

Value add for NFV vendor

Value of OPNFV

OpenInfrastructure

Open Source Platform- e.g. OPNFV


• Speed and spirit of open source• Rigor and stability and of open standards• Each has positive impact on the other• Running code validates evolving

standards• Standards unify and guide open source

implementations

Combine Open Source and Standards

CertificationTest-Suite

Standards

Open Source


https://www.ietf.org/hackathon/


https://wiki.mef.net/display/LH/MEF+LSO+Hackathon


• Be active, ask questions, learn about efforts around you• Don’t reinvent the wheel

• Reinvent = time wasted + community building opportunity lost

• Contribute upstream• Don’t fork up IoT

Call to Action


Thank you

an open and collaborative ecosystem for iot

Technology