universal state server (uss). all rights reserved © alcatel-lucent 2007 2 | uss module objetives...

Universal State Server (USS)

2 | USS All Rights Reserved © Alcatel-Lucent 2007

Module Objetives Get to know the way it works and its utility

How to configure counters and records data

Information that can be stored and how to read it

Indices: Configuration and use

USS triggers to execute a PF on a USS transition

How to invoke the USS from another VitalAAA server

Statistics

AI commands

RAM needed by USS


Introduction The “Universal State Server” (USS) recollects information of

users' sessions from 1 or more VitalAAA Front End servers

This information may be used to monitor or limit users' connections based on: User-name, realm, DNIS, CLID, etc

It is like a database "in memory"

The USS used can be: in the same host as a VA front end In a separate host used only to process USS requests

Only 1 USS can be active in the network, no matter how many VA front ends there are With HA-USS, we can have 1:1 redundancy


Network diagram

RADIUS(Remote

ISP)

Front End AAA #1

Front End AAA #2

UniversalStateServer

LDAP Directoriesor

Database Servers

NAS

...User

PSTN

the Internet


Accounting

Authentication

Data Flow between VA and USS

NAS VitalAAA USS

USS Query Check LimitsSend Access Request

Start session Send Access-Accept ACKAdd Record

Increment counters

Send START record

Notify USS of START Port “In-Use”Update Record

Send STOPrecord

Notify USS of STOP ”Release” PortDelete Record

Decrement counters

Send Acct-Response ACK

Send Acct-Response ACK


A deeper look (I)Authentication

VitalAAA notifies the USS of an incoming auth request providing the NAS-IP-Address, NAS-Port and call info VitalAAA sends a request to the USS listing the NAS and Port, plus any

other attribute User-Name, Called-Station-Id (DNIS), Realm, etc.

For each item sent, a “limit” may be specified For Example:

User-Name = auserUserLimit = 1DNIS = 5551212DNISLimit = 500


A deeper look (II)Authentication

The USS looks to see if the port is in use and notifies the PolicyFlow of the port status If the NAS and Port identified in the request are shown as busy the

USS assumes an error has occurred and deletes the old entry A missed stop counter is incremented

For each specified limit received, the USS checks to see if the current count for the item exceeds the specified limit

If all specified items are under limit, an “ACK” is returned to PolicyFlow In any of the items are over the specified limit a NACK is returned

instead


A deeper look (III)Authentication

The USS temporarily marks the port as busy and records information about the port usage (User-Name, DNIS, etc.) Simultaneous to sending the ACK to VitalAAA, the USS does the

following Adds an entry to the USS data table with session information, including

–NAS IP Address + NAS Port–User-Name, etc.

Increments the counters configured

Marks the time the entry was received If an authentication entry is not validated within a pre-defined time

(accounting start timeout) by a START of accounting record, it will be removed


A deeper look (IV)Accounting Start

VitalAAA notifies the USS when the accounting START record is received An accounting START record provides positive proof that a user

session has actually begun It is possible for a session to disconnect after the authentication request has

been answered with an Access-Accept.

A START of accounting record is only sent after the session has actually begun

A PolicyFlow method using the StateClient/StateServer plug-in is placed in the accounting flow to send notification to the USS of the START record arrival

The USS marks the port as “in-use” The temporary time stamp is removed from the USS record

The record will not be deleted until a accounting STOP record is received or the maximum session time-to-live (session timeout) is exceeded


A deeper look (V)Accounting Stop

The PolicyFlow notifies the USS when the accounting STOP record is received An accounting STOP record provides positive proof that a user session

has ended A PolicyFlow method using the StateClient/StateServer Plug-in is

placed in the accounting flow to send notification of the STOP record arrival to the USS

The USS entry is deleted and counters are decremented


USS Operation (1)

StateServer Plug-in params

PolicyFlow = AuthenticationUser-Name = auserNAS-IP-Addr = 192.1.11.2NAS-Port = 45DNIS = 5551212Realm = eol-esGroup = tot-eolLimit-User-Name = 1Limit-Realm = 1Limit-Group = 2

192.1.11.2+45 auser ...

Key User ... User Counter

auser@eol-es 1

Realm Counter

eol-es 1

group Counter

tot-eol 1

Universal StateServer

Packet Type = Access-RequestUser-Name = auser@eol-esCalled-Station-Id = 5551212NAS-IP-Addr = 192.1.11.2NAS-Port = 45

RADIUS Request

ack

A simple authentication under the limits configured.


USS Operation (2)


PolicyFlow = AccountingUser-Name = auserNAS-IP-Addr = 192.1.11.2NAS-Port = 45


auser@eol-es 1

Realm Counter

eol-es 1

group Counter

tot-eol 1


Packet Type = Accounting STARTUser-Name = auser@eol-esNAS-IP-Addr = 192.1.11.2NAS-Port = 45

RADIUS Request192.1.11.2+45 auser ...192.1.11.2+45 auser ...

ack

The START record confirms that the session has begun.


USS Operation (3)


PolicyFlow = AuthenticationUser-Name = buserNAS-IP-Addr = 192.1.11.2NAS-Port = 23DNIS = 5551234Realm = eol-frGroup1Name = tot-eolLimit-User = 1Limit-Realm = 1Limit-Group = 2

192.1.11.2+45 auser ...


auser@eol-es 1

Realm Counter

eol-es 1

group Counter

tot-eol 1


Packet Type = Access-RequestUser-Name = buser@eol-frCalled-Station-Id = 5551234NAS-IP-Addr = 192.1.11.2NAS-Port = 23

RADIUS Request

192.1.11.2+23 buser ... buser@eol-fr 1

tot-eol 2

eol-fr 1ack

Another simple access. Note that the group1 counter increases.


USS Operation (4)


PolicyFlow = AccountingUser-Name = buserNAS-IP-Addr = 192.1.11.2NAS-Port = 23


auser@eol-es 1

Realm Counter group Counter


Packet Type = Accounting STARTUser-Name = buser@eol-frNAS-IP-Addr = 192.1.11.2NAS-Port = 23

RADIUS Request192.1-.11.2_45 auser ...192.1.11.2+45 auser ...

192.1.11.2+23 buser ... buser@eol-fr 1

tot-eol 2eol-es 1

192.1.11.2+23 buser ...

ack

Again, the START record confirms the access -- but does not increment

the counters..

eol-fr 1


USS Operation (5)


PolicyFlow = AuthenticationUser-Name = auserNAS-IP-Addr = 192.1.11.2NAS-Port = 38Realm = eol-esCalled-Station-Id = 5551234 Group1Name = tot-eolLimit-User = 1Limit-Realm = 1Limit-Group = 2


auser@eol-es 1



Packet Type = Access RequestUser-Name = auser@eol-esNAS-IP-Addr = 192.1.11.2NAS-Port = 38Called-Station-Id = 5551234


192.1-.11.2_23 buser ... buser@eol-fr 1

tot-eol 2eol-es 1

192.1.11.2+23 buser ...

nack

‘auser’ tries again, but this time note we have set a UserLimit of 1, which

he exceeds..

eol-fr 1


USS Operation (6)


PolicyFlow = AuthenticationCalled-Station-Id = 5551234 User-Name = cuserNAS-IP-Addr = 192.1.11.2NAS-Port = 13Realm = eol-esGroup1Name = tot-eol Limit-User = 1Limit-Realm = 1Limit-Group = 2


auser@eol-es 1



Packet Type = Access RequestUser-Name = cuser@eol-esNAS-IP-Addr = 192.1.11.2NAS-Port = 13Called-Station-Id = 5551234


buser@eol-fr 1

tot-eol 2

192.1-.11.2_23 buser ...192.1.11.2+23 buser ...

nack

eol-es 1

Limit = 1 is >= Realm total of 1

Now the Realm Limit is reached. Since ‘cuser’ is the second user using

eol-es, he is refused access

eol-fr 1

eol-es 1


USS Operation (7)


PolicyFlow = AuthenticationUser-Name = cuserNAS-IP-Addr = 192.1.11.2NAS-Port = 13Called-Station-Id = 5559999Limit-User = 1Limit-Realm = 1Group1Name = tot-eolLimit-Group = 2


auser@eol-es 1



Packet Type = Access RequestUser-Name = cuser@eol-ptNAS-IP-Addr = 192.1.11.2NAS-Port = 13Called-Station-Id = 5559999


buser@eol-fr 1

tot-eol 2eol-es 1

192.1-.11.2_23 buser ...192.1.11.2+23 buser ...

nack

‘cuser’ tries again, this time using a different realm -- but now we have a

Group1Limit.

eol-fr 1

Counter = 2 is >= group1 Limit of 2

tot-eol 2


Operational Key Points The USS only keeps track of counters and sessions info

The USS doesn't store limit information

The limits are set in the StateServer plug-in Reading them from a file, external source, etc We can established different limits for different users for the same

counter Some users can have limits on certain attributes, and other users on

different attributes One user may have limits based on User-Name

Other on realm

Other on DNIS + User-Name, etc.


USS Records (I) USS records store session information of connections

It contains 5 main fields: Key: Identifies the session in a unique way

Two different simultaneous connections can't have the same key

By default, it is NAS-IP-Addr + NAS-Port–Though it can be changed

The token at the left side of the "+" sign, is also called subkey

NAS: Identifier of the NAS. Used for accounting-on/off, in case the key doesn’t include the NAS-IP

SessionId: to correlate if an event is for a new session or an existing one

AVP'sUser-Name = [email protected]

DNIS = 908390390

CLID=918078419

etc.KEY=

NAS-IP-Addr + Port StatedatesNAS SessionId


USS Records (II) State: It shows the state of this user's session (record)

Inactive: this NAS-Port doesn't have a connection right now, but it had–Inactive records can be deleted from memory or not, if they are to be reused

Waiting-for-start: An Access-Request has been received, and the USS is waiting for the Acct-start packet

Active: the session has been successfully established

Dates: of the last modification of the record, of the event (RADIUS request) and the expiration time Modification and Event timestamps can be different on Acct, if there have

been retransmissions (Acct-Delay-Time attribute)

Data, ‘Resources’ or AVP's (attrs): any extra data related to this session provided by the PolicyFlow Used to be read later by the PolicyFlow or to update counters

–User-Name, User-Realm, CLID, DNIS, groups, etc

Also referenced as uss variables


Counters (I) A counter counts the number of occurrences of a specific

resource Usually represents the active sessions using that resource

There are 2 types of counters Access or restrictive:

It is incremented upon receiving an Access-Request–If the Acct-Start is not received before a timer, it is assumed the session wasn't

successfully completed, and the counter will be decremented

A session which doesn't successfully completes, may limit another one which would have been successful if not refused by the USS

Accounting or permissive It is incremented upon receiving an Acct-START

–It doesn't include authenticated sessions, which haven't been established completely


Counters (II) Counters are costly to maintain in terms of memory and CPU

It’s not necessary to count every attribute of a session Only the counters specified in uss_counters will be maintained

User-Name, User-Realm, Called-Station-Id, DNIS, CLID, POP, etc.

Can have any name, not necessarily a RADIUS attribute

COUNTER COUNTER Type

Resource counts

Resource counts

Resource counts

DNIS DNIS Acces

s917529000 8419917148692 2405

913379994 1137User-Realm User-Realm Acctterra 9004

arrakis 1205

able 106

etc.

User-Name User-Name Acces

spepe@terra 1

john@tid 1


Finite State MachineRegular transitions

Non-exist.Non-exist.Waiting_for_startWaiting_for_start

