Обещал рассказать про DIAMETER. Начнем, но должен предупредить, писать буду вольным текстом, высока вероятность упрощения и опущения ряда важных моментов. Цель — обзорная статья и самое первое знакомство с протоколом, а детали можно прочитать в стандартах. Примеры будут из сотовой связи.
Введение
Первый документ, который описывал требования к новому протоколу был опубликован в 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, в котором ничего кардинально не изменилось, обратная совместимость сохранена, изменения описаны в самом документе и выходят за рамки статьи.
Важной особенностью протокола является его расширяемость и возможность создания не только собственных атрибутов, но и приложений. Примером приложения является RFC 4006 Diameter Credit Control Application, разработка которого началась в 2003 году, а финальный RFC вышел в 2005. Далее комитет 3GPP оттолкнулся от RCF 3588 и создал ряд приложений, например 3GPP 32.299 Diameter charging applications, который является следствием развития RFC 4006 DCCA.
Для рассмотрения возможностей DIAMETER хватит и этих трех источников, во многом это будет пересказ рекомендаций. Ниже я приведу ссылки на некоторые открытые спецификации. Помимо открытых, я сталкивался с проприетарными реализациями приложений DIAMETER. В итоге реальное количество реализаций, версий и приложений DIAMETER оценить не могу. Но могу точно сказать, что сегодня, для оказания почти любому абоненту услуг мобильной связи DIAMETER применяется в том или ином виде. А с развитием 3G, IMS, LTE процент проникновения будет стремиться к 100%.
Базовый протокол
Базовый протокол реализует требования к протоколам ААА, детали которых отражены в RFC2989, и описывает процесс установления соединения, проверку совместимости, правила отправки сообщений и их маршрутизации, разрыв соединения.
В качестве транспорта могут использоваться TCP и SCTP. Безопасность протокола должна обеспечиваться на транспортном уровне, в рекомендациях также указано, что протокол не должен использоваться без TLS, DTLS или IPsec. В доверенной сети, разумеется, возможно обойтись и без них, в частности, если внутреннюю сеть предприятия можно считать надежной.
Спецификация определяет несколько типов узлов DIAMETER.
Для понимания роли узлов необходимо ввести две термина, которые более подробно будут рассмотрены ниже.
Сессия — контролирует состояние абонента и включает в себя те и только те сообщения, которые относятся к отдельно взятому абоненту.
Соединение — контролирует состояние связи между узлами DIAMETER.
Сессия определяется AVP SessionID, и этот идентификатор является сквозным для всех узлов, принимающих участие в обработке сессии абонента.
Клиент
Клиентом обычно выступает сетевое устройство, которое непосредственно обрабатывает трафик абонента.
Сервер
Роль сервера вполне понятна, он должен контролировать состояние абонентских сессий.
Агент.
DIAMETER агенты являются промежуточными узлами между клиентом и сервером и выполняют функции управления трафиком. Например, они могут агрегировать сообщения от устройств на одной площадке, выполнять роль балансировщика нагрузки, модифицировать пакеты DIAMЕTER, выступать в роли шлюзов безопасности при переходе из доверенной сети в публичную.
Функционально агенты делятся на несколько типов.
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, поддержка которых реализована, т.к. только в этом случае агент сможет корректно обработать входящее сообщение.
Структура пакетов
Пакеты традиционно состоят из заголовка и полезной нагрузки (в виде AVP — Attribute-Value Pair).
Назначение первых трех полей понятно.
Command-Code — код команды, которая передается в пакете
Application-Id — указатель на тип приложения
Hop-by-Hop Identifier — уникальный номер запроса в рамках соединения, ответ должен иметь тот же самый номер, это поле может модифицироваться при необходимости агентами.
End-to-End Identifier — еще один идентификатор запроса, только в отличие от Hop-by-Hop, он должен оставаться уникальным в рамках сессии, и агенты не должны его изменять.
Далее идет полезная нагрузка в виде AVP (Attribute Value Pairs).
Структура AVP тоже очень проста.
AVP Code — код атрибута, описывается в рекомендации.
За кодом идут служебные биты, длина данных и необязательное поле Vendor-ID.
После идут сами данные с определенной длиной.
Данные в свою очередь могут содержать другие наборы AVP, структура AVP отлично описывается ASN.1.
На этом закончу.
В следующей части посмотрим на то, как протокол работает, вместо описательной части разберем порядок обмена сообщений по этапам: установка соединения, обработка DIAMETER сессий и завершение соединения. И самое интересное — рассмотрим расширяемость протокола и его приложения.
Автор: strib
