idnits 2.17.1
draft-ietf-forces-packet-parallelization-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (February 5, 2014) is 3732 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-05) exists of
draft-ietf-forces-model-extension-01
Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force E. Haleplidis
3 Internet-Draft University of Patras
4 Intended status: Standards Track J. Halpern
5 Expires: August 9, 2014 Ericsson
6 February 5, 2014
8 ForCES Packet Parallelization
9 draft-ietf-forces-packet-parallelization-00
11 Abstract
13 Forwarding and Control Element Separation (ForCES) defines an
14 architectural framework and associated protocols to standardize
15 information exchange between the control plane and the forwarding
16 plane in a ForCES Network Element (ForCES NE). RFC5812 has defined
17 the ForCES Model provides a formal way to represent the capabilities,
18 state, and configuration of forwarding elements within the context of
19 the ForCES protocol, so that control elements (CEs) can control the
20 FEs accordingly. More specifically, the model describes the logical
21 functions that are present in an FE, what capabilities these
22 functions support, and how these functions are or can be
23 interconnected.
25 Many network devices support parallel packet processing. This
26 document describes how ForCES can model a network device's
27 parallelization datapath.
29 Status of This Memo
31 This Internet-Draft is submitted in full conformance with the
32 provisions of BCP 78 and BCP 79.
34 Internet-Drafts are working documents of the Internet Engineering
35 Task Force (IETF). Note that other groups may also distribute
36 working documents as Internet-Drafts. The list of current Internet-
37 Drafts is at http://datatracker.ietf.org/drafts/current/.
39 Internet-Drafts are draft documents valid for a maximum of six months
40 and may be updated, replaced, or obsoleted by other documents at any
41 time. It is inappropriate to use Internet-Drafts as reference
42 material or to cite them other than as "work in progress."
44 This Internet-Draft will expire on August 9, 2014.
46 Copyright Notice
48 Copyright (c) 2014 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents
53 (http://trustee.ietf.org/license-info) in effect on the date of
54 publication of this document. Please review these documents
55 carefully, as they describe your rights and restrictions with respect
56 to this document. Code Components extracted from this document must
57 include Simplified BSD License text as described in Section 4.e of
58 the Trust Legal Provisions and are provided without warranty as
59 described in the Simplified BSD License.
61 Table of Contents
63 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
65 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
67 3. Packet Parallelization . . . . . . . . . . . . . . . . . . . 5
68 4. Parallel Base Types . . . . . . . . . . . . . . . . . . . . . 9
69 4.1. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 9
70 4.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 10
71 4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 10
72 5. Parallel LFBs . . . . . . . . . . . . . . . . . . . . . . . . 10
73 5.1. Splitter . . . . . . . . . . . . . . . . . . . . . . . . 11
74 5.1.1. Data Handling . . . . . . . . . . . . . . . . . . . . 11
75 5.1.2. Components . . . . . . . . . . . . . . . . . . . . . 11
76 5.1.3. Capabilities . . . . . . . . . . . . . . . . . . . . 11
77 5.1.4. Events . . . . . . . . . . . . . . . . . . . . . . . 12
78 5.2. Merger . . . . . . . . . . . . . . . . . . . . . . . . . 12
79 5.2.1. Data Handling . . . . . . . . . . . . . . . . . . . . 12
80 5.2.2. Components . . . . . . . . . . . . . . . . . . . . . 12
81 5.2.3. Capabilities . . . . . . . . . . . . . . . . . . . . 13
82 5.2.4. Events . . . . . . . . . . . . . . . . . . . . . . . 13
83 5.3. CoreParallelization . . . . . . . . . . . . . . . . . . . 13
84 5.3.1. Data Handling . . . . . . . . . . . . . . . . . . . . 14
85 5.3.2. Components . . . . . . . . . . . . . . . . . . . . . 14
86 5.3.3. Capabilities . . . . . . . . . . . . . . . . . . . . 14
87 5.3.4. Events . . . . . . . . . . . . . . . . . . . . . . . 14
88 6. XML for Parallel LFB library . . . . . . . . . . . . . . . . 14
89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
91 8.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 22
92 8.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 23
93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
95 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
96 10.2. Informative References . . . . . . . . . . . . . . . . . 24
97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
99 1. Terminology and Conventions
101 1.1. Requirements Language
103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
105 document are to be interpreted as described in [RFC2119].
107 1.2. Definitions
109 This document follows the terminology defined by the ForCES Model in
110 [RFC5812]. The required definitions are repeated below for clarity.
112 FE Model - The FE model is designed to model the logical
113 processing functions of an FE. The FE model proposed in this
114 document includes three components; the LFB modeling of individual
115 Logical Functional Block (LFB model), the logical interconnection
116 between LFBs (LFB topology), and the FE-level attributes,
117 including FE capabilities. The FE model provides the basis to
118 define the information elements exchanged between the CE and the
119 FE in the ForCES protocol [RFC5810].
121 LFB (Logical Functional Block) Class (or type) - A template that
122 represents a fine-grained, logically separable aspect of FE
123 processing. Most LFBs relate to packet processing in the data
124 path. LFB classes are the basic building blocks of the FE model.
126 LFB Instance - As a packet flows through an FE along a data path,
127 it flows through one or multiple LFB instances, where each LFB is
128 an instance of a specific LFB class. Multiple instances of the
129 same LFB class can be present in an FE's data path. Note that we
130 often refer to LFBs without distinguishing between an LFB class
131 and LFB instance when we believe the implied reference is obvious
132 for the given context.
134 LFB Model - The LFB model describes the content and structures in
135 an LFB, plus the associated data definition. XML is used to
136 provide a formal definition of the necessary structures for the
137 modeling. Four types of information are defined in the LFB model.
138 The core part of the LFB model is the LFB class definitions; the
139 other three types of information define constructs associated with
140 and used by the class definition. These are reusable data types,
141 supported frame (packet) formats, and metadata.
143 Element - Element is generally used in this document in accordance
144 with the XML usage of the term. It refers to an XML tagged part
145 of an XML document. For a precise definition, please see the full
146 set of XML specifications from the W3C. This term is included in
147 this list for completeness because the ForCES formal model uses
148 XML.
150 Attribute - Attribute is used in the ForCES formal modeling in
151 accordance with standard XML usage of the term, i.e., to provide
152 attribute information included in an XML tag.
154 LFB Metadata - Metadata is used to communicate per-packet state
155 from one LFB to another, but is not sent across the network. The
156 FE model defines how such metadata is identified, produced, and
157 consumed by the LFBs, but not how the per-packet state is
158 implemented within actual hardware. Metadata is sent between the
159 FE and the CE on redirect packets.
161 ForCES Component - A ForCES Component is a well-defined, uniquely
162 identifiable and addressable ForCES model building block. A
163 component has a 32-bit ID, name, type, and an optional synopsis
164 description. These are often referred to simply as components.
165 LFB Component - An LFB component is a ForCES component that
166 defines the Operational parameters of the LFBs that must be
167 visible to the CEs.
169 LFB Class Library - The LFB class library is a set of LFB classes
170 that has been identified as the most common functions found in
171 most FEs and hence should be defined first by the ForCES Working
172 Group.
174 2. Introduction
176 A lot of network devices can process packets in a parallel manner.
177 The ForCES Model [RFC5812] presents a formal way to describe the
178 Forwarding Plane's datapath with Logical Function Blocks (LFBs) using
179 XML. This document describes how packet parallelization can be
180 described with the ForCES model.
182 The modelling concept has been influenced by Cilc [Cilc]. Cilc is a
183 programming language that has been developed since 1994 at the MIT
184 Laboratory to allow programmers to identify elements that can be
185 executed in parallel. The two Cilc concepts used in this document is
186 spawn and sync. Spawn being the place where parallel work can start
187 and sync being the place where the parallel work finishes and must
188 collect all parallel output.
190 3. Packet Parallelization
192 This document addresses the following two types of packet
193 parallelization:
195 1. Flood - where a copy of a packet is sent to multiple LFBs to be
196 processed in parallel.
198 2. Split - where the packet will be split in equal size chunks
199 specified by the CE and sent to multiple LFB instances probably
200 of the same LFB class to be processed in parallel.
202 It must be noted that the process of copying the packet in the Flood
203 parallel type is implementation depended and is loosely defined here.
204 An implementor may either decide to physical copy the packet and send
205 all packets on the parallel paths, or may decide to logically copy
206 the packet by simply sending for example pointers of the same packet
207 provided that the necessary interlocks are taken into account. The
208 implementor has to take into account the device's characteristics to
209 decide which approach fits bets to the hardware.
211 Additionally in the split parallel type, while harder, the
212 implementor may also decide to logically split the packet and send
213 for example pointers to parts of the packet, provided that the
214 necessary interlocks are managed.
216 This document introduces two LFBs that are used in before and after
217 the parallelization occurs:
219 1. Splitter - similar to Cilc's spawn. An LFB that will split the
220 path of a packet and be sent to multiple LFBs to be processed in
221 parallel.
223 2. Merger - similar to Cilc's sync. An LFB that will receive
224 packets or chunks of the same initial packet and merge them into
225 one.
227 Both parallel packet distribution types can currently be achieved
228 with the ForCES model. The splitter LFB has one group output that
229 produces either chunks or packets to be sent to LFBs for processing
230 and the merger LFB has one group input that expects either packets or
231 chunks to aggregate all the parallel packets or chunks and produce a
232 single packet. Figure 1 shows an simple example of a split parallel
233 datapath along with the splitter and merger LFB. Figure 2 shows an
234 example of a flood parallel datapath along with the splitter and
235 merger LFB.
237 +------------+
238 +---->| Regex LFB |----+
239 +----------+ | +------------+ | +----------+
240 | |---+ +------>| |
241 | | +------------+ | |
242 --->| Splitter |-------->| Regex LFB |----------->| Merger |--->
243 | LFB | +------------+ | LFB |
244 | |---+ +------>| |
245 +----------+ | +------------+ | +----------+
246 +---->| Regex LFB |----+
247 +------------+
249 Figure 1: Simple split parallel processing
251 +----------+ +------------+ +-------+ +----------+
252 | | | Classifier | | Meter | | |
253 | |--->| LFB |--->| LFB |--->| |
254 --->| Splitter | +------------+ +-------+ | Merger |--->
255 | LFB | | LFB |
256 | | +------------+ | |
257 | |--------->| IPv4 TTL |---------->| |
258 +----------+ | Decrement | +----------+
259 | LFB |
260 +------------+
262 Figure 2: Simple flood parallel processing
264 This version of the modelling framework does not allow for nested
265 parallel datapath topologies. This decision was reached by the
266 authors and the ForCES working group as there was no strong use case
267 or need at the time. This led to a more simple metadata definition
268 needed to be transported between the splitter and the corresponding
269 merger. If there is a need for nested parallel datapaths a new
270 version of a splitter and merger will be needed to be defined as well
271 as an augmentation to the defined metadata.
273 One important element to a developer is the ability to define which
274 LFBs can be used in a parallel mode, with which other LFBs can they
275 be parallelized with and the order of the LFBs can be assembled.
276 This information must be accessible in the core LFBs. However
277 instead of appending one more capability in the FEObject LFB and
278 changing the FEObject LFB, we opted for an alternative. We
279 introduced an additional core LFB, the CoreParallelization, that will
280 not have input and output ports, but simply the capability necessary
281 for LFB parallelization. If this LFB is not supported in the
282 FEObjects LFB's SupportedLFBs component and not instantiated in the
283 FE, that means that the FE does not support LFB parallelization.
285 The topology of the parallel datapath can be deferred and manipulated
286 from the FEObject LFB's LFBTopology.
288 The CoreParallelization requires only one capability in order to
289 specify each LFB that can be used in a parallel mode:
291 o The Name of the LFB.
293 o The Class ID of the LFB.
295 o The Version of the LFB.
297 o The number of instances that class can support in parallel.
299 o A list of LFB classes that can follow this LFB class in a pipeline
300 for a parallel path.
302 o A list of LFB classes that can exist before this LFB class in a
303 pipeline for a parallel path.
305 o A list of LFB classes that can process packets or chunks in
306 parallel with this LFB class.
308
309
310 ParallelLFBType
311 Table entry for parallel LFBs
312
313
314 LFBName
315 The name of an LFB Class
316 string
317
318
319 LFBClassID
320 The id of the LFB Class
321 uint32
322
323
324 LFBVersion
325 The version of the LFB Class used by this FE
326
327 string
328
329
330 LFBParallelOccurenceLimit
331 The upper limit of instances of the same
332 parallel LFBs of this class
334
335 uint32
336
337
338 AllowedParallelAfters
339 List of LFB Classes that can follow this LFB
340 in a parallel pipeline
341
342
343 uint32
344
345
346
347 AllowedParallelBefores
348 List of LFB Classes that this LFB class can
349 follow in a parallel pipeline
350
351
352 uint32
353
354
355
356 AllowedParallel
357 List of LFB Classes that this LFB class be run
358 in parallel with
359
360 uint32
361
362
363
364
366
367
368 ParallelLFBs
369 List of all supported parallel LFBs
370
371 ParallelLFBType
372
373
375 Figure 3: XML Definitions for CoreParallelization LFB
377 While the ForCES model cannot describe how the splitting or the
378 merging is actually done as that is an implementation issue of the
379 actual LFB, however this document defines operational parameters to
380 control the splitting and merging, namely the size of the chunks,
381 what happens if a packet or chunk has been marked as invalid and
382 whether the merge LFB should wait for all packets or chunks to
383 arrive. Additionally this document defines metadata, which contain
384 necessary information to assist the merging procedure. The following
385 metadata set as a struct is defined:
387 1. ParallelType - Flood or split
389 2. Correlator - Identify packets or chunks that belonged to the
390 initial packet that entered the Splitter LFB
392 3. ParallelNum - Number of packet or chunk for specific Correlator.
394 4. ParralelPartsCount - Total number of packets or chunks for
395 specific Correlator.
397 This metadata is produced from the Splitter LFB and is opaque to LFBs
398 in parallel paths and is passed along to the merger LFB without being
399 consumed.
401 In case of a packet/chunk being branded invalid by an LFB in a
402 parallel path, it MUST be sent by an output port of said LFB
404 An LFB inside a parallel path decides that a packet or a chunk has to
405 be dropped it MAY drop it but the metadata MUST be sent to the Merger
406 LFB's InvalidIn input port for merging purposes.
408 Additional metadata produced by LFBs inside a datapath MAY be
409 aggregated within the Merger LFB and sent on after the merging
410 process. In case of receiving the same metadata definition with
411 multiple values the merger LFB MUST keep the first received from a
412 valid packet or chunk.
414 4. Parallel Base Types
416 4.1. Frame Types
418 One frame type has been defined in this library.
420 +---------------+---------------------------------------------------+
421 | Frame Type | Synopsis |
422 | Name | |
423 +---------------+---------------------------------------------------+
424 | Chunk | A chunk is a frame that is part of an original |
425 | | larger frame |
426 +---------------+---------------------------------------------------+
428 Parallel Frame Types
430 4.2. Data Types
432 One data type has been defined in this library.
434 +---------------+------------------------+--------------------------+
435 | DataType Name | Type | Synopsis |
436 +---------------+------------------------+--------------------------+
437 | ParallelTypes | Atomic uchar. Special | The type of |
438 | | Values Flood (0), | parallelization this |
439 | | Split (1). | packet will go through |
440 +---------------+------------------------+--------------------------+
442 Parallel Data Types
444 4.3. MetaData Types
446 The following metadata structure with ID 16, using the ForCES model
447 extension [I-D.ietf-forces-model-extension], is defined for the
448 parallelization library:
450 +--------------------+--------+----+--------------------------------+
451 | Metadata Name | Type | ID | Synopsis |
452 +--------------------+--------+----+--------------------------------+
453 | ParallelType | uchar | 1 | The type of parallelization |
454 | | | | this packet will go through. 0 |
455 | | | | for flood, 1 for split. |
456 | | | | |
457 | Correlator | uint32 | 2 | An identification number to |
458 | | | | specify that packets or chunks |
459 | | | | belong to the same parallel |
460 | | | | work. |
461 | | | | |
462 | ParallelNum | uint32 | 3 | Defines the number of the |
463 | | | | specific packet or chunk of |
464 | | | | the specific parallel ID. |
465 | | | | |
466 | ParallelPartsCount | uint32 | 4 | Defines the total number of |
467 | | | | packets or chunks for the |
468 | | | | specific parallel ID. |
469 +--------------------+--------+----+--------------------------------+
471 Metadata Structure for Merging
473 5. Parallel LFBs
474 5.1. Splitter
476 A splitter LFB takes part in parallelizing the processing datapath by
477 sending either the same packet or chunks of the same packet to
478 multiple LFBs.
480 5.1.1. Data Handling
482 The splitter LFB receives any kind of packet via the singleton input,
483 Input. Depending upon the CE's configuration of the ParallelType
484 component, if the parallel type is of type flood (0), the same packet
485 MUST be sent through all of the group output ParallelOut's instances.
486 If the parallel type is of type split (1), the packet will be split
487 into same size chunks except the last which MAY be smaller, with the
488 max size being defined by the ChunkSize component. All chunks will
489 be sent out in a round-robin fashion through the group output
490 ParallelOut's instances. Each packet or chunk will be accompanied by
491 the following metadata set as a struct :
493 o ParallelType - The paralleltype split or flood.
495 o Parallel ID - generated by the splitter LFB to identify that
496 chunks or packets belong to the same parallel work.
498 o Parallel Num - each chunk or packet of a parallel id will be
499 assigned a number in order for the merger LFB to know when it has
500 gathered them all along with the ParallelPartsCount metadata.
502 o ParallelPartsCount - the number of chunks or packets for the
503 specific parallel id.
505 5.1.2. Components
507 This LFB has only two components specified. The first is the
508 ParallelType, an uint32 that defines how the packet will be processed
509 by the Splitter LFB. The second is the ChunkSize, an uint32 that
510 specifies the maximum size of a chunk when a packet is split into
511 multiple same size chunks.
513 5.1.3. Capabilities
515 This LFB has only one capability specified, the MinMaxChunkSize a
516 struct of a uint32 to specify the minimum chunk size and a uint32 to
517 specify the maximum chunk size.
519 5.1.4. Events
521 This LFB has no events specified.
523 5.2. Merger
525 A merger LFB receives multiple packets or multiple chunks of the same
526 packet and merge them into one merged packet.
528 5.2.1. Data Handling
530 The Merger LFB receives either a packet or a chunk via the group
531 input ParallelIn, along with the ParallelType metadata to identify
532 whether what was received was a packet or a chunk, the Correlator,
533 the ParallelNum and the ParallelPartsCount.
535 In case that an LFB has dropped a packet or a chunk within a parallel
536 path the merger LFB MAY receive only the metadata or both metadata
537 and packet or chunk through the InvalidIn group input port. It
538 SHOULD receive a metadata specifying the error code. Current defined
539 metadata's in the Base LFB Library [RFC6956] are the ExceptionID and
540 the ValidateErrorID. The Merger LFB MAY store the parallel metadata
541 along with the exception metadata as a string in the optional
542 InvalideMetadataSets as a means for the CE to debug errors in the
543 parallel path.
545 If the MergeWaitType is set to false the Merger LFB will initiate the
546 merge process upon receiving the first packet. If false it will wait
547 for all packet in the Correlator to arrive.
549 If one packet or chunk has been received through the InvalidIn port
550 then the merging procedure will be operate as configured by the
551 InvalidAction component. If the InvalidAction component has been set
552 to 0 then if one packet or chunk is not valid all will dropped, else
553 the process will initiate. Once the merging process has been
554 finished the resulting packet will be sent via the singleton output
555 port PacketOutput.
557 If the Merger LFB receives different values for the same metadata
558 from different packets or chunks that has the same correlator then
559 the Merger LFB will use the first metadata from a packet or chunk
560 that entered the LFB through the ParallelIn input port.
562 5.2.2. Components
564 This LFB has the following components specified:
566 1. InvalidAction - a uchar defining what the Merge LFB will do if an
567 invalid chunk or packet is received. If set to 0 (DropAll) the
568 merge will be considered invalid and all chunks or packets will
569 be dropped. If set to 1 (Continue) the merge will continue.
571 2. MergeWaitType - a boolean. If true the Merger LFB will wait for
572 all packets or chunks to be received prior to sending out a
573 response. If false, when one packet or a chunk with a response
574 is received by the merge LFB it will start with the merge
575 process.
577 3. InvalidMergesCounter - a uint32 that counts the number of merges
578 where there is at least one packet or chunk that entered the
579 merger LFB through the InvalidIn input port.
581 4. InvalidAllCounter - a uint 32 that counts the number of merges
582 where all packets/chunks entered the merger LFB through the
583 InvalidIn input port.
585 5. InvalidIDCounters - a struct of two arrays. Each array has a
586 uint32 per row. Each array counts number of invalid merges where
587 at least one packet or chunk entered through InvalidID per error
588 ID. The first array is the InvalidExceptionID and the second is
589 the InvalidValidateErrorID.
591 6. InvalideMetadataSets - an array of strings. An optional
592 component that stores metadata sets along with the error id as a
593 string. This could provide a debug information to the CE
594 regarding errors in the parallel paths.
596 5.2.3. Capabilities
598 This LFB has no capabilities specified.
600 5.2.4. Events
602 This LFB specifies only two event. The first detects whether the
603 InvalidMergesCounter has exceeded a specific value and the second
604 detects whether the InvalidAllCounter has exceeded a specific value.
605 Both error reports will send the respective counter value.
607 5.3. CoreParallelization
609 A core LFB that specifies that the FE supports parallelization,
610 instead of updating the FEObject LFB
612 5.3.1. Data Handling
614 The CoreParallelization does not handle data. It is a core LFB that
615 has only one capability.
617 5.3.2. Components
619 This LFB has no components specified.
621 5.3.3. Capabilities
623 This LFB has only one capability specified. The ParallelLFBs is a
624 table which lists all the LFBs that can be parallelized. Each row of
625 the table contains:
627 1. LFBName - a string. The Name of the parallel LFB.
629 2. LFBClassID - a uint32. The Class ID of the parallel LFB.
631 3. LFBVersion - a string. The Version of the parallel LFB.
633 4. LFBParallelOccurenceLimit - a uint32. The upper limit of
634 instances of the same parallel LFBs of this class.
636 5. AllowedParallelAfters - a table of uint32s (LFB Class IDs). A
637 list of LFB classes that can follow this LFB class in a pipeline
638 for a parallel path.
640 6. AllowedParallelBefores - a table of uint32s (LFB Class IDs). A
641 list of LFB classes that can exist before this LFB class in a
642 pipeline for a parallel path.
644 7. AllowedParallel - a table of uint32s (LFB Class IDs). A list of
645 LFB classes that can process packets or chunks in parallel with
646 this LFB class.
648 5.3.4. Events
650 This LFB specifies no events
652 6. XML for Parallel LFB library
654
655
659
660
661
662 Chunk
663 A chunk is a frame that is part of an original
664 larger frame
665
666
667
668
669 ParallelTypes
670 The type of parallelization this packet will go
671 through
672
673 uchar
674
675
676 Flood
677 The packet/chunk has been sent as a whole
678 to multiple recipients
679
680
681 Split
682 The packet/chunk has been split into
683 multiple chunks and sent to recipients
684
685
686
687
688
689 ParallelLFBType
690 Table entry for parallel LFBs
691
692
693 LFBName
694 The name of an LFB Class
695 string
696
697
698 LFBClassID
699 The id of the LFB Class
700 uint32
701
702
703 LFBVersion
704 The version of the LFB Class used by this FE
705
706 string
707
708
709 LFBParallelOccurenceLimit
710 The upper limit of instances of the same
711 parallel LFBs of this class
712
713 uint32
714
715
716 AllowedParallelAfters
717 List of LFB Classes that can follow this LFB
718 in a parallel pipeline
719
720
721 uint32
722
723
724
725 AllowedParallelBefores
726 List of LFB Classes that this LFB class can
727 follow in a parallel pipeline
728
729
730 uint32
731
732
733
734 AllowedParallel
735 List of LFB Classes that this LFB class be run
736 in parallel with
737
738 uint32
739
740
741
742
743
744
745
746 ParallelMetadataSet
747 A metadata Set for parallelization related LFBs
748
749 32
750
751
752 ParallelType
753 The type of parallelization this packet/chunk
754 has gone through
755 ParallelTypes
757
758
759 Correlator
760 An identification number to specify that
761 packets or chunks originate from the same packet.
762
763 uint32
764
765
766 ParallelNum
767 Defines the number of the specific packet or
768 chunk of the specific parallel ID.
769 uint32
770
771
772 ParallelPartsCount
773 Defines the total number of packets or chunks
774 for the specific parallel ID.
775 uint32
776
777
778
779
780
781
782 Splitter
783 A splitter LFB takes part in parallelizing the
784 processing datapath. It will either send the same packet
785 or chunks of one packet to multiple LFBs
786 1.0
787
788
789 PacketIn
790 An input port expecting any kind of frame
791
792
793
794 [Arbitrary]
795
796
797
798
799
800
801 ParallelOut
802 An parallel output port that sends the same
803 packet to all output instances or chunks of the same
804 packet different chunk on each instance.
806
807
808 [Arbitrary]
809 [Chunk]
810
811
812 [ParallelMetadataSet]
813
814
815
816
817
818
819 ParallelType
820 The type of parallelization this packet will
821 go through
822 ParallelTypes
823
824
825 ChunkSize
826 The size of a chunk when a packet is split
827 into multiple same size chunks
828 uint32
829
830
831
832
833 MinMaxChunkSize
834 The minimum and maximum size of a chunk
835 capable of splitted by this LFB
836
837
838 MinChunkSize
839 Minimum chunk size
840
841 uint32
842
843
844 MaxChunkSize
845 Maximum chunk size
846 uint32
847
848
849
850
851
852
853 Merger
854 A merger LFB receives multiple packets or multiple
855 chunks of the same packet and merge them into one merged
856 packet
857 1.0
858
859
860 ParallelIn
861 An parallel input port that accepts packets
862 or chunks from all output instances
863
864
865 [Arbitrary]
866 [Chunk]
867
868
869 [ParallelMetadataSet]
870
871
872
873
874 InvalidIn
875 When a packet is sent out of an error port of
876 an LFB in a parallel path will be sent to this
877 output port in the Merger LFB
878
879
880 [Arbitrary]
881 [Chunk]
882
883
884
885 [ExceptionID]
886 [ValidateErrorID]
887
888
889
890
891
892
893
894 PacketOutput
895 An output port expecting any kind of frame
896
897
898
899 [Arbitrary]
900
901
903
904
905
906
907 InvalidAction
908 What the Merge LFB will do if an invalid
909 chunk or packet is received
910
911 uchar
912
913
914 DropAll
915 Drop all packets or chunks
916
917
918
919 Continue
920 Continue with the merge
921
922
923
924
925
926 MergeWaitType
927 Whether the Merge LFB will wait for all
928 packets or chunks to be received prior to sending
929 out a response
930 boolean
931
932
933 InvalidMergesCounter
934 Counts the number of merges where there is at
935 least one packet/chunk that entered the merger LFB
936 through the InvalidIn input port
937 uint32
938
939
940 InvalidAllCounter
941 Counts the number of merges where all
942 packets/chunks entered the merger LFB through the
943 InvalidIn input port
944 uint32
945
946
947 InvalidIDCounters
948 Counts number of invalid merges where at
949 least one packet/chunk entered through InvalidID per
950 error ID
952
953
954 InvalidExceptionID
955 Per Exception ID
956
957 uint32
958
959
960
961 InvalidValidateErrorID
962 Per Validate Error ID
963
964 uint32
965
966
967
968
969
970 InvalideMetadataSets
971 Buffers metadata sets along with the error id
972 as a string.
973
974
975 string
976
977
978
979
980
981 ManyInvalids
982 An event that specifies if there are too many
983 invalids
984
985 InvalidCounter
986
987
988
989
990 InvalidMergesCounter
991
992
993
994
995 ManyAllInvalids
996 An event that specifies if there are too many
997 invalids
998
999 InvalidCounter
1001
1002
1003
1004
1005 InvalidAllCounter
1006
1007
1008
1009
1010
1011
1012 CoreParallelization
1013 A core LFB that specifies that the FE supports
1014 parallelization, instead of updating the FEObject
1015 LFB
1016 1.0
1017
1018
1019 ParallelLFBs
1020 A table which lists all the LFBs that can be
1021 parallelized
1022
1023 ParallelLFBType
1024
1025
1026
1027
1028
1029
1031 Figure 4: Parallel LFB library
1033 7. Acknowledgements
1035 The authors would like to thank Jamal Hadi Salim and Dave Hood for
1036 comments and discussions that made this document better.
1038 8. IANA Considerations
1040 8.1. LFB Class Names and LFB Class Identifiers
1042 LFB classes defined by this document belong to LFBs defined by
1043 Standards Track RFCs. According to IANA, the registration procedure
1044 is Standards Action for the range 0 to 65535 and First Come First
1045 Served with any publicly available specification for over 65535.
1046 This specification includes the following LFB class names and LFB
1047 class identifiers:
1049 +----------+------------------+---------+----------------+----------+
1050 | LFB | LFB Class Name | LFB | Description | Referenc |
1051 | Class Id | | Version | | e |
1052 | entifier | | | | |
1053 +----------+------------------+---------+----------------+----------+
1054 | 18 | Splitter | 1.0 | A splitter LFB | This |
1055 | | | | will either | document |
1056 | | | | send the same | |
1057 | | | | packet or | |
1058 | | | | chunks of one | |
1059 | | | | packet to | |
1060 | | | | multiple LFBs. | |
1061 | | | | | |
1062 | 19 | Merger | 1.0 | A merger LFB | This |
1063 | | | | receives | document |
1064 | | | | multiple | |
1065 | | | | packets or | |
1066 | | | | multiple | |
1067 | | | | chunks of the | |
1068 | | | | same packet | |
1069 | | | | and merge them | |
1070 | | | | into one. | |
1071 | | | | | |
1072 | 20 | CoreParallelizat | 1.0 | A core LFB to | This |
1073 | | ion | | signify the pa | document |
1074 | | | | rallelization | |
1075 | | | | capability | |
1076 +----------+------------------+---------+----------------+----------+
1078 Logical Functional Block (LFB) Class Names and Class Identifiers
1080 8.2. Metadata ID
1082 The Metadata ID namespace is 32 bits long. Values assigned by this
1083 specification:
1085 +------------+---------------------+---------------+
1086 | Value | Name | Definition |
1087 +------------+---------------------+---------------+
1088 | 0x00000010 | ParallelMetadataSet | This document |
1089 +------------+---------------------+---------------+
1091 Metadata ID assigned by this specification
1093 9. Security Considerations
1095 10. References
1097 10.1. Normative References
1099 [I-D.ietf-forces-model-extension]
1100 Haleplidis, E., "ForCES Model Extension", draft-ietf-
1101 forces-model-extension-01 (work in progress), November
1102 2013.
1104 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
1105 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
1106 Control Element Separation (ForCES) Protocol
1107 Specification", RFC 5810, March 2010.
1109 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
1110 Element Separation (ForCES) Forwarding Element Model", RFC
1111 5812, March 2010.
1113 [RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
1114 Halpern, "Forwarding and Control Element Separation
1115 (ForCES) Logical Function Block (LFB) Library", RFC 6956,
1116 June 2013.
1118 10.2. Informative References
1120 [Cilc] MIT, "Cilk language",
1121 .
1123 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1124 Requirement Levels", BCP 14, RFC 2119, March 1997.
1126 Authors' Addresses
1128 Evangelos Haleplidis
1129 University of Patras
1130 Department of Electrical and Computer Engineering
1131 Patras 26500
1132 Greece
1134 Email: ehalep@ece.upatras.gr
1135 Joel Halpern
1136 Ericsson
1137 P.O. Box 6049
1138 Leesburg 20178
1139 VA
1141 Phone: +1 703 371 3043
1142 Email: joel.halpern@ericsson.com