Internet Engineering Task Force E. Haleplidis
Internet-Draft University of Patras
Intended status: Standards Track J. Halpern
Expires: January 27, 2015 Ericsson
July 26, 2014
ForCES Packet Parallelization
draft-ietf-forces-packet-parallelization-01
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, so that control elements (CEs) can control the
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
document describes how ForCES can model a network device's
parallelization datapath.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 27, 2015.
Haleplidis & Halpern Expires January 27, 2015 [Page 1]
Internet-Draft ForCES Packet Parallelization July 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Packet Parallelization . . . . . . . . . . . . . . . . . . . 4
2.1. Core parallelization LFB . . . . . . . . . . . . . . . . 6
2.2. Parallelization metadata . . . . . . . . . . . . . . . . 8
3. Parallel Base Types . . . . . . . . . . . . . . . . . . . . . 9
3.1. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 9
4. Parallel LFBs . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Splitter . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Data Handling . . . . . . . . . . . . . . . . . . . . 10
4.1.2. Components . . . . . . . . . . . . . . . . . . . . . 11
4.1.3. Capabilities . . . . . . . . . . . . . . . . . . . . 11
4.1.4. Events . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Merger . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Data Handling . . . . . . . . . . . . . . . . . . . . 12
4.2.2. Components . . . . . . . . . . . . . . . . . . . . . 12
4.2.3. Capabilities . . . . . . . . . . . . . . . . . . . . 13
4.2.4. Events . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. CoreParallelization . . . . . . . . . . . . . . . . . . . 13
4.3.1. Data Handling . . . . . . . . . . . . . . . . . . . . 13
4.3.2. Components . . . . . . . . . . . . . . . . . . . . . 13
4.3.3. Capabilities . . . . . . . . . . . . . . . . . . . . 14
4.3.4. Events . . . . . . . . . . . . . . . . . . . . . . . 14
5. XML for Parallel LFB library . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 22
7.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 23
Haleplidis & Halpern Expires January 27, 2015 [Page 2]
Internet-Draft ForCES Packet Parallelization July 2014
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
A lot of network devices can process packets in a parallel manner.
The ForCES Model [RFC5812] 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 modelling concept has been influenced by Cilc [Cilc]. Cilc is a
programming language that has been developed since 1994 at the MIT
Laboratory to allow programmers to identify elements that can be
executed in parallel. The two Cilc concepts used in this document is
spawn and sync. Spawn being the place where parallel tasls can start
and sync being the place where the parallel task finishes and must
collect all parallel output.
As task, we define a grouping of packets or pieces of a packet
(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 the an
32-bit identifier named correlator.
1.1. Requirements Language
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 [RFC2119].
1.2. Definitions
This document follows the terminology defined by the ForCES Model in
[RFC5812]. In particular, the reader is expected to be familiar with
the following terms:
FE Model
LFB (Logical Functional Block) Class (or type)
LFB Instance
LFB Model
Haleplidis & Halpern Expires January 27, 2015 [Page 3]
Internet-Draft ForCES Packet Parallelization July 2014
Element
Attribute
LFB Metadata
ForCES Component
LFB Class Library
2. Packet Parallelization
This document addresses the following two types of packet
parallelization:
1. Flood - where a copy of a packet is sent to multiple LFBs to be
processed in parallel.
2. Split - where the packet will be split in equal size chunks
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 implementor may either decide to physical copy the packet
and send all packets on the parallel paths, or may decide to
logically copy the packet by simply sending for example pointers of
the same packet provided that the necessary interlocks are taken into
account. The implementor has to take into account the device's
characteristics to decide which approach fits best to the hardware.
Additionally in the split parallel type, while harder, the
implementor 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.
This document introduces two LFBs that are used in before and after
the parallelization occurs:
1. Splitter - similar to Cilc's spawn. An LFB that will split the
path of a packet and be sent to multiple LFBs to be processed in
parallel.
2. Merger - similar to Cilc's sync. An LFB that will receive
packets or chunks of the same initial packet and merge them into
one.
Haleplidis & Halpern Expires January 27, 2015 [Page 4]
Internet-Draft ForCES Packet Parallelization July 2014
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. Figure 1 shows a simple example of a split parallel
datapath along with the splitter and merger LFB. Figure 2 shows an
example of a flood parallel datapath along with the splitter and
merger LFB.
P+M +------------+ P+M
+---->| Regex LFB |----+
+----------+ | +------------+ | +----------+
| |---+ +------>| |
P | | P+M +------------+ P+M | | P
--->| Splitter |-------->| Regex LFB |----------->| Merger |--->
| LFB | P+M +------------+ P+M | LFB |
| |---+ +------>| |
+----------+ | +------------+ | +----------+
+---->| Regex LFB |----+
+------------+
Figure 1: Simple split parallel processing
+----------+ +------------+ +-------+ +----------+
| |P+M | Classifier |P+M | Meter |P+M | |
P | |--->| LFB |--->| LFB |--->| | P
--->| Splitter | +------------+ +-------+ | Merger |--->
| LFB | | LFB |
| |P+M +------------+ P+M | |
| |--------->| IPv4 TTL |---------->| |
+----------+ | Decrement | +----------+
| LFB |
+------------+
Figure 2: Simple flood parallel processing
This version of the modelling 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 the time. This led to a more simple metadata definition
needed 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 be needed to be defined as well
as an augmentation to the defined metadata.
Haleplidis & Halpern Expires January 27, 2015 [Page 5]
Internet-Draft ForCES Packet Parallelization July 2014
2.1. Core parallelization LFB
One important element to a developer is the ability to define which
LFBs can be used in a parallel mode, with which other LFBs can they
be parallelized with and the order in which the 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. The presence of an instance of this LFB
class in the FEObject's SupportedLFBs component indicates 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:
o The Name of the LFB.
o The Class ID of the LFB.
o The Version of the LFB.
o The number of instances that class can support in parallel.
o A list of LFB classes that can follow this LFB class in a pipeline
for a parallel path.
o A list of LFB classes that can exist before this LFB class in a
pipeline for a parallel path.
o 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
Haleplidis & Halpern Expires January 27, 2015 [Page 6]
Internet-Draft ForCES Packet Parallelization July 2014
LFBClassID
The id of the LFB Class
uint32
LFBVersion
The version of the LFB Class used by this FE
string
LFBParallelOccurenceLimit
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 be run
in parallel with
uint32
Haleplidis & Halpern Expires January 27, 2015 [Page 7]
Internet-Draft ForCES Packet Parallelization July 2014
ParallelLFBs
List of all supported parallel LFBs
ParallelLFBType
Figure 3: XML Definitions for CoreParallelization LFB
2.2. Parallelization metadata
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 as a struct is defined:
1. ParallelType - Flood or split
2. Correlator - Identify packets or chunks that belonged to the
initial packet that entered the Splitter LFB
3. ParallelNum - Number of packet or chunk for specific Correlator.
4. ParralelPartsCount - Total number of packets or chunks for
specific Correlator.
This metadata is produced from the Splitter LFB and is opaque to LFBs
in parallel paths and is passed along to the merger LFB without being
consumed.
In case of a packet/chunk in a task being deemed invalid by an LFB,
it MUST be sent by an output port of the corresponding LFB.
In a different case which an LFB in a task decides that a packet or a
chunk has to be dropped it MAY drop it 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.
Haleplidis & Halpern Expires January 27, 2015 [Page 8]
Internet-Draft ForCES Packet Parallelization July 2014
3. Parallel Base Types
3.1. Frame Types
One frame type has been defined in this library.
+---------------+---------------------------------------------------+
| Frame Type | Synopsis |
| Name | |
+---------------+---------------------------------------------------+
| Chunk | A chunk is a frame that is part of an original |
| | larger frame |
+---------------+---------------------------------------------------+
Parallel Frame Types
3.2. Data Types
One data type has been defined in this library.
+---------------+------------------------+--------------------------+
| DataType Name | Type | Synopsis |
+---------------+------------------------+--------------------------+
| ParallelTypes | Atomic uchar. Special | The type of |
| | Values Flood (0), | parallelization this |
| | Split (1). | packet will go through |
+---------------+------------------------+--------------------------+
Parallel Data Types
3.3. MetaData Types
The following metadata structure with ID 16, using the ForCES model
extension [I-D.ietf-forces-model-extension], is defined for the
parallelization library:
Haleplidis & Halpern Expires January 27, 2015 [Page 9]
Internet-Draft ForCES Packet Parallelization July 2014
+--------------------+--------+----+--------------------------------+
| Metadata Name | Type | ID | Synopsis |
+--------------------+--------+----+--------------------------------+
| ParallelType | uchar | 1 | The type of parallelization |
| | | | this packet will go through. 0 |
| | | | for flood, 1 for split. |
| | | | |
| Correlator | uint32 | 2 | An identification number to |
| | | | specify that packets or chunks |
| | | | belong to the same parallel |
| | | | task. |
| | | | |
| ParallelNum | uint32 | 3 | Defines the number of the |
| | | | specific packet or chunk of |
| | | | the specific parallel ID. |
| | | | |
| ParallelPartsCount | uint32 | 4 | Defines the total number of |
| | | | packets or chunks for the |
| | | | specific parallel ID. |
+--------------------+--------+----+--------------------------------+
Metadata Structure for Merging
4. Parallel LFBs
4.1. Splitter
A splitter LFB takes part in parallelizing the processing datapath by
sending either the same packet Figure 2 or chunks Figure 1 of the
same packet to multiple LFBs.
+---------------+
SplitterIn | | SplitterOut
---------->| Splitter LFB |------------->
| |
+---------------+
Figure 4: Splitter LFB
4.1.1. Data Handling
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 of the group output SplitterOut's instances.
If the parallel type is of type split (1), the packet will be split
into same size chunks except the last which MAY be smaller, with the
max size being defined by the ChunkSize component. All chunks will
Haleplidis & Halpern Expires January 27, 2015 [Page 10]
Internet-Draft ForCES Packet Parallelization July 2014
be sent out in a round-robin fashion through the group output
ParallelOut's instances. Each packet or chunk will be accompanied by
the following metadata set as a struct :
o ParallelType - The paralleltype split or flood.
o Parallel ID - generated by the splitter LFB to identify that
chunks or packets belong to the same parallel task.
o Parallel Num - 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.
o ParallelPartsCount - the number of chunks or packets for the
specific parallel id.
4.1.2. Components
This LFB has only two components specified. The first is the
ParallelType, an uint32 that defines how the packet will be processed
by the Splitter LFB. The second is the ChunkSize, an uint32 that
specifies the maximum size of a chunk when a packet is split into
multiple same size chunks.
4.1.3. Capabilities
This LFB has only one capability specified, the MinMaxChunkSize a
struct of two uint32 to specify the minimum and maximum chunk size.
4.1.4. Events
This LFB has no events specified.
4.2. Merger
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 Figure 2 and Figure 1.
+-------------+
MergerIn | |
--------->| | MergerOut
| Merger LFB |----------->
InvalidIn | |
--------->| |
+-------------+
Figure 5: Merger LFB
Haleplidis & Halpern Expires January 27, 2015 [Page 11]
Internet-Draft ForCES Packet Parallelization July 2014
4.2.1. Data Handling
The Merger LFB receives either a packet or a chunk via the group
input ParallelIn, along with the ParallelType metadata that, the
Correlator, the ParallelNum and the ParallelPartsCount.
In case that an upstream LFB has dropped a packet or a chunk the
merger LFB MAY receive only the metadata or both metadata and packet
or chunk through the InvalidIn group input port. It SHOULD receive a
metadata specifying the error code. Currently defined metadata's in
the Base LFB Library [RFC6956] 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 correlator, it will wait for all packets/
chunks to arrive or until the MergeWaitTimeoutTimer has been
exceeded. If the MergeWaitTimeoutTime has been exceeded the Merger
MUST consider the rest of the packets/chuncks that have not been
received as invalid and 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/chuncks 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 dropped,
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 has the same correlator then
the Merger LFB will use the first metadata from a packet or chunk
that entered the LFB through the MergerIn input port.
4.2.2. Components
This LFB has the following components specified:
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
merge will be considered invalid and all chunks or packets will
be dropped. If set to 1 (Continue) the merge will continue.
2. MergeWaitTimeoutTimer - a uint32 defining the amount of time that
the Merger will wait for all packets or chuncks within the same
task to arrive before considering them invalid.
Haleplidis & Halpern Expires January 27, 2015 [Page 12]
Internet-Draft ForCES Packet Parallelization July 2014
3. 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.
4. 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.
5. InvalidTotalCounter - a uint 32 that counts the number of merges
where all packets/chunks entered the merger LFB through the
InvalidIn input port.
6. InvalidIDCounters - a struct of two arrays. Each array has a
uint32 per row. Each array counts 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.
4.2.3. Capabilities
This LFB has no capabilities specified.
4.2.4. Events
This LFB specifies only two event. 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
4.3. CoreParallelization
A core LFB that specifies that the FE supports parallelization,
instead of updating the FEObject LFB
4.3.1. Data Handling
The CoreParallelization does not handle data.
4.3.2. Components
This LFB has no components specified.
Haleplidis & Halpern Expires January 27, 2015 [Page 13]
Internet-Draft ForCES Packet Parallelization July 2014
4.3.3. Capabilities
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:
1. LFBName - a string. The Name 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.
4. LFBParallelOccurenceLimit - a uint32. The upper limit of
instances of the same parallel LFBs of this class.
5. 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.
6. 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.
7. 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.
4.3.4. Events
This LFB specifies no events
5. XML for Parallel LFB library
Chunk
A chunk is a frame that is part of an original
larger frame
Haleplidis & Halpern Expires January 27, 2015 [Page 14]
Internet-Draft ForCES Packet Parallelization July 2014
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
LFBParallelOccurenceLimit
The upper limit of instances of the same
parallel LFBs of this class
uint32
AllowedParallelAfters
Haleplidis & Halpern Expires January 27, 2015 [Page 15]
Internet-Draft ForCES Packet Parallelization July 2014
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 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
Correlator
An identification number to specify that
packets or chunks originate from the same packet.
uint32
Haleplidis & Halpern Expires January 27, 2015 [Page 16]
Internet-Draft ForCES Packet Parallelization July 2014
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
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 different chunk on each instance.
[Arbitrary]
[Chunk]
[ParallelMetadataSet]
Haleplidis & Halpern Expires January 27, 2015 [Page 17]
Internet-Draft ForCES Packet Parallelization July 2014
ParallelType
The type of parallelization this packet will
go through
ParallelTypes
ChunkSize
The size of a chunk when a packet is split
into multiple same size chunks
uint32
MinMaxChunkSize
The minimum and maximum size of a chunk
capable of splitted by this LFB
MinChunkSize
Minimum chunk size
uint32
MaxChunkSize
Maximum chunk size
uint32
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
Haleplidis & Halpern Expires January 27, 2015 [Page 18]
Internet-Draft ForCES Packet Parallelization July 2014
[Arbitrary]
[Chunk]
[ParallelMetadataSet]
InvalidIn
When a packet is sent out of an error port of
an LFB in a parallel path 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
Haleplidis & Halpern Expires January 27, 2015 [Page 19]
Internet-Draft ForCES Packet Parallelization July 2014
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 chuncks 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 number of invalid merges where at
least one packet/chunk entered through InvalidID per
error ID
Haleplidis & Halpern Expires January 27, 2015 [Page 20]
Internet-Draft ForCES Packet Parallelization July 2014
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
Haleplidis & Halpern Expires January 27, 2015 [Page 21]
Internet-Draft ForCES Packet Parallelization July 2014
CoreParallelization
A core LFB that specifies that the FE supports
parallelization, instead of updating the FEObject
LFB
1.0
ParallelLFBs
A table which lists all the LFBs that can be
parallelized
ParallelLFBType
Figure 6: Parallel LFB library
6. Acknowledgements
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.
7. IANA Considerations
7.1. LFB Class Names and LFB Class Identifiers
LFB classes defined by this document belong to LFBs defined by
Standards Track RFCs. According to IANA, the registration procedure
is Standards Action for the range 0 to 65535 and First Come First
Served with any publicly available specification for over 65535.
This specification includes the following LFB class names and LFB
class identifiers:
Haleplidis & Halpern Expires January 27, 2015 [Page 22]
Internet-Draft ForCES Packet Parallelization July 2014
+----------+------------------+---------+----------------+----------+
| LFB | LFB Class Name | LFB | Description | Referenc |
| Class Id | | Version | | e |
| entifier | | | | |
+----------+------------------+---------+----------------+----------+
| 18 | Splitter | 1.0 | A splitter LFB | This |
| | | | will either | document |
| | | | send the same | |
| | | | packet or | |
| | | | chunks of one | |
| | | | packet to | |
| | | | multiple LFBs. | |
| | | | | |
| 19 | Merger | 1.0 | A merger LFB | This |
| | | | receives | document |
| | | | multiple | |
| | | | packets or | |
| | | | multiple | |
| | | | chunks of the | |
| | | | same packet | |
| | | | and merge them | |
| | | | into one. | |
| | | | | |
| 20 | CoreParallelizat | 1.0 | A core LFB to | This |
| | ion | | signify the pa | document |
| | | | rallelization | |
| | | | capability | |
+----------+------------------+---------+----------------+----------+
Logical Functional Block (LFB) Class Names and Class Identifiers
7.2. Metadata ID
The Metadata ID namespace is 32 bits long. Values assigned by this
specification:
+------------+---------------------+---------------+
| Value | Name | Definition |
+------------+---------------------+---------------+
| 0x00000010 | ParallelMetadataSet | This document |
+------------+---------------------+---------------+
Metadata ID assigned by this specification
Haleplidis & Halpern Expires January 27, 2015 [Page 23]
Internet-Draft ForCES Packet Parallelization July 2014
8. Security Considerations
9. References
9.1. Normative References
[I-D.ietf-forces-model-extension]
Haleplidis, E., "ForCES Model Extension", draft-ietf-
forces-model-extension-03 (work in progress), July 2014.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Control Element Separation (ForCES) Protocol
Specification", RFC 5810, March 2010.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model", RFC
5812, March 2010.
[RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
Halpern, "Forwarding and Control Element Separation
(ForCES) Logical Function Block (LFB) Library", RFC 6956,
June 2013.
9.2. Informative References
[Cilc] MIT, "Cilk language",
.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Evangelos Haleplidis
University of Patras
Department of Electrical and Computer Engineering
Patras 26500
Greece
Email: ehalep@ece.upatras.gr
Haleplidis & Halpern Expires January 27, 2015 [Page 24]
Internet-Draft ForCES Packet Parallelization July 2014
Joel Halpern
Ericsson
P.O. Box 6049
Leesburg 20178
VA
Phone: +1 703 371 3043
Email: joel.halpern@ericsson.com
Haleplidis & Halpern Expires January 27, 2015 [Page 25]