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.
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.
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:
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.
- Operation, Administration, and Maintenance (OA&M) interface (CLI, SNMP)
- Discovery and high-availability management of data-plane resources
- Interaction with routing daemons for load-balancing and steering session traffic to appropriate data-plane resources
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:
- Handling signaling protocols
- Originating and terminating connections through sockets
- Authentication, authorization, and accounting functions (AAA) for customer management
- Performing session management functions and scheduling
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.
- POSIX API (socket API) on a symmetric multiprocessing (SMP) operating system that is scalable to a large number of CPUs
- No General Public License (GPL) issues
- Rich and proven TCP/IP support
- Virtual private network (VPN) routing and forwarding (VRF) support
- Health monitoring (see Health Monitoring)
- PIC-to-PIC failover (see The PIC to PIC Failover Daemon)
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:
- Tunneling and de-tunneling packets
- Differentiated Services (DiffServ) marking
- Class of service (COS) functions
- Deep packet inspection
- Header compression
Packet processing is driven by events, such as
- Raw packet framework support (base service SDK package)
- Database of value-added information from the JUNOS software, such as the route database, MPLS path information, SNMP identifier information, and autonomous system information
- Service sets (see Services and Service Sets)
- Plugins, or services that are executed in the context of the current service set (see Plugin Functionality and Service Chaining)
- PIC-to-PIC replication (see Data Replication)
- Health monitoring (see Health Monitoring)
- Reliable download of configurations from the Routing Engine to the Multiservices PIC (see Reliable Configuration Download)
- Support for spinlocks and user-level critical sections (see Locking)
- Control over packet distribution among CPUs (socket-affinity or packet based; see Flow, Thread, and Session Affinities)
- Shared memory objects (see Memory Management)
- Memory protection among processes
- Polled mode
- Zero copy
- Sampling support for the
- A library of functions to access the forwarding database for value-added data, including the route database, SNMP identifier information for interfaces, MPLS path information, and autonomous system information.
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
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:
equilibrium2_balance_data_hdlr() function in the Plugin Sync Equilibrium sample application, at
sandbox/src/lib/equilibrium2_balance in your development sandbox.
When a data application running on the PIC fails, the system restarts the application by default, with the following caveats:
The JUNOS software on the management CPU reads the initialization file to determine which daemons to execute.
Each daemon enters the
Data components spawn pthreads to run on each configured data CPU; their initialization callbacks must call the
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).
Initialization code typically performs the following operations:
- If you have configured your system for data redundancy (see Data-Plane Redundancy,) automatic restart is disabled.
- Sets up signal handling and logging
- Sets up a connection to the Routing Engine and/or other Multiservices PICs so that the configuration can be received and state can be mirrored
- Sets up any servers as needed
- Sets up the data-loops threads
- Usually allocates the object cache
- Starts any real-time priority threads (attached to user CPUs)
Any threads that should not receive signals should block them (usually only the main thread handles these).
For details on the following topics, see the sections indicated:
- Binds itself to a user or control CPU if necessary.
© 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