Содержание


Введение в Diameter

AAA-протокол следующего поколения

Comments

Протокол Diameter берет свое начало из протокола RADIUS (значительно улучшая его различные аспекты) и предлагается, в основном, для использования в качестве протокола следующего поколения для аутентификации, авторизации и учета (Authentication, Authorization, Accounting - AAA). Протокол Diameter широко использовался в IMS-архитектуре для обмена AAA-информацией между IMS-объектами. Поскольку IMS-система может быть следующим большим направлением в отрасли телекоммуникаций, мы считаем, что ясное понимание протокола Diameter необходимо для понимания сущности IMS-архитектуры. В данной статье предлагается обзор протокола Diameter и его работы. Для разработчиков, интересующихся работой AAA в IMS или реализующих Diameter-приложения, данная статья является хорошей стартовой точкой.

С появлением новых технологий и приложений, таких как беспроводные сети и Mobile IP, требования к аутентификации и авторизации значительно повысились, а механизмы контроля доступа стали более сложными, чем когда-либо. Существующего протокола RADIUS (Remote Authentication Dial-In User Service) может быть недостаточно для удовлетворения этих новых требований; необходим новый протокол, обладающий новыми возможностями контроля доступа, сохраняющий в то же время гибкость для последующих расширений. Вот здесь и может понадобиться протокол Diameter.

Обратите внимание, пожалуйста, на то, что данная статья предоставляет только обзор Diameter и не рассматривает все подробности протокола. Если вы хотите пойти дальше и реализовать базовый протокол Diameter, обратитесь к RFC3588 (см. раздел "Ресурсы") за деталями. Поэтому, поскольку эта статья, в основном, рассматривает базовый протокол, Diameter будет ссылаться на Diameter Base Protocol.

AAA и Diameter

Перед погружением в детали протокола, давайте посмотрим, зачем необходим AAA-протокол. В прежние времена люди дозванивались к своим провайдерам Интернет-служб (Internet Service provider - ISP), предоставляя свой ID и пароль для доступа к серверу, который затем выполнял аутентификацию пользователя перед предоставлением Интернет-доступа. В большинстве случаев информация, удостоверяющая личность пользователя, хранилась на сервере доступа не в открытом виде, а в более защищенных местах, например, на LDAP-сервере (Lightweight Directory Access Protocol) за брандмауэром. Следовательно, был необходим стандартизованный протокол между сервером доступа и репозиторием с пользовательской информацией для обмена ею с целью аутентификации, авторизации и учета. Для обеспечения простого, но эффективного способа предоставления этих AAA-возможностей, был разработан протокол RADIUS.

С развитием сетевых приложений и протоколов для аутентификации пользователей необходимы новые требования и механизмы. Эти требования суммируются в документе RFC2989 (см. раздел "Ресурсы"), который включает такие темы как восстановление после сбоев, безопасность и возможности аудита. Хотя существует несколько вспомогательных протоколов, предназначенных для расширения возможностей протокола RADIUS, ожидался более гибкий и общий протокол. На основе RADIUS был создан протокол Diameter, предназначенный для того, чтобы стать общей структурной основой для последующих AAA-приложений.

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

Рисунок 1. Взаимосвязь между базовым протоколом Diameter и различными Diameter-приложениями
Взаимосвязь между базовым протоколом Diameter и различными Diameter-приложениями

Узлы и агенты протокола Diameter

Diameter имеет одноранговую архитектуру (Peer-To-Peer), и каждый хост, реализующий протокол Diameter, может выступать либо клиентом, либо сервером, в зависимости от сетевой инфраструктуры. Поэтому термин Diameter-узел используется для ссылки на Diameter-клиент, на Diameter-сервер или на Diameter-агент, с которым мы познакомимся позже. Узел протокола Diameter, принимающий пользовательский запрос на соединение, выступает как Diameter-клиент. В большинстве случаев Diameter-клиентом будет Network Access Server. После сбора информации, удостоверяющей пользователя, такой как имя пользователя и пароль, он передаст сообщение запроса на доступ одному Diameter-узлу, обслуживающему запрос. Для простоты мы предполагаем, что это Diameter-сервер. Diameter-сервер выполняет аутентификацию пользователя на основе предоставленной информации. Если процесс аутентификации выполняется успешно, в ответное сообщение включаются полномочия пользователя, и это сообщение передается обратно соответствующему Diameter-клиенту. В противном случае передается сообщение об отказе.

