Service Nodes in an SRC Environment Overview
The Juniper Networks MX Series Ethernet Services Router supports the packet-triggered subscribers and policy control (PTSP) feature that allows the dynamic application of policies on a per-subscriber basis to individual source IP addresses flowing through a given interface. A subscriber context is created for each distinct source IP address seen in a given underlying interface. This feature can be used to support subscribers who are controlled by a subscriber termination device, such as a Broadband Remote Access Service (B-RAS) or gateway GSN (GGSN) device, that is connected to an MX Series router. MX Series routers that support PTSP are called service nodes.
Service nodes act as intelligent policy enforcement points for IP edge devices with these features:
Single access–agnostic policy enforcement point that allows the easy introduction of new services independent of access technologies. Subscribers and policies are tracked by a subscriber’s IP address and do not require subscriber interfaces.
Single point for management, reporting, and troubleshooting, which includes support for dynamic policy attachment and updates.
When the MX Series router acts as a service node in the SRC environment, the SRC software supports this role by providing subscriber awareness to the service node.
To support service nodes, the SRC software:
Collects and dispatches RADIUS accounting events.
Creates an IP edge attachment session and stores it.
Manages profile and policies for IP address sessions (PTSP sessions) by associating the session with the correct attachment session and sending profile and policy information to the MX Series router.
Sends start, interim, and stop accounting records containing usage information from the service node and attachment information from the IP edge device.
SRC Software in the Service Node Environment
Figure 1 illustrates a simple deployment scenario.
This simple deployment scenario includes the following components:
Customer premises equipment (CPE)—Equipment with which the network user connects to an IP network. This device can be any device that allows a subscriber to connect to the network—including a wireless phone, a DSL router, or a cable modem.
Access device—Device that terminates the IP session for the network user. This device must authenticate the network user and notify the access manager when an attachment session is created and stopped. Optionally, the device can notify the access manager when the attachment session is modified. This device can be a gateway GSN (GGSN), a Broadband Remote Access Server (B-RAS), or a cable modem termination system (CMTS).
Access manager—Device that manages access devices. This device must be able to forward session start/stop notifications to the SRC cluster. This device can be a RADIUS accounting server.
SRC cluster—Collection of SRC components that manage attachment sessions and PTSP device sessions, including:
Subscriber information collector (SIC)—SRC component that receives session start, modification, and stop notifications from the access manager. The start, modification, and stop notifications are RADIUS accounting start, interim update, and stop events.
Session State Registrar (SSR)—SRC component that stores attachment sessions and notifies other components about updates.
SAE—SRC component that manages service sessions and policies for IP subscriber sessions.
Application Services Gateway (ASG), API client—SRC cluster uses the gateway to allow external API clients to manipulate sessions maintained in the cluster.
MX Series router—MX Series Ethernet Services Router that supports the PTSP feature (service node), which detects IP flows and manages policies for those sessions.
In this simple deployment scenario, the following actions might occur:
- The CPE connects to an access device, which terminates an IP address and provides lifecycle notifications but provides limited policy management capabilities. The SRC cluster learns about CPE attachment sessions from the access manager.
- Traffic from the CPE to the network is routed through the MX Series routers that support PTSP (service nodes).
- The service node detects IP flows from the CPE and notifies the SRC cluster about the IP flow. Traffic from a single CPE can be routed through multiple MX Series routers; each router detects and manages individual flows that must be coordinated on the SRC cluster level.
- The SRC cluster associates the IP flow information with identity information that it has learned for the CPE attachment session and uses this information to select the appropriate policies for handling the subscriber traffic.
Service Node Scenario When the Access Device is Managed by the SRC Software
In a PTSP deployment scenario where the SRC manages the edge access device, sessions initiated on the access device are written directly to the SSR database—for example, when the PTSP scenario uses a Juniper Networks E Series Broadband Services Router or MX Series Ethernet Services Router (JSRC) as the access device. Figure 2 illustrates this deployment scenario.
An SAE user-tracking plug-in publishes subscriber session information to the SSR after the subscriber has successfully logged in through the access node. The SSR writer plug-in is a user-tracking plug-in that creates a user session record and writes it into the SSR. The SSR writer plug-in specifies which SAE plug-in attributes are written to the SSR and the SSR maps the SAE plug-in attributes to SSR attributes. The SSR writer plug-in configuration specifies the association between the SAE plug-in attributes, which are used in the SAE access session and carried in the user-tracking event, and the respective SAE plug-in attributes configured in the SSR association. Plug-in attributes associated with the SSR can be mapped either to the plug-in attributes used to identify the access session or to literal values.
An access subscriber session can be created before or after the PTSP IP flow is detected.
User Login Scenario When the Access Session is Created Before the PTSP Session
When a user logs in through the SRC-managed access device, a user session is created in the SAE. A user-tracking event is then sent to the SSR writer plug-in, which provides sufficient information to successfully identify the user and store the associated record in the SSR. When the PTSP flow is detected by the SAE, a temporary user session is created and a user authentication event is sent to the SSR reader authentication plug-in to authenticate the user. The SSR reader authentication plug-in reads the record and updates the event with the session attributes read from the SSR. When the user is authenticated, a permanent user session is created and the SAE installs the policies on the service node managing PTSP traffic.
User Login Scenario When the PTSP Session is Created Before the Access Session
The service node detects the new IP flow and creates a PTSP session. The SRC software starts an anonymous subscriber session and the SAE installs policies on the service node. The user logs in through the access device, an access user session is created in the SAE, and the user-tracking event is sent to the SSR writer. The record associated with the subscriber session is stored in the SSR. When the access session is created in the SSR, the identity of the PTSP subscriber session is changed through an SSR event. The SAE receives a notification that contains the IP-Address and VPN-ID attributes. The event handler searches for matching sessions that have been authorized by the SSR reader authentication plug-in and performs a re-authentication of those sessions. If the re-authentication does not change the existing session, the event handler re-evaluates all policies and sends updates to the PTSP router.
When the access session is dropped because the user logs out, the SSR writer plug-in updates the session state associated with the user. After the access session state becomes inactive in the SSR, the SAE receives a notification and terminates the PTSP subscriber session associated with the attachment session and all services are deactivated. In the case when the PTSP session is dropped but the access session remains active, the user may activate PTSP services at a later time reusing the same access session stored in the SSR. PTSP session termination does not affect the attachment session.