draft-ietf-forces-packet-parallelization-01.txt   draft-ietf-forces-packet-parallelization-02.txt 
Internet Engineering Task Force E. Haleplidis Internet Engineering Task Force E. Haleplidis
Internet-Draft University of Patras Internet-Draft University of Patras
Intended status: Standards Track J. Halpern Intended status: Experimental J. Halpern
Expires: January 27, 2015 Ericsson Expires: March 9, 2015 Ericsson
July 26, 2014 September 5, 2014
ForCES Packet Parallelization ForCES Packet Parallelization
draft-ietf-forces-packet-parallelization-01 draft-ietf-forces-packet-parallelization-02
Abstract Abstract
Forwarding and Control Element Separation (ForCES) defines an Forwarding and Control Element Separation (ForCES) defines an
architectural framework and associated protocols to standardize architectural framework and associated protocols to standardize
information exchange between the control plane and the forwarding information exchange between the control plane and the forwarding
plane in a ForCES Network Element (ForCES NE). RFC5812 has defined plane in a ForCES Network Element (ForCES NE). RFC5812 has defined
the ForCES Model provides a formal way to represent the capabilities, the ForCES Model provides a formal way to represent the capabilities,
state, and configuration of forwarding elements within the context of state, and configuration of forwarding elements within the context of
the ForCES protocol, so that control elements (CEs) can control the the ForCES protocol (RFC 5810), so that control elements (CEs) can
FEs accordingly. More specifically, the model describes the logical control the FEs accordingly. More specifically, the model describes
functions that are present in an FE, what capabilities these the logical functions that are present in an FE, what capabilities
functions support, and how these functions are or can be these functions support, and how these functions are or can be
interconnected. 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 ForCES can model a network device's
parallelization datapath. parallelization datapath.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 27, 2015. This Internet-Draft will expire on March 9, 2015.
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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Packet Parallelization . . . . . . . . . . . . . . . . . . . 4 2. Packet Parallelization . . . . . . . . . . . . . . . . . . . 4
2.1. Core parallelization LFB . . . . . . . . . . . . . . . . 6 2.1. Core parallelization LFB . . . . . . . . . . . . . . . . 6
2.2. Parallelization metadata . . . . . . . . . . . . . . . . 8 2.2. Parallelization metadata . . . . . . . . . . . . . . . . 9
3. Parallel Base Types . . . . . . . . . . . . . . . . . . . . . 9 3. Parallel Base Types . . . . . . . . . . . . . . . . . . . . . 9
3.1. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 9 3.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 10
4. Parallel LFBs . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Parallel LFBs . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Splitter . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Splitter . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Data Handling . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Data Handling . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Components . . . . . . . . . . . . . . . . . . . . . 11 4.1.2. Components . . . . . . . . . . . . . . . . . . . . . 12
4.1.3. Capabilities . . . . . . . . . . . . . . . . . . . . 11 4.1.3. Capabilities . . . . . . . . . . . . . . . . . . . . 12
4.1.4. Events . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.4. Events . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Merger . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Merger . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Data Handling . . . . . . . . . . . . . . . . . . . . 12 4.2.1. Data Handling . . . . . . . . . . . . . . . . . . . . 13
4.2.2. Components . . . . . . . . . . . . . . . . . . . . . 12 4.2.2. Components . . . . . . . . . . . . . . . . . . . . . 14
4.2.3. Capabilities . . . . . . . . . . . . . . . . . . . . 13 4.2.3. Capabilities . . . . . . . . . . . . . . . . . . . . 14
4.2.4. Events . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.4. Events . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. CoreParallelization . . . . . . . . . . . . . . . . . . . 13 4.3. CoreParallelization . . . . . . . . . . . . . . . . . . . 15
4.3.1. Data Handling . . . . . . . . . . . . . . . . . . . . 13 4.3.1. Data Handling . . . . . . . . . . . . . . . . . . . . 15
4.3.2. Components . . . . . . . . . . . . . . . . . . . . . 13 4.3.2. Components . . . . . . . . . . . . . . . . . . . . . 15
4.3.3. Capabilities . . . . . . . . . . . . . . . . . . . . 14 4.3.3. Capabilities . . . . . . . . . . . . . . . . . . . . 15
4.3.4. Events . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.4. Events . . . . . . . . . . . . . . . . . . . . . . . 15
5. XML for Parallel LFB library . . . . . . . . . . . . . . . . 14 5. XML for Parallel LFB library . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 22 7.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 24
7.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 23 7.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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 ForCES Model [RFC5812] presents a formal way to describe the The ForCES Model [RFC5812] presents a formal way to describe the
Forwarding Plane's datapath with Logical Function Blocks (LFBs) using Forwarding Plane's datapath with Logical Function Blocks (LFBs) using
XML. This document describes how packet parallelization can be XML. This document describes how packet parallelization can be
described with the ForCES model. described with the ForCES model.
The modelling concept has been influenced by Cilc [Cilc]. Cilc is a The modelling concept has been influenced by Cilc [Cilc]. Cilc is a
programming language that has been developed since 1994 at the MIT programming language that has been developed since 1994 at the MIT
Laboratory to allow programmers to identify elements that can be Laboratory to allow programmers to identify elements that can be
executed in parallel. The two Cilc concepts used in this document is executed in parallel. The two Cilc concepts used in this document is
spawn and sync. Spawn being the place where parallel tasls can start spawn and sync. Spawn being the place where parallel tasks can start
and sync being the place where the parallel task finishes and must and sync being the place where the parallel task finishes and must
collect all parallel output. collect all parallel output.
As task, we define a grouping of packets or pieces of a packet 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 (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 processed in parallel. All packets/chunks of the same task will be
distinguished by an identifier, in the specific case we use the an distinguished by an identifier, in the specific case we use a 32-bit
32-bit identifier named correlator. identifier named task correlator.
Being an experimental document the LFB Class IDs cannot be included
in the standard action's value and therefore must have a value of
larger than 65535 and must begin with prefix 'Ext-'. However when we
refer to the LFB Class names in the text of this document (not the
formal definitions), we will omit the 'Ext-' prefix.
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
skipping to change at page 4, line 14 skipping to change at page 4, line 20
Element Element
Attribute Attribute
LFB Metadata LFB Metadata
ForCES Component ForCES Component
LFB Class Library LFB Class Library
This document also introduces the following terms:
Chunk - Pieces of a packet
Task - Grouping of packets or chunks belong to the same packet
that are processed in parallel
Task Correlator - A 32-bit identifier that uniquely distinguishes
tasks
Split Type - A parallel type where the packets are split into
chunks to be processed in parallel. Each task in a split type is
composed only of chunks.
Flood Type - A parallel type where the packets are copied as is to
downstream LFBs to be processed in parallel. Each task in a flood
type is composed only of packets.
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 in equal size chunks
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 implementor may either decide to physical copy the packet here. An implementer may either decide to physical copy the packet
and send all packets on the parallel paths, or may decide to and send all packets on the parallel paths, or may decide to
logically copy the packet by simply sending for example pointers of logically copy the packet by simply sending, for example, pointers of
the same packet provided that the necessary interlocks are taken into the same packet provided that the necessary interlocks are taken into
account. The implementor has to take into account the device's account. The implementer has to take into account the device's
characteristics to decide which approach fits best to the hardware. characteristics to decide which approach fits best to the device.
Additionally in the split parallel type, while harder, the In the split parallel type, while harder, the implementer may also
implementor may also decide to logically split the packet and send, decide to logically split the packet and send, for example, pointers
for example, pointers to parts of the packet, provided that the to parts of the packet, provided that the necessary interlocks are
necessary interlocks are managed. managed. In addition, how chunks are distributed to the LFBs, e.g.
which chunk to which LFB, is implementation dependent. For example
while usually chunks are sent to the same LFB class, the number of
LFB instances may not equal to the number of chunks. It is up to the
implementer to decide how these chunks will be sent, for example in a
round-robin fashion.
This document introduces two LFBs that are used in before and after This document introduces two LFBs that are used in before and after
the parallelization occurs: the parallelization occurs:
1. Splitter - similar to Cilc's spawn. An LFB that will split the 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 path of a packet which will be sent to multiple downstream LFBs
parallel. to be processed in parallel.
2. Merger - similar to Cilc's sync. An LFB that will receive 2. Merger - similar to Cilc's sync. An LFB that will receive
packets or chunks of the same initial packet and merge them into packets or chunks of the same initial packet and merge them and
one. 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. Figure 1 shows a simple example of a split parallel
datapath along with the splitter and merger LFB. Figure 2 shows an datapath along with the splitter and merger LFB. Figure 2 shows an
example of a flood parallel datapath along with the splitter and example of a flood parallel datapath along with the splitter and
merger LFB. merger LFB.
P+M +------------+ P+M C1+M +------------+ C1+M
+---->| Regex LFB |----+ +---->| Regex LFB |----+
+----------+ | +------------+ | +----------+ +----------+ | +------------+ | +----------+
| |---+ +------>| | | |---+ +------>| |
P | | P+M +------------+ P+M | | P P | | C2+M +------------+ C2+M | | P
--->| Splitter |-------->| Regex LFB |----------->| Merger |---> --->| Splitter |-------->| Regex LFB |----------->| Merger |--->
| LFB | P+M +------------+ P+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
skipping to change at page 5, line 45 skipping to change at page 6, line 35
| |--------->| IPv4 TTL |---------->| | | |--------->| IPv4 TTL |---------->| |
+----------+ | Decrement | +----------+ +----------+ | Decrement | +----------+
| LFB | | LFB |
+------------+ +------------+
Figure 2: Simple flood parallel processing Figure 2: Simple flood parallel processing
This version of the modelling framework does not allow for nested This version of the modelling 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 the time. This led to a more simple metadata definition or need at decision time. This led to a simpler metadata definition,
needed to be transported between the splitter and the corresponding which was needed to be transported between the splitter and the
merger. If there is a need for nested parallel datapaths a new corresponding merger. If there is a need for nested parallel
version of a splitter and merger will be needed to be defined as well datapaths a new version of a splitter and merger will be needed to be
as an augmentation to the defined metadata. defined as well as an augmentation to the defined metadata.
2.1. Core parallelization LFB 2.1. Core parallelization 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, with which other LFBs can they LFBs can be used in a parallel mode, which LFBs can be parallelized
be parallelized with and the order in which the LFBs can be with which as well as the order in which parallel LFBs can be
assembled. To access the parallelization details, we opted for assembled.
defining a new LFB class - the CoreParallelization LFB. This choice
was an alternative to making another change to the core FEObject LFB. To access the parallelization details, we opted for defining a new
The CoreParallelization exists merely to define the capabilities for LFB class - the CoreParallelization LFB. This choice was an
an FE's LFB parallelization. The presence of an instance of this LFB alternative to making another change to the core FEObject LFB. The
class in the FEObject's SupportedLFBs component indicates to the CE CoreParallelization exists merely to define the capabilities for an
that the specific FE supports parallelization. There MUST be only FE's LFB parallelization. A CE using the ForCES Protocol [RFC5810]
one instance of the CoreParallelization LFB per FE. can check the existence of this LFB class in the FEObject's
SupportedLFBs component. The existence of the CoreParallelization
LFB will indicate to the CE that the specific FE supports
parallelization. There MUST be only one instance of the
CoreParallelization LFB per FE.
The topology of the parallel datapath can be deferred and manipulated 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
specify each LFB that can be used in a parallel mode: specify each LFB that can be used in a parallel mode:
o The Name of the LFB. o The Name of the LFB.
o The Class ID of the LFB. o The Class ID of the LFB.
skipping to change at page 8, line 20 skipping to change at page 9, line 12
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 as a struct is defined: chunks to arrive. The following metadata set is defined as a struct:
1. ParallelType - Flood or split 1. ParallelType - Flood or split
2. Correlator - 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 - Number of packet or chunk for specific Correlator. 3. ParallelNum - Sequence Number of the packet or the chunk for a
specific task.
4. ParralelPartsCount - Total number of packets or chunks for 4. ParralelPartsCount - Total number of packets or chunks for a
specific Correlator. specific task.
This metadata is produced from the Splitter LFB and is opaque to LFBs 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 in parallel paths and is passed along to the merger LFB without being
consumed. consumed.
In case of a packet/chunk in a task being deemed invalid by an LFB, In the case in which an LFB decides that a packet/chunk has to be
it MUST be sent by an output port of the corresponding LFB. 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.
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 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
skipping to change at page 10, line 12 skipping to change at page 11, line 12
extension [I-D.ietf-forces-model-extension], is defined for the extension [I-D.ietf-forces-model-extension], 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. |
| | | | | | | | | |
| Correlator | uint32 | 2 | An identification number to | | TaskCorrelator | uint32 | 2 | An identification number to |
| | | | specify that packets or chunks | | | | | specify that a packet or a |
| | | | belong to the same parallel | | | | | chunks belongs to the same |
| | | | task. | | | | | parallel task. |
| | | | | | | | | |
| ParallelNum | uint32 | 3 | Defines the number of the | | ParallelNum | uint32 | 3 | Defines the number of a |
| | | | specific packet or chunk of | | | | | specific packet or chunk of a |
| | | | the specific parallel ID. | | | | | specific task. |
| | | | | | | | | |
| ParallelPartsCount | uint32 | 4 | Defines the total number of | | ParallelPartsCount | uint32 | 4 | Defines the total number of |
| | | | packets or chunks for the | | | | | packets or chunks for a |
| | | | specific parallel ID. | | | | | specific task. |
+--------------------+--------+----+--------------------------------+ +--------------------+--------+----+--------------------------------+
Metadata Structure for Merging Metadata Structure for Merging
4. Parallel LFBs 4. Parallel LFBs
4.1. Splitter 4.1. Splitter
A splitter LFB takes part in parallelizing the processing datapath by The splitter LFB takes part in parallelizing the processing datapath
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 the
same packet to multiple LFBs. 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 of the group output SplitterOut's instances.
If the parallel type is of type split (1), the packet will be split 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 into same size chunks except the last which MAY be smaller, with the
max size being defined by the ChunkSize component. All chunks will max size being defined by the ChunkSize component. Chunks MAY be
be sent out in a round-robin fashion through the group output sent out in a round-robin fashion through the group output
ParallelOut's instances. Each packet or chunk will be accompanied by ParallelOut's instances or in any other way defined by the
the following metadata set as a struct : implementer. Each packet or chunk will be accompanied by the
following metadata set as a struct:
o ParallelType - The paralleltype split or flood. o ParallelType - The parallel type, split or flood.
o Parallel ID - generated by the splitter LFB to identify that o ParallelID - generated by the splitter LFB to identify that chunks
chunks or packets belong to the same parallel task. or packets belong to the same parallel task.
o Parallel Num - 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 parallel id. specific task.
4.1.2. Components 4.1.2. Components
This LFB has only two components specified. 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, an 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, an uint32 that
specifies the maximum size of a chunk when a packet is split into specifies the size of each chunk when a packet is split into multiple
multiple same size chunks. same size chunks. The last chunk MAY be smaller than the value of
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 a
struct of two uint32 to specify the minimum and maximum chunk size. struct of two uint32 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.
skipping to change at page 12, line 7 skipping to change at page 13, line 17
--------->| | 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 that, the
Correlator, 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 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 merger LFB MAY receive only the metadata or both metadata and packet
or chunk through the InvalidIn group input port. It SHOULD receive a or chunk through the InvalidIn group input port. It SHOULD receive a
metadata specifying the error code. Currently defined metadata's in metadata specifying the error code. Currently defined metadata's in
the Base LFB Library [RFC6956] are the ExceptionID and the the Base LFB Library [RFC6956] are the ExceptionID and the
ValidateErrorID. 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 the
merge process upon receiving the first packet. If false, for each merge process upon receiving the first packet. If false, for each
task identified by the correlator, it will wait for all packets/ task identified by the task correlator, it will wait for all packets/
chunks to arrive or until the MergeWaitTimeoutTimer has been chunks to arrive unless the MergeWaitTimeoutTimer timer expires. If
exceeded. If the MergeWaitTimeoutTime has been exceeded the Merger the MergeWaitTimeoutTimer has expired, the Merger MUST consider the
MUST consider the rest of the packets/chuncks that have not been rest of the packets/chuncks, that have not been received, as invalid
received as invalid and MUST handle the packets according to the and MUST handle the packets according to the InvalidAction value.
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/chuncks 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 dropped,
else the process will initiate. Once the merging process has been else the process will initiate. Once the merging process has been
completed the resulting packet will be sent via the singleton output completed the resulting packet will be sent via the singleton output
port MergerOut. 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 correlator then from different packets or chunks that has the same task correlator
the Merger LFB will use the first metadata from a packet or chunk then the Merger LFB will use the first metadata from a packet or
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.
skipping to change at page 16, line 45 skipping to change at page 18, line 14
</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">
<name>Correlator</name> <name>TaskCorrelator</name>
<synopsis>An identification number to specify that <synopsis>An identification number to specify that
packets or chunks originate from the same packet. packets or chunks originate from the same packet.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>ParallelNum</name> <name>ParallelNum</name>
<synopsis>Defines the number of the specific packet or <synopsis>Defines the number of the specific packet or
chunk of the specific parallel ID.</synopsis> chunk of the specific parallel ID.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
skipping to change at page 17, line 19 skipping to change at page 18, line 36
<component componentID="4"> <component componentID="4">
<name>ParallelPartsCount</name> <name>ParallelPartsCount</name>
<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="18"> <LFBClassDef LFBClassID="65537">
<name>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>
skipping to change at page 18, line 25 skipping to change at page 19, line 42
<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 same size chunks</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 splitted by this LFB</synopsis> capable of split by this LFB</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>MinChunkSize</name> <name>MinChunkSize</name>
<synopsis>Minimum chunk size</synopsis> <synopsis>Minimum chunk size</synopsis>
<optional/> <optional/>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<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="19"> <LFBClassDef LFBClassID="65538">
<name>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>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
<ref>Chunk</ref> <ref>Chunk</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>ParallelMetadataSet</ref> <ref>ParallelMetadataSet</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
skipping to change at page 21, line 51 skipping to change at page 23, line 20
</eventTarget> </eventTarget>
<eventGreaterThan/> <eventGreaterThan/>
<eventReports> <eventReports>
<eventReport> <eventReport>
<eventField>InvalidTotalCounter</eventField> <eventField>InvalidTotalCounter</eventField>
</eventReport> </eventReport>
</eventReports> </eventReports>
</event> </event>
</events> </events>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="20"> <LFBClassDef LFBClassID="65539">
<name>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 which lists all the LFBs that can be
parallelized</synopsis> parallelized</synopsis>
<array> <array>
skipping to change at page 22, line 36 skipping to change at page 24, line 9
The authors would like to thank Edward Crabbe for the initial The authors would like to thank Edward Crabbe for the initial
discussion that led to the creation of this document and Jamal Hadi discussion that led to the creation of this document and Jamal Hadi
Salim and Dave Hood for comments and discussions that made this Salim and Dave Hood for comments and discussions that made this
document better. document better.
7. IANA Considerations 7. IANA Considerations
7.1. LFB Class Names and LFB Class Identifiers 7.1. LFB Class Names and LFB Class Identifiers
LFB classes defined by this document belong to LFBs defined by LFB classes defined by this document do not belong to LFBs defined by
Standards Track RFCs. According to IANA, the registration procedure Standards Track RFCs in the http://www.iana.org/assignments/forces/
is Standards Action for the range 0 to 65535 and First Come First forces.xml registry. As such the values defined in this document are
Served with any publicly available specification for over 65535. in the above 65535 value range.
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 | Description | Referenc | | LFB | LFB Class Name | LFB Ve | Description | Referenc |
| Class Id | | Version | | e | | Class Id | | rsion | | e |
| entifier | | | | | | entifier | | | | |
+----------+------------------+---------+----------------+----------+ +----------+--------------------+--------+---------------+----------+
| 18 | Splitter | 1.0 | A splitter LFB | This | | 65537 | Ext-Splitter | 1.0 | A splitter | This |
| | | | will either | document | | | | | LFB will | document |
| | | | send the same | | | | | | either send | |
| | | | packet or | | | | | | the same | |
| | | | chunks of one | | | | | | packet or | |
| | | | packet to | | | | | | chunks of one | |
| | | | multiple LFBs. | | | | | | packet to | |
| | | | | | | | | | multiple | |
| 19 | Merger | 1.0 | A merger LFB | This | | | | | LFBs. | |
| | | | receives | document | | | | | | |
| | | | multiple | | | 65538 | Ext-Merger | 1.0 | A merger LFB | This |
| | | | packets or | | | | | | receives | document |
| | | | multiple | | | | | | multiple | |
| | | | chunks of the | | | | | | packets or | |
| | | | same packet | | | | | | multiple | |
| | | | and merge them | | | | | | chunks of the | |
| | | | into one. | | | | | | same packet | |
| | | | | | | | | | and merge | |
| 20 | CoreParallelizat | 1.0 | A core LFB to | This | | | | | them into | |
| | ion | | signify the pa | document | | | | | one. | |
| | | | rallelization | | | | | | | |
| | | | capability | | | 65539 | Ext-CoreParalleliz | 1.0 | A core LFB to | This |
+----------+------------------+---------+----------------+----------+ | | 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 7.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: specification are:
+------------+---------------------+---------------+ +------------+---------------------+---------------+
| Value | Name | Definition | | Value | Name | Definition |
+------------+---------------------+---------------+ +------------+---------------------+---------------+
| 0x00000010 | ParallelMetadataSet | This document | | 0x00000010 | ParallelMetadataSet | This document |
+------------+---------------------+---------------+ +------------+---------------------+---------------+
Metadata ID assigned by this specification Metadata ID assigned by this specification
8. Security Considerations 8. Security Considerations
This document does not alter either the ForCES model [RFC5812] or the
ForCES protocol [RFC5810] and as such has no impact on their security
considerations. This document simply defines the operational
parameters and capabilities of LFBs that perform parallelization and
not how parallelization is implemented. However as parallezation
tasks have security issues, a designer or an implementer must take
into account any security considerations that regards packet
parallelization.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-forces-model-extension] [I-D.ietf-forces-model-extension]
Haleplidis, E., "ForCES Model Extension", draft-ietf- Haleplidis, E., "ForCES Model Extension", draft-ietf-
forces-model-extension-03 (work in progress), July 2014. forces-model-extension-04 (work in progress), August 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[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.
[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.
9.2. Informative References 9.2. Informative References
[Cilc] MIT, "Cilk language", [Cilc] MIT, "Cilk language",
<http://supertech.csail.mit.edu/cilk/>. <http://supertech.csail.mit.edu/cilk/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
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 20178 Leesburg 20178
VA VA
Phone: +1 703 371 3043 Phone: +1 703 371 3043
Email: joel.halpern@ericsson.com Email: joel.halpern@ericsson.com
 End of changes. 54 change blocks. 
162 lines changed or deleted 207 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/