GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7409

Internet Engineering Task Force (IETF) E. Haleplidis Request for Comments: 7409 University of Patras Category: Experimental J. Halpern ISSN: 2070-1721 Ericsson

                                                         November 2014
         Forwarding and Control Element Separation (ForCES)
                       Packet Parallelization

Abstract

 Many network devices support parallel packet processing.  This
 document describes how Forwarding and Control Element Separation
 (ForCES) can model a network device's parallelization datapath using
 constructs defined by the ForCES model (RFC 5812) and controlled via
 the ForCES protocol (RFC 5810).

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for examination, experimental implementation, and
 evaluation.
 This document defines an Experimental Protocol for the Internet
 community.  This document is a product of the Internet Engineering
 Task Force (IETF).  It represents the consensus of the IETF
 community.  It has received public review and has been approved for
 publication by the Internet Engineering Steering Group (IESG).  Not
 all documents approved by the IESG are a candidate for any level of
 Internet Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7409.

Haleplidis & Halpern Experimental [Page 1] RFC 7409 ForCES Packet Parallelization November 2014

Copyright Notice

 Copyright (c) 2014 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Haleplidis & Halpern Experimental [Page 2] RFC 7409 ForCES Packet Parallelization November 2014

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   1.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
 2.  Packet Parallelization  . . . . . . . . . . . . . . . . . . .   5
   2.1.  CoreParallelization LFB . . . . . . . . . . . . . . . . .   7
   2.2.  Parallelization Metadata  . . . . . . . . . . . . . . . .  10
 3.  Parallel Base Types . . . . . . . . . . . . . . . . . . . . .  11
   3.1.  Frame Types . . . . . . . . . . . . . . . . . . . . . . .  11
   3.2.  Data Types  . . . . . . . . . . . . . . . . . . . . . . .  11
   3.3.  Metadata Types  . . . . . . . . . . . . . . . . . . . . .  12
 4.  Parallel LFBs . . . . . . . . . . . . . . . . . . . . . . . .  12
   4.1.  Splitter  . . . . . . . . . . . . . . . . . . . . . . . .  12
     4.1.1.  Data Handling . . . . . . . . . . . . . . . . . . . .  13
     4.1.2.  Components  . . . . . . . . . . . . . . . . . . . . .  13
     4.1.3.  Capabilities  . . . . . . . . . . . . . . . . . . . .  13
     4.1.4.  Events  . . . . . . . . . . . . . . . . . . . . . . .  13
   4.2.  Merger  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     4.2.1.  Data Handling . . . . . . . . . . . . . . . . . . . .  14
     4.2.2.  Components  . . . . . . . . . . . . . . . . . . . . .  15
     4.2.3.  Capabilities  . . . . . . . . . . . . . . . . . . . .  15
     4.2.4.  Events  . . . . . . . . . . . . . . . . . . . . . . .  16
   4.3.  CoreParallelization . . . . . . . . . . . . . . . . . . .  16
     4.3.1.  Data Handling . . . . . . . . . . . . . . . . . . . .  16
     4.3.2.  Components  . . . . . . . . . . . . . . . . . . . . .  16
     4.3.3.  Capabilities  . . . . . . . . . . . . . . . . . . . .  16
     4.3.4.  Events  . . . . . . . . . . . . . . . . . . . . . . .  17
 5.  XML for Parallel LFB Library  . . . . . . . . . . . . . . . .  17
 6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
   6.1.  LFB Class Names and LFB Class Identifiers . . . . . . . .  25
   6.2.  Metadata ID . . . . . . . . . . . . . . . . . . . . . . .  26
 7.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
 8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
   8.1.  Normative References  . . . . . . . . . . . . . . . . . .  26
   8.2.  Informative References  . . . . . . . . . . . . . . . . .  27
 Acknowledgments   . . . . . . . . . . . . . . . . . . . . . . . .  27
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

Haleplidis & Halpern Experimental [Page 3] RFC 7409 ForCES Packet Parallelization November 2014

1. Introduction

 A lot of network devices can process packets in a parallel manner.
 The Forwarding and Control Element Separation (ForCES) model
 [RFC5812] presents a formal way to describe the Forwarding Plane's
 datapath with Logical Function Blocks (LFBs) using XML.  This
 document describes how packet parallelization can be described with
 the ForCES model.
 The modeling concept has been influenced by Cilk [Cilk].  Cilk is a
 programming language that has been in development since 1994 at the
 Massachusetts Institute of Technology (MIT) Laboratory.  Cilk allows
 programmers to identify elements that can be executed in parallel.
 The two Cilk concepts used in this document are "spawn" and "sync":
 spawn being the place where parallel tasks can start and sync being
 the place where the parallel task finishes and must collect all
 parallel output (see Section 1.2 for the definitions of both "task"
 and "task correclator").
 This document is Experimental; thus, the LFB Class IDs will not be
 included in the Standard Action's values.  Therefore, the LFB Class
 IDs must have a value larger than 65535, and the LFB names must begin
 with the prefix 'Ext-'.  However, for brevity, when we refer to the
 LFB Class names in the text of this document (not the formal
 definitions), the 'Ext-' prefix will be omitted.

1.1. Requirements Language

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].

1.2. Definitions

 This document follows the terminology defined by the ForCES model in
 [RFC5812].  In particular, the reader is expected to be familiar with
 the following terms:
    FE
    CE
    FE Model
    LFB Class (or type)
    LFB Instance

Haleplidis & Halpern Experimental [Page 4] RFC 7409 ForCES Packet Parallelization November 2014

    LFB Model
    Element
    Attribute
    LFB Metadata
    ForCES Component
    LFB Class Library
 This document also introduces the following terms:
 Chunk:             Pieces of a packet.
 Task:              Grouping of packets or chunks belonging to the
                    same packet that are processed in parallel.
 Task Correlator:   A 32-bit identifier that uniquely distinguishes
                    tasks.
 Split Type:        A parallel type where the packets are split into
                    chunks to be processed in parallel.  Each task in
                    a split type is composed only of chunks.
 Flood Type:        A parallel type where the packets are copied as-is
                    to downstream LFBs to be processed in parallel.
                    Each task in a flood type is composed only of
                    packets.

2. Packet Parallelization

 This document addresses the following two types of packet
 parallelization:
 1.  Flood: Where a copy of a packet is sent to multiple LFBs to be
     processed in parallel.
 2.  Split: Where the packet will be split into chunks of equal size
     specified by the CE and sent to multiple LFB instances, probably
     of the same LFB class, to be processed in parallel.
 It must be noted that the process of copying the packet in the flood
 parallel type is implementation dependent and is loosely defined
 here.  An implementer may either decide to physically copy the packet
 and send all packets on the parallel paths or decide to logically
 copy the packet by simply sending, for example, pointers to the same

Haleplidis & Halpern Experimental [Page 5] RFC 7409 ForCES Packet Parallelization November 2014

 packet provided that the necessary interlocks are taken into account.
 The implementer has to take into account the device's characteristics
 to decide which approach fits best to the device.
 In the split parallel type, while harder, the implementer may also
 decide to logically split the packet and send, for example, pointers
 to parts of the packet, provided that the necessary interlocks are
 managed.  In addition, how chunks are distributed to the LFBs (e.g.,
 which chunk to which LFB) is implementation dependent.  For example,
 while usually chunks are sent to the same LFB class, the number of
 LFB instances may not be equal to the number of chunks.  It is up to
 the implementer to decide how these chunks will be sent, for example,
 in a round-robin fashion.
 This document introduces two LFBs that are used before and after the
 parallelization occurs:
 1.  Splitter: Similar to Cilk's spawn, a splitter is an LFB that will
     split the path of a packet that will be sent to multiple
     downstream LFBs to be processed in parallel.
 2.  Merger: Similar to Cilk's sync, a merger is an LFB that will
     receive packets or chunks of the same initial packet and merge
     them and the results into one packet.
 Both parallel packet distribution types can currently be achieved
 with the ForCES model.  The Splitter LFB has one group output that
 produces either chunks or packets to be sent to LFBs for processing,
 and the Merger LFB has one group input that expects either packets or
 chunks to aggregate all the parallel packets or chunks and produce a
 single packet.
 Figure 1 shows a simple example of a split parallel datapath along
 with the Splitter and Merger LFB.  The example in Figure 1 depicts
 multiple regular expression (regex) match LFBs that perform match
 operations on parts of the original packet.  Figure 2 shows an
 example of a flood parallel datapath along with the Splitter and
 Merger LFB.  The example in Figure 2 depicts a path that will
 classify an IPv4 packet while also performing metering; on the other
 path, the IPv4 Time to Live (TTL) field will be decremented.

Haleplidis & Halpern Experimental [Page 6] RFC 7409 ForCES Packet Parallelization November 2014

                    C1+M   +------------+  C1+M
                     +---->| Regex LFB  |----+
      +----------+   |     +------------+    |       +----------+
      |          |---+                       +------>|          |
   P  |          |  C2+M   +------------+  C2+M      |          | P
  --->| Splitter |-------->| Regex LFB  |----------->|  Merger  |--->
      |   LFB    |  CN+M   +------------+  CN+M      |   LFB    |
      |          |---+                       +------>|          |
      +----------+   |     +------------+    |       +----------+
                     +---->| Regex LFB  |----+
                           +------------+
              Figure 1: Simple Split Parallel Processing
      +----------+    +------------+    +-------+    +----------+
      |          |P+M | Classifier |P+M | Meter |P+M |          |
   P  |          |--->|     LFB    |--->|  LFB  |--->|          | P
  --->| Splitter |    +------------+    +-------+    |  Merger  |--->
      |   LFB    |                                   |   LFB    |
      |          |P+M       +------------+       P+M |          |
      |          |--------->|  IPv4 TTL  |---------->|          |
      +----------+          |  Decrement |           +----------+
                            |    LFB     |
                            +------------+
              Figure 2: Simple Flood Parallel Processing
 This version of the modeling framework does not allow for nested
 parallel datapath topologies.  This decision was reached by the
 authors and the ForCES working group, as there was no strong use case
 or need at decision time.  This led to a simpler metadata definition,
 which is required to be transported between the splitter and the
 corresponding merger.  If there is a need for nested parallel
 datapaths, a new version of a splitter and merger will need to be
 defined, as well as an augmentation to the defined metadata.

