draft-ietf-forces-packet-parallelization-03.txt   rfc7409.txt 
Internet Engineering Task Force E. Haleplidis Internet Engineering Task Force (IETF) E. Haleplidis
Internet-Draft University of Patras Request for Comments: 7409 University of Patras
Intended status: Experimental J. Halpern Category: Experimental J. Halpern
Expires: April 13, 2015 Ericsson ISSN: 2070-1721 Ericsson
October 10, 2014 November 2014
ForCES Packet Parallelization Forwarding and Control Element Separation (ForCES)
draft-ietf-forces-packet-parallelization-03 Packet Parallelization
Abstract Abstract
Forwarding and Control Element Separation (ForCES) defines an
architectural framework and associated protocols to standardize
information exchange between the control plane and the forwarding
plane in a ForCES Network Element (ForCES NE). RFC5812 has defined
the ForCES Model provides a formal way to represent the capabilities,
state, and configuration of forwarding elements within the context of
the ForCES protocol (RFC 5810), so that Control Elements (CEs) can
control the Forwarding Elements (FEs) accordingly. More
specifically, the model describes the logical functions that are
present in an FE, what capabilities these functions support, and how
these functions are or can be interconnected.
Many network devices support parallel packet processing. This Many network devices support parallel packet processing. This
document describes how ForCES can model a network device's document describes how Forwarding and Control Element Separation
parallelization datapath. (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).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on April 13, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7409.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Packet Parallelization . . . . . . . . . . . . . . . . . . . 4 2. Packet Parallelization . . . . . . . . . . . . . . . . . . . 5
2.1. Core parallelization LFB . . . . . . . . . . . . . . . . 6 2.1. CoreParallelization LFB . . . . . . . . . . . . . . . . . 7
2.2. Parallelization metadata . . . . . . . . . . . . . . . . 9 2.2. Parallelization Metadata . . . . . . . . . . . . . . . . 10
3. Parallel Base Types . . . . . . . . . . . . . . . . . . . . . 9 3. Parallel Base Types . . . . . . . . . . . . . . . . . . . . . 11
3.1. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 10 3.3. Metadata Types . . . . . . . . . . . . . . . . . . . . . 12
4. Parallel LFBs . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Parallel LFBs . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Splitter . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Splitter . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Data Handling . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Data Handling . . . . . . . . . . . . . . . . . . . . 13
4.1.2. Components . . . . . . . . . . . . . . . . . . . . . 12 4.1.2. Components . . . . . . . . . . . . . . . . . . . . . 13
4.1.3. Capabilities . . . . . . . . . . . . . . . . . . . . 12 4.1.3. Capabilities . . . . . . . . . . . . . . . . . . . . 13
4.1.4. Events . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.4. Events . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Merger . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Merger . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Data Handling . . . . . . . . . . . . . . . . . . . . 13 4.2.1. Data Handling . . . . . . . . . . . . . . . . . . . . 14
4.2.2. Components . . . . . . . . . . . . . . . . . . . . . 14 4.2.2. Components . . . . . . . . . . . . . . . . . . . . . 15
4.2.3. Capabilities . . . . . . . . . . . . . . . . . . . . 14 4.2.3. Capabilities . . . . . . . . . . . . . . . . . . . . 15
4.2.4. Events . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.4. Events . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. CoreParallelization . . . . . . . . . . . . . . . . . . . 15 4.3. CoreParallelization . . . . . . . . . . . . . . . . . . . 16
4.3.1. Data Handling . . . . . . . . . . . . . . . . . . . . 15 4.3.1. Data Handling . . . . . . . . . . . . . . . . . . . . 16
4.3.2. Components . . . . . . . . . . . . . . . . . . . . . 15 4.3.2. Components . . . . . . . . . . . . . . . . . . . . . 16
4.3.3. Capabilities . . . . . . . . . . . . . . . . . . . . 15 4.3.3. Capabilities . . . . . . . . . . . . . . . . . . . . 16
4.3.4. Events . . . . . . . . . . . . . . . . . . . . . . . 15 4.3.4. Events . . . . . . . . . . . . . . . . . . . . . . . 17
5. XML for Parallel LFB library . . . . . . . . . . . . . . . . 16 5. XML for Parallel LFB Library . . . . . . . . . . . . . . . . 17
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 25
7.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 24 6.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 26
7.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . 25 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
A lot of network devices can process packets in a parallel manner. A lot of network devices can process packets in a parallel manner.
The Forwarding and Control Element Separation (ForCES) Model The Forwarding and Control Element Separation (ForCES) model
[RFC5812] presents a formal way to describe the Forwarding Plane's [RFC5812] presents a formal way to describe the Forwarding Plane's
datapath with Logical Function Blocks (LFBs) using XML. This datapath with Logical Function Blocks (LFBs) using XML. This
document describes how packet parallelization can be described with document describes how packet parallelization can be described with
the ForCES model. the ForCES model.
The modeling concept has been influenced by Cilk [Cilk]. Cilk is a The modeling concept has been influenced by Cilk [Cilk]. Cilk is a
programming language that has been developed since 1994 at the MIT programming language that has been in development since 1994 at the
Laboratory to allow programmers to identify elements that can be Massachusetts Institute of Technology (MIT) Laboratory. Cilk allows
executed in parallel. The two Cilk concepts used in this document is programmers to identify elements that can be executed in parallel.
spawn and sync. Spawn being the place where parallel tasks can start The two Cilk concepts used in this document are "spawn" and "sync":
and sync being the place where the parallel task finishes and must spawn being the place where parallel tasks can start and sync being
collect all parallel output. the place where the parallel task finishes and must collect all
parallel output (see Section 1.2 for the definitions of both "task"
As task, we define a grouping of packets or pieces of a packet and "task correclator").
(chunks) that belong to the same original packet and are going to be
processed in parallel. All packets/chunks of the same task will be
distinguished by an identifier, in the specific case we use a 32-bit
identifier named task correlator.
This document is in the experimental track and thus the LFB Class IDs This document is Experimental; thus, the LFB Class IDs will not be
will not be included in the standard action's values. Therefore the included in the Standard Action's values. Therefore, the LFB Class
LFB Class IDs must have a value larger than 65535 and the LFB names IDs must have a value larger than 65535, and the LFB names must begin
must begin with the prefix 'Ext-'. However for brevity, when we with the prefix 'Ext-'. However, for brevity, when we refer to the
refer to the LFB Class names in the text of this document (not the LFB Class names in the text of this document (not the formal
formal definitions), the 'Ext-' prefix will be omitted. definitions), the 'Ext-' prefix will be omitted.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Definitions 1.2. Definitions
This document follows the terminology defined by the ForCES Model in This document follows the terminology defined by the ForCES model in
[RFC5812]. In particular, the reader is expected to be familiar with [RFC5812]. In particular, the reader is expected to be familiar with
the following terms: the following terms:
FE FE
CE CE
FE Model FE Model
LFB (Logical Functional Block) Class (or type) LFB Class (or type)
LFB Instance LFB Instance
LFB Model LFB Model
Element Element
Attribute Attribute
LFB Metadata LFB Metadata
ForCES Component ForCES Component
skipping to change at page 4, line 29 skipping to change at page 5, line 18
Attribute Attribute
LFB Metadata LFB Metadata
ForCES Component ForCES Component
LFB Class Library LFB Class Library
This document also introduces the following terms: This document also introduces the following terms:
Chunk - Pieces of a packet Chunk: Pieces of a packet.
Task - Grouping of packets or chunks belong to the same packet Task: Grouping of packets or chunks belonging to the
that are processed in parallel same packet that are processed in parallel.
Task Correlator - A 32-bit identifier that uniquely distinguishes Task Correlator: A 32-bit identifier that uniquely distinguishes
tasks tasks.
Split Type - A parallel type where the packets are split into Split Type: A parallel type where the packets are split into
chunks to be processed in parallel. Each task in a split type is chunks to be processed in parallel. Each task in
composed only of chunks. a split type is composed only of chunks.
Flood Type - A parallel type where the packets are copied as is to Flood Type: A parallel type where the packets are copied as-is
downstream LFBs to be processed in parallel. Each task in a flood to downstream LFBs to be processed in parallel.
type is composed only of packets. Each task in a flood type is composed only of
packets.
2. Packet Parallelization 2. Packet Parallelization
This document addresses the following two types of packet This document addresses the following two types of packet
parallelization: parallelization:
1. Flood - where a copy of a packet is sent to multiple LFBs to be 1. Flood: Where a copy of a packet is sent to multiple LFBs to be
processed in parallel. processed in parallel.
2. Split - where the packet will be split in equal size chunks 2. Split: Where the packet will be split into chunks of equal size
specified by the CE and sent to multiple LFB instances probably specified by the CE and sent to multiple LFB instances, probably
of the same LFB class to be processed in parallel. of the same LFB class, to be processed in parallel.
It must be noted that the process of copying the packet in the Flood It must be noted that the process of copying the packet in the flood
parallel type is implementation dependent and is loosely defined parallel type is implementation dependent and is loosely defined
here. An implementer may either decide to physical copy the packet here. An implementer may either decide to physically copy the packet
and send all packets on the parallel paths, or may decide to and send all packets on the parallel paths or decide to logically
logically copy the packet by simply sending, for example, pointers of copy the packet by simply sending, for example, pointers to the same
the same packet provided that the necessary interlocks are taken into packet provided that the necessary interlocks are taken into account.
account. The implementer has to take into account the device's The implementer has to take into account the device's characteristics
characteristics to decide which approach fits best to the device. to decide which approach fits best to the device.
In the split parallel type, while harder, the implementer may also In the split parallel type, while harder, the implementer may also
decide to logically split the packet and send, for example, pointers decide to logically split the packet and send, for example, pointers
to parts of the packet, provided that the necessary interlocks are to parts of the packet, provided that the necessary interlocks are
managed. In addition, how chunks are distributed to the LFBs, e.g., managed. In addition, how chunks are distributed to the LFBs (e.g.,
which chunk to which LFB, is implementation dependent. For example which chunk to which LFB) is implementation dependent. For example,
while usually chunks are sent to the same LFB class, the number of while usually chunks are sent to the same LFB class, the number of
LFB instances may not equal to the number of chunks. It is up to the LFB instances may not be equal to the number of chunks. It is up to
implementer to decide how these chunks will be sent, for example in a the implementer to decide how these chunks will be sent, for example,
round-robin fashion. in a round-robin fashion.
This document introduces two LFBs that are used in before and after This document introduces two LFBs that are used before and after the
the parallelization occurs: parallelization occurs:
1. Splitter - similar to Cilk's spawn. An LFB that will split the 1. Splitter: Similar to Cilk's spawn, a splitter is an LFB that will
path of a packet which will be sent to multiple downstream LFBs split the path of a packet that will be sent to multiple
to be processed in parallel. downstream LFBs to be processed in parallel.
2. Merger - similar to Cilk's sync. An LFB that will receive 2. Merger: Similar to Cilk's sync, a merger is an LFB that will
packets or chunks of the same initial packet and merge them and receive packets or chunks of the same initial packet and merge
the results into one packet. them and the results into one packet.
Both parallel packet distribution types can currently be achieved Both parallel packet distribution types can currently be achieved
with the ForCES model. The splitter LFB has one group output that with the ForCES model. The Splitter LFB has one group output that
produces either chunks or packets to be sent to LFBs for processing 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 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 chunks to aggregate all the parallel packets or chunks and produce a
single packet. Figure 1 shows a simple example of a split parallel single packet.
datapath along with the splitter and merger LFB. Figure 2 shows an
example of a flood parallel datapath along with the splitter and Figure 1 shows a simple example of a split parallel datapath along
merger LFB. with the Splitter and Merger LFB. The example in Figure 1 depicts
multiple regular expression (regex) match LFBs that perform match
operations on parts of the original packet. Figure 2 shows an
example of a flood parallel datapath along with the Splitter and
Merger LFB. The example in Figure 2 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.
C1+M +------------+ C1+M C1+M +------------+ C1+M
+---->| Regex LFB |----+ +---->| Regex LFB |----+
+----------+ | +------------+ | +----------+ +----------+ | +------------+ | +----------+
| |---+ +------>| | | |---+ +------>| |
P | | C2+M +------------+ C2+M | | P P | | C2+M +------------+ C2+M | | P
--->| Splitter |-------->| Regex LFB |----------->| Merger |---> --->| Splitter |-------->| Regex LFB |----------->| Merger |--->
| LFB | CN+M +------------+ CN+M | LFB | | LFB | CN+M +------------+ CN+M | LFB |
| |---+ +------>| | | |---+ +------>| |
+----------+ | +------------+ | +----------+ +----------+ | +------------+ | +----------+
+---->| Regex LFB |----+ +---->| Regex LFB |----+
+------------+ +------------+
Figure 1: Simple split parallel processing Figure 1: Simple Split Parallel Processing
+----------+ +------------+ +-------+ +----------+ +----------+ +------------+ +-------+ +----------+
| |P+M | Classifier |P+M | Meter |P+M | | | |P+M | Classifier |P+M | Meter |P+M | |
P | |--->| LFB |--->| LFB |--->| | P P | |--->| LFB |--->| LFB |--->| | P
--->| Splitter | +------------+ +-------+ | Merger |---> --->| Splitter | +------------+ +-------+ | Merger |--->
| LFB | | LFB | | LFB | | LFB |
| |P+M +------------+ P+M | | | |P+M +------------+ P+M | |
| |--------->| IPv4 TTL |---------->| | | |--------->| IPv4 TTL |---------->| |
+----------+ | Decrement | +----------+ +----------+ | Decrement | +----------+
| LFB | | LFB |
+------------+ +------------+
Figure 2: Simple flood parallel processing Figure 2: Simple Flood Parallel Processing
This version of the modeling framework does not allow for nested This version of the modeling framework does not allow for nested
parallel datapath topologies. This decision was reached by the parallel datapath topologies. This decision was reached by the
authors and the ForCES working group as there was no strong use case 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, or need at decision time. This led to a simpler metadata definition,
which was needed to be transported between the splitter and the which is required to be transported between the splitter and the
corresponding merger. If there is a need for nested parallel corresponding merger. If there is a need for nested parallel
datapaths a new version of a splitter and merger will be needed to be datapaths, a new version of a splitter and merger will need to be
defined as well as an augmentation to the defined metadata. defined, as well as an augmentation to the defined metadata.
2.1. Core parallelization LFB 2.1. CoreParallelization LFB
One important element to a developer is the ability to define which 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 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 with which, as well as the order in which parallel LFBs can be
assembled. assembled.
To access the parallelization details, we opted for defining a new To access the parallelization details, we opted for defining a new
LFB class - the CoreParallelization LFB. This choice was an LFB class: the CoreParallelization LFB. This choice was an
alternative to making another change to the core FEObject LFB. The alternative to making another change to the core FEObject LFB. The
CoreParallelization exists merely to define the capabilities for an CoreParallelization exists merely to define the capabilities for an
FE's LFB parallelization. A CE using the ForCES Protocol [RFC5810] FE's LFB parallelization. A CE using the ForCES protocol [RFC5810]
can check the existence of this LFB class in the FEObject's can check the existence of this LFB class in the FEObject's
SupportedLFBs component. The existence of the CoreParallelization SupportedLFBs component. The existence of the CoreParallelization
LFB will indicate to the CE that the specific FE supports LFB will indicate to the CE that the specific FE supports
parallelization. There MUST be only one instance of the parallelization. There MUST be only one instance of the
CoreParallelization LFB per FE. CoreParallelization LFB per FE.
The topology of the parallel datapath can be deferred and manipulated The topology of the parallel datapath can be deferred and manipulated
from the FEObject LFB's LFBTopology. from the FEObject LFB's LFBTopology.
The CoreParallelization requires only one capability in order to The CoreParallelization requires only one capability in order to
skipping to change at page 7, line 33 skipping to change at page 8, line 33
o A list of LFB classes that can follow this LFB class in a pipeline o A list of LFB classes that can follow this LFB class in a pipeline
for a parallel path. for a parallel path.
o A list of LFB classes that can exist before this LFB class in a o A list of LFB classes that can exist before this LFB class in a
pipeline for a parallel path. pipeline for a parallel path.
o A list of LFB classes that can process packets or chunks in o A list of LFB classes that can process packets or chunks in
parallel with this LFB class. parallel with this LFB class.
<!-- Datatype --> <!-- Datatype -->
<dataTypeDef> <dataTypeDef>
<name>ParallelLFBType</name> <name>ParallelLFBType</name>
<synopsis>Table entry for parallel LFBs</synopsis> <synopsis>Table entry for parallel LFBs</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>LFBName</name> <name>LFBName</name>
<synopsis>The name of an LFB Class</synopsis> <synopsis>The name of an LFB Class</synopsis>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>LFBClassID</name> <name>LFBClassID</name>
<synopsis>The id of the LFB Class</synopsis> <synopsis>The id of the LFB Class</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>LFBVersion</name> <name>LFBVersion</name>
<synopsis>The version of the LFB Class used by this FE <synopsis>The version of the LFB Class used by this FE
</synopsis> </synopsis>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</component> </component>
<component componentID="4"> <component componentID="4">
<name>LFBParallelOccurrenceLimit</name> <name>LFBParallelOccurrenceLimit</name>
<synopsis>The upper limit of instances of the same <synopsis>The upper limit of instances of the same
parallel LFBs of this class</synopsis> parallel LFBs of this class</synopsis>
<optional /> <optional />
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="5"> <component componentID="5">
<name>AllowedParallelAfters</name> <name>AllowedParallelAfters</name>
<synopsis>List of LFB Classes that can follow this LFB <synopsis>List of LFB Classes that can follow this LFB
in a parallel pipeline</synopsis> in a parallel pipeline</synopsis>
<optional /> <optional />
<array> <array>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</array> </array>
</component> </component>
<component componentID="6"> <component componentID="6">
<name>AllowedParallelBefores</name> <name>AllowedParallelBefores</name>
<synopsis>List of LFB Classes that this LFB class can <synopsis>List of LFB Classes that this LFB class can
follow in a parallel pipeline</synopsis> follow in a parallel pipeline</synopsis>
<optional /> <optional />
<array> <array>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</array> </array>
</component> </component>
<component componentID="7"> <component componentID="7">
<name>AllowedParallel</name> <name>AllowedParallel</name>
<synopsis>List of LFB Classes that this LFB class be run <synopsis>List of LFB Classes that this LFB class can run
in parallel with</synopsis> in parallel with</synopsis>
<array> <array>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</array> </array>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<!-- Capability --> <!-- Capability -->
<capability componentID="32"> <capability componentID="32">
<name>ParallelLFBs</name> <name>ParallelLFBs</name>
<synopsis>List of all supported parallel LFBs</synopsis> <synopsis>List of all supported parallel LFBs</synopsis>
<array type="Variable-size"> <array type="Variable-size">
<typeRef>ParallelLFBType</typeRef> <typeRef>ParallelLFBType</typeRef>
</array> </array>
</capability> </capability>
Figure 3: XML Definitions for CoreParallelization LFB Figure 3: XML Definitions for CoreParallelization LFB
2.2. Parallelization metadata 2.2. Parallelization Metadata
It is expected that the splitting and merging mechanisms are an It is expected that the splitting and merging mechanisms are an
implementation issue. This document plays the role of defining the implementation issue. This document plays the role of defining the
operational parameters for the splitting and merging, namely, the operational parameters for the splitting and merging: namely, the
size of the chunks, what happens if a packet or chunk has been marked 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 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: chunks to arrive. The following metadata set is defined as a struct:
1. ParallelType - Flood or split 1. ParallelType - Flood or split
2. TaskCorrelator - Identify packets or chunks that belonged to the 2. TaskCorrelator - Identify packets or chunks that belonged to the
initial packet that entered the Splitter LFB initial packet that entered the Splitter LFB
3. ParallelNum - Sequence Number of the packet or the chunk for a 3. ParallelNum - Sequence number of the packet or the chunk for a
specific task. specific task
4. ParralelPartsCount - Total number of packets or chunks for a 4. ParallelPartsCount - Total number of packets or chunks for a
specific task. specific task
This metadata is produced from the Splitter LFB and is opaque to LFBs This metadata is produced from the Splitter LFB, is opaque to LFBs in
in parallel paths and is passed along to the merger LFB without being parallel paths, and is passed along to the Merger LFB without being
consumed. consumed.
In the case in which an LFB decides that a packet/chunk has to be 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 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. sent to the Merger LFB's InvalidIn input port for merging purposes.
Additional metadata produced by LFBs inside a datapath MAY be Additional metadata produced by LFBs inside a datapath MAY be
aggregated within the Merger LFB and sent on after the merging aggregated within the Merger LFB and sent on after the merging
process. In case of receiving the same metadata definition with process. In case of receiving the same metadata definition with
multiple values the merger LFB MUST keep the first received from a multiple values, the Merger LFB MUST keep the first received from a
valid packet or chunk. valid packet or chunk.
3. Parallel Base Types 3. Parallel Base Types
3.1. Frame Types 3.1. Frame Types
One frame type has been defined in this library. One frame type has been defined in this library.
+---------------+---------------------------------------------------+ +-----------+-------------------------------------------------------+
| Frame Type | Synopsis | | Frame | Synopsis |
| Name | | | Name | |
+---------------+---------------------------------------------------+ +-----------+-------------------------------------------------------+
| Chunk | A chunk is a frame that is part of an original | | Chunk | A chunk is a frame that is part of an original larger |
| | larger frame | | | frame. |
+---------------+---------------------------------------------------+ +-----------+-------------------------------------------------------+
Parallel Frame Types Parallel Frame Types
3.2. Data Types 3.2. Data Types
One data type has been defined in this library. One data type has been defined in this library.
+---------------+------------------------+--------------------------+ +---------------+------------------------+--------------------------+
| DataType Name | Type | Synopsis | | DataType Name | Type | Synopsis |
+---------------+------------------------+--------------------------+ +---------------+------------------------+--------------------------+
| ParallelTypes | Atomic uchar. Special | The type of | | ParallelTypes | Atomic uchar. Special | The type of |
| | Values Flood (0), | parallelization this | | | Values Flood (0), | parallelization this |
| | Split (1). | packet will go through | | | Split (1). | packet will go through. |
+---------------+------------------------+--------------------------+ +---------------+------------------------+--------------------------+
Parallel Data Types Parallel Data Types
3.3. MetaData Types 3.3. Metadata Types
The following metadata structure with ID 16, using the ForCES model The following metadata structure with ID 16, using the ForCES model
extension [I-D.ietf-forces-model-extension], is defined for the extension [RFC7408], is defined for the parallelization library:
parallelization library:
+--------------------+--------+----+--------------------------------+ +--------------------+--------+----+--------------------------------+
| Metadata Name | Type | ID | Synopsis | | Metadata Name | Type | ID | Synopsis |
+--------------------+--------+----+--------------------------------+ +--------------------+--------+----+--------------------------------+
| ParallelType | uchar | 1 | The type of parallelization | | ParallelType | uchar | 1 | The type of parallelization |
| | | | this packet will go through. 0 | | | | | this packet will go through. 0 |
| | | | for flood, 1 for split. | | | | | for flood, 1 for split. |
| | | | | | | | | |
| TaskCorrelator | uint32 | 2 | An identification number to | | TaskCorrelator | uint32 | 2 | An identification number to |
| | | | specify that a packet or a | | | | | specify that a packet or a |
| | | | chunks belongs to the same | | | | | chunk belongs to the same |
| | | | parallel task. | | | | | parallel task. |
| | | | | | | | | |
| ParallelNum | uint32 | 3 | Defines the number of a | | ParallelNum | uint32 | 3 | Defines the number of a |
| | | | specific packet or chunk of a | | | | | specific packet or chunk of a |
| | | | specific task. | | | | | specific task. |
| | | | | | | | | |
| ParallelPartsCount | uint32 | 4 | Defines the total number of | | ParallelPartsCount | uint32 | 4 | Defines the total number of |
| | | | packets or chunks for a | | | | | packets or chunks for a |
| | | | specific task. | | | | | specific task. |
+--------------------+--------+----+--------------------------------+ +--------------------+--------+----+--------------------------------+
Metadata Structure for Merging Metadata Structure for Merging
4. Parallel LFBs 4. Parallel LFBs
4.1. Splitter 4.1. Splitter
The splitter LFB takes part in parallelizing the processing datapath The Splitter LFB takes part in parallelizing the processing datapath
by sending either the same packet Figure 2 or chunks Figure 1 of the by sending either the same packet (Figure 2) or chunks (Figure 1) of
same packet to multiple LFBs. the same packet to multiple LFBs.
+---------------+ +---------------+
SplitterIn | | SplitterOut SplitterIn | | SplitterOut
---------->| Splitter LFB |-------------> ---------->| Splitter LFB |------------->
| | | |
+---------------+ +---------------+
Figure 4: Splitter LFB Figure 4: Splitter LFB
4.1.1. Data Handling 4.1.1. Data Handling
The splitter LFB receives any kind of packet via the singleton input, The Splitter LFB receives any kind of packet via the singleton input,
Input. Depending upon the CE's configuration of the ParallelType Input. Depending upon the CE's configuration of the ParallelType
component, if the parallel type is of type flood (0), the same packet component, if the parallel type is of type flood (0), the same packet
MUST be sent through all of the group output SplitterOut's instances. MUST be sent through all instances of the group output "SplitterOut".
If the parallel type is of type split (1), the packet will be split If the parallel type is of type split (1), then the packet will be
into same size chunks except the last which MAY be smaller, with the split into same size chunks except for the last, which MAY be
max size being defined by the ChunkSize component. Chunks MAY be smaller, with the max size being defined by the ChunkSize component.
sent out in a round-robin fashion through the group output Chunks MAY be sent out in a round-robin fashion through instances of
ParallelOut's instances or in any other way defined by the the group output "ParallelOut" or in any other way defined by the
implementer. Each packet or chunk will be accompanied by the implementer. Each packet or chunk will be accompanied by the
following metadata set as a struct: following metadata set as a struct:
o ParallelType - The parallel type, split or flood. o ParallelType - The parallel type: split or flood.
o ParallelID - generated by the splitter LFB to identify that chunks o ParallelID - Generated by the Splitter LFB to identify which
or packets belong to the same parallel task. chunks or packets belong to the same parallel task.
o ParallelNum - each chunk or packet of a parallel id will be o 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 assigned a number in order for the Merger LFB to know when it has
gathered them all along with the ParallelPartsCount metadata. gathered them all along with the ParallelPartsCount metadata.
o ParallelPartsCount - the number of chunks or packets for the o ParallelPartsCount - The number of chunks or packets for the
specific task. specific task.
4.1.2. Components 4.1.2. Components
The splitter LFB has only two components. The first is the The Splitter LFB has only two components. The first is the
ParallelType, an uint32 that defines how the packet will be processed ParallelType, a uint32 that defines how the packet will be processed
by the Splitter LFB. The second is the ChunkSize, an uint32 that 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 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 same-size chunks. The last chunk MAY be smaller than the value of
the ChunkSize. the ChunkSize.
4.1.3. Capabilities 4.1.3. Capabilities
This LFB has only one capability specified, the MinMaxChunkSize a This LFB has only one capability specified; the MinMaxChunkSize is a
struct of two uint32 to specify the minimum and maximum chunk size. struct of two uint32s to specify the minimum and maximum chunk size.
4.1.4. Events 4.1.4. Events
This LFB has no events specified. This LFB has no events specified.
4.2. Merger 4.2. Merger
The merger LFB is the synchronization point for multiple packets or The Merger LFB is the synchronization point for multiple packets or
packet chunks of the same task, emanating out of the parallel path as packet chunks of the same task emanating out of the parallel path, as
illustrated in Figure 2 and Figure 1. illustrated in Figure 1 and Figure 2.
+-------------+ +-------------+
MergerIn | | MergerIn | |
--------->| | MergerOut --------->| | MergerOut
| Merger LFB |-----------> | Merger LFB |----------->
InvalidIn | | InvalidIn | |
--------->| | --------->| |
+-------------+ +-------------+
Figure 5: Merger LFB Figure 5: Merger LFB
4.2.1. Data Handling 4.2.1. Data Handling
The merger LFB receives either a packet or a chunk via the group The Merger LFB receives either a packet or a chunk via the group
input ParallelIn, along with the ParallelType metadata that, the input ParallelIn, along with the ParallelType metadata, the
TaskCorrelator, the ParallelNum and the ParallelPartsCount. TaskCorrelator, the ParallelNum, and the ParallelPartsCount.
In case that an upstream LFB has dropped a packet or a chunk the In the case in which an upstream LFB has dropped a packet or a chunk,
merger LFB MAY receive only the metadata or both metadata and packet the Merger LFB MAY receive only the metadata, both the metadata and
or chunk through the InvalidIn group input port. It SHOULD receive a the packet, or the chunk through the InvalidIn group input port. It
metadata specifying the error code. Currently defined metadata's in SHOULD receive a metadata specifying the error code. Currently
the Base LFB Library [RFC6956] are the ExceptionID and the defined metadata in the Base LFB Library [RFC6956] are the
ValidateErrorID. ExceptionID and the ValidateErrorID.
If the MergeWaitType is set to false the Merger LFB will initiate the If the MergeWaitType is set to false, the Merger LFB will initiate
merge process upon receiving the first packet. If false, for each the merge process upon receiving the first packet. If false, for
task identified by the task correlator, it will wait for all packets/ each task identified by the task correlator, it will wait for all
chunks to arrive unless the MergeWaitTimeoutTimer timer expires. If packets/chunks to arrive unless the MergeWaitTimeoutTimer timer
the MergeWaitTimeoutTimer has expired, the Merger MUST consider the expires. If the MergeWaitTimeoutTimer has expired, the Merger MUST
rest of the packets/chuncks, that have not been received, as invalid consider the rest of the packets/chunks that have not been received
and MUST handle the packets according to the InvalidAction value. 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 If one packet or chunk has been received through the InvalidIn port,
then the merging procedure will handle the packets/chuncks according then the merging procedure will handle the packets/chunks according
to the InvalidAction value. If the InvalidAction component has been to the InvalidAction value. If the InvalidAction component has been
set to 0 then if one packet or chunk is not valid all will dropped, set to 0, then if one packet or chunk is not valid, all will be
else the process will initiate. Once the merging process has been dropped or else the process will initiate. Once the merging process
completed the resulting packet will be sent via the singleton output has been completed, the resulting packet will be sent via the
port MergerOut. singleton output port MergerOut.
If the Merger LFB receives different values for the same metadata If the Merger LFB receives different values for the same metadata
from different packets or chunks that has the same task correlator from different packets or chunks that have the same task correlator,
then the Merger LFB will use the first metadata from a packet or then the Merger LFB will use the first metadata from a packet or
chunk that entered the LFB through the MergerIn input port. chunk that entered the LFB through the MergerIn input port.
4.2.2. Components 4.2.2. Components
This LFB has the following components specified: This LFB has the following components specified:
1. InvalidAction - a uchar defining what the Merge LFB will do if an 1. InvalidAction: A uchar defining what the Merge LFB will do if an
invalid chunk or packet is received. If set to 0 (DropAll) the invalid chunk or packet is received. If set to 0 (DropAll), the
merge will be considered invalid and all chunks or packets will merge will be considered invalid and all chunks or packets will
be dropped. If set to 1 (Continue) the merge will continue. be dropped. If set to 1 (Continue), the merge will continue.
2. MergeWaitTimeoutTimer - a uint32 defining the amount of time, in 2. MergeWaitTimeoutTimer: A uint32 defining the amount of time, in
milliseconds, that the Merger will wait for all packets or milliseconds, that the Merger will wait for all packets or chunks
chuncks within the same task to arrive before considering them within the same task to arrive before considering them invalid.
invalid. The MergeWaitTimeoutTimer starts as soon as the first The MergeWaitTimeoutTimer starts as soon as the first chunk or
chunk or packet of a parallel task arrives. packet of a parallel task arrives.
3. MergeWaitType - a boolean. If true the Merger LFB will wait for 3. MergeWaitType: A boolean. If true, the Merger LFB will wait for
all packets or chunks to be received prior to performing the all packets or chunks to be received prior to performing the
merge. If false, when one packet or a chunk with a response is 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. received by the merge LFB, it will start with the merge process.
4. InvalidMergesCounter - a uint32 that counts the number of merges 4. InvalidMergesCounter: A uint32 that counts the number of merges
where there is at least one packet or chunk that entered the where there is at least one packet or chunk that entered the
merger LFB through the InvalidIn input port. Merger LFB through the InvalidIn input port.
5. InvalidTotalCounter - a uint32 that counts the number of merges 5. InvalidTotalCounter: A uint32 that counts the number of merges
where all packets/chunks entered the merger LFB through the where all packets/chunks entered the Merger LFB through the
InvalidIn input port. InvalidIn input port.
6. InvalidIDCounters - a struct of two arrays. Each array has a 6. InvalidIDCounters: A struct of two arrays. Each array has a
uint32 per row. Each array counts number of invalid merges where uint32 per row. Each array counts the number of invalid merges
at least one packet or chunk entered through InvalidID per error where at least one packet or chunk entered through InvalidID per
ID. The first array is the InvalidExceptionID and the second is error ID. The first array is the InvalidExceptionID and the
the InvalidValidateErrorID. second is the InvalidValidateErrorID.
4.2.3. Capabilities 4.2.3. Capabilities
This LFB has no capabilities specified. This LFB has no capabilities specified.
4.2.4. Events 4.2.4. Events
This LFB specifies only two event. The first detects whether the This LFB specifies only two events. The first detects whether the
InvalidMergesCounter has exceeded a specific value and the second InvalidMergesCounter has exceeded a specific value, and the second
detects whether the InvalidAllCounter has exceeded a specific value. detects whether the InvalidAllCounter has exceeded a specific value.
Both error reports will send the respective counter value. Event Both error reports will send the respective counter value. Event
Filters can be used to limit the number of messages Filters can be used to limit the number of messages
4.3. CoreParallelization 4.3. CoreParallelization
A core LFB that specifies that the FE supports parallelization, A core LFB that specifies that the FE supports parallelization
instead of updating the FEObject LFB instead of updating the FEObject LFB
4.3.1. Data Handling 4.3.1. Data Handling
The CoreParallelization does not handle data. The CoreParallelization does not handle data.
4.3.2. Components 4.3.2. Components
This LFB has no components specified. This LFB has no components specified.
4.3.3. Capabilities 4.3.3. Capabilities
This LFB has only one capability specified. The ParallelLFBs is a This LFB has only one capability specified. The ParallelLFBs is a
table which lists all the LFBs that can be parallelized. Each row of table which lists all the LFBs that can be parallelized. Each row of
the table contains: the table contains:
1. LFBName - a string. The Name of the parallel LFB. 1. LFBName: A string. The Name of the parallel LFB.
2. LFBClassID - a uint32. The Class ID of the parallel LFB. 2. LFBClassID: A uint32. The Class ID of the parallel LFB.
3. LFBVersion - a string. The Version of the parallel LFB. 3. LFBVersion: A string. The Version of the parallel LFB.
4. LFBParallelOccurrenceLimit - a uint32. The upper limit of 4. LFBParallelOccurrenceLimit: A uint32. The upper limit of
instances of the same parallel LFBs of this class. instances of the same parallel LFBs of this class.
5. AllowedParallelAfters - a table of uint32s (LFB Class IDs). A 5. AllowedParallelAfters: A table of uint32s (LFB Class IDs). A
list of LFB classes that can follow this LFB class in a pipeline list of LFB classes that can follow this LFB class in a pipeline
for a parallel path. for a parallel path.
6. AllowedParallelBefores - a table of uint32s (LFB Class IDs). A 6. AllowedParallelBefores: A table of uint32s (LFB Class IDs). A
list of LFB classes that can exist before this LFB class in a list of LFB classes that can exist before this LFB class in a
pipeline for a parallel path. pipeline for a parallel path.
7. AllowedParallel - a table of uint32s (LFB Class IDs). A list of 7. AllowedParallel: A table of uint32s (LFB Class IDs). A list of
LFB classes that can process packets or chunks in parallel with LFB classes that can process packets or chunks in parallel with
this LFB class. this LFB class.
4.3.4. Events 4.3.4. Events
This LFB specifies no events This LFB specifies no events.
5. XML for Parallel LFB library 5. XML for Parallel LFB Library
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.1" <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:forces:lfbmodel:1.1" xsi:schemaLocation="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
provides="Parallel"> provides="Parallel">
<load library="BaseTypeLibrary" location="BaseTypeLibrary.LFB"/> <load library="BaseTypeLibrary" location="BaseTypeLibrary.LFB"/>
<frameDefs> <frameDefs>
<frameDef> <frameDef>
<name>Chunk</name> <name>Chunk</name>
skipping to change at page 16, line 49 skipping to change at page 18, line 4
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>ParallelLFBType</name> <name>ParallelLFBType</name>
<synopsis>Table entry for parallel LFBs</synopsis> <synopsis>Table entry for parallel LFBs</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>LFBName</name> <name>LFBName</name>
<synopsis>The name of an LFB Class</synopsis> <synopsis>The name of an LFB Class</synopsis>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>LFBClassID</name> <name>LFBClassID</name>
<synopsis>The id of the LFB Class</synopsis> <synopsis>The ID of the LFB Class</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>LFBVersion</name> <name>LFBVersion</name>
<synopsis>The version of the LFB Class used by this FE <synopsis>The version of the LFB Class used by this FE
</synopsis> </synopsis>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</component> </component>
<component componentID="4"> <component componentID="4">
<name>LFBParallelOccurrenceLimit</name> <name>LFBParallelOccurrenceLimit</name>
skipping to change at page 17, line 30 skipping to change at page 18, line 35
<name>AllowedParallelAfters</name> <name>AllowedParallelAfters</name>
<synopsis>List of LFB Classes that can follow this LFB <synopsis>List of LFB Classes that can follow this LFB
in a parallel pipeline</synopsis> in a parallel pipeline</synopsis>
<optional/> <optional/>
<array> <array>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</array> </array>
</component> </component>
<component componentID="6"> <component componentID="6">
<name>AllowedParallelBefores</name> <name>AllowedParallelBefores</name>
<synopsis>List of LFB Classes that this LFB class can <synopsis>List of LFB Classes that this LFB Class can
follow in a parallel pipeline</synopsis> follow in a parallel pipeline</synopsis>
<optional/> <optional/>
<array> <array>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</array> </array>
</component> </component>
<component componentID="7"> <component componentID="7">
<name>AllowedParallel</name> <name>AllowedParallel</name>
<synopsis>List of LFB Classes that this LFB class be run <synopsis>List of LFB Classes that this LFB Class can be run
in parallel with</synopsis> in parallel with</synopsis>
<array> <array>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</array> </array>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
</dataTypeDefs> </dataTypeDefs>
<metadataDefs> <metadataDefs>
<metadataDef> <metadataDef>
<name>ParallelMetadataSet</name> <name>ParallelMetadataSet</name>
<synopsis>A metadata Set for parallelization related LFBs <synopsis>A metadata set for parallelization-related LFBs
</synopsis> </synopsis>
<metadataID>32</metadataID> <metadataID>32</metadataID>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>ParallelType</name> <name>ParallelType</name>
<synopsis>The type of parallelization this packet/chunk <synopsis>The type of parallelization this packet/chunk
has gone through</synopsis> has gone through</synopsis>
<typeRef>ParallelTypes</typeRef> <typeRef>ParallelTypes</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
skipping to change at page 18, line 38 skipping to change at page 19, line 42
<synopsis>Defines the total number of packets or chunks <synopsis>Defines the total number of packets or chunks
for the specific parallel ID.</synopsis> for the specific parallel ID.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</metadataDef> </metadataDef>
</metadataDefs> </metadataDefs>
<LFBClassDefs> <LFBClassDefs>
<LFBClassDef LFBClassID="65537"> <LFBClassDef LFBClassID="65537">
<name>Ext-Splitter</name> <name>Ext-Splitter</name>
<synopsis>A splitter LFB takes part in parallelizing the <synopsis>A Splitter LFB takes part in parallelizing the
processing datapath. It will either send the same packet processing datapath. It will either send the same packet
or chunks of one packet to multiple LFBs</synopsis> or chunks of one packet to multiple LFBs</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>SplitterIn</name> <name>SplitterIn</name>
<synopsis>An input port expecting any kind of frame <synopsis>An input port expecting any kind of frame
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
skipping to change at page 19, line 4 skipping to change at page 20, line 8
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>SplitterIn</name> <name>SplitterIn</name>
<synopsis>An input port expecting any kind of frame <synopsis>An input port expecting any kind of frame
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</frameExpected> </frameExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="true"> <outputPort group="true">
<name>SplitterOut</name> <name>SplitterOut</name>
<synopsis>A parallel output port that sends the same <synopsis>A parallel output port that sends the same
packet to all output instances or chunks of the same packet to all output instances or chunks of the same
packet different chunk on each instance.</synopsis> packet to output instances. Each chunk is sent only
once by the LFB.</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
<ref>Chunk</ref> <ref>Chunk</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ParallelMetadataSet</ref> <ref>ParallelMetadataSet</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
skipping to change at page 19, line 34 skipping to change at page 20, line 38
<components> <components>
<component componentID="1" access="read-write"> <component componentID="1" access="read-write">
<name>ParallelType</name> <name>ParallelType</name>
<synopsis>The type of parallelization this packet will <synopsis>The type of parallelization this packet will
go through</synopsis> go through</synopsis>
<typeRef>ParallelTypes</typeRef> <typeRef>ParallelTypes</typeRef>
</component> </component>
<component componentID="2" access="read-write"> <component componentID="2" access="read-write">
<name>ChunkSize</name> <name>ChunkSize</name>
<synopsis>The size of a chunk when a packet is split <synopsis>The size of a chunk when a packet is split
into multiple same size chunks</synopsis> into multiple chunks of the same size</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</components> </components>
<capabilities> <capabilities>
<capability componentID="31"> <capability componentID="31">
<name>MinMaxChunkSize</name> <name>MinMaxChunkSize</name>
<synopsis>The minimum and maximum size of a chunk <synopsis>The minimum and maximum size of a chunk
capable of split by this LFB</synopsis> capable of split by this LFB</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
skipping to change at page 20, line 12 skipping to change at page 21, line 17
<name>MaxChunkSize</name> <name>MaxChunkSize</name>
<synopsis>Maximum chunk size</synopsis> <synopsis>Maximum chunk size</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</capability> </capability>
</capabilities> </capabilities>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="65538"> <LFBClassDef LFBClassID="65538">
<name>Ext-Merger</name> <name>Ext-Merger</name>
<synopsis>A merger LFB receives multiple packets or multiple <synopsis>A Merger LFB receives multiple packets or multiple
chunks of the same packet and merge them into one merged chunks of the same packet and merge them into one merged
packet</synopsis> packet</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="true"> <inputPort group="true">
<name>MergerIn</name> <name>MergerIn</name>
<synopsis>A parallel input port that accepts packets <synopsis>A parallel input port that accepts packets
or chunks from all output instances</synopsis> or chunks from all output instances</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
skipping to change at page 20, line 34 skipping to change at page 21, line 39
<ref>Chunk</ref> <ref>Chunk</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>ParallelMetadataSet</ref> <ref>ParallelMetadataSet</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
<inputPort group="true"> <inputPort group="true">
<name>InvalidIn</name> <name>InvalidIn</name>
<synopsis>When a packet is sent out of an error port of <synopsis>When a packet is sent out of an error port of
an LFB in a parallel path will be sent to this an LFB in a parallel path, it will be sent to this
output port in the Merger LFB</synopsis> output port in the Merger LFB</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
<ref>Chunk</ref> <ref>Chunk</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<one-of> <one-of>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
<ref>ValidateErrorID</ref> <ref>ValidateErrorID</ref>
skipping to change at page 21, line 44 skipping to change at page 22, line 50
<component componentID="2" access="read-write"> <component componentID="2" access="read-write">
<name>MergeWaitType</name> <name>MergeWaitType</name>
<synopsis>Whether the Merge LFB will wait for all <synopsis>Whether the Merge LFB will wait for all
packets or chunks to be received prior to sending packets or chunks to be received prior to sending
out a response</synopsis> out a response</synopsis>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
</component> </component>
<component componentID="3" access="read-write"> <component componentID="3" access="read-write">
<name>MergeWaitTimeoutTimer</name> <name>MergeWaitTimeoutTimer</name>
<synopsis>The time that the Merger will wait <synopsis>The time that the Merger will wait
for all packets or chuncks within the same task to arrive for all packets or chunks within the same task to arrive
before considering them invalid.</synopsis> before considering them invalid.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="4" access="read-reset"> <component componentID="4" access="read-reset">
<name>InvalidMergesCounter</name> <name>InvalidMergesCounter</name>
<synopsis>Counts the number of merges where there is at <synopsis>Counts the number of merges where there is at
least one packet/chunk that entered the merger LFB least one packet/chunk that entered the Merger LFB
through the InvalidIn input port</synopsis> through the InvalidIn input port</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="5" access="read-reset"> <component componentID="5" access="read-reset">
<name>InvalidTotalCounter</name> <name>InvalidTotalCounter</name>
<synopsis>Counts the number of merges where all <synopsis>Counts the number of merges where all
packets/chunks entered the merger LFB through the packets/chunks entered the Merger LFB through the
InvalidIn input port</synopsis> InvalidIn input port</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="6" access="read-reset"> <component componentID="6" access="read-reset">
<name>InvalidIDCounters</name> <name>InvalidIDCounters</name>
<synopsis>Counts number of invalid merges where at <synopsis>Counts the number of invalid merges where at
least one packet/chunk entered through InvalidID per least one packet/chunk entered through InvalidID per
error ID</synopsis> error ID</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>InvalidExceptionID</name> <name>InvalidExceptionID</name>
<synopsis>Per Exception ID</synopsis> <synopsis>Per Exception ID</synopsis>
<array> <array>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</array> </array>
</component> </component>
skipping to change at page 23, line 23 skipping to change at page 24, line 28
<eventReport> <eventReport>
<eventField>InvalidTotalCounter</eventField> <eventField>InvalidTotalCounter</eventField>
</eventReport> </eventReport>
</eventReports> </eventReports>
</event> </event>
</events> </events>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="65539"> <LFBClassDef LFBClassID="65539">
<name>Ext-CoreParallelization</name> <name>Ext-CoreParallelization</name>
<synopsis>A core LFB that specifies that the FE supports <synopsis>A core LFB that specifies that the FE supports
parallelization, instead of updating the FEObject parallelization instead of updating the FEObject
LFB</synopsis> LFB</synopsis>
<version>1.0</version> <version>1.0</version>
<capabilities> <capabilities>
<capability componentID="10"> <capability componentID="10">
<name>ParallelLFBs</name> <name>ParallelLFBs</name>
<synopsis>A table which lists all the LFBs that can be <synopsis>A table that lists all the LFBs that can be
parallelized</synopsis> parallelized</synopsis>
<array> <array>
<typeRef>ParallelLFBType</typeRef> <typeRef>ParallelLFBType</typeRef>
</array> </array>
</capability> </capability>
</capabilities> </capabilities>
</LFBClassDef> </LFBClassDef>
</LFBClassDefs> </LFBClassDefs>
</LFBLibrary> </LFBLibrary>
Figure 6: Parallel LFB library Figure 6: Parallel LFB Library
6. Acknowledgments
The authors would like to thank Edward Crabbe for the initial
discussion that led to the creation of this document and Jamal Hadi
Salim and Dave Hood for comments and discussions that made this
document better. Additionally Adrian Farrel for his AD review.
Finally Francis Dupont for his Gen-Art review and Magnus Nystroem for
his security review which refined this document to its final shape.
7. IANA Considerations 6. IANA Considerations
7.1. LFB Class Names and LFB Class Identifiers 6.1. LFB Class Names and LFB Class Identifiers
LFB classes defined by this document do not belong to LFBs defined by LFB classes defined by this document do not belong to LFBs defined by
Standards Track RFCs in the http://www.iana.org/assignments/forces Standards Action. As such, the corresponding values assigned in the
registry. As such the values defined in this document are in the "Logical Functional Block (LFB) Class Names and Class Identifiers"
above 65535 value range. registry at <http://www.iana.org/assignments/forces> are above 65535.
This specification includes the following LFB class names and LFB This specification includes the following LFB class names and LFB
class identifiers: class identifiers:
+----------+--------------------+--------+---------------+----------+ +-------+---------------------+-------+-----------------+---------+
| LFB | LFB Class Name | LFB Ve | Description | Referenc | | LFB | LFB Class Name | LFB | Description | Ref |
| Class Id | | rsion | | e | | Class | |Version| | |
| entifier | | | | | | ID | | | | |
+----------+--------------------+--------+---------------+----------+ +-------+---------------------+-------+-----------------+---------+
| 65537 | Ext-Splitter | 1.0 | A splitter | This | | 65537 | Ext-Splitter | 1.0 | A Splitter LFB | RFC |
| | | | LFB will | document | | | | | will send | 7409 |
| | | | either send | | | | | |either the same | |
| | | | the same | | | | | | packet or | |
| | | | packet or | | | | | | chunks of one | |
| | | | chunks of one | | | | | | packet to | |
| | | | packet to | | | | | | multiple LFBs. | |
| | | | multiple | | +-------+---------------------+-------+-----------------+---------+
| | | | LFBs. | | | 65538 | Ext-Merger | 1.0 | A Merger LFB | RFC |
| | | | | | | | | | receives | 7409 |
| 65538 | Ext-Merger | 1.0 | A merger LFB | This | | | | | multiple | |
| | | | receives | document | | | | | packets or | |
| | | | multiple | | | | | | multiple | |
| | | | packets or | | | | | | chunks of the | |
| | | | multiple | | | | | | same packet | |
| | | | chunks of the | | | | | | and merges | |
| | | | same packet | | | | | | them into one. | |
| | | | and merge | | +-------+---------------------+-------+-----------------+---------+
| | | | them into | | | 65539 | Ext- | 1.0 | A core LFB to | RFC |
| | | | one. | | | | CoreParallelization | | signify the | 7409 |
| | | | | | | | | | parallelization | |
| 65539 | Ext-CoreParalleliz | 1.0 | A core LFB to | This | | | | | capability | |
| | ation | | signify the p | document | +-------+---------------------+-------+-----------------+---------+
| | | | arallelizatio | |
| | | | n capability | |
+----------+--------------------+--------+---------------+----------+
Logical Functional Block (LFB) Class Names and Class Identifiers Logical Functional Block (LFB) Class Names and Class Identifiers
7.2. Metadata ID 6.2. Metadata ID
The Metadata ID namespace is 32 bits long. Values assigned by this The Metadata ID namespace is 32-bits long. Values assigned by this
specification are: specification are:
+------------+---------------------+---------------+ +------------+---------------------+-----------+
| Value | Name | Definition | | Value | Name | Reference |
+------------+---------------------+---------------+ +------------+---------------------+-----------+
| 0x00000010 | ParallelMetadataSet | This document | | 0x00000010 | ParallelMetadataSet | RFC 7409 |
+------------+---------------------+---------------+ +------------+---------------------+-----------+
Metadata ID assigned by this specification Metadata ID Assigned by this Specification
8. Security Considerations 7. Security Considerations
This document does not alter either the ForCES model [RFC5812] or the This document does not alter either the ForCES model [RFC5812] or the
ForCES protocol [RFC5810] and as such has no impact on their security ForCES protocol [RFC5810]. As such, it has no impact on their
considerations. This document simply defines the operational security considerations. This document simply defines the
parameters and capabilities of LFBs that perform parallelization and operational parameters and capabilities of LFBs that perform
not how parallelization is implemented. Finally, this document does parallelization and not how parallelization is implemented. Finally,
not attempt to analyze the presence or possibility of security this document does not attempt to analyze the presence or possibility
interactions created by allowing parallel operations on packets. Any of security interactions created by allowing parallel operations on
such issues, if they exist, are for the designers of the particular packets. Any such issues, if they exist, are for the designers of
data path, not the general mechanism. the particular data path, not the general mechanism.
9. References
9.1. Normative References 8. References
[I-D.ietf-forces-model-extension] 8.1. Normative References
Haleplidis, E., "ForCES Model Extension", draft-ietf-
forces-model-extension-05 (work in progress), September
2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Control Element Separation (ForCES) Protocol Control Element Separation (ForCES) Protocol
Specification", RFC 5810, March 2010. Specification", RFC 5810, March 2010,
<http://www.rfc-editor.org/info/rfc5810>.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model", RFC Element Separation (ForCES) Forwarding Element Model", RFC
5812, March 2010. 5812, March 2010,
<http://www.rfc-editor.org/info/rfc5812>.
[RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. [RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
Halpern, "Forwarding and Control Element Separation Halpern, "Forwarding and Control Element Separation
(ForCES) Logical Function Block (LFB) Library", RFC 6956, (ForCES) Logical Function Block (LFB) Library", RFC 6956,
June 2013. June 2013, <http://www.rfc-editor.org/info/rfc6956>.
9.2. Informative References [RFC7408] Haleplidis, E., "Forwarding and Control Element Separation
(ForCES) Model Extension", RFC 7408, November 2014,
<http://www.rfc-editor.org/info/rfc7408>.
[Cilk] MIT, "Cilk language", 8.2. Informative References
[Cilk] Massachusetts Institute of Technology, "The Cilk Project",
<http://supertech.csail.mit.edu/cilk/>. <http://supertech.csail.mit.edu/cilk/>.
Acknowledgments
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.
Authors' Addresses Authors' Addresses
Evangelos Haleplidis Evangelos Haleplidis
University of Patras University of Patras
Department of Electrical and Computer Engineering Department of Electrical and Computer Engineering
Patras 26500 Patras 26500
Greece Greece
Email: ehalep@ece.upatras.gr EMail: ehalep@ece.upatras.gr
Joel Halpern Joel Halpern
Ericsson Ericsson
P.O. Box 6049 P.O. Box 6049
Leesburg VA 20178 Leesburg, VA 20178
USA United States
Phone: +1 703 371 3043 Phone: +1 703 371 3043
Email: joel.halpern@ericsson.com EMail: joel.halpern@ericsson.com
 End of changes. 133 change blocks. 
407 lines changed or deleted 401 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/