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