2.1. CoreParallelization LFB

 One important element to a developer is the ability to define which
 LFBs can be used in a parallel mode, which LFBs can be parallelized
 with which, as well as the order in which parallel LFBs can be
 assembled.
 To access the parallelization details, we opted for defining a new
 LFB class: the CoreParallelization LFB.  This choice was an
 alternative to making another change to the core FEObject LFB.  The
 CoreParallelization exists merely to define the capabilities for an
 FE's LFB parallelization.  A CE using the ForCES protocol [RFC5810]

Haleplidis & Halpern Experimental [Page 7] RFC 7409 ForCES Packet Parallelization November 2014

 can check the existence of this LFB class in the FEObject's
 SupportedLFBs component.  The existence of the CoreParallelization
 LFB will indicate to the CE that the specific FE supports
 parallelization.  There MUST be only one instance of the
 CoreParallelization LFB per FE.
 The topology of the parallel datapath can be deferred and manipulated
 from the FEObject LFB's LFBTopology.
 The CoreParallelization requires only one capability in order to
 specify each LFB that can be used in a parallel mode:
 o  The Name of the LFB.
 o  The Class ID of the LFB.
 o  The Version of the LFB.
 o  The number of instances that class can support in parallel.
 o  A list of LFB classes that can follow this LFB class in a pipeline
    for a parallel path.
 o  A list of LFB classes that can exist before this LFB class in a
    pipeline for a parallel path.
 o  A list of LFB classes that can process packets or chunks in
    parallel with this LFB class.
    <!-- Datatype -->
    <dataTypeDef>
       <name>ParallelLFBType</name>
       <synopsis>Table entry for parallel LFBs</synopsis>
       <struct>
          <component componentID="1">
             <name>LFBName</name>
             <synopsis>The name of an LFB Class</synopsis>
             <typeRef>string</typeRef>
          </component>
          <component componentID="2">
             <name>LFBClassID</name>
             <synopsis>The id of the LFB Class</synopsis>
             <typeRef>uint32</typeRef>
          </component>
          <component componentID="3">
             <name>LFBVersion</name>
             <synopsis>The version of the LFB Class used by this FE
             </synopsis>

Haleplidis & Halpern Experimental [Page 8] RFC 7409 ForCES Packet Parallelization November 2014

             <typeRef>string</typeRef>
          </component>
          <component componentID="4">
             <name>LFBParallelOccurrenceLimit</name>
             <synopsis>The upper limit of instances of the same
                parallel LFBs of this class</synopsis>
             <optional />
             <typeRef>uint32</typeRef>
          </component>
          <component componentID="5">
             <name>AllowedParallelAfters</name>
             <synopsis>List of LFB Classes that can follow this LFB
                in a parallel pipeline</synopsis>
             <optional />
             <array>
                <typeRef>uint32</typeRef>
             </array>
          </component>
          <component componentID="6">
             <name>AllowedParallelBefores</name>
             <synopsis>List of LFB Classes that this LFB class can
                follow in a parallel pipeline</synopsis>
             <optional />
             <array>
                <typeRef>uint32</typeRef>
             </array>
          </component>
          <component componentID="7">
             <name>AllowedParallel</name>
             <synopsis>List of LFB Classes that this LFB class can run
                in parallel with</synopsis>
             <array>
                <typeRef>uint32</typeRef>
             </array>
          </component>
       </struct>
    </dataTypeDef>
    <!-- Capability -->
          <capability componentID="32">
             <name>ParallelLFBs</name>
             <synopsis>List of all supported parallel LFBs</synopsis>
             <array type="Variable-size">
                <typeRef>ParallelLFBType</typeRef>
             </array>
          </capability>
         Figure 3: XML Definitions for CoreParallelization LFB

Haleplidis & Halpern Experimental [Page 9] RFC 7409 ForCES Packet Parallelization November 2014

2.2. Parallelization Metadata

 It is expected that the splitting and merging mechanisms are an
 implementation issue.  This document plays the role of defining the
 operational parameters for the splitting and merging: namely, the
 size of the chunks, what happens if a packet or chunk has been marked
 as invalid, and whether the merge LFB should wait for all packets or
 chunks to arrive.  The following metadata set is defined as a struct:
 1.  ParallelType - Flood or split
 2.  TaskCorrelator - Identify packets or chunks that belonged to the
     initial packet that entered the Splitter LFB
 3.  ParallelNum - Sequence number of the packet or the chunk for a
     specific task
 4.  ParallelPartsCount - Total number of packets or chunks for a
     specific task
 This metadata is produced from the Splitter LFB, is opaque to LFBs in
 parallel paths, and is passed along to the Merger LFB without being
 consumed.
 In the case in which an LFB decides that a packet/chunk has to be
 dropped, the LFB MAY drop the packet/chunk, but the metadata MUST be
 sent to the Merger LFB's InvalidIn input port for merging purposes.
 Additional metadata produced by LFBs inside a datapath MAY be
 aggregated within the Merger LFB and sent on after the merging
 process.  In case of receiving the same metadata definition with
 multiple values, the Merger LFB MUST keep the first received from a
 valid packet or chunk.

Haleplidis & Halpern Experimental [Page 10] RFC 7409 ForCES Packet Parallelization November 2014

3. Parallel Base Types

3.1. Frame Types

 One frame type has been defined in this library.
 +-----------+-------------------------------------------------------+
 | Frame     | Synopsis                                              |
 | Name      |                                                       |
 +-----------+-------------------------------------------------------+
 | Chunk     | A chunk is a frame that is part of an original larger |
 |           | frame.                                                |
 +-----------+-------------------------------------------------------+
                         Parallel Frame Types

