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