Guiseppe, Adding the OpenFlow Plugin mailing list.
Probably - but I see you are adding it on the old design which is going to be switched out during the Boron release. You will need to look under the new design - or what used to be known as the Lithium design which is under openflowplugin-impl and openflowplugin-api. ~/git/opendaylight/openflowplugin$ \ls applications openflowplugin-controller-config artifacts *openflowplugin-impl* distribution openflowplugin-it drop-test parent drop-test-karaf pom.xml extension samples features src features-li test-common model test-provider openflowplugin test-scripts *openflowplugin-api* vagrant openflowplugin-common ~/git/opendaylight/openflowplugin$ On Mon, May 16, 2016 at 3:05 AM, Petralia, GiuseppeX < [email protected]> wrote: > Dear Abhijit, > > > > I am Giuseppe Petralia, I am working in the European project NetIDE, that > is also a project in OpenDaylight. We are currently working on a patch to > the Openflowplugin to implement the API calls and Notification to be able > to send to the switches serialized OpenFlow messages directly from the > northbound API of the openflowplugin and receive in the MD-SAL all the > openflow messages sent by the switches, using their original serialized > format. > > Alec presented our proposal to a PDT meeting of the Openflowplugin. > > > > To do that I am implementing an RPC call that accept a serialized Openflow > message, it deserializes it and sends it to the switch. > > To receive the notification I created a MessageTranslator, that takes in > Input a DataObject, serializes it and wraps the byte array into a > Notification to be published to the MD-SAL. > > > > Our service introduces a new notification named OfMessageReceived. > > The notification contains the byte representation of the OF messages > received from the switches. > > In the MDController class ( > https://github.com/opendaylight/openflowplugin/blob/master/openflowplugin/src/main/java/org/opendaylight/openflowplugin/openflow/md/core/MDController.java) > you can add message translators that translate the OF messages to the > respective notification. There are already a lot translators for many > message types. > > We need to add our Translator for all the message types. The > implementation suggests that you can have a list of translators for each > type, as then the message will be translated using all the translators > registered for a given type. The problem is that if I register > OfMessageReceivedTranslator for the FlowRemoved Message, after the > registration of the existing translator for the FlowRemovedMessage, with > the following lines in the init method: > > > > addMessageTranslator(FlowRemovedMessage.class, OF10, new > OfMessagerReceivedTranslator()); > > addMessageTranslator(FlowRemovedMessage.class, OF13, new > OfMessagerReceivedTranslator()); > > > > the test of the ConnectionConductorImplTest.testOnFlowRemovedMessage fail. > It seems as our translator is hiding the existing one and not just adding a > new one. > > I would like to ask you if it is possible to register the new translator, > if I am doing it in the right way, and if not how this notification can be > implemented, containing the serialized OpenFlow message, using an > alternative approach. > > > > Thank you very much for your help. > > > > Best, > > Giuseppe Petralia > > > > > > > > > > -------------------------------------------------------------- > Intel Research and Development Ireland Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by others > is strictly prohibited. If you are not the intended recipient, please > contact the sender and delete all copies. > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