InactiveInactive ActiveActive

Modify record

Create a new record

++ access counters

Access- Request

Access- Request

-- counters

++ acct. count.

Session Timeout-- access count.

AcctStart Timeout

Acct START

Acct-Off

Inactive Timeout

Acct INTERIMAcct-On

Acct STOP | Acct-Off

Access-Request


Finite State MachineIrregular transitions

The USS determines a packet has been lost

Waiting_for_startWaiting_for_start

InactiveNon-exist.InactiveNon-exist.

ActiveActive-- counters

++ access count.

++ acct. count.

++ Missed-Auths

-- access count.

++ Missed-Starts

Access-Request with different Acct-Session-Id

Acct-On

Acct-Stop

Acct-StartAcct-Interim

++ Missed-Stops


Timers Configuration

…StateServer_AcctStartTimeout = 45000StateServer_SessionTimeout = -1StateServer_InactiveTimeout = -1StateServer_KeySeparator = +…

…StateServer_AcctStartTimeout = 45000StateServer_SessionTimeout = -1StateServer_InactiveTimeout = -1StateServer_KeySeparator = +…

server_properties

If the NAS's reuse their ports and there are no indices, this value should be -1 to reuse the entries.

–It is faster to modify, than to delete an entry and create it later

If the NAS's don't reuse their ports in a short amount of time (or there are indices) the USS records should be deleted as soon as possible

• Value=0 for GGSN, LNS of L2TP, Ipsec servers, etc.

To determine if an ACCT STOP record has got lost

To determine that the session didn’t actually start, and the NAS hasn’t sent an ACCT STOP record


Counters Configuration

# Attribute Count Time# --------- ----------User-Name AccessUser-Realm Accounting

# Attribute Count Time# --------- ----------User-Name AccessUser-Realm Accounting

uss_counters


The StateServer plug-in It invokes the USS running in the same host

This plug-in has 2 main functions: Authorize users' access based on the network use Provide the USS with information of access or acct, so that the USS

updates the information it has about network usage


Info provided and retrieved to/from USS The StateServer exchanges information with the USS:

Request Map: The USS is provided with all information needed for updating network resources and limiting the session To store info in the sessions record and to update counters

Which counters limit this connection

Specific timers for this record entry

Reply Map: Optionally, the PF can read information stored in the USS data in the USS record for this connection (identified by the key)

counters occurrences

StateServer/StateClient

USS

Request-Map

Reply-Map


Info provided to USS (I):Request-Map

In the variable ‘mapping’ : The left side is a USS variable The right side is a VA variable

The USS variables may be of 3 types: uss or attruss or attr. An AVP to store in the record entry ${uss.User-Realm} = ${packet.User-Realm};

${attr.User-Realm} = ${packet.User-Realm};

limitlimit. The limit for this counter ocurrence It must be configured in the uss_counters file

It must also have a uss counterpart variable, with the same name

Two special values:– -1 : no limit– 0 : no access

${limit.User-Realm} = ${user.Realm_Limit:-1};


Info provided to USS (II):Request-Map timeouttimeout. Specific timeouts for this entry, instead of the general ones

acctstart, session, inactive

${timeout.session} = ${reply.Session-Timeout[increment(60),multiply(1000)]:-1};

When specifying a limit, and the counter in that moment is at the limit, the StateServer plug-in will fail The PolicyFlow will go on with Method-on-Fail

Example to limit to 10 connections by realm

${uss.User-Realm} = ${packet.User-Realm};

${limit.User-Realm} = 10; Usually the limit is read from a file/database, to have different limits for

different realms (customers) ${limit.User-Realm} = ${user.Realm_Limit};


Info retrieved from the USS: Reply-Map

The info read is stored in VA variables The left part is a VA variable The right part is a USS variable of these 2 groups:

ussuss. A value of an AVP store in a record entry, –which was previously stored in the request map

${user.POP_name} = ${uss.POP_name}

countcount. The value of a resource in a counter, passed in the Request-Map

${user.Realm-Count} = ${count.User-Realm};–for the specific counter provided in the Request-Map

${user.tmp_var_name } = “count.User-Realm.${packet.User-Realm}”;

${user.This-Realm-Count } = ${tmp_var_name[indirect]};–for any dynamic specific counter

*


StateServer Advanced Properties (I) Key-Attribute = how to identify uniquely different connections

No two sessions can have simultaneously the same key If a new session starts with the same key (and different Acct-Session-

Id), the previous session is supposed to have finished (and the Acct STOP packet was lost) Counters will also be decreased for the previous session

Nas-Attribute = to be able to close all sessions on a NAS reboot (Acct-On & Acct-Off packets) Necessary if the Key-Attribute doesn’t contain information about the

NAS


StateServer Advanced Properties (II) SessionId-Attribute –

to be able to distinguish from an update of an existing session, or from a new session with same key All packets of the same session, should have the same Acct-Session-Id

(including Acct Interim-Update packets)

Event-Time-Attribute – Time when the event took place in the NAS

Can be different from the Receipt-Time if there have been retransmissions (Acct-Delay-Time AVP)

User-Attribute – Only for support for the legacy ComOS-based NASs, where Acct-

Session-Id=0


StateServer Advanced Properties (III):Event Event – What transition the USS should do:

Auth, Start, Update, Stop, Boot, Shutdown, Timeout, None, AUTO

The default value (AUTO) is automatically determined according to the RADIUS packet received AUTH for Access-Request with new Acct-Session-Id (or NULL)

START for Acct-Start

UPDATE for Acct-Interim

STOP for Acct-Stop

BOOT and SHUTDOWN should be used for Acct-On and Acct-Off packets

NONE, to read values (reply-map), when no modification has to be made

TIMEOUT, to simulate the expected packet hasn’t arrived, and to decrease counters


StateServer example for authentication Limits the connection based on User-Name and realm limits

If not specified, the limit for User-Name is 1, and no limit for realm

checkLimits Method-Type = StateServer

StateServer-RequestMap = "${uss.User-Name} = ${request.User-Name};"

StateServer-RequestMap = "${limit.User-Name} = ${user.User-Limit:1};"

StateServer-RequestMap = "${uss.User-Realm} = ${packet.User-Realm};"

StateServer-RequestMap = "${limit.User-Realm} = ${user.Realm-Limit:-1};”

checkLimits Method-Type = StateServer


StateServer-RequestMap = "${limit.User-Name} = ${user.User-Limit:1};"


StateServer-RequestMap = "${limit.User-Realm} = ${user.Realm-Limit:-1};”


StateServer example for accounting In the accounting PolicyFlow, no limits need to be fixed

There is no possibility now to reject a user's connection

The USS must know that a START | INTERIM | STOP | Acct-OFF has been received

updateLimits Method-Type = StateServer Method-On-Success = writeCDR



updateLimits Method-Type = StateServer Method-On-Success = writeCDR




Non-attribute counters (I) The counters names need not be an attribute, can be anything

we want to count

The meaning of these non-attribute counters is given by the application and the PolicyFlow definition. Examples: “service class”

Each user is assigned a service class (gold, silver, bronze, etc)

We want to limit the "bronze" users to 10.000, as more would degrade network performance for "gold" users

Simultaneous connections by POP or geographic area There are several NAS's in a POP

Simultaneous connections of users belonging to the same realm Simultaneous connections by a group of realms


Non-attribute counters (II)Example for a group of realms (I)

We want to limit the total number of sessions of a customer, identified by a group of realms

The counter name is defined as “group”

We can read from a external source (file/database) the “realm_group" name for each realm And even the limit for each one

#Realm Provider Limitteleline terra 1000telelineb terra 10000terra terra 5000arrakis1 arrakis -1arrakis2 arrakis -1etc...

Realm2Group.txt

#Provider LimitTerra 70000arrakis 5000etc...

Group_limit.txt


Non-attribute counters (III)Example for a group of realms (II)

ReadRealmInfo Method-Type = ReadColumnarText Method-On-Success = ReadGroupInfoReadColumnarText-Text = @realm2group.txtReadColumnarText-Map = <<

${user.group} = ${2};${user.realm_limit} = ${3};

>>ReadColumnarText-SearchKey = ${packet.User-Realm}

ReadGroupInfo Method-Type = ReadColumnarText Method-On-Success = CheckLimitsReadColumnarText-Text = @group_limit.txtReadColumnarText-Map = "${user.group_limit} = ${2};"ReadColumnarText-SearchKey = ${user.group}

CheckLimits Method-Type = StateServerStateServer-RequestMap = <<

${uss.User-Name} = ${request.User-Name};${uss.Realm} = ${packet.User-Realm};${limit.Realm} = ${user.realm_limit};${uss.group} = ${user.group};${limit.group} = ${user.group_limit};

>>

•uss_counters•Realm Access

•group Access


Indices (I) Any value from the session record can be read searching by the

key Only 1 possible entry will be returned

Indices let us search entries from the records table searching by any AVP Many entries can be returned, if the searching value is not unique

Having indices created, and reading data often using the indices, has a great impact on performance (CPU+memory) Should only be created when strictly necessary

USS records based on index can be read from: PF: QueryUss plug-in CLI: index AI command external systems by LDAP

Search Criteria= index

User-Name = [email protected]

DNIS = 908390390

CLID=918078419

etc.KEY=



Indices (II)

Examples: by User-Name:

What's the Calling-Number of a certain User-Name?

Which NAS's have calls for a User-Name?

by DNIS: Which user(s) have dialed to a certain DNIS/APN?

By CLID Which User-Name is calling from a certain CLID?

By IP address Which user has been assigned right now a certain IP address?

By realm Which users and which CLID’s are connected to that realm?

User-Name = [email protected]

DNIS = 908390390

CLID=918078419

etc.KEY=



Indices configuration

User-NameUser-Name

uss_indices


QueryUss plug-in Used to retrieve entries from the USS, searching based on an

index. It is similar to the 'state index list' command

All entries that match a given index/value combination are retrieved and stored in a multi-valued variable. Could be processed, for example, by using the Iterate plug-in

Properties: Index - Which index to search

Special values include KEY or NAS

Value - of the index Result - (multi-valued) variable to store the USS record(s) matching

the searching criteria. The USS fields of the record(s) are mapped as a subvariable

–User.uss_result.State, user.uss_result.Key, user.uss_result.Event, user.uss_result.User-Name, etc

*


USS triggers (I)

A PF can also be started triggered by any USS transition. Usually: A USS timeout An Acct On/Off for NAS reset

The starting method of that PF is determined by the method_dispatch file The PF itself can be stored in any file

(with .pf extension)

Those PF’s have a lower priorities than those started based on a AAA packet

# Protocol State Event File Method# --------- --- ------- ---- ------trigger active timeout aaa CloseCDRtrigger active shutdown aaa CloseCDR

# Protocol State Event File Method# --------- --- ------- ---- ------trigger active timeout aaa CloseCDRtrigger active shutdown aaa CloseCDR

method_dispatch


USS triggers (II) The triggered PF can use these extra variables:

request.* - the contents of the USS entry before this event. reply.* - the contents of the USS entry after this event. packet.OldState - the state of the entry before the transition.

Will match <state> in method_dispatch file.

packet.NewState packet.Event - the event causing the state transition.

Will match <event> in method_dispatch file.

packet.OldTimestamp - the entry Event timestamp before this event. packet.NewTimestamp- the entry Event timestamp after this event. packet.DeltaSession - TRUE if the old and new entries refer to

different sessions. Determined by Session-Id

packet.Complete - FALSE if the entry is missing AUTH or ACCT data.

