Стандартизація в інфраструктурі osі
В рамках моделі на кожному рівні можна розробляти один або більше стандартних протоколів. Дана модель в загальних рисах визначає функції, які необхідно виконувати на даному рівні, та сприяє процесу розробки стандартів з двох причин:
оскільки функции на кожному рівні повністю визначені, стандарти можуть разроблятися незалежно та одночасно на кожному рівні. Це прискорює процес розробки стандартів;
оскільки межі між рівнями визначені, зміни в стандартах на одному рівні не впливатимуть на вже існуюче програмне забезпечення на іншому рівні. Це спрощує впровадження нових стандартів.
На рис. 8 показано використання моделі OSI в якості такої инфраструктури. Всі комуникаційні функції розділені на сім окремих рівнів на основі наведених раніше принципів. Ці принципи складають основу модульного проектування. Тобто всі функції розподіляються між декількома модулями, при цьому интерфейс між модулями повинен бути по можливості простим. Крім того, використовується принцип приховування інформації при проектуванні: на нижніих рівнях проходить більш детальна інформація, рівні, розташовані вище, не залежать від такої деталізації. Кожний рівень надає сервіси рівню, який знаходиться вище нього, та реалізує протокол рівноправного рівня в інших системах.
На рис. 9 показані особливості стандартизації на кожному рівні. Ключевими можна вважати три елементи:
специфікація протоколу: два об’єкта на однакових рівнях в різних системах взаємодіють з допомогою протоколу. Оскільки взаємодіють дві різні відкриті системи, протокол повинен бути визначений дуже точно. Сюди відноситься формат PDU, семантика всіх полів та допустима послідовність PDU;
визначення сервіса: на додання до протоколу або протоколів, які діють на даному рівні, стандарти необхідні для сервисів, які кожний рівень надає вищерозташованому рівню. Звичайно визначення сервисів еквівалентне функціональному опису, яке визначає тільки сервіси, що надаються але не спосіб надання цих сервисів;
адресація. Кожний рівень надає сервіси об’єктам вищестоящого рівня. На ці об’єкти посилаються з допомогою точок доступу до сервісу (Service Access Point, SAP). Тому мережеві точки доступу до сервісів (Network SAP, NSAP) вказують на транспортний об’єкт, який є користувачем мережевого сервісу.
Необхідність забезпечення точної специфікації протоколу для відкритих систем очевидна. Що стосується визначення сервисів, то мотиви надання лише функціонального опису пояснюються наступним. По-перше, взаємодія між двома суміжними рівнями відбувається в межах окремої відкритої системи та не має відношення до будь-якої іншої відкритої системи. Тому оскільки рівноправні рівні в різних системах надають однакові сервіси їх вищестоящим рівням, деталі надання цих сервисів можуть відрізнятися одна від одної от друга без втрати можливості взаємодії. По-друге,звичайно суміжні рівні реалізуються на одному процесорі. В такому випадку бажано надати системному програмісту свободу використання обладнання та операційної системи для забезпечення найбільш ефективного інтерфейсу.
Що стосується адресації, то використання адресного механізму на кожному рівні реалізується у вигляді точки доступа до сервісу, яка дозволяє на кожному рівні обслуговувати користувачів з вищестоящого рівня. Таке мультиплексування користувачів не обов’язково для кожного рівня, але модель допускає таку можливість.