3.2. Data Types

 One data type has been defined in this library.
 +---------------+------------------------+--------------------------+
 | DataType Name | Type                   | Synopsis                 |
 +---------------+------------------------+--------------------------+
 | ParallelTypes | Atomic uchar.  Special | The type of              |
 |               | Values Flood (0),      | parallelization this     |
 |               | Split (1).             | packet will go through.  |
 +---------------+------------------------+--------------------------+
                          Parallel Data Types

Haleplidis & Halpern Experimental [Page 11] RFC 7409 ForCES Packet Parallelization November 2014

3.3. Metadata Types

 The following metadata structure with ID 16, using the ForCES model
 extension [RFC7408], is defined for the parallelization library:
 +--------------------+--------+----+--------------------------------+
 |   Metadata Name    |  Type  | ID |            Synopsis            |
 +--------------------+--------+----+--------------------------------+
 |    ParallelType    | uchar  | 1  |  The type of parallelization   |
 |                    |        |    | this packet will go through. 0 |
 |                    |        |    |    for flood, 1 for split.     |
 |                    |        |    |                                |
 |   TaskCorrelator   | uint32 | 2  |  An identification number to   |
 |                    |        |    |   specify that a packet or a   |
 |                    |        |    |   chunk belongs to the same    |
 |                    |        |    |         parallel task.         |
 |                    |        |    |                                |
 |    ParallelNum     | uint32 | 3  |    Defines the number of a     |
 |                    |        |    | specific packet or chunk of a  |
 |                    |        |    |         specific task.         |
 |                    |        |    |                                |
 | ParallelPartsCount | uint32 | 4  |  Defines the total number of   |
 |                    |        |    |    packets or chunks for a     |
 |                    |        |    |         specific task.         |
 +--------------------+--------+----+--------------------------------+
                    Metadata Structure for Merging

4. Parallel LFBs

4.1. Splitter

 The Splitter LFB takes part in parallelizing the processing datapath
 by sending either the same packet (Figure 2) or chunks (Figure 1) of
 the same packet to multiple LFBs.
                           +---------------+
                SplitterIn |               | SplitterOut
                ---------->| Splitter LFB  |------------->
                           |               |
                           +---------------+
                        Figure 4: Splitter LFB

Haleplidis & Halpern Experimental [Page 12] RFC 7409 ForCES Packet Parallelization November 2014

4.1.1. Data Handling

 The Splitter LFB receives any kind of packet via the singleton input,
 Input.  Depending upon the CE's configuration of the ParallelType
 component, if the parallel type is of type flood (0), the same packet
 MUST be sent through all instances of the group output "SplitterOut".
 If the parallel type is of type split (1), then the packet will be
 split into same size chunks except for the last, which MAY be
 smaller, with the max size being defined by the ChunkSize component.
 Chunks MAY be sent out in a round-robin fashion through instances of
 the group output "ParallelOut" or in any other way defined by the
 implementer.  Each packet or chunk will be accompanied by the
 following metadata set as a struct:
 o  ParallelType - The parallel type: split or flood.
 o  ParallelID - Generated by the Splitter LFB to identify which
    chunks or packets belong to the same parallel task.
 o  ParallelNum - Each chunk or packet of a parallel ID will be
    assigned a number in order for the Merger LFB to know when it has
    gathered them all along with the ParallelPartsCount metadata.
 o  ParallelPartsCount - The number of chunks or packets for the
    specific task.

4.1.2. Components

 The Splitter LFB has only two components.  The first is the
 ParallelType, a uint32 that defines how the packet will be processed
 by the Splitter LFB.  The second is the ChunkSize, a uint32 that
 specifies the size of each chunk when a packet is split into multiple
 same-size chunks.  The last chunk MAY be smaller than the value of
 the ChunkSize.

4.1.3. Capabilities

 This LFB has only one capability specified; the MinMaxChunkSize is a
 struct of two uint32s to specify the minimum and maximum chunk size.

4.1.4. Events

 This LFB has no events specified.

Haleplidis & Halpern Experimental [Page 13] RFC 7409 ForCES Packet Parallelization November 2014

4.2. Merger

 The Merger LFB is the synchronization point for multiple packets or
 packet chunks of the same task emanating out of the parallel path, as
 illustrated in Figure 1 and Figure 2.
                             +-------------+
                    MergerIn |             |
                   --------->|             | MergerOut
                             | Merger LFB  |----------->
                   InvalidIn |             |
                   --------->|             |
                             +-------------+
                         Figure 5: Merger LFB

4.2.1. Data Handling

 The Merger LFB receives either a packet or a chunk via the group
 input ParallelIn, along with the ParallelType metadata, the
 TaskCorrelator, the ParallelNum, and the ParallelPartsCount.
 In the case in which an upstream LFB has dropped a packet or a chunk,
 the Merger LFB MAY receive only the metadata, both the metadata and
 the packet, or the chunk through the InvalidIn group input port.  It
 SHOULD receive a metadata specifying the error code.  Currently
 defined metadata in the Base LFB Library [RFC6956] are the
 ExceptionID and the ValidateErrorID.
 If the MergeWaitType is set to false, the Merger LFB will initiate
 the merge process upon receiving the first packet.  If false, for
 each task identified by the task correlator, it will wait for all
 packets/chunks to arrive unless the MergeWaitTimeoutTimer timer
 expires.  If the MergeWaitTimeoutTimer has expired, the Merger MUST
 consider the rest of the packets/chunks that have not been received
 as invalid, and it MUST handle the packets according to the
 InvalidAction value.
 If one packet or chunk has been received through the InvalidIn port,
 then the merging procedure will handle the packets/chunks according
 to the InvalidAction value.  If the InvalidAction component has been
 set to 0, then if one packet or chunk is not valid, all will be
 dropped or else the process will initiate.  Once the merging process
 has been completed, the resulting packet will be sent via the
 singleton output port MergerOut.

