For feedback and comments:
documentation.feedback@alcatel-lucent.com

Table of Contents Previous Next PDF


Diameter and Diameter Applications
In This Section
This section provides information pertaining to the Diameter authentication, authorization, and accounting protocol, and Diameter applications:
Restrictions
Diameter-Based Restrictions:
Accounting (RFC 6733, Diameter Base Protocol) via Diameter is not supported in this release.
Gx-Based Restrictions:
 
Terminology
Gx Interface (or simply Gx) term is used to refer to the implementation of Gx reference point in 7x50. Gx reference points are defined in 3GPP 29.212 document.
Enhanced Subscriber Management (ESM) subscriber is a host or a collection of hosts instantiated in 7x50 SR Broadband Network Gateway (7x50). The ESM subscriber represents a household or a business entity for which various services with committed Service Level Agreements (SLA) can be delivered.
AA Subscriber is a representation of ESM subscriber in MS-ISA for the purpose of managing its traffic based on applications (Layer 7 awareness). An AA subscriber has no concepts of ESM hosts.
7x50 BNG refers to the ALU network element on which a Gx interface is implemented and policy rules are enforced (PCEF). This term can be interchangeably used with the 7x50 term.
Flow – A flow in Gx context represents traffic matching criteria (traffic classification or traffic identification) based on any combination of the following fields:
A Gx flow is defined in the Flow-Information AVP:
Flow-Information ::= < AVP Header: 1058 > 	3GPP 29.212 §5.3.53 	
		[ Flow-Description ]						3GPP 29.214 §5.3.8 	
		[ ToS-Traffic-Class ]						3GPP 29.212 §5.3.15 	
		[ Flow-Direction ]							3GPP 29.212 §5.3.65 	
		*[ AVP ]
Gx flows are similar to dynamically created filter/ip-criteria (QoS) entries and are inserted within the entry range configured for the base filter/qos-policy.
IP-criterion – These fields are used in IPv4/v6 packet header used as a match criterion. The supported fields are DSCP bits and 5 tuple. This is part of traffic classification (or traffic identification) within the PCC rule or within the static qos-policy/filter entry.
Gx Policy Rule – There are three types of Gx policy rules supported within 7x50:
PCC rule represents a single or a set of IP based classifiers (DSCP bits or 5 tuple) associated with a single or multiple actions.
For example:
Each PCC rule can be removed via Gx from 7x50 by referencing its name (Charging-Rule-Name AVP).
PCC rule can contain a combination of QoS and IPv4/v6 filter actions as they pertain to 7x50.
PCC Rule Classifier — A flow-based (5 tuple) or a DSCP classifier defined in Flow-Information AVP within the PCC Rule. There can be a single or multiple classifiers (Flow-Information AVPs) within a single PCC rule. In 7x50 terms, a PCC classifier (Flow-Information AVP) correspond to an entry (match criteria) within the filter/ip-criteria definition.
CAM entry – A single entry in the CAM that counts toward the CAM scaling limit. For example a match condition within ip-criteria in a filter or qos-policy can evaluate into a single CAM entry or into multiple entries (in the case where port-ranges are configured in the classifier, or where matching against UDP and TCP protocols are enabled simultaneously).
Subscriber Host Policy – A collection of PCC rules (classifiers and actions), Gx overrides, NAS filter inserts and statically configured rules (CLI defined QoS or filter) that are together applied to the subscriber host.
 
3GPP-Based Diameter Credit Control Application (DCCA) - Online Charging
The 3GPP-based Diameter Credit Control On-line charging applications allow the control of subscriber access to services based on a pre-paid credit. The volume and time accounting in the 7750 SR supports online charging using the Diameter Credit-Control Application (DCCA). The 7750 SR supports Session Charging with Unit Reservation (SCUR) allowing the 7750SR to reserve volume and time quota for rating-groups. Furthermore, the 7750 SR supports centralized unit determination and centralized rating: it requests quota and reports usage against the quota provided by the Online Charging Server (OCS). Credit control is always on a per rating group basis. A rating group maps to a category inside a category-map of the 7750SR volume and time based accounting function.
The following are the basic configuration steps:
1.
In the config>aaa CLI context, configure a diameter peer policy with one or multiple Diameter peers.
 
configure
    aaa
        diameter-peer-policy "diameter-peer-policy-1" create
            description "Diameter peer policy"
            applications gy
            connection-timer 5
            origin-host "bng.alcatel-lucent.com"
            origin-realm "alcatel-lucent.com"
            source-address 10.0.0.1
            peer "peer-1" create
                address 10.1.0.1
                destination-host "server.alcatel-lucent.com"
                destination-realm "alcatel-lucent.com"
                no shutdown
            exit
        exit
    exit
 
2.
In the config>subscriber-mgmt CLI context, configure a diameter application policy:
 
Specify the Diameter peer policy to use and optionally specific additional Gy application specific parameters (for example AVP format).
 
configure
    subscriber-mgmt
        diameter-application-policy "diameter-gy-policy-1" create
            description "Diameter Gy policy"
            application gy
            diameter-peer-policy "diameter-peer-policy-1"
            gy
                avp-subscription-id subscriber-id type e164
                include-avp
                    radius-user-name
                exit
            exit
        exit
    exit
 
 
3.
 
configure
    subscriber-mgmt
        category-map "cat-map-1" create
            description "Category Map"
            credit-type time
            category "cat-1" create
                rating-group 1
                queue 1 ingress-egress
                exhausted-credit-service-level
                    pir 256
                exit
            exit
        exit
    exit
 
4.
Define the credit control servers to use by specifying the diameter application policy. Optionally, specify the default-category-map and an out-of-credit-action.
 
configure
    subscriber-mgmt
        credit-control-policy "cc-policy-1" create
            description "Credit Control Policy"
            credit-control-server diameter "diameter-gy-policy-1"
            default-category-map "cat-map-1"
            out-of-credit-action change-service-level
        exit
    exit
 
 
5.
 
configure
    subscriber-mgmt
        sla-profile "sla-profile-3" create
            description "SLA profile"
            credit-control-policy "cc-policy-1"
        exit
    exit
 
 
The following are examples of Diameter on-line charging flows:
Scenario 1 — Depicts a redirect use-case:
When the quota is depleted, the subscriber is redirected to a web portal. When the credit is refilled, the OCS server will notify the BNG and provide new quota. Note that 7750SR will install the configured out-of-credit-action when receiving a Final Unit Indication with action different from Terminate.
Figure 163: On-Line Charging Scenario 1 - Redirect (1/2)
Figure 164: On-Line Charging Scenario 1 - Redirect (2/2)
Scenario 2 — Depicts a terminate use case:
When the quota is depleted after reception of a Final Unit Indication with action set to Terminate, the subscriber host is disconnected. The configured out-of-credit-action is ignored in this case.
 
Figure 165: On-Line Charging Scenario 2 – Terminate
Abbreviations used in the previous drawings:
Policy Management via Gx Interface
Gx is a reference point in the network architecture model describing mobile service delivery. The network elements are described in various technical documents under the umbrella of 3GPP and are used to deliver, manage, report on and charge end-user traffic for mobile users. Gx reference point is used for policy control and charging control. As shown in Figure 166, it is placed between a policy server (PCRF - Policy and Rule Charging Function) and a traffic forwarding node (7x50 – Policy and Charging Enforcement Function) that enforces rules set by the policy server.
Figure 166: Gx Reference Point
The Gx reference point is defined in the Policy and Charging Control (PCC) architecture within 3GPP standardization body. The PCC architecture is defined in the document 23.203 while the Gx functionality is defined in the document 29.212. Gx is an application of the Diameter protocol (RFC 3588/6733).
Although Gx reference point is defined within 3GPP standardization body (spurred by mobile/wireless industry) its applicability has spread to wire-line operation as well. For example, mobile operators that also have fixed line customers (residential + business) would like to streamline policy management in their mobile and non-mobile domains with a single and already existing Gx based policy management infrastructure. In other words they want to integrate policy management of nodes serving fixed line subscribers into the system that is currently managing mobile subscriber base.
In such mixed environments, the 7x50 node plays a role of a PCEF with an integrated TDF (Traffic Detection Function, or Application Awareness [AA] in ALU terminology) where policies and charging rules can be managed via PCRF.
With WiFi Offload as a new emerging application, supporting Gx reference point on 7x50 nodes is becoming even more important.
Gx Interface in 7x50 encompasses the following functionality:
Gx will be applicable to Enhanced Subscriber Management (ESM) as well as to AA.
 
Gx Protocol
The Gx application is defined as a vendor specific Diameter application, where the vendor is 3GPP and the Application-ID for Gx application is 16777238. The vendor identifier assigned to 3GPP by IANA is 10415.
With regards to the Diameter protocol defined over the Gx interface, the 7x50 (PCEF) acts as a Diameter Client and the PCRF acts as a Diameter Server. The Gx Diameter Application uses existing Diameter Command Codes from the Diameter Base Protocol (RFC 6733) and Diameter Credit Control Application (RFC 4006), both of which are already implemented in 7x50.
Gx is using Attribute-Value Pairs (AVPs) for data representation within its messaging structures (command codes). AVPs in Gx come from various sources:
The initialization and maintenance of the connection between the 7x50 (PCEF) and the PCRF is defined by the underlying Diameter protocol as defined in RFC 3588/6733.
 
 
 
