Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

JSRC for Subscriber Provisioning and Accounting

Juniper Networks Session and Resource Control (SRC) and JSRC Overview

The Juniper Networks Session and Resource Control (SRC) environment provides a central administrative point for managing subscribers and their services. The SRC software runs on Juniper Networks C Series Controllers. The SRC software uses the Diameter protocol for communications between the local SRC peer on a Juniper Networks routing platform and the remote SRC peer on a C Series Controller. The local SRC peer is known as JSRC and is part of the AAA application. The remote SRC peer is the service activation engine (SAE); the SAE acts as the controlling agent in the SRC environment. JSRC and the SAE jointly provide the remote control enforcement functionality (RCEF).

JSRC has the following responsibilities:

  • Request address authorization from the SAE.

  • Request service activations from the SAE.

  • Activate and deactivate services as specified by the SAE. JSRC can activate multiple policies with the same service (dynamic profile) name.

  • Optionally report volume statistics for service accounting.

  • Log out subscribers as specified by the SAE.

  • Update the SAE with status of new service activations and deactivations.

  • Synchronize subscriber state and service information with the SAE.

  • Notify the SAE when subscribers log out.

The SRC software enables the SAE to activate and deactivate subscriber services (described by SRC policies) and log out subscribers. The SAE can control only those resources that have been provisioned through SAE. Therefore, the SAE receives information about only those subscribers for whom JSRC has requested provisioning from the SAE. For example, when a subscriber logs in, but the configuration did not require the session activation path to include SAE provisioning, the SAE does not receive information about this subscriber and cannot control the subscriber session.

Similarly, the SAE can control only the subscriber services that it has activated. When a service is not activated from the SAE—a RADIUS-activated service, for example—the SAE receives no information about the service and has no control over it.

The SAE can also direct JSRC to collect accounting statistics per service session.

Note:

More than one Diameter-based application (function) can run on a router simultaneously.

Benefits of Using JSRC

  • Enables the use of MX Series routers to act as the local peer in a Juniper Networks Session and Resource Control (SRC) environment for centralized management of subscribers and their services.

Hardware Requirements for JSRC for Subscriber Access

JSRC is supported on Juniper Networks MX Series 5G Universal Routing Platforms. JSRC currently supports subscriber sessions on static and dynamic interfaces.

Understanding JSRC-SAE Interactions

This topic describes the sequences of Diameter messages exchanged between JSRC (the local SRC peer) and the SAE (the remote SRC peer) as they interact to perform the following tasks for subscriber access:

  • Subscriber login

  • Service activation

  • Service deactivation

  • Resynchronization

  • SAE-initiated subscriber logout

  • Statistics collection and reporting

  • Subscriber-initiated logout

Subscriber Login

JSRC authorization works as follows for different subscriber types:

  • When you configure both authorization-order jsrc and authentication-order in the access profile, the authorization order applies only to DHCP subscribers affected by the profile and the authentication order applies only to non-DHCP subscribers.

  • When you configure only authorization-order jsrc in the access profile, the authorization order applies to all subscribers affected by the profile.

When a subscriber attempts to log in, the protocol daemon sends an authentication request to AAA. In turn, JSRC sends a Diameter AA-Request message to the SAE. SAE returns a Diameter AA-Answer message that can include the Framed-IP-Address attribute and the Juniper-DHCP-Options AVP (AVP code 2010). JSRC ignores any other optional AVPs included in this AA-Answer message.

JSRC provisioning is enabled for DHCP (and SSC) subscribers when you include the provisioning-order statement at the [edit access profile profile-name] hierarchy level. When the application requests AAA to activate the subscriber's session, JSRC sends an AA-Request message that includes the Juniper-Request-Type AVP (AVP code 2050) with a value that indicates service provisioning is requested from the SAE.

The SAE returns a AA-Answer message that contains an ACK if the request is accepted or a NAK if the request is denied. If the request is accepted, the AA-Answer message includes the Juniper-Policy-Install AVP (AVP code 2020), which is used to specify the service to attach to the subscriber’s interface. When this AVP is included, the SAE sets the Result-Code AVP to 1001 (DIAMETER_MULTI_ROUND_AUTH). This code means that the JSRC must send another AA-Request message to the SAE to report the success or failure of the policy instantiation (service activation) by AAA. JSRC ignores any other optional AVPs included in this AA-Answer message. The SAE returns an AA-Answer message to acknowledge this second AA-Request message.

Subscriber Service Activation and Deactivation

SAE policies provision subscriber services. After a subscriber is logged in, the SAE can send a PPR message to JSRC to activate or deactivate services. A given PPR can include the Juniper-Policy-Install AVP (AVP code 2020) to activate a service, the Juniper-Policy-Remove AVP (AVP code 2027) to deactivate a service, or both (for different services). A PPR can include no more than three of these AVPs (install, remove, or mixed).

JSRC sends a PPA message to the SAE when it has completed the tasks requested in the PPR. The PPA indicates the success or failure of the actions requested in the PPR.

Note:

If you use RADIUS or the CLI to deactivate a service that the SAE, the SAE becomes unsynchronized with the state of subscribers on the routing engine.

Subscriber Resynchronization

During resynchronization, JSRC informs the SAE about the services that are active for the provisioned subscribers. Either JSRC or the SAE initiates the resynchronization.

  • The SAE initiates resynchronization at startup or when a backup SAE takes over session control due to resource limits or conditions on the primary SAE. The SAE clears its database of all entries in preparation for the synchronization.

  • JSRC initiates resynchronization at JSRC startup, such as when AAA starts or restarts.

    JSRC can also initiate resynchronization in another circumstance. When an SAE in a multi-SAE environment becomes active, it must send an SRQ to JSRC as its first message. JSRC then locks the Origin-Host AVP of the active SAE. JSRC subsequently triggers resynchronization if it receives a message from any other SAE as indicated by the Origin-Host AVP. Such an incident can occur if communication between the active SAE and a standby SAE is interrupted.

Both entities initiate a resynchronization by sending an SRQ message. The recipient responds with an SRR message. After the SRR is sent, regardless of whether the SAE or JSRC initiates the synchronization, JSRC sends an AA-Request message to the SAE for each provisioned subscriber present in the session database. The AA-Request message includes a Juniper-Policy-Install AVP for the active services. The SAE returns an AA-Answer message with an ACK to acknowledge receipt.

Subscriber Session Terminated by the SAE

When the SAE terminates a subscriber session, it sends an ASR message to JSRC. JSRC causes AAA to send a logout request to the DHCP (or SSC) client application. When the DHCP client application accepts the logout request, JSRC includes an ACK in the ASR message it sends to the SAE to signify success. If the DHCP client application does not accept the request, then JSRC includes a NAK in the ASR to signify failure. The DHCP client application is responsible for initiating the actual logout sequence with AAA.

Statistics Collection and Reporting per Service Rule

Statistics information can be sent from the router to the SAE or from the SAE to the router. Both the Diameter Accounting-Request (ACR) and Accounting-Answer (ACA) messages include the Juniper-Acct-Record AVP (AVP code 2053), which identifies the policy (service) for which accounting information is requested.

Subscriber Logout

When the DHCP (or SSC) client application sends a subscriber logout notice to AAA, JSRC sends an STR message to notify the SAE that the provisioned subscriber session is being terminated. The SAE returns an STA message to JSRC, and JSRC notifies DHCP that the logout is complete.

JSRC Provisioning for Dual-Stack Subscribers

Starting in Junos OS Release 18.1R1, you can include the dualstack-support statement at the [edit jsrc] hierarchy level to configure JSRC provisioning for dual-stack subscribers so that it reports information about the separate stacks for a given subscriber, using a single JSRC session. In earlier releases, the DHCPv4 and DHCPv6 stacks are treated as a single subscriber; the remote SRC peer (SAE) is not informed about whether only one family or both families are active. The statistics are reported as an aggregate of both families rather than separated by family. The default behavior starting in Junos OS Release 18.1R1 is the same as the behavior in earlier releases.

This dual-stack provisioning behavior is not backward compatible with other releases. Table 1 on page 2 lists some of the differences in behavior when dual-stack support is configured and when it is not configured (the default).

Table 1: Differences Between JSRC Dual-Stack Behavior by Release

Dual-Stack Support Configured

Dual-Stack Support Not Configured

When the first network family is activated, sends the addresses for only that family in the initial request to the provisioning server.

When the first network family is activated, requests provisioning from the provisioning server (SAE; remote SRC peer).

When the second network family is activated, sends a special family-activate packet to inform the provisioning server that the family is active.

When the second network family is activated, reports nothing to the provisioning server.

When the next-to-last network family is deactivated, sends a special family-deactivate packet to inform the provisioning server that the family is no longer active.

When the next-to-last network family is deactivated, reports nothing to the provisioning server.

Reports IPv4 and IPv6 statistics separately.

Reports subscriber and services statistics as an aggregate of statistics for both IPv4 and IPv6 statistics.

Benefits of JSRC Dual-Stack Provisioning

  • Enables SAE to be aware of which network families are currently active for a subscriber.

  • Enables collection of accurate accounting statistics per address family, rather than an aggregated count that includes statistics for both families without distinction.

AA-Request Messages When Dual-Stack Support Configured

When dualstack-support is configured, Diameter AA-Request (AAR) provisioning messages sent to the SAE include the following:

  • IPv4 or IPv6 addresses of the currently active network families as well as the families that are in the process of being activated. When either address type is not included in the AAR message, it means that the corresponding network family is not active and is not being activated when the request is sent.

  • For IPv4 addressing, the following Diameter AVPs when they are available in the subscriber’s session database entry:

    • Framed-IP-Address (AVP 8)

    • Framed-IP-Netmask (AVP 9)

  • For IPv6 addressing, the following Diameter AVPs and Juniper Networks Diameter AVPs when they are available in the subscriber’s session database entry:

    • Framed-IPv6-Address (AVP 168)

    • Framed-IPv6-Prefix (AVP 97)

    • Delegated-IPv6-Prefix (AVP 123)

    • Juniper-IPv6-Ndra-Prefix (AVP 2200)

    • Juniper-Framed-IPv6-Netmask (AVP 2201)

  • The following Juniper Networks Diameter AVPs when they are available in the subscriber’s session database entry:

    • Juniper-Agent-Circuit-Id (AVP 2202)

    • Juniper-Remote-Circuit-Id (AVP 2203)

  • One of the following new values in the Juniper-Request-Type AVP (2636:2050) to notify the SAE when an inactive network family activates or an existing network family deactivates:

    • 4—NETWORK_FAMILY_ACTIVATE

    • 5—NETWORK_FAMILY_DEACTIVATE

    Only the addressing of the family being activated or deactivated is included in the notification.

    Note:

    An activation notification is not sent for the first network family that activates. A deactivation notice is not sent for the last family that deactivates.

  • When the AAR message is used for synchronization and recovery, only the addressing for the currently active address families for that subscriber. The AAR message does not include addressing for deactivated families.

Accounting-Request Messages When Dual-Stack Support Configured

When dualstack-support is configured, the Diameter Accounting-Request (ACR) messages always include both IPv4 and IPv6 statistics, even when the value is zero.

Statistics are reported for the life of the subscriber session and not merely for the life of the network family session. When one of the network families is inactive, JSRC continues to report the last statistics value for the inactive family with the current statistics of the active network family. If the deactivated family becomes active again, the new family statistics are added to the existing values.

The following Juniper Networks Diameter AVPs (IANA enterprise number 2636) are used to report IPv6 statistics:

  • Accounting-IPv6-Input-Octets attribute (2204)

  • Accounting-IPv6-Output-Octets attribute (2205)

  • Accounting-IPv6-Input-Pkts attribute (2206)

  • Accounting-IPv6-Output-Pkts attribute (2207)

These IPv6 AVPs are not used when dualstack-support is not configured. In that case the IPv6 statistics are aggregated with the IPv4 statistics in the corresponding IPv4 AVPs.

Network Family Activation and Deactivation Notification When Dual-Stack Support Configured

The following sequence describes client and authd process (daemon) behavior when a network family is activated:

  1. A subscriber initiates login.

  2. The client application on the router, such as PPP or DHCP, sends an authentication and authorization (AA) request to authd.

  3. The authd process sends the AA request as configured and returns the response to the client application, which then returns a response to the subscriber.

  4. The client application builds and configures the subscriber’s interface on the router with information from the client dynamic profile.

  5. The client application sends the first network family activation request to authd.

  6. The authd process sends a provisioning request to the SAE that contains the addresses of the family that is being activated. Because authd sends a provisioning request for the first family activation, there is no reason to also send a family-activation notification.

  7. The SAE returns policies (services) for authd to activate for the subscriber.

  8. The authd process activates those services and sends a family-activation ACK response to the client application.

  9. The client application might send a family activation request for the other network family.

    1. The authd process activates any services for that specific network family and then sends a family-activation ACK response to the client application.

    2. The authd process then sends a family-activation notification to the SAE with the addresses of the second family. The AAR message includes the Juniper-Request-Type AVP (2636:2050) with a value of 4 (NETWORK_FAMILY_ACTIVATE). The notification includes only addresses for this family.

For deactivations, the client application sends a family deactivation request only when both network families are active. The authd process deactivates the network family (and any associated services) as requested and sends the SAE a family deactivation notification with the addresses for that family. The AAR message includes the Juniper-Request-Type AVP (2636:2050) with a value of 5 (NETWORK_FAMILY_DEACTIVATE). The notification includes only addresses for this family.

However, when the last network family deactivates, the client sends a termination request, which causes authd to send the JSRC-Acct-Stop message to the SAE. Consequently there is no need for authd to send a family deactivation notification.

JSRC Configuration Overview

You can configure the JSRC client application to work with Session and Resource Control (SRC) to centrally manage subscribers and services. JSRC requests address and service authorizations from the remote SRC peer (the SAE), activates and deactivates services as specified by the SAE, logs out subscribers as specified by the SAE, and synchronizes subscriber state and service information with the SAE.

To configure JSRC:

  1. Configure the JSRC partition.
  2. Assign the JSRC partition.
  3. Configure JSRC authorization for subscribers.
  4. Configure JSRC provisioning for subscribers.
  5. (Optional) Configure JSRC to exclude an AVP from Messages Sent to SAE.
  6. Configure service accounting by JSRC.
  7. Configure JSRC support for dual-stack subscribers.
  8. Configure JSRC event tracing as part of general authentication service tracing operations.

Configuring the JSRC Partition

JSRC works within a specific logical system:routing instance context, called a partition.

Note:

Currently, only a single partition is supported; you must configure it within the default logical system:routing instance context.

Before you configure the JSRC partition, perform the following task:

Configuration for the JSRC partition consists of naming the partition and then associating a Diameter instance, the SAE hostname, and the SAE realm with the partition.

To configure the JSRC partition:

  1. Create the partition.
  2. Specify the Diameter instance for the JSRC partition.
    Note:

    Currently, only the default Diameter instance, master, is supported.

  3. Configure the destination host for the JSRC partition.
  4. Configure the destination realm for the JSRC partition.

Assigning a Partition to JSRC

You must associate a configured JSRC partition with the JSRC instance that you are configuring.

Before you assign a partition to JSRC, perform the following task:

To assign the JSRC partition:

  • Specify the partition name.

Authorizing Subscribers with JSRC

You can configure AAA to use JSRC in an SRC environment to request authorization from the SAE when AAA is verifying whether a DHCP subscriber can access the router. When JSRC authorization is configured, AAA ignores any configured authentication order settings.

Before you configure JSRC authorization, perform the following tasks:

  • Create the subscriber access profile at the [edit access profile] hierarchy level.

  • Define the subscriber username with the username-include statement in the authentication configuration for DHCP local server or DHCP relay.

To configure JSRC authorization:

  • Specify jsrc as the authorization method in the profile.

Provisioning Subscribers with JSRC

You can configure AAA to use JSRC in an SRC environment to request provisioning from the SAE to instantiate services for an authenticated subscriber.

Before you configure JSRC provisioning for subscribers, perform the following task:

  • Create the subscriber access profile at the [edit access profile] hierarchy level.

To configure JSRC provisioning:

  • Specify jsrc as the provisioning method in the profile.

Configuring JSRC for Dual-Stack Subscribers

By default, JSRC provisioning for dual-stack subscribers treats the DHCPv4 and DHCPv6 stacks as a single subscriber. The remote SRC peer (SAE) is not informed about whether only one family or both families are active. The statistics are reported as an aggregate of both families rather than separated by family.

Starting in Junos OS Release 18.1R1, you can configure dual-stack support so that JSRC reports information about the separate stacks for a given subscriber, using a single JSRC session.

When you configure dual-stack support for JSRC, Diameter AA-Request (AAR) provisioning messages sent to the SAE include Diameter AVPs (IANA enterprise number 2636) to convey the IPv4 and IPv6 addressing information that is available in the session database.

For IPv4, that includes the following AVPs:

  • Framed-IP-Address (AVP 8)

  • Framed-IP-Netmask (AVP 9)

For IPv6, that includes the following AVPs:

  • Framed-IPv6-Address (AVP 168)

  • Framed-IPv6-Prefix (AVP 97)

  • Delegated-IPv6-Prefix (AVP 123)

  • Juniper-IPv6-Ndra-Prefix (AVP 2200)

  • Juniper-Framed-IPv6-Netmask (AVP 2201)

JSRC also includes information about the access line if it is available in the session database, by means of Juniper-Agent-Circuit-Id (AVP 2202) and Juniper-Remote-Circuit-Id (AVP 2203).

When the first network family is activated, JSRC sends the addresses for only that family in the initial request to the provisioning server. When the second network family is activated, the AAR message includes the Juniper-Request-Type AVP (2050) with a value of 4 to signify family activation. When the next-to-last family is deactivated, the same AVP is sent with a value of 5 to signify the deactivation.

To configure JSRC provisioning to report dual-stack subscriber information by family:

  • Enable dual-stack support.

