Policies

The rXg policy enforcement engine is configured via three classes of objects: group records, enforcement records and policy records. Group records (e.g, account groups , MAC groups , LDAP groups , etc.) identify and classify end-users and devices into roles. Enforcement records (e.g., splash portals , application forwards , bandwidth queues ) define and configure behaviors that are to be applied to some or all end-users and devices managed by the rXg. Policy records associate the group records to the enforcement records and define who receives what treatment.

Policies link groups that identify end-users and devices with the enforcement capabilities of the rXg. In the example configuration depicted above, the groups are in the left column and the enforcement records are in the right column. The policies are in the center column and link the groups to the enforcement records. It is these links that define the network experience of the end-user.

If you are familiar with SQL and relational database management systems, then you may recognize the organization of the identity :: group :: policy :: enforcement mechanism. From a DBMS / ERD perspective, the policies should be thought of as rows in a join table that has columns to hold the foreign keys for tables that define kind of group and enforcement configuration.

The network experience for each end-user is determined by the policy. Each and every end-user is identified through one or more mechanisms (e.g., portal credentials, IP address, MAC address, etc.) and assigned to one or more groups. The effective group for a given end-user is resolved through the priority field present in all group objects. The rXg will apply the enforcement capabilities that are connected by the policy that is associated with the effective group.

The identity :: group :: policy :: enforcement mechanism is the method by which all network experience related features are delivered to the end-user. This mechanism determines everything including but not limited to the portal (which one is presented, what usage plans may be selected, etc.), the advertising experience (interstitial and injection), traffic shaping (rate limits and guarantees) and much more.

Consider the following example simple network configuration in conjunction with the policy shown above:

Assume that an end-user opens a laptop and connects to a wireless access point that is bridged into the switch on the LAN side of the rXg. The rXg serves the laptop a DHCP address of 192.168.5.254. Since the rXg is not aware of any identity for the end-user other than the IP address which falls into the IP group called_LAN IPs_, the end-user experiences the splash portal that is associated with the pre-auth policy.

Now let us say that the end-user navigates the splash portal, signs up for an account, selects and then purchases a usage plan. Let us also say that the usage plan that the end-user purchases is linked to the Hotspot group. The end-user now has two independent identities on the rXg (IP 192.168.5.254 and their user account). The IP places the end-user into the IP group called LAN IPs and the account places the end-user into the account group called hotspot.

When a single identity is present in more than one group, the group priority is used to disambiguate the membership. This concept is discussed in more detail in the identities portion of the operator's manual. Notice that the hotspot account group has a priority of 3 while the LAN IPs IP group has a priority of 2. Thus the end-user will now experience the enforcement options associated with the policy named hotspot.

To expand on this example and concept, let us assume that the operator has decided enable Internet access for the smartphones that technicians and administrators carry with them. The flexible nature of the rXg enables the operator to choose amongst many ways that this could be accomplished. Let us assume that the operator wishes to use a MAC address access control list as the authentication mechanisms for the smartphone fleet.

Notice that the Admin SmartPhones MAC group is associated with the T1 policy. Also notice that the priority of the Admin SmartPhones MAC group is 5. When a field technician or system administrator uses the Wi-Fi capability of their smartphone to connect an access point bridged to the LAN side of the rXg, they are issued a DHCP address in the 192.168.5.0/24 block. This makes the smartphone a member of the LAN IPs IP group. Since the priority of the_LAN IPs_ IP group is 2 and the priority of the_Admin SmartPhones_ MAC group is 5, the effective group is the Admin SmartPhones MAC group. Thus the smartphones experience the T1 policy that assigns a 1544 kbps symmetric amount of bandwidth without any forced browser redirection.

Now let us expand on this example. Consider an expanded as depicted by the network diagram shown below. In this example RGN, the operator has setup VLANs that are bridged to geospatially distinct locations.

End-users that connect to access points deployed at a local hotel are bridged into VLAN 2801. Similarly end-users that connect to access points deployed at a local gated community are bridged into VLAN 2808. Thus end-users that are at the hotel are assigned addresses in the 10.0.10.0/24 CIDR and end-users that are at the gated community are assigned addresses in the 172.16.16.0/24 CIDR.

The operator wishes to display distinct captive portals to the end-users at the hotel and the gated community. To accomplish this, two new policy objects are created along with two new splash portal objects. The actual captive portal that is displayed to each end-user is determined by the fields in the splash portal object. Several other aspects of the captive portal (e.g., which usage plans are displayed on the portal) are also determined by the configuration fields in the splash portal object.

In addition, IP group objects that contain the CIDRs for each geospatial location are created so that the non-authenticated end-users are associated with the appropriate policy that displays the desired captive portal. Following the network diagram depicted previously, the appalachian hotel IP group would need to have an IP CIDR member of 10.0.10.0/24 and the black creek sanctuary IP group would have an IP CIDR member of 172.16.16.0/24.

Policies Dashboard

The policies dashboard presents an overview of the current status and configured settings of the rXg policy enforcement engine.

At the top of the policies dashboard is a node-edge graph that depicts the current configured state of the rXg policy enforcement engine.

Groups are presented in a single column on the left. Enforcement records are presented in a single column on the right. Policy objects link groups and enforcement records and are in the middle of the group.

A graph that is isolated to a single policy may be generated by clicking on a policy or group object in the graph.

In addition, the operator may enter an identity (IP address, MAC address, username, token, etc...) into the search field at the top right of the dashboard. The result is an isolate graph (similar to the one shown above) of the groups, policies and enforcement records that are related to the data that is entered. This mechanism is useful for troubleshooting the operation of an rXg. The vast majority of perceived enforcement errors are a result of incorrect configuration that results in the application of a policy other than what is desired.

The views for each policy enforcement feature include a subset of the policies scaffold with the fields that are relevant to each specific enforcement capability. In this scaffold, all of the available enforcement features are presented. This enables the operator to quickly reconfigure what enforcement capabilities are linked to a policy.

At the very bottom of the policy dashboard are graphs that displays the number of sessions and the amount of data transferred for each policy over the course of the past 24 hours.