Policy Assignment Models
Subscriber and AA policies in 7x50 (PCEF with integrated TDF) will be assigned via Gx protocol from the policy server (PCRF).
There are two modes of operation:
In the pull mode, during the host creation process, a user is authenticated by the AAA server. This process is independent from PCRF. Once the user is authenticated and the IP address is allocated to it, the 7x50 sends a request for policies to the PCRF via CCR-i messages (initialization request message). This communication occurs via Gx interface. The subscriber-host must be uniquely identified in this request towards the PCRF. This sub identification over Gx interface could be by the means of IP address, username, SAP-id, etc.
Based on the user identification, PCRF will submit policies to the 7x50. Those policies can range from subscriber strings (sub/sla-profiles/AA-profiles) to qos and filter related parameters.
In the push mode, the PCRF initiates the mid-session policy change through the Re-Authentication Request (RAR) message.
Figure 167: Policy Assignment Models
In case that Usage-Monitoring is requested, the PCRF submitted policy changes are triggered by the Credit Control Request (Update) messages. This is based on ESM or AA Usage-Monitoring. Once the specified usage threshold is reached on the session-level, credit-category level, pcc rule level or application level on the 7x50, the Usage-Monitoring is reported from the 7x50 to the PCRF in the CCR-u message. Refer to the SR OS Multi-Service Integrated Services Adapter Guide for details on AA based Usage-Monitoring.
Alternatively, PCRF can request usage reporting on-demand via RAR command.
 
Figure 168: On-Demand Usage Reporting
 
IP-CAN Session – Gx Session Identification
IP Connectivity Access Network (IP-CAN) session is a concept that has roots in mobile applications. A policy rule via Gx interface can be applied/modified to an entity that is identified as IP-CAN session (in addition to individual bearers within the IP-CAN session, the bearer concept is currently not applicable to 7x50 BNG). For example, an UE (user interface or simply a mobile phone) can hosts several services, each of which appears as a separate IP-CAN session associated with the same IP address. For example in mobile world, an IP-CAN session can be defined as <IP_address, APN, IMSI>, where:
In wireline environment (ESM deployments), an IP-CAN session will identify an entity to which the policy can be applied/modified, and currently, this is a subscriber-host instantiated in the 7x50.
For the purpose of identifying the host in 7x50 in all Gx related transactions, the 7x50 will generate a unique, per host (single or dual-stack) session-id AVP (RFC 6733, §8.8). The Gx session-id will in essence represent the IP-CAN session from the standpoint of 7x50. Note that the Gx session-id AVP is not the same as the acct-session-id attribute used in RADIUS accounting.
 
User Identification in PCRF
The following identification related AVPs will be sent to the PCRF via 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, refer to the 7750 SR OS 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 will contain circuit-id from DHCPv4 Option (82,1) or interface-id from DHCPv6 option 18. The vendor-id will be set to ETSI (13019).
physical-access-id AVP (ETSI TS 283 034) — This will contain remote-id from DHCPv4 option (82,2) or DHCPv6 option 37. The vendor-id will be set to ETSI (13019).
Physical and logical access IDs are also defined in BBF TR-134 (§7.1.4.1).
 
Logical access ID
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.
 
NAS-Port-Id as Subscription-Id
7x50 allows the NAS-Port-Id to be carried within Subscription-Id AVP. Since the NAS-Port-Id may not be unique network-wide (two independent 7750s 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 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. Refer to the 7750 SR RADIUS Attribute Reference Guide to learn how to format NAS-Port-Id AVP in the SR 7x50.
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 in 7x50 (port + vlan tags) and the '@ALU-MOV-SITE-1' is the node itself.
Such NAS-Port-Id can be then inserted in the Subscription-Id AVP.
Gx Interface and ESM Subscriber Instantiation
Policy management via Gx enables operators to consolidate policy management systems used in wireline (mostly based on RADIUS/CoA) and wireless environment (PCRF/Gx) into a single system (PCRF/Gx).
The model for policy instantiation/modification via Gx is similar to the one using RADIUS CoA. The authentication and IP address assignment is provided outside of Gx while the policy management function is provided via Gx.
Some PCRFs may require that the IP address information is passed from the 7x50 in CCR-i. This assumes that the IP address assignment phase (via LUDB, RADIUS or DHCP Server) is completed before the PCRF is contacted via CCR-i. Message flow for various protocols (DHCP, AAA, Gx) related to IPv4 subscriber-host instantiation phase is shown in Figure 169
CCR-i message is sent to the PCRF once DHCP Ack is received from the DHCP server. Relaying DHCP Ack to the client in the final phase of the host instantiation process will depend on the answer from the PCRF and the configuration settings of the fallback function in case that the answer is not received.
This model allows the IP address of the host to be sent in the CCR-i message, even though the subscriber-host is not fully instantiated at the time when the CCR-i message is generated.
AAA/LUDB must still be used for authentication and assignment of parameters necessary to place the subscriber host in the proper routing context (service-id, grp-id, msap-policy).
Start of the accounting process nicely fits into this model since the host is not instantiated until the policy information from all sources (Gx, AAA, defaults) is known. Once the final sub-profile (containing the acct-policy) is known, the host will be instantiated and accounting can consequently be activated.
The IP address itself cannot be assigned via Gx, and this functionality is outside of the Gx scope (3GPP TS 23.203 Rel12, Annex S, IP-CAN Session Establishment section).
The purpose of the CCR-i message is the following:
 
Figure 169: Messages Flow During DHCPv4 Host Instantiation Phase
Message flow for PPPoEv4 host is similar. The host will be instantiated once the answer from PCRF is received.
However, IPCP negotiation and Gx negotiation (CCR/CCA) are performed in parallel, independently of each other and therefore 7x50 will not wait for the Gx session to be established before the last IPCP ConfAck is sent (like it is the case for DHCP ACK).
Once the host is instantiated in the 7x50 (after the CCA-i is received or as defined by the fallback action in case that the PCRF is not available), the Accounting-Start message will be sent by the 7x50 (assuming that accounting is enabled).
 
The message flow is shown in Figure 170.
Figure 170: Message Flow During PPPoEv4 Host Instantiation Phase
The host is created when the Gx session is established and therefore the subscriber host will transition into the traffic forwarding state once the Gx processing is completed. In case that the PCRF is unavailable or unresponsive, the host creation/termination will be driven by the fallback configuration
 
Gx and Dual-Stack Hosts
Dual-stack (DS) hosts are treated as a single session from the Gx perspective. The PCRF submits the policy rule that will be applied to DS host as a whole, regardless of the IP address (IPv4 or IPv6) that triggered the CCR-i message. DHCPv4 and DHCPv6 requests for DS host are linked by the same <SAP,MAC> combination which must be unique per system, while in PPPoE case the existing concept of the PPPoE session provides the v4/v6 linking natively.
The CCR-i will contain the IP address that was allocated first (the one that triggered the session creation). The request for the second IP address family will trigger (if enabled by configuration) an additional CCR-u that will carry the IP address allocation update to the PCRF along with the UE_IP_ADDRESS_ALLOCATE (18) event. Apart from that, the CCR-u content will mirror the content of the CCR-i with exception of already allocated IP address(es). There is a single Gx message (CCR-i or CCR-u) carrying the update for DHCPv6 IA-NA+IA-PD and DHCPv6/PPPoE NA+PD address/prefix, assuming that NA+PD is requested in a single DHCP message.
Similarly for the Gx session teardown, CCR-u messages will be sent carrying the UE_IP_ADDRESS_RELEASE event, followed by the CCR-t message.
The message flow is depicted in Figure 171.
Figure 171: Gx and Dual Stack 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 Figure 171, processing of the DHCPv6 Replay and CCR-u messages is performed in parallel. In other words, sending the DHCPv6 Reply message to the client will not be 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. In this case, the CCR-u message is simply a notification message, informing the PCRF about the new IPv6 address/prefix being assigned to an existing client.
 
 
Gx and PPPoEv6-DHCP
For PPPoE v6 hosts, the IPv6 address is not obtained during IPCP phase (only interface-id is negotiated). In this case, the 7x50 will wait 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 Figure 172.
Figure 172: Gx and PPPoEv6 Host Instantiation
 
Gx Fallback Function
The Gx fallback functionality refers to the behavior related to the subscriber host instantiation in situations where the PCRF is unresponsive while peering connection(s) are up or the PCRF is unavailable with all peering connections down. This functionality affects only Gx session processing related to CCR-i messages in 7x50 and has no effect on already established Gx sessions.
The fallback behavior can be controlled via local configuration in 7x50 or can be controlled via certain AVPs provided by PCRF.
PCRF provided AVPs that control fallback behavior are:
In case the fallback-related AVPs are not provided via PCRF, the 7750 SR can provide local configuration option to define the fallback behavior. In case that the response from the PCRF cannot be obtained, the local configuration can allow the subscriber host to be instantiated with default parameters, or alternatively the local configuration can deny subscriber host instantiation.
PCRF provided AVPs will overrule local configuration.
The local configuration that defines Gx fallback behavior can be found under the following CLI hierarchy:
config
    subscr-mgmt
      diam-appl-plcy
        on-failure 	
          failover {enabled|disabled} 
            handling {continue|retry-and-terminate|terminate}
 
The failover configuration option (equivalent to CC-Session-Failover AVP) controls whether the secondary peer will be used in case that the primary peer is unresponsive. The unresponsiveness is determined by the timeout of the previously sent message.
The handling configuration option (equivalent to Credit-Control-Failure-Handling AVP) controls whether the subscriber will be terminated or instantiated with default parameters in case that the PCRF is unresponsive.
 
The CCR retransmissions are controlled by the tx-timer command under the diameter-application-policy. Refer to the SR OS CLI reference for the description of retransmission handling.
In the case that all peers are down (no connections are open), the handling action will determine the behavior. If the action is set to continue, the subscriber-host will be immediately instantiated with the default-settings (provided that the defaults are available). In all other action cases, the host instantiation will be immediately terminated.
 
Gx CCR-I Replays
As described in the previous section, the subscriber host can be optionally (configuration controlled) established with default settings (sla-profile, sub-profile, app-profile) in the case where PCRF is not available to answer CCR-i. This results in a subscriber-host state mismatch between the 7750 SR and PCRF, where the subscriber-host is established in the 7750 SR but there is no corresponding Gx session established in PCRF.
In order to resolve this situation, ESM periodically sends CCR-i for the Gx orphaned subscriber‑host until the response from PCRF is received. The CCR-i is periodically retransmitted every 60 seconds.
 
Gx CCR-t Replays
Termination of the subscriber-host in 7x50 without termination of the corresponding Gx session in PCRF will result in state mismatch between 7x50 and the PCRF whereby the host Gx session is present in the PCRF while it is removed from 7x50.
Some PCRFs can cope with such out-of-sync condition by periodically auditing all existing Gx sessions. For example, a probing RAR can be sent periodically for each active Gx session. The sole purpose of this probing RAR is to solicit a response from the PCEF (7x50) and provide indication on whether the corresponding Gx session is alive in 7x50 or is vanished. The ‘probing’ RAR can contain an Event-Trigger that is already applied in 7x50, or if none is applied, then the Event-Trigger can contain NO_EVENT_TRIGGER. In either case the ‘probing’ RAR will not cause any specific action to be taken in 7x50 and it is used only to solicit reply from PCRF.
To minimize the impact on performance, probing RARs are sent infrequently and thus it may take days to discover stale Gx session on PCRF. 7x50 offers a mechanism that can clear the stale session in PCRF sooner. It does this by re-playing CCR-t messages until the proper response from PCRF is received (CCA-t). The CCR-t messages will be re-played up to 24 hours. This period of 24 hours is not configurable. In case that 24hour period expires before the proper answer is received, the CCR-t is deleted and a log is generated. The log contains Gx session-id.
The T-bit (retransmission bit) is set in all re-played CCR-t messages.
The following command will clear all orphaned sessions in 7x50 for a given diameter application policy:
clear subscriber-mgmt diameter-session CCR-t-replay diameter-application-policy <gx-policy-name>.  
 
RAR and CCR-t Replay
Certain scenarios will make possible that PCRF sends a RAR message to an orphaned Gx session running CCR-t replays in 7x50. The ESM host associated with such orphaned Gx session does not exist and therefore RAR cannot be applied.
In this scenario, 7x50 will reply with RAA carrying Result-Code= DIAMETER_UNKNOWN_ SESSION_ID (5002).
 
CCR-t Replay And Multi-Chassis Redundancy
The first CCR-t reply for each Gx session will be synchronized, but the consecutive CCR-t replays for the same Gx sessions will not be synchronized. Once the answer (CCA-t) is received, the CCR-t replay will be terminated and this event (deletion of CCR-t replay) will be 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 will 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 given Gx session. This occurs at the very beginning, when a CCR-t replay is first initiated for a given Gx session. The armed node will stay silent until the MCS peer that is actively sending CCR-t replays for a given Gx session, reboots. Only when the MCS peer reboots, the armed node will start sending CCR-t replays for a given 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.
 
CCR-t Replay And High Availability
On CPM switchover, the newly active CPM will immediately trigger a new CCR-t replay with T-bit set. From then onwards, CCR-t replays will be sent according to the configured replay interval. In other words, the replay interval will be reset on the CPM switchover. However, the lifetime is not reset when CPM switchover occurs, and is synchronized between CPMs.
 
 
 
 
Automatic Updates for IP Address Allocation/De-allocation
During the subscriber-host setup phase, the first allocated IP address is sent in the CCR-i message from the 7x50 to the PCRF.
Each subsequent IP address allocation/de-allocation for the same host can optionally trigger a CCR-u, notifying the PCRF of the IP address allocation/de-allocation event.
This behavior can be enabled via the following CLI command:
configure
    subscriber-mgmt
      diameter-application-policy <pol-name>
        gx
          [no] report-ip-addr-event
 
The IP address allocation/dea-llocation event driven CCR-u message will carry the respective event code [UE_IP_ADDRESS_ALLOCATE(18) or UE_IP_ADDRESS_RELEASE(19)] along with the corresponding IP address.
The IP address allocation/de-allocation events are applicable to the following addresses:
These event-codes will only be sent in CCR-u messages and not in CCR-i and CCR-t messages (when the host is instantiated and terminated).
Examples:
If the IP address notification event is enabled, 7x50 originated Gx message will carry all known IP addresses/prefixes associated with the subscriber-host (Gx session), unless those messages contain one of the two event codes:
UE_IP_ADDRESS_ALLOCATE(18) or UE_IP_ADDRESS_RELEASE(19). In the case that one of those two events is present in the Gx message, the IP address/prefix carried in that message will be only relevant to the event contained in the message (address/prefix allocated or released).
If the IP address notification event is disabled, 7x50 will only send the IP address from the first host. This IP address will be included in all messages related to the Gx session. If this IP address is removed (de-allocated) mid-session from the dual-stack host, 7x50 will stop advertising it, or any other address, from Gx messages for that particular session.
 
DHCPv4/v6 Re-Authentication and RADIUS CoA Interactions With Gx
In case that re-authentication for DHCPv4/v6 hosts is enabled, any policy changes that may be submitted during re-authentication (for example sla-profile update via Access-Accept) will overwrite the one previously applied, regardless of the source of the policy update. For example, in case that the Gx policy is applied to a subscriber host via RAR (mid-session policy update) and then some time later an overlapping policy with different values is submitted via RADIUS or LUDB during the re-authentication phase, the RADIUS/LUDB submitted policy will overwrite the one applied via Gx. In other words, the origin of the current policy in effect is not maintained internally in the system and therefore the overlapping policy update cannot be prioritized according to the source of the policy.
The following guidelines should be followed in case where the policy is provided via Gx:
In case that LUDB access is enabled, there should be no overlap between the LUDB provided parameters and Gx provided parameters. LUDB is accessed during every DHCP lease renew process and consequently parameters configured via LUDB would overwrite parameters provided by Gx.
In case that re-authentication is enabled, there should be no overlap between the RADIUS provided parameters and Gx provided parameters. With re-authentication enabled, RADIUS is contacted during every DHCP lease renew process and consequently parameters configured via RADIUS would overwrite parameters provided by Gx.
These guidelines are not applicable for PPPoE subscriber-hosts since re-authentication cannot be enabled for PPPoE hosts. Consequently, LUDB or RADIUS parameters cannot override Gx provided parameters.
Coexistence of RADIUS CoA and Gx for the same host is allowed. The two policy change mechanisms are independent of each other and as such they can override each other. For example, if the RADIUS CoA for policy change for the host is received, the policy will be updated but the PCRF (Gx) will not be notified of the change. If both policy management mechanisms are deployed simultaneously, then it is the operator’s responsibility to synchronize the actions between the two.
 
Gx, ESM and AA
Although the ESM subscriber and the AA subscriber are two separate instantiations within the 7x50, their policy management and Usage-Monitoring are handled uniformly through a single Gx session.
 
ESM Subscriber-host vs AA Subscriber
Since 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). Refer to the SR OS Multi-Service Integrated Services Adapter Guide for details on Application Assurance concepts.
 
