JSRC for Subscriber Provisioning and Accounting

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.

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.

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.

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.