University of Patras

Department of Electrical and Computer Engineering Patras 26500 Greece ehalep@ece.upatras.gr

Ericsson

P.O. Box 6049 Leesburg, VA 20178 United States +1 703 371 3043 joel.halpern@ericsson.com

Routing Internet Engineering Task Force ForCES Model Extension Many network devices support parallel packet processing. This document describes how Forwarding and Control Element Separation (ForCES) can model a network device's parallelization datapath using constructs defined by the ForCES model (RFC 5812) and controlled via the ForCES protocol (RFC 5810).

A lot of network devices can process packets in a parallel manner. The Forwarding and Control Element Separation (ForCES) model presents a formal way to describe the Forwarding Plane's datapath with Logical Function Blocks (LFBs) using XML. This document describes how packet parallelization can be described with the ForCES model. The modeling concept has been influenced by Cilk. Cilk is a programming language that has been in development since 1994 at the Massachusetts Institute of Technology (MIT) Laboratory. Cilk allows programmers to identify elements that can be executed in parallel. The two Cilk concepts used in this document are "spawn" and "sync": spawn being the place where parallel tasks can start and sync being the place where the parallel task finishes and must collect all parallel output (see for the definitions of both "task" and "task correclator"). This document is Experimental; thus, the LFB Class IDs will not be included in the Standard Action's values. Therefore, the LFB Class IDs must have a value larger than 65535, and the LFB names must begin with the prefix 'Ext-'. However, for brevity, when we refer to the LFB Class names in the text of this document (not the formal definitions), the 'Ext-' prefix will be omitted.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

This document follows the terminology defined by the ForCES model in . In particular, the reader is expected to be familiar with the following terms: FE CE FE Model LFB Class (or type) LFB Instance LFB Model Element Attribute LFB Metadata ForCES Component LFB Class Library This document also introduces the following terms: Pieces of a packet. Grouping of packets or chunks belonging to the same packet that are processed in parallel. A 32-bit identifier that uniquely distinguishes tasks. A parallel type where the packets are split into chunks to be processed in parallel. Each task in a split type is composed only of chunks. A parallel type where the packets are copied as-is to downstream LFBs to be processed in parallel. Each task in a flood type is composed only of packets.

This document addresses the following two types of packet parallelization: Flood: Where a copy of a packet is sent to multiple LFBs to be processed in parallel. Split: Where the packet will be split into chunks of equal size specified by the CE and sent to multiple LFB instances, probably of the same LFB class, to be processed in parallel. It must be noted that the process of copying the packet in the flood parallel type is implementation dependent and is loosely defined here. An implementer may either decide to physically copy the packet and send all packets on the parallel paths or decide to logically copy the packet by simply sending, for example, pointers to the same packet provided that the necessary interlocks are taken into account. The implementer has to take into account the device's characteristics to decide which approach fits best to the device. In the split parallel type, while harder, the implementer may also decide to logically split the packet and send, for example, pointers to parts of the packet, provided that the necessary interlocks are managed. In addition, how chunks are distributed to the LFBs (e.g., which chunk to which LFB) is implementation dependent. For example, while usually chunks are sent to the same LFB class, the number of LFB instances may not be equal to the number of chunks. It is up to the implementer to decide how these chunks will be sent, for example, in a round-robin fashion. This document introduces two LFBs that are used before and after the parallelization occurs: Splitter: Similar to Cilk's spawn, a splitter is an LFB that will split the path of a packet that will be sent to multiple downstream LFBs to be processed in parallel. Merger: Similar to Cilk's sync, a merger is an LFB that will receive packets or chunks of the same initial packet and merge them and the results into one packet. Both parallel packet distribution types can currently be achieved with the ForCES model. The Splitter LFB has one group output that produces either chunks or packets to be sent to LFBs for processing, and the Merger LFB has one group input that expects either packets or chunks to aggregate all the parallel packets or chunks and produce a single packet. shows a simple example of a split parallel datapath along with the Splitter and Merger LFB. The example in depicts multiple regular expression (regex) match LFBs that perform match operations on parts of the original packet. shows an example of a flood parallel datapath along with the Splitter and Merger LFB. The example in depicts a path that will classify an IPv4 packet while also performing metering; on the other path, the IPv4 Time to Live (TTL) field will be decremented.

| Regex LFB |----+ +----------+ | +------------+ | +----------+ | |---+ +------>| | P | | C2+M +------------+ C2+M | | P --->| Splitter |-------->| Regex LFB |----------->| Merger |---> | LFB | CN+M +------------+ CN+M | LFB | | |---+ +------>| | +----------+ | +------------+ | +----------+ +---->| Regex LFB |----+ +------------+ ]]>

| LFB |--->| LFB |--->| | P --->| Splitter | +------------+ +-------+ | Merger |---> | LFB | | LFB | | |P+M +------------+ P+M | | | |--------->| IPv4 TTL |---------->| | +----------+ | Decrement | +----------+ | LFB | +------------+ ]]>

This version of the modeling framework does not allow for nested parallel datapath topologies. This decision was reached by the authors and the ForCES working group, as there was no strong use case or need at decision time. This led to a simpler metadata definition, which is required to be transported between the splitter and the corresponding merger. If there is a need for nested parallel datapaths, a new version of a splitter and merger will need to be defined, as well as an augmentation to the defined metadata.

One important element to a developer is the ability to define which LFBs can be used in a parallel mode, which LFBs can be parallelized with which, as well as the order in which parallel LFBs can be assembled. To access the parallelization details, we opted for defining a new LFB class: the CoreParallelization LFB. This choice was an alternative to making another change to the core FEObject LFB. The CoreParallelization exists merely to define the capabilities for an FE's LFB parallelization. A CE using the ForCES protocol can check the existence of this LFB class in the FEObject's SupportedLFBs component. The existence of the CoreParallelization LFB will indicate to the CE that the specific FE supports parallelization. There MUST be only one instance of the CoreParallelization LFB per FE. The topology of the parallel datapath can be deferred and manipulated from the FEObject LFB's LFBTopology. The CoreParallelization requires only one capability in order to specify each LFB that can be used in a parallel mode: The Name of the LFB. The Class ID of the LFB. The Version of the LFB. The number of instances that class can support in parallel. A list of LFB classes that can follow this LFB class in a pipeline for a parallel path. A list of LFB classes that can exist before this LFB class in a pipeline for a parallel path. A list of LFB classes that can process packets or chunks in parallel with this LFB class.

ParallelLFBType Table entry for parallel LFBs LFBName The name of an LFB Class string LFBClassID The id of the LFB Class uint32 LFBVersion The version of the LFB Class used by this FE string LFBParallelOccurrenceLimit The upper limit of instances of the same parallel LFBs of this class uint32 AllowedParallelAfters List of LFB Classes that can follow this LFB in a parallel pipeline uint32 AllowedParallelBefores List of LFB Classes that this LFB class can follow in a parallel pipeline uint32 AllowedParallel List of LFB Classes that this LFB class can run in parallel with uint32 ParallelLFBs List of all supported parallel LFBs ParallelLFBType ]]>

It is expected that the splitting and merging mechanisms are an implementation issue. This document plays the role of defining the operational parameters for the splitting and merging: namely, the size of the chunks, what happens if a packet or chunk has been marked as invalid, and whether the merge LFB should wait for all packets or chunks to arrive. The following metadata set is defined as a struct: ParallelType - Flood or split TaskCorrelator - Identify packets or chunks that belonged to the initial packet that entered the Splitter LFB ParallelNum - Sequence number of the packet or the chunk for a specific task ParallelPartsCount - Total number of packets or chunks for a specific task This metadata is produced from the Splitter LFB, is opaque to LFBs in parallel paths, and is passed along to the Merger LFB without being consumed. In the case in which an LFB decides that a packet/chunk has to be dropped, the LFB MAY drop the packet/chunk, but the metadata MUST be sent to the Merger LFB's InvalidIn input port for merging purposes. Additional metadata produced by LFBs inside a datapath MAY be aggregated within the Merger LFB and sent on after the merging process. In case of receiving the same metadata definition with multiple values, the Merger LFB MUST keep the first received from a valid packet or chunk.