AA Subscriber State
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:
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:
 
Policy Management via Gx
Policy change can be implicitly requested by 7x50 at IP-Can session establishment time via CCR-i command. 7x50 will supply user identification attributes to the PCRF so that the PCRF can identify rules to be applied. However, 7x50 will not explicitly request specific policy update, for example via Event-Trigger = RESOURCE_MODIFICATION_REQUEST.
Another way to request policy update in 7x50 is via RAR command in a PUSH model.
Gx policies in 7x50 can be enforced via these three mechanisms:
 
Gx-Based Overrides
Gx-based overrides refer to activation or modification of the existing subscriber-host related objects in 7x50.
Subscriber-host related objects are shown in Figure 173. A subscriber represents a residence or home and it is identified by Subscriber-Id string in 7x50. Subscriber in 7x50 can be comprised of multiple hosts in bridged home environment or a single host in routed home environment.
Figure 173: ESM Objects Managed via Various Policies and Profiles
The two basic concepts in ESM context are sla-profile with its associated objects and sub-profile with its associated objects.
 
Instantiation of Gx Overrides
For a list of Gx related AVPs supported in 7x50, refer to the 7750 SR OS 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 towards 7x50.
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 in order to return the override status from 7x50 to the PCRF upon the override instantiation.
The objects (subscriber-hosts) to which the new overrides are applied must exists in 7x50 otherwise the override installation will fail.
Removal of overrides is not supported. The parameters defining a new override will simply replace 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:
Charging-Rule-Name AVP within the Charging-Rule-Install grouped AVP points to the preconfigured filter in the system, the preconfigured subscriber profiles or it simply represents the ESM string (such as inter-destination-string used to associate the subscriber host with a vPort construct). The existing objects applied to the subscriber-host will be replaced with the referenced one.
 
It is important to distinguish two locations for invoking Charging-Rule-Name AVP for overrides:
1.
Filter installation/overrides:
Subscriber-Id override:
Profile installation/overrides:
Inter-destination string override:
Usage-Monitoring:
AA:
 
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 in 7750.
 
2.
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.
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 in 7x50 but instead directly defined in the ADC-Rule-Definition. In AA, such rule definition can define AA overrides that will be applied to the subscriber. In other words, the existing objects for the subscriber will be 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.
“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
In this case, the aa-rule-name is an arbitrary name that will be used in rule status reporting.
In case 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 details in the SR OS Multi-Service Integrated Services Adapter Guide). Note however, that AA-Function AVP and AA-Usage-Monitoring cannot co-exist in the same ADC rule.
 
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 7x50.
The Charging-Rule-Name in this AVP can be arbitrarily set and it is used to uniquely identify the overrride in error reporting.
	Charging-Rule-Definition ::= < AVP Header: 1003 >
							 	{ Charging-Rule-Name }							 	
							 	[ QoS-Information ]	
								[ Nas-Filter-Rule]
								[ Alc-NAS-Filter-Rule-Shared]								
								*[ AVP ]
 
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 7x50. 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 7x50 and the PCRF within one IP CAN session.
	ADC-Rule-Definition ::= < AVP Header: 1094 >
			{ ADC-Rule-Name }				
			[AA-Functions]
			*[ AVP ]
 
In summary:
 
Examples of Gx Overrides
There are two ways of enforcing a Gx override in 7x50:
1.
2.
The following AVPs will identify Gx overrides that will be applied to a subscriber host. These AVPs can be included in CCA-i, CCA-u or RAR message sent from the PCRF. Note that in the first approach, all Gx overrides are submitted under a single Charging-Rule-Install AVP:
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> = “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 this example various subscriber profiles (sub/sla) will be applied to the subscriber host and at the same time a new ingress v4 and egress v6 filter will be installed. The subscriber-id will be overridden with the new name ‘residence-1’. Characteristics for queue 5 and 7 will be overridden.
Also the egress rate limit for the subscriber will be overridden and the subscriber host will be associated with the vPort named vport-AN-1.
All x overrides are aggregated under the same Charging/ADC-Rule-Install AVP.
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> = “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, etc.) can be examined individually via 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
 
PCC Rules
A generic use case for flow based dynamic policy is related to customized network level treatment of on-demand services. Such services can represent wide range of applications, such as video-on-demand or an access to a specific application in the network. The service can be identified by traffic destination parameters or DSCP bits. Once the service is identified within 7x50, a set of actions can be applied to the service (rate change, forwarding-class change, Usage-Monitoring, etc.).
Figure 174: Generic Use Case For IP-Criterion Based Policy Change via Gx
Typical flow of events for service activation is shown in Figure 174:
1.
2.
3.
4.
5.  
6.  
7.
 
PCC Rule Concept
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:
Supported actions are:
 
PCC Rule Instantiation
A PCC rule that is submitted to 7x50 via PCRF is internally instantiated using two basic policy constructs within 7x50, qos-policy and filter (ACL). Behavior-wise, 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 in 7x50, regardless of whether the rule is QoS related of filter (ACL) related.
The type of action within the PCC rule will determine whether the PCC rule is split within 7x50 between the qos-policy and the filter.
Rules with actions:
will be converted into a qos-policy within 7x50, while the rules with actions:
will be converted into filter rules.
The operator should be aware of this division for the dimensioning (scaling) purposes. Operational commands can be utilized to reveal resource consumption within 7x50.
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 since the qos resources are allocated per sla-instance1. This means that all hosts sharing the same sla-profile instance will inherit the change.
Filter-related entries are applied per each subscriber-host, irrespective of whether the hosts are sharing an sla-profile instance or not.
The concept of splitting the rules in 7x50 is shown in Figure 175.
Figure 175: PCC Rule Conversion within 7x50
The PCC rule instantiation will fail in 7x50 in case that a PCC rule contains only actions, without any classification, or if it contains only classification without any actions.
 
Base QoS-Policy and Base Filter
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 will be in effect. In this case, PCC rules with 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 Figure 176. 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:
configure>filter>ip-filter>
configure>filter>ipv6-filter
configure>qos>sap-ingres>
configure>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:
Such defined entry will map 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.
Figure 176: Static and Dynamic QoS-Policy/Filter Entries
 
Generic Policy Sharing and Rule Sharing
Policy2 sharing between the subscriber hosts is depicted in Figure 177. In order 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 will be instantiated. This new policy will consume 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.
Figure 177: Policy Cloning
 
PCC Rule Name and PCC Rule Removal
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 7x50 via a Gx directive by referencing the PCC rule name. The rule name is supplied via Charging-Rule-Name AVP at the time of the rule submission to the 7x50 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 7x50 is:
Charging-Rule-Remove ::= < AVP Header: 1002 >
							*[ Charging-Rule-Name ]
			
An example of rule instantiation and rule removal is shown in Figure 178.
Figure 178: Policy Removal by Name
 
 
Gx Rule Ordering
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 ways3:
The ordering behavior according to the Precedence is shown in Figure 179.
Figure 179: PCC Rule Ordering - Priority Model
The premise of the automatic rule optimization is shown in Figure 179.
Figure 180: Rule Ordering - Optimization 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 will be 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 given 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 within 7x50 in a way that what would allow more optimal sharing of the rules between different subscribers
 
PCC Rule Override
A PCC rule applied to a subscriber-host in 7x50 can be overridden by re-submitting the PCC rule with the same name but different contents.
In case that at least 1 new flow is sent in the PCC rule update, then the existing flows are removed and replaced with the new flow. In case that no new flows are submitted, then the existing flows stay in place.
In case that there are conflicting parameters between the existing rule and the modified rule (for example the combination of the unsupported actions), the PCC rule override will fail.
 
Aggregation of IP-Criterion
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 7x50
		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 will be fed into the same rate limiter (policer).
 
Gx Rules with Multiple Actions and Action Sharing
PCC rule can contain multiple actions.
The following table shows combinations of actions that are supported simultaneously within a given rule.
Legend:
Ingress:
Egress:
 
Combining IPv4 and IPv6 Entries within the Rule
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 non IP address aware actions (rate-limit, FC change, etc.) are universal and it will be applied to both flow types (IPv4 and IPv6). 7x50 will automatically sort out flow types (IPv4 and IPv6) within the rule and apply corresponding actions.
In case that the rule contains a mismatching flow type and actions (for example IPv4 flows and IPv6 specific action), the 7x50 will reject the rule. 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.
 
Alc-NAS-Filter-Rule-Shared AVP vs Flow-Information AVP
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:
<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:
configure>filter>ip-filter>
configure>filter>ipv6-filter
Such rule cannot be removed by the Charging-Rule-Remove directive referencing the rule name. Instead, each such Gx rule will overwrite the previous one.
sub-insert-shared-pccrule start-entry <entry-id> count <count>
under the following CLI hierarchy:
configure>filter>ip-filter>
configure>filter>ipv6-filter>
configure>qos>sap-ingress>
configure>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.
 
RADIUS and Gx Interaction
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 will override 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 Figure 181. 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.
Figure 181: CAM Table Population
 
Bulk Changes via CLI while Gx Rules are Active
Once PCC rules are applied to a subscriber-host, the operator is allowed to modify via CLI some of the parameters in the base filter/qos-policy. For example, the operator is allowed to add/remove terms in the base ACL filter.
The list of the parameters in the QoS policy that can be changed is shown in Table 3. Adding/removing queue/policer, re-mapping of FC, modifying dscp-map or modifying static ip-criteria is not allowed.
Modified parameters in the base-policy/filter referenced in the sla-profile will affect all subscribers using this sla-profile. Replacing the base qos-policy/filter in sla-profile is not allowed for any subscriber-host in case that a clone of the base qos-policy/filter exist anywhere in the system.
However, replacing the base filter-id for a host via CoA or Gx override is allowed. In this case, only the targeted host will be affected and all existing PCC rules for this host will be merged with the new filter.
 
 
PCC Rule Direction
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.
In case that the action within the PCC rule is in conflict with the direction of the flow, the PCC rule instantiation will fail. For example, an error will be raised if the flow direction is UPSTREAM, while the action is ‘Max-Requested-Bandwidth-DL’ (downstream bandwidth limit).
 
Action
A PCC rule may contain multiple actions. Each action is carried in a separate, action specific AVP. The action specified in the flow-description->ipfilterrule data type is ignored. In case that the rule contains multiple instances of the same action, each with a different value, the last occurrence of the action value will be in effect.
Not all of the action types can be applied at the same time. The allowed combination of the actions per direction is given in Table 26 and Table 27.
 
Rate-Limiting Action (Ingress, Egress)
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 will share common properties configured under the dynamic-policer CLI hierarchy:
configure
	qos
		sap-ingress/egress
			dynamic-policer  
				stat-mode 	no-stats|minimal|offered-profile-no-cir|
offered-profile-cir|offered-total-cir|
offered-limited-capped-cir|offered-profile-capped-cir
				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 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.
 
Dynamic Policers and Queue Mappings
Once traffic is processed by the dynamic policers on ingress, the traffic will flow through the policer-output-queues shared queues. Traffic through dynamic policers will always bypass subscriber queues or policers on ingress that are statically configured in the base qos-policy.
Similar behavior is exhibited when static policers are configured on egress. Traffic outputting dynamic policer is never mapped to another static policer. Instead, such traffic will be mapped to the corresponding shared queue in a queue-group. By default, this queue-group is the policer-output-queue group. However, the selection of the queue-group is configurable.
In contrast to the above, traffic processed by dynamic policers can be fed into statically configured subscriber (local) queues on egress. Dynamic policers and subscriber queues are tied through the forwarding-class.
The policer to local queue mapping and inheritance of the forwarding-class is shown in Figure 15. In this example, the mapping of traffic —> forwarding-class in rule 2 (flow 2) will depend on the DSCP bits in the traffic flow. If the DSCP value in this traffic flow are different from the explicitly configured DSCP values in the static (base) QoS policy, then traffic will be mapped to the default forwarding-class.
Figure 182: FC Inheritance for Dynamically Instantiated Policers on Egress
 
