doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc7409.txt b/doc/rfc/rfc7409.txt
new file mode 100644
index 0000000..deee7c1
--- /dev/null
+++ b/doc/rfc/rfc7409.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+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]
+