Розробка рівнів та моделі обміну даними між ними

На ефективність взаємодії пристроїв в мережі впливає якість всієї сукупності протоколів, що складають стек, зокрема, те, наскільки раціонально розподілені функції між протоколами різних рівнів і наскільки добре визначені інтерфейси між ними.

При розробці рівнів дотримуються наступних принципів архітектури відкритих систем:

кількість створюваних рівнів має бути мінімально достатньою для розбиття процессу передавання та обробки інформації на частини, доступні для легкого розуміння;

кількість створюваних рівнів повинна не перевищувати величини, за якою починається ускладнення інтеграції та опису рівнів;

межу між рівнями слід проводити через точки, у яких опис сервісу може бути коротшим, а кількість взаємодій через межу – мінімальною;

подібні функції мають зосереджуватися в одному рівні;

поділ на рівні має бути таким, щоб забезпечувалась незалежність рівнів та можливість модернізації чи заміни будь-якого рівня без зміни інших рівнів;

наявність для кожного рівня засобів ідентифікації відправника та отримувача;

для кожного рівня мають бути визначені правила переносу даних[4] на сусідні рівні і в межах рівня; протокол також має визначати кількість логічних каналів в межах зєднання (переважно їх два – для звичайних і термінових повідомлень) та їх пріоритети;

для кожного рівня має бути визначена процедура перевірки правильності переданих та отриманих даних та способи коригування помилок;

для кожного рівня має бути визначена процедура відновлення правильної послідовності повідомлень у разі втрати її на попередньому рівні;

для кожного рівня має бути визначена процедура узгодження швидкостей передавання та приймання даних для вузла-передавача і вузла приймача, які підтримують різні швидкості обміну даними;

для кожного рівня має бути обраний оптимальний розмір повідомлень, що передаються, з урахуванням обмежень на їх фізичний розмір на кожному рівні та падіння ефективності передавання в міру зменшення розміру повідомлення. Одним з шляхів такої оптимізації є обєднання модулів даних у пакет из наступним їх відновленням;

кожний з рівнів має мати можливість прийняти рішення про використання одного й того самого з’єднання для здійснення кількох процесів обміну даними. Таке використання називається мультиплексуванням;

кожний рівень має мати можливість незалежно від інших приймати рішення про вибір оптимального шляху транспортування повідомлення. Так, при пересиланні інформації між двома країнами верхній рівень обирає шлях на основі обмежень законодавства у різних країнах, а нижній – виходячи з завантаженості ліній зв’язку.

Як видно з вищеперерахованих вимог, кількість рівнів може бути різною, проте у всіх випадках будуть присутні: фізичний рівень, протоколи якого описуватимуть фізичний обмін даними чи передачу бітів через фізичне середовище між одиницями термінального обладнання (Data Terminal Equipment, DTE), зі способами кодувань бітів, порядком їх передачі термінальному пристрою та схемою з’єднання з пристроєм; канальний рівень, який відповідає за передачу даних між двома вузлами мережі, і, відповідно, визначає поля кадрів та способи виявлення і коригування помилок; мережевий рівень, протокол якого задає метод маршрутизації та пов’язаного з нею адміністрування; транспортний рівень, протоколи якого керують сегментуванням даних, якістю та ефективністю (співвідношенням пропускної здатності канала до витрат на її забезпечення) їх транспорування та прикладний рівень, протоколи якого визначають інтерфейс з користувачами, способи доступу до мережі, додаткові послуги користувачам та управління терміналами.

Протоколи канального рівня забезпечують доставку даних між будь-якими вузлами тільки в підмережі з певною типовою топологією, наприклад топологією ієрархічної зірки, що не дозволяє будувати мережі з розвиненою структурою, наприклад, мережі, що об'єднують кілька мереж підприємства в єдину мережу, або високонадійні мережі, в яких існують надмірні зв'язки між вузлами. Можна було б ускладнювати протоколи канального рівня для підтримки петлеподібних надмірних зв'язків, але принцип розділення функцій між рівнями приводить до іншого розв'язку. Щоб, з одного боку, зберегти простоту процедур передачі даних для типових топологій, а з іншою допустити використання довільних топологій, вводиться додатковий мережевий рівень.

Призначенням кожного рівня є надання послуг (сервісів) суміжному вищому рівню. Активний єлемент кожного рівня називають сутністю (entity). Сутність може бути реалізована програмно чи апаратно, наприклад, у вигляді мікропроцесора. Сутності одного рівня на різних вузлах (машинах) називають одноранговими. Сутності рівня «і» реалізують сервіси, які використовуються рівнем «і +1». Рівень «і» називають постачальником послуг (сервісів) для рівня «і +1», рівень «і +1» - споживачкм послуг. Для надання цих послуг рівень «і» може використовувати сервіси рівня «і -1». Рівень може надавати послуги різного класу, наприклад, швидке, але дороге з’єднання, чи дешеве, але повільне.

Послуги (сервіси) доступні через точки доступу до сервісів SAP (Service Access Points), у яких вищий рівень може отримати доступ до послуг нижчого. У кожної такої точки є ідентифікатор (адреса), який однозначно визначає її положення. Точки доступу виконують ту ж саму функцію, що й номери телефонів чи поштові адреси при встановленні зв’язку між двома об’єктами.

Для міжрівневого обміну інформацією необхідна домовленість про набір правил міжрівневого інтерфейсу. Сутність рівня «і +1» передає елемент даних інтерфейсу IDU (Interface Data Unit) сутності рівня «і» через точку доступу до сервісів. Елемент даних інтерфейсу складається з елементу даних послуги SDU (Service Data Unit) і певної керуючої інформації, яка забезпечує виконання нижнім рівнем свого призначення (наприклад, визначає кількість байт у елементі даних). Щоб передати елемент даних послуги, сутність рівня «і» може розбити його на кілька фрагментів, спорядити кожний з них заголовком і відправити у вигляді окремих елементів даних протоколу PDU (Protocol Data Unit), які відносно цього протоколу виступають базовими модулями даних. Назви цих модулів залежать від рівня: переважно модуль даних, який передається на канальному рівні, називають кадром (frame); модуль даних, який передається на транспортному рівні, називають сегментом (segment); на мережевому - пакетом (packet), вище мережевого – повідомленням (message). Заголовки елементів даних протоколу використовуються одноранговими сутностями для підтримки власних протоколів. Вони визначають, які базові модулі елементів даних містять дані сервісу, а які – керуючу інформацію, забезпечують послідовну нумерацію одиниць даних тощо.

Послуга (сервіс) формально описується набором примітивів чи операцій, доступних користувачеві чи іншій сутності для отримання послуги. Ці примітиви змушують сервіс виконувати певні дії чи виступають як відповіді на дії іншої однорангової сутності. Всі примітиви підрозділяють на чотири класи:

· запит (request) - примітиви відбивають потребу сутності у сервісі для виконання роботи;

· індикація (indication) – примітиви задовільняють вимогу проінформувати сутність про подію;

· відповідь (response) - примітиви відбивають бажання сутності відповісти на подію;

· підтвердження (confirm) – примітиви підтверджують отримання відповіді на запит.

Поняття «сервіс» не можна плутати з поняттям «протокол». Сервіс окреслює набір примітивів (операцій), які нижчий рівень надає вищому без визначення правил реалізації повідомлень. Сервіс описує інтерфейс між двома рівнями, з яких нижчий рівень є постачальником, а верхній – споживачем сервісу. Натомість протокол фіксує правила, які описують формат і призначення кадрів, пакетів чи повідомлень, якими обмінюються однорангові сутності в межах рівня. Сутності використовують протокол для реалізації визначень їх сервісів. Вони можуть змінювати протокол за своїм бажанням за умови збереження незміннми сервісів, які вони надають своїм користувачам. Протокол стосується реалізації сервісу і не відчувається користувачем.

Рівень «і» може надавати рівню «і+1» послуги (сервіси) на основі двох типів моделей обміну даними: на основі встановлення з’єднання і без встановлення з’єднання. Типи та приклади застосування сервісів залежно від використаної моделі обміну даних наведені у табл. 5.1.

Модель на основі з’єднання є моделлю типу «телефонний зв’язок»: сервіс спочатку встановлює з’єднання, потім його використовує і далі розриває зв’язок. Таке з’єднання працює подібно до труби – порядок отримання елементарних інформаційних об’єетів (бітів) такий самий, як і порядок їх відправлення.

Таблиця 5.1