Dynamic Policer Rates and Accounting Statistics
By default, policer rates are configured based on Layer 2 frame length (for example, the Ethernet header plus the IP packet). This can be changed by the packet-byte-offset (PBO) command under the policer. In case that the policer is fed into a local queue, the PBO of the policer will not affect the PBO of the local queue it is feeding.
The rates for local subscriber queues can be independently measured based on Layer 2 or Layer 1 frame length and the queue statistics can be measured based on Layer 1, Layer 2 or Layer 3 (IP-only) frame length. The IP-only stats for queues can be configured in the sub-profil>volume-stats-type {ip|default}.
Dynamic policer4 statistics are not reported in RADIUS-based accounting. On egress, this will have no effect on volume counters in RADIUS-based accounting, since the dynamic policers are normally fed into local queues whose statistics are reported in RADIUS-based accounting. However, on ingress, the dynamic policers are always fed into the queue-group queues which are excluded from RADIUS based accounting. The consequence is that the ingress RADIUS-based accounting will lack statistics for the traffic that is flowing via dynamic policers.
In case that the dynamic policer is feeding a local queue, the aggregate statistics in show commands for such queue are not reported in order to avoid double counting (since the traffic statistics in show commands are already reported for the dynamic policer). However, the per-queue statistics are reported in show commands, irrespective of whether the policer is mapped to the local queue or not.
To avoid losing aggregate SAP or subscriber stats in show commands, the recommendation is to have policers feed into local queues which are not already mapped to an FC.For example:
queue 4 create //Not counted since policer 2 is feeding it
exit
policer 2 create
exit
fc be create
	queue 4     //Not counted
exit
fc l1 create
	queue 4     //Not counted
exit
fc ef create
	policer 2 queue 4
exit
FC BE, FC2 L1 —> queue 4
FC EF —> policer 2, queue 4
In this case, traffic from queue 4 will not be counted in aggregate stats at all and consequently the aggregate accounting information will be lost for FC BE and FC L1.
 
Forwarding-Class Change (Ingress, Egress)
Traffic can be re-prioritized via PCC rule by re-classification into a different forwarding class. The forwarding-class can be changed for the following cases:
For example:
configure>qos>sap-egress#
dscp af11 fc "af"
Such mapping is configured outside of CAM and as such it has lower evaluation priority than the mapping configured via PCC rule which is installed in CAM.
For example:
config>qos>sap-egress>#
ip-criteria
entry 40000 create
match
dscp af11
exit
action fc "af"
exit
exit
In this case, 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 in 7x50 are mapped to QCIs (3GPP TS 23.203 §6.1.7.2) in the following manner:
BE — QCI 8
L2 — QCI 7
AF — QCI 6
L1 — QCI 4
H2 — QCI 2
EF — QCI 3
H1 — QCI 1
NC — QCI 5
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
 
Next-Hop Redirect (Ingress)
The next hop redirection will explicitly or implicitly change the next-hop for the traffic flow within the same service ID (routing context) or a different service ID (routing context).
In case that the next-hop is not explicitly provided, the next-hop will be 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:
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 will be performed to find the path (next-hop) to the indirect next hop from the PCC rule.
In case that only the service-id is specified in PCC rule (without the next-hop), then the next-hop will be selected from the specified service-id based on the destination IP address of the packet.
 
HTTP Redirect (Ingress)
HTTP redirect utilizes 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 >
							
 
 
Gate Function
The gate function is analogous to the forward | drop action within IP filters in CLI.
The Flow-Status AVP <AVP Header: 511> (3GPP 29.214, §5.3.11.) defines the gating action. The two supported values are enable and disable.
The gating action enabled (2) is the default action and it must be accompanied by at least one other action. In other words, the gating action enable cannot be the only action in the PCC rule. Otherwise the PCC rule is treated as it would not have any action at all and as such it will be rejected.
In case that the gating action is set to disable (3), all other actions within the same rule will lose their meaning since the packet will be dropped. In effect, the disabled directive will disable the flow of classified traffic through the system. Note that this is not the same as disabling the rule in a sense that the flow of packets would be permitted through the 7x50 although with no actions applied.
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 ]
 
 
 
PCC Rule Provisioning Example
An example for PCC rule provisioning in CCA-I message is given below:
<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 7x50 (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 one is used to instantiate the host. The second one 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 to the TCP port range 40000-40010 on the node with IP address 10.10.10.10/32.
The actions for this traffic flow are:
 
Operational Aspects
The commands used to examine dynamic rules and NAS filter inserts associated with the subscriber hosts are shown in Figure 183.
Figure 183: Overview of PCC Rule-Related Operational Commands
 
PCC Rules and Capacity Planning
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 set of base qos-policy or filter-id along with all PCC rules that are applied to a subscriber or a set of subscribers.
Let’s 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, let’s 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. In this case, ‘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 will 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.
Once 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 will take in CAM.
 
PCC Rule Scaling Example
The Figure 184 depicts an example relevant to capacity planning, with focus on understanding the scaling limits when it comes to the number of PCC rules and their mutual combinations when they are applied to the subscriber hosts.
This example is focusing 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 only for illustration purposes:
Note that the actual CAM limits vary per policy type (filter/qos), direction and IP address type (v4 vs v6). The actual scaling limits can be found in SROS Scaling Guides for the relevant software release.
Figure 184: Example of the Scaling Limits for PCC Rules
 
NAS Filter Inserts
Gx filter entries inserted via NAS-Filter-Rule are subscriber-host specific entries. This means that in the upstream direction, the source IP address in the NAS-Filter-Rule will always be internally set by 7x50 to the IP address of the subscriber host itself. Similarly, in the downstream direction the destination IP address in the NAS-Filter-Rule will be set by 7x50 to be the IP address of the subscriber-host itself.
On the other hand, the entries in the Alc-NAS-Filter-Rule-Shared AVP are processed as received without any modifications. This means that such entries can be shared with all the hosts that have the same Alc-NAS-Filter-Rule-Shared applied.
Similarly to QoS overrides, NAS filter entries are not predefined in 7x50 but instead they are defined under the Charging-Rule-Install — Charging-Rule-Definition AVP.
The Charging-Rule-Name AVP for NAS filter inserts is an arbitrary name that is part of Charging-Rule-Definition AVP in which NAS-Filter-Rule AVP or Alc-NAS-Filter-Rule-Shared is provided. Such Charging-Rule-Name will be used to report errors related to instantiation of the inserts.
 
Examples of NAS Entry Inserts
The following AVPs will identify NAS filter inserts that will be 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 will be inserted in the clone of the existing base filter for the subscriber(s).
 
 
Error Handing and Rule Failure Reporting in ESM
The Gx rule (overrides, PCC rules or NAS filter inserts) instantiation failure in 7x50 can occur on two levels:
Invalid content of a supported AVP will the M-bit set will also trigger the same response. Invalid content of an AVP refers to the malformed syntax of an AVP that carries the type of the AVP value implicitly embedded in the AVP value itself. Consider sla-profile:rule-name-1 string. In this case, the sla-profile: refers to the type of the value carried in the Charging-Rule-Name AVP. The value that Charging-Rule-Name carries is rule-name-1 and it this value represents the sla-profile name already configured within 7x50 (as opposed to filter, sub-profile, category-map, etc). In case that sla-profile: in our example is misspelled (type is unrecognized), the whole AVP will be un-decodable.
Another example that can cause all rules with the ESM module to fail would be invalid combination of actions within the rule.
 
AVP Decoding Failure in Gx
Reporting an AVP decoding problem in Gx is described in the following example:
A Gx directive is received to install two overrides in 7x50. The two overrides are supposed to change the sla 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”
Since the Charging-Rule-Name AVP has the M-bit set, the whole message will fail and an error will be reported. No rules within this Gx message will be installed (not even the valid ones, in this case this would be the Charging-Rule-Name = “Sub-Profile:prem”). Note that if the M-bit was clear in the Charging-Rule-Name AVP, the erroneous AVP would be simply ignored and we would proceed with installation of the remaining, ‘correctly formatted’ rules.
The nature of the error will depend on the original directive sent by the PCRF (RAR or CCA – push or pull model)
In case that the directive from the PCRF is passed via CCA command, the response will be CCR-u command 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
	
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 OS Gx AVPs Reference Guide), the whole message will fail 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.
 
ESM Rule-Installation Failure
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 case below, the referenced sla-profile is unknown. In such case, all directives passed to the ESM module will fail and consequently no rules/overrides will be installed. The sub-profile change will fail 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 will be the following:
[ 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)
 
RAA = OK since the Gx module successfully processed the AVP parsing.
The RAA will be followed by CCR-u, triggered by the rule instantiation failure in ESM module. CCR-u will contain 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, note that ESM, UM and AA are separate modules and failure to install rule in one module will not affect rule installation in another.
 
Failure Reporting in AA
Failure reporting in AA is performed in similar fashion as in ESM.
Instead of Charging-Rule-Report AVP, the ADC-Rule-Report will be used:
ADC-Rule-Report ::= < AVP Header: 1097 >
						*[ ADC-Rule-Name ]					
						 [ PCC-Rule-Status ]
						 [ Rule-Failure-Code ]
						*[ AVP ]
 
 
Summary of Failure Reporting
Table 29 summarizes Gx failure reporting in 7750.
 
 
 
Usage-Monitoring and Reporting
Usage-Monitoring and reporting refers to the collection and reporting of octets (volume) that a service or application on the 7x50 has consumed during certain period. The usage on the 7x50 is reported via Gx interface to the PCRF. Based on this information, the PCRF can apply specific action (policy change) to the entity being monitored. For example, QoS can be modified, or the service can be blocked when specific thresholds are reached.
Usage-Monitoring and reporting is performed over a single Gx session for the ESM/AA subscriber. In other words, there is only a single session for an ESM subscriber(-host) and corresponding AA subscriber. Via this single Gx session, Usage-Monitoring can be requested simultaneously in ESM context (PCC rule level, credit-category and/or IP-CAN session) and AA context (application based Usage-Monitoring).
 