Хотя только что описанная архитектура выглядит традиционной архитектурой клиент-сервер, узел, выступающий в роли Diameter-сервера, для некоторых запросов может, на самом деле, в некоторых ситуациях выступать как Diameter-клиент; протокол Diameter является, в действительности, одноранговым протоколом в более широком смысле. Кроме того, в протоколе четко определен специальный Diameter-узел, называемый Diameter-агентом. Обычно существует три типа Diameter-агентов:

Relay Agent (агент-ретранслятор)

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

Proxy Agent (прокси-агент)

Proxy Agent может также использоваться для перенаправления сообщений, но, в отличие от Relay Agent, Proxy Agent может изменить содержимое сообщения и, следовательно, предоставлять дополнительные службы, применять правила для различных сообщений или выполнять задачи администрирования для различных областей. На рисунке 2 показано, как используется Proxy Agent для перенаправления сообщения в другой домен. Если Proxy Agent не изменяет содержимое оригинального запроса, в этом сценарии достаточно было бы использования Relay Agent.

Рисунок 2. Diameter Proxy Agent
Diameter Proxy Agent
Diameter Proxy Agent

Redirect Agent (агент перенаправления)

Redirect Agent выступает в роли централизованного репозитория конфигураций для других Diameter-узлов. Принимая сообщение, он проверяет свою таблицу маршрутизации и возвращает ответное сообщение вместе с информацией о перенаправлении оригинальному отправителю сообщения. Это могло бы быть очень полезно для других Diameter-узлов, поскольку им не нужно хранить список записей о маршрутизации локально, и они могли бы, при необходимости, искать Redirect Agent. На рисунке 3 изображена работа Redirect Agent. Сценарий, показанный на рисунке 3, в основном идентичен сценарию, показанному на рисунке 2, но в этот раз Proxy Agent не знает адреса связанного Diameter-узла в example.com. Следовательно, он ищет информацию в Redirect Agent своей собственной области для получения адреса.

Рисунок 3. Diameter Redirect Agent
Diameter Redirect Agent
Diameter Redirect Agent

Translation Agent (агент преобразования)

Кроме этих агентов существует специальный агент, называемый Translation Agent. Обязанностью этого агента, как вы возможно догадались, является преобразование сообщения из одного AAA-протокола в другой. Translation Agent полезен для компании, или провайдера служб для интеграции пользовательской базы данных двух прикладных доменов, сохраняя их оригинальные AAA-протоколы. Другая ситуация: компания хочет выполнить миграцию на протокол Diameter, но этот процесс состоит из нескольких фаз. Translation Agent мог бы обеспечить обратную совместимость для плавной миграции. На рисунке 4 показано, как один агент преобразовывает протокол RADIUS в протокол Diameter, но, естественно, возможны также и другие типы преобразования протоколов (например, Diameter в RADIUS, Diameter в TACACS+).

Рисунок 4. Diameter Translation Agent
Diameter Translation Agent
Diameter Translation Agent

Diameter-сообщения

Diameter-сообщение - это элементарный модуль для передачи команды или доставки уведомления другим Diameter-узлам. Для различных целей протокол Diameter имеет различные типы Diameter-сообщений, которые определяются их кодом команды. Например, сообщение Accounting-Request распознает, что сообщение содержит информацию об учетной записи, а сообщение Capability-Exchange-Request распознает, что сообщение содержит информацию о возможностях Diameter-узла, передающего сообщение.

Поскольку тип обмена сообщениями в Diameter является синхронным, каждое сообщение имеет своего соответствующего двойника, который использует такой же код команды. В обоих предыдущих примерах приемник сообщения Accounting-Request подготавливает сообщение Account-Answer и передает его оригинальному отправителю.

Код команды используется для идентификации намерения сообщения, но реальные данные передаются в виде набора пар атрибут-значение (Attribute-Value-Pair - AVP). Протокол Diameter имеет предопределенный набор общих атрибутов и назначает каждому атрибуту соответствующую семантику. Эти AVP передают подробности AAA (такую информацию как маршрутизация, безопасность и возможности) между двумя Diameter-узлами. Кроме того, каждая пара AVP ассоциируется с форматом AVP Data Format, который определен в протоколе Diameter (например, OctetString, Integer32), поэтому значение каждого атрибута должно следовать формату данных.

На рисунке 5 изображена взаимосвязь между Diameter-сообщениями и их AVP. Дополнительные подробности по каждой части рисунка 5 можно найти в главе 3 и главе 4 базового протокола Diameter.

Рисунок 5. Diameter Packet Format
Diameter Packet Format
Diameter Packet Format

В таблице 1 перечислены все сообщения, определенные в базовом протоколе Diameter:

Таблица 1. Сообщения, определенные в базовом протоколе Diameter
Название сообщенияАббревиатураКод команды
Abort-Session-Request (прекращение-сессия-запрос)ASR274
Abort-Session-Answer (прекращение-сессия-ответ)ASA274
Accounting-Request (учет-запрос)ACR271
Accounting-Answer (учет-ответ)ACA271
Capabilities-Exchanging-Request (возможности-обмен-запрос)CER257
Capabilities-Exchanging-Answer (возможности-обмен-ответ)CEA257
Device-Watchdog-Request (устройство-сторожевой таймер-запрос)DWR280
Device-Watchdog-Answer (устройство-сторожевой таймер-ответ)DWA280
Disconnect-Peer-Request (отсоединение-равноправный узел-запрос)DPR282
Disconnect-Peer-Answer (отсоединение-равноправный узел-ответ)DPA282
Re-Auth-Request (повторная-аутентификация-запрос)RAR258
Re-Auth-Answer (повторная-аутентификация-ответ)RAA258
Session-Termination-Request (сессия-завершение-запрос)STR275
Session-Termination-Answer STA (сессия-завершение-ответ)STA275

Обнаружение однорангового узла

До появления Diameter системные администраторы должны были вручную настраивать в Network Access Server месторасположение его AAA-сервера, для того чтобы при входе пользователя устройство могло передать запрос по корректному адресу. Однако такая конфигурация могла быть трудоемкой для сложных конфигураций сети. Одним из замечательных улучшений в Diameter является его возможность искать одноранговые узлы. Кроме ручной настройки, которая должны поддерживаться всеми Diameter-узлами, для динамического обнаружения однорангового узла могут поддерживаться два параметра - SRVLOC и DNS. В основе этого лежит концепция, что для Diameter-сервер (или Diameter-агент) необходимо сообщать, какие приложения они поддерживают, а также обеспечиваемый уровень безопасности.

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

Для Diameter-узла, обнаруженное месторасположение однорангового узла и конфигурация по маршрутизации могут быть записаны локально при помощи двух Diameter-таблиц:

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

Peer Routing Table. В этой таблице существует четыре важных столбца, требующих дополнительного внимания для маршрутизации сообщений. Первыми двумя являются Realm Name и Application Name, которые выступают как критерии выбора для маршрутизации сообщений. Третий столбец - это действие, которое нужно выполнить для целевого сообщения, которым может быть PROXY, RELAY, REDIRECT или LOCAL. LOCAL означает, что сообщение должно быть обработано локально вместо перенаправления к другим узлам.

Последний столбец - это ссылка на запись в Peer Table, используемая для определения реального адреса хоста адресата. Обратите внимание на то, что Peer Routing Table будет всегда содержать запись по умолчанию для сообщений, не отвечающих критерию маршрутизации.

Соединение и сессия

После обнаружения соответствующего однорангового узла следующим шагом является установка соединения с ним. Соединение - это физическая связь между двумя Diameter-узлами. Для протокола Diameter является обязательным возможность работы по TCP или SCTP. В сравнении с UDP, используемым в RADIUS, эти два протокола обеспечивают более надежную передачу, что является критичным для приложений, обменивающихся информацией, связанной с учетными записями.

Исходя из того, что Diameter, в основном, имеет одноранговую архитектуру, для конкретного узла можно было бы установить более одного соединения. Протокол Diameter явно определяет, что Diameter-узел как минимум должен устанавливать соединение с двумя одноранговыми узлами в каждой области, которые выступают как первичные (primary) и вторичные контакты (secondary contact). Естественно, что при необходимости могли бы быть установлены дополнительные соединения.

По сравнению с соединением сессия представляет собой логическое соединение между двумя Diameter-узлами и может пересекать несколько физических соединений. Сессия – это, на самом деле, концепция последовательности активностей во временном промежутке; она относится к взаимодействиям между Diameter-клиентом и Diameter-сервером в течение определенного периода времени. Каждая сессия в протоколе Diameter ассоциируется с генерируемым клиентом идентификатором Session-Id, который уникален глобально и постоянно. Session-Id используется затем для идентификации конкретной сессии во время дальнейшего обмена информацией.

На рисунке 6 показаны концепции соединения и сессии:

Рисунок 6. Сессия и соединение в Diameter
Сессия и соединение в Diameter
Сессия и соединение в Diameter

Инициирование сессии

Как и в большинстве моделей взаимодействия клиент-сервер, Diameter-сессия начинается с передачи сообщения запроса от клиента серверу. В контексте Diameter Diameter-клиент передаст сообщение auth-request, содержащее уникальный Session-Id, Diameter-серверу (или Diameter-прокси, если необходимо перенаправление сообщения). Обратите внимание на то, что используемые для аутентификации и авторизации пары AVP зависят от приложения и что они не определены в базовом протоколе.

