Экзамен вопросы и ответы / 2_12

Протокол Diameter.

Diameter – это протокол семейства AAA, и является развитием RADIUS. Предназначен он, главным образом, для оценки услуг в сетях связи. В частности, в сетях 3G с его помощью происходит оценка услуг передачи данных, а в IMS\LTE протокол является одним из основных управляющих элементов.

История.

Первый документ, который описывал требования к новому протоколу был опубликован в 1998 году в рамках IETF, его авторами стали Pat R. Calhoun (Sun),Glen Zorn (MS), Ping Pan (IBM).

Коллектив авторов черновика менялся от версии к версии, они переходили из одной компании в другую, и наконец, в 2003 году был выпущен RFC 3588, но всегда первым стоит имя Pat R. Calhoun. В 3588 была описана базовая модель Diameter, которая включала в себя функционал Accounting и позволяла разработчикам создавать на ее основе новые приложения для протокола. И совсем недавно, в октябре 2012 года документ RFC 3588 был признан устаревшим, и его сменил RFC6733, в котором ничего кардинально не изменилось, обратная совместимость сохранена, изменения описаны в самом документе.

Важной особенностью протокола является его расширяемость и возможность создания не только собственных атрибутов, но и приложений.

Базовый протокол.

Базовый протокол реализует требования к протоколам ААА, детали которых отражены в RFC2989, и описывает процесс установления соединения, проверку совместимости, правила отправки сообщений и их маршрутизации, разрыв соединения.

В качестве транспорта могут использоваться TCP и SCTP. Безопасность протокола должна обеспечиваться на транспортном уровне, в рекомендациях также указано, что протокол не должен использоваться без TLS, DTLS или IPsec. В доверенной сети, разумеется, возможно обойтись и без них, в частности, если внутреннюю сеть предприятия можно считать надежной.

Спецификация определяет несколько типов узлов Diameter.

Сессия — контролирует состояние абонента и включает в себя те и только те сообщения, которые относятся к отдельно взятому абоненту.

Соединение — контролирует состояние связи между узлами Diameter.

Сессия определяется AVP SessionID, и этот идентификатор является сквозным для всех узлов, принимающих участие в обработке сессии абонента.

Клиент

Клиентом обычно выступает сетевое устройство, которое непосредственно обрабатывает трафик абонента.

Сервер

Роль сервера вполне понятна, он должен контролировать состояние абонентских сессий.

Агент.

DIAMETER агенты являются промежуточными узлами между клиентом и сервером и выполняют функции управления трафиком. Например, они могут агрегировать сообщения от устройств на одной площадке, выполнять роль балансировщика нагрузки, модифицировать пакеты Diameter, выступать в роли шлюзов безопасности при переходе из доверенной сети в публичную.

Функционально агенты делятся на несколько типов.

Relay agent (DRL) Узлы данного типа принимают Diameter-сообщения от сетевых устройств и перенаправляют их на следующие узлы на основании данных, содержащихся в сообщениях на основании Realm и списка известных соседей. Relay могут быть использованы для агрегации сообщений с множества узлов, расположенных в одной географической зоне. Relay никак не модифицируют значимые поля в теле сообщения, поэтому они могут работать любыми типами приложений Diameter, тем не менее, при установлении соединения, они должны анонсировать Relay Application Id.

Proxy agent. Proxy очень похожи на Relay, но умеют модифицировать полезную нагрузку Diameter-сообщения. Например, контролировать доступ к определенным сервисам, модифицировать значения полей и тд. Чаще всего Relay и Proxy объединяют в одну сущность, т.к. Proxy без правил преобразования является Relay-агентом.

Redirect agent (DRD) DRD используются в том случае, если правила маршрутизации Diameter-сообщений должны контролироваться из одной точки. DRD получает запрос, определяет узел, на который его надо отправить и сообщает DRL куда его надо перенаправить.

Translation Agents (TLA) Класс узлов Diameter — Трансляторы протоколов. Применяются они в том случае, если физические устройства несовместимы на уровне AAA протоколов. Например, реализовать преобразование из RADIUS в Diameter и обратно. Или поддержать преобразование между 2-мя несовместимыми версиями Diameter. TLA должны обеспечивать транзакционность и хранение состояния сессии во время ее обработки. TLA должны анонсировать только те ApplicationID, поддержка которых реализована, т.к. только в этом случае агент сможет корректно обработать входящее сообщение.

Структура пакетов.

Назначение первых трех полей понятно. Command-Code — код команды, которая передается в пакете Application-Id — указатель на тип приложения Hop-by-Hop Identifier — уникальный номер запроса в рамках соединения, ответ должен иметь тот же самый номер, это поле может модифицироваться при необходимости агентами. End-to-End Identifier — еще один идентификатор запроса, только в отличие от Hop-by-Hop, он должен оставаться уникальным в рамках сессии, и агенты не должны его изменять. Далее идет полезная нагрузка в виде AVP (Attribute Value Pairs).

На этом всё)