ESM Usage-Monitoring - What is Being Monitored
In the ESM context, volume consumption (octets - 3GPP 23.203 §4.4) can be monitored on three levels:
Usage-Monitoring can be monitored simultaneously on all three levels.
An IP-CAN session in the 7x50 represents a subscriber-host whose service types are determined by the sla-profile instance. In per IP-CAN session volume monitoring, the aggregated queue/policer counters will be reported per direction (in | out). This includes dynamic policers that are instantiated as a result of a Gx action (for example rate-limiting).
In case that the sla-profile instance changes mid-session, the counters will be 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 such queue/policer (or set of queues/policers as a subset of sla-profile instance) represents a service for which the Usage-Monitoring is required. Those queues/policers (services) are organized within 7x50 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 in 7750) that is used in Usage-Monitoring can be associated with the subscriber-host through the following methods (in the order of priority):
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 7x50 but it will not be active until it is turned on by the PCRF either via CCA-i, CCA-u or RAR.
Usage-monitoring can be enabled per ingress and/or egress direction or as total count. However monitoring the total count is mutually exclusive with per direction count. For example, total Usage-Monitoring cannot be enabled simultaneously with ingress (or egress) Usage-Monitoring for the same monitoring entity (session or category).
 
AA Usage-Monitoring – What is Being Monitored
In AA, charging groups (CG), application groups (AG) and applications are monitored. Refer to the SR OS Multi-Service Integrated Services Adapter Guide for details.
 
Requesting Usage-Monitoring in ESM
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)
 
Reporting Accumulated Usage
The 7x50 reports usage information to the PCRF under the following conditions:
To report accumulated usage for a specific monitoring-key the 7x50 sends a CCR with the Usage-Monitoring-Information AVP containing the accumulated usage information since the last report. For each of the enabled monitoring-key, the Usage-Monitoring-Information AVP will include the Monitoring-Key AVP and the accumulated volume usage in the Used-Service-Unit AVP.
Usage report on the 7x50 can be triggered by reaching the usage threshold communicated to the 7x50 by PCRF in CCR-u message carrying accumulated usage for that monitoring entity along with the Event-Trigger AVP set to USAGE_REPORT.
PCRF will in response to CCR-u message communicate to the 7x50 via CCA-u message whether the Usage-Monitoring should continue:
Threshold are incremental. For example if the quota of 100MB is submitted to the 7x50, the usage should be reported when that quota is reached. At that point the user can be granted another 100MB. The new usage report on the 7x50 will be triggered when another 100MB are accumulated. Absence of the threshold for a given entity in CCA-u message is an indication that the Usage-Monitoring should stop.
When the PCRF informs the 7x50 that Usage-Monitoring should stop (by not including thresholds in CCA-u), the 7x50 will not report usage which has accumulated between sending the CCR and receiving the CCA.
Another possibility of usage reporting is on-demand. In such scenario, usage for one or more monitoring keys will be reported regardless of whether the usage threshold has been reached. This is achieved by sending to the 7x50 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 will be reported to the PCRF.
In case 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 7x50 will report the outstanding usage in CCR-u command with the Event-Trigger set to USAGE_REPORT.
 
Disabling Usage-Monitoring
When the PCRF explicitly disables Usage-Monitoring on the 7x50, the 7x50 will report 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 7x50 sends new CCR-U and the Event-Trigger AVP set to "USAGE_REPORT" to report accumulated usage for the disabled Usage-Monitoring entities.
 
Usage-Monitoring for PCC Rules
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 will be rejected if the same monitoring-key is used for ingress and egress.
 
Session Termination
At IP-CAN session termination the 7x50 sends the accumulated usage information for all entities for which Usage-Monitoring is enabled in the CCR-t.
 
Usage-Monitoring Examples
For the description of the specific AVP, refer to the 7750 SR OS Gx AVPs Reference Guide.
IP-CAN session Usage-Monitoring
PCRF in RAR sends the following AVPs (among all the other mandatory ones: session-id, etc.)
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 7x50 reports usage when the thresholds are reached some time later in CCR-U. The usage is monitored inetrnally on the 7x50 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   
                        
PCRF instructs 7x50 to continue Usage-Monitoring with the new thresholds in 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 will send the following AVPs in the RAR message (among all the other mandatory ones: session-id, etc.)
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 7x50 reports usage when the thresholds are reached some time later in 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 7x50 to continue Usage-Monitoring with the new thresholds in 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)
 
 
Event Triggers
PCRF may subscribe to an event trigger in the 7x50. The PCRF subscribes to new event triggers or remove armed event triggers unsolicited at any time. When an event matching the event trigger occurs, the 7x50 reports the occurred event to the PCRF. The event triggers that are required in procedures will be unconditionally reported (for example IP address allocation/de-allocation) from the 7x50, while the PCRF may subscribe to the remaining events (for example Usage-Monitoring).
When sent from the PCRF to the 7x50, the Event Trigger AVP indicates an Event that will trigger an action in 7x50. When sent from the 7x50 to the PCRF, the Event Trigger AVP indicates that the corresponding event has occurred. If no Event Trigger AVP is included in a CCA or RAR operation, any previously provisioned event trigger will be still applicable.
The PCRF may remove all previously provided event triggers by providing the Event-Trigger AVP set to the value NO_EVENT_TRIGGERS. When an Event-Trigger AVP is provided with this value, no other Event-Trigger AVP will be provided in the CCA or RAR command. Upon reception of an Event-Trigger AVP with this value, the 7x50 will not inform PCRF of any event except for those events that are always reported and do not require provisioning from the PCRF.
When the PCRF subscribes to one or more event triggers by using the RAR command, 7x50 will send the corresponding currently applicable values to the PCRF in the RAA if available, and in this case, the Event-Trigger AVPs will NOT be included.
For a list of the supported events in the 7x50, refer to the 7750 SR OS Gx AVPs Reference Guide.
 
Subscriber Verification
At any time, the PCRF can query 7x50 for the presence of the subscriber-host via a RAR message.
The 7x50 will respond with the following result-codes in RAA:
 
Subscriber Termination
The PCRF can request IP-CAN session termination in the 7x50 via two messages:
Upon the arrival of either of those messages, the 7x50 will start the IP-CAN session termination procedure (CCR-t with corresponding Termination-Cause AVP will be sent to the PCRF). This is described in the 3GPP 29.212 document, §4.5.9.
For a list of the supported Termination-Cause AVP values in the 7x50, refer to the 7750 SR OS Gx AVPs Reference Guide.
 
Mobility Support in WiFi
When a WiFi subscriber moves between the access points (APs), a CCR-u message is triggered on the 7x50, carrying the Called-Station-Id AVP. The Called-Station-Id AVP carries the MAC IP address of the new AP. This functionality allows the PCRF to make location based policy decision.
This functionality is enabled via event trigger USER_LOCATION_CHANGE (13) [3GPP 29.212, §5.3.7] sent to 7x50 by PCRF in CCA or RAR message.
The same event will be reported back from 7x50 to the PCRF in CCR-u message when the user location changes.
 
Redundancy
Redundancy in Gx relies on the Diameter redundancy mechanisms described in the Diameter Redundancy .
 
Persistency and Origin-State-ID AVP (RFC 6733, §8.6 and §8.16).
Persistency (saving the state of IPoE hosts on the compact flash) for Gx sessions is not supported. This means that upon the reboot, the 7750 will restore the subscriber-hosts from the persistency but the Gx session awareness for the recovered hosts is lost. Any previously applied qos or filter overrides will be lost. However, subscriber-strings (subscriber-id, sub-profile, sla-profile, aa-profile) can be made persistent and can be preserved across reboots.
The Origin-State-Id (OSI) AVP is NOT stored in persistency. In case that the 7x50 reboots, the Origin-State-ID AVP is set to boot time (UTC).
The Origin-State-Id AVP is contained in the CER messages and application messages that are sent from 7x50 to the PCRF/DRA. In the other direction, (sent by PCRF to 7x50) the OSI is ignored.
To restore lost session after the reboot, 7x50 will initiate CCR-i message for every host that is recovered from persistency. The CCR-i will contain the new session-id and origin-state-id. Based on this CCR-i, it is expected that the PCRF returns the most current policy for the host.
 
