Diameter and diameter applications

Forwarding and routing of the application level (NASREQ/Gx/Gy) messages in Diameter depends on the message type (requests or answers). Requests messages are forwarded or routed based on destination hosts and realms. Forwarding and routing of request messages is based on the Diameter hosts and realms and is dependent on the two tables maintained in each node between the source and destination:

• A peer table contains a list of active peers (adjacent Diameter nodes). The peers in the peer table are populated though configuration and are not learned dynamically. The peer table contains only the peer name (no realms).

• A realm-based routing table contains mapping of realms and applications to peers. A realm-based routing table is in the SR OS created per Diameter node. Realms in the routing table are learned dynamically from peers from the origin-realm AVP in Capability Exchange Answer (CEA) messages and cannot be statically configured.

The selection of a peer to which a request message is sent can be a two step process. First, if the request message contains the destination-host AVP, the peer table is checked to find out if there is a matching peer available. If so (the destination is directly connected), the request message is forwarded to it, without further checking the routing table for the next hop (this is called forwarding phase). If the matching host is not present in the peer table (the destination is not directly connected), or the destination-host AVP is not present in the request message (in other words, CCR-I), then the diameter routing table is checked for the matching realm. This is referred to as routing phase. Each routable request message must contain the destination realm AVP and the destination realm is a mandatory configuration parameter in an SR node for a Diameter application. However, on the application level, a Gx and Gy session can also learn the destination realm from received application messages. In this case, the learned value overwrites the configured value.

If the Diameter realm table does not contain an entry for the destination realm and the application, the request message is forwarded to the default peer, if one is configured. There can be only one default peer per Diameter node. Unlike a realm routing entry in the realm table, the default peer is application (NASREQ, Gx, Gy) unaware, and it is used as a route of last resort, regardless whether the selected path leads to a server supporting this application.

If the default peer is not configured, messages destined for a realm that is not known in the realm routing table, are dropped.

Application level answer messages do not rely on the routing or forwarding table. They are forwarded in reverse direction of the matching requests in the transactional cache of each traversed Diameter node and the Hop-by-Hop AVP. The Hop-by-Hop AVP is set to a locally unique value by each Diameter node that forwards request messages. This AVP is then used to match request and answer messages in the reverse direction. This allows a Diameter response to follow the same route as the corresponding Diameter request.

Static Diameter realm routes are used to reach remote realms, which are not directly connected to the local realm configured on the SR OS.

They are configured under the Diameter peer:

configure
   aaa
      diameter 
           node <origin-host-string> [origin-realm <origin-realm-string>]
                peer index <index> [<destination-host-string>]      
                    route index <index> [realm <name>] [application <name>] [create]
                        preference <1-100> 
                

There are two preference parameters that can be configured under this CLI hierarchy:

• Peer preference is configured directly under the peer and applies only to routes learned using the capability exchange phase and not the static routes. This parameter determines the directly-connected preference of the learned routes relative to the static routes. Currently, there can be only one learned realm route per peer.

• Static route preference is configured for each static route. The static route with the numerically lowest preference is used.

The order of the evaluation for realm routes is:

• The route with the lowest preference is used. The preference of static routes is individually configured, whereas the preference of the learned routes is configured by a peer.

• In case of a preference tie, the route configured by the peer with the lowest index is chosen.

A static route is installed in the realm table only if the peer in which it has been configured is in an open state.

Host names and realm names are essential in Diameter routing. They are conveyed in Diameter messages through the following AVPs:

• Origin-Host

• Origin-Realm

• Destination-Host

• Destination-Realm

Origin-host and origin-realm AVPs are used to identify nodes in Diameter networks. Every Diameter message must carry these two AVPs. In SR OS, the origin hostname must be statically configured through CLI. The configuration of the origin realm is optional. If the origin realm is not configured, the origin realm is extracted from the origin hostname. The first ‟.” in the configured origin hostname is used as a delimiter between the host portion and the realm portion. If there is no ‟.” in the configured origin hostname, then the origin hostname is used as both, the origin hostname and the origin realm name. Origin host and realm names do not support online changes (once they are configured, because they cannot be changed without first deleting the Diameter node hierarchy).

The origin-host and origin-realm names received from peers, as a result of successful Capability Exchange negotiation, are used to populate peer and realm tables in SR nodes.

While origin-host and origin realms are used for identification of Diameter nodes within realms, the destination-hosts and destination-realms are used in Diameter request messages for forwarding and routing purposes. They steer the message through the Diameter network toward the destination.

The destination hostname that is used by applications (NASREQ, Gx, Gy) cannot be configured in an SR node and is only learned from the incoming application level messages (the origin-host AVP in the incoming request or answer messages). within each Diameter session.

On the other hand, the destination realm that is used in application request messages is a mandatory configuration parameter in an SR node. However, its value can optionally be learned from the incoming application messages and any newly learned value overwrites the previous one. This learning is performed on a per-message basis. The destination realm value (configured or learned) is not used to populate the realm table but is only used on the application level to populate the destination-realm AVP in every application level request message.

Because the destination-host AVP is optional and the destination-realm is mandatory in application request messages, the destination-realm can be used without the destination-host in forwarding and routing decisions to guide the request message to its destination. The destination-realm used in initial request message (CCR-I) is a configured one, while the destination-host is not used in the same message because it has not been learned yet.

Destination-host or destination-realm AVPs are never present in:

• Diameter messages that are not to be proxied or relayed (such as CER)

• Diameter answer messages

The destination-host AVP is cleared in all Diameter request messages that are retransmitted by the Diameter application (NASREQ, Gx, Gy). Messages retransmitted by the Diameter Base (peer failover related retransmissions) do not have the destination-host AVP cleared.

The Diameter application retransmits the message with the assumption that the path to the destination-host, or the destination-host itself is unavailable. Clearing of the destination-host AVP provides a new chance to for the Diameter Base to deliver the message to an alternate destination in the same realm. This alternate destination must be in a geo-redundant setup where sessions are synchronized between the geo-redundant nodes.

The T-bit can be set in a retransmitted Diameter request message as a direct indication that the message may be a duplicate. For example, if the original request message is received by the server, but the answer is lost on its way back to the sender. If the original request message is not received by the server, then the message is not a duplicate from the server point of view. Detection of the duplicates on the application server side is important, especially in credit control applications. Duplicate requests received by the server should not be interpreted as new requests for credit, or new reports for usage, otherwise, double accounting or billing may occur.

On the other hand, the indirect indication of a duplicate Diameter request message on the server side relies on the comparison of the origin-host and end-to-end identifier fields that must always be the same in original and retransmitted messages. This requires the server to keep a history of received messages (or some metadata after it has sent the answer). Normally, after the answer is sent, reference to end-to-end identifier is lost and the duplicate detection is not possible. While some servers may implement such logic to rely on implicit identification of duplicate messages, not all of them are expected to implement such logic. For this reason, setting the T-bit explicitly is a more reliable mechanism to detects duplicates on the server side.

The T-bit in an SR is set on retransmitted messages that are triggered by a timeout (via application) as well as on retransmitted messages triggered by an imminent peer failure.

The T-bit is not set on any message that is retransmitted in response to any explicit error message (3002, 3004, and so on). An explicit error message is an indication that the original request message has reached some Diameter node and solicited a specific response from that node, and therefore is not considered a duplicate.

RFC 4006, Diameter Credit Control Application, specifies a graceful service termination mechanism using the Final-Unit-Indication to indicate that an Answer message contains the final units for the service. When the final units are consumed, the action is specified with the Final-Unit-Action AVP.

Final-Unit-Indication ::= < AVP Header: 430 >
          { Final-Unit-Action } 
         *[ Restriction-Filter-Rule ]     
         *[ Filter-Id ]    
          [ Redirect-Server ]

In SR OS, with the Final-Unit-Action AVP = TERMINATE, the subscriber host or session is disconnected. With the Final-Unit-Action = REDIRECT or RESTRICT_ACCESS, the out-of-credit-action as specified in the credit-control-policy or category-map is executed. In the case of REDIRECT, the URL specified in the Redirect-Server AVP is used when IPv4 HTTP redirect is enabled as the out of credit action and the following conditions are met:

• a Final-Unit-Indication AVP is present in the Multiple-Services-Credit-Control AVP of a CCA message

• the Final-Unit-Action AVP is set to REDIRECT (1)

• a Redirect-Server AVP is included with the following:

  • the Redirect-Address-Type AVP set to URL (2)

  • the Redirect-Server-Address AVP containing the URL to use for this rating group (category-map)

• the out of credit action for the corresponding rating group is set to change-service-level using one of the following CLI commands:

  • configure subscriber-mgmt credit-control-policy policy-name out-of-credit-action change-service-level

  • configure subscriber-mgmt category-map category-map-name category category-name out-of-credit-action-override change-service-level

• an IPv4 HTTP redirection action with allow-override is specified in the exhausted credit service level context for the corresponding rating group using the command configure subscriber-mgmt category-map category-map-name category category-name exhausted-credit-service-level ingress-ip-filter-entries entry entry-id action http-redirect url allow-override.

In all other cases, the URL specified in the Redirect-Server-Address AVP is ignored and the configured URL is used if HTTP redirect is enabled as the out of credit action.

The Restriction-Filter-Rule and Filter-Id AVPs included in the Final-Unit-Indication AVP are ignored.

Use the following show commands to find the active URL when an out-of-credit-action change-service-level is triggered that includes an IPv4 HTTP redirect action in the credit control ingress IP filter entries:

• show service active-subscribers filter [subscriber sub-ident-string]

  This command displays the active IPv4 ingress filter identifier.

• show filter ip ip-filter-id

  With the filter identifier found in the previous command, this command displays the credit control inserted entries (Origin = ‟Inserted on ingress by Credit Control”), including the IPv4 HTTP redirect action with the static configured URL. The optional allow-radius-override flag may be shown. This flag is common for RADIUS and Diameter-based overrides, where the flag indicates that the URL may have been overridden by the Diameter Credit Control server. Use the next command to determine if an override was specified.

• show service active-subscribers credit-control

  This command displays the URL received from the Diameter Credit Control server for a rating group or category with ‟Out of Credit Action = ChangeServiceLevel” active. The URL is displayed in the ‟HTTP Rdr URL Override” field.

EFH - example call flow shows a sample call flow with EFH enabled. The following describes the call flow.

1. A Diameter Gy session is established between the Broadband Network Gateway (BNG), or credit control client, and the OCS, or credit control server.

2. A Credit Control Request Update (CCR-U) message is sent via the primary peer but no answer (CCA-U) is received. A timeout occurs which triggers a failover to the secondary peer. The same CCR-U is sent via the secondary peer. Again no answer is received. Because the CCFH value is set to CONTINUE for this session, EFH is activated.

3. The following EFH actions occur:

   • Service to the user continues uninterrupted.

   • If this is the first attempt to re-establish a Diameter Gy session:

     1. The failed Diameter Gy session (session ID x) is terminated without sending a CCR-T (Terminate) message.

     2. The unreported used credits for each rating group are stored in an EFH unreported credit counter.

     3. A new Diameter Gy session (new session ID y) is created internally but is not yet established with the OCS; the CCR-I (Initial) message is sent later.

   • For all subsequent attempts to re-establish a Diameter Gy session:

     1. The failed Diameter Gy session (session ID y or y+n) is terminated without sending a CCR-T (Terminate) message.

     2. The unreported used interim credit for each rating group is added to the EFH unreported credit counter.

     3. A new Diameter Gy session is created internally but not yet established with the OCS: the CCR-I (Initial) message is sent later. The internal Diameter session is created with the same session ID (y) or a new session ID (y+n) based on a configuration knob.

   • Pre-configured interim credit is assigned to all rating groups and an optional validity time is installed.

4. If either all interim credit is used or the validity time expires for one of the rating group, an attempt is made to establish the new Diameter Gy session (session ID y or y+n) with the OCS.

   A CCR-I message is sent via the primary peer but no answer (CCA-I) is received. A timeout occurs which triggers a failover to the secondary peer. The same CCR-I is sent via the secondary peer. Again no answer is received.

   EFH stays active for this user session.

   Steps 3 and 4 can be repeated multiple times until the maximum number of interim credit allocations is reached and the user session is terminated (not shown in this example call flow).

5. The EFH actions are as follows:

   • Service to the user continues uninterrupted.

   • The failed Diameter Gy session (session ID y or y+n) is terminated without sending a CCR-T (Terminate) message.

   • The unreported used interim credit for each rating group is added to the EFH unreported credit counter.

   • A new Diameter Gy session is created internally but is not yet established with the OCS: the CCR-I (Initial) message is sent later. The Diameter session is created with the same session ID (y) or a new session ID (y+n) based on the configuration.

   • Pre-configured interim credits are assigned to all rating groups and an optional validity time is installed.

6. If either all interim credits are used or the validity time expires for one of the rating groups, an attempt is made to establish the new Diameter Gy session (session ID y or y+n) with the OCS.

   A CCR-I message is sent via the primary peer.

7. An answer (CCA-I) is received with new granted service units (credit). Because communication with the OCS is restored, EFH becomes inactive.

8. The new Diameter Gy session resumes normal operation. Optionally, the EFH unreported credit usage is reported together with the usage from the newly granted credit in the next CCR-U credit negotiation for the rating group.

9. An answer (CCA-U) is received.

10. The service to the user continues and is uninterrupted during the OCS connectivity failure.

For EFH to become active, the Credit Control Failure Handling (CCFH) value must be set to CONTINUE.

For a new session, the CCFH value is set in the configuration:

configure
    subscriber-mgmt
        diameter-application-policy <application-policy-name> [create]
            on-failure [failover {enabled|disabled}] handling continue

For ongoing sessions, the CCFH value is determined from the configuration or can be overridden by the OCS by including the following AVP in an answer message (CCA-I or CCA-U):

[427] Credit-Control-Failure-Handling AVP = CONTINUE (1)

EFH is triggered when the CCFH value is set to CONTINUE and one of the following conditions occurs:

• transmit failure

  failure to send a CCR-I or CCR-U message

  EFH trigger: transmit failure shows an example of a transmit failure.

  

• timeout

  failure to receive an answer (CCA-I or CCA-U) within the configured timeout

  EFH trigger: timeout shows an example of a timeout.

  

• protocol error

  failure because of a protocol error; seen as a Result-Code at command level in an answer message (CCA-I or CCA-U)

  EFH trigger: protocol error shows an example of a protocol error.

  

