Пользователь
0,0
рейтинг
27 декабря 2012 в 23:31

Разработка → Diameter. Базовый протокол. Часть 1

Обещал рассказать про Diameter. Начнем, но должен предупредить, писать буду вольным текстом, высока вероятность упрощения и опущения ряда важных моментов. Цель — обзорная статья и самое первое знакомство с протоколом, а детали можно прочитать в стандартах. Примеры будут из сотовой связи.

UPDATE: По просьбе ploop, спасибо за ценное замечание. 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, в котором ничего кардинально не изменилось, обратная совместимость сохранена, изменения описаны в самом документе и выходят за рамки статьи.

Важной особенностью протокола является его расширяемость и возможность создания не только собственных атрибутов, но и приложений. Примером приложения является 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 агенты являются промежуточными узлами между клиентом и сервером и выполняют функции управления трафиком. Например, они могут агрегировать сообщения от устройств на одной площадке, выполнять роль балансировщика нагрузки, модифицировать пакеты Diameter, выступать в роли шлюзов безопасности при переходе из доверенной сети в публичную.

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

Relay agent (DRL)

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

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

Proxy agent.

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

Relay\Proxy

Сессия, соединение, Relay\Proxy

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 сессий и завершение соединения. И самое интересное — рассмотрим расширяемость протокола и его приложения.
Надо ли изменять уровень подачи материала?

Проголосовало 155 человек. Воздержалось 38 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Антон Воронцов @strib
карма
38,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (14)

  • +3
    Простите, я немного не по теме, но вижу опрос в конце статьи, значит вам не безразлично: пожалуйста, описывайте о чём идёт речь в начале топика. Я прочитал два абзаца, прежде, чем догадался глянуть на теги. Ну не знал я чисто по названиям, что эти протоколы используются в системах сбора информации и биллинга (кстати, из вики), а в подробностях эти темы меня пока не очень интересуют…
    • 0
      Добавил, спасибо.
  • +1
    Я как полномочный представитель граммар в этом топике намекну очень очень тонко:
    RADIUS — это аббревиатура.
    Diameter — нет
    Я думаю, многие уже поняли прелести RADIUS, как UDP-based протокола, и всё ждут, когда же ему на замену придёт надёжность TCP
    • +1
      Это только одно из различий. UDP тоже неплохо работает, а для телекома большую ценность имеет поддкржка SCTP. Ценность diameter больше в развитии функционала, увеличении размера полезной нагрузки, стандартизации failover, не надо генерировать фейковые запросы а можно использовать стандартную команду, механизмах расширяемости, поведение агентов стандартизировали.
      • 0
        SCTP для телекома? Для телекома нужна прибыль и стабильность, а не быть кому-то тестером нового протокола.
        • 0
          Это даже не смешно. SCTP давно и успешно используется в телекоме, уже лет 5 как. Посмотрите SIGTRAN.
      • 0
        Думаю, преимущества Diameter перед RADIUS нужно было бы где-то в начале топика привести. Я вот прочитал несколько абзацев, преимуществ не нашел, и дальше желание читать просто отпало.
        • 0
          Да, наверное интереснее будет. Дополню. Спасибо.
  • 0
    Эх, как-то внезапно статья закончилась.
    • 0
      Вторая часть получается большой и технической. Это пробная, захотелось мне оценить интерес и реакцию аудитории.
      • 0
        Буду рад почитать, тема мне крайне интересна, так как реализовал свой радиус сервер и стек сопутствующих протоколов. Интересно узнать, как там всё в диаметре работает.
        • 0
          На праздниках надеюсь дописать, очень не хочется скатываться к переводу RFC и прочих рекомендаций.
  • 0
    В целом статья очень интересная. Я бы ещё добавил про главные отличия RADIUS от Diameter.
  • 0
    Было бы неплохо понять, чем не угодил RADIUS, что начали развивать Diameter. Часть в комментариях нашел (failover, расширение приложений и т.д.) — неплохо бы это поднять в статью в один из первых абзацев.

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