BQN Docs

Configured Policies

Locally configured policies are selected using rules that combine profiles with policies:

• Profiles classify the traffic according to some criteria (for example, an access profile identifies all the traffic from subscribers within a set of IP address ranges).
• Rules relate policies and profiles. For example, a rule may specify that some specific access profile is limited by a rate policy, i.e., that subscribers whose IP address are in some subnet will have a specific rate limit.

‍

Profiles

Profiles classify the traffic, and, when used by policy rules, determine the policy applied to a subscriber or a flow. There are different profile types, according to the properties being used for traffic classification. The current version supports the following profile types:

• Interface Profile: identifies the flows or subscribers whose first data packet comes in through a network interface in the profile.
• VLAN Profile: identifies the flows or subscribers whose first data packet uses a VLAN tag within the set of VLAN tags (or the absence of any tag) of the profile.
• ‍Policy Rate Profile: identifies the name of the subscriber rate policy. The profile may contain patterns with wildcards. For example, a policy rate profile containing pattern “premium-*” will match subscriber traffic with rate policies named “premium-gold” and “premium-platinum”.
• Internet Profile:  identifies the traffic involving IP addresses, ports or L4 protocols on the Internet side.
• Access Profile: identifies the traffic involving IP addresses, ports or L4 protocols on the Access side.
• Subscriber group Profile: identifies the name of the subscriber group. The profile may contain patterns with wildcards. For example, a subscriber group name containing pattern “wireless*" will match subscriber traffic with rate policies named “wireless-north" and“wireless-south".

• Subscriber ID Profile: identifies the subscriberID. The profile may contain patterns with wildcards. For example, a subscriber ID  pattern “100" will match subscriber traffic with IDs “100123" and“100435".
• ‍Time Profile: defines time ranges. Optionally, ranges can be restricted to only some days of the week.
• Throughput Profile: identifies all the flows which were created while the total downlink traffic through the BQN was above the threshold specified by the profile.
• ‍DPI (Deep Packet Inspection) Profile: identifies the flows that have a DPI domain that matches one of the domain patterns (signatures) of the profile. There are a set of pre-defined DPI signatures, which include the signatures of popular applications (like the most important video-streaming apps or the most common software updates). See at the end of this section how to add custom signatures.

Profiles are configured in the menu option Configuration->Profiles.

‍

Interface Profile

An interface profile contains a list of network interfaces part of a data wire. It is true if the first packet is received by one of the interfaces of the profile. A network interface can only be part of one profile at the same time.

In the following example, a profile is defined for one of the two wires of the BQN server and another profile for a second wire:

‍

VLAN Profile

A VLAN profile is a list of VLAN tags. The profile is true if the traffic has any of the VLAN tags defined by the profile.

The following example defines two profiles for two network areas and a third profile for traffic without VLAN tag.

‍

Policy Rate Profile

This profile is used to select the Flow Policies based on the Rate Policy of the subscriber. It is a list of Subscriber Rate Policy names, or patterns with wildcards. Examples:

Internet and Access Profiles

Internet profiles check some traffic properties of the end points on the Internet side (content servers). Access profiles do the same for the end points on the access side (subscribers). The possible traffic properties are:

• IP addresses.
• IP address ranges.
• Layer 4 protocol number (e.g. ICMP, TCP, UDP,OSPF, etc.).
• Port numbers (for TCP and UDP protocols).

The following is an example of an access profile containing all private IP v4 ranges:

‍

To add an entry, click on Add Entry… menu option on the upper right. The following is one IP address entry, matching any protocol:

Some Internet profile examples follow:

The profile my-voip includes the IP range of a VoIP service that uses TCP and UDP ports 5001 and 5002.

The profile pings will match ICMP traffic to any IPv4or IPv6 destination (0.0.0.0/0 matches any IPv4 address and ::/0 any IPv6 address).

The profile web matches any IPv4 or IPv6 traffic to TCP ports 80, 8080 and 443.

To add an entry, click on Add Entry… menu option on the upper right.

And an entry matching any IPv4 traffic to TCP port 80:

It is possible to load an IP address list from a text file. The text file format has one IP address or address range per line. To load a file, edit the profile and select, in the upper right menu, the option Replace Using File… (the profile mirrors the file address list) or the option Merge Using File… (the content of the file is added to the profile existing addresses).

‍

Subscriber Group Profile

This profile is used to select Flow, Rate or Monitor Policies based on the group of the subscriber. It is a list of Subscriber Group names, or patterns with wildcards. Examples:

Subscriber ID Profile

This profile is used to select low, Rate or Monitor Policies based on the ID of the subscriber. It is a list of Subscriber IDs, or patterns with wildcards. Examples:

‍

Time Profiles

Activates the rule during a period. A time profile is a list of time ranges, and it is true if any of the ranges is true. Ranges within the same profile cannot overlap.

A range can apply to all days of the week or just to certain days.

The following example shows:

• A rush hour profile at the end of any day (note how we define the 20:00 – 1:00 interval as two separate periods).
• A weekend profile during Saturday and Sundays.
• A time profile for working hours, with two ranges, valid only from Monday to Friday

‍

Throughput Profiles

A throughput profile defines a threshold of the total downlink traffic through the BQN. It is true when the throughput is exceeded. The following example defines a threshold of 9 Gbps.

‍

DPI Profiles

A DPI profile is a collection of signatures to identify in the information obtained through deep-packet-inspection. The signatures can have different types depending on the DPI information:

• HTTP-Host: the hostname in HTTP traffic
• HTTPS-SNI: the Service-Name-Indication in HTTPS traffic.
• QUIC-SNI: the Service-Name-Indication in QUIC traffic.
• QUIC-MVFST:  presence of MVFST traffic (a QUIC variant).
• P2P-FILESHARING: presence of P2P traffic (BitTorrent).
• SPEEDTEST-OOKLA: presence of Speedtest traffic.

Signatures of the type HTTP-Host, HTTPS-SNI and QUIC-SNI must have a pattern indicating the expected content of the DPI information. Patterns can contain up to two wildchars. Examples: “prefix*”, “*suffix”, “*substring*”.

A set of pre-defined signatures can be loaded to the DPI profile selecting in the menu Add Predefined Signatures…

‍Some of the predefine sets are:

• Video streaming: YouTube, Netflix, Facebook,Instagram, Amazon Video, HBO, Hulu, Apple TV, Disney+, Twitch, Tiktok, PeacockTV, Pluto TV, Roku, Filmin, DAZN, Magis, Perseo
• Software downloads: MS windows, Mac OS andAndroid updates, PlayStation, Xbox and Steam downloads.
• Speed tests: Ookla, fast.com, cloudflare,waveform, m-lab, nperf

A DPI profile can be filled with custom signatures using the option Add Custom Signature….

Custom signatures can be loaded from a file using the option Add Signature File… A signature file is a text file with one line per signature, with the following format:

<pattern> <pattern-type>

where:

• <pattern> is a domain with wildcards (example: *domain-one.com)
• <pattern-type> is one of the following values: HTTPS-SNI, HTTP-host, QUIC-SNI

For example:

*domain-one.com HTTPS-SNI

*domain-one.com HTTP-host

prefix*domain-two.com HTTPS-SNI

‍

Subscriber Identification

‍

Policy control is enforced per access IP address

The BQN enforces policies on subscriber sessions. A subscriber session is all traffic of a distinctive IP address on the access side: one single IPv4 address or one IPv6 subnet. For example, a policy with rate limits will apply those limits to the total throughput of that distinctive IP address.

If there is a NAT between the BQN server and the real subscribers, subscribers whose IP addresses are translated to the same IP address would be considered as the same subscriber.

The default IPv6 subnet is /64 (to change it, go to Administration->General Settings and edit the field IPv6 prefix for subscribers).

A new subscriber session is identified when the first packet from an access IP address is received. This is when the subscriber rate and monitoring rules are evaluated, to choose which policies to apply.

‍

Subscriber ID

To facilitate the identification of a subscriber session, a subscriber ID field is supported. The subscriber ID can be used when requesting metrics, to obtain historical information even when the subscriber has changed IP address over time.

There are several possible sources for the subscriber ID:

• MAC access address (this is the default). In some networks, the MAC address might be the same for all subscribers (for example if all traffic is coming from the same router port) but in other networks, it may identify the subscriber access points.
• Subscriber access IP address. To configure the IP address to fill the subscriber ID, go to Administration->General Settings-> Default subscriber-ID source.

REST API. As part of the subscriber POST/PUT operation, a subscriber ID can be provided (see REST API section for details).

RADIUS. To configure a parameter from RADIUS, go to Configuration->RADIUS. The following RADIUS parameters can be mapped to BQN subscriber ID:

• Username
• Calling-Station-ID

Azotel billing system:

• Customer-ID
• Name
• Nickname

Powercode billing system:

• Customer-ID
• Equipment-ID
• MAC address
• Name

Sonar billing system:

• Customer-ID
• Name

Spynx billing system:

• Customer-ID
• Username
• Login

Visp billing system:

• Customer-ID
• First +Last name
• Username

To configure a parameter from an external billing system, go to Configuration->RADIUS/REST/Billing->Billing Systems.

‍

Subscriber Flow Policies

When a new flow is created, a subscriber flow policy is assigned to it, which specifies how to treat all the flows within that subscriber. The actions that can be defined in a subscriber flow policy are:

• TCP Optimization. Improves TCP traffic performance. It specifies whether to apply optimization to TCP traffic. It is recommended to enable it (the default value).
• Shaping per subscriber. It limits the combined speed of a subscriber flows to a given value. It is possible to limit in the downlink and/or uplink direction. The limit applies to all flows matching the policy belonging to the same subscriber. For example, if video streaming flows are assigned to a  policy with a 6 Mbps subscriber limit, and the subscriber has three video streaming flows at the same time, the three flows will share the 6 Mbps limit (getting around 2 Mbps each). It is possible to define bursts that allow flows to exceed temporally the limit (see the end of this section).
• Shaping per flow. It limits the speed of one flow to a given value. It is possible to limit in the downlink and/or uplink direction. The limit applies to any flow matching the policy. For example, if video streaming flows are assigned to a per flow 2 Mbps limit, a video flow cannot exceed those 2 Mbps. Shaping per flow can be combined with shaping per subscriber: for example, if there is a per subscriber 6 Mbps limit and a 2 Mbps per flow, a subscriber with four flows will have them limited to the 6 Mbps maximum (around 1.5 Mbps each). Per flow shaping has no burst option. Because per-flow shaping is not applied per subscriber, it can be used even when there is a NAT between the BQN and the end subscribers.
• ‍Block.  It blocks all flows falling in the blocking policy, in both directions, and does not let it proceed. It should be used with care, to avoid affecting traffic different to the one intended.
• Drop incoming connections. It blocks only flows that are started from the Internet side, but not flows started from the subscribers.
• ‍Skip subscriber rate limitation. The traffic from flows getting this policy will no longer be affected by the rate limitation specified in the rate policy for this subscriber. They will only get the rate limitation specified by this flow policy (if any).  

These policies are configured in the menu option Configuration->Subscriber Flows, selecting the tab POLICIES.

‍

Shaping per subscriber

The following example defines a downlink speed limit of 10 Mbps, an uplink limit of 8Mbps and bursts of 3 seconds of double the normal speed.

‍

Burst Options

Regarding bursts, they are configured under Burst Options of the appropriate direction. Burst policy is defined by four parameters:

• Burst Rate: it is the maximum rate during the burst, typically bigger than the normal shaping max rate (e.g., allow burst of 20 Mbps for flows normally limited to 10 Mbps).
• ‍Burst Duration: it is the duration of the burst, i.e. for how long the burst rate can be sustained.
• ‍Burst Threshold: it is an average speed that, if exceeded, prevent a new burst from happening. It is the way to control when a new burst can be granted. For example, for a 10 Mbps limit with 20 Mbps bursts, a 5 Mbps burst threshold will require the subscriber flows to drop the speed to half its normal limit before allowing a new burst.
• ‍Burst Threshold Window: it is the period, in seconds, used to compute the average speed that is checked versus the threshold. The longer the window, the bigger the weight of past subscriber activity on the decision of grating a new burst.

Shaping per flow

The following example is a policy with a limit per flow of 4 Mbps in either direction.

It is possible to add a shaping per subscriber. Per flow and per subscriber shaping limits will act at the same time, per flow shaping limiting the speed of individual flows and subscriber shaping limiting the combined flow speed per subscriber.

‍

Blocking incoming Traffic

It is possible to block incoming traffic, initiated from the Internet (TCP connections, UDP flows or other IP traffic like ICMP pings). To do so, there is a Drop Incoming Connections section as part of a Subscriber Flow policy.

‍

‍

Subscriber Rate Policies

Subscriber rate policies are applied per subscriber. The possible actions are:

• Maximum downlink speed. It is the maximum speed in the downlink direction for all traffic going towards the subscriber’s IP address.
• Maximum uplink speed. It is the maximum speed in the uplink direction for all traffic coming the subscriber’s IP address.
• Under Advanced Parameters, you can find the same burst options as for Subscriber Flow Policies.
• There is an Automatic Congestion Management (ACM) option, that will detect congestion and select a rate limit automatically (enabled by default).

‍

These policies are configured in the menu option Configuration->Subscriber Rates, selecting the tab POLICIES.

See in section Subscriber Identification how all traffic from the same subscriber is identified.
‍

Subscriber Rate Policies can also be created dynamically through the BQN external interfaces (RADIUS, REST API or an interface to an external billing system). In that case, the policy parameters, and the associations of the policy to the subscribers are controlled from the external interfaces and independent of BQN-configured rules (configured rules are a fallback for subscribers without a policy assigned by the external interface).

‍

Enable/Disable ACM

‍

The ACM is enabled by default.

To enable or disable ACM in a configured policy, change the “Automatic Congestion Management" field in the Subscriber Rate window:

Dynamic rate policies created by RADIUS, REST or an external billing also has ACM capabilities, and it is enabled by default.

To enable or disable ACM in a dynamic policy, change the “Automatic Congestion Management" field in the configuration of the RADIUS/REST/Billing system. For example, for RADIUS rate policies:

ACM improves the network quality with no need of configuration fine tuning, so it is recommended to keep it enabled at all times. Nevertheless, it is possible to disable ACM for all policies going to Configuration->TCPO/ACM Settings and change the Global ACM Status switch to off.

Subscriber Monitoring Policy

Subscriber monitoring policies are applied per subscriber. They just determine the amount of sampling of DPI records for each subscriber. By default, the BQN comes with a monitor-default policy that applies to all subscribers, which automatically determines the number of DPI records (called UDRs, or Usage Data Records) to produce, so that the DPI statistics are meaningful and do not take too much CPU and disk to produce, and that is the recommended mode of operation:

‍

It is possible to adjust the amount of UDRs for certain subscribers by creating a monitoring policy that specifies percentage of flows with UDRs (e.g. 0% or 100%). UDRs for 100% of flows will produce and accurate description of the subscriber usage statistics, but for performance reasons, it is recommended to set a 100% UDR monitoring policies only on a few subscribers at a time, because these policies can produce a huge number of records that could use all the available disk space and could also make the production of DPI statistics very slow and CPU-consuming.

Rules

Rules specify which configured policies to assign to each subscriber and flow, based on the profiles in the rule.

There are independent sets of rules for each policy type: subscriber flow rules select the appropriate subscriber flow policy for each flow, subscriber rate rules select the appropriate configured subscriber rate policy for each subscriber, and, similarly, subscriber monitoring rules select the appropriate subscriber monitoring policy for each subscriber.

A rule can use one profile of each type (or, alternatively, use the any option, if the profile type is indifferent), and it defines one and only one policy to apply.

Every set of rules may have many rules, but only the one with the best match will be selected for each flow or subscriber. To evaluate the rules in a way that maximizes performance, profiles are checked in order. This predefined order determines which rule is finally selected.  A tree view of the rules helps in identifying which rule is selected in each case. See Decision Tree sections for details on the trees and the profile evaluation order.

Manually configured rule priorities are not used because of the performance penalties they entail and the burden on the operator to keep priorities consistent.

The subscriber flow rules are configured in the menu option Configuration-> Subscriber Flows, selecting the tab RULES TREE-VIEW or RULES TABLE-VIEW. Similarly, the subscriber rate rules are configurable in Configuration->Subscriber Rates and the subscriber monitoring rules in Configuration->Subscriber Monitoring.

‍

Subscriber Flows Decision Tree

The evaluation of subscriber flow rules is as follows: when a new traffic flow is created (for example, a TCP connection), the profiles in the subscriber flow rule set are checked against that new flow, a matching rule selected, and with it the flow policy to apply.

For efficiency, profiles are evaluated in this predefined order:

1. Interface
2. VLAN
3. Policy-rate
4. Internet
5. Access
6. Subscriber group
7. Subscriber ID
8. Time
9. Throughput
10. DPI

The profile evaluation order defines a decision tree, whose nodes are the different profiles and with policies as leaves. The tree determines which rule is finally selected, because a rule can be excluded if it belongs to a branch that the decision tree does not follow. It may be the case that a flow matches more than one rule. In that case, the profile type order is important: for example, a rule matching the Interface profile would have priority over the rule matching the VLAN profile, and so on in the order specified above.

If two rules have a match with the same profile type, the more restrictive profile would have priority. For example, a flow from a subscriber with IP address 192.168.0.1 would match both an access profile with the 192.168.0.0/24 range and another access profile with the 192.168.0.0/16 range, but the first rule, with a narrower range (/24 vs/16), and therefore more restrictive, would be selected.  

To facilitate the understanding of this order, the GUI includes a graphic representation of the decision tree, where the better matching path would lead to the selected policy (except when there is more than one match at the same profile level, when the most restrictive would win). It is accessible in Configuration->Subscriber Flows->Rules clicking the Tree View tab.

If there are common elements in two profiles of the same type and therefore a rule conflict, the decision tree will signal it so the rules can be reviewed by the operator and the conflict corrected. In the following example, two access profiles have an overlap (they both contain the same IP range). This will be signaled with a warning window and, also, one of the conflicting rules will have its number in yellow. Removing the overlap (for example making one of the profiles to have a more specific range), the conflict will disappear.

‍

Subscriber Rate Decision Tree

The evaluation of the subscriber rate rules happens whenever a new subscriber session is detected (when traffic from a new access IP address is received). The profiles are checked against the subscriber session and a matching rule found, that will specify the rate policy to apply. For efficiency, the profiles are evaluated in the following pre-determined order:

1. Interface
2. VLAN
3. Access
4. Subscriber group
5. Subscriber ID
6. Time

Other profile types cannot be used in subscriber rate rules. For example, Internet profiles and DPI profiles will apply to some of the subscriber applications and not to others. Another example is throughput profile, because the rate rules are evaluated at the start of the subscriber session and the throughput changes continuously.

The decision tree is similar to the tree of subscriber flow rules. It is available in Configuration->Subscriber Rate->Rules selecting the tab RULES-TREE VIEW.

‍

Subscriber Monitoring Decision Tree

The evaluation of the subscriber monitoring rules happens whenever a new subscriber session is detected (when traffic from a new access IP address is received). The profiles are checked against the subscriber session and a matching rule found, that will specify the rate policy to apply. For efficiency, the profiles are evaluated in the following pre-determined order:

1. Interface
2. VLAN
3. Access
4. Subscriber group
5. Subscriber ID

Other profile types cannot be used in subscriber rate rules. For example, Internet profiles and DPI profiles will apply to someof the subscriber applications and not to others. Another example is throughput profile, because the rate rules are evaluated at the start of the subscriber session and the throughput changes continuously.

The decision tree is similar to the tree of subscriber flow rules. It is available in Configuration->Subscriber Monitoring->Rules selecting the tab RULES TREE-VIEW.

‍

Profile Explicit Priority

As explained in previous sections, profiles are evaluated in a priority order based on the profile type (some types take precedence over other types) and, for profiles of the same type, on what profiles are more specific. Most rule sets can be defined relaying on this implicit priority order.

However, some profiles use stringpatterns with wild chars, like *youtube* or mysubscriberId*, for which it is not easy to decide which profile is more specific. For that reason, those profile types have a priority number if the rules need to decide which one will take precedence over other matching profile of the same type. The lower the number, the higher the profile priority.

For example, a profile with a priority of 10 will take precedence over another profile of the same type with priority 20.

The profile types that have anumerical priority are:

• Policy rate profile
• Subscriber group profile
• Subscriber ID profile
• DPI

Profiles of these types are created with a default value of 9999 (the lowest possible priority, meaning none takes precedence unless the value is changed to a lower number).

‍

Policy Examples

Several common examples of policies follow.

‍

Implementing Subscriber Rate Plans

The objective is to apply the speed limits in each subscriber’s data plan.

The BQN applies these limits better than a conventional shaping element because, for TCP traffic (the most common), it does not need to discard packets. Furthermore, it uses independent queues per flow and that makes application latencies independent of each other, which greatly improves the experience of interactive applications. The following picture shows the queue structure, with a queue per flow and policy control at flow and subscriber levels.

The easiest way to implement Rate Plans is to use the RADIUS, REST or Billing interfaces (see the corresponding sections). Rate policies will then be assigned by an external system for each subscriber. The external system can directly create those policies, or it can assign rate policies configured from the BQN GUI.

If an external system cannot be used, you can create one rate policy for each plan, an access policy with all the subscriber IP addresses (or ranges) assigned to that plan, and then a rule linking the corresponding access profiles and rate policies. The following is an example of the rule tree:

‍

It is also possible to define such rules just for one test IP address that is used during a proof-of-concept to see the BQN performance as a bandwidth manager:

‍

Limiting the Speed of Some Applications

The goal is to reduce the network peak throughput to mitigate the congestion at the peak hour. To that end, a DPI profile is defined (video in the example) to identify the applications to limit. This example makes use of video streaming predefined signatures. To include them, in Add DPI profile, select Add Predefined Signatures and choose the Video Streaming predefined signature.

Also, a throughput profile is created with the traffic load from which to start limiting (above-5Gbps in this example). Then, a subscriber flow policy (flow-10Mbps in the example) is created with a downlink limit (Downlink shaping per Subscriber) set at 10 Mbps. Finally, the DPI profile, the throughput profile and the subscriber flow policy are tied together in a subscriber flow rule.

‍

Limiting the Speed of Some Applications with NAT

The goal is to reduce the network peak throughput to mitigate the congestion at the peak hour. In this scenario there is a NAT between the BQN server and the end subscribers and, therefore, a shaping per subscriber is not possible.

We will use the same Throughput and DPI profiles of the previous example, but we will use a per-flow shaping policy.

‍

Services not limited by the Subscriber Rate

The goal is to preserve the quality of experience of some services by granting throughput to them even when the subscriber rate plan is fully used.  An example could be a Voice over IP(VoIP) service hosted by the ISP. The policy is limited to subscribers with gold plans. It is created with an Internet profile (voip) with the IP address and port of the ISP-hosted VoIP service, a policy-rate profile and a flow policy (with Skip subscriber rate limitation selected to On). Next, the Internet profile and the policy-rate profiles are linked to the policy by a subscriber flow rule.

‍

Blocking Applications

In this scenario, some applications need blocking, for example, servers that are sources of attacks. To do this, an Internet profile is created (malicious-apps in the example) to identify the IP addresses to block. Next, a subscriber flow policy is defined with block action (with name flow-block in this example) and, finally, the Internet profile and the subscriber flow policy are combined in a subscriber flow rule.

‍

Exclude Traffic from TCP Optimization

The objective is that the BQN will not optimize certain traffic. For example, some subscribers. To that end, an access profile is defined (subs-no-tcpo in the example), with the subscriber IP addresses to exclude.  Next, a subscriber flow policy is defined with optimization set to off (flow-no-tcpo in the example) and, then the access profile and the subscriber flow policy are combined in a subscriber flow rule.

This setup is equivalent to the IP address blacklist in BQN Release 3 software.

Another example would be to use an Internet profile to exclude some applications per TCP port.