Difference between revisions of "Project Proposals/processing pipeline"
From fd.io
(Processing pipeline specific plugin leveraging v6SR to implement IP continuity) |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 23: | Line 23: | ||
<!-- Description of the work that will take place in this project --> | <!-- Description of the work that will take place in this project --> | ||
| − | Thank to this project it will be possible to create complex processing pipeline in which each node applies some transformation not at the IP packet level but rather at “application data level” which represents several IP packet payloads. For any given node in the processing pipeline the input and the output data sizes can be different. | + | Thank to this project it will be possible to create complex processing pipeline in which each node applies some transformation not at the IP packet level but rather at “application data level” which represents several IP packet payloads. For any given node in the processing pipeline the input and the output data sizes can be different. The idea is to create a generic and extensible framework to allow additional functionality to be provided. Media processing is a natural application of this framework. |
| + | The framework itself can be divided in three parts: | ||
| − | + | <LI>The input plug-in responsible for receiving incoming traffic and make it available to the processing application through e.g. a piece of memory | |
| − | + | ||
| − | + | ||
| − | <LI>The input | + | |
</LI> | </LI> | ||
| − | <LI>The output | + | <LI>The output plug-in responsible for sending outgoing traffic from one processing application. |
</LI> | </LI> | ||
| − | <LI> | + | <LI>A third control plugin is used to configure the other plug-ins. |
</LI> | </LI> | ||
| − | The | + | The input as well as output plugins are actually split in two parts the application domain specific (e.g. Media) part and the ip specific part. |
| − | + | (A fully detailed description of the involved mechanisms is accessible in a separate document) | |
| − | (A fully detailed description of the involved | + | |
== Scope == | == Scope == | ||
| Line 95: | Line 92: | ||
The code of each plugin is itself divided in two parts: | The code of each plugin is itself divided in two parts: | ||
| − | <li> A fully generic part which is responsible for IP packetization and depacketization. This part exposes a configuration API totally agnostic from the application specific part. This part is also responsible for maintaining IP continuity across processing applications which are not IP aware. | + | <li> A fully generic part which is responsible for IP packetization and depacketization. This part exposes a configuration API totally agnostic from the application specific part. This part is also responsible for maintaining IP continuity across processing applications which are not IP aware. This fully generic part is actually an extension of the existing v6SR development project which is meant to become an extensible framework to allow additional functionality to be provided. |
</li> | </li> | ||
| − | <LI>An application specific part which is responsible for implementing the communication | + | <LI>An application domain (e.g. Media) specific part which is responsible for implementing the communication with the external application. In the media particular case shared memory are used for this purpose. This domain specific part is new and could be considered either as an extension of the v6SR work or as a separate sub-project. |
</li> | </li> | ||
== Meets Board Policy (including IPR, being within Board defined Scope etc) == | == Meets Board Policy (including IPR, being within Board defined Scope etc) == | ||
| Line 105: | Line 102: | ||
== Administrata == | == Administrata == | ||
* Request for Project proposal consideration | * Request for Project proposal consideration | ||
| − | ** Email: | + | ** Email: https://lists.fd.io/pipermail/tsc/2017-January/000369.html |
| − | ** Date: | + | ** Date: 12-Jan-2017 |
Latest revision as of 13:21, 12 January 2017
Processing and forward
Contents
Name
Processing Pipeline with SRv6
Project Contact Name and Email
Andre Surcouf (asurcouf@cisco.com)
Clarence Filsfils (cfilsfil@cisco.com)
Repository Name
ppsr
Description
Thank to this project it will be possible to create complex processing pipeline in which each node applies some transformation not at the IP packet level but rather at “application data level” which represents several IP packet payloads. For any given node in the processing pipeline the input and the output data sizes can be different. The idea is to create a generic and extensible framework to allow additional functionality to be provided. Media processing is a natural application of this framework. The framework itself can be divided in three parts:
The input as well as output plugins are actually split in two parts the application domain specific (e.g. Media) part and the ip specific part.
(A fully detailed description of the involved mechanisms is accessible in a separate document)
Scope
- Processing
- Transform
- Forward
Initial Committers
Axel Taldir (ataldir@cisco.com)
Eyal Shalev (eshalev@cisco.com)
Francois Clad (fclad@cisco.com)
Vendor Neutral
There is no need for any particular hardware. However some implementation could use dedicated hardware to increase the performances. No driver required for any specific hardware
The code of each plugin is itself divided in two parts:
Meets Board Policy (including IPR, being within Board defined Scope etc)
Meets board policy as expressed in Technical Community Charter and IP Policy
Administrata
- Request for Project proposal consideration
- Email: https://lists.fd.io/pipermail/tsc/2017-January/000369.html
- Date: 12-Jan-2017
