Bugzilla – Bug 1456
update openflow distribution
Last modified: 2013-01-18 14:52:09 EST
1) move openflow out of Josh Pelkey's private repo to a separate repo on code.nsnam.org
2) clean out some unwanted files in that repository (any build artifacts)
3) test whether we can migrate up to version 1.0.0 available here:
If this is an easy port (to 1.0.0) we should do it, otherwise, we can stay back at the 0.8.9 version.
Created attachment 1413 [details]
patch to fix ns-3 static build with openflow
In my opinion, we should also evaluate the possibility to build ns-3 with stock openflow instead of a customized one, as we do with click.
Created attachment 1477 [details]
Patch to remove extra files from Openflow 0.8.9 MPLS
It turned out that migrating up to version 1.0.0 was not easy.
So, openflow will remain the same version but with the unwanted files in that repository and any build artifacts cleaned out.
That version is
Openflow 0.8.9 MPLS
We need to decide on a name for the nsnam openflow repository: openflow-ns3 or just openflow?
Note that the attached patch should be applied to a copy of openflow-mpls 0.8.9, i.e. not to ns-3.
Mitch, can you briefly explain what is the problem and roughly enumerate what exactly is needed to fix it?
Here is an email message from Josh Pelkey about this issue.
I did take a look at this a month or so ago, and I thought upgrading would be non-trivial, since the OpenFlow structure has changed a bit. I'll defer to Blake though.
On Tue, Oct 16, 2012 at 2:31 AM, Tom Henderson <firstname.lastname@example.org> wrote:
On 10/02/2012 03:34 PM, Blake Hurd wrote:
IIRC, it was merely to be more feature complete. MPLS-support seemed
like it would make it more useful. The project was designed with the
theory that with a few adjustments you could make it work with both the
non-MPLS and the MPLS variants (each have their own OFSID, as referred
to in the wiki). I think you should be able to cut out the MPLS
functionality if you want to.
Blake and Josh,
We're at the point of deciding whether to upgrade the openflow to 1.0.0. However, there are some changes in 1.0.0 and it isn't clear how much this may break things for the ns-3 integration. I'd like to check with you about your opinion on this.
openflow_089_mpls (and openflow without the mpls) has this directory:
[tomh@ns-test openflow_089_mpls]$ ls switch
automake.mk datapath.c er_act.h switch.8.in switch-port.h
chain.c datapath.h nx_act.c switch.c table.h
chain.h dp_act.c nx_act.h switch-flow.c table-hash.c
crc32.c dp_act.h pt_act.c switch-flow.h table-linear.c
crc32.h er_act.c pt_act.h switch-port.c TODO
This seems to provide the user-space implementation of the switch:
The switch is a userspace implementation of an OpenFlow switch. It
implements all three parts of the OpenFlow switch specification: a
``flow table'' in which each flow entry is associated with an action
telling the switch how to process the flow; a ``secure channel'' con‐
necting the switch to a remote process (a controller), allowing com‐
mands and packets to be sent between the controller and the switch; and
an OpenFlow protocol implementation.
In your build of openflow for ns-3, you built the lib/ and switch/ directories, so I am guessing that you used the code in switch/
In openflow_100_mpls, the switch/ directory is gone. The other user-space directories (controller, datapath, secchan, udatapath) are still there. I presume that the functionality of 'switch' was subsumed by something like ofdatapath.
Our question is whether the ns-3 model relies on this 'switch' in 0.8.9 release; i.e., whether it will be a non-trivial port or refactoring to get ns-3 openflow to work without the switch directory.
Could you please let us know whether you think this is going to be non-trivial work to move to 1.0.0? If there is work involved, I think we will just stay with 0.8.9 version for now since no one seems available to port and test the new code.
I would like to move:
and close this bug, keeping the base version of openflow-0.8.9-mpls.
The new repo is cleaner than the jpelkey3/openflow, in that:
1) the first changeset is a consolidation of previous checkins, reduced to a minimal patch. This changeset by itself could be extracted and used as the basis for porting to other openflow distributions.
2) it fixes the static build issue
3) the removal of build cruft is more comprehensive
The documentation would be updated to repoint users to this new maintained directory, which would be under user 'code'
This change should not create any backward compatibility issues for users of this openflow-ns3 library.
New openflow repository established on Jan 18, 2013 at http://code.nsnam.org/openflow
bug closed. Future patches to upgrade to a newer OFSID can be submitted against a new bug or code review issue.