Haleplidis & Halpern Experimental [Page 14] RFC 7409 ForCES Packet Parallelization November 2014

 If the Merger LFB receives different values for the same metadata
 from different packets or chunks that have the same task correlator,
 then the Merger LFB will use the first metadata from a packet or
 chunk that entered the LFB through the MergerIn input port.

4.2.2. Components

 This LFB has the following components specified:
 1.  InvalidAction: A uchar defining what the Merge LFB will do if an
     invalid chunk or packet is received.  If set to 0 (DropAll), the
     merge will be considered invalid and all chunks or packets will
     be dropped.  If set to 1 (Continue), the merge will continue.
 2.  MergeWaitTimeoutTimer: A uint32 defining the amount of time, in
     milliseconds, that the Merger will wait for all packets or chunks
     within the same task to arrive before considering them invalid.
     The MergeWaitTimeoutTimer starts as soon as the first chunk or
     packet of a parallel task arrives.
 3.  MergeWaitType: A boolean.  If true, the Merger LFB will wait for
     all packets or chunks to be received prior to performing the
     merge.  If false, when one packet or a chunk with a response is
     received by the merge LFB, it will start with the merge process.
 4.  InvalidMergesCounter: A uint32 that counts the number of merges
     where there is at least one packet or chunk that entered the
     Merger LFB through the InvalidIn input port.
 5.  InvalidTotalCounter: A uint32 that counts the number of merges
     where all packets/chunks entered the Merger LFB through the
     InvalidIn input port.
 6.  InvalidIDCounters: A struct of two arrays.  Each array has a
     uint32 per row.  Each array counts the number of invalid merges
     where at least one packet or chunk entered through InvalidID per
     error ID.  The first array is the InvalidExceptionID and the
     second is the InvalidValidateErrorID.

4.2.3. Capabilities

 This LFB has no capabilities specified.

Haleplidis & Halpern Experimental [Page 15] RFC 7409 ForCES Packet Parallelization November 2014

4.2.4. Events

 This LFB specifies only two events.  The first detects whether the
 InvalidMergesCounter has exceeded a specific value, and the second
 detects whether the InvalidAllCounter has exceeded a specific value.
 Both error reports will send the respective counter value.  Event
 Filters can be used to limit the number of messages

4.3. CoreParallelization

 A core LFB that specifies that the FE supports parallelization
 instead of updating the FEObject LFB

4.3.1. Data Handling

 The CoreParallelization does not handle data.

4.3.2. Components

 This LFB has no components specified.

4.3.3. Capabilities

 This LFB has only one capability specified.  The ParallelLFBs is a
 table which lists all the LFBs that can be parallelized.  Each row of
 the table contains:
 1.  LFBName: A string.  The Name of the parallel LFB.
 2.  LFBClassID: A uint32.  The Class ID of the parallel LFB.
 3.  LFBVersion: A string.  The Version of the parallel LFB.
 4.  LFBParallelOccurrenceLimit: A uint32.  The upper limit of
     instances of the same parallel LFBs of this class.
 5.  AllowedParallelAfters: A table of uint32s (LFB Class IDs).  A
     list of LFB classes that can follow this LFB class in a pipeline
     for a parallel path.
 6.  AllowedParallelBefores: A table of uint32s (LFB Class IDs).  A
     list of LFB classes that can exist before this LFB class in a
     pipeline for a parallel path.
 7.  AllowedParallel: A table of uint32s (LFB Class IDs).  A list of
     LFB classes that can process packets or chunks in parallel with
     this LFB class.

Haleplidis & Halpern Experimental [Page 16] RFC 7409 ForCES Packet Parallelization November 2014

4.3.4. Events

 This LFB specifies no events.

5. XML for Parallel LFB Library

<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
   provides="Parallel">
  <load library="BaseTypeLibrary" location="BaseTypeLibrary.LFB"/>
  <frameDefs>
    <frameDef>
      <name>Chunk</name>
      <synopsis>A chunk is a frame that is part of an original
            larger frame</synopsis>
    </frameDef>
  </frameDefs>
  <dataTypeDefs>
    <dataTypeDef>
      <name>ParallelTypes</name>
      <synopsis>The type of parallelization this packet will go
            through</synopsis>
      <atomic>
        <baseType>uchar</baseType>
        <specialValues>
          <specialValue value="0">
            <name>Flood</name>
            <synopsis>The packet/chunk has been sent as a whole
                     to multiple recipients</synopsis>
          </specialValue>
          <specialValue value="1">
            <name>Split</name>
            <synopsis>The packet/chunk has been split into
                     multiple chunks and sent to recipients</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </dataTypeDef>
    <dataTypeDef>
      <name>ParallelLFBType</name>
      <synopsis>Table entry for parallel LFBs</synopsis>
      <struct>
        <component componentID="1">
          <name>LFBName</name>
          <synopsis>The name of an LFB Class</synopsis>
          <typeRef>string</typeRef>

