[ovs-discuss] How to use auxiliary connnection
Ali Volkan Atli
Volkan.Atli at argela.com.tr
Sat Apr 22 05:04:03 UTC 2017
Hi Ben
Do you think it makes sense if I add a key to controller action to tell the switch what aux or main connections to use,
controller(key=value...)
Sends the packet and its metadata to the OpenFlow con‐
troller as a ``packet in'' message. The supported key-
value pairs are:
max_len=nbytes
reason=reason
id=controller-id
userdata=hh...
pause
*** new key: auxiliary_id ***
- Volkan
________________________________________
From: Ben Pfaff [blp at ovn.org]
Sent: Monday, April 17, 2017 6:03 PM
To: Ali Volkan Atli
Cc: discuss at openvswitch.org
Subject: Re: [ovs-discuss] How to use auxiliary connnection
How would the controller tell the switch what to use?
On Mon, Apr 17, 2017 at 07:03:44AM +0000, Ali Volkan Atli wrote:
> From SDN point of view, the of-switch should be dump but when
> I evaluate the spec and also your answer, the aux connection is
> breaking the issue.
>
> A controller has no way of telling of-switch what connection will be used,
> the of-switch can decide what it wants. This does not make sense to me.
>
> - Volkan
> ________________________________________
> From: Ben Pfaff [blp at ovn.org]
> Sent: Sunday, April 16, 2017 7:43 PM
> To: Ali Volkan Atli
> Cc: discuss at openvswitch.org
> Subject: Re: [ovs-discuss] How to use auxiliary connnection
>
> On Sun, Apr 16, 2017 at 11:30:33AM +0000, Ali Volkan Atli wrote:
> > I am trying to understand auxiliary connection according to OpenFlow 1.5 specifications but I have some questions as follows
> >
> > 1) Let's suppose I have one main and one auxiliary connection. How
> > does the controller decide (or force) which connection to use for
> > sending packet-in messages?
>
> The OpenFlow specification says:
>
> The controller is free to use the various switch connections for
> sending OpenFlow messages at its entire discretion, however to
> maximise performance on most switches the following guidelines are
> suggested:
>
> • All OpenFlow controller requests which are not Packet-out
> (flow-mod, statistic request...) should be sent over the main
> connection.
>
> • Connection maintenance messages (hello, echo request, features
> request) should be sent on the main connection and on each auxiliary
> connection as needed.
>
> • All Packet-Out messages containing a packet from a Packet-In
> message should be sent on the connection where the Packet-In came
> from.
>
> • All other Packet-Out messages should be spread across the various
> auxiliary connections using a mechanism keeping the packets of a
> same flow mapped to the same connection.
>
> • If the desired auxiliary connection is not available, the
> controller should use the main connection.
>
> > 2) If the switch will decide, how will it decide? In one case, if
> > there is an auxiliary connection, then -by default- all packet-ins are
> > sent over "only" the aux channel? Is this correct behavior?
>
> The OpenFlow specification says:
>
> The switch is free to use the various controller connections for
> sending OpenFlow messages as it wishes, however the following
> guidelines are suggested :
>
> • All OpenFlow messages which are not Packet-in should be sent over
> the main connection.
>
> • All Packet-In messages spread across the various auxiliary
> connection using a mechanism keeping the packets of a same flow
> mapped to the same connection.
>
> > 3) If there are multiple auxiliary connections, should the switch
> > spread across the various auxiliary connection (for example for load
> > balancing)
>
> Same question applies.
More information about the discuss
mailing list