One frame type has been defined in this library. Frame Name Synopsis Chunk A chunk is a frame that is part of an original larger frame.

One data type has been defined in this library. DataType Name Type Synopsis ParallelTypes Atomic uchar. Special Values Flood (0), Split (1). The type of parallelization this packet will go through.

The following metadata structure with ID 16, using the ForCES model extension, is defined for the parallelization library: Metadata Name Type ID Synopsis ParallelType uchar 1 The type of parallelization this packet will go through. 0 for flood, 1 for split. TaskCorrelator uint32 2 An identification number to specify that a packet or a chunk belongs to the same parallel task. ParallelNum uint32 3 Defines the number of a specific packet or chunk of a specific task. ParallelPartsCount uint32 4 Defines the total number of packets or chunks for a specific task.

The Splitter LFB takes part in parallelizing the processing datapath by sending either the same packet () or chunks () of the same packet to multiple LFBs.

| Splitter LFB |-------------> | | +---------------+ ]]>

The Splitter LFB receives any kind of packet via the singleton input, Input. Depending upon the CE's configuration of the ParallelType component, if the parallel type is of type flood (0), the same packet MUST be sent through all instances of the group output "SplitterOut". If the parallel type is of type split (1), then the packet will be split into same size chunks except for the last, which MAY be smaller, with the max size being defined by the ChunkSize component. Chunks MAY be sent out in a round-robin fashion through instances of the group output "ParallelOut" or in any other way defined by the implementer. Each packet or chunk will be accompanied by the following metadata set as a struct: ParallelType - The parallel type: split or flood. ParallelID - Generated by the Splitter LFB to identify which chunks or packets belong to the same parallel task. ParallelNum - Each chunk or packet of a parallel ID will be assigned a number in order for the Merger LFB to know when it has gathered them all along with the ParallelPartsCount metadata. ParallelPartsCount - The number of chunks or packets for the specific task.

The Splitter LFB has only two components. The first is the ParallelType, a uint32 that defines how the packet will be processed by the Splitter LFB. The second is the ChunkSize, a uint32 that specifies the size of each chunk when a packet is split into multiple same-size chunks. The last chunk MAY be smaller than the value of the ChunkSize.

This LFB has only one capability specified; the MinMaxChunkSize is a struct of two uint32s to specify the minimum and maximum chunk size.

This LFB has no events specified.

The Merger LFB is the synchronization point for multiple packets or packet chunks of the same task emanating out of the parallel path, as illustrated in and .

| | MergerOut | Merger LFB |-----------> InvalidIn | | --------->| | +-------------+ ]]>

The Merger LFB receives either a packet or a chunk via the group input ParallelIn, along with the ParallelType metadata, the TaskCorrelator, the ParallelNum, and the ParallelPartsCount. In the case in which an upstream LFB has dropped a packet or a chunk, the Merger LFB MAY receive only the metadata, both the metadata and the packet, or the chunk through the InvalidIn group input port. It SHOULD receive a metadata specifying the error code. Currently defined metadata in the Base LFB Library are the ExceptionID and the ValidateErrorID. If the MergeWaitType is set to false, the Merger LFB will initiate the merge process upon receiving the first packet. If false, for each task identified by the task correlator, it will wait for all packets/chunks to arrive unless the MergeWaitTimeoutTimer timer expires. If the MergeWaitTimeoutTimer has expired, the Merger MUST consider the rest of the packets/chunks that have not been received as invalid, and it MUST handle the packets according to the InvalidAction value. If one packet or chunk has been received through the InvalidIn port, then the merging procedure will handle the packets/chunks according to the InvalidAction value. If the InvalidAction component has been set to 0, then if one packet or chunk is not valid, all will be dropped or else the process will initiate. Once the merging process has been completed, the resulting packet will be sent via the singleton output port MergerOut. If the Merger LFB receives different values for the same metadata from different packets or chunks that have the same task correlator, then the Merger LFB will use the first metadata from a packet or chunk that entered the LFB through the MergerIn input port.

