Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Components of a Services PIC

 

In the service PIC, the process of applying configured or requested services occurs using the multiservices PIC management daemon. It loads a set of plugins (which is a shared library) to provide various services such as stateful firewall, NAT, and deep packet inspection. The Service PIC framework involves the following modules or plugins to apply Layer 7 PCC rules for each data session or flow:

Mobile Subscriber Service Plugin (MSS)

The main functionalities of MSS plugin include establishing and managing the communication channel with all session PICs belonging to the same gateway, informing the service PIC of load information (such as memory, number of subscribers, number of flows) to the RMPSd running on the Routing Engine, receiving the subscriber information and transmitting that data to the common-subscriber plugin. The functionalities include the following:

  • Receive subscriber session, bearer, rating group (RG), and service data flow (SDF) information from the session PIC for subscriber-aware DPI services. This information is maintained for each subscriber anchored on this service PIC.

  • Send PCC rules and rule-set information to PCEF plugin.

  • Provide callback to get subscriber specific info. Other plugins or library modules can send events to MSS plugin to get subscriber specific info.

  • Handle volume limit, time limit, tariff time change and other signaling trigger events such as Application Start or Application Stop.

  • Statistics agent to send collected stats block to the anchor session PIC to generate OCS updates as well as usage monitoring triggers.

  • Collect the statistical values if the current time stamp exceeds the aggregated last reported time and the time stamp value given as part of the time-limit RG configuration

  • Add the counters (packet count and byte count) and then check for volume limit triggers. Uplink, Downlink and Combined volume limit are supported and a consolidated limit of the three types are supported.

  • Handle session idle timeout functionality. If the subscriber session is idle for a configured interval, the subscriber session is torn down.

Common Subscriber Plugin

This is the common plugin framework which maintains subscriber DB for all type of subscribers. This plugin helps to identify subscriber for each data session. Also, provides per-subscriber info/attributes which can be queried by other subscriber-aware plugins and per subscriber flow limit.

Junos Services Framework (JSF) deep packet inspection (DPI) plugin is integrated with QOSMOS. This unification is independent of TDF. PCEF plugin is a generic data path plugin and all the existing functionalities are applicable for TDF, such as policing support , event triggers for application start/stop , and policy based analytics/header enrichment. The resource control manager (RCM) component reports various resources usage on service PICs.

JDPI Plugin

Junos Services Framework (JSF) DPI (JDPI) plugin helps to identify the application (such as HTTP, FTP) and nested application (such as Facebook) for each data session. APP-ID with Qosmos is used for better application detection. This plugin performs the following processes:

  • Application classification

  • Parsing and protocol context extraction

  • Protocol context propagation

  • Maintaining APPID 1.0 API for backward compatibility

  • Unified ISSU and high availability

JDPI is a superset of the APPID and Juniper Content and Protocol Parsers (JCPP) functionalities.

PCEF Plugin

PCEF Plugin Policy and Charging Enforcement plugin is a generic plugin for all type of subscribers. The functionalities of this plugin include the following:

  • Receive PCC rules (both static and dynamic) through MSS plugin and maintain them in a DB.

  • Interface with APP-ID plugin to get the matching applications identifiers for each data session.

  • Accumulate per-session stats until complete application match happens.

  • Do the PCC rule lookup and find the matching PCC rule for each subscriber data session.

  • Apply the Policy and Charging enforcement as per the matching PCC rule.

  • Interface with MSS plugin to send stats for charging/reporting purpose.

  • Support HTTP URL based packet redirection based on the matching PCC rule. Support VRF redirection based on the matching PCC rule. Support flow blocking/gating based on the matching PCC rule.

  • Support for dscp remarking. This support is using FC/PLP actions. Class-of-service rewrite rules to egress interfaces will dictate the outgoing packet’s code points. •

  • Handle show, debug and VTY commands.

For TDF, the following levels of Policing are supported on the service PIC:

  • VRF based policing: If subscriber is not yet learned, a default policy as specified in the TDF services configuration will be applied. If policer is configured as the action in default policy, it will be applied in PCEF plugin if subscriber lookup fails. The default-policy is per VRF, so the policer applied will be per VRF per Service-PIC for subscribers that are not learned yet.

  • Subscriber-level policing: If policer is configured at the subscriber level, it is applied for all flows of the subscriber.

  • PCC-rule based policing: If subscriber policy has policer configured as one of the actions, it is applied to flows matching the pcc-rule.

HCM Plugin

HCM Plugin provides HTTP tag insertion, modification and deletion. HTTP tagging allows router to monitor HTTP transactions flowing through the service-plane. If HTTP transaction matches a pcc-rule configured for tag manipulation in pcc-action-profile then a corresponding tag will be inserted/modified/deleted for that HTTP request. This functionality requires THR (TCP Header Rewrite) functionality to update TCP sequence numbers. The actual tag being inserted/modified can be a fixed string and/or attributes which are subscriber specific. In the latter case, Session Pic components send the subscriber-specific attributes that are programmed in the Subscriber-DB using MSS plugin. The DB is accessed by HCM Plug-in to manipulate the HTTP headers.