p4 spec v1.1 (1185620), страница 6
Текст из файла (страница 6)
Validity and deparsing (see Section 6) are the only points where packet headersand metadata headers differ.303.2 Header and Metadata Instances3 HEADERS AND FIELDSA header instance, declared with the keyword header, is valid if it is extracted duringparsing (see Section 5) or if an action makes it valid (add or copy). A field (inside aheader instance) is valid if its parent header instance is valid.All fields in a metadata instance are always valid. Testing a metadata field for validityshould raise a compiler warning and will always evaluate to True.Explanation: The reason for this is best seen by examining the caseof a "flag"; for example, suppose a one bit metadata flag is used toindicate that a packet has some attribute (say, is an IP packet, v4 orv6).
There is no practical difference between the flag having a valueof 0 and the flag itself being invalid. Similarly, many "index" metadata fields can be given a reserved value to indicate they are invalid(hence support for initial values of metadata fields). While occasionally it would be useful to have an independent valid bit for a metadatafield, defining a separate metadata flag to represent that field’s validityis a reasonable work around.Only valid packet header fields may result in a match (when a value is specified forexact or ternary matches against the field), although a match operation may explicitlycheck if a header instance (or field) is valid. Only valid packet headers are consideredfor deparsing (see Section 6).3.2.2 Header StacksP4 supports the notion of a header stack which is a sequence of adjacent headers of thesame type.
MPLS and VLAN tags are examples that might be treated this way. Headerstacks are declared as arrays as shown in Section 3.2, and are of fixed length. Adding orremoving elements from the stack does not change the number of headers in the array- it just changes the number of valid headers in the array.Header stack instances are referenced using bracket notation and such references areequivalent to a non-stack instance reference. Each element in the stack has its ownvalidity bit.
The following special indices can be used to reference variable locations inthe stack:• last: The largest-index element that is valid. Used primarily to refer the higherindexed end of the stack in match+action.• next: The smallest-index element that is invalid.
Used primarily for parsing headerdata into a stack in a loop.The special primitive actions push() and pop() are used to add and remove headersfrom the stack inside a match+action table. See Section 10.1 for more details.313.3 Header and Field References3 HEADERS AND FIELDS3.3 Header and Field ReferencesFor match, action and control flow specifications, we need to make references to headerinstances and their fields.
Headers are referenced via their instance names. For headerstacks, an index is specified in square brackets. The keyword last can be used as anindex to refer to the largest-index valid instance of a header stack, while next refers tothe smallest-index invalid instance.Dotted notation is used to refer to a particular field inside of a header instance.header_ref ::=header_instance_name | header_instance_name "[" header_ref_index "]"header_ref_index ::= const_expr | last | nextfield_ref ::= header_ref . field_nameFor example inner_vlan_tag.vid where inner_vlan_tag has been declared as an instance of header type vlan_tag.• Field names must be listed in the fields attribute of the header declaration.• A field reference is always relative to its parent header.
This allows the same fieldname to be used in different header types without ambiguity.• Each header instance may be valid or invalid at any given time. This state may betested in match+action processing.• References at run time to a header instance (or one of its fields) which is not validresults in a special “undefined” value. The implications of this depend on thecontext.3.4 Field ListsIn many cases, it is convenient to specify a sequence of fields. For example, a hash function may take a sequence of fields as input, or a checksum may be calculated based ona sequence of fields.
P4 allows such declarations. Each entry may be a specific field instance reference, a header instance (which is equivalent to listing all the header’s fieldsin order), or a fixed value. Packet headers and metadata may be referenced in a field list.If a field list contains an invalid field (i.e., if the field’s parent header is invalid) when it isevaluated (e.g., for hash calculation or checksum generation), then such an evaluationmay lead to an undefined behavior.field_list_declaration ::=field_list field_list_name {324 CHECKSUMS AND HASH-VALUE GENERATORS[ field_list_entry ; ] *}field_list_entry ::=object_ref | field_valueThe objects referenced in a field list must be either header instances, fields, or otherfield lists.
Recursive field list references are not supported.4Checksums and Hash-value generatorsChecksums and hash value generators are examples of functions that operate on astream of bytes from a packet to produce an integer. These have many applications innetworking. The integer may be used, for example, as an integrity check for a packet oras a means to generate a pseudo-random value in a given range on a packet-by-packetor flow-by-flow basis.P4 provides a means of associating a function with a set of fields and allowing the resulting operation (a map from packets to integers) to be referenced in P4 programs.These are called field list calculations or calculation objects.
P4 does not support theexpression of the algorithm for computing the underlying function, treating these likeprimitive actions. A set of known algorithms are identified for convenience.The resulting functions – a field list calculation maps a packet to an integer – may beconfigurable through run time APIs. Targets may vary in their support of these interfaces, but typically the seed value of the calculation may be configured, the algorithmmay have configurable parameters (such as the coefficients for a polynomial used inthe calculation) and possibly even the set of fields used may be configured.The field list may be referenced as a field property for checksums, discussed in Section 4.1, or referenced in a primitive action.field_list_calculation_declaration ::=field_list_calculation field_list_calculation_name {input {[ field_list_name ; ] +}algorithm : stream_function_algorithm_name ;output_width : const_expr ;}334.1 Checksums4 CHECKSUMS AND HASH-VALUE GENERATORSRun time APIs allow the selection of one of the input field lists to be active at a time.The first listed name is used as the default.The output_width value is in bits.A field instance is excluded from the calculation (i.e., it is treated as if the instance is notlisted in the input list) if the field’s header is not valid.The algorithm is specified as a string.
The following algorithms are defined with thegiven names, and targets may support others.• xor16: Simply the XOR of bytes taken two at a time.• csum16: See the IPv4 header checksum description inhttps://tools.ietf.org/html/rfc791#page-14.• optional_csum16: See the UDP header checksum description inhttps://tools.ietf.org/html/rfc768#page-2.• crc16: See http://en.wikipedia.org/wiki/Crc16.• crc32: See http://en.wikipedia.org/wiki/Crc32• programmable_crc: This algorithm allows the specification of an arbitrary CRCpolynomial. See http://en.wikipedia.org/wiki/Cyclic_redundancy_check.4.1 ChecksumsSome fields, such as the IP checksum, hold the result of a stream calculation. P4 allowsthe representation of these dependencies with the calculated field declaration.
Calculated fields matter to the extent they are verified at packet ingress or are updated atpacket egress.The syntax associates a sequence of update or verify directives to a specific field instance, each of which may have a condition associated with it. The first entry with acondition satisfied by the packet (or with no condition specified) determines the association. This complexity allows the selection of different calculations based on thepacket’s format. For example, the calculation of a TCP checksum may vary slightlybased on whether the packet has an IPv4 or an IPv6 header.Note that the conditions are evaluated at the point the verify or update operations arecarried out.Currently only limited conditions are supported.calculated_field_declaration ::=calculated_field field_ref { update_verify_spec + }344.1 Checksums4 CHECKSUMS AND HASH-VALUE GENERATORSupdate_verify_spec ::=update_or_verify field_list_calculation_name [ if_cond ] ;update_or_verify ::= update | verifyif_cond ::= if ( calc_bool_cond )calc_bool_cond ::=valid ( header_ref | field_ref ) |field_ref == field_valueHere is an example declaration.
It assumes field_list_calculation declarations fortcpv4_calc and tcpv6_calc have been given and that ipv4 and ipv6 are packet headerinstances.calculated_field tcp.chksum {update tcpv4_calc if (valid(ipv4));update tcpv6_calc if (valid(ipv6));verify tcpv4_calc if (valid(ipv4));verify tcpv6_calc if (valid(ipv6));}For checksums, the field list calculation is intended to bind the field list and algorithmto a specific field instance. This declaration indicates that the value stored in field_refis expected to be the value calculated by the given field set calculation on the packet.Note that although this declaration may occur anywhere in the P4 program, the declaration should be placed immediately after the header instance declaration for the fieldreferenced.Fields with type varbit cannot be declared as calculated fields.The verify option indicates that the parser should calculate the expected value andcheck if that value is stored in the indicated field.
If the value is not equal, then a p4_pe_checksum exception is generated; see Section 5.6.1. Standard Parser Exceptions. Thischeck occurs at the end of parsing and is performed only if field_ref is valid.The update option indicates that the system should update the value of the field ifchanges are made to any fields on which it depends. The update to the field occurswhen the packet is deparsed for egress. If no update clause applies, the field retains itsvalue from the match+action pipeline.355 PARSER SPECIFICATION5Parser SpecificationP4 models the parser as a state machine. This can be represented as a parse graphwith each state a node and the state transitions as edges.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
