Plug-In-able Switching System

Architecture Document

Internal Release Version 1.02 (DRAFT)
Date: January, 2000


Plug-In-able Switching System is a switching system that can dynamically deploy application supplied stream processor modules called Switchlet, in the junction nodes (such as router or switch). inside a network Once installed, the Switchlets are inserted in the flow path of the specified stream. Switchlets can perform any user defined application specific processing on the stream.
Plug-In-able Switching System.
  1. What is Plug-In-able Switching System 
  2. Architecture of Plug-In-able Switching System 
    1. Design
    2. Packet Design
    3. Switching System Design 
    4. Switchlet Design 
  3. How does the system works? 


What is Plug-In-able Switching System

Plug-In-able Switching System is an active switching system that can augment dynamic application processors in the flow path of any packet stream. The system provides not only the necessary data flow diversion mechanism but also provides management functions to load and unload Switchlets at network junction points as well as controllabilily of the state variables inside the Switchlet them-selves.

Switchlet is a loadable program module that can handle a packet data type. For examples, Routing Switchlet receives routing data and generate routing information while Cut Switchlet cuts input stream packets to a specified size.

System Components

Figure 1. Switching system components.


Design of Plug-In-able Switching System architecture.


The Plug-In-able switching system consists of three components. It has a manager component, processing components and session components. 

Manager component creates session components, loads processing components, and receives data from lower layers and forwards them to the appropriate session components. 

Processing components are the program modules such as switchlets. Some special processors such as scheduler invoked by manager are also processing component. A switchlet may be an application packet processor, a special filter or a routing process. 

Session components represent active processes with allocated data space. It has attached a process stream (hereafter referred as thread) and a data stream (hereafter referred as stream) on which a thread operates. Inside a session, the processing stream has space allocated to store the state variables of the processes in its thread, and data stream has space allocated for buffering packets.

Packet Design

In current implementation, the packet data, used by the Plug-In-able Switching System is enveloped in UDP or TCP over IP.

Packet format of real protocol

Figure 2. Packet format of real protocol

In the switching system, the packet format likes figure 3. 

Packet format of the Plug-In-able Switching System.

Figure 3. Packet format of the Plug-In-able Switching System.

Source ID. represents the identification of source node. 
Session ID. represents the identification of session to which the packet is diverted. This is basically the stream identifier while the sequence number contains the order of packet in this stream.
Processor ID. means the type of data, contained in the packet, i.e. control packet, management packet, data packet, etc. 
Data ID. shows the type of the traffic itself. It may be used for security and validation and private to Switchlets.


Switching System Design

Components Design 

Manager components

Manager component receives and directs the arrived packets, installs/removes process components, and creates/dismantles session components if needed.

Manager components

Figure 4. Manager components

Process components

Process scheduler activates and deactivates the Switchlets based on its type ID. Process scheduler itself is a process invoked by the manager.

Process  components

Figure 5. Process components

Process scheduler has a switchlet table which has identification of the switchlet, location of the switchlet, and some remarks of the switchlet.

Switchlet Table

Figure 6. Switchlet Table

Session components

Session components contains session identification, static information, and buffers for its packet. Figure 7. shows the structure, when a packet arrives in the session, it is linked in the buffer. From packet's point of view one by one the processes from the thread operates on them. From process'es point of view, each process skims through the packets in the stream. The Switchlet ID in the Packet Info field indicates the process that should operate on it next. Scheduler reads this field to roll the thread.

Session components

Figure 7. Session components

Session has a life cycle as described in Figure 8. When new session arrives in the switch, manager examines which resource will be needed to the session and allocates the resource to the session. If the resource requested/required is not available, manager rejects the new session.

If all the resources are available then it creates a session component and changes session status to ready. When packet arrives in the session, it triggers action on the packet in the action status. 

When end of session arrived, it releases the resource.

Session status transition diagram

Figure 8. Session status transition diagram.


Switchlet Design

A Switchlet is invoked by the activate messages from process scheduler. Each Switchlet selects the next Switchlet in the stream. Figure 9. shows the Switchlets. The ID of the first switchlet is derived by the scheduler from the fields in the packet header.

Switchlet of data type

Figure 9. Switchlet of data type.


How does the system works ?

When started, the system initialize it's internal structures and connections. After initialization, the system loads core engine switchlets from management nodes or it's own local nodes. When data received from one node then management components look into the packet and decide it's type.

If the type is control commands, then it pass messages to process components. If the type is data, then it handed the packet to session components to store the packet.

In process component, a process checks it's inputs and invokes a thread or sends a message to appropriate Switchlets. 

Switchlet process the packet by receiving messages from process components. When switchlet completes processing the packet then it decide which switchlet will be the next.

After all the processing is done, the switch forwards the processed packet to next switch (or node). Generally a routing/forwarding process is the last switchlet to process the data last in a switch. 

Finally,  we identify the processes that makes up the embryonic engine. At the core are the abilities to receive a message from the switch controller center, identify and install a switchlet, and invoke it. Routing is not included here. The argument is that if we have the above we can install a forwarder as well. That means the embryonic engine needs only the manager and process scheduler nothing else. Also note that embrionic engine initially does not know how to send reply. But with its basic engine it is possible to  install a 'messanger' as well. We also think the above engine is capable of self recomposition, where it can gradually substitute its own enbryo codeset completely.

If we want to build an application in the category of silent agent, the above enbrionic engine should work by itself. For application in the category of 'server' the above enbroyo needs to be equipped with a messanger switchlet. For application in the category of multi-point application the above have to be further upgraded with a router switchlet.

The requirement from platform: In the above, it is assumed that whatever (IP/UDP) is supporting this embrionic engine from below will (a) deliver a packet to the designated manager (b) and receive a packet from any (forwarder presumably) switchlet and forward it to the specified destination.