Haleplidis & Halpern Experimental [Page 17] RFC 7409 ForCES Packet Parallelization November 2014

        </component>
        <component componentID="2">
          <name>LFBClassID</name>
          <synopsis>The ID of the LFB Class</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="3">
          <name>LFBVersion</name>
          <synopsis>The version of the LFB Class used by this FE
             </synopsis>
          <typeRef>string</typeRef>
        </component>
        <component componentID="4">
          <name>LFBParallelOccurrenceLimit</name>
          <synopsis>The upper limit of instances of the same
                parallel LFBs of this class</synopsis>
          <optional/>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="5">
          <name>AllowedParallelAfters</name>
          <synopsis>List of LFB Classes that can follow this LFB
                in a parallel pipeline</synopsis>
          <optional/>
          <array>
            <typeRef>uint32</typeRef>
          </array>
        </component>
        <component componentID="6">
          <name>AllowedParallelBefores</name>
          <synopsis>List of LFB Classes that this LFB Class can
                follow in a parallel pipeline</synopsis>
          <optional/>
          <array>
            <typeRef>uint32</typeRef>
          </array>
        </component>
        <component componentID="7">
          <name>AllowedParallel</name>
          <synopsis>List of LFB Classes that this LFB Class can be run
                in parallel with</synopsis>
          <array>
            <typeRef>uint32</typeRef>
          </array>
        </component>
      </struct>
    </dataTypeDef>
  </dataTypeDefs>

Haleplidis & Halpern Experimental [Page 18] RFC 7409 ForCES Packet Parallelization November 2014

  <metadataDefs>
    <metadataDef>
      <name>ParallelMetadataSet</name>
      <synopsis>A metadata set for parallelization-related LFBs
         </synopsis>
      <metadataID>32</metadataID>
      <struct>
        <component componentID="1">
          <name>ParallelType</name>
          <synopsis>The type of parallelization this packet/chunk
                  has gone through</synopsis>
          <typeRef>ParallelTypes</typeRef>
        </component>
        <component componentID="2">
          <name>TaskCorrelator</name>
          <synopsis>An identification number to specify that
                  packets or chunks originate from the same packet.
               </synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="3">
          <name>ParallelNum</name>
          <synopsis>Defines the number of the specific packet or
                  chunk of the specific parallel ID.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="4">
          <name>ParallelPartsCount</name>
          <synopsis>Defines the total number of packets or chunks
                  for the specific parallel ID.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
      </struct>
    </metadataDef>
  </metadataDefs>
  <LFBClassDefs>
    <LFBClassDef LFBClassID="65537">
      <name>Ext-Splitter</name>
      <synopsis>A Splitter LFB takes part in parallelizing the
            processing datapath.  It will either send the same packet
            or chunks of one packet to multiple LFBs</synopsis>
      <version>1.0</version>
      <inputPorts>
        <inputPort>
          <name>SplitterIn</name>
          <synopsis>An input port expecting any kind of frame
               </synopsis>
          <expectation>

Haleplidis & Halpern Experimental [Page 19] RFC 7409 ForCES Packet Parallelization November 2014

            <frameExpected>
              <ref>Arbitrary</ref>
            </frameExpected>
          </expectation>
        </inputPort>
      </inputPorts>
      <outputPorts>
        <outputPort group="true">
          <name>SplitterOut</name>
          <synopsis>A parallel output port that sends the same
                  packet to all output instances or chunks of the same
                  packet to output instances.  Each chunk is sent only
                  once by the LFB.</synopsis>
          <product>
            <frameProduced>
              <ref>Arbitrary</ref>
              <ref>Chunk</ref>
            </frameProduced>
            <metadataProduced>
              <ref>ParallelMetadataSet</ref>
            </metadataProduced>
          </product>
        </outputPort>
      </outputPorts>
      <components>
        <component componentID="1" access="read-write">
          <name>ParallelType</name>
          <synopsis>The type of parallelization this packet will
                  go through</synopsis>
          <typeRef>ParallelTypes</typeRef>
        </component>
        <component componentID="2" access="read-write">
          <name>ChunkSize</name>
          <synopsis>The size of a chunk when a packet is split
                  into multiple chunks of the same size</synopsis>
          <typeRef>uint32</typeRef>
        </component>
      </components>
      <capabilities>
        <capability componentID="31">
          <name>MinMaxChunkSize</name>
          <synopsis>The minimum and maximum size of a chunk
                  capable of split by this LFB</synopsis>
          <struct>
            <component componentID="1">
              <name>MinChunkSize</name>
              <synopsis>Minimum chunk size</synopsis>
              <optional/>

