idnits 2.17.00 (12 Aug 2021)
/tmp/idnits5421/draft-ietf-forces-packet-parallelization-03.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 (October 10, 2014) is 2773 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Outdated reference: draft-ietf-forces-model-extension has been published
as RFC 7408
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: Experimental J. Halpern
5 Expires: April 13, 2015 Ericsson
6 October 10, 2014
8 ForCES Packet Parallelization
9 draft-ietf-forces-packet-parallelization-03
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 (RFC 5810), so that Control Elements (CEs) can
20 control the Forwarding Elements (FEs) accordingly. More
21 specifically, the model describes the logical functions that are
22 present in an FE, what capabilities these functions support, and how
23 these functions are or can be 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 April 13, 2015.
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
65 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
66 2. Packet Parallelization . . . . . . . . . . . . . . . . . . . 4
67 2.1. Core parallelization LFB . . . . . . . . . . . . . . . . 6
68 2.2. Parallelization metadata . . . . . . . . . . . . . . . . 9
69 3. Parallel Base Types . . . . . . . . . . . . . . . . . . . . . 9
70 3.1. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 9
71 3.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 10
72 3.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 10
73 4. Parallel LFBs . . . . . . . . . . . . . . . . . . . . . . . . 11
74 4.1. Splitter . . . . . . . . . . . . . . . . . . . . . . . . 11
75 4.1.1. Data Handling . . . . . . . . . . . . . . . . . . . . 11
76 4.1.2. Components . . . . . . . . . . . . . . . . . . . . . 12
77 4.1.3. Capabilities . . . . . . . . . . . . . . . . . . . . 12
78 4.1.4. Events . . . . . . . . . . . . . . . . . . . . . . . 12
79 4.2. Merger . . . . . . . . . . . . . . . . . . . . . . . . . 12
80 4.2.1. Data Handling . . . . . . . . . . . . . . . . . . . . 13
81 4.2.2. Components . . . . . . . . . . . . . . . . . . . . . 14
82 4.2.3. Capabilities . . . . . . . . . . . . . . . . . . . . 14
83 4.2.4. Events . . . . . . . . . . . . . . . . . . . . . . . 14
84 4.3. CoreParallelization . . . . . . . . . . . . . . . . . . . 15
85 4.3.1. Data Handling . . . . . . . . . . . . . . . . . . . . 15
86 4.3.2. Components . . . . . . . . . . . . . . . . . . . . . 15
87 4.3.3. Capabilities . . . . . . . . . . . . . . . . . . . . 15
88 4.3.4. Events . . . . . . . . . . . . . . . . . . . . . . . 15
89 5. XML for Parallel LFB library . . . . . . . . . . . . . . . . 16
90 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
92 7.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 24
93 7.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 25
95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
97 9.1. Normative References . . . . . . . . . . . . . . . . . . 25
98 9.2. Informative References . . . . . . . . . . . . . . . . . 26
99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
101 1. Introduction
103 A lot of network devices can process packets in a parallel manner.
104 The Forwarding and Control Element Separation (ForCES) Model
105 [RFC5812] presents a formal way to describe the Forwarding Plane's
106 datapath with Logical Function Blocks (LFBs) using XML. This
107 document describes how packet parallelization can be described with
108 the ForCES model.
110 The modeling concept has been influenced by Cilk [Cilk]. Cilk is a
111 programming language that has been developed since 1994 at the MIT
112 Laboratory to allow programmers to identify elements that can be
113 executed in parallel. The two Cilk concepts used in this document is
114 spawn and sync. Spawn being the place where parallel tasks can start
115 and sync being the place where the parallel task finishes and must
116 collect all parallel output.
118 As task, we define a grouping of packets or pieces of a packet
119 (chunks) that belong to the same original packet and are going to be
120 processed in parallel. All packets/chunks of the same task will be
121 distinguished by an identifier, in the specific case we use a 32-bit
122 identifier named task correlator.
124 This document is in the experimental track and thus the LFB Class IDs
125 will not be included in the standard action's values. Therefore the
126 LFB Class IDs must have a value larger than 65535 and the LFB names
127 must begin with the prefix 'Ext-'. However for brevity, when we
128 refer to the LFB Class names in the text of this document (not the
129 formal definitions), the 'Ext-' prefix will be omitted.
131 1.1. Requirements Language
133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
135 document are to be interpreted as described in [RFC2119].
137 1.2. Definitions
139 This document follows the terminology defined by the ForCES Model in
140 [RFC5812]. In particular, the reader is expected to be familiar with
141 the following terms:
143 FE
145 CE
147 FE Model
149 LFB (Logical Functional Block) Class (or type)
151 LFB Instance
153 LFB Model
155 Element
157 Attribute
159 LFB Metadata
161 ForCES Component
163 LFB Class Library
165 This document also introduces the following terms:
167 Chunk - Pieces of a packet
169 Task - Grouping of packets or chunks belong to the same packet
170 that are processed in parallel
172 Task Correlator - A 32-bit identifier that uniquely distinguishes
173 tasks
175 Split Type - A parallel type where the packets are split into
176 chunks to be processed in parallel. Each task in a split type is
177 composed only of chunks.
179 Flood Type - A parallel type where the packets are copied as is to
180 downstream LFBs to be processed in parallel. Each task in a flood
181 type is composed only of packets.
183 2. Packet Parallelization
185 This document addresses the following two types of packet
186 parallelization:
188 1. Flood - where a copy of a packet is sent to multiple LFBs to be
189 processed in parallel.
191 2. Split - where the packet will be split in equal size chunks
192 specified by the CE and sent to multiple LFB instances probably
193 of the same LFB class to be processed in parallel.
195 It must be noted that the process of copying the packet in the Flood
196 parallel type is implementation dependent and is loosely defined
197 here. An implementer may either decide to physical copy the packet
198 and send all packets on the parallel paths, or may decide to
199 logically copy the packet by simply sending, for example, pointers of
200 the same packet provided that the necessary interlocks are taken into
201 account. The implementer has to take into account the device's
202 characteristics to decide which approach fits best to the device.
204 In the split parallel type, while harder, the implementer may also
205 decide to logically split the packet and send, for example, pointers
206 to parts of the packet, provided that the necessary interlocks are
207 managed. In addition, how chunks are distributed to the LFBs, e.g.,
208 which chunk to which LFB, is implementation dependent. For example
209 while usually chunks are sent to the same LFB class, the number of
210 LFB instances may not equal to the number of chunks. It is up to the
211 implementer to decide how these chunks will be sent, for example in a
212 round-robin fashion.
214 This document introduces two LFBs that are used in before and after
215 the parallelization occurs:
217 1. Splitter - similar to Cilk's spawn. An LFB that will split the
218 path of a packet which will be sent to multiple downstream LFBs
219 to be processed in parallel.
221 2. Merger - similar to Cilk's sync. An LFB that will receive
222 packets or chunks of the same initial packet and merge them and
223 the results into one packet.
225 Both parallel packet distribution types can currently be achieved
226 with the ForCES model. The splitter LFB has one group output that
227 produces either chunks or packets to be sent to LFBs for processing
228 and the merger LFB has one group input that expects either packets or
229 chunks to aggregate all the parallel packets or chunks and produce a
230 single packet. Figure 1 shows a simple example of a split parallel
231 datapath along with the splitter and merger LFB. Figure 2 shows an
232 example of a flood parallel datapath along with the splitter and
233 merger LFB.
235 C1+M +------------+ C1+M
236 +---->| Regex LFB |----+
237 +----------+ | +------------+ | +----------+
238 | |---+ +------>| |
239 P | | C2+M +------------+ C2+M | | P
240 --->| Splitter |-------->| Regex LFB |----------->| Merger |--->
241 | LFB | CN+M +------------+ CN+M | LFB |
242 | |---+ +------>| |
243 +----------+ | +------------+ | +----------+
244 +---->| Regex LFB |----+
245 +------------+
247 Figure 1: Simple split parallel processing
249 +----------+ +------------+ +-------+ +----------+
250 | |P+M | Classifier |P+M | Meter |P+M | |
251 P | |--->| LFB |--->| LFB |--->| | P
252 --->| Splitter | +------------+ +-------+ | Merger |--->
253 | LFB | | LFB |
254 | |P+M +------------+ P+M | |
255 | |--------->| IPv4 TTL |---------->| |
256 +----------+ | Decrement | +----------+
257 | LFB |
258 +------------+
260 Figure 2: Simple flood parallel processing
262 This version of the modeling framework does not allow for nested
263 parallel datapath topologies. This decision was reached by the
264 authors and the ForCES working group as there was no strong use case
265 or need at decision time. This led to a simpler metadata definition,
266 which was needed to be transported between the splitter and the
267 corresponding merger. If there is a need for nested parallel
268 datapaths a new version of a splitter and merger will be needed to be
269 defined as well as an augmentation to the defined metadata.
271 2.1. Core parallelization LFB
273 One important element to a developer is the ability to define which
274 LFBs can be used in a parallel mode, which LFBs can be parallelized
275 with which as well as the order in which parallel LFBs can be
276 assembled.
278 To access the parallelization details, we opted for defining a new
279 LFB class - the CoreParallelization LFB. This choice was an
280 alternative to making another change to the core FEObject LFB. The
281 CoreParallelization exists merely to define the capabilities for an
282 FE's LFB parallelization. A CE using the ForCES Protocol [RFC5810]
283 can check the existence of this LFB class in the FEObject's
284 SupportedLFBs component. The existence of the CoreParallelization
285 LFB will indicate to the CE that the specific FE supports
286 parallelization. There MUST be only one instance of the
287 CoreParallelization LFB per FE.
289 The topology of the parallel datapath can be deferred and manipulated
290 from the FEObject LFB's LFBTopology.
292 The CoreParallelization requires only one capability in order to
293 specify each LFB that can be used in a parallel mode:
295 o The Name of the LFB.
297 o The Class ID of the LFB.
299 o The Version of the LFB.
301 o The number of instances that class can support in parallel.
303 o A list of LFB classes that can follow this LFB class in a pipeline
304 for a parallel path.
306 o A list of LFB classes that can exist before this LFB class in a
307 pipeline for a parallel path.
309 o A list of LFB classes that can process packets or chunks in
310 parallel with this LFB class.
312
313
314 ParallelLFBType
315 Table entry for parallel LFBs
316
317
318 LFBName
319 The name of an LFB Class
320 string
321
322
323 LFBClassID
324 The id of the LFB Class
325 uint32
326
327
328 LFBVersion
329 The version of the LFB Class used by this FE
330
331 string
332
333
334 LFBParallelOccurrenceLimit
335 The upper limit of instances of the same
336 parallel LFBs of this class
337
338 uint32
339
340
341 AllowedParallelAfters
342 List of LFB Classes that can follow this LFB
343 in a parallel pipeline
344
345
346 uint32
347
348
349
350 AllowedParallelBefores
351 List of LFB Classes that this LFB class can
352 follow in a parallel pipeline
353
354
355 uint32
356
357
358
359 AllowedParallel
360 List of LFB Classes that this LFB class be run
361 in parallel with
362
363 uint32
364
365
366
367
369
370
371 ParallelLFBs
372 List of all supported parallel LFBs
373
374 ParallelLFBType
375
376
378 Figure 3: XML Definitions for CoreParallelization LFB
380 2.2. Parallelization metadata
382 It is expected that the splitting and merging mechanisms are an
383 implementation issue. This document plays the role of defining the
384 operational parameters for the splitting and merging, namely, the
385 size of the chunks, what happens if a packet or chunk has been marked
386 as invalid and whether the merge LFB should wait for all packets or
387 chunks to arrive. The following metadata set is defined as a struct:
389 1. ParallelType - Flood or split
391 2. TaskCorrelator - Identify packets or chunks that belonged to the
392 initial packet that entered the Splitter LFB
394 3. ParallelNum - Sequence Number of the packet or the chunk for a
395 specific task.
397 4. ParralelPartsCount - Total number of packets or chunks for a
398 specific task.
400 This metadata is produced from the Splitter LFB and is opaque to LFBs
401 in parallel paths and is passed along to the merger LFB without being
402 consumed.
404 In the case in which an LFB decides that a packet/chunk has to be
405 dropped, the LFB MAY drop the packet/chunk but the metadata MUST be
406 sent to the Merger 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 3. Parallel Base Types
416 3.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 3.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 3.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 | TaskCorrelator | uint32 | 2 | An identification number to |
458 | | | | specify that a packet or a |
459 | | | | chunks belongs to the same |
460 | | | | parallel task. |
461 | | | | |
462 | ParallelNum | uint32 | 3 | Defines the number of a |
463 | | | | specific packet or chunk of a |
464 | | | | specific task. |
465 | | | | |
466 | ParallelPartsCount | uint32 | 4 | Defines the total number of |
467 | | | | packets or chunks for a |
468 | | | | specific task. |
469 +--------------------+--------+----+--------------------------------+
471 Metadata Structure for Merging
473 4. Parallel LFBs
475 4.1. Splitter
477 The splitter LFB takes part in parallelizing the processing datapath
478 by sending either the same packet Figure 2 or chunks Figure 1 of the
479 same packet to multiple LFBs.
481 +---------------+
482 SplitterIn | | SplitterOut
483 ---------->| Splitter LFB |------------->
484 | |
485 +---------------+
487 Figure 4: Splitter LFB
489 4.1.1. Data Handling
491 The splitter LFB receives any kind of packet via the singleton input,
492 Input. Depending upon the CE's configuration of the ParallelType
493 component, if the parallel type is of type flood (0), the same packet
494 MUST be sent through all of the group output SplitterOut's instances.
495 If the parallel type is of type split (1), the packet will be split
496 into same size chunks except the last which MAY be smaller, with the
497 max size being defined by the ChunkSize component. Chunks MAY be
498 sent out in a round-robin fashion through the group output
499 ParallelOut's instances or in any other way defined by the
500 implementer. Each packet or chunk will be accompanied by the
501 following metadata set as a struct:
503 o ParallelType - The parallel type, split or flood.
505 o ParallelID - generated by the splitter LFB to identify that chunks
506 or packets belong to the same parallel task.
508 o ParallelNum - each chunk or packet of a parallel id will be
509 assigned a number in order for the merger LFB to know when it has
510 gathered them all along with the ParallelPartsCount metadata.
512 o ParallelPartsCount - the number of chunks or packets for the
513 specific task.
515 4.1.2. Components
517 The splitter LFB has only two components. The first is the
518 ParallelType, an uint32 that defines how the packet will be processed
519 by the Splitter LFB. The second is the ChunkSize, an uint32 that
520 specifies the size of each chunk when a packet is split into multiple
521 same size chunks. The last chunk MAY be smaller than the value of
522 the ChunkSize.
524 4.1.3. Capabilities
526 This LFB has only one capability specified, the MinMaxChunkSize a
527 struct of two uint32 to specify the minimum and maximum chunk size.
529 4.1.4. Events
531 This LFB has no events specified.
533 4.2. Merger
535 The merger LFB is the synchronization point for multiple packets or
536 packet chunks of the same task, emanating out of the parallel path as
537 illustrated in Figure 2 and Figure 1.
539 +-------------+
540 MergerIn | |
541 --------->| | MergerOut
542 | Merger LFB |----------->
543 InvalidIn | |
544 --------->| |
545 +-------------+
547 Figure 5: Merger LFB
549 4.2.1. Data Handling
551 The merger LFB receives either a packet or a chunk via the group
552 input ParallelIn, along with the ParallelType metadata that, the
553 TaskCorrelator, the ParallelNum and the ParallelPartsCount.
555 In case that an upstream LFB has dropped a packet or a chunk the
556 merger LFB MAY receive only the metadata or both metadata and packet
557 or chunk through the InvalidIn group input port. It SHOULD receive a
558 metadata specifying the error code. Currently defined metadata's in
559 the Base LFB Library [RFC6956] are the ExceptionID and the
560 ValidateErrorID.
562 If the MergeWaitType is set to false the Merger LFB will initiate the
563 merge process upon receiving the first packet. If false, for each
564 task identified by the task correlator, it will wait for all packets/
565 chunks to arrive unless the MergeWaitTimeoutTimer timer expires. If
566 the MergeWaitTimeoutTimer has expired, the Merger MUST consider the
567 rest of the packets/chuncks, that have not been received, as invalid
568 and MUST handle the packets according to the InvalidAction value.
570 If one packet or chunk has been received through the InvalidIn port
571 then the merging procedure will handle the packets/chuncks according
572 to the InvalidAction value. If the InvalidAction component has been
573 set to 0 then if one packet or chunk is not valid all will dropped,
574 else the process will initiate. Once the merging process has been
575 completed the resulting packet will be sent via the singleton output
576 port MergerOut.
578 If the Merger LFB receives different values for the same metadata
579 from different packets or chunks that has the same task correlator
580 then the Merger LFB will use the first metadata from a packet or
581 chunk that entered the LFB through the MergerIn input port.
583 4.2.2. Components
585 This LFB has the following components specified:
587 1. InvalidAction - a uchar defining what the Merge LFB will do if an
588 invalid chunk or packet is received. If set to 0 (DropAll) the
589 merge will be considered invalid and all chunks or packets will
590 be dropped. If set to 1 (Continue) the merge will continue.
592 2. MergeWaitTimeoutTimer - a uint32 defining the amount of time, in
593 milliseconds, that the Merger will wait for all packets or
594 chuncks within the same task to arrive before considering them
595 invalid. The MergeWaitTimeoutTimer starts as soon as the first
596 chunk or packet of a parallel task arrives.
598 3. MergeWaitType - a boolean. If true the Merger LFB will wait for
599 all packets or chunks to be received prior to performing the
600 merge. If false, when one packet or a chunk with a response is
601 received by the merge LFB it will start with the merge process.
603 4. InvalidMergesCounter - a uint32 that counts the number of merges
604 where there is at least one packet or chunk that entered the
605 merger LFB through the InvalidIn input port.
607 5. InvalidTotalCounter - a uint32 that counts the number of merges
608 where all packets/chunks entered the merger LFB through the
609 InvalidIn input port.
611 6. InvalidIDCounters - a struct of two arrays. Each array has a
612 uint32 per row. Each array counts number of invalid merges where
613 at least one packet or chunk entered through InvalidID per error
614 ID. The first array is the InvalidExceptionID and the second is
615 the InvalidValidateErrorID.
617 4.2.3. Capabilities
619 This LFB has no capabilities specified.
621 4.2.4. Events
623 This LFB specifies only two event. The first detects whether the
624 InvalidMergesCounter has exceeded a specific value and the second
625 detects whether the InvalidAllCounter has exceeded a specific value.
626 Both error reports will send the respective counter value. Event
627 Filters can be used to limit the number of messages
629 4.3. CoreParallelization
631 A core LFB that specifies that the FE supports parallelization,
632 instead of updating the FEObject LFB
634 4.3.1. Data Handling
636 The CoreParallelization does not handle data.
638 4.3.2. Components
640 This LFB has no components specified.
642 4.3.3. Capabilities
644 This LFB has only one capability specified. The ParallelLFBs is a
645 table which lists all the LFBs that can be parallelized. Each row of
646 the table contains:
648 1. LFBName - a string. The Name of the parallel LFB.
650 2. LFBClassID - a uint32. The Class ID of the parallel LFB.
652 3. LFBVersion - a string. The Version of the parallel LFB.
654 4. LFBParallelOccurrenceLimit - a uint32. The upper limit of
655 instances of the same parallel LFBs of this class.
657 5. AllowedParallelAfters - a table of uint32s (LFB Class IDs). A
658 list of LFB classes that can follow this LFB class in a pipeline
659 for a parallel path.
661 6. AllowedParallelBefores - a table of uint32s (LFB Class IDs). A
662 list of LFB classes that can exist before this LFB class in a
663 pipeline for a parallel path.
665 7. AllowedParallel - a table of uint32s (LFB Class IDs). A list of
666 LFB classes that can process packets or chunks in parallel with
667 this LFB class.
669 4.3.4. Events
671 This LFB specifies no events
673 5. XML for Parallel LFB library
675
676
680
681
682
683 Chunk
684 A chunk is a frame that is part of an original
685 larger frame
686
687
688
689
690 ParallelTypes
691 The type of parallelization this packet will go
692 through
693
694 uchar
695
696
697 Flood
698 The packet/chunk has been sent as a whole
699 to multiple recipients
700
701
702 Split
703 The packet/chunk has been split into
704 multiple chunks and sent to recipients
705
706
707
708
709
710 ParallelLFBType
711 Table entry for parallel LFBs
712
713
714 LFBName
715 The name of an LFB Class
716 string
717
718
719 LFBClassID
720 The id of the LFB Class
721 uint32
722
723
724 LFBVersion
725 The version of the LFB Class used by this FE
726
727 string
728
729
730 LFBParallelOccurrenceLimit
731 The upper limit of instances of the same
732 parallel LFBs of this class
733
734 uint32
735
736
737 AllowedParallelAfters
738 List of LFB Classes that can follow this LFB
739 in a parallel pipeline
740
741
742 uint32
743
744
745
746 AllowedParallelBefores
747 List of LFB Classes that this LFB class can
748 follow in a parallel pipeline
749
750
751 uint32
752
753
754
755 AllowedParallel
756 List of LFB Classes that this LFB class be run
757 in parallel with
758
759 uint32
760
761
762
763
764
765
766
767 ParallelMetadataSet
768 A metadata Set for parallelization related LFBs
769
770 32
771
772
773 ParallelType
774 The type of parallelization this packet/chunk
775 has gone through
776 ParallelTypes
777
778
779 TaskCorrelator
780 An identification number to specify that
781 packets or chunks originate from the same packet.
782
783 uint32
784
785
786 ParallelNum
787 Defines the number of the specific packet or
788 chunk of the specific parallel ID.
789 uint32
790
791
792 ParallelPartsCount
793 Defines the total number of packets or chunks
794 for the specific parallel ID.
795 uint32
796
797
798
799
800
801
802 Ext-Splitter
803 A splitter LFB takes part in parallelizing the
804 processing datapath. It will either send the same packet
805 or chunks of one packet to multiple LFBs
806 1.0
807
808
809 SplitterIn
810 An input port expecting any kind of frame
811
812
813
814 [Arbitrary]
815
816
818
819
820
821
822 SplitterOut
823 A parallel output port that sends the same
824 packet to all output instances or chunks of the same
825 packet different chunk on each instance.
826
827
828 [Arbitrary]
829 [Chunk]
830
831
832 [ParallelMetadataSet]
833
834
835
836
837
838
839 ParallelType
840 The type of parallelization this packet will
841 go through
842 ParallelTypes
843
844
845 ChunkSize
846 The size of a chunk when a packet is split
847 into multiple same size chunks
848 uint32
849
850
851
852
853 MinMaxChunkSize
854 The minimum and maximum size of a chunk
855 capable of split by this LFB
856
857
858 MinChunkSize
859 Minimum chunk size
860
861 uint32
862
863
864 MaxChunkSize
865 Maximum chunk size
866 uint32
867
868
869
870
871
872
873 Ext-Merger
874 A merger LFB receives multiple packets or multiple
875 chunks of the same packet and merge them into one merged
876 packet
877 1.0
878
879
880 MergerIn
881 A parallel input port that accepts packets
882 or chunks from all output instances
883
884
885 [Arbitrary]
886 [Chunk]
887
888
889 [ParallelMetadataSet]
890
891
892
893
894 InvalidIn
895 When a packet is sent out of an error port of
896 an LFB in a parallel path will be sent to this
897 output port in the Merger LFB
898
899
900 [Arbitrary]
901 [Chunk]
902
903
904
905 [ExceptionID]
906 [ValidateErrorID]
907
908
909
910
911
912
913
914 MergerOut
915 An output port expecting any kind of frame
916
917
918
919 [Arbitrary]
920
921
922
923
924
925
926 InvalidAction
927 What the Merge LFB will do if an invalid
928 chunk or packet is received
929
930 uchar
931
932
933 DropAll
934 Drop all packets or chunks
935
936
937
938 Continue
939 Continue with the merge
940
941
942
943
944
945 MergeWaitType
946 Whether the Merge LFB will wait for all
947 packets or chunks to be received prior to sending
948 out a response
949 boolean
950
951
952 MergeWaitTimeoutTimer
953 The time that the Merger will wait
954 for all packets or chuncks within the same task to arrive
955 before considering them invalid.
956 uint32
957
958
959 InvalidMergesCounter
960 Counts the number of merges where there is at
961 least one packet/chunk that entered the merger LFB
962 through the InvalidIn input port
963 uint32
964
965
966 InvalidTotalCounter
967 Counts the number of merges where all
968 packets/chunks entered the merger LFB through the
969 InvalidIn input port
970 uint32
971
972
973 InvalidIDCounters
974 Counts number of invalid merges where at
975 least one packet/chunk entered through InvalidID per
976 error ID
977
978
979 InvalidExceptionID
980 Per Exception ID
981
982 uint32
983
984
985
986 InvalidValidateErrorID
987 Per Validate Error ID
988
989 uint32
990
991
992
993
994
995
996
997 ManyInvalids
998 An event that specifies if there are too many
999 invalids
1000
1001 InvalidCounter
1002
1003
1004
1005
1006 InvalidMergesCounter
1007
1008
1009
1010
1011 ManyTotalInvalids
1012 An event that specifies if there are too many
1013 invalids
1014
1015 InvalidTotalCounter
1016
1017
1018
1019
1020 InvalidTotalCounter
1021
1022
1023
1024
1025
1026
1027 Ext-CoreParallelization
1028 A core LFB that specifies that the FE supports
1029 parallelization, instead of updating the FEObject
1030 LFB
1031 1.0
1032
1033
1034 ParallelLFBs
1035 A table which lists all the LFBs that can be
1036 parallelized
1037
1038 ParallelLFBType
1039
1040
1041
1042
1043
1044
1046 Figure 6: Parallel LFB library
1048 6. Acknowledgments
1050 The authors would like to thank Edward Crabbe for the initial
1051 discussion that led to the creation of this document and Jamal Hadi
1052 Salim and Dave Hood for comments and discussions that made this
1053 document better. Additionally Adrian Farrel for his AD review.
1054 Finally Francis Dupont for his Gen-Art review and Magnus Nystroem for
1055 his security review which refined this document to its final shape.
1057 7. IANA Considerations
1059 7.1. LFB Class Names and LFB Class Identifiers
1061 LFB classes defined by this document do not belong to LFBs defined by
1062 Standards Track RFCs in the http://www.iana.org/assignments/forces
1063 registry. As such the values defined in this document are in the
1064 above 65535 value range.
1066 This specification includes the following LFB class names and LFB
1067 class identifiers:
1069 +----------+--------------------+--------+---------------+----------+
1070 | LFB | LFB Class Name | LFB Ve | Description | Referenc |
1071 | Class Id | | rsion | | e |
1072 | entifier | | | | |
1073 +----------+--------------------+--------+---------------+----------+
1074 | 65537 | Ext-Splitter | 1.0 | A splitter | This |
1075 | | | | LFB will | document |
1076 | | | | either send | |
1077 | | | | the same | |
1078 | | | | packet or | |
1079 | | | | chunks of one | |
1080 | | | | packet to | |
1081 | | | | multiple | |
1082 | | | | LFBs. | |
1083 | | | | | |
1084 | 65538 | Ext-Merger | 1.0 | A merger LFB | This |
1085 | | | | receives | document |
1086 | | | | multiple | |
1087 | | | | packets or | |
1088 | | | | multiple | |
1089 | | | | chunks of the | |
1090 | | | | same packet | |
1091 | | | | and merge | |
1092 | | | | them into | |
1093 | | | | one. | |
1094 | | | | | |
1095 | 65539 | Ext-CoreParalleliz | 1.0 | A core LFB to | This |
1096 | | ation | | signify the p | document |
1097 | | | | arallelizatio | |
1098 | | | | n capability | |
1099 +----------+--------------------+--------+---------------+----------+
1101 Logical Functional Block (LFB) Class Names and Class Identifiers
1103 7.2. Metadata ID
1105 The Metadata ID namespace is 32 bits long. Values assigned by this
1106 specification are:
1108 +------------+---------------------+---------------+
1109 | Value | Name | Definition |
1110 +------------+---------------------+---------------+
1111 | 0x00000010 | ParallelMetadataSet | This document |
1112 +------------+---------------------+---------------+
1114 Metadata ID assigned by this specification
1116 8. Security Considerations
1118 This document does not alter either the ForCES model [RFC5812] or the
1119 ForCES protocol [RFC5810] and as such has no impact on their security
1120 considerations. This document simply defines the operational
1121 parameters and capabilities of LFBs that perform parallelization and
1122 not how parallelization is implemented. Finally, this document does
1123 not attempt to analyze the presence or possibility of security
1124 interactions created by allowing parallel operations on packets. Any
1125 such issues, if they exist, are for the designers of the particular
1126 data path, not the general mechanism.
1128 9. References
1130 9.1. Normative References
1132 [I-D.ietf-forces-model-extension]
1133 Haleplidis, E., "ForCES Model Extension", draft-ietf-
1134 forces-model-extension-05 (work in progress), September
1135 2014.
1137 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1138 Requirement Levels", BCP 14, RFC 2119, March 1997.
1140 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
1141 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
1142 Control Element Separation (ForCES) Protocol
1143 Specification", RFC 5810, March 2010.
1145 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
1146 Element Separation (ForCES) Forwarding Element Model", RFC
1147 5812, March 2010.
1149 [RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
1150 Halpern, "Forwarding and Control Element Separation
1151 (ForCES) Logical Function Block (LFB) Library", RFC 6956,
1152 June 2013.
1154 9.2. Informative References
1156 [Cilk] MIT, "Cilk language",
1157 .
1159 Authors' Addresses
1161 Evangelos Haleplidis
1162 University of Patras
1163 Department of Electrical and Computer Engineering
1164 Patras 26500
1165 Greece
1167 Email: ehalep@ece.upatras.gr
1169 Joel Halpern
1170 Ericsson
1171 P.O. Box 6049
1172 Leesburg VA 20178
1173 USA
1175 Phone: +1 703 371 3043
1176 Email: joel.halpern@ericsson.com