Plugin Architecture

When you implement your SDK application as a plugin, the application is started by a JUNOS daemon (mspmand) running on the Multiservices PIC instead of starting up on its own as a separate daemon.

The system compiles the plugin code into a shared library instead of a program. The JUNOS daemon dynamically (at runtime) loads the shared library, allowing the SDK application to plug into it to extend the system's functionality. (It is possible for a plugin on the control plane to register its own events to drive itself.)

The following figure shows plugins in the context of the Services SDK services architecture.

dataplane-architecture-g016849.gif

Plugins and the Services Plane

There can be more than one shared library, and thus, more than one plugin, loaded by mspmand. mspmand can coordinate multiple plugin applications. When it receives data-plane packets, mspmand can chain the plugins in a certain order, and let each plugin in the chain handle each packet. This is the primary benefit to using the plugin model, and plugin applications are assumed to be chiefly interested in these data-plane packets.

Each service a plugin implements is modular and independent and is defined by a registration entry in the policy database. The registration entry for each service contains the plugin name, the names of its associated control and data event handlers, and an application ID you assign.

The system maintains a table of plugins and assigns a unique plugin ID to each one. A context structure is used to deliver the necessary data required by the plugin handler with each event.

The control portion of the plugin is still optionally part of the shared library; however, the control portion does not plug in in the same sense, because mspmand spawns a new thread to run this component independently. You can also write the control component to run separately, in another daemon, and hence not be compiled into the shared library.

System Stack for Plugins

The following figure summarizes the SDK stack as a plugin uses it for packet flow once a packet has reached the application running on the PIC.

layers-g016934.gif

Layers in the SDK Stack

Applications might or might not choose to use the plugin infrastructure; for example, if an application uses massive resources and only needs to transfer packets, calling through various layers might be less efficient. However, if your application is already structured to use sessions, using a plugin allows you to leverage the SDK stack architecture shown here.

Services Layer

The Services layer is the glue that holds all the plugins together. It supports the following functionality:

Session and Flow Layers

A flow represents a unidirectional stream of packets with the same 5-tuple. A session represents a pair of forward and reverse flows, and is used to maintain state for bidirectional packet traffic.

The flow layer contains a control part and a data part. The data part is responsible for classifying packets into flows. The control part is responsible for flow management: aging, timing, counting, and enforcing flows.

When you open a session, you specify a flow type.

A service can choose to maintain its own sessions - that is, it can choose to use packet-based sessions instead of the default flow-based sessions. To do this, your code sets the MSP_POLICY_FLAGS_SSET_PACKET flag before defining the policy add parameters. (For sample code that updates the policy database, see Attaching to the Policy Database).

The system assigns a new flow type to differentiate sessions that use new flow types from sessions the system creates. All plugins that will share these sessions must know the new type.

Plugin and Service Set State Machine

The system maintains states for the service sets implemented by plugins. Following are the states maintained per service set:

The state machine is triggered by the following events:

The following table summarizes the state machine:

Initial State         External Event         New State 
==================================================================

 -                    SSRB_ ADD              POLICY_ADD_PENDING             
 -                    POLICY_ADD             INIT_PENDING
INIT_PENDING          SSRB_ADD               POLICY_ADD_PENDING/ACTIVE
POLICY_ADD_PENDING    POLICY_ADD             ACTIVE
ACTIVE                POLICY_DELETE          POLICY_ADD_PENDING
ACTIVE                SSRB_DEL               DEL_PENDING
POLICY_ADD_PENDING    SSRB_DEL               DEL_PENDING 
DEL_PENDING           POLICY_DELETE          -      

For more details about plugin functionality and writing plugins, see Plugin Functionality and Service Chaining.


2007-2009 Juniper Networks, Inc. All rights reserved. The information contained herein is confidential information of Juniper Networks, Inc., and may not be used, disclosed, distributed, modified, or copied without the prior written consent of Juniper Networks, Inc. in an express license. This information is subject to change by Juniper Networks, Inc. Juniper Networks, the Juniper Networks logo, and JUNOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Generated on Sun May 30 20:26:47 2010 for Juniper Networks Partner Solution Development Platform JUNOS SDK 10.2R1 by Doxygen 1.4.5