lighty.io

ONAP SDNC on lighty.io use case

In contemporary SDN world, ONAP (Open Network Automation Platform) is quite a trend. ONAP is a big project composed from number of sub-projects (or components if you like), which together form a platform for orchestration and automation of network functions. There are big companies involved in ONAP and its development Read more…

lighty.io

Openflow on lighty.io

OpenFlow enables network controllers to determine the path of network packets across a network of switches. The controllers are distinct from the switches. This separation of the control from the forwarding allows for more sophisticated traffic management than is feasible using access control lists (ACLs) and routing protocols. Also, OpenFlow Read more…

lighty.io

lighty.io NETCONF device on ARM

Components of lighty.io are versatile and reusable in different scenarios. Let’s take closer look at lighty-netconf-device java library. This lighty.io component represents fully programmable NETCONF communication stack, which can be integrated with hardware to achieve interoperability with lighty.io NETCONF – RESTCONF controllers. lighty-netconf-device library implements server for RFC6241 (https://tools.ietf.org/html/rfc6241) and Read more…

lighty.io

Lighty.io clients

Real-life deployments are always challenging. Usually the story goes like this. You have your network devices to manage, a controller that usually provides a normalized interface for your network. Great, and now what? Next logical step is to integrate SDN controller with overlaying management tools and systems. This is easy Read more…

lighty.io

Migration of ONAP SDNC to lighty.io

Migration of ODL based application into lighty.io can be really straightforward. But sometimes you have to do more steps in order to run your application in lighty.io. Especially if your application is using OSGI/Karaf specific code. For example when it’s using BundleContext to get registered OSGI services in runtime (what Read more…

lighty.io

lighty.io SDN MADE EASY

Having worked as an OpenDaylight developer for some time, I participated on many customer projects based on OpenDayght’s Boron, Carbon, Nitrogen and Oxygen releases. OpenDaylight as a software-defined networking platform has an interesting concept of “model-driven architecture”, where features of SDN controller are using MD-SAL to interact with each other. Read more…