[P4-design] 3rd working meeting minutes

Leo Alterman leo at barefootnetworks.com
Mon Aug 10 19:02:49 EDT 2015


Hi Salvatore,

Thanks for the comments, responses inline:

> - several IPv4 options have variable length, e.g., LSRR, timestamp and
others; so you need a variable length field into the option_A header type
and you need a component/blackbox/whatever that can take another header
field as parameter:

Both of the option headers in this example were intended to be fixed length
options. Indeed, variable-legnth options would need a star field. As
defined, the counter's increment method can already take a header field as
its argument.

> (why aren't option_A and option_B arrays too?)

They could be - it's the difference between allowing those options to be
repeated in the header or not. It's probably important to clarify in the
spec what happens when one extracts to an already-extracted instance (I
would lean towards an exception being triggered).

> - as regards the struct ipv4_t, I think of it as an ordered memory area,
so if you define it like the following:

While the struct's members are ordered, I would not assume that this order
reflects how data is actually deparsed to the wire - the spec currently
describes the wire ordering as being inferred from the parse graph.

That being said, you still bring up a good point: if the deparsing
mechanism of the language works by determining a fixed order of header
instances (either through the struct definition or through the parse
graph), it's difficult to preserve the order of header options like this.
We've been working through a few different approaches to deal with this,
and one possibility is to define a union-of-headers construct and allow
arrays of these unions. A union containing every possible header option is
defined, and then an array of these unions is parsed in the main option
processing loop. It's a more advanced case of TLV parsing that we didn't
want to address in our initial proposal, and is only an issue depending on
how the deparsing process is defined.

~Leo


On Mon, Aug 10, 2015 at 6:23 AM, Salvatore Signorello <
salvatore.signorello at uni.lu> wrote:

> Hi all,
>
>
> On 08/07/2015 02:39 AM, Changhoon Kim wrote:
>
> [C] Barefoot proposes a blackbox that lets the parser keep such state,
> and says this is enough to handle common headers like IPv4, Geneve, and TCP.
>
>
> follow few things I've noticed skimming the ipv4_options_parser.p4 code.
> They're probably all known to the Barefoot folks, if so, please just ignore
> them.
>
> Best regards
>
>
> The idea of the counter to parse recurrent similar fields sounds great,
> but as showed into the code sample doesn't parse the IPv4 options for the
> following reasons:
>
> - several IPv4 options have variable length, e.g., LSRR, timestamp and
> others; so you need a variable length field into the option_A header type
> and you need a component/blackbox/whatever that can take another header
> field as parameter:
>
> header_type ipv4_option_A {
>     fields {
>         // Boilerplate
>         bit<8> type;
>         bit<8> len; (you cannot use 'length' as field_name, because this
> is a reserved token id)
>
>         // Option A fields
>         bit<*> foo;
>     }
>     length : len; // this is the header length in bytes
>     max_length : 40;
> }
>
>
> parser parse_option_a {
>         extract(ipv4.option_A);
>         ipv4_byte_counter.increment(-ipv4.option_A.len);
>         return options_loop;
> }
>
>
> - as regards the struct ipv4_t, I think of it as an ordered memory area,
> so if you define it like the following:
>
> struct_type ipv4_t {
>     header ipv4_base_t base;
>     header ipv4_option_A option_A; (why aren't option_A and option_B
> arrays too?)
>     header ipv4_option_B option_B;
>     header ipv4_option_padding padding[4]; (why 4? at max you need 3 to
> fill a 4 bytes word when a 1B option is present)
> }
>
> it does mean that you can have option_A then option_B then eventually some
> padding. Indeed this is not true, as for example the "No operation" option
> (RFC 791) is meant to align the beginning of the next option to a 32bit
> boundary. So you might (I've not run any code to double-check it) have:
>
> option_A[0] + option_B[0] + option_A[1] + option_B[0] (this time is an
> 'end of options list', in RFC 791 too ) + padding[0]
>
>
>
>
> --
> Salvatore Signorello
> PhD student @ SecanLab
>
> Interdisciplinary Centre for Security, Reliability and Trust
> SnT, University of Luxembourghttp://wwwen.uni.lu/snt/people/salvatore_signorello
>
>
> _______________________________________________
> P4-design mailing list
> P4-design at p4.org
> Listinfo - http://mail.p4.org/mailman/listinfo/p4-design_p4.org
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20150810/8afd0936/attachment-0001.html>


More information about the P4-design mailing list