This LFB has the following components specified: InvalidAction: A uchar defining what the Merge LFB will do if an invalid chunk or packet is received. If set to 0 (DropAll), the merge will be considered invalid and all chunks or packets will be dropped. If set to 1 (Continue), the merge will continue. MergeWaitTimeoutTimer: A uint32 defining the amount of time, in milliseconds, that the Merger will wait for all packets or chunks within the same task to arrive before considering them invalid. The MergeWaitTimeoutTimer starts as soon as the first chunk or packet of a parallel task arrives. MergeWaitType: A boolean. If true, the Merger LFB will wait for all packets or chunks to be received prior to performing the merge. If false, when one packet or a chunk with a response is received by the merge LFB, it will start with the merge process. InvalidMergesCounter: A uint32 that counts the number of merges where there is at least one packet or chunk that entered the Merger LFB through the InvalidIn input port. InvalidTotalCounter: A uint32 that counts the number of merges where all packets/chunks entered the Merger LFB through the InvalidIn input port. InvalidIDCounters: A struct of two arrays. Each array has a uint32 per row. Each array counts the number of invalid merges where at least one packet or chunk entered through InvalidID per error ID. The first array is the InvalidExceptionID and the second is the InvalidValidateErrorID.

This LFB has no capabilities specified.

This LFB specifies only two events. The first detects whether the InvalidMergesCounter has exceeded a specific value, and the second detects whether the InvalidAllCounter has exceeded a specific value. Both error reports will send the respective counter value. Event Filters can be used to limit the number of messages

A core LFB that specifies that the FE supports parallelization instead of updating the FEObject LFB

The CoreParallelization does not handle data.

This LFB has no components specified.

This LFB has only one capability specified. The ParallelLFBs is a table which lists all the LFBs that can be parallelized. Each row of the table contains: LFBName: A string. The Name of the parallel LFB. LFBClassID: A uint32. The Class ID of the parallel LFB. LFBVersion: A string. The Version of the parallel LFB. LFBParallelOccurrenceLimit: A uint32. The upper limit of instances of the same parallel LFBs of this class. AllowedParallelAfters: A table of uint32s (LFB Class IDs). A list of LFB classes that can follow this LFB class in a pipeline for a parallel path. AllowedParallelBefores: A table of uint32s (LFB Class IDs). A list of LFB classes that can exist before this LFB class in a pipeline for a parallel path. AllowedParallel: A table of uint32s (LFB Class IDs). A list of LFB classes that can process packets or chunks in parallel with this LFB class.

This LFB specifies no events