После приема сообщения auth-request Diameter-сервер может включить Authorization-Lifetime AVP в ответное сообщение. Эта пара AVP используется для указания количества времени в секундах, которое требуется Diameter-клиенту для повторной авторизации. После истечения лимита времени и допустимого Auth-Grace-Period, Diameter-сервер будет удалять сессию из своего списка сессий и освобождать все ресурсы, выделенные для нее.

Сессия

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

Кроме того, для догадки об исключительном закрытии сессии используется пара AVP Origin-State-Id. Отправитель запроса будет включать эту AVP, и поскольку необходимо, чтобы это значение монотонно увеличивалось, получатель запроса может легко догадаться о том, что предыдущая сессия была закрыта либо по аварийному завершению работы устройства доступа, либо из-за каких-либо других исключительных ситуаций. Получатель запроса может затем удалить сессию из своего списка, освободить ресурсы и, возможно, уведомить свои Diameter-серверы, если он работает как прокси-сервер.

Завершение сессии

Сообщения о завершении сессии используются только в контексте аутентификации и авторизации и только тогда, когда поддерживалось состояние сессии. Для служб работы с учетными записями вместо этого сообщения используется сообщение об остановке учета.

Сообщение о завершении сессии может быть инициировано либо Diameter-клиентом, либо Diameter-сервером. Когда Diamete-клиент полагает, что нужно закрыть сессию, он передает сообщение Session-Termination-Request Diameter-серверу. В этот запрос включается AVP Termination-Clause, указывающая Diameter-серверу причину, почему сессия должна быть закрыта. В свою очередь, если Diameter-сервер обнаруживает, что сессия должна быть закрыта (возможно, из-за того, что клиент вышел за пределы предоставленного кредита, или просто для административных целей), Diameter-сервер передает сообщение Abort-Session-Request Diameter-клиенту. Однако, в зависимости от различной политики или сценариев использования, Diameter-клиент может решить не закрывать сессию, даже при получении сообщения от сервера о ее завершении, и позволить пользователю продолжать пользоваться своим сервисом.

AAA в Diameter

Аутентификация и авторизация

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

Например, сообщение AA-Request используется для передачи информации об аутентификации и авторизации в NAS-приложение, в то время как в SIP-приложении (см. раздел "Ресурсы") сообщение называется User-Authorization-Request.

Учет

В отличие от аутентификации и авторизации, поведение и сообщение для учета четко определено. Учет в Diameter, по существу, следует модели управления сервером. Это означает, что устройство, генерирующее учетные записи, следует указаниям сервера авторизации.

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

Вообще говоря, в зависимости от предоставляемой службы существует два типа учетных записей: Для служб, основанных на единовременном инициировании, используется EVENT_RECORD. Однако если служба предоставляется в течение измеримого периода, могут применяться типы учетных записей START_RECORD, INTERIM_RECORD и STOP_RECORD для отметки начала, обновления и конца сессии.

Для предотвращения дублирования учетных записей каждому сообщению назначается AVP Session-Id вместе с AVP Accounting-Record-Number. Поскольку эта комбинация может уникально идентифицировать учетную запись, Diameter-узел, выступающий в роли Diameter-агента, может использовать эту информацию для обнаружения дублирования учетных сообщений, передаваемых Diameter-серверу, устраняя, таким образом, нежелательную обработку Diameter-сервером. Эта ситуация может возникнуть из-за временных сетевых проблем или останова клиента. Кроме того, Diameter-клиент должен хранить локальный кэш исходящих учетных сообщений до получения подтверждающего сообщения.

Обработка ошибок

Ошибки в Diameter делятся на две категории: ошибки протокола и ошибки приложения. К ошибкам протокола относится неправильная работа используемого для обмена Diameter-сообщениями протокола, возможно некорректная маршрутизация или временная авария на сервере.

Ошибки приложения, с другой стороны, являются результатом неполадок в самом протоколе Diameter, и существует множество источников этих ошибок. Например, если отсутствует обязательный AVP в конкретной Diameter-команде, возвращается код ошибки DIAMETER_MISSING_AVP. Каждое ответное сообщение в Diameter содержит AVP Result-Code, и приемник ответного сообщения может проверить этот AVP и определить успешность обработки предыдущего сообщения.

