p4 spec v1.1 (1185620), страница 14
Текст из файла (страница 14)
The original version continues to be processed as if the clone operation did not take place. We use the termclone (rather than mirror) to emphasize that this action is only responsible for generating a new version of the packet. Mirroring requires additional configuration. The clonemechanism may have additional applications.The source of the clone may be the original instance of the packet (an ingress clone), orthe packet as it would exit the switch (an egress clone). The processing of the new instance may be limited to the egress pipeline ("to egress") or it may start with the ingresspipeline ("to ingress"). Hence we have four different clone operations.7715.1 Clone15 RECIRCULATION AND CLONINGFor cloned packets, the instance_type metadata field is used to distinguish betweenthe original and cloned packet instances.If multiple clone actions are executed on one packet, that many clone instances shouldbe generated.
However, specific targets may impose limits on the number of clone instances supported.15.1.1 Clone to IngressFigure 3: Cloning to Ingress, from Ingress or EgressFigure 3 shows the paths for a cloned packet submitted to the ingress. The source maybe from the ingress itself, indicating that a copy of the original packet is given to theparser, or from the egress, in which case a copy of the packet as it is transmitted iscreated and submitted to the parser.15.1.2 Clone to EgressFigure 4 shows the paths for a cloned packet submitted to the egress pipeline. Thesource may be from the ingress, indicating that a copy of the original packet as parsed issubmitted to the Buffering Mechanism; or the source may be from the egress, in whichcase a copy of the packet (and some of its Parsed Representation) just prior to deparsingis created and submitted to the Buffering Mechanism.7815.1 Clone15 RECIRCULATION AND CLONINGFigure 4: Cloning to Egress, from Ingress or EgressSince the Buffering Mechanism requires an egress specification (metadata.egress_spec) to determine how to handle the packet, an egress specification should be associated with the clone_spec associated with the instance by the primitive operation.
Infact, the clone_spec could simply be an egress_spec for some targets.15.1.3 MirroringMirroring, or port monitoring, is a standard networking function described, for example, at http://en.wikipedia.org/wiki/Port_mirroring. In this section we describeone approach to implementing mirroring with P4.Mirroring involves the following:• Identifying the packets to be mirrored.• Generating the mirrored instances of those packets• Specifying what actions should be done on the mirrored instancesNormally, these functions are logically grouped together into a mirror session.Assuming minimal additional target support (for example, a target might provide intrinsic metadata that would directly execute everything necessary for mirroring) a P4program might include the following to support ingress mirroring of packets which are7915.1 Clone15 RECIRCULATION AND CLONINGselected based on a combination of ingress port, VLAN ID, L3 addresses and IP protocol.In this example, the Buffering Mechanism is assumed to provide a programmable mapfrom the clone_spec parameter passed to clone_i2e to an egress_port number.First, a table that matches on these characteristics would be declared.
It would reference an action like the following:action mirror_select(in int<8> session) { // Select packets; map to sessionmodify_field(local_metadata.mirror_session, session);clone_i2e(session, mirror_fld_list);}wherefield_list mirror_field_list {local_metadata.mirror_session;}indicates that the mirror session must be preserved in the cloned packet.This action results in a new copy of the ingress packet to be submitted to the egress.
Therun time APIs allow the specification of exactly which packets get mirrored. They alsohave the flexibility to select the mirror session ID associated with each such packet. Themirror_select table would be introduced into the control flow for the ingress pipeline,probably early in processing.A table matching on local_metadata.mirror_session would be introduced in the egresspipeline.
Assume a value of 0 means "not mirrored", so the table could be applied to allpackets but only select the actions related to mirroring for those marked with a mirrorsession. This table would exercise an action like:action mirror_execute(in int<16> trunc_length) {truncate(trunc_length);}For this example, the only action taken is the truncation of the mirrored packet. However the function could include the data used for an encapsulation header allowingeach mirror session to be sent to a different remote monitoring session.
The encapsulation header values would be programmed at run time.Egress mirroring would follow a similar pattern with the primary difference being theprimitive action used would be clone_e2e.8015.2 Resubmit and Recirculate16 EXTERN OBJECTS15.2 Resubmit and RecirculateFigure 5: Resubmit and RecirculateFigure 5 shows the paths for resubmitting a packet to the parser for processing.
The toppath shows a resubmit process. The resubmit action is signalled in the ingress pipeline.Upon completing that pipeline, the original packet seen on ingress is resubmitted tothe parser along with additional metadata as specified by the action. The parser mayuse the new metadata to make different parsing decisions than on the original passthrough the parser.The lower path shows the path for recirculation. After the packet has completed bothingress and egress processing, it is deparsed and sent back to the parser. The new packetis reparsed, possibly with metadata preserved from the original packet, and passed tothe ingress pipeline as usual.For resubmit and recirculate, the instance_type metadata field distinguishes between first and later times the packet is being processed.16Extern objectsAlthough P4 uses match+action tables and actions to express basic forwarding logic, P4programs might require functionality built out of components whose behavior is not8116.1 Extern types16 EXTERN OBJECTSexpressible in P4 itself.
Examples of this include stateful metering operations and parameterizable hash calculations. For this purpose, P4 allows the specification of externobject types that the user can instantiate in their P4 program.Extern types are provided by both standardized and target-specific libraries. P4 programmers are not supposed to define their own extern types, so much as use the set ofsupported extern types as a palette of components from which to compose their programs.16.1 Extern typesAn extern type definition is intended to be used by both the programmer and compilerfront-end to specify how extern instances of that type must be instantiated and wherethey may be used.An extern type may specify both attributes and methods.
Attributes are properties ofthe extern object that are bound inside the object instantiation. Methods are functionsthat can be called on a given extern instance at various places in the P4 program.extern_type_declaration ::=extern_type type_name {member_declaration*}member_declaration ::= attribute_declaration | method_declarationmethod_declaration ::=method method_name ( [ method_param_list ] );method_param_list ::= method_param [, method_param ]*method_param ::= param_qualifier* type_spec param_nameattribute_declaration ::=attribute attribute_name {type : attribute_type ;[ optional ; ]}identifier_list ::= variable_name ;attribute_type ::=type_specThe extern type indicates that the P4 programmer can instantiate objects of type type_8216.2 Extern Instances16 EXTERN OBJECTSname. Each attribute declaration inside the extern type indicates an attribute its instances contain, and the attribute’s expected type.Attributes marked with the optional property are not required to appear in object instantiations, though the compiler backend may impose further rules as to when an attribute truly is or is not optional.Each method declaration inside the extern type indicates a method that can be calledon its instances, with standard object.method(parameters) notation.
Methods may haveoptional parameters, but may not be overloaded (that is, method names within an extern type must be unique).While a P4 extern_type object describes the interface by which an extern instance interacts with the code around it, it (by design) does not express anything about the object’sactual behavior. For target-specific libraries of extern types, human language documentation is likely sufficient to fully specify an extern’s behavior. For standardized libraries, however, it is strongly recommended that the P4 extern_type is accompaniedwith pseudocode written in a general-purpose programming language to rigorouslydocument the behavior and semantics of the type and its methods.16.2 Extern InstancesThe P4 programmer can declare instances of these extern types the same way they declare tables and other standard P4 objects.extern_instance_declaration ::=extern type_name instance_name ; |extern type_name instance_name {extern_attribute_binding +}extern_attribute_binding ::=attribute_name : object_ref | general_expr;extern_method_call ::=object_ref .
method_name ( [ arg_list ] )If an expression that is used as an attribute value for an extern instance cannot be evaluated at compile time, the compiler should generate an error.Method calls must include arguments for all parameters specified by the extern typedefinition.
If the method includes any optional parameters, their arguments may followthe required arguments (similar to optional arguments in primitive actions).8317 APPENDICESExtern methods take typed and annotated parameters. P4 assumes the copy-in andcopy-out evaluation semantics for the extern-method parameters. When extern-methodparameters alias one another, the target may introduce undefined behaviors. Hence,the P4 authors are recommended not to introduce parameter aliasing.
In addition, acompiler may generate an error upon detecting parameter aliasing.17Appendices17.1 Programming ConventionsThe following is a list of conventions suggested for P4 programs.• Parsing begins with the parser state function named start.• Control flow begins with the control function ingress.17.2 Revision HistoryRelease1.0.0-rc11.0.0-rc21.0.0-rc3Release Date2014-09-082014-09-092014-12-301.0.12015-01-281.0.21.1.0-rc12015-03-032016-11-121.1.02016-1-27Summary of ChangesFirst public version.Minor typos.Fixed some missing tildes (negations).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