Haleplidis & Halpern Experimental [Page 20] RFC 7409 ForCES Packet Parallelization November 2014

              <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
              <name>MaxChunkSize</name>
              <synopsis>Maximum chunk size</synopsis>
              <typeRef>uint32</typeRef>
            </component>
          </struct>
        </capability>
      </capabilities>
    </LFBClassDef>
    <LFBClassDef LFBClassID="65538">
      <name>Ext-Merger</name>
      <synopsis>A Merger LFB receives multiple packets or multiple
            chunks of the same packet and merge them into one merged
            packet</synopsis>
      <version>1.0</version>
      <inputPorts>
        <inputPort group="true">
          <name>MergerIn</name>
          <synopsis>A parallel input port that accepts packets
                  or chunks from all output instances</synopsis>
          <expectation>
            <frameExpected>
              <ref>Arbitrary</ref>
              <ref>Chunk</ref>
            </frameExpected>
            <metadataExpected>
              <ref>ParallelMetadataSet</ref>
            </metadataExpected>
          </expectation>
        </inputPort>
        <inputPort group="true">
          <name>InvalidIn</name>
          <synopsis>When a packet is sent out of an error port of
                  an LFB in a parallel path, it will be sent to this
                  output port in the Merger LFB</synopsis>
          <expectation>
            <frameExpected>
              <ref>Arbitrary</ref>
              <ref>Chunk</ref>
            </frameExpected>
            <metadataExpected>
              <one-of>
                <ref>ExceptionID</ref>
                <ref>ValidateErrorID</ref>
              </one-of>
            </metadataExpected>

Haleplidis & Halpern Experimental [Page 21] RFC 7409 ForCES Packet Parallelization November 2014

          </expectation>
        </inputPort>
      </inputPorts>
      <outputPorts>
        <outputPort>
          <name>MergerOut</name>
          <synopsis>An output port expecting any kind of frame
               </synopsis>
          <product>
            <frameProduced>
              <ref>Arbitrary</ref>
            </frameProduced>
          </product>
        </outputPort>
      </outputPorts>
      <components>
        <component componentID="1" access="read-write">
          <name>InvalidAction</name>
          <synopsis>What the Merge LFB will do if an invalid
                  chunk or packet is received</synopsis>
          <atomic>
            <baseType>uchar</baseType>
            <specialValues>
              <specialValue value="0">
                <name>DropAll</name>
                <synopsis>Drop all packets or chunks
                        </synopsis>
              </specialValue>
              <specialValue value="1">
                <name>Continue</name>
                <synopsis>Continue with the merge</synopsis>
              </specialValue>
            </specialValues>
          </atomic>
        </component>
        <component componentID="2" access="read-write">
          <name>MergeWaitType</name>
          <synopsis>Whether the Merge LFB will wait for all
                  packets or chunks to be received prior to sending
                  out a response</synopsis>
          <typeRef>boolean</typeRef>
        </component>
        <component componentID="3" access="read-write">
          <name>MergeWaitTimeoutTimer</name>
          <synopsis>The time that the Merger will wait
          for all packets or chunks within the same task to arrive
          before considering them invalid.</synopsis>
          <typeRef>uint32</typeRef>

Haleplidis & Halpern Experimental [Page 22] RFC 7409 ForCES Packet Parallelization November 2014

        </component>
        <component componentID="4" access="read-reset">
          <name>InvalidMergesCounter</name>
          <synopsis>Counts the number of merges where there is at
                  least one packet/chunk that entered the Merger LFB
                  through the InvalidIn input port</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="5" access="read-reset">
          <name>InvalidTotalCounter</name>
          <synopsis>Counts the number of merges where all
                  packets/chunks entered the Merger LFB through the
                  InvalidIn input port</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="6" access="read-reset">
          <name>InvalidIDCounters</name>
          <synopsis>Counts the number of invalid merges where at
                  least one packet/chunk entered through InvalidID per
                  error ID</synopsis>
          <struct>
            <component componentID="1">
              <name>InvalidExceptionID</name>
              <synopsis>Per Exception ID</synopsis>
              <array>
                <typeRef>uint32</typeRef>
              </array>
            </component>
            <component componentID="2">
              <name>InvalidValidateErrorID</name>
              <synopsis>Per Validate Error ID</synopsis>
              <array>
                <typeRef>uint32</typeRef>
              </array>
            </component>
          </struct>
        </component>
      </components>
      <events baseID="30">
        <event eventID="1">
          <name>ManyInvalids</name>
          <synopsis>An event that specifies if there are too many
                  invalids</synopsis>
          <eventTarget>
            <eventField>InvalidCounter</eventField>
          </eventTarget>
          <eventGreaterThan/>
          <eventReports>

Haleplidis & Halpern Experimental [Page 23] RFC 7409 ForCES Packet Parallelization November 2014

            <eventReport>
              <eventField>InvalidMergesCounter</eventField>
            </eventReport>
          </eventReports>
        </event>
        <event eventID="2">
          <name>ManyTotalInvalids</name>
          <synopsis>An event that specifies if there are too many
                  invalids</synopsis>
          <eventTarget>
            <eventField>InvalidTotalCounter</eventField>
          </eventTarget>
          <eventGreaterThan/>
          <eventReports>
            <eventReport>
              <eventField>InvalidTotalCounter</eventField>
            </eventReport>
          </eventReports>
        </event>
      </events>
    </LFBClassDef>
    <LFBClassDef LFBClassID="65539">
      <name>Ext-CoreParallelization</name>
      <synopsis>A core LFB that specifies that the FE supports
        parallelization instead of updating the FEObject
        LFB</synopsis>
      <version>1.0</version>
      <capabilities>
        <capability componentID="10">
          <name>ParallelLFBs</name>
          <synopsis>A table that lists all the LFBs that can be
              parallelized</synopsis>
          <array>
            <typeRef>ParallelLFBType</typeRef>
          </array>
        </capability>
      </capabilities>
    </LFBClassDef>
  </LFBClassDefs>
