1. AAA і Diameter
2. Малюнок 1. Взаємозв'язок між базовим протоколом Diameter і різними Diameter-додатками
3. Relay Agent (агент-ретранслятор)
4. Proxy Agent (проксі-агент)
5. Малюнок 2. Diameter Proxy Agent
6. Малюнок 3. Diameter Redirect Agent
7. Малюнок 4. Diameter Translation Agent
8. Малюнок 5. Diameter Packet Format
9. Таблиця 1. Повідомлення, певні в базовому протоколі Diameter
10. Виявлення однорангового вузла
11. З'єднання і сесія
12. Малюнок 6. Сесія і з'єднання в Diameter
13. сесія
14. завершення сесії
15. AAA в Diameter
16. облік
17. Обробка помилок
18. Таблиця 2. Порівняння протоколів Diameter і RADIUS
19. на Закінчення
20. Ресурси для скачування

AAA-протокол наступного покоління

Протокол 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 має однорангову архітектуру (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

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

Redirect Agent виступає в ролі централізованого сховища конфігурацій для інших Diameter-вузлів. Беручи повідомлення, він перевіряє свою таблицю маршрутизації і повертає відповідь було надіслане разом з інформацією про перенаправлення оригінальному відправнику повідомлення. Це могло б бути дуже корисно для інших Diameter-вузлів, оскільки їм не потрібно зберігати список записів про маршрутизації локально, і вони могли б, при необхідності, шукати Redirect Agent. На малюнку 3 зображено робота Redirect Agent. Сценарій, показаний на малюнку 3 , В основному ідентичний сценарієм, показаному на малюнку 2 , Але в цей раз Proxy Agent не знає адреси пов'язаного Diameter-вузла в example.com. Отже, він шукає інформацію в Redirect Agent своєї власної області для отримання адреси.

Малюнок 3. 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-повідомлення

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

В таблиці 1 перераховані всі повідомлення, певні в базовому протоколі Diameter:

Таблиця 1. Повідомлення, певні в базовому протоколі Diameter

Назва повідомлення Абревіатура Код команди Abort-Session-Request (припинення-сесія-запит) ASR 274 Abort-Session-Answer (припинення-сесія-відповідь) ASA 274 Accounting-Request (облік-запит) ACR 271 Accounting-Answer (облік-відповідь ) ACA 271 Capabilities-Exchanging-Request (можливості-обмін-запит) CER 257 Capabilities-Exchanging-Answer (можливості-обмін-відповідь) CEA 257 Device-Watchdog-Request (пристрій-сторожовий таймер-запит) DWR 280 Device-Watchdog- Answer (пристрій-сторожовий таймер-відповідь) DWA 280 Disconnect-Peer-Request (від'єднання-рівноправний вузол-запит) DPR 282 Disconnect-Peer-Answer (від'єднання-рівноправний вузол-відповідь) DPA 282 Re-Auth-Request (re-аутентифікація -запр с) RAR 258 ​​Re-Auth-Answer (re-аутентифікація-відповідь) RAA 258 Session-Termination-Request (сесія-завершення-запит) STR 275 Session-Termination-Answer STA (сесія-завершення-відповідь) STA 275

Виявлення однорангового вузла

До появи 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-клієнт передасть повідомлення 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

Diameter RADIUS Транспортний протокол Орієнтовані на з'єднання протоколи (TCP і SCTP) Протокол без встановлення з'єднання (UDP) Захист Hop-to-Hop, End-to-End Hop-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.

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

Схожі тими

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів