idnits 2.17.1
draft-ietf-forces-packet-parallelization-02.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 (September 5, 2014) is 3520 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Outdated reference: A later version (-05) exists of
draft-ietf-forces-model-extension-04
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: March 9, 2015 Ericsson
6 September 5, 2014
8 ForCES Packet Parallelization
9 draft-ietf-forces-packet-parallelization-02
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 FEs accordingly. More specifically, the model describes
21 the logical functions that are present in an FE, what capabilities
22 these 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 March 9, 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 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 ForCES Model [RFC5812] presents a formal way to describe the
105 Forwarding Plane's datapath with Logical Function Blocks (LFBs) using
106 XML. This document describes how packet parallelization can be
107 described with the ForCES model.
109 The modelling concept has been influenced by Cilc [Cilc]. Cilc is a
110 programming language that has been developed since 1994 at the MIT
111 Laboratory to allow programmers to identify elements that can be
112 executed in parallel. The two Cilc concepts used in this document is
113 spawn and sync. Spawn being the place where parallel tasks can start
114 and sync being the place where the parallel task finishes and must
115 collect all parallel output.
117 As task, we define a grouping of packets or pieces of a packet
118 (chunks) that belong to the same original packet and are going to be
119 processed in parallel. All packets/chunks of the same task will be
120 distinguished by an identifier, in the specific case we use a 32-bit
121 identifier named task correlator.
123 Being an experimental document the LFB Class IDs cannot be included
124 in the standard action's value and therefore must have a value of
125 larger than 65535 and must begin with prefix 'Ext-'. However when we
126 refer to the LFB Class names in the text of this document (not the
127 formal definitions), we will omit the 'Ext-' prefix.
129 1.1. Requirements Language
131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
133 document are to be interpreted as described in [RFC2119].
135 1.2. Definitions
137 This document follows the terminology defined by the ForCES Model in
138 [RFC5812]. In particular, the reader is expected to be familiar with
139 the following terms:
141 FE Model
142 LFB (Logical Functional Block) Class (or type)
144 LFB Instance
146 LFB Model
148 Element
150 Attribute
152 LFB Metadata
154 ForCES Component
156 LFB Class Library
158 This document also introduces the following terms:
160 Chunk - Pieces of a packet
162 Task - Grouping of packets or chunks belong to the same packet
163 that are processed in parallel
165 Task Correlator - A 32-bit identifier that uniquely distinguishes
166 tasks
168 Split Type - A parallel type where the packets are split into
169 chunks to be processed in parallel. Each task in a split type is
170 composed only of chunks.
172 Flood Type - A parallel type where the packets are copied as is to
173 downstream LFBs to be processed in parallel. Each task in a flood
174 type is composed only of packets.
176 2. Packet Parallelization
178 This document addresses the following two types of packet
179 parallelization:
181 1. Flood - where a copy of a packet is sent to multiple LFBs to be
182 processed in parallel.
184 2. Split - where the packet will be split in equal size chunks
185 specified by the CE and sent to multiple LFB instances probably
186 of the same LFB class to be processed in parallel.
188 It must be noted that the process of copying the packet in the Flood
189 parallel type is implementation dependent and is loosely defined
190 here. An implementer may either decide to physical copy the packet
191 and send all packets on the parallel paths, or may decide to
192 logically copy the packet by simply sending, for example, pointers of
193 the same packet provided that the necessary interlocks are taken into
194 account. The implementer has to take into account the device's
195 characteristics to decide which approach fits best to the device.
197 In the split parallel type, while harder, the implementer may also
198 decide to logically split the packet and send, for example, pointers
199 to parts of the packet, provided that the necessary interlocks are
200 managed. In addition, how chunks are distributed to the LFBs, e.g.
201 which chunk to which LFB, is implementation dependent. For example
202 while usually chunks are sent to the same LFB class, the number of
203 LFB instances may not equal to the number of chunks. It is up to the
204 implementer to decide how these chunks will be sent, for example in a
205 round-robin fashion.
207 This document introduces two LFBs that are used in before and after
208 the parallelization occurs:
210 1. Splitter - similar to Cilc's spawn. An LFB that will split the
211 path of a packet which will be sent to multiple downstream LFBs
212 to be processed in parallel.
214 2. Merger - similar to Cilc's sync. An LFB that will receive
215 packets or chunks of the same initial packet and merge them and
216 the results into one packet.
218 Both parallel packet distribution types can currently be achieved
219 with the ForCES model. The splitter LFB has one group output that
220 produces either chunks or packets to be sent to LFBs for processing
221 and the merger LFB has one group input that expects either packets or
222 chunks to aggregate all the parallel packets or chunks and produce a
223 single packet. Figure 1 shows a simple example of a split parallel
224 datapath along with the splitter and merger LFB. Figure 2 shows an
225 example of a flood parallel datapath along with the splitter and
226 merger LFB.
228 C1+M +------------+ C1+M
229 +---->| Regex LFB |----+
230 +----------+ | +------------+ | +----------+
231 | |---+ +------>| |
232 P | | C2+M +------------+ C2+M | | P
233 --->| Splitter |-------->| Regex LFB |----------->| Merger |--->
234 | LFB | CN+M +------------+ CN+M | LFB |
235 | |---+ +------>| |
236 +----------+ | +------------+ | +----------+
237 +---->| Regex LFB |----+
238 +------------+
240 Figure 1: Simple split parallel processing
242 +----------+ +------------+ +-------+ +----------+
243 | |P+M | Classifier |P+M | Meter |P+M | |
244 P | |--->| LFB |--->| LFB |--->| | P
245 --->| Splitter | +------------+ +-------+ | Merger |--->
246 | LFB | | LFB |
247 | |P+M +------------+ P+M | |
248 | |--------->| IPv4 TTL |---------->| |
249 +----------+ | Decrement | +----------+
250 | LFB |
251 +------------+
253 Figure 2: Simple flood parallel processing
255 This version of the modelling framework does not allow for nested
256 parallel datapath topologies. This decision was reached by the
257 authors and the ForCES working group as there was no strong use case
258 or need at decision time. This led to a simpler metadata definition,
259 which was needed to be transported between the splitter and the
260 corresponding merger. If there is a need for nested parallel
261 datapaths a new version of a splitter and merger will be needed to be
262 defined as well as an augmentation to the defined metadata.
264 2.1. Core parallelization LFB
266 One important element to a developer is the ability to define which
267 LFBs can be used in a parallel mode, which LFBs can be parallelized
268 with which as well as the order in which parallel LFBs can be
269 assembled.
271 To access the parallelization details, we opted for defining a new
272 LFB class - the CoreParallelization LFB. This choice was an
273 alternative to making another change to the core FEObject LFB. The
274 CoreParallelization exists merely to define the capabilities for an
275 FE's LFB parallelization. A CE using the ForCES Protocol [RFC5810]
276 can check the existence of this LFB class in the FEObject's
277 SupportedLFBs component. The existence of the CoreParallelization
278 LFB will indicate to the CE that the specific FE supports
279 parallelization. There MUST be only one instance of the
280 CoreParallelization LFB per FE.
282 The topology of the parallel datapath can be deferred and manipulated
283 from the FEObject LFB's LFBTopology.
285 The CoreParallelization requires only one capability in order to
286 specify each LFB that can be used in a parallel mode:
288 o The Name of the LFB.
290 o The Class ID of the LFB.
292 o The Version of the LFB.
294 o The number of instances that class can support in parallel.
296 o A list of LFB classes that can follow this LFB class in a pipeline
297 for a parallel path.
299 o A list of LFB classes that can exist before this LFB class in a
300 pipeline for a parallel path.
302 o A list of LFB classes that can process packets or chunks in
303 parallel with this LFB class.
305
306
307 ParallelLFBType
308 Table entry for parallel LFBs
309
310
311 LFBName
312 The name of an LFB Class
313 string
314
315
316 LFBClassID
317 The id of the LFB Class
318 uint32
319
320
321 LFBVersion
322 The version of the LFB Class used by this FE
323
324 string
325
326
327 LFBParallelOccurenceLimit
328 The upper limit of instances of the same
329 parallel LFBs of this class
330
331 uint32
332
333
334 AllowedParallelAfters
335 List of LFB Classes that can follow this LFB
336 in a parallel pipeline
337
338
339 uint32
340
341
342
343 AllowedParallelBefores
344 List of LFB Classes that this LFB class can
345 follow in a parallel pipeline
346
347
348 uint32
349
350
351
352 AllowedParallel
353 List of LFB Classes that this LFB class be run
354 in parallel with
355
356 uint32
357
358
359
360
362
363
364 ParallelLFBs
365 List of all supported parallel LFBs
366
367 ParallelLFBType
368
369
371 Figure 3: XML Definitions for CoreParallelization LFB
373 2.2. Parallelization metadata
375 It is expected that the splitting and merging mechanisms are an
376 implementation issue. This document plays the role of defining the
377 operational parameters for the splitting and merging, namely, the
378 size of the chunks, what happens if a packet or chunk has been marked
379 as invalid and whether the merge LFB should wait for all packets or
380 chunks to arrive. The following metadata set is defined as a struct:
382 1. ParallelType - Flood or split
384 2. TaskCorrelator - Identify packets or chunks that belonged to the
385 initial packet that entered the Splitter LFB
387 3. ParallelNum - Sequence Number of the packet or the chunk for a
388 specific task.
390 4. ParralelPartsCount - Total number of packets or chunks for a
391 specific task.
393 This metadata is produced from the Splitter LFB and is opaque to LFBs
394 in parallel paths and is passed along to the merger LFB without being
395 consumed.
397 In the case in which an LFB decides that a packet/chunk has to be
398 dropped, the LFB MAY drop the packet/chunk but the metadata MUST be
399 sent to the Merger LFB's InvalidIn input port for merging purposes.
401 Additional metadata produced by LFBs inside a datapath MAY be
402 aggregated within the Merger LFB and sent on after the merging
403 process. In case of receiving the same metadata definition with
404 multiple values the merger LFB MUST keep the first received from a
405 valid packet or chunk.
407 3. Parallel Base Types
409 3.1. Frame Types
411 One frame type has been defined in this library.
413 +---------------+---------------------------------------------------+
414 | Frame Type | Synopsis |
415 | Name | |
416 +---------------+---------------------------------------------------+
417 | Chunk | A chunk is a frame that is part of an original |
418 | | larger frame |
419 +---------------+---------------------------------------------------+
421 Parallel Frame Types
423 3.2. Data Types
425 One data type has been defined in this library.
427 +---------------+------------------------+--------------------------+
428 | DataType Name | Type | Synopsis |
429 +---------------+------------------------+--------------------------+
430 | ParallelTypes | Atomic uchar. Special | The type of |
431 | | Values Flood (0), | parallelization this |
432 | | Split (1). | packet will go through |
433 +---------------+------------------------+--------------------------+
435 Parallel Data Types
437 3.3. MetaData Types
439 The following metadata structure with ID 16, using the ForCES model
440 extension [I-D.ietf-forces-model-extension], is defined for the
441 parallelization library:
443 +--------------------+--------+----+--------------------------------+
444 | Metadata Name | Type | ID | Synopsis |
445 +--------------------+--------+----+--------------------------------+
446 | ParallelType | uchar | 1 | The type of parallelization |
447 | | | | this packet will go through. 0 |
448 | | | | for flood, 1 for split. |
449 | | | | |
450 | TaskCorrelator | uint32 | 2 | An identification number to |
451 | | | | specify that a packet or a |
452 | | | | chunks belongs to the same |
453 | | | | parallel task. |
454 | | | | |
455 | ParallelNum | uint32 | 3 | Defines the number of a |
456 | | | | specific packet or chunk of a |
457 | | | | specific task. |
458 | | | | |
459 | ParallelPartsCount | uint32 | 4 | Defines the total number of |
460 | | | | packets or chunks for a |
461 | | | | specific task. |
462 +--------------------+--------+----+--------------------------------+
464 Metadata Structure for Merging
466 4. Parallel LFBs
468 4.1. Splitter
470 The splitter LFB takes part in parallelizing the processing datapath
471 by sending either the same packet Figure 2 or chunks Figure 1 of the
472 same packet to multiple LFBs.
474 +---------------+
475 SplitterIn | | SplitterOut
476 ---------->| Splitter LFB |------------->
477 | |
478 +---------------+
480 Figure 4: Splitter LFB
482 4.1.1. Data Handling
484 The splitter LFB receives any kind of packet via the singleton input,
485 Input. Depending upon the CE's configuration of the ParallelType
486 component, if the parallel type is of type flood (0), the same packet
487 MUST be sent through all of the group output SplitterOut's instances.
488 If the parallel type is of type split (1), the packet will be split
489 into same size chunks except the last which MAY be smaller, with the
490 max size being defined by the ChunkSize component. Chunks MAY be
491 sent out in a round-robin fashion through the group output
492 ParallelOut's instances or in any other way defined by the
493 implementer. Each packet or chunk will be accompanied by the
494 following metadata set as a struct:
496 o ParallelType - The parallel type, split or flood.
498 o ParallelID - generated by the splitter LFB to identify that chunks
499 or packets belong to the same parallel task.
501 o ParallelNum - each chunk or packet of a parallel id will be
502 assigned a number in order for the merger LFB to know when it has
503 gathered them all along with the ParallelPartsCount metadata.
505 o ParallelPartsCount - the number of chunks or packets for the
506 specific task.
508 4.1.2. Components
510 The splitter LFB has only two components. The first is the
511 ParallelType, an uint32 that defines how the packet will be processed
512 by the Splitter LFB. The second is the ChunkSize, an uint32 that
513 specifies the size of each chunk when a packet is split into multiple
514 same size chunks. The last chunk MAY be smaller than the value of
515 the ChunkSize.
517 4.1.3. Capabilities
519 This LFB has only one capability specified, the MinMaxChunkSize a
520 struct of two uint32 to specify the minimum and maximum chunk size.
522 4.1.4. Events
524 This LFB has no events specified.
526 4.2. Merger
528 The merger LFB is the synchronization point for multiple packets or
529 packet chunks of the same task, emanating out of the parallel path as
530 illustrated in Figure 2 and Figure 1.
532 +-------------+
533 MergerIn | |
534 --------->| | MergerOut
535 | Merger LFB |----------->
536 InvalidIn | |
537 --------->| |
538 +-------------+
540 Figure 5: Merger LFB
542 4.2.1. Data Handling
544 The merger LFB receives either a packet or a chunk via the group
545 input ParallelIn, along with the ParallelType metadata that, the
546 TaskCorrelator, the ParallelNum and the ParallelPartsCount.
548 In case that an upstream LFB has dropped a packet or a chunk the
549 merger LFB MAY receive only the metadata or both metadata and packet
550 or chunk through the InvalidIn group input port. It SHOULD receive a
551 metadata specifying the error code. Currently defined metadata's in
552 the Base LFB Library [RFC6956] are the ExceptionID and the
553 ValidateErrorID.
555 If the MergeWaitType is set to false the Merger LFB will initiate the
556 merge process upon receiving the first packet. If false, for each
557 task identified by the task correlator, it will wait for all packets/
558 chunks to arrive unless the MergeWaitTimeoutTimer timer expires. If
559 the MergeWaitTimeoutTimer has expired, the Merger MUST consider the
560 rest of the packets/chuncks, that have not been received, as invalid
561 and MUST handle the packets according to the InvalidAction value.
563 If one packet or chunk has been received through the InvalidIn port
564 then the merging procedure will handle the packets/chuncks according
565 to the InvalidAction value. If the InvalidAction component has been
566 set to 0 then if one packet or chunk is not valid all will dropped,
567 else the process will initiate. Once the merging process has been
568 completed the resulting packet will be sent via the singleton output
569 port MergerOut.
571 If the Merger LFB receives different values for the same metadata
572 from different packets or chunks that has the same task correlator
573 then the Merger LFB will use the first metadata from a packet or
574 chunk that entered the LFB through the MergerIn input port.
576 4.2.2. Components
578 This LFB has the following components specified:
580 1. InvalidAction - a uchar defining what the Merge LFB will do if an
581 invalid chunk or packet is received. If set to 0 (DropAll) the
582 merge will be considered invalid and all chunks or packets will
583 be dropped. If set to 1 (Continue) the merge will continue.
585 2. MergeWaitTimeoutTimer - a uint32 defining the amount of time that
586 the Merger will wait for all packets or chuncks within the same
587 task to arrive before considering them invalid.
589 3. MergeWaitType - a boolean. If true the Merger LFB will wait for
590 all packets or chunks to be received prior to performing the
591 merge. If false, when one packet or a chunk with a response is
592 received by the merge LFB it will start with the merge process.
594 4. InvalidMergesCounter - a uint32 that counts the number of merges
595 where there is at least one packet or chunk that entered the
596 merger LFB through the InvalidIn input port.
598 5. InvalidTotalCounter - a uint 32 that counts the number of merges
599 where all packets/chunks entered the merger LFB through the
600 InvalidIn input port.
602 6. InvalidIDCounters - a struct of two arrays. Each array has a
603 uint32 per row. Each array counts number of invalid merges where
604 at least one packet or chunk entered through InvalidID per error
605 ID. The first array is the InvalidExceptionID and the second is
606 the InvalidValidateErrorID.
608 4.2.3. Capabilities
610 This LFB has no capabilities specified.
612 4.2.4. Events
614 This LFB specifies only two event. The first detects whether the
615 InvalidMergesCounter has exceeded a specific value and the second
616 detects whether the InvalidAllCounter has exceeded a specific value.
617 Both error reports will send the respective counter value. Event
618 Filters can be used to limit the number of messages
620 4.3. CoreParallelization
622 A core LFB that specifies that the FE supports parallelization,
623 instead of updating the FEObject LFB
625 4.3.1. Data Handling
627 The CoreParallelization does not handle data.
629 4.3.2. Components
631 This LFB has no components specified.
633 4.3.3. Capabilities
635 This LFB has only one capability specified. The ParallelLFBs is a
636 table which lists all the LFBs that can be parallelized. Each row of
637 the table contains:
639 1. LFBName - a string. The Name of the parallel LFB.
641 2. LFBClassID - a uint32. The Class ID of the parallel LFB.
643 3. LFBVersion - a string. The Version of the parallel LFB.
645 4. LFBParallelOccurenceLimit - a uint32. The upper limit of
646 instances of the same parallel LFBs of this class.
648 5. AllowedParallelAfters - a table of uint32s (LFB Class IDs). A
649 list of LFB classes that can follow this LFB class in a pipeline
650 for a parallel path.
652 6. AllowedParallelBefores - a table of uint32s (LFB Class IDs). A
653 list of LFB classes that can exist before this LFB class in a
654 pipeline for a parallel path.
656 7. AllowedParallel - a table of uint32s (LFB Class IDs). A list of
657 LFB classes that can process packets or chunks in parallel with
658 this LFB class.
660 4.3.4. Events
662 This LFB specifies no events
664 5. XML for Parallel LFB library
666
667
671
672
673
674 Chunk
675 A chunk is a frame that is part of an original
676 larger frame
677
678
679
680
681 ParallelTypes
682 The type of parallelization this packet will go
683 through
684
685 uchar
686
687
688 Flood
689 The packet/chunk has been sent as a whole
690 to multiple recipients
691
692
693 Split
694 The packet/chunk has been split into
695 multiple chunks and sent to recipients
696
697
698
699
700
701 ParallelLFBType
702 Table entry for parallel LFBs
703
704
705 LFBName
706 The name of an LFB Class
707 string
708
709
710 LFBClassID
711 The id of the LFB Class
712 uint32
713
714
715 LFBVersion
716 The version of the LFB Class used by this FE
717
718 string
719
720
721 LFBParallelOccurenceLimit
722 The upper limit of instances of the same
723 parallel LFBs of this class
724
725 uint32
726
727
728 AllowedParallelAfters
729 List of LFB Classes that can follow this LFB
730 in a parallel pipeline
731
732
733 uint32
734
735
736
737 AllowedParallelBefores
738 List of LFB Classes that this LFB class can
739 follow in a parallel pipeline
740
741
742 uint32
743
744
745
746 AllowedParallel
747 List of LFB Classes that this LFB class be run
748 in parallel with
749
750 uint32
751
752
753
754
755
756
757
758 ParallelMetadataSet
759 A metadata Set for parallelization related LFBs
760
761 32
762
763
764 ParallelType
765 The type of parallelization this packet/chunk
766 has gone through
767 ParallelTypes
768
769
770 TaskCorrelator
771 An identification number to specify that
772 packets or chunks originate from the same packet.
773
774 uint32
775
776
777 ParallelNum
778 Defines the number of the specific packet or
779 chunk of the specific parallel ID.
780 uint32
781
782
783 ParallelPartsCount
784 Defines the total number of packets or chunks
785 for the specific parallel ID.
786 uint32
787
788
789
790
791
792
793 Ext-Splitter
794 A splitter LFB takes part in parallelizing the
795 processing datapath. It will either send the same packet
796 or chunks of one packet to multiple LFBs
797 1.0
798
799
800 SplitterIn
801 An input port expecting any kind of frame
802
803
804
805 [Arbitrary]
806
807
809
810
811
812
813 SplitterOut
814 A parallel output port that sends the same
815 packet to all output instances or chunks of the same
816 packet different chunk on each instance.
817
818
819 [Arbitrary]
820 [Chunk]
821
822
823 [ParallelMetadataSet]
824
825
826
827
828
829
830 ParallelType
831 The type of parallelization this packet will
832 go through
833 ParallelTypes
834
835
836 ChunkSize
837 The size of a chunk when a packet is split
838 into multiple same size chunks
839 uint32
840
841
842
843
844 MinMaxChunkSize
845 The minimum and maximum size of a chunk
846 capable of split by this LFB
847
848
849 MinChunkSize
850 Minimum chunk size
851
852 uint32
853
854
855 MaxChunkSize
856 Maximum chunk size
857 uint32
858
859
860
861
862
863
864 Ext-Merger
865 A merger LFB receives multiple packets or multiple
866 chunks of the same packet and merge them into one merged
867 packet
868 1.0
869
870
871 MergerIn
872 A parallel input port that accepts packets
873 or chunks from all output instances
874
875
876 [Arbitrary]
877 [Chunk]
878
879
880 [ParallelMetadataSet]
881
882
883
884
885 InvalidIn
886 When a packet is sent out of an error port of
887 an LFB in a parallel path will be sent to this
888 output port in the Merger LFB
889
890
891 [Arbitrary]
892 [Chunk]
893
894
895
896 [ExceptionID]
897 [ValidateErrorID]
898
899
900
901
902
903
904
905 MergerOut
906 An output port expecting any kind of frame
907
908
909
910 [Arbitrary]
911
912
913
914
915
916
917 InvalidAction
918 What the Merge LFB will do if an invalid
919 chunk or packet is received
920
921 uchar
922
923
924 DropAll
925 Drop all packets or chunks
926
927
928
929 Continue
930 Continue with the merge
931
932
933
934
935
936 MergeWaitType
937 Whether the Merge LFB will wait for all
938 packets or chunks to be received prior to sending
939 out a response
940 boolean
941
942
943 MergeWaitTimeoutTimer
944 The time that the Merger will wait
945 for all packets or chuncks within the same task to arrive
946 before considering them invalid.
947 uint32
948
949
950 InvalidMergesCounter
951 Counts the number of merges where there is at
952 least one packet/chunk that entered the merger LFB
953 through the InvalidIn input port
954 uint32
955
956
957 InvalidTotalCounter
958 Counts the number of merges where all
959 packets/chunks entered the merger LFB through the
960 InvalidIn input port
961 uint32
962
963
964 InvalidIDCounters
965 Counts number of invalid merges where at
966 least one packet/chunk entered through InvalidID per
967 error ID
968
969
970 InvalidExceptionID
971 Per Exception ID
972
973 uint32
974
975
976
977 InvalidValidateErrorID
978 Per Validate Error ID
979
980 uint32
981
982
983
984
985
986
987
988 ManyInvalids
989 An event that specifies if there are too many
990 invalids
991
992 InvalidCounter
993
994
995
996
997 InvalidMergesCounter
998
999
1000
1001
1002 ManyTotalInvalids
1003 An event that specifies if there are too many
1004 invalids
1005
1006 InvalidTotalCounter
1007
1008
1009
1010
1011 InvalidTotalCounter
1012
1013
1014
1015
1016
1017
1018 Ext-CoreParallelization
1019 A core LFB that specifies that the FE supports
1020 parallelization, instead of updating the FEObject
1021 LFB
1022 1.0
1023
1024
1025 ParallelLFBs
1026 A table which lists all the LFBs that can be
1027 parallelized
1028
1029 ParallelLFBType
1030
1031
1032
1033
1034
1035
1037 Figure 6: Parallel LFB library
1039 6. Acknowledgements
1041 The authors would like to thank Edward Crabbe for the initial
1042 discussion that led to the creation of this document and Jamal Hadi
1043 Salim and Dave Hood for comments and discussions that made this
1044 document better.
1046 7. IANA Considerations
1048 7.1. LFB Class Names and LFB Class Identifiers
1050 LFB classes defined by this document do not belong to LFBs defined by
1051 Standards Track RFCs in the http://www.iana.org/assignments/forces/
1052 forces.xml registry. As such the values defined in this document are
1053 in the above 65535 value range.
1055 This specification includes the following LFB class names and LFB
1056 class identifiers:
1058 +----------+--------------------+--------+---------------+----------+
1059 | LFB | LFB Class Name | LFB Ve | Description | Referenc |
1060 | Class Id | | rsion | | e |
1061 | entifier | | | | |
1062 +----------+--------------------+--------+---------------+----------+
1063 | 65537 | Ext-Splitter | 1.0 | A splitter | This |
1064 | | | | LFB will | document |
1065 | | | | either send | |
1066 | | | | the same | |
1067 | | | | packet or | |
1068 | | | | chunks of one | |
1069 | | | | packet to | |
1070 | | | | multiple | |
1071 | | | | LFBs. | |
1072 | | | | | |
1073 | 65538 | Ext-Merger | 1.0 | A merger LFB | This |
1074 | | | | receives | document |
1075 | | | | multiple | |
1076 | | | | packets or | |
1077 | | | | multiple | |
1078 | | | | chunks of the | |
1079 | | | | same packet | |
1080 | | | | and merge | |
1081 | | | | them into | |
1082 | | | | one. | |
1083 | | | | | |
1084 | 65539 | Ext-CoreParalleliz | 1.0 | A core LFB to | This |
1085 | | ation | | signify the p | document |
1086 | | | | arallelizatio | |
1087 | | | | n capability | |
1088 +----------+--------------------+--------+---------------+----------+
1090 Logical Functional Block (LFB) Class Names and Class Identifiers
1092 7.2. Metadata ID
1094 The Metadata ID namespace is 32 bits long. Values assigned by this
1095 specification are:
1097 +------------+---------------------+---------------+
1098 | Value | Name | Definition |
1099 +------------+---------------------+---------------+
1100 | 0x00000010 | ParallelMetadataSet | This document |
1101 +------------+---------------------+---------------+
1103 Metadata ID assigned by this specification
1105 8. Security Considerations
1107 This document does not alter either the ForCES model [RFC5812] or the
1108 ForCES protocol [RFC5810] and as such has no impact on their security
1109 considerations. This document simply defines the operational
1110 parameters and capabilities of LFBs that perform parallelization and
1111 not how parallelization is implemented. However as parallezation
1112 tasks have security issues, a designer or an implementer must take
1113 into account any security considerations that regards packet
1114 parallelization.
1116 9. References
1118 9.1. Normative References
1120 [I-D.ietf-forces-model-extension]
1121 Haleplidis, E., "ForCES Model Extension", draft-ietf-
1122 forces-model-extension-04 (work in progress), August 2014.
1124 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1125 Requirement Levels", BCP 14, RFC 2119, March 1997.
1127 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
1128 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
1129 Control Element Separation (ForCES) Protocol
1130 Specification", RFC 5810, March 2010.
1132 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
1133 Element Separation (ForCES) Forwarding Element Model", RFC
1134 5812, March 2010.
1136 [RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
1137 Halpern, "Forwarding and Control Element Separation
1138 (ForCES) Logical Function Block (LFB) Library", RFC 6956,
1139 June 2013.
1141 9.2. Informative References
1143 [Cilc] MIT, "Cilk language",
1144 .
1146 Authors' Addresses
1148 Evangelos Haleplidis
1149 University of Patras
1150 Department of Electrical and Computer Engineering
1151 Patras 26500
1152 Greece
1154 Email: ehalep@ece.upatras.gr
1156 Joel Halpern
1157 Ericsson
1158 P.O. Box 6049
1159 Leesburg 20178
1160 VA
1162 Phone: +1 703 371 3043
1163 Email: joel.halpern@ericsson.com