Is the OpenFlow implementation platform dependent? - openflow

I want to know is the OpenFlow implementation dependent on the platform or the CPU architecture? In other words can we run the same OpenFlow package on the windows and Linux? I saw that we can download the OpenFlow package and install it on the Linux but I want to know can I install that package on the windows platform too?

Your question: "Can we run OpenFlow on both Windows and Linux?"
Is the same as asking: "Can we run HTTP on both Windows and Linux?"
And the simple asnwer is: "Yes you can"
OpenFlow is the specification of an device-to-controller communication protocol used in the SDN paradigm. OpenFlow is one example of a "South-bound" protocol between an SDN Controller, and an OpenFlow enabled network device.
So, when you ask if you can install the OpenFlow package on a windows platform, it depends. It depends on the implementation of the SDN controller. The SDN controller will probably have a south bound module which implements OpenFlow so that you can communicate with OpenFlow enabled devices. This south bound module with OpenFlow support is what you are asking for.
So, if the "OpenFlow package" you found were for Linux, you probably couldn't install that on windows.
That being said. There are several SDN controllers with OpenFlow support that can run on Windows. Including the massive, and highly functional, OpenDaylight controller. OpenDaylight is implemented in Java, and can therefore run on both Linux, Windows, OS X etc..

Once you let another server(here we call it controller) to determine the packet forwarding behavior of your local machine (here it is your PC), it turns into so-called SDN mechanism. So it's not relevant what kind of CPU or hardware you are choosing, basically, you can consider SDN as a software solution.
However, it does not mean it has no any dependence on the platform, especially when we talk about windows. The problem is that when you delegate the forwarding behavior to the controller, do you have the privilege to do this? Basically it means it needs to program on the kernel level which you cannot obtain in windows platform.
So please forget to do this on Windows unless the Richmond company implements this by themselves.

Related

Is there a .net implementation for openthread

I have been working to connect to a device to a dongle using OpenThread.
I am looking for a .Net Implementation of Openthread.
There is a Zigbee implementaion for .net called ZigbeeNet.
Looking at ZigbeeNet it appears to be a library to interface with Zigbee device over a COM port, so I'm assuming you're also targeting .Net on Windows. The equivalent would be a Network Co-Processor host implementation in OpenThread terminology and unfortunately there isn't a direct .Net implementation. Microsoft implemented a Windows 10 NCP driver which would have been a good starting point, but unfortunately they've dropped support. It still may work but YMMV.
It is possible to run the UNIX host wpantund in a VirtualBox VM and run your .Net application in the guest.

If I deploy my Network Function on Oracle Virtualbox mean I am following NFV standards

I am working on a project related to Network Function Virtualization. To virtualize my Network Function, I am planning to deploy the Network Function on an Oracle Virtualbox. If I deploy my Network Function on the Oracle Virtualbox, does that mean I am complying with the standards of NFV architecture according to ETSI.
If yes, how Oracle Virtualbox is implementing the NFV architecture. Any source documentation would be useful.
If no, how much is Oracle Virtualbox implementation different from ETSI standards and what opensource architecture is better for implementing my project. Any source documentation on how much Oracle Virtualbox deviating from ETSI standard is useful.
Yes. The ETSI NFV Standards do not mandate a specific hypervisor.
As you may see in the Architectural Framework specification the MANO (Management and Orchestration) component interacts with the virtualization layer by means of a Virtual Infrastructure Manager (VIM), which decouples from the specific hypervisors.
The requirements for the MANO - VIM interface are specified here.
If you are starting from scratch, you may want to check out Openstack as a VIM and OSM as the MANO. Others open source implementation for both components are also available.
Have a look at the OpenStack VirtualBox drivers to get more information.
Installation information for OSM Release 5 are available here.

What is the difference between Weave and Openthread?