Для поддержки раннего обнаружения сбоев в соединении протокол Diameter определяет сообщение Device-Dogwatch-Request. Когда два соединенных Diameter-узла не обмениваются сообщениями определенный промежуток времени, это сообщение посылается любым из этих узлов для обнаружения сетевых проблем. Обсуждение алгоритма обнаружения ошибок транспортировки выходит за рамки данной статьи, но если вы интересуетесь этой темой, то можете обратиться к документу "AAA Transport Profile" (см. раздел "Ресурсы") для получения дополнительной информации.

Протокол Diameter использует ту же семантику определения кодов ошибок, что и протокол HTTP. Статус сообщения может быть легко идентифицирован путем проверки первой цифры кода возврата:

  1. 1xxx: означает, что запрос не может быть удовлетворен, и для предоставления службы необходима дополнительная информация.
  2. 2xxx: означает, что запрос был обработан успешно.
  3. 3xxx: означает, что произошла ошибка во время передачи Diameter-сообщения. Обычно Diameter-прокси должен попытаться исправить эту проблему, перенаправив сообщение на другой Diameter-сервер, либо сохранив сообщение в локальном кэше и передав его позже повторно.
  4. 4xxx: означает, что запрошенное сообщение не может быть обработано в данный момент времени, но оно может быть обработано позже. Например, когда сервер временно не имеет достаточное количество свободной физической памяти для обработки любых входящих запросов.
  5. 5xxx: означает, что произошла ошибка приложения по время обработки сервером сообщения запроса. Отправитель не должен пытаться отправлять это сообщение повторно. Вместо этого, он должен определить причину ошибки приложения, проверив код ошибки, и затем устранить проблему.

Кроме AVP Return-Code отправитель сообщения для обработки ошибки может также проверить другие AVP, несущие дополнительную информацию. AVP Error-Message содержит сообщение об ошибке в удобном для чтения формате, которое может использоваться для определения реальной причины ошибки. AVP Error-Reporting-Host содержит код, идентичный коду Result-Code, генерируемому хостом. Этот AVP очень полезен при исправлении ошибок для нахождения места возникновения проблемы. Failed-AVP содержит группу пар AVP, вызвавших исключительную ситуацию.

После обнаружения ошибки отправляющий узел передает все задержанные сообщения альтернативному Diameter-узлу. Этот процесс называется FailOver. Задержанным называется сообщение, которое было передано, но пока еще не был принят соответствующий ответ. Каждый Diameter-узел должен хранить локальную копию исходящих сообщений. Для ссылки на исходящие сообщения для каждого целевого однорангового узла внутри каждого сообщения используется Hop-to-Hop Identification (идентификация узел-узел). Однако этот процесс может вызвать прием Diameter-узлом идентичного сообщения более одного раза. В результате Diameter-узел должен использовать комбинацию заголовка сообщения End-to-End Identification и AVP Original-Host для идентификации сообщения, приходящего с конкретного Diameter-узла.

В таблицу 2 сведены некоторые значительные отличия между протоколами Diameter и RADIUS:

Таблица 2. Сравнение протоколов Diameter и RADIUS
DiameterRADIUS
Транспортный протокол Ориентированные на соединение протоколы (TCP и SCTP) Протокол без установления соединения (UDP)
Защита Hop-to-Hop, End-to-EndHop-to-Hop
Поддерживаемые агентыRelay, Proxy, Redirect, TranslationПолная поддержка, означающая, что поведение агента может быть реализовано на RADIUS-сервере
Возможности по согласованиюСогласовывает поддерживаемые приложения и уровень безопасностиНе поддерживается
Обнаружение узловСтатическая конфигурация и динамическое обнаружениеСтатическая конфигурация
Сообщение инициации сервераПоддерживается. Например, сообщение повторной аутентификации, завершения сессииНе поддерживается
Максимальный размер данных атрибутов16,777,215 октетов255 октетов
Поддержка сторонних производителейПоддерживает сторонние атрибуты и сообщенияПоддерживает только сторонние атрибуты

В заключение

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

После прочтения данной статьи вы должны понимать работу протокола Diameter и иметь базовые знания для более подробного исследования.

В дополнение к SIP Diameter является еще одним основным протоколом, использующимся в архитектуре IP Multimedia Subsystem (IMS) как для функций предоставления служб, так и для функций управления. IMS определяет набор точек ссылки (reference point) между различными IMS-объектами, и некоторые из них используют Diameter в качестве протокола для обмена сообщениями подписки, присутствия и биллинга. Например, точка ссылки Sh в IMS определяет набор Diameter-сообщений для подписки и уведомления.

Поскольку IMS продолжает развиваться, мы полагаем, что будет появляться больше Diameter-приложений, а также реализаций протокола Diameter.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=158789
ArticleTitle=Введение в Diameter
publish-date=01242006