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