Hi
According to OpenFlow protocol spec (1.3), only two ways to remove flows.
One is using timeout, another is send flow delete message to the switch
from controller.
2017-05-11 19:37 GMT-07:00 varun hrithik <varunlikitha1...@gmail.com>:
> no this one does not work for different scenarios, as it will delete all
> flows of other moving stations.
>
> Now, we implemented the HARD_TIMEOUT in test bed, we experienced 45 packet
> loss during handoff, whereas in mininet we ended up with just 9 packet
> loss. So, thnking of any other method to make controller to delete flows of
> previous datapath automatically during handoff.
>
> On Thu, May 11, 2017 at 9:32 PM, Yi Tseng <a86487...@gmail.com> wrote:
>
>> Hi
>>
>> Is there any error log when you using OFPFC_DELETE ?
>>
>> 2017-05-11 17:21 GMT-07:00 varun hrithik <varunlikitha1...@gmail.com>:
>>
>>> i think OFPFC_delete method is wrong, do you know any other way to
>>> delete the flows of previously connected datapath.
>>>
>>> On Tue, May 2, 2017 at 12:20 PM Yi Tseng <a86487...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Basically, you need to create another thread to send flow modification
>>>> message.
>>>>
>>>> To create a simple thread, you can use *spawn *method in ryu.lib.hub
>>>>
>>>> --Yi
>>>>
>>>> 2017-05-02 5:49 GMT-07:00 varun hrithik <varunlikitha1...@gmail.com>:
>>>>
>>>>> As you directed me not to miss table-miss entry, i used it, now ITS
>>>>> WORKING PERFECTLY, handoff is performing at its best , with 3 packets loss
>>>>> in mininet, now the problem is, BUT FOR DEPLOYING THIS CODE ON WU MESH, i
>>>>> heard that HARD_TIMEOUT does not work on WU mesh test bed, so what i think
>>>>> is to use "OFPFC_DELETE or OFPFC_DELETE_STRICT " can we make
>>>>> controller to delete flows by itself, instead of using HARD_TIMEOUT, if
>>>>> that can be done, how to use OFPFC_DELETE? IS THERE A WAY FOR THAT?
>>>>>
>>>>> Thanks a lot
>>>>>
>>>>> On Tue, Apr 25, 2017 at 7:00 PM, Yi Tseng <a86487...@gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Because you removed table-miss flow entry, so the switch will not
>>>>>> send any packet-in message to the controller.
>>>>>>
>>>>>>
>>>>>> --Yi
>>>>>>
>>>>>> 2017-04-25 16:38 GMT-07:00 varun hrithik <varunlikitha1...@gmail.com>
>>>>>> :
>>>>>>
>>>>>>> Based on what you insisted me, i used idletimeout to delete flows,
>>>>>>> but my controller is not receiving my packetIn message automatically,
>>>>>>> when
>>>>>>> station moves to different AP, I am including my controller code, Let me
>>>>>>> know if i need add a loop to direct the packetIn message to controller
>>>>>>> or
>>>>>>> am i missing with some logic in my code?
>>>>>>>
>>>>>>> # Copyright (C) 2011 Nippon Telegraph and Telephone Corporation.
>>>>>>> #
>>>>>>> # Licensed under the Apache License, Version 2.0 (the "License");
>>>>>>> # you may not use this file except in compliance with the License.
>>>>>>> # You may obtain a copy of the License at
>>>>>>> #
>>>>>>> # http://www.apache.org/licenses/LICENSE-2.0
>>>>>>> #
>>>>>>> # Unless required by applicable law or agreed to in writing, software
>>>>>>> # distributed under the License is distributed on an "AS IS" BASIS,
>>>>>>> # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>>>>>>> # implied.
>>>>>>> # See the License for the specific language governing permissions and
>>>>>>> # limitations under the License.
>>>>>>>
>>>>>>> from ryu.base import app_manager
>>>>>>> from ryu.controller import ofp_event
>>>>>>> from ryu.controller.handler import CONFIG_DISPATCHER, MAIN_DISPATCHER
>>>>>>> from ryu.controller.handler import set_ev_cls
>>>>>>> from ryu.ofproto import ofproto_v1_3
>>>>>>> from ryu.lib.packet import packet
>>>>>>> from ryu.lib.packet import ethernet
>>>>>>>
>>>>>>>
>>>>>>> class SimpleSwitch13(app_manager.RyuApp):
>>>>>>> OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]
>>>>>>>
>>>>>>> def __init__(self, *args, **kwargs):
>>>>>>> super(SimpleSwitch13, self).__init__(*args, **kwargs)
>>>>>>> self.mac_to_port = {}
>>>>>>>
>>>>>>> @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
>>>>>>> def switch_features_handler(self, ev):
>>>>>>> datapath = ev.msg.datapath
>>>>>>> ofproto = datapath.ofproto
>>>>>>> parser = datapath.ofproto_parser
>>>>>>>
>>>>>>> # install table-miss flow entry
>>>>>>> #
>>>>>>> # We specify NO BUFFER to max_len of the output action due to
>>>>>>> # OVS bug. At this moment, if we specify a lesser number, e.g.,
>>>>>>> # 128, OVS will send Packet-In with invalid buffer_id and
>>>>>>> # truncated packet data. In that case, we cannot output packets
>>>>>>> # correctly. The bug has been fixed in OVS v2.1.0.
>>>>>>> match = parser.OFPMatch()
>>>>>>> actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
>>>>>>> ofproto.OFPCML_NO_BUFFER)]
>>>>>>> self.add_flow(datapath, 0, match, actions)
>>>>>>>
>>>>>>> def add_flow(self, datapath, priority, match, actions,
>>>>>>> buffer_id=None):
>>>>>>> ofproto = datapath.ofproto
>>>>>>> parser = datapath.ofproto_parser
>>>>>>>
>>>>>>> inst =
>>>>>>> [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS,
>>>>>>> actions)]
>>>>>>> if buffer_id:
>>>>>>> mod = parser.OFPFlowMod(datapath=datapath,
>>>>>>> buffer_id=buffer_id, idle_timeout=50,
>>>>>>> priority=priority, match=match,
>>>>>>> instructions=inst)
>>>>>>> else:
>>>>>>> mod = parser.OFPFlowMod(datapath=datapath, idle_timeout=50,
>>>>>>> priority=priority,
>>>>>>> match=match, instructions=inst)
>>>>>>> datapath.send_msg(mod)
>>>>>>>
>>>>>>> def del_flow(self, datapath, match):
>>>>>>> ofproto = datapath.ofproto
>>>>>>>
>>>>>>> mod = datapath.ofproto_parser.OFPFlowMod(datapath=datapath,
>>>>>>> match=match, cookie=0,
>>>>>>> command=ofproto.OFPFC_DELETE, idle_timeout=0,
>>>>>>> hard_timeout=0,
>>>>>>> priority=priority)
>>>>>>> datapath.send_msg(mod)
>>>>>>> """
>>>>>>> def add_flow1(self, datapath, priority, match, actions,
>>>>>>> buffer_id=buffer_id):
>>>>>>> ofproto = datapath.ofproto
>>>>>>> parser = datapath.ofproto_parser
>>>>>>>
>>>>>>> inst =
>>>>>>> [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS,
>>>>>>> actions)]
>>>>>>> if buffer_id:
>>>>>>> mod = parser.OFPFlowMod(datapath=datapath,
>>>>>>> buffer_id=buffer_id, idle_timeout=50,
>>>>>>> priority=2000, match=match,
>>>>>>> instructions=inst)
>>>>>>> else:
>>>>>>> mod = parser.OFPFlowMod(datapath=datapath, idle_timeout=50,
>>>>>>> priority=2000,
>>>>>>> match=match, instructions=inst)
>>>>>>> datapath.send_msg(mod)
>>>>>>> """
>>>>>>> @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
>>>>>>> def _packet_in_handler(self, ev):
>>>>>>> # If you hit this you might want to increase
>>>>>>> # the "miss_send_length" of your switch
>>>>>>> if ev.msg.msg_len < ev.msg.total_len:
>>>>>>> self.logger.debug("packet truncated: only %s of %s bytes",
>>>>>>> ev.msg.msg_len, ev.msg.total_len)
>>>>>>> msg = ev.msg
>>>>>>> datapath = msg.datapath
>>>>>>> ofproto = datapath.ofproto
>>>>>>> parser = datapath.ofproto_parser
>>>>>>> in_port = msg.match['in_port']
>>>>>>>
>>>>>>> pkt = packet.Packet(msg.data)
>>>>>>> eth = pkt.get_protocols(ethernet.ethernet)[0]
>>>>>>>
>>>>>>> dst = eth.dst
>>>>>>> src = eth.src
>>>>>>>
>>>>>>> dpid = datapath.id
>>>>>>> self.mac_to_port.setdefault(dpid, {})
>>>>>>>
>>>>>>> self.logger.info("packet in %s %s %s %s", dpid, src, dst,
>>>>>>> in_port)
>>>>>>>
>>>>>>> # learn a mac address to avoid FLOOD next time.
>>>>>>> self.mac_to_port[dpid][src] = in_port
>>>>>>>
>>>>>>> if dst in self.mac_to_port[dpid]:
>>>>>>> out_port = self.mac_to_port[dpid][dst]
>>>>>>> else:
>>>>>>> out_port = ofproto.OFPP_FLOOD
>>>>>>>
>>>>>>> actions = [parser.OFPActionOutput(out_port)]
>>>>>>>
>>>>>>> # install a flow to avoid packet_in next time
>>>>>>> if out_port != ofproto.OFPP_FLOOD:
>>>>>>> match = parser.OFPMatch(in_port=in_port, eth_dst=dst)
>>>>>>> # verify if we have a valid buffer_id, if yes avoid to send
>>>>>>> both
>>>>>>> # flow_mod & packet_out
>>>>>>> if msg.buffer_id != ofproto.OFP_NO_BUFFER:
>>>>>>> #self.del_flow(datapath, match)
>>>>>>> self.add_flow(datapath, 1, match, actions,
>>>>>>> msg.buffer_id)
>>>>>>> return
>>>>>>> else:
>>>>>>> self.del_flow(datapath, match)
>>>>>>> self.add_flow(datapath, 2, match, actions,
>>>>>>> msg.buffer_id)
>>>>>>> data = None
>>>>>>> if msg.buffer_id == ofproto.OFP_NO_BUFFER:
>>>>>>> data = msg.data
>>>>>>>
>>>>>>> out = parser.OFPPacketOut(datapath=datapath,
>>>>>>> buffer_id=msg.buffer_id,
>>>>>>> in_port=in_port, actions=actions,
>>>>>>> data=data)
>>>>>>> datapath.send_msg(out)
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 24, 2017 at 1:10 PM, Yi Tseng <a86487...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *Please don't drop mailing list*
>>>>>>>> If flows had been removed, the controller should received PacketIn
>>>>>>>> message again, the simple switch application should install new flow
>>>>>>>> into
>>>>>>>> the switch.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Yi
>>>>>>>>
>>>>>>>> 2017-04-24 11:03 GMT-07:00 varun hrithik <
>>>>>>>> varunlikitha1...@gmail.com>:
>>>>>>>>
>>>>>>>>> yeah, removing flows is fine, i want t know how those flows can be
>>>>>>>>> added to the new ap, such that when a station is in between two APs(
>>>>>>>>> i.e,
>>>>>>>>> if the station are connected to two APs at the same time) , new AP
>>>>>>>>> should
>>>>>>>>> be able to connect wid station, so that new flows are created.
>>>>>>>>>
>>>>>>>>> On Mon, Apr 24, 2017 at 12:47 PM, Yi Tseng <a86487...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I think the easiest way is to set idle timeout for every flow, if
>>>>>>>>>> any host move to another device(AP), the original flow will be
>>>>>>>>>> removed.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Yi
>>>>>>>>>>
>>>>>>>>>> 2017-04-24 9:00 GMT-07:00 varun hrithik <
>>>>>>>>>> varunlikitha1...@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> I have created a topolgy which has 5 stations moving around 5
>>>>>>>>>>> access points using mininet-wifi (tool) extension of mininet which
>>>>>>>>>>> allows
>>>>>>>>>>> GUI format of wireless network simualtion.
>>>>>>>>>>> Now im trying to handle mobility of those moving stations using
>>>>>>>>>>> ryu controller example code (simple_switch_13.py),
>>>>>>>>>>>
>>>>>>>>>>> NOW THE PROBLEM IS,
>>>>>>>>>>>
>>>>>>>>>>> When the stations are inbetween two accespoints which have
>>>>>>>>>>> access range overlapped, the packets are not getting transferred
>>>>>>>>>>> from one
>>>>>>>>>>> ap to another (mobility is not working), so i want to know how to
>>>>>>>>>>> add and
>>>>>>>>>>> delete flows in the ryu controller code(simple_switch_13.py), so
>>>>>>>>>>> that my
>>>>>>>>>>> mobility works.
>>>>>>>>>>>
>>>>>>>>>>> SORRY FOR THE BIG QUESTION !
>>>>>>>>>>>
>>>>>>>>>>> Thank you
>>>>>>>>>>> Varun Siripurapu
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>> ------------------
>>>>>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ryu-devel mailing list
>>>>>>>>>>> Ryu-devel@lists.sourceforge.net
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Yi Tseng (a.k.a Takeshi)
>>>>>>>>>> Taiwan National Chiao Tung University
>>>>>>>>>> Department of Computer Science
>>>>>>>>>> W2CNLab
>>>>>>>>>>
>>>>>>>>>> https://takeshi.tw
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Yi Tseng (a.k.a Takeshi)
>>>>>>>> Taiwan National Chiao Tung University
>>>>>>>> Department of Computer Science
>>>>>>>> W2CNLab
>>>>>>>>
>>>>>>>> https://takeshi.tw
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Yi Tseng (a.k.a Takeshi)
>>>>>> Taiwan National Chiao Tung University
>>>>>> Department of Computer Science
>>>>>> W2CNLab
>>>>>>
>>>>>> https://takeshi.tw
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Yi Tseng (a.k.a Takeshi)
>>>> Taiwan National Chiao Tung University
>>>> Department of Computer Science
>>>> W2CNLab
>>>>
>>>> https://takeshi.tw
>>>>
>>>
>>
>>
>> --
>> Yi Tseng (a.k.a Takeshi)
>> Taiwan National Chiao Tung University
>> Department of Computer Science
>> W2CNLab
>>
>> https://takeshi.tw
>>
>
>
--
Yi Tseng (a.k.a Takeshi)
Taiwan National Chiao Tung University
Department of Computer Science
W2CNLab
https://takeshi.tw
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