I would like to work on Weave but I noticed that Nest has open sourced Openthread instead. I would like to get my hands dirty with Openthread but if someone can answer these questions for me I would really appreciate that.
Is one preferred over the other for certain applications. If so, what are they?
Will devices running Openthread be directly compatible with ones running Weave?
Will these devices be able to communicate with Android devices as is or is future support in Android being planned?
What soc's or emulators can I test Openthread on?
Thanks in advance!
First Question
Succinctly, in terms of the OSI model:
Thread is a network technology that defines layer 2 (link-layer) and layer 3 (network-layer). Thread gives your embedded device IPv6 interface with some nifty capabilities, such as fault-tolerance, mesh networking, and low power consumption.
Weave is (for the most part) a layer 6 protocol, like CoAP or HTTP. It is a protocol that applications running on embedded devices can use to communicate with each other. It requires an IPv6 network interface, which could be provided by ethernet, Wi-Fi, or Thread.
It is important to differentiate OpenThread and Thread. OpenThread is an open-source implementation of the Thread standard.
Both technologies are designed to be used (albeit in different ways) in residential settings on the following loose categories of embedded devices:
Embedded devices that need to be able to reliably communicate with each other under adverse conditions, like a power outage or a fire.
Battery-operated embedded devices that need to be able to last for many years without changing or recharging the battery.
Sensor networks for monitoring things like temperature, motion, humidity, etc.
Second Question
The implication of your question is that the two technologies are mutually exclusive, or that they somehow solve similar problems. As the cute naming implies, Thread and Weave are complementary technologies. Weave needs a network interface to communicate with other devices, and Thread provides one.
Thread is like Wi-Fi in this way. Wi-Fi doesn't define the protocols that run over it. For example, just because a smart thermostat and a smart light switch have Wi-Fi radios doesn't mean that they can communicate with each other. It will be a similar situation with devices that have Thread-compatible radios.
Third Question
While there is no particular reason why you would not be able to use Thread or Weave (or both!) to communicate with devices running Android (or any other operating system), the the devil is in the details: there is no one-size-fits-all solution.
That being said, one way is to use IPv6 routing: Thread is based on IPv6, so if you have a Thread border router, you can allow devices on a Wi-Fi network to directly communicate (via IPv6) with devices on the Thread network.
Fourth Question
In addition to the POSIX simulator, the CC2538 is now an officially supported hardware platform. Support for Dialog's SmartBond™ SoC family of chips is currently provided directly by Dialog.
it might help to first better understand Thread and what it is trying to solve. Designed for the home, Thread is an IPv6 networking protocol built on open standards for low-power 802.15.4 mesh networks that can easily and securely connect hundreds of devices to each other and the cloud. This is different than Weave, which is an application protocol. Multiple application protocols can be developed on top of Thread, including Nest Weave. The Thread Group has a nice technical overview of Thread on their site.
Now to your specific questions:
You should use OpenThread if you're looking for an open source low-power, ipv6-based mesh networking protocol to build upon for your home connectivity application protocol
That really depends on what you mean. Any application protocol built on Thread should be compatible at the network layer with OpenThread, assuming they are targeting compatible versions of Thread.
One of the key design goals of Thread is being able to allow the Home Area Network to reliably communicate to the cloud through Border Routers. We demonstrated an Android app controlling a Thread end device from a Android. Here is a video.
You can find a CLI simulator in the /examples folder. At the time of this writing, OpenThread is still rather new - however we expect to see various SoCs officially supported from our silicon launch partners. Watch the repo for more updates.

How to reverse-engineer a USB device without monitoring traffic?

How is it possible to determine the commands to operate a usb device, if that device comes from another operating system and traffic monitoring software cannot be installed on that OS. The only method i can think of is sending random commands to the device, until the device responds, but this seems implausible for more complex commands, and potentially dangerous. For example, consider the DualShock 4 controller. Sony has not made an official driver for this device, so what method can i use to create a linux driver for it?
Get a hardware protocol analyzer. Then you won't need to install any software on the host or device under test. Here is one that I have used:
http://www.totalphase.com/products/beagle-usb12/

board with webserver, email, snmp

I am looking for board, module, kit for our new project.
requierments:
necessary:
IP interface IPv4/IPv6
DHCP, StaticIp, ICMP(Ping)
SNMP V2, V3
HTTP, Webserver
Email
good to have:
Telnet
SSH
SysLog
There are two ways:
complete controlled modul + master(some 8-bit with rs232, spi, ..)
I've found this http://www.connectone.com/products.asp?did=73&pid=92
But there is probably problem with SMTP, it isnt direct supported. Only UDP.
some board with linux
Thanks for your advices and recommendation.
with such heavy requirements, i would definitely go for an embedded computer running linux or a lighter unix based kernel. it will give you some flexibility over the software package, and you will easily find some support.
(there are plenty of embedded computers on the market, i can't chose one...)
I've found this XPORT PRO from LANTRONIX.
http://www.lantronix.com/device-networking/embedded-device-servers/xport-pro.html
There is Linux, so all 'net' stuffs should be supported.
8MB SDRAM/16MB Flash
small, cheap
Do you have some experience with that?
The second tip is http://www.rabbit.com/
Very powerfull modules with C libraries.