Chunk A chunk is a frame that is part of an original larger frame ParallelTypes The type of parallelization this packet will go through uchar Flood The packet/chunk has been sent as a whole to multiple recipients Split The packet/chunk has been split into multiple chunks and sent to recipients ParallelLFBType Table entry for parallel LFBs LFBName The name of an LFB Class string LFBClassID The ID of the LFB Class uint32 LFBVersion The version of the LFB Class used by this FE string LFBParallelOccurrenceLimit The upper limit of instances of the same parallel LFBs of this class uint32 AllowedParallelAfters List of LFB Classes that can follow this LFB in a parallel pipeline uint32 AllowedParallelBefores List of LFB Classes that this LFB Class can follow in a parallel pipeline uint32 AllowedParallel List of LFB Classes that this LFB Class can be run in parallel with uint32 ParallelMetadataSet A metadata set for parallelization-related LFBs 32 ParallelType The type of parallelization this packet/chunk has gone through ParallelTypes TaskCorrelator An identification number to specify that packets or chunks originate from the same packet. uint32 ParallelNum Defines the number of the specific packet or chunk of the specific parallel ID. uint32 ParallelPartsCount Defines the total number of packets or chunks for the specific parallel ID. uint32 Ext-Splitter A Splitter LFB takes part in parallelizing the processing datapath. It will either send the same packet or chunks of one packet to multiple LFBs 1.0 SplitterIn An input port expecting any kind of frame Arbitrary SplitterOut A parallel output port that sends the same packet to all output instances or chunks of the same packet to output instances. Each chunk is sent only once by the LFB. Arbitrary Chunk ParallelMetadataSet ParallelType The type of parallelization this packet will go through ParallelTypes ChunkSize The size of a chunk when a packet is split into multiple chunks of the same size uint32 MinMaxChunkSize The minimum and maximum size of a chunk capable of split by this LFB MinChunkSize Minimum chunk size uint32 MaxChunkSize Maximum chunk size uint32 Ext-Merger A Merger LFB receives multiple packets or multiple chunks of the same packet and merge them into one merged packet 1.0 MergerIn A parallel input port that accepts packets or chunks from all output instances Arbitrary Chunk ParallelMetadataSet InvalidIn When a packet is sent out of an error port of an LFB in a parallel path, it will be sent to this output port in the Merger LFB Arbitrary Chunk ExceptionID ValidateErrorID MergerOut An output port expecting any kind of frame Arbitrary InvalidAction What the Merge LFB will do if an invalid chunk or packet is received uchar DropAll Drop all packets or chunks Continue Continue with the merge MergeWaitType Whether the Merge LFB will wait for all packets or chunks to be received prior to sending out a response boolean MergeWaitTimeoutTimer The time that the Merger will wait for all packets or chunks within the same task to arrive before considering them invalid. uint32 InvalidMergesCounter Counts the number of merges where there is at least one packet/chunk that entered the Merger LFB through the InvalidIn input port uint32 InvalidTotalCounter Counts the number of merges where all packets/chunks entered the Merger LFB through the InvalidIn input port uint32 InvalidIDCounters Counts the number of invalid merges where at least one packet/chunk entered through InvalidID per error ID InvalidExceptionID Per Exception ID uint32 InvalidValidateErrorID Per Validate Error ID uint32 ManyInvalids An event that specifies if there are too many invalids InvalidCounter InvalidMergesCounter ManyTotalInvalids An event that specifies if there are too many invalids InvalidTotalCounter InvalidTotalCounter Ext-CoreParallelization A core LFB that specifies that the FE supports parallelization instead of updating the FEObject LFB 1.0 ParallelLFBs A table that lists all the LFBs that can be parallelized ParallelLFBType ]]>

LFB classes defined by this document do not belong to LFBs defined by Standards Action. As such, the corresponding values assigned in the "Logical Functional Block (LFB) Class Names and Class Identifiers" registry at <http://www.iana.org/assignments/forces> are above 65535. This specification includes the following LFB class names and LFB class identifiers:

+-------+---------------------+-------+-----------------+---------+ | LFB | LFB Class Name | LFB | Description | Ref | | Class | |Version| | | | ID | | | | | +-------+---------------------+-------+-----------------+---------+ | 65537 | Ext-Splitter | 1.0 | A Splitter LFB | RFC | | | | | will send | 7409 | | | | |either the same | | | | | | packet or | | | | | | chunks of one | | | | | | packet to | | | | | | multiple LFBs. | | +-------+---------------------+-------+-----------------+---------+ | 65538 | Ext-Merger | 1.0 | A Merger LFB | RFC | | | | | receives | 7409 | | | | | multiple | | | | | | packets or | | | | | | multiple | | | | | | chunks of the | | | | | | same packet | | | | | | and merges | | | | | | them into one. | | +-------+---------------------+-------+-----------------+---------+ | 65539 | Ext- | 1.0 | A core LFB to | RFC | | | CoreParallelization | | signify the | 7409 | | | | | parallelization | | | | | | capability | | +-------+---------------------+-------+-----------------+---------+

The Metadata ID namespace is 32-bits long. Values assigned by this specification are: Value Name Reference 0x00000010 ParallelMetadataSet RFC 7409

This document does not alter either the ForCES model or the ForCES protocol. As such, it has no impact on their security considerations. This document simply defines the operational parameters and capabilities of LFBs that perform parallelization and not how parallelization is implemented. Finally, this document does not attempt to analyze the presence or possibility of security interactions created by allowing parallel operations on packets. Any such issues, if they exist, are for the designers of the particular data path, not the general mechanism.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword Massachusetts Institute of Technology

The authors would like to thank Edward Crabbe for the initial discussion that led to the creation of this document. They also thank Jamal Hadi Salim and Dave Hood for comments and discussions and Adrian Farrel for his AD review that made this document better. Finally, the authors thank Francis Dupont for his Gen-Art review and Magnus Nystroem for his security review both of which refined this document to its final shape.