</LFBLibrary>
                    Figure 6: Parallel LFB Library

Haleplidis & Halpern Experimental [Page 24] RFC 7409 ForCES Packet Parallelization November 2014

6. IANA Considerations

6.1. LFB Class Names and LFB Class Identifiers

 LFB classes defined by this document do not belong to LFBs defined by
 Standards Action.  As such, the corresponding values assigned in the
 "Logical Functional Block (LFB) Class Names and Class Identifiers"
 registry at <http://www.iana.org/assignments/forces> are above 65535.
 This specification includes the following LFB class names and LFB
 class identifiers:
 +-------+---------------------+-------+-----------------+---------+
 | LFB   |  LFB Class Name     |  LFB  |  Description    |   Ref   |
 | Class |                     |Version|                 |         |
 | ID    |                     |       |                 |         |
 +-------+---------------------+-------+-----------------+---------+
 | 65537 |   Ext-Splitter      |  1.0  | A Splitter LFB  |   RFC   |
 |       |                     |       |  will send      |   7409  |
 |       |                     |       |either the same  |         |
 |       |                     |       |   packet or     |         |
 |       |                     |       | chunks of one   |         |
 |       |                     |       |   packet to     |         |
 |       |                     |       | multiple LFBs.  |         |
 +-------+---------------------+-------+-----------------+---------+
 | 65538 |    Ext-Merger       |   1.0 |  A Merger LFB   |   RFC   |
 |       |                     |       |    receives     |   7409  |
 |       |                     |       |    multiple     |         |
 |       |                     |       |   packets or    |         |
 |       |                     |       |    multiple     |         |
 |       |                     |       | chunks of the   |         |
 |       |                     |       |  same packet    |         |
 |       |                     |       |   and merges    |         |
 |       |                     |       | them into one.  |         |
 +-------+---------------------+-------+-----------------+---------+
 | 65539 | Ext-                |   1.0 | A core LFB to   |   RFC   |
 |       | CoreParallelization |       | signify the     |   7409  |
 |       |                     |       | parallelization |         |
 |       |                     |       |   capability    |         |
 +-------+---------------------+-------+-----------------+---------+
   Logical Functional Block (LFB) Class Names and Class Identifiers

Haleplidis & Halpern Experimental [Page 25] RFC 7409 ForCES Packet Parallelization November 2014

6.2. Metadata ID

 The Metadata ID namespace is 32-bits long.  Values assigned by this
 specification are:
           +------------+---------------------+-----------+
           |   Value    |         Name        | Reference |
           +------------+---------------------+-----------+
           | 0x00000010 | ParallelMetadataSet |  RFC 7409 |
           +------------+---------------------+-----------+
              Metadata ID Assigned by this Specification

7. Security Considerations

 This document does not alter either the ForCES model [RFC5812] or the
 ForCES protocol [RFC5810].  As such, it has no impact on their
 security considerations.  This document simply defines the
 operational parameters and capabilities of LFBs that perform
 parallelization and not how parallelization is implemented.  Finally,
 this document does not attempt to analyze the presence or possibility
 of security interactions created by allowing parallel operations on
 packets.  Any such issues, if they exist, are for the designers of
 the particular data path, not the general mechanism.

8. References

8.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC5810]  Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
            W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
            Control Element Separation (ForCES) Protocol
            Specification", RFC 5810, March 2010,
            <http://www.rfc-editor.org/info/rfc5810>.
 [RFC5812]  Halpern, J. and J. Hadi Salim, "Forwarding and Control
            Element Separation (ForCES) Forwarding Element Model", RFC
            5812, March 2010,
            <http://www.rfc-editor.org/info/rfc5812>.
 [RFC6956]  Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
            Halpern, "Forwarding and Control Element Separation
            (ForCES) Logical Function Block (LFB) Library", RFC 6956,
            June 2013, <http://www.rfc-editor.org/info/rfc6956>.

Haleplidis & Halpern Experimental [Page 26] RFC 7409 ForCES Packet Parallelization November 2014

 [RFC7408]  Haleplidis, E., "Forwarding and Control Element Separation
            (ForCES) Model Extension", RFC 7408, November 2014,
            <http://www.rfc-editor.org/info/rfc7408>.

8.2. Informative References

 [Cilk]     Massachusetts Institute of Technology, "The Cilk Project",
            <http://supertech.csail.mit.edu/cilk/>.

Acknowledgments

 The authors would like to thank Edward Crabbe for the initial
 discussion that led to the creation of this document.  They also
 thank Jamal Hadi Salim and Dave Hood for comments and discussions and
 Adrian Farrel for his AD review that made this document better.
 Finally, the authors thank Francis Dupont for his Gen-Art review and
 Magnus Nystroem for his security review both of which refined this
 document to its final shape.

Authors' Addresses

 Evangelos Haleplidis
 University of Patras
 Department of Electrical and Computer Engineering
 Patras  26500
 Greece
 EMail: ehalep@ece.upatras.gr
 Joel Halpern
 Ericsson
 P.O. Box 6049
 Leesburg, VA  20178
 United States
 Phone: +1 703 371 3043
 EMail: joel.halpern@ericsson.com

Haleplidis & Halpern Experimental [Page 27]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7409.txt · Last modified: 2014/12/01 02:21 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki