We've worked out a solution where, for each data set transfer, we know which of the many, many compute nodes are going to be involved. In order to direct traffic, we get a list of all the source IP addresses and pass those on to the controller, and when the controller sees the source and destination IPs it can set up a flow rule and map the flow onto a dynamic circuit between A and B.
When dealing with individuals, it's just going to be a question of looking at the aggregate traffic and how it's flowing and trying to direct flows. Down the line we intend to apply machine learning classifications and understanding to learn the patterns from the flow data so we can manage it. That's somewhat down the line but I think it's an interesting application to apply to this kind of problem.
How many controllers do you think you'll end up with?
NEWMAN: That's an interesting question because this is actually a collaboration of many organizations. We start with one controller. I think ultimately there will be a few at strategic points, a handful, but how the different controllers interact is not very well developed in the OpenDaylight framework.
How many switches will ultimately be controlled?
NEWMAN: There are 13 Tier 1 sites and 160 Tier 2 sites, but I think we'll probably end up somewhere in the middle, which is a few dozen switches involved with the largest flows.
Did you look at buying a controller versus building one?
NEWMAN: We looked at some controllers. We had previous development based on the Floodlight controller. Julian?
BUNN: The OpenDaylight controller is public domain software and supported by the major vendors and many research groups. It has become sort of the de facto SDN controller in the community. There have been others, such as the Floodlight controller, which we've used. Some of these were a little less open. That's why we picked OpenDaylight. We'd already worked with Floodlight so we knew how an SDN controller worked.
NEWMAN: The Brocade Vyatta Controller is based on OpenDaylight and Brocade is an active contributor to OpenDaylight project, but the funding agencies prefer that we choose open-source software because of the potential benefits of engaging a larger community of users and developers.
What version of OpenFlow have you settled on here?
BUNN: OpenFlow 1.0 because we found the particular switches we've been using support that very well. We don't need any of the features in 1.3. The sort of flows we're writing into the switch tables don't really need anything more advanced than 1.0 at the moment.
NEWMAN: The other aspect is, when you have test events there are typically different flavors of switches involved, so by requiring OpenFlow 1.0 it's easier to make them all work together. We foresee moving to Openflow 1.3 when the number of switches supporting it increases, and when there is a greater need to moderate the size of flows on the fly (a feature supported in 1.3).
Sign up for Computerworld eNewsletters.