• failure

  reception of unknown Result-Code values in a Credit Control Answer message. Diameter Gy known transient and permanent failures result-code values lists the known Transient and Permanent Failures Result-Code values.

  Table 4. Diameter Gy known transient and permanent failures result-code values

  Result code		Command level		MCSCC level
  		CCA-I	CCA-U
  4001	DIAMETER_AUTHENTICATION_REJECTED	known	known	unknown
  4010	DIAMETER_END_USER_SERVICE_DENIED	unknown	known	known
  4011	DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE	known	known	known
  4012	DIAMETER_CREDIT_LIMIT_REACHED	unknown	known	known
  5003	DIAMETER_AUTHORISATION_REJECTED	known	known	known
  5030	DIAMETER_USER_UNKNOWN	known	known	unknown
  5031	DIAMETER_RATING_FAILED	unknown	known	known

• a Diameter Gy message decoding error, for example (this is not an exhaustive list):

  • a missing Result-Code AVP

  • an unknown command code received

  • an incorrect session ID, origin host or origin realm in CCA

  • quota received for unexpected rating group

  • quota received with Result-Code 4012 (Credit Limit Reached)

EFH interim credit can be specified in two ways:

• as a single volume interim credit value that is assigned to all rating groups of the Diameter Gy session with active EFH and that have no default credits configured

• configure subscriber-mgmt
     diameter-application-policy <application-policy-name> create
        gy
           extended-failure-handling
              interim-credit
                 volume <credits> {bytes|kilobytes|megabytes|gigabytes}
  

• as a single volume or time interim credit value per rating group (default credit)

  The activity threshold configured in the category map also applies to all rating groups that have time-based interim credit assigned while EFH is active.

• configure subscriber-mgmt
     category-map <category-map-name> create
        activity-threshold <kilobits-per-second>
        category <category-name> create
           default-credit time <seconds>
           default-credit volume <credits> <bytes|kilobytes|megabytes|gigabytes>
  

A single validity time value can be specified and applied to all rating groups that have interim credit assigned, regardless of whether the interim credit is configured for all rating groups in the Diameter application policy or per rating group in the category map.

configure subscriber-mgmt
   diameter-application-policy <application-policy-name> create
      gy
         extended-failure-handling
            interim-credit
                 validity-time <seconds>

The maximum number of times that interim credit is assigned to all rating groups of a Diameter Gy session when EFH is active can be limited in the configuration. The max-attempts value also corresponds with the maximum number of attempts to establish a new Diameter Gy session with the OCS (the default maximum attempts = 10).

configure subscriber-mgmt
   diameter-application-policy <application-policy-name> create
      gy
         extended-failure-handling
            interim-credit
               max-attempts <count>
               max-attempts infinite

An attempt to establish a new Diameter Gy session with the OCS is made when one of the following conditions occurs.

• The assigned interim credit for one of the rating groups is used.

• The validity time of the interim credit for one of the rating groups expires.

When the maximum number of attempts is reached and a new Diameter Gy session is not yet successfully established, then the user session is terminated; that is, the corresponding subscriber hosts are deleted from the system.

The reporting of used EFH interim credit can be enabled using the following CLI command:

configure subscriber-mgmt
   diameter-application-policy <application-policy-name> create
      gy
         extended-failure-handling
            interim-credit
               [no] reporting

With reporting enabled, the following accumulated used credit is reported when a new Diameter Gy session is established with the OCS and usage reporting is triggered for a rating group:

• unreported used credit granted via the initial Diameter Gy session that caused the EFH activation

• used interim credit when EFH was active

• used credit granted via the new Diameter Gy session

By default, reporting is disabled and all the used credit from the initial Gy session and all used interim credit are discarded.

EFH is enabled by specifying no shutdown in the extended-failure-handling CLI context in a Gy Diameter application policy.

configure subscriber-mgmt
   diameter-application-policy <application-policy-name> create
      gy
         extended-failure-handling
            no shutdown

EFH states lists the EFH states for a Diameter Gy session.

configure subscriber-mgmt
    diameter-application-policy gy-1 create
        --- snip ---
        on-failure handling continue
        gy
            --- snip ---
            extended-failure-handling
                no new-session-id          # default
                interim-credit
                    no reporting           # default
                    volume 100 megabytes
                    validity-time 900
                    max-attempts 96
                exit
                no shutdown
            exit
        exit
    exit

In this example, EFH is enabled and when active, 100 Mbytes of volume interim credit is assigned to all rating groups of the Diameter Gy session with a validity time of 900 s. The maximum number of attempts to establish a Diameter Gy session with the OCS is 96.

Therefore, a maximum of 96 x 100 Mbytes or 9.6 Gbytes can be consumed before the user session is terminated (that is, the subscriber host is deleted from the system) when the OCS remains unreachable. Alternatively, when less than 100 Mbytes per rating group is consumed every 15 minutes (900 s), the user is disconnected after 900 s x 96 = 24 hours when the OCS remains unreachable.

configure subscriber-mgmt
    category-map "cat-map-1" create
        activity-threshold 10
        category "cat-1" create
            description "Time interim credit per category"
            default-credit time 900
            rating-group 1
            queue 1 ingress-egress
        exit
        category "cat-2" create
            description "Volume interim credit per category"
            default-credit volume 10 megabytes
            rating-group 2
            queue 2 ingress-egress
        exit
        category "cat-3" create
            no default-credit
            rating-group 3
            queue 3 ingress-egress
        exit
    exit
    diameter-application-policy gy-1 create
        --- snip ---
        on-failure handling continue
        gy
            --- snip ---
            extended-failure-handling
                new-session-id
                interim-credit
                    reporting
                    volume 100 megabytes
                    validity-time 900
                    max-attempts 96
                exit
                no shutdown
            exit
        exit
    exit

In this example, EFH is enabled and when active, the following interim credit is assigned:

• 900 s of time interim credit to rating group 1 (category cat-1) with a validity time of 900 s. The activity threshold applies. When the usage stays below 10 kbytes/s, no time credit is used.

• 10 Mbytes of volume interim credit to rating group 2 (category cat-2) with a validity time of 900 s

• 100 Mbytes of volume interim credit to rating group 3 (category cat-3) with a validity time of 900 s

For inactive users, the validity time ensures that new Diameter Gy session connection attempts with the OCS are made at regular intervals.

For each attempt to establish a Diameter Gy session with the OCS, a new session ID is used.

When a new Diameter Gy session is successfully established, the EFH unreported credit for each rating group is included in the used service units when reporting is triggered for that rating group on the new Diameter Gy session.

When no new Diameter Gy session is established after 96 attempts, the user session is terminated; that is, the subscriber hosts are deleted from the system.

Subscribers with Diameter Gy sessions that have EFH enabled can be displayed with the following CLI command:

# show service active-subscribers credit-control extended-failure-handling [state] [summary]

where the EFH state can be set to:

• active

  shows subscribers with Diameter Gy sessions that have EFH enabled and EFH is active

• inactive

  shows subscribers with Diameter Gy sessions that have EFH enabled and EFH is inactive

• all

  shows subscribers with Diameter Gy sessions that have EFH enabled and EFH is active or inactive.

Example output:

A:BNG-1# show service active-subscribers credit-control extended-failure-handling
===============================================================================
Active Subscribers
===============================================================================
-------------------------------------------------------------------------------
Subscriber ipoe-msap-002 (sub-profile-1)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
(1) SLA Profile Instance sap:[1/1/4:1201.2] - sla:sla-profile-3
-------------------------------------------------------------------------------
Credit Control Policy: cc-policy-1
Category Map         : cat-map-1
Diameter Session Gy  : bng.domain.com;1464610029;840
CC Failure Handling  : continue
Extended Failure Handling (EFH)
  State              : active
  Attempts           : 1                      Maximum Attempts   : 10
  Active time        : 0d 00:00:10
  Total Active time  : 0d 00:00:10
  Total Active Count : 1
Category Name        : cat-1-time
Ingress Queues       : 1
Egress Queues        : 1
Ingress Policers     :
Egress Policers      :
Credit Volume Used   : 0                    Credit Time Used     : 11
Credit Volume Avail. : 0                    Credit Time Avail.   : 589
Credit Volume Thres. : 0                    Credit Time Thres.   : 0
Credit Expired       : False                Credit Negotiating   : False
Out Of Credit Action : None                 Quota Holding Time   : 0
Validity Time Used   : 0                    Validity Time Avail. : 0
EFH Unreported Credit
  Current Volume     : 0                      Current Time       : 601
  Total Volume       : 0                      Total Time         : 601
Category Name        : cat-2-volume
Ingress Queues       : 4
Egress Queues        : 4
Ingress Policers     :
Egress Policers      :
Credit Volume Used   : 38400                Credit Time Used     : 0
Credit Volume Avail. : 10447360             Credit Time Avail.   : 0
Credit Volume Thres. : 0                    Credit Time Thres.   : 0
Credit Expired       : False                Credit Negotiating   : False
Out Of Credit Action : None                 Quota Holding Time   : 0
Validity Time Used   : 13                   Validity Time Avail. : 587
EFH Unreported Credit
  Current Volume     : 1527600                Current Time       : 0
  Total Volume       : 1527600                Total Time         : 0
-------------------------------------------------------------------------------
IP Address
                MAC Address          Session        Origin       Svc        Fwd
-------------------------------------------------------------------------------
10.1.1.101
                00:51:00:00:00:02    IPoE           DHCP         1000       Y
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Number of active subscribers : 1
===============================================================================

The following information is displayed In the Extended Failure Handling (EFH) section of the example:

Extended Failure Handling (EFH)
  State              : active

State indicates that EFH is enabled and active. Another possible state is ‟inactive”. When EFH is disabled, no EFH information is included.

Attempts           : 1                      Maximum Attempts   : 10

Attempts indicates the number of times interim credit has been assigned to all categories followed by an attempt to establish a new Diameter Gy session with the OCS. When the attempt to establish a new Diameter Gy session with the OCS is still failing after the Maximum Attempts value is reached, then the user session is terminated (that is, the subscriber hosts are deleted from the system).

Active time        : 0d 00:00:10

Active time indicates the time because the EFH state became active for this subscriber session.

Total Active time  : 0d 00:00:10
  Total Active Count : 1

Total Active time indicates the accumulative time of all occurrences that EFH was active during the lifetime of this subscriber session.

Total Active Count indicates the number of times that EFH was active during the lifetime of this subscriber session.

For each category (rating group), the EFH Unreported Credit is displayed:

EFH Unreported Credit
  Current Volume     : 0                      Current Time       : 601
  Total Volume       : 0                      Total Time         : 601

The Current Volume and Current Time counters contain, respectively, the unreported volume and time credit for the current occurrence of the EFH in an active state. These counters include the unreported used credit for the initial Diameter Gy session that caused the EFH state to become active and the unreported interim credit from previous attempts. Used interim credit for the current attempt per category (rating group) is shown in the following counters:

Credit Volume Used   : 0                    Credit Time Used     : 11
Credit Volume Avail. : 0                    Credit Time Avail.   : 589

The Total Volume and Total Time counters contain respectively the accumulated total unreported volume and time credit for the previous occurrences of EFH active state. The total counters are updated when the EFH state toggles from active to inactive. When interim credit reporting is enabled, the counters are reset to zero when the actual usage reporting happens for that rating group. When interim credit reporting is disabled, the counters are accumulating the total unreported credit during the lifetime of the subscriber session.

Current and Total Volume EFH Unreported Credit counters are the sum of used ingress and egress octets.

For each category (rating group), the validity time is displayed:

Validity Time Used   : 13                   Validity Time Avail. : 587

The following fields are only displayed when the EFH state is active:

• Extended Failure Handling (EFH): ‟Attempts”, ‟Max Attempts” and ‟Active time”

• EFH Unreported Credit: ‟Current Volume” and ‟Current Time”

When EFH is disabled (shutdown), then the EFH information is not included in the credit control output.

The following identification related AVPs are sent to the PCRF through Gx messages to aid in IP-CAN session identification:

• subscription-id AVP (RFC 4006, §8,46)

  This can be used to identify the subscribers on the PCRF. For the supported fields within the subscription-id AVP, see the 7750 SR and VSR Gx AVPs Reference Guide.

• NAS-Port-Id AVP (RFC 2869 / §5.17; RFC 4005 / §4.3)

• AN-GW-Address AVP (3GPP 29.212 / §5.3.49)

• Calling-Station-ID AVP (RFC 4005 / §4.6)

• user-equipment-info AVP (RFC 4006, §8.49)

• logical-access-id AVP (ETSI TS 283 034)

  This contains the circuit-id from DHCPv4 Option (82,1) or interface-id from DHCPv6 option 18. The vendor-id is set to ETSI (13019).

• physical-access-id AVP (ETSI TS 283 034)

  This contains remote-id from DHCPv4 option (82,2) or DHCPv6 option 37. The vendor-id is set to ETSI (13019).

Physical and logical access IDs are also defined in BBF TR-134 (§7.1.4.1).

PDP to PEP direction parameters shows PDP to PEP direction parameters.

A Subscription-id AVP is most commonly used to identify the subscriber but any combination of the above listed parameters can be used to uniquely identify the IP-CAN session on PCRF and consequently identify the subscriber.

In addition, NAS-Port, NAS-Port-Type, and Called-Station-ID AVPs from RFC 4005 (§4.2, §4.4, §4.5) can be passed to the PCRF.

The node allows the NAS-Port-Id to be carried within the Subscription-Id AVP. Because the NAS-Port-Id may not be unique network-wide (two independent nodes may use the same NAS-Port-Id), there is a need for another identifier in conjunction with NAS-Port-Id to make the Subscription-Id unique across the network. This additional identifier is a custom string that can be appended to the NAS-Port-Id. It is defined when the NAS-Port-Id is configured for inclusion in Gx messages. See the 7450 ESS, 7750 SR, and VSR RADIUS Attributes Reference Guide for information to format NAS-Port-Id AVP on the node.

The string can be used to identify the location of the node. For example:

@ALU-MOV-SITE-1

An example of the augmented NAS-Port-Id would look like:

NAS-Port-Id = lag-1.1/1/2:23.2000@ALU-MOV-SITE-1

where: 'lag-1.1/1/2:23.2000' is the part referencing the SAP on the node (port + vlan tags) and the '@ALU-MOV-SITE-1' is the node itself.

The NAS-Port-Id can be then inserted in the Subscription-Id AVP.

Dual-stack (DS) hosts are treated as a single session from the Gx perspective, regardless whether an IPoE session concept is enabled. The difference between the IPoE session and non-IPoE session concept is related to the identification of the hosts for identification and policy management purposes.