Excluding AVPs from Diameter Messages for JSRC

Starting in Junos OS Release 14.2, you can configure the router to exclude AVPs from Diameter messages that are sent to the SAE from JSRC.

Note:

Currently, only the user-name (1) AVP is supported.

To configure JSRC to exclude an AVP in Diameter messages:

  1. Specify that you want to configure JSRC settings in the access profile.
  2. Specify that you want to configure Diameter attribute usage.
  3. Configure the router to exclude the specified AVP from the specified messages. The following example excludes the user-name AVP from authorization and provisioning AAR messages.

Service Accounting with JSRC

A service session represents a service for a specific subscriber. Service sessions exist in the context of a subscriber session. JSRC activates and deactivates services as specified by the SAE (remote SRC peer). JSRC can collect and report service accounting data by volume. JSRC accounting requires that either classic firewall filters or fast update firewall filters be configured to count service packets—the service packet information provides the volume statistics.

Note:

JSRC supports only volume statistics accounting for service sessions. Time statistics and subscriber accounting are not supported.

JSRC service accounting supports both accounting based on service activation/deactivation and interim accounting.

  • Service activation/deactivation accounting—When accounting is enabled, JSRC sends an accounting start message to the SAE when it activates a service and an accounting stop message when it deactivates the service. The start message initiates the accounting session and provides initial information about the service session. The stop message terminates the accounting session and reports the final (cumulative) accounting data.

  • Interim accounting—When interim accounting is enabled for a service session, JSRC sends interim accounting messages to the SAE at a specified interval to report the cumulative accounting information available at that time. Interim accounting is ignored when accounting is not enabled for the corresponding service session.

JSRC accounting for a service begins when the service is activated, and remains in effect while the service is active. The SAE specifies the service (policy) to be activated for the subscriber with the Juniper-Policy-Install AVP (AVP code 2020). When this AVP includes the Juniper-Acct-Collect AVP (AVP code 2054), JSRC initiates service activation/deactivation accounting for the service.

JSRC initiates interim accounting when the Juniper-Policy-Install AVP includes the Acct-Interim-Interval AVP (AVP code 85). In this case, JSRC updates the accounting values at the interval specified in the AVP— in the range 600 through 86,400 seconds. Aggregate counters are reported for the dual stack case.

JSRC and the SAE exchange Diameter Accounting-Request (ACR) and Accounting-Answer (ACA) messages to communicate accounting data. Both messages include the Juniper-Acct-Record AVP (AVP code 2053) to identify the service for which accounting information is requested.

JSRC sends ACR messages to report accounting data to the SAE. The ACR message includes the Accounting-Record-Type AVP (AVP code 480) to specify the kind of accounting record that it is sending. When a service is activated, this AVP has a value of START_RECORD. When a service is deactivated, it has a value of STOP_RECORD. For interim accounting, ACR messages are sent at the specified accounting interval and the AVP has a value of INTERIM_RECORD.

In addition to specifying the accounting record type, the ACR messages include standard RADIUS attributes to specify the desired statistics: Acct-Input-Octets [42], Acct-Output-Octets [43], Acct-Input-Packets [47], Acct-Output-Packets [48], and Acct-Session-Time [46].

The SAE returns ACA messages to the JSRC to acknowledge receipt of the ACR messages.

An access profile specifies subscriber access authentication and accounting parameters. When a service is activated through JSRC, the accounting reports can be sent either to the SAE or to RADIUS. The default configuration sends the reports to the SAE; you can also configure this by including the service accounting-order activation-protocol statement in the access profile. To send the reports instead to the RADIUS server, include the service accounting-order radius statement in the access profile.

When a service is activated through RADIUS rather than through JSRC, the accounting reports of the service session are sent to the RADIUS server.

Configuring Service Accounting with JSRC

In addition to the configuration shown here, the network context for JSRC service accounting includes the configuration of firewall filters to count the statistics, Diameter, JSRC, the subscriber services, RADIUS, and the SRC.

You can configure JSRC to report accounting statistics for service sessions.

To configure service accounting by JSRC:

  1. Configure JSRC to provision subscriber services.
  2. Configure service accounting to be provided by the application that provisions the service—JSRC.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
18.1R1
Starting in Junos OS Release 18.1R1, you can include the dualstack-support statement at the [edit jsrc] hierarchy level to configure JSRC provisioning for dual-stack subscribers so that it reports information about the separate stacks for a given subscriber, using a single JSRC session.
14.2
Starting in Junos OS Release 14.2, you can configure the router to exclude AVPs from Diameter messages that are sent to the SAE from JSRC.