Label Routing

From TBwiki
Revision as of 12:23, 30 June 2014 by Cboulanger (Talk | contribs)
Jump to: navigation, search

Label Routing is an algorithm that combines Digit Analyzer and the concept of RouteSet. It is implemented as a RoutingScript in Toolpack Gateway.  This algorithm allows complex routing rules, as normally available with RoutingScript, but on a very large number of destination numbers.


Contents

Concept

The concept behind label routing is quite simple.

  1. A list of numbers (NPA-NXX) for a specific destination is assigned a RouteSet name. This list can be very large
    1. i.e., 514201,514202,514203, ... -> "Montreal, Qc"
  2. The list of routes for the destination is assigned the same RouteSet name. This list usually is limited to the number of network access points (NAP) in the system.
    1. i.e., Bell, Rogers, Videotron -> "Montreal, Qc"


Note: No matter how many destination numbers lead to a given destination, only a limited list of routes are selected. At this point, complex, yet efficient, routing rules can take place.


Implementation

As previously mentioned, routeset (label) routing is implemented as a RoutingScript. It was written as an optional filter, and can be used in any existing scripts. This filter is a before_filter, and reduces the amount of routes the routing script will work with.


Provisioning

Provisioning of large amounts of Routeset definition and digitmaps is accomplished by importing CSV files using the WebPortal.  Those files are being saved in the HA Database.


Routeset Definition

Each NAP in the system must be assigned a routesets_definition CSV file. A routesets_definition file gives the association between NAP and RouteSet names. The association between a NAP and a RouteSet name is in fact a route! ie: Rogers->"Montreal, Qc" Thus, for each RouteSet name<->NAP association, a dynamic route entry gets created.


The routesets_definition file defines a list of RouteSet names, with optional attributes.

  • One mandatory column: routeset_name (label)
  • Supplementary columns are used to provide optional and custom attributes to dynamically created routes
 routeset_name,  cost,    custom_1
"Montreal, Qc", "0.24",  "custom_val"

In the above example, routes are created with custom attributes found in the second and third columns. Each custom attribute must be defined by adding a custom column in the gateway Route table.


The NAP <-> Routeset Definition association is done by setting the NAP dynamic columns named 'routesets_definition'.  More than one NAP can point to the same 'routesets_definition' file. This file must be imported in the database using the File Db view in the Toolpack Web Portal.


Digitmap

Each NAP in the system can be assigned a routesets_digitmap CSV file. It is usual that all NAP uses the same routesets_digitmap file. A routesets_digitmap file gives the association between numbers and RouteSet names.

  • Three mandatory columns: route_set_name, called and calling
 called,calling,routeset_name
403200,       ,"Calgary, AB"
514201,       ,"Montreal, Qc"
514202,       ,"Montreal, Qc"
514203,       ,"Montreal, Qc"

The NAP <-> Routeset Digitmap association is done by setting the NAP dynamic columns named 'routesets_digitmap'.   This file must be imported in the database using the File Db view in the Toolpack Web Portal.


Dynamic Routes

When provisioning is complete, dynamic routes can be generated by going in the Routetsets menu item, under Gateway menu Item.

Routesets.png
Generate routes.png


Performance

Typically, there are only a few hundred labels (e.g. countries/states/regions/providers/cities identifiers) but there are hundred thousands and millions of actual numbers pointing to those labels. Each label will correspond to a dynamic route associating it to a destination NAP. The biggest portion of the data comes from the digitmap files. These million digit maps are loaded into binary trees when a configuration is applied allowing longest match algorithm to be performed with constant delay regardless of the number of digit map entries in memory. The only performance impact is upon the "Apply configuration" time, not on the call processing flow. Here are a few samples of configuration loading time on a TMG3200 running release 2.7:

Nb of digitmap entries Uncompressed digitmap filesize Apply configuration time (s)
Not used
-
~6s
250k
4.4MB
~7s
500k
8.8MB
~8s
5M
88MB
~17s


Note that digit map files can be gzipped to reduce size before importing them in the File Db.

Configuration

Useful links

Personal tools