[P4-discuss] Can we start a new flow from p4 switch?

Debobroto Das Robin drobin at kent.edu
Fri Oct 27 18:59:32 EDT 2017


Andy and Antonin,
* Things are now pretty much clear to me. *Thanks for your detailed answer.

On Fri, Oct 27, 2017 at 4:30 PM, Antonin Bas <antonin at barefootnetworks.com>
wrote:

> Adding p4-dev mailing list.
>
> Hi Robin,
>
> You seem to be describing OpenFlow packet-in / packet-out feature - or
> more precisely here packet-in since you are referring to packets sent by
> the switch to the controller.
> The way this is usually achieved is by sending appropriate packets to a
> special port, called the CPU port, potentially encapsulated in a custom
> header. Unlike OpenFlow, P4 doesn't mandate anything in this regard, but
> you usually need this custom header to carry relevant metadata information,
> such as the incoming port number of the packet.
> In the case of bmv2, this CPU port number can be anything you want, but
> actual hardware targets often mandate a special value.
>
> The exact meaning of the CPU port can depend on the P4 target. In bmv2,
> all packets are sent to an interface of your choice, and you can read /
> write from it. See this P4_14 example: https://github.com/
> p4lang/tutorials/tree/master/examples/copy_to_cpu
>
> In P4 Runtime however, we define higher-level APIs for packet-in /
> packet-out, which are very close to OpenFlow (
> https://github.com/p4lang/PI/blob/master/proto/p4/p4runtime.proto#L343).
> This enables the applications to use packet-in / packet-out in a
> target-independent way. The closest thing we have to an example is this
> unit-test: https://github.com/p4lang/behavioral-model/blob/
> master/targets/simple_switch_grpc/tests/test_packet_io.cpp#L41, but we
> hope to add more concrete examples very soon.
>
> On Fri, Oct 27, 2017 at 1:11 PM, Andy Fingerhut <andy.fingerhut at gmail.com>
> wrote:
>
>> Regarding your point 1)
>>
>> The digest mechanism does not generate a packet that goes out a 'normal'
>> port.  It generates a message in some implementation-specific form that
>> goes to the control plane software.
>>
>> Features like counters, meters, registers, digest, recirculate, resubmit,
>> clone, action profiles and selectors, were all part of the P4_14 base
>> language, and thus you find them in the P4_14 language specification
>> documents and the open source implementations, including the 1.0.3 you
>> mention, which is most likely v1.0.3 of the P4_14 language spec.
>>
>> Those features were intentionally separated into 'extern's in P4_16, so
>> are not part of the base language specification.  There is a PSA (Portable
>> Switch Architecture) document being worked on now, the latest draft is here
>> [1], which defines those things for switches.  The digest mechanism in PSA
>> is something that still isn't quite nailed down yet, and I don't know the
>> current state of the open source tools on P4_16 and the digest mechanism.
>>
>> Most things in P4 assume a model of "specify what the P4-programmable
>> device does when it receives a packet".  There isn't anything in it that
>> says "spontaneously wake up and start generating traffic".  Now if you took
>> a P4-programmable device and added a mechanism, not specified in P4, that
>> caused packets with particular contents to be sent to the P4-programmable
>> device, e.g. based upon timer events firing, or from control plane
>> software, then that combined system could be made to act as if the
>> P4-programmable device was initiating flows to the rest of the world, but
>> the P4-programmable part would still only be specifying how it reacts to
>> packets when it receives them.  Hopefully I explained that in an
>> understandable way.
>>
>> I am not familiar enough with how an openflow switch can initiate
>> communication to other devices, so could be missing something here.
>>
>> Andy
>>
>> [1] https://p4lang.github.io/p4-spec/   (look for the links to the PSA
>> document -- remember, still in draft form right now)
>>
>> On Wed, Oct 25, 2017 at 11:43 AM, Debobroto Das Robin <drobin at kent.edu>
>> wrote:
>>
>>> Andy, Thanks a lot for the reply.
>>>
>>> 1) The digest mechanism is obviously a new direction to me. I was
>>> reading the P4_16 specs and there was no "digest" keyword. Then i moved to
>>> version 1.0.3 and found the digest mechanism. Is the digest mechanism
>>> available in P4 16? In case of digest, generate_digest  will not initiate a
>>> new flow. It basically generates a reply after processing a packet. (if my
>>> understanding are correct)
>>>
>>> 2) I know about clone based mechanism.
>>>
>>> Let me explain my question a little bit more detail. Think about an
>>> openflow like protocol. Here both the controller and switch can initiate
>>> communication toward each other. Now if we want to achieve this kind of
>>> switch initiated communication (i.e. new flow), what would be the best
>>> technique in P4  ?
>>>
>>> Robin
>>>
>>> On Wed, Oct 25, 2017 at 2:27 PM, Andy Fingerhut <
>>> andy.fingerhut at gmail.com> wrote:
>>>
>>>> The digest mechanism is intended to send a 'record' containing a
>>>> P4-program-specified collection of field values to the control plane, as
>>>> the result of processing a received packet.  The prototypical example is if
>>>> the P4 program was implementing Ethernet learning bridge functionality, if
>>>> the source MAC address of the received packet was not currently in the MAC
>>>> address table, then the P4 program would send a digest containing the
>>>> packet's source MAC address and ingress port it arrived on (and perhaps
>>>> other field values, too).
>>>>
>>>> In addition to processing the received packet 'normally' (whatever that
>>>> means for your application), the clone mechanism can be used to create
>>>> another copy of the received packet, and then your P4 program can process
>>>> it differently before sending it to a different destination than the
>>>> 'normal' copy.  That clone could be sent to the control plane, to a
>>>> different port, be tunnel-encapsulated, etc.
>>>>
>>>> The P4 language is probably not the best fit for trying to implement
>>>> the behavior of a TCP endpoint, with all of the data buffering and packet
>>>> retransmission behavior that requires.  Not sure if you were even thinking
>>>> along those lines, but wanted to mention it.
>>>>
>>>> Andy
>>>>
>>>> On Wed, Oct 25, 2017 at 11:12 AM, Debobroto Das Robin <drobin at kent.edu>
>>>> wrote:
>>>>
>>>>> Hello All,
>>>>>
>>>>> Is there any option to start a new flow from p4 switch? For example
>>>>> based on certain event at switch we want to send a notification to control
>>>>> plane or some other destination. Is it possible?
>>>>>
>>>>> _______________________________________________
>>>>> P4-discuss mailing list
>>>>> P4-discuss at lists.p4.org
>>>>> http://lists.p4.org/mailman/listinfo/p4-discuss_lists.p4.org
>>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> P4-discuss mailing list
>> P4-discuss at lists.p4.org
>> http://lists.p4.org/mailman/listinfo/p4-discuss_lists.p4.org
>>
>
>
>
> --
> Antonin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-discuss_lists.p4.org/attachments/20171027/9a576a03/attachment-0002.html>


More information about the P4-discuss mailing list