So how is IP addressing handled? I would expect it is IP4 and IP6 compliant. Are there white, grey and black lists supported from certain IP domains
or is this all in the box? No developer concerns or awareness about IP traffic?
backwards compatible with IP V4 & V6, in older links and switches the packet "header" still contains destination address, so is routed normally on non
SDN network fabric, and is routed by SDN networks (in data centre or between data centres) by looking at "encoded" information in the data portion of
the packet, so you can route by packet header or by packet encoding. a point to make is that switches can "look up" any space in the packet, not just
the "destination" space
Sounds like some programmer overheads / abstractions that need to be performed, any specifics?
yes the basic deployment of open flow (at this stage) requires nothing to work out of the box,
if you want to design specific operations like,
smart routing with fail-over,
packet strip and network isolation
individual user segregation on commodity server infrastructure,
you are required to "program" solutions in the form of APIs or purchase solutions that suit your requirements.
so there is a need for skilled programmers to customise the implementation
This is one of the hard edges at the divide. The ability to restrict permissions is a huge plus. The structured function also provides a clear
separation of powers. Ok, a hacker may be able to implement what can be done through the website, but they cannot do a table delete or basic reformat
if database permissions where exposed.
you can program the network indirectly through the central controller, so that any management functions can only be accepted from specific locations
and the commands themselves can be fabric specific (with some cleaver coding)
so that "route" and "commands" are at the same "level" in the packet inspection processes
My flash video player is busted at the moment, bandwidth issues prevent me for implementing a fix. I have heard of REST before, can you
The controller exposes open northbound APIs which are used by applications. OpenDaylight supports the OSGi framework and bidirectional REST for
the northbound API. The OSGi framework is used for applications that will run in the same address space as the controller while the REST (web based)
API is used for applications that do not run in the same address space (or even necessarily on the same machine) as the controller. The business logic
and algorithms reside in the applications. These applications use the controller to gather network intelligence, run algorithms to perform analytics,
and then use the controller to orchestrate the new rules, if any, throughout the network.
there is a small technical explanation on the open daylight page linked,
my definition is a full duplex connection manager that can be used for API connectivity and allows for separation of functions across different
The controller platform itself contains a collection of dynamically pluggable modules to perform needed network tasks. There are a series of base
network services for such tasks as understanding what devices are contained within the network and the capabilities of each, statistics gathering,
etc. In addition, platform oriented services and other extensions can also be inserted into the controller platform for enhanced SDN
hope this helps
Open SDN Architectures represent a fundamental change in networking architectures. An Open SDN introduces centralized software controllers that
implement a common data plane abstraction that unifies the entire network fabric southbound, and publishes open APIs for software applications
northbound. With this open architecture, a fabric of multi-vendor devices can be aggregated into a single policy domain that can be programmed and
automated using standard software (not CLI). Open SDN Architectures leverage an industry standard data plane abstraction protocol, like OpenFlow,
which provide direct access to the data plane hardware and forwarding flow tables – not just a CLI proxy mechanism. And, OpenFlow can operate across
a variety of physical and virtual switches, as well as vendor architectures. As a result, for the first time in history, an Open SDN controller can
program and automate a multi-vendor network using standard software protocols, like OpenFlow and RESTful APIs.
edit on 21/4/13 by XPLodER because: (no reason given)