Functionality in the Services SDK

The Services SDK builds on the RE SDK to enable running complex and scalable applications.

This module supports developing service-plane applications that perform specialized packet processing on the Multiservices PIC. Typically, these applications focus on packet manipulation, such as compression, inspection, sampling, encapsulation and decapsulation, or encryption of packets in the data plane. Some applications might require run-to-completion functionality. Others might need time-share processing. The Multiservices PIC supports both.

A Services SDK application has dedicated access to Multiservices PIC CPUs, memory, and the network interface. One application at a time runs on the Multiservices PIC, and in fact, one application can use more than one PIC, so your design need not consider resource constraints. The Services SDK module provides libraries, drivers, and APIs that ease porting your existing application to the Multiservices PIC environment.

Components of a Services SDK Application

Services SDK applications generally consist of up to three components, management, control, and data. These are abstract architectural components: an application can have all these functions combined into one module or can separate them for scaling purposes. If the application creates the separate components, each component must be built as a separate package.

Management Component

The Management component runs on the Routing Engine and has a global view of the system, including all interfaces and data. This component is responsible for system management. Major functions of this component are as follows:

Application Control Component

The Application Control component can run on the Routing Engine or on control CPUs in the Multiservices PICs to facilitate scaling. The control component controls the data component, communicates with the management component on the Routing Engine, and has a local view of the system. The control CPUs have a full protocol stack.

This component is responsible for handling application-specific signaling protocols and for establishing and maintaining user sessions. Major functions of this component are as follows:

The Services SDK includes the following for application control:

Application Data Component

The Application Data component is responsible for processing packets, using data loops running in threads. The data component is typically interested only in session, flow, or packet state. It does not track system state. The control component sets data component behavior through shared memory.

This component must run on data CPUs; it can use one or more Multiservices PICs. It requires infrastructures that offer high throughput and scalability.

Among others, the data component facilitates the following operations:

The Services SDK includes the following features for the application data component:

Initialization and the Event Loop

Packet processing is driven by events, such as MSVCS_DATA_EV_PKT_PROC, MSVCS_DATA_EV_SESSION_OPEN, and MSVCS_DATA_EV_SESSION_CLOSE. Every time a new event occurs, the system makes callbacks to each service using the handler function registered during initialization. The event type is passed as an argument to the processing function.

Daemons start on control CPUs as single-threaded applications. However, most applications use the event loop for processing. Using the event loop is optional, but recommended, because many of the Services SDK APIs use an event context. There are no default events.

As a result of processing an event, your code can interface with the services layer and ask for one or more actions to be performed. These actions can be triggered from timer and packet processing contexts. Examples of actions are dropping, resetting, ignoring, or closing sessions.

For sample code that processes these events, see the equilibrium2_balance_data_hdlr() function in the Plugin Sync Equilibrium sample application, at sandbox/src/lib/equilibrium2_balance in your development sandbox.

Application Startup

When the JUNOS SDK has been mounted, the JUNOS software is running on the management CPU. At this point, both the control and data components are also running on the management CPU. To run an application on the PICs, the following steps execute:

  1. The JUNOS software on the management CPU reads the initialization file to determine which daemons to execute.

  2. Each daemon enters the junos_app_init() function.

  3. Data components spawn pthreads to run on each configured data CPU; their initialization callbacks must call the msp_init() function.

  4. Control components initialize the environment and then simply enter the event loop; their initialization callback must call the msp_daemon_init() function if the control component will call any other Services SDK functions (for example, to create a thread on a user CPU).

Application Restart

When a data application running on the PIC fails, the system restarts the application by default, with the following caveats:

Initialization Operations

Initialization code typically performs the following operations:

Any threads that should not receive signals should block them (usually only the main thread handles these).

For More Information

For details on the following topics, see the sections indicated:

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