Передача по событию без агрегирования
Метод передачи информации учета по событию лишен недостатков предыдущего метода. Его суть заключается в том, что устройство, обладающее информацией учета, передает ее на сервер учета сразу же, как только эта информация готова к отправке. Так как передача выполняется без агрегирования информации учета, то есть в одном пакете передается информация об одном событии, задержка передачи информации является минимальной.
Вследствие этого такая модель распространена в распределенных сетях и в сетях с функциями роуминга. Именно эта модель учета применяется в протоколе кредитного контроля Diameter, а также в протоколе учета RADIUS и в функциях учета базового протокола Diameter. Понятно, что при передаче по событию без агрегирования объем сигнального трафика будет пропорционален количеству событий, подлежащих учету, так как передача каждого события требует отдельного пакета протокола учета.
Передача по событию с агрегированием
Передача по событию с агрегированием отличается от предыдущего метода тем, что информация учета о событиях передается не в отдельных пакетах, а в виде агрегированных пачек при накоплении сервером определенного количества данных или при срабатывании определенного таймера. Использование пачек приводит к большей задержке передачи информации учета, так как после генерации записи устройство будет хранить эту запись до тех пор, пока не накопит количество информации, достаточное для заполнения пачки.
Обратной стороной растущей задержки передачи данных является лучшая масштабируемость по сравнению с предыдущим методом, так как передача информации учета пачками создает меньший сигнальный трафик, чем передача отдельно данных о каждом событии учета. Очевидно, что это и предыдущее решения могут быть объединены: приоритетная информация может отправляться в отдельных пакетах, в то время как более толерантная к задержкам информация может отправляться на сервер учета агрегированными пачками.
Опрос по событию
Модель опроса по событию подразумевает уведомление сервера учета оборудованием, генерирующим учетные данные, о наличии данных учета, готовых к передаче. Уведомление может отправляться при накоплении определенной пачки агрегированных данных учета, при срабатывании определенного таймера или при наличии данных определенного типа.
Такая модель может использоваться в роуминговых сценариях и в распределенных сетях, так как сервер учета должен опрашивать только то оборудование, которое само уведомляет его о наличии информации учета. Тем не менее, задержка обработки информации при такой модели будет больше, чём при передаче по событию с агрегированием, так как она требует как минимум две сквозных передачи сообщений (уведомление и запрос информации учета).
Обобщенная архитектура ааа
Сервер аутентификации, авторизации и учета (AAA-сервер) является тем единым сетевым элементом, в котором выполняются указанные процедуры ААА.
Элементы обобщенной архитектуры ааа
На рис. 1.13 представлен центральный элемент ААА-архитектуры - обобщенный AAA-сервер, обрабатывающий запросы аутентификации, выполняющий авторизацию и накапливающий информацию учета. Обобщенный сервер ААА взаимодействует со следующими элементами общей инфраструктуры ААА:
Модуль приложения - устройство, которое управляет ресурсами услуги и выполняет конфигурационные функции оборудования, осуществляющего предоставление услуги. Модуль приложения может участвовать в процедуре авторизации, так как ему доступна специфическая для запрашиваемой услуги информация, которая может потребоваться в процессе авторизации. Эта информация может быть получена путем обращения к базе данных приложения, а также путем интерпретации специфических для услуги параметров обслуживания. Следует отметить, что специфическая для услуги информация не обязательно должна быть «понятна» обобщенному AAA-серверу, так как во многих случаях она является уникальной для услуги, и «научить» сервер распознавать информацию, специфическую для большого числа услуг, не представляется возможным.
Вместо этого серверу достаточно знать, к какому модулю приложения следует обратиться при авторизации того или много запроса, для чего в запрос авторизации в том или ином виде должен включаться идентификатор модуля приложения.
Рис.
1.13.
Элементы обобщенной архитектуры ААА
Хранилище событий и политики. В целях аудита обобщенный ААА-сервер должен сохранять информацию о событиях с привязкой данных о них ко времени в определенном хранилище. Подобным хранилищем в AAA- архитектуре выступает хранилище событий и политики. Как следует из названия, еще одной функцией этого элемента является хранение разной политики доступа, то есть разных правил авторизации пользователя при предоставлении ему доступа к имеющимся услугам и ресурсам.
Хранилище информации об услуге - база данных, содержащая сведения об услуге определенного типа. Модуль приложения при поступлении на него запроса авторизации взаимодействует с этим хранилищем для получения данных, необходимых для обслуживания запроса.
Типичная последовательность обслуживания запроса авторизации в рамках обобщенной архитектуры ААА будет выглядеть следующим образом:
пользователь или сетевое оборудование, действующее по запросу пользователя, сформирует запрос авторизации доступа к услуге и отправит его на ААА-сервер;
для проведения аутентификации пользователя ААА-сервер обратится к базе данных пользователей, а также к хранилищу политики и событий для регистрации запроса и определения правил авторизации;
для авторизации компонентов, относящихся к информации, специфической для приложения, отправляется запрос к модулю соответствующего приложения. Для авторизации компонентов, требующих обработки другими AAA-серверами, запрос будет переправлен к соответствующим серверам;
результаты авторизации, а также информация, необходимая для первоначальной конфигурации услуги, передаются на сетевой элемент, отправивший запрос авторизации.