Overload Protection
7x50 has a receiving queue per Gx application (ESM, UM, AA). Each queue can hold 10K messages. While the queue is in the overloaded state, 7x50 replies to every new RAR message with the RAA message that contains the Result-Code AVP set to DIAMETER_TOO_BUSY (3004) value. This can be considered as explicit signaling towards the PCRF notifying it of the condition on the 7x50.
In case that the messages in the overwhelmed 7x50 queue do not require sending an answer (in case that the overwhelmed queue contains CCA-i/u messages), the TCP window will fill up, TCP ACKs will not be sent and consequently this will be an implicit notification to the PCRF to slow down.
If 7x50 receives a response from an overloaded PCRF (Result-Code = DIAMETER_TOO_ BUSY), the 7x50 will timeout (tx-timer) the originally sent message. Once the message is timed out, the configuration settings (on-failure) will determine whether to trigger the peer-failover procedure or not (Peer-failover based on DIAMETER_TOO_BUSY Result-Code is recommended in RFC6733, §7.1.3.
 
Diameter NASREQ Application
The Diameter NASREQ application is used for Authentication, Authorization, and Accounting services in the Network Access Server (NAS) environment. SR OS supports a stateless operation of NASREQ authentication and authorization, interacting with a NASREQ server that does not maintain session state.
Subscriber host or session authentication results in an AA-Request (AAR) message being sent to the Diameter NASREQ server. An Auth-Session-State AVP with value equal to 1 (No State Maintained) is included in the AAR to inform the server of the stateless mode. The server responds with an AA-Answer (AAA) message and must include the Auth-Session-State AVP with value equal to 1 (No State Maintained), together with the authorization AVPs.
Diameter NASREQ accounting is not supported.
Table 30 lists the supported Diameter NASREQ messages. Vendor-specific AVP's are shown as: v-<vendor-id>-<AVP id>.
Diameter NASREQ authentication is supported for IPoE hosts and sessions, PPPoE PTA PAP/CHAP authentication. Diameter NASREQ authentication is not supported for L2TP LAC/LNS.
NASREQ and RADIUS authentication cannot be configured simultaneously on a capture-sap, local-user-database, or group-interface. They have the same priority in the hierarchy of different sources (such as local user database, Gx, defaults, etc.) for obtaining the subscriber host or session authorization parameters.
Multi-chassis redundancy is supported via separate Diameter NASREQ peers on each redundant node. Each node of the multi-chassis redundancy pair has its own Diameter Identity (origin host/realm). The subscriber host or session is authenticated on the BNG where it is initially connected. Due to the stateless operation, there is no need to synchronize NASREQ session state. Alternatively, the Diameter proxy can be used if it is required to have a single Diameter Identity (origin host/realm) per pair of multi-chassis redundant nodes.
There is no NASREQ re-authentication for active subscriber hosts or sessions, except for a forced re-authentication when the circuit ID/interface ID or remote ID of a DHCP host is changed.
Stateless NASREQ authentication can be complemented with Diameter Gx policy management for policy control and mid-session changes. Diameter NASREQ and Gx applications are supported simultaneously on a single Diameter peer.
Figure 185 shows a sample call flow for a subscriber using Diameter NASREQ for authentication and Diameter Gx for policy management.
Figure 185: Sample Diameter NASREQ Call Flow
Table 31 lists the authorization AVPs that are accepted in a Diameter NASREQ AA-Answer message. Vendor-specific AVPs are shown in the table as: v-<vendor-id>-<AVP-id>.
 
Sample Configuration Steps
To specify the peers to reach the Diameter NASREQ server in a diameter peer policy:
configure
    aaa
        diameter-peer-policy "diameter-peer-policy-1" create
            description "Diameter NASREQ peer policy"
            applications nasreq
            origin-host "bng@alcatel-lucent.com"
            origin-realm "alcatel-lucent.com"
            peer "peer-1" create
                address 172.16.3.1
                destination-realm "myDSCRealm.com"
                no shutdown
            exit
        exit
 
To specify the Diameter NASREQ application specific parameters, such as AVP format and values, in a Diameter application policy:
configure
    subscriber-mgmt
        diameter-application-policy "diameter-nasreq-policy-1" create
            description "Diameter NASREQ application policy"
            application nasreq
            diameter-peer-policy "diameter-peer-policy-1"
            nasreq
                user-name-format mac
                include-avp
                    circuit-id
                    nas-port-id
                    nas-port-type
                    remote-id
                exit
            exit
        exit
 
To apply the Diameter NASREQ application policy as Diameter authentication policy at a VPLS capture SAP, at an IES/VPRN group-interface and/or at a local user database:
(Note: A Diameter authentication policy cannot be configured simultaneously with a RADIUS authentication policy on the same group-interface or capture SAP, nor for the same host in a local user database.)
configure
    service
        vpls 10 customer 1 create
            sap 1/1/4:*.* capture-sap create
                ---snip---
                diameter-auth-policy "diameter-nasreq-policy-1"
        ies 1000 customer 1 create
            subscriber-interface "sub-int-1" create
                ---snip---
                group-interface "group-int-1-1" create
                ---snip---
                    diameter-auth-policy "diameter-nasreq-policy-1"
        vprn 2000 customer 1 create
            subscriber-interface "sub-int-1" create
                ---snip---
                group-interface "group-int-1-1" create
                ---snip---
                    diameter-auth-policy "diameter-nasreq-policy-1"
 
configure
    subscriber-mgmt
        local-user-db "ludb-1" create
            ipoe
                host "ipoe-host-1" create
                    ---snip---
                    diameter-auth-policy "diameter-nasreq-policy-1"
            ppp
                host "ppp-host-1" create
                    diameter-auth-policy "diameter-nasreq-policy-1"
 
If no AA-Answer message is received from the primary or secondary Diameter peer, then the host or session can be instantiated with the configured defaults. This is achieved by the following NASREQ application policy configuration:
configure
    subscriber-mgmt
        diameter-application-policy "diameter-nasreq-policy-1" create
            on-failure failover enabled handling continue
 
To enable flexible integration with different NASREQ servers, a Python policy can be configured on the Diameter peer policy. The Python script can interact on the AVPs present in the AA-Request and AA-Answer messages.
configure
    python
        python-policy "py-policy-nasreq-1" create
            diameter aar direction egress script "NasreqAar"
            diameter aaa direction ingress script "NasreqAaa"
configure
    aaa
        diameter-peer-policy "diameter-peer-policy-1" create
            ---snip---
            python-policy "py-policy-nasreq-1"
 
Diameter Redundancy
Diameter redundancy is supported on multiple levels:
Diameter Peer Level Redundancy: A Diameter client in 7x50 supports up to five open peers, two of which (primary and secondary) can actively participate in Diameter transactions. The purpose of the secondary peer is to protect the primary peer, should the primary peer experience problems.
Diameter Multi-Chassis Redundancy: Diameter sessions are synchronized on the application level (via ESM in case of Gx and NASREQ) between two redundant 7x50 nodes. Only one of the 7750 SRs opens up a peering connection on behalf of the redundant 7750 SR pair towards DRA/PCRF.
High Availability (HA): This refers to control plane redundancy with dual Control Plane Modules (CPMs) in a single chassis configuration. Diameter transactions are fully synchronized between CPMs and the peering connection towards DRA/PCRF remains uninterrupted in case that one of the control plane modules fails.
 
Diameter Peer Level Redundancy
Once the peer in the Diameter policy (maximum five peers per policy) is administratively enabled (no-shutdown), the 7x50 starts connecting to it. If the establishment of the TCP connection fails, the 7x50 periodically retries to connect.
If creation of the TCP connection succeeds, the peer is placed in the peer table, and in that table the “preference” defines the current usability of the peers. All administratively enabled peers that are in the open state have keepalives (DWR/DWA) enabled to check the liveliness of the connection, but only the two open peers with the highest preference are considered as primary and secondary. In this fashion, the application messages (for example, DCCA or Gx) are sent only to the primary and/or the secondary peer.
Initially all messages are sent to the primary peer. If a session-failover occurs (timeout or primary peer closes), the messages are sent to the secondary peer (which could have become primary by that time). Once an (application) session has switched, the consecutive messages are sent to the peer where it had its last success request/answer (it sticks to the peer).
The status of primary and secondary peer is constantly re-evaluated, in case an error condition occurs at the primary or secondary peer.
The following example shows how DCCA messages are treated:
1.
2.
All ten sessions start requesting credit updates (CCR-u), but only six of them are successfully completed (CCR-u/CCA-u) by the peer-a. Their preferred peer will remain peer-a. Then, the connection to the peer-a fails (connection is closed). Peer-b becomes the primary, peer-c becomes the secondary. The remaining four CCR-u sessions that were pending will now be redirected to the peer-b with the retransmission bit (T) set in the diameter header. When these four outstanding transactions successfully complete (CCA-u received), they will have the peer-b as the preferred peer.
3.
4.
In case that peer-a did not become alive in time, peer-c would be used for re-transmissions. At some point later, when peer-a and peer-b become the primary and the secondary peers again, those sessions with the preferred peer-c will be redirected back to peer-a (as we only use peer-a and peer-b to send application messages).
So in essence, a revertive mode is used for the peer recovery, where the sessions are reverted back to the peer on which the session was originally setup, as long as this peer is one of the two active peers (primary and secondary).
 
Diameter Multi-Chassis Redundancy
The Diameter Multi-Chassis Redundancy solution in the 7750 SR is based on the model where communication with the PCRF/DRA occurs over a single Diameter peering connection for the redundant pair of 7750 SR nodes; that is, an active Diameter proxy module running on the
7750 SR is front‑ending the communication with the PCRF/DRA, and is relaying messages between the Diameter clients (in redundant 7750 SRs) and the DRA/PCRF. Both 7750 SR nodes run Diameter proxy module, but only the active one opens the TCP peering connection towards the DRA/PCRF.
The benefits of the Diameter proxy model are:
The goal of this redundancy model is to provide a predictable and quick recovery after a 7750 SR nodal failure, PCRF failure, or relevant components within those two entities (such as line cards, MDAs, and physical ports).
Figure 186 illustrates the basic concept for Diameter Multi-Chassis Redundancy for a Gx application. The model shows two 7750 SRs (BNGs). Each BNG contains an ESM module and a Gx/Diameter module which have a peering connection to the active Diameter proxy module. The peering connections are IP connections. Both nodes communicate with the PCRF/DRA through the active Diameter proxy which maintains a peering connection with the PCRF/DRA.
Figure 186: Proxy Gx Model
Diameter Proxy Model General Operational Principles
The fundamental principles of the Diameter proxy-based redundant solution are described below (also refer to Figure 186):
1.
2.
Application level information (Gx session, NASREQ session, etc.) is not synchronized between Diameter proxies. Instead, synchronization of session level information is performed on the application level; for example, Gx session information is performed through subscriber management (ESM) synchronization.
3.
4.
5.
6.
7.
The Diameter client will retransmit when:
8.
9.
If the T-bit is set in the message coming from the client side, the Diameter proxy sends the message to the secondary peer (invokes the peer failover procedure). That is, the application level retransmissions is performed by the Diameter client (which is peering with the Diameter proxy). The client sets the T-bit (retransmission bit) in the Diameter header and this signals to the Diameter proxy that it needs to failover the message to the alternate peer. This operation is performed on a per message basis and not on a per session basis.
The Diameter proxy initiates a failover procedure to the secondary peer when the primary peer on Diameter proxy is closed, or the watchdog timer on the primary peer expires.
All messages in the DRA/PCRF-to client direction with the E-bit set (the E-bit can be present only in answer messages) are dropped in the proxy. Consequently, the client retransmits the request, upon timeout.
The messages with the E-bit set that are traveling in the opposite direction are not dropped; they are transparently passed to the DRA/PCRF.
10.
11.
12.
 
Diameter Proxy Activity Selection
The Diameter proxy with the highest system MAC address assumes the controller role. The controller node decides which proxy becomes ACTIVE or STANDBY. Activity election information is processed by the controller node and then the controller node delegates the actual ACTIVE/STANDBY roles to Diameter proxies. The ACTIVE proxy may not necessarily be the same node as the controller node.
The activity selection (by the controller node) in the Diameter proxy is based on the current states of both Diameter Proxies (local and remote) and the system MAC.
Preemption is not supported, which means that newly brought up Diameter proxy does not overtake the activity state from the existing active Diameter proxy, regardless of the system MAC addresses.
Once the node becomes active, it advertises the new state to the MCS Diameter proxy peer and tries to open a DRA/PCRF peering connections and at the same time accept the client connections. The active Diameter proxy replies to the client with a DIAMETER_UNABLE_TO_DELIVER error-code in cases where server side peers cannot be opened.
 
Synchronization and MCS
All application level (Gx or NASREQ) sessions related parameters are synchronized on the ESM level via MCS.
The parameters synchronized on the ESM level are:
The Diameter proxy module is synchronized via MCS; the information passed between the two nodes is:
The above information is used to determine the activity of the Diameter proxy at each node.
In the case where an MCS link fails, the nodes become isolated. Each node acts independently and tries to become active. This scenario is described in Isolated Chassis .
 
Retransmissions
The handling of Diameter retransmissions is crucial for the Diameter Multi-Chassis Redundancy operation. Retransmissions provide the means to recover a Diameter session that was left in an unacknowledged state due to failure of the path between the 7750 SR and the DRA/PCRF.
Retransmissions of Diameter messages are handled on two levels by a pair of redundant 7750 SR nodes:
1.
2.
A more detailed explanation of the processing that occurs on each level for a Gx application is given below.
1.
2.
Since the Diameter proxy only relays the messages between the client and the DRA/PCRF, it never buffers and retransmits the Diameter message. Retransmissions are the responsibility of the Diameter peer (Diameter client) that sits behind the Diameter proxy. Retransmitting Diameter client sets the T-bit in the Diameter header of the retransmitted message
(CC-req-num is kept the same in the original and retransmitted message). The T-bit in the message triggers the Diameter proxy to re-route the messages to the secondary peer while the primary peer is still active. This means that the Gx client has already retransmitted the message, and the Diameter proxy re-route its.
In case of a single peer, the Diameter client retransmits the message to the same peer and it sets the T-bit in the Diameter header.
In case of a single peer, the Diameter proxy sends the message with the T-bit set to the same peer.
The Gx client typically re-routes the message to the secondary peer in the following cases:
The Diameter message times out due to a received answer with E-bit set in the Diameter header (E-bit can be only set in the answer messages and it indicates protocol errors with Result-Code from the 3xxx range). Once the reply with E-bit set is received, the corresponding request message is left on the pending queue where it times out after the interval controlled by the tx-timer statement in the
diameter-application-policy. Upon message timeout, the 7750 SR retransmits the message to the secondary peer if the secondary peer is available. If not, the message will is retransmitted to the same (primary) peer.
In summary:
These scenarios are shown in Figure 187, Figure 188, and Figure 189.
Figure 187: Retransmissions with Two Peers and no Diameter Proxy
Figure 188: Retransmissions with a Single Peer and no Diameter Proxy
Figure 189: Redirection with Diameter Proxy (T-bit set)
Retransmissions and the T-bit
Multi-chassis redundancy is less concerned with the retransmissions of the answer messages (RAA) since, if the answer is not received, the PCRF retransmits the request (RAR). Retransmission of the answer messages is performed only on the TCP level within a single
7750 SR node. It is not performed on the Diameter level.
When the request message is retransmitted by the Diameter application (due to the Tx timer timeout, primary peer failure - DWR timeout, or receipt of the answer message with E-bit set), the content of the message stays the same, including the CC-Request numbers but the T-bit in the Diameter header is set. The T-bit indicates to the PCRF that the message is retransmitted (mostly used for accounting purposes so that the counting records are not duplicated). It also signals to the Diameter proxy that the message rerouting to the secondary peer should be performed.
 
Diameter Proxy Role
The Diameter proxy is applied to an IPv4 address within a routing-context on a 7750 SR. This IPv4 address is a Diameter proxy listening IPv4 address that is associated with an interface on a 7750 SR, including the system interface (system IPv4 address), or loopback interface (loopback IPv4 address).
The number of Diameter Proxies per listening IPv4 address is limited to one. That is, each proxy diameter-peer-policy requires a unique combination of source-ipv4 (listening IPv4 address) and the routing-context (router).
The number of Diameter-peer-policies on a 7750 SR is limited to 32. This means that the combined number of Diameter clients and Proxies on a 7750 SR cannot exceed 32.
The Diameter Proxy has the following role on a 7750 SR:
1.
2.
3.
4.
5.
6.
7.
8.
Table 32 summarizes the differences between the regular Diameter client and the Diameter proxy.
 
Diameter Proxy and CC-Request-Number AVP
CC-Request-Number AVP (RFC 4006, 8.2) are typically used to match requests with answers. Session-id and CC-Req-Num are a unique per-message pair. CC Request Numbers along with the session-id uniquely identify a transaction (matching requests and answer messages) on a global level.
The Diameter proxy does not re-write the CC-Request-Number in the messages received by the client.
CC-Req-numbers are synchronized at the ESM level. This is needed so that operation with proper CC-Req-Num can resume after the switchover.
For example, the following CC-Req-Num sequence for the session is preserved across SRRP switch-overs:
 
Stateless Diameter Proxy
The Diameter proxy does not maintain any session state. Forwarding is based on transactions which are short lived. Transactions are based on a pairing request/answer messages matched by the same hop-by-hop identifier and the peer from which the request was received. In this fashion, answer messages coming from the DRA/PCRF can be unambiguously forwarded to the proper Diameter client (from which the request was received).
Since the session state is not kept in Diameter proxy, RAR request are be flooded to both Diameter clients. The Diameter client on the standby SRRP node will silently drop such RAR requests and only the master SRRP will r
Switchover Scenarios
The following are four types of switchovers that are most likely to occur:
1.
2.
3.
4.
Each switchover type for a Gx application is discussed in more detail below:
1.
The Diameter proxy switches over to the new peer in the event of two cases:
Retransmission due to the message timeout is performed at the Diameter client level, and setting the T-bit signals to the Diameter proxy that peer failover is needed for this particular message.
Figure 190: PCRF/DRA Peer Switchover
2.
This type of switchover (without the node failure) is unlikely to occur. For example, a Diameter proxy switchover (without the node failure) would mean that all PCRFs/DRAs have failed, since normally the same pair of PCRF/DRA peers are configured in both Diameter proxy nodes. This would mean that all DRA/PCRFs are unavailable, which indicates a problem on the network side (either network paths to DRA/PCRFs are broken or all DRA/PCRFs have crashed).
Another example where this scenario could occur is poor redundancy design practices. For example, the active Diameter proxy has a single peering connection to one PCRF (no secondary peer), while the standby Diameter proxy is configured with a separate PCRF peer (the two PCRFs are still synch’d). This scenario is shown in Figure 191.
Figure 191: Diameter Proxy Switchover
As always, only the active Diameter proxy maintains an open TCP peering connection towards the PCRF/DRA. If this connection fails, the active proxy sends a TCP RST towards the client and transitions into standby state. The client then, upon expiry of connection-timer, open a new TCP connection towards the newly active Diameter proxy.
3.
Figure 192: Node Failure
4.
Log/Trap Generation Caused by Diameter Proxy State Change
In cases where the Diameter proxy changes its states (INIT, ACTIVE, STANDBY), a log/trap is generated. This log is enabled by default in log-event control. The notification name is tmnxDiamProxyStateChange.
 
Switchover Update Event (CCR-u)
The AN-GW-Address carried in the CCR-I message for the Diameter application session (for example, Gx) is the IP address of the node on which the underlying SRRP instance (for this Gx session) is in the SRRP master state.
When the SRRP switches over due to the failure in the access part of the network (including the ports on a 7750 SR), a CCR-U can be optionally (configuration dependent) sent with the
AN-GW-Address AVP of the node on which an SRRP instance transitioned into the master state.
This behavior is controlled via the event trigger id 13 (USER_LOCATION_CHANGE).
 
Isolated Chassis
In cases where the MCS connection is broken, the Diameter proxy on both 7750 SR nodes try to become active since they each consider that they are the only functional node. From the local point of view, the MCS peer is dead.
While in isolation scenario, both nodes are most likely able to open the TCP peering session with the PCRF/DRA (see Figure 193).
Figure 193: Isolated Nodes
Once the MCS is recovered, the states are re-synchronized.
 
Diameter Identities
Diameter identities (origin-host/realm) can be configured to be the same on both 7750 SR nodes. This ensures that the redundant pair of 7750 SRs appears as a single node at the Diameter level (Diameter Identities).
High Availability
A CPM switchover on the active Diameter proxy causes the peering connections between the client and the proxy to be lost. Consequently, the clients have to re-establish their peering connections. Peering connections on the active Diameter proxy towards the server remain uninterrupted.
 
Gx Specific Behavior
Gx specific behavior in a multi-chassis configuration is as follows:
1.
2.
3.
4.
5.
 
 
 

1
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.

2
Policy is in this context defined as a collection of static and dynamic rules.

3
Note the difference between ordering of the entries with the rules, and the ordering of the rules themselves.

4
Dynamic policers are instantiated due to rate-limiting or usage-monitoring action in PCC rules.