*


Example 1 with USS triggers:Closed accounting records only

To store into file/DB only CLOSED accounting records. Due to: Acct STOP packet received Acct On/Off received for all of the users of the NAS Timeout in the USS -> STOP packet was lost or 2 consecutive

INTERIMS The Acct-Session-Time will be taken from the previous INTERIM

The timers will be set during the AUTH PF, based on specific Session-Timeout for this user, specific Acct-Interim-Interval or a default of Interims every 1 hour

If STOP is not received, will take: Acct-Input/Output-Octets from previous INTERIM Session-Time based on the:

last interim for a timeout

moment the Acct-On/Off arrived


Example 1 with USS triggers [ACCT]:Closed accounting records only

radius Acct Accounting-Request uss_triggers UpdateUSSwithAcctradius Auth Access-Request uss_triggers ReadUserDatatrigger active timeout uss_triggers CalculateAcctSessionTime4Timeouttrigger active shutdown uss_triggers CalculateAcctSessionTime4AcctOfftrigger active boot uss_triggers CalculateAcctSessionTime4AcctOff


Example 1 with USS triggers [ACCT]:Closed accounting records onlyUpdateUSSwithAcct Method-Type = StateServer Method-On-Success = AckIfNotStop

StateServer-RequestMap = <<${uss.Acct-Start-Time} = ${packet.Acct-Start-Time};${uss.Last-Interim-Time} = ${packet.Event-Timestamp};${uss.Acct-Session-Time} = ${request.Acct-Session-Time:0};${uss.User-Name} = ${request.User-Name};${uss.Calling-Station-Id} = ${request.Calling-Station-Id};${uss.Called-Station-Id} = ${request.Called-Station-Id};${uss.Nas-IP-Address} = ${request.Nas-IP-Address:request.Nas-Id:request.Origin-Host};${uss.Acct-Input-Octets} = ${request.Acct-Input-Octets:0};${uss.Acct-Output-Octets} = ${request.Acct-Output-Octets:0};

>>

AckIfNotStop Method-Type = Compare Method-On-Failure = WriteUDR2FileCompare-Input1 = ${request.Acct-Status-Type}Compare-Input2 = StopCompare-Type = StringCompare-Operator = "!=“

CalculateAcctSessionTime4AcctOff Method-Type = Calculate Method-On-Success = WriteUDR2File• Calculate-Expression = "${request.Acct-Session-Time} := ${packet.NewTimestamp[fromDate,toUnsigned32]} - ${request.Acct-Start-Time[fromDate,toUnsigned32]}"


Example 1 with USS triggers [ACCT]:Closed accounting records only

•CalculateAcctSessionTime4Timeout Method-Type = Calculate Method-On-Success = WriteUDR2File• Calculate-Expression = "${request.Acct-Session-Time} := ${request.Last-Interim-Time[fromDate,toUnsigned32]} - ${request.Acct-Start-Time[fromDate,toUnsigned32]}"

WriteUDR2File Method-Type = WriteDelimitedFileWriteDelimitedFile-Filename = udr.WriteDelimitedFile-DelimitChar = ","WriteDelimitedFile-Map = <<

${1} = ${packet.Acct-Start-Time:request.Acct-Start-Time};${2} = ${packet.Acct-Stop-Time:packet.Event-Timestamp:packet.NewTimestamp};${3} = ${request.Acct-Session-Time};${4} = ${packet.Event[toUpper]:STOP};${5} = ${request.User-Name};${6} = ${request.Calling-Station-Id};${7} = ${request.Called-Station-Id};${8} = ${request.Nas-IP-Address:request.Nas-Id};${9} = ${request.Acct-Input-Octets:0};${10} = ${request.Acct-Input-Octets:0};

>>WriteDelimitedFile-FilenameExtension = .txtWriteDelimitedFile-RolloverMode = HourlyWriteDelimitedFile-IdleTime = 1000


Example 1 with USS triggers [AUTH]:Set USS timers, specific for each user

ReadUserData Method-Type = ReadUserFile Method-On-Success = CheckPasswordReadUserFile-Filename = usersReadUserFile-Map = << ${check.*}=${check.*}; ${reply.*}=${reply.*}; ${reply.Acct-Interim-Interval} = "3600";>>

CheckPassword Method-Type = AuthLocal Method-On-Success = USSinAuth

USSinAuth Method-Type = StateServerStateServer-RequestMap = <<

${uss.User-Name} = ${request.User-Name}; ${timeout.session} = ${reply.Session-Timeout[increment(60),multiply(1000)]:reply.Acct-Interim-

Interval[increment(30),multiply(2000)]};>>


Example 2 with USS triggers:Release IP addresses to the DHCP server

If having an external DHCP server, there is no DHCP message to bulk release all IP addresses of a pool (belonging to a NAS) DHCP was never intended to work with a RADIUS server and PPP users

Was intended to work with individual users, over Ethernet

If a NAS reboots and users’ IP addresses are not released, when the NAS boots up again and users reconnect, the DHCP server might run the risk to run out of IP addresses Specially true if the DHCP MAC address is generated from the Nas-Port

AVP, and the NAS doesn’t reuse the Nas-Ports

The USS triggers should be used to generate 1 DHCP Release message for EVERY active user in that NAS, based on an Acct-On or Acct-Off packet

1 Acct-Off•or/and

•1 Acct-On N DHCP ReleaseN users connected


Remote communication between VA and USS (I)

There can only be 1 USS in the network Contains centralized information This VA's PolicyFlow will use the "StateServer" plug-in

There can be several VA front ends in the network These VA's PolicyFlow will contact remotely the USS with the

"StateClient" plug-in

The protocol used to exchange information is the RADIUS protocol itself Uses non-standard packet with code 129, and Vendor-Specific

attributes These AVP’s transport non-standard attributes and limits


Remote communication between VA and USS (II)

The VA server with the active USS, must be able to distinguish from: Regular RADIUS requests from a NAS Special RADIUS packets from a remote VA (a Front End)

This may be achieved: in method_dispatch with Code = 129, or Inside the PF by assigning the Front End VA as a special client class

And branching based on ${client.Client-Class} variable, etc

RADIUS server #1 with USS = 1.1.1.1

RADIUS #2 = 2.2.2.2

RADIUS #3 = 3.3.3.3 NAS

NAS

NAS


StateClient Syntax The StateClient generates a special RADIUS request towards the

VA hosting the USS It is like a "Radius" plug-in, acting as proxy-radius

Plug-in properties: Server-Address = IP address and port of the VA+USS host Secret = shared-key between this VA and the one in the USS host Timeout = ms. waiting for reply from USS (2000) Retries = # of retries before giving up (0) Request-Map = attributes to send to the VA+USS server (${*}=$

{request.*};) Reply-Map = specifies how data is read from the USS database ($

{reply.*} = ${*};) Client-Address = to choose a source IP addr. for this RADIUS packet (*)


StateClient example for authentication The PolicFlow in the VA with the active USS must also be

configured properly

checkRemoteLimits Method-Type = "StateClient" StateClient-Secret = "top-secret"StateClient-ServerAddress = "1.1.1.1" StateClient-RequestMap = << ${User-Name} := ${request.User-Name}; ${VA-AVPair} += "Limit-User-Name=${reply.Connection-Limit:1}";

${VA-AVPair} += "Uss-User-Realm=${packet.User-Realm}";

${VA-AVPair} += "Limit-User-Realm=${user.Realm-Limit:1}";

${NAS-IP-Address} := ${request.NAS-IP-Address}; ${NAS-Identifier} := ${request.NAS-Identifier};

${NAS-Port} := ${request.NAS-Port :packet.Normalized-NAS-Port}; ${Acct-Session-Id} :=${request.Acct-Session-Id}>>

checkRemoteLimits Method-Type = "StateClient" StateClient-Secret = "top-secret"StateClient-ServerAddress = "1.1.1.1" StateClient-RequestMap = << ${User-Name} := ${request.User-Name}; ${VA-AVPair} += "Limit-User-Name=${reply.Connection-Limit:1}";


${VA-AVPair} += "Limit-User-Realm=${user.Realm-Limit:1}";

${NAS-IP-Address} := ${request.NAS-IP-Address}; ${NAS-Identifier} := ${request.NAS-Identifier};

${NAS-Port} := ${request.NAS-Port :packet.Normalized-NAS-Port}; ${Acct-Session-Id} :=${request.Acct-Session-Id}>>


StateClient example for accounting

checkRemoteLimits Method-Type = "StateClient" StateClient-Secret = "top-secret"StateClient-ServerAddress = "1.1.1.1" StateClient-Timeout = "3000"StateClient-RequestMap = << ${User-Name} := ${request.User-Name};


${NAS-IP-Address} := ${request.NAS-IP-Address};${NAS-Identifier} := ${request.NAS-Identifier};${NAS-Port} := ${packet.Normalized-NAS-Port:request.NAS-Port};${Acct-Status-Type} := ${request.Acct-Status-Type};${Acct-Session-Id} := ${request.Acct-Session-Id};${Acct-Delay-Time} := ${request.Acct-Delay-Time};

>>

checkRemoteLimits Method-Type = "StateClient" StateClient-Secret = "top-secret"StateClient-ServerAddress = "1.1.1.1" StateClient-Timeout = "3000"StateClient-RequestMap = << ${User-Name} := ${request.User-Name};


${NAS-IP-Address} := ${request.NAS-IP-Address};${NAS-Identifier} := ${request.NAS-Identifier};${NAS-Port} := ${packet.Normalized-NAS-Port:request.NAS-Port};${Acct-Status-Type} := ${request.Acct-Status-Type};${Acct-Session-Id} := ${request.Acct-Session-Id};${Acct-Delay-Time} := ${request.Acct-Delay-Time};

>>


Configuration in VA with USS Example to limit on User-Name and User-Realm

clients2.2.2.2 top-secret3.3.3.3 top-secret

clients2.2.2.2 top-secret3.3.3.3 top-secret

method_dispatchradius Auth NR-State-Request auth checkLocalLimitsradius Acct NR-State-Request acct updateLocalLimits

method_dispatchradius Auth NR-State-Request auth checkLocalLimitsradius Acct NR-State-Request acct updateLocalLimits

auth.pfcheckLocalLimits Method-Type = StateServer

StateServer-RequestMap = "${uss.User-Name} = ${request.User-Name};"StateServer-RequestMap = "${limit.User-Name} = ${packet.Limit-User-Name};"StateServer-RequestMap = "${uss.User-Realm} = ${packet.Uss-User-Realm};"StateServer-RequestMap = "${limit.User-Realm} = ${packet.Limit-User-Realm};"

acct.pfupdateLocalLimits Method-Type = "StateServer"

StateServer-RequestMap = "${uss.User-Name} = ${request.User-Name};"StateServer-RequestMap = "${uss.User-Realm} = ${packet.Uss-User-Realm};"

acct.pfupdateLocalLimits Method-Type = "StateServer"

StateServer-RequestMap = "${uss.User-Name} = ${request.User-Name};"StateServer-RequestMap = "${uss.User-Realm} = ${packet.Uss-User-Realm};"


Packet Flow for authentication

RADIUS #2 = 2.2.2.2

NAS

RADIUS server #1 with USS = 1.1.1.1

StateClient plug-in

Method_dispatchCode=129 -> StateServer Method_dispatchCode=129 -> StateServer

StateServer

Success

Access-Request (1) - ID=1User-Name (1) = ”pepe@terra"User-Password (2) = 5E%&gn)8NAS-IP-Address (4) = 192.168.20.2NAS-Port (5) = 20.........

VA-State-Request (129)- ID=5User-Name(1) = "pepe@terra"VA-AVPair(26->831(2)) = "Limit-User-Name=1"VA-AVPair(26->831(2)) = "Uss-User-Realm=terra"VA-AVPair(26->831(2)) = "Limit-User-Realm=1000"NAS-IP-Address(4) = 192.168.20.2NAS-Port (5) = 20

VA-State-Accept (130)- ID=5Access-Accept (2) - ID=1Service-Type (6) = Framed (2).........

*

variablesrequest.NAS-IP-Address = 192.168.20.2request.NAS-Port = 20Request.User-Name = [email protected] = 1Packet.Uss-User-Realm = terrapacket.Limit-User-Realm = 1000

VA stores the attributes VA-AVPair="X=Y" as variables $

{packet.X}=YThe rest of the attributes are stored in

regular request variables ${request.XXX}


Extra considerations (I) All authentication and accounting requests must be sent to the

same USS

Any manipulation/change of User-Name, Called-Station-Id or any other resource counted in the USS records, must be treated in the same way both in auth and acct

In the accounting PolicyFlow, the USS should be invoked as soon as possible To decrement counters ASAP not to reject new legitimate users


Extra considerations (II) In the authentication PolicyFlow, the USS should be invoked as

late as possible, especially after any method which could reject the user's access-request If the session is not finally established:

the USS won't know until the AcctStartTimeout expires.

the USS would have wasted CPU and memory, twice–Both to add a new record, and later to delete it

In simple PolicyFlows, the CheckItems and AuthLocal should be executed explicitly as soon as possible. The VA option to automatically check password and check-items shouldn´t be

used


USS Start-up and logging The USS is automatically started, as it is part of the VA

PolicyServer If that USS is not to be used, the PolicyFlow will never invoke a

StateServer plug-in And it will not take any RAM

If the network has several VA servers, only 1 will invoke the USS locally (StateServer) The rest will invoke the StateClient plug-in

The USS logs are stored in policy.log: This behavior can be changed with log_rules and log_channels


Exporting & Importing the USS records It could be useful to:

dump to file the USS records on a clean shutdown import from that file when starting up

Good idea if stopping the USS for a short period of time Valid not to lose the USS data during VA upgrades

…StateServer_DataFile = uss_today.txt…

…StateServer_DataFile = uss_today.txt…

server_properties


Statistics and monitoring (I) The SMT statistics (also accessible from the CLI) show:

Amount of records and state (Sessions) To have an idea of the total load of the USS and the memory taken

Statistics For requests received

State changes in the Finite State Machine And events that generated those changes


Statistics and monitoring (II)

Interim StopAuth

Start


Viewing the USS database (I) Counters: for each counter, the resources and values

Ports (records): shows all the fields in a USS Searching by key (and subkey)

Indices If there are many entries, this can load the USS and make it work

slower


Viewing the USS database (II) A port can be released,

decreasing the related counters


USS related AI commands (I) All AI commands related to the USS have the prefix “state”

uss counts - output counter infouss entry - list a state database entryuss index list - list entries using indexuss keys - list keysuss list - list a state entryuss load - restores a state database from a fileuss naslist - list NASesuss save - save the state database to a fileuss stats help - describe state database statisticsuss stats - list state database statistics uss stats reset - reset state database statisticsuss status - show state server replication stateuss stop key - stop a state entry by keyuss stop all - stop all entriesuss stop nas - stop all entries for a NAS

uss counts - output counter infouss entry - list a state database entryuss index list - list entries using indexuss keys - list keysuss list - list a state entryuss load - restores a state database from a fileuss naslist - list NASesuss save - save the state database to a fileuss stats help - describe state database statisticsuss stats - list state database statistics uss stats reset - reset state database statisticsuss status - show state server replication stateuss stop key - stop a state entry by keyuss stop all - stop all entriesuss stop nas - stop all entries for a NAS


USS related AI commands (II) The USS related commands are:

uss counts [counter_name] To show counters and their values

uss list [entry] Shows the USS records of user sessiones, all or selected ones

==> uss list103 Multi-line response follows. entry: 127.0.0.1+20 ACTIVE complete mod: Mon Apr 10 15:30:30 CEST 2006 ev: Mon Apr 10 15:30:30 CEST 2006 exp: Tue Apr 11 16:30:31 CEST 2006 User-Name = "user1_basic" … Calling-Station-Id = "917410029" Called-Station-Id = "917434000" Framed-IP-Address = 91.87.84.19 NAS-Port-Type = Async

==> uss counts103 Multi-line response follows.Counter Value------- -----User-Name 1

==> uss counts User-Name103 Multi-line response follows.user1_basic 1

*


USS related AI commands (III) uss entry <key> [ key | complete | state | mode | ev | attrs ]

Shows a specific record, with all the values or only the desired ones

uss stop key <key> | nas <subkey> | all Simulates an Acct-Stop packet or an Acct-Off

–Marks the USS record(s) as INACTIVE and decrement the counters

Useful when the Acct-Stop or Acct-Off packet has got lost

==> uss entry 127.0.0.1+20 attrs103 Multi-line response follows. Acct-Status-Type = Start Acct-Session-Id = "1234" Calling-Station-Id = "917410029" Called-Station-Id = "917434000" Framed-IP-Address = 91.87.84.19 NAS-Port-Type = Async User-Name = "user1_basic"

==> uss stop key 127.0.0.1+22

100 Ok.


USS related AI commands (IV)

uss keys [subkey] Shows the ID of all (or selected) session records in USS [for a NAS]

Usually defined by: NAS_IP_Address+NAS_Port

uss naslist | subkeys Shows the subkeys of session records

Usually NAS_IP_Address

==> uss naslist

103 Multi-line response follows.

10.1.1.1

10.2.1.4

100 Ok.


USS related AI commands (V)

uss load | save <filename> To import/export all USS information from/to a file

Mainly for testing purposes or upgrades without losing USS info

When loading data, in-memory records are not deleted; the new ones are added We could load different records from different files

Counters are not saved to file. When loading, they are generated from USS records

The file has "stanza" format and is compatible between different releases

*

127.0.0.1+20 NAS=127.0.0.1 Session-Id=1234 State=waiting-for-start Complete=false Modify="2006/04/10 15:30:30.890" Event="2006/04/10 15:30:30.000" Timeout="2006/04/11 16:30:31.000"

User-Name = "user1_basic"

127.0.0.1+202 NAS=127.0.0.1 Session-Id=1236 State=active Complete=true Modify="2006/04/10 14:30:30.890" Event="2006/04/10 14:30:20.000" Timeout="2006/04/11 16:30:31.000"


127.0.0.1+20 NAS=127.0.0.1 Session-Id=1234 State=waiting-for-start Complete=false Modify="2006/04/10 15:30:30.890" Event="2006/04/10 15:30:30.000" Timeout="2006/04/11 16:30:31.000"


127.0.0.1+202 NAS=127.0.0.1 Session-Id=1236 State=active Complete=true Modify="2006/04/10 14:30:30.890" Event="2006/04/10 14:30:20.000" Timeout="2006/04/11 16:30:31.000"



USS related AI commands (V) uss stats

Statistical information about USS records and requests

uss stats help To describe the previous statistical

values

== > uss statsActive-Active = 0 Active-Active = 0 Active-Auth = 0 Active-Auth-Diff = 0 Active-Auth-Same = 0 Active-Auth-Unknown = 0 Active-Inactive = 0 WaitingStart-Update-Diff = 0 WaitingStart-Update-Same = 0 WaitingStart-Update-Unknown = 0 WaitingStart-WaitingStart = 0 Ok.


USS related AI commands (VI) uss index list [attr [value]]

Shows created indices, and their values

==> uss index list User-Name user1_basic entry: 127.0.0.1+20 ACTIVE INDEXED incomplete mod: 2007/11/28 11:41:17.084 ev: 2007/11/28 11:41:16.975 exp: <never> NAS-IP-Address = 127.0.0.1 NAS-Port = 20 Acct-Status-Type = Start Acct-Session-Id = "123" User-Name = "user1_basic" Full-User-Name = "user1_basic"


Sizing Guidelines for the USS host (I) The USS can optionally be run on a dedicated host

Not receiving regular auth/acct requests from NAS’s Only receiving requests from other VA Front Ends

The USS can be very CPU intensive, depending on: the # of events/sec the timers configured (SessionTimeout = -1 or not) PFs executed based on USS triggers Information read without events

StateServer plug-in with Event=None, for entries or counters

Indices read (QueryUss plug-in or the AI index command)


Sizing Guidelines for USS host (II) It may need a lot of RAM, depending on:

the # of records to be kept simultaneous user’s connections with InactiveTimeout = 0

Total available ports in the network, with InactiveTimeout = -1

the amount of AVPs stored in each record the amount of counters configured the amount of indices configured

The host needed (# and speed of CPUs & RAM) will greatly depend for every customer/site No simple guidelines can be given


RAM measurement The only way to foresee the average RAM/record, is by

simulating active sessions, with all the counters and indices that will be needed

Generate 1.000 active entries (e.g: with NAS simulator) and check how much memory has been needed Based on the “java memory” AI command

1000

)0()1000(/

RAMRAMrecordbytes

1000

)0()1000(/

RAMRAMrecordbytes


Special RAM configuration in the JVM Under special conditions of huge amount of RAM needed, some

extra parameters can be configured related the Java Virtual Machine Mainly to increase the initial & max. memory taken from the system

With a 32-bit JVM, the maximum RAM that can be handled is 2 GB

...com.lucent.aaa.PolicyServer -bg -cd –Xmx1500m –Xms1000m -XX:NewSize=100m-XX:MaxNewSize=100m -server -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFFE -Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFFE...

vaexec.cfg

*


Huge USS deployments:Partitioning based on a hashing criteria

If the amount of users is too big, or the performance in packets/sec. is too high,

the USS can be split in several smaller USS’s Each individual USS could also have redundancy: HA-USS Maybe only useful with 1 counter to count

Front End #1

Front End #M

USS_1

...USS_N

USS_2... ..Each USS (pair) store information for specific users /realms / CLID’s

The NAS doesn’t change anything, as it is unaware

there is even an USS

The Front End PF must know which user is stored

in which USS (pair)


Huge USS deployments:Partitioning based on a hashing criteria

The splitting criteria could be a hash algorithm to guarantee that: the same user (User-Name, Calling-Station-Id), or Realm, or Called-

Station-Id (DNIS or APN), or other thing that is counted, is always sent to the same USS

Different users are sent evenly (with a load balancing criteria) to different USS server

The Front Ends MUST know to which USS to send the request to

SelectUssBasedOnUserName Method-Type = ReadDelimitedText Method-On-Success = InvokeUssReadDelimitedText-Text =@USS_servers.txtReadDelimitedText-Map = "${user.Uss-Server} = ${1};"ReadDelimitedText-SelectMode = HASHCODEReadDelimitedText-SearchKey = ${packet.Base-User-Name}

InvokeUss Method-Type = StateClientStateClient-ServerAddress = ${user.Uss-Server}…

•Sample PF in the Front Ends•Sample PF in the Front Ends

1.1.1.1

1.1.1.2

1.1.1.3

•USS_servers.txt

universal state server (uss). all rights reserved © alcatel-lucent 2007 2 | uss module objetives...

Documents

uss uss operation

uss entry

uss introduction

uss checks

uss of startport

uss triggers

uss requests

uss transition