If the IPoE session concept is disabled, a dual-stack host is identified by its {MAC,SAP} combination. Consequently, the key used for Gx session creation is based on the same {MAC,SAP} combination.

In some scenarios, this is not sufficient to differentiate hosts on the same SAP for Gx policy management purposes. As a result. a single Gx session is created for all hosts on that SAP. To avoid this creation, the IPoE session concept must be enabled in SR OS, where a Circuit-id or a Remote-id can be used for further differentiation between the Gx managed entities (subscriber-hosts).

The PCRF submits the policy rules per Gx session. The rules are then be applied to the underlying entity that is managed by this Gx session (single or dual stack IPoE host or IPoE session). For PPPoE deployment, the Gx session is automatically tied to the PPPoE session. A notion of a session is native to PPPoE (there is a session ID in PPPoE), and therefore, it is more natural to conceptualize the relationship between a PPPoE session (for single of dual-stack hosts) and a Gx session. By contrast, the concept of a session for IPoE is artificial, and which is why additional consideration is required for IPoE hosts, as described above.

The following example examines a case where IPoE session concept is disabled and consequently the IPoE dual-stack host is tied by a {MAC,SAP} combination.

The CCR-I contains the IP address that was first allocated (meaning, the first IP address that triggered the session creation). The request for the second IP address family triggers (if enabled by configuration) an additional CCR-U that carries the IP address allocation update to the PCRF along with the UE_IP_ADDRESS_ALLOCATE (18) event.

Separately, the CCR-U content mirrors the content of the CCR-I with exception of the pre- allocated IP address or addresses. A single Gx message (CCR-I or CCR-U) carries the update for the DHCPv6 IA-NA+IA-PD and DHCPv6/PPPoE NA+PD address/prefix. This assumes that the NA+PD is requested in a single DHCP message.

Similarly, for the Gx session teardown, the CCR-U messages are sent carrying the UE_IP_ADDRESS_RELEASE event, followed by the CCR-T message.

The message flow is depicted in Gx and DS session instantiation.

For Dual-Stack PPPoE host, the CCR-I is sent when the first IP address is assigned to the host. In the example in Gx and DS session instantiation, processing of the DHCPv6 Replay and CCR-U messages is performed in parallel. In other words, sending the DHCPv6 Reply message to the client is not delayed until the response from the PCRF is received. The reason being is that the Gx session is already established (triggered by the IPv4 host in our example) and all parameters for IPv4 and IPv6 are already known as received in CCA-i. Then, the CCR-U message is simply a notification message, informing the PCRF about the new IPv6 address/prefix being assigned to an existing client.

For PPPoE v6 hosts, the IPv6 address is not obtained during the IPCP phase (only the interface-id is negotiated). Then, the node waits until the IPv6 address/prefix is allocated to the IPv6 hosts before it sends the CCR-I message. Otherwise, the IP address would not be available in CCR-I. This is shown in Gx and PPPoEv6 host instantiation.

Certain scenarios allow the PCRF to send a RAR message to an orphaned Gx session running CCR-T replays on the node. The ESM host associated with the orphaned Gx session does not exist and therefore RAR cannot be applied.

In this scenario, the node replies with RAA carrying Result-Code= DIAMETER_UNKNOWN_ SESSION_ID (5002).

The first CCR-T reply for each Gx session is synchronized, but the consecutive CCR-T replays for the same Gx sessions are not synchronized. When the answer (CCA-t) is received, the CCR-T replay is terminated and this event (deletion of CCR-T replay) is synchronized to the other node.

CCR-T replays are sent from the node that was in SRRP active state at the time when the CCR-T was initiated. They continue to be sent from the same node even if the SRRP is switched over in the meantime.

This entire process can be thought of as if the CCR-T initiating node (active SRRP) armed its MCS peer with CCR-T replay for a Gx session. This occurs at the very beginning, when a CCR-T replay is first initiated for a Gx session. The armed node stays silent until the MCS peer that is actively sending CCR-T replays for a Gx session, reboots. Only when the MCS peer reboots, the armed node starts sending CCR-T replays for a Gx session in the following fashion: first message is sent with cleared T-bit, followed by replays at the configured replay interval and a fresh 24 hour lifetime.

On CPM switchover, the newly active CPM resumes the CCR-T replay with the T-bit set until the lifetime, which is synchronized between the CPMs, expires.

Because ESM and AA modules are part of integrated service offering (ESM with residential AA on the same node), they share the same subscriber-id string. However, Gx interface in ESM is primarily applicable to hosts (basic entity to which policy is applied) while AA has no awareness of hosts. AA is only aware of subscribers (which is, in broader terms, a collection of hosts within a residence). See the 7450 ESS, 7750 SR, and VSR Multiservice ISA and ESA Guide for details on Application Assurance concepts.

AA subscriber state must exist for App-profiles and ASO overrides to be applied.

The app-profile for the aa-sub is applied explicitly by a CCR-I or RAR message with an AVP AA-App-Profile-Name.

App-profiles interact with ASO characteristics in this way:

• The AA-App-Service-Options AVP within the app-profile assignment is optional at subscriber instantiation time and may be used later to modify the policy.

• The newly submitted AA-App-Profile-Name AVP overwrites the one that is already applied. Any ASO AVPs that is received within the Gx message is applied.

  Note: If an app-prof AVP is present, even if it is the same app-profile as currently applied, all previous ASO override policies are removed for the sub.

The state of the subscriber policy attributes is modified by ASO AVPs in this way:

• The app profile can define one or more ASO characteristics attributed to a subscriber.

• If there are multiple ASO AVPs for the same characteristic in the message, the first one takes effect.

• There is no explicit delete of ASO overrides (the PCRF can always resend or change the app-profile to delete all overrides).

For a list of Gx related AVPs supported on the node, see the 7750 SR and VSR Gx AVPs Reference Guide.

Gx overrides are installed via Charging-Rule-Install AVP (for ESM or AA) or ADC-Rule-Install AVP (for AA only – 3GPP Release 11) sent from the PCRF toward the node.

AVP Format:

Charging-Rule-Install ::=       < AVP Header: 1001 >
                                       *[ Charging-Rule-Definition ]
                                       *[ Charging-Rule-Name ]
                                       *[ AVP ]

ADC-Rule-Install ::=       < AVP Header: 1092 >
                                       *[ ADC-Rule-Definition ]
                                       *[ ADC-Rule-Name ]
                                       *[ AVP ]

Every Gx override must have a Charging-Rule-Name (ESM) or ADC-Rule-Name (AA - 3GPP Release 11 and Release 12) associated with it. This is important for returning the override status from the node to the PCRF upon the override instantiation.

The objects (subscriber-hosts) to which the new overrides are applied must exist on the node; otherwise, the override installation fails.

The parameters defining a new override simply replaces the existing parameters that are already applied to the subscriber-host, without the need to remove the previously installed parameters.

There are four types of overrides that are currently supported via Gx:

• ESM string overrides (sla/sub/app-profiles, subscriber-id)

• update of subscriber host QoS information (queue rate change)

• filter override for the subscriber host (including one-time http redirect)

• category-map installation/override

• HTTP redirect override within the filter

A Charging-Rule-Name AVP within the Charging-Rule-Install grouped AVP can have several meanings:

• It can directly reference a preconfigured filter in the system.

• It can directly reference a preconfigured subscriber profile (sla and sub).

• It can directly reference a preconfigured category map.

• It can directly reference an ESM string (such as an inter-destination-string used to associate the subscriber host with a Vport configuration).

• Or, if there is an HTTP redirect override, it serves as a special container within which the HTTP redirect URL is defined. Note that HTTP redirect override is not to be confused with PCC rule-based HTTP redirect.

In all of the above cases, the existing objects applied to the subscriber-host is replaced with the referenced object.

It is important to distinguish two locations for invoking the Charging-Rule-Name AVP for overrides:

• directly under the Charging-Rule-Install AVP

  Then, the Charging-Rule-Name references the predefined structures (profiles, filter-ids, cat-maps, and so on) on the node. The type of the structure is contained within the Charging-Rule-Name AVP in the form of a reserved keyword that has to be prepended to the identifier of structure:

  Filter installation/overrides:

  • Charging-Rule-Name = Ingr-v4:<id>

  • Charging-Rule-Name = Ingr-v6:<id>

  • Charging-Rule-Name = Egr-v4:<id>

  • Charging-Rule-Name = Egr-v6:<id>

  • Charging-Rule-Name = In-Othr-v4:<id> (othr - one-time-http-redirect)

  • Charging-Rule-Name = In-Othr-v6:<id> (othr - one-time-http-redirect)

  Subscriber-Id override:

  • Charging-Rule-Name = Sub-Id:sub-id-string

  Profile installation/overrides:

  • Charging-Rule-Name = Sla-Profile:sla-profile-name

  • Charging-Rule-Name = Sub-Profile:sub-profile-name

  Inter-destination string override:

  • Charging-Rule-Name = Inter-Dest:inter-dest-string

  Usage-Monitoring:

  • Charging-Rule-Name = Cat-Map:category-map-name

  AA:

  • Charging-Rule-Name = AA-UM:<string-name>

  • Charging-Rule-Name=AA-Functions:<string-name>

  In summary, the reserved prefixes ingr-v4:,ingr-v6:, egr-v4:, egr-v6:, in-othr-v4:, in-othr-v6:, sub-id:, sla-profile:, sub-profile:, inter-dest:, cat-map:, aa-um: and aa-functions: have special meaning within the Charging-Rule-Name AVP on the node.

  One exception to this is HTTP redirect override, which is described separately.

• under the Charging-Rule-Install

  Charging-Rule-Definition AVP. In this case, the override itself is not pre-provisioned on the node but instead, directly defined in the Charging-Rule-Definition. Part of the override definition is the name assignment via Charging-Rule-Name AVP. The Charging-Rule-Name AVP is used to report on the override status.

  For example, the Charging-Rule-Name AVP for QoS overrides is an arbitrary name. This AVP is part of Charging-Rule-Definition AVP in which QoS-Information is provided. Such Charging-Rule-Name is used to report errors related to instantiation of the override.

  Another example of the override defined within the Charging-Rule-Definition AVP is HTTP redirect override:

  Charging-Rule-Name = v4-http-url:<name>
  Redirect-Information ::= < AVP Header: 1085 >
  
  [ Redirect-Address-Type ]
  [ Redirect-Server-Address ]
  

  and

  
  Charging-Rule-Name = v6-http-url:<name>
  Redirect-Information ::= < AVP Header: 1085 >
  [ Redirect-Address-Type ]
   [ Redirect-Server-Address ]
  

  The ADC-Rule-Name AVP within the ADC-Rule-Install grouped AVP handles application policy related processing (AA). This AVP is applicable under the ADC-Rule-Install—ADC-Rule-Definition AVP. In this case the ADC rule itself is not pre-provisioned on the node but instead directly defined in the ADC-Rule-Definition. In AA, such rule definition can define AA overrides that are applied to the subscriber. In other words, the existing objects for the subscriber are replaced with the ones referenced in the rule. Part of the ADC rule definition is the ADC rule name assignment via ADC-Rule-Name AVP. The ADC-Rule-Name defined in such manner is used to report on the rule status.

  The AA-Functions: prefix in the ADC rule name is reserved for ADC rule definitions applicable to AA-functions (namely, app-profile and ASOs):

  ADC-Rule-Name = AA-Functions:aa-rule-name

  Then the aa-rule-name is an arbitrary name that is used in rule status reporting.

  If that ADC-Rule-Name is used in AA Usage-Monitoring, the ‟AA-Functions:” prefix must not be present (Usage-Monitoring in AA is covered in detail in the 7450 ESS, 7750 SR, and VSR Multiservice ISA and ESA Guide).

  Note: AA-Function AVP and AA-Usage-Monitoring cannot coexist in the same ADC rule.

The Charging-Rule-Definition AVP (AVP code 1003, 3GPP 29.212 §5.3.4) is of type Grouped, and it defines the override sent by the PCRF to the node.

The Charging-Rule-Name in this AVP can be arbitrarily set and it is used to uniquely identify the override in error reporting.

Charging-Rule-Definition ::= < AVP Header: 1003 >
                                 { Charging-Rule-Name }
                                 [ QoS-Information ]
                                 [ Nas-Filter-Rule]
                                 [ Alc-NAS-Filter-Rule-Shared]
                                 *[ AVP ]

The ADC-Rule-Definition AVP (AVP code 1094, 3GPP 29.212 §5.3.87) is of type Grouped, and it defines the ADC override sent by the PCRF to the node. The ADC-Rule-Name AVP within the ADC-Rule-Definition AVP uniquely identifies the ADC policy rule and it is used to reference to a policy rule in communication between the node and the PCRF within one IP CAN session.

ADC-Rule-Definition ::= < AVP Header: 1094 >
              { ADC-Rule-Name }
              [AA-Functions]
              *[ AVP ]

HTTP redirect override submitted via the Gx interface overrides the current URL string defined in the filter that is currently applied to the subscriber-host. The override is implemented through the standard Redirect-Information AVP nested within the Charging-Rule-Definition (CRD) AVP.

IPv4:

Charging-Rule-Install
   Charging-Rule-Definition
      Charging-Rule-Name = v4-http-url:<name>
         Redirect-Information ::= < AVP Header: 1085 >
           [ [ Redirect-Address-Type ]
           [ [ Redirect-Server-Address ]

IPv6:

Charging-Rule-Install
   Charging-Rule-Definition
      Charging-Rule-Name = v6-http-url:<name>
         Redirect-Information ::= < AVP Header: 1085 >
           [ Redirect-Address-Type ]
           [ Redirect-Server-Address ]

The keywords v4-http-url and v6-http-url are special keywords that must be part of the Charging-Rule-Name (CRN) AVP. These keywords can be followed by an arbitrary string name.

The purpose of the <name> string in the CRN AVP is for the PCRF to differentiate between different HTTP redirect overrides. However, the name string in the context of the http url host override command in a filter has no meaning on the node, and therefore it is ignored. This means that there can be only one HTTP redirect override per host and per address family on a node.

The outcome of this Gx directive (Redirect-Information AVP without the Flow-Information AVP within the Charging-Rule-Definition AVP) is the override of the HTTP redirect URL in the currently applied subscriber-host filter. The filter definition must explicitly allow overrides via the allow-radius-override keyword.

As long as the override rule is present in the system (meaning, it has been submitted via the Gx and has not been explicitly removed since), the override tries to enforce itself when both of the following two conditions are met:

• A filter with the action http-redirect is applied to the subscriber-host. This is valid whether the filter was there when the rule was submitted, or whether the filter was applied after the rule was submitted.

• The filter definition allows http-redirect overrides (filter with the allow-radius-override keyword).

If the above conditions are not met, the override is accepted (the node responds with RAA=OK) and stored by the system, although it is not applied until the above conditions are met.

For the HTTP URL host, the CRD directive must not contain any flow information or any other action besides the Redirect-Information AVP. Otherwise, the Diameter encoding fails and an error response is generated for RAR while CCR-I is silently dropped.

With the exception of HTTP redirect override, overrides cannot be removed by the Charging-Rule-Remove AVP. They can only be overridden, and consequently the Charging-Rule-Remove AVP is ignored. It is ignored only for regular overrides and not for PCC rules (see PCC rules) or for HTTP redirect override. An HTTP redirect override can be removed whether it is active (a filter with HTTP redirect action is applied) or inactive (a filter without HTTP redirection is applied).

Charging-Rule-Remove ::= < AVP Header: 1002 >
   Charging-Rule-Name = v4-http-url:<name>
   Charging-Rule-Name = v6-http-url:<name>

The name string in the CRN AVP is ignored in the context of HTTP redirect override. This means that the removal of HTTP redirect override with any name removes the currently installed HTTP redirect override.

Similarly, the installation of the HTTP redirect override replaces any currently installed HTTP redirect override, regardless of the name string (implicit removal of the current HTTP redirect override, followed by the installation of the new one).

The node replies with RAA=OK if a properly formatted Charging-Rule-Remove directive with any name is received for HTTP redirect override.

The instantiation of HTTP redirect overrides via the Gx can be summarized as:

• The Central AVP for the Gx overrides in SR OS is the Charging-Rule-Install AVP. Multiple overrides can be submitted to an node via a single Charging-Rule-Install AVP, or each Gx override can be submitted via its own Charging-Rule-Install AVP.

• Gx override is identified by the Charging-Rule-Name AVP. This AVP is also used to report on the status of Gx override. The Charging-Rule-Name can reference a pre-configured construct on the node (profiles, cat-maps, filters) or it can be assigned by PCRF to identify the PCRF defined override (QoS policy modifications, HTTP redirect AA ASO modifications, and so on).

• With the exception of the HTTP redirect override, overrides cannot be removed by the Charging-Rule-Remove AVP. They can only be overridden. The Charging-Rule-Remove AVP is ignored for Gx overrides.

The following is an example of Gx override instantiation where all Gx overrides are submitted under a single Charging-Rule-Install AVP. The AVPs in this example can be included in the CCA-i, CCA-u or RAR messages sent from the PCRF.

The outcome of the override is the following:

• The subscriber-id is overridden with the new name ‛residence-1’.

• New ingress v4 and egress v6 filters are installed.

• New sub-profiles and sla-profiles are applied to the subscriber host.

• The subscriber host is associated with the Vport named vport-AN-1.

• The existing HTTP redirect URL is overwritten with a new URL.

• Characteristics for queues 5 and 7 are overridden.

• The egress rate limit for the subscriber is overridden.

• ASOs are overridden.

Charging-Rule-Install ::= <AVP Header: 1001>
Charging-Rule-Name <AVP Header: 1005> = ‟sub-id:residence-1”
Charging-Rule-Name <AVP Header: 1005> = ‟ingr-v4:7”
Charging-Rule-Name <AVP Header: 1005> = ‟eggr-v6:5”
Charging-Rule-Name <AVP Header: 1005> = ‟Sub-Profile:prem”
Charging-Rule-Name <AVP Header: 1005> = ‟Sla-Profile:voip+data”
Charging-Rule-Name <AVP Header: 1005> = ‟Inter-Dest:vport-AN-1”

Charging-Rule-Definition <AVP Header: 1003>
Charging-Rule-Name <AVP Header: 1005> ‟v4-http-url:http-redir-1”
Redirect-Information < AVP Header: 1085 >
  Redirect-Address-Type < AVP Header: 433 > = 2 -> URL type
    Redirect-Server-Address < AVP Header: 435 > = 
‟http://www.operator.com/portal.php?mac=$MAC”


Charging-Rule-Definition <AVP Header: 1003>
Charging-Rule-Name <AVP Header: 1005> = ‟premium-service”
QoS-Information <AVP Header: 1016>
Alc-Queue <AVP Header; vnd ALU; 1016>
 Alc-Queue-id <AVP Header; vnd ALU; 1007> = 5
 Max-Requested-Bandwidth-UL <AVP Header: 516> = 10000 
         Max-Requested-Bandwidth-DL <AVP Header: 515> = 100000  
         Guaranteed-Bitrate-UL <AVP Header: 1026> = 5000
             Guaranteed-Bitrate-DL <AVP Header: 1027> = 50000
 Alc-Committed-Burst-Size-UL <AVP Header; vnd ALU; 1008> = 1000
     Alc-Maximum-Burst-Size-UL <AVP Header; vnd ALU; 1009> = 2000
     Alc-Committed-Burst-Size-DL <AVP Header; vnd ALU; 1010> = 1000
     Alc-Maximum-Burst-Size-DL <AVP Header; vnd ALU; 1011> = 2000

 Alc-Queue <AVP Header; vnd ALU; 1006>
Alc-Queue-id <AVP Header; vnd ALU; 1007> = 7
 Max-Requested-Bandwidth-UL <AVP Header: 516> = 10000 
         Max-Requested-Bandwidth-DL <AVP Header: 515> = 100000  
         Guaranteed-Bitrate-UL <AVP Header: 1026> = 5000    
        Guaranteed-Bitrate-DL <AVP Header: 1027> = 50000
 Alc-Committed-Burst-Size-UL <AVP Header; vnd ALU; 1008> = 1000
     Alc-Maximum-Burst-Size-UL <AVP Header; vnd ALU; 1009> = 2000
     Alc-Committed-Burst-Size-DL <AVP Header; vnd ALU; 1010> = 1000
     Alc-Maximum-Burst-Size-DL <AVP Header; vnd ALU; 1011> = 2000

Alc-Sub-Egress-Rate-Limit <AVP Header; vnd ALU; 1016> = 10000

 

ADC-Rule-Install ::= <AVP Header: 1092>
ADC-Rule-Definition <AVP Header: 1094>
ADC-Rule-Name <AVP Header: 1096> = ‟AA-Functions:apps”
AA-Functions
AA-App-Profile-Name = ‟apps-prof”
AA-App-Service-Options 
AA-App-Serv-Options-Name = ‟bitttorent”
AA-App-Serv-Options-Value = ‟low-prio-1mbps”
AA-App-Service-Options
AA-App-Service-Options-Name =  ‟ftp”
AA-App-Service-Options-Value = ‟hi-prio”

In the following example, all Gx overrides are submitted via a separate Charging-Rule-Install AVP:

Charging-Rule-Install ::= <AVP Header: 1001>
     Charging-Rule-Name <AVP Header: 1005> = ‟sub-id:residence-1”

Charging-Rule-Install ::= <AVP Header: 1001>
     Charging-Rule-Name <AVP Header: 1005> = ‟ingr-v4:7”

Charging-Rule-Install ::= <AVP Header: 1001>
     Charging-Rule-Name <AVP Header: 1005> = ‟eggr-v6:5”

Charging-Rule-Install ::= <AVP Header: 1001>
     Charging-Rule-Name <AVP Header: 1005> = ‟Sub-Profile:prem”

Charging-Rule-Install ::= <AVP Header: 1001>
     Charging-Rule-Name <AVP Header: 1005> = ‟Sla-Profile:voip+data”

Charging-Rule-Install ::= <AVP Header: 1001>
     Charging-Rule-Name <AVP Header: 1005> = ‟Inter-Dest:Gx-inserted-string”

Charging-Rule-Install ::= <AVP Header: 1001>
   Charging-Rule-Definition <AVP Header: 1003>
      Charging-Rule-Name <AVP Header: 1005> ‟v4-http-url:http-redir-1”
         Redirect-Information < AVP Header: 1085 >
            Redirect-Address-Type < AVP Header: 433 > = 2   URL type
            Redirect-Server-Address < AVP Header: 435 > = 
                  ‟http://www.operator.com/portal.php?mac=$MAC”
Charging-Rule-Install ::= <AVP Header: 1001>
     Charging-Rule-Definition <AVP Header: 1003>
          Charging-Rule-Name <AVP Header: 1005> = ‟premium-service”
          QoS-Information <AVP Header: 1016>
               Alc-Queue <AVP Header; vnd ALU; 1016>
                 Alc-Queue-id <AVP Header; vnd ALU; 1007> = 5
                         Max-Requested-Bandwidth-UL <AVP Header: 516> = 10000 
                   Max-Requested-Bandwidth-DL <AVP Header: 515> = 100000  
           Guaranteed-Bitrate-UL <AVP Header: 1026> = 5000
           Guaranteed-Bitrate-DL <AVP Header: 1027> = 50000
                         Alc-Committed-Burst-Size-UL <AVP Header; vnd ALU; 1008> = 1000
                  Alc-Maximum-Burst-Size-UL <AVP Header; vnd ALU; 1009> = 2000
                  Alc-Committed-Burst-Size-DL <AVP Header; vnd ALU; 1010> = 1000
              Alc-Maximum-Burst-Size-DL <AVP Header; vnd ALU; 1011> = 2000
               
               Alc-Queue <AVP Header; vnd ALU; 1006>
                         Alc-Queue-id <AVP Header; vnd ALU; 1007> = 7
                         Max-Requested-Bandwidth-UL <AVP Header: 516> = 10000 
           Max-Requested-Bandwidth-DL <AVP Header: 515> = 100000  
           Guaranteed-Bitrate-UL <AVP Header: 1026> = 5000    
           Guaranteed-Bitrate-DL <AVP Header: 1027> = 50000
                         Alc-Committed-Burst-Size-UL <AVP Header; vnd ALU; 1008> = 1000
              Alc-Maximum-Burst-Size-UL <AVP Header; vnd ALU; 1009> = 2000
              Alc-Committed-Burst-Size-DL <AVP Header; vnd ALU; 1010> = 1000
              Alc-Maximum-Burst-Size-DL <AVP Header; vnd ALU; 1011> = 2000
                    
               Alc-Sub-Egress-Rate-Limit <AVP Header; vnd ALU; 1016> = 10000
                        
ADC-Rule-Install ::= <AVP Header: 1092>
     ADC-Rule-Definition <AVP Header: 1094>
          ADC-Rule-Name <AVP Header: 1096> = ‟AA-Functions:apps”
          AA-Functions
               AA-App-Profile-Name = ‟apps-prof”
               AA-App-Service-Options 
                    AA-App-Service-Options-Name = ‟bitttorent”
                    AA-App-Service-Options-Value = ‟low-prio-1mbps”
               AA-App-Service-Options
                    AA-App-Service-Options-Name =  ‟ftp”
                    AA-App-Service-Options-Value = ‟hi-prio”

Gx overrides (QoS rates, sub/sla-profiles, filters, and so on) can be examined individually with subscriber specific operational commands. In the example below, fields in bold can be overridden.

show service active-subscribers detail 
========================================================================
Active Subscribers
========================================================================
------------------------------------------------------------------------
Subscriber residence-1 (prem)
-------------------------------------------------------------------------------
I. Sched. Policy : basic_policy                     
E. Sched. Policy : N/A               E. Agg Rate Limit: 10000
I. Policer Ctrl. : N/A                              
E. Policer Ctrl. : N/A                              
Q Frame-Based Ac*: Disabled                         
Acct. Policy     : N/A               Collect Stats    : Disabled
Rad. Acct. Pol.  : N/A                              
Dupl. Acct. Pol. : N/A                              
ANCP Pol.        : N/A                              
HostTrk Pol.     : N/A                              
IGMP Policy      : N/A                              
MLD Policy       : N/A                              
Sub. MCAC Policy : N/A                              
NAT Policy       : N/A                              
Def. Encap Offset: none             Encap Offset Mode: none
Avg Frame Size   : N/A                              
Vol stats type   : full                             
Preference       : 5                                
Sub. ANCP-String : "iope-left-dupl"
Sub. Int Dest Id : "Gx-inserted-string" 
Igmp Rate Adj    : N/A                              
RADIUS Rate-Limit: N/A                              
Oper-Rate-Limit  : 10000       


show service id 10 subscriber-hosts detail 
=============================================================
Subscriber Host table
=============================================================
Sap                    Subscriber                
  IP Address                                     
    MAC Address          PPPoE-SID Origin       Fwding State
-------------------------------------------------------------
[1/1/5:6.2]            iope-sub
  192.168.0.11
    00:00:65:06:02:01    N/A       DHCP         Fwding
-------------------------------------------------------------
Subscriber-interface  : int1
Group-interface       : g1
Sub Profile           : prem 
SLA Profile           : voip+data
App Profile           : apps-prof
Egress Q-Group        : N/A
Egress Vport          : N/A
Acct-Session-Id       : D896FF0000001852EDFF46
Acct-Q-Inst-Session-Id: D896FF0000001952EDFF51
Address Origin        : DHCP
OT HTTP Rdr IP-FltrId : N/A
OT HTTP Rdr Status    : N/A
OT HTTP Rdr Fltr Src  : N/A
HTTP Rdr URL Override : N/A
GTP local break-out   : No

A PCC rule consists of traffic classifiers (Flow-Information AVPs) required for traffic identification, and one or more actions associated with such classified traffic. PCC rules are unidirectional, which means that each rule is applied on ingress or egress. They are provisioned from PCRF via Gx interface.

Traffic classification is based on:

• 5 Tuple (IPv4 and IPv6)

• DSCP bits. When the content hosting device cannot be identified by the IP address, port and protocol, the DSCP marking can be used instead. Then, the DSCP marking is set by the client application and the markings should be preserved throughout the network until they reach the BNG.

Supported actions are:

• rate limiting (in | out)

• forwarding class (FC) change (in | out)

• QoS forward (in | out)

• next hop redirect (in)

• service ID redirect (in)

• HTTP redirect (in)

• service gating function (in | out)

• filter forward/drop (in | out)

• Usage-Monitoring (in | out)

A PCC rule that is submitted to the node via PCRF is internally instantiated using two basic policy constructs, QoS policy and filter policy (ACL). This internal division is transparent to the operator at the time of the rule provisioning. The operator perceives Gx as a unified method for provisioning policy rules, whether the rule is QoS-related or filter-related.

The type of action within the PCC rule determines whether the PCC rule is split between the QoS policy and the filter policy.

Rules with actions:

• rate limit

• forwarding class change

• QoS forward; matching traffic is forwarded without QoS actions and do not match on the next entry (match and exit behavior). This is equivalent to an allowlist entry.

• Usage-Monitoring

are converted into a QoS policy while the rules with actions:

• next hop redirect

• service ID redirect

• HTTP redirect

• gate function (enable/drop)

• filter forward/drop

are converted into filter rules.

The operator should be aware of this division for dimensioning (scaling) purposes. Operational commands can be used to reveal resource consumption on the node.

A PCC rule is addressed to a subscriber-host (single stack or dual stack) via the diameter session-id. However, qos-policy-related entries are applied per sla-profile instance because the qos resources are allocated per sla-instance. An sla-profile instance and sla-profile are two distinct concepts. An sla-profile instance is an instantiation of the sla-profile which is a configuration concept in which parameters are defined. An sla-profile is instantiated per a subscriber-host, or multiple subscriber-hosts can share an sla-profile instance as long as they belong to the same SAP and have the same subscriber ID.

This means that all hosts sharing the same sla-profile instance inherits the change. The sla-profile instance and sla-profile are two distinct concepts. The sla-profile instance is an instantiation of the sla-profile which is a configuration concept in which parameters are defined. The sla-profile is instantiated per a subscriber-host, or multiple subscriber-hosts can share an sla-profile instance as long as they belong to the same SAP and have the same subscriber-id.

Filter-related entries are applied per each subscriber-host, whether the hosts are sharing or not sharing an sla-profile instance.

The concept of splitting the rules is shown in PCC rule conversion on the node.

The PCC rule instantiation fails if a PCC rule contains only actions without any classification, or if it contains only classification without any actions.

Subscriber host must have an explicit static (or base) filter or qos-policy before any dynamic entries can be inserted via Gx. For example, a base filter/qos-policy can be referenced by a sla-profile when the subscriber is instantiated. However, the parameters in the base qos-policy and base filter cannot be modified via Gx.

In the absence of explicitly defined qos-policy for the subscriber host, the default qos-policy 1 is in effect. Then, PCC rules with a QoS-related action cannot be applied.

PCC rule entries can be inserted in specifically allocated range in the base filter or qos-policy. The insertion point is controlled by the operator. This is shown in Static and dynamic QoS-policy/filter entries. The entries reserved for PCC rules start at the beginning of the range specified by the following CLI command:

sub-insert-shared-pccrule start-entry <entry-id> count <count> 

under the following CLI hierarchy:

config>filter>ip-filter>
config>filter>ipv6-filter
config>qos>sap-ingress>
config>qos>sap-egress>

An entry corresponds to a Flow-Information AVP and is equivalent to a match condition defined as any combination of the following parameters under a filter or qos-policy ip-criteria:

• source IP address

• destination IP address

• source port or port range

• destination port or port range

• protocol

• DSCP

Such defined entry maps into a single CAM entry with exception of port range configured as match criteria whereby a single port range command can expand into multiple CAM entries.

Static entries in filter/qos-policy can be inserted before and after the range reserved for PCC rules.

Policy (defined in this context as a collection of static and dynamic rules) sharing between the subscriber hosts is depicted in Policy cloning. To simplify CAM scaling explanations, the examples in this section assume that one rule within the policy occupies exactly one CAM entry. For simplicity, only PCC rules are shown but in reality a subscriber-host policy consist of PCC rules together with the base qos-policy/filter.

A policy, as a set of rules, can be shared amongst the subscriber-hosts. However, when a new rule is added to one of the subscriber-host, the newly created set of rules for this host becomes unique. Hence, a new policy for the subscriber-host is instantiated. This new policy consumes additional resources for all the old rules (clone of the old policy) along with the new rule. Figure below shows that a new policy (3) is instantiated when rule D is added to User 1, even though the rules A, B and C remain the same for Users 1 and 2. Policy 3 is a newly cloned with the same rules as Policy 1, and then Rule D is added onto it. On the other hand, when the rule C is applied to User 3, the set of rules becomes identical to the set of rules for User 2. Thus the two can start sharing rules and therefore the resources are freed.

Each PCC rule has a subscriber-host scope and it is referred to it by its name which is assigned by the operator on PCRF. The rules with exactly the same content but different rule names are evaluated into separate rules. To optimize performance and maximize scale, it is recommended that the rules sharing the same content have the same name (as provisioned in the PCRF).

PCC rules can be removed from the node via a Gx directive by referencing the PCC rule name. The rule name is supplied via the Charging-Rule-Name AVP at the time of the rule submission to the node by the PCRF. There is no Gx mechanism that would remove all PCC rules at once. Each PCC rule must be removed individually.

The AVP used to remove the rule from the node is:

Charging-Rule-Remove ::= < AVP Header: 1002 >
                                   *[ Charging-Rule-Name ]

An example of rule instantiation and rule removal is shown in Policy removal by name.

Entries in IPv4/v6 filter and QoS policy created via CLI are ordered according to the numerical value associated with each entry command (which corresponds to the match condition) within the policy. CLI rules can be re-ordered with the renum command (in filters and QoS policies).

On the other hand, the PCC rules are ordered in one of the two ways. The difference between ordering of the entries with the rules, and the ordering of the rules themselves is:

• PCC rules are prioritized according to the Precedence AVP within the Charging-Rule-Definition AVP. They are inserted within the subscriber-host policy, according to the Precedence AVP relative to the other PCC rules already applied to the subscriber-host. A PCC rule with a lower Precedence value is applied before a rule with a higher Precedence value.

  The ordering behavior according to the Precedence is shown in PCC rule ordering - priority model.

  

• Automatic optimization of PCC rules. Automatic optimization is used in cases where the PCC rule order is not important to the operator. Then, the node optimizes the rule ordering to achieve the best possible scale by maximizing rule sharing. This optimization (or internal rule ordering) is performed for PCC rules without the Precedence AVP, or for PCC rules with the same Precedence value.

  The premise of the automatic rule optimization is shown in PCC rule ordering - priority model.

  

The ordering of PCC rules has no effect on the ordering of the static entries in the base qos-policy or filter.

Mixing of the PCC rules with the Precedence AVP and without Precedence AVP is allowed for the same subscriber-host. PCC rules without the Precedence AVP are inserted at the end of all PCC rules that do have the Precedence value set explicitly. In other words, the Precedence value for PCC rules without the explicitly configured Precedence AVP is assumed to be the highest. The PCC rules without the Precedence value are automatically inserted at the bottom of the PCC rule range.

A distinction should be made between the order of PCC rules in a PCC rule set and the order between the entries within each PCC rule. A PCC rule contains a group of classifiers that are all associated with the same actions. Therefore, the order of the entries (equivalent to match conditions) within any specific PCC rule does not matter (all entries result in the same action). For this reason, PCC rules with identical name and identical entries but different order of the entries are automatically ordered in a way that would allow more optimal sharing of the rules between different subscribers.

A PCC rule applied to a subscriber-host on the node can be overridden by re-submitting the PCC rule with the same name but different contents.

If at least one new flow is sent in the PCC rule update, then the existing flows are removed and replaced with the new flow. If no new flows are submitted, then the existing flows stay in place.

If there are conflicting parameters between the existing rule and the modified rule (for example the combination of the unsupported actions), the PCC rule override fails.

An action with a PCC rule can be applied for a set of IP-criterion.

For example, a single policer can be instantiated for a set of flows for rate-limiting purposes.

A pseudo Gx directive would look like this:

Charging-Rule-Install — Directive to install the rule in 7750 SR
          Charging-Rule-Definition — PCC rule definition created on PCRF
               Charging-Rule-Name = Rule-1 — PCC rule name
                    Flow1     — match-criteria for flow 1
                    Flow2     — match-criteria for flow 2
                    Flow 2    — match-criteria for flow 3
                    Rate-limit    — rate-limiting action applicable as an aggregate action for all 3 flows

All three flows are fed into the same rate limiter (policer).

IPv4 flow entries and IPv6 flows entries can be combined within the same PCC rule. The actions that carry the IP address are address-type-specific (for example next-hop-redirect). All other actions (rate-limit, FC change, and so on) are universal and it are applied to both flow types (IPv4 and IPv6). The node automatically sorts out flow types (IPv4 and IPv6) within the rule and apply corresponding actions.

If the rule contains a mismatching flow type and actions (for example, IPv4 flows and IPv6 specific actions), the rule is rejected. It is the operator’s responsibility to ensure that the address-type-specific actions in the rule have corresponding flows to which they can be applied.

PCC rules can contain multiple actions. For the list of support action combinations, see the PCC rules.

A Gx rule (as defined in a single Charging-Rule-Definition AVP) can contain either Flow-Information AVP or Alc-NAS-Filter-Rule-Shared AVP, but not both simultaneously.

Presence of either AVP within the Charging-Rule-Definition AVP determines the mode of operation for the rule:

Alc-NAS-Filter-Rule-Shared AVP indicates the mode of operation in which the permit or deny action is part of the flow definition itself (Alc-NAS-Filter-Rule-Shared AVP). This mode of operation is referred as NAS filter inserts. The basic format of the AVP is the following (RFC 4849 and 4005; AVP Code 400):

<action> <direction> <protocol>  from <source> to <destination> <options>.

There can be multiple ip-criteria definitions within the rule per subscriber-host, and each ip-criteria carries its own permit/deny action. There can be only one such rule (Charging-Rule-Definition) per subscriber-host. The rule entries are installed within the filter range defined by the following command:

sub-insert-shared-radius start-entry <entry-id> count <count> 
under the following CLI hierarchy:
config>filter>ip-filter>
config>filter>ipv6-filter

Such rule cannot be removed by the Charging-Rule-Remove directive referencing the rule name. Instead, each such Gx rule overwrites the previous one.

Flow-Information AVP indicates the mode of operation whereby all the flows in the rule share the same actions carried in separate AVPs. This mode of operation is referred to as PCC rule inserts. The rule entries are installed within the filter or qos-policy range defined by the following command:

sub-insert-shared-pccrule start-entry <entry-id> count <count> 
under the following CLI hierarchy:
config>filter>ip-filter>
config>filter>ipv6-filter>
config>qos>sap-ingress>
config>qos>sap-egress>

There can be multiple flow based rules present in an orderly fashion and each rule can be individually removed by referencing its name.

Both modes of operation are supported simultaneously for the subscriber host.

Gx and RADIUS (CoA) policy management interfaces are simultaneously supported for the same subscriber-host.

RADIUS and Gx share the same entries for filter entry inserts (NAS-Filter-Rules and Alc-NAS-Filter-Rule-Shared) and therefore the most recent insert overrides the previous one. Similar logic applies to subscriber-string overrides and QoS overrides, where the most recent source, overrides the previous one.

However, PCC rules (IP-criteria based Gx rules) are provisioned in a separate filter ‛entry’ space from RADIUS and Gx filter inserts and therefore the PCC rules and RADIUS/Gx based filter inserts can independently coexist.

Filter/QoS-policy entry order is shown in CAM table population. The order of configuration blocks (static, PCC rules or NAS filter inserts) is configurable. For example, an operator can specify that static filter entries are populated before PCC rules which are then populated before NAS filter inserts.

When PCC rules are applied to a subscriber-host, the operator can modify some of the CLI parameters in the base QoS or filter policies. For example, the operator can add and remove terms in the base ACL filter.

CLI modifiable parameters in base QoS policy that contains clones lists the parameters in the QoS policy that can be changed. Adding or removing queue and policer, re-mapping of FC, modifying the DSCP map or adding or removing static IPv4 or IPv6 criteria entries with action different from FC, profile, or priority is not allowed.

Modified parameters in the base QoS policy or filter referenced in the sla-profile affects all subscribers using this sla-profile. Replacing the base QoS or filter policy in sla-profile is not allowed for any subscriber-host if a clone of the base QoS or filter policy exist anywhere in the system.

However, replacing the base filter ID for a host using CoA or Gx override is allowed. Then, only the targeted host is affected and all existing PCC rules for this host are merged with the new filter.

PCC rules are unidirectional. The PCC rule direction is determined based on the value of the Flow-Direction AVP within the Flow-Information AVP. In the absence of the Flow-Direction AVP, the PCC rule direction is determined based on the Flow-Description AVP (as part of IPFilterRule direction field). Both of these AVPs (Flow-Direction and Flow-Description) are part of the PCC rule definition.

If the action within the PCC rule is in conflict with the direction of the flow, the PCC rule instantiation fails. For example, an error is raised if the flow direction is UPSTREAM, while the action is ‛Max-Requested-Bandwidth-DL’ (downstream bandwidth limit).

A PCC rule may contain multiple actions. Each action is carried in a separate, action specific AVP. The action specified in the flow-description>ipfilter rule data type is ignored. If rule contains multiple instances of the same action, each with a different value, the last occurrence of the action value is in effect.

Not all of the action types can be applied at the same time. The allowed combination of the actions per direction is described in CLI modifiable parameters in base QoS policy that contains clones and Failure reporting .

Rate-limiting action is implemented via policers. The policer is dynamically created at the PCC rule instantiation time. The rate can be enforced based on Layer 2 rates or Layer 3 rates.

Dynamically instantiated policers have their own policer ID range to avoid the conflict with static policers.

The dynamically created policers shares common properties configured under the dynamic-policer CLI hierarchy:

configure
   qos
      sap-ingress/egress
         dynamic-policer  
            stat-mode <stat_mode>
            parent <arbiter-name> [weight <weight-level>] [level <level>
            mbs <size> [bytes | kilobytes]
            cbs  <size> [bytes | kilobytes]
            packet-byte-offset {add <add-bytes> | subtract <sub-bytes>}
            range start-entry <entry-id> count <count>

The configured dynamic policer parameters can be overridden per PCC rule by including the Alc-Dynamic-Policer grouped AVP in the QoS-Information AVP. All AVPs are optional and when specified override the configured value:

• ingress PCC rules

  +--1046 Alc-Dynamic-Policer
     +--1039 Alc-Policer-Parent
        +--1022 Alc-Arbiter-Name
        +--1040 Alc-Parent-Level
        +--1041 Alc-Parent-Weight
     +--1008 Alc-Committed-Burst-Size-UL
     +--1009 Alc-Maximum-Burst-Size-UL
     +--1042 Alc-Stat-Mode-UL
     +--1044 Alc-Packet-Byte-Offset-UL
  

• egress PCC rules

  +--1046 Alc-Dynamic-Policer
     +--1039 Alc-Policer-Parent
        +--1022 Alc-Arbiter-Name
        +--1040 Alc-Parent-Level
        +--1041 Alc-Parent-Weight
     +--1010 Alc-Committed-Burst-Size-DL
     +--1011 Alc-Maximum-Burst-Size-DL
     +--1043 Alc-Stat-Mode-DL
     +--1045 Alc-Packet-Byte-Offset-DL
  

The policer rates are part of PCC rule itself and are not part of static configuration.

The generic Gx directive for rate-limiting action is:

Charging-Rule-Install ::=      <AVP Header: 1001>
     Charging-Rule-Definition <AVP Header: 1003>
          Charging-Rule-Name <AVP Header: 1005> 
          QoS-Information <AVP Header: 1016>                         
               Max-Requested-Bandwidth-UL <AVP Header: 516> [bps] 3GPP 29.214 §5.3.15
        Max-Requested-Bandwidth-DL <AVP Header: 515> [bps] 3GPP 29.214 §5.3.14
        Guaranteed-Bitrate-UL <AVP Header: 1026> [bps] 3GPP 29.214 §5.3.26
        Guaranteed-Bitrate-DL <AVP Header: 1027> [bps] 3GPP 29.214 §5.3.25

The above rate limits refer to PIR and CIR rates of the dynamic policer in the respective direction.

Traffic can be re-prioritized via PCC rule by re-classification into a different forwarding class. The forwarding-class can be changed in several cases.

The original static mapping between traffic type, forwarding-class and the queue/policer in the base qos-policy is configured outside of the ip-criteria CLI hierarchy.

For example:

     config>qos>sap-egress#
          dscp af11 fc "af"

Such mapping is configured outside of CAM and therefore it has lower evaluation priority than the mapping configured via PCC rule which is installed in CAM.

The original static mapping is provisioned in the base qos-policy via ip-criteria CLI hierarchy.

For example:

     config>qos>sap-egress># 
           ip-criteria
                entry 40000 create
                     match 
                          dscp af11
                 exit
         action fc "af"
    exit
   exit

Then, the configured entry range for PCC rules must precede the static entry (match criteria) in which the original forwarding-class is configured. The insertion point (entry) is controlled via configuration: sub-insert-shared-pccrule start-entry <entry-id> count <count> command under the qos-policy.

In both of the above cases, the following PCC rule would override forwarding-class for traffic with DSCP value of 10 (af11 traffic class) from value af to h2.

Charging-Rule-Install 
     Charging-Rule-Definition 
          Charging-Rule-Name = fc-change
          Flow-Information
               ToS-Traffic-Class = 00101000 11111100
               Flow-Direction = 1
          QoS-Information      
               QoS-Class-Identifier  = 2   

The eight forwarding classes are mapped to QCIs (3GPP TS 23.203 §6.1.7.2) in the manner displayed in Forwarding class and QCI mapping.

The generic Gx directive for forwarding-class change:

Charging-Rule-Install ::=      <AVP Header: 1001>
     Charging-Rule-Definition <AVP Header: 1003>
          Charging-Rule-Name <AVP Header: 1005>      
               QoS-Information <AVP Header: 1016>              3GPP 29.212 §5.3.16
                    QoS-Class-Identifier <AVP Header: 1028>     3GPP 29.212 §5.3.17 

Create an ip-criteria or ipv6-criteria entry with no action specified. Matching traffic is forwarded without a QoS action and not match on a next entry (match and exit behavior). This is equivalent to an allowlist entry. CLI equivalent:.

config>qos
  sap-ingress | sap-egress <id> create
    ip-criteria | ipv6-criteria
      entry <id> create
        match
          <5-tuple | dscp>
        exit
        action
      exit
    exit

The generic Gx directive for QoS forwarding:

Charging-Rule-Install ::= <AVP Header: 1001>
    Charging-Rule-Definition <AVP Header: 1003>
        Charging-Rule-Name <AVP Header: 1005>
            Alc-QoS-Action = Forward (1) <AVP Header: 1028>

The next hop redirection explicitly or implicitly changes the next hop for the traffic flow within the same service ID (routing context) or a different service ID (routing context).

If the next hop is not explicitly provided, the next hop is selected automatically, according to the routing lookup in the referenced service ID.

The generic Gx directive:

Charging-Rule-Install <AVP Header: 1001>
     Charging-Rule-Definition <AVP Header: 1003>
          Charging-Rule-Name <AVP Header: 1005>
               Alc-Next-Hop :: <AVP Header: 1023>                    
                     Alc-Next-Hop-IP <AVP Header: 1024>
Alc-V4-Next-Hop-Service-id <AVP Header: 1025> 
                    Alc-V6-Next-Hop-Service-id <AVP Header: 1026> 

This action overwrites the routing table lookup based on the destination IP and sets the next hop to the:

• IPv4/6 address within the same service ID

• IPv4/6 address within a different service ID

The next hop search is indirect, which means that if the explicitly provided next hop in the PCC rule cannot be found in the routing table, then an additional routing table lookup is performed to find the path (next hop) to the indirect next hop from the PCC rule.

If only the service-id is specified in PCC rule (without the next hop), then the next hop is selected from the specified service-id based on the destination IP address of the packet.

HTTP redirect uses Redirect-Information AVP from 3GPP 29.212, §5.3.82.

The generic Gx directive:

Redirect-Information < AVP Header: 1085 >
     Redirect-Support < AVP Header: 1086 >
     Redirect-Address-Type < AVP Header: 433 >
     Redirect-Server-Address < AVP Header: 435 >

This action is used to control traffic flow within a PCC rule by using ALU specific AVP. PCC rules are utilizing filters and QoS policies as distinct building blocks. This action within a PCC rule creates an IP or IPv6 filter entry with an action forward or drop.

The CLI equivalent follows:

config>filter
    ip-filter | ipv6-filter <id> create
        entry <id> create
            match
                <5-tuple | dscp>
            exit
            action
                forward | drop
            exit
        exit
    exit

The generic Gx directive for filter forward/drop is implemented through ALU specific AVP:

Charging-Rule-Install ::= <AVP Header: 1001>
    Charging-Rule-Definition <AVP Header: 1003>
        Charging-Rule-Name <AVP Header: 1005>
            Alc-Filter-Action = Forward (1) <AVP Header: 1027>               
            Alc-Filter-Action = Drop (2)

The service gating function is used to enable or disable the service that is represented by the PCC rule. This action is enforced through a Flow-Status AVP (AVP code 511) - 3GPP 29.214, §5.3.11. The system supports the following values (actions) for the Flow-Status:

enabled (2)

enables all actions specified within the PCC rule. Note that although Flow-Status (service gating function) is considered an action, in this context it is used to enable all other actions that are explicitly set within the PCC rule.

disabled (2)

disable all action specified within the PCC rule and drops the traffic

The service gating function is applicable in the direction that is associated with the rule (PCC rules in the system are unidirectional).

Flow-Status is by default enabled (2) (if the Flow-Status AVP is not explicitly specified within the PCC rule). Flow-Status=Enabled must be accompanied by one or more additional actions in the same PCC rule (see Gx rules with multiple actions and action sharing for a list of allowed simultaneous actions), otherwise the PCC rule instantiation in the node fails.

If the Flow-Status is set to disabled (3), all other actions within the same rule loses their meaning because the packet is dropped. The disabled directive disables the flow of packet through the system. A disabled Flow-Status is equivalent to the Alc-Filter-Action = Drop (2).

This AVP is carried inside of Charging-Rule-Definition (3GPP 29.212, §5.3.5):

Charging-Rule-Definition ::= < AVP Header: 1003 >
                             { Charging-Rule-Name } 
                            *[ Flow-Information ]
                             [ Flow-Status ]
                             [ QoS-Information ] 
                             [ Precedence ] 
                            *[ Flows ]
                             [ Monitoring-Key]
                             [ Redirect-Information ]
                            *[ AVP ]

The following is an example of PCC rule provisioning in a CCA-I message:

<CC-Answer> ::=  < Diameter Header: 272, PXY >
     < Session-Id >
     { Auth-Application-Id }
     { Origin-Host }
     { Origin-Realm }
     [ Result-Code ]
     [ Experimental-Result ]
     { CC-Request-Type }
     { CC-Request-Number }
     *[ Supported-Features ]     
     *[ Event-Trigger ]
     [ Origin-State-Id ]

     Charging-Rule-Install ::= <AVP Header: 1001> -> host instantiation
          Charging-Rule-Name = ‟ingr-v4:7”
          Charging-Rule-Name = ‟eggr-v6:5”
          Charging-Rule-Name = ‟Sub-Profile:prem”
          Charging-Rule-Name = ‟Sla-Profile:voip+data”
          Charging-Rule-Name = ‟Inter-Dest:vport-AN-1”
   
     Charging-Rule-Install  —> service instantiation
          Charging-Rule-Definition
               Charging-Rule-Name = ‟service-1”  —> should be able to remove the rule by name later on
                    Flow-Information      —> traffic flow definition 
                    Flow-Description = ‟permit in 6(TCP) from any to ip 10.10.10.10/32 40000-40010" 
                    ToS-Traffic-Class = 00101000 11111100]  —> DSCP definition (value mask). In case of the DSCP, Flow-Direction (1080) AVP must be included. 
                    Flow-Direction = UPSTREAM  —> traffic flow direction
                    QoS-Information <AVP Header: 1016> 
                         Max-Requested-Bandwidth-UL = 10000000  —> UPSTREAM rate definition (not downstream, since the traffic flow direction is IN) 
                         QoS-Class-Identifier  = 3      —> EF forwarding class; in general one of 8 forwarding-classes (FC) in 7450 ESS and 7750 SR (be|l2|af|l1|h2|ef|h1|nc). This is used for re-prioritization of the traffic. 

In this example the host is instantiated using the two Charging-Rule-Install AVPs. The first is used to instantiate the host. The second is used to instantiate the IP-criterion based service named service-1. Service-1 is defined as the upstream traffic flow with traffic class AF11, destined for the TCP port range 40000-40010 on the node with IP address 10.10.10.10/32.

The actions for this traffic flow are:

• rate-limit of 10M

• change forwarding-class to AF11

The commands used to examine dynamic rules and NAS filter inserts associated with the subscriber hosts are shown in Overview of PCC rule-related operational commands.

One of the most important factors to be considered for capacity planning with PCC rules is the number of unique policies that are applied to subscribers.

A unique policy constitutes a base a QoS policy or filter ID along with all PCC rules that are applied to a subscriber or a set of subscribers.

Now examine an example where there are ‛n’ PCC rules in the system (‛n’ qos rules and ‛n’ ACL filter rules). Those rules are applied to IPv4 traffic in ingress direction. Further, assume that the PCC rules do not have defined Precedence AVP, which means that the system can optimize their order for maximum sharing and maximized scale. Then, ‛n’ PCC rules can be combined by various permutation into 2^n-1 unique combinations Next assumption is that there are five possible base qos-policies for IPv4 traffic in ingress direction and five possible base filters for IPv4 traffic in the ingress direction.

Given the above, the unique PCC rule combinations (2^n-1) together with five base QoS polices produce 5*(2^n-1) unique qos-policies per ingress IPv4. Same logic can be applied for ingress IPv4 filters.

This exercise must be repeated for egress direction as well as for IPv6 type traffic, by taking into consideration the number of respective base qos-policies/filters and the number of PCC rules.

When the number of unique policy combinations is determined and ensured that it is within the system limits, each policy must be further evaluated to determine the number of entries it takes in CAM.

Example of the scaling limits for PCC rules depicts an example relevant to capacity planning with focusing on understanding the scaling limits pertaining to the number of PCC rules and their mutual combinations when they are applied to the subscriber hosts.

This example is focuses on an IPv4 filter applied in ingress direction but similar logic can be used in understanding other policy types (QoS, egress, IPv6).

The system/line card limits in this example are set to the following values for illustration purposes only:

• Number of PCC rules per system is 1K.

• Max number of rules per subscriber host is 64.

• Max number of combinations of the PCC rules (or services) that are active (applied to the subscriber-hosts) per system is 4K.

• Max ingress IPv4 filter CAM entries per FP2/FP3 is 64k.

• Max filters per system is 16k.

The following AVPs identify NAS filter inserts that are applied to a subscriber host. Those AVPs can be included in CCA-i, CCA-u or RAR message sent from the PCRF.

Charging-Rule-Install ::= <AVP Header: 1001>
Charging-Rule-Definition <AVP Header: 1003>
            Charging-Rule-Name <AVP Header: 1005> = ‟allow-all”
            Alc-NAS-Filter-Rule-Shared <AVP Header: 158> = "permit in ip from any to any "ASCII NUL" permit out ip 
from any to any"

In this example, the filter entry defined in Alc-NAS-Filter-Rule-Shared AVP is inserted in the clone of the existing base filter for the subscribers.

Reporting an AVP decoding problem in Gx is described in the following example:

A Gx directive is received to install two overrides on the node. The two overrides are supposed to change the sla-profiles and sub-profiles for the subscriber host. The AVP that is used to change the sla-profile is miss-formatted. The predefined sla-profile keyword in the Charging-Rule-Install AVP is misspelled as spa-profile instead of sla-profile.

Charging-Rule-Install ::= <AVP Header: 1001>
    Charging-Rule-Name <AVP Header: 1005> = ‟Sub-Profile:prem”
    Charging-Rule-Name <AVP Header: 1005> = ‟Spa-Profile:voip+data”

Because the Charging-Rule-Name AVP has the M-bit set, the whole message fails and an error is reported. No rules within this Gx message is installed (not even the valid ones, then this would be the Charging-Rule-Name = ‟Sub-Profile:prem”).

The nature of the error depends on the original directive sent by the PCRF (RAR or CCA – push or pull model).

If the directive from the PCRF is passed with the cca command, the response is CCR-U with the following error related AVPs:

[ Error-Message ] — ‟Invalid value spa-profile:voip+data”

Charging-Rule-Report ::= < AVP Header: 1018 >
    *[ Charging-Rule-Name ] — Spa-Profile:voip+data
    [ PCC-Rule-Status ]    — INACTIVE (1)
    [ Rule-Failure-Code ]  — GW/PCEF_MALFUNCTION (4)
    

Charging-Rule-Report ::= < AVP Header: 1018 >
    *[ Charging-Rule-Name ]      —  Sub-Profile:prem
    [ PCC-Rule-Status ]          —  INACTIVE (1)
    [ Rule-Failure-Code ]        —  GW/PCEF_MALFUNCTION (4) 

Failed-AVP ::= < AVP Header: 279 >        
    Charging-Rule-Name = Spa-Profile:voip+data

If the directive is passed to the node through RAR, the node responds with the following RAA message:

Failed-AVP ::= < AVP Header: 279 >
    Charging-Rule-Name = Spa-Profile:voip+data 
 
Result-Code ::= < AVP Header: 268 > = DIAMETER_INVALID_AVP_VALUE (5004)

Similarly, if the number of filter entries for each entry type (NAS-Filter-Rule — host-specific or Alc-NAS-Filter-Rule-Shared — shared) exceeds the maximum supported number (see the 7750 SR and VSR Gx AVPs Reference Guide), the whole message fails the decoding phase.

The reason that the Result-Code AVP is present in the RAA message and not in the CCR-U message is that this code is only allowed to be present in the answer messages, according to the standard.

This assumes that the rule installation directives are successfully passed from the Gx module to the ESM module and the failure to install rules occurs in the ESM module.

In the Gx override example below, the referenced sla-profile is unknown. Then, all directives passed to the ESM module fails and consequently no rules or overrides are installed. The sub-profile change fails as well although the prem sub-profile is known in the system.

Charging-Rule-Install ::= <AVP Header: 1001>
    Charging-Rule-Name <AVP Header: 1005> = ‟Sub-Profile:prem”
            Charging-Rule-Name <AVP Header: 1005> = ‟Sla-Profile:unknown”

The error reporting flow is as follows:

• If the directives are passed using the CCA command, the response is CCR-U command with the following error related AVPs:

  [ Error-Message ]                     — ‟sla-profile ‛unknown’ lookup failed”
  
  Charging-Rule-Report ::= < AVP Header: 1018 >
      *[ Charging-Rule-Name ]                 —  Sla-Profile:unknown
      [ PCC-Rule-Status ]                     —  INACTIVE (1)
      [ Rule-Failure-Code ]                   —  GW/PCEF_MALFUNCTION (4)
      
  
  Charging-Rule-Report ::= < AVP Header: 1018 >
      *[ Charging-Rule-Name ]         —  Sub-Profile:prem
      [ PCC-Rule-Status ]             —  INACTIVE (1)
      [ Rule-Failure-Code ]           —  GW/PCEF_MALFUNCTION (4)
  
  

• If the directive is passed to the node with RAR, the node responds with the following messages:

  RAA = OK because the Gx module successfully processed the AVP parsing.

  The RAA is followed by CCR-U, triggered by the rule instantiation failure in ESM module. CCR-U contains the following AVP related to the rule status:

  [ Error-Message ]                 —   ‟sla-profile ‛unknown’ lookup failed”
  
  Charging-Rule-Report ::= < AVP Header: 1018 >
      *[ Charging-Rule-Name ]       —  Sla-Profile:unknown
      [ PCC-Rule-Status ]           —  INACTIVE (1)
      [ Rule-Failure-Code ]         —  GW/PCEF_MALFUNCTION (4)
      
  
  Charging-Rule-Report ::= < AVP Header: 1018 >
      *[ Charging-Rule-Name ]       —  Sub-Profile:prem
      [ PCC-Rule-Status ]           —  INACTIVE (1)
      [ Rule-Failure-Code ]         —  GW/PCEF_MALFUNCTION (4)
  
  

Similar behavior would be exhibited if the directive is sent to the UM or AA modules. However, ESM, UM, and AA are separate modules and failure to install rules in one module does not affect rule installation in another.

Failure reporting in AA is performed in similar fashion as in ESM.

Instead of Charging-Rule-Report AVP, the ADC-Rule-Report is used:

ADC-Rule-Report ::= < AVP Header: 1097 >
                        *[ ADC-Rule-Name ]
                         [ PCC-Rule-Status ]
                         [ Rule-Failure-Code ]
                        *[ AVP ]

Failure reporting summarizes Gx failure reporting on the node.

In the ESM context, volume consumption (octets - 3GPP 23.203 §4.4) can be monitored on three levels:

• per entire IP-CAN session

• per credit-category

• per PCC rule

Usage-Monitoring can be monitored simultaneously on all three levels.

An IP-CAN session on the node represents a subscriber-host whose service types are determined by the sla-profile instance. In per IP-CAN session volume monitoring, the aggregated queue or policer counters are reported per direction (in or out). This includes dynamic policers that are instantiated as a result of a Gx action; for example, rate-limiting.

The following configuration is necessary to allow per IP-CAN session level Usage-Monitoring to be enabled for sessions associated with the category map:

configure
    subscriber-mgmt
        category-map <category-map-name> [create]
            gx-session-level-usage

If the sla-profile instance changes mid-session, the counters are reset.

One obvious difference between regular RADIUS accounting and Gx Usage-Monitoring is that in RADIUS accounting the cumulative byte number for sla-profile instance is presented in each report (interim-updates or stop acct messages), while in Usage-Monitoring this count is reset between the two reports (when the quota is reached, the usage report is triggered).

Per credit-category monitoring refers to volume monitoring of a single queue/policer or a set of queues/policers within the sla-profile instance. Each queue/policer (or set of queues/policers as a subset of the sla-profile instance) represents a service for which the Usage-Monitoring is required. Those queues/policers (services) are organized on the node in credit categories.

*A:7750>config>subscr-mgmt>cat-map# info 
----------------------------------------------
            activity-threshold 1
            credit-exhaust-threshold 50
            category "queue1" create
                queue 1 ingress-egress 
            exit
            category "queue3-5" create
                queue 3 ingress-egress 
                queue 5 ingress-egress 
            exit
            category "rest-queues" create
                queue 2 egress-only 
                queue 4 egress-only 
                queue 6 egress-only 
                queue 7 egress-only 
                queue 8 egress-only 
            exit
----------------------------------------------

Each service category has a name that is used to reference the category in Usage-Monitoring and reporting.

The category-map (predefined on the node) that is used in Usage-Monitoring can be associated with the subscriber-host through the following methods (in the order of priority):

• PCRF — Charging-Rule-Install AVP that references the category map in Charging-Rule-Name = cat-map:<cat-map-name>

• LUDB

• RADIUS

• Python script

PCC rule Usage-Monitoring reports volume usage per flow or set of flows. PCC rule Usage-Monitoring is described in a separate section below.

Usage-Monitoring for the subscriber host can be configured on the node, but it is not active until it is turned on by the PCRF either via CCA-i, CCA-u or RAR.

Usage-Monitoring can be enabled per ingress or egress direction or as total count. However monitoring the total count and per direction count are mutually exclusive. For example, total Usage-Monitoring cannot be enabled simultaneously with ingress (or egress) Usage-Monitoring for the same monitoring entity (session or category).

In AA, charging groups (CG), application groups (AG) and applications are monitored. See the 7450 ESS, 7750 SR, and VSR Multiservice ISA and ESA Guide for details.

Gx Usage-Monitoring is activated explicitly from the PCRF via CCA-I, CCA-U or RAR. It is triggered via the Usage-Monitoring-Information AVP along with the event-trigger = usage-report (33). The Usage-Monitoring-Information AVP contains the following AVPs:

Usage-Monitoring-Information::= < AVP Header: 1067 >
                                  [ Monitoring-Key ]
                            0,2   [ Granted-Service-Unit ]
                            0,2   [ Used-Service-Unit ]
                                  [ Usage-Monitoring-Level ]
                                  [ Usage-Monitoring-Report ]
                                  [ Usage-Monitoring-Support ]

There could be multiple instances of Usage-Monitoring-Information AVP present in a single CCA or RAR messages. For example, simultaneous Usage-Monitoring for IP-CAN session level, credit-category level or pcc rule level can be requested.

Usage-Monitoring-Level for IP-CAN session is set to SESSION_LEVEL (0)

Usage-Monitoring-Level for category-map is set to PCC_RULE_LEVEL (1)

Usage-Monitoring-Level for PCC rules is set to PCC_RULE_LEVEL (1)

The node reports usage information to the PCRF under the following conditions:

• when a usage threshold is reached

• when all pcc rules associated with the monitoring are removed or deactivated

• when Usage-Monitoring is explicitly disabled by PCRF

• when a session is terminated

• when requested by PCRF (on demand)

To report accumulated usage for a specific monitoring-key, the node sends a CCR with the Usage-Monitoring-Information AVP containing the accumulated usage information since the last report. For each of the enabled monitoring-keys, the Usage-Monitoring-Information AVP includes the Monitoring-Key AVP and the accumulated volume usage in the Used-Service-Unit AVP.

A usage report on the node can be triggered by reaching the usage threshold communicated to the node by the PCRF in the CCR-U message carrying accumulated usage for that monitoring entity along with the Event-Trigger AVP set to USAGE_REPORT.

In response to the CCR-U message, the PCRF communicates to the node via a CCA-u message whether the Usage-Monitoring should continue:

• If the new thresholds for the currently monitored entity/levels are provided in Granted-Service-Units AVP, the Usage-Monitoring continues.

• If the thresholds are not included in Granted-Service-Units AVP, the Usage-Monitoring stops.

Thresholds are incremental. For example, if the quota of 100 MB is submitted to the node, the usage should be reported when that quota is reached. At that point, the user can be granted another 100 MB. The new usage report on the node is triggered when another 100 MB are accumulated. Absence of the threshold for an entity in the CCA-u message is an indication that the Usage-Monitoring should stop.

When the PCRF informs the node that Usage-Monitoring should stop (by not including thresholds in CCA-u), the node does not report usage which has accumulated between sending the CCR and receiving the CCA.

Another possibility of usage reporting is on-demand. In this scenario, usage for one or more monitoring keys is reported whether the usage threshold has been reached. This is achieved by sending the node the Usage-Monitoring-Report AVP (within the Usage-Monitoring-Information AVP) set to USAGE-MONITORING_REPORT_REQUIRED. If the Monitoring-Key AVP is omitted in such a request, Usage-Monitoring for all enabled entities is reported to the PCRF.

If that the credit-category is removed from the subscriber host (the sla-profile instance referencing the category-map is changed for the subscriber host), the node reports the outstanding usage in a CCR-U message with the Event-Trigger set to USAGE_REPORT.

When the PCRF explicitly disables Usage-Monitoring on the node, the node reports the accumulated usage which has occurred while Usage-Monitoring was enabled.

To disable Usage-Monitoring for an entity, the PCRF sends the Usage-Monitoring-Information AVP referencing only the applicable monitoring entity with the Monitoring-Key AVP and the Usage-Monitoring-Support AVP set to USAGE_MONITORING_DISABLED.

When the PCRF disables Usage-Monitoring in a RAR or CCA command, the node sends new a CCR-U with the Event-Trigger AVP set to "USAGE_REPORT" to report the accumulated usage for the disabled Usage-Monitoring entities.

Each PCC rule for which Usage-Monitoring is required, contains Monitoring-Key AVP.

Charging-Rule-Definition ::= < AVP Header: 1003 >
                             { Charging-Rule-Name }
                            *[ Flow-Information ]
                             [ Flow-Status ]
                             [ QoS-Information ]        
                             [ Precedence ]
                             [ Monitoring-Key]
                            *[ AVP ]

Usage-Monitoring for PCC rules is implemented through a dynamic policer. The policer is instantiated at the time when the PCC rule with Monitoring-Key AVP is installed.

The same monitoring-key can be used in multiple PCC rules assuming that these rules are for the same direction. In other words, the charging rule is rejected if the same monitoring-key is used for ingress and egress.

At IP-CAN session termination, the node sends the accumulated usage information for all entities for which Usage-Monitoring is enabled in the CCR-T.

A Diameter Gx session from which Usage Monitoring is started controls the Usage Monitoring for the entire SLA profile instance. Only one Diameter Gx session can control the Usage Monitoring per SPI at a specific time. That is, Usage Monitoring can only be started from a single Gx session when multiple subscriber hosts or sessions share an SLA profile instance.

The session ID of the Diameter Gx session that controls the Usage Monitoring is displayed as the ‟Diameter Session Gx” field in the output of the following show command.

# show service active-subscribers credit-control [subscriber <sub-ident-string>]
===============================================================================
Active Subscribers
===============================================================================
-------------------------------------------------------------------------------
Subscriber sub-1 (sub-profile-1)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
(1) SLA Profile Instance sap:1/1/2:10 - sla:sla-profile-1
-------------------------------------------------------------------------------
Category Map         : catmap-1
Diameter Session Gx  : bng1.domain.com;1490015297;7
Number of categories
static               : 2
gx-session           : 0
gx-pcc               : 1
Category Name        : cat-1                  
Ingress Queues       : 1
Egress Queues        : 1
Ingress Policers     : (Not Specified)
Egress Policers      : (Not Specified)
No monitoring
HTTP Rdr URL Override: (Not Specified)
Category Name        : cat-2                  
Ingress Queues       : 2
Egress Queues        : 2
Ingress Policers     : (Not Specified)
Egress Policers      : (Not Specified)
No monitoring
HTTP Rdr URL Override: (Not Specified)
Category Name        : fl_um1_up
Volume Used          : 0                    Volume Available     : 100000
HTTP Rdr URL Override: (Not Specified)
-------------------------------------------------------------------------------

A Diameter Gx session stops being the controlling Gx session for Usage Monitoring of the SLA profile instance in the following situations:

• The Gx session controlling Usage Monitoring for an SLA profile instance is terminated, for example, because the associated subscriber session is disconnected. A CCR-T is sent immediately reporting the usage.

• All Usage Monitoring is disabled form the controlling Gx session. A CCR-U is sent immediately reporting the usage.

When the Usage Monitoring terminates, the usage of subscriber hosts or sessions sharing the SLA profile instance is no longer accounted for. Usage Monitoring can now be started from another Diameter Gx session, which then becomes the controlling Gx session for Usage Monitoring on the SLA profile instance.

For the description of the specific AVP, see the 7750 SR and VSR Gx AVPs Reference Guide.

IP-CAN session Usage-Monitoring

A category-map with gx-session-level-usage-monitoring must be associated with the subscriber host or session:

configure
    subscriber-mgmt
        category-map cat-map-1 create
            gx-session-level-usage

PCRF in RAR sends the following AVPs (among all the other mandatory ones: session-id, and so on.)

Usage-Monitoring-Information
        Monitoring-Key = ‟any-string”  
        Granted-Service-Unit 
            CC-Input-Octets = 1000000
              CC-Output-Octets = 1000000
        Usage-Monitoring-Level = session_level(0)

Event-Trigger = USAGE_REPORT

The node reports usage when the thresholds are reached some time later in the CCR-U. The usage is monitored internally on the node based on the current sla-profile instance.

Usage-Monitoring-Information
        Monitoring-Key = ‟any-string” 
        Used-Service-Unit   
        CC-Input-Octets = 1000000
                 CC-Output-Octets = 1000000   

The PCRF instructs the node to continue Usage-Monitoring with the new thresholds in the CCA-U:

Usage-Monitoring-Information
        Monitoring-Key = ‟any-string”  
        Granted-Service-Unit 
            CC-Input-Octets = 1000000
            CC-Output-Octets = 1000000
        Usage-Monitoring-Level = session_level(0)

Category Usage-Monitoring

Assume that the following category-map is associated with the subscriber host:

*A:7750>config>subscr-mgmt>cat-map# info 
----------------------------------------------
            activity-threshold 1
            credit-exhaust-threshold 50
            category "queue1" create
                queue 1 ingress-egress 
            exit
            category "queue3-5" create
                queue 3 ingress-egress 
                queue 5 ingress-egress 
            exit
            category "rest-queues" create
                queue 2 egress-only 
                queue 4 egress-only 
                queue 6 egress-only 
                queue 7 egress-only 
                queue 8 egress-only 
            exit

The PCRF sends the following AVPs in the RAR message (among all the other mandatory ones: session-id, and so on.)

Charging-Rule-Install 
        Charging-Rule-Name = Cat-Map:cat1 — cat-map rule install

Usage-Monitoring-Information
        Monitoring-Key = ‟queue-1”  
        Granted-Service-Unit 
            CC-Input-Octets = 1000000
            CC-Output-Octets = 1000000
            Usage-Monitoring-Level = PCC_RULE_LEVEL (1)
Usage-Monitoring-Information
        Monitoring-Key = ‟queue-3-5”  
        Granted-Service-Unit 
            CC-Input-Octets = 2000000
            CC-Output-Octets = 2000000
            Usage-Monitoring-Level = PCC_RULE_LEVEL (1)
Event-Trigger = USAGE_REPORT

The node reports usage when the thresholds are reached some time later in the CCR-U:

Usage-Monitoring-Information
        Monitoring-Key = ‟queue-1” 
        Used-Service-Unit   
               CC-Input-Octets = 1000000
               CC-Output-Octets = 1000000   
Usage-Monitoring-Information
        Monitoring-Key = ‟queue-3-5” 
        Used-Service-Unit   
               CC-Input-Octets = 2000000
               CC-Output-Octets = 2000000   
                

The PCRF instructs the node to continue Usage-Monitoring with the new thresholds in the CCA-U:

Usage-Monitoring-Information
        Monitoring-Key = ‟queue-1”  
        Granted-Service-Unit 
            CC-Input-Octets = 1000000
            CC-Output-Octets = 1000000
            Usage-Monitoring-Level = PCC_RULE_LEVEL (1)
Usage-Monitoring-Information
        Monitoring-Key = ‟queue-3-5”  
        Granted-Service-Unit 
            CC-Input-Octets = 2000000
            CC-Output-Octets = 2000000
            Usage-Monitoring-Level = PCC_RULE_LEVEL (1)

Redundancy in Gx relies on the Diameter redundancy mechanisms described in Diameter redundancy.

Each configured Diameter node in SR OS can support several peers that are simultaneously open. Only one of those peers is used to forward application messages for a specific user session. If there are multiple peers for the same realm, then the next-hop peer with the numerically lowest preference value is selected. If all peers have same preference for a specific realm, then the peer index is used to break the tie.

Peer failover is performed by a Diameter base protocol and is supported only for application request messages (for example, a peer failover does not apply to a CER message). Events that trigger peer failover can be categorized as:

• explicit notifications from a peer through an error message, informing the recipient of the error message that the peer cannot deliver the request message to the destination

  The receipt of the DIAMETER_UNABLE_TO_DELIVER (3002) or DIAMETER_TOO_BUSY (3004) protocol error messages triggers a retransmission of the original request messages to the next best peer. The retransmission bit (T-bit) in the retransmitted message is set. At the same time, the Tx timer (a configurable parameter in the SR OS) is started. Continued errored replies (3002/3004) for the retransmitted messages over newly selected peers continue to trigger the selection of the next best peer until:

  • a valid peer is found

  • all eligible peers are attempted without success

  • the Tx timer expires

  If there are no viable peers available to deliver the request message (3002/3004 errors received from all attempted peers), or the Tx timer expires, the Diameter base notifies the application layer (NASREQ, Gx, Gy) which may invoke a server failover procedure (if enabled on the application level by configuration).

• termination of an active peering connection

  A peering connection can be explicitly closed by either side because of a Disconnect-Peer-Request message attributed to the timeout of the watchdog messages or any other error on the TCP transport level. Termination of an active peer triggers a search for the next best peer through forwarding/routing for all messages in the transmit queue toward that peer. The T-bit is set on all retransmitted messages.

  If no eligible peers are left, the Diameter base notifies the application layer (NASREQ, Gx, Gy) which may invoke a server failover procedure (if enabled on the application level through configuration).

The destination-host AVP in the retransmitted messages because of the peer failover remains the same as in the original request message.

After the Diameter application is notified by the Diameter base that it is unable to deliver the message to the destination, the Diameter application can invoke a server failover procedure. A server failover procedure is enabled through configuration in the Diameter application policy (failure handling).

The server failover procedure on the Diameter application level provides the opportunity for one last retransmission of the original Diameter request messages, but this time with the destination-host AVP cleared in the retransmitted message. The T-bit in the retransmitted messages is set.

Clearing the destination-host AVP allows delivery of the application message to any server in the realm supporting that application. The retransmitted application request message is successfully processed on such server only if the applications servers are redundant and synchronized.

Both SR nodes in the redundant pair are configured with the same Diameter Identity (DI), the origin host and origin realm. This configuration is performed per Diameter node configuration context, and there can be multiple Diameter node configuration contexts per an SR node or a pair of redundant SR nodes.

Only one node in the SR redundant pair is instructed to open a peering connection, while the other node keeps the connection to the same peer closed (inactive). A single peering connection from a pair of redundant SR nodes to the same Diameter network peer is essential for unambiguous transport of Diameter messages in an environment with:

• a single realm spanning multiple redundant pairs

• a pair of redundant SR nodes sharing the same Diameter Identity (DI)

If the open peering connection fails (such as a node reboot or a peer is closed or unavailable), the redundant SR node, upon detection of this event, immediately starts initiating the connection to the same peer.

Inter-peering Diameter connection between the two redundant SR nodes is required to transport Diameter messages directly between them if the SR node with an active SRRP instance does not have a direct Diameter path to the agent or server. Instead, the messages must be sent over the inter-peering connection to the other SR node which is directly connected to the Diameter agent or server.

The synchronization mechanism between the two redundant nodes ensures that only one SR node initiates this inter-peer connection. The other (peering) SR node accepts this request but does not initiate it.

The watchdog timer for this peering connection should be set to the lowest configurable value.

If the Diameter request message is originated from a node (SRRP Active) that does not have direct connections to the agent or relevant Diameter servers, the request message must be sent to the inter peer which does have such connections. This is accomplished by designating the inter-peer as a default peer. A default peer is a peer used for all Diameter traffic that does not have an exact match for the destination-realm and application in the realm routing table. A default-peer is application (NASREQ/Gx/Gy) unaware. For routing loop avoidance information, see Diameter routing loop avoidance.

Because both redundant SR nodes have their default peers pointing to each other, a mechanism for routing loop prevention must be in place. This means that a Diameter message received from a peer, is never transmitted in the reverse direction back to this same peer (in other words, looped around).

In a Diameter multi-chassis configuration, the SR node with SRRP in an Active state (where the subscriber is active) and the SR node with open relevant Diameter peering connections may not be co-located. As a result, it is possible that the RAR message is received on the SR node where the Diameter application (for example, Gx) is not active. In this case, the RAR message is re-routed from the default peer to the peering SR node where the SRRP is in the Active state, and the Diameter application is active.

If the default peer is not available, the RAR message is dropped and a DIAMETER_UNABLE_TO_DELIVER error message is sent back to the peer from which the RAR message was received.

An SR inserts the Route-Record AVP to all CCR messages that are passed through it. The Route-Record AVP is not added on the SR originating the message, but instead only on the transit SR, where messages are received from the inter-peer and passed to the network, or when they are received from the network and passed to the inter-peer.

The value inserted in the Route-Record AVP is the origin-host of the peer from which the message is received.

Checks that are performed on the Route-Record AVP are the following:

• If the peer’s identity in any of the Route-Record AVPs in the received request messages matches the local host identity, then this means that a routing loop is detected (Diameter routing loop detection). The SR answers with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.

• Route-Record AVPs are examined in received request messages to determine whether the message should or should not be forwarded. Only the next-hop (peers) candidates for the route that are not in any of the Route-Record AVPs of the received message, are allowed to be used. If there are no such next-hop candidates, an error message with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER must be sent back to the peer.

Scenarios in which an SR can receive a request message are:

• RAR from the inter-peer

• RAR from a network peer

• CCR-I/U/T message received from the inter-peer

• CCR-I/U/T message is received from a network peer

SRRP activity and Diameter peer activity are independent of each other, and consequently, an SRRP switchover that is because of an access link or path failure does not cause Diameter peers to switchover. However, a SRRP switchover can trigger a Diameter application to notify the application server (for example, PCRF) of this event. This is performed through the AN-GW-IP AVP which is reported in CCR-U message sent to the PCRF. AN-GW-IP AVP carries the IP address of the newly active SRRP SR node, where the application session is now active. This functionality is enabled on the application level by arming the Diameter client on SR node with the event-trigger ID 13 (USER_LOCATION_CHANGE) from the PCRF.

The following two scenarios are not protected by the Diameter multi-chassis redundancy:

• Loss of the intra-peering (MCS) link. This scenario causes a split-brain scenario where both nodes act as stand-alone nodes and they both try to open peering connections to the Diameter servers.

• SRRP Active-Active state, where the SRRP messaging path between the two SR nodes is broken and consequently, both SR nodes own the Diameter application session (for example, Gx session).

These two scenarios do not meet the minimum requirements (MCS and SRRP must be operational) for successful Diameter multi-chassis operation, and therefore, are not supported. However, after the valid control channel states are restored (intra-chassis link is restored or SRRP states become stable, Active or Standby), the expectation is that the redundant system brings itself up to a valid protecting state.

Peer preference is a configuration parameter used to break the tie between multiple peers in the realm routing table leading to the same Diameter realm. Peer preference is a local configuration parameter and it does not transfer across the chassis. The peer with the numerically lowest preference value is preferred. As a result, peer preference may lose its meaning in the multi-chassis environment because the peers leading to the same realm may be distributed across both chassis.

The scenario can be clarified by the following example:

• Peer 1 and Peer 2 are redundant peers and Peer 1 has a lower preference than Peer 2 on both SR nodes.

• Because each SR node in Distributed peer connections has peering connection open to its own PCRF, the local peer preference loses its meaning. Peer 1 is used on BNG1 and Peer 2 is used on BNG2, although it may be needed that Peer 1 is always preferred over Peer 2.

If the peering connections are colocated (Collocated peer connections), the preference parameter regains its meaning. In this case, Peer 1 is always selected over Peer 2.

Synchronization frequency is configurable per diameter application policy and the minimum configurable value is five minutes. This interval is maintained per each individual Gx session associated with the relevant diameter application policy.

The configured synchronization interval governs the accuracy of UM in dual-homed systems where the switchover is caused by the sudden unavailability (crash, reboot, and so on) of the node on which a UM session is active.

Online configuration changes (while UM sessions are active) for synchronization interval are activated only for the new sessions that are established after the configuration is made.

A switchover, other than the one caused by a node loss, triggers an immediate synchronization of counters. This ensures better UM accuracy by synchronizing data up to the moment of the switchover, instead of up to the moment of the last periodic sync interval.

Credit quotas as received by the PCRF and UM counters are synchronized between dual homed nodes. However, the configuration is not synchronized or checked at the time of synchronization. This means that it is left to the operator to ensure that the UM configuration (for example, credit categories) is identical on both nodes.

Inter-chassis link (ICL) is used to transfer synchronization information. Any logical connectivity serves this purpose, but it is crucial that this link is redundant. The loss of this link is a faulty scenario where the control channel for UM synchronization between the two chassis is broken. In this case, both nodes remain operational in a stand-alone mode and they continue to forward traffic. After the ICL is recovered, the UM counters are re-synchronized from the active to standby node automatically within the configured synchronization interval.

In a Master-to-Master scenario, the SRRP connectivity between the two nodes is lost and consequently both nodes transition into a master SRRP state. This means that in the downstream direction both nodes forward traffic (this depends on how the traffic is attracted on each node via routing). Similarly, in the upstream direction both nodes forward traffic, but the node selection is guided by the learning of VMAC (SRRP MAC) in the Layer 2 access network (the last received downstream packet determines the upstream path). The Master-to-Master state is, from the operational standpoint, an invalid and erroneous state where both nodes are sending synchronization messages to each other and at the same time they are rejecting them. The system recovers within one synchronization periodic interval after the valid SRRP state combination is restored (master/backup).

Collecting usage counters without quota can occur when the original quota is exhausted and reported by the BNG, but the new quota is not given by Policy and Rule Charging Function (PCRF) while UM is still active (not explicitly disabled).

In this case, BNG continues counting. When the new quota is submitted, all consumed bytes up to this point are counted toward the new quota. For example, if 200 units are consumed since the last report, and then a new quota of 1000 units is issued, the 200 already consumed units are counted toward the new quota. For this reason, operators must avoid enabling UM without the quota. This can be achieved by:

• disabling UM if it is not needed

• submit a new quota by PCRF on every quota report exhaustion generated by the BNG

The correct sequence of events during the (M)ISSU from a software release which does not support UM MCS (old release), to a software release that does support UM MCS (new release) is the following:

• The old release has ESM and Gx synchronization enabled but the UM does not. This is because UM synchronization is not supported on older releases.

• (M)ISSU is performed

• The new software release boots up with UM still disabled. UM must be enabled via Gx directives send from PCRF.

• The UM can now be enabled in the new release. When enabled, synchronization automatically takes place.